►
From YouTube: OpenCrowbar Sprint Meeting 2014 03 26
Description
http://pad.opencrowbar.org/p/community-planning-meeting-2014-03-26
Review last sprint results, Discuss plan for next sprint
Discuss Quarterly Release Roadmap
B
This
is
the
March
26
2014
open,
crowbar
community
planning
meeting,
in
which
we
review
our
previous
sprint
achievements
in
the
last
sprint,
then
we
review
our
overall
goals
and
discuss
any
funk
for
term
and
long
term
goals
in
criteria
to
meet
those
goals.
Any
community
planning
topics,
upcoming
conferences
and
meetups
other
resources
available
and
finally
enumerate
our
likely
upcoming
sprint
stories
and
try
to
put
a
finer
point
on
focusing
our
work
and
if
there's
any
time
left,
we
will
do
a
demo
or
technical
review
of
whatever
interesting
stuff
we've
made
for
this
past
spring.
B
So
Rob,
would
you
like
to
take
it
away
with
some
the
our
previous
print
achievements,
please
passed
or
not.
I
may
I'd
be
happy
to
suddenly
something
I
should
bring
up
the
document.
If
you
don't,
if
you
don't
mind
typing
a
little
bit,
I
will
go
through
what
what
we've
done.
It's
been
really
productive,
since
we
did
the
official
open,
crowbar
migration
about
yes.
Last
two
sprints
ago,
I'll
try
to
break
their
cough
my
board
and
get
organized.
Keep
watching
I
feel
like
we've,
really
been
making
a
lot
of
progress.
B
So,
as
you
know,
we
fully
moved
over
it
up
in
crowbar
and
we've
been
migrating
everything
out
of
the
crowbar
one
repos
and
making
sure
we
didn't
have
any
in
hanging
Chad
codes
that
work
is
almost
complete.
All
the
core
work
has
been
moved
/,
but
the
sum
of
the
migration
for
ipmi
and
open
sacks
is
still
hanging
an
infection
part
of
what
we're
planning
for
this
spring.
B
We
did
a
lot
of
refactor
and
clean
up
in
this
last
sprint,
so
we
pulled
out
the
whole
snapshot.
Concept
was
a
big
deal
to
remove
we
added
referential
integrity
constraints.
We
fixed
a
whole
bunch
of
500
API,
but
there
were
some
you
I'd,
bugs
that
we
fixed.
If
you
missed
it,
the
CLF
Cromer's
been
really
strong.
Oh,
my
goodness,
we
got
the
RPM
we're
actually
publishing
rpms.
B
We
can
install
from
our
p.m.
we're
still
tuning
that
it's
a
little
bit.
Flaky
golden
sledgehammer
is
actually
next
sprint.
Officially,
because
all
the
polls
haven't
come
in
yet,
but
so
one
of
the
things
that
we're
doing
in
this
coming
sprint
is,
we
have
switched
from
having
people
from
having
sledgehammer
have
to
be
built
by
each
person
than
we
now
have
a
consistent
word.
That
is
in
part
because
we
change
the
API.
So
where
are
things
that
in
this
sprint,
yay.
B
B
B
We
used
to
have
one
API
called
a
created,
a
node
and
added
the
system
deployment,
and
that
was
causing
us
problems
because
a
whole
bunch
of
decisions
were
being
made
in
that
transaction.
It
also
exposed
a
whole
bunch
of
transaction
boundary
issues
within
the
code
base
so
and
it
also
forces
to
do
these
weird
things
called
hints
that
we're
sort
of
out
of
keeping
with
the
rest
of
the
schema.
So
we
split
mode
creation
into
a
couple
of
discrete
steps.
B
You
create
a
node,
you
add
it
to
a
deployment
you
commit
it,
and
so
those
those
are
the
basic
steps
stiff
to
turn
it
on
commit
market
alive,
and
you
also
have
to
say
that
it's
available
for
action
and
those
those
changes
really
streamline
how
we
can
handle
notes
when
things
that
we're
working
towards
is
how
doctor
works,
how
we
can
create
docker
notes,
because
dr.
nodes
have
returned
challenges.
B
B
B
B
B
B
Anyway,
we
we
got
so.
B
B
B
B
B
B
B
So
yeah
there's
code
in
there
that
got
in
quietly
that
actually
identifies
which
os's
are
available
based
on
my
sins
that
are
in
the
cache
and
so
provisional
automatically
package,
those
into
bootable
package
into
suitable
forms,
pre
pre
slur,
wow,
I,
we've
been
busy
ya
allah
people.
Now
you
realized
once
you
look
at
it
from
30,000
feet.
You
keep
getting
a
lot
done,
oh
yeah,
so
it's
one
of
the
things
that
interesting
in
this
stuff
is
that
either
that
with
the
doctor,
admin
is
super
fast.
A
B
Let
me
look
at
the
backlog
a
little
bit,
so
one
of
the
things
that
I'll
note
in
this
for
somebody
who
might
be
listening
to
this
recording
is
that
we
actually
have
and
is
somebody
defense,
yeah
I,
don't
came
on
the
list.
Hello.
We
just
joined.
A
B
B
I
was
going
to
say
that
the
so
agile
we
actually
used
l
use
an
internal
agile
board
and
we
have
plants
to
open
that
up
and
make
it
to
actually
use
the
backlog
board
over
time.
One
of
the
things
we're
trying
to
do
is
we're
building
up
to
get
a
gated
CI
going
for
open,
chrome,
bar
and
I
think
once
we
have
that
in
order
to
get
through
the
gate,
we're
going
to
also
need
to
have
people
working
against
stories
in
the
backlog,
forbidden
we're
still
being
a
little
bit
loose
on
that.
B
But
the
purpose
of
this
meeting
is
to
actually
go
through
the
things
that
gal
has
in
its
backlog
for
the
Sprint
and
encourage
anybody
else
who
wants
to
work
on
things
in
this
print.
Make
commitments
put
them
put
them
on
the
show
them
and
share
them
so
that
we
can
create
make
sure
those
resources
to
do
pull.
Requests
and
reviews
is
part
of
the
sprint
yeah
and.
B
Bring
up
support,
developer,
bring
out
support,
included
a
great
point
in
the
past.
We
found
that
if
we
don't
coordinate
other
people's
for
coming
in
then
it's
hard
to
make
sure
that
it's
prioritize
to
review.
This
is
part
of
the
process
and
then
so.
The
things
that
we're
looking
at
seeing
in
the
coming
sprint
golden
sledgehammer
is
means
that
you
don't
have
to
build
sledgehammer
yourself
that
we
have
a
published
one
and
pledged
hammer
it's
important
to
note
sledgehammer
changed
I
mean
they
can
noted
this.
B
B
B
I
review
the
pull
request
yesterday
and
building
is
not
even
recommended
anymore.
The.
A
A
B
B
Would
you
be
a
gated
trunk,
so
rpm
work
is
part
of
the
continuous
integration
checks
for
this
and
then
the
other
work
that
we
have
coming
is
puppet
jig
and
being
able
to
use
puppet
with
master.
That's.
We
have
recommended
that
the
other
thing
that
we're
working
very
hard
with
is
the
Burke
shelf
integration.
B
And
then
the
other
thing
we're
building
towards
with
some
of
the
refactor
we've
done,
is
docker
being
able
use
docker,
as
as
it
and
so
mid,
a
lot
of
progress
with
docker
early
on
and
then
that
exposed
some
workflow
challenges.
The
docker
offers
very
specifically
that
you
can't
easily
set
IP
addresses
for
docker
knows
you
can't
change
their
names.
You
can't
change
the
dns
entries,
so
there's
things
that
we
had
to
change
in
our
workflows
to
make
them
more
flexible.
Oh,
that's!
Actually
something
that's
coming
in
the
next
sprint.
B
What
that
did
this
is
so
cool,
so
the
idea
is:
we've
been
using
node
roles
consistently
as
milestone
points,
and
so
no
sorry
no
operas
milestone,
please
so
the
u.s.
tweaked
for
this,
so
that
when
you're,
when
you're,
actually
looking
at
a
deployment,
you
don't
look
at
the
individual
node
roles.
You
can
set
them,
but
what
you're
really
doing
is
you're
picking
the
set
of
no
trolls,
no
operas
that
you
want
to
implement
so
they're
things
like
in
song
and
LS
or
becoming
a
criminal,
managed,
node
or
set
stuff
capability.
B
Think
that
and
one
of
the
things
that
the
docker
work
requires
you
to
do.
Is
it
require
you
to
say
you
know
what
I
look
just
like
a
crowbar
managed?
Node
I
provide
the
same
services
that
no
alcohol,
but
you
know
what
you
don't
have
to
have
any
of
the
predecessors
of
that
role
of
the
novel
to
become
of
our
managed
node.
If
your
docker,
so
we're
going
to
have
a
docker
managed
node.
B
You
can
just
use
those
assuming
they're
there,
but
they're,
not
there.
They've
actually
been
done
by
a
different
role,
so
it's
not
exactly
an
alias
because
it's
actually
taking
over
your
the
whole
forward
dependency
graph,
but
it
provides
this
really
cool
way
to
say
you
know,
and
then
we
came
up
with
other
examples.
Besides
soccer
soccer,
you
don't
need
no
discovery,
you
just
say
oh
I'm,
poof
you're
instantly
and
installed
OS
note
and
a
lot
of
the
things
that
we
have
to
do.
We
don't
do
a
docker,
but
the
same
thing
would
be
true.
B
If
you
want
to
provide
a
database,
you
could
actually
have
a
no-op
role
for
a
database,
and
then
our
default
might
be
postgres
and
it
would
just
build
a
Postgres
database,
but
you
could
actually
substitute
my
sequel,
database
or
or
I,
don't
care
what
our
goal,
whatever
you
want
it,
and
then
you
would
just
install
that
and
say
this.
These
roles
provide
the
database
no
opera
and
then
it
provides
you
with
an
alternate
path
to
implement
parallel
functionality.
B
Is
it
that
the
these
roles
provide
is
a
no
parole
or
they
provide
the
roles
in
order
to
achieve
the
state
that
gets
you
to
they
know
on
it?
They
provide
what
it
takes
to
get
to
the
Noah
role,
but
you
don't
want
the
Noah
focus.
The
knob
role
has
prerequisites,
so
it's
effectively
an
alternate,
no
opera
or
it's
an
alternate
end
state
I
this.
This
really
should
be
our
topic
for
next
week's
technical
call,
because
Victor's
Victor's
actively
building
it
in
right.
Now.
B
And
it
will
know
pearls
continue
to
survive
in
this
design.
Yeah
I
know
we
should
like.
B
We
had
no
idea
when
we
we
built
them
that
they
were
going
to
be
as
important
had
an
increment.
Their
big
ended
up
being
much
more
important
than
we
realized
and
we
change
them
to
mouth,
though
it's
something
to
suggest
I,
don't
think
it
would
be
that
hard
to
do.
B
B
A
B
A
B
B
B
So
one
of
the
things
that
we
really
want
to
see
is
kovar
on
a
quarterly
release
cycle
which,
which
is
a
pretty
aggressive
release
cycle,
but
considering
the
that
we
end
up
bottlenecking
the
workloads,
we're
not
careful.
We
think
that
the
court
would
cycle
is
warranted.
It
means
that
we're
going
to
have
to
be
careful
about
how
we
clip
stream
things
in
but
seems
like
it's
a
good
plan,
permanent,
restructure
perspective
and
the
goal
would
be
to
have
released
early,
upgrade,
upgrade
ability
and
doing
this
and
looking
at
our
refactor,
where
we
are
with
things.
B
It
actually
feels
to
me
like
we're
we're
getting
to
a
hardening
point
where
we
can
cut
that
God's
around
release
and
people
start
looking
at
it
as
a
stable
thing
and
that'll
make.
That
will
make
our
conversations
easier.
We
need
we
need
a
release,
naming
convention
and
we
have
to
be
started
a
thread
on
that,
but
I
think
purse.
B
B
B
B
B
A
B
Idea
was,
this
is
something
I
circulated
at
least
internally.
I
don't
think
I
took
it
to
the
community
at
the
time
just
to
look
through
some
some
ideas
to
create
the
ship
raya.
So
if
I
go
into
the
Wayback
Machine
two
years
ago,
we
we
actually
created
this
thing
that
we
call
ship
readiness.
You
can
actually
go
back
and
find
a
whole
bunch
of
documentation
round.
One
is
ready.
B
Think
it's
important,
but
call
that
our
ship
ready
release
and
people
can
start
through
targeting
workloads
for
it
and
they
can
actually
start
using
it
count
on
the
API.
So
there's
a
contract
at
this
point
that
api's
will
be
iOS
will
stabilize
databases
will
be
migrated.
Able
upgrades
will
be
possible.
Let
me
do
this
to
the
list.
B
But
I
think
it's,
I
think
what
we
really
want
to
be
able
to
do
is
get
to
this
first
release
target
and
then
start
enforcing
to
the
contract
and
part
of
the
goal.
Here
would
be
that
we
might
make
API
changes
between
anvil
and
broom,
but
if
we
can
of
whatever
we
won't,
and
they
should
be
four
words
capabilities.
B
A
B
A
A
B
B
B
B
B
B
B
B
But
I
think
we
do
need
two
releases
of
people
using
the
api's
to
before
we
say
their
final.
That
makes
sense
so
that
the
idea
here
is
that
the
first,
the
first
release
is
really
targeted
at
getting
the
base
table
the
summer
release.
We
would
bring
in
really
bringing
the
workload
so,
even
though
we're
working
with
the
OpenStack
stuff
workloads,
what
we're
really
seeing
here
is
that
those
guys
could
start
start
courting
with
the
idea
of
targeting
the
broom
release
as
their
their
their
actual.
Now,
it's
ready
release
clearly.
B
Summer,
yeah
I
I
really
want
to
see
this
done
before
the
open
saxena's.
So
this
is
this
is
where
it's
worth
talking
about,
what's
necessary
for
ship
readiness
right.
So
these
are
things
I
wrote
in
a
while
ago,
but
it's
worth
discussing
and
I'm
not
as
interested
in
talking
about
and
camshaft
as
I
am
about
sort
of
figuring
out
with
this.
These
critical
milestones
for
n
bar
any
shipping
means
that
other
people
are
going
to
use
your
product
that
third
parties
could
integrate
with
it,
which
means
a
stable
API.
Does
that.
B
A
B
B
A
B
B
B
To
sprint
by
sprint,
no
feature
regression
which
sounds
like
unknown
to
me,
it
sounds
like
well
duh,
but
it's
very
common
for
us
in
adding
capabilities
to
break
things
in
traditional
development,
and
so
what
we're
really
trying
to
do
here
say?
Look,
we've
got
it
working
we're
going
to
not
purpose,
not
break
it
and
which
means
there's
a
level
of
CI
and
automated
tests,
and
things
like
that
that
are
covered.
B
B
Because
it
we
have
a
serious
problem.
If
somebody
comes
in
users,
users
open
crowbar,
the
poison
know
that
it
and
then
they
take
it.
They
do
a
pull
and
it's
busted
now
yeah.
We
would
probably
need
to
start
doing
the
sprint
contract.
I'm
saying
all
right,
you
know
in
inside
the
sprint.
Okay,
it
might
be,
it
might
not
be
as
safe,
but
outside
the
sprint,
all
right
the
sprint
boundaries.
We
should
have
a
working
or
working
stable
point
or
we
should
start
establishing
stable
points
and
part
of
it
is
that
we
actually
need
to
have.
B
B
B
B
B
The
idea
with
a
milestone
is
I
want
us
to
be
able
to
say
guys.
Everything
looks
good
we're
stable,
but
this
is
great
cut
that
because
somebody
can
count
on
it
and
what
will
probably
call
that
just
open
stack
of
exactly
this
right.
They
do
it
on
a
monthly
monthly
by
every
other
release
every
other
sprint
detective.
Every
month
they
have
a
thought,
you
know
and
being
a
dot
18
out
to
a
top
three
milestone,
leading
up
to
the
release,
as
we
were
only
going
to
have
eight
sticks
prints
per
quarter.
B
B
Then
we
might
as
well
just
stay
with
semper
and
say
the
API
is
stable.
We
have
feature
number,
you
know
we
have
new
features
here.
You
know
two
three.
B
The
only
reason
why
that
doesn't
work
is
that
I,
don't
expect
December
perspective,
that
the
groom
release
is
going
to
be
different
and
have
a
different
December
top
top
level
version.
So
when
we
get
to
d
we're
not
going
to
the
dremel
we're
not
going
to
have
three
two
dot
one,
we
might
up
to
that
one
at
that
point.
B
Right
I
expect
the
API
will
change
okay.
So
when
we
get
to
the
D
release,
we'll
figure
out,
if
that's
two
dot
one
or
if
it's
too
dot
Delta
all
right,
okay,
because
I
think
it
is
meaningful
to
say
all
right.
This
is
our
api
version
and
then
the
feature
capability
is
described
by
the
Alpha
groomer
camshaft.
And
that's
that's
why?
Actually,
you
might
want
two
vectors
here,
so
you
have
your
temper
versioning
for
the
API
great,
but
well.
A
B
You
here
it
is
oops
all
right
on
the
share.
I
have
number.
The
first
is
a
major
which
is
the
incompatible
API
changes
seconds
when
you
add
functionalities
in
a
backward,
compatible
manner,
and
the
third
is
patch
mixes
so
effectively
I.
Think
if
we
want
to
map
this
December,
it
would
be
to
dot
anmol
dot,
one
for
the
first
sprint
2
for
the
second
spring,
but
we
might
have
milestones
that
are
more
frequent
than
sprint's
or
less
frequent
I.
B
A
B
B
B
B
B
B
B
Right
so
there's
there
some
technical
debt
things
that
we've
done,
that
we
needed
to
do
for
a
home
a
long
time
right.
The
repos
converged,
and
actually
some
of
this
is
that
community
accessible.
These
are
all
things
in
that
in
that
bucket,
so
this
was
the
first
most
important
thing
get
far
having
all
those
all
those
repos
converged.
So
that
core
is
one
thing
right:
heart
OpenStack
is
its
own
thing,
just
just
one
thing
to
be
much
more
straightforward
with
that,
and
actually
part
of
this
repos
converged
would
include
Burke
shelf.
B
B
B
B
B
And
so
one
of
the
things
that's
going
to
be
important
with
this
release
is
the
things
we
put
in
critical
features,
we're
going
to
need
to
have
demonstrated
with
QA
and
so
I
think
this
is
why
we're
not
this
isn't.
This
is
a
straw,
man
proposal,
so
that
we
can
actually
say
all
right
all
these
things
that
we're
saying
are
done
in
me
and
going
Elise
we're
going
to
stand
up,
demonstrate
and
say
this
is
complete.
B
B
B
Thank
you.
Do
we
want
to
add
for
the
folks
who
are
committed
to
docker
the
docker?
The
deployment
platform
that
is
soccer
is
a
we
ship
ship
crowbar
in
a
container.
B
Definitely
could
I
would
let
that
happen.
Organically
yeah
I
think
we've
we've
done
a
lot
to
do
the
doctor.
Admin
I
need
to
sit
down
with
those
guys
and
show
them
the
hotness,
because
they
should
be
happy.
The
doctor
community
should
be
pretty
happy
with
what
we
did
because
I
think
it's
pretty
cutting
edge.
A
B
A
A
A
B
Such
as
pendency
graph,
honey
failure
modes
right
I
mean
some
of
the
way
that
we
built
the
annealer
is
a
consequence
of
the
design
pattern
we
were
following,
but
also
the
need
to
have
the
orchestration,
and
you
can
be
a
very
specific
graph,
be
laid
down
and
fail
very
visibly
and
an
easel
easy
to
troubleshoot,
because
one
of
the
big
challenges
with
curve
r
1
is.
The
failures
are
incredibly
hard
to
diagnose.
B
B
B
B
More
company
hello,
if
you're
on
the
call,
please
I,
think
we
just
lost
somebody
Kevin.
Are
you
still
there
if
we
only
have
a
couple
minutes
left,
but
if
you're
there
something
interesting,
you
have
questions
that
I'd
love
to
have
hear
your
voice
and
see.
What's
what
you're
interested
in
hearing
more
about.
B
A
A
B
B
B
A
A
B
Cool
at
me,
epigenetics,
are
the
sort
of
rethinking
of
what
is
the
motor
of
of
evolution
and
of
mutation
and
of
metamorphosis,
and
that
accounting,
much
more
for
environment
and
habitat
of
life
forms
or
of
robots
link
was
okay.
Did
you?
Did
you
read
the
swarm
patents?
Then
I'll
tops
my
list
together.
I
have.
B
Swarm
patent,
that's
actually
part
of
the
genesis,
a
crowbar
we've
actually
around.
What
and
the
reason
why
BDD
is
written
in
Erlang
is
because
we
start
the
prototype.
This
form
swarm
deployments
for
my
environmental
evolutionary
base
deployment.
It's
pretty
cool,
still
trying
to
get
there
almost
built
it
from
the
infrastructure
that
can
handle
it,
and
the
new
paper
from
google.
B
B
Where
our
way
up
so
I'm
rated
I
mean
we're
done,
we've
had
an
hour.
I
think
this
is
a
really
good
really
good
draft
in
in
the
true
nature
of
irony,
I
I
will
distribute
this
work
inside
of
our
team.
First,
even
though
we've
been
discussing
it
in
the
community
for
an
hour,
Jed
I
guess
you're
going
to
do
the
normal
wrap
up.
Oh.
A
B
A
B
B
B
B
Yeah
yeah
I
got
this
blog
thing
to
write:
that'll
be
fun
good.
All
right!
That's
one
step
out,
so
we
planned
out
some
of
the
topics
for
our
next
call,
and
we
got
a
tremendous
amount
done
here
on
this
planning
call
talking
about
the
future
releases
and
strategies
for
open
crowbar,
the
open,
Grove
our
project
from
crowbar
thanks
for
joining
everybody,
thanks
for
listening
back
at
home,
and
we
are
going
to
sign
off
and
catch
you
next
time,
everybody
Thank,
You,
Jed,
look
good!