►
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
Welcome
everyone
today
is
Wednesday
the
18th
of
January
2023,
and
this
is
the
cluster
API
Community
project.
Meeting
cluster
API
is
a
sub-project
of
the
kubernetes
sigs
and
as
such,
we
follow
their
Community
guidelines,
which
essentially
means
you
know.
Please
raise
your
hand
if
you'd
like
to
speak
and
I'll
call
on
you
and
please
treat
each
other
kindly
as
well.
We
try
to
we
try
to
maintain
decorum
here.
So
with
that
we'll
start
the
meeting
at
the
beginning
of
our
meetings.
A
We
always
take
some
time
to
welcome
new
members
of
the
community.
So
if
this
is
your
first
meeting
or
you
or
you
haven't
introduced
yourself
before,
please
feel
free
to
raise
your
hand
or
unmute
yourself
and
and
say
hi
to
the
community.
B
Yeah,
hello,
I
guess:
that's
me:
I'm
volodia,
wentland
I'm,
based
in
in
Scotland
in
UK
and
I
work
for
Cloud
hosting
and
Cloud
company
called
wife,
Corner
Germany
and
we're
using
cluster
API
to
stand
up
a
couple
of
clusters
and
are
simply
interested
as
to
what's
going
on
in
the
community
and
how
we
can
contribute.
If
we
run
into
issues.
A
Awesome
welcome
aboard
Amit
you're
up
next.
C
Yeah,
so
this
is
India.
I
am
working
in
spectrocloud
and
willing
to
contribute
here
in
the
copy.
D
D
I
work
in
AWS
eks
I
have
a
few
colleagues
in
the
in
the
meeting
and
work
on
the
local,
because
local
outposts,
where
we
use
copy
and
also
have
a
lot
of
interaction
with
eks
anywhere
and
yeah
I'm
Keen,
to
learn
a
bit
more
about
the
community
and
and
try
to
help
as
I
get
as
I'm
very
nice
and
with
it.
B
A
So
I
don't
see
any
other
hands
going
up
or
other
people
on
muting,
so
I'll
give
us
one
last
call
here:
alrighty
we're
gonna
move
on
to
the
next
part.
So
next
we
do
open
proposal.
Readouts
and
I.
Don't
remember
if
we
had
any
open
right
now.
No,
there
are
no
open
proposals.
So
we'll
keep
going
past
that
so
discussion
topics
looks
like
Killian.
You've
got
the
first
one
about
adding
variable
Discovery.
So.
E
Sorry
Mike
so
before
moving
into
topics,
I
just
received
some
requests
from
people
trying
to
assess
the
meeting
notes
and
just
a
reminder
that
if
you
want
to
assess
the
the
meeting
minutes,
no
you
have
to
subscribe
to
the
C
Class
ra
cycle
mailing
list.
I
I
put
the
the
link
in
the
chat.
A
Cool,
thank
you
for
breezio
yeah.
That's
that's
a
good
Public
Service
Announcement
and
if
anyone
is
having
trouble,
please
please
type
something
in
chat
and
and
hopefully
we
can.
We
can
help
get
you,
sir
solved
there.
A
So
with
that
I
guess
Killian.
Would
you
like
to
take
it
away.
F
Sure
could
you
open
this
link?
It's
okay,
just
so
some
context
around
this.
So
this
is
a
an
amendment
to
the
technology
education
hook,
proposal
that
we
merged
last
year.
F
So
basically,
what
this
does
with
cluster
classes,
we
introduced
inline,
patches
and
inline
variables
in
cluster
classes
that
allow
you
to
Define,
purchase
and
variables
to
make
changes
to
individual
clusters
based
on
different
conditions,
different
variables
set
in
the
cluster,
with
the
runtime
hook
or
with
runtime
SDK
and
the
topology
mutation
hook
proposal.
We
introduced
external
patches
so
allowed
you
to
write
your
patches
in
code.
We
have
a
go
SDK
for
it.
F
The
reconciliers
will
call
out
to
it
and
then
your
I
guess
your
patches
are
testable.
You
can
do
a
lot
more
in
external
batches,
because
the
inline
patches
are
limited
to
Json
patching.
So
this
is
an
evolution
of
that
proposal
which
allows
you
to
also
Define
your
variables
in
your
external
component.
That's
doing
the
patching,
so
it
allows
your
variables
and
patches
to
be
defined
in
a
single
place.
F
It
requires
a
call
to
discover
the
variables
so
from
the
poster
class
reconciler
out
to
the
external
performance
component,
but
it
still
allows
users
to
set
values
for
these
variables
in
their
cluster.
So
you
individually
are
able
to
mutate
your
clusters,
even
though
they
all
rely
on
the
same
cluster
class
based
on
external
patches
with
external
variables,
so
yeah.
This
is
an
amendment
to
the
proposal.
It's
across
two
dots
because
of
the
way
the
runtime,
SDK
and
apology
mutation
hook
ended
up.
F
I.
Think
there's
two
things
here
to
I
want
to
draw
attention
to
they're
kind
of
related.
One
is
that
currently
inline
variables
are
the
only
way
to
supply
variables
into
patches.
So
today,
inline
variables
are
used
in
external
patches.
F
The
idea
here
to
simplify
the
implementation
is
that
external
variables
would
be
linked
to
specific
external
patches
and
inline
variables
will
be
linked
to
inline
patches,
so
inline
variable
definitions
would
no
longer
link
to
external
definitions,
which
is
an
incompatibility
with
what
we
currently
have,
but
given
that
this
is
all
in
Alpha
I
think
it's
okay
and
the
other
thing,
then,
is
that
we're
going
to
name
space.
F
These
variable
definitions,
just
in
order
to
link
to
their
origin,
so
the
grief
clashes
in
terms
of
the
naming
but
I
think
yeah
I've
gone
into
a
lot
of
detail.
F
I
think
the
important
thing
is
that
I
would
really
like
to
get
Eyes
On
The
Proposal
from
the
community,
especially
from
people
who
kind
of
have
experience
using
either
internal
patches
or
our
runtime
SDK
and
yeah.
Hopefully
we
can
move
forward,
but
I'd
really
like
to
get
some
lies
to
to
review
this.
A
Cool
sounds
good.
Does
anybody
have
questions
or
comments
for
Killian
about
this.
E
Just
not
a
commented
first
of
all
that
thanks
and
shout
out
to
Kilian
to
taking
over
this
this
work
I
think
that
it
it
really,
it
really
makes
sense.
We
are
making
around
time
extension
self-contained.
This
will
at
the
end,
this
will
allows
people
to
ensure
quality
of
cluster
class
and
to
build
a
very
robust
testing
about
the
class.
E
So
you
can
test
and
prevent
or
loud
you
can
make
sure
that
any
change
does
not
have
impact
on
the
customer
on
the
user,
Etc
et
cetera,
so
it
it
I
think
that
is
really
a
one
missing
piece
of
the
puzzle.
I
really
encourage
everyone
taking
a
look
and
provide
feedback.
A
Cool
thank
you
and
yeah
I,
see
in
the
chat
as
well
Stefan's,
giving
a
little
shout
out
to
Killian
as
well
so
good.
You
know
some
nice,
some
nice
Kudos
here.
If,
if
other
folks
in
the
community
could
take
a
look
at
this
PR
and
you
know,
read
it
and
leave
comments.
Even
if
you
just
say
it
looks
okay,
that
would
be
really
helpful.
A
Okay,
next
topic:
okay,
I
I,
also
wanted
to
give
a
shout
out
to
Killian
and
Fabrizio
for
a
little
bit
of
different
work.
A
You
know
probably
I'm
guessing
a
lot
of
people
in
the
community
haven't
seen
this,
but
Fabrizio
and
Killian
have
put
up
a
bunch
of
patches
to
the
cube
Mark
provider
recently,
really
just
raising
the
bar
of
the
quality
of
the
code.
There
adding
more
tests,
you
know
just
making
it
work
a
little
better
with
our
our
current
Mainline
cluster
API
code.
So
you
know
I
just
want
to
say
thank
you
Killian
and
Fabrizio.
It's
been,
it's
been
great,
having
having
the
two
of
you
help
out
there.
E
I
I
just
want
to
also,
in
this
case,
add
a
little
bit
of
contest
so
why
we
are
doing
this
work.
Cuba
Market
provider
provides
a
lightweight
and
solution
for
testing
cluster
API
in
the
sense
that
it
consume
very
few
resources,
and
what
we
want
to
use
this
about
is
two
things.
First
of
all
is
test
to
set
up
an
end-to-end
test
for
Caster
API
with
the
autoscaler.
E
So
we
have
a
Upstream
signal
about
the
integration
of
cast
API
with
Delta
Scala,
which
is
are
things
that
many
users
are
relying
on
and
we
want
the
senior
about
it.
E
The
second
is
that,
which
is
a
more
longer
term
objective,
is
that,
as
of
today,
we
don't
have
a
good
signal
for
running
Caster
API
to
scale
and-
and
we
learned
in
the
past
that,
if
irancaster
API
in
scale
that
could
be
some
scanning
issue,
memory
leaks
stuff
like
that,
and
so
we
would
like
to
get
those
stuff
to
to
have
some
signal
about
running
cost
API
on
a
scale
on
two
Dimension
which
are
number
of
cluster
and
number
of
machines
that
we
have
to
handle.
E
And
we
see
in
the
kubemark
provider
a
good
opportunity
to
get
there.
I
think
that
both
goals
are
valuable
for
the
for
everyone
in
the
community.
So
yeah
I
encourage
everyone
that
is
interested
in
improving
the
quality
of
the
entire
project
and
with
regard
to
auto
screen
integration
and
and
performance
scale,
yeah
to
take
a
look
or
reach
out
about
this
work.
A
Yeah
and
thanks
for
adding
that
extra
context
for
brizio
I
think,
like
I,
think
the
scale
testing
is
really
important.
Work
and
and
My
Hope
too,
is
that
we
would
be
able
to
use
this
in
pre-submit
testing
on
the
cluster
Auto
scaler
as
well
and
I
know.
That's
that's
something
that
that
Community
is
also
curious
about.
So
this
I
think
it's
yeah,
it's
just
great
to
have
some
help
there
and,
like
you,
know,
yeah.
Thank
you
so
much.
G
Thanks
yeah,
it's
just
spicy
to
bring
attention
that
the
nfx
springmanship
program
has
been
has
opened
up
as
of
yesterday
for
projects
to
submit
proposals
for
for
mentorship
in
this
spring
period.
If
you
want
to
submit
a
proposal,
you
need
to
get
it
in
by
the
31st
of
January,
so
it
would
be
good
to
I,
am
get
I,
guess
providers
and
maybe
call
Copy
on
that
mentorship
program.
G
Cap
G
did
this
last
year
and
it
was
really
really
valuable.
So
we've
submitted
a
proposal
again
for
this
year
and
it's
just
I
guess
it's
great
on
two
parts
number
one
is
it's.
You
know
provided
in
the
mentorship
to
people
that
will
then
continue
on
to
contribute
to
the
project
and
that's
really
valuable
and
growing
the
you
know
the
next
generation
of
contributors
to
the
project,
but
also
as
the
person
in
the
the
mentoring.
It
really
really
helps.
You
grow
your
skills
as
well,
so
yeah.
G
A
Very
cool
and
yeah
these
mentorship
programs
are
an
awesome
way
to
connect
with.
Like
you
know,
new
people
coming
into
the
community
and
more
junior
members
and
like
Richard,
was
saying
it's
just
a
great
way
to
build
things
out.
A
So
if
anyone
out
there
any
other
providers
have
thoughts
about
about
doing
this,
I
guess
maybe
reach
out
to
Richard
online
or
check
out
some
of
the
materials
we
have
here,
and
you
got
about
what
another
week
and
a
half
to
to
get
these
things
in
another
10
days
or
so
so
very
cool
thanks
for
bringing
that
forward.
Richard
and
it
looks
like
it
looks
like
Kappa-
will
be
submitting
as
well
cool
okay.
So,
let's
go
on
to
the
provider
updates
at
this
point.
A
All
right,
Jonathan,
I'm,
gonna,
get
this
wrong,
but
k
c,
a
a
p
h
is
that
our
Apache
or
I
guess
this
is
new.
So
why
don't
you
take
it
away
and
tell
us
about
it?.
I
Technical
difficulties:
okay,
cool
cool,
Okay
cool,
so
yeah
I
got
the
official
repo,
finally
migrated.
So
there
it
is.
The
acronym
is
just
something:
I
came
up
with
and
it
kind
of
stuck
I'm
open
to
suggestions,
but
I,
just
I
just
figured
if
we
did
a
Capa
should
seem
like
a
cloud
provider,
so
I
wanted
to
differentiate
that
but
yeah.
So
the
repo
is
here
did
want
to
share
that
for
now
we're
probably
planning
on
using
this
meeting
to
discuss
stuff
related
to
the
add-on
provider.
I
So
that
way,
it's
easier
to
keep
everybody
in
sync
about
what's
going
on,
I
know
some
folks
think
about
getting
a
separate
meeting,
but
if
we
have
the
critical
mass
we
can
do
that
and
but
for
now
I'm
cool
with
meeting
here
and
besides
that
I'm
working
on
setting
up
a
lot
of
The
Proud
jobs.
So
we
can
get
some
PR
validation.
I
I
have
this
gigantic
PR
that
copies
like
almost
all
the
Cappy
scripts,
so
I'm
gonna
start
Trucking
through
that.
But
yeah
get
excited
the
add-on
thing
is
here:
it's
happening.
A
I
Yeah,
for
now
it's
just
I
just
want
to
share.
That's
here,
I'm
working
on
getting
everything
set
up,
so
it
can
function
like
a
normal
okay,
it's
repo,
but.
I
Any
questions
ping
me
on
slack
or
speak
up
in
this
meeting
as
well.
That's.
A
A
Cool.
Thank
you
so
much
Jonathan,
that's
cool!
All
right
jack
you're
up
next
with
some
cap,
C
updates.
H
Yeah
real
quick
call
out
1.7
actually
landed
last
week,
thanks
for
clicking
through
release
notes,
it's
a
pretty
big
release,
go
check
it
out
if
you're,
a
captain
user
and
then
I
wanted
to
add
a
note
about
AKs
graduation.
H
We
call
those
Azure
manage
cluster
Azure
managed
control
planes
in
captiland,
so
AKs
support
has
graduated
from
experimental
in
this
development
cycle,
so
that
will
ship
with
1.8.0
and
seven
weeks
time
or
thereabouts,
and
an
important
note
about
that
is
if
you
are
currently
shepherding
a
PR
and
the
Caps
EQ
you'll
notice,
a
new
AKs
test
which
yesterday
had
to
undergo
a
little
bit
of
surgery
to
get
it
working,
but
it's
now
working
so
apologies
to
anyone.
Who's
have
their
PR's
delayed
a
day
or
two,
but
that's
it.
A
Cool
yeah,
like
the
some
very
deep,
some
very
deep
release
notes,
so
anyone
who's
using
cap
C
definitely
go
read
through
those
and
see
what's
changed,
and
if
you
need
to
do
anything
there,
okay,
so
we'll
move
on
then
to
the
feature
group
updates
and
the
first
one
up
is
the
alternative.
Communications
patterns
feature
group
Richard.
Do
you
want
to
talk
about
this.
G
Yeah,
it's
just
to
follow
up
on
a
message
I
put
in
slack,
so
we're
trying
to
arrange
the
first
meeting
of
the
alternative
communication
patterns.
What
feature
group?
So
that's
just
looking
at
things
like
reverse
proxy
support,
so
yeah,
there's
doodle
there
there's
some
times
for
next
week,
please
vote
and
then
we'll
we'll
close
it
at
the
end
of
the
week
and
arrange
the
first
meeting
next
week,
but
yeah
just
to
follow
what
from
British
I
said
last
week.
It
will
follow
the
usual
feature
group
format.
A
G
And
I'll
put
the
link
in
here
as
well,
which
is
the
the
feature
group
PR,
but
essentially
it
is
to
to
look
at
alternatives
to
the
current
communication
pattern,
which
assumes
that
the
management
cluster
has
direct
connectivity
to
all
of
the
child
clusters
and
it
can
initiate
that
connection,
whereas
a
lot
of
companies
don't
allow
that
scenario.
G
Where
you
know
one
one
thing
can
connect
to
all
of
the
other
clusters
and
they
they
prefer
a
reverse
communication
patterns
where
the
child
cluster
initiates
the
connection
back
to
the
management
cluster,
and
then
the
operations
are
performed.
So
it's
it's
really
to
to
look
at
that
and
and
whether
that
is
actually
possible.
G
You
know
that
it's
really
quite
an
interesting
thread
on
slack
as
well,
where
people
are
currently
doing
this
using
the
cubeadm
provider
with
the
pre
and
post
kubernet
commands
to
to
deploy.
You
know,
reverse
proxy
and
and
connect
backwards.
So
yeah,
it's
been
interesting.
I'll
I'll.
Add
that
link
in
there
now
as
well
for
extra
context.
A
A
H
I
was
just
curious,
Richard
is,
are
disconnected
scenarios
and
iot,
and
that
kind
of
thing
part
of
the
the
user
story,
portfolio
for
what
you're
trying
to
solve
yeah.
G
So
that
is
one
of
the
use
cases,
so
there
are
a
couple
of
those
there
is
this
all
started
with
one
issue
which
was
I,
think
the
deer
raised
it
around
disjointed
networks
so
yeah.
That
is
one
of
the
use
cases.
H
Of
course
I
think
if,
if
you
didn't
make
that
connection
and
if
you're
interested
in
that
this
could
potentially
greatly
ease
those
scenarios
for
you.
So.
H
All
right,
thank
you,
members
taking
notes,
yeah
and
I
can
do
just
a
brief
call
out
for
managed
kubernetes
thanks
Mike.
We
we
met
this
morning
briefly
and
thanks
to
Richard
writing
content
to
the
to
our
draft
proposal,
doc.
So
I'm
going
to
try
to
make
these
discussions
super
lightweight
and
short
on
Wednesdays
and
prefer
async,
so
we'll
get
better
and
better
at
that.
So
just
a
call
out
if
you're
interested
managed
kubernetes
in
Cappy
debate
is
happening.
A
All
right
cool
yeah-
and
that
is
that's
also
another
interesting.
It's
cool
to
see
the
feature
groups
kind
of
growing
here
and
stuff,
because
these
are
some
interesting
efforts,
so,
if
you're
new
to
the
community
or
if
you're,
someone
who
likes
to
kind
of
look
at
emerging
technology
or
you
like
to
get
into
what's
on
the
bleeding
edge,
some
of
these
feature
groups
are
looking
at
stuff.
A
That's
just
really
cool,
so
yeah
I
I
would
recommend
anyone,
even
if
you're
just
curious
to
listen
and
sometimes
some
great
content
and
really
good
questions
going
back
and
forth
there.
Okay!
So
that's
pretty
much
the
end
of
our
meeting,
although
I
see
Stefan
is
typing
more
in
the
regular
discussion
topics,
so
yeah
Stefan.
Do
you
want
to
talk
about
bumping?
The
Go
version.
J
Typing
yeah
I'm
done.
Okay,
so
I
don't
know
who's
in
on
that
made
in
this
in
Oregon
domain.
I.
Think
it's
like
the
moment
could
be
this
one.
So
essentially,
Upstream
kubernetes
is
sort
of
supporting
releases
for
a
long
time,
and
the
latest
two
minorities
in
communities
which
are
still
in
supported
are
124
and
123,
and
for
the
reasoning
laid
out
in
this
document
basically
series
they
will
bump
the
goal
version
in
1.23
and
1.24,
which
is
something
which,
as
far
as
I
know,
wasn't
done
before.
J
People
are
interested.
Just
read
the
email,
but
I
would
just
want
to
already
give
like
a
small
information
already
we're
taking
a
closer
look
at
all
of
that
figure
out
yeah,
essentially
here
what
we
could
do,
what
the
impact
would
be
and
then
we'll
bring
it
up
again,
maybe
probably
next
week.
J
J
So
we
might
want
to
consider
bumping
cluster
API
1.2
I
wanted
to
Branch
two
using
gold
1.19
as
well,
but
I
guess
it
depends
on
a
few
factors
that
I
have
to
do
more
into
its
investigation
before
suggesting
anything.
A
A
You
know,
like
you
said,
like
124
and
123,
are
also
being
updated
to
go
1.19
so
yeah
a
little
bit
of
complication
just
to
coordinate
it
all.
There.
J
Yep
yeah
the
most
the
most
relevant
part
for
us.
Essentially,
it
would
be
relatively
easy
from
core
clusters
with
respective
to
just
bump
the
version,
and
that's
not
that
much
effort.
The
interesting
thing
is
what
will
happen
to
people
who
are
actually
consuming
our
go
code?
If
they
adopt
I,
don't
know
1.2.10
or
whatever
our
next
version
is,
will
they
have
to
bump
to
go
on
19
as
well?
Is
it
something
that
they
should
do,
because
if
they
don't
do
it
and
they
have
a
go
SDK
Series
in
it?
A
A
Okay,
so
I'll
check
the
agenda
one
more
time
to
make
sure
there's
no
more
late
minute
additions
and
I'm,
not
seeing
any
so.
J
E
Oh
and
let
me
say
just
to
adding
on
top
of
the
last
two
coins,
so
let
me
say
keeping
up
with
this
changing
happening
in
the
ecosystem.
It
is
work.
It
requires
a
research
work,
experimentation
as
well
as
as
being
reading
for
the
intake
of
the
outcome
of
the
working
groups,
like
the
one
that
Richard
discussed
so
I.
Take
this
opportunity
to
make
another
call
for
volunteers.
E
I
think
that
Caster
API
as
a
project
needs
some
more
reviewers
and
more
people
willing
to
step
in
and
and
yeah
and
work
on
the
then
go
up
the
ladder
up
to
maintainer
and
so
yeah
I
I
will
start
thinking
how
we
can
do
this.
Maybe,
given
that
we
are
at
the
beginning
of
the
year,
it
is
a
good
opportunity
to
go
through
the
current
list
of
reviewers
and
see
if
we
can
make
some
changes
based
on
the
on
the
on
the
last
contribution
or
based
on
people
that
are
willing
to
step
in.
E
So
if
you
are
interested
feel
free
to
reach
out,
there
is
a
lot
of
work
to
keep
the
light
on
on
this
project
and
to
make
it
progress
and
yeah.
We
are
looking
for
that
for
everyone.
A
Okay,
so
we'll
give
it
one
more
round
here,
any
last
minute
topics
things
people
would
like
to
add
going
in
three
two
one:
okay,
so
everyone
could
take
30
minutes
their
day
back.
Thank
you.
So
much
and
I
guess
have
a
good
have
a
good
week.