►
From YouTube: OKD Working Group Meeting July 31 2019
Description
https://okd.io
full working group meeting video/presentation
recorded July 31 2019
meeting minutes: http://bit.ly/OKDWGMeetingNotes
A
All
right
so
I
have
104
so
I'm
gonna
do
that
and
we
have
21
people
on
there.
I
don't
know
if
everybody's
put
their
name
in
the
list,
but
I
think
we
have
a
good
smattering
of
people.
I
figured
this
first
meeting
would
probably
be
RedHat
heavy
just
in
light
of
what
we're
talking
about
today,
but
we
really
welcome
and
hope
that
all
of
you
who
are
non
Red
Hatters
will
speak
up
and
participate
actively
in
this
conversation.
A
B
B
A
Danny
I'm,
just
what's
gonna
call
you
out
first
and
sort
of
the
welcome
and
get
the
meeting
started,
and
let
me
see
if
I
hit
the
record
button
because
I'm
really,
actually
you
know,
I-
did
hit
the
record
button.
So
this
meeting
is
being
recorded
and
I
will
post
the
video
with
the
link
in
the
notes
to
the
google
group
and
the
video
will
be
up
on
YouTube
under
the
OpenShift
opens.
Maybe
I'll
start
another
playlist
for
okd
for
related
things
or
okd
related
things.
A
Because
a
lot
of
the
survey
that
we
just
put
out,
which
52
people
responded
to
a
lot
of
it
from
my
point
of
view,
was
about
logistics
for
meetings
and
who
was
interested
in
in
discussing
this
okd
design
and
roadmap
and
the
current
thinking,
and
not
only
just
interested
in
discussing
it.
But
who
is
interested
in
working
on
it
and
contributing
to
it
so
Thank
You
Danny
for
that
and
don't
have
a
card
accident,
but
we're
grateful.
A
A
Cool
and
and
that-
and
that
was
really
one
of
the
the
key
things
for
me,
and
so
that
may
I
tend
to
chair
most
of
the
cig
groups
that
are
under
open
ship
comments,
but
I
really
wanted
to
have
some
of
the
more
technical
people
incorporated
into
driving
the
working
group
and
I.
Don't
know
if
you
can
see
my
screen
right
here,
but
Sonia
Banach
I,
think
that's
how
you
say.
You
name
Sonia,
that's
Anja!.
A
Been
works
for
Sonia
or
works
with
Sanjay
I'm,
not
sure
the
total
hierarchy
of
things
here,
and
so
thank
you
for
volunteering,
then
that
he
was
going
to
do
this
so
great.
Also
I'm
gonna
say
that
I
don't
actually
have
all
the
visibility
of
the
chat.
So
if
it's
something
Sanjay
is
my
own
boss,
good
I
got
that
right.
A
So
if
you'll
bear
with
me,
we're
we're.
Okay
with
that
and
I'm
just
going
to
pop
and
make
sure
no
one's
objecting
to
doing
that.
Please
put
you
on
the
list.
If
someone
could
put
Michael
kopje
on
the
list,
that
would
be
great
so
and
I
know
that
blue
jeans
isn't
the
perfect
device.
So
we
may
move
to
something
else
like
zoom
or
something
like
that.
A
A
This
so
that
that's
really
what
I
wanted
to
say
is
I
think
this
group
needs
an
official
charter
needs
to
be
an
official
working
group,
because
I
think
there
are
things
I
believe
and
ever
I
think
everybody
else
on.
The
call
hopefully
believes
to
that
we're
going
to
do
work
and
we're
going
to
have
to
make
decisions
about
directions
and
things,
and
there
will
be
things
we
need
to
vote
about
and
and
set
that
stage
so
having
something
in
place
and
making
it
a
little
bit
more
formal
than
this.
A
B
E
A
So
the
next
bit
of
this
clayton
is
here.
I
want
to
use
his
time
wisely.
We've
had
a
couple
of
good
discussions
already
about
okay
d
for
design
and
roadmap,
but
clayton.
If
you
could
bring
us
up
to
speed,
eat
a
little
bit
here
and
take
a
few
minutes
and
talk
about
the
current
thinking
and
the
proposed
strategy
and
how
we,
you
know,
discuss
how
we
can
set
some
short
and
medium
strategy.
Checkpoints
I
do
really
appreciate
that
sure.
F
So
I
assume
a
lot
of
folks
on
this
are
familiar
with
the
discussions
of
the
mailing
list.
If
I
were
to
briefly
summarize,
where
we
are,
we
I
made
an
initial
proposal
around
what
I'm
quote:
philosophy
for
okay
T
for
continuously
updating
continuously
secure,
kubernetes
distribution.
In
that
model,
it
would
inherit
a
lot
of
the
things
that
make
open
ship
or
easy
to
manage
easy
to
use
easy
to
operationalize
by
taking
some
choices
away.
F
There
was
a
number
of
good
discussions
in
the
mailing
list,
folks
talking
about
operating
systems
and
what
other
choices
we
might
have
folks,
who
wanted
potentially
to
run
on
architectures
or
platforms
that
may
not
be
necessarily
in
Fedora
core
OS
execution
path.
Also
that
this
couple
of
discussions
around
wanting
flexibility,
I
think
those
are
the
kind
of
the
two
major
you
know
core
approaches,
something
that's
flexible
and
can
be
used
to
help
build
out
things
that
are
a
little
bit
more
opinionated
from
a
user
perspective
versus
something
that
allows
a
an
open
source
ecosystem.
F
You
know
participant
to
mix
and
match,
or
to
change
up
to
have
a
little
bit
more
flexibility.
There
was
a
bunch
of
good
points
there
I
feel
like
a
good
next
step
may
be,
for
the
working
group
in
general
would
be
to
summarize
those
concisely
and
to
fit
those
into
a
trade-offs
and
choices,
doc.
That
folks
could
act
on.
Certainly
right
now
the
path
of
least
resistance
for
you
know
getting
getting
the
the
basic
idea
of
something
running
that
takes
a
lot
of
the
work
that's
been
done
for
openshift
for
into
okay.
F
T4
would
be
No
proceeding
down
the
Fedora
core
OS
discussion.
I
know
there'll,
be
some
follow-up
on
that,
but
it
does
not
mean
in
any
sense
that
we
are
locked
into
that
approach.
The
survey
hopefully
generated
some
good
data
around
what
people
are
looking
for
and
I
think
we
want
to
leave
open
and
really
gather
from
consumers,
contributors
and.
F
Visionaries
in
the
community,
if
there
are
different
directions
that
we're
not
considering
between
those
two,
it's
entirely
possible
that
some
of
the
tools
that
we
would
think
of
as
part
of
oak
84
are
actually
pieces.
That
should
be
that
can
satisfy
those
goals,
maybe
split
out
so
there's
a
number
of
components
that
make
up
open
shipped,
and
so
it's
not
as
if
all
of
our
agreements
have
to
happen
in
this
forum,
we
could
certainly
break
that
down
into
smaller
pieces
and
spin
up
some
working
groups
for
that.
A
B
My
view
is
that
you
know
as
a
phase
one
or
baby
steps
or
ever,
but
we
should
just
crack
on
with
exactly
what
we
said:
okay,
d
plus,
of
course,
and
took
me
exactly
what
I
see
before
is:
yes
all
the
other
stuff,
it's
you
know
are
all
welcome,
but
at
least
let's,
let's
have
something
out
ready
for
carry
rather
than
just
boiling
the
ocean.
That
is
my
view
anyway.
G
One
of
the
things
that
I'm
generally
concerned
of
with
with
the
way
that
Oki
d4
has
for
the
lack
of
shaping
up
shaping
up
is
something
that
I
don't
want
to
see
continue,
which
is
that
we've
kind
of
lagged
super
far
behind
OCP,
and
that
has
also
been
something.
That's
happened
in
3x
for
a
fair
bit
of
time,
and
that
has
made
it
very
difficult
to
sort
of
make
sure
that
things
are
going
to
be
working
and
stuff
like
that.
G
Traditionally,
with
mostly
other
stuff
that
redhead
ships,
it
is
dev
community,
then
product
and
the
loop
being
inverted
means
that
it
makes
it
very
difficult
for
that
to
get
those
things
kind
of
shaken
out
properly.
And
another
thing
that
I'm
concerned
about
from
my
efforts
within
the
Fedora
project
is
that
most
of
the
container
orchestration
components
and
the
container
engine
components
are
rotting
because
we
don't
have
anything
to
use
it
with
the
version
of
OpenShift
and
kubernetes
upstream.
Vanilla
kubernetes.
G
F
That's
actually
a
really
sting
point:
Neela
like
okay
D
was
more
Santos
focused
rather
than
Fedora,
and
the
development
cycle
of
okay
D
was
on
the
cube
schedule,
not
on
the
Fedora
schedule.
I,
certainly
think
that
there's
a
good
there's
a
good
discussion
to
be
have
on
the
strategy
side
about
what
the
release
cycle
is.
I
know
that
the
team
sets
a
very
you
know.
The
folks
working
on
open
shift
in
general
today
set
a
very
aggressive
schedule
that
is
on
the
open,
show
schedule.
Not
anybody
else's.
F
G
There's
two
aspects
to
this,
so
one
is
that
the
Fedora
process
is
generally
four
there's
components
that
we,
the
open,
shift
kubernetes
and
things
like
that
rely
on
that,
come
from
the
fedora
side
and
a
lot
of
times
you
guys
are
kind
of
kneecapped
from
being
able
to
take
advantage
of
it
because
you've
been
following
Santos
almost
strictly,
and
this
is
a
good
opportunity
to
change
that.
That
part
is
true.
G
G
That
would
allow
us
to
release
those
things
at
the
kind
of
cadence
that
you
guys
have
typically
done,
which
I
think
is
quarterly,
but
I
would
it
would
be
nice
to
see
like
we
would
have
in
a
the
default
version
of
okd
shipping
in
a
non
modular
context.
For
you
know
whatever
anyway,
shipping
the
default.
The
default
version
of
okay
be
moving
forward
in
the
Fedora
release
process,
but
also
shipping.
The
other
versions
is
possible
with
the
modularity
stuff,
that's
been
going
on
in
fedora
and
I.
G
Think,
and
one
of
the
things
that
will
make
sense
with
that
is
that
we
currently
have
cryo
modularized
and
so
tying
the
cryo
module
to
the
kubernetes
or
OpenShift
module
means
that
we
can
get
that
dependency
relationship,
matched
so,
for
example,
OCP,
3:11,
sorry,
orange,
okay,
t
3:11
map
to
cryo,
111
and
kubernetes
111
maps
to
Kryolan
lens.
Basically,
you
pick
okay,
deep
or
kubernetes.
G
F
F
The
platform
makes
about
it,
rather
than
vice
versa,
and
the
choice
that
some
of
those
choices
are
modularity
actually
isn't
important
to
us,
because
we
already
have
a
modularity
approach:
the
in
packaging,
maybe
in
release
lifecycle,
know
like
some
of
the
mindset
in
okd
and
open
shifts.
His
you
know
is
starting
to
be
making
an
opinionated
choices
about
what
parts
of
the
operating
to
consume
and
controlling
that
very
deeply
I.
F
Don't
know
if
that's
in
conflict
with
the
Fedora
approach,
but
it's
actually
I
think
that's
a
discussion
topic
that
we
need
to
queue
up
in
a
strategy.
Discussion
which
is
I
almost
might
characterize.
What
we're
trying
to
do
is
the
exact
opposite
of
that
is
not
expect
fedora
to
tell
that
us
to
dictate
to
the
version
of
the
operating
system
package
together
how
that
works
since
historically
at
least
cryo
development
is
driven
by
the
open
shift
goals
and
the
kubernetes
team
goals,
rather
than
vice-versa.
F
G
Why
are
we
shipping
Cooper
days,
components
that
don't
work
and
is
there
is
like
I'm
I
start
wondering
the
more
existentially?
Does
it
even
make
sense
to
involve
the
door
at
all?
If
you
guys
don't
care,
so
if
you
guys
don't
care,
then
what
should
we
be
doing
and
I'm
not
saying
that
that's
what
we
should
just
rip
the
door
out
of
this
whole
equation.
G
I,
actually,
personally,
would
like
to
see
like
Fedora
core
OS,
to
be
more
central
to
this,
but
we've
got
to
have
the
point
where
people
in
fedora
land
have
to
be
able
to
use
this
stuff
and
you're
shipping
stuff
that
nobody
can
verify
whether
it
works
or
not.
So
that's
that's
my
fundamental
problem.
Okay,.
F
And
I
think
that
so
then
I
took
some
notes
as
well
on
that
I
think
the
other
question
that
I
heard
in
that
last
one
is
okay,
D
thinks
of
itself
as
a
distribution
and
Fedora
thinks
of
itself
as
a
distribution.
So
we
actually
are
in
somewhat
conflict
in
terms
of
philosophy.
And
how
do
we
reconcile
that
right?
F
Like
okay,
the
many
of
the
tools
in
okay
D
and
we
talked
about
this
in
the
threads-
were
designed
to
be
able
to
create
a
new
distribution
concept,
that's
above
and
beyond
an
OS
concept,
but
much
of
the
content
in
those
comes
from
what
we
would
continue.
What
we
consider
distributions
as,
and
so
we
need
to
reconcile
that.
So
that
is
a
definite
thing
that
we
have
to
close
in
a
subsequent
discussion.
H
F
This
is
kind
of
that
trade-off.
They
discussed
in
the
thread
is
I.
Think
you
could
argue
that
okay,
Dee
is
the
first
attempt
the
first
real
attempt
to
create
a
new
type
of
district
9,
an
OS
distro,
but
a
cluster
OS
distro,
and
there
are
elements
of
that
where
there's
huge
overlap
between
you
know:
building
and
shipping
software
and
fedora
testing
that
it
all
works
together
and
verifying
it.
F
But
then
that
also
has
to
be
combined
with
all
of
the
software
on
top
of
it,
much
of
which
may
or
may
not
be
coming
from
fedora
it.
You
know
in
a
traditional
sense
and
so
I
think
the
I
think
I
think.
That's
basically
an
open
question
is:
do
we
want
to
be
a
distro
in
okd
and
create
the
new
cluster
OS
distro,
or
do
we
want
to
subsume
some
of
those
pieces
into
maybe
the
more
traditional
Fedora
cycle,
I.
G
Mean
so
to
be
absolutely
clear
here:
I
am
NOT
talking
about
making
okd
follow,
fedoras
release
cycle
that
none
of
what
I'm
talking
about
involves
that
at
all,
because
already
right
now
for
the
or
chorus
operates,
basically
on
its
own.
Whatever
the
hell
update
cycle,
it
is
it's
every
two
weeks
or
whatever,
and
within
the
disk
it
and
the
process
model,
and
things
like
that
things
can
lifecycle
more
or
less
independently
if
they
want
to
the
fact
that
it's
29
or
30
or
31
is
more
or
less
irrelevant
that
that
is
not
part
of
this.
G
Okay,
D
relies
on
them
in
production
systems
right
because
we
don't
have
a
kubernetes
package
that
works
and
we
don't
have
an
okay
D
system
that
works
within
the
Fedora
sources,
sent
secure
environment
that
we
can
actually
use
to
bootstrap
and
test
and
validate
these
things.
There's
a
Fedora
CI
system
that
is
in
process
of
being
developed
and
used.
G
F
H
I
F
Maybe
we
can
do
it,
both
doc
and
mailing
list
and
potentially,
and
a
couple
of
meetings
on
identifying
the
fundamental
trade-off
questions,
making
arguments
for
or
against
and
building
to
a
consensus
on
each
of
those
then
Colin,
if
you
guys
can
it
sounds
like
you
got
volunteered
for
that
at
least
frame
the
initial
document?
Is
there
anybody
else
who
wants
to
be
involved
in
that
or.
A
Clayton,
a
review
of
that
and
if
I
could
Colin
I
could
work
with
you
and
then
Howard
to
just
sort
of
at
least
frame.
Some
of
that
and
then
share
that
document
with
with
the
group
for
further
refinement.
I
think
that
that
would
be
helpful
because
I
you
mentioned
something
earlier:
I
just
want
to
go
back
to
and
I'm
on
this
meeting,
I'm
really
just
a
logistics
person.
I
don't
have
a
strong
opinion.
I
have
opinions,
but
I'm
not
gonna.
A
Make
them
strongly
that
the
survey
that
we
initially
did
was
more
logistics
about
meetings
and
whether
you
would
be
a
resource
for
these
discussions
and
collaborations,
but
the
trade-off
voices
document
developed
and
then
perhaps
turned
into
a
bit
of
a
survey
on
that.
Some
of
those
questions
that
we
have
from
that
and
send
it
out
to
the
group
good
feedback
on.
J
D
I
put
that
in
the
charger
how
I
it
happen
at
w3c
and
where
it's
work,
because
there's
a
whole
lot
of
global
contributors
who
sometimes
do
not
answer
for
ages,
so
they
have
a
good
process
of
dealing
with
that,
which
is
what
I've
put
in
the
decision
process
in
the
chart.
What
I'd
like
to
just
say
that
so
once
we
have
discussed
on
a
way
forward,
that
is
that
or
that's
how
I
view
it.
D
A
A
G
A
A
We'll
get
to
that
in
a
minute
that
I
will
have
a
list
of
working
group
members
from
this
meeting
and
the
last
item
which
I'll
just
jump
to
now,
is
I'm
going
to
use
Google
Group
and
there's
a
link
there
to
the
google
group
to
join
the
working
group.
So
if
you
click
on
there
and
join,
you
will
be
added
to
the
at
least
to
the
mailing
list
and
all
of
that,
once
we
figure
out
the
Charter.
A
Then
there
will
be,
you
know
some
to
being
a
member
of
the
working
group,
but
not
very
official.
We
really
just
want
participation
and
external
people
working
on
with
us
on
this.
So
these
doing
that,
though,
did
we
come
to
a
bit
of
a
closure
there?
On
the
you
know,
the
sort
of
design
strategy
and
next
step
of
creating
the
trade-off
and
choices,
because
I'm,
just
cognizant
or
half
through
the
meeting
I'm.
E
That's
a
really
big
problem,
because
before
I
even
start,
I've
got
to
make
a
fork
in
the
road
and
say
am
I
going
down,
though
you
know
what
would
be
the
federal
federal
core
s
route
and
then
okay
d
or
am
I
going
down.
The
supported
route
on
RedHat
core
is
and
they're
two
completely
different
products
with
different
behaviors
and
different
bugs
and
different
behaviors
and
all
sorts
of
things.
E
But
my
point
of
view
of
rolling
out
things
to
a
customer
I'd
like
there
to
be
much
much
tighter
convergence
between
the
two
do
I
question
whether
we
should
be
basing
this
on
federal
core
RS
at
all,
whether
it
be
better
to
base
it
around
Red
Hat
or
s.
So
we
got
the
same
of
basic
operating
system.
One
is
just
a
bit
more
upstream
than
the
other
hey.
K
Char
groomer
here
I
want
to
echo
into
that
as
a
an
actual
customer
of
Red
Hat
running
OCP
in
production
up
through
the
3.11
family.
We
we've
been
running
okay,
D
previously
origin
in
a
lab
environment
dude
as
a
way
to
stay
up-to-date
on,
what's
common
and
and
using
it
as
a
learning
opportunity
for
my
engineers
to
get
familiar
with.
G
You
know
I
actually
kind
of
like
I,
don't
like
to
say
this,
but
I
kind
of
agree
here
to
like,
obviously
using
OCP
in
production
is
going
to
use
rel,
core,
OS
and
and
even
though
I
personally
would
like
and
I
am.
The
number
of
the
members
of
my
team
would
like
to
have
latest
and
greatest
technologies
when
we're
using
okb.
There's
also
the
flip
side
of
that.
G
If
we're
also
trying
to
use
it
in
in
a
production
environment
and
we're
using
OCP
and
rel
core
OS
isn't
following
Fedora
core
OS
that
closely,
then
there
is
a
bit
of
a
problem.
Now
that
being
said,
I
was
actually
less
no
clue
about
how
rel
core
OS
is
being
developed.
It
could
be
that
it's
just
more
closer
to
fedora
than
then
relative
ik
was
in
the
past,
and
if
that's
the
case,
then
maybe
this
really
doesn't
matter.
So
this
is
more
about
like
what
is
this.
G
A
The
next
talk
topic.
Well,
that's
that's
well
done
so
Virgil,
so
I'm
gonna
add
that
in
and
we
have
Collin
and
Benjamin
Gilbert's
on
this
call.
So
maybe,
if
we
pause
here
and
move
into,
you
know
what
the
okay,
the
integration
with
F
cos
means
and
what
the
divergence
is
between
F
cos
and
rel
can
be
something
they
address.
On
Benjamin.
I
I
You
know
Oh
fixing
bugs
the
Machine
config
operator
and
our
cost,
and
that's
at
the
time,
but
that's
one
where
this
going
to
happen.
I
think
why
I
really
wanted
to
get
to.
You
was
kind
of
there's,
definitely
high-level
strategy
thing,
but
I
I
think
we
can
get
to
you
a
point
where
we
have
something
bleeding
like.
I
I
F
You
know
it's
interesting,
Colin
I
think,
like
the
divergence
question,
leads
into
the.
What
are
the
thing?
What
are
the
choices
that
benefit
stability
for
end-users
and
you
know
a
reasonable
set
of
consistency
and
what
are
the
choices
that
allow
flexibility
where
people
want
it?
Where
people
have
the
flexibility
to
go,
do
what
they
want
and
I
feel
like
those
are
kind
of
an
interesting
tension.
F
So
there's
people
who
would
like
to
make
choices
that
would
probably
be
more
with
the
classic
flexibility
of
open
sources,
and
so
much
of
like
the
open
shift
for
mindset
is
around
taking
away
flexibility
to
offer
that
appliance
like
model.
That
appliance
like
mindset
is
the
details
are
kind
of
supposed
to
be
unimportant
because
it's
supposed
to
just
work
for
each
of
the
different
questions,
each
of
the
different
types
of
components,
the
OS,
the
things
in
the
US,
the
the
core
operators,
the
operators
on
top
and
the
Installer.
F
Maybe
for
each
of
those
there
might
be
a
subtly
different
discussion
point
that
we
have
about.
Maybe
this
is
the
one
component
that
varies
a
little
bit
for
mostly
Peter.
Maybe
this
isn't
that,
as
we
get
into
detail,
I
think
we
could
probably
have
different
answers
for
different
components.
All
in
those
lines.
J
They
could
be
a
wild
captain's
heard
some
extra
questions
in,
but
in
my
communication
with
folks,
there's
a
fair
bit
of
confusion
as
to
whether
a
lot
of
okay
D
is
the
bleeding
edge,
the
platform
from
which
you
can
try
emerging
technology
before
it
finds
its
way
into
into
a
commercial
distribution
or
or
or
is
it
something
that
will
lag
the
commercial
distributions
and
really
is
not
a
good
testbed
for
getting
getting
to
know
the
platform
and
its
future
directions?
So.
F
Maybe
I
can
take
a
quick
moment
to
answer
this
and
I
feel
like
this
needs
to
go
into.
One
of
the
docs
is
so
the
OpenShift
for
philosophy
both
for
OCP
and
at
least
in
theory,
for
okay
d.
Is
that
there's
a
number
of
existing
up
streams?
The
Linux
kernel,
uber
Nettie's,
a
number
of
projects
out
there
that
are
fairly
stable,
that
are
consumed
and
the
number
of
projects
out
there
that
are
actively
developed
for
a
lot
of
those
components.
F
The
active
developed
ones
are
the
ones
that
folks
in
the
OpenShift
community
are
actually
working
on
so
operator,
life
cycle,
the
Machine,
api's
and
machine
operators.
Those
are
being
driven
to
satisfy
the
goal,
so
those
are
bleeding
edge
or
leading
edge
for
a
number,
the
other
components,
consumption
of
a
kernel,
picking
a
version
of
kubernetes.
Those
are
more
taking
the
stable
versions
and
the
bleeding
edge.
C
F
Itself
intrinsic,
if
you
want
the
latest
kubernetes
go
to
kubernetes
I
think
that's
been
a
point
of
tension
and
confusion,
and
maybe
that's
another
discussion
point
for
the
strategy
of
kind
of
OC
PE
as
it
is
today
and
in
theory,
okd
are
bleeding
edge
where
they
need
to
be
to
deliver
value,
leading
edge
where
it
has
a
lot
of
value
and
stable
for
the
things
that
are
less
critical
to
drive.
My
opinion
is
honestly:
the
OS
is
the
least
at
least
important,
but
we
don't
typically
drive
from
it
and
kubernetes
everybody
who
contributes
to
kubernetes.
F
F
At
the
same
time,
we've
certainly
done
a
lot
of
work
in
OCP
to
make
nightly
we're
planning
on
having
Knightley's
for
for
two
and
for
three
available
well
in
advance
and
release
for
people
to
try
things
and
that's
not
the
whole
like
I,
don't
think
that's
this
community's
strict
apartment,
but
for
some
of
the
strict
interest.
But
certainly
if
your
goal
is
to
try
OCPD
ahead
of
release,
we
will
have
other
ways
of
doing
that
which
gives
okay
be
a
little
bit
more
flexibility
to
be
different
from
OCP.
If
that's,
what
people
choose.
A
Driving
right
along
and
I
made
it
just
a
note
to
myself.
There's
I'm
apologizing
in
advance,
I'm
really
bad
at
taking
minutes,
and
there
will
be
a
video
and
the
video
has
some
transcription,
which
is
what
I
love
about
YouTube.
So
if
you
didn't
catch
all
of
that,
and
you
obviously
can
see
that
I
haven't
caught
it
all
on
the
minutes,
it
will
be
in
the
video
and
we
listen
to
that.
You
want
to
take
on
the
next
topic.
The
overview
of
the
state
of
release
of
tooling
for
okd,
like
Titan.
A
F
F
A
It
was
little
I
wanted
to
talk
a
little
bit
about
ignition
and
also
say
that
at
the
end
of
August,
we're
going
to
have
a
bunch
of
Commons
briefing
on
ignition.
So
if
you're
on
the
call-
and
you
don't
know
about
ignition
I-
think
that's
between
you
guys
scheduled
to
give
a
full
own
talk
on
it
and
dive
into
it.
So
just
so,
you
know
and
I'll
put
the
link
in
when
I
link
to
the
briefing
and
I
know.
There's
I
can
see,
there's
a
question.
F
F
Everyone
see
this
yes
great,
so
what
we
like
as
part
of
that
mindset
of,
like
shortening
the
ability
data
consume
from
upstream
there's,
a
lot
of
work
that
happened
in
rel,
core
OS,
that's
in
cross,
which
this
gets
to
like.
Where
are
you
pulling
from?
What
we've
tried
to
do
is
kind
of
look
at
this,
as
how
do
you
compose
things
out
of
images?
F
Artifact
and
that's
based
on
operators.
So
an
operator
can
say:
hey,
I'm
I
want
to
be
included
in
the
release
and
when
I
get
deployed,
I'm
gonna
go
do
stuff.
We
have
a
bunch
of
tooling
in
the
open
ship
space
called
the
cluster
version
operator
and
OLM
that
hides
some
of
the
details
of
I
just
want
to
get
a
controller
installed
into
kubernetes.
F
That
goes
and
does
the
rest
of
the
work,
and
so
what
we
actually
do
is
we
stitched
together
a
large
number
of
in
we
stitched
together
a
large
number
of
images
and
pick
us
a
version
and
compose
them.
So
in
a
sense
like
there's
an
analogy
here
to
like
OS
composes,
which
is
we
take
a
bunch
of
fundamental
components
and
their
API
is
need
to
be
aligned
right,
the
kernel
and
geodesy
and
LS
and
system.
Do
you
all
kind
of
need
to
be
pretty
close,
we're
combining
that
it
kind
of
a
higher
level
of
operators?
F
By
doing
that,
we're
really
kind
of
saying
we
don't
care
about.
What's
inside
the
image
as
long
as
it's
compatible,
we
bundled
them
together,
test
them
and
release
them.
So
for
everything
in
the
current
OCP
released
today,
except
for
the
OS
content,
it
is
fully
open
source
content
that
exists
out
on
the
Internet
and
that
content
we
publish
those
to
quai.
F
You
know
this
is
a
looks
like
I'm,
not
using
the
right
version
of
the
tool.
So
this
is,
you
know
just
showing
you
what
particular
git
commit
in
the
open
source
it
is.
This
image
is
built
in
mirror
to
quai
dot
I/o.
So
you
know
this
source
code
for
this
operator
shows
up
at
quai
dot
IO
and
you
openshift.
F
We
are
publishing
all
of
these
images
to
Quay
they're,
you
know
rolling
published
and
what
we're
trying
to
just
do
is
get
the
momentum
going
so
that
when
we
do
get
to
an
oak
ad
the
point
of
having
an
okay
de
that
actually
works,
the
vast
majority
of
the
components
are
already
being
built.
These
are
being
built
by
CI
when
changes
are
merged
to
the
release
branches
in
the
open-source
repos.
But
you
can
see
here
they're,
just
as
like
a
really
basic
the
master
branch.
F
These
changes
are
made
and
then
they
show
up
and
open
shift
OCP
in
the
shelf
and
a
fugitive
origin
in
close
proximity
in
the
next
version
of
OCP,
but
in
the
latest
version
of
the
images
and
all
that.
So
what
we're
just
trying
to
do
is
get
the
momentum
going
so
that
we
can
leverage
a
lot
of
what
we
have
and
we
can
change
anything
we
want
in
this
process.
F
But
we
wanted
to
at
least
ensure
that
people
didn't
feel
like
you
know
in
my
mind,
we
could
very
quickly
or
as
quickly
as
reasonably
possible,
integrate
the
Fedora
core
Westside
and
be
able
to
have
something
we
can
point
and
look
at
and
then
iterate
from
there.
Maybe
you
know
dramatically
diverge,
maybe
rebuild
the
CI
and
infrastructure
to
be
completely
different.
I
think
we've
had
some
choices.
F
My
hope
had
just
been
that
we
could
be
used
as
much
as
possible
that
was
built
and
published
in
an
open-source
fashion
so
that
people
can
iterate
and
so,
like
you
know,
if
I
jump
in
to
look
at
some
of
these
images
and
off
essentially
the
metadata.
Actually
you
know,
some
of
the
metadata
you
can
actually
see
in
here
is
this
git
commit
was
actually
what
I
use
to
link
to
that
website,
and
so
it's
like.
We
are
publishing
this
content.
It
is
okd
quote-unquote,
ready.
J
F
Sure
we'll
want
to
go
in
and
iterate,
but,
for
the
sake
of
you
know
an
initial
stab,
we
are
very
close
to
having
90%
of
the
stuff
covered
and
we
need
to
close
the
last
details
before
we
can.
Even
what
we
have
like
lay
a
prototype
phase,
one
okay
B
so
I
did
I
didn't
want
people
to
get
the
feeling
that
we
aren't.
They
aren't
terribly
close
to
having
something
that
we
can
at
least
iterate
on.
B
So
so
great
them
I
am
I.
Have
a
quick
question
for
you.
If
you
don't
mind
once
we
address
the
elephant
in
the
room
idea
with
regards
to
the
operating
system,
is
it?
Is
it
fair
to
assume
that,
let's
say
if
federal
courts
will
will
be
the
TOI
smoking,
for?
Is
it
fair
to
say
that
the
the
current
yeah
I
would
be
able
to
or
should
be
able
to
kind
of
beat
the
the
language
for
the
federal
chorus
in
the
same
way
it
does
for
the
parish?
F
Think
there's
some
elements
of
it
that
may
need
to
be
discussed
so,
like
the
Fedora,
the
the
core
OS
pipeline
tools
should
be
pretty
there.
The
Fedora
chorus
team
already
has
many
of
those
elements,
the
bits
of
it,
so
it's
kind
like
Fedora
caress
is
like
just
one
component.
The
vast
majority
of
the
rest
of
the
components
are
just
very
simple:
docker
images
on
top
of
the
village
and
so
I
think
it
I
think
we're
pretty
close.
Its
there'll
be
a
few
in
there.
F
B
A
B
What
sue
did
what
I'm
struggling
a
bit
to
kind
of
be?
What
are
the
next
action
item
on
this
particular
topic?
Is
it
something
we
need
to
kind
of
put
it
down
and
discuss
how
we're
going
to
do
the
implementation?
If
there
is
any
need-
or
we
should
say
forget
about
that,
because
we'd
be
on
that
plane,
so
we
can,
you
know,
wrap
it
up
and
any
ever
the
whole
day
the
pieces
put
together
in
the
puzzle
to
be
honest,
I
feel.
F
Like
the
fat
like
I
am
I,
am
you
know,
I'm
a
very
incremental
kind
of
person,
I
I
think
we
could
very
easily
get
to
the
point
Murray
about
fedora
course
and
do
the
basic
minimum
integration
I
think
has
been
and
Christian
have
kind
of
like
talked
about
with
Colin
and
other.
Do
that
bare
metal
and
a
bare
minimum
integration?
F
And
then,
as
we're
getting
close
to
that,
have
a
discussion
about
you
know
we
might
have
a
phase
zero
prototype
that
has
some
wrinkles
that
we're
not
happy
with
and
then
in
phase
one
or
phase
two
get
the
release.
Tooling
evolve
the
release
tooling,
however,
we
need,
and,
however
it
needs
to
be
opened
up
to
make
it
easy
for
that
as
well
as
consider
you
know,
maybe
we
should
rewrite
it
all
from
scratch
and
bash
or
something.
A
All
right,
I
heard
that
no
bash
nope,
so
we're
almost
at
the
end.
The
our
cognizant
of
everybody's
times
and
every
edge
was
including
my
own
and
I
had
I
do
have
a
survey
results
in
as
I
said
earlier.
They
are
mostly
about
logistics
or
timings
of
things,
and
what
people
had
said
really
was
bi-weekly
would
be
good
and
it
looks
like
for
the
majority
of
people
at
the
moment.
A
A
There
was
no
serious
winner
for
a
day
of
the
week
and
for
me
earlier
is
always
better
in
weekdays,
but
I'll
send
a
note
to
the
mailing
list
around
that
and
I'm
going
to
propose
something
in
two
weeks
time
to
the
group
and
the
other
thing
I
just
added
into
the
bottom
and
please
feel
free
the
date
for
the
ignition
deep
dive
is
August
28th.
At
9
a.m.
Pacific,
as
you
can
see,
that's
why
I
don't
like
9
a.m.
A
A
We
and
you
will
through
the
mailing
list,
will
then
and
Colin,
and
probably
myself
will
hook
up
on
the
trade-off
choices,
doc
development
and
probably
set
up
a
meeting
to
do
that.
The
only
thing
I'm
gonna
say
to
everybody
right
now
is
I'm
on
vacation
next
week
and
the
week
after,
though
you
may
be
doing
some
of
this
on
your
own,
but
I
will
stage
you
nicely
and
then
Diane
and
Sanja
will
I
think
somebody
else
volunteered
for
working
on
the
the
Charter.
Let
me
just
look
at
the
notes
here.
A
Anyone
else
and
Danny
well
we'll
do
that,
but
we'll
try
and
do
that
as
much
the
email
threads
and
then
share
the
documents
in
a
Google
group
folder
that
is
public
for
now
and
then
figure
out
where
to
host
this
stuff.
Once
we
have
first
drafts
in
the
okay
D
Weibo,
so
that's
probably
another
task
to
take
on
this
two
weeks
time
sound
good
for
everybody
here,
who's
still
on
the
call
and
hasn't
dropped
off.
Is
there
any
objection?
Two
weeks
from
now
good,
okay.
G
A
So
cool,
so
thank
you
all
again
for
coming
for
Danny
for
Tim
or
John
and
Neil
and
everybody
who's,
not
from
Red
Hat.
It
is
greatly
appreciated
and
we
love
I
love.
I,
don't
don't
speak
for
Red
Hat
men,
we'd
love
that
you're
here
and
in
this
conversation,
and
if
you
have
other
people
that
you've
we
can
invite.
Well,
we
should
please
do
and
again
if
you
can
join
the
the
ok
D
working
group
mailing
list,
we
promise
it's
not
another
marketing
list.
A
It
is
specifically
for
working
group
conversations
and
the
open
ship,
dev
and
open
ship
users
is
still
going
to
be
there
for
mailing
list,
for
people
to
use
so
use
that
for
to
continue
the
conversations
you're
having
but
the
stuff
around
voting
and
documents
and
meeting
announcements
will
try
and
do
on
the
OPD
working
group
and
decision
making
there
there
you
go
Wow.
We
did
it
in
two
minutes
over.
So
thank
you
all
and
I
will
post
the
recording
first,
along
with
the
links
to
the
notes
and
we'll
be
going
going
for
it.