►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro + Deep Dive: Cloud-Provider SIG - Chris Hoge, OpenStack Foundation, Andrew Sy Kim, VMware, & Jago Macleod, Google
This SIG-Cloud-Provider session will begin with an introduction to the SIG activities in representing the collective interests of all participating cloud providers in the Kubernetes ecosystem. The session will then move on to the status of current efforts to remove the in-tree cloud provider code from the Kubernetes code base and replacing this code with the Cloud Controller Manager interface and external provider code. Time permitting, we will also cover collaborations with other SIGs such as Docs, Testing, and Cluster Lifecycle.
https://sched.co/MPkm
A
A
A
All
right
so
yeah,
like
I,
said
agenda.
So
Sagan
trove
gonna
talk
about
talk
about
our
charter
areas
of
focus
sub
projects,
and
then
we
have
a
few
items
lined
up
for
the
discussion,
but
we're
gonna
try
to
also
get
a
poll
from
people
to
see
if
there
are
any
other
like
new
topics
that
we
want
to
discuss
so
yeah.
A
All
the
API
is
and
interfaces
to
provision
and
delete
resources
that
are
associated
cluster,
how
to
configure
a
cluster
to
actually
enable
that
integration
and
testing
and
testing
frameworks
against
kubernetes
and
the
providers,
and
so
these
are
not
gonna,
go
over
all
them.
But
these
are
some
of
the
things
that
we,
we
own
interfaces,
type
controller
manager,
some
of
the
EDD
test
opponent.
One
is
all
the
sub
projects
that
were
owned
by
some
of
the
previous
provider:
specific
SIG's.
A
We
have
an
effort
to
kind
of
fold
the
governance
structure
so
that
we
have
all
the
providers
and
do
it
under
a
single
sake.
So
we'll
talk
more
about
that
later
and
then
we
also
do
some
cross-cutting
work
with
cig
testing
and
cig
release
to
make
sure
that
we're
bundling
all
the
claw
provider
traditions
together
in
the
releases
way
we're
working
with
cig
Doc's
to
write
better.
You
know
documentation
on
how
to
enable
that
cloud
provider,
integration
and
all
the
features
that
it
comes
with
and
all
that
stuff.
A
Yeah,
if
you
want
to
check
out
what
sub-projects
me
on
again
go
to
the
community
repo
under
six
a
provider
and
in
the
readme
there
we've
kind
of
list
out
all
the
other
code
bases
that
are
sick
home.
So
if
you
want
to
make
changes
to
any
of
these
posit
or
E's
come
join
our
cig
meeting
and
you
can
can
chat
about
all
that
stuff.
A
B
B
I
know
it's
siesta
time,
but
we're
gonna
ask
you
to
sit
up
and
participate
a
little
bit
and
wake
up,
and
so
what
we're
gonna
do
is
spin
through
a
description
of
a
few
pre
planted
discussion,
topics
and
then
open
for
any
suggestions
of
discussion,
topics
that
are
about
the
same
level
of
granularity,
we're
gonna
vote
on
order
and
we're
gonna
kind
of
time
box,
but
work
through
an
order
of
the
votes
we
receive.
It's
gonna
be
not
really
scientific,
but
it'll
be
close
enough
and
some
rules
for
engagement,
one
be
respectful.
B
B
Please
introduce
yourself
maybe
what
you
work
on,
or
what
your
interests
are,
the
first
time
you
speak,
you
don't
have
to
do
it
every
time,
but
that's
also
helpful,
and
the
goal
here
is
to
get
various
perspectives
on
an
idea
not
to
just
trade,
the
mic
back
and
forth
between
two
people.
So
we
as
moderators
may
ask
you
to
give
someone
else,
an
opportunity
to
speak
and
yeah.
We
talked
about
the
talking.
Spec
stick
literally
raise
a
hand,
and
one
of
us
will
get
you
a
mic.
B
B
The
initial
set
of
seven
cloud
providers
existed
in
kubernetes
kubernetes,
that's
what
what
we
mean
by
entry
and
then
it
became
clear
as
there
were
potentially
dozens
now
there's
something
like
80
providers
of
kubernetes
that
are
certified,
conformant,
kubernetes
distributions
or
platforms.
We
didn't
want
86,
and
so
it
became
clear
that
we
needed
a
different
way
to
organize
the
code
and
not
compile
into
kubernetes
itself
every
cloud
provider
implementation.
B
B
So
this
is
one
and
we
have
a
proposed
timeline
for
that.
Another
is
the
sig
governance
and
we
talked
a
little
bit
about
folding
the
existing
cloud
provider
SIG's.
We
have
a
sig
GCP
folding,
that
under
the
cloud
provider
as
a
sub
project
of
sig
cloud
provider,
one
of
the
issues
that
existing
SIG's
had
was
time
at
these
events
and
some
of
the
infrastructure
around
slack
channels
and
ways
that
their
users
can
find
them
for
support.
And
so
user
groups
are
replacement
for
this
concept.
B
That
we
think
is
the
right
way
to
go,
but
this
discussion
would
be
about
what
are
some
of
the
benefits
that
folks
still
have
concerns
about,
or
how
should
we
model
that?
And
what
are
the
weekly
meeting
structures?
Is
there
and
being
consistent
on
that,
so
that
end
users
can
find
the
right
place
to
ask
the
questions
and
fan
that
out?
B
We
just
talked
about
user
groups.
These
still
need
some
more
definition.
This
is
an
idea,
but
not
a
really
fully
fleshed
out
concept.
Yet
we
need
some
concrete
requests
to
ask
of
the
CNC
F
to
make
sure
that
providers
have
the
right
infrastructure
to
provide
value
to
their
end
users,
and
we
need
some
level
of
expectations
or
criteria
for
a
cloud
provider
to
get
that
infrastructure.
There's
a
cost
to
us
as
a
community
for
maintaining
that
we
have
two
users.
B
Maybe
you
don't
need
a
weekly
meeting
and
a
slack
channel
under
this
and
of
that,
but
it's
still
useful
to
be
able
to
discover
at
the
same
level
and
one
of
the
concrete
questions
like
how.
How
long
do
we
think
we
need
for
a
user
group
session
in
San
Diego,
which
is
cube
con
at
the
end
of
this
year
and
then
I
think?
The
last
of
the
example
are
proceeded.
Topics
was
the
code
Organization
for
cloud
provider
sub-projects,
and
this
one
gets
tricky
really
in
the
hierarchy
of
this.
B
We
want
to
make
sure
that,
as
we
break
down
into
more
and
smaller
sub
projects,
we
don't
make
it
impossible
to
find
what
you're
looking
for
so
some
level
of
expectation
around
how
to
find
those
things.
Oh
one
more
enhancements.
Yes,
so
we
have
had
many
requests.
This
has
a
risk
of
becoming
the
junk
in
the
trunk
Zig,
where
everything
ends
up.
If
it
doesn't
have
a
home.
B
Everyone
has
an
opinion.
We
just
need
to
figure
out
how
to
order
the
process.
We
can
come
to
decisions
that
are
reasonable,
given
where
we
are
now
credential
providers,
they're
kind
of
similar
iam
concepts
and
multiple
providers.
It's
really
hard
to
come
up
with
the
right
level
of
abstraction
that
isn't
just
the
minimum
kind
of
bare
minimum.
B
So
come
those
require
deep
thought
and
real
proposals
and
compromise
so
rate
limiting
libraries
and
utilities
for
cloudy
api's
api.
It's,
I
won't
read
them
all,
but
these
are
really
the
the
general
bucket
here
is
how
to
draw
that
lines
of
scope
so
that
we
can
make
progress
and
not
just
have
conversations
but
actually
make
progress,
and
what
we
want
to
do
here
is
figure
out
what
are
the
highest
priority
topics
to
consider
and
make
progress
on
in
the
next
several
releases,
rather
than
getting
20%
of
the
way
everywhere.
A
B
D
Hi,
my
name
is
Doug
helm
and
I
work
at
Red,
Hat,
I'm,
working
on
a
bare-metal
provisioning
tool
for
kubernetes
and
I'm,
trying
to
figure
out
so
I've
been
engaging
with
the
cluster
API
group
and
I'm
interested
in
figuring
out
like
if
we
brought
something
upstream.
Would
it
live
in
that
group?
Would
it
live
in
this
group?
You
know:
do
we
have
cloud
provider,
not
a
cloud
or
is
it
some
other
thing
or
is
the
group
scope
too
limited
I,
don't
know
whether
that
fits
into
the
governance
question
or
the
you.
B
Know
it's
a
really
good
question.
We
did
actually
just
briefly
I'll
say
we
struggled
with
the
name
of
the
cloud
provider
sig
initially
whether
it
was
just
provider
that
seemed
a
little
too
vague
for
exactly
this
reason,
but
I
think
there
are
qualities
that
either
public/private
or
otherwise
type
of
flexible
environments
may
provide,
and
it's
a
totally
reasonable
topic.
So
thank
you
for
that.
One
yeah.
C
And
I
actually
have
an
answer
to
the
specific
question
based
off
of
the
contributor
you
know
over
the
last
week.
So
if
you
think
of
Sigma
provider
as
at
a
high
level,
it's
an
advocacy
group
for
all
of
the
providers,
and
so
we
all
have
common
interests
and
common
goals
and
sig
cloud
provider
is
a
way
to
express
those
to
the
larger
kubernetes
community
and
advocate
for
those.
And
so
one
of
those
is
how
do
we?
How
do
we
manage
and
organize
code
repositories?
C
They
would
like
us
to
do
that
in
our
conversations
with
cluster
lifecycle
on
Monday,
for
the
time
being,
while
they're
still
figuring
out
how
they
the
projects
to
work
and
how
they
want
them
to
be
organized.
They
are
going
to
take
on
that
responsibility,
but
there
may
be
a
point
in
the
future
where
they
don't
want
to
do
that
anymore
and
that
will
move
our
direction.
But
for
the
time
being,
cluster
life
cycle
in
particular,
is
going
to
manage
all
of
the
provided
repositories
for
cluster.
B
Let's
hold
off
on
more
discussion
on
that
one,
but
it
is
a
candidate
as
a
topic
for
discussion.
As
of
now
are
there
any
others
about
that
level
of
granularity?
Anyone
come
in
here
thinking,
my
goodness,
there's
only
one
question
I
wanted
answered,
and
none
of
these
things
have
anything
to
do
with
it:
No,
okay,
so
we
will
spin
through
in
order
and
add
the
provider,
not
a
provider
question
to
the
end
as
an
equal
voting
opportunity,
you
can
vote
for
multiple
options.
B
If
you
would
like
to
that's
totally
fine
and
Chris
will
keep
count
for
those
votes.
So
first
one
is
the
cloud
provider
extraction
migration.
How
many
have
an
interest
in
that
area
and
want
to
learn
more
I
want
to
talk
more
okay
order
of
magnitude
is
totally
reasonable.
Okay,
the
sig
governance:
how
do
we
structure
all
of
these
moving
parts
and
try
to
anticipate
where
they'll
go
yeah?
See?
No
one
wants
to
talk
about
its
governance.
It's
even
people
involved
in
governance.
B
So
when
I
talk
about
governance
a
lot,
this
is
where
it
becomes
very
clear
that
it's
a
public
servant
role,
not
a
role
of
power,
move
on
user
groups,
who
wants
to
know
more
about
or
ask
for
specific
value
that
they
currently
have
that
out
of
a
sig
that
they
want
to
make
sure
that
is
maintained
in
user
groups,
all
right
and
code
organization
for
the
cloud
provider,
sub
projects
or
not
cloud
provider,
sub
projects
in
some
cases,
okay
and
then
enhancements-
and
they
may
be
these
enhancements.
They
may
be
others,
but
really
it's
about.
B
C
B
Okay,
I
heard
that
extraction
is
first
I,
don't
know
it
comes
in
experts,
but
Chris
will
help
us
transition
to
our
next
topic.
We
will
take
call
it
15
minutes
for
this
one,
just
based
on
feedback
and
and
we'll
talk
about
this,
and
if
your
topic
was
not
selected,
one
of
us
would
be
happy
or
all
of
us
will
be
happy
to
follow
up
with
you
afterward
and
make
sure
it
makes
it
into
the
cig
agenda
for
a
follow-up.
Sig
meeting
I
should
have
said
that
first,
so.
A
So
if
you've
ever
stood
up
a
cluster
on
Amazon
as
your
or
DCP,
whatever
you'll
know
that,
like
all
the
components
have
this
a
provider
flag
and
if
you
enable
it
it
does
things
like
set.
The
proper
node
addresses
on
your
nodes,
set
the
right,
topology
labels
and
all
that
stuff,
and
so
this
effort
is
to
try
to
remove,
like
all
of
the
cloud
provider
code,
that's
embedded
in
all
those
components
and
move
it
and
migrate
it
to
a
new
out
of
tree
component.
That
is
customizable
extendable.
A
Anyone
can
build
their
own
to
pull
on
the
cluster.
You
can
tweak
the
implementation
per
provider.
You
can
release
it
at
your
own
cadence,
it's
it's
kind
of
following
the
whole,
like
CNI
CSI
model.
We're
like
you
can
deploy
your
own
version
of
the
provider
implementation
yourself
out
of
tree,
and
that
also
means
that,
from
from
a
security
standpoint
from
a
bill
to
release
standpoint,
all
the
more
kubernetes
components
don't
have
this
like
hard-coded
and
embedded
logic
on
a
provider
basis.
So
that's
kind
of
the
goal.
A
The
trickiest
part
here
is
the
millions
and
millions
of
clusters
or
nodes
whatever
that
are
already
in
tree
like
how
do
we
safely
get
those
clusters
migrated
to
this
new
model
and
it's
kind
of
again
a
similar
problem
with
like
CSI,
where
it's
a
matter
of
adoption
like
how
do
we
get
early
adopters
to
use
it
test?
It
bet
it
out,
make
sure
that
it
works
in
the
way
it
does
make
sure
the
functionality
is
exactly
the
same
and
all
that
stuff.
So
so
this
effort
is,
is
mainly
around
that
anyone
have
questions
about
that.
E
A
So
yeah
they're,
probably
the
biggest
production
deployment
of
manage
kubernetes
offerings
that
are
that
are
using
the
controller
manager
out
of
tree.
So
one
of
the
luxuries
that
they
get
is
like.
Oh
there's
a
bug
in
the
provider
integration.
They
can
still
build,
deploy
new
image
of
that
component
and
throw
it
at
clusters
without
having
to
wait
for
the
next
kubernetes
patch
release,
or
if
it's
a
new
feature,
they
don't
have
to
wait
for
the
next
kubernetes
major
or
minor
release
and
so
forth.
So
that's
pretty
cool.
A
E
I'm
not
sure
if
I
have
anything
in
this
regard,
you
know
I
think
that's,
that's,
okay
and
that's
been
working
for
us,
fine,
something
that
has
been
more
troublesome
to
us
and-
and
you
know
this
we
talked
about
this
before
earlier
today-
is
that
I
the
other
day
or
the
other
week,
I
tried
to
upgrade
the
dependencies
from
kubernetes.
We
used
to
be
based
on
111
to
1.14
and
I
found
that
there's
quite
a
lack
of
documentation,
and
how
do
you
do
this?
E
It
fails
because
there's
some
specific
GCP
flag,
that's
been
enabled
by
default,
so
you're
out
of
cloud
provider,
installation
things
your
GCP
and
it's
not
working,
and
you
need
to
make
your
you.
You
basically
need
to
work
around
that
so
I
admit
that
could
be
due
to
me
doing
it
wrong,
maybe
missing
how
how
this
is
working,
but
for
somebody
that
is
not
as
tightly
integrated
into
the
work
that
that
this
suggests
right
now.
It
took
me
quite
some
effort
to
figure
out
how
to
do
this
right.
There's.
C
But
during
that
process,
there's
going
to
be
a
lot
of
shift
and
a
lot
of
things
breaking,
and
so,
when
you
run
into
issues
where
you
know
something
like
there's
a
GCC
GCP
flag,
that
has
said
implicitly-
and
you
don't
know
how
to
do
it.
You
know
it's
it's
great
to
be
able
to
come
to
our
meetings
and
tell
us
about
it
and
also
file
issues
about
it,
so
that
we
can
so
we
can
fix
that
because
that's
not
the
experience.
C
A
And
one
of
the
interesting
things
is
that,
because
the
out
of
true
providers
aren't
deployed
with
kubernetes,
there's
usually
like
a
delay
in
terms
of
providers
adopting
the
cloud
controller
manager
like
the
new
code
in
the
cloud
controller
manager,
because
they'll
usually
vendor
it
in
a
little
bit
after
the
release.
And
so
we
may
not
always
catch
those
things.
E
Maybe
just
slightly
related
to
that
is,
if
I
like
now,
with
a
new
wizard
dependencies
updated
if
I
do,
like
my
binary,
help
I
think
there's
a
list
like
a
three-page,
long
list
of
flags
that
are
no
part
of
it,
which
probably
I
guess
it's
related
to
at
the
same
point.
Many
of
those
should
probably
not
be
on
that
binary,
but
they
are
right
now.
So
that
is
it's
not
an
issue
per
se,
but
it
you
know
it
just
makes
it
harder
to
understand.
C
A
Got
back
ported
from
the
cue
controller
manager,
that's
what
happened
and
so
yeah
I
definitely
agree
like
we
should
layer
the
component
flags
in
a
way
where
it's
like.
These
are
the
Bay
component
flags
for
that
all
providers
going
to
need,
and
then
you
can.
You
can
dump
your
custom
flags
and
a
separate
file
and
something
like
that,
rather
than
just
like
importing
everything
and
making
you
have
to
read
through
hundred
lines.
C
So,
with
with
the
providers
who
are
entry,
we've
been
looking
at
we.
What
we've
been
talking
about
is
trying
to
complete
this
extraction
process
by
the
end
of
the
year,
and
that's
just
not
the
code
coming
out
of
urban
Eddie's,
but
also
having
some
sort
of
migration
path,
especially
for
people
who
have
production
clouds
to
be
able
to
migrate
from
the
from
their
entry
provider
to
their
outer
tree
provider.
F
Hi
I'm
Craig
Peters
I
work
Microsoft
on
azor,
and
you
know:
we've
been
working
for
quite
a
while
I
just
joined
so
I'm
catching
up
with
what
what's
been
going
on.
We've
been
working
quite
a
while
to
get
the
code
out
of
tree
and
we're
at
the
point
where
we
have
functioning
stuff.
We
can
actually
use
a
KS
engine
or
tooling
with
that
creates,
as
your
resource
manager
templates
to
test
it,
and
you
know
the
biggest
thing
we
see
right
now
for
for
people
is
that
they
don't
know
how
to
do
it.
F
C
A
C
Yeah-
and
that
illustrates
one
of
the
major
mandela's
modalities
that
we
have
is
that
we
have
cloud
providers
who
are
offering
managed
kubernetes
and
they're,
using
the
the
cloud
providers
to
provide
clusters
for
their
for
their
users,
so
the
responsibility
of
kind
of
figuring
out
how
to
run
those
external.
How
to
how
to
start
that
external
provider
code,
which
is
it's
a
separate
binary
that
you
you
start
up
and
it
communicates
with
a
cube
api
server.
C
You
know
versus
a
user
who
has
to
show
up
in
you
know
you
know,
use
you
know
cubed
min
to
create
a
cluster.
You
know
how
do
you?
How
do
you
add
on
those
those
additional
external
providers
a
tip
on
that
is?
If
you
look
at
the
queue
Bob
script,
they
actually
have
some
some
code
in
there
which
which
handles
this.
You
can
get
a
sense
of
the
things
that
you
need
to
do
to
be
able
to
start
up
an
external
provider
when
you're
bringing
a
cluster
up,
and
so
that's
not
a
replacement
for
documentation.
C
F
Other
thing
that
has
come
up
in
discussions
that
we've
had
is
the
notion
that,
as
we
release
multiple
versions
of
the
azure
cloud
provider,
how
do
we
think,
as
a
group
about
versioning
version
compatibility
version
matrices
those
kinds
of
things
you
know?
Is
it
something
that
each
cloud
provider
should
sort
of
do
that
on
their
own?
Or
is
it
something
that
we
should
do
together,
as
a
group
at
least
have
some
standards
so
that
when
users
who
are
using
multiple
clouds
can
come
in,
they
can
understand
the
the
semantics
of
that
yeah.
C
B
This
is
kind
of
an
underlying
topic
of
conversation
across
multiple
SIG's
as
kubernetes.
The
repository
gets
broken
into
more
in
smaller
repositories,
and
they
have
independent
release
cycles
for
those
things.
What
is
the
release
of
kubernetes?
Look
like
in
the
dependency
management,
and
this
gets.
We
don't
have
no
problems.
We
just
have
different
problems.
Core
DNS,
replacing
cube
DNS
is
one
example.
There
are
others.
Ingress
gets
released
independently.
B
There
are
all
kinds
of
things
you
need
in
addition
to
what
is
spit
out
of
the
kubernetes
release
cycle,
and
we
don't
have
a
canonical
answer
for
that
today,
but
it
is
something
that
I
think
we,
as
a
community
need
to
figure
out.
What
is
the
versioning
I?
Think
the
the
simple
answer
is:
every
minor
release
of
kubernetes
has
matching
releases
of
the
components
that
it
must
have
with
it,
and
that's
not
a
perfect
answer.
B
It
doesn't
get
the
release
velocity
that
those
things
necessarily
need,
but
as
a
cloud
provider
in
this
specific
context,
it
does
remove
my
need
to
wait
for
the
kubernetes
patch
release
to
fix
some
bug.
That's
specific
to
GCP,
and
that
is
one
of
the
primary
benefits
of
this
whole
process.
Is
we
discover
a
bug
that
affects
only
gzp
users.
B
So
my
observation
is
that,
at
least
shortly
after
a
new
minor
release
of
kubernetes,
a
bunch
of
like
regressions
that
are
fixed
for
individual
providers
and
so
in
addition
to
giving
us
better
velocity
over
our
own
customer
experience,
I
think
it
will
reduce
the
amount
of
code
going
into
kubernetes
itself
after
each
minor
patch
release,
because
we
don't
just
fix
things.
We
also
introduce
new
bugs
when
we
fix
things
so
that
this
is
the
runaway
train
that
we're
trying
to
stop.
In
general.
G
Okay,
my
name
is
Ricardo
from
CERN
I
have
a
related
question.
So,
in
addition
to
the
release,
if
we
do
patches
on
the
out
of
three
provider,
which
versions
of
kubernetes,
is
it
being
tested
again
against
and
validated
like?
Would
it
be
always
the
master
or
how
many
releases
it
goes
back
and
things
like
this.
B
So
that's
a
really
good
question.
One
of
the
things
we
did
in
the
cloud
provider
extraction
project
was:
we
worked
with
some
folks
from
cig
testing
on
extension
of
the
test
grid,
and
so
external
cloud
providers
can
run
their
own
and
and
tests
of
the
conformists
tests
and
post
results
back
to
test
grid.
So
we
can
see,
for
example,
OpenStack
or
digitalocean
or
whatever
a
cloud
provider
runs
the
integration
to
in
their
own
environment.
B
They
set
up
the
cluster,
however,
they
set
up
the
cluster,
they
run
the
conformance
test
and
then
submit
the
results
of
the
conformance
test
back
to
test
grid,
including
what
version
is
that
running
against?
So
we
as
Google
can
run.
You
know
one
twelve
and
thirteen
one
fourteen
test
results
and
if
only
one
fourteen
turns
red,
then
that
means
one
thing:
if
all
the
providers
turn
red,
it
means
we
borked
not
only
ourselves
but
someone
else,
and
if
we
just
work
one
test,
then
it's
a
horizontal
line,
and
now
we
know
what
to
look
at.
C
Yet
to
be
able
to
to
report
back
to
to
the
to
the
test
screen
test
grid
is
available
to
everybody
you
write
into
a
bucket
in
it
and
it
publishes
those
results
as
far
as
what
what
how
you,
how
you
manage
versioning
with
with
the
especially
right
now
with
the
changes
that
are
happening
in
kubernetes
for
the
for
the
provider
extraction,
you
should
count
on
a
new
version
of
your
cloud
provider
for
every
new
version
of
kubernetes
and
and
to
sync
those
up.
Yeah
I.
B
It's
like
way
more
complicated
than
cloud
providers,
because
there's
also
CSI
drivers
that
go
with
verts
certain
versions.
There's
again
the
core
DNS
examples.
There's
at
CDE,
there's
fluent
D,
there's
like
I
mean
what
we
do
is
kind
of
insane
on
some
level.
So
we
do
need
some
consistency
across
that.
H
B
Conformance
program
and
part
of
the
conformance
program,
if
you
pass
the
conformance
tests,
is
what
gives
you
the
right
to
use
the
word
kubernetes
and
your
offering,
and
there
is
a
duration
for
which
that
lasts.
If
you
it's
like
12
months,
I
think
but
I
would
encourage
you
to
go.
Look
at
the
conformance
program
guidelines
and
you
can
certify
against
a
114.
B
You
can
still
publish
that
it's
something
kubernetes
whatever
service
or
engine
or
project
for
12
months
and
then,
if
you
haven't
certified
a
version
in
the
meantime,
then
your
certification
expires
and
you
have
to
take
down
the
word
kubernetes.
On
the.
What
version
of
the
cloud
provider
code
exists
with
a
kubernetes
project,
we
will
never
stop
the
converting
at
kubernetes
project
progress,
because
a
provider
doesn't
continue
to
update
their
cloud
provider,
but
that
cloud
provider
is
also
the
one
provisioning.
C
And
it'll
be
the
responsibility
of
the
user
group
that
owns
that
code
to
to
to
develop
that,
and
so,
if
that
code
stops
being
developed,
it's
because
there's
not
enough
interest
from
their
user
community
or
from
their
developer
community.
To
me
to
maintain
that.
But
this
is
also
part
of
the
reason
why
it's
important
that
this
external
about
what
that
this
extraction
happens.
C
And
so
you
know
you
should
think
about
it
as
a
as
an
opportunity
for
the
experts
who
are
who
are
working
on
these
particular
drivers
and
who
are
working
on
these
providers
to
be
able
to
give
you
the
best
user
experience
and
if
they
are,
if
you
don't
feel
like
you're
getting
that
experience
and
that's
not
being
updated,
then
engaging
with
that
user
group.
Or
you
know
that
sig
right
now
is
the
the
best
way
to
prevent
that
from
happening.
And
one.
A
Oh,
this
is
the
most
well
maintained,
we're
gonna,
use
it,
and
so
like
same
thing
with
entry
like
we're
on
the
next
release,
we're
gonna,
delete,
I,
think,
like
photon,
overt
and
classic,
because
we
couldn't
find
anyone
to
maintain
it,
and
so
Indiana
would
be
like
we're.
Just
gonna
delete
it,
because
no
one's
maintaining
it's
those
double.
B
C
I
Was
their
Swan
teen
as
I
can't
use
a
developer?
I
would
like
cloud
provider
might
be.
Have
some
metadata
fields
from
like
request
a
metadata
fields
from
Z
I
know,
that's
a
lot
biases
and
volumes
like
let's
say,
o
storage
closest
I,
say.
If
my
cloud
provider
provides
a
storage
class,
it
has
I'd
say
you
know
it's
like
file
based
I'd,
say:
o
blog
based
on
I
know
like
like
is:
if
it's
that's
it
I
started,
they
can
decide,
can
I,
deploy
my
sickos
it
or
not
and
followed
bar.
I
A
So
we
definitely
have
that
problem
right
now,
with
pretty
much
everything
where
you
so
so
low
bouncers
is
a
great
example
right,
because
every
cop
ever
implements
all
bouncers
differently
and
so
like.
If
you
want
a
very
AWS
specific
thing,
the
natural
thing
that
we've
done
is
stick
it
in
an
annotation
and
throw
it
on
the
service
resource.
B
Yeah
these
are
super
hard
because
they
often
become
the
least
common
denominator
and
then
it's
not
as
you're
not
getting
as
much
value
out
of
any
implementation.
So
these
conversations
tend
to
be
fairly
long,
so
I've
loved
digging
into
it
more,
but
we
should
go
into
it
with
clear
expectations
and
sig
apps.
They
have
an
application.
Crd
that's
been
swirling
around
for
a
year
at
this
point
and
maybe
making
progress
now,
but
it's
taken
some
time
to
get
alignment
there.
B
J
Hi
Alex
my
name
I'm
working
on
integrating
kubernetes
on
our
OpenStack
platform
internally
and
it's
more
of
a
general
question.
So
if
there's
some
decision
being
made
on
an
enhancement
but
should
be
present
in
all
cloud
providers,
this
is
some
sort
of
process
or
like
some
way.
It's
ensured
that
it's
actually
going
to
be
implemented
in
the
next
release
or
yeah
I
mean
that
we
don't
run
into
situation
where
one
cloud
provider
implements
all
the
cool
features
and
the
other
ones
lagging
behind,
because
yeah.
A
Oh,
not,
everyone
has
his
zones
and
regions
and
not
everyone
has
load
balancers
in
the
same
way,
and
so
we're
like
undoing
a
lot
of
that.
And
so
the
big
reason
why
we're
pushing
for
the
whole,
like
all
the
cloud
providers
in
a
single
cig,
so
that
we
can
do.
We
can
vote
in
a
cig
and
say
like
make
sure
that
the
right
technical
leads
from
the
right
cloud
providers
are
there
to
say
that
this
feature
actually
won't
work
for
our
users,
because
we
don't
implement
zones
or
we
don't
implement
whatever
yeah.
C
Api
is
to
file
an
issue
and
also
come
to
the
meetings
and
bring
that
up
and
advocate
for
it,
because
that
is,
you
know,
that's
that's
largely
how
things
get
accomplished,
and
so
this
is
actually
the
venue
for
that
to
happen
and
and
we're
we
burnt
a
young
enough
sick
still.
But
we
have
enough
reach
that
you
can
have
some
really
deep
and
positive
impact
in
the
community.
If
you,
you
know,
if
you
share
these
broadly
and
our
meetings
are
weekly
from
when.
K
A
But
to
that
point,
though,
like
because
we
know
that
it's
not
just
you
know,
Google
anymore,
that's
running
kubernetes
and
there's
hundreds
of
providers,
probably
that
that
want
to
do
it.
We
really
have
to
be
more
mindful
of
like
features
or
new
integrations,
and
we
have
to
make
sure
that
there's
a
reasonable,
critical
mass
of
providers
that
are
one
that
want
a
feature
before
we
go
ahead
and
add
it
because
the
more
things
we
throw
at
it,
it
becomes
a
mess
and
hard
to
maintain
and.
B
There
are
great
reasons
for
the
way
some
things
are
like
it
just
was
the
way
somebody
did
in
on
a
Tuesday
afternoon
and
because
that
everyone's
perspective
is
the
only
one
they
have,
it
would
work
for
them
and
that's
the
way
it
is.
But
you
may
find
that
you
have
a
proposal
and
there's
no
objection
whatsoever
and
everybody
cruises
along
with
it
it.
It
can
be
surprising
that
way
so.
B
A
So
I
think
the
the
provider
specific
topology
labels
is
a
has
been
a
pretty
hot
topic
lately
and
so
right
now,
when
you
register
node
it'll
query
the
provider
and
it'll
put
a
zone
in
region
label
and
you
can
you
use
the
zone?
Read
you
use
a
zone
label
to
do
like
volume,
aware
topology,
you
know
and
all
that
stuff,
but
there's
been
recent
discussions
around
like.
A
Should
there
be
more
labels
like
like
physical
host
or
like
the
hypervisor
or
like
a
rack,
a
label
so
that
you
can
split
your
topology
into
smaller
chunks
and
allow
for
smaller
spare
domains?
And
so
do
people
have
thoughts
on
you
know
what
if
there
should
be
more
topology
labels
and
zones
and
regions
and
if
so
like?
What's
the
use
case,
what
provider
would
need
that
and
and
and
so
forth?
Anyone
have
thoughts
on
that.
B
F
F
B
F
B
B
B
L
B
Where
there
are
lots
of
efforts
underway
in
related
areas,
so
there's
like
watch
cache
project
to
not
have
to
read
back
from
the
beginning
of
time.
If
you
reconnect
to
the
API
server
that
should
help
on
some
of
this
there's
also
changes
in
the
node
heartbeats
behavior,
so
that
with
lots
of
nodes,
you
don't
overwhelm
your
API
server
and
then
specifically,
in
this
rate,
limiting
and
fairness-
and
this
is
a
very
deep
topic
where
many
of
us
have
been
through
this
and
other
projects
in
the
past.
It's
not
a
new
idea.
B
It's
just
now
we're
with
as
many
clients
of
the
API
server
as
there
can
be.
It
becomes
an
issue.
So
one
of
the
things
that's
interesting
about
kubernetes
is
it's
not
always
the
traffic
from
the
external
internet.
It's
the
traffic
between
the
things
that
enable
all
of
this
self-healing
and
reaction
to
changes
in
desired
state,
for
example,
but
it
can
pile
up,
especially
in
really
large
clusters,
so
it
works
really
well
in
three
node
clusters
does
not
work
well
in
5,000
node
clusters.
Sadly,
yes,.
A
I'd
actually
like
to
get
a
sense
of
how
big
of
a
problem
like
running
out
of
a
vehicle
is,
is
for
a
kubernetes.
So
like
raise
your
hand
if
you've
deployed
a
cluster
somewhere
and
then
it
some
functionality
broke
because
you
ran
out
of
eight
care
coders,
okay,
so
I
guess,
like
mostly
large
clusters,
there's.
B
B
K
C
A
B
M
One
there
hey,
my
name
is
eeshwar
I
manage
a
Mazzoni
kiss,
so
this
is
a
near
and
dear
topic
for
us.
Actually,
a
lot
of
our
customers
end
up
being
rate
limited
at
large
scale.
Right
so
I
mean
this
is
a
topic
that
even
we're
talking
Mike,
here's
our
is
our
active
participant
in
the
cloud
provider
group.
M
So,
even
though
there
have
been
a
number
of
improvements
in
the
ATB
as
part
of
the
cloud
provider
right
things
where
EPA
calls
that
need
not
be
happening
where
happening
duplicate
calls
that
we
don't
need
to
do
number
two
batting
wasn't
implemented,
so
that
was
added
a
little
later
right.
We
still
run
into
throttling
issues
right
so
like
now
we
are
discussing
on
how
maybe
we
could
potentially
have
a
cache.
So
the
entire
problem
being
like
you,
have
a
number
of
entities
not
coordinated,
distributed
right,
because
nodes
are
also
utilizing.
M
The
API
calls
at
the
end
of
the
day
right
doing
their
own
API
calls
and
as
cluster
scales,
you
have
more
number
of
API
calls
leading
to
throttles
right
and
you
are
in
a
downward
spiral
right.
You
back
off,
retry
right.
So
we've
been
thinking
about
potentially
having
a
cache
that
serves
as
an
intermediary
intermediary
right
so
that
you
don't
need
to
do
API
calls
repeatedly
at
the
end
of
the
day,
right
obviously,
with
cash
comes
problems
with
caching,
consistency
and
stuff
like
that
right.
M
B
I
think
there
are
some
investments
in
that
know.
Something
node
local
cache
is
something
I
know
that
the
node
team
is
looking
into
as
well.
As
you
point
out,
then
everything
becomes
a
cache
invalidation
problem
and
consistency
is
important,
but
again
it's
kind
of
the
benefit
of
the
system
as
a
whole.
Is
this
very
decoupled
behavior
of
all
of
these
independently
evolving
components,
and
that
comes
with
a
cost
and
the
chattiness
and
connection
so
the?
What
did
we
call
it?
B
Chunking
of
lists
is
one
thing
that
we
added
an
API
machinery
recently,
so
you
don't
have
to
get
a
whole
list
of
things.
Most
of
these
are
behavior
and
very
large
clusters,
so
the
concepts
that
work
really
well
with
small
clusters.
You
need
to
rethink
when
there
are
large
clusters
and
those
conversations
get
very
long
and
detailed
and
very
smart
people
who
have
done
this
before
are
thinking
about
many
of
those
things.
I
would
very
much
like
to
avoid
building
another
cache
solution
that
it's
not
an
academic
exercise
anymore.
B
A
Sure
they
had
a
problem
with
the
route
controller
and
because
they
would
do
like
a
list
routes
on
every
single
route
on
the
table,
and
so
they
implemented
their
own
cache
behind
the
interface
and
that
worked
out
so
yeah
like
for
eks
or
for
Amazon
customers
may
be
more
practical
approaches
like
implement
caching
and
then
bring
it
back
to
the
sig
like.
Let's
look
at
that
together.
Maybe
this
is
something
that
all
the
riders
should
do
as
a
catch-all
and
and
or
maybe
like.
Maybe
your
solution
solved
very
specific
case
for
Amazon
and
so
yeah.
B
So
there's
a
lot
of
improvements
on
services,
a
number
of
endpoints
per
service
and
how
to
have
end
points
and
shard
end
points
across
us
and
point
slices
or
something
I
can't
remember
the
name
and
point
slice
yeah.
So
there's
a
lot
of
effort
in
that
direction.
From
that
perspective,
and
it
would
be
great
to
get
your
input
on
what
are
some
other
scalability
challenges
and
where
to
focus
that
energy.
H
H
B
B
C
It
it
mirrors
other
things,
I've
heard
where
you
know
like
you
know.
People
also
want
other
information.
It's
helpful
in
tracing,
it's
helpful
in
you
know,
for
operators,
users
should
care
last
but
which,
but
there's
there
may
be
a
way
to
provide
that
in
a
consistent
way,
maybe
through
some
sort
of
API
and.
C
B
C
So
the
next
topic
is
code
Organization
for
cloud
providers.
Sub-Projects
a
lot
of
people
raise
their
hands
on
this
one
also,
and
so
this
this
one
also.
This
is
something
that
has
come
partly
out
of
OpenStack
we're
in
seconds
a
mano
repository.
So
you
just
go
to
cloud
provider
OpenStack
and
you
wind
up
with
everything.
B
N
B
Thank
you
and
that
was
aditi
from
NEC.
We
do
have
kubernetes
SIG's
cloud
provider
and
code
in
there
now
I
think
the
question
is
about
other
parts
of
the
organization
and
if
we
want
to
collect
all
the
things
that
you
want
for
a
given
distribution
on
a
cloud
provider
in
that
one
place
or
have
consistency
about
where
they've
points
to
elsewhere
and
I
think
where
it
gets
really
confusing
is
there
are
like
CSI
driver
implementations
that
are
intended
to
work
across
clouds.
B
So
it
isn't
the
case
that
it
belongs
to
only
one
subtree
and
I'm,
not
an
expert
on
remote
repos
and
how
to
point
to
another
repo.
But
I
know
it
is
not
straightforward
in
many
cases,
so
I
don't
have
the
right
answer
here
or
any
real
position.
I
just
know
it's
tricky.
Has
anyone
interested
in
trying
to
come
up
with
a
proposal
or
try
and
think
about
all
the
things
that
are
required
and
are
and
currently
moving
out
of
tree
and
what
to
do
about
them?
Yes,.
O
C
A
C
A
C
P
B
I
would
care
to
take
a
swing
at
it,
so
the
service
catalog
intends
to
expose
managed
services
to
workloads
running
in
your
kubernetes
cluster.
In
a
consistent
way
is
my
understanding.
Interpretation
I
haven't
worked
on
it,
but
so,
if
you
use
managed
database,
you
say
provision
a
new
manage,
make
a
new
instance
of
that
managed
database
and
give
me
an
endpoint
for
Redis
or
whatever,
and
then
it
returns
that
that
endpoint
and
your
service
is
running
in
your
cluster.
It
can
access
that
as
if
it
were
local
to
the
cluster.
B
Even
though
it's
far
away,
this
SIG
does
not
give
any
guidance
on
how
Service
Catalog
should
behave
or
work
directly
with
the
manage
services
in
the
cloud
providers.
It's
more
up
earlier
in
time
than
that
the
cluster
had
to
exist
and
creating
that
cluster
requires
some
integration
with
persistent
disks
and
load
balancers
and
infrastructure
provided
by
the
infrastructure
provider,
and
what
we
try
to
do
is
make
that
work
in
a
consistent
way
and
then,
once
the
cluster
is
running,
service
catalog
provides
access
to
external
services
that
are
also
running
and
started
before
then.
K
Think
we
implement
in
the
cloud
providers
the
core
primitives
of
kubernetes
that
have
to
be
implemented
specifically
to
the
cloud
provider
as
load
balancers
as
storage
as
such
such
things
and
not
the
specific
services
the
cloud
provider
offers
as
well
like
Redis
and
so
on.
It's
just
the
core
components
that
we
implement
in
the
specific
route
providers.
I.
G
A
You're
talking
about
like
the
provider,
implementations
in
the
cluster
are
all
scalar
right
yeah.
So
that's
that's
an
interesting
case
because
it's
cluster
scalar
scalar
is
an
add-on
so
like
they
can
choose
to
do
that.
Implementation,
their
own
way
and
I.
Think
I've
talked
to
I
forgot
his
name,
but
one
of
the
chairs
of
sagal
scaling
and
the
approach
that
they
took
instead
was
to
use
build
tags.
So
they
bundle
all
the
providers
in
the
same
repository
and
they
have
a
default
build
tag
that
compiles
all
the
providers
into
it.
A
O
O
A
A
So
now
you
want
to
like
backward
it
back
into
the
kubernetes
organization
yeah.
So
we
have
a
few
requirements
for
kubernetes
sponsored
repository
which
are
like
you
need
like
real
users
using
your
provider.
You
need
like
a
staple
like
a
some
sort
of
like
beta
version
of
a
controller
manager
which,
which
you
see
me
to
have
mini
docs.
You
need
to
report
test
results
test
grid,
so
we
have
a
cap
proposal,
so
you'd
have
to
create
a
cap
that
says
like
this:
is
a
provider
I
want
to
support
in
the
communities
repository
or
the
organization?
A
And
if
you
fill
that
out,
we
can
approve
it
and
then
we'll
give
you
a
repository
to
put
the
CloudStack
provider
in
there
yeah,
but
yeah
we
shot
on
slack
and
I.
Can
give
you
more
details
on
how
to
do
that.
Well,
that
it's
good
to
know
that
the
cloud
stack
provider
is
being
used,
though
I
didn't
know
that.