►
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
Hello,
everyone-
this
is
the
cluster
API
of
this
hour
and
today
is
October
the
5th
and
before
starting
a
quick
reminder
that
this
meeting
abide
to
the
cncf
code
of
conduct
so
be
kind
with
each
other.
And
if
you
have
topic
you,
you
can
add
them
to
the
meeting.
B
A
Let
me
share
the
documenting
chart
and
in
order
to
to
add
the
item
to
the
gender,
you
need
to
subscribe
to
the
be
subscribers
to
the
seek
cluster
life
cycle
management
list
and
one
last
item.
If
you
want
to
speak,
please
use
the
raise
and
feature
that
you
can
find
in
Zoom.
So
let's
get
this
started.
So,
first
of
all,
at
the
beginning
of
the
meeting
we
usually
welcome
new
attendees,
so
I
will
shut
up
for
some
few
seconds
and
let
people
to
to
chime
in
and
introduce
themselves
foreign.
A
If
someone
wanted
to
increase
the
sample
so
later
feel
free
to
do
it.
Okay,
moving
on
open
proposal
readout,
so
is
there
some
update
about
a
new
proposal?
This
is
Stefan
with.
The
answer
is
please.
C
Just
Guillermo
couldn't
join
so
he
was
asking
on
on
spr
for
the
htms
from
everyone,
like
you
suggested.
He
got
hdms
and
I
think
we
should
start
on
the
AC
consensus
now
and
and
set
a
date.
A
A
D
D
October
face
of
this
coming
to
the
constant
source.
D
D
Next
week,
which
is
but.
A
Okay,
okay
I
also
have
an
update
with
regards
to
open
proposal,
so
I
I'm
continuing
to
work
on
the
topic
of
level
sync.
Last
week,
I
introduced
the
first
breakdown
of
this
work.
That
is
the
pr
it
is
a.
A
The
documents
how
we
plan
to
do
level
sync
between
machine
and
underlying
kubernetes
nodes
this
week,
I
started
a
new
weave
proposal.
It
is
still
work
in
progress
but
I'm
getting
there
that
basically
tickles
the
problem
of
in
place
propagation
of
changes
affect
the
kubernetes
object.
Only
why
I'm
not
talking
about
labels,
it
is
documented
in
in
in
The
Proposal
itself,
but
basically
we
have
other
information
like
I.
A
B
D
C
And
we
have
a
first
proposal
for
essentially
the
next
two
release,
dates
and
yeah.
How
to
recycle
itself
would
work
yeah
also
discuss
it
with
what
beats
you
know,
so
what
I
would
do
is
essentially
I
would
show
the
picture
and
then
just
go
through
it.
I
think,
based
on
a
1.3
example,
maybe
just
how
how
you
think
that
could
work.
C
Please
correct
me
if
I'm
misrepresenting
something:
okay,
okay,
so
we
are
currently
in
the
wonderful
recycling,
of
course,
somewhere
September
October
and
we
are
still
just
only
churning
all
essentially
patch
releases
here.
C
So
we
defined
a
recycle,
more
or
less
like
kubernetes
or
recycling
means
starting
from
the
point
where
we
start
working
on
release.
So
when
we
release
the
previous
release,
so
here
we
released
one
or
two:
we
start
with
three
cycle
of
1.3
and
the
recycle
essentially
goes
until
we
do
the
1.3.0
release.
That's
not
super
visible
here,
but
we
put
some
in
the
docks
so
essentially
just
from
when
we
start
to
work
on
it
until
you
have
the
minorities,
that's
what
recycle
itself
is
for
1.3
and
1.4.
C
That
would
be
each
roughly
four
months
and
the
ideas
to
have
the
next
one
or
three
release
end
of
November
and
the
1.4.
This
end
of
March
I
added
those
all
through
the
meeting
notes.
C
Then,
regarding
Alpha
Beta
RC
releases,
the
idea
is
that
in
the
first
three
months
of
the
release,
we
can
essentially
create
iPhone
releases
on
demand.
So
if
there
is
a
reason
to
worry,
have
an
ivory,
so
that's
easier
for
someone
to
pick
up.
We
can
do
alpha
releases
in
that
phase,
but
we
usually
always
have
also
have
nightly
releases
every
day.
C
They
are
currently
broken
so
yeah,
but
once
if
the
Knight
is
fixed,
I'm,
not
sure
if
you
actually
I've
heard
this,
but
we
could
have
done
then,
four
weeks
before
the
release,
we
start
creating
better
releases.
So
those
are
just
those
two
weeks.
C
Let's
see
the
idea
is
to
have
them
as
a
preview,
more
or
less
so
folks
can
already
start
adopting.
It's
not
necessarily
feature
complete
at
this
point,
but
it
should
be
already
very
stable
and
it
can
be
definitely
used
for
testing
Etc
just
to
already
get
the
providers
working
next.
Does
the
API
release?
The
idea
is
that
from
this
point
forward,
every
change
that
we
would
want
to
merge,
that
would
break
providers
has
to
be
discussed
and
approved
in
the
office
or
so
just
yeah?
Essentially
ideas.
C
If
you
have
things
that
affect
providers,
we
should
merge
them
at
the
beginning
of
3D
cycle,
and
if
you
have
something
that
really
has
to
be
merged
after
we
start
with
betas,
we
have
to
essentially
discuss
and
approve
it.
Otherwise
it
won't
be
merged
into
this
release.
Of
course
it
can
be
merged
into
the
next
release,
but
otherwise
we
already
have
like
provider
breaking
changes
towards
you.
Then,
after
two
weeks
of
betas,
we
start
with
release
candles
and
that's
also
the
time
where
we
create
a
release
Branch.
C
So
two
weeks
before
release,
we
created
a
new
release.
Branch,
we
have
feature
freeze,
feature,
freeze,
a
feature
or
code
freeze,
we
don't
make.
C
A
difference
essentially
means
the
only
things
that
are
allowed
to
merge
are
bug,
fixes,
test
improvements,
test
fixes
documentation,
but
nothing
else
and
yeah,
and
then
we
have
those
two
weeks
where
the
main
goal
is
just
stabilize
the
release
until
the
minorities
and
from
this
point
forward
we
can
already
start
matching
things
again:
breaking
Stuff
Etc
on
Main,
which
are
then
part
of
the
next
three
is
1.4
so
just
to
check
if
I
missed
one
of
the
important
points.
C
Yeah
yeah,
so
main
goal
is
definitely
to
have
a
predictable
risk
Cadence
to
allow
providers
to
plan.
On
top
of
that,
so
that
when
people
know
hey
here
in
November
or
in
March,
the
next
class
API
really
is
coming.
They
can
already
kind
of
include
that
in
the
provider
minorities
planning
and
ideally,
we
can
shorten
the
the
time
period
between
the
cluster
API
release
and
the
provideries,
because
class
apis
only
actually
really
useful
to
users.
C
C
C
B
No
I
think
that
was
great
I
think
the
only
thing
I'll
add
is
like
this
is
kind
of
a
attempt
to
like
structure
a
little
bit
for
the
next
two
releases.
Just
so
we
have
dates
in
mind
to
plan
for
the
release
team,
but
I
think
the
plan
is
not
to
like
say
this
is
the
release
Cadence
we're
gonna
adopt
forever,
like
I
think
we
want
to
reevaluate
at
the
end
of
really
1.4
and
see
how
that
went
and
what
we
want
the
Cadence
to
be
for
1.5.
C
What
I
would
do,
as
the
next
step
is
essentially
put
that
into
or
let's
say,
I'll
take
a
look
at
our
documentation,
I'll
see
where
it
fits
I
think
it
would
be
good.
Definitely
for
now
to
have
that
picture
there.
We
have
to
decide
going
forward
if
you
want
to
maintain
it
or
not.
I
think
it's
a
good
overview
and
yeah,
of
course,
also
the
other.
C
The
things
I
just
mentioned,
like
oh
four
weeks
before
release
we're
doing
that
two
weeks
before
we're
doing
that,
I
would
put
it
all
into
the
documentation.
Then
we
can
also
do
a
round
of
reviews
on
top
of
that,
based
on
that
PR
oud.
But
if
they
are
then
still
no
concerns,
then
it
would
just
go
ahead
with
that
plan
is.
A
Okay,
I've
seen
some
someone
making
congratulations
on
using
the
reaction
in
in
the
in
Zoom
Mike
is
writing
that
everything
sounds
good
and
thank
you
for
their
work,
which
is
something
that
I
Echo
and
so,
in
my
opinion,
I
already
reviewed,
discussed
this
before
and
and
I
think
that
that
is
is
a
good
step
in
in
the
right
direction
and,
as
I
still
said,
we
have
to
start
somewhere
and
let's
iterate
in
future.
If
you
find
out
that
this
can
be
improved.
So
thank
you
Stefan
and
sister
for
grabbing
this.
D
B
B
Another
reason
why
also
we
wanted
to
kind
of
plan
for
like
a
1.4
start
is
so
that
we
can
plan
ahead
and
start
forming
a
first
release
team.
So
do
you
mind
going
back
to
the
the
Google
docso?
Please
thanks
yeah,
just
at
the
bottom
right
there
yeah,
so
we
had
some
like
I
think
a
lot
of
people
volunteered
last
time
when
we
first
brought
up,
but
the
plans
were
kind
of
still
a
little
vague.
B
Now
that
we
have
a
better
idea
of
exactly
what
the
release
team
is
going
to
do
and
for
how
long
we
would
like
to
call
for
volunteers
again
for
the
first
cycle,
so
the
idea
is
that
I
will
be
looking
for
one
person
to
fill
each
role
that
is
defined
in
that
document
right
there.
If
you
can
click
on
it
reads
you
please.
B
So,
essentially,
we're
looking
for
one
person
to
be
release
lead
for
1.4,
one
person
to
be
Communications,
docs,
release,
notes,
manager,
one
person
to
be
CIA
signal,
bug,
triage
automation,
manager
and
then
up
to
or
around
three
shadows.
So
maybe
one
Shadow
for
each
role,
and
so,
ideally
the
people
who
will
be
taking
on
this
role.
They
they
don't
need
to
be
maintainers
of
cluster
API
or
reviewers,
but
ideally
you're,
already
a
kubernetes
six
member.
B
So
you
have
basic
permissions
to
do
things
like
triage
issues,
ideally
you're
already,
a
contributor
of
cluster
API
and
you're
somewhat
familiar
with
the
project.
This
is
for
the
first
time
just
so
that
this
is
a
smooth
process
since,
like
it's,
the
first
time
we'll
be
doing
this,
and
we
just
want
to
make
sure
that
people
are
kind
of
already
aware
of
the
basics
and
they
can
help
also
Define
the
process
itself.
B
We're
trying
to
have
a
good
company
representation.
So
if
we
can
try
to
do
three
different
companies,
that
would
be
awesome
and
what
else
did
I
write
down?
If
you
have
experience
releasing
a
open
source
project,
that's
a
plus,
it
doesn't
have
to
be
Cappy.
It
could
be
any
project
that
you're
experienced
with
doing
a
GitHub
release
and
know
how
that
works.
That
would
be
awesome
so
going
to
try
to
figure
this
out
before
kubecon.
B
So
in
the
next
two
weeks,
if
you're
interested
and
you
or
if
you
just
want
to
discuss
to
know
more,
please
or
if
you're
like
hesitant
or
have
any
questions,
please
reach
out
to
me
on
slack
or
stefaner
for
Brazil
or
any
of
the
maintainers
will
be
happy
to
help
and
we
can
talk
and
see
if
this
is
a
good
fit.
So
just
to
clarify
this
is
for
1.4.0
release
cycle
only
not
forever.
So
this
is
a
very
defined
period
of
four
months
that
goes
from.
B
If
you
scroll
back
to
the
diagram,
that's
the
fan
hat,
that
is
from
December
approximately
December
1st
to
April
1st
yeah.
So
that
is
when
we'd
be
looking
I
think
did
we
said
December
15th.
B
So
I
guess
somewhere
around
beginning
of
December
to
beginning
of
April,
is
what
you
should
be
looking
at
in
terms
of
time
commitment,
and
then
this
isn't
going
to
be
like
a
full-time
job
or
anything
like
that
where
you
need
to
like
put
your
other
duties
on
hold,
and
just
do
this
for
six
months
or
four
months,
it's
more
like
a
few
hours
a
week
kind
of
thing
and
we'll
we're
kind
of
defining
this
as
we
go
again.
B
This
is
the
first
time
we're
doing
this,
though
you'll
also
help
us
learn
from
the
process
and
iterates
for
next
time.
Does
that
Define?
Do
you
have
anything
to
add
to
that
that
I
kind
of
cover
all
the
points
yeah.
C
Just
one
comment:
what
we're
planning
to
do
until
the
let's
say
until
beginning
of
December
is
just
to
improve
the
current
state
a
little
bit
in
a
sense
of
that
we
have
more
documentation
about
what
to
actually
do
than
we
have
today,
but
yeah.
That's
a
little
bit
work
in
progress.
C
So
it's
not
like
hey
we're
just
saying:
please
do
that
stuff,
and
then
you
have
no
idea
what
to
do.
We
really
aim
for
having
a
basic
documentation
about
how
we
currently
do
those
releases
and
and
what
you
would
have
to
do
during
those
four
months
so
that
you
don't
have
to
search
start
from
scratch.
Essentially.
B
Yes,
and
the
other
point
also
that
that
reminds
me
is
Stefan
and
I
are
also
going
to
be
there
as
Shadows
and
to
help
out
the
first
release
team.
So
at
first
we
thought
of
like
whether
we
should
be
the
first
release
team.
B
But
then
we
figured
that,
if
we're
doing
it
ourselves,
it
might
not
help
us
improve
the
process
in
a
way
that
is
like
more
inclusive
to
everyone,
who's,
not
a
maintainer,
and
so
we
want
to
make
sure
that
we're
there
available
to
help,
but
also
learning
from
watching
someone
else
go
through
it.
The
first
time.
B
D
E
Yeah
I
just
wanna
I,
don't
know
if
we've
done
this
already
or
not
before,
but
I'm
wondering
like
since
we're
kind
of
like
rolling
up
to
this
for
the
first
time
would
it
you
know
like
thinking
about
the
shadowing
and
whatnot?
Would
it
make
sense
to
kind
of
like
make
a
video
recording
of
doing
this
one
time
so
that
we
could?
We
could
maybe
share
the
recording,
as
as
extra
material.
A
This
could
be
an
idea
honestly,
we
have
to
figure
it
out
how
to
write
the
documentation
on
our
football
knowledge,
but
yeah.
These
are.
These
are
good
suggestions
to
see.
B
Yeah
I
think
that's
a
great
suggestion
Mike,
especially
for
the
like
actual,
like
cutting
the
release.
Part
where,
like
we
go
through
like
the
automation,
steps,
I
think
that
would
be
a
good
one
to
have
right.
That
can
be
something
that
we
do
in
the
next
month
and
have
like
the
fun
we're
saying,
like
I,
think
the
next
month,
we're
gonna
focus
on
like
building
up
our
ducks,
so
that
the
people
who
do
this
aren't
lost
and
have
some
documentation
to
start.
E
Yeah
that
sounds
awesome.
I
was
just
thinking.
I
was
kind
of
imagining
like
if
we
get
the
shadow
and
the
release
person
together
and
like
you're,
probably
gonna,
be
you
know
doing
a
video
chat
anyways
as
you
do
this
yeah.
It
might
be
easy
to
pick
it
up
or
something
so
anyways
yeah
cool,
I'm,
happy
to
hear
it.
A
Okay,
great
next,
one
in
agenda
is
Stefan.
C
Yep,
so,
first
of
all,
thanks
for
always
keeping
us
up
to
date
on
new
stuff
and
qadian.
So
let
me
started
rfe
hack,
MD
for
HD
learner
mode
and
I
just
wanted
to
essentially
service
it
here.
If
people
are
interested
to,
please
take
a
look
and
give
feedback
so
there's
the
second
year,
the
corresponding
Cube
idiom
issue,
and
we
also
have
a
cluster
API
issue
that
is
I,
think
roughly
related.
C
You
know
I
look
here
if
you
want
to
say
more
you're
awesome
here,
if
you
want
to
but
I
think
that
that's
the
main
part.
F
Basically
we're
looking
for
someone
for
coaster,
API
or
other
areas,
of
course,
life
cycle
to
potentially
step
in
and
help,
because
we
are
not
really
stuffed
to
do.
This
change
in
Canadian
I
managed
to
write
a
proposal
with
the
idea
to
how
do
I
say
to
explain
how
the
difficulty
Alliance,
but
basically,
if
somebody
is
interested
and
wishes
to
improve
this
Integrity
of
cubadium
around
hcd,
please
step
in.
D
Yeah
and
I
think
like
plus
one
to
this
I
think
basically
like
this
is
also
affecting
stuff
like
cap
V.
So
it's
definitely
like
for
any
other
on-prem
provider,
for
example
using
Cube
VIPs
as
a
load
balancer.
So
there's
that
there's
like
issues
that
comes
up
also
during
bootstrapping
because
of
leader
elections,
so
yeah
I
think
this
is
definitely
for
the
better
for
for
cluster
API
in
general.
Thank
you.
D
A
I
agree:
this
is
a
this
cool
is
an
option
to
give
to
have
better
stability
on
on
the
joy
process,
especially
a
machine
with
low
D
is
called
poor,
Network
performance,
and
so
these
are
these
changes
important
from
cluster
Pi.
We
should
help
as
much
as
possible
and
also
I'm,
seeing
that
in
the
document
there
is
a
the
idea
to
have
this
behind.
A
Key
and
so
this
will
kind
of,
let
us
to
experiment
and
see
how
it
works
in
reality
progressively,
which
sounds
great.
So
thank
you
very
much
for
giving
another
push
to
this
idea.
C
Stephanie
yep,
so
can
you
open
up
the
link?
C
Oh
yeah,
that's
originally
for
the
progress.
Okay,
so
just
some
context.
So
today,
when
we
look
at
detains
field
that
we
have
in
our
Cuban
conflict,
that's
the
third
called
snivit.
C
Essentially
Auto.
Documentation
says
that
you
can
hydro
set
retained
a
feud
not
at
all
in
cluster
API,
which
means
Cupid,
M
just
does
its
default
thing.
Then
it
says
you
can
set
an
empty
slice,
which
means
there
should
be
no
chains
on
the
control
plane
motion
or
you
just
set
a
list
of
things,
and
then
you
get
a
list
of
things.
The
problem
is
that
the
case
where
you
can
set
an
empty
size
just
doesn't
work
today
with
our
API.
C
The
problem
is
running
for
web
Hooks
and
also
I
think
for
bootstrap
controller,
we're
doing
a
lot
of
Chase
marshalling
and
unmarceling,
and
because
we're
using
omit
empty
on
the
chains
field.
The
Chase
and
marshalling
doesn't
differentiate
between
the
slides
being
set
to
new
or
the
Styles
being
set
to
an
empty
slice.
C
So
essentially,
we
just
get
one
new
additional
Behavior,
which
is
we
are
now
able
to
set
an
empty
slide,
slides
which
gender
cells
in
a
control
plane
with
routines
and
I
mainly
want
to
bring
this
up,
because
it's
a
change
to
how
we
Marshal
this
field
and
if
you
consider
this
change,
something
that
we
can
do
I
would
also
suggest
to
cherry
pick
it
accordingly,
because
it's
essentially
a
bug
fix
to
the
field.
So
the
question
is:
do
you
have
a
problem
with
that
or
not
yeah?
C
Maybe
the
before,
after
is
an
important
thing.
Sorry,
essentially,
I
I
wrote
down
what
what
we
have
a
before
and
after
this
PRS,
so
before
this
PR.
C
If
the
slice
is
no,
it's
not
marshaled
in
chasing.
If
it's
an
empty
slice,
it's
not
Marshall
and
Jason.
So
we
can
differentiate,
and
if
you
have
an
area,
then
just
get
an
array
and
afterwards
the
first
two
cases
change.
So
if
the
slice
is
new,
you
will
get
it
as
null
in
yummy
and
if
it's
an
empty
slice,
then
it
just
stays
in
empty
sense,
yep,
so
yeah
just
asking
for
free
conversation.
A
C
D
Hey
I,
just
wonder:
do
we
need
to
consider
backwards
compatibility
here
because
as
far
as
I
understand,
if
a
user
sets
explicitly
an
empty
slice,
then
at
the
moment
they
would
get
the
default
things
and
in
the
future
they
would
get
no
taints.
Is
that
a
concern
here.
C
Good
question,
essentially,
the
behavior
would
definitely
change
or
for
that
behavior
is
based
on
the
Golduck
that
we
have
clearly
a
buck.
So
a
good
question,
but
yeah.
C
A
C
Me
yeah
so
I
just
hope.
The
benefit
of
making
that
behavior,
possible
and
and
bug
free
outweighs
the
case
where
someone
did
set
an
empty
size
and
then
later
on,
didn't
really
notice
that
that
doesn't
work,
and
now
it
suddenly
starts
working.
A
F
A
A
Okay,
so
so
it
seems
that
there
are
people
that
that
are
interested
to
this
to
this
fix,
because
they
are
working
around
these
in
in
yeah
in
strange
ways.
So
this
will
help
users.
So
if
there
are
no
other
issue
in
Alaska
second
issues,
we
can
get
some
time
back
today.