►
From YouTube: OpenCrowbar Planning Meeting 2014 07 02
Description
Reviewed IPMI & Ready State Wizard progress. Discussed CI plans and work for next sprint. Created agenda for Design Meeting on 7/9
A
A
B
Well,
as
of
the
latest,
uphold
that
I
have
up
for
ipmi
open
crowbar,
will
automatically
assume
direct
control
of
any
ipmi
controllers
on
notes
that
it
discovers
and
we
can
use
them
to
power
machines
on
power
them
off,
identify
them,
regroup
them
blink
them
force
them
to
fix
eboot.
All
that
sort
of
goodness.
A
B
B
If
there's
nothing
else
to
do
with
them
at
the
time,
it
will
turn
them
off
if
it
detects
that
it
has
a
method
of
turning
them
back
on
you,
though,
for
OS
installation,
if
the
know
it
has
that
it
has
the
ability
to
be
turned
on
remotely
if
we
install
the
OS
and
there's
nothing
else
to
do
once,
the
OS
is
up
and
running
and
we've
glued
it
into
it
and
everything's
gone
green
it'll.
Just
turn
that
note.
B
E
B
A
B
I
mean
watching
that
I'm
using
is,
if
you
just
plug
in
a
rack
worth
of
nodes,
and
you
turn
them
on
to
get,
and
you
know
you
turn
them
on
to
get
them
discovered,
but
you
don't
have
anything
else
to
do
at
the
time.
The
notes
are
just
going
to
sit
there.
Wasting
power
profile
will
turn
them
off
until
you
have
something
for
them
to
do.
F
E
B
F
Like
it
as
a
default,
it
might
be
nice
to
turn
it
off,
because
sometimes
when
you're
first
bringing
up
the
machines
you're,
not
sure
that
you
have
all
the
power
and
cooling
in
place
and
you
want
to
bring
them
up
other
times.
You
actually
want
to
test
power.
Loading
on
your
PD
is
so
there's
a
case
where
you
might
want
to
bring
all
the
machines
on
before
they're
deployed.
B
C
B
A
I
know
I.
Remember
you
adding
it
I'm
trying
to
remember
where,
where
where
to
find
it
in
the
document,
so
there's
a
place
in
the
docs
in
the
deployment
guide
for
troubleshooting
that
it
would
be
useful
to
add
this
as
a
as
an
item,
because
I
think
it's
only
in
the
dev
guide.
This
is
a
really
useful
stage.
B
C
B
A
What
what
if
we
had
a
role
for
heart?
You
know-
we've
always
talked
about
this
like
a
diagnostic
mode
or
a
power
test
mode,
or
a
system
check
right
at
that
that
would,
that
would
be
a
different
type
of
things.
You'd
actually
be
running
a
self-test,
all
right
that
was
sort
of
solve
this
problem
with
it.
If
you
want
to,
if.
B
You
want
to
boot
the
system
into
self
says
we
can
add
that
the
reason
I
don't
want
power
actions
by
themselves
to
be
roles
is
that
they're
kind
of
independent
I
mean
crowbar,
despite
the
fact
that
with
since
we're
managing
ipmi,
we
can
control
the
power
state
of
the
note.
You
know
we're
not
the
only
thing
to
control
the
power
state
of
the
note.
You
know:
dudes
walking
through
data
centers,
pushing
power
buttons,
control
the
power
state
of
endowed
and
there's
no
and
that's
something.
That's
just
fundamentally
out
of
van
and
phor
crowbar.
C
A
A
A
B
Yeah
I
mean
and
just
have
just
with
ipmi
without
TMI
two
point
O
at
least
now.
We
could
go
a
lot
further
into
power
management
like
we
could
put
power
caps
on
servers,
that's
supported
and
exposes
VoIP
line
that
functionality
is
baked
into
the
ipmi
2.0
specification,
so
probably
not
going
to
go
there
for
a
while.
B
A
Ok
and
then
so
the
other,
the
other
thing
that
dropped
this
time
was
the
initial
ready
state,
wizard
I'm,
still
I'm
still
debugging
that
unbelievable
still
so
working
that
that,
through
as
we've
gotten
far
enough,
but
the
ready
state
wizard
actually
will
let
you
complete
the
tasks
that
we
had
and
it
took
people's
feedback
from
the
middle
of
the
week.
So
that's
that
hopefully,
in
the
next
cycle
will
make
that
an
official
part
of
the
UI.
C
A
A
So
this
is
that
this
is
what
it
looks
like.
So
you
have.
It
didn't
really
change
much
from
what
people
saw
before,
but
you
doesn't
include
the
admin
node
now
and
you
actually
can
pick
the
operating
system
that
you
want
and
then,
when
you
click
run
wizard
it
takes
you
into
into
the
pilot
or
whatever
name
you
give
it
into
the
pilot
deployment,
and
then
you
still
have
to
commit.
You
still
have
to
press
commit,
so
it
has
an
expectation
that
you're
going
to
review
the
final
item.
A
The
bug
the
bug
I
have
in
it
is
that
it
seems
like
it's
adding
node
rolls
into
the
employment
that
it
shouldn't
ask.
So
I
need
to
see
what
happens
and
then
Victor
I
need
to
validate.
If
this
is,
if
I
caused
this
or
its
core,
it
was
the
ipmi
power
state,
but
I
am
NOT
I'm.
Not
currently
automatic
system
is
not
shutting
down
VMS
automatically
it.
A
C
C
A
B
A
I
I
was
planning
to
rebase
line,
but
I'll
give
you
a
heads
up,
because
I
know
you
changed
some
of
those
paths.
Oh
actually
there's
a
question
relevant
to
the
ipmi
work,
so
the
ipmi
I
introduced
the
this
out
of
an
capability
to
turn
machines
on
and
off
and
I
thought.
The
code
also
did
it
for
VMS
just
by
doing
the
conventional
ssh
and
shut
down.
If
you
ask
for.
B
F
C
B
C
B
Mean
for
any
other
like
out
of
van
power
management
type
things
I
don't
want,
even
if,
like
the
out
of
that
thing,
is
just
essence
a
Qing
into
a
node
and
saying
halt.
I,
don't
want
to
do
that
without
being
able
to
undo
it
via
the
same
control
path,
and
you
know
turning
machine
off
is
kind
of
one
way
unless
you've
got
some
out
of
an
way
of
turning
it
back
on
that.
A
A
This
screen
brings
together
five
different
actions
that
we
were
performing
over
and
over
again,
and
so
the
idea
is,
it
really
simplifies
people's
first
experience
with
crowbar.
That's
the
use
of
the
use
case
and
actually
I
think
that's
in
the
actually
put
it
in
the
story,
but
the
use
cases
as
an
operator
I
want
to
bring
up
nodes
and
install
an
operating
system
without
having
to
learn
six
different
screens.
E
A
Because
that's
in
this
case,
normally
what
you'd
have
to
do
is
you'd
have
to
create
a
deployment.
You'd
have
to
create
a
network
you'd
have
to
edit
the
range
information
you'd
have
to
then
go
to
the
bulk
deployment
screen
to
put
the
nodes
in
the
right
deployment
and
then
on.
Each
node
you'd
have
to
click
in
to
the
available
OS
role
and
set
the
operating
systems.
So
this
one
screen
takes
the
place
of
point
about
20
since
there's
five
nodes
in
here
at
least
20
node
neva
20
clicks
through
the
crowbar
system.
E
A
C
A
E
A
A
What
we
could
conceivably
do
is
just
start
throwing
flags
in
there
about.
You
know
if
so,
some
of
some
of
the
information
that
you're
looking
for
it
could
actually
be
badge
badge
doubt
so
you
could
actually
have
a
bios,
bios
alert
or
something
like
that,
and
then
you
could
hover
to
get
the
additional
detail.
C
The
idea
the
the
issue
I'm
trying
to
address
is
either
one
of
two
either
they're.
All
I
have
a
newer
bios
for
them.
If
there
are
Dell
machines
or
I
have
a
mismatch
in
bios
and
they're
the
exact
same
machine,
otherwise,
so
those
I
have
I
have
12
720
sitting
there
waiting
to
go,
and
it
goes
hey,
wait
a
minute.
Three
of
these
are
older.
That's
that
what
I'm
trying
to
capture
makes.
A
C
E
C
A
What
I'm,
what
I'm
hoping
is
the
workloads
will
have
their
own
variants
of
this
wizard
that
the
tunes
for
them,
because,
if
I'm
doing
say
a
Hadoop
cluster,
the
raid
and
BIOS
configurations
are
going
to
be
I,
don't
need
to
expose
them
because
they're
much
more
set
based
on
that.
So
this
was
sort
of
the
the
leaf.
The
least
common
denominator.
Wizard
and
I
was
oh,
so.
C
A
E
I
was
just
wondering
what
the
what
the
flow
would
be
all
right
it
could
be.
It
could
be
a
number
of
different
different
options.
I
think
either
of
them
are
fine,
but
I
think
this
one's.
We
have
some
some
workload
deployment
functionality
in
the
system.
You
need
to
be
clear
in
both
the
documentation
and
the
UI
flow,
which
one
it
is
that
you
should
do,
or
you
should
I
one
than
the
other.
A
C
A
And
then
the
other
other
thing
that
we
said
we
were
going
to
do
this
and
it
sort
of
came
in
for
free
as
the
Travis
CI,
at
least
working
on
a
no-op
basis,
and
then
at
during
the
design
meeting
we
talked
through
thought.
We
talked
through
some
options
on
how
to
handle
that
I.
Just
have
I
haven't
had
time
to
make
me
progress
if.
E
A
E
A
F
C
C
E
E
Start
it
that
one
got
it:
ok,
there's
the
diagram,
alright
cool.
So
at
the
last
meeting
we
said
that
that
what
we
wanted
to
do
is
document
how
the
process
flow
would
work
with
with
the
Travis
CI.
So
this
is
a
fairly
simple
proposal,
but
I
thought
that
a
picture
would
also
help
with
it.
I
also
defined
what
the
Travis
CI
system
will
do
at
this
point
in
time
and
what
we
would
potentially
have
an
integration
system
on
do
later,
so
just
in
essence
a
quickly
reviewing
the
two
of
them.
E
So
the
Travis
CI
system
is
effectively
a
gating
system
that
does
a
really
really
quick
smoke
test
to
ensure
that
that
the
BDD
test
sequences
pass
on
a
virtual
environment.
It
has
a
serious
limitations,
namely
the
operating
system
and
what
you're
doing
in
those
pieces.
So
I
tried
to
outline
those
in
this
in
this
email.
E
It's
clear
that
we
are
going
to
need
a
further
testing
system,
probably
on
physical
gear,
where
we
can
actually
test
multiple
operating
systems,
because
it's
one
of
the
value
propositions
of
the
system
on
which
we
can't
do
with
Travis,
at
least
the
online
Travis.
So
that's
a
future
sir,
to
be
named
later
type
of
function.
Does
that
all
make
sense?
Yes,.
E
E
Makes
the
the
BDD
tests
run
through
appropriately
at
that
time,
arm
reviewer?
So
a
different
engineer
will
review
the
code.
Do
a
code
analysis
through
that
will
leave
it
up
to
the
up
to
the
reviewer
whether
they
believe
that
they
need
to
run
additional
smoke
tests
or
just
do
code
inspection
arm
at
the
point
that
they're
okay
with
what
it
is,
they'll,
actually
pull
it
into
master
arm,
and
that's
that's
kinda.
C
C
E
Know
when
we
build
the
integration
system,
armed
that'll
do
some
more
in-depth
tests.
You
know
we
very
well
may
make
that
you
know
make
that
another
system
gate
arm,
but
I
expect
that
test
to
take
much
longer
somewhere
in
the
order.
You
know
45
minutes
to
an
hour,
especially
if
we
were
dealing
with
real
hardware
arm.
So
we
don't
necessarily
want
to
put
that
in
the
middle
of
the
of
the
development
stream.
You
want
to
use
it
as
a.
We
have
a
broken,
build
type
of
type
of
environment.
Now,
you're
really
looking
for.
D
A
A
E
Think
that's
part
of
the
sir
to
be
named
integration
test
function.
You
know,
I
didn't
want
to
go
into
design
for
that,
because
it
was
so
future.
I
thought
it
would
take
more
more
discussion,
but
it's
conceivable
of
the
integration
tests
would
actually
test
the
the
final
installation
mechanism
and
run
through
the
installation
as
well
as
physical
boot
processes
and
all
the
other
things
that
aren't
tested
by
the
by
the
DVD
infrastructure.
A
Got
it,
though,
so
one
of
the
things
that
that's
I
don't
know
if
we
need
to
highlight
it
in
the
flow
or
not,
but
the
top.
The
sort
of
top
row
is
all
code
based
checks,
they're
testing,
the
actual
raw
code
and
checked
out
from
get,
whereas
the
integration
suite
is
using
the
filled
sort
of
the
RPM
build
distribution
bit,
which
is
I,
think
it's
we
want
it.
We
need
to
test
both
some.
C
A
That
that's
been
an
Achilles
heel
in
the
past.
That's
a
lot
of
all
a
lot
of
these.
This
whole
process,
leading
up
to
merge,
is
actually
against
some
of
the
really
dev
systems
and
Dev
bits,
not
against
production
bits
so
future
the
future
integration
tests
going
to
be
is
going
to
be
important
by
the
time
we
get
to.
E
Brew
yeah,
the
other
thing
that
we
found,
that
was
an
Achilles
heel
that
I
touched
on
briefly,
is
interactions
between
multiple
operating
systems.
You
know
where
everything
works,
fine
on
a
bun
too,
but
we
break
scent
or
break
souza,
and
if
we're
going
to
continue
to
support
multiple
operating
systems,
we
need
to
test
infrastructure.
That's
going
to
test
on
multiple
operating
systems.
Well,
if
you're
a
nine-year-old,
sorry.
D
D
E
E
Systems,
I
really
tried
to
find
one
that
would
be
able
to
test
on
multiple
operating
systems.
I
wasn't
able
to
find
one
that
had
the
level
of
integration
that
Travis
did
so
it
kind
of
took
the
you
know.
My
recommendation
was
take
the
least
common
denominator,
at
least
we'll
have
an
automated
voting
mechanism
and
we
can
make
it
smarter
going
forward,
but.
A
Since
conceivably,
we
could
use
docker
to
create
different
environments,
you
know
at
least
tests
and
a
bunt
to
era
centos
or
things
like
that.
Right
now,
we're
using
docker
two
minima
minimize
the
number
of
different
environments.
We
we
are
trying
to
support
in
the
future.
We
could
use
it
to
test
more
broadly,
you
know.
That's.
D
D
D
A
B
B
C
B
C
B
C
B
Next
job
mattified
yeah
that
process
could
very
easily
be
modified
to
you
know,
be
able
to
stand
up
an
admin
note
on
a
linux,
distro
and
test
that
I
don't
use
it
mainly
because
the
doctor
process
is
much
faster
and
frankly,
I
don't
I'm
not
at
the
stage
where
I
really
care
about
what
operating
system.
The
admin
note
is
running
on,
because
we
have
multi-os
capabilities
and
it
doesn't
matter
what
I
was.
The
atman
note
is
running
on
because
it
can
install
any
other
Linux
sister.
Oh.
C
C
A
E
E
A
But
the
in
the
core
repository
it
doesn't
have
knowledge
of
any
workloads,
so
it
can't
do
work
load
tests.
The
BDD
was
designed
so
that
you
could
add
workload
specific
tests
inside
that
workload
and
then
at
that
would
become
additive
to
the
test,
but
I
think
it's
actually
a
different
different.
This
process.
It's
the
same.
It's
the
same
general
process
but
we'd
be
a
different
Travis
configuration
file
to
test
the
workload.
A
Interesting,
this
is
actually
a
bigger
question.
It's
a
good
one,
because
if
you
were
going
to
actually
have
a
smoke
test
that
included
OpenStack
or
a
Travis
test
that
included
the
OpenStack
configuration
we
couldn't
actually
install
it
all
you'd
be
doing
from
a
bdd
perspective
would
be
validating
that
the
roles,
the
relationships
and
the
roles
worked
and
if
you
extended
crowbars
api's,
those
would
be
tested.
It'd
be
useful
to
test.
A
A
A
Well
and
it
it's
going
to
just
spin
up
a
vm
or
a
container
to
run
the
test
sequence,
give
you
the
entry
points
and
come
back
right
to
we'd,
actually
have
to
spin
up
a
multi-node
system
I
it
might.
We
might
get
to
a
point
with
docker
that
we
could
actually
spin
up
a
multi
docker
system
and
to
play
OpenStack
against
that,
and
then
we
could
do
a
real
smoke.
This
travesty
I
people's
heads
are
going
to
explode.
Yes
at
that
point
that
that
would
be
fine,
be
an
interesting
conversation
to
have
right.
A
E
A
C
A
A
A
A
And
it'll
tell
you
what
it
what
happened,
and
so
this
will
show
up
as
soon
as
you
start
doing
commit
it'll.
Actually,
you
know,
like
start
doing,
checks
against
these
he's
convinced
and
you'll
commit
my
commit
it'll
it'll
review
them.
There's
hi,
there's
thai,
there's
very
virtuous
feedback
or
doing
frequent
pull
reviews
or
frequent
pushes
to
your
personal
repo
in
this
model.
A
F
Talk
about
is
that
so,
okay
I
think
you
know
how
about
a
reasonable
success.
Taking
the
this
park
down
the
oxen
convert
HTML.
If
people
think
that's
a
good
idea,
I'll
move
forward
and
put
together
a
workflow
to
kind
and
then
can
I
deliver
it
off
yeah
unless
versions
plan
at
this
txt
markup
for
now
pick
it
up.
I'm
gonna
do
looking
in
the
prop
sink
and
later
or
maybe
but
I
just
want
to
look
at
this
stuff
push
down
on
ISA.
So
it's
always
up
to
date
and
accessible
I
just
want
to.
F
F
F
F
I'm
definitely
interested
in
that
I
just
add:
Joe
I
want
to
hit
the
first
thing.
First,
get
the
docs
published
the
key
issue.
I'm
seeing
right
now,
tables
are
fubar,
I
can
fix
those
in
the
processing,
and
some
of
the
TOC
levels
are
a
little
funny
because
of
the
way
markdown
handles
levels
and
I'm,
pretty
sure
I
could
deal
with
that
automatically
in
the
conversion.
F
This
is
taking
the
docs
that
are
in
the
code
base,
pushing
them
out
to
a
website,
say
github,
delay
or
someplace
else
is
HTML
and
probably
also
pushing
them
out
as
PDF
and
epub
formats,
since
it's
almost
free,
so
docs
are
online,
so
I
want
to
build
directly
from
the
markdown,
that's
in
the
existing
sources
and
then
at
some
point
in
the
future.
I
want
to
go
back
and
look
at
converting
the
doc
format
to
restructure
text,
but
I
don't
want
to
do
that
right
now.
E
E
F
F
F
E
F
Trying
to
think
a
great
way
to
answer
that
so
right
now,
within
the
crow
bar
code
base,
we
kind
of
built
our
own
documentation
system,
so
we're
rendering
the
markdown
into
HTML
in
the
UI
dynamically.
What
I'd
like
to
do
eventually
is
get
the
same
processing
that
publishes
those
docs
troll
website
integrated
into
the
code
base.
F
F
That's
why
I
was
just
looking
for
feedback
here.
If
people
think
we
should
just
kind
of
I
guess
the
executive
summary
is
I'd
like
to
do
a
brute
force,
conversion
to
get
the
stuff
accessible
on
the
web
and
then
kind
of
go
back
and
revisit
the
code
base
and
improve
the
way
we
actually
do
the
documentation
within
crowbar.
If
it's
running
I'm,
not
sure
if
that
answers,
your
questions
got
it
does
week.
That's
that's
perfect.
Yes,
because
we
kind
of
build
our
own
documentation
system
and
I
think
we
could
replace
that.
F
E
C
E
You
should
you
should
make
it
so
that
you
have
one
way
to
render
the
docs
right,
whether
they're
being
published
or
whether
they're
being
rendered
in
the
user
interface.
It's
fine
to
do
it
in
steps.
I
completely
agree
with
that.
But
do
you
know
II
I
could
just
see
you
know
the
public
docs
are
messed
up.
Oh.
C
E
D
C
F
Agreeable
so
I
take
the
next
step
here
on.
This
is
to
open
an
issue
and
kind
of
summarize
what
we're
doing,
potentially
on
a
on
a
separate
etherpad,
the
big
picture
plan
and
then
the
short
term
moves,
and
then
we
can
review
that
in
the
next
meeting
or
for
that
matter,
I'll
just
blitz
through
and
publish
what
I've
done
so
far.
F
A
A
A
What
they're,
looking
for
so
chef,
the
chef
metal
stuff,
does
not
actually
do
metal
it.
It
is
really
very
similar
to
crowbar
one.
It
builds
run
lists
based
on
a
system
perspective.
That's
that's
a
very
short
version.
Job
jubs,
probably
cringing,
but
and
so
what
they
really
need
is
something
that
handles
discovery.
Boot
and
os
laid
OS
and
network
lay
down
so
that
you
can
then
run
chef
against
it
and
they
have
a
pretty
reasonable.
A
Api
for
that
and
they're,
actually,
they
have
calls
against
our
API.
They
use
a
chef
gem,
a
ruby
gem
to
do
that.
That
would
integrate
pretty
well
what
I,
what
I
believe
is.
If
we
do
a
chef
metal
integration,
then
the
chef
community
will
be
much
more
interested
in
investigating
what
we've
built
with
crowbar,
because
it
will
address
a
gap
in
a
technology
that
they
that
there's
a
little
bit
chef
is
promoting
quite
heavily,
and
so
it's
it's
predominantly
a
marketing.
B
Mutation
of
being
able
to
play
well
with
others,
the
general
feeling
I
get
when
I'm
out
talking
about
crowbar,
is
that
it's
a
monolithic
thing.
We
have
to
do
everything
the
crowbar
way,
and
it
just
does
too
much.
If
we
can
show
a
nice
clear
integration
that
it
it
will
make
it
easier
for
people
to
imagine
crowbar
helping
them.
E
E
E
A
A
Me
about
it
and
we'll
talk
one-on-one
one-on-one
on
it,
but
we'll
go
through
it
and
some
detail
next
Wednesday
and
then
I'm
going
to
post
100.
No
challenge
just
showed
up
on
the
screen
just
a
second
ago
and
then
I
think
we
do
need
to
have
a
conversation
about
RPM,
install
maintenance
and
what
we
might
want
to
do
is
move
that
we
sort
of
touched
on
it.
Scott
with
your
process,
but
I
think
we
need
to
actually
talk
about
it
at
the
design
meeting
that
reasonable.
C
A
Because
because
we
have
a
people
in
the
community
or
coming
want
to
come
in
to
crowbar
through
the
RPM
install
and
we're
just
not
using
it
that
much
so
I
want
to
want
to
figure
out
either
we
should
decommit
from
doing
it,
or
we
should
figure
out
what
it's
going
to
take
to
maintain
a
updated
RPM
Victor.
Do
you
know
for
actually
generating
a
new
rpm
I,
don't
think
our
build
with
a
build
process
that
does
anymore.
We.