►
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
A
A
All
right,
just
because
I
see
Milestone
review
here,
I
was
thinking
about
it.
We
didn't
actually
yet
open
the
testing
for
PR
to
enable
a
1.6
Milestone
and
have
that
be
our
main,
so
I
was
just
doing
that.
So
so
maybe
we
don't
have
Milestone
review
today
unless
we
want
to
start
from
scratch,
but
I
think
the
process
is
you're
supposed
to
open
a
test
in
for
PR
first
and
then
that'll
create
the
milestone
for
us.
It's
the
proper
way.
A
B
C
A
D
D
C
Cool,
so
my
take
on
this
is
that
this
is
epic-ish
and
I
would
think
that,
to
the
extent
that
we
can
continue
to
move
this
forward
kind
of
with
say,
sixty
percent
of
of
the
assignees
focus
and
then
allow
a
little
bit
of
overhead
for
other
sort
of
more
near-term
pressing
items
to
be
worked
on.
So,
if
you're
going
to
work
on
this,
which
would
be
amazing,
some
some
arrangement
like
that
would
make
the
most
sense
so
from
a
priority
standpoint.
I
would
say
this
is
from
a
medium
term
standpoint.
C
C
D
C
E
So
I
kind
of
feel
selfish.
In
saying
that
you
know
a
higher
priority
from
that
perspective,
so
I
think
that
if
we
have
a
kind
of
maybe
a
slightly
higher
priority
is
kind
of
building
out
the
framework
to
allow
people
to
do
this,
and
that
would
allow
you
know
people
who
needed
this
functionality
to
to
bring
it
themselves.
So
you
know
I
I
could
have
a
teammate
of
mine,
say:
hey
yeah,
you
know
we
want
this,
come
in.
E
C
What
I
see
is
that
the
longer
we
don't
have
a
way
to
expose
preview
features
in
AKs.
We,
you
know,
there's
just
a
sort
of
baked
in
risk
that
our
Azure
managed
cluster
customers
aren't
going
to
need
these
preview
features,
but
I
I
suspect
that
that
will
change
at
some
point
and
that
a
feature
will
land.
That's
preview,
that's
deemed
to
be
extremely
valuable
and
then
we're
in
a
position
where
we
have.
We
literally
have
no
way
to
expose
those
features
because
we
haven't
done
the
the
engineering
work
to
lay
that
surface.
C
You
know
I
think
that
John
and
I
and
and
Cecile
and
some
other
folks
have
gone
through
a
kind
of
intellectual
exercise
of
imagining
how
this
could
happen,
and
so
we
have
a
decent
idea
that
it's
feasible
and
how
much
work
it
might
cost.
You
know
I,
said
earlier
three
months
or
so,
but
I
think
we're
at
the
point
where
those
intellectual
assumptions
need
to
be
tested
with
a
little
bit
of
just
rolling
up
the
sleeves
and
poking
around
does.
C
Ahead
so
I
agree
with
you
100
that,
and
we
can
make
this
clear
in
the
issue
that
really
this
issue
is
to
expose
the
that
preview
API,
which,
as
far
as
I
can
tell
is
more
or
less
I
mean
this
needs
some
explore.
Exploratory
work
as
well,
but
as
far
as
I
can
tell
it's,
it's
feature
compatible
with
the
ga
API,
so
maybe
the
scope
of
that
work
could
be.
C
You
know
the
the
equivalent
of
turning
on
your
preview,
like
when
you
you're,
using
the
CLI
just
running
that
command.
That
basically
enables
the
preview
API,
which
essentially
redirects
your
AZ
AKs,
calls
I'm,
still
I'm
thinking
of
the
CLI
here
to
the
preview
API,
but
the
existing
interface
with
the
ga
API,
as
far
as
I
can
tell
is,
it
might
not
be
100
compatible,
but
it's
very
close
to
100
compatible.
So
you
can
use
GA
features
against
the
preview
apis
as
far
as
I
understand.
So
that
could
be.
C
The
scope
is
to
just
allow
the
preview
API
in
cap
Z.
You
can
declare
it
somewhere
in
your
spec
with
no
additional
features
and
then
the
preview
features
can
probably
be
implemented.
Like
we're
doing
now
with
GA
features
according
to
to
customer
priority
and
our
own
sense
of
priority
I
know,
there's
a
lot
to
take
notes.
Was
that
sort
of
clearish
for
folks
just
my
thoughts.
D
C
C
D
C
Yeah,
the
easiest
test
is
just
to
literally
go
through
the
SDK
and
look
for
preview
features,
and
you
just
won't
see
it
in
the
GI
API
versions.
They
don't
exist,
so
that's
the
matriculation
process.
So
that's
when,
when,
as
an
AKs
customer,
you
like
wire
your
client
environment
to
enable
preview
features
you're.
Essentially
you
know
redirecting
where
your
underlying
API
and
endpoint
is
going
to
go
to
when
it
makes
those
make
S
requests.
D
Yeah
yeah
I
think
so
so
yeah
I
think
I
think
I'll
I'll
take
on
this
effort
for
now
at
least
and
then
so
yeah
I
can
start
kind
of
flushing
out
what
the
API
might
look
like
and
I'll
definitely
make
sure
to
ask
her
feedback
on
that.
So
stay
tuned
yeah,
that's
all
I
had
for
just
does
anybody
else
have
any
last
thoughts.
A
A
C
C
and
what
it
Cappy
1.2
enables
this,
which
allows
for
more
Atomic
operations
against
sets
of
things
I'm
going
to
go
with
things
so
that
subnet
spec
up
there
that
was
actually
a
good
or
that
right
there
yeah,
but
yeah
line
140
in
types
dot
go.
You
can
see
that
this
so
This
PR
hasn't
been
merged
because
we're
not
the
the
set
of
folks
who
are
here.
C
Basically
Cecile
is
still
on
vacation
I'd
like
to
get
her
thoughts,
Cory
merges
because
it
will
have
a
change
in
behaviors,
but
that
subnets
type
up
there
is
the
type
of
atomic
sort
of
resource
set
that
is
subject
to
Edge
conditions
when
not
using
what
kubernetes
called
server-side
apply,
and
so
those
decorations
that
are
added
as
part
of
this
PR
or
essentially
pragmas
that
instruct
the
server-side
apply
functionality
how
to
uniquely
operate
against
items
in
that
set.
So
in
this
case
the
set
is
an
array
of
subnet
spec
atomically.
C
So
what
we're
doing
essentially
is
telling
the
server
side
apply
what
type
of
data
set
it
is.
So
that's
where
the
list
typical
is
map
and
the
key
is
the
unique
key.
So
this
this
allows
sort
of
deterministic
exclusive
access
to
items
in
that
set.
So
when
they're
controllers,
multiple
controllers
operating
concurrently
across
items
in
that
set,
they
can
essentially
take
out
exclusive
locks
on
particular
items.
C
So
without
these
this
pragmas,
when
you
have
crds
that
are
being
mutated
concurrently
by
multiple
controllers,
as
you
can
imagine,
the
the
atomic
transaction
is
is
indeterminate,
so
As,
One,
controller,
I,
start
operating
against
one
item
in
that
set
I
do
some
work
and
I
then
update
the
set
with
the
updated
item.
Another
controller
may
be
operating
on
that
same
item
or
a
different
item
in
that
set
and
without
any
sort
of
way
to
synchronize
those
behaviors
as
discrete
Atomic
transactions.
C
I
feel
like
I'm,
a
poor
computer
science
teacher
at
a
JC,
or
something
trying
to
describe
this
conceptually
so
the
the
tldr
is
that
we
don't
understand
we're
not
confident
without
some
more
thoughts
from
Cecile,
maybe
some
folks
from
Cappy.
This
was
identified
by
cluster
API
itself,
so
it
was
very,
very
generous
of
them
to
actually
do
an
audit
of
our
code
as
they
were.
Implementing
the
server-side
apply
functionality
in
one
two
and
they
identified
subnets
as
being
the
only
thing
there
was
another,
as
you
can
see,
there's.
C
Actually
this
was
a
quite
a
stream
of
stuff,
but
there's
a
there's.
Another
type
Edition
there
under
Neath
period
appearing
sample,
spec
and
I-
think
there
may
be
one
more
so
essentially
I
identified
the
the
properties
that
are
set
properties,
I,
think
you've
seen
in
some
other
folks
in
Cappy
did
some
more
auditing
and
identifying
the
subnets
is
the
only
one
that
is
subject
to
multiple
controller
operations.
So
that's
really
the
the
conditions
under
which
you
need
to
worry
about
this.
C
I,
you
know,
we've
been
using
one
point,
so
this
shipped
with
1.2
of
Cappy
and
and
cap
Z
I
did
the
work,
so
I
can
speak
to
it.
Capsi
pin
to
1.2
a
couple
months
ago,
six
weeks,
maybe
so
and
I
think
the
easiest
answer
is
that
we
just
don't
have
test
signal
for
this
particular
race
condition.
So
we
I
don't
think
that
we
know
whether
or
not
the
code
is
subject
to
it.
C
So
we
definitely
want
to
test
it.
Given
that
lack
of
knowledge
and
then
perhaps
work
with
Cappy
to
this
is
the
kind
of
thing
that
would
probably
be
a
combination
of
functional
and
and
testing
I
mean
it's
pretty
low
level,
but
obviously
fairly
nasty.
So
you
want
to
make
sure
that
that
we're
doing
this
in
the
right
way.
B
B
So
what
happens
is
once
the
capture
reconciler
Works?
They
actually
pull
in
other
couple
of
details
like
cider
block
and
stuff,
like
that
and
writes
it
back
to
that
subnet
slice,
but
once
it
is
done,
Cappy
topology
controller
will
still
say:
okay,
there
is
a
dip
and
it
will
update
it
back.
So
essentially,
there
are
two
things:
one
is
having
ownership
of
that
particular
ID
or
that
particular
field
in
the
subset.
B
B
B
So
I'll
get
back
onto
this
I
think
I'll
I'll
try
to
deploy
a
cluster
class,
so
provisioning
is
not
blocked,
so
you
will
end
up
creating
a
cluster,
but
it
will
just
oscillate
like
this
is
what
I
think
will
happen,
because
this
happened
with
cap
a
because
you
know
Cappy,
topology
controller
will
continuously
start
to
patch
it
yeah,
but
but
you
know,
I'll
get
back
on
this
I
think
it
should
be
pretty
quick
to
test
it.
Yeah.
That's.
C
Fantastic
and
if
you
could
comment
on
so
there's
a
if
you
could
go
back
to
the
change
that
Matt
there,
there
I'm
going
to
go
a
little
bit
deep
at
this
point,
so
we
essentially
tried
to
mimic
kappa's
solution
to
this.
So
I
think
this
is
solved
in
Kappa,
at
least
in
Maine,
I'm,
not
sure
if
they've
released
and
and
that's
what
you
see
in
the
the
cluster
API
docs-
that
as
an
example
of
what
providers
must
do
when
adopting
1.2.
C
That's
either
read-only
or
not
required,
and
so
the
way
we
kind
of
hack
around
that
in
cap
Z
when
we
create
subnets
is
we
pass
the
subnet
spec
to
Azure
and
then
in
the
payload
response
we
get
with
the
201.
We
then
update
our
representation
of
the
data
type
with
the
authoritative
information
from
azure
and
we
Define
the
front-end
spec
of
this
data
type
like
you
can
see.
If
you
look
at
that,
you
go
drill
down
to
that
subnet
spec.
C
You
can
see
that
the
ID
property
is
marked
as
read
only
so
from
a
user-facing
point
of
view.
It's
read
only
and
the
the
generator
code
doesn't
like
a
list
map
key
value
with
a
property.
That's
read
only
so
that's
sure
if
we
were,
if
we
were
able
to
do
that,
we
would
have
already
merged
it,
because
that
makes
perfect
sense,
so
we're
trying
to
find
a
user
and
basically
a
required
user,
accessible
value.
C
C
C
Can
you
have
I
think
for
control
plane,
there's
only
going
to
be
one
control,
plane,
subnet,
that's
just
baked
into
the
architecture,
I'm,
less
sure
about
the
the
node
role
type
are
there?
Does
it
make
sense
on
on
a
single
cluster
to
have
multiple
subnets
each
with
the
role
of
node
I?
Think
it's
node
is
the
allowed
value.
B
C
B
B
B
C
B
C
Would
want
to
make
sure
that
we
might
be
doing
that,
but
we
might
maybe
it's
possible
that
we
shouldn't
be
doing
that
and-
and
if
that
were
the
case,
then
that
would
not
be
the
correct
so
like
maybe
in
the
future.
An
orthogonal
work
effort
would
be
like.
Oh
I
need
multiple
node
subnets
and
we're
like
cool.
We
can
do
that
we'll
just
remove
the
web
of
validation
that
that
prevents
that
and
then
we've
now
broken
this
in
a
in
a
way,
that's
really
hard
to
correlate.
C
A
Cool,
thank
you.
I
got
a
question.
So
does
this
so
we've
entered
in
1.2
a
long
time
ago,
but
we
never
clued
into
this
until
recently.
Does
that
point
to
a
gap
in
e2e
test?
Do
we
not?
We
do
have
a
cluster
class
test,
at
least
through
Cappy,
but
we
never
triggered
this
bug.
As
far
as
I
can
tell.
Does
that
mean
we
have
e2e
gaps?
We
need
to
fill.
A
B
B
C
C
Well,
maybe
I,
didn't
describe
it
well,
because
that's
actually
that
wasn't
my
understanding.
So
we
want
to
get
clarity
on
that.
I
described
it
in
a
different
way,
where
updates
to
that
subnets
resource
are
going
to
be
concurrent
updates
are
going
to
be,
you
know,
only
one
will
win
that
race,
and
so
one
updated
in
that
concurrent
set
will
be
one
or
more
will
be
dropped
depending
on
how
much
concurrency
we're
talking
about.
C
So,
if
that's
not
true-
and
it's
it's
more
like
just
thrashing
it's
not
able
to
determine
that,
there's
no
diff,
essentially
when
it's
doing
its
reconciliation,
then
that
is
a
I
mean,
that's
something
we
would
want
to
fix,
and
we
we
could.
We
could
write
a
test
to
detect
those
that
kind
of
thrashing.
B
A
B
B
C
Anyone
that's
awesome,
I
I'll,
be
there
I,
don't
know
exactly
yet,
which
is
a
problem
and
also
probably
predicts.
The
answer
is
known.
So
there
was
a
Cappy
talk
that
was
rejected
and
then
later
accepted,
which
means
that
you
have
to
go
to
your
management
chain
at
the
last
minute
and
get
a
budget
approval.
So
does
anyone.