►
Description
Meeting notes https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit#
A
2022
and
before
starting
just
a
few
notes,
so
this
is
a
project
and
this
is
the
ncf
project.
So
please
be
nice
with
each
other.
We
about
to
do
the
cncf
control.
A
First
of
all,
let's
start
to
welcome
new
attendees.
So
if
there
is
someone
which
is
new
of
this
group
feel
free
to
speak
up,
I
stopped
for
a
moment.
A
Okay,
it
seems
that
there
is.
There
are
no
new
attendees
today,
so
let's
jump
quickly
to
open
proposal
result.
So
I
think
that
a
couple
of
proposals
merged
recently
so
machine
pool
machine.
If
I'm
the
right
is
already
merged
matt.
Could
you
confirm.
B
C
I
think
you
can
merge
it
now,
sir,
just
kept
it
open
before.
Let's
wait
another
day,
yes,
since
yesterday,
so.
A
A
A
Okay,
so
stefan,
if
I'm
right
this
one
merged
beginning
this
week-
oh
yes,
yep,
okay,
alberto!
Please
speak
up.
D
D
Yeah
sure
go
ahead,
I
can
talk
about
it.
A
A
Okay,
so
we
have
still
a
couple
of
proposals
open.
I
think
that
the
one.
A
As
far
as
I
know,
this
one
is
being
worked.
Jonathan
is,
please
speak,
give
an
update.
E
Yeah
yeah,
so
I've
been
working
on
this
with
jack
for
the
past
couple
weeks
and
we're
making
a
lot
of
progress
on
a
prototype.
We've
been
working
on
adding
a
method
to
maintain
an
inventory
of
the
helm,
charts
we've
installed
and
we're
gonna
make
some
changes
to
the
proposal
soon.
So
please
read
it
over
and
give
us
some
comments.
A
F
Yeah,
I
have
a
question,
maybe
for
you
too,
for
proposals
like
this,
which
do
not
involve
merging
code
into
cluster
api
but
are
still
like
part
of
the
capi
ecosystem.
Would
we
what
would
be
the
next
step
for
like
the
proposal
to
get
consensus
once
we
have
like
a
working
prototype?
Are
we
hoping
to
get
that
proposal
merged
as
a
pr
into
cappy,
or
would
that
be
like
in
its
own
repo?
Maybe
what's
the
what's
the
thinking
there.
A
That's
a
good
point.
I
I
think
that
in
in
this
phase
it
is
fine
to
have
a
pr
here
and
the
long
term
I
personally
given
that
is
a
project
ready
to
cup
api.
I
don't
mind
having
the
the
proposal
here,
but
eventually,
if
the
project,
let
me
say,
groans
buying
its
own
part,
we
can
reconsider
and
have
separate
set
of
proposals.
A
G
Yeah,
I
I
largely
agree
with
that.
I
the
way
that
I've
been
thinking
about
it
is
that
the
proposal
will
go
through
the
normal
flow,
so
eventually
it
would
be
agreed
upon
in
the
google
doc
and
then
be
matriculate
to
a
pr
in
cappy.
G
But
what
we
have
we're
sort
of
trying
to
prove
out
is
by
making
a
prototype
and
an
external
project.
In
parallel,
we
can
make
progress
and
have
the
proposal
not
block
actual
functional
progress
to
prove
out
some
of
our
hypotheses,
and
the
proposal
becomes
a
sort
of
acceptance
gate
for
integrating
that
prototype
in
the
into
actually
cappy.
A
In
my
opinion
makes
sense,
at
least
to
keep
the
old
option
open
at
this
stage.
Sooner
or
later
we
let
me
say
we
are.
We
are
adding
more
and
more
things
to
the
copyright
port,
I'm
fine
with
it,
because
we
always
had
the
vcd
of
butter
included,
but
yeah
the
record
is
growing
so
for
now
I
find
maybe
some
time
in
future.
We
have
to
discuss
about
balance
and
different
option,
but
I'm
good
for
now.
So,
okay,
if
we
can
move
on
so
we
have
merged
kubernetes.
A
I
know
this
proposal
is
is
waiting
for
answer.
I
will
try
to
give
a
look
now:
the
cube
economies.
Let's
conclude
that
and
I'm
back
to
normal.
A
Okay
level
think
oh,
this
proposal
needs
needs
some
love
from
the
community.
I
I
remember
someone
updated
a
couple
of
a
couple
of
weeks
ago
and
we
have
to
help
making
progress,
roberto.
D
Yeah
thanks
very
that's
the
one
that
I
was
talking
about
before
I
was
looking
at
it
today.
I
was
it's
been
hanging
there
for
a
while.
I
was
hoping
we
can
reap
idea
for
him
and
materialize.
It.
D
The
proposal
looks
okay
to
me
as
it
is
now.
I
think
stefan
dropped
some
comment
earlier,
but
mainly
about
making
sure
that
we
agree
on
the
scope
so
yeah.
I
was
wondering
how
how
we
could
proceed
here.
We
could
maybe
start
lazy
consensus,
or
do
you
guys
think
that
we
need
more
time
to
keep
discussing
there?
C
Yep,
so
for
me
it's
only
the
two
things
that
I
wrote
there.
We
got
some
feedback
from
vince,
so
I
would
say
something
like
for
pizza.
Maybe
we
can
also
take
a
look
at
least
at
those
two
points,
and
I
think
it's
just
we
just
have
to
make
a
decision
there.
I
mean
the
two
points,
in
my
opinion,
are
the
one
thing
is:
where
do
we
actually
put
the
labels
inside
the
map
you
already
have
and
just
treat
some
of
them
differently
or
have
a
separate
field.
C
I
think
we
don't
have
strong
objections.
I'm
not
sure
if
you
have
a
tendency
or
not-
and
the
other
thing
is
just
should
be
as
part
of
that
proposal
only
implemented
from
machines
of
machine
deployments,
or
should
we
try
to
implement
for
machine
learning
and
kcp?
I
think
that
would
be
better
because
then
we
don't
have
to
introduce
some
hack
into
the
machine
controller
to
differentiate
between
kcp
and
machine
learnings,
but
just
my
opinions,
I
think.
H
Thank
you.
Thank
you.
I
got
a
bunch
of
reviews
on
this
today.
My
only
comment
would
be
that
incorporate
incorporating
it
into
kcp.
Actually,
two
comments
would
so
incorporating
it
into
kcp
is
not
an
issue.
I
definitely
can
update
the
proposal
to
to
incorporate
that.
I
think
the
other
one
is
is
is
maybe
the
bigger
question
and
I
think
we
keep
going
back
and
forth
on
it.
H
That
is
introducing
a
new
field
versus
just
overloading,
or
you
know,
just
using
the
labels
as
they
are,
but
having
some
some
exception
in
terms
of
how
they're
handled
if
we
can
just
reach
some
consensus
on
that.
That
would
be
great.
I
think.
That's
the
only
real
sticking
point.
H
My
I
think
the
tendency
is
to
lean
towards
introducing
a
new
field,
and
I'm
that's
totally
fine
with
me.
I
just
want
to
make
sure
everybody
else
feels
the
same
way
on
that
topic.
Besides,
that,
I
think
you
know,
I
think
the
proposal
in
itself
is
we've
addressed
all
the
other
points.
A
So,
thank
you
for
this
note.
Personally,
I
I
yeah.
I
would
like
our
couple
of
days
to
take
a
look
and
if
it
is
okay
for
the
I
will
take
this
week
and
next
week
we
set
the
laser
consensus
for
for
everyone,
and
I
will
ask
also
beans
to
to
make
a
passage
possible.
F
A
F
Yeah,
I
think
that
sounds
fine,
I
think
in
general.
Maybe
we
should
have
a
bit
more
of
a
criteria
for
when
a
proposal
can
go
into
lazy
consensus.
It
feels
like
we
have
to
decide
it
every
time
maybe
like
once
it's
received
two
lgt
lgtms
from
reviewers,
then
we
can
move
it
forward
or
something
like
that
to
make
sure
proposals
get
enough
reviews,
but
also
aren't
blocked
eternally
waiting
for
reviews.
A
Yeah
that
that's
a
good
point,
let
me
say-
and
one
thing
that
I
want
to
do
now-
is
that
I
want
to
go
back
to
the
discussion
about
the
release
currents
and
possibly
when
we
talk
about
these
currents,
I
want
kicking
kick
off
to
other
discussion.
One
is
proposalized
cycle
if,
if
we
try
to
have
proposal
merge
at
the
beginning
of
the
of
each
cycle,
so
it's
it's
like
giving
reviewers
a
focused
time
to
look
at
the
proposal
and
and
then
we
have
a
implementation
window
and
so
on
and
so
forth.
A
Release
management
because
yeah,
probably
this
is
probably
better
to
talk
later,
when
maybe
stefan
give
us
an
update
on
124.
A
A
Okay,
so
let's
see
what
we
have
for
discussion
topic
so
psa,
I
don't
know
who
added,
but
I
can
read
it
so
cubicon
was
the
response
from
the
community
and
the
interest
for
the
class
api
project.
That
coopercon
was
amazing,
totally
unexpected
and
and
else
therapy
vince
made
a
great
recap
in
this
tweet.
Please
take
a
look.
There
are
interesting
talks.
A
We
made
the
main
stage
basically
every
day,
with
different
menu,
all
from
our
users
and
during
the
conference,
vince
ugarzi
basically
updated
the
the
slide
of
the
of
the
cluster
apid
dive
to
reflect
all
the
feedback,
and
I
think
that
yeah,
the
most
important
quote,
is
that
our
users
are
our
best
asset
and
I
like
this
sentence,
so
thank
you
for
our
users
and
yeah.
C
I
I
Does
it
work
now?
Maybe
yes,
perfect?
Okay,
just
some
glitch!
Apparently
yes,
so
I
I
started
coupon
in
our
spontaneous
meetup
with
another
attempt
at
removing
core
v1
object.
Reference
and
I've
now
created
a
new
issue
about
that,
because
the
other
one
first
of
all
has
a
lot
of
history
of
just
bought,
commands
and
so
on
and
now
also
got
renamed
to
it
to
a
different
topic.
I
So
I
would
like
to
try
again
and
I've
summarized
a
few
aspects
of
what
was
discussed
at
least
a
little
bit
at
kucon,
and
I've
made
proposals
for
the
types
we
could
potentially
add.
It's
quite
long,
maybe
even
long
enough
to
to
be
a
proper
proposal,
but
I
just
wrote
it
as
an
issue
for
now
we
can
convert
it.
I
Yes,
it's
probably
I
saw
I
don't
know
if
we
want
to
discuss
it
in
here.
It's
probably
too
long,
and
people
also
need
to
look
at
it
before
we
can
actually
discuss,
and
so
maybe
just
take
a
look,
the
most
important
thing
from
my
perspective,
because
that
was
the
blocking
thing
before
and
I
think
it's
still.
The
blocking
thing
is
that
this.
I
I
would
argue
that
it's
not
that
it's
that
it's
still
fine
to
do
it,
because
the
impact
is
not
that
great,
but
we
need
to
decide
how
we
want
to
handle
api
versioning,
because
if
you
strictly
follow
the
api
guidelines
of
kubernetes,
you
technically
aren't
allowed
at
least
the
way
I
interpret
them
to
to
change
anything
or
to
really
change
anything
in
better
api
versions.
So,
from
my
perspective,
if
you
strictly
follow
the
guidelines,
it
doesn't
even
make
sense
to
have
v1
better
too,
because
you
can't
have
any
braking
changes
between
beta
versions.
I
I
think
that's
the
most
important
thing
to
decide
and
my
my
idea
or
my
my
suggestion
would
be
to
not
strictly
follow
it,
but
to
still
allow
changes
in
beta
versions,
but
just
use
the
status
or
the
better
status
of
the
eye
to
of
the
api
to
to
specify
how
long
it
will
be
supported.
So
if
it's
a
better
api,
there's
longer
backwards
compatibility
than
if
it's
a
alpha
api
and
if
it's
a
v1,
then
we
basically
want
to
support
it
for
a
very
long
time.
I
From
my
point
of
view,
maybe
I'm
wrong,
and
or
maybe
the
opinion
about
the
avi
conventions
is
different
already
but
yeah
and
then
there's
another
decision
we
can
make
when
we
actually
decide
to
implement
this,
and
that
would
be
to
drop
the
version
field
on
all
references
because
we
technically
don't
need
them
for
most
cases.
I
There's
also
some
arguments
for
dropping
the
version
fields,
which
also
involves
git
ops,
for
example,
because
there
it's
difficult.
If,
if,
if
the
controller
or
if
some
convert
some
some
mutating
web
hook,
changes
fields
that
were
previously
set
through
githubs,
that
doesn't
really
work.
I
So
if,
since
that's
one
of
the
goals
in
the
future,
that
would
also
be
an
argument,
but
but
it's
all
written
in
there
and
there's
a
second
comment
about
that
version
problem.
The
best
thing
might
be
just
reading
this
and
then
providing
some
feedback.
C
Just
a
high
level
comment.
I
would
generally
like
to
see
this
happen.
It's
just
a
question
of
when
and
how,
but
essentially
what
we're
currently
using
is
object
reference
from
upstream,
which
has
a
bunch
of
fields
that
we're
not
using
and
there's
even
a
comment
there
that
this
type
shouldn't
be
used.
So
I
would
really
like
to
fix
this
before
we
go
to
e1
at
some
point
but
yeah.
I
A
A
I
I
We
want
object
reference
so
that
we
can
use
those
new
reference
types
with
new
apis
that
get
added,
because
I
mean
it's
then
even
more
inconsistent
within
the
api.
If
we
use
in
one
api,
both
more
specific
references
and
generic
object
reference
once,
but
if
we
plan
to
to
change
it
anyway,
then
it
doesn't
really
make
sense
to
add
the
old
reference
type
to
new
types.
I
So
I'm
mostly
coming
or
my
I
mostly
want
to
have
it
because
of
the
item:
implementation,
because
there
are
need
references,
and
I
don't
really
want
to
do-
object
references
because
it
just
makes
it
more
complicated
and
requires
than
validation
and
defaulting
workbooks
that
I
otherwise
would
need.
I
think,
at
least
in
some
cases,
so
alberto.
D
Yeah
thanks
yeah,
thanks
again
jacob
for
for
bringing
this
up.
I'm
curious,
if
is
this,
causing
any
any
trouble
for
you
as
a
as
an
api
user,
or
you
look
into
this
just
because
of
like
from
a
correctness
point
of
view.
I
I
For
me
personally,
it
doesn't
cause
any
trouble,
because
I
know
about
it,
but
there
is
a
lot
of
unused
field,
so
in
general
core
we
want
object.
Reference
is
not
really
intended
to
be
used
anymore,
there's
even
a
warning
as
a
comment.
That's
discouraged
to
use
it
because
there's
a
lot
of
fields
that
are
usually
not
used
by
implementations.
I
Because
of
some
sensible
security,
or
I
don't
know,
just
application
restrictions
and
if
you
just
remove
the
namespace
field,
it's
first
and
foremost,
more
clear
that
you
can't
choose
the
namespace
and
therefore
only
reference
things
in
the
same
namespace
and
at
the
same
time
you
can
remove
validation,
logic
and
defaulting
logic
that
you
don't
really
need,
and
I
think
when
I,
when
I
implemented
so,
I
just
tried
implementing
this
two
times
already.
I
I
think
once
for
alpha
three
and
then
once
for
us
four
and
I
think
the
first
time
I
even
found
one
instance
in
the
code
where
it
wasn't
properly
validated
the
namespace
or
the
validate
validation
for
the
namespace
was
missing
and
the
field
was
just
ignored.
So
you
could
even
set
it
to
a
different
namespace,
but
it
didn't
have
any
effect
and
that's
just
from
a
user
experience
not
that
ideal.
That's
also
one
of
the
reasons
that
they
discourage
using
the
object.
I
Of
manifests
in
your
git
repository
or
in
general,
the
version,
the
referenced
version
can
change
and,
in
general,
also
with
conversion
web
hooks.
It's
probably
difficult
if
you
set
it
through
a
validation
webhook,
where
you
need
to
automatically
l
through
a
conversion.
I
Webhook,
I'm
sorry
or
you
need
to
convert
the
version
of
the
reference
object
in
the
webhook
as
well,
and
it
makes
it
difficult
to
properly
upgrade
manifest.
So
if
you
have
two
manifests
in
git
that
both
belong
to
cluster
api,
for
example,
I
don't
know
cluster
and
machine
deployment
and
machine
deployment,
references
cluster
and
you
want
to
upgrade
the
manifests.
You
also
need
to
make
sure
to
upgrade
the
reference
version
or
the
version
in
the
reference,
and
you
need
to
do
it
at
the
same
time.
I
K
Sure
I
was
just
actually
it
just
reminded
me
of
of
a
pr
that
I
that
I
opened
a
little
while
back.
I
realized
that
the
namespace
wasn't
being
wasn't
being
defaulted
for
the
infra
and
bootstrap
references,
and
that
isn't
a
problem.
K
You
know
unless,
unless
you
start
to
actually
work
with,
you
know
if
you're
processing
those
those
resources
in
some
way,
you're
looking
at
the
the
references
and
if
the
name
space
is
missing,
you
know
sometimes
that
that
can
that
can
cause
a
they
can
cause
a
problem
that
you,
you
know
you
basically
have
to
say.
Okay,
like
the
database,
may
be
something
that
we
don't
actually
care
about
if
the
defaults,
not
there
etc,
but
at
the
end
of
that
conversation
on
the
pr
you
know
the
the
conclusion
was
hey.
K
J
So,
like
I
started
taking
a
look
at
the
issue
and
I
think,
like
in
general,
I
think
it's
desirable
to
move
away
from
object
reference.
I
think
even
jason
at
the
time
opened
a
long
time
issue
to
move
away
from
that.
The
only
thing
that
I
won't
want
to
be
cautious
about
is
probably
using
whatever
api
machinery
exposes
in
terms
of
types
and
apis,
and
the
second
thing
is
probably
like:
if
you
want
to
do
this
in
v1
beta
2
yeah.
J
As
long
as
we're
able
to
convert
the
existing
types
and
like
have
conversion
workbooks
that
work
through
those,
then
that
should
be
fine.
I
guess
this
makes
sense.
A
Okay,
thank
you
jacob
for
raising
the
point.
It
seems
that
it
is
really
interesting.
I
will
go
through
I'm.
I
understand
that
the
problem
that
you
we
have
a
additional
field
that
just
creates
annoyance
and
bad
ux.
I
will
investigate
a
little
better,
the
gitops
part
of
the
program,
but
yeah.
Thank
you
for
writing
this.
So,
let's
move
to
the
next
point.
Jonathan.
B
E
A
So
if
there
are
no
comments,
stefan.
C
Yep
just
added
a
link
yeah.
I
just
had
the
update
so
we're
currently
trying
to
use
communist
1.24
in
capti,
and
we
had
an
issue
there,
but
it's
very,
very
cappy
specific
in
my
opinion.
C
So
essentially
our
problem
is
that,
because
of
some
more
context,
so
qberium
started
defaulting
to
the
systemd
secret
driver
with
1.21.
I
think
plus
minus
one
version
kind
started
to
use
system
dc
drive
for
1.24.
C
The
result
is
essentially
that
in
cap
d
we
have
to
use
a
c
group
fs,
a
secret
driver
for
kubnit
is
1.23
or
lower,
and
we
have
to
use
system
d
for
1.24
or
higher.
So
essentially,
we
end
up
in
a
situation
where
we
have
to
use
a
specific
secret
driver
depending
on
the
coordinates
version.
C
We
did
a
few
iterations
and
we
have
pr
open
which
now
works.
So
essentially
we
got
it
to
work
to
deploy
1.24
clusters
to
be
able
to
upgrade
from
1.23
to
1.24.
C
C
C
If
you
go
through
capti,
you
have
to
set
the
cluster
to
polish
your
feature
flag,
and
then
you
can
use
use
the
only
template
that
we
have,
which
is
just
the
class
based
the
alternative
to
that,
would
be
to
provide
a
second
one
which
yeah,
which
is
not
using
cluster
class.
But
we
have
to
add
a
bunch
of
disclaimers
like
you
can't
use
that
template
with
1.23
or
below.
You
can't
use
the
template
for
upgrades,
or
you
can
have
to
modify
manual
stuff,
so
current
status.
C
We
would
only
provide
a
cluster
class
based
template.
I
think
now
would
be
a
good
time
for
objections
yeah,
but
tldr
is
essentially
we
have
it
working
and
when
the
pr
is
merged,
we
have
it
on
main
yeah.
Probably
just
summarize
everything
for
pizza,
I
think
those
are
the
main
points.
A
Yeah,
to
tell
the
artist
that
we
managed
to
get
end-to-end
working
and
for
company,
we
are
moving
to
a
single
template
deployed
which
is
based
on
cluster
class,
because
this
is
the
only
way
we
can
manage
this.
The
change
of
cigarette
drivers
during
the
upgrade
so
yeah.
C
I
forgot
two
important
parts:
one:
we
had
to
bump
the
kind
version
to
0.14,
because
only
strictly
only
0.13
and
upwards
supports
1.24
and
there's
a
one,
a
small
fix
in
0
14
for
arm
or
something
so
we
just
jumped
two
versions
and
the
other
thing
is
our
machine:
pull
coverage
doesn't
change.
So
while
we
changed
a
lot
of
our
tests
to
cluster
class
and
classic
class
technically
doesn't
support
machine
pools.
C
A
So
if
there
are
no
comment,
I
just
want
to
point
out
things
that
is
getting
relevant
for
the
project,
so
we
discussed
and
there
is
a
general
agreement
to
move
the
project
to
a
stable
risk
cadence
to
be
defined.
If
trail,
four,
I
will
try
to
get
discussion
moving,
but
and-
and
we
basically
discussed
that
for
each
release-
we
have
a
bunch
of
tasks
to
do
and
we
have
to
try
to
automate
these
tasks.
A
I
would
like
to
point
that
also
when
a
kubernetes
happens,
we
have
a
couple
of
activities
to
do
and
I
think
that
as
a
community
as
a
community,
we
we
should
find
a
better
solution
or
a
better
team
organization
in
order
to
make
this
happen
timely,
because
if
this
activity
basically
insists
on
only
on
the
same
always
in
the
same
person,
things
became
tricky.
A
So
the
idea
that
I
would
like
to
throw
on
the
table-
and
that
can
then-
and
that
came-
maybe
we
can
discuss
more
in
detail
later-
is
that
probably
cluster
api
needs
a
sort
of
a
release
team
that
is
responsible
both
of
bumping
cluster
api
itself
at
the
given
cadence,
but
also
for
making
cluster
pi
adopt
the
latest
kubernetes
release.
A
This
could
be
interesting
from
many
point
of
view,
because
it
will
ensure
our
currents
get
respected,
but
also
because
doing
this
kind
of
activities
gave
to
newcomers
a
great
overview
of
the
project,
so
yeah.
C
A
Okay,
if
there
are
no
comments,
we
can
move
to
provider
updates.
First
up
is
capazine
met.
B
Yeah
we
had
a
patch
release
last
week,
just
a
couple
of
fixes.
You
can
read
about
right
there
and
then
we-
I
don't
know
if
this
is
interest
to
the
community
in
general,
but
we
still
don't
have
reference
image
support
because
it
requires
writing
some
new
code
for
probably
uninteresting
reasons
we
had
to
change
around
the
way
things
are
stored
within
azure,
but
this
should
land
pretty
soon.
L
L
Yep,
nothing
major
just
working
towards
donating
the
code
repository
to
the
sig,
so
I'm
meeting
with
the
life
cycle
teams
office
hours
next
week.
I
think
to
start
that
process
and
figure
out
what
we
need
to
do
to
donate
the
repo.
A
M
I
yeah
I
put
a
comment
in
slack,
but
I
wanted
to
bring
it
up
here
too.
I
think
that
if
you
wanted
to
call
it
a
cap
oc
for
oracle
cloud
that
might
be
less
ambiguous,
I'm
very
worried
about
calling
something
oci
for
open
container
initiatives
related
reasons.
I
think
it
could
lead
people
to
thinking
that
you're
repo
is
related
to
something
that
it's
not
and
given
that
things
like
renzi
are
over
in
the
open
containers
org.
That
could
lead
to
a
lot
of
confusion.
A
L
A
Yeah
is
there
an
issue
for
the
donation
of
the
project
in
in
kubernetes,
community
or
or
kubernetes
or.
A
L
I
have
I
have
an
issue
open
in
kubernetes
for
the
donation.
A
A
Okay
season:
okay,
it
seems
that
we
are
at
the
end
of
our
agenda.
So
is
there
some
last-minute
topic
to
add.