►
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
Hi,
this
is
the
kubernetes
sid
cluster
life
cycle
api
office
hours
of
what
is
today.
It
is
wednesday
april
20th
2022,
which
is
a
date
that
definitely
exists.
And
yes,
apparently
I
have
lots
of
sirens
here.
So
you
know
that's
exciting.
We
are
abiding
by
the
cncf
code
of
conduct,
we'd
like
participants
to
use
the
raise
hands
feature,
and
I
will
share
my
screen
with
the
agenda
so
that
it
will
be
in
the
meeting
sharing
that
now
and.
A
All
right
so
we're
going
to
take
a
look.
I
think
we
start
with
open
proposals.
Oh
wait!
First,
we
welcome
new
attendees.
Do
we
have
any
new
attendees
to
welcome
today?
A
So
I
see
one
flaw
with
me
screen
sharing
is
I'm
not
necessarily
sure
I
can
see
if
you
raise
your
hand
or
not?
So
if
you
want
to
please
go
ahead
and
just
unmute
and
let
us
know
if
you
are
a
new
attendee.
A
Okay.
So
let's
go
to
open
proposal
readouts.
Do
we
want
to
start
with,
looks
like
the
spot
instances
proposal
needs
review,
or
do
we
have
one?
We
want
to
start
with.
B
Hey
there's
so
many
of
them
we've
usually
just
been
waiting
for
people
to
raise
their
hands.
I
guess
so.
I
just
did
so.
As
I've
said.
For
the
last
few
weeks,
machine
pull
machines
continues
to
move
forward.
We've
gotten
really
good
feedback.
I
think
I've
addressed
most
of
it,
but
I
feel
like
we're
still
a
little
bit
slow
motion
and
as
fabrizio
suggested
last
week.
B
Maybe
it
would
be
worth
you
know,
having
a
short
meeting
and
working
over
the
remaining
feedback
and
seeing,
if
we're
really
at
lazy
consensus
time
yet
or
if
there's
more,
to
do
fabricio.
C
I
think
that
we
need
a
a
meeting.
At
least
there
is
something
up
here.
I
I
did
not
have
time
to
figure
it
out
in
detail.
So
for
me,
a
meeting
will
be
helpful,
and
this
week
we
had
a
meeting
for
the
iphone
proposal
and
it
really
helped
to
to
move
things
forward.
So
if
we
can
find
a
slot
whenever
you
are
comfortable,
I
do
my
best
to
join
great.
C
I
can
give
a
brief
update
on
the
ipam
proposal,
so
we
had.
I
I
saw
that
jacob
added
appointing
agenda-
I
don't
know
if
jacob
is
here
as
well
seems
not
so
I
am
okay.
Do
you
want
to
give
an
a
quick
update
on
the
discussion
that
we
had.
D
Yeah
sure
so
I
think
we've
mostly
clarified
a
few
things,
there's
also
a
quick
summary
by
fabrizio
and
slack
about
what
we've
discussed.
So
there
is
like
one
open.
Big
open
topic
was
moving
network
configuration
to
machine
level,
which
was
touched
in
the
feedback
for
the
proposal,
which,
in
my
opinion,
is
such
a
big
topic
that
it
probably
requires
a
separate
proposal
entirely.
We've
discussed
about
the
current
item
proposal
in
case
we
actually
want
to
move
configuration
to
machine
level
and
in
our
opinion
it
doesn't
really
interfere.
D
And
then
a
second
topic
that
was
discussed
a
little
bit
at
least
was
allocating
ip
blocks
or
ip
pools
automatically,
which
is
probably
mostly
interesting
with
cluster
class,
and
that's
something
I
think
that
can
be
done
in
another
iteration.
I've
added
some
or
one
point
in
the
proposal
regarding
that
yeah.
I
don't
think
there's
any
other
big
topics
open,
maybe
some
some
details
on
the
on
the
types
which
can
maybe
also
be
clarified
during
implementation.
Then
I
will
just
update
the
proposed
with
the
proper
types
once
they
are
finalized.
A
Okay,
we
have
a
few
hands.
I
had
a
quick
question
in
the
agenda.
It
says
we
have
lazy
consensus
until
question
mark,
so
if
we
had
any
more
specificity
about
dates
or
desired
dates
or
amount
of
time,
maybe
that
question
mark
could
be
filled
in
and
then
I
believe
jack
had
his
hand
up.
First.
E
Yeah
I'll
be
really
quick.
I
just
wanted
to
mention
that
I
added
my
name
and
jonathan
tong's
name
to
the
cluster
api
add-on
orchestration
proposal
list.
I
don't
want
to
suggest
that
help
wanted
is
still
not
the
case.
If
you
want
to
get
involved
in
that,
please
ping,
fabrizio
or
myself
or
jonathan
and
jonathan
has
made
really
good
progress
already
on
a
prototype,
so
expect
a
demo
in
the
next
few
weeks.
A
Awesome-
and
you
seen
you
raised
your
hand
as
well.
F
Yeah,
it
is
mainly
a
follow-up
on
the
iphone
proposal,
so
yeah,
I
think
in
general.
The
proposal
is
on
a
stage
that
is
where
it's
solving
like
real
problems
for
the
use
cases
that
it's
lists
and
from
the
meeting.
What
we
saw
is
that
it's
not
like
gonna
corner
us
or
block
us
in
case
we
want.
You
know
to
start
modeling
it
like
a
common
api
on
how
we
model
like
network
interfaces
for
machines,
so
yeah
in
general,
black
plus
one
for
this
proposal.
A
Okay,
great
and
I
know
jack
has
more
commentary
as
well
jack
is,
do
you
want
to
talk
more
about
this
topic,
or
do
we
have
an
additional
proposal
topic
to
move
to.
A
Okay,
no
worries
and
christian.
You
have
one
as
well.
A
D
I
wasn't
sure
how
long
how
long
it
should
take
the
idea
was.
C
I
propose
end
of
this
next
week
because
I
I
really
would
like
to
give
chance
to
pro
people
in
provider
to
take
a
last
look,
because
most
of
the
work
is
on
the
provider's
side.
A
G
Yeah,
maybe
I've
got
it
also
in
the
listener
gender
later
on.
So
maybe
we
just.
A
G
A
Okay,
it
looks
like
we've
got
yuvaraj
and
fabrizio
want
to
talk
about
default
version.
C
A
C
I
I
will
told
you
that
cannot
join
today,
so
we
we
are
still
using
in
cluster
bi
version
of
cert
manager.
That
is
now
out
of
support.
C
We
discovered
this
recently
we
are
using
153,
which
is
now
out
of
support,
so
I'm
proposing
we
have
already
a
pr
out
to
bump
third
manager
to
one
seven
two,
which
is
the
latest
in
in
the
seventh
release.
I'm.
I
think
that
we
should
keep
bringing
this
one
and
backboard,
and
then
eventually
we
can
pick
up
the
1.0
version
of
search
manager
that
has
been
related,
released.
C
A
C
So
cluster
api
does
not
have
a
tv,
let
me
say
dependencies
on
search
manager.
We
we
just
use
to
to
get
a
certificate
for
the
controller,
so
it
is
a
pretty
common
use
case.
We
have
automation
so
as
soon
as
we
backport
we
give
one
or
today
to
to
see
if
our
test
works-
and
I
don't
expect
problems
but
yeah,
I'm
asking
to
the
community.
H
Yeah,
hey
fabrizio
just
one
question
here
about
the
one
seven
version
I
know
we're
like
in
the
one
five
space
today.
What's
the
support
timeline
for
the
one
seven
version
like
how
long?
How
long
do
we
have
to
potentially
bring
in
one
seven
and
then
ultimately,
ultimately
think
about
moving
to
1.8
before
we
lose
like
lose
supportability
of
that
one
as
well.
C
I
I
have
to
check.
Let
me
see
the
fact
that
1.3
is
how
to
support
is
something
that
someone
reported.
I
have
to
check
if
there
is
a
table
or
ask
to
the
search
manager
community
but
yeah
that
that's
a
good
question.
I
will
report
it.
Oh
christian
is
passing
information
so.
A
A
I
Yeah,
there
are
some
comments
in
the
issue
in
the
cluster
api
issue,
about
how
one
seven
made
some
significant
changes
which
looks
like
it
requires
kubernetes
118,
because
it's
using
server
side
apply,
and
it's
also
dropping
some
apis.
There's
some
deprecated
api
versions
so
which
might
require
some
extra
upgrade
steps.
I
So
I'm
just
wondering
if
we
really
want
to
be
cherry
picking
something
that
potentially
would
you
know,
be
breaking
for
existing
clusters,
especially
if
this
is
like
a
very
aggressive
deprecation
like
how,
until
when
do
we
keep
you
know,
backboarding?
Are
we
gonna
do
the
same
thing
again
in
june?
Or,
what's
I
guess,
what's
our.
G
Yeah,
they
also
know
the
supported
versions
at
their
their
page.
So
maybe
that's
one
thing
to
look
at
if
you
want
to
cherry
pick
or
not,
yeah.
C
C
Migrate,
everything
to
the
to
the
new
version-
I'm
I
want
also
to
there
is
always
an
escape
patch,
because
a
user
can
override.
This
is
for
the
default
version
that
copy
instance
user
can
override
and
use
a
older,
newer
version.
C
And
this
put
us
in
a
kind
of
big
pressure,
so
we
have
to
figure
it
out.
A
Yeah,
at
the
same
time,
though,
considering
we
just
discussed
1.18,
I'm
just
sitting
here
thinking
kubernetes
itself
moves
pretty
quickly
too.
So
maybe
we
should
think
about
how
far
back
we
want
to
support
things
in
general
if
the
upstream
projects
are
upstream
but
like
if
the
projects
that
we're
consuming
don't
have
patches
and
support
for
something
anymore.
At
some
point,
we
might
have
to
just
say:
look
you
shouldn't
be
using
version
x.
A
E
Yes,
the
just
related
to
the
last
comment
about
the
moving
too
fast.
I'm
not
sure,
I'm
not
sure
if
the
problem
is
the
moving
too
fast
inversion.
So
much
as
the
rapid
breaking
changes
or
rapid
deprecate,
the
kubernetes
has
a
deprecation
schedule.
So
I
wonder
if
maybe
some
of
the
other
six
projects
aren't
following
the
schedule
or
the
recommendations
there.
That
might
be
something
to
follow
up
with
them
to
to
help
with
the
pain
around
getting
these
upgrades
in.
C
We
are
kind
of
a
requester
by
our
user
to
support
a
wide
range
of
kubernetes
release
and
cluster
api
in
some
somehow
is
absorbing
part
of
of
the
speed
of
the
ecosystem,
because
at
the
end
our
user
needs
this
decompression
support
to
to
follow
up
with
production
and
stuff
like
that.
So
I
think
that
is
important
for
copy
not
to
restrict
too
much
the
the
the
range
of
release
that
we
support.
C
So
our
we
have
our
policies
basically
say
that
we
do
this
at
the
best
effort
we
we
cannot
basically
solve
problem
of
the
other
project.
What
concerns
me
is
that
now
we
are
deploying
a
search
manager,
release
that
is
not
supported
anymore,
and
this
is
something
that
I
would
like
to
get
out
as
soon
as
possible.
I
Part
of
the
problem
is
that
we're
not
clear
on
our
own
support
policy
and
like
release
branches
that
we
support,
because
we
documented
something
that
seems
like
in
practice
we're
not
following
that,
because
we
we
did
document
that
we
were
gonna
support,
only
the
last
minor
release
of
each
api
version,
and
here
we're
talking
about
back
porting
to
1.0,
which
is
you
know
supposed
to
be
end
of
life
by
now.
I
But
if
we
do
stick
to
like
only
supporting
the
release
branches
that
are
like
currently
supported
by
cluster
api,
then
things
like
that,
like
you
know,
keeping
the
kubernetes
version
support
and
the
cert
manager
version
support,
and
all
of
that
fresh,
I
think,
would
be
a
little
easier
to
do
if
we're
like,
targeting
only
like
the
release
branches
that
we're
actively
maintaining
and
not
trying
to
like
keep
everything
that
was
ever.
You
know
released
to
users
up
to
date,
because
that
just
gets
like
very
painful.
I
think
to
maintain
over
time.
A
I
have
to
big
big
time
plus
one
to
that
cecile.
I
think
that
the
desire
to
keep
everything
forever
good
for
everyone
runs
right
up
against
the
actual
reality
of
the
infinite
matrix
of
complexity.
A
C
A
And
what's
cecile
said
about
the
broader?
What's
going
on
with
how
much
we're
going
to
support
forever?
Let's
make
sure
we're
actually
doing
what
we
said,
we're
going
to
do
and
not
trying
to
do
more,
because
then
people
expect
it
and
then
maybe
we'll
fall
down
and
not
able
not
be
able
to
produce
what
they
end
up
expecting
that
we
never
intended
to
cover.
Does
that
sound
like
it
covers
it.
C
No,
that
does
sound
good.
We
yeah.
I
I
brought
up
one
to
zero
because
I
don't
we,
we
kind
of
agreed
to
have
a
extra
release
patch.
I
don't
remember
the
if
we
already
did
or
not,
but
I
can
check
there
is
not
so
that's
fine
for
me.
Okay,.
A
All
right,
thank
you
very
important.
It
looks
like
a
dane.
We've
got
a
externally
managed
replica
account
to
talk
about.
E
Yes,
thank
you
bridget,
so
I
got
pretty
busy
and-
and
I
lost
the
ability
to
keep
working
on
this
for
a
couple
months
there.
So
I'm
trying
to
get
back
into
it
a
little
bit
my
time's
still
under
a
lot
of
pressure,
but
I
I've
seen
there's
several
comments
on
the
issue
and
several
people
are
interested
for
fabrizio
place.
Some
some
very
good
thoughts
in
in
there
about
some
interactions
with.
E
I
think
it
was
clustered
class
or
it
was
one
of
the
other
controllers
apologizing
I'm
mistaking
so
it
sounded,
like
maybe
things
were.
Consensus
was
maybe
drifting
towards
an
annotation
instead
of
a
spec
field
and
instead
of
putting
this
into
the
provider-
and
I
just
kind
of
wanted
to
bubble
that
up
to
this
group
and
see
if
we
can
get
some
consensus
on
exactly
where
to
configure
this
behavior.
E
A
A
E
So
the
the
configuration
the
field
needs
to
exist
somewhere,
it
wasn't
clear
to
me
the
benefits
of
annotation
versus
spec
field.
They
feel
pretty
much.
They
feel
very
similar
to
me,
except
spec,
is
a
little
bit
more,
has
a
stronger
contract
around
it.
But
so
you
know
if,
if
starting
in
an
annotation
makes
sense,
maybe
he
graduates
to
a
spec
field
later
I
don't
know,
but
you
know
I'm.
E
I
think
it
makes
sense
as
a
spec
field,
but
I'm
completely
okay,
putting
it
in
an
annotation.
Instead,
it's
just
a
matter
of
I
don't
know
if
there's
a
right
or
wrong
answer
here,
there's
just
a
lot
of
preferences,
so
it's
kind
of
a
difficult
one
to
drive
consensus
towards
there's
a
lot
of
different
opinions.
A
Yeah
yeah
fabrizio
you
have
a
thought.
C
C
So
for
the
specific
topic,
I
have
to
look
at
the
pr
and
make
up
my
mind
again.
I
don't
remember
why
we
go
to
the
conclusion
annotation
versus
field.
What
are
the
pros
and
cons,
but
what
I'm
kind
of
advocating
for
is
that
we
should,
whenever
there
are
things
that
require
discussion,
probably
or
we
do
this
in
an
issue
or
even
better
in
a
in
a
document
in
a
google
doc
where
we
discuss
product
codes.
C
This
will
help
people
to
understand
what
problem
we
are
solving
understand,
what
option
we
have
and
and
inventory
configure,
because
it
is
happening
this.
This
is
not
only
the.
C
This
is
not
the
first
case
that
that
we
have.
We
had
recently
another
case
for.
C
A
Thank
you,
fabrizio
and
cecile
put
in
the
chat,
and
I
think
maybe
we
should
get
this
on
the
recording
about,
maybe
that
this
is
a
question
that
has
come
up
around
this
kind
of
convention
cecile.
Do
you
want
to
elaborate
on
that.
I
Oh
yeah,
I
just
feel
like
the
annotation
versus
field.
Question
is
just
very
common.
Like
we've
had
it
many
many
times,
and
so
I
feel
like,
maybe,
instead
of
like
rehabbing
the
entire
discussion
each
time
it
comes
up,
we
could
have
some
sort
of
convention
that
we
agree
on
as
a
project
like
this
is
when
it's
appropriate
to
use
an
annotation
and
versus
using
a
field.
So
we
can
point
to
it
and
that
might
be
a
bit
easier,
so
we're
aligned
on
that.
A
Yeah
fabrizio
your
thoughts.
A
E
Dane
yeah,
I
totally
agree
on
the
proposal
process
for
most
things
that
I
think
that
just
a
clarification.
I
guess
this
is
an
experimental
resource,
so
my
understanding
was
this
was
kind
of
still
in
a
you
know.
We
were
still
kind
of
trying
to
define
the
interface
around
that
so
would
you
be
proposing
that
we
would
use
that
process
for
the
experimental
ones
as
well.
C
C
C
This
doc
can
be
linked
to
an
issue
or
whatever
could
be
a
better
way
to
get
an
agreement
before
writing
code
and
and
getting
lost
into
detail
or
stuff
like
that.
So
I
don't
think
that
we
always
need
a
full-fledged
proposal.
C
In
some
cases,
it
will
be
enough
something
more
than
an
issue
to
to
to
figure
it
out
option.
Some
company
called
these
one
page
errors,
something
similar
it
is.
It
is
just
that
it
is
kind
of
hard
to
figure
it
out
all
these
back
and
forth.
At
this
stage,.
C
C
And
get
to
an
agreement
before
writing
code
and
then
having
pr
stuck
for
months
and
which
is
not
nice
for
everyone,
so
yeah,
maybe
I
I
understand
the
cap
can
be
overwhelming,
but
that
there
could
be
some
middle
ground.
We
try
and
ride
between
writing
a
full-fledged
cap
and
the
writing
directory
code.
A
Right
right,
absolutely
dang
your
thoughts.
E
Sorry,
I
think
I
lost
my
train
of
thought
there,
but
the
yeah
I
can.
I
can
move
this
into.
Actually
I
don't
I
I
recall
so
this
is
related
actually
to
the
next
bullet
item
there
is.
Some
of
this
is
touched
on
in
the
managed,
kubernetes
and
cappy,
so
they're
they're
interconnected.
I
guess
is
what
I'm
saying,
because
the
core
crux
of
why
this
became
an
issue
in
the
first
place
was
trying
to
delegate
things
to
cloud
providers
which
is
related
to
the
managed
stuff.
E
So
maybe
we
can
incorporate
some
of
what
fabrizio's
asking
for
into
that
document.
A
Fabulous
well,
that
is
a
nice
segue
to
it,
looks
like
winnie
and
richard
want
to
talk
about
managed,
kubernetes
and
cappy.
J
Yeah
sure
I
can
call
this
so
yeah.
We
we've
added
a
new
draft
proposal
that
is
a
result
of
a
meeting
we
had
at
the
beginning
of.
I
think
it
was
march
now
where
we
discussed
how
to
represent,
managed
kubernetes
services
in
capi,
and
that
was
a
result
of
an
issue
in
kappa
and
the
way
that
we've
implemented
eks
and
cluster
classes
is
causing
a
problem.
J
So
in
this
proposal
we
sort
of
taken
the
approach
of
using
gcp
as
a
as
an
example
because
gke
isn't
currently
implemented
in
in
the
gcp
provider,
and
we've
we've
mainly
focused
on
the
distinction
between
the
infrastructure
and
the
control
plane
and
given
four
options
for
potential
options
as
a
way
to
implement
this
with
pros
and
cons
and
then
a
recommendation
towards
the
end.
J
So
we
are
just
adding
a
new
section
on
how
to
represent,
managed
node
groups
if,
if
the
the
cloud
service
offers
that
so
you
know,
gcp
node,
pause
or
eks
node
groups
are
good
examples
of
that,
and
really
this
I
guess
the
outcome
of
this
proposal
would
be
just.
I
guess
provider
implementation,
documentation,
updates
and
a
way
that
for
new
providers,
if
you
are
implementing
a
managed
kubernetes
service
in
kappa,
then
these
these
are
the
recommendations.
J
A
Awesome
thanks.
So,
if
folks.
K
Want
to
follow
the
link
and
winnie
you
have
thoughts,
oh
yeah,
and
I
I
just
want
to
mention
that,
so
this
proportion
is
a
little
bit
different,
that
there
are
already
existing
implementations.
K
We
actually
want
to
provide
guidance
for
future
implementations
and
we
want
to
find
a
solution
that
worked
with
cluster
class,
but
we
are
not
requiring
existing
implementation
to
converge
onto
a
solution
if
it
works
with
the
cluster
present.
There.
K
A
A
All
right
do
we
have
thoughts,
commentary,
questions.
A
J
Yeah,
that's
probably
the
best
next
step,
and
especially
especially
good
to
get
feedback
from
any
providers
that
have
a
managed
kubernetes
service.
A
A
Okay,
great,
thank
you
so
much.
This
is
very
exciting.
All
right
christian
lazy,
consensus
on
cluster
api
state
metrics,
there's
a
proposal.
G
Yeah,
as
already
mentioned
last
week,
there's
the
request
for
the
cluster
by
state
matrix
proposal.
They
are
also
already
looks
good
to
me
from
fabrizio
and
alberto
yeah.
As
already
mentioned
the
last
time.
It
will
be
a
component
in
the
experimental
directory.
It
will
not
harm
the
core
copy
controllers
and
opt
be
opt-in
component.
So
yeah
I
was
asking
if
there's
still
some
time
required
for
some
people
who
want
to
read
it
out
or
if
you
could
agree
on
some
basic
consensus
date.
C
I
Yeah,
just
I
noticed
there
are
like
five
reviewers
listed
in
the
proposal,
but
so
it
would
be
good
to
you
know,
maybe
get
those
reviewers
that
haven't
signed
off
on
it
to
you
know,
say
if
they
have
any
objections
for
moving
forward
and
if
not
then
yeah.
I
think
a
week
is
usually
good.
A
Okay.
Next
topic,
richard
you
want
to
talk
about
a
meeting
at
kubecon.
J
Yeah,
so
this
was
just
following
up
on
a.
I
think
there
was
a
thread
on
slack
and
I
think
it
was
mentioned
a
couple
weeks
ago
in
the
office
hours,
but
I
wasn't
aware
of
any
firm
arrangements
for
for
an
informal
meet
up
at
cubecon
eu
in
in
may.
So
I
was
wondering,
have
I
missed
it
or
or
do
we
need
to
arrange
a
doodle
to
to
try
and
arrange
a
time
for
everyone
that
suits
everyone
to
meet
up?
A
Contributor
summit
day
is
being
renowned
in
conference
right.
So
if
it's
an
unconference
style,
I
guess
you
could
just
go
there
and
propose
the
cluster
api
topic
for
the
own
conference,
and
then
people
could
join
for
that.
That's
one
fairly
lightweight
way
to
have
people
participate.
If
they're
going
to
the
contributor
summit.
J
A
A
Awesome:
okay,
you
seen
we
have
the
cluster
naming
consistency.
F
Yeah,
so
this
one
is
about
like
consistency
across
providers.
Today
we
have
like
some
providers,
like
cap
z,
restricting
dots
within
the
cluster
name,
where
on
others
like
we're,
allowing
like
dots
or
any
valid
kubernetes
name.
Basically
so
yeah
wondering
if
we
probably
want
to
restrict
or
relax
capzi,
but
I
think
overall,
we
should
align
like
the
expectations
with
our
end
users
across
providers.
F
So
I
wonder
if
anyone
has
any
thoughts
about
this,
at
least
in
cap
fee,
I've
seen
I've
seen
past
issues
youtube
cloud
in
it
and
like
using
dots
within
the
name
of
the
cluster.
F
F
So
yeah
like
if
you
have
any
specific
thoughts
on
this
I'll,
probably
like
open
an
issue
against
cappy
to
to
consolidate
the
discussions
there.
A
Okay,
we
can.
We
can
look
for
that
issue.
I
don't
know
if
anyone
has
anything
specific
they
want
to
point
to
about.
Do
we
have
any
prior
art
of
how
clusters
are
you
know
should
be
named,
or
is
that
something
that
we've
left
slightly
ambiguous?
A
F
So
this
is
mainly
because
nothing
was
part
of
the
contract.
Nothing
was
enforced
at
the
cluster
api
levels,
so
pretty
much
every
provider
is
doing.
I
guess
what
works
for
them.
J
Go
ahead,
richard
yeah,
but
this
will
extend
to
things
like
maximum
name,
because
I
know
you
know:
we've
run
into
issues
with
the
length
of
cluster
names
in
kappa
or
is
it
just
around?
The
use
of
you
know,
dots
and
dashes,
and
things
like
that.
F
Yeah-
and
this
is
like
it
like,
the
inconsistency
arises
when
you're
using
providers
one
next
to
the
other
so
like,
if
you're
using
two
providers
or
more
like
you,
have
to
start
thinking
about.
Oh,
is
this
provider
allowing
this,
or
is
this
provider
not
allowing
it
so
while
like
it
works
in
a
like
in
self-contained
fashion,
if
you
start
putting
a
provider
next
to
the
other,
you
start
seeing
like
some
of
these
inconsistencies.
F
I'll,
let
a
link
the
issue
on
like
on
on
on
the
agenda
and
then
we
can
take
it
from
there.
A
Awesome
yeah
turns
out
cash
invalidation
and
naming
things
are
the
hard
problems
who
knew
yeah.
Okay,
let's
see
it
looks
like
we
are
out
of
discussion
topics
and
we
just
have
room
for
a
few
provider
updates.
If
folks
want
to
do
a
few,
we
have
one
in
the
notes
now
jack.
Do
you
want
to
talk
a
little
bit
about
cabsie
provider
updates?
Meanwhile,
if
anyone
else
is
thinking
to
themselves,
oh,
I
want
to
add
one
go
ahead:
jack.
E
Yeah
sure,
thanks
real
briefly,
we
have
merged
in
capsi
a
change
that
sets
up
our
out
of
tree
cloud
provider,
tests
to
use
helm
as
the
delivery
mechanism
replacing
cluster
resource
set.
E
So
if
anybody
is
interested
in
that
sort
of
inside
baseball,
you
can
hit
us
up
on
slack
and
we
can
tell
you
how
we
did
that
and
our
documentation
has
also
been
updated.
So
folks,
who
are
coming
to
the
out
of
tree
cloud
provider,
documentation
example
will
be
instructed
to
use
helm
to
install
that,
on
top
of
their
cluster
post
cluster,
create.
A
A
I
think
we're
we're
out
of
topics.
We've
got
plenty
going
on
here
and
we
will
presumably
see
everyone
in
two
weeks.