►
From YouTube: Cloud Provider OpenStack Community Session - Kendall Nelson, OpenStack Foundation & Aditi Sharma
Description
Cloud Provider OpenStack Community Session - Kendall Nelson, OpenStack Foundation & Aditi Sharma, NEC
In this session, the Cloud Provider OpenStack team will give a brief overview of OpenStack cloud integration projects, including the: * OpenStack cloud controller manager. * Cinder and Manilla storage providers. * Cluster API provider. * Keystone identity integrations. * Other provider interfaces. In addition to this overview, they will also engage the community to plan future development efforts and priorities. Both OpenStack beginners and experts are encouraged to join the session, and the community content will be tailored to fit audience interests.
aditi sharma
Software Engineer, NEC
Aditi works as a Software Enginner at NEC, She primarily works on cloud native technologies, she contributes to opensource projects like Kubernetes, OpenStack. She is also approver/reviewer for provider-openstack subproject under SIG-Cloud-Provider.
Kendall Nelson
OpenStack Foundation
Upstream Developer Advocate
kennelson11
Websitekendallnelson.dev
Kendall is an Upstream Developer Advocate at the OpenStack Foundation based in Seattle, WA. She first started working on Cinder and os-brick in the Liberty release and since then gotten involved in Release Mangement, StoryBoard, the Women of OpenStack (WoO), the First Contact SIG, the Contributor Guide, and OpenStack Upstream Institute. She has also worked as an election official for TC and PTL elections (Pike-Rocky) and served as a track chair for the Barcelona, Boston, Sydney, and Vancouver summits.
A
B
I'm
Kendall
Nelson
I
work
for
the
OpenStack
foundation.
I've
been
involved
in
OpenStack,
specifically
for
about
four
and
a
half
years
now,
mostly
working
upstream
for
previously
IBM
and
now
the
OpenStack
foundation
and
I've
been
getting
more
involved
in
the
kubernetes
community
over
the
last
six
ish
months.
So
yeah,
ok,.
A
So,
let's
get
started
with
the
presentation.
Ok,
so,
firstly,
you
will
see
what
are
cloud
providers.
Mostly
everybody
of
you
know
this,
but
it's
just
to
revisit
some
things.
Okay,
so
like
to
leverage
cloud
services
in
Cuban
address
clusters,
cloud
providers
are
used
cloud
provider,
any
enables
kubernetes
to
talk
with
cloud.
Api
is
I
mean
for
to
get
the
information
about
the
underlying
infrastructure,
like
your
zones
or
your
volumes,
and
your
no
details,
okay,
so
in
Cuba
notice,
when
they
started,
they
have
all
the
cloud
providers.
Entry
like
is
your
OpenStack
and
GCP.
A
All
the
code
for
the
cloud
provider
was
built
inside
the
Cuban.
It
is
binary
and
also
the
code
resides
in
the
main
Cuban
address
repo.
So,
as
the
number
of
cloud
providers
have
grown
up
in
kubernetes,
it
was
very
difficult
to
get
managed
all
the
cloud
provider
in
the
kubernetes
ripple,
and
also
it
was
a
they
were
facing
maintenance
issues.
Their
binary
size
were
was
getting
bigger,
so
they
have
decided
to
move
all
the
cloud
providers
out
of
tree.
So
in
Cuba
notice
for
provider
OpenStack,
we
have
two
versions
of
cloud
provider
exist.
A
Currently,
one
is
the
entry
one
and
one
is
the
out
of
tree
provider,
so
the
entry
cloud
provider,
mostly
current
clusters,
are
deployed
on
the
entry
cloud
provider.
It
is
deprecated,
so
we
are
also
maintaining
the
out
of
tree
version.
So
any
of
you,
if
you
are
deploying
a
new
Cuban,
a
disk
cluster
that
should
be
that
should
use
the
out
of
three
provider
one
and
those
using
the
entry
version
they
need
to
migrate
to
the
out
of
tree
version,
okay,
so
yeah.
A
So
basically,
when
an
entry
provider,
what
happened?
Various
Cuban,
a
disk
components
like
cubelet
queue,
controller
manager
and
all
these
talks
to
the
claude
api
with
the
out
of
tree,
provide
reversion
all
these
things.
They
are
say
greek,
their
aggregated
to
a
single
binary
that
is
called
as
cloud
controller
manager.
A
So
all
the
control
loops
are
accepted
from
the
cube
controller
manager
and
the
cubelet
that
they
are
now
in
cloud
in
the
CCM
binary
that
is
called
as
cloud
controller
manager,
so
yeah
so
deploying
the
out
of
tree
provider.
I
mean
most
of
you
are
well,
it
was
with
deploying
the
entry
version,
so
here
I
have
I
just
there
are
some
summary
that
how
will
it
apply,
deploy
the
out
of
tree
cloud
provider.
So
there
are
various
deployment
tools
available
to
deploy
a
kubernetes
cluster
on
OpenStack.
Maybe
magnum
copes
cube
ADM.
A
A
You
need
to
deploy
separately,
the
cloud
controller
manager
for
OpenStack
as
a
demonstrate
in
your
cluster,
and
since
the
outer
free
cloud
provider
does
not
manage
volumes,
so
you
also
need
to
deploy
the
CSI
driver,
Center
CSI
driver
for
volume
management,
so
the
so
for
deploying
out
of
three
provider.
You
additionally
need
two
things:
one
is
the
deploying
the
CCM
binary
and
the
cinder
CSI
driver
II.
A
A
Okay,
so
we
host
the
project
in
Cuba
notice,
o
RG.
Only
you
can
go
to
the
link
and
we
have
a
repository
here
and
apart
from
cloud
provider,
there
are
various
other
plugins
like
cinder,
CSI,
Manila,
CSI,
ingress
controller,
the
Barbican
key
manager
plugin.
All
this
repository
contains
all
of
the
plugins,
and
so
the
mostly
the
code
is
in
the
package
repository
in
the
package,
folder,
sorry
and
yeah.
We
have
all
the
manifest
file
here
to
deploy
the
cloud
controller
manager
or
to
deploy
the
CSI
plugin.
Any
plugin
you
want
to
deploy.
A
A
B
In
addition
to
the
entry
and
outer
tree
cloud
providers,
we
have
a
variety
of
plugins
she's
covered
them
a
little
bit,
but
there's
an
Octavia
ingress
controller.
We
have
two
different
storage
plug-ins
for
syndra
Manila,
if
you're
familiar
with
those
I'll
go
into
them
a
little
bit
more
in
a
sec
here,
the
Barbican
key
managed
queue
manager,
service
and
obviously
needs
some
authentication
too
so
Keystone
for
that
so
diving
in
a
little
bit
deeper.
The
Octavia
ingress
controller
is
a
controller
and
not
an
actual
load.
Balancer
service.
B
It
helps
kind
of
manage
all
of
them
together
and
Octavia
is
the
OpenStack
project
that
uses
Elle
bass
for
this
for
storage.
You
know,
need
storage
for
your
cloud.
We
have
the
cinders
the
block,
storage
project
and
OpenStack
and
Manila
is
the
like
filesystem
service.
So,
depending
on
what
you
want
for
storage,
you
could
use
either
one
of
those
plugins
and
yeah
moving
on.
B
So
the
other
important
project
that
we
wanted
to
point
out
was
Magnum
DT
mentioned
it
a
little
bit
earlier,
but
basically
it's
a
service
for
management
of
your
container
infrastructure.
Recently,
with
the
OpenStack
train
release,
there
were
a
variety
of
improvements
that
they
were
able
to
implement
and
update,
and
so
we
wanted
point
some
of
these
out.
The
rolling
upgrades
being
available.
Auto
healing
now
is
also
available.
You
can
boot
kubernetes
clusters
from
volumes
and
use
configurable
volume
types
and
then
a
little
bit
more
of
work
was
done
on
private
clusters
as
well.
A
Okay,
so
these
are
some
major
updates
so
fastest
previously
cloud
provider,
OpenStack
was
a
sync
in
Cuban
and
s
community.
Now
all
the
cloud
provider
SIG's
are
dissolved
and
provider.
Openstack
is
a
sub
project
under
the
fic
cloud
provider.
So
previously
si
G
cloud
provider
OpenStack
used
to
maintain
used
to
manage
cloud
provider,
OpenStack
cluster
API
provider,
OpenStack
cluster,
auto
scale
for
OpenStack,
but
now
these
projects
are
under
a
size,
e
cluster
lifecycle
and
the
provider.
A
So
users,
the
API,
will
remain
intact,
so
there
will
be
no
effect
on
the
if
they
are
using
an
entry
signals
under
volume
driver
and
they
have
volumes
persistent
volumes
and
PVCs
using
the
entry
one.
They
just
need
to
install
the
CSI
driver.
However,
while
upgrading
the
cluster
and
all
of
the
calls
from
entry,
all
of
the
API
calls
to
the
entry
volume
driver
will
be
migrated
to
the
CSI
driver.
This
is
currently
is
an
alpha
stage
and
will
be
moved
to
beta
next
cycle.
A
Second,
there
was
a
standalone
sender
driver
that
has
been
deprecated,
because
there
was
no
user
and
no
Manta
maintainer
around
it.
So
it
has
been
deprecated,
not
Manila,
manila
CA
side.
Our
driver
is
implemented
in
la
cycle
only,
but
there
was
various
features
and
bug
fixes
has
been
done.
The
cycle
Cinda
CSI
driver
is
now
updated
to
the
CSI
specs
1.1
dot
0
resize
support
has
been
added
in
cinder,
CSI
driver.
So
with
this
feature,
the
sender
CSI
driver
is
now
in
feature
parity
with
the
entry
a
sender
driver,
go
module.
A
A
We
need
to
have
the
CI
job
for
entry
migration
so
that
we
can
move
it
to
beta
as
CI
is
very
fluctuating
and
we
want
to
move
jobs
to
kind
currently
you
it
uses
a
hack,
local
up,
cluster
dot
asset
script,
and
we
also
want
to
have
upgraded
migration
strategy
from
moving
entry
to
external
provider.
So
one
thing
currently
one
PR
is
up
for
the
documentation
that
that
tells
how
you
can
migrate
from
entry
to
external
provider.
A
The
PR
has
not
been
merged
yet,
but
it
is
up
now
so,
let's
second,
we
also
want
to
move
our
images
to
destroy
less
sin
in
senders,
ESI.
We
are
expecting
in
line
cloning
and
e
to
test
support
for
the
next
cycle,
and
if
you
want
to
have
any
feature
any
bugs,
you
can
report
and
we
cloud
provider
OpenStack
repo
okay.
So
this
is
the
rough
timeline.
Currently
for
the
entry
provider
OpenStack
removal,
so
basically
there
is
a
dependency.
Unless
and
until
the
CSI
driver
migration
things
to
GA,
we
cannot
remove
the
provider
OpenStack.
A
A
B
B
The
the
timeline
we
laid
out
is
kind
of
like
where
we're
going
as
far
as
features
on
top
of
that
or
in
more
detail
I,
don't
think
we
have
a
whole
lot
of
that
planned
out
yet
opportunity
to
get
involved.
If
there's
something
that
you're
interested
in
in
particular.
Definitely
let
us
know
yeah
another
question.