►
From YouTube: OpenCrowbar Dev Environment Setup ROUGH CUT
Description
Walk through of OpenCrowbar development environment using Admin node running on Docker and booting VMs. Shows off new features of OpenCrowbar environment.
A
Hello
and
welcome
to
this
introduction
to
open
crowbar
from
the
building
and
admin
for
development
and
test
perspective,
I'm
Rob
hirschfeld
I'm,
going
to
give
you
a
quick
tour.
This
video
is
useful
to
actually
go
through
the
process
of
setting
up
an
open,
crowbar
admin
server
on
your
laptop
or
in
a
lab
using
the
docker
configuration,
and
so
what
we
have
here.
This
is
just
open.
A
Crowbars
github
has
a
friendly,
read
me
page:
we've
been
working
really
hard
on
improving
the
documentation
and
throughout
this
I'm,
going
to
help
highlight
some
of
the
places
where
up
in
crowbar
is
really
different
than
crowbar
one,
and
some
of
the
things
that
we
want
you
to
pay
attention
to
it,
understanding
how
things
work
and
then
there's
a
second
video
where
I'll
really
go
through
the
operation
and
give
you
a
tour
of
open,
crowbar
itself
from
the
UI
perspective.
The
thing
that
I'm
focused
on
right
now
is
building
and
using
our
development
environment.
A
A
I've
got
I've
docker
doctor
installed,
give
you
my
version
right
now,
I'm
running
on
the
nine
dot
one
and
there's
some
specific
configuration
things
that
we
recommend.
As
far
as
how
dr.
is
configured
and
you
can
go
through
that
and
what
we've
done
is
we've
actually
built
a
docker
image
that
has
a
lot
of
the
prerequisites
installed
for
crowbar,
and
so
that
makes
it
very
fast
and
easy
to
get
things
running.
A
I
have
the
crow
bar
code
checked
out
right
now,
I'm
doing
this
all
using
our
github
clone
code,
but
we
actually
have
rpms
and
their
RPM
instructions
that
you
can
follow
to
work
through
these.
If
you
don't
want
to
do
your
own
build
or
work
from
the
codebase,
both
perfectly
adequate
code
base
is
going
to
make
it
a
little
bit
easier,
stay
up
to
date
and
the
way
the
docker
and
then
works.
I'm
going
to
start
that
process.
So
I
can
show
you
is
we
have
a
set
of
tools,
something
called
docker
admin.
A
A
The
actual
environment
that
I
want
to
run
is
production,
so
I'm
going
to
run
the
production
script
and
I
have
for
that.
I
have
to
tell
it
the
name
of
my
admin
server
and
what
we've
done
with
docker
here
is:
we've
created
a
pristine
prepped
krub,
our
environment,
which
includes
post
grass
and
Ruby
two
rails
gems,
and
things
like
that
that
the
normal
install
just
walk
you
through
installing,
but
since
they're
prepped
and
dr.
A
I
don't
have
to
redo
it,
but
we
didn't
install
crowbar
in
the
container,
we're
actually
doing
a
full,
clean,
crowbar
install
here,
and
that
means
every
time.
I
run
this
command.
If
I
stop
the
container
I
wipe
out
everything,
I've
done
my
database,
everything
and
if
I
restart
it,
it's
going
to
walk
through
the
full
install.
We
use
chef
so
loaded,
the
install
so
there's
actually
a
bootstrapping
script
in
the
code
base
under
bootstrap,
and
this
actually
has
the
cookbooks
that
we
use
to
install
crowbar.
A
Soaker
bar
has
its
own
installation,
unlike
the
past,
where
we
actually
had
actually
did
full,
effective
and
no
deployment.
You
don't
have
to
do
that
anymore.
When
you
do
the
admin
note,
it
brings
itself
up,
it
brings
up
the
web
server,
but
it
doesn't
have
to
go
through
the
full
installation
process
that
allows
you
to
set
the
admin
network
and
make
configuration
changes
before
any
deployment
is
actually
done
if
you
want
to
by
using
the
production
script
I,
which
is
in
the
grove,
our
core
library
down
here.
A
Here's
the
production
script
that
goes
through
and
it'll
do
the
install
bootstrap
and
then
it
calls
the
API
to
set
up
and
register
some
critical
values.
So
it
really
is
designed
to
help
get
you
moving
quickly,
it's
very
similar
to
what
crowbar
one
would
do
if
you
use
the
full
production
script
so
where
it
creates
a
default
Network.
It
attaches
the
admin
node
to
itself
and
it
begins.
A
The
annealing
process
will
talk
about
the
annealing
process
in
some
detail
so
that
you
understand
what's
going
on
in
this
case,
we're
just
literally
going
through
and
building
everything
up.
You
can
see.
We've
actually
built
the
database
right
here.
That's
what
all
those
migrations
are
for
and
now
once
things
are
stable,
I'm
going
to
kick
off
the
background
threads.
One
of
the
major
differences
with
crowbar
open
crowbar
is
that
it
actually
is
a
multi-threaded
system.
It
has
background
workers
by
default
10
that
do
the
work
of
do
of
all
the
orchestration
and
configuration.
A
So
first
we
bring
up
a
web
server
and
then
we
bring
up
the
10
workers
that
perform
the
actions.
It's
one
of
the
places
that
we're
really
very
different
between
crowbar
one
and
open,
crowbar
and
I'll
pause
and
explain.
Crowbar
too,
we
change
the
name
to
be
open
crowbar.
It
was
part
of
our
process
of
bringing
the
system
together.
We
got
a
lot
of
feedback
that
crowbar
repos
were
very
hard
to
understand.
They
needed
special,
tooling,
it's
very
hard
to
use,
get
with
them.
A
It
was
hard
to
find
things,
and
so
we
really
worked
hard
to
bring
all
those
things
together.
Rpm
builds
a
much
simpler,
get
commit
process
codes,
all
in
one
place
and
one
get
repo.
We
did
keep
all
the
history
and
the
functionality
for
crowbar
to
was
ported
over,
but
we
really
felt
like
it
was
important
to
start
in
a
new
repo
so
that
we
could
simplify
and
streamline
and
get
all
the
docs
straight
and
not
have
that
confusing
and
crowbar.
One
is
still
under
active
development.
A
Seuss
is
doing
a
lot
of
great
work
around
OpenStack
development
on
top
of
crowbar
one,
and
so
it
actually
gets
a
little
confusing
to
have
two
active
code
streams
in
the
same
rebound
so
I
hope.
That
explains
why
we
are.
We
chose
to
make
that
split.
It's
it's
been
a
really
positive
thing.
We
feel,
like
the
the
code
changes
in
consolidation
that
we've
put
together.
We've
wanted
to
do
for
a
long
time.
At
this
point,
the
websites
actually
running
and
I
can
come
back
over
and.
A
Run
open
crowbar
what
you'll
see
this
is
a
system
overview
screen
shows
the
system
coming
up.
The
real
action
here
is:
this:
is
the
work
queue,
so
this
is
the
annealer
which
I'll
explain
a
little
bit
here
and
a
lot
more
in
the
next
demo
when
we
bring
up
some
additional
nodes.
The
idea
here
is
that
this
is
the
work
that
has
to
be
done
by
the
system,
and
you
can
see
very
specifically
what's
going
on.
This
is
the
queue
type
view.
If
you
look
at
the
system,
deployment.
A
This
is
this
will
show
you
the
actions
that
are
going
on
in
the
system,
so
the
way
crowbar
works
is
that
we
break
all
of
the
activities
into
specific
roles.
If
you
used
to
chef,
these
are
chef
roles
effectively,
although
there's
a
lot
more
roles
in
the
system
than
just
chef
roles,
because
this
is
how
we
control
and
orchestrate
what's
going
on.
A
So
let
me
show
you
a
couple
things
that
are
happening
in
the
process,
so
this
is
my
docker
container,
so
right
now,
I'm
inside
of
the
container
I
could
control
C
out
of
this
actually
I'll
do
that
it'll
stay
in
here
until
all
of
the
check,
recheck
boxes
are
done
once
you've
hit
this.
This
converge
step,
it's
perfectly
safe
to
interrupt
it,
and
now
I
can
access
the
crowbar,
CLI
and
start
taking
action.
So
this
is
one
of
the
nice
things
about
working
inside
the
container.
A
We
have
the
CLI
all
wired
in
and
you
can
take
considerable
number
actions
on
the
system
right
through
the
CLI,
so
you
don't
have
to
rely
on
the
UI
if
something
you're
looking
for
is
there
if
you
want
to
automate
or
or
take
some
extra
steps.
Of
course,
the
CLI
is
actually
just
a
wrapper
for
the
API,
and
you
could
of
course
hit
things
using
the
API
also
so
now
that
I'm
here,
if
I
wanted
to
work
inside
of
this
container,
I
can
look
at
my
logs
so
that
we
put
the
logs
in
the
place.
A
A
So
you
can
go
and
dump
the
debug
and
troubleshoot
here,
although
this
isn't
necessarily
the
place
you
were
going
to
be
most
interested
in
troubleshooting,
especially
if
you're
used
to
curve
r1.
What
you'll
see
is
that
for
every
action
that
we
take,
we
get
very
specific
logs,
so
for
every
node
role,
every
node
rolls
very
atomic
independent
action,
those
actions
we
capture
the
logs
for
them.
We
don't
run
chef
for
these
actions.
We
actually
run
chef
solo
so
we'll
attach
to
the
system
preload
all
the
data,
so
we
use
attribute
injection.
A
A
Working
with
this
attribute
injection
pattern,
we're
very
excited
to
be
able
to
basically
pass
specific
data
stage
to
stage
the
stage,
and
that
means
that
not
only
can
you
have
very
finite
control
of
how
the
chef
cookbooks
interact,
but
you
can
actually
mix
and
match
so
we're
bringing
in
things
like
puppet.
Alongside
of
chef,
so
you
can
use
them
some,
you
can
use
them
in
parallel
or
SSH
or
add
and
extend
your
own
system.
A
A
A
A
Jump
over
to
the
top
level,
the
github,
so
one
of
the
things
that
we've
done
is
instead
of
having
all
the
bar
clamps
we're
really
trying
to
focus
much
more
on
workloads
in
version
so
crowbar
core
itself.
This
is
all
the
core
and
you'll
notice
in
here.
We
still
have
the
concept
of
individual
bar
clamps,
but
they're
they're,
all
governed
together,
so
that
you
don't
have
a
spread
of
bunch
of
pieces
and
same
is
true
OpenStack
staff
hardware
do
these!
A
These
different
workloads
are
actually
versioned
as
their
own
thing,
and
so
they
are
maintained
in
their
own
repos,
rather
than
having
six
million
individual
bar
clamps.
Where
we
split
everything
out,
we
want
to
have
things
more
consolidated,
so
you
could
track
things
in
a
more
logical
way.
We've
been
adding
the
concept
of
Berk
shelf
and
bourke
shelf
pointers
for
some
of
these
cookbooks.
So
this
is
actually
possible
to
take,
say
the
OpenStack
cookbook,
the
OpenStack
workload
and
then
pull
in
the
direct
upstream
cookbooks
from
OpenStack,
and
that
that's
really
been
an
important
point
for
us.
A
We
don't
want
crowbar
to
have
its
own
cookbooks.
We
want
to
be
able
to
fully
leverage
the
community
once
that's
partly
why
we
adopted
the
the
attribute
injection
pattern,
so
over
here
I'm
using
opens
to
open
cravat
core.
If
I
look
in
this,
one
of
the
benefits
of
the
docker
containers
is
that
we've
actually
crossed
mapped
the
code
here
directly
into
my
code
working
environment,
so
this
is
outside
of
the
container.
This
is
where
I've
cloned
out
out
the
code.
A
So
if
I
do
get
status
here,
you'll
see
I've
got
my
code
playing
around
a
little
bit
by
adding
these
files.
Let
me
remove
of
them
and
I
will
recreate,
and
this
will
hopefully
make
some
sense
so
right
now,
if
I
do
this,
if
I
look
at
the
list
there
and
lists
here,
they're
going
to
be
the
same,
and
if
I'm
touch
food
text,
you
can
see
I'm
repeating
my
demo
over
here.
You'll
see
food
text
is
included
so
I'm
able
to
transfer
files
back
and
forth
between
the
container
and
my
machine.
A
That's
not
normal
container
docker
behavior
it
part
of
our
tooling.
When
we
set
up
the
admin
server
is
to
map
the
present
working
directory
or
current
working
directory
into
open
crib
our
core,
and
what
that
allows
you
to
do
is
I
can
come
back
and
I've
checked
out,
SEF
here
and
so
that'll.
That
means
that
crowbars
going
to
also
discover
SEF,
let's
say
so.
You
should,
when
I
look
at
the
bar
clamps
I.
A
See
the
SEF
bar
clamp,
so
it's
a
really
important
point
and
how
this
works.
If
you
have
checked
out
things
as
siblings
to
the
crowbar
core,
so
I
could
bring
in
OpenStack,
which
is
still
in
development
SEF.
It's
actually
won
our
first
workload
and
we've
made
a
lot
of
progress
with
SEF
when
I
bring
those
things
in
as
siblings
to
core
they're
automatically
mapped
in
and
discovered
as
additional
work
loads
for
crowbar.
So
it's
stuff
is
actually
installed
in
this
in
this
demo
environment.
A
A
A
A
Literally,
all
you
have
to
do,
for,
if
you
want
to
make
a
change,
is
go
into
the
role
that
you
want
it
and
you
could
retry
that
role
and
then
the
system
is
going
to
catch,
that
there's
a
change
and
it
will
reapply
that
and
very
importantly,
it
is
aware
of
the
dependency
graph
and
then
it
automatically
reapplies
all
of
the
downstream
dependencies.
Because
if
you
made
a
change,
the
downstream
dependencies
are
going
to
be
impacted.
It's
a
really
significant
action
here.
A
So
some
of
the
other
things
that
you
you
want
to
be
aware
of
with
the
docker
container,
so
I
just
did
a
PS.
So
this
is
the
container
that
I
running
it
is
possible
to
snapshot
this
container
and
keep
it
running
in
the
background
and
thereby
have
a
persistent
admin
note.
We
don't
normally
do
that.
The
goal
here
is
to
just
have
make
it
very
easy
to
bring
one
up
test.
It
use
the
latest
code
check
it.
If
you've
made
changes,
you
can
then
actually
fix
a
bug.
A
I
can
then
push
the
change
back
through
this,
this
environment
right
them.
Now,
in
my
get
full
access
to
my
get
environment,
it's
very
important
to
note
that
I'm
about
to
about
to
start
a
demo
where
I
boot
other
machines
using
the
pixie
boot
process,
and
to
do
that
I'm
going
to
need
to
map
the
docker
bridge
into
an
Ethernet
port
that
I
can
use
so
by
way
of
looking
at
the
setup.
A
This
is
my
build
machine
in
that
machine.
I
have
three
network
adapters.
One
is
natin
for
the
internet,
the
other
one
is
my
host
adapter.
So
I
can
talk
to
it
SSH
and
do
things
like
that,
this
third
adapter
is
the
one
that
we
use
for
pixie
booting.
So
this
this
adapter
is
set
up
in
the
virtual
machine
is
equal.
It's
too
you'll
notice,
here,
z,
2,
I've
already
gone
through
the
configuration
process,
but
I'll
show
you
what
with
this,
what
is
happening.
A
If
I
look
at
my
bridge
control,
what
you'll
see
is
docker,
my
docker
bridge
has
eath
2
and
the
interface
for
my
container,
which
means
that
the
container
I'm
running
over
here,
ms
blue,
this
blue
session
and
e2,
are
able
to
communicate.
So
when
I
take
this
slave
node
and
start
it,
it's
only
adapter.
A
Is
this
Ethernet
host-only
adapter
two,
so
that
adapter,
when
I
pixie
will
respond
crowbar
will
be
able
to
pick
see
it
if
I
wanted
to
do
this
without
virtual
machines
and
use
physical
nodes,
all
I
have
to
do
is
bind
this
docker
bridge
to
whatever
Ethernet
port
I
have
available
for,
for
my
pixie
boot
environment
I
could
do
that
through
any
physical
Network.
However,
I
felt
like
I
wanted
to
do
it
in
this
case.
It's
super
easy.
A
Just
to
use
virtualbox
as
a
way
to
boot
slave
nodes,
we
used
to
do
this
in
crowbar
one
all
the
time
we
had
a
much
more
complex
networking
configuration
curb
our
court
to
open
car
bars
is
much
more
flexible
from
a
networking
perspective,
so
I
have
to
normally
I
would
do
a
pseudo
Bridge
control,
add
interface
to
docker,
to
de2,
like
that.
That's
already
been
done
here
and
then
I'd
also
have
to
turn
the
link
on,
because
we
don't
bind
that
IP
address.
We
let
it
be
just
via
pass
through.
A
So
I'm
going
to
do
an
IP,
add
link
set
to
up
like
that,
and
these
steps
are
in
the
documentation.
So
you
don't
have
to
pull
them
off.
The
video
I
mention
them
here
because
they
trip
people
up
with
they're,
not
aware
that
they
need
to
do
it.
Another
thing
that's
important
to
realize
is
we
switched
crowbar
to
use
online
mode,
so
in
the
past
you
would
have
had
to
build
a
whole
I.
So
then
boot
a
machine
with
that
I.
So
and
then
that
would
be
your
deploy
media
between
Daka
and
rpms.
A
We
don't
do
that.
We
only
include
the
crowbar
bits
in
the
curb
our
pieces,
and
so
you
must
have
internet
access
to
use,
crowbar
we're
working
on
some
caching
strategies
that
will
make
that
not
as
necessary,
but
it's
a
significant
benefit
for
being
able
to
bring
new
things
in
and
try
new
things
and
do
different
operating
systems.
So
crowbar
will
go
to
the
Internet
and
pull
in
the
things
and
dependencies
it
needs
in
order
to
get
the
installs
completed.
A
The
other
thing
that's
worth
noting
is
that
we've
been
very
careful
to
not
create
the
documentation
mess
that
we
had
created
before
and
so
crowbar
has
a
documentation
infrastructure
we've
been
spending
a
lot
of
time
in
the
development
guides,
documenting
the
API
and
the
model
and
principals
workflows.
So
there's
actually
quite
a
bit
of
information
in
here,
and
the
slashdot
directory
is
the
authoritative
source
for
all
crowbar,
open,
chrome
or
documentation.
There
is
no
other
wiki.
A
We
have
other
things
floating
they
all
funnel
back
into
here.
So
if
you're
looking
for
something,
this
should
be
here.
If
it's
not
at
it
or
talk
to
us
and
we'll
help
get
to
get
those
things
at
it,
we
even
have
information
about
how
the
doc
guys
are
formatted
and
things
like
that.
So
there's
a
significant
amount
of
information
for
you
to
start
with
here
and,
of
course,
I'm
going
to
recommend
you
start
with
the
dev
systems
to
actually
build
your
your
pieces
and
goes
through
the
things
that
we're
talking
about
here.