►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
hello,
everyone
today
is
August
25th
2022,
and
this
is
the
cluster
API
provider
Azure
office
hours
if
you're
joining
us
for
the
first
time.
Please
know
that
we
are
following
the
cncf
code
of
conduct.
A
A
If
you
don't
have
access
to
the
document,
you
can
get
access
for
editing
by
joining
the
sick
cluster
lifecycle,
mailing
list
and
I
just
want
to
note
that
we
have
changed
the
meeting
time.
This
is
the
first
time
we're
doing
this
at
this
new
time.
The
we're
not
going
to
have
this
office
hours
every
week
instead
of
bi-weekly,
and
it's
going
to
be
every
Thursday
at
9
00
a.m.
A
Pacific
time
so
I
hope
you
can
join
us
and
if
you
have
any
topics,
you
can
add
them
to
the
open
discussion
right
here
and
if
you
can,
please
add
your
name
to
the
attend
the
list
so
that
we
can
chat,
keep
track
of
who's
attending
news
and
it
will
also
help
us
know
if
the
new
time
is
working
for
people
all
right
with
that.
A
We
usually
start
by
giving
a
chance
to
anyone
who
is
new
to
the
meeting
to
kind
of
introduce
themselves
and
tell
us
a
bit
about
why
they're
here.
So,
if
anyone
here
hasn't
been
to
this
meeting
before
and
wants
to
say,
hi
now
would
be
a
good
time.
Please
go
ahead
and
unmute
and
tell
us
a
bit
about
yourself.
B
A
All
right
anyone
else,
I
think
everyone
else
has
a
familiar
face:
cool
all
right.
So,
let's
see,
let's
did
I
dive
right
into
discussion.
Jack
has
two
items
today:
go
for
a
jack.
C
Okay
cool,
so
the
first
thing
I
wanted
to
talk
about
was
the
graduation
of
azure
manage
cluster,
which
is
the
capsi
jargon
for
running
AKs
clusters
on
cap
C
and
cluster
API.
C
This
is
kind
of
using
the
formal,
kubernetes
style
proposal
medium,
which
usually
manifests
first
as
a
Google
doc,
and
that
is
a
PR,
but
I
think
there
are
advantages
to
doing
this
in
the
pr
from
the
beginning
to
sort
of
make
sure
this
is
even
more
public,
because
I
think
this
is
going
to
touch
a
lot
of
folks
and
I
also
would
love
to
Fast
Track
this
and
get
people's
ideas
as
soon
as
possible,
so
that
we
can
make
sure
that
we
do
this
in
a
timely
way.
C
So
I
I,
guess
it's
probably
not
I'm
happy
to
go
through
and
read
the
current
status
of
things.
This
is
basically
a
a
brain
dump
from
me
after
you
know
several
weeks
and
months
of
thinking
about
this,
but
it's
definitely
not
complete
what
I
wanted
to
do
in
this
office
hours
just
sort
of
announce.
This
and
then
turn
the
pr
from
a
draft
into
a
real
PR
and
then
just
start
soliciting
opinions
from
the
community.
C
C
A
I
personally
haven't
had
the
chance
to
go
through
this,
yet
I
will
definitely
take
a
read
if
we
want
to
discuss
the
high
level
overview,
though
of
like
what
is
the
current
status.
I
think
that
could
be
useful.
C
Yeah
great
I
mean
so
for
folks
who
don't
I,
see
Zayn
and
sum
out.
Sorry,
if
I
butchered
your
names
are
here
who,
as
far
as
I
can
tell,
are
using
the
Azure
management
cluster
solution.
So
this
is
definitely
relevant
to
to
you
folks
and
you,
so
you
know
the
background,
but
just
for
the
purposes
of
the
recording
I
will
explain
the
background,
which
hopefully
is
sort
of
concisely
explained
in
this
document.
C
There
is
no
cluster
API,
there's
no
formal
cluster
API
specification
for
how
to
do
managed,
kubernetes
in
in
cluster
API,
so
providers
implementing
this
in
the
past
two
years
or
so
have
sort
of
had
to
bootstrap
their
own
set
of
resource
specifications
that
fits
within
the
existing
cluster
API
spec.
C
So
really
the
the
long
story
short
is
that,
due
to
that
sort
of
freedom
to
do
this
in
any
way
possible,
capsi
made
the
decision
to
do
this
under
an
experimental
API
tag,
and
so
that
has
not
the
the
project
has
evolved
sort
of
organically
in
the
last
couple
years,
and
we've
maintained
that
experimental
API
specification
as
a
way
of
giving
ourselves
the
flexibility
to
adapt
and
respond
to
how
folks
are
using
it
in
the
real
world.
C
So
I
think
that
we
it's
it's
the
opinion
of
I,
think
most
folks
who
have
been
paying
attention
to
this
recently
that
we
have
sort
of
received
enough
actual
adoption.
We're
kind
of
at
a
terminal
velocity
for
folks
actually
using
this
in
the
real
world
and
Zayn
feel
free
to
chime
in.
If
you
have
any
of
your
own
opinions,
and
so
the
value
of
hardening
this
API
down
to
a
sort
of
stable
contract
has
I
think
overtaken
the
value
of
flexibility
in
the
future.
C
So
for
folks
who
are
actually
building
platforms
and
building
businesses
on
top
of
azure
managed
cluster
I
think
the
the
value
of
flexibility
is
is
less
than
like.
The
value
of
like
okay
can
I
actually
trust
this
API
or
am
I
going
to
have
to
go
refactor
all
my
operational
platforms.
You
know
continually
until
this
graduates,
so
I
think
we
want
to
graduate
this
as
soon
as
possible
to
give
folks
that
confidence
that
they
can
reliably
build
platforms
on
top
of
a
stable
contract.
C
So
that's
the
sort
of
background
it's
been
experimental
and
we
are
we're
trying
to
make
sort
of
the
minimum
amount
of
practical
changes
to
get
this
to
V1
V1,
so
I
would
anticipate.
There
will
be
some
breakage,
but
we
want
to
work
within
the
community
to
determine
what
the
appropriate
sort
of
pain
is
to.
B
A
Yeah
I
do
have
one
question,
I
think
all
of
us
here
know
what
we're
talking
about,
but
it
might
be
worth
clarifying
to
external
our
like
people
who
aren't
as
familiar
with
the
implementation,
what
we
mean
by
V1
because
cabs
itself,
the
version
is
already
V1,
so
AKs
is
part
of
that,
and
really
what
we're
talking
about
here
is
removing
the
feature
flag
and
not
marking
the
API
as
experimental
anymore,
so
that
it
can't
have
breaking
changes
and
it
won't
be
removed
without
notice,
but
really
the
API
version
and
the
kab
Z
version
are
not
related
to
that
right.
A
C
Right
so
I
don't
know,
maybe
you
could
do
a
better
job
of
explaining
that
there's
a
subtle
distinction
between
the
capsi
API
or
the
cap,
C
sort
of,
if
you
want
to
call
it
product
and
this
particular
subset
of
what's
available
in
V1
cap
Z.
C
C
Think
of
this,
like
purely
practical
terms,
when
I'm
defining
an
Azure,
managed
cluster
resource
and
all-
and
you
know,
defining
all
of
its
references
and
and
how
you
might
compose
an
entire
cluster
template
together,
the
Azure
managed
cluster
resource
type
is
subject
to
change
so
as
the
community
evolves
and
as
we
so
you
know
one
thing:
this
is
a
slight
digression,
but
one
thing
that
we
are
currently
evaluating
is
how
to
integrate
the
cluster
API
proposal.
C
That
recommends
how
to
do
manage
kubernetes
and
cluster
API
for
providers
how
to
integrate
those
recommendations
into
our
Azure,
managed
cluster
implementation,
and
that
may
I
think
the
to
the
folks
who've
read
that
proposal.
There
are
some
I
think
definite
opportunities
for
breaking
changes,
so
it'll
be
up
to
us
as
a
community.
C
You
know
really
as
a
larger
Community
capacity
and
working
with
cluster
API
to
determine
if
it
makes
sense
for
us
to
integrate
those
breaking
changes
into
Azure
manage
cluster,
which
we
can
do
now
because
we
haven't,
we
haven't
sort
of
tagged.
These
particular
API
specs,
so
Azure
manage
cluster
Azure,
manage
machine
pool
those
kinds
of
things
as
V1.
C
D
Yeah
something
like
I
just
wanted
to
add
like
there's
like
you
know,
for
me
to
do
things
like
the
B1.
Is
the
contract,
like
you
know,
like
the
user
interface,
that
we
are
going
to
support
if
we're
going
to
provide
an
experience
to
running
AKs
on
top
of
that,
but
I
from
the
past
few
months,
like
I've,
been
working
with
like
AKs
itself,
you
know
like
not
speaking
out
of
the
capsic.
It's
also
an
evolving
product.
I
would
say
it
has
been
adding
our
features.
D
It's
I
would
say
like
it's
or
dropping
some
features
in
that
sense
and
I
would
say,
Pepsi
has
the
is
the
only
operator
I
think
like
out
there
who
is
managing
AKs
because
from
the
issues
that
have
been
discovered
uncovered
through
capsule
I
believe,
like
AKs,
is
not
managed
through
any
operator
right
now
or
in
a
like
a
wide.
You
know
like
spread
usage,
so
they're
like
few
things
that
probably
we
need
to
on
the
back
end
to
learn
from
the
AKs
behaving
right.
D
So
AKs,
like,
let's
say
like
is,
is
very
error
prone
to
you
know,
like
you
know
like
when
some
Opera
is
happening
in
the
agent
pool.
It
won't
allow
any
operations
on
the
cholesterol
level,
or
these
kind
of
things
that
you
would
not
expect
in
any
kubernetes
generally
kubernetes
cluster
to
happen.
But
AKs
has
these
kind
of
issues
capsi
being
it's
like
open-ended
implementation.
I
think
should
adopt
to
those
also.
So
those
are
like
the
the
second
thing.
D
A
Yeah
I
think
I
I
agree
with
Zayn
about
like
the
reliability
and
aspect
of
it
of
like
now.
You
know
we
recommend
this
for
production,
whereas
right
now
it's
kind
of
like
use
at
your
own
risk,
not
the
AKs
product
but
like
the
cabs
integration
and
I.
Think.
A
I
think
we
should
just
try
to
be
in
a
state
where
we
feel
comfortable
that
we're
going
to
be
maintaining
this
long
term
I'm
not
going
to
want
to
remove
it
and
it's
stable
enough
for
people
to
use
in
production,
but
I
think
feature
the
feature.
Matrix
will
keep
expanding
after
we
remove
experimental
label.
One
thing
that
I
wanted
to
point
out
is:
maybe
we
should
also
think
about
how
machineful
experimental
status
comes
into
this.
A
Like
comes
into
play
here,
because
even
if
we
remove
the
Azure
managed
cluster
experimental
feature,
it
will
still
require
the
machine
pool
feature
flag
until
Mission
Pool
is
not
experimental
and
that
so
I
don't
know.
If
we
want
to
consider
that
a
dependency
or
to
Independent
work
streams,
but
there's
something
there.
C
I,
don't
think
it's
an
easy
so
that
that
really
is
a
cluster
API
dependency
that
we
have.
So
that's
the
as
far
as
I
can
tell
cap
Z
would
be
happy
to
graduate
machine
pool
to
be
one,
but
we
can't
we
have
an
Azure
machine
pool.
Let's
be
one
with
a
cluster
API
machine
pool,
that's
experimental
that
won't
really
work
so
yeah
I'm,
going
to
take
a
note
of
that.
A
All
right,
if
not
I,
would
encourage
everyone
to
read
through
this
proposal
and
add
your
comments
and
I
guess
we
can
continue
the
review
process
async
and
revisit
maybe
next
week
or
in
two
weeks.
C
Yeah
I
I
mean
we'll,
let's,
let's
use
the
community
consensus
process
to
come
to
a
agreement
as
far
as
priority
and
when
we
want
to
land
this.
But
just
FYI
will
be
probably
pushing
to
do
this
soon,
like
in
the
coming
months
and
not
I.
Don't
want
this
to
take
like
a
year
year
and
a
half.
A
C
Go
first:
okay,
it's
a
pretty
simple
one,
so
yeah
I
wanted
to
propose
the
I
wanted
to
actually
to
pull
the
audience
for
how
we
feel
about
patch
releases
right
now.
My
understanding
is
that
we
release
patch
releases
kind
of
ad
hoc
when
we
feel
like
we
have
the
complete
set
of
fixes
that
make
sense.
You
know
there's
a
little
bit
of
overhead
of
of
cutting
a
release
and
that
works.
C
Fine
I
wonder
if
it
would
work
better
if
we
did
patch
releases
on
a
regular
Cadence
like
say,
weekly
and
then
use
our
office
hours
as
a
sort
of
go,
no
go
gating
discussion
to
see.
Do
we
want
to
release
this
week?
I
know
it's
not
ideal,
because
offs
hours
is
on
Thursday,
and
that
means
we
would
be
releasing
toward
the
end
of
the
week,
but
also
I.
Don't
think
that
we're
in
the
position
where
our
releases
are
sort
of
pushing
to
live
environment.
C
Instead
of
you
know,
opening
up
a
random
slack
thread
and
say
hey:
should
we
cut
a
patch
release
instead,
just
document
in
our
release
process
that
we
release
patch
release
is
our
regular,
like
say
every
Friday
and
during
office
hours
we
discussed
whether
or
not
we
have
the
sufficient
number
of
content
to
kind
of
release
that
week
any
opinions.
A
This
part
and
I
don't
have
the
issue
link
right
now,
but
we
have
an
issue
right
now
and
they're
not
done
to
Define
release
Cadence
and
it's
unfortunate
Matt
isn't
here
right
now,
but
let's
see
he
was
going
to
drop
this
and
I
think
we
were
aiming
to
do
this
mostly
for
minor
releases,
but
I
don't
see
why
we
couldn't
also
include
a
bullet
point
about
patch
releases
in
general
I
like
the
idea
of
having
a
really
check-in
at
office
hours,
although
it's
less
inclusive,
because
not
everyone
can
make
it
to
office
hours
so
I
find
that
using
slack
async
is
a
little
more
inclusive.
A
We
could
have
maybe
like
a
a
slight
reminder
every
week
that,
like
the
bot
posts,
a
message
and
says:
hey,
do
we
want
to
release
this
week
and
then
we
kind
of
use
that
to
remind
ourselves,
we
should
check
whether
a
patch
release
is
warranted.
I
also
agree
that
we
should
do
it
kind
of
on
a
her
need
basis.
We
don't
need
to
release
every
week
if
there's
nothing
to
release
that
week,
but
it's
good
to
at
least
have
that
weekly
reminder.
C
Yeah
I,
like
I,
mean
I
I,
think
the
two
main
takeaways
are
from
the
two
main
sort
of
differences
between
the
way
we
do
it
now
one
is
to
to
set
a
day
so
so
the
community
can
just
have
their
expectations
that,
like
every
whatever,
if
it's
every
week,
then
it's
every
day
or
if
it's
every
two
weeks
or
three
weeks.
C
They
just
know
that
there's
a
regular
day
where
they
can
check
in
and
and
evaluate
the
set
of
changes
that
have
been
released
in
order
to
build
their
own
processes
around
potentially
consuming
those
releases
with
regularity.
You
know
in
their
operations
and
then
I
I
have.
This
is
Maybe
my
own
intuition,
which
is
very
subjective
but
I.
I
I
would
like
to
make
the
practice
of
regular
releases
not
like
controversial
thing
and
not
not
an
indication
that
the
project
is
unstable
or
you
know,
I.
Think.
C
In
the
past
we've
done
patch
releases
very
irregularly.
There
are
lots
of
minor
releases
that
don't
even
get
a
patch
release,
and
so
there
there's
a
potential
there's
some
potential
signaling
going
on
where
you
start
releasing
patch
releases
like
oh,
is
this
minor
release
unstable?
C
Maybe
I
should
wait
till
the
next
minor
release,
because
I'm
not
used
to
having
patch
races
so
I
I
would
like
to
to
change
that
culture
where,
where
patch
releases
are
just
the
normal
part
of
the
the
process
of
managing
the
project
and
also
I,
think
that
this
will
be
a
forcing
function
for
us
as
project
maintainers,
to
get
better
at
prioritizing
What
lands
on
to
Maine.
So
we'll
realize,
if
there's
a,
if
there's
a
helpful
fix
that
we
can
prioritize
that
and
get
that
into
the
next
patch
release.
B
So
yeah
I
think
it's
it's
a
great
idea.
I
think
that
would
be
very
helpful.
Two
two
notes,
though
one
it's
the
releases
on
Friday,
and
so
if
we
release
on
Friday
what
happens
if
we
need
a
critical
fix
or
to
fix
something
in
production,
or
do
we
have
an
escape
hatch
to
to
cut
a
release
earlier
if
it's
required?
B
Otherwise,
you
know
I,
don't
want
to
release
something
on
a
Friday,
but
if
it's
broken,
wait
for
the
other
Friday
to
get
something.
So
just
like
you
know,
brainstorming
ideas
here.
A
For
the
Friday
thing,
I
think
that
was
mostly
a
constraint
of
wanting
to
do
it
with
office
hours.
But
if
we
do
go
to
async
slack
route,
we
could
have
that
reminder
be
any
day
of
the
week
and
we
could
even
do
it
Monday
and
aim
to
release
on
Tuesdays.
It
doesn't
have
to
be
Friday.
I
agree
that
Friday
is
not
ideal.
Even
for
maintainers,
like
work-life
balance,
it's
not
great
to
be
doing
releases,
Fridays,
yeah.
B
C
That's
that's
the
thing
I
I
heard
that's
the
most
important,
so
yeah.
There
I
think
that
there
is
yes,
so
so
long
as
we
to
me,
the
the
key
concept
here
is
keeping
to
the
regular
release
schedule
as
a
way
of
preventing
releases
from
getting
indefinitely
pushed
back,
because
with
that
regular
release
schedule,
it's
like
no
matter
what
we're
going
to
release
on
Monday
or
whatever
it
might
be,
and
I
think
that's
helpful
to
making
sure
that,
like
the
outcome
is
we
want
regular
releases.
C
We
want
to
get
patches
into
customers
hands
if
they
want
them
and
so
having
a
regular
reschedule
in
my
experience
is
the
best
way
to
do
that,
as
opposed
to
to
having
every
release
be
subject
to
some
sort
of
subjective,
triage
prioritization
that
can
just
get
Harry.
So
as
long
as
you
have
the
regular
release
process,
I
would
also
be
totally
fine
with
documenting
in
the
release
Cadence
some
sort
of
escape
hatch
situation.
Where,
where
folks
can
the
community
can
vote
on
hey?
C
Let's
do
it
on
Wednesday
release,
even
though
we
just
did
one
on
Monday,
because
this
fix
that
landed
yesterday,
which
has
sufficient
test
coverage,
is
super
important.
We
don't
want
to
wait
five
days,
so
I
think
we
should
probably
we
can
discuss
that
in
the
the
document
that
so
see
a
link
to
an
issue
that
we're
tracking,
so
that
will
eventually
yield
documentation
updates
to
our
existing
release
process.
So
we
should
make
sure
we
can
account
for
that
cool.
A
A
Okay,
great:
what
are
we
I
guess
what
are
the
next
steps
to
for
this?
Should
we
bring
this
to
the
issue.
C
Yeah
I
think
the
next
steps
are
to
sort
of
land
the
set
of
definitions
that
we
want
like
is.
How
often
is
it
weekly?
Is
it
bi-weekly,
which
day
of
the
week
I
mean
there's
there
I
think
that
there
is
some.
We
haven't
really
talked
about
release
validation.
C
We
can
definitely
improve
the
way
we
test
releases
and
gate
releases,
but
maybe
that's
maybe
that's
like
an
orthogonal
work
stream
that,
like
we
don't
want
to
block
I,
don't
want
to
block
the
regular
release
of
patch
releases
on
that,
but
I
do
want
to
continually
improve
that,
so
that
we
can
get
more
and
more
confident
that
when
we
do
release
it's
going
to
be
stable
because
right
now,
I
think
we
pass
a
little
bit
of
that
on
to
the
customers.
C
A
Sort
of
yeah,
I
I,
so
I
guess
do
you
want
to
set
up
a
reminder
on
slack
or
is
this
jumping
the
gun?
Should
we
like
be
first,
okay,.
A
Could
I
ask
you
to
follow
up
with
Matt
to
see
if
we
can
get
that
integrated?
Definitely,
okay,
cool
I!
Guess,
speaking
of
releases,
do
we
want
to
talk
about
doing
a
patch
release
this
week
or
early
next
week?
I
think
we
have
a
lot
of
fixes
and
one
for
for
especially
for
managed
clusters.
C
Yeah
I,
so
I
spent
most
of
my
time
yesterday
in
terms
of
capsi
product
maintenance.
Getting
those
Cherry
picks
landed
in
one
four,
and
so
those
are
all
there
now
so
I
think
we're
actually
a
sufficient
we've
got
the
sufficient
number
of
changes
to
do
a
release,
so
I
would
be
totally
in
favor
of
doing
that
today.
Tomorrow,
Monday.
D
Yeah,
so
I
just
wanted
to
raise
not
not
in
this
meeting
but
like
we
introduced
some
bugs
also
in
the
capsic
managed
clusters.
I
was
just
trying
to
create
a
like
issue
around
that.
So
it's
not
a
capsi
work.
It's
just
like
AKs
API
issue.
It
accepts
the
labels.
We
we
just
introduced
a
narrative
PR
where
it
can
change
the
labels
right,
and
we
can
note
labels
can
be
changed,
but
that
means
like
we
remove
the
system.
D
Labels
from
AKs
and
AKs
allows
us
to
do
that,
and
that
means
like,
if
is
any
kind
of
system
labels
that
are
being
added
by
AKs,
they
they
will
be
removed.
The
good
thing
is
like
it
allows
us
to
add
it
back
also,
so
there's
no
like
no
gatekeeping
on
the
side
of
AKs,
but
this
is
something
probably
it
just
want
to
discuss
in
the
open
issue.
I
will
how
we
deal
with
that,
like
you
know,
like
kubernetes
dot,
azure.com
labels
speech
labels.
That
applies
for
the
tents
also
actually
PR,.
B
D
A
We
dig
in
so
are
you
saying
that
this
is
a
regression
that
is
currently
being
introduced
in
the
current
release
branch
that
we
should
block
releasing
on
just
wanting
to
make
sure
I
understand.
A
B
C
I
mean
we
could
also
just
undo
the
I
think.
The
key
point
is
that
the
current
state
of
things
you
can't
update
labels
and
that's
that,
arguably,
is
safer.
So
we
can
just
remove
that
cherry
pick
from
1.4
manually,
somehow
so
not
shift
that
change.
Well,
let's
talk
about
that
a
little
bit
Zayn.
So
it
sounds
like.
Maybe
what
you're
saying
is
that
when
I
as
a
as
a
cap,
Z
user,
when
I
submit
a
set
of
additive
labels
to
to
change,
does
that
then
become
the
does?
C
B
A
And
plus
one
on
your
suggestion
to
revert
the
pr
that
made
labels
mutable
until
we
can
think
and
reintroduce
it
in
a
way,
that's
not
having
undesirable
side
effects.
I
think
we
should.
There
are
a
lot
of
really
important
fixes
in
that
branch
that
we
want
to
get
out
to
users,
and
so,
if
we
can
find
a
quick
way
to
unblock
ourselves
and
release
in
the
meantime,
that'd
be
great.
C
A
D
Yeah
so
actually
like
on
the
other
side,
like
I,
have
been
testing
a
solution
like
in
our
development
staging
so
just
ignoring
kubernetes.aju.com
labels
and
not
allowing
users
to
like
remove
them,
because
we
are
doing
a
very
easy
comparisons
like
that.
It's
existing
profile
versus
the
current
profile
that
we
want
if
the
existing
profile
has
anything
that
has
kubernetes
Dot
azure.com,
we
just
send
it
again,
and
that
has
been
like
at
least
helped
us
to
gain
with
work
with
confidence
in
at
least
our
staging
environment.
Right
now,.
A
I
think
if
we
have
a
solution-
and
we
can
time
box
it
and
say
like
we
are
able
to
merge
it
by
end
of
day,
for
example,
that's
great
but
I
still,
you
know
think
we
should
have
the
revert
option
as
a
backup
and
not
rush
into
anything
like
if
we're
I
think
reverting
is
safer.
If
we're
not
able
to
get
to
a
solution
that
we're
all
good
with
to
merge
quickly,
and
then
we
can
re-add
the
patch
and
the
fix
together.
C
Can
I
ask
a
question
about:
do
we
need
to
consume
the
set
of
system,
applied
labels
and
and
maybe
taints
as
well
during
cluster
creation,
so
that
the
the
capsi
representation
of
azure
managed
cluster
has
or
Azure
management
machine
pool?
Has
those
system
labels
well
that's
go
ahead
and
say.
D
Yeah,
no,
we
don't
need
because
we
were
supporting
labels
actually
on
the
equation.
Time
always
and
somehow,
when
the
cluster
is
created,
the
AKs
reconciler
comes
in
later
and
they
add
Source
level
threads
for
everyone.
Somehow
I,
don't
know
how
this
works
under
the
hood
and
we
had
those
system
levels
always
even
if,
in
the
question
time,
we
are
specifying
two
or
three
labels
from
the
user
provided
labels
right,
so
that
request
would
go
in
and
the
system
level
will
work.
D
A
A
If
you
could
open
an
issue,
let's
do
that
with
the
bug
and
then
maybe
we
can
open
an
issue
in
the
AKs
repo
as
well
that
links
to
this
issue
to
get
gas
to
weigh
in
on
the
API
differences,
and
then
you
know
feel
free
to
open
a
PR
with
the
the
fix
that
you
have
if
it
works
out.
Well,
if
not,
we
can
follow
up
on
that.
A
Yeah
I
think
I,
think
that
should
be.
That
should
be
good
and
then,
after
that,
we
can
probably
aim
to
release
the
patch
release
either
to
tomorrow
or
Monday.
A
That's
a
good
question:
Zane.
Do
we
want
to
revert
the
tanks
as
well.
A
C
C
When
is
it
appropriate
to
implement
something
as
create?
Only
because
that
to
me
that
sort
of
smells
just
like
a
bug
that
we
would,
we
wouldn't
support
an
update?
That
would
not
be
obvious
from
a
user
perspective,
but
I
suppose
that's
not
true,
like
we're
literally
running
into
various
things
in
the
AKs
surface
area
that
are
not
updatable.
So
we
probably
do
want
to
have
a
nice
clean
pattern
for
that
and
call
that
sort
of
feature
complete
until
we
can
work
with
ACS
to
make
update
possible
go
ahead.
Zane.
D
Yeah,
like
I,
want
to
say,
like
the
labels,
were
always
mutable,
actually
like
that.
That's
just
basically,
that
was
a
bug
when
we
added
that
feature
do
not
to
update
that.
That
kind
of
saved
us
and
the
other
was
like
the
the
teams
and
others
are
even
more
dangerous,
because
we
need
some
dusting
to
be
done
there.
What
happens
is
like
when
right
now,
we
are
not
deleting
any
node
pull
through
capsule
ever.
D
Why?
Because
we
are
worried
that
the
the
teams
that
are
being
added
during
the
drain
process
might
be
removed,
also
like
that
are
not
added
by
us
as
a
user
provider
it
so
anything
like
that
is
also
like
it's
even
the
surface
area
is
even
bigger
for
that
to
all
the
all
the
considerations
or
all
the
edge
cases,
so
labels
probably
is
an
easy
fix,
but
tints
probably
is
gonna,
take
much
more
time
for
us
to
get
in
a
good
shape
or
have
enough
confidence
to
land
that.
C
Yeah
I
mean
again
we're
going
I'm
going
into
detail,
but
I'm
just
super
curious.
What
the
labels
thing
I
would
imagine
that
the
CLI
that
AKs
AKs
CLI
supports
label
updates,
so
maybe
we're
just
using
the
wrong
API
call
when
we,
so
we
I
can
talk
with
AKs
all
right,
I,
don't
know
Matt
do
you?
Are
you
familiar
enough
with
looking
into
the
the
the
CLI
code
to
be
able
to
identify
what
API
calls
are
actually
being
performed
under
the
hood.
B
C
I'll
wait
until
the
so
it's
I
assume
it's
fairly
easy
wait
at
some
point
until
the
the
kubernetes.azure.com
labels
are
part
of
the
nodes
and
once
I
see
that
then
I'll
update
the
labels
with
so
it
just
whether
it's
additive
or
or
delete
of,
like
the
the
system
notes,
get
deleted.
No
matter
what
any
update
in
capsity
deletes
labels
right
now
is
that
right.
D
D
If
we
can
reach
to
conclusion
that
cap,
C
use
cases
or
features
will
never
allow
a
system
label,
then
pretty
much
it's
safe,
but
I
was
not
sure
about
that,
like
what
are
the
all
different
combination
of
the
features
of
capsic,
you
know
icon
from
add-ons
or
some
agent
Port
features
that
will
add
those
or
not
I'm,
not
100.
On
that.
A
Foreign
all
right,
if
not,
let's
do
a
any
other
general
questions
or
questions
for
maintainers
comments.
A
All
right,
let's
do
a
quick,
Milestone
check.
We
are
two
weeks.
Is
it
two
weeks
two
weeks
approximately
from
our
Target
release
date
and
the
Milestone
is
getting
pretty
small,
so
that's
great
and
anything
that
anyone
wants
to
update
on
in
here
are
we
is
there
anything
else
that
isn't
in
here
that
should
be
in
here
or
anything
that
is
in
here
that
we
think
we're
not
gonna
be
able
to
get
done
in
the
next
two
weeks
that
we
should
get
out
of
the
milestone.
B
A
If
it
doesn't,
we
can
move
it.
B
And
I'll
jump
on
the
second
one.
I
promise
this
time
this
week
or
soon.
A
Hours
I'll,
let
Jack
catch
you
up
on
that
that
we're
talking
about
including
our
Cadence
for
patch
releases
in
there
go
ahead.
C
C
C
A
No
I
was
just
gonna
say
for
what
it's
worth.
I
I
did
review
that
for
like
the
last
few
weeks,
and
it's
I
think
it's
really
close
to
merging.
It
was
basically
ready.
I
just
asked
Jonathan
to
hold
on
because
we
wanted
to
fix
the
auto
scaler
bug
for
AKs
and
I
was
gonna.
That
refactor
was
gonna,
make
that
bug
fix
harder
to
merge
because
of
merge
conflicts,
but
now
that
that
has
merged
I
think
if
we're
able
to
merge
it
like
in
the
next
two
days.
C
A
A
I
think
this
one
is
not
gonna
make
it
I,
it's
there's
a
PR,
but
there
are
lots
of
comments
on
it
and
I.
Don't
think
it's
been
active
for
a
bit
so
I'm,
not
confident
that
we'll
be
able
to
get
that
merged.
A
What
else
I
actually
want
to
talk
about
the
last
one
I
kind
of
want
to
propose
deferring
that
to
the
next
release,
just
for
risk
kind
of
the
same
ideas
the
agent
pulls
except.
This
is
worse.
A
This
is
a
really
big
change
and
I'm,
just
afraid
of
the
side
effects
that
we're
gonna
find
out
and
I
wouldn't
want
that
to
merge
like
right
before
the
release
and
it's
closed,
but
it
hasn't
been
reviewed
yet
so
the
review
cycle
is
probably
going
to
take
a
while
and
I.
Don't
want
that
to
merge
like
two
days
before
the
release
or
something
like
that,
especially
since
I'll
be
out
during
the
release
and
won't
be
around
to
help
out
if
something
goes
wrong.
C
A
It's
in
a
place
where
I'm
waiting
for
reviews
and
there's
one
thing
that
I
haven't
figured
out
yet
there's
that
I
haven't
had
time
to
look
at,
which
is
the
there's
a
bug,
basically
in
the
Linux
kernel.
That
causes
a
feature
in
Calico
when
using
vxlan
to
not
work,
and
we
have,
in
the
past,
gone
around
by
disabling
that
feature
with
the
check
feature
dissect
override.
But
it's
a
bit
harder
to
do.
You
can't
do
that
override
directly
in
the
helm
chart.
C
A
The
first
I
think
the
first
90
took
like
an
hour
and
then
less
10
has
taken
me
like
four
weeks.
So
it's
it's
just
like
getting
the
the
last
smell,
that's
really
hard,
but
yeah.
Your
your
first
attempt
helped
me
a
lot
Jack,
so
yeah
definitely
gonna
give
you
credit
on
the
commits.
A
A
C
To
be
clear
to
folks,
this
isn't
really
a
part
of
caps
eat,
but
it
would,
if
we
merged
something
like
this,
that
sort
of
added
testing
friction.
It
would
materially
make
it
harder
for
us
to
validate
the
health
of
1.5.
So
it's
I
think
it's
a
good
idea
to
to
move
a
change
like
that
to
the
beginning
of
a
release.
A
Yeah
exactly
just
being
cautious
and
don't
want
to
break
everything
right
before
releasing
cool
I
think
this
one
is
in
a
good
place
that
just
needs
review
so
that
one
we
can
move
in
here
all
right.
Anything
else
that
anyone
wants
to
add
in
here
that
we
should
be
tracking.