►
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
a
cluster
api
office
hour
meetings
today,
is
wednesday
six
of
july
before
starting
some
notes.
So,
if
you
want
to
speak
you
you
have
to
use
the
resent
feature
or
in
zoom,
which
is
near
reactions.
A
To
keep
an
eye
on
the
participant
list,
and
otherwise
please
help
me
find
out
if
someone
raises
ended,
if
you
want,
if
you
have
some
topic
to
discuss,
please
feel
free
to
add
them
to
the
agenda.
I've
posted
the
agenda
links
links
in
chat.
If
you
don't
have
access
to
the
document,
you
have
to
join
the
sierra
crystallized
cycle,
meaning
race.
A
A
Okay,
let's
keep
moving
so
as
usual
at
the
beginning
of
the
meeting,
we
give
a
room
to
new
attendees
to
introduce
themselves
why
they
are
interesting.
That
is
api
and
sports,
so
or
just
say
hello,
and
I
stopped
for
a
few
seconds
for
the
new
attendees
to
speak.
A
Okay,
since
there
are
no
new
attendees
this
this
week
is
someone
joy
later
feel
free
to
speak
up
as
well.
Let's
go
to
open
proposal
readouts,
so.
B
I
will
give
a
brief
update
on
the
cluster
api
add-on
orchestration
proposal,
so
the
the
the
work
that
we've
been
doing
to
define
the
spec
has
been
in
the
google
doc.
That
fabrizio
is
now
opening
and
sharing,
and
this
has
sort
of
stabilized
we've
got
a
lot
of
comments,
but
we're
not
getting
new
participation.
So
what
we
are
going
to
propose
to
do
is
to
sort
of
mark
this
as
read-only
at
the
end
of
the
week
and
if
you
know
feel
free
to
reach
out
to
myself
and
fabrizio.
B
If
you
feel
like
you
want
to
add
something
say
next
week,
we
can
be
flexible
on
that,
but
next
week,
I'll
work
with
jonathan
fabrizio
to
essentially
migrate
this
into
a
pr
form
into
the
cappy
repo,
where
we
can
do
the
next
phase
of
outlining
what
this
is
going
to
look
like
and
solicit
more
feedback
from
the
community.
So
just
more
of
a
heads
up
than
anything.
A
Okay
looks
great:
we
should
also
close
all
the
servers
comments
before
before
moving
it
so
that
it
yeah
it
is
easier
if
we
look
back.
B
A
Okay,
let's
move
on
discussion
topics,
discussion
topics,
so
I
I
have
the
first
one.
I
want
to
give
a
brief
update
on
on
release
1.2,
so
the
current
plan,
pending
provider,
feedback.
A
Is
to
cut
a
first
lc
next
monday,
11
00
and
to
cut
the
final
release
18
seven,
so
that
the
in
two
weeks?
Basically
currently,
we
know
that
some
providers
are
testing.
We
don't
have
a
feedback
of
problems,
so
we
think
that
this
is
sustainable.
But
please
speak
up.
If
you
see
that
this
roadmap
is
is
too
aggressive
or
not.
A
Moving
on
what
means
c1
for
us,
it
means
that,
basically,
we
start
the
code
freeze
or
you
can
call
it
feature.
A
Okay,
jack
is
telling
that
capsicum
test
looks
good.
Thank
you
for
the
feedback,
so
I
was
playing.
Cod
freeze
means
that
we
we
go
in
in
a
phase
where
we
stabilize
the
the
release,
so
we
limit
backwards
as
much
as
possible
only
to
basically
fixes,
if
required
or
small
documentation,
improvement
stuff
like
that,
but
yeah.
We
we
go
basically
for
stabilization.
A
Notable
changes
in
that
will
go
in
b1.2
rc1
are
we
are
going
to
bomb
controller
runtime
to
let
2
2
0
12.3,
which
is
not
yet
out,
but
yeah
we
are.
We
are
working
with
the
controller
and
time
team
to
get
it
out.
This
includes
an
improvement
on
custom
web
books
that
I'm
going
to
explain
in
a
second
and
yeah
and
also.
I
would
like
to
point
out
that
these
release.
A
A
This
change
must
be
implemented
in
in
the
web
books
only
if
they
are
enforcing
template
immutability,
so
the
change
is
documented.
I
will
briefly
go
through.
Documentation
does
also
show
what
is
what
are
the
expected
changes,
so
the
problem
that
we
faced
is
that
basically,
when
doing
server
side
apply,
we
were
dry
running
changes
on
templates,
but
the
the
infrastructure
and
booster
provider
have
implemented
immutability
checks.
A
A
What
we
are
proposing.
I
show
an
example,
a
diva
from
cup
d
that
probably
will
simplify
we.
What
we
are
proposing
is
that
provider
in
this
case
is
cup
b.
They
have
to
switch
their
validation
or
book
from
the
default
validation
or
book
that
the
controller
and
time
support
to
the
custom
validation
web.
That
was
introduced
a
couple
of
release
ago
custom
in
order
to
use
custom
validator
what
we
have
to
do
the.
How
do
you
register
so?
First
of
all,
you
have
to
introduce
a
new
type.
A
A
The
signature
of
the
method
is
slightly
different,
but
the
interesting
part
is
that
we
got
context
and
and
and
in
the
conte,
and
we
can
use
the
contest
in
order
basically
to
to
get
the
admission
request
from
the
context,
and
we
can
use
the
admission
request
in
order
to
check
if
this
operation
was
an
actual
dry
run
executed
by
the
topology
controller,
so
does
mean
that
we
are
going
to
skip
the
immutability
checks
only
if
we
are
dry
running
and
it
is
the
topology
controller
that
is
dry
running
everything
else.
A
We
will
be
ever
as
expected,
so
kuber
cattle's
apply
et
cetera,
et
cetera.
We
will
will
behave
as
of
today,
so
yeah.
The
change
is
not
big,
is
I
don't
know
15
lines
of
code
and
yeah.
We
hope
that
this
does
not
create
too
much
annoyance
for
for
the
provider.
A
You
can
yeah
ping
me.
Stefan
kilian
christian.
If
you
need
clarification,
and
I
stop
to
see
if
there
are
questions.
A
Okay,
so
it
seems
that
there
are
no
question
as
usual,
we
are
available
is
lucky
if
you
need
our
help
before
today.
I
had
a
discussion
with
stefan
that
that
I
would
like
to
yeah
to
raise
in
this
meeting.
Discussion
is
about
one
pr
which
is
the
pr
for
adding
the
types
from
the
ipam
proposal
to
cluster
api,
so
this
pr
is
still
there
working
there.
There
is
a
couple
of
question
pending.
A
But
it
is
also-
let
me
say
not
so
far
from
the
finish
line,
so
we
have
a
a
couple
of
options
in
front
of
us,
so
we
can
try
to
squeeze
this
pr
in
the
earth
rc
one.
So
that
means
finish
the
pr
by
by
this
week.
A
A
I
don't
know
later
this
year
we
don't
have
yet
a
planning
for
one
two,
three,
which
is
not
the
idea,
given
that
there
is
consensus
on
the
ipad
proposal-
and
I
know
there
is
interest
from
some
provider
to
have
it.
A
There
is
a
middle
ground
that
we
can
consider
if
there
is
community
agreement,
we,
that
is
to
make
an
exception
to
our
reporting
rules
and
basically
allow
to
cherry
pick
this
pr
sometime
in
in
1.1.
A
C
Hi
yeah,
I
I
personally
don't
think
we
should
make
an
exception
for
a
change.
This
big.
That
is
adding
like
a
feature.
It's
obviously
not
a
bug,
fix
it's
an
extra
extra
large
pr,
it's
adding
api
types.
I
I
think
it's
clearly
out
of
the
exception
rules
that
we
defined,
and
I
think
this
is
why
it's
so
important
that
we
really
get
on
a
release
cadence,
where,
when
something
misses
the
deadline,
it's
not
the
end
of
the
world
and
we
can
just
get
on
the
next
one.
C
I
think
why
there's
a
fear
right
now
that
we
punt
it
to
1.3
it's
a
bad
thing:
it's
because
we
have
no
guarantee
when
1.3
is
gonna
come,
but
if
we
know
1.3
is
coming
in,
let's
say
three
months
or
two
months
or
whatever
it
is.
I
think
it's
a
lot
easier
to
have
that
commitment
that
that's
when
it's
going
to
be
in
there-
and
I
don't
think
squeezing
it
into
1.2-
is
a
good
option
either
like
in
general,
that
just
you
know
squeezing
a
change
in
there
and
trying
to
pressure.
C
Reviewers
is
not
a
good
practice.
So
personally,
my
my
opinion
is
that
we
should
punt
it
to
1.3,
and
we
should
you
know,
do
things
well
take
the
time
to
have
a
proper
code
review
and
think
about
how
we
can
improve
our
guarantees
around
release
timelines
so
that
we
don't
have
this
issue,
because
this
is
going
to
keep
coming
up.
It's
not
a
one-off
thing,.
A
Yeah,
I
think
that
I
I
kind
of
agree
at
the
same
time.
I'm
aware
that
yeah
beans
jacob
do
you
want
to
speak
up
instead
of
writing
in
chat.
So
maybe
we
can
have
a
discussion.
D
D
E
E
The
main
reason
I
would
like
to
get
it
into
a
release
is
that
that
would
help
with
provider
implementation,
especially
on
the
infrastructure
provider
side,
because
providers
probably
don't
want
to
tag
unreleased
code
base
and
it
would
help
to
have
it
in
any
release,
even
if
it's
a
patch
release
to
just
be
able
to
properly
upgrade
to
that
code
base
and
then
be
able
to
do
also
experimental,
potentially
at
least
implementation
on
the
provider
side,
to
also
be
able
to
test
it
more
like
in
an
integrated
way
to
also
see
if
it
works
properly
with
providers
and
so
on,
so
to
make
any
significant
progress
on
the
provider
side.
E
F
Okay,
I'll
just
continue,
would
it
help
if
we
have
a
very
early
alpha
release
of
1.30
like
kubernetes
has
so
basically
once
they
do
their
release,
they
immediately
release
release
of
the
next
version.
A
A
I
think
that,
let
me
say
peop
if
we
address
the
comment
and
given
that
the
pi
is
being
discussed
at
length
in
the
proposal,
I
think
that
we
are
still
in
in
it
will
be
possible
to
get
this
done
by
monday.
A
C
Yeah,
I
I
think
the
fact
that
it
is
experimental
does,
I
think,
change
in
this
particular
instance.
I
didn't
realize
that
at
first
I
thought
it
wasn't
an
experimental
type,
but
I
think
regardless.
We
need
to
talk
about
this,
because
I
don't
think
this
is
going
to
be
an
isolated
instance
like
this
is
going
to
happen
again
in
the
future,
where
things
are
going
to
be
like
slipping
up
like
the
release
deadline
and
there's
always
going
to
be
like
a
good
reason
for
getting
it
out
there
sooner
than
later.
C
So
I
yes,
if
we
can
like
solve
it
in
this
particular
instance
by
merging
it
that's
great,
but
I
still
think
we
need
to
think
about
the
overall
like
what
is
our
our
strategy
for
when
something?
This
is
the
release,
and
I
think
what
vince
brought
up
also,
we
need
to
talk
about
like
the
fact
that
we
don't
we
feel
like
we
don't
have
any
enough
people
to
do
releases.
That's
a
problem.
I
feel,
like
that's
a
pretty
important
aspect
of
the
health
of
the
project
and
I
think
fabrica.
C
A
Yeah,
I'm
I'm
totally
in
in
trying
to
do
this
honestly.
I
I
would
like
to
experiment
on
release
cadence
I
I
will
use
as
soon
as
as
we
get
this
release
out.
I
will
start,
let's
start
simple
three
release
per
year
like
kubernetes
and
see
if
we
can
basically
keep
up
with
our
promises
we
we
are.
We
are
experimenting,
I'm
confident
that
we
can
do
it,
but
but
yeah
we
have
to
have
more
people
rotating
on
release
duties
so.
A
I
think
that
that
this,
let
me
say,
release
cadence
needs
a
the
server
discussion,
probably
as
soon
as
a
result.
We
have
to
take
as
a
season
as
a
community.
What
is
the
next
release
planning?
We
do
a
time
boxes,
release
or
or
best
effort
releases
as
we
are
doing
today,
and
we
keep
a
decision.
We
try
to
stick
it
to
it.
A
A
So,
for
for
the
for
this
topic
ipam,
I
think
that
there
is
a
kind
of
agreement
in
best
course
will
be
getting
this
merged.
If
this
is
not
possible,
we
we
cut
an
early
tag,
which
is
a
good
compromise.
A
A
Okay
c
plus
one
thumbs
up.
Okay,
thank
you.
Thank
you,
everyone
for
the
nice
discussion.
I
have
also
the
the
next
point.
So
I've
opened
an
issue,
and
this
is
also
related
to.
How
do
we
manage
stuff
and
release
management?
So
I'm
proposing
a
change
on
how
do
we
perform
issue
triage
and
milestone
management?
A
Yes,
the
change
is
described
in
in
in
the
okay.
So
I
see
already
some
comment.
So
the
idea-
and
I'm
just
let
me
say,
raising
our
awareness.
I
will
take
a
look
at
the
comment,
so
the
idea
is
that
we
have
to
stop
to
assign
the
current
micelle
to
new
issues
as
a
senior
for
three-edged,
because
a
sign,
an
issue
to
a
milestone
today
really
does
not
means
that
it
will
be
implemented.
A
A
So
this
is
not,
let
me
say,
a
nice
senior
for
for
people
looking
at
our
background,
so
the
idea
is
that
stop
assigning
milestone
as
a
senior
for
triage
and
instead
start
using
triage
labels.
A
So
when
an
issue
gets
created,
it
gets
the
need,
a
triage
label
and
then
maintainers
take
a
look
and
remove
this
triage
and
other
new
labels.
Accordingly.
This
is
the
first
point.
Second
point
is
yeah:
they
are
the
triathlete
or
triage
knee
deformation,
etc,
etc.
It
is
it
is,
it
is
described.
A
A
To
keep
track
of
things
that
we
are
not
going
to
yeah,
we
consider
things
in
in
the
far
future.
To
be
honest,
I
think
that
my
first
my
milestone
next
from
for
me,
seems
like
triage
accepted,
but
no
milestone.
A
But
yes,
so
this
is
my
proposal.
If
you
have
opinions,
please
go
and
comment
on
these.
This
issue,
I
thank
you
cecile
and
for
it
is
his
first
round
of
feedbacks
opinions.