►
From YouTube: DefCore Community Review #2 2015-04-21
Description
Second session, same basic content, discussing DefCore progress for the last 6 months
Slides: http://www.slideshare.net/rhirschfeld/community-defcore-presentation
A
Hello,
everybody
and
welcome
to
second
installment
of
the
community
review
of
death
Corps
for
what
we
call
the
scale
cycle.
So
this
is
pre.
Vancouver
summit
will
spend
about
30
minutes
going
giving
you
some
history
about.
What's
going
on
with
deaf
core,
with
the
focus
on
the
latest
changes
and
then
we'll
open
up
for
questions
and,
of
course,
we'll
take
questions
in
the
back
channel
as
we
go
and
follow
along
we've
uploaded
the
presentation
to
to
SlideShare
so
you're
welcome
to
watch
it
there
and
you're.
A
Listening
to
this
offline
you're
going
to
be
listening,
the
recording
there's
another
recording.
You
want
to
double
down
on
learning
about
deaf
cork.
So
let
me
get
just
roll
ahead
and
get
started
actually
I'll
start
with
here.
So
def
course
mission
its
name
def
core
to
maybe
a
unique
searchable
topic.
Our
mission
is
to
define
what
is
OpenStack.
A
So
it's
the
core
of
OpenStack
is
the
idea
and
we're
going
to
talk
a
little
bit
about
what
that
means
and
what
context
it's
we're
discussing
it,
and
the
objective
of
this
presentation
is
specifically
to
engage
the
community
to
review
what
we
call
the
2015
a
process.
So
in
Vancouver
the
board
is
going
to
approve
the
official
def
core
process
which
defines
how
the
board
manages
core.
We've
spent
the
last
18
months
if
you've
been
tracking
def
core
figuring
out
the
wattage.
A
So
that's
of
interest
to
you
and
we
spent
a
lot
of
time
figuring
out
our
principles
and
guidelines
and
how
the
process
was
composed.
We'll
talk
about
some
of
that,
but
significant
amount
of
work
went
into
sort
of
getting
that
ramped
up
so
that
we
could
define
how
the
process
should
be
managed
and
then
what
we
want
is
a
community
to
think
about
the
process
and
understand
it.
So
we
have
to
give
you
enough
background
something
you
read
what
we're
doing
it
makes
sense,
and
so
that's
that's
really.
A
The
objective
of
today's
presentation,
the
bitly
link,
will
take
you
directly
to
the
process
document,
which
is
reviewed
and
garrett
talk
about
all
those
components
to
it.
Before
we
get
down
into
the
details,
have
a
process
works?
We
need
to
bring
you
up
to
speed
on
desk
or
one
of
the
most
common
misconceptions
about
death
Corps.
Is
that
we're
trying
to
reach
in
and
tell
people
what
code
to
write
or
what
projects
to
use
and
things
like
that?
That's
really
not
the
intent
openstack.
A
That
sense,
the
code
itself
so
being
an
OpenStack
project
being
part
of
the
OpenStack
github.
Those
are
those
are
really
part
of
our
code
use
and
there's
open,
SEC
trademarks
for
that,
but
def
core
concerns
itself
with
its
commercial
use
of
deaf
course.
So
when
a
vendor
says
or
product
says,
I
am
open
back
this
or
I
am
an
openstack
cloud.
A
Those
uses
of
the
word
OpenStack
are
controlled,
so
they're
actually
managed
very
carefully
by
the
foundation,
and
so
the
foundation
needs
rules
and
governance
to
figure
out
when
people
can
use
that
mark
and
it's
incumbent
on
the
board.
The
board's
responsibility
is
to
make
sure
that
that
mark
has
value
and
that
it
means
something
in
the
market.
If
it
doesn't
mean
anything,
then
in
some
ways
the
foundation
itself
can
be
in
serious
trouble
about
about
what
it
does
and
how
it,
how
can
enforce
the
mark.
A
So
it's
very
important
from
that
perspective
that
the
foundation
and
the
board
maintain
commercial
control
of
what
OpenStack
is
and
there's
another
benefit
to
doing
this
right.
We
want
OpenStack
to
mean
something
it
should
matter.
It
shouldn't
just
be
a
matter
of
legal
enforcement
of
a
brand.
It
actually
should
mean
that
you
have
sign
that's
a
reliable
platform,
something
that
we
can
say.
A
A
A
Four
of
this
tech
products,
type
defining
must
test,
must
pass
tests
of
capabilities
and
designated
sections
of
code.
These
definitions
use
community
resources
to
drive
interoperability
by
creating
minimal
standards
for
products,
labeled,
OpenStack,
so
sure
definition
of
what
I
just
spent
the
last
couple
minutes
talking
about
this
sort
of
tries
to
capture
it
in
a
nutshell,
and
we're
going
to
spend
some
time
really
digging
into
must
pass
tests
and
capabilities
and
designated
sections
and
we'll
go
through
that
this
started
two
years
ago.
A
Hong
Kong
summit,
where
the
board
really
kicked
off
the
deaf
core
process
and
there's
I
have
a
blog
posts
and
actually
whole
video
is
dedicated
to
this.
This
one
picture
being
very
quick
summary:
it
defines
what
we're
trying
to
do
and
why
and
the
goal
is
that
we're
going
to
have
a
common
core
that
covers
all
uses,
so
there's
one
version
of
core
and
then
that
core
includes
specific
code.
So
it's
very
important
in
this
definition
that
we
don't
just
say
it's
an
API
only
it
includes
code,
but
we
allow
people
to
substitute.
A
Certain
parts
of
the
code
will
talk
about
how
that
works,
and
then
that
code
is
validated
by
test.
Those
tests
are
community
test.
The
foundation
is
not
a
certifying
agency,
it
uses
the
tests
that
are
in
the
repositories
in
the
code
base,
and
the
idea
is
that
some
of
those
tests
will
be
required.
You
must
pass
those
tests.
A
So
when
you
look
at
what's
going
on,
we
put
this
graphic
together
a
couple
of
months
ago
to
sort
of
explain
the
process
very
broad
terms
and
there's
three
three
core
elements:
community
vendors
and
foundation
board
to
this
to
this
process.
But
overall
we
really
want
to
make
sure
that
it's
open
and
transparent
right.
It
needs
to
be
balancing
all
these
concerns
and
one
of
the
ways
to
make
sure
it's
balanced
is
to
ensure
openness
and
transparency,
and
this
is
how
we
do
that
from
a
community
perspective,
we're
working
to
build
an
interoperability
map.
A
So
it's
really
important
that
the
community
be
able
to
express
these
are.
These
are
capabilities
that
are
important
in
OpenStack
and
widely
used,
and
those
are
the
ones
we
focus
on.
We
want
that
feedback
so
that
we
put
the
right
things
in
core,
doesn't
help
to
put
things
that
aren't
widely
adopted
in
core.
Let's
create
strains,
a
lot
of
friction.
Ultimately,
community
wrecks
the
tests,
so
we
don't
come
to
the
community
with
tests.
A
That's
actually
organically
comes
out
of
the
comedian's
one
of
things
that
we
try
and
create
a
testing
economy,
encourage
people
to
testing,
and
then
the
tests
we
work
with
the
community
to
define
the
test
into
capabilities
and
we'll
talk
about
how
tests
are
grouped
into
the
capabilities
and
capabilities
are
really
not
driven
by
oh
I.
Think
OpenStack
should
be
able
to
do
this.
They're
driven
by
these
are
tests
that
demonstrate
and
prove
this
capability
and
ultimately,
the
essence
of
def
core.
Is
that
tests
or
truth?
A
So
we
believe
that
testing
and
validating
results
is
the
way
to
achieve
interoperability
more
than
any
other
type
of
specification,
and
it's
worth
noting,
especially
in
recent
times,
we've
been
moving
to
make
tempest
not
the
only
source
of
tests,
so
while
tests
still
need
to
be
OpenStack,
tests
in
the
next
cycle
will
actually
be
opening
things
up
to
allow
non
tempest
tests
and
a
lot
of
tests
are
moving
around.
That's
in
itself.
It's
an
interesting
topic
that
we
spend
a
lot
of
time.
A
Discussing
vendor
responsibility
in
here
is
that
the
vendors
will
self
test,
so
they
need
to
run
the
results
themselves.
They
need
to
report
to
the
foundation.
We
work
to
be
very
clear
and
pass
fail,
so
the
required
tests
must
be
passed
for
you
to
be
interoperable.
There's
not
there's
nothing,
fuzzy
in
how
we're
defining
it
and
then,
when
the
vendors
report,
the
results
they
get.
A
You
know
those
are
publicly
available
results
and
then,
in
order
to
make
in
order
to
make
it
possible
for
us
to
have
a
wide
body
of
tests,
we
will
have
exceptions
and
there
is
an
appeals
process
in
the
in
the
testing.
So
vendors
can
tell
you
know
at
this:
test
doesn't
work
unless
you
have
kvm
as
a
hypervisor
and
I
use
hyper-v,
and
so
there
will
be
cases
where
we
have
to
make
exceptions
and
there's
a
process
for
that.
A
But
ultimately
you
must
test
your
implementation
of
OpenStack,
whether
it's
a
public
cloud,
a
private
cloud
or
something
in
between
to
use
the
brand,
and
that's
really
what
we're
driving
towards
that.
When
people
use
an
openstack
cloud,
they
will
be
able
to
say
and
test
it
against
a
common
set
of
tests.
A
A
The
foundation
is
managing
the
brand.
It
manages
products
and
vendors
and
enforces
forces
people
using
OpenStack.
The
board
is
a
governance
body,
and
so
when
the
board
says
this
is
core:
it's
not
the
board's
job
to
make
sure
that
the
vendors
follow
that
it's
actually
the
Foundation's
job.
So
there's
a
balance
in
this,
where
the
foundation
interacts
with
the
vendors,
the
board
can
sit
back
and
talk
both
the
vendors
and
community
sort
of
neutrally.
A
Okay,
a
lot
of
background.
What
is
the
deliverable
so
def
course
deliverable
is
something
called
a
guideline,
and
this
is
a
recent
change.
So,
if
you've
been
following
def
core
in
the
last
couple
months,
we
change
the
process
to
be
more
time
based
more
like
a
specification
unless
release
based
and
so
what
a
deliver
a
guideline
is
it's
a
simple
definition
of
what
capabilities
and
code
are
required
to
be
open
side
products,
and
this
is
a
sample
of
one
and
you
can
get
or
get
haven't,
actually
see
them,
2015
03.
So
it's
a
date!
A
That's
that
this
one
was
approved
in
March
of
this
year,
there's
a
2015
04
that
was
approved
in
April
or
expecting
a
2015
05
that
will
be
approved
in
May
and
it
says
very
clearly.
You
know
these
are
the
releases
that
are
covered
in
this
guideline.
Here
are
the
platform
components
so
that
we'll
talk
about
that
in
a
moment,
here's
the
things
that
are
the
required
capabilities
and
then
you'll
notice.
We
have
things
called
required:
divisor
e,
deprecated
and
removed.
So
in
the
process,
things
come
in
their
advisory
first
before
they're
required
and
their
deprecated.
A
It's
worth
also
noting
that
we
have
a
Jason
version,
Jason
is
the
authoritative
and
it's
very
detailed
with
a
lot
of
detailed
list
of
tests,
detailed
designated
sections,
and
then
we
summarize
occur
rst
plain
English
summary:
that's
what
it's
much
easier
to
review
that,
but
it's
a
higher
level
document
and
then
the
rest
is
consumed
by
our
sorry.
The
Jason
is
meant
to
be
consumed
by
the
automated
systems.
A
So
we
have
guidelines.
Guidelines
are
really
points
in
time.
Snapshots
and
this
graphic
is
designed
to
sort
of
help.
Explain
that
we're
on
a
cadence
to
release
guidelines,
the
goal
is
to
be
in
a
six-month
cadence
right
now,
we're
doing
monthlies
to
catch
up
will
drop
to
we'll
do
one
in
a
expect,
the
next
one
to
be
in
August
and
then
we'll
be
on
a
six-month
cycle.
I'll
talk
about
the
cycle
in
a
little
bit.
The
idea
here
is
that
a
guideline
and
deaf
core
itself
is
not
the
release
item.
A
This
is
why
we
switched
timed
items
not
release
items,
because
in
deaf
core
we're
really
not
trying
to
capture
the
latest
features,
just
the
opposite.
We
really
want
lagging
features.
We
want
things
that
are
gaining
popularity
and
are
widely
deployed
that
are
there
things
that
people
can
count
on
and
being
stable
and,
being
you
know,
sort
of
the
core
of
OpenStack
and,
if
you
think
about
it.
A
From
that
perspective,
we
will
pick
up
different
parts
of
each
of
releases
over
time
and
the
graphic
is
really
designed
to
show
that
there's
a
trick,
we're
a
trailing
edge
on
the
release
and
we're
not
even
all
of
the
release.
There's
parts
of
what
you
see
in
the
deaf
court
in
the
guidelines.
We
don't
even
cover
all
of
the
original
release
from
Havana
or
you
know,
Essex,
there's
still
things
for
those
releases
that
aren't
really
considered
court
or
additional
features,
and
we
can.
A
A
Another
visualize:
this
is,
if
you
look
at
the
guidelines,
we
have
this
progression
from
advisory
required
to
deprecated,
and
then
we
have
a
lot
of
different
pieces
and
parts
and
they
all
fit
together
so
releases,
and
actually
the
concept
of
release
is
getting
a
little
fuzzier
as
we're
moving
to
tags
and
that's
okay,
we
from
a
guidelines
perspective.
It's
really
a
date
perspective.
A
We
have
platforms
and
components.
The
OpenStack
platform
is
a
very
broad
term.
It's
very
general
use
of
the
trademark
components
are
subsets
of
the
functionality,
likes
compute
or
object,
and
then
capabilities
are
the
pieces
within
that,
so
a
test,
a
set
of
tests
that
define
an
API
get
rolled
into
a
capability,
those
capabilities
get
scored.
We
have
a
whole
process.
We
actually
spent
a
whole
six
month
cycle
talking
about
how
we
score
capabilities,
because
it's
so
high
stakes
as
to
what
api's
get
included
or
not.
We
want
to
be
very
disciplined
about
that.
A
We
have
a
12
point
scoring
matrix
if
you're
interested
in
that
it's
actually
a
big
part
of
our
cycle
in
this
process
and
there's
a
lot
of
blogs
and
material
that
we've
dedicated
to
that,
especially
in
the
last
cycle
where
we
approve
the
final
capabilities
and
their
designated
sections
are
parts
of
the
code
that
you
need
to
use,
so
you're
expected
to
be
participating
in
the
designated
sections.
Those
are
the
upstream
pieces
where
those
are
parts
of
the
OpenStack
product.
A
It
is
important
to
note
that
OpenStack
and
def
quarter
made
a
very
intentional
decision
that
def
core
includes
code
of
OpenStack,
and
it's
I
really
need
to
stress
this.
Not
everybody
agrees
with
this.
This
is
a.
We
have
a
consensus
position
on
designated
sections.
That
is
a
compromise
between
people
who
want
all
of
the
code
to
be
included
and
required
for
OpenStack
products
and
there's
people
on
the
other
side
who
only
want
the
API
is
to
be
required
if
you
pass
the
tests
and
that
should
be
good
enough
to
the
OpenStack.
A
A
A
A
So
Swift
has
vendors
who
only
sell
Swift
and
for
them
they
can
use
the
OpenStack
powered
object,
storage
trademark,
the
more
restricted
trademark,
but
they
can
sell
Swift
without
selling
Nova,
and
we
have
people
in
the
community
who
sell
novo
without
selling
Swift,
so
they
would
be
an
open
OpenStack
powered
compute
platform.
Sorry
open
psyched
are
compute
and
they
could
use
that
mark.
If
you
do
both,
then
we
have
a
lot
of
vendors
who
do
goals.
A
Then
you
can
be
an
open
site,
powered
platform
and
you
have
a
ISM,
it's
a
more
liberal
use
of
the
OpenStack
brand.
Once
again,
the
foundation
enforces
this
and
actually
grants
people
use
of
the
trademark
and
and
helps
them
figure
out
how
they're
allowed
to
use
the
word
OpenStack
it's
a
controlled
word.
A
The
purpose
here
is
to
show
that
we
have
these
two
levels
and
that
is
reflected
in
the
Deaf
core-mark.
It's
a
little
bit
different
than
when
we
started
this
whole
process.
We
thought
they'd
sort
of
you,
one
OpenStack,
if
you
think
about
it,
this
is
sort
of
saying
their
sub
open
stacks
and
then
there's
a
master
platform
OpenStack,
so
we've
actually
adjusted
from
principles
based
on
feedback
from
the
community.
Here,
in
the
previous
session,
somebody
called
out
Keystone
as
a
TBD.
A
It's
worth
noting
in
the
way
the
guidelines
work
is
the
foundation
enforces
that
the
vendors
must
certify
against
one
of
the
last
two
guidelines
so
right
now,
five,
so
2015
03
and
2015
04.
Those
are
the
current
to
guidelines,
neither
of
them
have
Keystone,
and
so
vendors
could
certify
products
that
didn't
include
Keystone,
Keystone's
advisory,
so
in
the
2015
05
advisory
that
will
deprecated
the
2015
03.
A
If
you're
looking
at,
if
you
want
to
get
down
into
details,
the
way
we
work,
this
is
when
we're
working
on
the
next
guideline.
We
call
it
dot
next,
so
2015
next
is
where
we're
working
on
the
next
guideline.
If
it's
not
approved
in
May,
then
that
guideline
might
become
the
June
or
July
or
August
guidelines.
A
Okay,
it's
very
day
based
the
networking
pieces
are
something
will
bring
up
later
rocky
the
great
question
and
it's
one
of
the
things
that
we're
going
to
be
discussing
in
the
next
cycle
after
Vancouver,
because
it
creates
some
challenges
so
which
coat
gets
designated
concept
a
designated
code.
People
get
confused
just
because
the
wording.
A
The
idea
here
is
that
it's
the
picked
code
and
we're
not
a
no-no
instance
here
is
the
foundation
being
asked
to
become
a
police
force
and
show
up
on
site
with
to
do
you
know,
code
inspections
and
figure
out
line,
so
it's
designating
is
mentally
guidance.
It's
not
meant
to
be
use.
This
line
of
code,
don't
use
that
line
of
code,
but
the
idea
is
basically
the
upstream
common
shared
code
is
designated
and
we
have
just
like
everything
else.
We
actually
have
principles
and
guidelines.
C
A
A
That's
been
a
big
part
of
nailing
down
the
process
as
understanding
how
we
make
decisions
about
this
and
what
rules
we
use.
But
that's.
This
is
what
it
comes
down
too.
So,
there's
certain
code,
that's
designated
certain
code,
that's
not
designated
it's
a
community
engaged
process,
but
ultimately
the
board
is
responsible
for
deciding
which
code
is
in
in
which
code
is
out.
A
So
capabilities
I've
talked
about
capabilities
a
lot.
This
is
this
is
really
designed
just
to
help
you
visualize
what
we're
talking
about.
So
we
create
a
cat
capability
block
snapshots
and
in
that
capability
there's
a
list
of
tests
that
must
be
that
are
included
in
that
capability,
and
so
you
can
go
very
clearly
back
and
say:
you
know,
create
virtual
machine.
Create
machine
is
the
capability.
These
are
the
tests
that
validate
that
capability.
A
If
somebody
writes
new
tests,
we
can
include
them
in
that
capability
and
continually
make
our
definitions
of
capabilities
stronger
and
more
robust
by
adding
more
tests.
And
if
new
capabilities
are
added
to
the
product
then
or
individual
projects,
then
we
can
will
group
them
part
of
the
deaf
course
activity
and
then
score
them
to
figure
out
if
they
become
required
or
not
required
capabilities.
So
you
can
group
tests
all
the
tests
can
be
grouped
into
capabilities,
but
not
all
the
capabilities
become
required.
Capabilities
and
I'll
remind
everybody
that
you
don't
become
a
required
capability
overnight.
A
You
have
to
be
advisory
for
at
least
one
guideline
cycle
and
then
what
we're
working
towards
is
not
limiting
tests.
The
Tempest,
so
any
tests
that
are
in
the
OpenStack
domain
could
become
added
and
capabilities.
You'll
see
if
you
look
down
at
the
Jason,
we're
actually
modifying
the
JSON
schemas
to
accommodate
test
from
different
sources.
And,
of
course,
if
you
think
about
these
tests,
their
code,
they're
managed
by
code,
we
actually
have
to
know
which
test
which
point
in
time
which
test
is
being
used.
A
You
alright,
so
now
gives
a
lot
of
background
it's
time
to
go
and
dig
into
what
the
2015
a
process
is
and
we'll
running
a
little
bit
slower
than
I
did
last
time,
but
this
will
so
another
five
or
ten
minutes
and
we'll
be
really
ready
open
for
questions
if
you
haven't
seen
one
this
is.
This
is
a
picture
of
an
Austin
conference
shirt
of
one
out
of
the
archives
for
people,
so
the
2015
a
process
I'll
remind
the
goal
here-
is
not
to
define
every
single
thing.
A
It's
meant
to
you,
make
sure
that
we
understand
the
rules
that
we're
playing
by
and
there's
some
room
for
wiggle,
and
actually
it's
been
important
that
these
are
humans,
doing
the
process,
not
machines,
and
so
we
want
to
keep
people's
judgment
in
the
middle
of
the
process.
Listen
and
you'll
think
you'll
see
that
it's
been
one
of
the
fun
discussions
we've
had
as
we've
tried
to
craft
the
rules
within
the
process,
so
we've
broken
the
process
down
into
time.
It's
much
easier
to
understand.
C
A
It's
this
is
this
to
me
is
a
really
fun
time
where
we're
evaluating
the
new
stuff
and
things
are
very
fluid,
and
there
are
a
lot
of
great
conversations,
but
once
we
come
up
to
that
solid
draft,
then
it's
expected
that
the
broader
community
can
look
at
it.
So
vendors
can
start
testing
against
the
lifts.
They
can
start
saying:
hey
this
works
from
here
doesn't
work.
A
They
could
actually
start
trying
to
validate
their
product
and
getting
the
you
know
being
prepared
for
that
guideline
to
go
official
and
be
officially
blessed
against
that
that
guideline
and
that's
what
happens
at
the
end.
So
after
the
top
draft
is
presented,
then
we're
really
in
a
review
cycle
during
that
review
cycle.
You
know
we'll
deal
with
exceptions
and
community,
but
ultimately
it's
going
to
be
presented
to
the
board
and
the
board
will
or
not
approve
the
guidance
for
the
most
part.
A
A
When
you
look
at
those
for
those
us
six
months
cycles,
they
break
down
into
four
phases
so
sort
of
detailed.
That's
already
you
have
guidelines
draft
phase
and
if,
when
you
look
at
the
actual
text
of
what
we've,
what
we've
put
together,
what
you'll
see
there
is
there's
a
is
B,
C's
and
DS,
so
the
guidelines
straf
face
has
the
rules
for
that.
The
B
section
talks
about
godland
review,
which
is
really
where
we're
transferring
you
know
into
a
different
different
mode
of
operations
at
in
the
C
phase.
A
It's
real
talk
about
how
we're
going
to
get
community
and
vendor
vendor
feedback,
and
then
the
approval
talks
about
the
details
of
what
it
actually,
what
who
approves
it
and
how
they're
approving
any
things
like
that,
so
it's
a
whole
bunch
of
who
does
what,
when
and
what
their,
what
their
limitations
are
and
how
results
get
posted
and
I
didn't
bring
in
a
copy.
It's
left
to
the
reader
to
review
the
document
itself,
which
is
exactly
what
we
want
you
to
do.
So
it's
really
important
for
people
to
take
a
look
at
that
document.
A
Understand
it
enough
to
say
this,
make
sense
to
me
or
not,
and
we
are
now
at
a
point
where
vendors
are
validating.
We've
had
our
first
I
know
of
at
least
one
vendor,
who
is
validated
I'm,
not
at
liberty,
to
a
pre
announced
that,
but
we've
had
vendors
going
through
this
process
and
validating
their
products.
A
Users
can
come
back
and
should
come
back
and
ask
vendors
if
they
validated
and
how
they've
passed
and
actually
see
the
results
and
find
out
where
you
know
where
they
are
in
this
process,
because
the
users
asking
for
it
is
going
to
drive
interoperability
much
faster
than
the
foundation
trying
to
enforce
it,
and
we
need
help.
We
need
review
of
the
of
the
guideline.
We
need
review
of
the
designated
sections
and
you
can
even
help
by
running
tempest,
and
then
you
know,
sharing
your
results
and
figuring
out
what
things
are
working
or
not.
A
There
was
a
project.
There
still
is
a
project.
Kathryn
and
rocky
are
both
on
than
they've
been
instrumental
on
this
on
the
project
club
restack
ref
stack
was
much
more
coupled
to
deaf
core
in
the
past,
we've
separated
the
projects
a
little
bit
as
we
as
we
sort
of
grown
and
figured
out
what
what
logistics?
A
We
want
to
hear
when
you
don't
agree.
We
want
to
be
in
discussions
with
you,
but
we
also
want
to
hear
when
you
do
agree.
It's
really
important
for
this
process
to
be
approved
by
the
community,
not
just
passively
accepted,
because
at
some
point
we're
going
to
have
to
tell
people
know
and
we
need
the
community
say
hey
you
know
this
is
this
is
the
way
to
govern
it?
This
makes
sense
to
me
so.
E
A
Support
positive
and
your
feedback
negative
is
really
helpful
for
us
building
a
good
process,
building
a
great
community
and
with
that
I
have
a
couple
of
links
and
references
for
people
to
use
because
I've
been
doing
def
gore
for
so
long.
My
blog
has
a
lot
of
material
to
go.
Go
through
good.
Chris
is
posting
a
link
about
information
on
reporting
I'm
going
to
open
up
the
mics
for
a
second
Chris
I'll.
Let
you
talk
about
that.
Chris
Chris
hoga
is
the
the
foundation
representative
secretary
of
the
Deaf
cork
communities.
B
B
You
know
successfully
run
the
Deaf
core
tests
and
then
work
with
us
to
you
know
on
identity
and
reporting
that
back
to
the
community
and
so
right
now
all
of
the
OpenStack
powered
trademark
agreements
going
forward
are
going
to
be
required
to
to
pass
the
the
current
deathcore
tests
and,
in
particular
for
the
for
the
Vancouver
summit.
We're
going
to
be
highlighting.
C
B
A
A
E
A
A
Is
and
so
we
felt
at
the
time
these
we
did
the
work,
the
first
pass
of
work.
We
didn't
none
of
neither
know
the
network
nor
Neutron
were
passing
the
the
capability
so
that
the
tests
that
we
had
didn't
didn't.
Another
capability
scored
high
enough
because
of
adoption
or
stability
for
us
to
put
them
in,
and
we
started
having
some
discussions
about
making
them
their
own
components
and
then
making
potentially
an
or
component.
So
you
would
have
a
OpenStack
novanet
component
and
I.
Don't
this
isn't
work
out?
A
D
A
A
D
E
A
Only
something
fun
on
them
and
you
know
so
if
you
have,
if
you
have
a
position
on
it,
think
it
through
there's.
You
know
we
definitely
need
networking.
I
haven't
heard
anybody
disagree
with
that
statement.
We
need
to
have
networking
included,
but
it's
much
much
much
less
clear
how
to
accommodate
the
drift
between
neutron
and
neva
net,
both
an
adoption
engine
and
functionality.
Rnap
eyes,
yeah,
unbelievable
here,
Morgan
and
river.
Do.
B
On
the
networking
side
to
one
of
the
things
that
that
that
they
need
to
consider
is
that
they're
actually
in
order
to
test
that
implicitly
depend
upon
networking
just
like
there
are
a
number
of
tests
that
implicitly
depend
upon
identity,
and
so,
even
though
networking
is
not
explicitly
required,
its
implicitly
required
and
I
think
that
moving
on
down
the
line,
we're
going
to
see,
you
know
more
of
these
more
direct
testing
of
these
capabilities.
But
you
know
right
now.
This
is
we're
at
a
pretty
good
place.
A
It
could
be
the
opposite
and
until
we
start
collecting
test
results
that
include
non
core
capabilities
to
me,
that's
always
been
a
goal.
The
vendors
would
report
capabilities
even
if
they
weren't
core,
then
we
actually
have
data
to
say.
Okay,
we
should
include
another
net
or
we
should
include
neutron
or
maybe
both
it
could
be
a
50-50
split.
A
E
A
D
In
terms
of
peso,
so
based
on
my
experiences
testing
a
non-death,
that
cloud
is
greatly
depending
on
the
number
of
failure
that
you
have.
A
lot
of
the
failure
is
depending
on
because
of
configuration
on
both
the
cloud
side
and
also
the
tempest
side.
So
the
test
time,
if
we
you
test
the
whole
test
suite
the
test
time
could
take
from
one
and
a
half
hour
24
hours.
D
So
so
there
is
some
some
test
time
there,
but
since
this
is
a
test
that
you
start
and
it
will
test
by
itself
it
it
makes
sense
to
test
the
hotel
suite
so
that
we
can
collect
data
and
that
the
number
of
highest
tests
that
path
that
I
have
seen
past
so
far
on
the
D
on
the
major
project,
what
I
mean
major
project
is
compute
Network
glands
and
it
doesn't
include
bare
metal
data
processing.
Messaging
of
that,
the
highest
number
I
have
seen
so
far
would
be
around
1,300
test
case
past
yeah.
D
C
D
A
Well,
one
of
the
the
hopes
that
I've
had
in
this
process
would
be
that
people
would
leave
the
tests
on
and
we'd
start
seeing
past
results
for
these
new
projects,
and
we
could
start
saying.
Oh,
it
looks
like
you
know,
there's
a
high
degree
of
adoption
for
database
to
the
service,
and
that
might
be
a
capability.
We
should
watch
for
yep.
A
And
the
way
that
Cape,
the
components
and
platformer
structure
it's
it
is,
within
the
it's
perfectly
reasonable
to
have
a
component
database
as
a
service
that
is
has
required
capabilities.
If
you
want
a
license
that
component,
but
might
not
be
part
of
the
platform.
Yet
so
by
design,
there's
a
lot
of
control
and
how
you
know
how
we
make
things
required
and
when
things
become
required,
so
both
the
capabilities
can
be
required,
but
also
moving
from
the
component
level
to
the
platform.
A
C
Think
one
important
thing
is
that
we
have
weekly
meeting
70
wednesday
at
11am
central
time
and
really
want
everybody
participating
as
much
as
they
can
and
also
the
big
time
commitment
if
you
already
have
a
lot
of
meetings,
but
we
have
a
lot
of
great
discussions
and
even
though
we
have
gone
over
this
process
many
times,
there's
always
something
that
was
either
overlooked
or
not
considered,
and
we
do
need
specialized
constantly
and
we
really
need
your
help.
So
please
join
us.
We
send
out
email
and
white.
Do
the
Deaf
core
mailing
list?
C
A
C
B
No,
I
mean,
I
think,
that
you
know,
I
think,
that
we
made
a
trendsetter
progress
over
the
last
six
months
since
the
last
summit
and
it's
really
exciting
to
see
the
the
tests
and
the
process
and
everything
else
into
place
where
you
know
where
we
can
really.
You
know
what
kind
of
taking
this
first
step
of
you
know
actually
proving
that
the
process
works,
and
so
it's
going
to
be
exciting
to
see
over
the
next
six
months.
B
You
know
seeing
the
process
in
place
and
watching
it
grow,
not
just
in
terms
of
the
tests
that
are
passing,
but
how
do
we?
How
do
we
find
and
evaluate-
and
you
know
and
move
this
forward
so
they're
written
so
that
we're
really
building
a
strong
tool
that
you
know
give
us
gives
up
a
sec
users
a
way
to
move
confidently
between
clouds?
You
know
it's
good,
I
think
it's
one
of
the
original
dreams
will
open
stack
and
the
you
know,
and
I
think
this
is
an
important
part
of
that.
B
A
Excellent,
so
if
there
aren't
further
question
will
give
people
back
a
little
bit
of
their
evening
day,
and
you
know
this
is
recorded,
please
your
review
anything
if
you've
got
questions
you
can
find
us
on
the
list,
we're
very
happy
to
talk
about
it.
Love
feedback,
love,
some
some
comments
and
reviews
in
the
in
the
document.
Please
participate
we're
looking
forward
to
working
with
you.