►
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).
B
I
think
we've
got
quorum
so
we'll
get
started
and
let's
focus
showing
we'll
welcome
them
and
go
from
there.
So
welcome
to
the
february
8
2021
meeting
of
the
azure
cloud
provider,
sig
cloud
provider
subproject
meeting
and
we
are
part
of
the
kubernetes
community,
so
let's
all
be
nice
to
each
other
by
abiding
by
the
cncf
community
guidelines,
and
I
pasted
the
link
to
the
agenda
in
the
chat.
If
you
don't
have
it
handy,
there
are
a
couple
of
items
on
the
agenda
and
I'll
propose.
B
We
just
go
down
the
one
by
one,
but
first
does
anybody
want
to
volunteer
to
be
a
note
taker?
Actually,
since
I
have
less
to
say
about
all
these
things
I'll
volunteer
to
take
notes.
B
Sure
that
probably
won't
be
a
whole
lot,
so
I
just
wanted
to
share
in
this
group
and
especially
for
anybody
who's
listening
to
the
recording-
since
I
think
everybody
here
already
knows,
but
as
andy
shared
earlier,
the
azure
file
csi
driver
has
moved
to
ga
that's
great
news
to
have
stability
in
that
driver.
So
I
think
a
gas
is
gonna
take
advantage
of
it
shortly
and
we
hope
lots
of
users
take
advantage
of
it.
A
A
B
B
B
Okay,
so
peg,
you
probably
know
best
is:
have
you
been
asked
to
prepare
a
maintainer
session
for
the
azure
cloud
provider
for
kubecon
eu,
or
do
you
know
anything
about
that?
I
I
have
not
seen
any
communication
about
that.
B
Okay,
I
know
that
the
the
committee
had
reduced
the
number
of
maintainer
sessions.
Yes,
so
it's
possible
that
the
azure
cloud
provider-
subproject-
wouldn't
have
its
own,
so
I'll
reach
out
to
andrew
to
find
out
if
there
is
an
overall
cloud
provider,
one
and
collaborate
with
him,
if
it
makes
sense
to
include
azure
content
there.
A
B
D
I
certainly
like
the
idea
of
just
having
a
standing
talk
at
every
kubecon
we've
sort
of
done
that,
historically,
with
some
success,
some
like
some
of
them
better
than
others,
but
just
basically
having
a
status
update
at
every
kubecon,
I
think,
makes
sense.
C
Sorry
go
ahead.
This
is
anecdotal,
but
in
sick
cluster
life
cycle
we
have
like
maintainer
talks
for
sub
projects
since
they're
so
different.
So
we
have
like
an
update
for
qbm
and
an
update
for
cluster
api,
usually
but
they've
started
asking
sigs
to
have
one
talk
per
sig.
I
think,
but
I
think,
if
there's
like
enough
justification
to
have
like
different
talks
for
different
sub-projects,
it
might
make
sense
to
have
like
an
azure
specific
one.
B
Yeah,
it's
tough
because
on
the
cloud
provider
front-
and
you
know,
northbound
api
is
obviously
the
same
with
the
other
cloud
providers,
so
the
southbound
is
where
the
differences
are
and
for
most
of
the
community.
It's
not
not
super
relevant.
So
it's
it's
hard
to
make
the
argument,
but
I'll
I'll
do
some
investigation
in
that
area.
Okay,
thanks
for
the
feedback,
any
other
thoughts
on
the
eu
before
we
move
to
the
next.
B
Subject
all
right,
so
the
next
is
an
issue
that
was
brought
up
just
today
by
j
vos.
B
From
vmware,
who
pointed
out
a
an
issue
that
I
think
is
the
same
issue
that
we
ran
into
with
aks
engine
last
week,
and
that
was
that
the
cloud
provider
broke
under
certain
conditions.
I
know
jackie.
I
think
it
links
to
an
issue
that
you
were
working
on,
whether
you
identified.
This
is
the
elb
node
level,
node
label
issue,
maybe
just
who
has
kind
of
the
best
handle
on
the
whole
issue.
C
I
can
give
context
so
that
specific
issue
is
actually
fixed,
so
this
new
issue
is
not
about
that
issue.
Thank
you,
chief
for
the
pushing
the
fix,
so
we
thought
we
only
saw
the
origin
original
pr
which
caused
the
that
issue,
but
there
was
a
follow-up
pr
that
fixed
it
so
that
issue's
good
the
issue
that
jay
opened
is
more
about.
C
So
it
would
be
really
great
if
we
could
have
some
sort
of
first
of
all
contract
which,
like
I
think
the
assumption
is
that
cloud
provider
isn't
going
to
make
any
assumptions
that
aren't
made
by
azure.
So,
like
everything,
that's
in
cloud
provider
should
work
for
like
all
of
azure,
but
in
some
cases
we
do
have
to
make
specific
assumptions,
and
if
those
assumptions
are
made,
it
would
be
great
if
they
were
documented
in
a
contract
so
that
every
provisioning
tool
can
like
adhere
to
that
contract
and
make
sure
that
they're
not
broken.
C
A
I
I
think
that
that
makes
sense
so
generally
for
club
provider.
It
shouldn't
make
a
lot
of
assumptions
across
different
results.
So
far
for
the
eco
you
reported
earlier
is
actually
caused
by
the
bug
and
and
then
back.
It
is
not
cut
during
our
engine
test
and
it
has
already
been
fixed
now,
so
so
it
shouldn't
have
a
much
easier
now,
but
for
the
general
contract.
I
think
cloud
provider
indeed
have
some
assumptions
for
the
underlying
error
result.
A
I
think
the
the
most
important
one
is
a
the
other
resource
should
be
inside
the
same
tenant.
So
we
we,
we
don't
support
a
cross-tenant
resource
for
the
cloud-provided
cell
and
also
the
other
other
resource.
Other
virtual
machines
should
be
behind
either
vmss
or
vmas.
It
shouldn't
shouldn't
be
a
standalone
virtual
machine.
I
think
that
that's
many
the
two
assumptions
so
for
other
cases
for
for
for
the
other
other
resource,
it
should
be
just
to
work
so
yeah
and
for
the
entering
test.
A
C
Yeah
we
have
the
tests,
but
they're,
not
pr
blocking
and
they're
only
running
on
releases,
not
on
the
faster
branch.
So
I
think
we
need
to
add
that,
for
so,
I
think
we
should
talk
more
about
the
assumption
that
you
can
only
have
a
vm
as
part
of
an
availability
set
or
vmss,
because
that's
actually
not
true.
Historically,
that's
not
been
the
case
like
we
do
this
in
cluster
api
right
now
and
we
use
azure
cloud
provider
and
it
works.
So
if
that's
an
assumption,
that
means
we
could
be
broken
by
this
assumption.
C
So
I
think
we
need
to
talk
about
that,
but
about
the
contract
in
general.
It'd
be
great
if
we
documented
those
so
they're,
not
just
like
hearsay,
and
we
have
them
on
paper.
Yeah.
E
B
So,
who
can
take
that
next
step
to
document
this
assumption.
C
Yeah
and
I'm
sure
other
people
who
weren't
able
to
join
this
meeting
are
also
interested,
especially
like
the
openshift
folks
in
giant
swarm,
who
aren't
you
know
using
cabsie
per
se,
so.
C
Documentation
all
right
great,
the
other
thing
that
would
be
great
to
include
in
this
is
which
resources
cloud
provider
expects
to
be
able
to
modify,
because
that
it
doesn't
create,
because
right
now,
aks
and
aks
engine
only
create
the
cluster
and
then
those
azure
resources
like
are
there,
and
then
you
can
make
any
modifications
you
want.
It's
not
gonna.
You
know,
try
to
reconcile
it,
whereas
with
cap
z,
we
like
reconcile
the
infrastructure
in
like
a
new
controller
right.
C
A
No,
I
I
think
each
writer
position
should
be
enforced
by
some
kind
of
e-text.
So
if
you
don't
know
the
tag
theme,
even
if
not
touched
by
cloud
provider,
it
may
cause
issues
when
custom
touches,
then
so
so
you.
E
You
should
always
use
the
tag
when
you
put
the
results
exactly
so
that's
an
assumption
or
that's
like
a
rule
right
or
contract.
D
Yeah,
I
would
imagine
lots
of
folks
now
just
sort
of
painfully
go
through
trial
and
error
reading
through
the
source
code
to
figure
out
how
to
make
their
diy
solutions
work.
So
we
probably
make
their
lives
a
lot
easier
if
we
just
basically
wrote
a
how-to
guide,
how
to
implement
kubernetes
on
azure
and
then
made
those
assumptions
like
actual
parts
of
the
contract.
So
we
kept
that.
B
B
It
was
called
out
by
jay
that
there
was
the
kept
for
the
semantic
versioning
policy
for
external
cloud
provider.
A
D
How
do
we
break
the
so
assuming
we
take
the
next
steps
and
document
the
contract
that
you
have
to
fulfill
in
order
to
implement
kubernetes
on
azure,
we
should
probably
have
a
plan
to
sort
of
how
do
we
purposely
break
that
contract
and
then
revenue
api.
D
B
C
D
I
would
say
the
the
recent
issue
that
we
were
tracking
that
was
fixed
was
actually
the
introduction
of
additional
validation
that
didn't
used
to
exist.
So
you
can
assume
that
the
the
cloud
provider
implication
before
that
was
much
more
tolerant
to
say
that
the
specific
case
was
the
name
of
the
nick
associated
with
the
vm,
and
so
a
change
was
introduced
to
sort
of
make
the
identification
of
that
nick
more
deterministic.
So
you
know,
regular
expression
was
introduced
to
say,
look
for
a
nick
that
looks
like
this,
but
that
wasn't
there
before.
D
And
so.
If
someone
had
been
running
a
successful,
azure
plus
kubernetes
implementation
using
their
own
totally
hand
rolled
infra
that
named
the
nick,
you
know
my
my
nick
xyz
or
something
then
that
would
have
suddenly
broke
so
that
kind
of
stuff
is
also
very.
A
Interesting,
I
I
think
that's
that's
the
the
bag
we
introduced
earlier.
So
generally,
we
shouldn't
assume
the
the
the
name
for
any
resource.
The
the
only
exception
is
the
virtual
machine
itself.
So
if
a
machine
name
should
be
same
as
this
hostname,
I
think
that
that's
the
only
assumption
for
the
name
but
for
other
results,
the
resource
name
itself
shouldn't
be
make
any
assumption.
A
A
I
mean
let's
review
more
on
the
pro
request,
so
there
would
be
a
list
of
assumption.
A
Yeah
and
it's
better
to
run
some
kinds
of
engine
tests,
so
if
classifier
will
support
all
kinds
of
features,
part
in
case
engine,
we
could
actually
switch
our
pull
request
to
ete
to
class
cpi,
but
I'm
not
sure
whether
that
is
that
is
possible.
For
example,
it's
called
load
balancer
because
we
see
a
lot
of
breaking
changes
from
network
team
recently.
C
Yeah,
that's
actually
on
our
roadmap
to
do
that.
We
have
the
pr
the
test
running
in
periodic
right
now
in
the
sig
azure
tab,
but
they're
not
running
as
part
of
pr's.
C
D
And
maybe
I
can,
I
can
audit
the
aks
engine
and
test
to
make.
I
mean
it's
really
hard
to
test,
as
I'm
sure
you
know,
pink
fade
all
the
different
possibilities
of
building
kubernetes
clusters,
but
I
can
audit
the
way
that
aks
engine
specifically
is
being
tested
to
see.
If
there's
some
easy
things,
we
can
do
just
add
a
little
bit
more
functionality
into
the
cluster
config
to
get
more
surface
area
coverage
with
the
tests
that
we're
already
running.
That
might
be
an
easy
win.
B
B
B
We
have
well,
it's
really
trimodal,
I
guess
we
have
and
it
kind
of
corresponds
to
where
people
are.
So
we
have
a
group
of
people
who
are
in
europe
who
prefer
early
morning,
pacific
time,
and
we
have
a
group
in
asia
who
prefer
late
in
the
day
pacific
time,
and
then
we
have
our
pacific
time
folks,
who
prefer
slightly
less
early
or
slightly
less
late
times.
B
It's
not
a
big
surprise,
so
we
had
at
one
time
in
the
past,
switched
to
have
our
meetings
kind
of
alternating
between
times
and
then
what
happened
is
that
nobody
from
the
europe
time
zone
ever
actually
came,
and
so
those
meetings
ended
up
being
no
ops,
but
I've
been
getting
more
and
well.
We
have
had
this
meeting
at
this
time
very
rarely
either
because
I've
had
issues
or
because
there's
been
no
agenda
items,
and
that
was
our
agreement.
B
B
You
know,
should
we
focus
less
specifically
on
azure
cloud
provider
and
broaden
the
scope
to
more
being
in
office
hours
about
running
kubernetes
on
azure
in
a
more
general
sense.
That's
one
option.
Another
option
would
be
to
switch
back
to
kind
of
alternating
times
for
cloud
provider
or
even
doing
both
right.
We
could
because
they
may
serve
different
purposes
right.
The
kind
of
conversations
we
have
you
know
the
problem
we
have
here
is
that
it's
just
us
chickens
who
work
on
this
stuff
and
we
don't
have
any
users
in
this
conversation,
yeah.
A
I
I
think
so
so
I
I
think
we
should
expand
the
meeting
to
moscow
to
to
talk
about
the
the
communists,
the
general
running
communities
on
error.
So
this
is
includes
the
cloud
provider,
but
it
should
also
include
some
customs
to
join
our
meeting.
B
B
Yeah
and
then
and
then
we
would
record
it
and
would
you
you
know,
because
it's
very
important
that
you
and
chi
and
andy
are
able
to
you
know
at
least
get
asynchronous
communication
from
that
channel.
Since
you
know
you're
three
of
the
primary.
A
B
A
Yeah
so
so
I
I
think
the
meeting
is
actually
one
of
the
best
ways
to
collect
the
custom
feedback,
but
the
current
medium
are
actually
no
custom
join,
so
we
have
no
chance
to
collect
them
directly.
B
So
I
think,
that's
I
don't
know
jack
seems
to
agree
in
the
chat
that
if
we
do
the
alternating
and
we
have
a
europe-friendly
and
asia-friendly
meetings,
we'll
switch
back
to
that
and
and
then
for
the
europe-friendly
one.
B
I
might
reach
out
to
some
individually
to
coax
some
some
more
participation,
because
you
know
they'll
get
more
out
of
it
if
they
participate
more
and
and
then
that
way
we
would
meet
in
this
time
zone
at
this
kind
of
time
once
a
month
and
then,
once
a
month
at
the
european
friendly
time,
are
there
any
objections
to
that
model?.
C
B
Yeah,
I
I
I
I'll
work
specifically
with
the
gbb
team,
who
has
created
exactly
that
already
to
make
sure
that
we
differentiate
from
that.
So
they've
created
a
an
aks
office
hours
and
we
can
even
advertise
that
aks
office
hours
in
our
meeting
invite
to
help
redirect
those
people
who
have
aks
specific
questions
and
therefore
at
least
filter.
Some
of
that
out
does
that
make
sense.
D
I
think,
like
the
the
csi
announcement
today,
that's
a
perfect
general
purpose,
type
thing
that
we
would
want
to
keep
folks
current
on
every
two
to
four
weeks.
You
know
that
going
ga
status
of
like
for
now
the
status
of
21,
how
how
the
release
1.21
is
looking
from
our
test
signal
perspective
status
of
windows,
all
the
various
things
that
folks
are
kind
of
working
on
it
would
be
nice
to
be
able
to
announce
those.
E
B
I'll
I'll
put
together
some
draft
communication
around
exactly
that
plan
and
share
it
with
this
audience
for
a
quick
review
and
then
I'll
implement
the
schedule
changes
in
a
week
so
that
they
show
for
the
following
meeting
sound
sound
good
awesome,
yeah.
B
At
the
end
of
the
half
hour,
are
there
any
other
items
anybody
wants
to
bring
up
in
this
meeting.