►
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
Everybody
see
the
agenda
all
right
good
morning
afternoon
evening,
whatever
it
is
where
you
are
welcome
to
the
cluster
API
azure
provider
weekly
office
hours
meeting.
A
We
are
a
project
of
the
Sid
cluster
life
cycle
umbrella
project
and
therefore
we
abide
by
there
General
code
of
conduct,
which
you
probably
are
familiar
with,
but
it
boils
down
to,
let's
all
be
polite
to
each
other.
Try
to
use
the
raise
hand
feature,
so
we
don't
talk
over
each
other
Etc
yep.
A
We
have
this
meeting
every
week
and
thanks
for
being
here,
if
you
wouldn't
mind
adding
your
name
to
the
attendee
list,
it
just
helps
people
clue
in
who
everyone
else
is
and
what
they
do
and
maybe
Network
later
do.
We
have
anyone
here
who's
here
for
the
first
time
who
wants
to
just
unmute
and
say
hello,
I
will
be
quiet
for
a
second
to
give
you
an
opportunity
to
do
that.
A
Not
all
right,
let's
move
on
first
discussion
topic:
John:
do
you
want
to
talk
about
priority
in
the
issue?
Queue.
B
Yeah
so
recently,
I
started
looking
for
a
new
issue
to
pick
up
and
found
it
kind
of
hard
to
figure
out
what
was
important
based
on
like
labels
and
Milestones
or
anything
else.
That's
easy
to
filter
on
in
the
queue
so
I'm
wondering
if
others
would
find
it
helpful
to
have
some
sort
of
canonical
way
to
express
which
issues
are
most
important
in
the
immediate
term
and
does
that
even
make
sense,
given
everyone
kind
of
has
their
own
sense
of
what's
important
to
them.
A
I
do
if
no
one
else
does
yeah
go
ahead.
Jack.
C
I
I
think
that
in
the
community's
Spirit,
let's
bypass
the
whole,
how
do
we
figure
out?
Which
person's
version
of
important
is
the
most
important
and
just
trust
that
if
someone
is
willing
to
stick
their
neck
out
and
say,
this
is
important
that
it's
important
and
we
can
figure
out
if
we
need
to
optimize
later
on.
D
I,
pretty
much
I
mean
I
agree
with
what
Jack
said,
but
at
the
same
time
one
of
the
things
that
I
came
across
with
yesterday
I
think
it
was
is
I
was
trying
to
kind
of
figure
out.
You
know
what
I
could
help
work
on
to
help
get
the
AKs
part
of
it
outside
of
beta
without
saying
hey.
What
can
I
do
to
help
get
this
outside
of
you
know
experimental,
so
some
sort
of
prioritization.
D
Sort
of
would
be
useful.
You
know
for
what,
when
there's
initiatives
would
be
good,
I,
don't
know
if
necessarily
have
features
overall,
but
just
does
that
make
sense.
B
Yeah
that
makes
sense
to
me
where,
like
we
might
not
want
to
like
load
up
a
milestone
and
then
prioritize
things
that
way,
but
yeah
I,
think
kind
of
having
bigger
buckets
of
like
okay.
This
is
the
AKs
stuff.
That's
important
and
yeah
having
I
think,
initiatives
like
that
does
make
sense
to
me.
Go
ahead.
Jack.
C
Yeah
I
think
for
for
epic
style,
using
a
sort
of
you
know,
scrum
jargon
for
epic
style
issues
and
and
work
streams.
C
It
might
make
sense
to
just
spin
off
a
GitHub
project
for
each
of
those
and
then
each
of
those
efforts
can
sort
of
self-organize
and
Define
how
to
prioritize,
because
often
that
that
is
the
sort
of
that's
where
I
think
prioritization
can
benefit
the
most,
at
least
in
my
experience
when
you're
working
week
over
week
or
month
over
month
toward
a
common
goal,
you
get
into
a
really
really
nice
sort
of
working
cruising
altitude.
Where
he's
like
I.
Did
this
thing?
What's
next?
C
Okay,
let's
do
that
thing
and
because
there's
a
common
sort
of
context
to
what
you're
working
towards
it
allows
you
to
kind
of
be
slightly
to
leave
your
sort
of
critical
mind
behind
when
you
pick
an
issue
because
you're
just
like
all
right,
I'm
gonna
trust
the
PM's
gonna
pick
me
a
good
issue.
I
know
this
whole
surface
area.
Well,
I'm
just
going
to
do
this
work,
so
you
kind
of
get
into
that
mode,
whereas
for
the
entire
like
for
an
entire
open
source
project,
it
can
be
harder.
C
It
just
becomes
really
I
think
the
the
inputs
for
assigning
a
reasonable
priority
across
issues
becomes
harder
because
the
inputs
are
including
things
like.
Okay.
What
is
this?
Where
does
this
issue
fit
into
the
sort
of
meta
work
streams?
If,
if
AKs
is
more
important
than
I,
don't
know
what
else
would
be
more
important
in
KFC
right
now,
but
then
you
have
to
like
do
sort
of
multi-dimensional
stack,
ranking
which
can
be
complicated.
C
So
that
was
a
lot
of
language.
I.
Think
tldr
for
me,
is
maybe
in
the
spirit
of
like
experimentation.
Maybe
we
could
spin
off
the
AKs
effort
into
its
own
project
and
the
folks
are
especially
interested
in
that
can
self-govern
how
to
prioritize
those
issues
and
maybe
share
that
regularly
with
the
community
and
if,
if
there's
a
model,
that
makes
sense,
maybe
that
can
be
generalized.
A
I'm
going
to
say
something:
I
updated
Zoom
just
now,
and
I
literally
can't
find
the
raised
hand
feature
I
hate
this
UI
sorry,
so
let
me
interrupt.
We
also
have
I
mean
maybe
everybody's
fully
aware
of
this,
but
we
have
you
know
these
tags
here
that
are
common
to
most
of
the
proud
projects.
Priority
backlog,
Etc
that
we
just
haven't
been
using
these
run
kind
of
or
effectively
and
I'm
sure
you
all
know
the
way
we've
been
prioritizing.
A
B
A
B
I
think
that's
definitely
one
one
way
to
go
about
that,
but
yeah
I
think
I
I
kind
of
like
Jack's
idea
of
like
with
the
AKs
stuff,
in
particular,
let's
kind
of
put
that
stuff
in
a
bucket,
and
then
we
can
kind
of
figure
out
how
that
stuff
should
go
and
then
like.
If
the
labels
work
really
well,
then
yeah
I
can
see
where
that's
something
we
could
apply
it
more
broadly.
A
C
I,
like
those
labels,
I
think
we
would
probably
have
to
discuss
as
a
community
what
those
mean
for
cap
Z
in
particular,
but
one
thing
I
can
imagine,
is
as
someone
especially
like
I
think
from
a
from
a
contributor
point
of
view,
the
most
common
orientation
you
are
in
terms
of
the
project
is:
can
I
get
my
PR
reviewed?
When
is
it
going
to
land
like
those?
Those
are
really
interesting
things,
and
usually
contributors
don't
like
to
just
shout
like
when
someone
helped
me.
C
C
C
What
do
you
think,
Matt
and
folks
who've
been
here
for
a
long
time?
I
would
imagine
one
of
the
reasons
why
we're
not
using
these
sort
of
standard
priority
labels
that
we
have
access
to
is.
C
Maybe
the
project
hasn't
been
big
enough
until
now,
where
we
could
just
kind
of
handle
this
in
real
time,
because
there's
three
or
four
folks
who
are
primarily
responsible,
but
now
that
we're,
if
we're
12,
16
20
folks,
deep,
who
are
interested
in
the
project
and
the
lack
of
priority
labels
is
sort
of
more
conspicuously
absent.
You
know.
A
I
think
that's
true.
If
up
until
now,
it's
more
or
less
been
the
case
that
if
we
can't
sort
of
assign
the
work
within
the
group
of
reviewers
and
maintainers
and
regulars
that
we
just
market
help
wanted
and
that's
sort
of
that
sort
of
worked
okay
up
until
now,
but
maybe
not
anymore,
and
we
should
still
use
help
wanted.
But
I
see
the
need
for
more
for
priority
labels
or
something
like
that.
C
D
Yeah
I,
just
as
a
recent
new
contributor,
you
know
and
don't
take
this
as
pressure
to
review
my
PR
having
a
general
idea
of
timelines
for
PR
review
reviews
and
that
kind
of
thing
with
those
kind
of
priority
tags
would
be
really
beneficial,
because
then
I
would
know
that.
A
A
E
A
B
A
I,
don't
all
right
next
issue
has
been
here
for
a
long
time
and
done
tons
of
work,
and
we
would
like
to
make
him
a
reviewer
I
assume
this
is
a
no-op,
but
just
want
to
make
people
aware
of
that,
and
unless
someone
has
an
objection,
let's
go
ahead
and
merge
this
yeah.
A
E
I
would
say
thanks
to
Matt,
Jack
and
Cecilia,
and
everybody
else
who
helped
me
navigate.
So
thanks
a
lot
I'm
learning
quite
a
bit
as
all
things.
Thank
you
thank.
A
You
there's
a
there's
a
couple:
other
follow-up,
PRS
I'll
create
now
that
are
super
uninteresting,
but
there's
several
other
kubernetes
projects
where
you
have
to
update
basically
the
same
list.
It's
super
annoying
but
I'll
I'll
CC
you
on
this.
A
C
A
Cool
next
item,
just
yesterday
at
the
Cappy
meeting
they
were
talking
about,
is
probably
not
productive.
To
have
a
regularly
scheduled
meeting
during
kubecon
week
wondering
if
we
should
do
the
same
thing.
The
following
day.
E
C
Yeah,
maybe
we
can
say
reach
out
to
Matt
or
Cecil
or
myself.
If
you
want
to
host
this
meeting
without
us,
and
we
can
work
out
a
way
to
get
you,
maybe
the
credentials
to
do
that,
but
otherwise
by
default
will
cancel
okay.
A
I
agree:
I'll
actually
be
here,
so
if
we
do
want
to
do
a
meeting,
I
could
host
it,
but
I
guess
that
constitutes
canceled
by
default.
Unless
people
on
slack
disagree,
which
would
be
fine
all
right,
should
we
do
a
patch
release
or
the
SSA
change
I.
Think
probably
yes,.
E
Yeah,
like
we
had
a
discussion
last
week
on
slide
with
Cecil,
and
we
were
kind
of
in
a
split
yeah.
The
brain
situation
like
because
this
particular
PR
is
an
API
change,
but
also
at
bug
fix
right.
So
you
know
we
wanted
to
like
hear
from
everyone
else
like
what
do
they
think
about
this?
E
As
far
as
I'm
concerned,
I
may
be
biased,
because
there
are
a
lot
of
things
that
are
kind
of
blocked
Downstream,
because
of
this
like,
we
are
trying
to
validate
a
lot
of
things
around
cluster
class.
So
all
of
pipelines
are
red
and
yeah
I
mean
I'll
stay
out
of
it
in
terms
of
like
what
would
be
the
best
practice.
So,
let's,
let's
decide
and
come
to
a
consensus.
A
C
I
I
think
it's
actually
kind
of
controversial.
Can
you
can
you
State
the
case
for
this
not
being
breaking
ashtash
and
in
the
meantime,
when
is
1.6
due?
Is
it
do
we
have
another
month?
Is
it
November,
7th
ish
so
for
for
your
environment,
that
additional
three
weeks
or
so
would
be
a
big
ask,
sounds
like.
E
Yeah
I
mean
I'll
have
to
like
figure
out
other
ways,
because
I
have
three
weeks
should
be
a
long
time
but
to
your
question:
Jack,
it's
safe,
Breaking
Chains,
because
one
of
the
fields
were
removed
into
Azure
cluster
object
so
but
like.
If
you
see
the
Practical,
if
you
see
the
Practical
situation
like
I'm,
not
sure
like
how
many
users
are
actually
using
as
a
cluster
template
right
cluster
class.
So
these
were
kind
of
discussions
that
we
were
having
but
yeah.
It's
a
breaking
change
as.
C
Far
as
yeah
it's
it's
all
it's
it
gets
into
that
category
of
like,
strictly
speaking,
we
are
breaking
the
API
or
change
I
shouldn't
say
breaking
that's
like
a
loaded
word
we're
changing
the
API
yeah,
but
we
are
doing
it
in
a
way
that
is
not
user,
impacting
because
it's
embedded
trucks
and
better
trucks.
That
kind
of
thing
is:
has
the
pr
merged
to
Maine?
Yes,
the
pr
has
okay
great
well
once
again,
thank
you
so
much
for
that
that
that's
just
awesome
that
you
did
that
work,
so
let's
I
would
Advocate.
C
Let's
have
a
quick
breakout
today,
maybe
in
the
next
couple
hours
with
with
folks
in
cecile's,
not
here,
I'd
love
to
get
her
input
on
on
the
patch
issue.
I
I
tend
to
myself.
C
If
there's
a
practical
reason
to
do
it.
That
would
outweigh
like
a
sort
of
strict
if
it
strictly
violates
the
letter
of
the
law.
I.
Think
that's!
Okay!
If
we
can
find
a
practical
justification.
E
A
E
C
A
C
C
And-
and
this
is
all
documented
in
this
PRN
and
another
PR-
that
this
is
the
actually
the
direction
we
all
agreed
to
go
in,
so
that
right
there,
you
might
argue
that
that
additive
change
right
there
is
enough
to
sort
of,
if
you're
doing
a
letter
of
the
law
you
wouldn't
want
to
patch
that
in,
but
that's
actually
not
what
I'm
talking
about
and
I.
You
know
you
could
definitely
make
the
argument
that
practically
speaking,
that's
a
safe
petition.
D
Yeah,
this
is
the
one
where
it
changed,
name
right
from
moved
around
where
name
is
set
or
was
that
a
non-impacting
change
and
it
just
affected
the
the
spec
in
inside
the
code.
Oh
you're
right.
D
F
E
Yeah,
so
so,
basically,
what
we
did
is
we
pulled
out
the
name
field
that
was
there
in
the
subnet
spec
and
moved
it
to
subnet,
Prospect
so
technically
for
end
user.
You
know
it
doesn't
make
any
difference,
but
you
know
in
terms
of
course
structure
when
we
code
it
around.
It
makes
difference
like
and
we
have
two
objects
here.
One
is
as
or
cluster
template
and
one
is
azure
cluster.
So
when
we
use
cluster
class
as
Orchestra
object
can
be
created
by
using
this
as
a
cluster
template.
E
C
Yeah,
that
last
part,
is
the
key.
So
the
reason
why
moving
that
name
out
from
underneath
the
subnet
spec
and
then
adding
it
into
the
subnet
class
spec
is
because
subject
classes
I'm
going
to
make
sure
I
say
sorry,
setback
class
back
is
an
embedded
property
and
another
struct,
and
so
once
Things
Are
constructed
together
for
the
user-facing
API.
A
F
C
That's
exactly
right,
that's
the
sort
of
strict
letter
of
the
law,
but
the
reason
I
want
to
thank
you
for
demonstrating
this
Matt
and
and
talking
through
it.
I
just
wanted
to
give
any
other
folks
who
are
here
who
haven't
maybe
looked
at
this
an
opportunity,
because
this
is
kind
of
a
standard
pattern
and
go
to
to
voice
any
concerns.
Opinions,
thoughts,
foreign.
E
E
and
types
underscoreclass.go,
is
actually
used
in
as
Orchestra
template
apis,
and
we
want
to
have
a
sort
of
primary
key
kind
of
field
so
that
we
are
able
to
uniquely
identify
the
slice,
and
this
is
required
for
API
server.
You
know
to
do
a
server-side
apply
so
tldr
is
we
want
to
kind
of
uniquely
identify
this?
Not
really
like
the
we
said
we
want
to
help
it.
We
want
to
help
Cube
APS
server
to
uniquely
identify
it,
and
that's
where
you
see
there
is
a
tag.
If
you
scroll
up
Matt.
A
E
The
in
the
in
the
subnets
they
have
your
line,
one
three,
eight
yeah
yeah,
so
yeah.
So
that's
the
change
and
I
have
LinkedIn
issue
to
this
like.
If
this
is
not
there,
what
would
be
that?
That's
the
motivation,
part
and
yeah
Jack
explained
like
the
breaking
TV
box,
so
big,
pretty
glossy
favorite
questions.
F
If
someone
is
using
that
and
they
do
the
upgrade
if
this
is
broken
and
if
we
can
like
use
this
opportunity
to
provide
a
path
to
move
forward
where
we
can
do
right,
you
know
changes
on
API,
but
without
doing
any
breaking
things
like
keeping
it
I
know,
there's
no
new
API
type,
so
you
cannot
use
the
conversion
webbook
for
that.
But
still
can
we
just
keep
it.
The
old
old
stack
till
the
new
version
is
released
and
the
new
API
types
comes
in,
and
then
we
like
just
deprecate
that.
E
So
maybe
I
didn't
get
the
entire
part,
but
like
is
somebody
using
cluster
class
like
if
in?
If,
if
anyone
is
using
cluster
class,
it's
already
broken
and
if
you
know
someone
is
not
using
a
cluster
class,
then
it
should
be
all
fine,
correct
me
exactly:
okay,
that's
what
I
understand.
A
C
Right,
that's
right!
That's
that's
why
we
haven't
seen
this
except
for
for
your
scenario:
Ash,
maybe
some
other
folks,
cluster
class
adoption
isn't
like
100
at
this
point
and
our
and
and
test
don't
cover
this
particular
scenario.
It's
yeah
I'm
delighted
that
you
have
test
scenarios
all
at
some
point.
Maybe
bug
you
and
see
if
we
can
get
those
you
said
you're
saying
your
pipeline
is
red.
Now
I'd
love
to
get
our
pipeline
right
too,
so
to
speak,
foreign.
F
E
C
Yeah
to
be
super
super
clear,
my
what
I
want
folks
to
to
weigh
in
on
is
this.
The
changes
to
the
API
here,
the
this
is
definitely
fair
to
classify
as
a
bug
fix,
but
I
want
to
see
if
it's
a
bug
fix.
That
is
maybe
the
way
that
we
had
to
fix
this
bug
is
to
change
the
API,
which
we
literally
did
so
in
some
scenarios.
That's
the
kind
of
thing
that
you
wouldn't
actually
be
able
to
include
with
a
patch
release.
So
that's
why
I
want
folks
to
weigh
in.
E
A
Cool
any
other
comments
on
this
one.
Are
we
going
to
still
hold
people
in
slack
and
just
make
sure
no
one
objects
or.
C
Yeah
I
would
I'll
probably
do
myself
is
if
someone
else
doesn't
do
it
before
me
is
just
Loop
the
folks
who
wait
in
here
today
and
Cecile
in
like
the
next
half
hour
or
so,
and
just
give
folks
any
last
chance
to
Express
concern
before
I
tag
them
for
Cherry
picks.
A
A
D
Oh,
that's
just
a
PSA
from
yesterday's
Cappy
meeting.
D
There's
a
lot
been
a
lot
of
interest
Beyond,
just
the
stuff
I
brought
up
for
importing
clusters
for
managed
control
planes
and
so
we're
starting
some
conversations
about
that,
and
just
if
people
are
interested
in
participating,
there's
a
slack
thread
where
we're
starting
to
talk
about
trying
to
schedule
a
meeting
to
discuss
it
in
more
detail.
That's
all.
A
C
D
The
focus
will
be
on
managed
clusters,
not
not
the
non-managed
Clusters,
but
the
you
know:
AKs
eks,
that
kind
of
thing,
but
you
know
we'll
still
be
saying
no
for
the
other
type.
But
still
it's
a
start.
A
All
right,
let's
move
on
to
the
next
item,
econolo,
tell
me
if
I'm
getting
your
name
wrong.
Sorry
wanna!
You
were
talking
about
managed
cluster
and
cluster
class
last
time.
G
Yeah,
so
for
some
background,
my
my
team
is
planning
some
work
around
cluster
API.
We've
done
some
work
already
and
I
we're
looking
to
use
cluster
class
and
AKs
specifically
for
life
cycle
hooks,
so
that
the
issue
is
there
for
that.
I
created
is
to
add
that
support
and
just
want
to
follow
up
on
just
at
least
understanding.
G
You
know
level
of
effort
anything
our
team
can
do
to
help
or
pay
down
along
those
lines,
either
for
a
support
or
even
development,
so
we're
all
new
to
Cluster,
API
and
development.
So
we're
not
sure
really
is
this,
like
you
know
one
line
of
code
or
you
know
much
more
than
worry
type
deal.
A
C
A
Well,
I
mean
certainly
we're
here
to
help,
if
you
guys,
if
you're
able
you
and
your
team
are
able
to
get
going
on
it,
it
doesn't
look
trivial,
but
it
looks
like
Cecile
kind
of
has
her
head
around
it.
So
I'm
sure
that
means
it's
a
finite
amount
of
work.
G
A
G
Makes
sense,
is
there
any
I
guess
it
would
be?
You
know
next
steps
from
here
is
it
you
know
at
some
point
so
I'll
pick
it
up
and
start
to
break
it
down
or
just
really
just
trying
to
understand,
at
least
from
from
my
team's
end,
you
know
planning.
Is
it
something
kind
of
like
as
we're
creating
our
schedules
now
I'm
moving
forward?
We
just
want
to
make
sure
we
don't
accidentally
put
something
on
our
plate.
G
That's
a
blogger
and
we're
waiting
for
a
while,
and
if
there
are
things
that
we
can
do
in
the
meantime
to
help
push
this
forward
as
well.
We're
also
open
to
that
as
well.
A
I
mean
it
looks
like
some
of
these
things
are
potentially
separable,
like
the
second
paragraph,
where
you
should
see
if
we
about
moving
some
Fields,
although
that's
a
breaking
change,
so
that's
you
know
potentially
problematic,
but
it
does
look
like
this
could
be
broken
down
into
maybe
more
than
one
task.
C
So
it
does
it
there's
a
non-zero
chance
that
this
would
would
take
a
long
time
and
it
would
block
you
so
I
think
we
should.
We
should
just
be
pulling
in
the
right
folks,
so
as
an
example
that
that,
in
addition,
part
that
Cecile
mentioned
that
would
result
in
Breaking
changes
to
the
Azure
managed
cluster
API
like
full
stop.
So
we
may
want
to
do
that,
but
we're
going
to
want
to
we've
got
folks
on
this
call
right
now
we're
going
to
have
opinions
about
that.
So
you
know
Zane.
C
Are
you
going
to
want
to
change
all
of
your
Azure
manage
plus
respects
in
order
to
get
that
long-term
benefit
of
adhering
to
the
the
Cappy
standard?
You
know
same
question
to
you,
Mike
and
other
folks.
You'll
have
to
that'll
be
a
breaking
change
for
every
existing
Azure
managed
cluster
customer
that
might
be
part
of
the
contract.
You
know
we
all
are
aware
that
it's
experimental
but
I
think
we
just
want
to
have
a
conversation
about
that.
C
If
we
have,
you
know
significant
pushback
on
that
part,
then
this
may
be
harder
to
do
the
cluster
class,
so
I'm
gonna,
I'm,
gonna
wave
my
hands
a
little
bit,
but
the
the
Affinity
between
the
Azure
managed
cluster
spec
and
the
original
Cappy
specs
is
already
kind
of
it's
a
it's
not
quite
like
Square
Peg
round
hole,
but
something
like
that
and
I
I
think
that
with
cluster
class
it
gets
even
more
sort
of
difficult.
C
And
so,
if
we
don't
do
that
middle
step,
then
the
the
Affinity
between
Azure
managed,
cluster
and
cluster
class
becomes
really
sort
of
difficult
to
reconcile
and
so
doing
this
work
would
be
really
hacky.
C
So
I'm
not
going
into
a
lot
of
detail
right
now,
but
I
think
that
this
is
a
decent
amount
of
work.
A
E
You
know
like
like,
for
example,
I,
don't
understand
what
may
be
the
impact,
and
if
that
is
outlined
like
okay,
if
we
want
to
do
cluster
class,
you
know
this
is
the
impact,
and
do
we
really
want
to
do
that
for
manuscripts,
I
mean
that
can
help
a
lot
of
other
folks
to
actually
decide
on
and
then
maybe
not
into
this
minorities.
But
you
know
going
forward
again
think
about
that.
A
Yeah,
that's
a
good
point
so
since
it
looks
like
the
sticky
widget
here
might
be,
this
potentially
breaking
change
may
be
a
good
strategy
for
you
back
in
Lola
would
be
to
follow
up
on
her
comment
and
try
and
figure
out
concretely
what
Fields
would
actually
have
to
move
and
then
present
that
back.
A
A
That
might
be
a
good
way
to
see
and
if
it
seems
like
something
we
could
work
around
then
full
steam
ahead.
If
it
seems
like
it's
going
to
be
a
problem,
then,
obviously
that's
something
we
have
to
work
at.
Does
that
seem
like
a
reasonable
way
to
approach
it.
G
Yeah
sounds
good
to
me
and
just
another
quick
question:
the.
G
Serene
The
Proposal
the
for
the
cluster
class
and
manage
clusters
and
mentioned
that
the
current
implementation
in
capsu
uses
like
the
option
two
from
their
proposal
and
seems
to
be
nice
from
the
question
here
is:
would
the
cabs
would
kab
Z
keep
the
current
implementation
or
move
to
the
new
proposal,
and
it
seemed
like
there's
still
some
questions
to
answer
there?
G
Would
that
also
be
part
of
what
will
need
to
be
decided
as
well
or
is
there
any
consensus
already
on
which,
which
proposal
the
the
capsa
team
is
going
to
take.
C
C
But
if
we
decide
to
go
with
option
one,
then
that
would
be
blocked
on
that.
Otherwise
we
have
to
do
that
work
sort
of
twice
it.
You
know
if
that
makes
sense
it
makes
it
makes
the
the
effort
harder,
because
now
we
have
to
rip
apart
cluster
class
stuff
as
well.
So
we
would.
We
would
do
this
work
first
and
the
consensus
is
is
TBD.
C
G
Okay,
it
makes
sense
so
I'll
see
if
I
can
help
push
forward
the
in
the
information
about
the
fields
and
things
that
will
need
to
change
in
them
and
then
get
that
documented
in
this
issue.
A
All
right,
that's
the
end
of
the
agenda.
Do
we
want
to
do
Milestone
review.
B
Yeah
I
think
we
I
think
Jonathan
was
also
working
on
something
similar
with
the
same
problem,
but
like
this
problem
might
be
a
little
bit
hard
to
solve,
because
just
because
of
the
design
of
like
how
the
manager
policy
files
are
generated
every
time
something's
run.
So
it
might
take
a
little
bit
to
look
into
that.
A
But
we're
still
on
it
so
I'll
leave
it
on
the
Milestone.
I
guess
yeah
add
new
test
specs
it's
been
assigned,
although
I
haven't
seen
any
progress,
but
hopefully
it's
going
somewhere.
A
C
We
did
merge
one
PR,
so
I
yeah,
I'm
I
made
one
change
and
John
has
also
done
a
lot
of
this
discovery.
Work
here,
so
yeah
I
feel
like
this
will
be,
will
be
a
good
place.
It's
possible
based
on
that
Discovery
work
that
we
have
to
do
less
on
the
capsi
side
than
we
originally
thought,
but
that's
still
amounts
to
the
same.
We
have
a
better
idea
by
the
end
of
this
milestone
about
how
we're
responding
to
http
429.
A
Cool
and
this
that's
essentially
the
same
well,
this
is
rate
limiting,
but
it's
also
so
just
part
of
the
same
fix
area.
A
C
Let's
close
this,
this
I
think
we
just
determined
was
out
of
scope
or
not
needed,
basically
because
we
have
rate
limiting
already
in
the
SDK,
and
we
also
have
a
same
Cappy
idiomatic
way
to
control
the
rate
of
like
reconciliation.
So.
A
This
is
waiting
on
me
and
others
to
review
sorry
Mike
I'm
really
trying
to
get
to
it.
Quite
all
right.
It's
a
big
one,
node
public
IP,
prefix
ID,
is
still
in
progress.
Sean.
B
A
A
E
Yeah
that
one
I
think
we
know
what
we
want
to
do,
just
that
I'm
not
getting
a
chance
to
raise
a
design
document.
So
there
was
a
PR
that
was
worked
upon
some
time
back
by
sham
and
it
looked.
It
is
like
little
complex
because
it
involves
couple
of
cloud
in
its
script
and
hacks.
So
Cecil
has
asked
to
raise
the
design
document,
so
I'll
try
to
find
some
time
and
actually
raise
it.
I
have
some
draft
written
with
me,
probably
once
we
get
that
reviewed.
E
I'll
just
have
to
take
the
whole
PR
of
Sam
and
rework
on
that,
maybe
possibly
rebase
some
of
the
changes,
and
then
we
can
navigate
that
we'll
try
to
see
if
we
can
make
this
release
even
then,
given
that
cubecon
is
there
and
I
have
to
prefer
my
talk.
Also
so
I'll
try
to
see
if
I
can
raise
the
design
of
the
coming
days.
A
Okay
I
mean,
if
not,
if
not
it
Just
slips
to
the
next
Milestone.
That's
fine
yeah.
As
long
as
there's
a
fighting
chance,
I
guess
we
generally
leave
it
on
the
milestone,
and
this
is
also
related.
G
E
I
think
I
need
to,
like
you
know,
like
started
thread
and
have
developed
questions
on
this
one
with
the
workload
identity.
Folks,
I
see
that
we
don't
have
a
go.
Sdk
mentioned
there
in
their
document,
so
like
I
need
like
a
couple
of
more
details,
and
it's
like
fuzzy
right
now
in
my
brain,
so
I'll
possibly
do
a
write-up
and
paste
this
here
in
the
issue
and
on
the
slack
so
that
you
know
I
have
some
questions
that
can
help
me
to
actually
get
started
on
this.
E
A
Okay,
awesome:
that's
everything
we
have
on
the
milestone.
If
anybody
can
think
of
anything
that
really
should
go
on
there.
I
don't
want
to
grovel
through
all
the
issues,
but
you
know
feel
free
to
assign
it
to
the
Milestone
yourself.
We
can
always
take
it
out
or
let
us
know-
and
we
can
put
it
on
the
milestone.
E
Yeah
I,
you
know
I
just
want
to
set
a
funny
story
that
happened
like
last
time,
while
I
was
debugging,
a
cab
G
release
like
I
just
want
to
share
it.
If
it
might
help
people
like,
if
you
are
running
behind
a
proxy,
just
make
sure
that
your
capture
deployment
has
a
no
proxy
field
that
allows
this
MSI
endpoint
to
be
passed
through
no
proxy,
because
it
is
some
one,
six,
nine,
two,
five,
four
one,
six
nine
two
five
four
and
you
know
I
was
like
like
doing
crazy.
E
I
was
doing
all
the
debugging
I
couldn't
figure
out.
What's
going
wrong
wrong
and
I
have
started
a
thread
in
cap
Z.
Like
you
know,
I
was
trying
to
figure
out.
What's
going
wrong.
It
was
giving
some
400
State
bad
request,
error
and
looks
like
that,
because
that
MSI
endpoint
was
being
redirected
through
a
proxy.
It
never
got
intercepted
by
the
nmi
port.
So
it
all
didn't
work.
Just
a
PSA.