►
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
This
is
Chill,
it's
July
27th,
and
we
meet
here
at
this
time
every
week
to
discuss
whatever
topics
are
relevant
to
Cluster
API
provider
azure.
A
We
are
a
sub-project
of
Sig
cluster
lifecycle,
which
is
a
kubernetes
umbrella
group.
Therefore,
we
abide
by
their
rules
of
conduct
which,
as
probably
everyone
knows,
boils
down
to
please
be
kind
to
each
other.
Try
not
to
talk
over
each
other
use
the
raise
hand,
feature
Etc.
A
If
you
have
any
questions
about
editing
this
list,
Eddie
sorry
editing
this
document
and
stuff,
there's
some
instructions
up
the
top
about
how
to
get
access,
and
if
you
feel
like
putting
your
name
here
under
the
attendees,
please
do
so
at
the
very
beginning.
We
usually
leave
some
time
for
anyone,
who's
new
or
wants
to
say
hello
and
introduce
themselves
to
do
so.
I'm
pretty
sure.
No
one
here
is
new,
but
I
will
still
mute
and
be
quiet
for
a
few
seconds
in
case
somebody
wants
to
say
something.
A
All
right,
let's
move
on
to
open
discussion,
yeah
the
well.
The
thing
that's
probably
on
most
of
our
minds
is
we're
having
a
lot
of
problems
with
CI.
It's
pretty!
It's
I,
don't
know
if
it's
worth
going
through
the
several
problems
that
we've
fixed
already,
but
maybe
we
could
and-
and
these
aren't
all
actually
related
to
Cappy
v150.
A
We
initially
some
of
the
problems
cropped
up,
trying
to
do
the
rendering
and
now
we're
just
sort
of
firefighting
trying
to
get
CI
healthy
again,
so
that
PRS
and
stuff
can
pass
we
merged
some
workarounds
yesterday
or
Cecile
came
up
with
a
workaround
which
is
basically
pinning
the
version
of
kubernetes
back
slightly.
A
That
fixes
some
problems
that
we
were
seeing
in
installing
the
Calico
chart,
specifically
on
IPv6
or
maybe
also
dual
stack,
I,
think
it's
just
IPv6
clusters
that
seems
to
be
fixed
and
I
looked
at
test
grid
this
morning
and
things
are
turning
green
again.
So
that's
good!
A
So
as
far
as
I
can
tell,
the
main
remaining
issue
for
CI
is
the
AKs
Auto
scaling
issue
where
essentially
AKs
changed
an
API
on
their
side
to
Chase
change
the
behavior
slightly.
We
weren't
aware
of
that
as
soon
as
it
started,
trickling
out
to
all
the
different
regions.
We've
we're
seeing
failures
when
we
try
to
disable
Auto
scaler
John
has
a
fix
there.
That
sure
looks
like
it
should
work
but
seems
to
have
failed.
Do
you
want
to
update
us
on
that
John?
B
Yeah,
so
now
that
we've
fixed
the
auto
scaling
issue
now
there's
another
failure
that
we
were
hitting.
We
at
least
hit
the
same
thing
twice
in
a
row
on
that
PR
and
I
tried
it
locally
in
a
different
region
and
a
different
region
from
CI
in
a
pass
for
me
locally,
so
I'm
trying
it
again
locally
for
me
in
North
Europe,
where
CI
failed
and
I'll
see
if
that
fails
to.
B
A
It
could
also
be
that
you
know
they're
still
updating,
AKs
providers
in
different
regions,
and
maybe
we
hit
one
that
had
implemented
something
the
other
one
didn't.
But
do
you
think
that's
a
do?
You
think
that's
a
fix.
We
still
that
we
should
do
in
that
same
PR
or
a
separate
fix
that.
B
I
still
don't
have
like
a
super
firm
grasp
on
like
exactly
why
it
failed.
So
I
think
that'd
be
a
little
hard
to
say,
but
yeah
I'll
keep
digging
into
it.
Cool.
A
A
Pipeline
building
copy
and
also
test
Grid
in
general,
there
were
a
bunch
of
fixes
I
had
to
put
in
this
morning
because
that
go
120.6
bug
is
still
failing,
a
bunch
of
tests
that
rely
on
Cappy
or
capsie,
but
as
far
as
cap,
Z,
PR's
and
test
crit
is
concerned,
I
think
that's
all
I
see.
Is
this
AKs
test,
so
that's
better
than
yesterday
much
better.
A
All
we
can
hope
for.
Does
anybody
have
any
questions
or
comments
about.
A
Okay,
next
topic
came
up
is
not
nearly
so
urgent
but
John
realized,
and
this
clicks,
because
I've
seen
this
happen
in
the
past,
that
you
know
when
we
update
people
in
the
maintainers
list.
A
It
only
takes
effect
where
we
merged
it
in
Maine,
and
when
you
look
at
PRS
that
are
targeted
against
different
branches,
it
correctly
checks
to
see
who
the
maintainers
are
on
that
branch
and
doesn't
let
his
so
logically,
when
someone's
moved
to
maintainer
the
intent
is
now.
You
maintain
the
whole
project,
including
the
branches
that
we
maintain
in
the
past,
but
we've
just
been
lazy
about
cherry
picking
those
changes
because
it
usually
hasn't
mattered
much
but
I
wonder
if
we
should
do
that
in
this
case.
What
do
people
think?
A
Because
we
have
almost
two
more
months
before
the
next
release
happens
and
it
would
probably
be
convenient
to
have
ashitosh
and
John
also
be
able
to
approve
those
anybody
have
any
strong
opinions
or
weak
opinions.
A
D
Oh
I
thought
that
being
a
maintainer
for
a
project
gives
access
for
the
whole
I
mean
all
the
branches.
Is
it
not
the
case.
A
Logically,
that's
the
idea,
but
in
practice
the
way
it's
implemented
we've
seen,
we
can
show
empirically
that
it
checks.
The
target
branch,
looks
at
the
owner's
file
and
sees
that
you're
not
in
there
and
says
you're,
not
an
approver,
whereas
that
should
works
fine
on
Main,
because
you
are
in
that
case.
A
So
if
we
want
to
make
things
consistent,
we
can
cherry
pick.
So
the
owner's
file
is
the
same
on
all
the
branches.
D
A
It
must
it
must
match
up
the
definition
of
the
maintainers
in
what
is
it
Kate's,
dot,
IO
project
and
then
check
against
what
it
actually
sees
in
the
Target
branch.
I
mean
the
owner's
file
and
the
owners
aliases
that
gets
included
are
a
structured
sort
of.
C
A
Thing
that
gets
parsed,
apparently
so
I,
don't
know,
I've
seen
that
I've
seen
that
this
is
how
it
works
in
the
past
and
I'm,
pretty
sure
that's
how
it
works.
Although
I
don't
actually
know
how
the
code
runs,
I
should
touch.
E
B
A
You
know
Jack
Francis
is
out
for
until
the
very
end
of
August
and
other
people
are
gonna,
be
taking
vacation,
and
so
we
end
up
in
the
situation
where
there's
only
one
I
think
right
now:
I'm
the
only
maintainer
who's
here
today
who
can
approve
things
on
those
branches
which
isn't
the
end
of
the
world.
But
we
could
avoid
that
by
cherry
picking
these
things.
So
maybe
we
should
do
that.
A
Well,
if
people
agree,
then
if
one
of
you
could
actually
create
those
PR's
just
to
sync
them
up,
then
I'll
approve
them,
but
I
can't
create
them
because
I
can't
self-approve.
So
if
somebody
wants
to
do
that
as
an
idle
time
task
or
whatever
I'll
be
glad
to
approve
those
changes,
I'll
do
that.
Okay,
great!
E
Yeah,
thank
you.
I
came
back
to
workload,
identity
pending
topics
after
I
set
a
little
bit
in
my
new
company,
and
so
I
have
like
prepared
a
document
and
risk
PR
did
that,
though,
I've
marked
it
as
WIP,
because
I
just
want
to
myself.
Try
that
document
blindly
and
see
if
it
works
in
a
single
flow.
E
So
you
know
once
I'm
ready
while
paying,
and
if
anybody,
if
there
is
any
volunteer
to
kind
of
run
through
that
document
and
do
it.
That
would
be
great
because
I
just
want
to
like
avoid
that
bias
yeah,
and
this
is
what
I
wanted
to
just
bring
back
to
notice,
really.
C
Yeah,
it's
not
a
mention
I'm
happy
to
volunteer
and
take
a
look,
because
I
wanted
to
learn
more
about
workload,
identity,
anyways,
so
yeah.
Just
let
me
know
when
you're
ready.
E
Yeah
exactly
I'd
also
love
to
volunteer
so
just
spend
whenever
the
document
is
ready.
Awesome
thanks,
I
can
see
the
chat.
Sean
has
typed
that
he
has
already
set
up
workload
identity
and
he
can
also
help
us.
So
thank
you.
John.
A
And
I
have
blundered
into
it
without
reading
the
docs
and
failed
once
or
twice
so,
I
would
I'll
also
volunteer,
but
I
think
maybe
we've
got
it
covered.
E
Yeah
by
the
way
Matt
like
the
document
is,
if
you
see
the
proposal,
the
the
there
isn't
like
more
detailed
document.
So
if,
if
you,
if
someone
wants
to
go
geeky
on
that,
you
can
take
a
look
at
that
document.
I
just
want
to
give
this
document
like
as
as
simple
as
it's
a
read
for
a
user
like
this
is
just
be
able
to
follow
that
and
get
there.
So
that's
the
idea.
A
A
All
right
do
we
have
any
other
cluster
API
stuff
we
want
to
mention
here.
A
C
Yeah
so
we've
published
a
new
DMX
engine
and
it's
supported
by
arm64,
but
it
is
like
it
doesn't
work
specifically
with
Ubuntu
2004,
due
to
a
bug
with
like
newer
Go
versions
and
Ubuntu
2004.
So
we
I
opened
another
PR
that
only
uses
the
new
VM
extension
for
arm64
architectures
and
everyone
else
will
use
the
original
1.,
1.0
and
yeah,
so
that
PR
is
it's
got
two
LG
TMS.
So
it's
kind
of
just
waiting
to
merge
and
I
think
this
issue
will
be
closed
afterwards.
C
B
A
All
right,
well,
I'll,
just
do
the
slow
scroll
thing
here
and
if
someone
has
an
update
they
want
to
offer.
Please
do.
A
Here's
all
the
ones
that
aren't
moving
forward
because
of
me,
but
Willie
and
I
talked
so.
Hopefully
we
can
finally
get
off
in
SDK
V2
updated
so
that
it
works
better
more
the
way
we
intended
and
doesn't
stomp
on
workload
ID
for
example,
and
then
these
should
start
falling
like
dominoes
I
know,
I've
said
that
a
couple
stand-ups
in
a
row,
but
it's
still
true.
E
E
You
know
I
understand
that
I
understand
that,
like
there
will
be
some
a
lot
of
issues
that
would
be
like
critical
and
we
want
to
get
them
done,
but
yeah
right,
I'm
just
checking
if
there
is
something
that
we
have
done
it
like
I,
could
potentially
direct
them
to
a
couple
of
folks
who
have
reached
out
to
me
and
sown
interest
in
Kinder
readings.
I
just
wanted
to
see
this
thought
here.
A
A
Got
it
so
yeah
I
mean?
Maybe
we
could
take
a
look
at
these
real
quick,
maybe
some.
Maybe
some
of
this
is
suitable
for.
A
A
A
There's
still
a
handful
that
are
tagged
that
way
that
no
one's
looks
like
some
of
them
are
assigned,
but
I
mean
it's
a
very
good
point.
We
should
really
be
if
we
don't
have
that
kind
of
those
kind
of
issues.
It's
harder,
attracting
people
to
the
project.
B
B
Yeah
going
through
the
Milestone,
you
might
notice
that
there
is
not
much
ASO
stuff
in
here,
and
that
is
purely
due
to
my
neglect.
So
I'm
going
to
go
ahead
and
just
tag
a
bunch
of
ASO
issues
to
put
in
the
Milestone
that
I
think
we
can
get
done
in
the
next
six
weeks
or
so
great.
A
I
we
could
look
at
new
pull
requests,
but
I
think
I'm
pretty
familiar
with
most
of
these.
Oh
here's
you
were
talking
about
ashtush
here
is
the
bug
fix
that
we
were
discussing
it
earlier.