►
From YouTube: OpenCrowbar (CB2) NodeRole data training 2014 01 31
Description
This Developer focused video explains how the data flows within Crowbar 2 and how developers can generate default values for NodeRoles.
Please add notes to: http://crowbar.sync.in/XL4DJ-Xa2Dw
A
A
A
We
use
a
lot
of
subclassing
behavior
when,
when
this
works,
no
trolls
darn
subclass
neutrals
are
just
no
trolls,
but
the
all
the
work
for
no
trolls
is
actually
done
in
the
role
code.
So
if
you
look
at
roll
it
implements
some
methods
that
are
critical
to
making
everything
work,
and
this
is
this
is
one
of
the
key
things
that
I
wanted
to
highlight
today.
Is
these
these
transition
roles,
and
also
no
troll
and
node
create?
A
A
A
So,
all
right,
let
me
just
I'm
going
to
work
from
the
drawing
a
little
bit.
So
the
center
of
everything
in
crowbar
is
cover.
Two
is
no
troll
right,
no
troll
carry
state.
No
troll
is
effectively
the
gating
process
right.
Everybody
should
be
well
aware
of
this
when,
as
you
build
up
the
roles
for
the
work
workloads
that
you're
putting
together,
what
you're
really
doing
is
you're
creating
a
neutral
graph,
so
the
roles
are
going
to
be
directly
translated
into
node
roles
when
you
add
them
to
a
deployment.
A
So
actually,
when
you
add
them
to
a
deployment
and
then
associate
a
node
with
them,
it's
when
you
take
that
action,
it
builds.
It
builds
a
graph
for
that
that
node
in
the
into
the
deployment
graph
does
that
does
that
make
sense
for
everybody
sin
with
these
no
trolls
are
effectively
interrelated
to
each
other,
and
that's
actually
that's
missing
in
this
graph.
A
A
A
Okay,
yep,
add
node,
add
to
node.
So
what
the?
What
happens
is
in
the
role
class,
when
you
add
an
ode
to
a
snapshot,
it
goes
through
and
builds
up
the
whole
dependency
graph.
You
can
see
there's
a
lot
of
code
in
this
appears
by
roll
it
active
if
it
looks
at
see
if
it's
a
cluster
and
finds
all
the
parents.
A
A
A
A
A
The
the
thing
that
gets
that
makes
that
even
more
complex
I've
been
working
on
ways
to
visualize
it,
because
it's
it's
so
painful
to
debug
is
that
you
not
only
have
forward
and
backward
relationships
on
the
on
the
individual
node.
You
also
have
cross
relationships
to
other
nodes,
which
makes
perfect
sense
right.
A
Sorry,
the
in
the
wrong
one
back
to
roll
you'll
notice.
There's
there's
actually
there's
there's
a
whole
bunch
of
concepts
in
here
like
clusters
and
things
like
that
and
so
we've.
This
is
a
place
where
there's
where
the
complexity.
This
is
the
place
where
you
would
expect
to
find
the
complexity
for
crowbar,
because
the
way
we
build
this
graph
determines
all
most
are
all
or
most
of
the
behaviors
for
crowbar
and
so
I
guess.
The
number
one
take
away
from
today
is
going
to
be
helping.
A
A
So
to
answer
that
question
I'm
can
give
you
an
answer
from
a
crowbar
to
perspective,
because
I
had
to
change
it
to
make
crowbar
to
work
so
crowbar
to
collapsed.
All
of
the
core
bar
clamps
into
a
single
thing,
which
is
so
much
easier
to
work
with
I
can't
tell
you,
and
one
of
the
consequences
of
that
is
that
there
is
now
a
bar
clamps
directory
where
exactly
what
you
suggested.
A
So
this
only
has
the
role
information
for
that
bar
clamp,
so
the
DNS
and
it
automatically
result
there's
a
way
that
automatically
resolves
all
this
stuff
so
yeah.
We
could
rename
the
root
crowbar
animal
to
be
crowbar
EML.
But
in
this
case
it's
actually
now
it's
pretty
straightforward.
If
you're
looking
for
the
logging
roles,
they're
all
in
one
place
together
and
it's
just
that,
and
so
the
files
are
much
simpler.
A
A
Think
that
makes
sense.
It
really
doesn't
matter
at
all,
because
when
you
import
it,
you
get
to
say
what
it
is
you're
too.
So
for
crowbar,
it's
defaulting
to
crow
bar
right
now,
but
it
since
that
that
action
is
determined
in
the
migration.
So
there
is
a
bar
clamp
import,
so
you
could
pass
whatever
name
whatever
name
resolved
here
and
you
can
pass
the
file
name
in
as
an
additional
parameter
or
if
you
need
to
change
the
code
so
that
you
can
change
it
right.
A
But
this
when
you
run
crowbar
it
actually,
the
import
of
all
the
bar
clamps
from
the
animal
files
is
done
during
this.
During
this
import
face,
at
which
point
all
the
roles
are
populated
and
all
that
stuff.
That's
when
all
this
that
comes
in
this
code
is
not
called
until
you
actually
add,
create
the
neutral
and,
and
so
that
ends
up
being
a
very
important
event.
A
A
Correct
I'll
try
and
be
careful.
The
the
only
difference
between
the
two
right
now
is
the
the
bar
clamp.
The
way
we
import
bar
clamps
and
the
the
docs
code
is
is
shifted,
but
the
code,
this
code,
it
should
be
again
unless
somebody's
changed
in
the
last
couple
days
is,
should
be
identical
between
the
two
sets
so
I
have
both
both
on
the
advantage
of
showing
you
here
is
that
when
I
want
to
show
you
the
you
know,
all
the
bar
clamp
code
is
here
and
there's
no
extra
navigation.
I
have
to
do
so.
A
That
was
one
of
the
big
changes
for
open
crowbar
was
that
all
the
bar
clamps
are
collapsed.
All
the
core
ones
are
collapsed
into
one
one
repo,
so
you
won't
have
like.
If
you
have
to
make
one
change
to
ntp,
it's
not
a
separate
pull
request
across
two
different
repos,
alright,
and
that's
actually
a
good
good,
stopping
point
or
a
good
transition
point.
So
we've
covered
how
no
trolls
get
created.
I
was
talking
about
the
complexity
that
got
added
with
recently
with
this
node
roll
data.
A
So
it's
important
to
remember
snapshots
or
time
time
series
help
us
create
time
series
for
deployments
and
no
trolls
contain
the
state,
so
they're
used
by
the
annealer
to
determine
when
things
get
handed
the
order
that
things
get
handed
off
to
the
jig
to
to
actually
run
the
chef
cook,
the
chef's
coat
or
script
or
whatever,
whatever
we're
executing
those
the
there
is
data
associated
with
a
node
role,
but
what
we
found
was
a
lot
of
times.
A
node
role
would
go
through
a
transition,
but
the
data
wouldn't
change
and
we
actually
want.
A
We
want
to
make
sure
that
we
aren't
showing
changing
changes
of
data
when
there
aren't
any,
and
so
one
of
the
the
optimizations
that
Victor
made
was
to
take
the
data
for
that
node
role
and
put
it
into
a
separate
object.
It's
basically
a
it's
a
it's,
a
denormalization
of
stripping
away
the
data
on
the
on
the
expectation
that
we
only
need
to
change
that
data
that
that
that
notre
all
data.
A
If
it
changes,
so
don't
expect
the
data
in
the
nodal
data
to
be
updated,
expected
to
be
replaced,
it's
a
create
and
change
the
reference
approach,
because
we
never
want
to
throw
away
old
data
and
that's
what
that
that's,
what
that
model
does
a
lot
of
this
is
handled
transparency
transparently.
So,
if
you
look
at
the
node
role
model.
A
It's
going
to
get
where's
your
system,
here's
data,
here's
where
it
gets
data
system
data,
those
things
are:
it's
just
going
and
pulling
it
from
its
it.
Does
it
basically,
transparently
by
because
of
the
object,
relationships,
okay
and
so
there's
specific
methods
to
update
the
wall
to
update
the
system
data.
A
A
There's
code
in
the
attribute
file,
the
handles
looks
at
the
attribute
metadata
figures
out
what
type
of
data
it,
what
type
of
where
the
data
supposed
to
come
from
and
then
it
it
writes.
It
basically
writes
the
Jason
key
into
the
right
mapping,
location
or
extracts.
It
I'm
going
to
repeat
that
to
make
sure
it's
clear.
So
let
me
pull
up
a
template.
A
A
A
A
So
if
you
look
at
this
template,
this
template
is
adjacent
right.
This
is
eventually
going
to
become
no
droll
data.
An
overall
system
data
this
this
is
this
JSON
data
is
effectively
a
little
database
a
little
database
and
if
I
want
to
talk
to
the
least
time
for
my
DHCP
server,
the
data
is
60
right.
Mikey.
Does
that
make
sense?
The
attribute
is
60
the
there's,
a
mapping
crowbar
dhcp
lease
time.
That
is
the
key
for
that.
A
Correct
there's
there's
an
important
exception,
which
is
when
we
have
something
like
the
network,
which
is
using
the
database
to
store
this
I'll
show
that
too,
but
I
want
to
get
the
this.
This
is
the
ninety-nine
percent
case
is
when
we
store
it
as
JSON
data.
So
here's
there's
a
there's,
a
sustainability
problem,
which
is
that
not
everybody
you
don't
want
to.
A
If
somebody
changes
the
Jason
map,
then
everything
breaks,
because
what
we've
the
danger
here
is
that
we
end
up
coding,
crowbar
dhcp,
server
least
time
into
everything,
write,
cookbooks
and
recipes,
and
this
and
that
and
then,
if
we're
using
an
upstream
cookbook
that
doesn't
want
to
use
crowbar
dhcp
lease
time
as
their
guess,
their
index
we're
stuck,
and
so
we
we
had
to
come
up
with
a
way
to
abstract
that
out
and
that's
what
the
attributes
are.
So
the
attribute
system
where
did
I,
where
is
it
a
trabajar,
what
the
atropine
and
it
maps?
B
A
Default,
oh
oh
yeah
I
might
not
have
gone
far
enough
down,
but,
okay,
I
don't
I'm
not
going
to
spend
more
time
trying
to
connect
these
two
points
that
sort
of
picked
at
random,
but
the
idea
here
is
that
when
I
create
an
attribute
here,
it's
going
to
map
into
this
thing,
so
I
could
go
to
provision
or
available
OSS.
I
should
be
able
to
go
to
the
provisioner.
A
Should
be
in
here,
oh
here
we
go.
This
one
is
a
lot
more
so
provisioner.
So
if
I
go
back
to
my
provision
or
e
mo
crowbar
provision
or
server
access
keys,
I
should
be
able
to
go
here
and
say:
perv.
It
crowbar
provisioner
server
and
there
should
be
an
access
keys
somewhere
in
here.
I.
Don't
know
why
it's
not!
Oh.
A
I
think
you're
right
key,
all
right
so
well.
This
is
actually
really
good
because
we'll
talk
through
how
you
make
these
into
reasonable
things,
but
Mike.
The
idea
here
is
that
this
map
allows
you
to
abstract
the
JSON
mapping
here
in
into
genera
came,
and
this
is
really
important.
So
this
key
is
attribute.
A
Key
becomes
this
mapping
that
mapping
becomes
a
looks
up
data
here
and
then
the
the
thing
that
that
got
added
recently
is
this
once
add:
attributes,
let's
see,
if
I
have
an
example
of
one
here
it
is
so
the
wants
attributes
is
smart
enough
to
when
it
composes
the
data.
It
looks
it
up
from
the
data,
finds
the
key
and
then
maps
it
into
a
new
vat,
a
new
path
so
that
you
can
control
how
the
data
is
injected.
C
A
There's
there's
a
couple
ways
to
override
it.
Yes,
so
this
the
template
is
just
the
the
base
is
the
default,
so
when
there's
there's
two
places
to
override
it.
So
when
you
put
a
role
in
a
deployment,
it
creates
a
deployment
role
model.
That's
this.
So
I
have
a
deployment.
I
add
a
role
to
the
deployment
that
action
of
connecting
deployment
and
roll
together
creates
a
deployment
role.
A
Deployment
roles
have
a
copy
of
the
template
that
you
can
modify
so
the
first
there's
the
first
level
of
override
from
default
says
that
when
I
create
a
deployment
that
that
relationship
copies,
this
template
into
that
and
then
I
make
I
can
make
copies.
I
can
make
changes,
so
I
could
then
come
and
say
instead
of
online
false.
I
want
for
this
deployment
to
be
online.
True,
where
I
want
to
use
a
different
web
port,
or
I
want
to
change
the
available
operating
systems
or
might
default
my
password
hash.
A
I
could
instead
of
changing
the
default.
When
I
create
the
deployment,
I
could
change
the
deployment
role
for
this
role
to
you
know
something
else
and
then,
but
that's
at
the
deaths
of
the
deployment
level.
When
I
actually
attach
an
ode
to
that
role,
then
it
creates
a
node
role
and
the
node
role
has
first
looks
to
its
own
data
store.
Then
it
looks
to
the
deployment
roles
data
store,
so
I
can
modify
it
here,
which
is
really
no
troll,
oh
and
then,
and
then
anything
that's
not
overridden
here.
A
A
A
Has
a
very
similar
concept
is
no
surprise,
there's
a
precedence,
it
pulls
data
from
the
date,
the
node
roll
and
then
it
from
the
deployment
roll
and
then
because
deployments
are
hierarchical,
it's
going
to
pull
data;
no
it
won't,
it
does
I,
don't
think
it
merges
from
one
deployment
roll
to
another.
It's
gonna!
It
only
goes
one
level
at
this
point
and
then
so
the
place.
Let
me
show
you
the
place
where
that
that
is
done
so
that
the
place
where
that
code
is
is
pulled
together
is
out
of
run.
A
A
A
A
This
is
really
this
is
this.
This
actually
tells
you
everything
you
need
to
see
in
a
way
when,
when
a
node
role
is
ready
for
the
to
be
handed
to
a
jig,
the
jig
run
method
is
called
and
the
jig
run
gets
a
node
roll
and
gets
the
data.
This
is
the
top-level
jig,
so
it
can't
do
anything.
A
jig
is
required
to
have
a
run
method.
A
So
if
you
look
at
the
let's
see
the
crowbar
jig,
it
actually
has
a
run
method,
and
then
this
is
this:
does
all
that
s
the
SSH
SSH
SCP
execute.
So
this
is
actually
the
script
jig
code
that
that's
doing
the
running.
So
if
you
want
to
see
where
script
jig
does
its
thing
it's
here,
the
chef
jig
is
here
in
the
chef
bar
clamp
and
it
has
its
own
preps
the
run,
and
it
runs
it,
and
this
this
does
all
of
the
chef's
actions
that
are
necessary
to
run
run.
A
A
So
what
happens
is
is
that
when
we're
about
to
run
a
jig,
we
call
that
those
those
merge
compositions
I'm
trying
to
find
I'm
trying
to
find
where
that
code
was
just
in
front
of
me
a
second
ago
here.
It
is
sorry,
so
the
node
roll
calls
this
these
data
prep
these
data
prep,
and
it
pulls
together
all
of
the
data
that
it
needs
based
on
the
cut
the
calls
out
of
here
and
some
of
these
go
back
into
the
role
and
do
it.
A
A
B
A
B
A
To
God
I
got
bugged
by
wat
by
seeing
it
to
do
in
there
every
time.
So
yes,
that
the
idea
would
be
in
these
in
these
just
in
the
discovery
right
here
you
would,
you
could
actually
validate.
We
know
the
node
role.
We
could
write
a
validator,
Jason,
validator
metadata
and
then,
before
you
accepted
the
discovery
data
you
could
validate
the
Jason
as
valid
Jason
before
you.
You
would
raise
if
the
Jason
wasn't
valid.
So
very
much.
Ok,
I'd
love
to
see
us
do
that.
A
It's
it's
very
doable,
it's
it's
a
matter
of
starting
it
out
right.
You
start
off
with.
Basically
anything
goes
schema
validation,
and
then
you
build
up
that.
You
basically
defend
yourself
as
you
found
issues,
but
since
everything
in
crowbar
runs
through
that
a
little
bit
of
Medicine
would
go
a
long
way
if
that
makes
sense
right,
because
ultimately,
every
every
time
you
exercise
any
changes
to
a
node
roll.
Your
do
you
have
to
update
that
data
to
some
extent
and
so
check
in
being
able
to
validate.
A
It
would
be
useful,
but
that's,
but
no
it's
a
great
it's
a
great
question.
This
is
exactly
where
you
would
do
it
and
you
could
you
could
and
so
and
there
and
there's
a
lot
of
ways
to
validate
this,
because
when
you
retrieve
the
object,
you
actually
get
back
the
Jason,
so
you
could
actually
make
you
could
you
could
do
it
after
the
fact?
But
I'd
really
like
to
see
it
done
here
and
it
could
be
done
very
in
a
very
dry
way.
I
mean
don't
repeat
yourself
where
you
write
it.
A
One
validation
approach
that
works
for
all
the
ways
we
set.
The
data
and
as
a
minimum,
we
could
probably
do
it
out
of
attributes.
Attributes
can
can
also
validate
that
they're
they're
valid,
but
I
do
historically
jumping
around
a
little
bit.
Historically,
it
was
faster
to
hard
code,
the
paths
we
knew
that
wasn't
a
long
term,
and
so,
if
you
see
hard
code
paths
in
here
understand
that,
ultimately
we
want
to
replace
them
for
these
semantic
attributes
and
use
attributes
to
do
all
the
mapping,
not
the
hard
coding.
A
I
would
you
know
this
is
one
of
those
places
where
I'm,
ok
with
the
technical
debt,
but
I
definitely
want
us
to
address
it
because
I
think
it'll.
So
one
of
those
things
where
it's
going
to
burn
us
and
I
hope
when
it
burns
us,
we
fix
it.
Then
we
put
in
the
semantic
checks
at
that
point.
It
might
be
sooner
rather
than
later
it
depends
on.
If
somebody
has
to
itch
itch
to
scratch.
I
will
say
for
the
record.
A
A
A
A
A
A
A
Atropine
the
server
role
this
well.
This
is
a
server
role,
but
that
would
that
would
show
up
that.
That
would
so
that's
the
trick.
Is
that
it's?
If
it's
passed
across
it,
then
it's
a
it's
a
dependency
in
the
chain,
and
so
what
you
would
do
is
we've
cheated
on
the
namespace,
the
flat
namespace
for
a
drugs.
A
A
A
A
It
does
show
up
in
crowbar
yamo
for
the
sequel
server
and
as
an
attribute
on
the
sequel
server.
So
yet
here's
the
thing,
that's
interesting
right.
You've
got
a
sequel,
client
and
it
needs
an
attribute
from
the
sequel
server,
which
makes
perfect
sense.
The
way
this
the
way
it
works
is
crowbar
when
it
resolves
the
attributes
is
going
to
look
up
your
dependency
graph,
your
node
roll
graph
to
find
the
nearest
attribute.
That
applies
to
the
one
you're
asking
for.
A
A
Right
but
the
at
all,
those
attributes
are
collected
from
its
upstream
dependencies
and
the
server
is
one
of
its
dependencies.
So
you
get
when
when,
when
that
attribute,
when
the
JSON
data
is
passed
to
you
with
your
attributes
in
it,
it
includes
the
upstream
server
attribute,
which
you
can
then
go
get.
A
A
A
A
A
So
let
me
break
that
into
two
problems.
One
is
the
crowbar
llamo
piece
and
then
the
next
one
is
the
piece
that
answers
I'm.
Going
to
answer
your
question:
by
showing
you:
how
do
we
generate
data?
That's
not
in
the
template,
so
you
have
to
have
the
so.
If
you're,
let's
say
your
sequel,
client,
sequel,
client
role
would
have
to
have
a
requirement
for
the
sequel,
server
role
and
then
the
sequel
server
role
would
have
to
have
the
would
have
to
produce
the
attribute.
A
Then
the
sequel,
client
role
would
have
to
have
would
have
to
ask
for
that
attribute.
So
in
this
case
the
provisioner.
So
let's
say
this
role,
so
here's
a
role
called
provisional
provision
or
repose,
and
it
wants
the
provisioner
package
repose
list
right
provision
or
package
repo
is
up
here
in
the
provision
or
server.
So
what
you'll
notice
is
the
provisioner
repo
role
has
a
requirement
on
provision
or
server
right.
So
this
role
that
wants
this.
This
attribute
must
have
this
server.
A
What's
ever
in
that
JSON
file,
the
things
that
we're
controlling
that
you
were
trying
to
limit
you
from
getting
is
all
the
upstream
Jason,
so
the
first,
the
early
version
of
crowbar
to
you,
would
get
all
of
the
Jason
from
all
of
your
upstream,
no
trolls,
which
is
a
big
set
and
and
and
and
had
no
abstraction
in
crow
bar
with
with
this.
In
with
the
attribute
system,
you
only
get
the
data
that
you
want
that
you
asked
for,
and
that
means
that
you
get
your
own
data
plus
a
much
smaller
set
of
Jason.
B
A
C
A
Ok,
so
so
I
want
to
I
want
to
hold
on
to
for
a
sec,
because
I
I'm
bound
and
determined
to
answer
Ragini's
question
from
this
morning,
like
what
I
want
to
I
want
to
pause
this,
because
I
want
I,
want
to
get
to
that
and
then
and
then
we're
clearly
going
to
do
more
and
we'll
go
back
because
I.
This
is
very
iterative
right.
A
A
A
A
So
there's
actually
an
object
created
when
you
said
you
haven't
attached.
Tenia
knows
yet,
but
in
the
deployment
you
now
have
this
this
relationship,
that's
a
deployment
role
and
that
the
action
of
creating
the
deployment
role,
copies
the
template
into
the
data
and
actually
copies
the
template
in
so
once
you've
created
a
deployment
role
that
you
can't
change
the
template
anymore.
You've
copied
it
now,
if
you
create
a
new
deployment
row,
little
recopy
the
template
from
the
role,
but.
A
So
all
of
these
on
methods,
you'll
notice,
they
don't
do
anything
except
they
did.
They
just
have
loggers,
so
the
default
role
class
has
stubs
in
there
for
responding
to
different
state
changes
and
also
note
creation
and
node
removal,
and
what
happens
is
every
time
when
you
add
a
node
role
and
the
deployment
role
actually
has
a
similar
stuff
nearness
on
deployment
create
on
deployment
delete.
A
So
all
of
these
on
things
happen
at
specific
times
on
deployment
creating
on
deployment.
These
two
are
our
and
I.
We
actually
have
some
docs
on
this.
These
those
methods
get
called
when
you
create
a
deployment
role.
So
if
I
wanted
to
change,
make
a
global
change
to
a
deployment
to
the
template
when
I
create
what
I
would
override
this
method,
so
on
deployment
create
I
can
actually
take
advantage
of
when
that
happens,
to
change
the
template
data
or
build
the
whole
darn
template.
A
A
A
We're
not
we're
not
actually
edit
we're
not
generating
this
every
time
it's
only
when
it's
created,
so
you
would
do
the
same
thing.
This
is.
This
is
the
actual
answer
to
Ragini's
question.
If
you
wanted
to
generate
a
password
for
a
sequel
server,
you
would
add
you
would
create
a
role.
You
would
create
an
override
for
the
sequel,
server
role,
just
like
I
did
here
so
bark
bark,
lamp
revision
or
OS
install
roll.
This
yeah.
A
A
Class
of
the
model
that
overrides
it.
So
if
I
wanted
the
OS,
the
provisioner
OS
install
to
use
a
different
class,
which
this
will
be
a
good
example
if
I
wanted
class
of
role
a
sub,
it's
a
subclass
of
role.
So
when
the
roll
is
when
I
create
when
I
import
the
provisioner
OS
role,
so
let
me
go
over
here.
A
A
Here
it
is
so
provision
or
OS
install
this
name
decomposes
automatically
into
provision
or
OS
install
this
this
role
name,
it
actually
looks
it
up,
and
so,
when
you
import
this
crowbar
yamo
and
it
hits
that
line,
it
goes
into
the
data
set
and
it
finds
that
that
role
and
it
actually
uses
tells
the
role
hey.
You
don't
don't
use
the
base
class,
use
this
override
class
and
then.
A
A
A
A
We
just
just
all
the
models,
follow
the
convention
and
coding
by
conventions
easy,
but
what
happens
is
is
that
when
this
node
roll
goes
through
the
proposed
state,
so
that's
basically
the
first
state
that
it
always
achieves
its
going
to
inject
this
data
into
that
into
that
neutral,
and
so
that
means
for
every
every
note
every
if
you
were
to
inspect
all
the
node
roles
and
that
in
that
deployment
they
would
all
have
this
piece
of
data
set
based
on
their
deployment
data
right.
So
it's
actually
going
to
look
up
deployment
data
which
deployment
data.
A
So
deployment
data
is
coded
to
actually
go
and
go
to
the
deployment
role
and
pick
up
its
top
level
data,
so
this
is
actually
potentially
redundant
because
it
should
do
that
automatically
anyway.
So
for
some
reason,
when
Victor
wrote
this,
he
decided
he
wanted
to
hard
code.
I
think
I
know
this
rationale,
but
he
actually
specifically
sets
the
target
OS
for
each
node
role,
but
this
is
where
you
do
so.
If
I
wanted
to
have
a
database
password
or
user
and
I
want
to
code
those
in
programmatically.
A
This
is
where
I
do
it
and
because
it's
code,
I,
could
look
up
information
from
other
places.
I
can
generate
it
and
store.
I
can
do
all
sorts
of
things
if
the
most
sophisticated
examples
of
these
are
in
the
network
bar
clamps,
where
we
actually
don't
store
Jason
at
all,
but
we
generated
all
dynamically.
So
in
those
cases
we
override
all
that
stuff.
A
It's
it
is
called
every
time
that
node
roll
goes
through
the
proposed
phase.
So
it's
that
it's
it's
one
per
post
is
really
helpful
because
it's
called
well
it's.
It's
really
called
when
the
users
before
the
user
changes
it
when
the
user
goes
into
proposed
state,
but
you
can
hook
off
any
transition.
So
if
you
want
to
do
validation,
you
could
actually
hook
into
the
on
sorry
on
to
do
event,
and
you
could
validate
that
everything
was
ok
on
to
do
when
things
go
active.
You
can
hook
into
a
lot
of
these.
A
A
A
This
is
something
that's
gotten,
a
little
fuzzy
to
me
and
I
love
to
have
Victor
help
clarify,
but
because
the
way
there's
I'm
not
on
what
Elena
we're
talking
about
that
this
morning,
I'm
going
to
defer
to
Victor
and
have
him
explain
when
we
use
the
wall
and
when
we
use
the
system
data,
because
I
think
that
we've
been
moving
away
from
the
wall.
We
don't
need
it
as
much
as
we
used
to
I.
Don't
I,
don't
know
if
that
answers.
A
A
Okay,
all
right
some
of
the
stuff.
This
is
a
little
fuzzy
and
I'm
committing
to
get
better
answers
for
you
on
the
system.
Sista
data
versus
wall
data,
because
we
have
to
resolve
that.
The
the
key
thing
that
I
felt
like
was
blocking
you
for
right
now
was
understanding
that
you
need
in
order
to
inject
a
password
or
any
other
generated
data.
What
you
need
to
do
is
you
need
to
take
your
proposed.
A
You
need
to
create
a
rollover
ride,
and
then
you
have
to
define
the
event
handler
for
dealing
with
that
and
there's
there's
actually
a
lot
of
really
good
examples
for
this
that
do
different
things.
So
this
one
sets
it
sets
the
target
OS
whenever
you
create
a
new
proposal
and
then
when
the,
when
that
node
role
is
transitioned,
it
goes
in
and
make
some
calculations
based
on
the
boot
environment.
A
So,
okay,
but
this
is
this-
is
the
place
to
look
to
make
those
changes
and
there's
a
there's
a
lot
of
places.
We
do
that
and
the
thing
that
I
would
point
out
is
there's
two
ways
to
do
it,
and
this
I
tried
to
document
this
clearly.
So
there's
the
in
the
dev
guide.
There's
there's
documentation
about
this.
If
you
have
a
very
specific
neutral,
like
OS
install,
you
can
create
a
new
role
for
it.
A
If
you
have
a
generic
one
like
network,
most
of
the
network's
actually
have
exactly
the
same
logic,
and
you
can
create
a
bar
clamp
network
role
and
the
system
will
automatically
resolve
that
as
a
default
also
and
if
it
doesn't
find
either
of
those.
It
goes
all
the
way
up
to
the
generic
role
and
you
don't
get
specialized
behavior.
You
just
get
generic
behavior.
A
Chris
Chris
can
tell
you
how
how
we
battled
against
some
of
these
concepts
in
the
first
first
version
of
khobar
to
and
and
some
of
that
that
work
we
we
salvaged
in
some
of
that
work,
we
had
to
rethink
based
on
how
the
how
the
relation,
how
the
injection,
how
we
ended
up
with
roles
which
is
a
new
cut,
which
is
a
different
concept.
We
didn't
start
with
crowbar
in
the
first
pass
at
core
part
2.
A
A
A
A
So
you
can,
depending
on
how
you
override
those
things,
there's
a
lot
of
places
where
you
can
decide
to
take
action
and
and
I'll
say
something
that
we
it
was
confusing
when
we
set
it
before,
but
I'll
repeat
it,
because
it's
worth
understanding
these
aren't
asynchronous
events.
So
all
of
these
on
event,
all
these
on
handlers
hand
are
a
run
as
part
of
the
code
as
putting
in
sequence
with
the
code
action.
A
So
they
don't
don't
expect
that
you're
going
to
be
able
to
take
a
long
time
doing
some
of
these
things.
They're
just
meant
to
basically
inject
data
or
check
things
or
do
a
test,
or
something
like
that.
They're
meant
to
be
small
small
checks,
anything
that
needs
to
be
asynchronous.
That
really
is
a
node
role
in
itself,
no
roles
are
asynchronous.
These
things
are
just
meant
to
provide
specific
overrides
for
nodal
behavior
or
no
change.
Behavior
deployment
change,
behavior.
A
A
Yes,
they
are,
they
are
all
within
the
transaction
of
changing
the
state
of
the
state
transition
or
of
the
action
that
they're
like.
So,
if
a
note
is
created
this,
the
oncreate
actions
must
complete
before
the
node
is
completed
or
deleted,
or
so
yes,
they
are
atomic
I
guess.
From
that
perspective,
I
I,
would
say.
They're
executed
in
sequence,
with
the
action
there
are
taught,
are
attached
to.
A
A
It's
any
any
role
of
any
sophistication
will
always
have
a
role,
sorry,
a
class
associated
with
it
in
a
bar
clamp
and
that's
why
you'll
notice,
even
though
I
brought
all
of
the
bar
clamps
into
one
repo
for
simplicity,
reasons,
I
still
kept
the
bar
clamp
namespaces,
because
otherwise
the
role
the
role
names
get
really
messy.
So
I
didn't
want
to
break
the
idea
that
the
these
models,
these
base
models,
are
in
the
base
directory
and
then
all
of
the
overrides
are
in
their
own
name
spaces.
So
this
the
models.
A
This
is
this
actually
true,
no
matter
which
version.
If
you're
in
the
crowbar
too
or
the
open,
crowbar
it's
the
same
model.
It's
just
collapsed
into
one
into
one
repo
in
Korean,
open
crowbar.
So
the
idea
is
that
the
models
here
are
the
base
models
and
anytime.
You
want
to
do
an
override.
You
always
create
a
namespace
by
convention.
It's
always
a
bar
clamp,
something
namespace,
and
then
the
overrides
go
in
that.
A
A
Yep
and
it's
not
doing
any
tests
to
make
sure
that
the
attributes
are
have
all
their
upstream
cement
I'm,
not
sure
that
we
would,
because
we
don't-
we've
been
trying
not
to
require
that
bar
clamps
have
all
their
upstream
requirements
when
they're
imported.
We
allow
that
to
be
done
after
the
only
at
deployment
time.
That's
a
whole
nother
topic.
A
All
right,
everybody
have
a
great
weekend
over
the
weekend.
I
will
composite
this
recording
and
post
it
and
hopefully
it'll,
be
it'll,
be
useful
questions
and
I'll
do
before
I
go
off.
Actually,
maybe
I'll
do
at
nashua
we'll
do
another
one
of
these.
Let's
say
I'll,
try
and
find
a
morning
time
to
do
it
so
that
we're
not
so
unfair
to
the
island
folk,
but
we'll
do
another.
One
keep
keep
keep
the
train
going.