►
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
Okay,
welcome
everybody
it's
february
3rd.
This
is
the
kubernetes
cluster
api,
azure
provider
office
hours
meeting.
We
have
this
every
two
weeks.
We
are
part
of
the
sid
cluster
life
cycle
project
and
as
such,
we
try
to
abide
by
the
cncf
rules
of
conduct
for
this
meeting,
which
basically
boils
down
to
everybody,
be
polite
to
each
other
and
let's
try
and
use
the
raise
hand,
button
and
zoom
so
that
we
don't
stomp
on
each
other.
B
B
I
just
want
to
say
hello,
essentially,
I'm
not
sure
if
you
already
noticed,
but
we
are
currently
looking
from
the
vmware
side
at
a
bunch
of
providers
and
we're
looking
at,
I
don't
know,
who's
running,
which
linder
and
what
validation
tools
we
have
and
then
we
just
try
to
propose
if
there
is
some
useful
stuff
that
someone
might
not
have
already
to
add.
That's
so
yeah.
So
if
you
see
me
somewhere
on
some
issues
in
pr's,
that's
probably
because
of
that.
A
Cool,
I
guess
we'll
do
a
milestone
review
at
the
end
and
let's
go
on
to
open
discussion.
I
just
put
this
in
there.
I
don't
want
to
get
bogged
down,
but
maybe
the
cert
manager
issue
obviously
cratered
most
of
our
pr's
yesterday
and
I'm
just
curious
where
we're
at
and
if
there's
anything
we
still
need
to
do
or
if
it
was
all
upstream.
I
guess
I'm
asking
you
cecile
or
maybe
david.
You
know.
C
I
can
take
this
one
so
yeah,
so
there's
two
cappy
patch
releases
for
zero,
four
and
1.0
that
fixed
cluster
ctl
in
those
so
as
soon
as
those
were
out,
users
should
have
been
back
to
good.
In
order
to
test
our
end-to-end
tests.
We
had
to
get
those
versions
backported
into
our
release,
branches
that
were
testing
with
those
previous
versions,
so
those
prs
merged.
C
I
think
midday
yesterday,
so
we're
good
on
that
front
and
then
the
cappy
1.1.0
release
fix
it
for
the
1.1
and
we
also
included
that
in
the
main
branch,
so
the
main
branch
is
also
fixed,
so
I
think
we're
good
on
every
front
unless
I'm
missing
something,
but
we
should
be
back
to
running
all
the
branches
would
be
worth
checking,
maybe
this
morning
to
see
if
there
are
any
failures.
D
Yeah,
so
we
now
have
windows
container
d,
and
it's
been
a
few
months.
We
have
all
the
upstream
tests
running
against
it
and
it's
actually
more
stable
than
the
dr
shim
implementation
and
with
124
coming
without
dr
shim,
I'd
like
to
appreciate
the
docker
shim
implementation
that
we
have
in
cap
c
and
move
forward
to
only
using
container
d
and
making
all
the
implementations
there
right
now.
If
you
were
to
use
the
cluster
ctl
template,
you
would
get
a
windows.
D
If
you
used
windows,
he
would
end
up
with
a
docker
implementation.
I
would
like
to
swap
that
all
over
to
container
d
for
the
next
release
and
have
docker
shim
be
the
older
one,
and
things
like
that.
So
I
don't
know
if
anybody
has
any
objections
to
that
or
thoughts
around
it,
but
I
just
wanted
to
announce
it
here.
A
I
saw
that
with
123.3.
We
didn't
do
just
a
we
didn't
do
a
non-container
d
windows
was
that
on
purpose?
Have
we
started
this
already
or
is
it?
Oh?
I
don't.
I
don't
think
that
was
on
purpose,
but
should
I
fill
that
hole?
We
just
made
the
container
d
releases
this
first
I
could
tell
yeah.
We
should
probably
do
that
since
we're
we're
doing
it.
But,
okay,
I
can
do
that.
This
takes
a
minute.
A
A
All
right,
cecile,
you
want
to
talk
about
the
111
release.
C
Yeah,
this
is
more
of
a
psa,
I
guess,
but
the
there
was
a
rollout
in
aks
this
week,
which
caused
a
regression
in
our
aps:
implementation
tldrs.
They
changed
the
name,
the
keys
of
tags,
that
we
were
relying
on
to
determine
like
to
match
a
vmss
to
a
full
name.
The
tags
that
were
changed
in
question
are
part
of
the
managed
resource
group,
which
typically
were
not
supposed
to
be
depending
on
or
using
or
changing,
which
is
part
of
it's
documented,
as
not
a
supported
thing
to
do
so.
C
For
now,
we've
fixed
the
tags.
Thanks
saying
for
opening
that
pr
for
the
long
term,
I
think
we
should
find
a
plan
to
not
rely
on
those
tags
anymore.
Just
in
case
you
know
things
might
change
again,
it's
just
not
something
where
we
should
rely
on.
C
So
we
need
to
look
into
alternatives,
but
for
now
the
regression
is
fixed,
but
that
requires
everyone
to
use
the
new
release
to
that
has
the
fix,
if
you're,
using
aks
and
if
you're
not
you're,
going
to
quickly
realize
you're,
not
using
it,
because
it's
not
going
to.
Let
you
build
vehicles
so
makes
you
update
to
1.1.1
if
you're,
using
a
yes
and
yeah
any
questions
about
that.
C
Cool
so
yeah,
and
then
this
is
also
psa.
We,
I
opened
two
pr's
to
add
james
who's
here
and
jack
francis
to
reviewers
they've,
both
been
you
know,
contributing
for
a
while
and
making
reviews
and
we're
getting
more
and
more
pr.
So
this
is
a
good
time
to
expand
our
reviewers
and
also,
I
guess
this.
C
I
also
want
to
say
if
anyone
else
wants
to
become
a
reviewer
like
we're.
You
know
happy
to
help.
You
mentor
you
and
on
board
you
to
the
contributor
ladder.
So
please
reach
out
to
one
of
us
and
we
can
try
to
make
sure
you're
getting
exposed
to
the
things
you
need
to
be
exposed
to
in
order
to
become
a
reviewer
and
congrats
james
and
jack,
and
thanks
for
all
the
contributions.
C
Yeah,
I
was
gonna
say
I
don't
know
if
we've
been
keeping
the
milestone
up
today,
but
we
should
check
in
on
the
release
and
see
so
last
time
we
did.
A
release
was
1.1
that
was
mid-december
before
the
holidays.
Cappy
just
did
a
1.1
release.
C
I
was
hoping
we
would
do
1.2
around
this
time
or
at
least
mid-february.
I
don't
know
how
we're
feeling
about
that.
I
know
there's
a
lot
of
stuff
in
flight,
that's
not
done
yet
there's
some
async
pr's
like
that,
are
still
waiting
for
merge.
C
There's
the
aks
different
features
that
we
want
to
add
that
are
still
kind
of
in
progress
and
there's
also
the
cluster
class
template
refactor,
which
is
not
it's
not
merged
yet
so
I
don't
know
if
we
want
to
give
ourselves
more
time
to
include
those
if
we
think
we
already
have
a
lot
to
release
and
we
should
do
an
intermediate
release
for
now.
What
do
people
think.
A
My
general
feeling
is:
we
should
default
to
doing
more
frequent
releases
because
it's
easy
to
fall
into
the
trap
of
oh
well.
If
we
just
wait
for
you
know
these
things
to
land,
then
we'll
have
like
a
nice
set
of
features,
but
but
you
know
you
can
always
kind
of
be
there
and-
and
we
want
to
make
the
releases
lower
stakes
and
all
that
so
just
in
general,
I
go
for
more
frequent
releases,
but
I
don't
know
not
dogmatic.
D
D
But
if
we
had
like
six
of
them,
we
might
hold
off
kind
of
thing
this
kind
of
might
take
or
if
there's
like,
two
or
three
more
aks
ones
that
are
required,
but
kind
of
trying
to
identify
what
those
like,
how
big
is
the
gap
between
getting
those
in
and
getting
out
another
release
and
what
we
have
ready
to
go.
E
Yeah,
I
also
think
like
we
should
be
since
they're,
just
like
two
ways
in
ps
or
I
think
like
three
three.
We
should
just
wait
for
that
to
get
merged
before
like
making
a
new
release,
but
but
in
general,
like
I
agree
with
matt
that
we
should
be
making
frequent
releases,
but
just
this
in
this
case,
like
let's
just
wait
for
the
asu.
That's
my
opinion.
C
What
do
we
think
of
targeting
maybe
mid
february
for
the
next
release,
like
around
february
15
february
20th?
I
think
that
should
get
us
enough
time
to
get
those
prs
in
but,
like
matt
said,
I
don't
think
we
should.
We
should
like
always
wait,
because
otherwise
it's
an
ongoing
growing
release
and
we're
never
gonna
cut
it.
There's
always
more
stuff
to
do
so.
C
We
can,
if
it's
useful
to
people,
I
don't
think
our
milestone
is
up
to
date,
but
we
can
check
and
try
to
make
it
up
to
date
or
we
can
just.
C
Yeah,
if
no
one
has
strong
desires
to
go
through
the
milestone,
let's
not
do
that
and
bore
people
through
it,
but
I
guess
more
of
a
meta
topic
is:
what
do
we
think
of
this
meeting?
I
feel
like
I
was
hoping
this
would
be
more
of
a
like.
C
Let's
help,
users
out
and
like
you
know,
people
who
are
using
cappy
cabsie
can
come,
and
we
can,
you
know,
hear
feedback
or
try
to
unblock
people
talk
about
what's
currently
going
on
in
development
and
see
if,
like
we're
line,
features
we're
not
getting
many
questions
or
many
people
coming,
and
you
know
asking
things
it's
been
mostly
like
the
maintainers
kind
of
like
talking
amongst
themselves,
and
I
feel
like
it's
a
lot.
C
Are
you
getting
anything
from
like
hearing
us
talk
about
like
announcing
things
or
would
it
be
more
useful
if
it
was
more
like,
hence
on
like
deep
dives
or
I'm
just
trying
to
see,
you
know,
don't
want
to
waste
people's
times
and
but
if
you're
saying
you
know,
this
is
great.
We
like
this.
Let's
keep
doing
this,
then,
let's,
let's
do
that.
A
I
mean,
I
think,
it's
useful
just
to
check
in
see
what
everybody's
doing,
there's
always
at
least
a
couple
things
I
wasn't
aware
of
here,
but
I
also
wonder
if
you
know
maybe
we
could
have
some
like
crowd
pleaser,
each
time
like
we
could
try
and
have
a
demo
or
try
and
have
a
hands-on
thing
for
each
one.
That
would
be
a
way
which
we
could
say,
hey
make
sure
you
come
to
office
hours.
If
you
missed
the
demo
of
blank,
because
we
certainly
have
time
for
that.
A
C
A
C
Yeah
I
mean
my
my
goal:
isn't
like
to
be
tourists
not
to
like
make
people
come
right
like
if
it's
useful
people
should
come,
but
I
don't
want
to
try
to.
But
I
what
would
be
useful
is
to
like
hear
you
know,
people
that
were
doing
this
for
what
they
want
or
what
would
be
useful
to
them
like
how
we
can
better
serve
their
time
and
also
like
if
we
can
hear
some
feedback.
C
You
know
like,
because
I
think
a
lot
of
it
is
like
we're
trying
to
assess
like
if
we're
going,
the
right
direction
or
like
if
people
are
having
trouble,
and
that
would
be
really
great
to
like
hear
from
those
people
who
are
actually
using
the
project.
F
Saw
your
hand
was
up:
hey
no
worries.
Thank
you.
Even
from
even
outside
of
the
point
of
view
of
getting
more
folks
to
come,
the
code
walkthroughs
could
be
super
useful
in
the
recorded
nature
of
the
meeting
as
well.
So
I
mean
we
could
you
know
mark
on
each
one
of
those
videos?
We
did
a
code
walkthrough
of
this
area.
F
So,
as
folks
are
interested
in
like
learning
more
about
that
area,
they
could
go
back
and
find
that
video
and
end
up
learning
about
that
area
as
they
jump
into
it.
This
this
could
be
really
good
for,
like
in
the
fullness
of
time,
we
could
have
a
pretty
good
walkthrough
on
the
different
areas
of
the
code,
this
project,
I
know
something
to
think
about.
C
Yeah,
I
think
I
like
that
idea
and
just
in
general,
I
think
it's
also
on
us.
Maintainers
to
try
to
you,
know,
be
a
bit
more
organized
and
maybe
announce
these
things
ahead
of
time.
So,
like
maybe
like
wednesday,
each
like
before
a
meeting
like
the
day
before
we
can
try
to.
C
C
If
we
don't
have
anything,
then
we
shouldn't
have
the
meeting
and
then,
if
there
are
no
other
topics,
and
then
we
can
do
like
you
know
announcement
like
say
this
is
where
we're
going
to
be
doing
this
meeting
and
then
we
can
leave
a
time
at
the
end
for
general
q,
a
and
just
anything
people
want
to
bring
up
that
way.
It's
like
kind
of
clear
like
what
you're
showing
up
for,
and
it's
not
just
like.