►
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: OpenStack SIG - Chris Hoge, OpenStack Foundation & Aditi Sharma, NEC Technologies India
The SIG-OpenStack Introduction and Deep Dive will be an opportunity for members of the Kubernetes community involved with development related to hosting Kubernetes on OpenStack to share existing work and plan for upcoming work. The first portion of the talk will cover basic usage of OpenStack Cloud Provider. We will then follow up with an update on the status of the OpenStack provider for the Cluster API project. The session will wrap up with a deep dive on the software development and future plans.
https://sched.co/MPlD
A
All
right
good
morning,
everybody
and
welcome
to
the
Sig
OpenStack
intro
and
deep
dive.
Now
this
is
an
85
minute
session,
because
we've
combined
both
the
introduction
to
what
sig
OpenStack
is
doing
and
the
kind
of
work
that
we're
doing,
as
well
as
the
deeper
dive
and
more
of
a
work
session
for
people
who
want
to
become
involved
and
contribute
to
the
different
projects
that
fall
under
the
sig
OpenStack
governance.
A
A
We
also
had
some
additional
contributors,
Nanjing
kong,
from
catalyst
cloud
who,
unfortunately,
wasn't
able
to
be
here
for
the
for
the
summit,
but
he
contributed
to
this
slide
deck
and
has
been
a
very
active
contributor
to
the
the
cloud
provider
as
well
as
Thomas
Hartfield
from
Heartland
from
CERN.
Who
is
going
to
be
talking
about
the
the
new
autoscaler
work
that
has
just
landed
within
the
organization?
A
A
On
top
of
that,
we
build
different
sort
of
compute
engines
that
that
take
advantage
of
all
of
those
sonofa
pervert
for
virtual
machines,
as
well
as
bare
metal
containers
with
Zune
and
containers
of
the
function
with
kindling
and
also
as
well
as
other
applications
that
sit
on
top
of
that.
One,
in
particular,
that
is
of
interest
of
this
community
is
Magnum,
which
is
it's
essentially
a
an
application.
A
Okay.
So
what
is
cig
OpenStack?
The
sig
coordinates
the
cross
community
efforts
of
the
OpenStack
and
kubernetes
communities
and
there's
actually
a
sig.
That's
within
the
within
the
OpenStack
community
called
cig
kubernetes,
which
consists
of
the
same
people
and
has
the
same
aims,
and
so
we
are
really
trying
to
build
cross
community
efforts
and
and
build
as
much
collaboration
as
we
can,
because
one
of
the
things
that
that
that
that
the
OpenStack
community
really
believes
is
that
we
are.
A
So,
but
when
you
break
this
down,
there
are
a
lot
of
different
ways
that
these
collaborations
can
happen.
The
first
is
that,
if
you
treat
OpenStack
is
the
point
deployment
platform
for
kubernetes,
and
so,
for
example,
you
know
this
this.
This
comes
up
with
magnum,
but
it
also
comes
with
other
installers
like
cops
or
cube
spray
or
the
new
cluster
API
project.
That's
being
managed,
there's
through
sig
sig
life
cycle.
You
know
so
you're
treating
OpenStack
like
you
would
any
other
cloud
like
you
would
Google
compute
or
Azure
or
AWS
it's
the
cloud.
A
You
want
to
run
applications
on
it.
You
want
to
run
kubernetes
on
that
cloud
to
deliver
the
applications,
but
it
can
also
be
a
service
provider
for
kubernetes,
and
so
this
is
the
instance
where
you
might
want
to
have
an
identity
provider
that
that
lets.
You
manage
users
for
your
communities
clusters,
so
we
have
hooks
to
bring
in
keystone
authentication
or
you
might
want
to
use
the
cinder
storage
provider.
A
But
it's
all.
It
can
also
be
a
collection
of
applications
to
run
on
kubernetes,
and
so,
in
this
case
we're
kind
of
inverting
what's
going
on
here,
and
this
covers
projects
like
OpenStack,
helm
and
airship,
where
you're
putting
your
putting
kubernetes
down
on
bare
metal
on
your
bare
metal
infrastructure
and
possibly
linking
that
in
with
some
other
OpenStack
services
and
then
deploying
OpenStack.
On
top
of
that,
as
a
cloud.
A
We
actually
gave
a
demonstration
of
a
custom
resource
definition
with
kubernetes
that
integrates
with
ironic
to
put
down
bare
metal,
so
you
have
collaborations
between
kubernetes
and
OpenStack
at
the
very
bottom
of
the
at
the
very
bottom
of
your
stack
moving
on
to
the
infrastructure
layer
where
you're
doing
your
OpenStack
installations
or
your
communities,
installations
with
Network
overlays
that
are
that
are
managed
between
products
like
calico
and
and
courier.
And
then
your
cloud
where
you
have
a
full
set
of
cloud
api's
available.
A
Ok,
so
what
are
we
working
on
right
now?
Kind
of
the
major
things
that
are
happening
inside
of
the
kubernetes
community
are
the
cloud
provider
OpenStack,
and
so
this
is
the
software
that
allows
a
kubernetes
cluster
to
talk
to
and
take
advantage
of
open,
OpenStack
resources
that
are
available,
and
this
includes
the
implementation
that
is,
for
the
cloud
controller
manager,
but
also
a
number
of
things
like
a
CSI
driver
for
Cinda
for
cinder.
A
B
C
So
it
is
V
cloud
provider
OpenStack,
it
is
in
the
kubernetes
or
orz
github
repository
and
this
sub
project
hosts
various
plugins
so
that
we
can
leverage
various
OpenStack
cloud
services.
So
first
one
is
a
cloud
controller
manager
that
is,
that
is
the
cloud
provider
interface
implementation
for
cuban
artists.
Second,
one
is
send
the
CSI
plugin
and
we
have
ingress
controller.
Also.
We
have
a
key
manager,
service
and
keystone
authentication
and
authorization.
You
will
see
little
about
each
plugin
in
the
next
slides.
C
So
as
I
said
cloud
provider,
OpenStack
is
the
implementation
for
the
cloud
provider
interface,
so
Cuban
artist
needs
various
information
from
the
cloud
like
information
about
zones
node
and
all
these
details.
These
details
fetch
are
fetched
from
the
OpenStack
through
this
plug-in,
that
is
cloud
controlled
OpenStack
and
it
is
in
essentially
a
CCM
binary,
Cloud
Controller
manager,
binary.
So
the
second
one
we
have
the
Octavia,
sorry
Octavia
ingress
controller,
so
it
is
a
it
is
a
in
Cuban.
It
is
an
interest.
C
C
So
basically
Octavia
ingress
controller
has
been
developed
by
catalyst
cloud
and
they
also
they're
also
using
it
the
next
one
it's
under
the
CSI
drivers,
so
we
have
a
file
system
based
driver
and
a
storage
base
driver,
an
openstack
that
is
sender
and
manila.
So
we
have
the
container
storage
interface
implementation
for
both
of
them,
so
in
Cuba
notice
all
the
entry
providers,
all
the
entry
volume
drivers
are
going
to
be
deprecated
and
they
will
be
replaced
by
the
CSI
ones.
So
we
have.
C
We
are
currently
working
on
CSI
and
ESI
drivers,
so
the
Manila
CSI
driver
that
is
still
in
progress
one
and
in
center
CSI
driver.
We
have
I,
think
released
the
we
have
released.
We
have
two
or
three
releases
of
send
a
CSI
driver,
so
the
next
one
is
Keystone
auth
and
client
Keystone.
So,
like
Chris
also
said
you
can
manage
your
your
Cuban
interest,
cluster
users.
We
are
the
Keystone
plugins,
so
we
have.
We
have
two
plugins
that
works
together.
One
is
the
Keystone
art
and
another
one
is
client
Keystone.
C
The
next
one
is
the
Barbican
kms
plugin.
It
is
a
very
basic
stage,
so
it
provides
encryption
at
rest
service,
but
you
are
with
the
Barbican
service
running
in
your
OpenStack
cloud.
You
can,
you
can
encrypt
your
EDC
today
you
are
Cuban,
it
is
EDC
data,
so
this
plugin
is
also
currently
in
development.
C
D
A
So
so
the
the
migration
story,
for
that
is
you
you.
You
essentially
have
to
restart
the
cube
API
server
and
it's
it's
tricky.
So
you
restart
the
cube,
API
server
and
you
set
the
cloud
provider
to
be
external
and
then
and
then
then
you
bring
up
the
external
provider
and
then
you
restart
the
API
server
again
and
it
will
hook
in
to
the
cloud
provider
now.
The
primary
issue
with
this
is
is
that
your
API
server
will
be
down
for
either
some
amount
of
time
or
the.
A
If
you
have
h
a
API
server,
how
that
manages
the
leader
election
can
be
a
little
bit
problematic,
sig
cloud
provider,
realizes
that
if
you
have
a
running
kubernetes
cluster
and
you
need
to
perform
this
upgrade
that
there
may
be
some
additional
tooling.
That
has
to
happen,
and
so
that's
an
active
sub
project
within
sig
cloud
provider,
which
is
finding
a
migration
path
for
how
you
transition
from
the
entry
provider
to
the
outer
tree
provider
and.
E
So
I
think
the
the
question
more
pertains
to
the
file
formats
between
the
entry
provider
and
what
data
needs
to
be
given
and
what
is
being
expected
by
the
out
of
tree
provider
are
totally
different.
They
require
different
pieces
of
information
that
isn't
available
or
required
in
in
the
entry
versus
out
of
tree
like
how
do
we
go
as
not
so
much
as
like?
How
do
you
make
this
switch,
but
if
I
have
a
hundred
clusters,
how
do
I
operate
a
and
I
mean
collectively
we
have
thousands
and
thousands
of
these
clusters.
E
C
Understand
there
is
a
synchronization
issue
and
I
think
we
can
sing
the
entry
and
out
of
free
provider,
so
we
can
we
are.
We
can
develop
like
for
sender
like
for
the
CSI
plug-in
what
we
are
doing.
We
are
exactly
using
the
same
configuration
parameters
that
are
being
you
already
used
in
the
entry
one
so
same
things
we
can
do
for
the
cloud
provider
code.
Also,
we
can,
we
can
bring
them
in
sync,
yeah,
yeah,.
A
A
Yet
we
have
sig
meetings
on
on
on
Wednesdays,
which
are
the
in
the
morning
for
the
US
and
for
the
afternoon
for
for
Europe,
which
you
know,
that's
actually
I,
think
I
think
those
are
work
items
where
we
should
prioritize
that,
because
the
people
who
are
running
production
clouds
and
and
need
to
make
sure
that
those
stay
up
are
you
know
as
we
make
this
transition
and
this
transition
is
going
to
be
happening
in
in
the
next
like
it's
going
to
be
forced
in
the
next
nine
months.
You
know
we.
D
Maybe
to
explain
a
little
bit
more
I
mean
the
one
thing
is
having
the
API
server
temporaly
tow
and
that's
not
ideal,
but
that's
okay,
but
a
different
problem
is,
for
example,
the
acutely
flex
for
the
cloud
provider.
What
are
we
going
to
do
about
that?
Should
we
like
take
down
all
notes
and
then
we
start
them?
That's
that's
a
problem.
D
C
A
A
Thursday
afternoon
in
the
US
we
have
cloud
provider
extraction
meetings
where
this
is
one
of
the
central
topics
that
we
talk
about,
I
can
I
can
look
at
into
having
that
meeting
moved
to
an
earlier
time,
so
that
there
can
be
a
wider
participation
from
from
you
know.
I
couldn't
know
that
a
lot
of
a
lot
of
the
OpenStack
clouds
are
running
in
Europe,
and
you
know
we
would.
We
want
to
make
sure
that
with
that
one
we
that,
when
we
work
out
the
solution,
that
the
solution
is
going
to
work
in
production
for
everybody.
F
So,
to
recap,
how
we
are
doing
it
you're?
Currently
we
currently
implementing
this
to
migrate
to
the
cloud
provider
and
also
migrate
to
this.
You
sign
a
dragon.
We
are
restarting
the
API
server
and
the
controller
manager
and
also
restarting
all
cubelets,
to
use
the
external
provider
have
some
migration
to
create
a
CR
DS
for
the
CSI
stuff
for
existing
attachments
and
yeah.
That's
it
are.
A
A
A
A
A
It's
one
that
that
dims
prepared
and
has
been
ready
for
about
six
months
now
it
would
be
it
would
need
to
be
rebased
and
reworked,
because
a
lot
of
entry
work
has
happened.
That
has
that
is
that
has
gone
to
extracting
the
providers.
We've
been
deprecated
for
about
a
year
now,
based
on
the
feedback
that
I'm
hearing
right
here
and
so,
and
so
one
of
the
things
I
was
going
to
work
on
was
bringing
that
patch
up
to
speed
and
having
that
in
so
the
code
has
removed
this
cycle.
A
But
if
we're
not
ready
for
that,
then
the
feedback
that
I'm
hearing
from
this
session
is
that
we
might
still
want
to
clean
that
patch
up
and
make
it
ready
to
go
but
make
it
land
directly
after
the
next
release,
so
that
we
have
one
more
release
where
everyone
can
prepare.
And
then
we
have
a
solid
three
months
to
make
sure
that
the
tooling
is
in
place
and
that
the
common
practices
are
in
place,
but
in
general
you
should
be
ready
to
have.
I
Hey
just
a
couple
of
things,
so
the
intrigued
cloud
provider
handled
load
balancers
as
well
as
storage,
but
then
with
the
CSI
and
the
ingress
controller.
Does
that
mean
that
this
is
gonna
be
handled
now
by
those
two
components?
And
it's
not
going
to
be
in
the
cloud
Control
Manager?
Or
is
this
control
manager
going
to
be
using
those.
A
C
Balancer
is
there
an
out
of
tree,
but
there
are
no
volume
control
loops
and
there
is
nothing
related
to
volume
in
the
outer
free
cloud
provider.
This
is
in
general
consensus
from
the
cuban
artists
community.
So
there
is
a
so
CSI
it's
different.
There
is
no
relation
between
the
external
cloud
provider
and
CSI,
so
yeah
you
have
to
deploy
it
separately.
Yeah.
C
A
And
that's
you
know
when
you
look
at
the
documentation
for
I
mean
I,
think
it
was
like
ten
dot.
I
mean
1.6
when
they,
when
they
made
when
they
implemented
the
cloud
controller
manager
and
broke
away
from
the
cube
controller
manager,
where
it
was
a
conscious
decision
that,
because
of
CSI
that
the
volume
control
loop
should
be
handled
independently,
but
you're.
Seeing
this
a
lot
too,
where
there,
you
can
actually
set
up
a
lot
of
these
control
loops
independently,
and
so
the
secrets
manager
is
being
is
in
the
cloud
controller
manager
repository.
A
A
Now,
if
there
are
a
lot
of
OpenStack
clouds
and
I
know
that
within
the
research
community
that
is
happening,
it
may
make
sense
also
to
start
looking
at.
You
know,
adding
zone
support
so
that
we
can
start
building
clusters
across
multiple
regions
and
taking
advantage
of
those
facilities.
But
that's
really
the
only
thing
in
the
in
the
cloud
provider
we
haven't
implemented
yet.
A
For
my
own
personal
experiences,
working
with
with
Elbaz
v2,
it
has
some
pretty
serious
race
conditions
that
Octavia
doesn't
have
so
I
would
suggest
that
you
move
to
Octavia
anyway.
One
of
the
complaints
that
people
have
about
Octavia
is
it's
right.
Now,
it's
pretty
heavyweight,
because
you
need
basically
need
to
bring
up
a
virtual
machine
for
every
load
balancer.
But
it's
my
understanding
that
the
Octavia
team
is
aware
of
that
problem
and
they're
actively
working
on
solutions.
B
B
A
A
J
Everyone
I
just
want
to
give
you
a
quick,
introduce
introduction
into
the
cloud
provider
OpenStack
which,
as
Joe
Beda,
talked
about
that
on
stage
already.
What
we
are
going
to
achieve.
There
is
to
have
a
central
place
where
we
can
define
how
the
clusters
could
and
the
machines
are
going
to
look
like
and
that's
not
specific
to
OpenStack,
but
we
have
an
implementation
for
OpenStack
so
that
you
can,
with
the
same
set
of
API.
So
you
can
bring
up
a
cluster
on
OpenStack
and
we
are
it's
a
very
fast-paced
development.
J
Currently
there
we
have
many
things
that
happen
in
the
cluster
API
upstream
project.
What
we
need
to
keep
up
with
so
developers
are
always
welcome
and
we're
hoping
that
we
can
share
forces
with
all
the
other
cloud
providers
should
get
to
a
point
where
we
have
a
the
right
layer
of
abstraction
and
just
configure
the
separate
other
specific
parts
that
we
need
for
the
specific
implementation.
J
So,
in
short,
it
is.
We
have
the
server
running
in
the
in
the
API
server
as
a
custom
resource
definition.
You
create
how
a
machine
supposed
to
look
like
a
controller
kicks
in,
brings
up
the
Machine
installs
everything
on
top
of
it
and
that's
totally
independent
of
the
cloud
provider.
We
implement
this
part
for
OpenStack,
but
it's
totally
independent.
We
also
have
a
bootstrapping
mechanisms
so
that
locally
on
your
machine
likely
or
on
an
existing
open
stack
where
you
to
play,
deploy
everything
to
it.
J
The
controller
kicks
in
and
on
a
mini
cube,
for
instance,
creates
the
OpenStack
components
for
the
move
or
the
control
plane
and
then
devote
everything
to
that,
and
then
that
takes
over
and
your
clusters
go
into
your
mini
cube
class.
That's
going
to
shut
down
and
everything
else
is
managed
on
the
running
cluster
you
have,
then
we
have
a
couple
of
more
primitives,
not
just
machines.
We
also
have
machine
sets
and
machine
deployments
which
are
very
close
to
how
deployments
and
replica
sets
look
like
in
kubernetes.
J
So
you
can
just
create
a
machine
deployment
of
that
say
three
nodes
and
in
the
background,
the
control
loop
kicks
again
in
creates
three
new
nodes,
connect
them
to
the
API
server.
And
then
you
have
three
three
new
nodes:
you
can
even
have
different
configurations
for
separate
deployments
so
that
you
have
some
nodes
with
GPU
in
it
some
nodes
where
no
GPUs
and
what
whatever
you
need,
whatever
you
need.
J
We
are
very
open
to
that
under
the
covers,
so
where
we
implement
the
class
API,
we
one
alpha
one
currently
and
we
test
with
pike
to
rocky
and
the
OpenStack
versions.
We
didn't
have
tests
for
Stein
as
for
now,
but
that's
going
to
change
in
the
future
and
I.
Don't
expect
any
user
problems
there,
because
the
API
is
that
we
are
using
our
stable.
The
only
thing
I
am
we
have.
We
can't
go
down
to
an
earlier
version
than
pack,
that's
not
possible
because
we
use
ap
is
that
are
not
there
yet
we
support
given.
J
J
There
are
examples
where
you
can
start
from
for
centralized
and
Ubuntu
and
container
the
way
double
bootstrappers
are
kind
or
kind--
mini
cube,
or
an
existing
cluster
I
recommend
to
use
Kint
kubernetes
andhaka,
because
it
starts
up
very
fast
and
you
spin
up
your
OpenStack
machines
and
pivot
and
shut
shut,
shut
that
off
and
the
entire
project
is
also
used
in
the
open
shift
installer.
They
currently
use
a
fork,
but
they
also
contributing
Heavy
D
back,
so
how
you
start
usually
is
for
contributing
you
or
even
for
trying
that
out.
J
You
can
go
to
our
github
repo
check
that
out
install
the
cluster
control
command
and
then
you
need
to
generate
a
couple
of
files,
but
those
are
those
example
files.
There
are
so
many
parameters
you
can
tweak
so
that
we
can't
provide
a
canonical
way
of
doing
stuff
and,
as
I
said
it's
just
like
every
other
communities
manifest.
We
have
those
providers
back,
that's
important
and
everything.
That's
underneath
the
value
is
specific
to
the
cloud
provider.
J
So
what-
and
there
is
really
specific
to
what
we
need
on
OpenStack
and
AWS
thing
would
look
exactly
like
this,
except
for
that.
Well,
use
is
going
to
be
different
and
you
need
to
change
some
things
like
the
image
name.
You
want
to
use
SSH
user
name.
You
currently
need
key
pair
of
to
access
the
staff,
maybe
availability
zone.
J
You
need
to
give
it
a
Cuban
in
OpenStack
network
so
that
they
that
you
have
networking
in
your
VMs
and
probably
a
floating
IP.
That's
primarily
important
for
the
control
plane
component,
but
not
for
notes.
So
on
notes,
you
usually
don't
do
that
just
do
it
on
the
control
plane
and
then
you
can
just
create
the
cluster,
and
this
is
seriously
just
bringing
a
Benitez
locally
on
your
machine
installing
the
cluster
llamo,
which
is
just
a
short
configuration
like
the
pot
cider
and
the
server
cider,
putting
the
machines.
This
is
what
we
saw
here.
J
This
is
one
of
them
is
this
is
a
list
of
machines.
Technically
we
see
one
here
at
the
provider
components,
provider
components
is
something
we
generate
and
there
is
everything
in
we
need
all.
This
is
committed
or
post
it
to
our
cluster,
which
runs
locally.
The
control
loops
kicks
in
and
does
everything
to
bring
up
the
cluster
on
OpenStack.
J
In
the
provider
components
we
also
define
the
user
data
of
this
specific
target
we
have
like
if
it's
in
Ubuntu,
we
inject
a
script
which
uses
cube,
control
underneath
and
brings
up
the
entire
machine
same
for
for
centers.
It's
also
just
the
script
in
this
case
for
container
denotes.
We
are
using
the
content
container,
Linux
configuration
which,
which
is
compiled
into
ignition
internally,
but
nothing
keeps
you
from
changing
that.
So
if
you
decide
you
want
to
have
another
distribution
or
you
don't
want
to
use
those
groups
we
provide.
J
J
Yeah
and
we
are
always
happy
to
have
new
contributors
to
the
project
for
sure,
like
I
said
before,
there's
we
are
working
heavily
on
the
cluster
API.
Currently,
the
v1
I
for
two
there's
much
discussion
happening
there.
So
this
is
the
channel
for
that
and
we
have
our
own
separate
channel
for
the
OpenStack
related
stuff
so
that
we
can
coordinate
quite
a
bit
better
because
the
cluster
API
slack
channel
is
so
full
of
all
the
people
around
the
project
and
it's
it
was
hard
to
coordinate
for
a
specific
provider.
J
So
some
of
the
providers
have
their
own
channels
like
we
have
just
jump
in
ask
questions
and
I
might
I
can
speak
for
the
entire
SiC
here
there
are
no
dumb
questions.
Just
ask
questions.
We
try
to
answer
that.
If
you
don't
get
an
answer,
maybe
try
it
once
more,
because
people
are
sleeping
and
are
not
able
to
to
come
up
with
or
to
follow,
follow
everything
that's
happening.
There's
just
try
it
again,
and
even
if
it's
not
related,
we
are
happy
to
point
you
to
the
direction
where
you
need
to
go.
A
A
J
A
A
That
is
that's
starting
off
of
some
efforts,
that
kind
of
came
out
of
Red
Hat
with
their
work
on
open
shift,
but
it's
turning
into
a
larger
community
bare-metal
effort
now
they're
they're
machine
custom
resource
definition
is
backed
by
ironic,
and
so
there's
there's
a
lot
of
interest
from
the
OpenStack
community
to
work
on.
You
know
to
work
on
this.
A
If
you
go
and
you
look
at
the
keynote
at
the
open
infrastructure
summit
a
couple
weeks
ago
and
I
also
gave
a
demonstration
at
the
the
kubernetes
community
meeting
on
how
the
the
the
implementation
of
the
mist
of
the
machine
custom
resource
definition.
So
you
can
go
and
see
those,
but
but
but
essentially,
there's
going
to
be
the
one
of
the
bare
metal
implementations
for
cluster
API
is
going
to
be
backed
by
ironic
and
airship.
A
Right
now,
airship
is
using
mass
they're
bare-metal
deployment
tooling,
but
they're
going
to
be
transitioning
to
using
cluster
api,
bare-metal
and
so
they're
going
to
be
contributing
to
this
and
recently
at
Sousa
con.
They
they
also
they.
They
announced
that
they're
going
to
be
adopting
airship
as
their
as
their
cloud
deployment
tool.
So
that's
gonna
be
part
of
Sousa
cloud,
10,
so
they're
also
starting
to
Cano
to
participate
and
contribute
in
the
in
the
bare-metal
cluster
API
driver.
So
it's
another.
A
It's
another
place
where
sig
OpenStack
is
definitely
interested
in
that,
because
it's
using
ironic
as
as
the
as
as
essentially
one
of
the
as
the
kind
of
the
the
basic
underlying
driver
for
that,
and
it's
another
place
that
if
you
want
to
get
interested
there's
a
lot
of
work,
that's
going
on
and
a
project
that
really
started
out
is
like
a
Red.
Hat
centric
thing
has
suddenly
become
a
much
broader
community
oriented
project
and
it's
the
developments
moving
really
fast,
but
it's
it's
really
cool
I
haven't
used
it
hands-on
and
use
the
machine
actuator.
J
A
So
I
mean
I,
think
that
is
largely
up
to
the
Magnum
developers.
I
think
that
we
have
some
of
them
here
so
magnums
mechanism
for
for
managing
kubernetes
is
largely
heat
templates
and
there's
been
a
tremendous
amount
of
work
put
into
that
and
it's
it's
it's
it's
stable
work,
and
just
because
one
implementation
exists
doesn't
mean
that
another
implementation
can
exist
and
can
exist
side-by-side.
A
Magnum
is
also
a
user
facing
API.
That's
doing
a
lot
of
work
behind
the
scenes
and
there's
so
there's
no
reason
that
you
know
magnum
couldn't
switch
to
something
like
the
cluster
API
behind
the
scenes.
The
important
thing
is
that
the
Magnum
API
stays
the
same
so
that
when
so
that,
when
a
user
shows
up
the
same
commands
that
bring
up
a
cloud
will
continue
to
work
across
future
releases
of
it.
A
E
Then,
oh
sorry,
so
one
thing
I'm
preface
I
am
one
of
the
maintainer
zuv
cluster,
a
provider
OpenStack
and
a
cluster
API
developer
I've
been
working
on
it
for
about
two
years.
When
it
was
named
something
completely
different,
we
will
be
changing
the
name
as
well.
We
made
that
decision
as
part
of
the
contributor
summit.
E
The
core
thing
to
remember
about
cluster,
a
P
I
is
cluster.
Api
right
now
is
in
a
very
dynamic
state,
but
it
is
the
goal
for
cluster
II
to
be
API,
to
become
the
definitive
way
to
deploy
kubernetes
clusters.
We've
got
hundreds
and
hundreds
of
different
ways
across
the
community
where
we've
built
coop
spray
and
Magnum-
and
you
know
that's
just
like
two
things:
you've
got
cops.
You've
got
gke.
You've
got
all
of
these
different
things
that
are
doing
the
same
thing
we
want
to.
E
You
know:
we've
fractured
out
enough
that
we
can
see
where
most
of
the
api's
need
to
be
what
those
API
is
need
to
look
like
and
we're
bringing
them
back.
So,
regardless
of
what
the
tooling
is,
that's
going
to
be
using
it,
whether
that
be
cops
or
magnum
or
airship,
or
something
else,
cluster
API
provider
OpenStack,
the
underlying
tooling,
will
eventually
be
expected,
not
necessarily
required
by
kubernetes
we're
pulling
more
stuff
out
of
the
core.
E
There
is
less
stuff
required,
but
it
will
be
expected
by
the
user
base
that
you
will
have
the
Machine
primitive
they're
just
as
much
as
you
will
have
the
pod
primitive
there,
and
it
is
expected
that
all
of
the
tooling
will
eventually
use
the
same
api's
and
provide
the
same
user
facing
api's
to
do
that,
whether
you
want
to
use
cluster
api
provider
OpenStack
or
airship,
or
something
else
to
do
that
as
long
as
it
makes
sure
that
it
provides
those
API
is
internally
to
the
user.
Who
cares.
J
K
A
J
A
Right
and
there's
and
there's
a
you
know,
you
might
want
to
differentiate
between
a
cluster
that
you
own
and
you
build,
and
you
and
and
you
you
have
in
cluster
API
is-
is
always
available
to
you.
If
you
have
access
to
a
cloud.
You'll
have
access
to
the
cluster
API,
because
you
make
a
choice
to
stand
up
that
kubernetes
cluster
and
and
how
and
how
you
manage
it.
A
It
interfaces
with
your
cloud
and
it's
just
how
you
stand
it
up
if
you're,
if
you
are
using
someone's,
managed
kubernetes
api,
it's
very
likely
that
people
are
going
to
start
moving
to
cluster
API
to
manage
that
anyway,
but
when
you're
using
a
managed
communities
cluster,
you
know
you
may
not
have
accent.
You
know.
One
of
the
features
of
that
is
you
actually
don't
care.
How
that
cluster
is
is
is
is
established.
You
just
know
that
you
ask
for
the
clustering
and
it's
and
it's
given
to
you.
E
The
expectation
is
that
cloud
providers,
regardless
whether
they're
managed
on
manage
etc,
will
provide
you
with
those
primitives,
because
that's
also
how
we'll
eventually
the
goal
is
to
do
things
like
auto
scaling
and
doing
upgrades.
Also,
you
know
it's
very,
very
easy.
If
you
haven't
tried
it
out,
one
of
the
coolest
things
that
you
can
do
is
scale
your
entire
cluster
by
doing
coupe,
cuddle
scale,
machine
deployment,
replicas
a
hundred
and
now
I've
got
a
hundred
machines
in
my
cluster
and
I
haven't
yeah.
E
B
Alright,
I
also
have
a
lot
of
questions
about
very
metal
deponent
like
I've,
tried,
metal,
cube
and
so
far
so
the
main
idea
behind
it.
So
I
have
these
primitives
that
we've
talked
about.
Like
a
metal
house
become,
you
know,
I
create
a
machine.
It
triggers
the
machine
actuator
which
creates
a
very
metal
host
for
me,
and
then
it
becomes
the
kubernetes
node.
B
G
C
A
There
are
there
any
metal
cube
developers
in
the
room
right
now,
because
so
what
what
I
do
know
is
that,
right
now
they
focused
on
the
machine
actuator,
which
is
come
along
very
nicely.
They
don't
have
that
it's
the
cluster
actuator
isn't
in
place
yet
so
that
the
tooling
that
they're
using
for
that
I,
don't
I,
don't
know
I.
A
Imagine
that
there's
going
to
be
tooling
to
facilitate
different,
different
deployers
and
so
I
would
imagine
that
something
based
on
core
OS
is
very
early
on
on
the
on
the
roadmap,
for
that
so,
but
I
think
that,
because
there
are
so
many
different
interested
parties
that
it's
gonna
have
some
sort
of
pluggable
architecture
where
you
can
pick
your
precise
deployment
method.
So
the
answer
is
I,
don't
know.
G
J
User
data
and
for
the
container
denotes
part
we
are
using
a
cotton.
A
Linux
configuration
is
also
just
passed
in
as
a
as
user
data
into
the
OpenStack
and
under
the
covers
we
for
installation
we
use
cube
ATM,
but
but
that's
also
up
totally
up
to
you,
you
can,
even
when
you
use
faster
API
provided
OpenStack,
you
can
inject
whatever
user
data
you
like
to
and
you
can
either
use
a
prepared
image.
You
could
use
your
own
cloud
config.
You
can
spin
up
the
control
plane
via
VM
with
system
B
instead
of
using
cube.
L
A
Co-Writers
so,
and-
and
so
essentially,
when
you
stand
up
a
Corinne
IDs
cluster
inside
of
an
OpenStack
cloud,
you
are
you're
giving
a
user
a
tenant
and
OpenStack
Neutron
as
well
as
the
other
projects,
have
have
strong
ideas
of
multi-tenancy.
There
are
a
number
of
ways
that
you
can
be
configured
but
largely
that
the
software-defined
networking
component
of
Neutron
make
sure
that
all
of
your
network
traffic
network
traffic
is
segmented.
You
can
also
implement
stronger
or
weaker
policies
on
the
nodes.
A
J
A
L
A
Yeah
running
like
like
a
kubernetes
cluster
is
a
career
Nettie's
cluster
and
one
of
the
one
of
the
goals
of
things
like
the
cloud
controller
manager
and
the
cluster
API.
Is
that
you,
as
a
user
once
you've
launched
your
kubernetes
cluster?
It's
a
kubernetes
cluster
and
you
treat
it
like
you
would
any
other
cluster
and
and
the
machinery
that
you
use
to
manage,
that
is,
is
the
same,
and
so,
if
you
want
to
set
up
our
back,
you
know
so
that
you
can
control.
You
know
you
see,
so
you
have
nancy's
control
and
user.
A
A
J
Last
API
part
of
in
theory
works,
but
you
must
customize
it
because
you
must
pass
that
configuration
to
the
API
server
and
we
are
just
we
don't
have
templating
at
that
point.
So
you
must.
You
must
configure
this
reconfigure
the
script
and
pass
it
to
the
provider
convict,
but
but
it's
in
theory,
it's
possible
totally.
A
N
Hello,
I'm
Thomas,
Hartland
I
work
at
CERN
and
I've
been
developing
the
cluster
autoscaler
cloud
provider
for
Magnum.
It
was
just
mentioned
earlier,
but
when
I
say
cloud
provider
I
mean
only
the
internal
part
of
the
autoscaler,
which
provides
the
interface
between
the
autoscaler
and
the
scaling
api's
of
the
cloud.
N
My
work
was
just
too
late
for
the
autoscaler
1.14
release,
so
it
will
be
released
with
1.15,
but
we
did
already
work
to
include
it
in
the
magnum
stein
release.
So
you
can
already
use
it
if
you
have
already
upgraded
by
setting
this
label
at
cluster
creation
time.
The
manual
deployment
isn't
difficult
at
all.
So
on
older
versions,
you
can
still
do
that.
N
There
are
sorry.
There
are
example
files
in
this
repository
here
in
this
directory,
and
you
only
need
to
change
a
couple
of
things
in
the
deployment
you
need
to
give
the
cost
a
name
or
ID
of
the
cluster.
The
autoscaler
is
going
to
run
on
and
you
set
the
maximum
and
minimum
size
that
you
would
like
the
order,
the
scalar
to
scale
between
just
here,
and
you
should
set
the
maximum
size
so
that
your
cluster
can
not
overrun
the
quota
limits
of
the
OpenStack
project
you're
in
because
it
is
not
aware
of
the
quota.
N
You
also
have
to
give
credentials
for
authenticating
with
OpenStack,
and
you
can
either
copy
these
from
a
cloud
config
file
on
one
of
the
nodes
or
just
fill
in
the
values
yourself,
and
there
is
also
a
service
account
which
you
is
in
another
file,
and
you
do
not
need
to
modify
that.
So
you
create
these
three
files
and
then
you're
up
and
running
when
you
create
some
pods
which
requests
more
CPU
than
there
is
available
in
the
cluster,
the
autoscaler
triggers
a
scale-up
immediately.
N
N
Now.
This
is
all
well
and
good,
but
if
I'm
creating
and
deleting
the
pods
myself
I
could
be
resizing
the
cluster
myself.
Instead,
you
should
use
the
horizontal
pod
autoscaler,
which
scales
the
number
of
pots
in
a
deployment
to
the
amount
of
workload
either
by
the
CPU
usage
of
the
pods
or
by
a
metric
that
the
pods
exposed,
such
as
number
of
requests
per
second
or
the
latency
of
responses.
N
N
N
At
the
moment,
the
cloud
provider
for
Magnum
is
not
yet
feature
complete.
We're
waiting
for
a
couple
of
new
features
in
Magnum
in
the
stein
release.
There
is
the
cluster
resize
API,
which
gives
more
control
to
Magnum
of
how
their
how
the
cluster
is
scaled
and
in
the
train
release
there
will
be
no
troops
for
Magnum.
These
enable
different
node
types,
sizes,
availability
zones
and
different
hardware
of
nodes
in
the
same
cluster,
and
these
node
groups
can
intimately
scaled
based
on
which
pods
want
to
be
on
which
nodes.
N
B
A
Pretty
much
yes,
yeah
I
mean
I
would
I
would
look
at
the
cluster.
Api
is
not
it's
in
still
alpha
right,
it's
still
in
alpha.
So
if
you
use
it
today,
you
can
expect
changes.
You
can
expect
it
to
be
unstable
one
year
well,
one
year
from
now
you
can
expect
to
not
maybe
be
entirely
implemented
across
some
providers,
but
one
year
from
now
you
should
be
thinking
about
how
you
are
going
to
move
your
deployment
tooling
to
cluster
API
or
whatever.
What's
the
new
name
of
it,.
E
E
Cluster
autoscaler
will
be
able
to
get
rid
of
most
of
their
code
and
the
reason
we're
doing
this
is
the
exact
same
reason
as
that
were
we're
moving
to
the
cloud
provider.
It's
that
people
like
really
good
example
here
in
Europe,
is
EXO
scale,
they're,
really
small
Swiss
provider
that
do
fantastic
work,
they're
awesome,
but
they
have
their
own
API
for
them
to
get
any
kind
of
code
into
autoscaler
is
almost
impossible
because
that's
all
controlled,
essentially
by
google
AWS
and
somebody
else,
I
can't
remember
who
that
sure
might
have
some
stuff.
E
But
there
was
somebody,
a
VMware
VMware,
so
getting
any
kind
of
code
merged
into
that
or
getting
any
kind
of
entry
providers
merged
into
the
couplet,
and
you
know
kubernetes
kubernetes
as
a
whole,
like
just
doesn't
happen
anymore.
We
needed
a
better
way
to
do
it
so
we're
extracting
all
of
this
stuff
out.
E
Cluster
API
will
become
the
definitive
way
to
address
the
cloud
provider
from
an
infrastructure
side
of
things,
not
from
a
load
balancing
side
of
things
or
a
storage
side
of
things,
but
from
an
infrastructure
side
of
things,
and
then
we
can
start
ripping
out
all
of
the
code.
That
represents
everything
else.
So
we
are
in
alpha.
That
means
that
our
API
will
change.
E
Some
of
the
providers
already
have
guarantees
about
their
stability,
cluster
API
provider
OpenStack.
We
are
certainly
not
stable.
Please
do
not
use
us
in
production
if
you're
developing
on
it
and
you're
really
really
crazy,
then
maybe
you
can
run
it
in
production,
but
it
certainly
caused
me
a
lot
of
pain.
So,
probably
don't,
but
there
are
providers
like
the
GCP
provider
in
the
AWS
provider
that
say,
hey
come
use.
Us
we're
stable
enough
to
do
this,
so
it
really
depends
on
a
provider
by
provider
basis.
E
The
big
thing
about
cluster
API
is
it's
all
about
the
API.
The
API
will
change.
The
stability
of
the
provider
is
dependent
on
the
provider
and
whether
that
be
a
coops
pray
to
provision
a
control
plane
with
some
machines
under
the
hood
or
something
else
like
at
the
end
of
the
day.
It's
the
same
API
that
you're
going
to
use
to
interact
with
the
machines.
J
And
we
are
certainly
not
here
to
replace
Magnum
but-
and
we
are
not
implementing
a
button
where
you
can
click
on
and
you
get
your
cluster
because
we
already
have
that
it's
called
Magnum.
So
we
are
hoping
that
that
will
that
they
will
keep
up
with
our
development
and
in
a
future
release
of
Magnum.
We
maybe
also
have
a
provider
for
Casta
API,
we're
not
here
to
replace
Merriman
anyways.
A
There
is
going
to
be
a
period
of
time
where,
if
you're,
depending
upon
Magnum
and
you're,
depending
upon
the
api's
that
there's
going
to
be
stability
on
that,
so
that
it's
so
that
you
don't
have
to
think
about
it
as
an
either/or.
If
you
know
if
and
when
Magnum
goes
to
using
cluster
API
as
its
implementation
of
how
it
deploys,
probably
the
biggest
change
that
you're
going
to
see
is
an
improvement
of
the
API,
that's
available
to
you
directly
through
the
kubernetes
cluster.
That's
provided
as
well
as
the
API
provided
to
you
through
Magnum.
A
So
so
it's
you
know
it's
it's
I!
Think
it's
I!
Think
it's
once
you
start
thinking
about
projects
in
terms
of
the
api's
they
provide
and
less
about
the
underlying
implementation
of
it.
You
you
start
bringing
a
lot
more
power
to
the
users
and
that
in
and
to
me
that's
one
of
the
advantages
of
having
something
like
Magnum
API
and
having
the
cluster
API
is
that
they
don't
become
mutually
exclusive
one
another,
because
you're
focused
on
the
API
is
rather
than
just
a
direct
implementation.
O
Well,
thanks:
it's
got
a
question
about
your
products,
your
production
readiness
you're,
telling
me,
maybe
in
nine
months
a
year,
but
how
come
read
that
is
using
it
in
its
OpenShift
installer,
so
I'm
waiting
for
the
OpenStack
installer
for
our
new
open
ship
for
version,
they're
planning
it
for
a
July
releases,
how's
that
possible
I'm.
Sorry,
they
are
not
yes,.
A
A
Production
ready
may
mean
that
you
have
to
wait
for
your
preferred
vendor
to
package
and
support
it,
and
that
is
always
going
to
lag
where
something
is
in
the
development
cycle
and
the
development
cycle.
It's
typically
stable
long
before
it
reaches
production
within
your
vendor,
and
so
you
know
that
you
know
so
much
of
that
depends
upon.
So
you
need
to
be.
A
You
need
to
be
watching
the
developer
community
and
what's
happening
at
these
events,
and
at
meetings
like
these
and
also
you
know
communicating
with
your
vendor
and
saying
that
the
you
know
I've
heard
about
these
things.
When
are
you
going
to
support
it
so
that
you
can
plan
your
own
roadmap
for
it
and.
J
Then
some
specific
kind
of
thing
that
they
bring
up
some
OpenStack
VMs
that
are,
after,
what's
not
necessary,
necessarily
managed
by
trusty
API.
This
is
the
part
I
wouldn't
try
today
because
of
the
stability
but
bringing
that
up,
bringing
the
VMs
up
once
with
an
installer.
Then
you'll
just
freeze
the
code
at
a
certain
point
where
you
know
that
you
can
bring
up
the
m's
and
connect
them
together,
and
in
this
terms,
it's
stable
enough.
A
A
P
We
are
working
on
an
installer,
the
OpenShift
installer,
which
uses
the
cluster
api.
Among
other
things,
it
uses
the
OpenStack
provider
and
it's
we're
planning
to
support
it
before
the
end
of
this
year.
In
India
we
believe
it's
a
pretty
solid
and
ready
to
you
know,
go
in
production
as
soon
as
we
release
it.
Currently,
if
you
check
the
releases
of
openshift
soon
we're
gonna
release
opposite
4.1.
P
A
A
A
And
functional
testing
improvements
for
all
the
drivers
is
on
our
list.
So
if
you
want
to
get
involved,
we
have
a
slack.
We
have
sig
OpenStack
as
well
as
sync
cluster
API,
OpenStack
assume
and
a
Google
group
or
where
there's
a
fairly
low
volume
mailing
list
where
we
communicate.
Also,
if
you
want
to
join
our
meetings,
they
are
every
other
Wednesday
I
think
1500
UTC
yeah.
A
So
we
skipped
this
Wednesday
because
of
Cuba
and
will
resume
next
Wednesday
and
then
every
other
Wednesday
after
that,
and
so
what
we
would
like
to
see
is
there
were
a
lot
of
Awesome
questions
and
people
who
are
very
invested
and
interested
in
the
work
that's
going
on
here.
We
would
love
for
you
to
come
to
the
meetings
so
that
so
that
we
can
that
that
we
can
get
you
involved
in
the
work
that's
happening.
A
We
can
make
sure
that
we're
focusing
our
efforts
on
the
things
that
the
community
needs
at
large
and
also
get
you.
You
know
the
community
members
more
involved
with
the
the
day-to-day
development
more
active
in
you
know
being
part
of
the
community,
because
we're
because
the
number
of
people
who
were
active
in
sig
OpenStack
is
is
pretty
small,
but
the
reach
is
also
fairly
large,
and
so
we
would
like
to
make
sure
that
we're
growing
the
developer
base-
and
you
know
you
know
pretty
much
all
contributions
and
all
feedback
are
welcome.
C
A
And
also
for
for
those
of
you
who
are
interested,
we're
gonna
talk
if
you're
interested
in
cloud
providers
themselves,
I'll
be
giving
a
talk
later
this
afternoon,
going
into
a
few
more
details
of
how
you
start
building
a
cloud
provider
and
just
kind
of
an
introduction
on
where
the
code
is
how
it
works,
the
things
that
are
expected
to
be
implemented
and
some
tricks
for
how
you
test-
and
you
know,
and
some
other
implementation
details,
and
so
that
is,
is
going
to
be
happening
this
afternoon.
At
let's
see
what
time
is
that
happening
at.
A
Q
N
So
the
autoscaler
is
structured
in
such
a
way,
or
at
least
the
the
Magnum
cloud
provided
in
development.
It
was
called
the
OpenStack
auto
scalar
cloud
provider,
but
then
we
changed
it
because
it
was
only
for
Magnum
at
that
time.
The
structure
is
such
that
there's
a
kind
of
OpenStack
general
layer
in
the
cloud
provider,
and
then
there
are
different
managers
possible
that
can
call
different
api's.
N
So,
for
instance,
once
the
node
groups
and
the
resize
api
are
available,
that
will
be
a
separate
manager,
but
we
will
use
the
same
OpenStack
authentication
from
the
kind
of
the
other
layer
of
the
cloud
provider.
If
you
wanted
to
use
OpenStack
with
something
else,
you
could
write
a
different
manager
that
would
also
slot
in
and
provide
its
own
interface.