►
From YouTube: OKD Working Group 2020 12 22 Full Meeting Recording
Description
OKD Working Group 2020 12 22 Full Meeting Recording
https://okd.io
https://github.com/openshift/community/projects/1
A
All
right
so
yeah
I'll
share
the
screen
again.
So
welcome
everybody.
This
is
the
official
last
meeting
that
I
have
of
2020
thank
the
lord
it's
over
and
and
the
last
working
group
meeting.
So
thank
you
for
coming
and
joining
us.
I
don't
have
a
huge
agenda
today.
I'm
just
sharing
that
thing.
A
few
people
have
wandered
in
over
the
past
little
while
so
I
wanted
to
make
sure
we
had
this
meeting
in
case
they
showed
up.
A
A
B
A
C
So
yeah
we're
preparing
the
next
12.6
z
stream
release.
It's
been
quite
4.6
has
introduced
quite
a
few.
Oh
we've
had
some
fallout
with
4.6,
because
the
the
switch
over
to
fedora
33
packages
came
rather
late
in
in
the
cycle.
So
yeah
we
hit
a
few
issues,
especially
with
regards
to
networking
dns,
because
the
underlying
os
fedora
in
33
had
some
major
changes,
how
they
yeah,
for
example,
they
use
resolve
d,
and
we
had
to
revert
that
change
for
now
to
make
it
work.
C
Everything
is
being
worked
on,
though
I
can
paste
a
link
to
the
current
fracking
bug
for
the
next
stable
release
so
and
in
the
future.
We
will
actually
streamline
this.
Just
yesterday,
a
rawhide
fedora
coreos
stream
was
introduced,
so
we'll
have
that
testing
much
earlier
in
the
future
on
the
future
package
set
of
fedora
and
hopefully
not
run
into
issues
as
big
as
as
this
time
around.
C
Yeah,
I
was
just
gonna
say
I
think,
for
those
who
don't
hit
those
problems,
because
they
only
affect
a
subset
of
platforms.
I
think
for
those
of
you,
everything
should
continue
to
work.
Fine.
We
do
have
one
issue
with
our
image
mirroring
at
the
moment
there
was
a
some
wreckage
in
part
man
that
apparently
the
images
that
we
push
to
quay,
don't
have
the
correct,
manifest
the
version
and
those
can't
be
mirrored.
C
D
C
F
F
Right
it
wasn't,
I
wasn't
trying
to
do
it
from
a
repo
internal
repository,
a
mirrored
one.
No,
it
was
very
strange
one
of
the
it
worked
perfectly
until
the
very
end
when
it
upgrades
the
nodes
and
then
the
there
was
one
node
that
got
an
obs
configuration
failure
for
some
reason,
because
it
was
it
was
started
up
and
it
started
up
fine,
but
then,
when
it
rebooted
it,
it
wasn't
there
anymore
and
so
that
node
failed
and
then
there
was
sort
of
a
cascading
things.
F
So
I
I
got
the
image
registry
back
by
going
with
a
a
a
zero
image
image
registry.
Basically,
but
but
of
course
all
the
I've
got,
I
don't
know
hundreds
of
pods
that
are
in
you
know
they
can't
get
their
images
to
restart
et
cetera,
et
cetera.
So
so
I
think
it
was
all
somehow
and-
and
I've
got
something
on
the
the
395
report
on
that,
but
it
does
seem
slightly
different
from
the
other
failures
and
I've
been
doing.
E
C
Yeah,
I
think
it's
it's
a
it's
two
things
here
the
mirror
step
first,
and
then
you
also
use,
I
think,
podman
within
or
at
least
this
container
image
containers
image
library
within
oc
when
you
actually
mirror
that
over
within
the
client,
so
yeah.
As
far
as
I
can
tell
the
the
fix,
we're
hoping
that
we're
hoping
will
resolve
this
is
the
one
I
just
linked
and
that
you
also
linked
joseph
yeah,
I'm
not
sure
how
how
this
came
to
be
and
how
this
could
be
missed.
C
C
G
C
Exactly
and
that's
actually
a
pretty
strict
rule,
so
we're
yeah
we're
definitely
looking
at
being
backwards,
compatible
forward
compatibility.
Obviously
isn't
you
know
we
can't
promise
that,
but
we're
pretty
good
at
you
know,
for
example,
if
you
have
the
4.6
client,
you
can
4.4
cluster
with
it
that
that
should
work,
and
that
is
actually
supported.
I
think
in
the
in
the
openshift
product,
so
it'll
it'll
also
work
with
okd.
C
Especially
with
the
introduction
of
new
apis,
you
know
crds
that'll,
you
know
they
will
will
just
not
be
supported
in
the
newer
client.
Obviously,
that's
mostly
a
problem
when
you
have
minor
version
bumps,
not
patch
patch
releases,
but
still
it's.
It's
definitely
best
practice
to
always
keep
up
to
date
and
you
it's
yeah,
it's
safer
to
to
just
be
up
to
date
and
be
at
the
leading
edge
with
the
client,
because
it's
always
backward
what's
compatible.
G
G
G
We
should
probably
just
have
it
upgraded
to
the
latest
to
the
latest
versions
because,
like
that
makes
it
easier
for
people
to
you
know,
go
between
f
cause,
okd
and
and
fedora
and
stuff,
and
it's
not
like
there's
api
promises
from
a
single
from
a
binary
program
that
you
just
you
know.
You
can't
like
build
a
pen
on
on
the
openshift
clients
and
like
embed
some
of
its
code
into
something
else.
A
A
A
G
C
Yeah
we
had
a
look
at
that
last
year.
When
we
started
to,
you
know,
do
ok,
d4
and
it
was
decided
it's
not
really
viable
for
us
to
go
through
rpm
packaging
for
everything,
and
especially
because
there's
there's
rapid
changes
right.
We
could
obviously
build
oc
ddrd
the
origin
package
for
each
okd
release,
but
what
we
can't
currently
do
is
just
take
that
from
from
ci,
like
all
the
other
artifacts-
and
you
know,
have
continued
continuously
have
the
most
up-to-date
version
in
there.
G
A
G
Yeah
I
mean
the
other
bit
about
you
know.
Having
the
clients
in
in
fedora
itself
is
that
you
know
fedora
is
starting
to
have
openshift
based
infrastructure
and
having
the
community
be
able
to
like
work
with
openshift-based
applications
and
stuff
so
having
the
clients
easily
available
through.
There
makes
it
a
lot
more
straightforward
for
that
to
be
plugged
into
basically
like
a
ton
of
workflows.
So
not
again,
so
there
are.
There
are
compelling
reasons
to
at
least
have
the
clients
in
there,
but
yeah.
C
C
So
the
the
main
or
the
biggest
part,
that's
still
left
to
do-
is
getting
the
installer
merged
and
we've
kind
of
just
made
the
enhancement
into
a
kind
of
a
checklist.
Most
of
that
is
already
implemented
and
has
already
been
done.
That's
really
yeah
just
to
to
summarize
all
of
that,
so
the
installer
pr
that
that
is
linked
in
the
enhancement
that
vadim
created
is
the
biggest
missing
piece
there,
and
then
we
will.
There
will
be
discussion
either
on
the
pr
itself
or
on
the
on
the
enhancement.
C
I
I
I
would
suggest
you
follow
both.
If,
if
you
want
to
monitor
that
closely
and
because
we've
had
changes
in
the
installer
team,
there's
a
new
team
lead
so
yeah.
We
will
see
whether
that
approach
is
fine
with
them.
It
certainly
works
it's
what
we
have
in
in
the
in
the
okd
fork
of
the
installer
currently,
and
it
kind
of
allows
us
to
build
both
the
okd
and
the
ocp
binaries
from
the
same
branch,
which
is
yeah
what
we
want
to
do
like
with
the
machine
config
operator.
C
So
it
is
not
a
blocking
issue.
It's
really
just
kind
of
tech
depth.
Cleanup
nothing
anybody
really
has
to
worry
about,
but
it
will
help
vadiman
and
me,
you
know
with
with
maintenance,
because
we
can
then
drop
the
maintenance
of
the
of
the
fork
that
we
have.
We've
been
rebasing
it.
So
there
isn't
really
as
you
as
you
know,
just
we've
been
over
pushing
pushed
over
as
some
of
your
commits,
unfortunately,
with
the
azure
support
there
as
well
yeah
things
like
that.
E
C
Yeah,
so
I'm
not
sure
how
we
have
configured
it
currently,
but
when
we
do
this
a
release,
promotion
right,
our
our
releases-
are
just
promoted
from
prague
from
from
ci
right.
So
we
have
this
continuous
system
that
always
has
the
newest
parts
of
you
know
of
all
the
repositories
and
then,
when
we
decide
to
to
push
a
release,
we'll
just
take
that
most
current
date
of
things
and
and
tagged
that
as
a
release
and
a
mirror
to
quay
so
yeah.
C
We
could
maybe
even
make
that
work
there,
but
yeah,
I'm
not
sure
right
now,
it's
probably
just
aws,
but
we
really
want
to
make
the
releases
tested
more
and
I'm
not
sure
they're,
probably
just
running
but
not
blocking
at
this
time,
but
yeah.
That
is
definitely
thing
we
wanna
ensure
in
the
future
more
as
well,
and
that
that's
even
going
that's
going
to
be
easier
as
well.
When
we
have
just
one
installer.
E
E
A
D
E
I
can
try
to
find
it
yeah,
which
version,
because
there
was
an
extremely
old
one
there.
Yes,
it
looked
nuts
and
used
one
it's
this
one
and
it's
the
same
version
as
in
the
repos.
I
don't
know
because
the
redhead
version
is
1.2.1
and
this
one
is
dot
15,
something
I
don't
know
because
it's
the
same
version
as
in
the
repositories
on
operator
hub,
but
the
red
hat
version
is
versioned
different.
B
E
E
C
We
yeah
I'm
working
internally
to
to
make
that
part
of
the
default
release,
strategy
to
kind
of
have
regular
and
timely
community
releases
there
as
well
for
the
time
being,
the
easiest
is
to
build
them
yourself.
I
get
I'd
say
so
you
can
go
to
the
repositories,
there's
the
container
images
and
everything
there.
C
Then
you
can
kind
of
build
them
from
there
create
your
own
manifest,
and
even
that
way
we
could
even
allow
for
those
builds
or
for
the
for
those
package
minor
pests,
if
you
create
them
to
be
to
be
added
to
the
community
operators
yeah,
because
what
we
currently
don't
have
is
this:
this
release,
automation,
right.
We
have
release
automation
for
our
internal
builds,
but
then
you
have
to
kind
of
copy
everything
manually
over
into
the
community
operators.
C
So
how
you
really
want
to
do
is
get
all
the
teams
to
to
create
those
prs,
and
then
you
know,
release
to
the
okd
or
to
the
to
the
operator
hub
catalog
that
is
included
in
okd,
but
you
can
always
do
that.
Yours,
yourselves
as
well.
If
you
see
an
operator
and
it's
you
know
it's
not
there,
yet
you
can
kind
of
add
it
to
this
catalog
yeah.
We
would,
which
would
be
if
for
something
the
community
wants
to
help
with.
A
Could
we
do
something
like
a
a
hackathon
on
community
operators,
post
that
and
then
get
somebody
from
the
opera
I
mean
I
could
is?
Is
that
a
worthy
thing
to
spend
energy
on
is
to
build
all
the
ones
that
we
need
for
once
four
sixes
stable
to
go
and
build
it,
and
then
then
the
next
iteration
of
four
six
would
pick
all
of
that
up.
C
Exactly
so
yeah
I
I
think
that
would
make
sense,
because
I'm
it's
it's
not
a
super
quick
process
internally
to
get
all
the
teams
to
change
their.
You
know
their
release
methodology
here
and
because
it's
also
extra
work
for
them.
We
don't
currently
have
automation
for
it,
which
is
kind
of
probably
the
biggest
blocker,
for
if
it
was
just
one
more
click
for
everybody
that
they
easily
be
able
to
do
it.
C
But
it
is
a
bit
more
work,
so
I
think
yeah
having
a
hackathon,
because
because
we
can't
do
that
work
ourselves
as
a
as
a
community
working
group,
everything
is
open
source.
We
just
have
to
build
images,
push
them
somewhere
on
quay,
for
example,
and
then
add
those
manifests
yeah
catalog,
so
they
are
picked
up
by
okd.
E
E
E
E
C
And
kind
of
manage
those
images
within
our
group
because
yeah,
oh,
yes,
pushing
images
to
quay.
You
know
everything
is
built
internally
in
the
ci
system
and
then,
when
they
release
it,
they
have
a
totally
separated
internal
system
for
building
those
releases
and
essentially
making
those
releases
for
quay
would
replicate
that.
So
it's
not,
they
would
do
it,
but
it
would
have
to
be
super
easy.
H
C
I
do
think
in
the
long
term.
We
want
that.
Definitely
because
we
want
the
images
to
just
you
know
be
automatically
pushed
on
a
release
out
to
the
community
variant
as
well
yeah,
but
I
think
for
now
it's
probably
easiest
to
just
do
that
in
our
own
name
space,
but
instead
of
you
know
each
one
of
us
doing
that
ourselves.
A
I'm
thinking
that
when
we
come
back
in
2021
at
the
next
working
group
meeting,
if
we
could
that
we
could
also
invite
some
of
the
people
who
created
the
operators
to
come
to
that
hackathon
too,
or
the
people
in
charge
of
the
pipeline
of
building
them
all
so
that
we
could
do
it
as
a
cross-community
collaboration.
They
can.
Maybe
we
give
them
a
lightning
talk
to
talk
about
their
operator
and
then
we
hack
on
it
and
get
our
build
for
it.
A
That
might
be
a
good
good
start
so
that
the
first,
whatever
the
first
meeting
is
we
have
in
2021
in
january.
I
don't
know
what
the
date
is
at
the
moment,
but
we
could
talk
about
doing
that
and
then
you'd
have
a
little
set
of
documentation
and
have
already
done
one,
and
we
can
see
if
that
worked,
and
if
we
need
to
create
our
own
clay
space
for
for
ours.
But
then
because
I
I'm
pretty
tied
in
with
the
operator
community
folks.
H
C
C
C
E
Okay,
well,
I
will
do
that
and
the
very
last
question,
a
short
one.
The
version
from
the
tactile
operator
compared
to
the
openshift
version
is
completely
different,
but
I
don't
find
any
clue
in
the
repository
of
this
version.
1.1
used
in
openshift,
it's,
there
is
only
a
version,
0.15
dot.
Anything.
Are
you
sure
that
the
source
code
from
openshift
of
the
shift
version
is
still
the.
D
E
C
D
A
I
think
that
is
quite
okay,
so
so
it
sound
sounds
like
the
hack,
maybe
merging
the
hackathon
and
the
contributor
summit,
or
doing
some
two-day
thingy
might
be
in
february
march,
might
might
work
out
nice
unless
and
and
let's,
let's
just
bring
it
up
at
the
next
call
on
in
january
and
see
if
we
can
get
that
move
forward.
Are
there
anything.
C
I
think
it's
a
good
idea
to
invite
those
operator
team
have
them
present
their
operator
and
then
have
them
help
us
as
a
working
group
create
a
community
version
of
it,
because
I
know
they
they
would
like
to
see
it,
but
they
just
don't
have
the
time
as
a
team
there's.
No
nobody
schedules
that,
because
it's
not
really,
you
know
that
they
have
features
to
implement,
and
it's
not
that
high
of
priority
for
most
teams
so
giving
them
this
kind
of
opportunity.
C
A
A
If
you
can
find
that
then
I'll,
then
I'll
look
and
after
the
january
meeting
and
I'll
try
that
and
I'll
talk
to
daniel
messier
who's,
the
pm
for
it
for
operator
of
things
and
a
couple
of
the
I'll
go
back
to
a
couple
of
the
working
group
meetings
on
the
operator
framework
folks.
But
it's
really
tracking
down
the
individual
project
themselves
and
making
sure
like
the
rook
or
the
tecton
person
that
and
and
getting
them
there,
but
we
might
get
some
oversight
from
the
operator
framework
or
support
from
them
as
well.
E
A
E
E
C
C
We
will
have
to
build
them
ourselves.
There
is
no
automation
as
of
now,
so
we
have
some.
We
have
some
automation
for
this
in
in
the
windows,
containers
windows,
machine
config
operator
now,
but
even
there
we
only
use
that
for
ci
testing
at
the
actual
release
is
another
build
of
that
in
the
future.
Obviously
we
want
to
kind
of
mirror
that
from
ci,
ideally
but
yeah.
There
is
no
like.
E
D
C
D
E
E
Yeah,
I
have
done
the
same
recently
and
it
worked
great
but
yeah.
It
worked
with
the
query
images.
I
had
only
to
build
a
bundle
image
and
with
the
reference
I
changed,
the
reference
in
the
cluster
service
version
to
images
in
my
quave
folder.
That
was
a
step
I
I
made.
It
was
a
simple
set
command
in
in
some
of
one
of
the
scripts
and
anything
else
worked
out
of
the
box.
So
I
was
hoping
that
that
is
all
we
have
to
do.
D
It
also
creates
some
scaffolding
like
it.
It
automatically
creates
the
pipeline
service
account
yeah.
It
creates
the
open
shift
pipelines
namespace,
where
what
what
the
link
that
I
just
sent
you
here,
it's
more
generic.
It
creates
tecton
pipelines,
it
does
not
create
a
service
account,
so
so
we
probably
want
to.
We
probably
want
to
take
the
the
code
of
the
openshift
operator
and
use
it
to
build
the
to
build
the
bundle,
so
it
creates
all
the
boiler
plate
as
well.
A
D
A
G
A
D
G
There's
some
container
application
scaffolding
stuff
that
I'm
trying
to
get
opened
up
that
might
be
useful
to
you
know,
have
docs
or
or
instances
or
examples
and
stuff
is
okay
cookbooks.
If
that
fits
in
that
purpose.
If
so,
like
it'd
be
nice,
if
I
had
access
to
that
to
that
board,
so
I
could
add
stuff
when
that
is
figured
out,
although,
admittedly
I
don't
know
what
okd
cookbook
is
for
so.
A
A
A
D
G
D
H
E
D
G
So
charo
this
is
this
is
something
that
I
actually
have
been
thinking
about
a
little
bit.
So
you
know
about
packer
right,
like
the
the
get
forged
stuff
that
we
use
in
fedora
and
stuff
like
that.
So
jenkins,
sucks
and
also
there's
been
an
ask
to
have
containerized
packer.
I
don't
know
what
I'm
doing,
but
it
would
be
super
cool
if
we
could
probably
like
it's
a
relatively
straightforward
python.
Flask
based
application,
minimal
requirements
and
stuff
it'd
be
super
cool
if
we
could
maybe
work
together
on
doing
a
thing
where
we
take
this
application.
G
A
C
A
They
should
have
an
official
one
official
verified
community
and
bespoke
yes,
that
would
that
be
mine
and
you
should
wear
a
bow
tie
or
something
all
right.
So
I
think
we're
I'm
gonna
stop
sharing
and
I
think
we're
almost
to
the
end
of
our
hour,
so
everybody
even
those
silent
folks,
yeah
and
joseph.
I.