►
From YouTube: OKD Working Group Meeting 03-01-2022
Description
The OKD Working Group's purpose is to discuss, give guidance to, and enable collaboration on current development efforts for OKD, Kubernetes, and related CNCF projects. The OKD Working Group includes the discussion of shared community goals for OKD 4 and beyond. Additionally, the Working Group produces supporting materials and best practices for end-users and provides guidance and coordination for CNCF projects working within the SIG's scope.
https://okd.io
A
Hello
and
welcome
everybody
to
the
okd
working
group
meeting,
I'm
gonna
sub
in
and
share
this
one.
If
you
have
a
chance,
please
enter
your
details
in
the
hack
md
file
and
timothy
is
noting
hack.
Md
is
laggy
for
me.
Maybe
we
should
archive
this
one
and
create
a
new
empty
one.
How
about?
If
we
do
that
after
today's
meeting
for
the
next
meeting,
all
right
timothy,
now
that
I've
got
the
agenda
in
this
one,
so
yeah.
A
Be
hackmd
could
be
the
universe,
so
today
we
are
supposed
to
have
a
talk
on
microshift,
but
the
guest
speaker
has
not
shown
up
yet.
A
So
I
think
what
we're
gonna
do
is
we're
gonna
motor
through
the
agenda
and
see
if
sally
o'malley
are
one
of
the
members
of
the
microchip
team
do
show
up
and
while
you're
talking,
I
will
hello
neil,
I
will
motor
through
slack
and
see
if
I
can
find
her
online
and
make
sure
she
has
the
details
for
getting
in,
because
vadim
is
the
one
who
invited
her
and
she's
there.
A
So
today
we
are
gonna
just
power
through
I'm
gonna
share
my
screen
because
it's
easier
for
me
difference
between
jamie
and
myself
when
we
chair,
I
put
the
like
to
put
the
agenda
up
on
the
screen.
Now
I
can
see
it
and
you
get
to
see
the
rest
of
this.
So
vadim
is
not
here.
If
you
christian,
is
you
want
to
give
a
quick
update
on
the
okd
release
on
behalf
of
vidim
christian.
C
Yeah
so
vadim
told
me
that
there
isn't
much
news
on
4.10.
I
think
he
didn't
do
a
new
release
for
4.9
this
weekend.
I
think,
due
to
the
circumstances
yep
in
eastern
europe,
so
yeah,
no,
no
big
updates
from
from
engineering
side
here,
yeah.
C
So
he's
he's
based
out
of
bruno,
but
he
is
from
belarus.
Oh
well,.
A
C
Definitely
devastating
what's
happening
there.
A
Yeah
we
have
to
be
cognizant
of
that
for
all
of
our
colleagues
is
we
have
offices
and
lots
of
eastern
european
countries,
so
arts
go
out
to
that
part
of
the
world
all
right
so
and
anyone
else
have
any
thing
to
add
on
the
okd
release.
A
E
Yeah,
hello,
I'm
yes,
I'm
chanting
the
agenda
directly
in
the
height
of
d,
fiercely,
as
you
say,
so,
yes,
so
not
much
my
side
as
compared
to
last
two
weeks
ago,
since
you
have
a
bunch
of
things
in
progress
that
will
have
come
with
the
rebase
to
federal
36,
so
federal
36
is
coming.
The
rebates
for
freedom
across
next
is
coming
along
the
beta,
which
should
happen
sometime
mid
march.
I'm
correct
if
I
find
this
you'll
again.
E
E
Those
two
major
changes
that
we're
tracking
we've
added
a
docs
page
here.
So
the
last
link
in
the
in
please
have
mail
is
a
new
page,
new,
fresh
new
page
that
we've
added
to
the
fedora
qrs
docs,
where
you
can
track
major
changes
that
we
have
planned
incoming
progress
and
so
right
now
those
are
the
two
main
ones,
but
hopefully
we'll
have
more
and
there's
also
links
and
descriptions
and
how
to
test
them
and
on
federal
course
notes
right
now
and
what
to
see
when
to
see
them
happening
and
everything
like
that.
E
The
timelines
so
yeah,
and
apart
from
that,
we
have
all
the
federal
36
changes
that
we're
tracking
regularly.
And
I
don't
have
anything
else,
pedro
right
now.
A
Thanks
any
questions
for
timothy
from
the
group,
if
not
we're
going
to
zoom
right
along
here,.
C
F
C
Then
maybe
we'll
need
to
cut
a
release
that
is
based
on
fedora
35
before
well.
That
can
happen,
but
yeah
I'll
definitely
check
back
with
vadim
on
that
as
well,
and
maybe
timothy,
you
know,
you
know
anything
whether
that
might
be
causing
might
be
causing
problems.
E
So
I
don't
know:
what's
the
current
status
of
the
ocd
machine
noise
content
which
release
it
is
based
on?
I
have
to
check
that
again,
but
for
sure
that's
one
thing
I
wouldn't
recommend
trying
is
skipping
release
like
that's.
Definitely
something
we
don't
test
that
much
rocker
is
side
of
things
because
we
have
barrier
releases
for
each
release.
So
usually
we
don't
skip
releases
like
everybody
goes
through
the
flow
where
they
don't
skip
natural
releases,
at
least.
C
Although
we
don't
really,
we
don't
really
think
of
the
barrier
releases,
though,
might
those
might
happen
within
one
fedora
major
version
as
well
right
and
we,
I
don't
think,
we've
really
thought
of
of
regarding
those
barrier
releases.
We
just
re
because
it's
it's
a
recompose,
it's
not
we're
not
really
using
fedora
core
os
other
than
the
for
the
boot
images
at
least
right
now.
C
There
definitely
is
a
plan,
and
there
has
been
some
movement
on
that
too
to
to
not
rebuild
fedora
core
os,
and
I
think,
with
the
coreos
layering
effort.
That's
going
on
right
now,
that'll
that'll
might
be
much
much
easier
by
then,
but
in
in
general
we
haven't
really
been
looking
at
what
what
is
a
barrier
release
and
what
do
we
have
to
yeah?
What
do
we
have
to
look
out
for
when,
when
kind
of
moving
from
from
one
version
to
the
next,
so
yeah
I'll
I'll.
C
Back
with
vadim
and
see
it
might
might
just
make
sense
to
kind
of
make
one
last
4.9
release
on
moving
it
to
fedora
35
and
then,
when
moving
to
okd
4.10,
also
moving
to
fedora
36.
We
will
see
about
that.
We'll
we'll
definitely
come
back
here
with
some
info
on
that.
G
G
D
D
It's
all
one
piece
that
that's
like
the
fundamental
thing
is
that,
when
you're,
when
open
shift
declares
that
it's
going
to
do
an
upgrade
like
and
I'm
using
the
term
openshift,
because
I'm
talking
about
both
sides,
both
you
know
our
cause
and
and
okd,
ocp
and
and
okd
when
openshift
declares
that
it
upgrades
it
goes
through
and
actually
checks
for
updates
for
the
the
operating
system.
It
runs
on
as
well
as
a
software
it's
doing
and
it
attempts
to
do
both
together
and
if
there
is
event
where
either
one
fails.
D
It's
supposed
to
stop
the
whole
thing.
What
you're
telling
me
is
that
it
is
not
stopping
and
it
is
still
breaking
so
what
should
be
happening
is
that
either
a
there's,
a
mix
missing
in
the
gap
in
the
test
gap,
there's
a
test
gap
somewhere
or
b.
Something
mco
is
not
mcd
is
not
doing
something
correctly
to
ensure
that
its
settings
persist
as
it
upgrades
the
system.
G
B
G
What
I'm
saying
is
that,
from
my
experience
and
and
I've
been
in
this
now
for
quite
a
long
time
so
so
I
I
think
I
have
a
right
to
say
this,
especially
you
know
using
okd
and
production
that
when
we
do
an
upgrade
and
we
change
fcos
version
within
the
release
of
okd,
we
are
at
big
risk
and
we
have
seen
it
over
and
over
again.
My
preference
would
be
to
either
have
a
choice
or
not
to
do
it
and
do
an
ethical
change.
When
we
do
a
new
release
of
okd.
A
F
G
C
Yeah
I'd
say
we
really
have
to
think
about
okd,
not
not
really
in
terms
of
of
openshift
versus
fedora
coreos
life
cycles
because
they
aren't
aligned.
So
we
will
always
run
into
this
issue
and
we
do
test
the
upgrades
from
one
okd
release
to
the
other.
So
it
is
one
bundle
that
is
upgraded
and
tested
as
a
whole,
and
it
shouldn't
really
matter
what
version
number
it
has
if
the
upgrade
works
it
we
would.
That
would
be
our
signal
to
say
this.
This
works.
C
We
can
release
it
as
is,
and
if
we
now
move
to
4.10
and
then
with
that
also
upgrade
to
the
fedora
35
by
then
fedora
36
is
out
and
are
we?
What
are
we
going
to
do
then?
Are
we
going
to
wait
till
okay,
okay,
d4.11
is
out
to
to
move
to
fedora
36.
C
We
have
an
open,
an
open
shift
release
both
ocp
and
okay,
roughly
every
three
to
four
months,
and
we
have
a
fedora
release
every
six
months,
so
those
life
cycles
just
aren't
aligned
and
we
can't
really
say
we
move
them
along
together
and
only
upgrade
one
when
we
also
upgrade
the
other.
So
at
one
point
we'll
we'll
have
to
say
now
we're
moving
within,
let's
say:
openshift
4.10.
We
move
from
itara
35
packages
to
fedora
36
packages
without
actually
adding
a
a
minor
version
to
the
the
okd
version
number.
C
Well,
yeah:
it's
it's
a
rolling
release.
We
don't
really
do
releases
off
of
the
last
minor
version
once
we
have
the
next
out
so
once
we
release.
B
C
That,
oh,
like
only
in
in
emergency
cases,
but
really
it's
a
rolling
release
and
there
is
just
yeah
there
isn't
any
parallel
streams
like
you
have
on
on
the
product
side,.
H
So
if
fedora
is
supported
for
a
year
after
release,
then
I
understand
that
the
two
don't
release
at
the
same
time,
but
whenever
a
minor
version,
if,
if
we
lock,
whatever
f
cos,
is
out
at
the
time
of
an
okd
minor
release,
that
fcos
version
should
be
supported
and
updated
for
the
entire
life
cycle.
Of
that
minor
of
an
okd
release.
Right
am,
I
am
I
missing
something.
Fortunately,.
G
All
I
can
tell
you
is
that,
from
what
I've
seen
in
the
last
year,
we
have,
we
have
had
many
and
I've
spent
many
hours
debugging
changes
between
fcos
when
there's
net
nothing
wrong
with
okd,
it's
the
underlying
os
that
has
that
has
caused
issues
in
the
stability
of
of
okd.
It's
not
okd,
it's
that
goes.
C
It
it
really
mostly
is
things
like
a
new
network
manager
version
or
a
systemd
version
that
has
some
some
change
in
api
or
some
new
feature
or
something
that
isn't
properly
supported,
changes
something
in
the
output
or
something
that
is
what
most
of
the
time
happens,
because
the
the
okd
code,
the
cluster
side.
That
is
what
we
also
release
as
the
ocp
product,
which
obviously
is
very,
very
well
tested
and
then
bundling
that,
together
with
with
f
cause.
C
Obviously
because,
though
they're
the
the
versions
of
of
those
underlying
packages
are
different
in
comparison
to
to
rel
core
os,
that
is
what
mostly
creates
problems
for
us.
Well,.
G
E
Yeah,
the
the
way
to
fix
those
things
is
not
to
die
and
say
we
stick
to
specific
release,
because
that's
no,
how
federal?
That's
not
all
s
works
so
right
now,
okg
uses
the
rebuild
of
federal
careers
talks
to
specific
versions,
but
so
essentially
you're
not
using
something
that
federacare
has
tested.
E
So
the
way
to
have
this
work
is
to
test
before
is
to
put
put
the
test
forward
so
put
the
test
forward
in
pediatrics
itself.
We
release
ahead
of
time.
So
right
now
we
are
trying
to
prepare
for
the
federal
36
rebates.
So
right
now
would
be
a
good
time
for
qd
to
take
a
look
at
federac36
as
a
base
and
see
if
things
breaks
in
there
so
that
when
we
rebase
fedora
36
unstable,
then
okd
can
consume
it
and
not
break
things.
So
that's
the
way
we
things
flow.
Unfortunately,
we
don't.
E
G
And-
and
that
makes
sense-
but
in
this
case
then
I'm
all
for
going
forward,
but
don't
do
it
with
four
point
nine.
Do
it
four
point?
Ten
four
nine
is
nice
and
stable
as
far
as
I
can
see,
if
we
go
ahead
and
add
a
new
fcos
and
it
also
becomes
unstable,
I
mean
basically,
it
makes
okd
unsupportable
and
unusable.
E
So
I
understand
that
right
now:
that's
no
further,
not
the
whole
fear
of
where
this
works.
So
if
okd
machinery
is
content,
we
want
to
stick
with
specific
release
for
okg.
That's
up
to
okd,
that's
up
to
vanim
to
those
doing
the
releases.
I
don't
it's
not
my
decision
here,
but
that's
you
will
know
you
will
have
to
know
that.
Essentially
you
will
be
using
somebody,
something
that
has
not
been
tested
for
us
by
fedora
forest.
That's
not
been
tested
by
us.
C
Essentially,
the
gap
here
is
that
we
have
a
separate
build
system
for
the
okd
machine,
os
content
currently,
and
we
rebuild
that
which
is
essentially
a
core
os
assembler
compose
same
thing
that
run
that
makes
fedora
coreos
itself.
We
do
that
again.
We
run
that
again
for
the
okd
content
in
the
future.
C
There's
this
it's
called
the
core
os
layering
effort,
I
think,
and
that
is
gonna-
enable
us
to
actually
reuse
what
the
fedora
coreos
folks
have
built
and
just
layer
our
stuff
on
top
of
that,
without
rebuilding
the
whole
thing,
and
with
that,
we
can
then
close
this
gap
in
testing,
where
we
kind
of
run
okd
end-to-end
tests
already
when
fedora
core
os
is
built,
and
maybe
even
block
fedora
coreos
releases
on
that,
and
that
is
currently
the
gap
we
we
aren't
currently
doing
continuous
testing.
C
We,
we
are
doing
discrete
testing
when
upgrading,
and
that
is
the
gap
and
there
is
always
going
to
be
yeah.
That
is
all
that.
That's
not
great,
obviously,
and
we,
however,
we
do
obviously
test
upgrades.
We
don't
release
without
upgrades
we're
succeeding,
and
that
should
that
is
currently
our
signal,
whether
we
can
release
or
not
so,
and
that
doesn't
suffice
in
in
some
cases,
unfortunately,
but
yeah
in
the
future,
with
chorus
layering.
This
is
going
to
be
much
better
and
we
will
either
have
to.
We
can
say
we.
C
We
now
hold
back
the
move
to
fedora
35
and
do
that
with
4.10,
but
then
we'll
have
to
within
4.10
move
to
fedora
36.
like
we
can.
We
don't
have
to
align
strictly
with
the
fedora
car
os
release,
as
you
can
see,
we're
currently
still
on
fedora
34.
I
think
while
fedora
35
is
already
nearing
its
its
end
of
life,
so
that
is
fine,
but
we
at
some
point
we
kind
of
have
to
move
a
fedora
major
version
within
an
okd
miner.
C
D
With
coreos
layering
support
before
you
do
the
ford
eleven
upgrade,
because
otherwise
you
can't
stage
in
for
the
re-provisioning,
so
we
would
have
to
move
to
36
before
we
actually
start
using
the
capability,
because
otherwise
mcd
can't
use
it
like,
because
you
create
a
weird
bootstrap
problem,
where
you
don't
have
the
capability
to
actually
use
it.
D
I
D
I
Are
so
so
I'm
from
the
mco
team
we
are.
We
are
highly
cognizant
of
that.
We
are
working
on
that
at
the
moment.
D
D
So
what
we're
talking
about
here
is
essentially
the
situation.
Right
now
is
okay,
open
shift,
rebuilds
fcos
for
okd,
and
that
means
that
the
content
sent
is
not
the
same
as
what
we
release
in
fedor
coreos,
the
configuration's,
not
the
same.
The
packages
are
not
the
same.
The
testing
that
fedora
core
os
has
done
has
invalidated,
and
that
means
that
either
there
are
two
real
solutions
to
this
either
one
the
f
cause
plus
okd
tests,
are
run
on
the
build
of
that
f
cause,
which
is
not
happening
today
or
two.
D
We
essentially
stop
doing
upgrades
until
we
are
ready
for
that
transition
to
core
os
layering.
C
So,
unfortunately,
as
it
is
right
now
running,
okd
end-to-end
tests
on
the
fedora
core
os
config
repository
isn't
really
possible
because
we've
set
up
or
vadim
has
set
up
the
the
okd
os
builds
on
an
external
ci
system
external
build
system.
So
we
can't
just
trigger
that
very
easily.
C
However,
when
we
move
to
coreos
layering,
we
will
be
able
to
actually
build
that
okd
artifact,
the
okd
machine
os
content
container
as
part
of
the
fedora
coreos
builds
as
a
layered
product
as
a
layered
artifact,
and
with
that
once
that
is
happening,
we
will
then
have
continuous
testing
for
okd
as
well
and
yeah.
Obviously,
we,
since
we
do
have
a
signal.
It's
not
the
best
signal.
C
Currently
we
do
test
upgrades,
so
you
make
we
make
a
new
compose
and
then
we
obviously
test
is
that
old
compose
the
old
version
that
is
already
released
upgradeable
to
that
new
one.
Those
end-to-end
tests
don't
run
on
all
the
platforms.
Currently
they
just
run
on
a
few
of
them
and
that
might
be
the
biggest
gap
we
have.
C
But
I
don't
think
we
can
wait
and
not
push
out
a
new
release
for
a
long
time.
You
can
decide
not
to
upgrade
obviously.
B
E
No
not
yet
we're
trying
to
the
rebase
is
happening.
F
A
Will
two
weeks?
Okay,
I
want
to
just
pause
us
pause
us
for
a
minute.
Bruce
has
had
his
hand
up
for
a
while.
So
did
you
did
you
want
to
add
into
this.
B
B
That
says
we
use
fcos
you're
totally
misled,
because
that's
not
how
it
works
at
all,
and
maybe
that
causes
issues
maybe
not,
and
it
is
sort
of
like
I
went
through
all
the
stuff
that
john
went
through,
maybe
not
as
bad,
but
I
can
understand
where
he's
coming
from
pretty
totally.
B
Okay,
we
have
our
own,
and
so
we
don't
get
whatever
good
testing
the
fcos
people
are
doing,
but
I
mean
there
there
does
seem
to
be
a
plan
involving
the
layering.
I've
been
following
that
all
the
way
along
too,
and
so
the
question
is
how
do
we
get
from
here
to
there
and
what
I?
A
I'll
just
interrupt
from
it
so
on
maybe
on
john's
behalf,
because
I
know
john's
on
a
cell
phone
someplace,
probably
in
a
car.
So
the
the
resolution
to
this
sounds
a
bit
to
me
and
I
could
be
the
naive
one
here,
because
I
don't
have
it
in
production
that
maybe
we
hold
off
on
going
to
35
until
the
410
release.
So
the
first
410
release
goes
out
with
35
and
then
somewhere
in
the
410
release.
We
do
a
step
up
to
36.
C
And
and
yeah
kind
of
get
along,
but
by
then
we
we
will
hopefully
be
able
to
migrate
to
core
os
layering.
Maybe
we
can
even
back
part
that
to
fedora
35,
because
we,
essentially,
if
that
lands
in
the
fedora
35
packages,
we
will
still
be
able
to
do
our
own
compose
of
kind
of
okd
os
35,
including
new
changes
that
have
then
landed
in
rpm
os
3.
The
base.
A
So,
john,
the
reason
why
I'm
trying
to
articulate
this
is
so
that
we
don't
go
off
and
have
vadim,
create
a
4
9
with
35
and
and
we
hold
off.
But
me.
If
I'm
hearing
everybody
right
and
I
often
don't
that
still
means
you're
going
to
have
the
same
issues.
Someplace
in
the
middle
of
410
is.
Is
that
correct.
G
I
my
feeling
is
that
once
we
release
a
stable
release.
Well,
you
know,
like
four
nine
was
released
with
34,
it
should
stay
with
34.
and
you
know
410
may
release
with
35
or
36.
I
don't
know,
but
I
think
once
we
do
a
stable
release
of
410,
I
I
think
we
should
stay
with
it
and
then
you
know,
because
we
are
focused
on
okd.
G
You
know
we're
not
estimating
we're,
not
a
testing
ground
for
fcos,
you
know
so
once
we
have
a
stable
release,
I
think
we
should
be
able
to
keep
that
and
then,
when
we
do
our
next
release
or
next
stable
or
next
testing
cycle,
then
we
go
to
the
next
one,
because
I
tell
you
if
I
do
an
upgrade
and
it
breaks
my
production
environment
and
yes,
I
realize
this
is
open
source
software,
it's
self-supported
and
everything
else,
but
I'm
also
a
member
of
this
community.
You
know.
G
B
Yeah,
it's
also
worse
on
vsphere.
I
think,
because
vsphere
isn't
specifically
tested.
E
Yeah
clear
clearly
okd
is
not
a
testing
ground
for
for
federal
courts.
Okay,
we
make
really
sure
that
of
federal
courts
releases
are
stable
and
tested,
though
once
those
kind
of
change
go
out.
It's
about
us
knowing
about
them,
because
when
we
know
about
such
breaking
change,
we
make
really
damn
sure
that
they
don't
happen
or
that
folks
get
warned
about.
So
that's
definitely
only
or
not
how
we
work.
E
So
the
thing
is
we,
don't
we
don't
get
to
fix
the
issue
we
don't
know
about,
so
we
cannot
fix
stuff
in
federal
courts
if
it's
not
important
to
us.
That's
why
we
make
damn
sure
that
we
have
well
advanced
well
in
advance
of
the
releases
that
we
have
streams
with
new
releases
that
folks
can
test
on
it.
E
So
if
okd,
when
a
separate,
the
testing
will
step
up
the
stability
of
of
the
project,
then
you
have
to
separate
and
test
or
federal
careers
release
beforehand
like
up
front
at
the
very
beginning,
where
we
do
them,
where
we
try
like
right
now,
we
are
looking
at
federal
36.
So
right
now
is
is
the
right
time.
Try
okd
with
fedora
36
content
and
try
and
make
that
happen,
and
so
yeah
this.
G
So
there
was
a
systemd
change
that
was
done
by
a
person
that
basically
broke
resolve.conf
by
replacing.
If
you
didn't,
if
you
were
booting
from
an
from
a
from
a
kernel
boot
and
you
didn't
have
a
domain
name,
they
decided
that
all
of
a
sudden
well
we're
just
going
to
put
a
dot
in
there
instead
of
using
the
default
domain.
G
Well
for
people
who
are
using
okd
that
basically
broke
their
systems
and
we
had
to
come
up
with
a
fix
in
okd
to
work
around
that
we
opened
up
a
ticket
in
bugzilla
and
basically
the
folks
who
owned
that
basically
said
well,
tough,
we're
not
going
to
fix
it,
so
you're
just
going
to
have
to
deal
with
it,
and
I
have
that
supporting
documentation.
If
you
want
to
see
it,
so
I
understand
what
you're
saying,
but
just
because
you
say
that
you
know
we,
we,
if
we
raise
our,
you
know
an
issue.
G
G
C
I
I
do
agree
that
this
is
far
from
ideal,
but
I
think
in
the
future,
when
we
have
that
okd
end-to-end
testing
as
part
of
the
fedora
core
os
test
matrix,
then
the
fedora
core
os
folks
will
get
those
signals
from
okd
beforehand.
I
think
the
problem
here
was
that
by
the
time
that
that
issue
was
reported,
dura
core
os
had
already
been
released
and
everything
had
already
been
in
place.
C
That
makes
it
really
hard
to
then
kind
of
after
the
fact
fix
those
things
while
if,
if
you
know
before
releasing
both
fedora
core
os
and
okd
fedora
core
os
would
just
kind
of
run
a
new
okd
release
as
a
test
and
end
to
end
test
that
as
part
of
the
fedora
core
os
test
suite
they
they
do
that
now
with
kubernetes
as
well.
C
Since
recently
there
have
been
upstream
kubernetes
tests
have
been
added
and
the
same
will
be
done
with
okd,
so
that
there
is
so
the
federal
coreos
folks
do
get
that
signal
that
they
currently
don't
get.
Because
currently
we
don't
have
continuous
testing.
We
only
have
the
discrete
testing
every
once
in
a
while
when
there's
a
new
release
being
cut
right.
It's
not
it's
far
from
ideal.
I
do
agree,
but
we
we
will
have
to
have
make
that
one
jump
to
get
to
the
coros
layering
part
and
after
that.
C
A
So
I
I'm
going
to
keep
coming
back
to
this,
just
because
I
don't
want
to
eat
so
so
I
I'm
still
going
to
put
on
the
table
so
for
4
9,
just
to
give
john
fortin,
maybe
a
break
in
his
production
that
we
hold
off
and
keep
four
nine
and
thirty
four
and
then
some
and
get
with
a
lot
of
forewarning
and
maybe
some
testing
in
in
the
410
release.
A
When
layering
becomes
available,
we
move
from
35
to
36,
but
with
a
lot
of
explicit
testing
on
the
part
of
this
group,
and
I
think
that
might
be.
D
So
there's
a
couple
of
problems:
one
34
is
about
to
eol
in
a
few
months,
so
that's
like.
Even
if
so,
let's
let's
say
we
do
this
right.
Let's
say
we
do
this.
That
means
that
we
will
need
to
recompose
a
stable
release
on
ourselves
on
a
semi-regular
basis
of
f
cause.
So
we
need
to
recompose
updates
and
push
those
out.
D
A
D
D
There
is
no
reasonable
conception.
I
can
think
of
that
makes
any
that
I
can
think
of
that
makes
sense
for
john
forten
to
get
a
response
from
someone
in
fedor,
especially
one
of
the
core
maintainer
folks
that
are
working
on
core
system
stack
stuff
to
say
screw.
You
essentially
like
he
said
it
much
more
nicely,
but
it's
effectively
screw
you.
The
only
reason
I
can
think
that
is
that
f
cause
people
aren't
actively
communicating
with
these.
D
These
core
stack
parts
to
make
sure
that
the
that
these
things
are
part
of
the
these
are
influencing
those
changes,
and
I
understand
from
what
timothy
has
said
over
the
past
few
months.
This
is
something
that
they've
been
actively
working
on,
and
I
know
dusty
has
kept
me
abreast
of
their
efforts
to
improve
communication
here.
D
I
expect
that
that
will
improve.
However,
it
is
absolute
lunacy
from
speaking
as
a
fedora
member
is
absolute
lunacy
that
we
would
have
a
situation
where
someone
says
this
is
flat
out
broken
and
there,
and
they
tell
you
you're,
just
gonna
have
to
stop
figure
it
out
yourself.
That
is
absolutely
unacceptable.
I
don't.
G
D
G
G
Yeah,
but
that
was
that
was
coming
through
I
mean:
whoever
did
it
on
you
know
on
bugzilla.
You
know
basically
said
we're
not
going
to
fix
it,
even
though
it
broke
specifically,
you
know
what
I
you
know.
What
we
had
identified
is
that
this
is
a
change,
we're
not
going
to
fix
it
and
you're
going
to
have
to
come
with
a
workaround,
which
is
why
we
had
to
come
up
with
that
weird
script
to
fix
result
whatever
file.
It
was
it's
the
resolve
d.
If
there
was
a
dot.
K
Okay,
can
I
just
come
in
and
make
a
suggestion
here?
So
to
me,
this
is
not
a
problem
with
what
version
of
earthquake
we
have
what
we
don't
have
it's
the
fact
that
we're
not
finding
the
bug
and
we've
talked
a
number
of
times
I'll,
be
in
the
community
coming
up
to
a
year
now,
and
we've
talked
several
times
about
trying
to
engage
community
to
do
better
testing.
K
It
sounds
like
if
we
have
a
more
robust
testing
on
nightlys
and
especially,
as
we
take
say,
a
new
update
of
fedora.
If
we
had
testing
on
cross
platform
for
those
nightlys,
we
would
find
issues
like
this
are
much
better
long
before
they
actually
hit
the
upgrade
stream.
So
I
think
part
of
what
we
need
to
do
is
create
a
plan
of
how
we
can
leverage
the
community
to
maximize
the
testing.
K
We
do
both
while
we're
while
we're
in
this
stage
and
we're
building
our
own
fcos,
but
then
also,
as
you
go
into
the
into
the
sort
of
the
streams
approach.
We've
had
this
discussion
a
number
of
times
and
and
that's
the
way
that
we
actually
I
mean
we
could
screw
up
within
the
build.
I
mean
we're
all
human,
it's
not
just
an
f
cost
problem.
A
I
think
you
you
put
that
very
well
brian
and
I'm
just
going
to
say,
and
that's
kind
of
why
the
I
keep
coming
back
to
this,
keep
four
nine
with
34
we're
going
to
410
relatively
soon
and
build
in
you
know,
start
working
on
getting
some
more
of
that
cross-platform
testing
by
the
community
earlier,
so
that
when
it
comes
to
the
next
upgrade
mid
mid
okay,
okd
release,
we
have
better
testing
and
better
communication
with
all
of
the
the
upstream
communities
as
well
we've
given
them
feedback
earlier
on.
A
But
I
think
that
might
be
at
this
juncture.
The
best
we
can
relief
we
can
give
to.
Those
of
you
who
have
okd
or
nine
in
production
is
acknowledge
that
we
haven't
got
the
community
test
plans
in
place
or
cross-platform
testing
and
work
on
that
in
the
next
few
months
and
work
on
our
communication
with
f
cause
system
d
and
everybody
else,
and
that
would
be
in
rawhide
or
everything
everything
else,
but
acknowledge
that
we
have
to
do
that
quickly
within
the
410
release.
A
So
I
I
think
I'm
taking
copious
notes
in
the
hackmd,
but
please
add
in
in
hackmd
the
anything
else
that
I
might,
but
that's
and
so
christian,
when,
if
I'm
expecting
that
you're
probably
going
to
be
the
one
that
goes
back
to
vedim
and
replays
this
a
little
bit
that
I
just
won't,
I
don't
want
vadim
to
think
of
doing
a
release
with
or
935
and
do
that
extra
work.
And
you
know
the
the
I
think
the
best
we
can
do
right
now
is
that
and
work
on
our
communication
plans.
A
So
that
said,
I'd
like
to
circle
back
and
bring
a
little
closure
and
move
to
the
next
topic.
Thank
you,
john,
for
bringing
it
up
and
saying
it
loud
again
and
and
always
being
so,
diplomatic
about
it.
G
A
A
For
for
being,
you
know
so
eloquent
that
brings
us
to
the
docs
update
brian.
If
you
want
to
give
us
a
quick
update
on
and
docs,
I
know
I
have
another
call
with
you
right
after
this
meeting.
K
Yep
yeah,
so
I'm
going
to
keep
this
quick
and
we
had
our
docs
meeting
last
week.
We
are.
We
have
got
the
code
of
conduct,
it's
down
to
me
to
actually
get
it
live,
I'm
having
some
work
done
in
my
house,
so
chaos
around
here,
so
I
will
get
it
done
as
soon
as
I
can
promise.
So
that's
going
to
go
into
the
okay.
I
o
site,
we've
also
agreed
to
shut
down
the
community
repo.
K
That's
got
five
documents
in
I'm,
going
to
move
that
content
into
the
okd
dot
io
site,
we're
making
plans
to
create
our
new
git
org
and
move
the
content
there,
and
one
of
the
things
we're
going
to
do
is
start
to
re-org
the
okd
main
repo.
That's
where
all
our
discussion
and
our
issues
are.
The
idea
is
that
we're
going
to
pull
documentation
out
of
that
repo
we're
going
to
do
it
in
a
series
of
pull
requests
and
anything.
K
K
So
the
idea
is,
we
want
to
clean
up
the
okd
repo
before
we
actually
generate
the
new
org.
So
what
we
put
in
the
new
org
is
nice
and
neat
and
clean,
so
they'll
basically
be
the
okd
repo
for
issues
and
discussions
with
a
front
read
me
which
is
just
a
pointer
to
where
the
stuff
lives
and
then
the
okay
I
o
would
be
the
source
of
all
our
community
documentation.
K
K
We
did
talk
about
the
new
operator
catalogue
and
anybody
that
wants
to
contribute
that
discussion
use
christian's
issue,
that's
in
the
okd.io,
the
okd
repo,
sorry,
so
christian
created
a
repo
of
what
operators
we
want
to
see,
and
so
that's
where
we
should
go
for
the
discussion
on
there
and
I
believe
soon
there
will
be
some
discussions
that
will
be
reported
back
on
that
issue
and
that's
all
I
have
from
the
docs
meeting.
A
And
that
person
who
is
the
security
person
is
muhammad.
Who
is
on
the
call
right
now
and
muhammad?
Are
you?
Did
you
want
to
make
a
comment?
Yep?
A
Oh,
he
didn't
get
a
contact
from
jaime
because
jamie
is
on
vacation
in
florida
this
week
and
good
on
him.
So
muhammad
expect
something
next
week
and
if
you
don't
hear,
come
to
the
docs
meeting
and
we
will
hijack
that
and
make
sure
you
get
what
you
need.
Okay,
thanks
all
right.
Let's
see,
I'm
gonna
try
and
share
my
screen
again
here
and
walk
through
some
any
issues
that
we
should
do
quickly,
because
what
do
we
got
for
time
left?
We
got
10
minutes
so.
A
The
issues
open
issues
I
know
charo
update,
okd
based
crd,
build
charo,
had
brought
up
the
issue
in
slack
somewhere
over
the
past
week
about
not
continuing
doing.
Crc
builds,
I'm
not
sure.
If
that's
exactly
what
this
issue
is
about,
but.
A
He's
right
now
the
sole
volunteer
on
the
crc
build
process.
We
were
supposed
to
get
a
talk
on
microshift
and
charles,
not
here
so
I'm
gonna.
Let
you
guys
continue
this
conversation,
it's
not
that
it's
dead,
it's
that
the
community
hasn't
invested
in
it
as
he
puts
here.
A
So
just
so.
That's
on
people's
radar.
If
you
have
have
bandwidth
and
want
crc
builds,
we
need
volunteers
and
so
reach
out
to
charo.
So
that
he's
not
the
only
one
doing
that,
because
I
think
from
the
conversation
he's
doing
them,
but
he's
not
using
it
so
he's
gone.
K
A
A
At
the
top
of
this
deck,
the
w
the
okd
is
the
slides
for
for
micro
shift.
I
thought
someone
was
going
to
give
a
presentation
on
that
today,
but
the
slides
are
there.
My
understanding
is
that
micro
is
built
with
okd
in
mind,
so
so
I
think
we
already
have
that
it's
just
whether
people
are
using
it.
I
think
a
few
people
have
said
that
they've
played
with
it
a
bit.
A
A
I
think
that
was
the
major
new
thing
on
the
issues
list
and
other
than
the
operator
wish
list,
which
is
the
perpetual
thing
on
the
wish
list
issue
and
if
there's
any
updates
to
that
christian,
I
don't
think
there's
an
update
and
then
there's
the
discussions
and
idea
stuff
and
the
online
assisted
installer
service
for
okd
was
the
the
latest
one.
That
I
saw
and
that's
two
weeks
old
too,
and
I
think
that's
something
that
vadim
has
been
working
on.
If
I'm
correct
christian
and
he's
not
here
right
now.
A
But
if
you
want
to
pile
on
to
that.
A
That's
okay:
you
were
distracted,
never
get
distracted
in
no
kd
meeting.
I'm
just
going
to
share
my
screen
again.
C
I
do
have
an
update
to
share,
though
so
I've
just
chatted
with
vadim
and
he
will
keep
okd
4.9
at
fedora,
34
and
4.10
will
be
moving
to
35,
and
then
we
will
have
to
figure
out
whether
we
will
either
do
the
move
to
36
within
4.10,
or
we
skip
a
fedora
major
sometime
later
on
all
right.
C
Those
are
kind
of
the
two
options.
Maybe
it
might
make
sense
to
just
skip
a
fedora
release
and
well
we
will
see
about
that,
but
I'll
definitely
for
now,
4.9
will
stay
on
34.
4.10
will
move
to
35.
A
Okay,
postpone
the
pain
yeah
thanks
thanks
for
doing
that,
that's
a
worthy
distraction
and
I'm
just
looking
at
the
discussion
list.
This
is
the
most
recent
one,
the
online
assisted
installer
service
for
okd.
I
think
that
was
something
that
vadim
was
also.
C
Right,
so
it
is
possible
to
to
kind
of
deploy
that
and
we
we
have
a
a
kind
of
proof
of
concept
for
running
okd
or
installing
okd
with
the
assisted
installer,
and
there
is
also
the
the
assisted
installers
kind
of
two
pieces.
C
It's
an
agent
that
runs-
and
it's
also
web
service-
that
that
the
the
that
kind
of
generates
an
image
for
you
and
the
images
that
are
then
installed
call
back
to
that
web
service
and
and
you'll
kind
of
get
a
status
update
on
as
a
visual
on
on
that
website,
and
that
is
kind
of
in
the
works.
But
we're
not
sure
and-
and
that
is
it's
even
an
open
shift.
It's
just
a
tech
preview
and
we're
not
sure
whether
that
is
going
to
be
productized
at
all.
C
So
we
might
not
go
through
that,
but
we
are
definitely
focusing
on
this
agent
driven
install,
which
will
make
it
much
easier
to
install
openshift
in
general
and
okd,
obviously
as
well
on
any
platform
without
having
to
do
too
much
integration
work
that
way.
So
that
is
the
focus
of
ours.
Having
this
agent
driven
install,
whether
we
need
the
web
service
part
of
it
or
just
make
it
kind
of
a
cli
thing,
we
we
don't
really
know
yet.
So
I,
I
would
just
say,
stay
tuned
and
watch
that
issue.
A
H
Sure
yeah,
I
I
wanted
to
point
out
that
we
have
the
discussion
about
what
what
the
purpose
of
our
install
guides
are
and
and
how,
how
kind
of
what
format
they
should
be
in
I've
raised
it.
I
haven't
gotten
any
feedback
from
anybody,
yet
who's
previously
participated
in
the
guide.
Brian
and
jamie.
I
think,
are
here.
H
A
Is
on
on
vacation
brian
is
here,
can
you
can
you
throw
the
discussion
url
into
the
chat
just
for.
H
Me
yeah
it's
in
it's
in
tasks
right
now,
all
while
chat.
So
I
don't
know
if
this
is
a
case
of
everybody
likes
my
proposal,
so
nobody
felt
the
need
to
say
anything
or
people
haven't
had
a
chance
to
read
it.
Yet
I'm
not
sure
how
long
to
go
without
just
saying
okay
nobody's
objected.
So
the
thing
I
wrote
up
is
the
thing
we're
doing.
F
C
I
I
totally
missed
that
I
was.
I
was
out
with
kovic
during
that
time,
so
I
I
do
think.
I
think
I
like
that
and
most
importantly
I'd,
like
all
the
guides
to
be
to
share
one
common
format.
So
you
know
so
it's
kind
of
clear
how
to
add
another
one
and
what
what
the
actual
purpose
of
of
each
guide
is,
which
should
be
the
same
platform.
I'd,
say
yeah.
I
I
do
like
I've
just
had
a
very
quick
look
but
I'll
I'll
review
it
a
bit
more
early
in
a
bit.
C
A
All
right
all
right
anything
else.
Anyone
wants
to
bring
up
in
these
final
few
minutes.
Otherwise,
thank
you
all
for
participating
today.
I
really
appreciate
that
the
feedback
and
and
thanks
for
stepping
up
there
christian
and
doing
the
back
to
our
discussion
with
vadim.
So
we
got
that
update
in
this
week.
A
There
is
a
docs
meeting
next
week
on
tuesday
and
the
other
thing
well
that
under
the
docs
kind
of
thing,
is
we're
looking
at
doing
a
staying
with
make
docs
staying
with
okd.io,
but
using
a
bit
of
outside
contractor
help
to
do
a
refresh
of
the
okd.io
site.
So
it's
a
little
more.
A
Perky
or
websitey
or
whatever
it
is,
we
have
some
dollars
in
an
account
somewhere
that
I
need
to
spend
so
brian
and
I
are
going
to
meet
with
brandon
right
after
this
call
and
discuss.
You
know
that
so
we
may
be
bringing
back
a
few
wireframes
and
suggestions
for
things
to
make
it
look
a
little
bit
better
too,
so
that
might
help
in
the
usability
of
the
site.
A
So
with
that,
I'm
going
to
let
you
all
go
back
to
your
day
jobs,
and
thank
you
all
again
for
all
of
your
support
and
talk
to
you
all
soon.