►
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
As
you
probably
know,
we
are
a
sub-project
of
Sig
cluster
lifecycle
and,
as
part
of
the
overall
kubernetes
ecosystem,
we
try
to
abide
by
those
rules
of
conduct
which
basically
boils
down
to
let's
try
to
be
nice
to
each
other,
not
to
talk
over
each
other
and
raise
your
hand,
not
that
we
generally
have
many
issues
with
that.
But
just
so
we
know,
if
you
don't
have
access
to
this
document
for
editing,
there's
some
instructions
at
the
top.
A
A
I
think
that's
most
of
the
Spiel.
If
I
forgot
anything,
please
let
me
know,
please
add
your
name
to
the
attendee
list.
If
you
so
choose,
and
here
at
the
beginning,
we
usually
provide
a
minute
for
new
folks
to
say
hello
and
introduce
themselves
I'll
be
quiet
for
a
few
seconds
here,
and
someone
wants
to
do
that,
although
I
think
I
see
The
Usual
Suspects,
so
probably
not
the
case.
A
Okay,
let's
move
on
to
the
recurring
topics.
Please
feel
free
to
interrupt
me
because
everything
on
the
board
here
is
mine
so
far
and
please
feel
free
to
add
stuff.
A
If
you
think
of
anything,
the
first
thing
I
was
going
to
point
out,
is
we
have
some
musical
chairs
going
on
with
the
people
who
maintain
the
project,
essentially
David
Justice,
who
probably
you've
all
interacted
with
and
is
working
on
other
things,
largely
wasm
stuff
and
still
wants
to
keep
a
hand
in
cluster
API,
but
is
not
able
to
review
PR
so
he's
moving
to
Emeritus,
which
is
a
status.
That
means
you
know
you
can
still
come
in
and
approve
things,
but
you're
not
expected
to
and
PRS
won't
get
assigned
to.
A
You
is
is
the
crucial
thing
so
and-
and
you
know
if,
if
you
haven't
been
with
the
project
wrong,
just
know
that
David
and
Cecile
and
Stephen
Augustus
and
Nader
ziata.
Basically,
there
are
a
handful
of
people
who
made
this
project
initially
and
David
was
one
of
those,
so
we
really
wouldn't
be
here
without
him
and
then
on
the
other
side,
ashitosh
Kumar
and
John
hewn
and
several
other
people.
But
honestly
we're
trying
to
do
it
in
stages
are
well
deserving
of
being
maintainers.
A
If
you
want
to
go
pile
on
there
and
say
lgtm,
please
feel
free
to
do
so.
I
didn't
link
to
the
PRS
here,
but
you
could
find
them
and
I
kind
of
thought.
Maybe
we'd
merge
those
today,
but
I
need
to
coordinate
with
Cecile
so
and
she
apparently
couldn't
make
the
meeting
so
I'll
check
with
her
later,
but
those
should
merge
pretty
soon
and
then
there's
a
couple
of
follow-on,
clerical
PRS,
because
of
course
this
is
kubernetes
and
there
always
are
so
once
those
merge.
A
Having
changed
all
three
of
these
rules,
then
there's
two,
maybe
three
other
PRS.
We
have
to
merge
in
the
ecosystem
and
then,
when
you
type
slash,
approve
it'll
approve
it
as
the
Salient
thing.
A
But
again
thanks
David
yeah
go
ahead.
B
Mata
had
one
question
about
the
merging
of
br's,
so
when
the
pr
is
basically
approved,
is
it
supposed
to
just
write
the
way
emerge
into
it,
because
there
was
one
pull
request
that
I
did
and
it
was
a
very
minor
connection
into
something
and
I
think
someone
approved
it.
However,
when
I
check
on
the
website,
it
is
not
just
the
change
hasn't
been,
let's
just
say
implemented,
so
is
it
that
it
directly
right
away
it
gets
implemented
when
someone
approves
it
or
what
is
it.
A
Did
the
did
the
pr
get
merged
or
is
it
still
waiting
to
be
merged.
B
I
do
not
know
I
will
check
it.
Why
would
I
know
that
it
was
approved.
A
Well,
so
the
way
it
works
in
general
in
all
the
kubernetes
projects
is
there's
this
thing.
A
bot
essentially
called
prow.
That
is
always
watching
PR's
and
updating
their
status
and
there's
a
bunch
of
Hoops.
You
have
to
jump
through
to
get
it
and
and
it's
the
thing
that's
responsible
for
merging
PRS
and
we
like
to
let
it
do
its
job.
You
know
we
could
go
in
there
old
school
and
merge
things
by
hand,
but
that's
kind
of
not
the
way
to
do
so.
A
Those
are
some
of
the
gates
and
then
obviously
all
the
tests
have
to
pass
for
for
it
to
merge
and
then,
generally
speaking,
once
things
are
approved,
this
prowbot
takes
a
fresh
look
at
the
pr
and
according
to
some
calculation
I,
don't
fully
understand
decides
that
some
jobs
should
be
run
again
and
behind
the
scenes,
it's
actually
rebasing
what
it's
those
jobs
off
of
the
current
main
branch.
So
it's
trying
to
ensure
that
nothing
has
happened
in
the
main
that,
with
regards
to
integrating
it,
that's
going
to
break
us
so
it'll
rerun
tests.
A
Sometimes
it's
annoying
because
it's
going
to
rerun
almost
all
the
tests
and
you're
like
I've,
just
waited
several
hours
and
we
had
to
rerun
this
and
why
isn't
this
merging
yet?
But
prow
is
going
to
decide
to
rerun
a
bunch
of
tests
and
then,
as
long
as
everything
goes
green
then
browse
responsible
for
merging
it.
But
again
it's
not
doesn't
always
happen.
Lickety-Split.
Usually
it's
pretty
quick
but
they've
definitely
been
sort
of
brownouts
or
service
issues
with
prow
itself,
where
PR's
are
ready
to
go
and
it
sits
there
for
a
while.
A
So
we
don't
have
total
control
over
it.
Does
that
explain
your
question
or
if
or
if
something's
merged?
Are
you
saying,
something's
merged
and
you're
not
actually
seeing
the
effects?
When
you
run
the
product.
B
No,
it
is
merged
because
I
think
someone
merged
I,
think
I,
don't
know
who
exactly
am
I
did
but
I'm
aware
someone
merged
it.
Sorry
approved
it.
I'm,
sorry,
okay,
I'm,
not
sure
about
the
merging
I'll
check
it
out
and
then
I'll.
Let
you
guys
know
like
before
this
meeting
ends.
Okay,
I'll
check
it
out
right
now:
okay,.
C
A
B
E
B
E
A
Actually
yeah,
that's
that's
a
good
point.
That's
probably
why?
Because
the
the
docs
point
to
the
latest
release
Branch,
but
things
that
go
into
Maine
are
not
going
to
show
up
there.
There
is
a
way
to
go.
Look
at
the
main
branch
explicitly
in
our
published
docs.
If
you
want
to
make
sure
that
they're
there
but
yeah,
that's
probably
why
doc
changes
don't
show
up
sort
of.
B
Immediately
cool.
A
All
right,
the
next
thing
I
just
wanted
to
let
people
know
about
the
Cappy
150
integration
update
long
story
short
I
have
a
PR
out
there.
The
only
real
interesting
thing
is
that
since
controller
runtime
got
updated,
a
bunch
of
things
broke
and
we
have
to
update
catch
up
with
those
function,
signature
changes
and
then
we
depend
to
some
extent
on
ASO.
Aso
also
needs
to
update
update
controller
runtime
to
the
same
version.
I.
A
Yeah,
that's
where
that's
where
I
was
getting
to
is
they
are?
They
were
awesome.
They
jumped
on
the
pr
the
issue
right
away
and
they
merged
it
this
morning
and
they
seem
to
be
doing
the
other
prep
work
for
their
next
release.
So
I'm
very
optimistic
that
we
can
get
this
all
squared
away
within
the
week
or
two,
maybe
before
Cappy's
release
go.
F
A
C
Yeah
Matt
I
just
commented
on
the
pr
with
a
commit
to
do
the
ASO
date
and.
D
F
C
As
I
can
tell
that
will
work.
The
only
hitch
right
now
is
that
some
of
the
release
assets
from
ASO
aren't
published.
Yet
like
the
docker
image
and
the
crd
Manifest
in
particular.
Those
are
the
things
we
need
so
I
think
it's
still
in
a
somewhat
broken
state,
but
I
think
we're
at
least
moving
forward.
A
So
you
know,
obviously
we
could
still
get
hung
up
on
something
but
I
think
I.
Think
things
are
looking
pretty
good,
that
we'll
be
able
to
merge
it
that
we'll
be
able
to
catch
up
with
cappy15-
and
you
know
they're
not
here
but
hurray-
for
the
ASO
team
for
aggressively
jumping
on
that
and
getting
it
done.
I'm
really
impressed.
A
Please
feel
free
to
interrupt
me.
I
just
have
a
couple
more
weird
topics
here,
so
we
have
support
now,
as
you
may
know,
for
Mariner
in
image.
Builder
and
I
have
tested
it
by
hand
with
cap
Z
and
it
seems
to
work
fine,
I
guess.
My
next
question
is
and
probably
not
something
we
could
resolve
here,
but
I
just
want
to
hear
what
people
are
thinking
is.
Should
we
start
publishing
Mariner
images?
A
Currently
we
only
publish
Ubuntu
images
as
reference
images,
but
perhaps
we
should
start
publishing,
mirror
images
alongside
of
that
or
we
could
maybe
choose
to
publish
them
to
a
community
shared
image
gallery
which
jumping
ahead
is
the
way
of
publishing
images
that
we
would
like
to
get
to
at
some
point
soon.
A
So
David
Justice
actually
was
making
the
argument
that,
even
though
that
proposal
is
still
out
there
and
we
don't,
we
aren't
completely
sure
how
we
want
to
publish
stuff
to
Shared
image
gallery.
We
could
perhaps
jump
the
gun
and
start
publishing,
mirror
images
there
for
Intrepid
people
who
want
to
start
working
with
Mariner
and
then
we'd
have
a
and
then
eventually
when
we
change
our
publishing
scheme.
So
everything
goes
there,
Mariner
World
in
there.
So
if
anybody
has
any
that's,
that's
my
little
brain
dump.
A
E
A
To
publish
to
the
marketplace
is
actually
a
yes
or
no
decision
that
we're
gonna
that
we
should
make
today
because
I'm
gonna
do
the
patch
releases,
so
the
pipeline
we
have
right
now.
Mariner,
luckily,
is
just
another
variable,
so
we
can
just
say
instead
of
Ubuntu
publish
Mariner
to
the
marketplace,
so
actually
it's
actually
Marketplace
publishing
doesn't
isn't
going
to
take
any
more
work.
It's
just
a
decision.
E
E
F
A
If
we
want
to
publish
like
I
said,
if
we
want
to
publish
to
Marketplace,
it's
essentially
no
more
work
because
I'm
going
to
do
that
for
Ubuntu
today,
and
it's
just
going
to
be
adding
a
couple
more
jobs.
If
we
want
to
publish
the
shared
image
gallery,
I
guess
the
way
I
would
do
that
right
now
is
I
would
run
image.
A
Builder
locally
I
would
probably
publish
it
from
my
machine
out
there,
which
is
not
you
know,
The
Next
Step
would
be
to
capture
that
workflow
and
put
it
in
a
pipeline
and
run
it
in
an
Azure
pipeline.
A
We
could
do
and
that
would
take.
You
know
not
a
lot
of
time
an
hour
or
two,
and
the
only
the
only
calculation
would
be
making
sure
that
the
community
image
gallery
we
set
up
is
kind
of
the
Final
Destination.
So
we
don't
have
to
move
things
around
when
the
proposal
lands
and
we
eventually
make
that
our
overall
destination
well.
A
No
I
guess
we're
to
some
extent
we're
increasing
our
support
burden.
If
we
make
these,
you
know
official
images
right,
then,
presumably
we
start
getting
a
lot
of
questions
about
hey.
Mariner
is
not
working
for
me
here.
How
do
I
do
this,
so
I
I
think
the
only
trade-off
is
that
Network,
even
though
we
call
them
reference
images,
meaning
please
don't
you
know,
rely
on
these
for
your
production
system.
In
effect,
people
are
using
them
all
the
time
and
are
going
to
report
bugs
against
them.
So
that
would
be
I
think
that's
the
only
trade-off.
A
D
E
Okay,
well,
I,
think
I
think
we
should
I,
think
I
think
Matt.
Let's,
let's
have
a
just
another
chat
later,
because
I
I
think
there's,
like
you
said:
there's
the
the
support
side
of
things
and
I
know
there's
others
at
least
inside
of
Microsoft
that
have
an
interest
in
that
too.
So,
let's
Maybe
talk
about
that
off
off
the
community
meeting.
A
Sounds
good
it's
some
of
this
is
inside
baseball
for
Azure
I
guess,
because
a
lot
of
the
people
are
going
to
want
to
use
it
or
first
party
customers,
but
but
yeah.
There's,
no
real
urgency
it'd
be
good
to
decide.
You
know
in
a
week
or
so,
if
we're
going
to
do
it
or
not
this
time
around,
but
thanks
for
your
thanks
for
your
thoughts.
I
guess
we'll
talk
about
it
more
any
other
questions
about
that.
A
And
then
this
last
one
is
truly
random
and
and
there
it
is
there,
because
someone
I
was
working
with
was
asking
about
cdk
Cates,
and
maybe
nobody
knows
anything
about
it
and
I
should
have
asked
this
at
the
Cappy
meeting
yesterday,
but
I
just
thought
of
it
now.
So
if.
A
Let
me
know
here
or
offline
for
a
little
bit
of
context.
Cdk
is
Amazon's
sort
of.
A
Terraformish
type
library
for
declaring
infrastructure
in
actual
code
like
programming,
language
code,
python
or
whatever,
and
then
having
it,
emit,
kubernetes,
manifests,
and
so
in
theory,
something
like
that
could
be
divorced
from
Amazon
specifics
and
could
maybe
also
publish
cluster
API
objects.
That's
the
only
thought
and
then
once
we
were
talking
about
it,
we're
like
someone
must
have
thought
about
this
or
tried
it
and
either
it's
a
good
or
bad
idea,
and
so
I'd
like
to
we'd
like
to
find
that
out
before
we
went
any
further.
A
A
I
guess
we
should
fly
over
and
do
Milestone
review
I'll
try
not
to
oh
go
ahead.
David.
E
I
was
just
gonna
ask
John
like
if,
in
terms
of
the
ASO
integration
and
the
install
like
when,
when
would
that
light
up
in
terms
of
it,
it
actually
being
present
like
the
actual
ASO
dependencies
themselves,
where
someone
could
theoretically
use
ASO
and
capacity
together.
C
So
there
is
a
whip
PR
open
to
do
that
to
like
actually
enable
all
the
ASO
stuff
that
is
not
ready
now,
but
hopefully,
by
the
111
release.
That
would
be
ready
to
go.
E
Will
that
allow
or
enable
as
it
stands
or
maybe
that's
the
plan
to
where
you
can
configure
various
CR
like
configure
anything
you
can
configure
with
the
ASO
Helm
chart,
or
at
least
the
crd
pattern,
to
be
configurable
upon
the
install
or
no.
C
The
crd
pattern
itself
like,
if
you
just
do
closer
CTL
and
knit
I,
don't
think,
there's
a
way
to
tweak
that,
but
I
think
it
would
be
fair
after
the
fact
to
edit
the
ASO
deployments
to
have
that
install
any
extra
crds
I
haven't
tried
that
so
I
don't
know
if
that
would
cause
any
issues
with
cap
Z,
but
it
seems
like
that
would
be
a
possible
way
to
use
more
resources
than
just
what
cap
Z
needs
and
configures
automatically.
E
Yeah
I,
don't
I,
think
I
have
something
we
should
Target
because
we
like.
We
should
be
clear
at
what
what
resources
we
are
installing
effectively
from
ASO
and
then
that
way.
If
people
want
to
install
something,
that's
totally
unrelated,
they
just
need
to
enable
the
crds
for
it,
and
then
there
should
be
good.
E
I
don't
conflict,
it's
like
if
I
want
to.
If
I
want
to
install
you
know
mySQL
database
I.
This
should
be
zero.
Zero
conflict
with
cap
Z.
You
know.
A
All
right
any
other
discussion
topics.
A
All
right,
let's
do
Milestone
review
I
promise,
I
promise
not
to
get
to
detailed
I
know
this
can
turn
into
a
drag
pretty
quickly,
but
the
stuff
that's
in
the
Milestone
I
feel
like
is
still
pretty
new,
and
so
it's
hopefully
we
don't
have
a
lot
of
changes
here,
but
let
me
just
scroll
over
it
and
if
one
of
these
things
is
already
not
in
scope,
please
let
me
know,
but
I
think
these
are
all
still
being
worked
on
actively.
It
looks
like
I'm,
certainly
trying
to
get
SDK.
A
E
I
think
now
would
be
a
good
time
to
maybe
do
the
bug
triage
because
it's
been
a
while,
since
we've
done
that-
and
there
is
a
under
the
project
report-
there
is
like
a
issues
thing
or
you
can
just
go
to
issues
with
bugs
I
guess.
But
if
you
go
to
the
project
board,
you'll
have
a
little
more
field,
so
you
can
tweak.
E
Because
bugs
sometimes
you
know
we
should
just
and
since
we're
resetting
on
the
Milestone,
you
know
bugs
is
maybe
a
good
to
just
see
if
there's
any
high
level
ones
or
ones.
We
need
to
triage
that
are
in
there.
A
E
A
yeah
there's
actually
a
view,
I
believe
it's
bugs.
If
you
that's
all
so,
if
you
scroll
to
the
different
view,
there
should
be
like
a
triage
or
a
bug.
I
think
you
I
have.
F
A
A
E
I
think
that
we
should
we
should
we
should
address
when
we
start
to
do
the
performance
testing
stuff
with
the
controllers,
because
we
have
a
bunch
of
we
have
a
bunch
of
work
in
the
ASO
testing
like
planned,
for
like
performance
with
crds,
like
that's,
that's
where
I
think
we
can
weave
this
in
to
the
testing.
E
And
maybe
just
go
to
the
oldest
issue
first
and
then
just
kind
of
work
up.
A
They're
getting
older,
but
they
all
right
well,
I'll,
just
so
we
got
the
memory
leak
in
the
controller.
This
I
think
this
was
on
the
Milestone
that
got
removed
and
that
wasn't
intentional
yeah
this.
This
should
have
moved
to
the
next
milestone.
A
E
So
if
you
look
to
the
scroll
to
the
the
right,
there's
a
it
has
a
mouse.
If
it's
in
part
of
the
Milestone
or
not,
you
can
actually
see
the
column.
D
A
D
Probably
not
because
we
have
to
wait
for
it
to
be
in
Kathy
and
that's
what
I'm
working
on
right
now
gotcha
and
then
after
that
then
I
have
to
start
working
on
the
cap.
Z
version.
A
F
F
A
D
E
I
think
I
think
that's
fine.
Is
there
any
PR's
that
are
in
unknown
status?
I
think
there
were
some
if
I
remember,
I
saw.