►
From YouTube: OpenStack DefCore Community Meeting 2 2014 07 16
Description
Review current status of DefCore for Havana Release
http://etherpad.openstack.org/p/DefCoreLighthouse.4
A
Ending
where
you
are
in
the
world
had
six
o'clock
pacific
time
and
the
focus
of
the
call
is
really
to
get
people
to
the
point
where
we
can
have
a
community
discussion
around
the
capabilities
chart
for
Havana.
So
this
is
a
Havana
focused
document
about
capabilities
and
which
ones
the
Deaf
Corps
has
identified.
Difficult
committee
has
identified
as
core
or
not
and
you'll
notice
I
haven't
put
in
the
course
we
got
from
the
tce
yeah
those
they
need
to
do
that
before
the
board
meeting.
A
But
in
order
to
have
that
conversation,
it's
important
to
walk
backwards
a
little
bit,
so
everybody
has
an
understanding
of
where
what
what
these
are
and
so
I'll
but
I'll
do
is
I'll
started.
I'll
do
a
couple
minutes
of
preamble
so
that
you
understand
you
know
we
sort
of
baseline
with
where
we
are,
and
the
things
I
can
do
is
talk
through
a
little
bit
more
on
the
timeline.
But
then
this
deck
is
designed
fact
of
Lee
to
do
the
same
overview
but
slower,
and
what
I
would
have
been
trying
to
reinforce.
A
Very
clearly
here
is
def
cores
about
commercial
use,
and
so
there's
there's
other
uses
we're
really
working
about
helping
vendors,
sell
OpenStack
products
and
have
the
user
community
who's
using
those
products
know
what
OpenStack
is
that's
what
that
supply
them.
I'm
building
here
is
about
a
deaf
course
about
helping
up
can
stack,
establish
its
brand
and
have
people
be
able
to
use
ignoring
the
name
in
a
consistent
way
and
that's
a
lot
of
such
about
interoperability.
A
It's
a
prot
ongoing
process,
that's
managed
by
the
board
and
we're
in
just
in
the
middle
just
the
beginning
of
starting
that
process
up
and
we've
identified
that
it's
composed
of
two
different
things:
there's
a
set
of
must
pass
tests
that
define
capabilities,
and
the
thing
we're
going
to
talk
about
today
are
the
capabilities
that
are
required
for
Havana.
So
of
all
the
capability.
A
You
must
also
include
the
designated
sections
of
code,
and
that
could
be
none
or
something
we'll
talk
about
that
a
little
bit
and
usually
that's
that
ends
up
being
a
good
cue,
a
part
of
the
QA
when
we
talk
about
it,
I'm
interested
in
feedback
on
this
graphic,
so
I
pulled
together.
This
graphic,
specifically
for
this
presentation
and
Mondays
and
I,
think
it's
going
to
be
useful
to
explain
how
this
works
so
in
in
deaf
course
approach
to
core
and
it's
iterative,
so
free
every
release,
we're
going
to
adjust
the
definition
based
on.
A
What's
in
that
release,
we
look
at
the
integrated
release,
nothing
more,
nothing
less,
and
in
that
integrated
release,
we
identify
core
capabilities,
which
is
a
subset
of
all
the
projects
of
each
project,
and
not
all
projects
will
have
core
capabilities
in
the
matrix
that
we're
looking
at
neutron
has
two
core
capabilities
specifically
and
then
things
for
Havana.
There
really
wasn't
enough
test
coverage
of
other
things
like
key,
even
be
on
this
list.
A
Others,
the
orchestration
is
actually
here,
but
for
the
most
part,
it's
your
compute
consume
objects
or
things
like
that
and
then
within
each
one
of
those
projects,
the
components
of
the
code
that
we
designate
as
needed.
So
you
must
use
if
you
want
to
be
an
open,
SEC
product
and
it
is
possible
to
have
projects
of
none
and
like
Keystone
is
one
that
most
people
understand
will
not
have
any
designated
code,
because
there
are
implementations
in
the
field
that
have
fully
replaced
Keystone,
but
yet
have
API
compatibility.
A
So
it's
sort
of
these
two
pieces,
API
compatibility
and
designated
code,
and
that's
been
really
important
because
as
a
community,
we
don't
want
people
to
just
emulate
the
api's
and
say
hey,
that's
great.
What
we've!
What
we've
recognized
is
that
that's
from
here
is
that,
in
order
to
have
interoperability,
we
have
to
be
able
to
validate
that
the
code
works.
What
people
expect,
but
there's
also
a
common
implementation,
need
sort
of
inherent
in
the
way.
A
Openstack
is
designed
that
we
really
expect
you
know
people
to
use
shared
code,
and
so
what
we're
trying
to
do
is
define
what
that
looks
like
it's
only
the
Deaf
core
committees
taking
up
over
the
next
couple
weeks.
We
spent
a
lot
of
time
on
it.
So
I
think
we've
got
a
pretty
good
idea
and
this
graphic
helps
explain
what
is
designated.
Not
so
the
white
coat
is
designated.
B
A
Reference
of
limitations
aren't
necessary
designated,
but
there
are
part
of
what
we
expect
to
see
in
the
in
the
code
base
part
of
the
principles
for
deaf
core
and
then
things
that
would
not
be
designated
are
things
like
extension.
Api
is
things
that
we
said
are
going
to
be
replaced
things
we're
deprecating
or
vendor
the
new
actual
vendor
code
isn't
designated
so
we'd
have
a
serious
problem
with
OpenStack,
if
you
required
say,
and
I
sierra's
plug-in
to
achieve
the
core
capabilities.
A
We
get
into
this.
This
then
dives
way
down
into
a
lot
of
the
other
things.
This
is
the
principles
we've
got
through
the
thought,
not
I'll.
Let
you
do
your
own
reading.
If
you
want
on
that,
but
this
graphic
sort
of
sums
up
the
way
things
go
for
this.
So
what
we're
saying
is
there's
two
vectors
designated
code
and
tests.
If
you
don't
have,
if
you
don't
have
poor
capabilities
the
must-pass
test,
then
the
designated
code
doesn't
really
apply
to
your
to
that
project.
So
OpenStack
brand
is
both
of
those
things.
A
Misconfigured,
isn't
it
is
an
interesting
statement,
so
it's
the
tests
are
failing,
but
I'm
using
the
code.
So
if
the
tests
are
failing
and
you're
using
the
code,
you
you
are
doing
so
wrong.
There's
a
future
compatible
mark
that
we
were
talking
about,
but
this
we're
not
at
yet
which
says
that
I
passed
the
test,
but
I
don't
use
the
designated
code
and
then,
if
you're,
not
passing
a
test
or
using
the
code
you're,
just
not
even
better
I
could
see
the
anti
case.
Yep.
Thank.
C
A
A
So,
and,
and
then
what
we
did
with
this
slot
was
we
pulled
this
into
some
actual
examples,
and
not
this
is
this
was
the
talk
we
already
gave
and
it's
recorded
and
I'm
not
going
to
try
and
explain
this
week.
I
can
go
back
through
this
and
explain
it.
Although
this
the
example
helps
so
Nova
has
core
capabilities
and
designate
code.
A
Have
core
capabilities
but
not
designated
code,
and
then
we
have
examples
in
here
where
they
don't
have
any
code,
but
they
are
still
gonna.
They
still
open
sac
projects,
but
someone
like
trove
might
not
have
designated
code
or
tests.
But
if
you
deploy
it,
this
karma
is
it's
a
great
thing
to
deploy
projects
that
aren't
core.
That's
part
of
how
things
become
core
is
by
having
people
use
them
and
adopt
them,
but
at
the
same
time
we
don't
want
we're
not
throwing
things
into
core
unless
we
actually
are
expected
to
defend
it
at
the
Bay.
A
A
Good
phrase,
so
what
we
did
was
this
process
can
get
very
I'll,
make
this
bigger
to
this.
The
process
we
started,
it
was
I,
wouldn't
say,
confrontational.
I
would
say
that
there
were
a
lot
of
different
opinions
that
didn't
align,
and
I
guess
that
does
be
confrontational,
so
we
were
trouble
converging
on
what
is
core.
It's
not
core,
and
so
we
broke
the
process
down
into
smaller.
A
The
board
can
overrule
these
scores
if
we
feel
like
there's
a
need,
however,
that
this
is,
if
we're
doing
that
on
a
regular
basis,
we
have
a
serious
problem,
and
so
what
we
do
is
we
put
all
these
capabilities
in.
We
took
a
first
pass
at
the
capabilities,
are
backed
up
by
tests,
but
I
have
I,
actually
have
a
page
up,
I'm
going
to
go
out
a
full
screen
again.
A
You
I
think
I
put
this
if
I
didn't
put
this
link
in
I
do
want
to
have
this
link.
Inning,
there's
actually
a
deaf
course
section:
we're
going
to
move
this
a
little
bit,
but
there's
a
JSON
file
that
says
each
capability
and
what
tests
are
in
each
capability.
So
the
capabilities
are
not
are
not
fabricated.
Out
of
out
of
bored
fantasy
they're
actually
built
out
of
a
technical
decision
about
which
test
coalesce
to
a
capability
of
our
expectations.
A
That's
really
a
community
activity
scoring,
however,
will
be
something
that's
managed
by
the
deaf
core
midi
on
an
ongoing
basis,
and
so
the
sort
of
the
purpose
of
this
meeting
is
to
introduce
exactly
this.
This
whole
concept
that
we
have
set
of
capabilities
supported
by
tests
and
underlined
that
have
been
scored
through
deaf
core
and
then
reviewed
by
the
TC
in
the
place
where
we
we
had
ambivalent
answers
or
we
could
make
a
decision,
and
so
from
that
perspective
we
came
up
with
a
clear
set
of
tests
that
we
felt
were
core.
A
What
we
really
love,
give
people
a
chance
to
say
wait.
This,
doesn't
you
I,
don't
understand?
What's
going
on
answer
questions
and,
and
if
their
concerns
raised
them
and
I'll
say
this
multiple
times,
if
you
don't,
if
you
think
of
it
later
work
available,
this
isn't
you
are
not
closing
this
down
and
locking
it
today.
It's
this
is
our
ongoing
evolutionary
process
and
we're
giving
people
a
lot
of
time
to
digest
the
implications
and
the
choices.
B
B
C
A
A
The
shower
I
can
hear
you
fine.
Now
it
was
Jeff
it
wasn't
you
if
you're
adjusting
your
sound
okay,
I
twiddle
I
tweaked,
my
my
headset
in
it,
it
fixed
it.
Yes,
there
is
a
concept
of
waiting.
However,
right
now
we
haven't
done
any
so
in
the
principles
that
set
this
up.
We
said
we
could
wait
test
differently
or
criteria
differently.
We
did
them
all
even
and
results
seem
plausible,
so
we
reserved
we
reserve
the
right
to
wait
differently,
but
for
now
or
not.
B
A
That
that
would
be
exactly
the
type
of
thing
I
would
like
a
lot
of
eyes
to
look
at
in
this,
and
we
have
some.
We
have
some
tests
with
some
criteria
that
are
designed
to
address
that,
so
it
is
a
proximity
column
that
last
column
on
the
right.
The
idea
with
that
is
that
it's
actually
used
to
bring
in
adjacent
function,
so
you
would
actually
score
up
an
API
that
was
necessary.
B
A
Because
there
is
it's
very
possible
that
there
is
a
that
there
is
a
test,
there's
a
capability
that
that
is
implied
as
required
in
this
list,
although
I
don't
think
they're
I
think
we've
passed
through
it
once,
but
I'm,
confident
that
we
missed
things
as
much
as
we've
spent
time
with
this.
So
additional
review
is
necessary.
Okay,.
B
B
You
so
yeah
I
mean
that
my
reaction
is
this
is
fantastic
I
want
to
I,
want
to
take
this
away
and
sit
down
with
my
fellow
Cisco
card
architects
and
and
spend
a
couple
of
hours
just
drilling
into
it,
a
lot
of
decisions,
we're
making
and
then
get
back
to
you
on
that
I
mean
that's
the
that
that's
that
I'm
not
I'm,
not
going
to
trust
myself
to
come
up
with
all
the
way
on
with
a
useful
answers
on
the
fly
in
the
call,
but
this
is
going
to
be
very,
very
important.
Thank.
B
B
A
So
this
this
list
is
going
to
so
everything
is
designed
to
have
to
not
create
high
blood
pressure.
Although
deadlines
are
important,
this
list
is
going
to
the
board
on
Monday
sorry
Tuesday
to
be
proved,
as
did
advisory
list,
which,
which
means
the
first
we're
not
enforcing
this
core
definition
for
Havana.
What
we're
doing
is
we're
asking
people
to
measure
this
list
against
their
products
and
come
back
and
stay.
Oh,
this
would
suck
or
okay
we're
cool
with
it.
B
A
In
and
I'll
link
it
back
into
the
wiki
theater
so
in
this
is
actually
this
on
the
OpenStack
wiki.
This
is
actually
a
board
approved
document,
and
so
this
has
that
for
the
four
major
sections
and
then
each
section
it
has
a
sentence
describing
what
these,
what
these
are,
what
they
need
and
there's
there's
deeper
discussion
around
these.
If
you
need,
if
you
need
to
find
that
my
blog
great.
B
A
C
A
It
could
but
there's
actually
a
source
document
that
I
used
to
generate
this
at
this
checking
file.
Okay,
that's
troubling!
So
there's
there's
a
google
drive,
although
let
me
find
it
that's
an
excellent
question:
there
is
a
google
drive
that
has
capability
score
matrix
in
it.
So
this
is
this
is
this?
Is
the
raw
data
and.
C
A
A
A
A
A
Would
so
I
would
love,
so
what
our
hope
was
is
that
the
ptl's
for
the
project
would
provide
somehow
I'd
love
to
see
friendlier
names
and
short
descriptions
of
what
he
capability
minute
and
if
they
felt
that
we
needed
to
reorganize
the
capabilities
and
switch
the
tests
around
I'm.
Okay,
with
that,
we
had
some,
we
started
this
process
with
John
Dickerson
on
swift
and
the
count
as
he
was
trying
to
create
capabilities
that
didn't
match
test.
So
the
balance
is
that
we're.
A
C
B
A
C
A
C
C
B
B
A
C
A
You've
documented
and
discoverable
are
important
capabilities
here
right
so
having
an
API
documented
is
just
as
important
to
us
as
having
it
able
and
complete
and
part
of
the
future
direction
right.
It's
it
we're
trying.
This
is
why
everything
is
equally
weighted
right
now,
we'll
turn
the
knob
over
time
to
adjust
behaviors
if
we
need
it,
but
we
very
clear
signals
to
the
community
what's
important,
so
you
guys,
you
got
me
excited
I.
Think.
B
Yeah,
this
is
good,
yeah
I
mean
I
think
this
is.
This
is
hanging
exactly
the
right
direction
here
and
you
know
the
I
know
that
I'm
going
to
need
to
be
able
to
take
this
process
and
our
results
and
make
them
comprehensible
to
c-level
executives.
And
so
you
know
the
more.
The
more
material
is
to
some
to
help
to
walk
through
that
process
and
explain.
What's
going
on
the
better
and.
A
Of
the
assistant
things
I've
tried
to
do
is
build
these
pictures,
not
those
best
pictures,
but
the
officials
that
help
people.
What
I
found
is
that
when
we
reach
it
is
it's
six
months
of
work,
and
it
you
thumb
it
up
in
a
picture
like
this,
that
these
these
tricks
842
executives,
really
really
easily
yeah.
B
A
B
B
A
Much
and
often
this
is
this
project
called
ref
stack,
which
is
designed
to
allow
people
to
take
do
a
test
result
of
their
a
test
run
of
tempest
against
their
a
working
cloud
and
then
upload
the
results
2shared
to
restack,
which
is
a
community
repository,
so
that
we
can
actually
start
collecting
past
data
of
which
capabilities
are
actually
working
in
the
field
and
so
we'll
be
able
to
actually
pull
in
some
real
data
about
these.
These
are
things
that
are
working
in
the
fields
are
not
working
from
a
deprecation
perspective
that
starts
to
get
tricky.
A
Just
like
just
like
test,
it's
going
to
be
a
release
by
release
things,
though
I
fully
expect
the
designated
code
to
change
release
to
release
as
as
the
project
changes
or
as
we
learn
things
about
the
project
and
a
classic
one
is
Swift,
generates
quite
a
bit
of
this
discussion
around
this
because
I
didn't
highlight
it.
It's
always
worth
highlighting
to
capabilities.
Forklift
are
in
the
core
list,
there's
an
objects
or
client
and
an
object,
store
object
and
an
objects
or
container
that
are
soaring.
A
Indicators
should
be
included
as
core
capabilities,
because
you
also
need
designated
code.
The
board
is
about
to
take
up
the
more
thorny
question,
which
is
case.
Lift
capabilities,
look
like
they
should
be
core,
but
because
there's
a
lot
of
implementations
of
OpenStack
that
don't
include
the
swift
code,
it
likely
would
have
a
zero
designated
section
in
Havana.
A
Swift
has
been
refactoring
and
I'll
end
becoming
more
modular
over
the
last
couple
listas,
and
so
it's
possible
that
in
juneau
we
actually
would
change
the
designated
sections
force
lift
to
and
to
include
some
code
where
before
we
didn't-
and
you
might
have
the
opposite
trend.
Also
cinder
has
been
refactoring
how
it
operates
and
it
might
have
less
designated
code
based
on
its
it's,
how
it's
refactoring
it's
this
driver,
I,
don't
know
that
I'm
not
saying
that's
the
case.
Yeah.
A
C
A
Where
are
we
actually
asset
score?
It
do
all
the
all.
The
work
can
come
out
with
a
final
recommendation
and
then
there's
actually
a
relief
valve
from
a
vendor
perspective
for
vendors
to
come
in
and
wait
a
second
there's
tests
that
got
added
into
this
release
that
aren't
make
sense
or
aren't
working
or
inconsistent,
and
so
there
is
a.
A
B
B
B
B
A
B
A
B
Think
I
touched
on
the
main
things
I
wanted
to
talk
about
that
I'd
really
need
to
dive
into
this
one
and
look
at
it
from
you
know:
one
things
I
needed
it.
We
have
this
big
intercloud
initiative
which
is
actually
plays
beautifully
into
this,
because
it
we're
really
focusing
on
the
interoperability
between
private
and
public
and
federated
opens
at
clouds,
and
so
you
know
getting
things
lined
up
around
around
interoperability
in
turn,
and
and
conformance
is
pretty
much
central
for
that.
We.
A
B
A
That
they
actually
suggested
it
probably
is
not
appropriate
for
for
us
to
include
his
core,
then,
which
is
a
good
feedback.
The
other
one
is
why
the
day
of
ones-
and
we
made
the
decision
halfway
through
the
process
that
non
only
to
include
the
nun
admin
api's
from
an
interoperability
perspective,
if
you're
using
a
public
cloud,
they're
not
accessible
so
may.
A
But
we
didn't
want
to
lose
the
scores,
so
we
anticipate
that
there
may
be
future
private
core
private
clouds,
those
that's
near
future
or
sub
mark-
or
something
like
that,
and
so
we
didn't
want
to
lose
the
the
score.
It's
just
like
the
other
side.
There's
a
pretty
clear
delineation
of
administrative
API
is
that
you
can
expect
to
see
in
every
cloud
and
ones
that
are
probably
less
common
or
you
still
going
through
the
maturation
process.
Yep.
B
One
thing
I
read,
expect
to
see
downs
in
it
in
a
future
version
of
this
is
going
beyond
the
capability
in
a
sense
of
things,
you
can
verify
our
API
a
tests
to
a
data
model
completeness
particularly
around
the
metrics
that
that
and
that's
going
to
be
that's
going
to
be
an
interesting
thing
to
to
figure
out
how
to
capture
and
score
all
that.
It.
B
B
Exactly
I
mean
one
of
the
one
of
the
one
of
things
with
one
of
the
things
that
we're
running
into
right
now
is
a
a
real
frustration
that
the
consistency
of
implementation
of
salamat
er
data
gathering
is
very,
very
poor.
There's
the
main
theme
the
plug,
bears
products
from
all
over
the
map,
and
it
would
be
very
nice
to
get
some
kind
of
core
data
model
consistencies
other
way,
so
that
we
can
so
we
actually
know
what
we
know
what
you
can
rely
on.
I.
A
I
think
that,
right
now
we
made
the
decision
to
have
all
the
test
results.
The
binary
yep,
but
in
early
conversations
that
we
were
actually
sort
of
sad
to
give
up
more
quantitative,
I
guess
would
be
qualitative
results,
not
quantitative,
but
we
would
love
to
be
able
to
start
incorporating
a
broader
test
test
data
set
into
this,
even
if
they
didn't
end
up
being
core
yeah,
and
my
hope
is
that,
by
making
tests
sort
of
the
interoperability
standard,
that
will
encourage
more
circulation
of
results
like
that
yeah.
B
A
B
B
Think
that
yeah,
I
think
this
I
think
I
think
there
is
a
need
for
a
kind
of
almost
a
kind
of
cookbook
of
which,
which
which
can
people
can
use
to
both
of
to
familiarize
themselves
with
the
process
and
ink.
When,
yes,
including
you,
know
how
they
click
through.
To
get
to
find
the
find
the
code
that
both
see.
A
C
A
C
A
B
A
We'll
definitely
submit
one
to
give
an
update
for
it.
Yes,
yeah
and
so
that'll
be
we'll
see
where
people
stand
with
voting.
We
don't
don't
really
have
a
section
for
you
generalized
stuff
that
you
need
to
know
about
OpenStack.
So
sometimes
these
sections
make
it
as
voted
in
a
sometimes
they
don't
whether
it's
important
or
not.
You
lose
out
to
the
lap
laughs
about
the
mirantis
title
about
goats,
dance,
olivos.
A
B
B
We
were
really
running
out
in
two
more
data
centers
of
the
next
of
the
next
couple
of
weeks
and
yeah,
and
this
is
absolute
significant
scale
and
the
year
the.
What
the
other
thing
that
I
really
wish
to
like
that
the
tests
are
testing
I
really
want.
This
is
nothing
to
do
with
Dudley
they
would
be,
and
with
with
with
fresh
back
on
and
decor,
but
I
really
wish.
We
were
doing
a
better
job
on
testing
a
bit
of
a
che
capabilities
and
even
snakes,
so
I.