►
From YouTube: OKD Working Group 2020 05 12 Full Meeting Recording
Description
OKD Working Group 2020 05 12 Full Meeting Recording
A
One
day:
okay,
let's
get
started
so
I,
don't
I'm,
not
sure
what
the
agenda
should
be
today,
but
maybe
I'll
just
give
a
quick
update
on
what's
been
happening
in
the
past
seven
days,
unfortunately,
master
hasn't
opened
or
a
4.6.
Yet
so
we
can't
merge
any
of
the
MCO
PRS
and
well
that's
one
thing
and
on
the
Installer
side
of
a
team
and.
B
A
A
C
C
C
I
also
have
a
few
patches
for
installer
to
re-enable,
to
fix
a
few
things
in
Liberty
installer
and
automatically
detect
that
we're
running
on
a
single
node
and
inject.
A
few
manifests
for
at
City
pouring
grass
and
a
patch
to
MCO
to
scale
down
the
LCD
quorum
guard,
so
single
node
should
be
installed
to
be
able
to
to
run
without
additional
hacks.
C
Charro
has
a
great
repo
how
to
achieve
that
today,
but
it
needs
scaling
down
a
few
operators
and
we're
trying
to
avoid
that.
On
a
related
note,
I
release
I
created
a
beta
5
release
today,
but
it
fails
to
update
again
and
I'm
thinking
it's
an
actual
bug,
so
we
will
have
to
track
it
down.
I
think
we
won't
be
taking
down
the
b25
due
to
that,
because
it's
been
quite
a
long
time
since
previous
pizza,
but
we
can
discuss
it
today.
C
A
A
D
B
I
mean
now
we
just
have
to
come
up
with
some
cool
wacky
name
or
okay.
D
at
that
size,
like
yeah
I
mean
we
could
easily
just
compile
at
CD
inside
and
make
it
like
not
do
raft
consensus,
which
is
essentially
what
k3s
does
I
just
don't
know
what
the
hell
is
going
on
in
k3
us
at
all,
because
it's
all
there
other
choices
are
stupid
too,
but
you.
C
B
There's
no
point
to
it
because
well,
actually
there
is
a
point
like
the
main
reason
to
switch
to
sequel.
Lite
was
to
get
rid
of
RAF
consensus,
that's
that's
it,
and
also
because
sequel
is
written
and
see
it's
actually
way.
Smaller
at
runtime
like
go
is
fat,
that's
pretty
much
it
that's
pretty
much.
The
meat
and
potatoes
of
it
and
cutting
the
dough
fat
makes
it
small
enough
to
fit
on
a
Raspberry
Pi.
C
A
C
D
C
D
D
C
A
B
A
We're
not
we're
not
we've
been
pretty
clear,
we're
focusing
on
Fedora
and
we're
not
gonna
focus
on
that,
but
if
we,
if
we
chose
Fedora
images
for
all
the
all
the
containers
or
all
the
operators
on
operator,
you
know
we
would
still
need
CentOS
based
containers
for
the
Centaurs
version.
Well,
we
can
use
CentOS
containers
on
F,
course-based,
okay
right
but
yeah
I
mean
there
I'd,
be
totally
fine
with
just
having
Fedora
containers
and
push
Fedora
they're
everywhere,
but.
B
A
And
I
I
do
think
we
should
probably
split
the
the
operator
hub
thing
into
a
second
proposal:
enhancement
proposal
buddy,
because
the
okay,
the
enhancement
proposal
right
now,
is
more
well.
The
one
that
I
still
haven't
published
is
really
focused
on
just
getting
the
the
core
operators
purged
and
and
the
F
cross
branches
Forks
sort
of
to
get
rid
of
those
and
to
be
able
to
just
use
one
Operator
one
build
of
the
operators
for
both
okay,
Dee
and
Ossie
P.
B
B
C
C
C
A
A
The
Installer
will
have
to
wait
a
little
longer,
probably,
but
even
that
we
can
maybe
get
all
merged
in
4.6,
and
even
if
not,
we
won't
I
think
we
won't
block
on
the
on
the
Installer
to
to
be
merged
with
master
for
for
okay
D
to
go
GA
because
I
think,
once
once
we
have
sort
of
aligned
all
the
operators.
That's
that's
enough.
The
Installer
just
runs
once
at
installation
time,
and
it's
not
yeah.
It's
not
that
big
of
a
deal
to
maintain
that
one
fork
for
a
little
bit
longer.
C
A
I
just
saw
Mike's
question
is
okay,
they
still
on
track
for
a
4.6,
ga,
so
yeah
I
think
we're
still
on
track
there,
which
you
know
it.
We
might
even
be
releasing
in
the
4.5
OCP
timeframe,
because
will
will
merge
the
the
F
course
MCO
with
master
in
the
F
in
the
4.6
development
timeframe,
which
is
way
before
the
release,
and
then
once
we
have
sort
of
everything
in
one
master.
We
can
just
back
port
the
okay
D
specific
things
that
are
already
in
master
to
n
F
course.
A
A
So
I
don't
expect
a
lot
of
problems.
I
have
a
PR
open
that
sort
of
adds
dual
support
for
ignition
spec,
B,
3
and
spec
v2.
A
There
is
sort
of
the
transition,
the
reconciliation
between
a
system
that
has
v2
on
it
and
that
owes
to
go
to
v3.
But
luckily,
for
us,
that's
not
a
problem
we'll
have
to
deal
with
in
ok
D,
because
we
are
already
on
spec
3
and
we'll
just
have
an
MCO
that
supports
spec,
3
and
that'll.
Be
good
enough.
I!
Don't
really
expect
a
lot
of
problems
on
that
side.
A
Yeah,
it's
essentially
yeah
exactly
that
the
biggest
tasks
is
getting
em
Co
merged
and
then
creating
an
installer
ork
44.5.
That
will
need
a
few
where
we
just
need
to
carry
the
okay.
These
specific
things
that
we
haven't
figured
out
how
to
merge
yet
and
even
from
them
like
the
pull
secret
stuff
disabling
that
we
will
need
to
eventually
find
a
way
to
get
that
into
master
as
well.
A
And
if
we
decide
on
adding
a
build
flag
there,
we
may
even
be
able
to
merge
it
in
the
four
point:
six
window
there
as
well
but
yeah
to
be
honest,
I,
don't
expect
a
lot
of
problems.
It's
really
just.
We
have
two
now
aligned
with
the
OCP
releases,
of
course,
so
we
can
sort
of
get
the
0.50
CP,
GA
and
backport
all
the
okd
patches
to
that,
and
then
release
that
s
okay,
d,
GA
0.5.
C
C
C
B
C
A
A
C
A
And
the
MP,
the
one
thing
that
we
sort
of
are
how
we
are
depending
on
our
CP,
is
in
the
future.
We
we
of
course
want
to
be
able
to
to
deliver
a
stable
system,
so
we
want
to.
We
don't
want
to
release
off
of
branches
that
haven't
really
been
released
like
the
master
branch,
but
instead
we
want
to
build
off
of
release
branches
so
for
each
OCP
release
each
LCP
release
gets
branched
off
of
master.
A
So
we
have
like
a
release
for
point
to
release
for
point
three
and
so
on
branch
for
every
release
and
we
want
to
be
building
off
of
these
same
release
branches.
And
then,
when
the
next
branching
happens
of
the
next
release
happens,
we
will
transition
with
an
update,
of
course,
very
quickly
from
from
the
current
on
to
the
next
branch
or
from
from
the
previously
current
on
to
the
new
current
branch.
A
So
we
won't
be
maintaining
many
release,
branches
side-by-side
for
okd,
always
just
one
and
maybe
of
course,
that'll
overlap
a
little
bit,
but
we
really
want
to
have
people
upgrade
quickly
with
okt.
You
know,
of
course,
if
you're
paying
for
the
product,
you
can
stay
on
for
point
two
forever.
A
That
may
not
be
true,
but
you
know
that
there's
more
longer
support
and
lot
security
patches
and
everything
gets
back
ported
a
lot
longer
than
we
will
be
doing
in
okd
will
essentially
do
it
like
fedora,
where
we
have
a
maximum
of
one
past
release
that
is
still
sort
of
kept
up
to
date.
Well,.
C
We
still
have
Knightley's
which
are
built
automatically
and
there
is
nothing
which
can
stop
them
from
building
the
issues
that
they
live
just
48
hours.
So
if
you
mirror
them
very
quickly,
you
would
get
a
pretty
much
stable
release.
We
don't
test
their
upgrades,
so
you're
on
your
own
here,
but
the
official
for
stable
branch
yeah.
It
would
be
rolling.
Definitely
we
would
switch
to
for
the
54.6
seamlessly
unless
we
have
any
other
ideas,
but
that's
pretty
much
the
goal
right
now.
C
A
Yeah,
it's
so
we'll
always
have
the
builds
off
of
the
master
branch,
of
course,
and
you'll
be
able
to
use
them
and
they'll
be
upstream
to
what
what's
in
the
product
right
now,
but
you
know
for
the,
but
just
the
usual
okd
user.
We
will
sort
of
be
building
off
of
the
same
release,
branches
and
yeah
Joseph.
You
asked
whether
ok
d4
will
never
be
real
upstream,
it's
sort
of
a
a
sibling
stream,
it's
the
same
codebase
but
built
for
a
different
operating
system
for
a
different
base.
A
Os
and
of
course
you
know,
it's
ok,
D.
There
is
no
paid
support,
there's
community
support,
which
is
what
what
we've
been
doing
here
a
little
bit
and
that
will
hopefully
be
thriving
a
little
bit
more
once
more
people
get
to
use
it
and
actually
can
participate
in
helping
each
other
out,
but
yeah,
it's
more.
A
It's
more
of
an
unsupported
OCP
yeah
like
Fedora,
well,
yeah,
maybe
yeah,
it's
kind
of
like
rel
and
Fedora,
but
different
I
mean
the
packages
are
also
kept
up
to
date,
but
the
colonel
isn't
and
that's
kind
of
the
same.
We
will
have
the
same
operators
and
maybe
build
onto
different
container
images,
but
they're
essentially
the
same
code.
A
It's
just
the
base
operating
system
is
a
different
one,
has
a
different
kernel
and
yeah,
and
so
when,
of
course
in
okd,
we
it'll
be
the
sort
of
the
the
testing
round
for
all
kinds
of
new
features
we
want
to
bring
into
okt,
so
it
may
be
that
will
build
ok,
D
with
cgroups,
v2
enabled
or
I'm
pretty
certain.
We
will
do
that
before
that
will
land
in
OCP,
but
that
should
really
be
just
a
configuration
thing
and
not
really
require
any
huge
differences
in
code
at
that.
At
that
point,
the
well.
A
Yeah
exactly
so,
I
I
I
assume
or
I
expect
that
OCP
will
handle
this
transition
much
more
conservatively.
Then
we
will
in
okay
d,
because
yeah
oh
I,
think
we
will
see
see
groups
b2
in
okay
D
before
will
see
it
in
OCP
enabled,
but
that's
just
it's
not
on
the
cluster
side,
it's
more
because
the
base
operating
system-
maybe
which
is
you,
know,
redhead
core
OS,
as
opposed
to
Fedora
core
OS,
a
redhead
core
OS,
wouldn't
maybe
supported
yet
well
Fedora
core
wise
theoretically,
already
supports
it.
Yeah.
B
Well,
the
funny
thing
is
I'm,
pretty
sure
the
in
that
particular
example
it'll
be
backwards,
rel
core
OS,
we'll
get
to
it
first,
because
Fedora
core
OS
keeps
turning
it
off
because
of
okd
though,
and
dr.
oh,
it's
it's
gonna,
be
interesting,
I'm,
pretty
sure
rel
core
OS
will
do
it
first
in
this
particular
circumstance,
because
it
doesn't
have
to
care
about
anything
else,
except
for
okay,
D.
Oh
sorry,
OCD
yeah,
that
openshift
thingy
yeah.
A
C
A
Fedora
core
OS,
right,
which
I
find
very
unfortunate,
that
we
sort
of
have
to
keep
that
I've
been
pushing
towards
just
focusing
on
your.
C
A
A
Yeah
I'm
not
sure
how
the
how
you
highway,
the
groups
version
mismatch
between
a
container
and
a
host.
All
that
behaves
to
be
honest.
B
The
the
problem
most
likely
is
that
system
D
isn't
handling
being
a
deputy
in
it
very
well
inside
of
a
container
cuz.
It's
not
really
big
one
and
as
to-
and
there
are,
there
are
certain
things
that
has
to
happen
for
it
to
behave
properly.
So
if
you
can
James
I
would
suggest
filed
like
a
bug
with
Red
Hat
and
file
a
support
ticket.
Does
that
really
has
to
be
fixed
since
rally
point
to
now
fully
supports
see
groups
v2.
A
B
Do
you
inherently
need
a
multi-service
container
to
do
the
same
thing
you
do
with
a
single
like
whiskey,
server
thing
in
in
Python
that
PHP
requires
you
having
nginx
or
Apache,
and
a
fast
CGI
server
of
some
kind
connected
to
each
other
to
do
the
right
things.
So
there
is
a
valuable
reason
to
have
it.
B
Whether
it
is
universally
required
is,
is
a
different
matter,
but
like
I
personally
as
part
of
my
work,
like
data
does
PHP
web
applications
out
of
the
wazoo
like
we're
gonna
wind
up
like
as
we
build
out
containers
we're
gonna
heavily
start
relying
on
multi
service
container
stuff,
because,
quite
frankly,
it's
the
only
reasonable
way
to
do.
This,
like
I,
have
personally
explored
the
other
architectures
it
sucks
it
really
really
sucks
or
for
those
types
of
apps.
B
So,
like
I
I
agree
with
you,
I
think
it'd
be
nice
if
we
didn't
need
them,
but
the
reality
is
that
there's
enough
architectures
out
there
that
I
that
I
and
others
have
to
deal
with
and
PHP
still
like
two-thirds
of
the
Internet,
it's
just
a
reality.
We
need
to
have
a
proper
way
to
do
it.
Otherwise
people
will
hack
bad
solutions
together
for
everything
else
and
that's
worse.
B
A
I
agree,
I
mean
there's,
definitely
a
huge
use
case
for
having
that
and
I.
Think
redhead
was,
you
know
we
we
essentially
enabled
systemd
in
containers
in
the
first
place,
for
you
know
that
there's
services
like
free
IPA
that
yeah
and
even
just
PHP,
it's
Multi
multi
services,
multiple
services
inside
a
container
and
that
that's
totally
fine
I
mean
I'm,
not
I'm,
not
one
of
I'm,
not
a
great
fan
of
the
docker
mantra
to
just
have
one
process
per
container.
A
Exactly
and
right
now,
just
it's
it's
it's
not
really
possible,
except
you
sort
of
create
your
own
container
from
scratch,
and
even
if
you
just
install
an
RPM,
it
always
pulls
in
system.
B
and
I
mean
yeah.
It's
even
though
starting
up
these
services
inside
the
container
without
system
D
is
always
kind
of
ugly
but
yeah.
C
B
This
is
I
think
where
we
should
go
next
with
the
working
group
we
should
move
to.
We
should
swiftly
move
to
make
it
so
that
the
Fedora
community
could
be
better
enabled
to
to
leverage
okay
be
for
things,
especially
since
there's
a
community
open
shift
like
it'd
be
good
to
start
like
making
that
make
Fedora
a
valuable
part
of
our
ecosystem.
Oh
I,.
A
Agree
wholeheartedly
here:
I
really
want
to
move
the
OpenShift
and
Fedora
communities
closer
together
because
I've,
you
know,
openshift
hasn't
been
a
prime
example
of
how
to
and
courage
you
know
a
community
to
grow
and
to
contribute
because
it
had
it.
Just
you
know,
hasn't
really
been
possible
in
the
past,
but
yeah
with
OK
dv4
I
think
we
should
really
go
in
the
direction
that
Fedora
has
gone,
and
you
know
just
try
to
get
people
from
Fedora
over
here
and
also
tried
us
as
I'm,
also
from
the
Fedora
community.
B
I
want
an
avenue
that
doesn't
involve
what
happened
with
our
do
like
I.
Just
I
want
to
completely
avoid
the
at
the
end
state
of
our
do,
which
is
they
advertise
that
they're
about
the
Red,
Hat
ecosystem
and
they're,
not
and
they're,
just
about
rel
and
CentOS,
and
there's
no
real
strong
community
buy-in
in
the
sense
of
like
community
contributions,
active
work
and
stuff
by
people
that
aren't
just
red.
Add
employees
working
on
the
OpenStack
team
like
I,
want
us
to
be
way
more
successful
than
that.
A
B
So,
like
it's
I,
I'm
happy
to
see
how
things
have
been
moving
forward
and
I
know
that
this
whole
the
fact
that
okd
has
been
focusing
on
Fedora,
core
OS
and
moving
towards
the
future
and
being
an
expanded
scope.
It
has
certainly
made
coca
tea
and
and
also
even
OpenShift,
an
easier
and
easier
thing
to
work
with
within.
C
B
C
C
B
C
B
C
I'm
sitting
supports
a
mode
called
once
from
so
it
emulates
a
proper
ignition
parsing
and
applying
files.
We
do
that
when
we
add
a
real
seven
note
and
you
can
create
a
Center
where
say
container
run
MCD
inside
of
it
give
it
the
bootstrap
ignition
and
that
would
become
a
full-blown
bootstrap
node.
You
just
need
world
connections
that
would
be
a
fun
experiment
to
play
with
I.
A
A
A
B
With
all
the
clean
ups
and
and
fixes
and
improvements,
you
know,
give
a
good
path
for
those
things
to
be
able
to
run
an
open
shift
as
well
and
and
enable
a
true,
proper
ecosystem
of
supporting
containerization
of
applications
and
services,
and
maybe
even
help
you
pull,
make
operators
and
stuff
like
that.
Cuz
hell
I
want
to
make
an
operator,
for
example,
a
pattern,
but
I,
don't
know
how
to
I,
don't
know
how
to
get
started.
B
A
A
And
I
mean
we,
we
do
have
all
of
this
in
an
open
shift
in
ok,
be
in
an
automated
manner,
so
it
just
makes
sense
to
sort
of
set
it
up
or
Fedora
and
go
from
there.
Yes,
so
that
makes
a
lot
of
sense
for
me
to
me
and
I
think
that's
that's
a
great
really
great
point.
Once
we
go
GA,
we
should
really
invite
the
container
sig
to
join
us
here,
and
you
know
create
some
yeah,
some
high
quality
content,
essentially
to
run
on
ok
tea.
There
yeah.
B
B
A
B
B
A
single
kind
of
packaged
thing
because,
like
I
certainly
do
have
applications
that,
for
example,
one
of
them
requires
loading,
a
custom,
kernel,
module
and
things
like
that,
and
you
just
really
can't
do
that
without
it,
without
a
virtualization,
wet
layer
and
I'm
not
really
going
to
enjoy
random
kernel
modules
into
the
host
of
OpenShift.
Like
that's
just
not
gonna
happen.
Sorry
so
like
being
able
to
bring
those
two
together
would
be
actually
a
really
compelling
an
interesting
story.
Cata
might
work,
but
I
don't
actually
know
anything
about
how
cata
containers
work.
D
Yeah,
just
from
from
the
infrastructure
management
perspective,
if,
if
operations
folks
just
learn
open
shift
and
we
can
migrate
all
of
those
other
special
ecosystems
into
that,
it's
a
much
reduced
workload
for
them,
they're
not
having
to
worry
about
vmware
ESX
and
vMotion
and
OpenStack
it
just
it
becomes
openshift.
Well.
I
think
that
Rev.
B
And
OpenStack
it
becomes
a
little
harder
of
a
proposition,
but
I
think
Rev
is
still
valuable,
because
Rev
is
the
thing
that
is
not
designed
for
you
to
just
you
know,
just
spawn
machines
for
no
reason
at
all
they're
very
much.
They
stick
around.
They
kind
of
live
forever
kind
of
thing,
so
Rev
to
me
still
makes
sense.
If
we're
talking
about
99%
of
my
workload
as
containers
and
then
I
have
like
maybe
1%
of
it
that
offers
you
know
some
require
some
virtual
machines
to
go
with
it.
B
Then
then
OpenStack
starts
making
a
bit
less
sense,
but
then
there's
the
whole
like
I,
want
to
auto
scale
my
openshift
cluster
and,
to
be
quite
frank,
openstax
pretty
much.
The
only
thing
I've
seen
that
does
this
nice
and
don't
even
talk
to
me
about
airship
airship
just
like
makes
my
brain
hurt.
It's
just
weird
like
that.
Airship
is
for
those
who
don't
know.
That
is,
that
is
where
you
run
parts
of
OpenStack
on
top
of
kubernetes
to
orchestrate
the
rest
of
OpenStack.
B
Yeah
yeah
great
well
knew
that
Kristen
you
were,
you
were
sharing
your
chat
screen.
It
was
okay
I.
It
was
nicely
that
Oh,
apparently
even
chorus,
has
just
too
many
slacks
I
mean
at
least
it's
not
15.
Like
my
my
slack
wind,
my
flack
application
has
way
too
many,
and
it
makes
me
sad
whenever
I
look
at
it.
B
D
A
A
Like
this,
like,
this
is
fun,
absolutely
I
mean
yeah.
Usually
we
just
talk
about.
What's
not
done
yet,
and
you
know
I
really
hope
we'll
get
to
to
kind
of
kind
of
like
not
just
you
know.
Free
flow
like
this,
but
I
really
want
to
survey
the
community
more
and
find
out
what
you
know.
What
do
you
guys
want
to
do
want
to
use
okay,
D
for,
and
you
know,
have
a
getting
feedback
like
we
should
merge
with
the
container
sick
I
think
that's
an
excellent
idea
and
also
you're
the
coachee
operator.
B
Copper
as
an
operator
would
be
cool
like
like
if
people
want
to
have
their
own
conference.
I
understand
red
hats
instance
of
coppers
actually
already
containerized
it,
though
it
would
be
interesting
if,
like
people
who
wanted
to
run
their
own
version
of
Fedora
copper
internally
with
all
of
its
fun
multi
districts
forward
and
the
fact
that
it
has
a
nicer
abstraction
for
projects
and
packages
running
that
on
in
their
own
infrastructure
through
openshift
would
be
really
neat
and
I.
B
Obviously,
as
I
said
earlier,
I
want
to
have
Packer
in
there
because
my
thought
would
be
well.
Packer
is
a
really
minimal
kit
surfer.
What?
If
pairing
that,
with
things
like
Tecton
and
other
kubernetes
native
the
icd
things,
it's
not
like
competing
with
everything
and
it'd
be
just
kind
of
fun
to
start
using
that
stuff
and
I
want
to
use
that
also
in
the
Fedora
community,
because
if
we
can
do
this
with
a
packer
that
can
run
in
OpenShift,
we
can
certainly
use
it
for
Packer
I/o,
core
stuff
Fedora
project.
B
Org
start
using
Tecton
community
shift
like
there's.
There's
a
lot
of
opportunities
there
for
the
kinds
of
interesting
things
that
can
be
done,
and
so
I
I
really
want
us
to
get
there
because,
like
I,
think,
there's
a
lot
of
opportunity
here
or
for
making
this
to
be
I.
Think
one
of
the
rare
times
where
Red
Hat
product
turns
into
a
breakout
community
project,
because
that
doesn't
happen
so
much
anymore.
And
it
makes
me
very
sad.
D
A
Right:
okay,
cool
yeah:
we've
we've
done
the
hour;
yes,.