►
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
Foreign
good
morning,
it's
Wednesday
it's
morning
for
me
in
Oregon,
USA,
Wednesday,
December
14th
it's
evening
for
some
other
folks
on
the
other
side
of
the
world
Welcome
to
our
new.
As
of
now
weekly
discussion
about
managed,
kubernetes
and
cluster
API,
cluster
API
is
a
sub-project
of
Sig
cluster
lifecycle.
We
abide
by
the
cncf
code
of
conduct,
so
we
look
forward
to
being
kind
to
one
another
and
let's
get
started,
so
this
should
be
fairly
quick.
A
Today,
at
least
as
far
as
my
side
is
concerned,
if
other
folks
want
to
talk
about
things
in
more
detail,
that's
great
as
well
I,
don't
see
any
new
attendees,
so
I
think
we
can
get
started
and
I've
added
one
agenda
item
just
to
update
folks
on
the
managed
kubernetes
cap,
Z
stories
Saga,
whatever
you
want
to
call
it
so
I'm,
going
to
paste
a
link
to
a
PR
that
we
are
tracking
or
graduation
from
experimental.
A
So
I
can't
recall
if
Kappa
or
in
that
case,
if
cap
G
or
the
Oracle
provider
has
done
what
what
Azure
has
done,
which
is
to
put
the
manage
cluster
features
behind
a
feature
flag
and
put
it
in
an
area
of
the
code
base.
That
is
classified
as
experimental,
and
we
have
sort
of
like
documented
that
as
such.
So
this
is
a
PR
that
that
I've
been
curating
and
that
lots
of
folks
been
commenting
on
over.
A
In
fact,
several
months
at
this
point,
which
sort
of
outlines
some
of
the
background
there
and
defines
criteria
for
graduating
this
from
experimental.
A
So
I
just
wanted
to
update
this
crew
on
that
status,
which
is
that
we
are
nearing
consensus
on
the
criteria
and
the
criteria
basically
will
allow
us
to
graduate
after
burning
down
a
few
final
tasks,
primarily
adding
some
additional
end-to-end
coverage,
and
we
anticipate
that
that
will
happen
in
January,
so
call
it
q1
2013..
A
So
I'm
not
sure
if
we're
following
any
kind
of
official
definition
of
experimental.
What
we
are
calling
experimental
simply
is
communicating
to
our
user
community
that
the
API
surface
area
may
change
with
any
given
release
at
any
any
time
so
by
graduating
from
experimental.
We
are
declaring
that
that
won't
be
the
case.
A
Does
anybody
have
any
questions
about
any
of
that
background
cool?
So
what
this
means
for
this
group
in
just
in
terms
of
azure's
role
in
this
whole
effort,
is
that
we
will,
as
we
discuss
in
this
in
this
feature
group,
how
we
can
move
a
more
common
cluster.
Api
idiomatic
managed
kubernetes
solution
to
to
reality
that
per
cap
Z.
A
This
would
be
a
V2
because
we're
essentially
going
to
ship
what
we
have
now,
which
is
input
for
the
problem,
we're
trying
to
solve
long
term,
as
this
is
V1
beta1
and
I
I.
Don't
think
that
we
would
introduce
a
breaking
change
as
a
kind
of
V1,
beta,
2
kind
of
thing,
or
even
a
V1
I
think
that
would
have
to
be
a
V2
if
I
understand
that
we
can
I
can
do
some
more
homework
in
terms
of
kubernetes
I.
A
Think
we'd
want
to
just
follow
the
conventions,
but
my
experience
suggests
that
that
would
be
a
V2.
So
I
was
curious
if
there's
any
concerns
from
the
larger
group
about
Affinity
between
a
Cappy
manage
kubernetes,
surface
area
and
then
like
the
provider.
Adoption
of
that
is
a
V2
going
to
be
super
weird.
A
Is
there
any
concern
that
capsi
is
going
to
be
committed
to
not
breaking
this?
You
know:
option
two
flavor
of
managed
kubernetes
in
our
provider
code
base
for
the
long
term.
Any
concerns
about
any
of
this,
or
does
this
sound
like
a
sort
of
overly
structured
official
way
of
what's
already
happening
across
other
providers,
so
I
just
wanted
to.
B
This
is
sort
of
what
we
did
with
chappa
I
guess,
but
in
a
more
formal
way
we
were
more
like
I
was
there's
a
number
of
people
using
it
with
feelings
of
a
certain
level
of
quality,
one
of
those
being
the
end-to-end
tests
being
there.
So
then,
we
we
graduated
and
moved
moved
out
of
experimental.
The
feature
flag
was
true
by
default.
B
From
that
point
onwards
as
well,
like
I,
said
he
caveat
for
us
in
relation
to
what
we're
talking
about
is,
then
it
just
becomes
harder
to
change
the
API.
Doesn't
it
in
the
future
which
is
relevant
to
these
discussions,
but
yeah.
If
you
follow
the
deprecation
policy,
that's
not
a
problem,
but
yeah
yeah,
exactly
what
we
did.
Yeah,
okay.
A
That
that's
exactly
what
we
plan
to
follow
and
basically
I.
You
know:
I've
done
this
in
kubernet,
Upstream
kubernetes,
with
various
features
and
I'm
just
going
to
copy
that
and
I
I
think
it's
totally
appropriate
to
do
so
so
default
feature
for
like
a
true
announce,
deprecation
and
number
of
releases
remove
feature
flag
altogether.
That
kind
of
thing
do
you,
are
you
on
V1,
beta
1?
Is
that
your
is
that
kappa's
sort
of
API
version?
A
B
Are
all
on
V1
beta2.
B
Made
some
breaking
changes
for
our
V2
release
that
we
we
needed
to
to
bump
the
API
version.
So
we
came.
We
had
the
conversions
and
stuff
like
that.
A
Cool,
so
do
we
have
any
idea
about.
A
So
I'm
going
to
type
this
down,
while
so
V1,
beta,
1
or
2,
or
V1
beta
and
I'll,
just
call
this
oops
it
can
we
do
something
like
this
to
B1
beta?
A
To
V2
that
that's
really
my
question
and
then
my
follow-up
question
would
be
if
we
answer
that
in
terms
of
what
we're
planning
to
propose.
So
if
this
feature
group
succeeds
in
producing
an
actual
concrete
proposal
within
cluster
API
for
folks,
like
Kappa
and
cap
Z,
to
adopt
that,
are
we
able
to
adopt
that
in
an
API
idiomatic
fashion
in
this
kind
of
way,
or
does
it
have
to
be
a
a
REV
to
the
say,
major
release
in
FP
of
B2.
B
Yeah
so
the
way
I
understand
it
from
when
we
looked
at
this
in
Kappa
was
we
can
do
that
as
part
of
the
first
one.
So
as
long
as
we're
incrementing
B1
B
to
one
two,
three,
four
five,
that
is
possible,
I,
think
when
we
looked
at
it
it
was
like.
Well,
you
have
to
keep
the
features
there
for
three
versions
or
or
nine
months
or
whatever
it
was
I
can't
remember
at
the
time.
So
that
would
be
then
like
V1,
beta
4
or
something
like
that.
I
can't.
A
C
Yeah
yeah,
what
what
Richard
said?
That's
what
I
didn't
yeah
yeah
I
think
we
just
like
need
to.
Oh,
no,
the
application
timeline
and
things
like
that.
A
But
we
do
have
to
support
Legacy
API
for
one
period
of
time.
I
will
do
that
because
we
need
to.
We
want
a
definition
of
that.
Okay,
John
I'm
curious
your
thoughts.
Does
this
sound?
Does
anything
sound
like
we
need
further
follow-up,
controversial
or
does?
This
is
what
you
would
expect
us
to
conclude
based
on
your
attorney's
working
in
Upstream
kubernetes?
A
This
all
seems
fairly
consistent
to
me,
with
my
understanding
of
things,
so
yeah
I
think
this
sounds
good
cool.
To
be
clear.
A
My
my
main
concern
with
this
isn't
that
there's
any
I'm,
not
particularly
afraid
of
going
from,
say,
V1
to
V2,
it's
more
I
would
anticipate
based
on
my
knowledge
of
the
current
cluster
API
API,
that
a
managed
kubernetes
set
of
crd
definitions
would
probably
ship
as
a
V1
in
cluster
API
and
so
I
was
I
was
concerned
that
if
we
have
something
like
V2
and
Kappa,
that
is
an
implementation
of
V1
and
capping
that
that
might
be
wrong.
A
There
might
be
some
something
wrong
there,
so
it
sounds
like
we
have
enough
flexibility
where,
if,
if
we
want
to
adhere
to
the
same
version
that
we
inherit
from
Cappy,
we
can
do
that,
even
if,
if
Cappy,
if
we
launch
this
with
Cappy
as
V2
I,
don't
know
how
we
would
do
that.
But
if,
for
whatever
reason,
there's
a
good
reason
to
do,
that
sounds
like
we
can
just
jump
to
V2
and
in
the
providers
as
well.
So
cool
I'll
do
some
homework
on
this,
and
this
will
be
part
of
the
proposal.
A
A
Items
and
then
I
just
wanted
to
I'll.
Add
one
more
quick
agenda
item
which
is:
are
we
ready
to
start.
A
So
I
I
would
vote
before
we
even
answer
this
question.
I
I
want
to
disclaim
this
by
saying,
I
think
we
should
do
this
in
January,
or
at
least
we
we
should.
We
should
plan
to
present
an
initial
draft
in
January,
but
do
do
folks
think
that
we
have
yeah.
Basically
it's
like
a
what
kind
of
working
agreement
do
we
want
to
have
going
forward?
A
Do
we
do
we
want
to
spend
a
few
of
these
meetings,
sort
of
deliberately
teasing
out
what
the
problem
statements
are,
ensuring
that
we
reach
out
to
the
right
number
of
people
as
a
precondition
to
actually
writing
things
down
on
paper,
or
do
we
want
to
do
just
start
writing
down
a
paper
and
looping
people
in
and
having
the
document
be
sort
of
equivalent
equivalent
discussion
medium
as
these
meetings
in
terms
of
moving
that
process
forward?
Does
anybody
have
any
thoughts.
A
Richard's,
bobbing
and
weaving
in
my
experience,
the
idiomatic
thing
in
kubernetes
is
the
second
one
most
proposals.
Just
you
know
if
there's
an
opportunity
where
folks
have
cycles-
and
you
know
insights,
then
things
just
start
going
on
paper
and
then
at
some
point
it's
shared
and
it's
not
super
super
formal.
There
aren't
like
formal
requirements
like
Thou
shalt,
not
begin
a
proposal
doc
until
you
have
blah
blah,
go
ahead.
Winnie.
C
Yeah
so
clarifying
questions
with
the
design
or
the
proposal
having
no
charity
in
Cafe
itself.
It
is
that
the
scope
of
this
proposure.
A
So
let
me
pull
up
the
pr
that
I
have
for
this
feature
group
and
the
scope
is
stated
here.
So
this
would
be
a
good
opportunity
to
sort
of
like
sanity,
check
the
scope
so
ensure
current
inconsistencies
and
manage
kubernetes
implementations
across
providers
are
well
documented,
agree
upon
a
path
board
to
achieve
provider,
consistency
for
managed,
kubernetes
and
cluster
API
so,
to
a
certain
extent
the
idea
of
writing
the
proposal
skips
ahead
of
of
the
part
where
we
talk
about.
A
A
Of
course,
we
have
to
accept
the
cluster
API
as
a
broader
community
might
not
agree
with
our
conclusions,
but
I
think
we
should
come
into
that
conversation
feeling
very
confident
and
strong,
and
so
maybe
we
need
more
pros
and
cons
just
about
like
what,
if
we
just
did
something
to
the
effect
that
Winnie
you
and
Richard
already
did,
and
let's
reevaluate
that
option
three
or
something
like
that,
maybe
that's
better
than
making
this
into
cluster
API,
especially
if
the
timelines
are
moved
off
like
maybe
that's,
maybe
we
would
prefer
that
kind
of
standardization.
A
The
immediate
con
that
comes
to
my
mind
that
we're
talking
we're
like
talking
about
this
is
just
that.
It's
sort
of
non-binding
at
that
point.
It's
just
a
document,
the
advantage
of
of
baking
the
standardization
into
the
API
itself,
as
it's
somewhat
contractual
like
the
provider
ecosystem,
can't
help
but
produce
an
implementation
that
meets
these
goals.
C
C
Yeah
custom,
yeah
I
think
we
should
just
like
start
writing.
Google
Talk
because
yeah,
for
example,
like
helping
the
API
in
cluster
API
serve
I
get
the
idea.
But
it's
it's
not
really
clear
to
me
so
I'm
not
like
we
started
writing
it.
It
doesn't
become
very
clear
so
yeah
that.
A
That's
my
totally
totally
understood.
Yes,
the
sooner
we
write
the
doc,
the
sooner
we
can
get
past
the
phase
where
Jack
France
is
waving
his
hands
in
meetings
and
talking
about
Pie
in
the
Sky
ideas,
go
ahead.
Richard.
B
Yeah
I
sort
of
agree
that
yeah,
if
we
start
writing
the
talk-
and
it
gives
us
something
focused
to
talk
about
in
the
meetings
that
happen
every
week
and
that
feeds
back
into
the
docket,
it's
a
nice
cycle
of
of
discussion,
yeah
and
I.
Also
like
the
idea
that
we
compare
multiple
options
again,
you
know:
can
we
can
we
do
it
with
the
current
saying?
Do
we
need
to
create
a
new
API
type?
B
Do
we
need
these
changes,
but
yeah
all
that
in
the
dot
would
be
fantastic
that
we
can
discuss
in
person.
Okay,.
A
Cool
that
works
for
me,
too
person
I.
Think
it's
a
personal
thing
personally.
The
discovery
process
happening
at
the
same
time
as
the
writing
stuff
down
is
that's
how
I
my
brain
works.
That's
how
I
know
what
I
think
about
things
but
glad
to
have
that
conversation.
I
know,
I
noticed
that
Nawaz
and
I
can
lolu
join,
welcome,
feel
free
to
raise
hands
and
I'll.
Give
you
the
floor.
If
you
want
to
comment
on
anything
we're
talking
about.
A
Okay,
cool
I'm
glad
we
talked
about
that
briefly.
I
think
I
would
suggest
that
we
meet
at
the
in
2023
at
this
point
and
in
I
mean
anything's
proposal
anything
subject
to
change.
If
there's
anything
interesting
that
comes
up,
let's
self
organize
in
a
practical
way,
we've
got
this
slot,
so
I
think
it's
fairly
durable.
At
this
point,
we've
got
the
Cappy
Zoom,
so
that's
great
I'd
be
happy
to
just
say
race
to
whoever
creates
the
Google
Doc
first,
you
know
you
win.
That
becomes
the
doc.
A
So
if
anybody
feels
motivated
and
has
Cycles
between
now-
and
you
know
three
or
four
weeks
from
now
and
there's
a
doc
that
materializes
then
that's
that's
amazing,
so
I
would
encourage
anyone
to
go
ahead
and
do
that
and
then,
of
course,
it's
going
to
become
a
it'll,
become
a
community
effort
in
that
document,
but
I
know
we're
all
busy,
and
this
is
all
like
bonus
gravy
effort,
so
Richard,
if
you
have
the
the
Cycles
to
do
it
or
or
John
or
anyone
in
here
that's
great.
B
I
yeah
another
just
another,
interesting
thing
that
came
up
today
when
I
was
working
on
the
country.
Gke
implementation
was
it's
just
a
stupid
annoyance
which
is
like
for
the
gke
implementation.
It's
a
bit
like.
We
have
a
capo,
we
didn't
want.
We
want
a
control,
plane
provider,
but
we
don't
want
it
to
be
installed
more
separately
as
a
control
plane
and
then
it's
you
know,
API
groups
and
things
like
this
and
structural
repos,
so
I
just
I.
Guess
we
never
got
to
that
guidance,
I!
B
Guess
from
for
provider
implementers,
it
was
more
about
just
API
yeah.
What
should
it
look
like,
but
not
actually
how
you
can
structure
things
as
well,
so
I'm
wondering
if
we
could
include
that
as
part
or
would
that
be
Erica
separate
thing
when
we
update
the
provider
Implement
data's
implementers
guide.
A
No
I
mean
I
that
doesn't
sound
like
you'll
be
out
of
school,
but
also
it
sounds
like
what
you're
saying
is
that,
in
addition
to
doing
the
more
sort
of
abstract
work
of
like
designing
an
API,
that's
going
to
go
into
cluster
API,
we
should
also
scope
some
sort
of
concrete
I
mean.
Maybe
we
can
almost
scope
a
can?
We
do
like
a
novel
provider
which
is
just
literally
a
a
reference
implementation.
A
I,
don't
know
if
we
can
do
that
easily
make
I,
don't
know
how
we
would
do
that
easily
without
a
particular
cloud,
and
then
it's
going
to
become,
even
even
when
we
standardize
it's
going
to
be
slightly
idiomatic
from
Amazon
to
Azure
to
Google,
but
I.
Think
that's
great
I.
Don't
think
that
that's
out
of
scope
at
all
I
mean
as
far
as
I'm
concerned.
We
have
we
get
to
choose
when
we
stop
calling
ourselves
a
feature
group.