►
From YouTube: Introducing Metal³: Kubernetes Native Bare Metal Host Management - Russell Bryant & Doug Hellmann
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
Introducing Metal³: Kubernetes Native Bare Metal Host Management - Russell Bryant & Doug Hellmann, Red Hat
Metal³ (“metal kubed”) is a new open source bare metal host provisioning tool created to enable Kubernetes-native infrastructure management. Metal³ enables the management of bare metal hosts via custom resources managed through the Kubernetes API as well as the monitoring of bare metal host metrics to Prometheus. This presentation will explain the motivations behind creating the project and what has been accomplished so far. This will be followed by an architectural overview and description of the Custom Resource Definitions (CRDs) for describing bare metal hosts, leading to a demonstration of using Metal³ in a Kubernetes cluster.
https://sched.co/UaZr
A
So
the
first
question
I'm
sure
all
of
you
are
asking
yourself
is:
why
did
we
build
another
tool
to
provision
servers?
There's
the
bazillion
tools
out
there
already
that
do
that
and
we've
been
doing
it
for
years
and
years
and
what
is
the
point
of
having
another
tool?
So
we
have
three
main
reasons
that
drove
us
creating
this
new
project.
A
The
first
is
that
we
wanted
something
that
had
a
kubernetes
native
API,
so
that
a
cube
admin
who
was
working
with
their
cluster
could
use
the
same
tools
to
administer
the
infrastructure
underneath
the
cluster
that
they
used
to
administer
the
applications
that
run
on
top
of
it.
We
also
wanted
the
tool
to
be
self
hosted
so
that
it
would
run
in
the
cluster.
So
you
don't
have
to
deploy
something
separately
in
order
to
manage
your
clusters,
and
then
we
also
wanted
the
tool
to
manage
the
cluster
itself.
A
So
we've
tied
in
with
the
machine
API
from
Sigma
cluster
life
cycle,
so
that
once
you
have
the
tool
installed,
everything
works
just
the
same
way.
It
would
is,
if
you
had
a
cloud-based
cluster,
so
you're
operating
your
bare
metal
cluster
in
the
same
way
that
you
would,
if
you
were
on
Amazon
or
Google
or
whatever.
A
So,
let's
look
at
the
pieces
of
the
system
and
talk
a
little
bit
about
the
design
and
how
it
works.
I
mentioned
that
we
wanted
to
have
kubernetes
native
API,
so
the
API
for
metal
cubed
is
a
new
CRD
called
the
bare
metal
host,
and
that
gives
us
a
little
bit
of
information
about
the
host
so
that
we
can
manage
it.
So
we
need
things
like
the
credentials
and
the
location
of
the
base
board
management,
controller
and
then
some
information
about
it.
So
we
can
recognize
it
when
it
come
show
up
on
the
network.
A
So
we
get
things
like
a
MAC
address
and
stuff
like
that.
That
information
is
used
by
the
bare
metal
operator
which
drives
the
provisioning
process
by
invoking
the
ironic,
REST
API.
So
ironic
is
a
provisioning
tool
that
came
out
of
the
OpenStack
community.
It's
got
a
nice
REST
API
for
doing
provisioning,
and
it
knows
how
work
with
a
lot
of
different
kinds
of
hardware,
and
by
adopting
that
we
were
able
to
really
bootstrap
the
project
and
make
a
lot
of
a
lot
more
progress
than
if
we
had
started
from
scratch.
A
A
Ironic,
we'll
use
the
image
that
you
have
hosted
in
your
image
registry
and
it
will
take
some
config
drive
data
that
we
pass
it
and
it
will
deploy
the
image
to
the
server
and
reboot
the
server
to
run
whatever
that
image
is
so
this
level
of
this
layer
of
the
components
is
basically
a
generic
provisioning
tool
that
wraps
up
an
existing
API
in
a
kubernetes
native
API.
So
that
gives
us
two
of
our
three
goals.
A
We've
got
that
kubernetes
native
out
API
and
it's
self
hosted
running
in
the
cluster
that
you're
working
with
and
in
order
to
meet
our
third
goal
of
having
it
be
self
managing.
That's
where
we
tie
in
with
the
machine
API.
The
machine
API
is
out
of
the
cig
cluster
life
cycle
group.
It
defines
things
like
machine
set
and
machine
which
allow
you
to.
A
All
right,
so
I've
mentioned
three
different
representations
for
the
same
sort
of
piece
of
your
cluster.
We
get
this
question
a
lot.
Why
do
we
have
nodes
and
machines
and
hosts
nodes?
I'm
sure
everybody
is
familiar
with
that
concept.
That's
the
basic
concept
built
into
kubernetes.
Basically,
where
you
have
a
cubelet
running,
the
machine
is
the
new
thing
that
comes
from
the
signal,
Uster
life
cycle
group
and
the
work
that
they're
doing
there
and
that's
you
think
of
it
as
a
request
to
have
a
cubelet
run
somewhere
and
when
you're
running
in
a
cloud
environment.
A
What
happens?
Is
the
provider
calls
out
to
the
cloud?
Api
creates
a
new
configures,
that
instance
to
become
a
node
and
then
uses
the
machine
resource
to
keep
track
of
the
instance
and
track
the
information
about
it,
and
that's
really
thing
well:
in
a
bare-metal
environment
we
don't
have
a
cloud
API,
we
have
to
become
the
cloud
API,
and
so
that's
what
the
host
resources
for
that
gives
us
that
API
that
we
can
call
out
to
and
trigger
provisioning
trigger
configuration
and
the
host
resource
becomes
inventory.
A
So,
let's
look
at
the
details
of
what
a
host
actually
looks
like
I
mentioned,
that
we
need
the
base
management,
controller
credentials
and
locations.
So
that's
here
in
the
BMC
fields.
We've
support
a
couple
of
different
kinds
of
BMC's
for
different
hardware
vendors,
so
there's
the
URL
specify
as
what
protocol
to
use
and
then
a
location
on
the
network
where
we
can
find
it
and
the
credentials
are
stored
in
a
secret
so
that
those
are
all
protected
and
we
just
you
know,
read
the
secret
inside
the
operator
when
we
need
it
to
talk
to
ironic.
A
The
consumer
ref
field
is
used
to
keep
track,
of
which
hosts
are
actually
being
consumed
by
some
other
systems.
So
in
this
case
it's
been
allocated
to
a
machine.
So
it's
going
to
be
provisioned
or
it
has
been
provisioned
as
a
worker
node
in
this
cluster.
If
you
were
using
the
lower-level
api
yourself
to
provision
other
things,
you
could
put
some
other
reference
in
there
just
to
sort
of
keep
it
as
a
placeholder
to
indicate
that
that
host
was
being
used,
the
image
fields,
control
what
image
has
actually
been
provisioned
to
the
host.
A
So
that's
the
spec
section
of
the
host
the
status
section
includes
some
information
that
we
can
learn
about
the
host
as
we
inspect
it
and
do
provisioning.
So
the
hardware
fields
collect
information
about
all
of
the
CPUs.
All
of
the
network
interfaces
all
the
storage.
That's
available,
I've
abbreviated!
This
we
actually
collect
quite
a
lot
of
information,
that's
available
about
what's
in
the
host,
and
you
can
use
that
to
select
which
host
you
want.
A
So
you
can
select
only
hosts
that
have
a
certain
amount
of
ram
to
be
a
part
of
certain
machine
sets
and
things
like
that.
The
operational
status
field
is
basically
an
error
indicator.
If
we
can't
talk
to
the
management
controller
or
if
the
Machine
suddenly
stops
working
correctly
in
some
other
way,
we're
gonna
reflect
the
error
in
that
field
and
then
that
provisioning
section
at
the
bottom
is
showing
what
actually
was
provision
to
the
host.
So
you
have
the
instructions
in
the
spec
and
you
have
the
the
actual
reality
in
the
status
field.
A
Once
the
provisioning
is
completed,
and
you
will
see
in
the
demo
that,
as
the
host
is
being
provisioning
to
the
state,
will
update
from
different
steps
along
the
way
to
to
show
exactly
what's
going
on
all
right.
So
at
this
point,
I'm
gonna
hand
over
to
Russell
and
he's
going
to
talk
about
the
deployment
process
and
show
some
demos
or
deployments
sure.
B
I've
got
four
demos,
I'm
gonna,
show
and
before
I
get
into
that
I'm
just
gonna
talk
through
a
little
bit
kind
of
wrapping
up
what
Doug
talked
about.
He
talked
about
the
architecture,
some
of
the
api's.
This
is
one
particular
use
case.
We've
taken
our
metal,
cube,
components,
we've
built
and
we
have
them
integrated
into
two
openshift
and
so
talking
about
what
does
that
look
like
in
an
open,
shipped
cluster?
So
the
use
case
we
have
an
existing
cluster.
We
want
to
add
another
host
to
that
cluster.
Or
do
you
have
to
do
first?
B
You
got
to
set
up
the
host
so
literally
get
up
as
close
to
you
got
to
plug
it
in
and
we
need.
We
have
some
expectations
about
how
it's
gonna
be
plugged
into
the
network.
You
have
your
primary
network
for
the
cluster.
We
have
a
separate
provisioning
network,
so
you
can
get
it
get
it
set
up
and
then
you're
gonna
create
that
bare
metal
host
resource.
That's
adding
it
to
the
inventory
so
telling
the
cluster
about
a
new
new
host.
B
It
has
available
to
it
to
manage,
and
so
that
the,
but
to
do
that,
you
create
the
bare
metal
host
resource,
then
you're
gonna
create
a
machine.
So
if
our
desire
here
is
to
enroll
this
new
host
as
a
node
in
the
cluster,
you
need
to
create
a
machine.
So
maybe
you
create
them,
oisin
directly
or
you
scale
up
a
machine
set.
However,
you
do
it
and
that's
that's
the
the
end
of
your
sort
of
active
involvement
than
that,
and
then
our
automation
kicks
off
from
there.
B
So
once
you
know
the
Machine
gets
created,
it
finds
an
available
host
to
satisfy
the
request
it
triggers
provisioning.
The
host
is
provisioned,
given
the
necessary
configuration
it
needs
and
it
comes
up
and
joins
the
cluster
as
a
new
node
post-deployment.
We
also
do
look
at
doing
active
monitoring
of
the
state
of
the
host.
You
know
watching
power
state
also
gathering
any
sort
of
out
of
looking
at
gathering,
ateb
and
metrics
those
sorts
of
things.
B
B
So
let
me
talk
a
little
bit
about
the
the
environment
that
these
demos
are
running
in
so
in
the
project
and
the
metal
cube
project,
we
have
a
repo
called
metal,
3
dev
and
what
metal,
what
this
development
and
test
environment
does?
Is
it
sets
up
a
an
environment
with
virtual
machines
and
were
able
to
manage
and
provision
virtual
machines
just
as
if
they're
bare
metals,
that's
what
you'll
see
here
is
handy
for
well
for
development
and
testing,
and
so
that's
what
I'm.
That's
what
I'm
using
here
to
show
these
and
the
inspection
process.
B
B
So
we're
gonna
kick
off
play
in
the
first
I'm
going
to
show
here
is
that
we,
this
is
a
cluster
that
has
no
bare
metal
host
resources
created,
yet
so
I'm
about
to
create
them,
and
in
here
we've
got
to
a
host
1
and
host
2
and
the
the
required
information.
We
need
the
MAC
address
that
we
can
recognize
these
hosts
in
the
provisioning
network
and
we
need
the
BM
secret
information,
this
IP
address
and
the
credentials
and
a
secret
and
we're
also
I'm,
also
creating
two
secrets
with
those
credentials
in
it.
B
So
here
we
go,
we've
created
those
two
bare
metal
hosts
and
the
two
secrets
and
now
I'm
going
to
watch
looking
at
the
bare
metal
host
resources.
So
here
we
are,
we've
got
our
two
hosts
and
they've
just
been
created
and
you
can
see
the
provisioning
status
is
in
inspecting.
So
what
happens
here
is
the
first
thing
we
do.
Is
we
boot
these
hosts
into
a
special
Ram
disk?
This
is
this
is
a
capability
of
ironic.
B
This
Ram
disk
then
runs
some
tools
to
gather
all
the
data
about
the
hardware
it
can
find,
and
then
it
posts
all
that
hardware
details
back
to
an
API,
so
we
can
store
it
and
present
that
in
the
bare
metal
host
resource,
so
through
some
of
these
things
that
are
normally
long-running
operations,
of
course,
I'm
speeding,
I'm
speeding
up
the
recording
here
to
show
but
it'll
that
finishes
and
it
gets
into
a
ready
state.
What's
in
a
ready
state,
that's
a
host
that
that
is
ready
to
be
provisioned
for
some
purpose.
B
So
I'm
gonna
jump
out
of
the
that
and
I'm
going
to
look
at
the
yeah
mol
of
a
one
of
these
resources
and
show
that
now
it's
populated,
if
all
these
hardware
details
so
I'm
gonna
scroll
on
down-
and
here
we
are
so
now.
The
first
is
our
CPU
section.
You
know
the
thing
on
the
slide
earlier
was
abbreviated
and
this
is
sort
of
showing
more
of
the
details.
So,
with
the
architecture
speeds
how
many
CPU
cores
we
have
all
the
CPU
flags
that
you
might
care
about
to
know
scroll
on
down.
B
We've
got
my
gather
a
bit
a
spur
more
information.
We
know
the
host
name
of
that
host
the
host
name.
It
got
when
we
booted
that
Ram
disk.
You
know
what
host
name
did
it
get
from
DNS.
We
store
that
off
what
network
interfaces
we
observed
from
the
servers
and
what
IP
addresses
they
got,
how
much
RAM
it
has
how
its
storage
we
had
in
this
case
you-
and
this
is
the
VM
test
environment.
B
So
that's
the
step
so
now
we're
going
to
so.
Okay,
so
far,
I'm
only
looking
at
the
bare
metal
host
API,
the
next
thing
you
can
do
if
you're
only
focused
on
this,
the
lowest
level
API
here
the
bare
metal
host,
you
can
provision
an
operating
system
image
to
that
host
and
so
that
well
we
know
how
to
to
take
a
image
and
get
it
written
to
disk
and
then
have
the
host
reboot
back
into
that
image
that
we've
written
there
so
I'm
going
to
show
that
process.
B
Now,
what
I'm
gonna
do
here
is
I'm,
taking
like
the
generic
CentOS
cloud
image
that
you
could
download
from
the
Cintas
website
and
get
it
provisioned
here,
I'm
passing
the
enough
to
user
data,
so
that
cloud
in
it
can
inject
my
SSH
key
and
I'll
be
able
to
ask
the
sage
into
the
resulting
provisioned
server.
So
off
we
go
so
we
have
those
host
1
and
host
2
that
I
created
in
the
last
demo,
I'm
gonna
show
here
in
this
host.
B
B
B
So
we
take
a
look
at
this
bare
mental
host
resource
again
and
and
show
that
we've
patched
it
and
set
an
image.
So
here
we
are
and
it's
this
is
again.
This
is
the
generic
cloud
image
from
since
I'm
unmodified
but
hosted
somewhere
on
the
cluster.
So
they
can
download
it
faster
and
once
we
back
out
out
here,
we
can
look
at
the
bare-metal
host
resources
again
and
see
that
this
in
a
new
state.
So
now
that
we've
patched
it
and
set
an
image
on
the
spare
mental
host,
it's
now
in
our
provisioning
status.
B
So
we
can
watch
this
and
of
course,
this
is
a
fast
forwarded
recording,
especially
on
real
bare
metal
hosts.
This
takes
a
bit
of
time
because
we're
rebooting
the
servers
a
couple
times
to
go
through
this
process,
but
we,
you
know,
what's
really
happening
in
the
background.
Is
there
we're
telling
ironic
to
drive
the
deployment
process,
we're
booting
the
server
into
a
ram
disk?
That's
a
part
of
part
of
ironic.
B
That
knows
how
to
then
pull
down
the
image
and
write
it
to
disk,
and
then
we
ultimately
reboot
the
server
into
that
into
the
operating
system.
We
wrote
to
the
disk,
so
there
we
are
it
provisioned
itself
and
we
can
I'm
showing
here.
Just
as
a
reminder,
you
know
in
the
status
section
we
we
happen
to
gather
some
IP
addresses
for
the
network
interfaces
before
and
so
I
can
snag.
One
of
those
and
SSH
into
this
new
server
that
I
just
provisioned
to
kind
of
demonstrate
that
it
really
did
what
I
wanted
it
to
do.
B
All
right
gran,
so
we
SSH
it
into
a
noose
in
Tasos
right
uptime.
It's
been
up
for
0
minutes,
so
this
is
a
freshly
provisioned
host
and,
of
course,
like
I
said,
the
only
thing
we've
done
here
is
injected
an
SSH
SSH
key,
but
it
kind
of
shows
that
at
this
base
layer
of
the
things
we've
built,
we've
we've
provided
as
this
kubernetes
native
API
for
getting
operating
system
images
provisioned
to
bare
metal
hosts.
So
that
is
that,
and
of
course
you
can
do
the
opposite.
You
can
deep
provision,
a
host
which
is
similar.
B
You
know
when
we
provisioned
it.
We
patched
it
to
set
the
image
if
you
patch
it
and
remove
the
image
completely.
That's
saying
that
now
your
desired
state
of
this
bare
metal
host
is
that
nothing
is
provisioned
to
it.
So
then
we
will
drive
it
to
addy
provisioning
process,
wipe
the
disks
and
off
it
goes.
B
B
Okay,
demo
number
three,
so
I
kind
of
talk
to
this
a
little
bit
before
I
jumped
into
the
terminal.
What
does
this
look
like
an
open
shift
when
we've
integrated
this
into
a
platform
and
using
a
machine
API
I'm,
going
to
show
that
process?
I
talked
about
a
little
bit
where
we
have
an
existing
cluster
I'm,
going
to
start
with
a
cluster?
That's
three
three
masters,
and
how
do
we
add
what's
the
process
of
adding
a
new
host
to
become
a
worker
in
this
cluster?
B
So
that
is
this,
so
first
I'm
going
to
take
a
look
at
some
existing
resources.
We
have.
There
are
three
masters.
There
are
three
bare
metal
hosts
that
correspond
to
those
three
masters
that
exist
and
there's
also
a
machine
set.
This
machine
set
were
first
represents
our
the
number
of
desired
worker
nodes
for
this
cluster
and
right
now,
that's
set
to
zero,
but
we
want
to
add
a
worker.
So
what
do
we
need
to
do?
B
B
All
right
so
we've
created
that
new
bare-metal
host
and
if
we
look
at
the
list
of
bare-metal
hosts,
we
had
those
three
masters
before
and
now
we
have
a
fourth,
this
fourth
one
is
in
a
ready
state,
it's
ready
to
be
provisioned,
it
hasn't
been
provisioned,
yet
nothing
has
told
it
to
be
provisioned
and
you
can
see.
There's
a
machine
column.
B
So
here
it
off.
Of
course,
now
it's
interprets
the
Machine
got
created
when
we
scale
up
the
Machine
set.
We
can
see
in
the
bare-metal
host
list
that
it's
in
a
provisioning
State
now,
so
this
is
now
getting
provisioned
and
it'll
be
given
the
user
data
it
needs
to
then
initialize
itself
and
join
the
cluster
I'm
going
to
watch
a
few
things.
I'm
gonna
look
at
not
just
the
bare
metal
hosts
and
then
the
nodes
of
the
cluster.
So
we
can
see
when
the
new
worker
joins
I'm.
B
Also
looking
under
the
hood
a
little
bit,
we've
mentioned
before
that
we're
using
ironic
under
the
hood
as
a
provisioning
tool
to
do
the
work
so
I'm,
looking
at
the
state
of
that,
you
can
see
that
that
it's
the
bottom
in
the
first
section
there
at
the
top.
The
bottom
host
is
the
new
worker.
They
were
provisioning.
First,
it's
going
through
this
cleaning
stage.
Cleaning
is
where
we
boot
up
a
ram
disk
and
make
sure
the
disks
are
cleaned.
B
B
B
There's
a
team
from
Ericsson
who's
been
working
really
hard
on
v1
alpha
to
support
and
they
helped
me
get
this
working.
So
thank
you
very
much
to
that
team
for
their
hard
work
on
on
v1
alpha
to
support
and,
of
course,
helping
me
get
this
demo
prepared
so
I'm
going
to
show
provisioning
a
new
cluster.
So
this
is
a
different
environment.
I
showed
we
showed
before
the
sort
of
self
hosting
this
components
and
provisioning
new
nodes
for
like
your
own
cluster,
and
this.
B
This
is
a
slightly
different
approach
where
we're
starting
with
like,
with
mini
with
a
mini
cube
cluster
and
this
mini
coop
lustre,
is
your
management
cluster
and
then
we're
going
to
provision
to
a
to
new
house
to
become
a
new
cluster,
so
we're
gonna
provision
a
new
worker
and
in
master
it
becomes
like
a
new,
a
new
cluster.
So
that's
what
this
this
is
showing
here.
B
So
first
step
just
to
show
what's
running
here,
so
just
to
recap:
what's
running
this
pot
at
the
bot,
this
is
showing
the
pause
in
the
metal
3
namespace,
the
pot
at
the
bottom
metal,
3
bare
metal
operator.
That's
the
clutch
lemare
metal
operator
from
the
little
cube
project
and
an
ironic
runs
within
that
pod
as
well.
There's
also
the
generic
cluster
API
controllers,
the
C
a
PBM
part
is
the
cluster,
a
pre
OTT
cluster
API
provider,
bare
metal
and
then
the
very
top
one
C
APB
pk.
B
That's
the
cluster
API
bootstrap
provider,
cube
ADM
so
and
that
is
going
to
take
care
of
provisioning
the
cluster
after
we,
you
know
after
we
provision
the
host,
it's
gonna
configure
the
cluster
okay.
So
that's
what's
running
I'm
going
to
run
a
few
scripts
here
that
exist
in
our
development
environment
that
you
can
try
out.
If
you
wanted
to
try
this
out
yourself
and
it's
gonna
create
a
cluster
resource
and
it's
gonna
create
the
machine
and
related
resources
needed
to
provision
both
the
control
plane
or
the
master,
and
also
the
the
worker.
B
So
now
that
all
the
necessary
resources
have
been
created,
I'm
going
to
take
a
look
at
some
watch.
Some
resources
so
show
I'm,
showing
here
both
machines
and
bare-metal
hosts,
and
so
there's
there's
the
two
bare
metal
hosts
that
represent
the
master
in
the
worker
and
then
the
two
machines
corresponding
to
that.
B
So
the
way
this
process
is
going
to
go
through
is
its
first
going
to
provision
the
control
plane
or
the
master,
and
it's
gonna
make
sure
that's
fully
up
and
running
before
then
it
provisions
the
the
worker
associated
with
it,
and
so
once
the
master
is
fully
provisioned.
There'll
be
another
section,
I'll
add
to
the
output
here
that
it's
talking
to
the
API
of
a
new
cluster,
getting
created
enlisting
the
nodes
of
this
new
cluster.
So
now
here
the
the
master
is
provisioned,
it's
booting
up
and
now,
once
it's
you
know
up
and
running.
B
B
And
what's
really
cool
about
this?
You
know
an
earlier
iteration
of
of
the
cluster
API,
though
the
work
to
use
cube
ATM
to
configure
this
was
a
little
bit
more
coupled
to
the
infrastructure
provisioning.
What's
cool
about
this
version?
Is
that's
a
better
decoupled,
so
we're
able
to
reuse
this,
this
bootstrap
provider
that
runs
cube
ATM
on
top
of
our
code.
That
just
knows
how
to
provision
bare
metal
hosts.
B
B
You
know
prove
that
we've
got
a
new
cluster
here,
I'm
going
to
show
the
the
pods
running
in
our
management
cluster
and
then
I'm
going
to
connect
to
the
API
the
new
cluster
and
show
the
pod
is
running
there,
and
you
can
see,
of
course,
that
they're
different,
so
the
first
command
here
well,
actually
a
first
time
showing
you
can
get
the
amusing
and
the
a
Liberty
command
to
get
the
DGP
leases
of
our
different
hosts
in
this
development
environment.
So
I
know
how
to
SSH
into
the
master
of
our
new
cluster.
B
But
when
I
read
this
first
cube
CTL
command.
This
is
the
the
management
cluster.
This
is
our
mini
cube
cluster.
You
can
see
that
it
has
the
cube
system
namespace
than
our
metal,
3,
namespace
and
now
I'm,
going
to
run
the
same
command
but
SS
aging
into
the
master
of
our
new
cluster
and
we'll
see
that
it's
got
a
independent
set
of
pods
running
there,
showing
that
we
can
talk
to
an
API
of
a
new
cluster
and
that's
that's
the
end,
the
demo.
B
So
we
have
our
you
know
we,
but
we
started
the
ground
up
how
to
with
how
to
use
a
kubernetes
native
API
to
provision
hosts.
We
layer
on
the
machine
API
or
the
cluster
ap
on
top
of
that
for
managing
kubernetes
clusters
and
we've
integrated
that
an
open
shift,
and
we
also
have
support
for
for
v1
alpha
2
and
that
you
can
go
try
out.
So
thanks
again
to
that
team
for
all
their
great
work,
and
that
is
the
end
of
our
demos.
B
I'm
gonna
demo
ZAR
not
publishing
the
blog
yet,
but
that's
where
they'll
be
after
this.
If
anyone
wants
to
see
them,
there's
on
our
website,
there's
a
blog
and
I'll
get
them
posted
there,
a
little
bit
of
commentary
on
future
work.
So
what's
what's
happening,
of
course,
I've
talked
about
the
v1
alpha
2
and
then
there's
v1
alpha
3
happening,
so
we're
gonna
continue
chasing
that
as
a
community
to
need
to
improve
our
support
for
those
api's.
B
Also,
looking
at
just
continuing
to
improve
our
ability
to
manage
bare-metal
hosts
where
there's
active
work
happening
to
manage
bio
settings
during
deployment
also
active
work
to
do
raid
configurations
so
there's
some
of
the
active
things
going
on,
and
so
with
that
we
can
take
some
questions
and
say
thank
you
for
well
again.
Thank
you
for
coming
to
listen
to
us
today
and,
of
course
thank
you
to
the
to
the
people
that
have
been
contributing
to
our
communities.
So
far,
it's
been
it's
been
a
pleasure.
So
thank
you
very
much.
B
C
B
Great
question,
so
is
there
a
way
to
automatically
register
a
bare
metal
host
instead
of
having
to
create
the
resource?
It's
kind
of
like
what
I'm
saying
it's
on
the
roadmap,
so
I
don't
think.
We've
fully
integrated
that
yet
I
run
ironic.
Your
underlying
versioning
tool
does
have
discovery
capabilities
and
it's
kind
of
been
one
of
those
things
I'm
sure
we
have
a
github
issue
filed
of
like
we
need
to
finish
getting
that
integrated.
B
B
So
are
we
using
it
to
provision
everything
it
can
be
used
that
way?
I
mean
our
use
case.
So
you
know,
I
have
my
upstream
hat
at
my
Red
Hat
hat.
You
know
our
primary.
You
scape
we're
very
focused
on
provisioning
nodes
for
kubernetes
clusters.
Now
the
bare
metal
operator
has
an
underlying
you
know
key
component
or
piece
of
technology.
We
designed
it
with
that
in
mind
like
it
just
knows
how
to
provision
operating
system
images
to
hosts,
and
you
could
use
it
for
you.
B
D
Once
our
once
ironic
has
detected
and
discovered
the
device
when
it's
in
that
ready
state,
is
the
machine
powered
off
and
just
waiting
for
IPMI
boot,
or
is
the
machine
like
sitting
in
a
ram
disk?
So
let's
say
I
have
a
bunch
of
machines
that
are
provisioned
and
I
just
want
to
you
know,
leave
them
in
that
state
can
I
leave
them
off
my
DC
and
then
just
power
them
through
IPMI
when
I'm
needham
yeah.
A
So
by
default
it
stays
in
a
running
state
and
we're
collecting
out-of-band
metrics
so
that
you
can
see
you
know
if
your
unused
nodes
or
overheating
for
some
reason
or
something
like
that
you
there
is
one
of
the
fields
we
didn't
show
in
the
spec-
is
actually
a
power
switch.
So
you
can
turn
it
off
using
the
CRT.
E
B
I
think
the
question
is,
you
know:
we've
got
when
you
provision
an
image
that
image
is
a
particular
version.
What
happens
if
you
like
bump
that
version
that
sort
of
thing
so
in
that
this
is
sort
of
a
layered
system?
If
you
change
that
image
on
the
host,
we're
literally
going
to
reprovision
the
thing
that
may
be
what
you
want
its
profits,
also
likely
not
what
you
want.
You
know
once
you
have
it
provisioned
it.
B
You
probably
want
to
just
do
it
at
you
know
in
software
and
management
of
the
running
host
operate
optic
the
operating
system
so
like
I,
probably
wouldn't
you
know
design
my
workflow
such
that
every
time
I'm
doing
an
OS
updated
you
can.
You
know
reprovision
it
from
scratch
every
time
or
you
could
leave
it
running
and
update
it
and
running
states,
but
it's
sort
of
left
up
to
you.
That's
at
the
bare
metal
operator
level.
B
A
F
Question
about
dependencies
to
sorts
in
follow
up
to
your
answer
to
that
guy's
question
I'm
wondering
now
about
circular
dependencies.
This
thing
is
running
on
a
cluster
in
managing
the
cluster.
That
I
mean
that
sounds
kind
of
circular
I'll.
Also
you
mentioned
you're
using
ironic
how
much
of
the
rest
of
OpenStack
is
dragged
in
with
ironic.
B
B
It's
we've
sort
of
we've
minimized
it
and
and
we've
even
we
even
have
ironic
running
in
a
special
way
that,
like
it
like
it's,
not
using
RabbitMQ,
for
example,
you're
really
familiar
with
the
architecture,
so
we've
got
it
like
running
in
a
very
specialized
mode,
just
for
this
and
we're
not
plug
in
any
other
dependencies
and
the
fact
that
we're
running
it
out
of
the
hood,
these
api's
are
not
exposed
outside
of
the
outside
of
the
pod
at
all.
It
gives
us
some
flexibility
on
how
we
managed
it.
So
that's
the
second
question.
B
The
first
one
hey
it
seems
circular
we've
got
a
cluster
managing
itself.
How
do
you
get
into
that
state?
Yes,
the
way
you
do
that
is
you,
like
you,
do
have
to
start
with
something
else.
You
have
to
get
the
cluster
up
and
running,
and
then
you
can
then
move
the
components
into
the
cluster
the
way
so
within
that
last
MOV,
one
alpha,
that's
not
actually
self-hosting
it
right,
you
that
showed
a
management
cluster
that
provisioned
it
like
an
open
shift.
B
We
threw
things
a
little
differently
where
we
have
an
installer
that
runs
a
process
to
get
the
cluster
up
and
running
just
enough,
and
then
we
move
the
components
into
the
cluster.
So
you
you
get
just
enough
running
and
then
it
then
it
moves
into
the
cluster.
If
that
makes
sense,
there's
sort
of
a
bootstrapping
process
that
gets
you
there.
So
it's
not
I
mean
it's
not
magic.
It's
just.
You
know
it's
sort
of
a
boot,
a
bootstrapping
process
that
gets
you
up
to
a
running
cluster
with
the
components
running
inside
of
it.
A
So
what
happens
if
the
provisioning
fails
for
some
reason
related
to
the
host
or
something
like
that,
the
the
operator
will
keep
retrying
to
provision.
Eventually,
the
host
will
go
into
an
error
state
that
just
reflects
that
it's
failed
to
work,
and
so
the
actuator
may
choose
a
different
host
if
you've
got
multiple
hosts
available
in
your
inventory,
if
you're
using
that
low-level
API
directly,
then
whatever
tool
you're
using
to
watch
that
resource,
the
host
resource
should
be
watching
that
status.
To
see
that
it's
got
that
error
state.
B
There
a
cloud
provider
for
ironic,
so
we
haven't
needed
to
write
a
cloud
provider
yet
we've
gotten
by
without
having
to
write
one,
and
if
I
mean
it's,
we've
talked
about
it
a
couple
of
times,
but
it
hasn't
hasn't
been
necessary
and
if
we
did,
it
wouldn't
be
an
ironic
one,
so
kind
of
as
much
as
we're
thankful
to
have
ironic,
because
it
helped
us
get
going
so
fast.
With
this,
with
this
project,
ironic
is
intentionally
hidden
like
we.
B
You
know
it
wouldn't
be
an
ironic
cloud
provider,
it'd
be
a
metal
cubed
one
and
you
know
it
wouldn't
have
any
knowledge
that
ideally,
like
architectural
goals,
is
there's
no
knowledge.
That
ironic
is
here
outside
of
the
well
the
internals
of
how
we've
implemented
it
so
it'd
be
like
a
metal,
cubed
cloud
provider.
Potentially
that
does
some
very
specific
things,
but
we
haven't
written
one.
Yet.
A
Yes,
so
I
think
that's
the
work
that
you
were
showing
with
the
newer
version
of
the
cluster
API
so
for
the
v1
version,
v1
alpha
one
version
that
we
supported.
Initially,
we
don't
do
any
of
the
pivoting.
It's
just
the
self-hosted,
bringing
a
node
into
the
current
cluster
thing,
but
in
the
the
2v1
alpha
to
work
that
the
Ericsson
folks
have
been
doing,
then
they
are
able
to
provision
a
separate
cluster
and
pivot
into
that
cluster.
Yeah.
All.