►
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
Okay,
welcome
to
the
November
4th
edition
of
the
Sig
cloud
provider
as
a
cloud
provider
sub-project
meeting.
This
is
a
meeting
in
the
communities
community
and
it's
such
as
governed
by
the
code
of
conduct,
and
that
just
means
we're
all
going
to
be
nice
to
each
other.
Okay,
and
it's
it's
just
a
few
of
us-
it
should
be
short
and
sweet
and
I
can
see
Steven.
You
already
have
the
notes,
open,
I,
believe
you
probably
added
the
Reuben
a6
migration
agenda
item
yeah,
so
I
actually
there's
a
several
things.
We
can
talk
about
that.
A
B
So
basically,
what's
happening
is
so
I
called
for
lazy
consensus
on
that
issue,
and
that
has
since
been
achieved
this
Friday.
So
what
we're
going
to
do
is
start
proceeding
with
migration
from
so.
Basically,
this
is
the
external
cloud
provider
Azure
migrating
from
the
kubernetes
org
into
the
kubernetes
sigsworth.
So
as
policy
when
we
create
new
repose
for
kubernetes,
if
they
are
sig
related
and
not
core
kubernetes,
so
core
grooving
ideas
relating
to
core
components
of
entry,
gerber
Nettie's,
then
they
should
be
created
in
the
kubernetes
SIG's
org.
B
So
this
is
just
moving
forward
with
that
with
that
work
or
that
migration.
So
there
are
a
few
things
that
we
have
to
look
at
things
that
would
be
immediately.
Concerning
would
be
the
is
the
link
going
to
change
right.
So
the
link
does
change
from
kubernetes
cloud
provider
Azure
to
kerbin
at
e-cigs
right
Roger.
That's
not
a
big
deal
since
github
handles
the
redirect
if
you've
migrated
the
repo
only
once
right,
if
you've
changed
name
of
the
repentantly
once
so.
That
should
be
fine.
We
also
have.
B
B
Hopefully,
today,
I
think
that'll
work
fine
today
and
then
put
a
hold
on
them
until
we
do
the
repo
migration
and
then
unhold
them
all,
and
once
once
that's
done
so
it
should
be
quick
and
painless.
If
you
are
using
the
external
cloud
provider
and
see
any
weirdness,
please
let
us
know
the
channel
for
slack
is
a
provider
Azure
and
then
the
mailing
list
is
kubernetes
provider,
Azure,
kubernetes
provider
measure
at
Google,
Groups,
calm,
cool.
A
This
is
the
quiet
hour:
okay
got
it!
Okay,
since
we
kicked
off
for
several
people
had
joined
they're,
a
couple
of
names,
I
don't
recognize,
and
we
like
to
welcome
new
participants
and
I.
Think
well,
since
there's
so
few
of
us
on
here,
I
think
we
can
do
just
a
quick
round
of
introductions.
Just
so
folks
know:
who's
working
on
provider
is
your
so
I'm
Craig
Peters
I'm,
a
p.m.
at
Microsoft
working,
all
kind
of
open
source,
kubernetes
related
projects,
I'm
gonna,
go
and
order
across
my
screen.
B
Hello,
hello,
everyone
I
am
the
I'm,
a
senior
cloud
native
architect
at
VMware
I
work
on
I'm,
also
one
of
the
emeritus
chairs
for
sig
Asher.
Currently,
one
of
the
sub
project
owners
for
cloud
provider
Azure
also
one
of
the
primary
maintain
errs
for
cluster
API
measure
and
what
else
sig
release
share
and
sig
p.m.
chair.
So
hey.
A
A
They're
various
very
yeah,
so
one
I'm,
aware
of,
is
that
on
October
16th
they
rolled
out
an
update
to
the
extensions
mechanism
for
vmss.
It
included
a
bug,
so
many
people
who
operated
scaling
operations
on
clusters
that
existed
before
that
date
and
had
stateful
sets
faced
issues
with
the
state
of
disk
detachment
from
VMs
when
workloads
moved
within
IBM
SS
after
that,
so
we've
since
resolved
those
issues
to
the
best
of
my
knowledge,
I
haven't
been
able
to
find
any
new
instances
of
that
that
that's
that's
the
most
recent
one
that
I'm
intimately
do.
B
A
D
A
C
A
D
B
So
there
will
be
impact,
but
I'll
be
landing
PRS
to
basically
change
the
testscore
jobs
over
to
the
correct
repo,
so
basically
they're
all
they're
part
of
the,
like
the
pod
utilities,
annotations.
That
will
be
like
where
you
point
what
repo
you
point:
posts
emits
or
periodic
stew,
so
that
just
needs
to
be
edited
and
we
need
to
make
sure
that
they
land,
basically
after
the
repo
moves
right,
yeah.
A
So,
in
the
last
three
weeks
the
team
has
been
focused
on
creating
many
improvements
to
the
way
in
which
the
cloud
provider
and
the
Cloud
Controller
manager
interact
with
the
azure
api's,
including
optimizing
the
number
of
calls
treating
back
offs
differently
and
creating
more
configurations
for
API
back
offs,
and
some
caching
and
the
team
is
doing
some
benchmarking,
which
we
can
publish
here,
I
believe
for
the
next
meeting.
That's
my
expectation
anyway.
A
A
C
A
The
number
of
calls
left
in
your
waiting
time
quota
against
a
particular
resource
is
definitely
one
of
those
that
would
be
a
fun
chart
to
watch
as
this
decreases
and
then
increases
again
will
be
nice
sawtooth,
but
sort
of
tracking
the
minimums
over
time
could
definitely
be
useful.
So,
yes,
as
with
the
changes
to
the
way
in
which
was
calling
the
API,
is,
and
reducing
the
number
of
api's
API
calls,
you'd
need
to
upgrade
to
newer
versions
of
kubernetes
to
to
get
the
benefit
of
those.
Is
that
something
that's
possible
in
your
environment
and
say.
C
C
A
No
I
think
that's
a
great
point
and
right
up
it
pasted
it
into
the
chat
tracking
issue,
an
issue
that
is
tracking
that
and
you
can
certainly
follow
a
one
there
and
we'll
we'll
be
adding
the
metric
stuff
coming
tune.
Or
if
you
want
to
contribute
to
that
as
well,
we
definitely
invite
all
kinds
of
contributions,
including
that
there.
B
B
A
We're
taking
into
account
the
different
user
personas
as
we
as
we
define
where
and
how
those
get
exposed
and
we'll
provide
guidance
about
how
to
get
the
right
data
to
people.
So
you
know,
obviously
we
will
have
an
integration
into
Azure
monitoring,
but
I
I
really
want
to
expose
things
in
raw
prometheus
metrics,
so
people
can
hook
it
into
whatever
monitoring
system.
They're
they're
using.
A
And
all
right
last
call
for
issues
right.
You
did
that.