►
Description
A Kubernetes community meeting about the Azure provider for Cluster API. Cluster API brings familiar, declarative APIs to Kubernetes cluster creation, configuration, and management.
A
All
righty
welcome
everybody.
It
is
april
18th,
2022
april
august,
18
2022.
This
is
the
sig
cluster
life
cycle
project
kubernetes
cluster
api
azure.
We
meet
right
now,
every
two
weeks
here,
we're
part
of
the
sig
cluster
life
cycle
umbrella
project.
So
as
such,
we're
trying
to
comply
with
their
rules
of
conduct
here,
which
basically
boils
down
to
try
not
to
interrupt
each
other
and
try
to
use
the
raised
hand
feature.
So
we
don't
stomp
on
each
other.
A
If
you
want
more
details,
we've
for
about
how
this
is
run,
that's
at
the
top
of
the
document,
but
let's
go
ahead
and
get
started
first
of
all,
do
we
have
anybody
who's
here
for
the
first
time
or
wants
to
unmute
and
introduce
themselves.
B
Hello,
I'm
nicos
I'm
a
nursery
at
elastic,
and
this
is
my
first
time
here
I'm
trying
to
understand.
What's
going
on
and
check,
you
know
the
internals.
A
B
A
Okay,
if
you
want
to
you,
can
add
your
name
to
the
list
here
just
so,
we
have
a
record
of
who's
attending.
Sometimes
people
are
later
like
who
was?
Who
was
that
person
who
was
talking
about
x
y?
I
want
to
get
in
touch
with
them,
so
that's
kind
of
why
we
have
an
attendee
list.
A
C
Yeah,
so
okay
seals
here
been
talking
with
cecile
and
jack
about
fixing,
is
v-net
managed
with
managed
control
planes
right
now
with
managed
control
planes.
You
can
bring
your
own
v-net,
but
it
always
assumes
that
it
is
managed,
so
it
tries
to
delete
the
subnet
with
that
v-net
and
we've
gone
through
a
couple.
Different
approaches
on
try
to
how
to
fix
it.
C
A
couple
of
different
in-progress
prs,
and
I
just
wanted
us
to
try
to
determine
what
approach
we're
deciding
on
for
the
the
actual
solution.
If
we're
going
to
go
with
the
approach
of
not
deleting
the
subnet
resources
and
just
rely
on
deleting
the
the
v-net
and
have
it
cascade,
delete
the
subnet
resources
or
if
we're
going
to
try
to
you
know,
do
all
the
different
conditionals
for
those
sub
resources.
C
D
I'll
just
speak
up,
so
I
wish
jack
was
here
because
I
think
he
would
be
the
better
person
to
answer
this
question.
I,
as
far
as
I
know,
from
what
I
you
know,
I've
been
following,
but
I've
also
been
calling
the
same
way
as
you
trying
to
see
what
what's
happening,
but
I,
I
think,
the
pr
to
never
delete
the
subnet.
That's
not
gonna
work.
For
now
we
identified
that
it
wasn't.
It
was
causing
issues
when
deleting
other
resources
like
route
tables.
D
D
So
we
can't
use
that
approach.
So
what
we
need
is
something
that
makes
a
call
to
the
api
to
actually
get
the
state
of
the
bnet
and
then
checks
the
tags
on
that.
I
think
jaxpear
is
really
close.
The
only
thing
that
him
and
I
discussed
in
review,
is
to
remove
the
rate
limiter
implementation
from
that
pr
to
make
it
as
simple
and
lean
as
possible.
D
So
we
can
merge
it
quickly
and
if
it
needs
to
be
reverted,
it's
easier
to
convert,
and
we
can
cherry
pick
it
that's
the
most
important
part
and
then
follow
up
with
a
separate
pr
that
adds
rate
limiting
across
services.
Not
just
for
this
one
particular
case.
The
one
thing
that
we
were
still
going
back
and
forth
on
is
whether
we
should
do
the
cash
or
not.
I
thought
the
cash
was
a
low
hanging
fruit
and
pretty
simple
improvement,
but
I'm
also
okay.
D
So
I
think
you
know
I'm
also
fine
with
you
know
either
europr
or
jaxper,
which
everyone
gets
there
first
and
it's
like
an
emergable
state,
and
I
think
at
this
point
you
should
both
add
each
other
as
co-authors,
because
there's
been
so
much
back
and
forth,
but
we
just
need
something
really
simple:
that
checks
the
v-net
or
gets
the
v-net
and
then
uses
that
and
if
you
know,
if
we
want,
we
can
do
the
caching.
But
it's
not
blocking
for
me.
C
Yeah
no
problem
yeah,
my
only
I
think
the
the
quick
caching
is
going
to
be
a
little
bit
important,
at
least
from
my
perspective.
Just
because
I
do
know
we
hit
rate
limits
fairly
frequently
due
to
like
the
auto
scaler.
C
I
actually
don't
know
within
an
aks
world,
but
that's
going
to
be
as
common
as
some
of
the
rate
limiting
we're
hitting
in
a
non-aks
world.
So
I
am
slightly
concerned
about
in
the
reconciler
how
frequently
that
runs,
making
the
api
calls
so
that
and
considering
that
it
rarely
changes.
I
think,
having
that
as
a
cache
is
a
more
optimal
solution,
but
with
the
the
429
checks.
C
I
agree
that
that
should
be
a
separate
I'd,
rather
go
with
jax
vr,
just
because
he
would
know
better
how
to
do
the
the
mocking
than
I
would.
That
was
one
of
the
big
blockers
that
I
get
into
is
how
to
mock
out
the
service
in
service
of
a
different
service
in
it.
I
could
mock
out
the
scope.
C
D
Yeah,
so
how
about
this?
How
about
we
close
the
other
two
pr's,
like
jack's
other
attempt
and
your
pr
just
to
have
clarity
around
which
vr
we're
working
towards
and
then,
if
you
could,
please
comment
what
you
just
said
about,
like
preferring
caching
and
being
good
with,
not
including
the
rate
limiter
on
that
pr,
so
that
we
can
move
forward
with
it,
because
we
were
kind
of
going
back
and
forth.
I
think
in
the
end
we
both
agreed.
B
A
Right
on
next
topic,
we
actually
brought
up
last
time
and
I
kind
of
twiddled
my
thumb
so
we're
doing
it
again,
but
we're
interested
in
seeing
if
people
have
the
appetite
for
doing
this
meeting
every
week
and
maybe
moving
in
an
hour
later.
A
We
tried
this
a
long
time
ago
by
floating
a
doodle
to
vote
on,
and
people
voted
for
this
time
again.
But
overall
we
see
that
most
of
the
attendees
are
on
west
coast,
the
u.s.
So
it
seems
like
we
might
try
again.
But
what
do
people
think
about
that?
Zayn?
You
raised
your
hand
was
that
something
else.
E
Yeah,
it
was
about
the
previous
topic.
I
just
wanted
to
ask.
Oh
yeah
go
ahead.
If
I
can
ask
yeah
so
there's
a
question
there
like
how
to
keep
deleting
for
an
existing
v-net
in
these
cases
like?
Is
there
more
details
on
some
pr
about
that?
Or
can
I
read
because
we
are
creating
v-net
outside
of
the
like
cluster
api
and
capsi,
and
our
v-nets
do
not
get
deleted,
and
this
was
like
explicit
check
that
I
did
so
I
want
to.
I
would
be
interested
in
knowing
like
what
case
we
are
talking.
Okay,.
D
Yeah,
oh
actually
mike
do
you
want
to
go
for
it?
I
see
you
have
your
handwriting
I'll,
find
a
link
yeah.
D
C
I
was
just
about
to
find
the
pr
we
ran
into
a
situation
where
it
was
with
bring
your
own
v-net,
specifically
just
with
aks
so
with,
if
you're
not
using
aks,
everything
worked,
just
as
it
should.
When
you
bring
your
own
v-net,
you
can
create
a
cluster
and
it
launches
it
properly
inside
of
that
v-net.
C
C
So
what
this
approach
is
trying
to
do?
What
we're
trying
to
do
is
just
basically
say
hey
to
bring
your
own
v-net.
It
shouldn't
try
to
delete
the
subnet,
because
it
basically
always
thought
that
it
was
a
managed
v-net.
E
Yeah,
I
I
think,
like
yeah,
I
can
speak
so
I
think
we
are
using
aks
with
vnet
and
definitely
it's
not
happening
for
our
case.
So
probably
the
only
thing
different
is
like
we
do
limit.
It
gets
closer
to
its
own
subnet
and
we
are
okay
with
subnet
to
be
getting
deleted
right
so,
but
the
vnet
is
definitely
shared
between
multiple
clusters
and
we
have
been
doing
it
periodically
like
creating
and
deleting
a
cast
cluster
using
cluster
api.
E
So
unless
it's
something
new
issue
or
something
that
it
at
least
was
not
happening
because
we
tested
that
scenario
multiple
times
so
subnet
do
get
deleted.
That's
attached
to
the
aks
cluster,
but
we
not
we
provide
it
already
created
through
some
other
resources
like
terraform
and
that
is
like
should
exist
outside
your
guest
clusters.
E
B
D
Yeah-
actually,
I
just
want
to
use
this
moment
to
make
an
introduction
mike
if
you
haven't
met
zayn
before
zane,
has
actually
been
doing
a
lot
of
the
aks.
You
know,
testing
and
breaking
and
investigating
and
helping
us
fix
stuff.
So
you
know
he'd
be
a
great
resource
to
know
and
person
to
talk
to.
D
If
you
have
questions
through
your
own
journey
and
saying
mike,
is
actually
from
adobe
and
is
testing
out
using
cabsie
to
run
like
yes,
clusters
right
now,
building
a
prototype
so
he'll
be
around
just
just
want
everyone
to
know
each
other
great.
A
Cool
anything
else
about
peanuts,
subnets.
A
I
guess
not
so
then
it
has
been
proposed
that
we
try
to
do
this
meeting
every
week
and
maybe
change
the
time.
People
have
opinions
about
that.
A
Should
we
just
try
and
do
it
and
see
if
people
freak
out
or
should
we
we
could
do
another
poll
through
the
slack
channel,
but
last
time
it
didn't
really
provide
any
different
information.
A
B
D
I
think
we
did
every
two
weeks
at
the
very
beginning
when
the
project
was
very
nascent
and
it
didn't
really
make
sense,
because
we
didn't
have
much
to
talk
about
every
week,
but
I
think
at
this
point
we're
getting
enough
our
regular
attendance
from
users
and
people
who
come
with
questions
that
it's
worth
even
we
don't
have
to
fill
the
whole
meeting
with
an
agenda
even
just
like
the
maintainers
and
reviewers
being
here
to
answer
questions
and
having
people
just
being
able
to
jump
in
and
come
with
questions
that
they
would
normally
ask
in
slack.
D
I
think,
there's
value
in
that
we
could
try
that
out
and
see.
If
it
is,
you
know
the
if
we
do
get
the
same
attendance
or
attendance
drops
about
the
time.
I
think
we
should
definitely
do
an
async
survey
for
that
and
because
the
people
who
can't
make
this
time
aren't
in
here,
so
they
can't
voice
their
opinion.
Right
now-
and
I
don't
know
about
like
everyone's
schedule-
is
gonna-
be
different.
It's
really
really
hard
to
find
a
time
that
works
for
every
single
person
across
every
single
time
zone.
D
A
Definitely
an
option
I
mean
I
like
the
simplicity
of
just
having
it
every
week.
At
the
same
time,
you
know
I
put
those
little
reminder
things
in
slack,
just
because
I
think,
like
a
lot
of
people
since
it's
every
two
weeks,
I
don't
know
if
it's
happening
this
week
or
not
so,
but
if
it
happened
every
week,
then
I
think
we
all
fall
into
a
pattern,
ideally
at
the
same
time,
but
we
could
do
that
separately.
A
A
Like
you
can't
do
every
week,
but
could
do
every
other
week.
Okay,
I
mean
we
also
record
all
these.
So
if
people
really
need
to
catch
up,
you
can
go
watch
the
recording.
A
Well,
I'm
not
hearing
any
anybody
responding
negatively.
So
let's
consider
that
a
soft
consensus
and
we'll
try
and
just
do
this
next
week
and
every
week
from
now
on
and
then
I'll
go
ahead
and
do
a
poll
and
see
if
we
want
to
change
the
time
for
one
or
both
meetings
for
one
every
other
meeting.
Something
like
that.
D
D
I
haven't
seen
any
movement
on
that
pr
for
a
while,
so
maybe
worth
thinking
or
tagging
mutation
asking,
if
he's
so.
If
this
is
still
active
or
if
you
should
move
it
out
of
the
mouse.
B
B
Like
it's
just
yeah,
so
that
one's
something
we're
trying
to
implement
using
the
add-on
controller
that
I'm
working
on.
Oh
right,.
A
Do
you
think
it's
likely
to
land
in
the
next
week
or
two
or
should
we
move
it
to
a
different
milestone
or.
B
I
mean
it's
probably
usable,
but
I
wouldn't
guarantee
that
it's
tested
by
then
like.
We
can
definitely
try
it
out.
If
we
want
to,
you
know,
see
see
how
it
works
and
try
out
the
flow,
but
yeah,
probably
next
milestone.
B
B
To
also
tags,
don't
it's
not
really
a
service.
We
can
make
async,
that's
sort
of
what
I
discovered
working
on
that
oh
and
I
guess
I
I
sort
of
experimented
with
some
changes
so
we'll
have
to
see
if
we
want
to
close
the
pr
or
if
we
want
to
move
forward
with
the
refactor
anyway,.
A
So
it
sounds
like
based
on
that:
it's
probably
not
going
to
land
in
the
next
week
or
two
since
there's
still
some
open
questions.
Would
you
agree,
yeah
yeah,
all
right,
let's
just
acknowledge
reality.
A
A
Oh,
it
reload
document
new
release,
cadence.
This
is
on
me
and
I
will
do
this-
probably
not
today
or
tomorrow,
but
by
next
week,
configurable
network
interfaces.
A
B
B
A
D
If
I
may,
I
think
this
is
actually
fixed
from
so
this
was
the
same.
This
is
basically
a
duplicate
issue
from
the
other
one
that
we
were
looking
at,
that
zane
opened
with
the
provider
id
issue,
so
I
think
like
when
we've
done,
we've
already
fixed
and
merged
and
backboarded,
but
I
think
I'll
leave
it
up
to
check
to
verify,
but
it
should
be
should
be
good.
A
This
lowercase
yeah
yeah,
two
five,
three.
B
A
D
That's
my
monster
baby,
this
one's
still
in
progress.
I
run
there's
this
colonel
bug.
That
is
blocking
me
right
now
that
is
making
the
self-hosted
house
fail.
It's
a
known
bug
that
is
supposed
to
be
fixed
in
the
latest
journal.
So
I'm
I'm
trying
to
figure
out
why
I'm
still
seeing
this
in
the
image
if
it's
because
we're
using
an
older
kernel
or
what
it
is,
but
otherwise
I
would
love
some
reviews
on
this,
because
it's
a
pretty
big
pr.
So
it's
it's
ready
for.
A
A
A
A
Okay,
I
guess
that's
it
for
this
week,
we'll
see
everybody
here
at
this
point
same
time
next
week,
which
will
be
what
the
25th
so
we'll
see.
You
then,
and
hopefully
the
new
meeting
schedule
works
out.