►
From YouTube: Cluster API Breakout Meeting 2019-05-29
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Great
okay
welcome
everyone
to
the
cluster
API
meeting
or
Wednesday
May
29th
2019.
This
is
the
first
cluster
API
meeting
since
cube
con
happened
and
we
probably
have
a
bunch
of
things
to
go
over.
It
looks
like
there's
a
some
meta
stuff
coming
up
first
and
we'll
do
an
introduction
for
new
folks
after
it
looks
like
Doug
wants
to
go
over
a
bit
of
meeting
etiquette.
A
Please
add
your
name
to
the
attending
list
if
you
have
anything
to
or
if
you're
attending
and
and
anything
you'd
like
to
discuss
onto
the
agenda
at
the
bottom,
and
we
can
rearrange
if
it's
necessary,
but
with
that
Doug.
If
you
want
to
talk
about
meeting
etiquette,
could
be
awesome.
Thank
you.
Oh
yeah,.
B
Thanks
so
a
couple
of
meetings
back,
we
started
using
the
raise
your
hand,
feature
of
zoom
to
sort
of
keep
conversation
flowing,
but
also
allow
everybody
done
to
participate
and
have
their
say
and
then,
sometime
after
we
started
doing
that,
I
asked
for
the
meeting
right
before
cube
con.
That
was
sort
of
a
free-flowing
thing
and
not
really
with
a
very
structured
agenda,
because
I
kind
of
wanted
to
dig
in
deep
on
on
whatever
people
were
interested
in
and
feedback
after.
That
was
that
that
particular
meeting,
especially
but
also
some
previous
meetings,
had
been
it.
B
The
the
raise
your
hand,
thing
wasn't,
wasn't
working
out
quite
as
well
as
we'd
hoped,
and
so
we
talked
about
it
with
a
couple
of
people
at
cube
con.
The
idea
of
differentiating
between
I
want
to
speak
next
and
I
want
to
speak
next
on
the
current
topic,
and
so
what
I
was
suggesting
was
that
we
used
the
raise
your
hand,
feature
to
add
to
or
rebut
or
comment
on
or
whatever,
whatever
we're
talking
about
at
the
moment.
B
Why
don't
you
put
it
at
the
agenda
and
we'll
get
to
when
we
get
to
that
point
in
the
agenda
and
get
us
back
on
track,
which
also
is
something
that
we've
talked
about
wanting
to
be
a
little
better
about
so
I
just
want
to
throw
that
out
there
for
everybody
to
think
about
I,
don't
know
whether
we
want
to
talk
about
it
in
depth
here
whether
people
have
objections
to
it.
That's
sort
of
thing,
I
think.
C
A
Well,
thank
you
for
that.
If
anyone
has
any
other
comments
on
that,
I
think
it
would
probably
be
good
to
add
to
the
meeting
notes
just
somewhere
at
the
top,
so
we
sort
of
have
that
written
down.
Sure
I
can
do
that
cool.
Thank
you
and
just
to
post
an
introduction
here
for
anybody
who
is
joining
us
for
the
first
time.
This
is
a
sub-project.
This
this
particular
meeting
is
a
sub
project
of
the
sig
cluster
life
cycle.
So
the
sig
is
a
special
interest.
A
Group
and
sync
cluster
life
cycle
is
a
special
interest
group
relating
to
the
life
cycle
and
management
of
kubernetes
clusters.
So
cluster
API
aims
to
solve
exactly
that,
or
at
least
in
some
way,
automating
and
managing
kubernetes
clusters
in
the
whole
life
cycle.
Looking
there's
a
link
to
the
scopes
and
objectives
of
this
project
and
at
the
top
of
the
notes,
there
is
a
list
of
ongoing
enhancement
proposals
for
cluster
API,
but
I
think
we
have
a
bunch
of
things
to
talk
about.
It
looks
like
so.
A
If
anyone
has
any
questions
feel
free
to
reach
out
either
in
the
chat,
or
you
convey
me
on
kubernetes
slack
privately.
If
that's,
if
you
feel
more
comfortable
doing
that,
yes,
the
slack
channel
is
cluster
API
has
Vince
has
pointed
out
with
that.
Let's
move
on
to
the
next
topic:
Andy,
it
looks
like
you've
got
release
cadence
proposal
thanks.
E
E
D
D
115
is
scheduled
for
June
17th
and
if
we
add
six
weeks,
that's
July,
29th
I,
don't
know
that
will
necessarily
be
ready
for
a
V
104
to
release
by
July
29th.
So
we
could
either
just
do
it
as
soon
as
we're
ready.
You
know
July
29th
or
later,
or
we
could
just
say,
not
we're.
Gonna
start
with
six
weeks
after
116,
which
I'm
guessing
is
probably
late:
October
Justin.
F
I
guess
I
actually
want
to
reason
than
to
agree,
but
also
to
say
hey.
We
do
something
similar
but
less
timely
in
cops
where
we
really
sort
of
after
communities
one
of
the
things
people
do
like
that,
but
they
dislike
the
idea
that
at
that
big,
like
release
brouhaha,
that
they
can't
like
get
the
latest
and
greatest
cups.
F
So
it
could
be
a
good
idea
to
try
to
have
alphas
or
betas
also
running
so
that
when
the
release
train
comes
around
and
I
was
excited,
that
there
is
some
version
of
the
cluster
API
that
they
could
try.
I
do
also
hope
that
we
won't
have
that
many
like
any
strict
dependencies
with
communities.
But
yes,
as
you
say,
chameleon
types
will
be
an
example
counter.
Example
to
that
I
guess:
I.
A
A
G
E
D
C
D
A
D
D
If
it
doesn't
go
well,
but
I
think
that
it
would
be
nice
to
try
and
do
this
and
I
would
love
for
Tim
when
he's
back
to
present
to
this
group
the
way
that
he
does
the
key
video
prioritization.
So
I
will
probably
wait
a
little
bit
until
next
week
for
him
to
returns.
But
I
do
want
to
have
a
discuss
post
around
this
so
that
we
can
get
everybody
a
chance
to
read
it
and
and
comment
on
it.
D
Yeah
I
have
seen
it
post
in
slack
and
say:
hey
folks,
we're
gonna
do
Cuba
diem,
prioritization
anybody's,
welcome
to
join
and
I
would
like
to
do
something
similar
with
this
group
for
cluster
API
yeah.
D
D
It's
probably
worth
copying
over
here,
but
I
think
we
at
least
several
of
us
spoke
and
recognized
that
trying
to
cover
everything
in
B
1,
alpha
2
is
going
to
probably
be
difficult
and
that
it
would
benefit
the
community
if
we
can
have
more
frequent
iterative
releases
than
trying
to
get
everything
done
in
one
release
that
takes
us
a
year.
To
have
to
do
so.
D
Machine
bootstrapping
and
we
had
several
several
groups
in
agreement,
at
least
in
principle,
on
the
approach
that
we're
looking
at
doing
for
machine
bootstrapping.
So
I
am
working
to
write
up
cap
for
that
and
as
soon
as
we
have
something
shareable,
we
will
share
it.
It's
going
to
incorporate
lots
of
things
that
we've
already
been
talking
in
terms
of
machine
life
cycle,
machine
bootstrapping,
so
I
hope
that
nothing
will
be
earth-shattering
and
complete
completely
out
of
left
field
for
people,
but
basically
that's
what
I'm
looking
to
try
and
get
agreement
on
that.
D
F
D
D
C
D
It's
a
good
question:
I,
don't
think
anybody
can
really
say
with
any
certainty
today
there
will
be
three
betas
or
three
alphas
in
minutes
data
like
we
with
each
alpha.
We
learn
new
things
and
we
get
feedback
from
the
community
and
that
helps
us
shape
new
alphas
and
I.
Think
as
we
get
more
refined
feedback
and
a
better
understanding
of
what
works
well
and
what
doesn't
work
well,
we'll
be
able
to
make
an
educated
decision
to
go
from
alpha
to
beta.
F
Justin,
well,
it's
just
out
on
that.
It's
it's
also
a
tricky
question,
because
the
API
can
still
be
alpha,
but
we
could
have
a
stable
release
indicating
that
we
don't
believe
that
the
AP.
We
believe
that
the
ego
is
going
to
change
significantly
going
forwards,
but
we
believe
that
if
you
are
willing
to
use
the
API
fields
as
we've
defined
them
today,
that
everything
should
work
so
I
think
you
know,
we've
talked
about
quarterly
cadence
and
we
can
have
quarterly
releases
that
are
dot
zeroes
or
whatever.
We
call
them,
but
they
are
still.
D
A
A
F
Yeah
Justin,
yeah,
I,
just
I
just
wanna,
say
I,
really,
I
actually
really
liked
the
the
hand
thing
I
may
be
abusing
her
overusing
a
little
bit
and
I
really
like
our
arty
scoping,
so
I
think
it
everyone
that
liked
it
that
I
think
like
we
can
actually
make
progress
again
place
somewhere
like
where
we
are
written
yeah.
So.
D
H
H
For
example,
if
we
have
machine,
if
we
add
a
field
to
the
machine
spec-
and
we
don't
even
call
it
spec,
but
it's
basically
like
the
kubernetes
api
version
right,
yeah,
the
domain,
the
namespace
string,
if
fields
are
added,
sometimes
we
don't
bump
a
version,
especially
if
it's
alpha,
but
if
fields
are
changed
or
removed,
then
we
do
bump
the
version.
So
I
think
the
good
practice
is
to
always
bump
the
version.
If
you
change
the
API
I
would.
G
Was
just
gonna
say,
like
we're,
probably
will
kind
of
have
these
discussions
like
when
we
actually
know
we
want
to
change
in
the
cap.
There
is
a
section
that
actually
talks
about
version
skew,
so
we
can
document
that
as
we
go
but
I
would
say
like
it
would
probably
follow
like
good
nice
genic
guidelines
around
that,
like
you
mentioned,
like
adding
a
field,
but
that
kind
of
depends
like
what
kind
of
field
that
you're
adding
like
if
you're,
actually
breaking
functionality
that
like
definitely
be
a
breaking
change.
B
Doug
you're
up
next
yeah
as
a
consumer
of
these
API,
is
if
I
was
working
with
two
different
clusters
that
claimed
to
support
the
same
guy
version
that
had
different
fields.
I
would
be
very
confused,
so
I
think
we
should
always
change
the
version
now
like
in
between
releases.
Maybe
we
don't
bother
to
do
it
like
every
single
time.
We
make
a
change
to
a
file,
but
at
the
release
boundary
if
we've
changed
the
fields
in
any
way,
I
think
we
should
increment
the
version
Oh
and
then
Michael.
C
F
G
E
So
I
fully
agree
with
D
scoping
view
on
all
four
I'm,
just
a
little
bit
unsure
where
we're
gonna
keep
track
of
the
scope,
because
if
I
look
at
the
issues
list
in
github,
that's
quite
long
and
not
really
categorized
and
the
scope
seems
to
be
split
across
like
five
different
documents
at
the
moment.
So
how
are
we
kind
of
planning
to
track
this
scope
for
the
next
release?
Yeah.
D
Don't
know
how
much
commentary
we'll
want
to
do
in
a
Google
Doc
versus
in
a
pull
request.
But
ultimately
we
will
open
up
a
pull
request
to
the
cluster
egg
repository
as
a
as
a
cup,
and
once
we
get
it
merged.
As
implementable.
I
would
imagine
that
we'll
have
a
series
of
github
issues
that
relate
to
this
particular
work
and
that'll
include
things
such
as
creating
AV
1,
alpha
2,
set
of
API
types
and
changing
the
controllers
to
use
them,
and
so
on
so
I
think
we'll
still
use
github
for
it.