►
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: vSphere Cloud Provider and CSI - Fabio Rapposelli, VMware
Kubernetes cloud providers and volume plugins used to be "in-tree" meaning that their source code is included in the main Kubernetes repo. They were compiled in, and shipped only in a Kubernetes release. The drawbacks of this monolithic approach were that Kubernetes was larger than needed, and feature + patch activity was locked to Kubernetes release schedules. Going forward, new features are exclusive to the new replacements: an out-of-tree vSphere cloud provider + a CSI storage plugin. Legacy implementations remain for the short term but are destined for deprecation.
https://sched.co/Uajd
A
Alright,
let's
get
started
it's
the
last
session
of
the
day.
I
see
many
people
are
tired
of
being
the
conference.
I
don't
want
to
keep
you
from
going
to
the
party,
so
I
don't
have
many
slides
for
you
today.
So
the
idea
of
the
session
here
and
in
general,
the
maintainer
Strax
session,
is
to
have
like
a
discussion
so
interact
the
discussion.
I'm
fortunate.
We
don't
have
anybody
that
can
run
around
with
a
microphone.
So
we'll
encourage
you
to
just
ask
any
questions.
I
will
repeat
the
question
at
the
mic
and
just
keep
it.
A
You
know.
The
discussion
before
getting
into
the
discussions
is
when
a
well
first
of
all,
briefly
introduce
myself.
My
name
is
Fabio
passaglia
we're
the
VMware
I've
been
working
in
kubernetes
in
and
around
kubernetes
for
the
past
four
years
or
ish
years,
but
I've
been
involved
in
container
work,
clothes
management
for
a
very,
very
long
time.
A
So
again,
you
know
just
a
couple
of
us
keeping
items
rules
our
Gammage,
that
this
is
a
discussion
just
be
respectful,
be
kind.
Don't
wait
until
the
end
to
ask
your
question
whatever
you
see,
something
on
ask
just
raise
your
hand,
just
stop
it
right.
There
gonna,
you
know,
try
to
get
this
discussion
going
and
again
just
be
respectful
of
everybody
else.
I
want
to
get
started
with
a
couple
of
like
items
into
kind
of
like
the
the
sausage-making
aspect
of
the
cig.
A
Some
people
might
know
that
we
used
to
have
cig
VMware
before
in
the
community.
I
was
one
of
the
co-chairs
of
cheeky
hammer,
we
had
say
VMware
for
a
lot
of
year
and
a
half,
it
was
basically
looking
after
everything.
I
have
to
do
with
with
VMware
infrastructure,
so
kubernetes
on
VMware.
That
could
be.
You
know,
from
fusion
and
workstation
to
vSphere
to
cloud
to
any
other
product
the
VMware
has.
A
But
there
was
a
master
plan
coming
from
the
steering
committee
to
just
basically
fold
all
this
provider,
Six
Sigma
was
one
of
them.
We
also
had
to
get
a
big
open,
many
honors.
The
idea
was
justice.
Consolidated
all
these
providers,
things
into
one
master
sake,
which
is
sick,
claw
provider
and
as
of
July
this
year
we
completed
this
process,
there's
multi-month
process
that
actually
took
a
long
time
to
complete
and
we
no
longer
have
all
these.
You
know
cloud
providers
takes,
we
only
have
one
sick
club
provider
and
will
participate
in
that.
A
So
this
doesn't
change
effectively
anything
in
terms
of
what
what
we
do
as
part
of
like
supporting,
VMware
and
vSphere
in
the
criminals
community.
It
was
the
laser
focus
on
making
sure
that
kubernetes
is
you
know
is,
is
something
that
is
well
supported
on
vSphere
and
honor
of
EMR
platform.
The
only
thing
is
that
we
reduced
the
amount
of
meetings
that
we
have
basically,
so
this
is
literally
what
happened
so
I
was
mentioning
the
beam
laser
focus
on
working
on
making
sure
that
kubernetes
and
vSphere
work
well
together.
A
There's
the
entry
problem,
so
I'm
sure
that
people
that
are
running
kubernetes
on
vSphere
probably
know
about
this.
So
how
many
of
you
actually
running
kubernetes
on
be
severe
on
tears,
just
show
hands:
okay,
that's
more
than
a
bunch
cool.
So
you
probably
know
that
you
can
start.
You
know
your
kubernetes
cluster
with
cloud
equals
V
severe
and
that
will
kick
off.
A
If
the
helical
music
abilities
there's
a
specific
schedule,
so
you
always
have
to
have
you
know
new
features
added
or
the
bug
fixes
released
as
part
of
the
main
kubernetes
release,
and
this
is
probably
not
practical
for
many
of
the
clouds
that
are
iterating
very
fast
of
new
things,
adding
or
even
like
fixes
happening
so
think
of
it
as
a
CV
whence
the
CVE
comes
out.
If
a
CV
impacts,
one
cloud
provider,
it
needs
to
be
fixed,
it
needs
to
have,
and
you
could
be
a
kubernetes
release
for
it.
A
So
there
is
that
decoupling,
kubernetes
core
from
all
the
provider
specific
code
that
lives
in
kubernetes
is
a
thing
that
has
to
be
done.
This
effort
started
a
while
back
and
it's
been
in
progress
for
a
very,
very
long
time,
the
very
first,
the
very
first
stub
of
the
API
for
having
this
code
being
offloaded
outside
the
converting
score.
A
We
introduced
it
in
Cuba
days,
1.6
so
long
time
ago,
we're
now
at
a
point
where
we're
actually
making
progress
and
we're
almost
at
a
point
where
we
are
able
to
extract
those
components
from
within
kubernetes
core
and
just
have
them
running
this
pods
on
top
of
kubernetes,
which
is
the
end
result
that
we
all
want
so
as
part
of
SiC
VMware.
Before
and
now,
as
our
you
know,
of
the
largest
co-op
provider
group
and
other
groups,
what
we're
doing
is
we
continue
to
work
on
this
to
make
sure
that
vSphere
is
part
of
this.
A
It's
part
of
these
platforms
that
are
enabled
to
run
as
pause,
we're
going
to
go
over
all
this,
but
the
idea
is
that
we
want
to
get
to
a
point,
and
this
is
one
of
the
main
one
of
the
main
points
of
the
stick
up
of
our
strategies.
We
want
to
make
sure
that
we
have
kubernetes
as
a
core
orchestration
kernel
and
not
having
anything
to
do
with
the
actual
platform
that
kubernetes
runs
on.
A
So
where
are
we
we're
here
to
talk
about
vSphere,
so,
let's
just
deep
dive
into
it.
So
where
are
we
here
today?
Today?
We
have
three
major
things,
so
we
have
a
cloud
provider
auto
tree
cloud
provider.
We
have
an
auditory,
CSI
provide,
which
is
for
storage.
We
have
closer
API,
which
is
to
manage
lifecycle
of
clusters
of
on
vSphere,
and
we
are
working
slowly
working
towards
a
future.
What
we're
going
to
have
also
as
CNI
for
not
specifically
for
vSphere
but
more
optimized
for
vSphere.
A
There
was
an
announcement
this
earlier
this
week
about
a
project
called
on
TRAI,
which
is
a
CNI
based
on
open
V
switch
from
VMware.
So
if
you're
interested
in
CNI-
and
you
know-
maybe
you
wanna
you're,
looking
for
something
different
than
you
know-
final
calico,
weave
and
so
on-
go
check
it
out,
it's
still
very
early,
but
it's
very
promising
so
cloud
provider
as
I
was
telling
same
before.
You
know.
Yes,
yes,.
A
So
here,
so
the
question
is
what
version
of
kubernetes
are
we
talking
about
with
this
with
these
plugins
here?
So
here's
the
interesting
thing.
So
all
these
plugins
are
outside
of
kubernetes
core,
so
they're
not
tagged
with
a
specific
communities
version
they
have
their
own
versioning
right.
All
these
three
components,
except
for
cluster
API,
which
is
still
considered
alpha
beta
both
pop
provider
and
CSI,
have
reached
GA
production
maturity.
A
So
today
we're
if
you're
deploying
a
new
cluster
like
a
brand
new
cluster
and
writing
new
kubernetes
cluster
with
a
you
know,
a
fairly
recent
vSphere
version
sitting.
Underneath
we
will,
we
will
recommend
you
to
deploy
these
components
and
not
the
entry
component
just
avoid
completely
the
entry
components.
B
A
How
do
you
know
if
the
infrastructure
team
has
used
the
right
tools?
Well,
if
you
have
access
to
the
kubernetes
cluster,
you
can
tell
right
away
because
you
could
see
the
pods
running,
so
these
components
runs
run
has
parts,
so
you
can
literally
do
a
cube,
cuddle,
get
pause
and
see
the
spas
running.
A
A
A
That
was
stressed
that
again,
the
entry
code
is
still
supported,
but
we're
not
gonna
add
any
new
features
to
the
entry
stuff,
because
the
interest
off
is
frozen
in
time
right
now
or
just
there
only
so
if
kubernetes
is
only
accepting
bug
fixes
for
that
part
of
the
code
base
or
they're,
not
accepting
any
new
features,
any
net
new
features
will
not
be
introduced
there.
So
for
new
features
you
got
to
go
with
the
auto-ship
provider,
so
we
got
version
100.
We
support
availability
zone
so
you're
able
to
create.
You
know
different
topologies.
B
A
Cooperate
with
kubernetes
in
vSphere,
you
can
create.
You
know
multiple
availability
zones
using
tagging
in
vSphere.
It's
actually
pretty
pretty
interesting,
because
you
can,
you
can
create
topologies
that
are
very
effective
and
their
map.
You
know
very
nicely
to
your
vSphere
topology
itself,
we're
currently
lacking
load,
balancer
support,
which
is
something
that
we
are
working
on
right
now,
we're
trying
to
figure
out
how
to
do
it.
Actually,
it's
very
tricky
because
vSphere
by
default
doesn't
have
a
little
balancer
facility
in
the
infrastructure
layer.
A
A
Yes,
that's
a
very
good
question.
So
what
about
NSX
so
obviously
I
know
sex
is
a
is.
You
know,
he's
basically
giving
you
that
facility
that
you're
missing
right,
it's
giving
you
an
API
that
you
can
talk
to
and
you
can
get
a
little
dancer
out
of
it
and
be
deployed
in
vSphere.
This
is
exactly
the
kind
of
things
we're
looking
at.
So
the
problem
is
that
we
know
that
we
have
ways
to
get
the
load
balancer,
but
we
don't
have
a
standard
interface
for
it
right.
A
We
can
have
nsx,
but
then
it
will
have
something
specific
to
nsx,
like
the
implementation
will
be
very
specific
to
nsx.
In
this
case,
we
need
to
do
something
slightly
different
from
what
other
cloud
providers
have
been
doing.
You
know,
other
cloud
providers
have
been
just
supporting
their
own
load
balancers,
they
have
one
type
of
load,
balancer,
that's
it
right.
In
our
case,
we
need
to
figure
out
a
way
to
just
do
a
way
where
we
can
plug
in
multiple
load
balancer
facilities.
A
So
you
can
just
pick
your
own
right,
so
we
need
to
create
another
interface
to
that
which
is
netting
you-
and
nobody
else
has
done
this,
and
this
is
actually
one
call
to
action
for
people
that
are
interested
in
contributing
to
this.
You
know
where
this
is
what
your
one
big
item,
one
big
ticket
item
that
we
have
for
v2.
A
So
if
people
are
interested
in
working
on
this,
for
you
to
reach
out
there's
a
there's,
a
bunch
of
information
at
the
end
on
you
know
the
meetings
that
we
have
etc,
because
this
is
definitely
something
that
we're
looking
at
for
the
next
version
of
Clarke
provider,
all
right
CSI.
This
is
an
hour
big
one,
so
I
didn't
mention
this
before,
but
the
the
type
of
entry,
plug-ins
or
providers
that
we
have
today
in
kubernetes
is
not
just
Club
provider.
It's
also
storage
provider,
it's
kind
of
hidden
in
there,
but
it's
you
know.
A
It's
very
well
understood
that
when
you
ask
for
a
persistent
volume
and
you
have
the
vSphere
integration
configured,
what
you
get
is
you
get
a
VM
hey
attach
to
your
VM,
so
you
have
a
way
to
use
the
persistent
volume
abstraction
of
kubernetes
being
abstracted
to
actual
VMDK
elements
in
the
underlying
infrastructure.
So
the
entry
code
is
tightly
you
know
intertwined
together,
so
cloud
provider
and
storage
provider
entry
they
go
and
in
them
you
cannot.
You
know,
pull
them
apart,
they're,
just
one
single
thing:
you
have
to
use
them
in
concert.
A
You
cannot
use
one
of
each
right
stand
alone.
You
have
to
use
them
both
at
the
same
time.
That
means
that
when
you
go
out
a
tree,
you
need
to
have
both
a
club
provider
and
a
storage
provider
that
are
working
in
concert.
You
cannot
just
do
piecemeal,
taking
one
from
entry,
one
from
out
a
tree
and
vice
versa.
You
have
to
move
from
entry
trading
throughout
a
tree
for
both,
so
there
were
some
decisions
made
here.
A
A
This
is
very
interesting
because,
if
you're,
if
the
day,
you're
standing
up
a
cluster
with,
you
know
on
vSphere
kubernetes
cluster,
on
vSphere
and
you're
running
a
fairly
recent
version
of
vSphere,
meaning
that
673
or
above
you
actually
get
UI
visibility
on
the
persistent
volumes
that
you're
deploying
on
kubernetes.
So
if
you
deploy
this,
you
you
create
your
stateful
set
you
you
know,
you
know,
attach
some
persistent
volumes.
You
will
actually
see
those
persistent
volumes
and
we
tags
and
everything
in
the
vSphere
UI
you
will
have.
A
A
So
it's
it's
a
pretty
powerful
integration
and
gives
you
a
lot
of
visibility
into
what's
going
on
inside
the
de
coeur
bananas
cluster
and
you
know
it's
powerful
for
the
infrastructure
team
they
can
see
what's
going
on,
since
all
these
objects
are
created,
as
you
know,
standalone
vindicates
or
they're
not
attached,
specifically
to
one
VM
they're.
Just
you
know
VM
decays
that
are
stored
in
the
data
store
and
they
get
used
by
the
kubernetes
by
the
communities
cluster
last
but
not
least,
cluster
API.
So
how
many
of
you
are
familiar
with
cluster
API?
C
A
Pointing
the
sphere
and
this
API
endpoint
is
basically
treating
the
VMDK
is
created
in
the
datastore
as
a
global
registry.
So
it's
easy
to
keep
in
fact
of
whatever
we
indicate
you
create
in
your
data
stores
and
keeping
track
of
that
that
ID
and
mapping
that
ID
to
the
kubernetes
cluster
is
requesting
that
the
persistent
volume,
so
you
do-
have
visibility
into
that
specific
volume.
So
you
can
see
that
specific
volume,
how
big
it
is,
what
storage
only
C
is
attached
to
it.
You
can.
D
B
B
A
A
That's
a
good
question:
when
are
we
going
to
support
a
resizing
resize
of
volumes?
So
this
is
actually
an
open
question
with
the
CSI
spec,
not
just
an
implementation
problem,
we're
working
on
that
very
hard
trust
in
that
there's.
This
two
main
main
things
that
we're
working
on
right
now
one
is
resizing
volumes,
you
gotta
want
is
snapshots
and
both
are
can't
exist
like
they
are
in
the
spec,
but
they're
not
in
a
way
that
can
be
implemented
so
there's
this
work.
A
That
needs
to
be
done
there
it's
more
than
just
implementing
something
that
is
in
a
spec
right,
so
it
takes
time
they
were
definitely
working
on
that,
because
it's
resize
of
line
is
basically
the
major
number
one
feature
request
that
we
get
every
single
time.
We
talk
about
storage
in
kubernetes,
cluster.
A
Api,
so
how
many
of
you
know
about
cluster
API
at
all?
Okay,
a
few
good,
so
cluster
API
very,
like
very,
very
brief
overview.
Cluster
API
is
community
driven,
so
urbanize
community
driven
project
to
make
cluster
lifecycle
management
of
kubernetes,
easy,
consumable
and
potentially
boring
right.
So
getting
the
life
cycle
of
the
cluster
right
is
very,
very
difficult
as
many
tools
of
proem
before
it
gets
very
complex,
very
complicated,
very
fast,
each
and
every
provider,
his
own
perks
and
inflammation
implementation
details.
A
So
much
for
API
is
now
in
its
v1
alpha
three
stage,
which
has
been
in
the
works
for
the
past
few
months
and
it's
again
driven
by
six
cluster
life
cycle,
which
is
the
sake
that
is
driving
most
of
this
work
and
around
squash
for
API.
There
is
a
lot
of
in
work
that
goes
into
the
actual
provider,
so
call
sarpy.
A
We
have
cluster
api
from
our
vSphere
or
in
short
cap
V,
so
cautionary
paper,
either
vSphere
as
long
to
the
sidewith
cluster,
api,
AWS
and
GCP,
and
a
few
others
is,
you
know
very
much
on
track
with
what's
happening
in
the
main
framework,
so
we're
trying
to
keep
us
in
lockstep
with
what
happens
in
the
community
upstream
of
cluster
api.
So
we
never.
We
never
get
like
far
behind
on
what
they're
being
implementing.
So
we
always
keep
up
with
them.
A
We're
not
at
a
point
where
we
will
consider
this
like,
for
you
know
big
large
production
workloads,
but
we're
it's
starting
to
consolidate
around
some
of
the
I
would
say
some
of
the
specific
easy,
easy
topologies.
So
when
you
have
like
a
simple
question
unit
to
stand
up,
the
workflow
from
create
to
you
know,
update
deletion
of
the
cluster
is
actually
pretty
solid
and
we're
making
progress,
we're
making
changes
and
so
on
to
the
actual
cluster
API
itself
to
make
it
more
cymbal
and
more
easy.
A
But
the
the
best
thing
about
Kloster
api
is
it's
just
series,
so
the
infrastructure
itself
becomes
part
of
the
kubernetes.
So,
for
example,
when
you
deploy
cluster
api
vSphere,
you
have
your
management
cluster.
That
has
the
series
and
everything
and
then
you
can
deploy
multiple
clusters
with
that
and
you
will
see
the
vSphere
cluster
objects
in
your
communities
clusters
and
you
can
just
you
know,
scale
that
just
cube
cuddle
scale
and
you
will
get
more
v4
VMs
in
your
clusters.
So
it's
a
very
powerful
pattern.
It's
very
very
powerful.
A
The
latest
version
for
pop
provider-
Australia
prodigy
sphere,
is
0
5
3,
so
I
will
suggest
if
you
have,
if
you
want
to
test
this,
if
you're
interested
in
cluster
lifecycle
of
your
combination
cluster.
On
this
view,
I
will
totally
suggest
you
to
check
this
out
since
version
0
5
2,
we
started
to
put
as
default
the
two
providers
that
we
talked
about,
so
both
cloud
provider
and
CSI.
A
So
today,
if
you
have
a
vSphere
6w3,
you
want
to
deploy
a
cluster
with
kubernetes
with
all
the
bells
and
whistles
you
just
use
cluster
API,
you
get
a
cluster
that
is
perfectly
deploy
with
everything
you
need.
You
know
by
best
practices,
so
I
want
to
encourage
you
to
test
it
out,
because
it
is
a
very
powerful
pattern
and
we're
gonna.
You
know
work
we're
working
on
it
a
lot
and
we're
gonna
work
on
hit
even
more
in
the
future.
So
it's
definitely
something
to
check
out.
A
A
A
So
it's
not
so
the
question
is:
when
it's
going
to
be
ready
for
production,
it's
very
close.
Actually,
so
we
there's
a
big
change
coming.
It
would
be
one
off
of
three
so
right
now
the
major
concern
that
I
have
personally
with
Foster
API
is
that
there's
no
way
to
manage
the
size
of
the
control
plane
of
kubernetes.
So
everything
is
a
cluster
right.
A
You
get
a
cluster
and
you
can
now
manage
your,
for
example,
your
NCD
size,
your
cluster
STD
cluster
size,
v1,
alpha
3,
which
is
due
in
January,
February
I,
don't
know
exactly
when
that's
going
to
be
done,
but
introduce
the
concept
of
control
plane,
interest.
The
control
plane
object.
That
will
give
you
the
ability
to
actually
have
that
dimension.
You
can
you
can
size
up
right.
That
will
be
the
point
where
I
can
see
it.
A
A
You
want
to
point
out
that,
even
though
0:05
2,
we
have
the
auditory
components
as
the
default
cluster
area
is
very
much.
You
know
it's
very
much
something
you
can
customize
to
your
needs
and
we
always
keep
a
way
to
actually
use
the
entry
providers.
So
true,
just
a
couple
of
lines
of
gamal
is
it's
all
Yambol
here,
as
always
with
kubernetes,
you
can
actually
specify
to
use
the
entry
providers
that
you
will
not
get
the
new
stuff
deployed.
You
will
only
get
the
old
stuff.
A
How
do
I
get
involved?
This
is
the
last
slide
of
the
presentation.
Then
I
want
to
hear
questions
and
discussion
if
you're
interested
in
cluster
lifecycle
management.
If
you
want
to
help
with
cluster
API,
we
have
a
meeting
that
is
specific
to
vSphere
every
other
Monday
at
1
p.m.
Pacific.
So
if
you
want
to
know
the
link
to
that,
just
go
check
it
out
in
a
community
or
on
kubernetes
slack,
there
is
provider
vSphere
as
a
channel
on
slack
everybody
is
there.
So
all
the
you
know
the
information
they
fully
flow
through
that
channel.
A
Basically,
and
so
we
have
a
zoom
meeting
as
part
of
the
community
Monday
at
1
p.m.
Pacific
every
other
month.
We
have
latest
one
was
this
monthly,
so
there
would
be
two
Monday's
from
now.
If
you're
interested
in
cloud
provider,
interface
or
CSI,
you
should
join
sick
cloud
provider.
There
is
a
meeting
there,
every
other
Wednesday
1
p.m.
Pacific.
This
is
the
large,
the
larger
sick
cloud
provider
meeting.
We
talked
about
everything
that
has
to
do
with
the
cloud
providers.
A
Last
but
not
least,
if
you're
a
user-
and
you
have
no
interest
in
participating
in
actually
developing
the
product
or
developing
the
project,
which
is
absolutely
fine,
there
is
a
new
VM
or
user
group
forming
in
the
community
in
the
kubernetes
community.
So
this
is
something
that
is
not
brand
new,
but
very
new.
Anyway,
a
user
group
is
forming
actually
formed
this
week.
A
A
So
if
we're
interested
in
like
talk
with
other
users,
talking
about,
like
you
know,
getting
some
feedback
on
how
things
are
going
getting
some
feedback
on
or
providing
feedback
back
into
the
six.
This
is
the
way
you
should
be
engaging
the
community
anything
else:
provider
vSphere
on
kubernetes
Lac.
That's
where
pretty
much
all
of
us
hang
out
free
to
chime
in
there
ask
questions
and
that's
what
I
have
please
ask
questions
now.
A
Yes,
so
the
question
is
the
CSI
provider
and
the
club
provider
rely
on
each
other,
both
auditory
and
entry.
So
to
answer
your
question
entry
technically,
what
happens
is
that
the
storage
provider
calls
into
the
cloud
provider
code
literally,
so
the
storage
provider
is
a
shim
layer
on
top
of
the
cloud
provider
code.
So
all
the
connections
to
vSphere
everything
that
happens
to
talk
to
the
platform
happens
in
the
cloud
provider
code
and
the
storage
protocol
code
calls
in
to
that.
A
So,
if
you
just,
you
can
technically
pick
just
like
just
a
storage
provider,
for
example
from
entry,
you
can
use
that,
but
it
will
not
work
because
it
doesn't
know
how
to
call
into
the
the
infrastructure
itself.
So
it
doesn't
have
a
way
to
call
into
the
infrastructure
if
the
cloud
provider
code
is
not
running.
So
in
order
to
do
it
on
a
tree,
we
had
to
do
both
call
provider
and
CSI
at
the
same
time.
So
there's
no
like
that.
A
Some
other
providers
have
this
piecemeal
situation
where
you
can
just
use
the
claw
toe
tree
claw
provider
with
the
entry
storage
provider.
I.
Think
Google
is
one
of
them
that
can
give
you
that
opportunity
to
do
it.
We
cannot
do
that.
We
have
to
you,
can
either
do
in
tree
or
you
can
do
auditory
and
the
dependencies
auditory
are
not
that
hard
that
actually
pretty
you
know
decoupled
from
each
other.
A
The
only
thing
that
happens
is
that,
in
order
to
fulfill
the
basically
the
the
promise
of
the
availability
zones
and
the
tax,
the
the
way
that
the
storage
provider
works,
the
CSI
story
works
requires
the
claw
provider
to
just
you
know,
give
back
that
information.
Basically,
there's
no
outer
Street
dependency
on
that.
Actually
we're
thinking
about
decoupling
that
even
more
make
sure
that
we
can
run
those
independently.
A
D
A
The
question
is:
what
I
can
I'm
fine
can
I
find
some
information
on
the
permission
level
that
you
need
to
like?
Have
these
plugins
do
the
work
for
you
in
in
the
infrastructure
in
chrome
in
vSphere?
That's
a
very
good
question.
We
try
to
actually
work
on
this
type
of
documentation.
It's
easy
to
test
with
all
administrative
permissions
like
we
have
an
open
permission.
You
can
just
log
in
as
an
administrator.
A
You
can
do
everything,
but
in
a
more
constrained
environment
we
actually
have
the
very
similar
problem
to
that
with
VM
T,
which
is
vSphere
on
AWS,
there's
a
very
specific
way
that
VM
C
is
set
up.
It
doesn't
give
you
all
the
permission
for
the
entire
cluster,
so
you
cannot
do
some
of
the
some
of
the
operations
there.
We're
actually
in
the
process
documenting
that
and
well.
I
should
love
some
help
to
get
some
information
more
on
some
very
specific
use
cases.
You
know
many
people,
you
know
create
their
own
these
for
your
deployment
differently.
A
Of
information
already,
if
you
just
go
to
one
of
the
repos
you'll,
see
a
link
to
the
documentation,
there's
a
get
look
page,
which
is
basically
just
markdown
document
created
as
a
website.
There's
actually
some
documentation
there
on
the
level
of
permission
for
a
belief
for
the
storage
provider.
There's
definitely
some
for
a
cloud
provider,
but
I
would
love
to
get
more
more
feedback
on
that.
A
E
A
Yes,
very
good
question
so
how
the
credentials
are
stored
with
the
auditory
provider,
since
the
entry
provider
used
clear
text.
Yes,
there
is.
That
was
a
huge
pain
for
me.
You
want
to
saw
that
actually
it's
fixed
in
entry
as
well.
Now
you
can
use
a
secret.
You
can
is
a
cooperate,
a
secret
to
store
those
credentials
since
115
3,
I
believe.
A
So
it's
done,
it's
done
always
true
secret.
So
what
you
have
is
you
have
your
config
map
that
has
the
configuration
and
then
in
the
config
map,
there's
that
there's
a
pointer
to
the
secret,
the
stores,
the
actual
password
of
vSphere
and
it's
it's
shared
through
both
the
color
provider
and
the
CSI
provider.
So
they
both
share
the
same
secret.
A
You
can
have
different
if
you
and
if
you
need
to,
but
if
you
just
have
one
like,
for
example,
you
have
one
service
account
that
you
using
for
that.
You
can
just
have
one
just
be
told,
there's
an
artist
tool
that
we're
working
on
which
we
call
vcp
CTL,
which
is
basically
a
tool
that
gives
you
an
easy
button
type
of
creation
of
a
solution
user
which
is
a
specific
user
in
vSphere.
A
The
number
P
many
people
know
about
this,
because
it's
used
by
integrations
of
other
products
like,
for
example,
if
you
have
I,
don't
know.
V
realized
operation,
for
example,
which
is
a
product
to
the
monitoring
of
vSphere
when
you
attach,
via
via
ops
with
vSphere.
Your
ops
will
create
a
solution
user
and
use
that
solution
user
to
perform
in
an
operation
there
and
there's.
A
It
actually
needs
not
an
easy
way,
but
there's
a
way
we
created
this
tool
to
do
that.
We
haven't
pumped.
You
know
we
haven't
publicized
that
much
because
it
still
has
a
lot
of
rough
edges,
but
it
will
be
a
good
way
to
just
have
this
as
way
to
just
provision,
a
user
that
has
all
the
privileges
needs
and
it's
not
something
that
is
basically
a
user
that
can
just
log
in
interactively
with
a
UI
if
somebody
discovers
that
password.
A
A
A
That
I
have
with
the
product,
as
you
know,
as
somebody
can
install
vSphere,
is
that
when
you're
within
the
minor
version,
so
let's
say
from
600
to
65
to
67,
there's
no
reason
to
stay
on
the
previous
minor
version.
You
can
just
go
straight
to
the
you
know
to
the
newest
and
greatest
in
within
that
minor
within
that
within
the
major
version.
A
So
you
should
upgrade
miners
as
soon
as
you
can
right
as
soon
as
you're
the
Informatics
fix
or
if
it's
right,
usually
the
reason
why
people
stay
behind
and
the
versioning
is
that
there's
some
other
tool
that
requires
an
older
version
of
committed
era
of
vSphere
and
it
cannot
run
an
old,
newer
version.
That's
usually
the
reason
why
so
I
would
say
it's
much
better
to
just
go
straight
to
six.
Seven.
A
Technically,
there's
nothing
except
for
CSI,
except
for
the
CSI
storage,
plug-in,
there's
nothing
preventing
you
from
using
six
five,
four
cluster
API
or
four
cloud
provider,
there's
nothing
that
prevents
you
if
you're
using
them.
But
if
you
want
you
know,
if
you
want
to
have
blaze
and
greatest
in
terms
of
like
kubernetes
report,
you
should
be
moving
to
673.