►
Description
Meeting notes https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit
A
All
right
welcome.
Everyone
today
is
wednesday,
the
13th
of
july
2022-
and
this
is
the
cluster
api
community
meeting
cluster
api
is
a
subproject
of
the
kubernetes
cluster
sig
cluster
life
cycle
and
as
such,
we
are
following
the
kubernetes
sig's
conduct
policy,
which,
basically
is
you
know,
treat
everyone
as
you
would
expect
to
be
treated.
Hopefully
that's
kindly,
and
please
raise
your
hand
if
you'd
like
to
contribute
to
the
conversation.
A
B
Sure
I'll
say:
hi
real,
quick,
I'm
mike
teuzeron,
I'm
with
adobe
we're
doing
a
poc
right
now
of
cappy
and
cap
z
for
running
aks
clusters,
we're
currently
running
on
azure
with
just
plain
vms
and
we're
looking
to
migrate,
our
vms
to
aks
and
we're
hoping
to
be
able
to
use
cappy
and
cap
z
to
to
do
that.
So
pretty
major
architectural
shift
for
us
and
we're
really
excited
about
it.
So
I'm
gonna
start
attending
these
in
the
cap.
A
C
Yeah
I
wanted
to
yeah
comment
on
the
crs
crs
reconcile
mode,
the
last
one
there
I
know
we've
talked
about
this
multiple
times
from
different
angles.
So
now
we
have
it
in
a
pr,
I'm
just
looking
for
feedback
fabulous
has
been
helping.
So
thanks
for
that,
I'm
looking
for
feedback
either
on
favor
of
moving
forward
with
these
or
against,
and
then
just
waiting
for
the
add-ons
project.
You
know
that
we're
working
on
that
is
clearly
the
long-term
solution.
D
E
C
Yeah
great
question:
my
motivation
is
a
quick
solution
that
we
can
implement.
You
know
in
a
few
days
or
a
week
until
the
long
term
solution,
which
is
the
out
of
proposals
that
jonathan
was
mentioning.
So
I
I
do
for
me
believe
that
that
proposal
should
be
the
long
term,
but
this
is
more
a
short-term
solution
until
that's
right.
A
A
All
right,
then,
let's
move
along
to
the
discussion
topics
and
it
looks
like
stefan-
is
up
first
with
a
pr
about
the
cluster
cash
tracker.
Take
it
away.
Stefan.
F
Yep,
so,
okay,
some
some
context
today
when
one
of
our
controllers
communicates
with
clusters,
it
creates
a
client
with
the
so-called
cluster
cache
tracker.
A
cluster
cache
tracker
usually
just
reads
a
cubeconfig
secret
in
a
management
cluster
and
then
creates
a
control,
runtime
client
from
that.
What
this
pr
essentially
does.
Is
it
optimizes
that
for
the
management
cluster?
So
when
the
management
cluster
wants
to
manage
itself
as
a
workload
cluster,
it
doesn't
really
have
to
go
through
the
server
which
is
in
the
cube
config.
F
So
it
doesn't
really
have
to
communicate
with
the
api
server
with
the
dope
balancer
in
front
of
that
et
cetera,
et
cetera.
It
can
just
communicate
in
with
the
in-cluster
config,
with
the
yeah
with
the
local
api.
So
basically,
and
this
pr
changes
that
essentially
so
it
optimizes
that
when
the
cluster
cache
tracker
or
when
a
controller
wants
to
actually
talk
just
through
the
current
cluster,
then
just
uses
the
local
kubernetes
default.
F
So,
as
you
see,
instead
of
going
through
the
regular
apis
or
endpoint,
we
had
one
issue
in
cap
c.
I
think
if
you
have
a
capsiz,
self-hosted,
self-hosted
cluster
and
then
there's
some
hairpin
hairpinning
issue
when
the
controller
runs
on
control,
plane
notes
that
it
sometimes
can
talk
to
the
external
api
server,
not
sure
if
I
repeat
that
correctly
but
there's
an
issue
for
it.
So
essentially
we're
looking
for
feedback,
and
it
would
be
great
if
someone
can
test
that
and
some
in
something
which
is
not
just
kept
d.
F
Ideally
in
cap
c,
we
don't
want
to
put
it
into
1.2.0,
but
we
were
thinking
about
putting
it
into
the
next
patch
releases
for
1.2
and
1.1.
Of
course,
only
if
we
get
it
verified
correctly
and
it's
fine
yep,
that's
basically
everything
in
the
linked
issues.
If
you
have
more
questions,
just
ask
this
or
something.
A
Okay
cool,
so
it
sounds
like
looking
for
a
little
bit
of
feedback
on
this
one
and
especially
if
someone
could
test
it
with
capzi.
Those
are
appreciated
comments.
Does
anyone
have
questions
about
this.
A
F
G
Yeah,
okay,
so
I
think
some
of
you
know
the
problem.
So
the
problem
is,
if
you
use
cluster
class-
and
you
have
a
list
in
in
the
in
the
spec
when
the
list
is
reconciled,
it
actually
overrides
the
changes
right.
So
imagine
so
in
aws
cluster
there
are
subnets
right.
G
G
But
then,
when
the
cluster
topology
reconciler
reconciles
it,
it
actually
overrides
the
changes
in
kappa,
so
the
id
field
is
removed
right.
So
that's
a
and
the
same.
Similar
thing
is
happening
in
clustering
for
oca,
which
actually
I'm
working
on
so.
G
We
have
a
couple
of
solutions.
We
can
ask
customers
to
always
define
a
unique.
You
know
this
id
in
the
unique
you
know
key
in
the
list.
For
example
in
oci
you,
you
can
define
a
name
for
the
subnet
in
aws.
G
There
is
no
name
you
can
just
use
id
and
in
cap
z
also,
you
can
define
a
name
which
is
unique
right,
but
there
are
cases
where,
in
like
in
case
of
cluster
api
provider,
oci
there
are
cases
where
you
can
define
only
a
name
and
the
id
will
be
generated
or
you
can
specify
id
right.
So
it's
like
you
know.
We
are
really
not
sure
what
is
if
we
get
get
a
uniform
solution
which
will
which
will
work
across
all
the
cloud
providers
right.
A
Okay,
I
am
not
super
familiar
with
this
part
of
the
cluster
class
stuff,
but
is
there
anyone
here
who
would
like
to
make
a
comment
on
this
or
maybe
has
a
little
more
information.
G
Yeah
I
mean
the
kaapa
team
actually
tried
to
have
a
workaround
and
we
couldn't
work
on.
So
we
have
one
solution
which,
if
community
agrees,
we
can
go
ahead
with
that.
I
mean,
of
course,
but
yeah.
G
The
the
pr
is
actually
specific
in
oca
the
cluster
be
provided
for
oca
right.
So
in
you
know,
the
solution
is
that,
okay,
if
you
can
just
open
that
aws
thing,
aws
page
right,
if
you
have
a
subnet
right,
if
and
if
you
are
defining
it
in
cluster
class,
you
need
to
give
a
name
in
case
of
oci.
You
need
to
give
a
name
which
is
unique
right
in
case
of
cap
z.
Also,
it
is
unique,
so
name
is
unique
right.
G
So
if
you
are
defining
a
subnet
inside
a
cluster
class,
you
need
to
give
a
unique
id
for
it
or
you
need
unique
key
for
it
and
in
case
of
both
cabsie
and
capo
ci,
it's
a
name
right.
So
if
you
give
the
name,
that's
fine,
but
if
you
want
to
use
an
external
subnet
in
which
only
id
is
present,
you
can
you
cannot
define
it
in
the
cluster
class
as
a
you
know
this
as
a
topology.
What
you
have
to
give
is
you
have
to
provide
it
as
a
variable
from
outside.
G
You
understand
right,
so
that
then
the
topology
reconcile
will
not
reconcile
it
because
it's
it's.
It's
only
a
variable,
it's
just
you
know.
So
if
you
want
to
use
an
external
architect
external,
you
know
infrastructure
where,
if
for
in
this
case
some
id
or
if
you
you
just
pass
it
as
a
variable
and
it
will
not
set
it
as
a
topology
basically,
so
these
are
the
two
flavors
that
customers
can
use.
A
G
Is
a
separate
there
is
a
separate
ticket
in
kappa
for
this.
Let
me
see
once
again:
it's
still
in
that
thread
just
give
me
one.
Second,.
A
I
see
fabrizio
has
his
hand
up
while
we're
looking
for
the
link
here.
Do
you
want
to
go
ahead
fabrizio.
G
Yeah,
I'm
finished,
I'm
just
pinging
you,
the
ticket.
G
It's
three
five
to
eight
okay,
clustered
product
right
near
just
not.
H
Change
cluster
now
basically
use
what
cluster
api
offers.
So
we
are,
we
align
to
basically
the
what
is
the
kubernetes
solution
for
handling
two
controllers
or
a
set
of
different
people
or
things
altering
the
same
kubernetes
object.
So
at
this
point
we
basically
removed
all
the
custom
things
that
there
was
in
the
previous
release.
So
point
number
one
point
number
two:
is
that.
H
The
rule
from
kubernetes-
let
me
say,
server-side
apply,
are
quite
simple.
If
you
want
that
list
is
called
red.
Basically,
you
need
a
are
you
a
unique
identifier
that
could
be
composed
by
a
single
field
or
by
a
set
of
fields.
H
Say
that
the
the
problem
is
complex,
I
did
not
have
time
to
look
at
the
thread
about
oci,
because
yeah,
looking
things
in
in
slack
is
is
not
easy.
H
I
discussed
this
with
winnie
and
justine
a
couple
of
times
ago
and
it
seemed
and
the
solution
proposes
the
same
other
way
now
to
catch
up
with
we
need
again.
What
I'm
advocating
for
is
is
that,
of
course,
I'm
happy
to
help
to
jump
in
in
some
zoom
discussion
to
try
to
solve
together
this
problem,
I'm
advocating
for
a
solution
that
that
we
try
to
apply
consistency
across
providers,
so
we
make
the
life
of
our
user
a
little
bit
easier,
so
yeah.
G
Yeah,
I
completely
agree.
The
only
concern
is
I
mean
the
the
way
network
is
defined.
The
cloud
providers
are
different
like
for
example,
cap
cap
azure.
They
don't
have
an
id
concept,
they
just
have
a
need,
a
name
is
unique,
oca
has
both
id
and
name.
The
way
network
is
defined
in
cap,
kappa
is
there
is
there
is
no
name,
there
is
only
idp,
so
there
is
a
bit
of
you
know.
H
G
H
I
I
understand
at
the
same
time,
it's
kind
of
hard
to
follow.
We
have
to
find
a
way
which
is
a
better
way
which
is
not
as
like
a
trade.
It
could
be
a
spreadsheet.
It
could
be
a
document
to
to
surface
a
compare
difference,
because
otherwise
I
I
really
struggled
to
follow
the
problem
of
the
of
the
nuances.
We
have
basically
to
formulate
the
problem
to
enrill
it
together
to
find
the
solution.
G
Yeah,
I
mean
the
problem:
actually,
it's
not
just
topology
consider
the
id
problem,
the
id
solution,
which
was
discussed
in
kappa
right
it.
It
fails
in
the
case
where
an
user
applies
updates
across
the
class.
So
that
is
the
main
concern.
It's
like
the
both
ways.
It's
the
solution
is
not
working
both
ways.
A
H
A
With
the
community
that
kind
of
describes
what
the
problem
is
and
and
kind
of
spells
out
the
the
details,
and
then
I
think,
as
a
group,
we
could
probably
look
at
it
and
start
to
think
about.
Is
there
a
solution
that
would
apply
to
every
provider
because
it
sounds
like
some
of
the
details?
Right
now
are
slightly
confusing
yeah
sure
I
can
do
that,
awesome.
That
would
be
great
and
then
and
then
you
know
bring
the
doc
back.
A
You
know
when
you're
ready
and
I
guess
we
can
start
to
look
at
it
more
asynchronously
and
maybe
come
up
with
some
ideas.
You
know
see
if
there's
a
way
to
to
have
an
idea
that
could
be
like
it
could
work
for
all
the
providers.
I
it
sounds
like
from
what
you're
saying
each
provider
has
slightly
different
details
about
the
way
the
subnets
are
defined,
so
we
might.
A
Okay,
cool
awesome.
Thank
you.
So
much
does
anyone
else.
Have
any
comments
or
questions
about
this
topic.
A
All
right,
I'm
not
seeing
any
hands
go
up,
so
it
looks
like
the
next
topic
is
mine.
I've
been
looking
at
doing
another
release
of
cap
k,
the
kubernetes
client
and,
unfortunately,
I've
been
having
some
trouble
getting
getting
pick
up
on
it.
A
We
did
add
some
more
reviewers
to
the
project,
but
it's
been
about
a
month
now
I've
been
trying
to
get
I've
been
trying
to
get
this
pr
merged,
which
kind
of
makes
it
so
that
you
can
use
cap
k
the
way
it's
described.
You
know
the
way
the
other
clients
are
used.
A
Essentially,
you
know
being
able
to
run
just
the
cluster
init
commands
to
do
it,
and
then
I've
also
got
an
issue
opened
right
now
to
get
a
4.0
release,
because
we
added
a
big
feature
and
we've
also
got
some
fixes
up
for
the
instructions,
so
I'm
kind
of
reaching
out
to
the
community
here,
because
I've
been
having
trouble
getting
contact
with
the
other
kubemark
maintainers,
and
I
just
wondered
if
anyone
here
had
maybe
a
suggestion
or
maybe
some
ideas
on
on
how
we
could
kind
of
push
this
forward.
A
Has
anyone
has
anyone
run
into
this
before,
with
kind
of
like
some
of
the
smaller
providers,
where
we
don't
necessarily
like
have
enough
people
to
review
the
the
pr's
like?
Have
we
ever?
Would
it
be?
Okay?
To
you
know
I
mean
I,
I
hate
to
switch
the
proud
config
to
allow
one
person
to
approve
things,
but
you
know
unless
there
are
people
here
who
would
like
to
work
on
kubemark,
I'm
not
sure
how
how
we
go
forward
at
this
point.
I
A
The
next
topic
is
jonathan,
with
a
link
to
an
open
proposal
for
add-on
orchestration.
You
want
to
take
it
away.
Jonathan.
D
A
Okay,
so
fabrizio
you've
got
a
quick
update
on
release.
1.2.0.
H
Is
a
a
for
all
regards
me,
stefan
and,
and
and
and
the
other
critics
working
on
this
release.
We
are
really
testing
testing
testing
doing
as
much
test
as
you
can
refine
any
liter
of
refinement
in
in
the
dogs,
but
basically
we
consider
there.
It
is
what
we
have
for
now.
We
don't
have
maybe
that's
a
problem,
so
we
still
looking
as
a
target
date
for
for
the
release
next
monday
and
yeah.
That's
all
so.
If
someone
has
feedback
concern,
please
reach
out.
A
I
Yeah,
just
a
real
quick
announcement
about
1.4.0,
I
was
reviewing
the
release
page
to
look
for
one
or
two
interesting
things
to
announce
and
there's
actually
just
a
lot
of
great
things
in
this
release,
so
I
won't
just
read
through
them
all,
but
there
they
are.
Thank
you
mike.
So
thanks
to
cecile
for
doing
the
grunt
work
on
this
and
for
all
of
the
contributors.
There's
a
lot
of
people
on
that
page
right
there.
So
yeah,
1.4.0.
A
Awesome,
thank
you
and
thank
you
to
all
the
contributors
yeah.
It
looks
like
you
really
packed
a
lot
into
the
1.4.0
release.
There.
A
Alrighty,
well,
that
is
the
end
of
our
planned
schedule
here.
Does
anyone
have
any
ad
hoc
topics
or
anything
they'd
like
to
say
before
we
go
any
questions
comments?
People
need
any
help
or
anything.
A
All
right,
I'm
not
seeing
any
hands,
go
up
so
in
three
two
one,
all
right.
That's
the
end
of
the
meeting
for
this
week,
thanks
everyone
for
coming
out-
and
I
guess
we'll
see
you
next
week.