►
From YouTube: SIG Cloud Provider 2021-12-08
Description
Election for new SIG Cloud Provider co-chair.
Move to match cloud provider versioning with K/K versioning.
Discussion on zone label usage
Support for mixed protocols (IPV4 and IPV6)
A
Welcome
to
the
wednesday
december
8
2021
sig
cloud
provider
meeting.
As
always,
this
meeting
is
part
of
the
kubernetes
project
in
the
cncf
and
we
are
abide
by
their
general
rules
of
behavior.
So
please
be
considerate,
inclusive
and
polite
to
all
your
fellow
contributors,
and
with
that
I
think
we
can
begin
the
meeting.
A
C
D
Yeah,
I
did
chat
with
folks
about
making
sure
we
talked
a
few
meetings
ago
about
making
sure
that
the
provider
azure
releases
were
lined
up
numerically
wise
with
the
kubernetes
releases
and
they
are
making
that
adjustment
per
their
next
release
so
follow
up
based
on
what
was
discussed
on
this
call.
No
other
major
changes
just
keep
on
keeping
on.
A
A
The
other
piece
of
interest
that
is
worth
noting
is
quite
a
few
folks
have
been
asking
us
about
having
official
releases
of
the
cloud
provider
ccm,
so
we're
starting
to
look
into
putting
in
the
the
infrastructure
to
generate
the
builds
of
the
cloud
provider.
Gcp
ccm,
I
imagine
if
we're
being
asked
to
do
that
other
providers
are
also
going
to
so
I
think
it's
things
like
kind
that
are
really
driving
that
I
don't
think
we
have
anything
from
huawei,
no
updates
from
ibm.
E
A
A
It's
a
little
unfortunate
on
the
timing,
because
there's
a
new
version
we'd
like
to
get
shipped
and
we
made
it
or
I
made
a
small
error
on
the
go
versions.
I
used
the
rd.
I
set
the
api
server
network
proxy
to
the
latest
kk
dependencies
and
that's
caused
a
few
problems
for
the
oldest
release
kk
release.
So
we
probably
need
to
set
the
dependencies
on
api
server
network
proxy
to
be
the
oldest,
supported,
kk
release
rather
than
the
newest.
A
A
A
F
C
A
A
A
A
A
A
G
F
So
the
topology
are
first-class
kubernetes
labels,
but
the
there's
no
guarantee
for
any
cluster
that
it
it
that
it
sets
the
label
on
the
nodes.
But
we
do
we
actually
so
tim
hawkins
put
together
a
kep
on
the
expected
semantics
of
the
labels
and
like
the
way
the
topology
hierarchy
is
supposed
to
work.
But
aside
from
that,
it's
not
strictly
required
in
any
cluster.
Let
me
find
that
kept
for
you.
Yeah.
A
G
F
Some
of
this
stuff,
it
is
failure
domain
was
what
it
was
called
initially
and
it
was
prefixed
with
beta
and
then
so.
Maybe
this
is
my
fault,
because
I
did
the
pr
for
this,
but
we
we
really
wanted
to
rename
it
to
signal
that
it's
ga,
but
it's
hard
to
rename
labels,
because
you
have
people
with
node
selectors
using
those
labels.
So
we
just
we
backfill
it.
So
we
have
both
labels
now
and
we're
slowly,
phasing
out
the
failure
domain
beta
labels,
but
they're
supposed
to
behave
in
the
same
way.
A
Yeah,
and
just
just
as
a
quick
background
for
folks,
a
lot
of
the
the
cloud
providers
have
sort
of
this.
What
I
mean
in
what
is
in
google,
known
as
the
zone
and
region
breakdown,
where
multiple
zones
make
up
a
region,
and
so
the
idea
here
is
to
allow
for
certain
particular
behavior.
So,
for
instance,
if
you
have
a
service
that
you
want
to
make
in
an
aha
environment,
you
want
to
make
sure
that
you're
running
one
instance
of
your
service
in
every
failure
zone.
A
A
G
Yeah
I
mean
that
that's
great
and
and
honestly
like
walter,
the
use
case
that
you
just
kind
of
mentioned.
There
is
kind
of
it's
it's
not
the
same
area
but
like
topically,
it's
very
similar
to
what
this
colleague
was
asking
me
about,
because
they
they
were
curious
like
if
they
could
depend
on
this
zone
label
being
set
so
that
they
could
build
automation
around.
You
know
being
able
to
do
similar
types
of
things
where
you
want
to
have
zone
awareness
about
like
nodes
that
are
in
your
cluster,
so
yeah,
it's
really
illuminating.
A
F
Yeah
yeah,
like
you'll,
see
it
like
in
vsphere
and
bare
metal
installs
like
you'll
you'll,
see
the
zone
labels
being
used,
but
it
becomes
a
bit
more
arbitrary.
Where
you
know
a
zone
might
be
a
rack
and
a
region
might
be
a
data
center
or
something
like
that.
But
I
would
say
it's
it's
pretty
standard
like.
I
would
assume
it's
there
all
the
time,
and
the
special
case
would
be
that
it's
not
there.
If
that
helps
at
all.
E
Yeah,
I
can
say
through
the
the
vmware
user
group
that
I
don't
think
it
is
guaranteed
there,
but
it's
very
commonly
used,
so
nothing
forces
somebody
to
put
it
in,
but
it's
up
to
the
user
to
decide
what
their
failure
domains
might
be.
You
know
you
could
elect
for
it
to
be
a
single
blade,
server,
a
rack,
an
aisle
and
a
lot
depends
on
what
you've
got.
I
mean
some
people
don't
have
multiple
aisles,
and
so
the
the
actual
deployment
in
process
varies
in
terms
of
making
a
move
to
standardize
it.
E
E
The
experience
is
that
the
usage
of
those
labels-
I
don't
think
it
is
standardized,
and
that
might
be
a
good
thing
just
because
it's
up
to
them
to
decide
what
their
failure
domains
are
based
on
their
perceived
risk
and
what
their
particular
situation
is.
And
when
you
get
to
on-prem,
there
might
be
quite
a
bit
of
variance
there.
A
G
That
I
mean
these
are
some
great,
like
great
thoughts
being
tossed
around
here.
I
really
appreciate
it
and
I
totally
get
that
like
there's,
also
like
a
kind
of
an
impedance
mismatch
at
some
level
like
this,
this
zone
label
doesn't
apply
to
all
infrastructure
providers
and
especially
when
we
get
into
some
of
the
more
cutting
edge
kind
of
weirdo
providers
where
things
are
sliced
not
specifically
to
instances
or
something
like
that,
you
know,
then
it
looks
much
more
different
and
honestly,
you
know
the
it's
interesting.
G
A
F
It's
probably
worth
mentioning
people,
because
you
mentioned
the
csi
driver
also
had
the
zone
so
there's
a
topology
aware,
but
there's
a
topology
feature
from
the
csi
driver
as
well,
and
there's
a
there's
like
a
there's.
A
api
contract
between
those
two
between,
like
the
the
node
label
set
by
the
cloud
provider
and
the
csi
driver
to
standardize
on
the
the
topology
labels
to
agree
on
the
zone
region
metadata.
So
you're,
probably
seeing
like
the
volume
based
labels
being
set
by
the
csi
topology
driver
and
then
on
the
nodes.
It's
the
ccm.
A
D
Yes,
thank
you.
So
we've
talked
before
on
this
call
about
that:
supportive
mixed
protocols
and
services
with
type
load
balancer
that
is
currently
sitting
in
alpha
and
there
are
folks
who
want
it
to
be
moving
forward.
So
I
am
gathering
all
the
information
needed
to
move
it
forward
to
beta,
and
there
were
a
few
remaining
questions
in
my
mind
at
least
like
we
got
an
answer
from
tim
hawkin
as
of
september
3rd,
at
least
this
year.
Google
cloud
had
not
implemented
anything
for
you
know
supporting
or
indicating
non-support
properly.
D
It
appears
when
I
got
answers
back
from
other
folks,
so
it
appears
just
about
every
other
cloud
wants
to
handle
it
correctly.
So
tim
did
indicate
when
it
was
discussed
before
that
it
wasn't
going
to
be
incredibly
hard
to
at
least
air
correctly,
but
just
highlighting
that
for
our
google
friends,
because
it
looks
like
we
have
con,
you
know
we
have
a
general
weight
of
people
would
like
to
move
this
forward
and
or
are
ready
for
it
to
move
forward.
D
A
Quick
note
on
that,
if
you
don't
mind
me
interrupting
absolutely,
please
do
tim
is
nightmarishly
busy.
He
he
does.
Okay,
everything
I
mean
literally,
does
everything
so
you
might
be,
even
though
he
will
also
be
busy
you're,
probably
going
to
get
better
traction
if
you
engage
with
bowie
on
this
yeah,
absolutely.
D
I
will
mention
just
I
will
at
mention
bowie
on
the
issue
and
just
ask
him
hey
on
the
enhancements
issue.
Let's
take
a
look
and
then
I
have
a
couple
of
other
questions
like
there's
an
issue
in
here
or
sorry,
one
of
the
hey.
We
should
make
sure
coop
proxy
doesn't
proxy
on
ports
that
are
in
an
error
state
and
I'm
like
okay,
that
was
in
the
you
know,
original
plan
and
I'm
wondering
who,
if
anyone
would
you
recommend
that
I
talk
to
you
to
verify
that.
D
Spelling
sorry
yeah,
so
there
was
a
from
the
original
plan.
It
said
the
coop
proxy
should
use
the
port
status
information,
blah
blah
blah
so
that
it
doesn't
allow
traffic
on
ports
that
couldn't
be
opened,
so
basically
don't
proxy
ports
that
are
in
error,
state
and
I'm
kind
of
wondering,
because
I'm
trying
to
pick
this
up
and
move
it
forward
from
somebody
who
kind
of
left
it
does.
Anyone
know
who
the
right
person
to
talk
to
is
to
verify
and
check
into
that.
D
H
D
D
D
F
A
D
A
D
I
did
want
to
remind
people
if,
if
you
weren't
paying
attention
one
of
the
very
exciting
things
that
happened
in
kubernetes
1.23
is
the
ipv4
ipv6
dual
stack
going
to
stable.
So
if
your
cloud
provider
wants
to
be
super
fancy,
you
could
get
with
that.
I
know
the
cloud
provider
I
work
for
is
certainly
going
to
get
with
that,
and
perhaps
you
could
as
well
and
then
all
the
customers
would
be
happy.
D
All
right,
I
just
talked
to
a
pm
on
arrow.
This
is
the
azure
red
hat
open
shift
like
azure
plus
openshift
equals
excitement,
and
I
just
talked
to
the
pm
and
said:
hey:
can
we
get
somebody
to
answer
this
person
so
conversation
ongoing?
I
will
get
sometime
in
the
next
week.
I
will
get
either
me
or
this
person
answering
it
feel.