►
From YouTube: Crowbar v2.1 Install
Description
Video 2 in series
Install Crowbar and review UI options
A
Hello
and
welcome
to
the
second
installment
in
the
open,
crowbar
video
sequence.
Today
we
are
going
to
be
showing
the
admin
booting
the
admin
server
process.
So
we
have
a
previous
video
where
we've
set
up
the
environment.
We
focused
on
windows
I'm
using
in
a
bun
to
12
04
system.
This
time,
keep
things
up.
Show
you
a
little
bit
about
how
the
different
environments
go.
The
basics
that
we're
showing
this
video,
our
independent
of
that,
but
we'll
walk
through
the
actual
bootstrapping
process
and
what's
going
on
with
this,
so
fundamentally,
we've
already
shown
the
screen.
A
I'll
walk
you
through
the
UI
in
a
moment
as
we
boot
things,
but
this
is
a
crowbar
infrastructure
that
has
the
admin
node
provision,
so
the
system's
overview
breaks
down
all
the
roles
and
functional
divisions,
the
open
crowbar
one
mostly
brings
up
core
and
networking
infrastructure
we'll
see
how
that
changes
as
we
bring
up
some
other
nodes.
So
let
me
do
that
without
any
further
ado.
This
is
micro
of
our
admin
system
right
here.
I
have
a
session
into
it.
I'm
actually
running
this
one
in
a
docker
container,
which
is
very
fast
and
convenient.
A
A
We
have
a
small
script,
makes
things
pretty
easy
that
sets
up
a
kvm
slave,
so
I
checked
out
the
code,
I'm
using
one
of
our
kbm
slave
tools.
You
can
also
set
up
your
own
virtual
machines
using
VirtualBox
VMware.
It
really
doesn't
matter
as
long
as
you
set
up
the
appropriate
network
connections.
In
this
case,
these
slaves
are
going
to
be
connected
into
the
system,
I'm
going
to
go
ahead
and
start
three
of
them
all
running
in
background
windows
here
and
in
this
case
they're,
starting
with
an
empty
disk.
A
So
we
just
basically
build
a
vm
shell.
We
boot
the
machines,
the
pixi
boot,
crowbar
downloads
of
discovery
image.
This
is
part
of
the
normal
provisioning
process
for
us
there's
a
lot
of
different
ways
for
crowbar
to
learn
about
nodes.
The
default
one
here
is
to
use
DHCP
and
pixie
go
and
load
a
discovery
image
which
is
doing
right
now,
based
on
centos.
A
We
call
that
image
sledgehammer
and
we
use
that
as
our
pre
execution
environment,
sometimes
I'll
call
that
sideband
control,
the
OS
hasn't
been
provisioned
yet,
and
so
we
have
an
environment
where
we
can
access
all
the
hardware
infrastructure.
Do
some
inventory
and
discovery
do
management
and
controls?
The
system
will
persist
in
this
state
until
we
decide
it's
time
to
move
on
to
the
next
step,
so
you
can
actually
take
advantage
of
sledgehammer
as
an
operating
environment.
We
put
the
keys
in.
A
We
attach
it
to
the
correct
networks
and
use
that
as
a
burnin
environment,
one
of
the
things
rack
and
has
done-
and
extending
up
and
crowbars
added
burnin
steps
into
the
sequence.
So
you
can
run
custom
vernon
tests
make
sure
your
gear
is
up
to
date.
So
it's
going
to
go
through
and
boot.
I
launched
three
of
these,
so
we'll
actually
have
three
different
systems
going
up
and
booting
minimizing
them,
so
they're
very
tiny,
little
kvm
instances,
oops.
A
Expand
one
out
there
you
go
it's
nice
to
keep
these
around
it'll
bill
disappear
as
soon
as
there
as
soon
as
I
got
four
reboot
once
they've
been
discovered,
you'll
see
them
get
added
into
this
screen.
You
also
see
we
track
a
number
of
node
roles
and
process
in
the
top
right
corner
of
the
screen,
so
we
can
watch
in
the
background
as
things
progress
bring
this
over
here,
so
I
can
watch
it
out
of
the
corner
of
our
respective
eyes.
A
So
this
is
the
key
screen
for
crowbar.
This
is
our
system
deployment
screen.
You
can
create
sub
deployments.
We'll
show
you
how
to
do
that
as
we
go
into
the
next
steps
in
our
progression.
That's
about
building
ready
state
in
the
next
video
and
each
one
of
these
know
what
we
call
no
trolls.
These
green
checks
represents
a
concrete
service
within
the
infrastructure.
Some
of
them
are
what
we
would
call
milestone
rolls,
so
they
don't
represent
an
actual
install.
A
They
represent
a
chain
of
things
leading
up
to
it
and
so
there's
a
dependency
graph,
that's
being
built
to
make
this
work,
and
in
doing
that,
we
know
how
things
are
related
and
how
they
have
to
be
installed
and
brought
together.
Now.
This
will
be
more
interesting
when
the
other
machines
come
in,
but
to
bring
up
a
crowbar
environment,
we
actually
have
to
bring
up
or
attached
to
a
full
operating
infrastructure.
So
we
need
to
bring
in
chef,
DNS
servers,
console
service
for
service
discovery
and
registration,
dns,
a
dns
server
and
TP
logging
DCP.
A
All
of
these
components
are
necessary
to
run
a
data
center
crowbar
has
to
install
them
in
order
to
get
running,
we're
actually
making
some
changes
in
this
coming
release
to
turn
these
into
services
and
leverage
existing
provisioning
tools,
dhcp
dns,
in
addition
to
or
instead
of
the
ones
that
we've
built
inherently
into
crowbar.
So
a
lot
of
new
flexibility
coming
in
in
this
next
release.
Today,
our
expectation
is
that
you
have,
you
can
run
a
DHCP
server
if
you
contact
rack
and
we
can
help
you
use
existing
DHCP
infrastructure,
existing
cobbler
infrastructure.
A
Those
are
definitely
possible,
and
in
this
case
you
can
see
those
the
servers
have
come
up.
They've
been
there
being
discovered.
The
first
thing
that
crowbar
is
doing
is
it's
making
dns
entries
so
we're
aware
of
these
servers.
We
have
to
create
DNS
records
for
them.
Then
we
have
to
create
DCP
boot
records
for
them.
So
we
have
provisioning
control.
They'll,
tell
us
what
we're
going
to
boot,
the
next
time
it
boots.
A
So
all
those
changes
come
through
and
you'll
notice
that
crowbar
is
literally
going
through
and
making
operational
changes
to
get
these
systems
ready
to
work
and
then
it'll
go
in
and
it
will
start
doing
the
provisioning
against
it.
So
it's
installed
the
chef
client,
it's
going
to
build
the
admin
network
and
literally
attached
these
newly
discovered
nodes
into
the
operations
fabric
of
the
system.
A
What's
going
on
behind
the
scenes,
is
we've
built
up
a
list
of
work
and
we're
very
excited
about
how
we
do
this?
We
call
the
kneeling.
It's
part
of
having
a
very
flexible
graph
system
is
able
to
accommodate
changes
and
and
interconnections
within
a
physical
environment.
It's
really
a
graph
system
designed
for
physical
infrastructure,
so
what's
happening
is
we
have
a
couple
of
things
that
are
operating?
These
can
operate
in
parallel
and
then
each
one
you
can
see,
there's
additional
actions
that
are
blocked.
A
A
It's
designed
with
our
principle
of
late
binding,
where
each
one
of
these
steps
can
be
added
into
the
environment
and
notes
can
be
very
dynamic
and
shifting
is,
as
you
add
things
to
them,
you
don't
have
to
decide
up
front
how
to
resolve
this
graph.
It's
literally
resolved
dynamically
as
part
of
our
operational
philosophy
for
how
this
operates.
We've
built
some
networks
and
then
we've
identified
a
whole
bunch
of
attributes.
A
So
we
track
a
huge
amount
of
data
part
of
the
functional
operations
paradigm
that
we
follow
where
we
separate
each
node
roll
into
a
very
defined
unit
of
work.
That
means
we
have
to
pass
information
in
and
out.
That's
what
attributes
do
for
this,
and
so
you
can
expose
attributes
both
for
needing
them
and
for
taking
them,
and
then
we
have
some
where
you
can
expose
them
in
the
api's
so
that
you
have
additional
capabilities
along
those
lines.
A
A
And
so,
if
you
go
through
the
system,
we
have
a
nodes
view
where
we
share
the
nodes.
There
they've
all
completed
one
of
the
things.
That's
really
interesting
for
crowbars
that
we
don't
consider
nodes
having
a
discrete
state.
The
state
is
actually
all
of
the
actions
that
are
pending
and
completed
so
when
nodes
are
in
transition,
then
they'll
be
shown
as
as
being
in
this
intermediate
state
in
the
interest
of
time.
A
What
I
want
to
do
is
I
want
to
point
out
a
couple
of
things
and
then
kick
us
into
the
next
phase
of
the
deployment.
So
you'll
see
these
nodes,
don't
need
all
the
roles
and
they
actually
have
their
own
roles.
So
they
have
a
login
client
that
attaches
to
the
logging
server.
So
these
things
are
all
pre
baked
into
each
other.
A
You'll
see
the
clients
are
coming
in
as
we
get
the
new
pieces
and
parts
in
here
and
then
node
discovered,
is
its
own
distinct
milestone
and
so
that
that
becomes
the
part
here
and
they're,
not
admins.
So
there's
there's
a
fair
bit
of
granularity
and
how
the
graph
is
resolved,
but
you
wouldn't
deploy
an
application
in
the
system
graph
where
we're
dealing
with
operations
tools.
What
you
would
want
to
do
is
use
the
ready
state
wizard,
the
ready
state
wizard,
isn't
anything
fancy
it
just
pulls
together,
discreet
provisioning
steps
into
a
single
unit.
A
In
this
case,
what
it
will
do
is
it'll
build
us,
a
deployment
that
will
call
pilot.
In
this
case
it
will
say
that
for
that
pilot
deployment
we
want
to
use
the
second
Nick.
Second,
one
gig
Nick,
so
1g
one
gig
one
is
the
second
interface
and
it'll
find
that
in
an
abstract
way,
there's
a
lot
of
things.
A
We
can
do
with
this
nomenclature,
let's
beyond
the
scope
of
the
video,
but
it
allows
you
to
abstract
out
networking
so
that
you
can
have
the
same
networking
applied,
no
matter
if
you're,
using
VMs
or
hardware
or
even
docker
containers
to
an
extent.
So
abstracted
network
has
been
very
important
from
a
functional
operations
perspective
so
that
your
scripts
will
run
in
every
environment.
We
give
it
a
range
for
that.
Network
crowbar
automatically
adds
ipv6
I'll,
show
you
some
of
how
that
works.
A
Our
core
default
is,
is
ipv6
and
we
use
IP,
be
four,
is
overlay,
and
then
we
have
the
option
to
bring
up
notes.
So
these
are
the
discovered
notes.
They've
been
inventoried,
so
you
can
see
some
information
about
them
and
then
I
can
pick
operating
systems
and
to
make
things
more
colorful,
I'm
going
to
pick
different
operating
systems
for
each
one,
I'll
run
the
wizard.
The
wizard
is
just
building
network.
A
The
deployment
putting
the
nodes
in
the
deployment
I
could
go
in
I'm
in
the
proposed
state
right
now,
so
it
haven't
taken
any
action
and
I
could
change
the
operating
system
if
I
wanted
and
then
OS
installed
is
a
milestone.
So
it's
not.
Actually
it
doesn't
do
anything.
It
just
rolls
up
other
things
if
I
wanted
and
it's
we've
added
a
pilot
network,
if
I
was
going
to
install
pack
stack,
I
can
do
that
here
and
add
that
into
the
infrastructure.
I'll
go
ahead
and
do
that
for
illustration.
A
A
We
don't
see
these
as
provisioning
operations
so
much
as
a
sort
of
upgrade
or
continuous
stabilization.
So
we've
told
the
system
you
have
to
make
some
changes.
You'll
see
it's
really
interesting.
It
goes
in
and
adds
the
pilot
network
pilot
networks
part
of
these
nodes.
Now
it
actually
added
it
to
sledgehammer,
even
though
it's
just
about
the
terror
sledgehammer
down-
and
you
can
use
effects
like
this
to
be
able
to
do
work
in
sledgehammer.
It's
part
of
our
graph
resolution
so
that
you
can
do
burn
in
or
testing
or
some
network
discovery
configuration.
A
If
you
would,
if
I've
added
the
rate
and
BIOS
configuration,
those
could
take
action
inside
sledgehammer
and
do
certain
types
of
activities
system
just
went
down.
That
means
it's
rebooting,
we're
back
in
the
system
deployment
where
we're
going
to
show
how
changes
are
coming
in
and
here's
one
of
the
nodes
being
rebooted,
another
node
being
rebooted-
and
here
is
the
third
node
being
rebooted
and
what's
happened
is
for
each
one
of
these
nodes.
A
We
have
set
the
next
OS
to
boot.
We've
told
it
what
pilot
it's
in
and
it's
going
through
the
process
and
you'll
see
here.
I
have
reboot,
since
their
virtual
machines
and
I
know
that
the
only
action
I
have
is
reboot.
If
I
had
physical
hardware
like
I'll
show
another
video,
I
would
expose
additional
operations
based
on
what
the
hardware
was
capable
of
so
reboot
power
lights,
identifications
things
like
that.
A
The
other
things
to
show
in
here
there's
a
bulk
edit,
where
you
can
set
a
whole
bunch
of
things
at
a
time.
Change
the
aliases
and
names
and
deployments
networks
show
the
networks
that
we've
created.
So
in
this
case
we
have.
The
administrative
network.
Is
the
one
that's
built
by
default?
We
have
a
special
BMC
network
that
is
for
the
out-of-band
management
you
can
see.
A
All
of
my
different
os's
are
installing
so
I
have
my
sent
sent
us
network
I
have
a
bunt
too,
and
I
have
sent
seven
six,
five
pontoons
and
since
seven
and
then
I
have
my
pilot
network,
this
is
the
one
we
just
built.
I
could
add
others
and
make
them
part
of
the
dependency.
So
when
you
have
a
deployment,
you
can
inject
a
network.
A
That
network
becomes
part
of
your
install
dependencies
and
you
could
set
it
as
a
prereq
so
and
install
would
fail
if
it
didn't
have
the
right
network
setup,
one
of
things
that
we've
done.
This
really
important
is
if,
if
anyone
action
has
a
problem,
let
me
show
you
this
so,
for
example,
my
admin
network
here
this
is
the
admin
network.
I
can
see
all
the
allocations
and
the
data,
and
then
we
have
very
concrete
logging.
So,
as
these
actions
happen,
we
track
the
logging.
So
you
can
see
exactly
what
was
done
each
step.
A
A
We
also
have
additional
views
that
help
you
resolve,
which
IP
addresses
have
been
assigned
to
which
networks
and
which
networks
are
all
much
nodes.
None
of
these
are
physical,
so
there's
no
BMC,
and
then
this
allows
you
to
deal
with
the
fact
that
different
systems
and
numerate
Nick's
in
different
ways.
So
it's
very
important
that
if
you
have
a
system,
you
want
to
be
able
to
identify
Nick,
enumeration
and
normalize
that-
and
this
is
processed
by
which
we
normalize
Nick
enumeration,
so
that
you
can
consistently
have
your
environment
specific
to
you.
A
A
This
is
a
new
install
by
the
way
I
slipped
one
in
between
my
paws.
After
networking,
you
can
take
a
look
at
all
the
roles.
It's
important
when
you
look
at
roles
to
understand
that
each
roll
is
implemented
by
a
different
jig.
Jig
is
our
abstraction
interface,
so
when
each
roll
is
executed
can
be
done
by
a
different
implementation
mechanism.
That's
in
cases
that's
a
script,
so
that's
actually
a
bash
shell
action,
no
op
is
does
nothing.
Is
we
use
that
for
checkpoints
and
milestones
and
something
very
important
part
of
the
orchestration
system?
A
So
you
can
have
other
roles
that
depend
on
a
milestone
and
then
basically
create
a
series
of
gates
for
your
deployment,
then
extend
the
orchestration
around
those
gate.
Points
ends
up
being
a
critical
architectural
design
component.
We
didn't
realize
how
important
it
would
be
until
after
we
put
it
in
test.
Jigs
are
used
for
our
offline
tests,
so
we
can
test
without
having
to
deploy
physical
infrastructure
chef
solo
as
an
older
jig.
We
used
to
use
it
before
we
switch
to
using
chef
server,
so
it's
basically
runs
without
the
chef
server
being
required.
A
It
is
functionally
equivalent
to
the
chef
jig,
except
that
you
can't
use
encrypted
data
bags.
You
could
pop
a
standalone,
very
similar
concept
if
you
have
puppet
modules
that
you
want
to
execute
role
provided.
Jig
is
a
new
concept
that
we're
using
for
some
of
the
burn-in
and
valid
system,
validation
and
then
a
lot
of
the
core
work.
We
have
a
chef
because
that's
historically
what
we've
used
a
crowbar,
so
we
were
able
to
reuse
significant
amounts
of
code
from
crowbar
one
by
reusing
the
chef
jayke.
A
A
System
overview
the
annealer:
when
the
system
is
operating,
it's
going
to
show
you
what
work
is
in
different
states,
convenient
way
to
track.
It's
happening
with
the
system
system
overview
here
is
designed
to
help
sort
of
see
the
system
at
the
high
level.
It's
really
useful
when
there
are
a
lot
of
notes
and
in
and
what
it
does
is
I'll
show
you
what
type
of
work
is
going
on
in
from
the
system
in
a
functional
sort
of
way,
so
you
can
see
operating
systems
being
deployed
knows
being
brought
up.
A
I
call
this
the
CIO
view
it's
useful
to
sort
of
see
how
busy
your
infrastructure
is,
and
then
under
utilities
we
have
a
series
of
things.
Bootstrapping
is
used.
If
you
don't
provide
the
defaults,
you
can
use
the
bootstrapping
screen
to
populate
all
the
critical
data.
If
you
were
using
our
production
on
SH
script,
exported
items
is
used
to
retrieve
log
files.
Install
jigs
will
show
you
all
the
different
jigs
that
are
in
operation,
there's
quite
a
number
of
them
for
roles.
The
test
one's
not
activated.
A
If
you
ran
a
development
about
a
lot
of
these
jigs
wouldn't
be
installed.
Bar
clamps
are
legacy
concept
from
gerber
one
really
there
they're
groupings
of
roles,
then
that
those
are
then
bundled
into
workloads.
It
used
to
be
that
you
had
to
have
a
github
repo
for
every
bar
clamp.
We
did
away
with
that
and
so
something
like
OpenStack,
which
in
crowbar
one
would
have
10
or
15
different
bar
clamp
and
github
repos.
A
Those
would
still
be
bar
clamps,
but
they
would
be
managed
as
a
single
workload,
and
then
we
have
some
user
management,
so
there
is
password
and
user
identities
with
admin
and
non
admin
credentials
and
if
you're
going
to
do
API
work,
you
have
to
these
have
to
be
set
as
API
enabled
that's.
What
the
machine
install
and
clip
are
both
operate
as
API
enabled
users
and
there's
also
a
user
setting.
A
If
you
were
going
into
the
github,
you
actually
should
be
able
to
jump
edit.
The
page
on
github
takes
you
right
to
the
get
out
page,
and
this
has
been
really
important
for
us,
because
it
allows
people
to
maintain
and
retrieve
the
latest
documentation.
Even
if
thirds
dollars,
we've
been
talking
about
removing
a
whole
component
and
just
using
online
documentation
more
detail
than
you
probably
wanted,
but
that's
a
complete
tour
of
the
UI
so
that
you
can
see
how
things
operate
and
hopefully
get
a
better
sense.