►
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
Hello,
everyone
today
is
Thursday
January
26th,
and
this
is
the
cluster
API
provider
Azure
office
hours
thanks
for
joining.
If
you
haven't
been
here
before
just
a
reminder
that
cluster
API
provider
Azure,
is
a
sub-project
of
sick
cluster
lifecycle,
you
can
get
access
to
our
mailing
to
our
documents
Sorry
by
joining
the
mailing
lists
to
edit
and
just
a
reminder
that
we
followed
the
cncf
code
of
conduct.
We
encourage
everyone
to
raise
hands
when
they
want
to
say
something
and
just
be
respectful
of
everyone
in
general.
A
Let's
see
okay,
so
we
have
a
few
items
on
the
agenda
today,
but
before
we
start
is
there
anyone
here
who
would
like
to
introduce
themselves
say
hi,
just
tell
us
a
bit
about
why
they're
here,
if
you
haven't
been
here
before
now,
is
your
chance.
I
will
mute.
A
All
right,
I,
don't
see
any
unmute
buttons
going
on,
so
I
think
we're
good
cool
all
right.
So,
first
of
all,
just
a
few
quick
announcements:
PSAs
first
one
is
the
releases,
so
we
have
two
patches
that
were
released
this
week,
v1.7.1
and
b1.6.2.
So
if
you're
using
one
of
those
two
minor
versions,
we
encourage
you
to
upgrade.
A
A
Okay,
the
second
one
is
I,
just
wanted
to
call
out
and
I,
don't
think
he's
here,
but
we're
We've
nominated
John
to
be
a
reviewer
in
cab
c.
So
the
pr
here
adds
in
this
is
in
recognition
of
all
the
work
he's
done
in
managed
clusters
recently
and
being
one
of
the
primary
reviewers
for
a
lot
of
PR's
already
so
he's
essentially
already
acting
as
a
reviewer,
so
we'd
like
to
make
make
it
official
and
yeah.
A
So
thank
you,
John
for
all
your
work
and
contributions
and
if
you
have
any
comments,
feel
free
to
comment
on
the
PR,
but
this
PR
will
stay
open,
I,
Don't,
Know
Jack.
Do
we
have
a
plan
for
consensus
on
this
one
or
lazy
consensus,
I.
B
Don't,
since
we
have
a
couple
more
maintainers
that
haven't
weighed
in
Let's,
maybe
set
the
timer
to
end
of
this
week
because
it's
been
open
for
I
think
already
a
week.
Does
that
sound,
sensible
and
since
I'm
unmuted
just
a
shout
out?
If
anyone
else
is
interested
in
becoming
a
reviewer
I
think
the
pr
description
sort
of
outlines
the
criteria
reach
out
to
any
maintainer
we
can.
We
can
help
you
we'd
love
more
reviewers
from
the
community.
A
A
Okay,
now
we
have
okay,
the
only
topic
there
is
the
one
I
added.
Unless
anyone
has
anything
else,
but
I
guess
I'll
start
with
that
one.
A
A
Essentially
what
happened
is
we
moved
all
the
aps
manage
clusters
stuff
out
of
experimental
in
the
main
branch
in
preparation
for
the
1.8
release,
which
is
great.
However,
that
means
that
our
book
immediately
got
changed
to
essentially
represent
the
fact
that
it
was
no
longer
experimental,
even
though
that
is
not
true
yet
in
a
release,
so
we
had
a
user
new
user
that
was
confused
because
they
tried
to
use
it
and
the
feature
flag
that
they
still
needed
and
the
release
was
not
being
listed
because
you
no
longer
needed
the
main
brush.
A
So
this
kind
of
restarted
the
conversation
around.
Why
is
there
a
book
pointing
at
the
main
branch
and
not
at
the
release?
Branch
and
so
just
wanted
to
talk
a
little
about
that
and
what
we
should
do
to
me.
It
seems
pretty
clear
that
it
should
be
playing
another
really
scrunched.
Since
that's
you
know
what
we're
targeting
users
here
and
users
are
going
to
be
using
releases.
A
The
only
thing
that
makes
it
a
little
Annoying
is
that
it's
all
control
on
the
netplify,
UI
and
essentially
I
can
show
you
all,
but
this
like
just
getting
access
to
this
page,
requires
getting
manually
added
by
thick
docs
folks,
it's
not
controlled
by
any
sort
of
owner's
file
or
anything
which
means
that
it's
very
like,
like
I,
have
access,
but
I,
don't
know
if
a
lot
of
other
people
here
have
access
and
if
we
weren't
wanted
to
add
more
people,
we'd
have
to
like
ask
to
get
them
added
and
it
seems
to
be
a
very
Case
by
case
basis.
A
So
that's
one
thing.
The
second
thing
is
like
we
have
to
like
change
the
branch.
Every
time
we
release
in
the
build
and
deploy
here
so
right
now,
it's
set
to
main
we'd
have
to
set
that
to
release,
and
the
other
inconvenience
is
that
in
art
for
the
domain
to
be
a
valid
certificate.
On
that
release,
Branch
we'd
have
to
essentially
like
email,
support
every
time
and
ask
them
to
add
our
release
Branch
to
the
search
which
we've
done
for
Cappy
in
the
past.
A
It's
doable
it's
just
annoying,
because
someone
has
to
do
it
and
I
don't
want
to
be
a
single
point
of
failure
for
that.
So
that's
kind
of
where
we're
at
right
now
why
we
haven't
made
the
change
yet
I
think
Jack.
Your
first
go
ahead.
B
A
Yes,
so
basically
we'd
have
to
like
so
right
now
the
production
branch
is
set
to
me,
so
we're
R
is
deploying
every
single
Branch,
so
the
branches
are
getting
deployed,
but
they're
not
use
as
our
our
default
production
Branch.
So
then
we'd
have
to
like
go
and
do
this
every
time
and
so
like
right
now
we
would
set
it
to
1.7,
but
then
next
time
we
really
someone
would
have
to
come
into
this
UI
change
this
to
1.8.
B
Because
that's
what
you
just
described
right,
there
is
not
actually
that
difficult
I
was
assuming.
It
would
be
more
like
at
least
my
did.
The
Legacy
version
of
the
kubernetes
Upstream
documentation
where
there
is
a
sort
of
convenient
Alias
that
always
gets
you
to
the
URL
for
the
latest
released
version
of
docs.
But
then
you
can
click
in
a
drop
down
box
and
see
the
docs
for
like
two
versions
prior
or
something
which
might
have
slight
differences
so
that
you
can
correlate
your
actual
version
of
kubernetes
with
the
documentation.
A
B
A
Point
at
the
release
branch
and
then
in
addition
to
that,
we
could
have
something
that
points
to
like.
If
you
wanted
an
older
Branch
or
if
you
wanted
the
main
branch,
he
could
do
that.
That's
what
that's
kind
of
what
cluster
API
has
right
now
I
can
show
you
yeah
like
right
here,
so
this
is
like
all
the
documentation
versions.
So
this
main
one
points
I
believe
right
now
we're
on
one
point
two
or
whatever
the
latest
is,
but
if
you
want
to
go
to
main,
you
can
go
to
main.
A
1.2
is
like
older,
so
you
can
go
on
all
the
previous
versions,
which
is
nice,
but
in
order
to
do
that
in
cluster
API
we
had
to
first
of
all
change
this,
but
also
go
into
the
search
and
email
support
to
get
them
to
add
all
these
branches
to
the
search.
B
Right
understood
so
we
could.
It
sounds
like
we
could
crawl
here
and
just
update
the
branch
to
point
to
the
latest
release
and
then
maybe
update
the
documentation
at
the
very
top.
That
just
says
you
know
disclaimer.
This
documentation
always
refers
to
the
latest
release,
and
maybe
so
maybe
that
would
be
a
crawl
version
of
this.
If
we
decided
to
go
this
way,
Matt's
been
raising
his
hand
for
a
while,
so
I'll,
let
him
go
and
I
have
some
other
stuff
to
talk
about,
but
I
wanted
to
clarify
the
notify
Matt.
C
If
you
go
back
to
a
previous
release,
it's
static,
HTML
and
it
doesn't
know
about
later
releases,
so
you're
kind
of
lost
at
that
point
but
like
if
you
click
on
yeah
see
it
doesn't
know
how
to
get
back
to
1.3,
but
ideally
that
would
be
some
little
navigation.
Widget,
that's
on
every
page,
like
you
have
in
a
lot
of
other.
So
it
sounds
like
a
lot
of
work.
C
It
sounds
like
some
of
it
is
going
to
be
kind
of
manual
and
fiddly,
like
updating
the
cert,
updating
the
branches
and
doing
all
that
through
the
netpli
UI
all
I
can
offer,
is
I'm
totally
willing
to
help
with
that
kind
of
stuff.
But
it
feels
like
we
should
add.
C
We
should
try
and
do
the
full
nine
yards
I
think
or
maybe
we
could
do
the
the
walk.
The
crawl
before
you
run
thing.
First,.
C
The
value
of
n
really
doesn't
matter
the
minimum
you
have
to
do.
There
is
Main
and
latest
release
branch
and
then
I'm,
just
asserting
at
that
point.
Maintaining
a
couple
extra
historical
versions
doesn't
wouldn't
be
a
lot
more
work,
but
I
would
Advocate
that
we,
you
know
close
the
door
at
some
point.
You
don't
necessarily
want
people
coming
looking
at.
You
know
0.8
release
and
complaining
about
things
that
work
that
way,
because
we
don't
care
anymore.
C
On
the
other
hand,
you
can't
just
throw
away
releases
as
soon
as
they
go
out
of
support,
because
people
I
mean
you
could.
Maybe
that
would
be
the
safest
solution.
Is
we
just
do
1.6
1.7
in
Maine,
but
you
at
least
have
to
do
1.7
in
Maine
and
I'm
just
saying
it
doesn't
sound
like
it.
A
lot
more
work
to
keep
some
historical
branches
around.
A
Maintain
them
as
and
make
changes
to
them,
but
it
could
like
it's
just
like
you
can
still
go
on
previous
tags
on
GitHub
and
look
at
the
docs.
Nothing
prevents
you
from
doing
that.
So,
like
the
book
like,
we
wouldn't
delete
that
book
URL.
It
would
still
be
there,
but
would
we
advertise
it?
Maybe
not,
but
we
would
at
least
want
to
keep
the
two
supported
branches.
C
B
Jack
I
am
just
not
convinced
because
I
I,
it's
a
significant
amount
of
work
and,
most
importantly,
like
maintaining
that.
If,
if
we
do
do
this,
then
there
are
two
key
things
that
we
have
to
do
in
order
for
this.
To
really
have
value.
One
is
that
the
documentation
from
each
branch
that
we
would
maintain
with
this
netlify
ux
would
have
to
be
really
integral.
B
So
we
would
have
to
really
be
good
about
updating
it
if
we're
just
going
through
the
exercise
of
creating
URLs
that
point
to
branches,
but
we
we
don't
actually
make
sure
that
the
documentation
is
really
clear
for
each
one.
Then
it's
then
it's
like
worse
than
not
doing
anything
in
my
view,
because
you're
you're
suggesting
that
the
documentation
is
really
like
hygienic
per
release.
So
it's
a
significant
amount
of
work,
in
my
view
to
to
clean
that
up,
especially
going
forward.
B
Just
don't
I'm
not
convinced
that
it's
a
non-trivial
amount
of
work
and
I
I
also
think
the
most
important
thing
for
me
is
that
I
feel
like
our
support
policy
is
a
really
kind
of
like
cve
emergency
support
policy,
which
is
to
say
that
if
there's
something
really
critical,
we
we
will
patch
an
N
minus
one
release
to
to
accelerate
the
process
of
getting
that
critical
fix
onto
our
user
Community,
but
not
that
we
actually
want
to
encourage
folks
not
to
continuously
upgrade
forward.
So
I.
Think.
B
If
we
maintain
like
these
canonical
URLs
for
for
older
versions,
then
we
aren't
we're
no
longer
encouraging
our
community
to
move
forward.
A
A
Don't
think
that
our
support
policy
is
emergency
cve
only
like
we
do
support
bug
fixes
like
we
backboard
bug,
fixes
and
so
I
think
that's
with
the
intend
that
people
are
given
that
grace
period
to
upgrade,
because
we
realize
that
the
moment
we
release
is
not
going
to
be
like
the
moment.
People
upgrade
so
I.
A
Think
like
the
reality
is
there
are
users
who
are
going
to
be
on
those
versions
still,
and
so
we
want
to
give
them
a
way
to
see
the
dogs
that
like
apply
to
their
version
that
they're
using
and
not
have
to
kind
of
deduct,
based
on
like
new
PRS
that
landed
like
oh,
this
doesn't
apply
to
me.
This
doesn't
apply
to
me.
So
it's
more
like
a
historical
snapshot.
More
than
like
a
living
documents,
I
think.
B
Right
and
to
be
to
be
clear
that
this
already
exists
because
the
docs
derive
from
a
strongly
versioned
source
of
Truth,
which
is
the
GitHub
repository,
so
I
I,
guess,
based
on
that.
What
I'm
suggesting
is
that
this
is
really
there's
no
functional
change,
with
the
exception
that
maybe
with
absent
this
convenience,
where
folks
don't
have
to
go
into
the
GitHub
UI
and
select
the
right
branch
and
then
go
to
the
markdown
like
that's
definitely
inconvenient.
There's
no
doubt
about
that.
B
So
what
I
think
we're
really
proposing
is
convenience
with
with
a
little
bit
of
Maintenance
costs
and
so
totally
on
board,
with
the
fact
that
that
our
release
branches
are
tightly
coupled
to
the
actual
documentation
that
actually
describes.
What's
going
on
in
those
branches.
A
Cool
I
think,
let's
still
focus
on
the
curl
for
now,
though,
like
this,
this
is
all
like.
I
mean
I
think
this.
This
would
be
useful,
but
it
would
not
like
be
something
we
do
like
right
away,
I
think
for
now
we
want
to
start
by
figuring
out
first,
if
we
can
change
this
to
release
and
it
just
works.
If
that's
the
case,
that's
great,
then
we
want
to
add
a
step
in
our
release
process.
That
is
allowing
us
to
do
that
every
time,
but
also
I,
think
before
we
even
do
that.
A
I
should
try
to
figure
out
if
I
can
get
all
the
other
maintainers
at
it
to
this
like
to
have
permissions
to
this,
just
because
I
don't
think
I
should
be
the
only
one
with
permissions
if
there's
a
step
in
the
release.
A
So
let's
start
with
that
and
then
maybe
then
we
can
see
if
we
want
to
have
some
sort
of
historical
release,
brunch
either
drop
down
or
place
where
people
can
see
it.
Does
that
sound
good?
A
Does
anyone
have
any
objections
to,
or
like
kind
of
concerns
about
us,
switching
the
main
like
the
default
Branch
to
be
the
latest
release?
Does
that
sound
shocking
to
anyone?
Okay,
oh,
got
two
hands
at
the
same
time.
I
don't
know
who
was
first
go.
C
So
just
to
clarify:
are
we
proposing
switching
from
Maine
to
1.7
release
branch
and
that's
that's
all
we
do
right
now
so
then,
effectively
the
main.
The
latest
stocks
would
no
longer
be
hosted
here
until
we
maybe
do
something
else
to
is
that
right?
Yes,
yeah.
A
Okay,
this
is
the
change
so
but
I
don't
know
if
this
would
just
work
out
of
the
box
or
if
this
requires
a
change
to
start.
So
that's
something
we
have
to
figure
out.
Oh.
C
A
Yes,
so,
okay,
that's
done
with
this!
So
let's
see,
if
there's
any
PR
that
changed
stocks
here.
B
A
Endpoints,
maybe
yeah:
let's
try
this
one
so
in
here
there
is
a
few
netlify
actions
that
run
including
one
called
deploy,
slash,
netlify
and
it
says
preview
is
ready.
If
you
click
on
details,
it
actually
brings
you
to
a
deploy
preview
and
then
this
is
like
essentially
what
that
book
would
look
like
with
that
change.
A
C
B
B
Cool
super
helpful.
A
You
can
go
to
where
is
it.
A
Deploys
so
if
you
have
access
not
again
not
everyone
has
access,
but
if
you
go
to
deploys
here,
you
can
see
all
the
previous
yeah
like
this
is
all
the
previous
deploys
so
like
this
is
the
production
Branch
for
example
yesterday,
so
this
must
have
been
when
something
merged
and
you
can
go
and
look
at
like
yeah,
so
I
think
this
main
dash
dash
actually
gives
us
Main,
so
I
could
share
that
URL,
actually
I
think
you
can
do
this
with
any
of
the
branches
that
get
deployed.
B
Cool
this,
this
all
seems
really
great
I
wanted
to
well.
Does
anybody
else
want
to
talk
because
I've
been
talking
a
lot
I'm
taking
for
granted?
That
you'd
raise
your
hand
if
you
want
to
talk
cool
I
I'm,
just
feeling
that
there's
something
we
might
be
forgetting
in
terms
of
how
to
manage
PR
flows
and
and
documentation.
B
If
we
make
this
change
so
you
know,
for
example,
a
new
feature
lands,
it's
documented
everything
goes
to
Maine
and
then,
when
the
next
release
is
cut,
you
know
we
update
netlify
to
point
to
this
new
release,
Branch
the
documentation
and
the
feature
land
at
the
same
time.
So
that
is
good
for
so
other
things
that
land
and
release
branches
are
bug
fixes.
B
Sometimes
we
curate
various
things
in
our
end
and
tests.
Those
typically
have
no
documentation
side
effects,
so
I
just
wanted
to
kind
of
walk
through
and
have
other
folks,
listen
to
me
monologue
and
also,
maybe
add
your
own,
like
we
want
to
make
sure
that
we
don't
have
to
change
the
way
we
actually
land
PRS
with
documentation.
If
we
make
this
change,
it
sounds
like
we
don't.
Are
we
confident
about
that.
A
Yes,
I
think
so,
and
I
mean
including
documentation
is
already
part
of
our
process.
It's
and
that's,
actually
why
we
get
in
this
weird
place
now,
where
features
get
put
in
the
book
before
they're
actually
available.
A
A
A
So
we
just
set
that
to
Lazy
consensus
for
Monday.
Please
take
a
look
and
once
again
thank
you,
John,
congratulations,
I,
I
think
this
is
a
reflection
of
all
the
work
you've
done
at
the
reviewer
already,
and
we
look
forward
to
your
future
contributions.
E
A
All
right
does
anyone
have
any
random
topics
or
questions
or
thoughts
that
they
want
to
bring
up
chats
anything.
A
Things
are
looking
busy,
so
I,
don't
know
if
you
wanna
what
would
be
most
useful
to
folks.
Do
we
want
to
just
go
through
every
single
one,
or
should
we
just
like
go
and
only
talk
about
the
ones
that
have
callouts.
A
C
B
Process
that
we
do
toward
the
end
of
the
dev
cycle,
do
we
want
to
look
at
PRS
and
just
I
mean
PR's,
I,
guess
at
this
point
in
the
dips,
like
we're,
probably
going
to
land,
no
matter
what
and
they
get
tagged
retroactively.
If
we
don't
do
that,
so
are
there
any
new
issues
that
we
want
to
potentially
definitely
include
or
definitely
not
include.
A
A
B
About
someone
in
terms
thanks
to
folks
for
interrupting
for
submitting
that
I
mean,
as
stated
I
I
was
like
sort
of
reading.
I
know.
Cecilia
you've
spent
some
time
engaging
with
that.
There's
an
initial
response
that,
like
as
described
that
bug,
is
like
well,
that's
not
a
bug,
that's
not
supposed
to
be,
but
it
seems
like
behaviorally
speaking,
we
are
putting
the
machine
pool
into
a
failed
state
erroneously.
Is
that
right.
B
It
doesn't
sound
too
super
controversial
that
that
are
that,
in
terms
of
cluster
API,
a
machine
pool
going
into
a
failed
state
would
then
get
recycled
to
create
a
successful
machine
pool.
So
there
must
be
something
slightly
subtle
going
on
where
we
were
reclassifying.
What
gets
called
failed
state
in
terms
of
the
machine
pool
so
that
that
doesn't.
A
Know,
I
don't
want
to
get
too
into
the
Beats
here,
but
it's
essentially
that
we're
deleting
the
whole
vmss
instead
of
deleting
an
instance
so
like
a
single
instance,
getting
like
failed
or
not
bootstrapping
properly
shouldn't
cause
the
whole
skill
set
to
get
deleted
with
all
the
other
health
instances.
I.
B
A
Cool
but
yeah,
let's
yeah,
let's
just
follow
up
basic
on
that.
B
A
Cool,
so
this
one
I
replied:
I'm,
pretty
sure
this
is
just
a
documentation
or
they
missed
the
docs
on
this,
but
it
is
supported.
I,
don't
think
this
is
actually
a
bug.
So
actually
let
me
just
remove
the
bug
label
and
is
there
a
question?
C
A
A
A
I
wonder
if
that's
something
we
can
look
at
after
the
move
to
workload
Identity
or
as
part
of
that.
A
Yeah
I
think
so.
The
cluster
identity
secret
is
not
owned
by
the
cluster
because
it
can
have
multiple
owners,
so
you
can
share
single
identity
secret
between
owners
or
between
clusters,
and
so,
if
you
move
your
cluster
to
a
new
cluster
to
a
new
management
cluster,
you
don't
want
your
secret
to
follow
because
we
don't
know
if
that
same
secret
is
already
being
used
by
other
clusters
in
that
Source
cluster.
So
you
don't
want
to
like
move
it
because
it
might.
It
doesn't
actually
belong
to
that
cluster.
A
A
Okay,
agentpool,
isn't
able
to
update
machine
pulling
non-terminal
state
I.
Think
is
that
one
that
you
were
looking
at
John.
E
This
was
the
one
that
I
couldn't
really
reproduce.
Okay,
so.
A
A
Okay,
this
one
is
I,
don't
think,
that's
really
a
a
bug.
More
of
like
an
improvement
in
ux
and
I,
don't
mean
this
is
less
than
1.8.
A
B
A
C
C
It
is
lame
to
deploy,
you
know
a
bunch
of
parts
of
the
cluster
and
then
have
the
VMS
fail,
and
you
have
to
dig
through
the
logs
to
find
out
that
that's
why
only
part
of
your
cluster
actually
came
up.
It
would
be
great
if
we
could
do
it
up
front,
but
I
agree.
That's
painful!.
B
A
A
Okay,
how
are
we
doing
on
time?
Okay,
I'll
timebox
this
to
another
three
minutes
just
so
we
don't
spend
too
much
time
on
this
okay.
This
is
also
not
a
bug.
A
I
think
we're
over
using
the
bug
label
because
it's
basically
a
bug
or
feature.
So,
let's
see
this
is
a
test
Improvement.
B
C
B
A
A
No
I
think
that's
different.
That's
not
the
one
that
I
should
talk.
She's
working
on
okay,
just
going
back
to
top
of
the
list
Matt
this
one
is
marked
as
important
soon
is
it
still
I.
A
C
C
A
Vlogging
yeah
yeah
I,
don't
think
we
have
something.
A
A
Cool
okay:
there
are
lots,
I
think
we
should
do
this
exercise
more
often.
This
just
shows
how
many
bug
labels
issues
we
have
that
we
haven't
looked
at.
A
D
A
A
D
A
A
Area,
okay
and
then
I
will
stop
there
for
now,
but
yeah.
If
anyone
is
looking
to
help
asynchronously
the
way
I
was
doing.
This
is
just
clicking
on
label
bug
and
then
no
Milestone
and
then
I
think
especially
the
ones
that
haven't
had
any
answers
like
very
few
comments
or
no
comments
are
good
to
look
at
and
kind
of
triage
to
see
if
the
person
is
still
needing
help
or
if
the
issue
got
resolved
or
if
it's
still
valid.
A
Cool
is
there
anything
in
the
Milestone
that
anyone
wants
to
call
out?
That
is
either
no
longer
be
there
or.
A
One
so
I
guess
for
that
one
we
met
John
Jonas,
give
a
quick
like
summary
of
what
the
strategy
is
there
on
the
SDK
V2,
slash,
ASO
potential
migration,
sure.
C
Well,
so
for
SDK
V2
I've
been
working
on
in
the
background.
Unfortunately,
I
have
some
higher
priority,
bugs
that
I've
looked
at
in
a
couple
days,
but
I'm
trying
to
convert
converting
the
SDK
V2
versus
V1
is
actually
relatively
trivial
or
mechanical.
Things
have
just
changed
names
in
a
few
and
locations
but,
as
I
said
before,
the
SDK
V2
uses
generics
and
go,
which
is
a
new
thing
for
our
code
base
and
doesn't
work
with
mock
gen
and
doesn't
doesn't
work
with
our
async
framework
in
particular.
C
So
I've
picked
the
public
IP
service,
I've
stubbed
it
out
and
I'm
writing
sort
of
a
replacement
for
the
async
framework
as
an
example
of
how
we
could
do
this
and
that
could
be
merged
on
its
own
at
some
point
and
and
coexist.
And
so
we
could
do
this
piecemeal,
but
I'm,
hoping
to
show
that
it's
not
that
we
can
convert
the
async
framework
over
to
a
new
framework
that
works
with
go
SDK,
V2
and
here's
how
we
did
it
for
one
service
and
yes,
there's
a
lot
of
work
left
to
do.
E
E
Kind
of
parallel,
so
I'm
working
on
integrating
Azure
service
operator
to
kind
of
transitively
consume,
SDK
V2,
so
Azure
service
operator
is
kind
of
its
own
set
of
controllers
that
map
Azure
resources,
kind
of
one-to-one
with
kubernetes
resources.
E
So
that's
something
we
could
use
to
do
all
the
stuff
that
we're
currently
using
the
SDK
for
and
I've
kind
of
just
started
exploring
how
that
might
work.
So
overall,
it
sounds
like
Matt
is
probably
further
along
with
SDK
V2
stuff,
but
that's
kind
of
something
else.
I'm
working
on
kind
of
in
the
background
go
ahead.
Jack.
B
That
explanation
was
great
for
both
of
you,
based
on
what
Matt
said,
which
I
think
is
what
this
is
really
referring.
Is
that
is
the
scope
of
that
correct
still,
given
the
the
two
things
that
Matt
and
John
are
investigating
cool,
it
sounds
like
a
v-next
thing
to
me
unless
I'm
wrong
about
how,
when,
when
we
talk
about
refactoring,
the
async
stuff
that
seems
like
it,
we
shouldn't
fit
that
into
the
same
release
as
like
graduating
a
Cancer
and
experimental.
It's
like
a
big
deal
go
ahead.
Matt.
C
Yeah
I
mean
I
think
it
may
happen
anyway.
We
may
find
out.
This
is
there's
just
a
lot
of
work
to
do
once
we
prove
that
it
could
work,
so
it
may
take
longer.
We
just
ideally
we
want
to
avoid
the
situation,
which
is
what
March
31st
I
think
is.
The
kiko
is,
is
the
date
where
they're
officially
is
not
supported.
B
A
Yeah
I
I,
don't
think
that
will
close
this
issue
in
this
Milestone,
but
I
think.
The
idea
is
that
by
the
end
of
this
Milestone
we'll
want
to
have
a
plan
for
like
what
the
actual
migration
will
look
like,
and
we
want
to
have
a
new
issue
that
has
all
the
services
that
need
to
get
done
and
a
pattern.
That
explains
what
exactly
needs
to
be
done
for
each
of
them,
so
that
we
can
then
just
like
divide
and
conquer
and
have
several
people
taking
the
services
and
moving
them
one
by
one.
C
A
B
A
A
D
No,
the
from
the
PRS
there's
the
pr
in
there
for
the
private
endpoints
that
Adrian
created
I'm
actually
doing
a
code
review
of
that
initial
review
of
his
work
today
tomorrow,
to
hopefully
send
that
off
for
a
reviewer
to
take
a
look
at
next
whenever
there's
time
but
I'm
trying
to
do
an
initial
review,
at
least
before
hitting
the
lifecycle
active
on
it.
D
So
I
believe
from
our
needs.
That's
the
last
Delta
for
what
we
need
to
fully
go
forward
with.
A
Cool
awesome
all
right.
If
there's
nothing
else,
I,
don't
see
anything
new
got
added
to
the
agenda.
I
guess
just
a
call
out
that
I
just
want
to
say
thank
you
to
everyone.
Who's
been
helping
doing
reviews.
Lately
we
are
at
one
page
for
PRS,
which
is
great
hasn't
always
been
the
case.
We
were
at
two
pages
for
a
long
time,
so
it's
nice
to
see
things
getting
closed
and
move
forward,
and
so
many
active
reviewers
in
the
project.
So
thanks.
A
All
right
hope
you
all
have
a
great
rest
of
your
day
and
we'll
see
you
online.