►
From YouTube: OpenStack Meetup on Core in San Antonio 2013-09-05
Description
OpenStack Meetup on Core in San Antonio 2013-09-05
NOTE: Improved Video http://youtu.be/ktU7XDTlpxE with post production!!
A
So
this
we
kind
of
kicked
this
discussion
off
in
the
february
board
meeting
and
it's
been
evolving
as
a
as
a
board
topic,
and
then
we
brought
the
tc
and
then
a
few
weeks
ago
we
started
opening
it
up
to
get
more
and
more
community
input
to
try
to
evolve
this
and
really,
I
think
a
lot
of
this
was
about
starting
out
as
a
point
of
view.
How
do
we,
how
are
we
even
going
to
define
what
core
is?
A
A
But
if
we
start
kind
of
peeling,
the
onion
at
the
outer
side
and
working
our
way
down,
there's
some
potential
to
make
some
progress
and,
I
think,
maybe
to
start
with,
we
can
have
rob
kind
of
kick
over
a
kickoff
kind
of
an
introduction
sort
of
where
we
are
and
then
just
see
what
questions
you
guys
have
or
thoughts
or
inputs.
You
have
in
the
process.
B
B
Just
not
just
for
practical
about
what
the
project's
about
and
the
the
debate
sort
of
ends
up
sounding
had
sounded
a
lot
like
this.
It's
like
this
has
to
be
in
court.
It's
an
absolutely
required
part.
Well,
if
you
do
that,
then
this
has
to
be
in
court
that
shouldn't
be
in
court.
We
get
this
very
circular
argument
right
and
people
would
be
yeah.
Well,
I
don't
want
this.
I
don't
want
us
to
not
be
innovative.
B
We
want
to
have
all
this
stuff
and
if
you
do
that,
it's
going
to
be
nobody's
going
to
want
to
contribute
to
the
project
and
all
these.
So
we
had
these
big
round
and
round
discussions
about
it
and
with
the
board,
especially
24
people
on
the
board.
The
only
way
we
resolve
problems
is
we
come
up
with
a
schema
for
for
discussion.
First,
that
makes
sense.
B
I
I
working
with
the
board
of
24
people
is
a
big
challenge,
and
so
what
what
we've
done
with
this
discussion
is
we're
not
going
to
say
what
is
core
tonight
right.
This
is
probably
the
hardest
statement
that
anybody's
going
to
that's,
not
what
we're
trying
to
do.
What
we're
trying
to
do
is
figure
out
what
how
we
determine
what
is
core
right,
the
meta,
the
meta
conversation
and
the
reason
why
that's
really
important
is
because
that
that
then
lets
us
just
discuss
in
a
very
rational
way.
B
This
is
core,
this
isn't
core,
and
so
we've
been
working
through
this
process
to
try
and
help
people
understand
that.
So
that's
the
first
thing
is
not
not
to
walk
away
saying.
Oh
now,
I
know
exactly
what's
in
court,
not
in
court.
One
of
the
other
reasons
you
won't
get.
That
answer
is
because
this
is
we're
at
the
vetting
phase.
So
the
things
we
talk
about
tonight
are
all
open
for
discussion
right.
B
There's
points
in
this
there's
positions
here:
we've
intentionally
described
to
the
dispositions
because
it
gets
people's
attention
and
it
helps
the
dialogue
go.
If
we
actually
say
here's
what
we're
thinking,
then
here's
a
whole
bunch
of
questions
we
want
to
answer,
but
every
single
thing,
we've
we've
presented
every
single
thing,
we've
done
so
far
has
very
much
been
responding
to
feedback,
bringing
things
out.
We
we
had
some
language
that
when
we
showed
this
process
to
the
ptl's
in
the
tc,
they
were
allergic
might
be.
B
The
right
word:
we're
not
mandating
plug-ins
as
part
of
core.
Let's
just
say,
there's
right
and-
and
it's
really
there's
a
very
it's
a
very
diverse
community
and
there's
a
lot
of
there's
a
lot
of
things
that
are
there
that
we
have
to
consider
and
what
we're
going
the
community
is
going
to
continue
to
get
diverse,
and
the
last
thing
we
want
to
do
in
defining
core
is
make
anybody
feel
like
they're,
not
part
of
the
community
right
and
that's
one
of
the
biggest
liabilities.
B
The
other
thing
that
hopefully
you'll,
walk
away
from
this
understanding
is
that
it's
not
there's,
no,
not
being
a
core
component
in
openstack
is
not
a
walk
of
shame
right.
This
is
one
of
the
biggest
things
is
there's
a
lot
of
people
who
are
like
if
I'm
not
core,
I'm
not
important
anymore,
and
that's
not
the
purpose
of
defining
core
the
purpose
of
defining
core
is
about
interoperability.
It's
about
hittability!
It's
about!
B
You
know
people
knowing
what
they
can
count
on
what's
necessary
just
because
a
project
isn't
core
that
doesn't
mean
that
project
isn't
part
of
openstack.
It
really
is
very
narrowly
defined,
but
it's
also
a
very
helpful
thing
for
us
to
understand
and
I'll
give
you
a
you
know
a
hometown
example
for
this.
You
know:
rackspace
doesn't
operate
dashboard
which,
by
the
current
definition
according
to
the
bylaws,
is
core
and
you
must
use
they
have
their
own
variant
of
keystone.
B
For
good
reasons
makes
perfect
sense.
Not
you
know,
but
that's
also
a
core
project.
So
if
you're
going
to
say
I'm
an
openstack
cloud
or
I'm
deploying
openstack
and
you
don't
use
core
components,
you
were
out
of
compliance,
you
actually
couldn't
make
that
claim,
and
so
there's
some
there's
some
shades
of
gray
and
all
this
stuff.
But
that's
why
it's
important
right.
People
want
to
be
able
to
say
we
want
the
openstack
trademark
to
mean
something,
and
this
opens
up
some
cans
of
worms
that
we
were
discussing
earlier
today
about.
B
B
Please
bring
up
projects,
okay,
just
because
we're
we
can't
say
this
is
core
or
not
core,
I'm
not
going
to
definitively
answer
it.
It
is
the
most
effective
exercise
for
somebody
to
say
I
think
heat
should
be
core.
This
happens
to
me
twice
a
week
right.
I
think
this
project
should
be
core
and
you
know,
and
then
test
it
to
see
if
this
answer,
if
we,
if
we're
like
okay,
if
you
think
it
should
be
core,
can
we
answer
why
it
is
or
why
it
isn't
right?
Can
you
can
you?
B
Would
you
be
able
to
effectively
lobby
your
case
and
what
how
that
would
be
so
there's
all
that
it's
a
lot
of
ground
setting
but-
and
you
know
what
I
can
actually
do
this
I'm
going
to
I'm
going
to
turn
the
screen,
I'm
going
to
turn
my
screen
around,
so
you
guys
can
see
it
and
then
I'm
going
to
share
it.
At
the
same
time,.
B
B
So
I'm
going
to
try
and
go
through
this
this.
This
is
the
end
result
of
a
lot
of
discussions
and
dialogues
and
back
and
forth
with
the
board
and
board
members
and
the
tc
and
ptl's,
and
now
the
community
and
so
right,
one
of
one
of
the
things
I'm
going
to
ask
all
of
you
is,
you
know,
raise
your
concerns.
Bring
these
things
up.
B
If
you
feel
like
we're
addressing
the
concerns-
and
this
is
reasonable
and
you're
being
heard,
say
it
right
part
of
part
of
the
factor
and
all
this
stuff
is
that
you,
this
is
you're
representing
not
just
your
positions
but
the
community's
positions,
and
if
you
think,
there's
something
that
we're
doing
that
doesn't
smell
right.
We
need
you
to
bring
it
up
and
you
don't.
If
you
don't
feel
comfortable
here,
you
sleep
on
it,
bring
it
up
on
twitter,
bring
it
up
on
the
list,
bring
it
up
right.
B
Don't
show
this
message
again.
I
said
that
before
all
right,
so
I
know
you
can't
see
this
and
I'll
walk
I'll,
walk.
You
walk
you
through
it
to
make
it
a
little
bit
easier.
The
way
this
the
way
this
works
is
we
start
from
the
position
that
openstack
core
is.
You
must
use
core
to
get
the
trademark
that
those
are
not
necessarily
interlinked
but
they're.
The
only
way
that
openstack
can
enforce
it.
B
We
had
a
really
funny
quote,
which
is
how
do
you
make
sure
all
this
stuff
works,
and
we
said
trust
and
lawyers,
so
the
idea
is
we're.
We
don't
want
to
believe
we're
not
trying
to
create
openstack
police
state,
but
at
the
end
of
the
day,
if
people
don't
comply,
openstack
can
sue
somebody
for
misuse
of
not
using
the
trademark
correctly
right.
A
A
F
A
B
B
B
This
so
here's
and
a
lot
of
these
points
build
they
intentionally
build
on
each
other.
So
the
the
first
thing
in
this
is
that
that's
that's
the
enforcement
mechanism.
Right
core
is
a
subset
right.
I
already
talked
about
this.
You
shouldn't
get
your
feelings
if
you're,
not
core,
you're,
still
openstack,
so
we're
not
trying
to
describe
100
of
the
codebase
that
can
be
applied
to
any
any
application.
B
So
the
definition
of
core
should
not
be
core
for
hosters
and
core
for
at
this
point,
right
that
what
we're
trying
to
define
is
core
that
is
common
across
all
use
cases.
Okay,
that
doesn't
mean
that
we
might
not
refine,
and
then
these
the
next
set
are
all
technical
related.
The
first
one
is
that
it
requires
that
you
actually
deploy
some
openstack
code
right.
That
is
a
requirement
that
drives
a
community.
B
B
There's
a
lot
of
commercial
interests,
but
if
we
define
core
in
a
way
that
doesn't
encourage
a
collaborative
community
around
openstack
or
it
doesn't
encourage
people
to
contribute
code
and
make
the
product
project
better,
we
failed
so
there's
a
test
in
all
this
and
please
help
apply
this
test,
that
what
we're
doing
is
actually
adding
to
the
body
of
knowledge
for
this,
the
okay
and
then
so.
One
of
the
things
that
people
feel
very
adamantly
about
is
that
you
must
include
openstack
as
part
of
the
definition
for
this
right.
So
that's
our
openstack
code.
B
How
do
you
know
which
openstack
code
or
not
it's
up
to
the
leaders
in
the
project-
the
technical
decision,
where
there's
an
expectation
that
they
will
identify
a
section
of
code
and
say
you
must
use
this
part
of
the
code.
It
is
required
part
of
the
thing
we
were
talking
about
that
helps
that
helps
drives.
It
actually
helps
make
sure
that
people
are
still
contributing
back
things
into
openstack.
There's
some
board
members
who
are
very
adamant
about
this
position.
It's
an
interesting
one
and
then
we
branch
there
must
be
an
open
source
reference
implementation.
B
Okay,
that's
expected
right,
it
doesn't
have
to
have
every
bell
and
whistle.
Well,
we
have
to
have
all
the
core
bells
and
whistles
you're
not
going
to
have
something
in
core:
that's
not
in
the
open
source
reference
implementation,
and
we
also
allow
people
to
have
alternate
implementations
right
in
past.
We
call
these
plugins
or
extensions,
or
things
like
that,
we're
much
simpler
than
that.
The
technical
leaders
of
that
project
say
this
is
a
place.
This
is
the
reference
implementation,
here's
the
required
code.
Here's
places
you
can
substitute
some
projects
call
those
plug-ins.
B
Some
projects
might
be
designated
just
by
lines
of
I
don't
I
don't
care
it's
up
to
the
technical
group
to
do
it,
but
we're
expecting
that
you'll
have
reference
implementation,
that's
open
as
part
of
the
openstack
project
and
and
people
can
substitute
in
alternative
implementations.
What's
to
keep
the
project
from
saying
this
is
the
code
base.
B
We're
having
that
we're
having
that
conversation
in
some
cases
and
one
of
them,
I'm
going
to
answer
that
in
a
couple
ways
to
answer.
One
is
there's
social
pressure
and
the
pressure
of
this
being
the
definition
of
core,
but
it
also
is
a
necessary
thing
just
to
evolve
the
code
base.
So
if
somebody
says
I
want
to
change
part
of
how
the
code
operates
and
we
need
an
alt
a
way
to
have
an
alternate.
B
Oh,
I
can
use
this
or
that
right
I
can
use
rabbit
or
zero
mq,
and
so
I
mean
even
that's
a
reasonable
place
to
say.
Okay,
we
allow
you
to
use
whatever
queuing
system
you
want
or
hypervisor
that
you
want
or
file
system
that
you
want
underneath
the
covers.
So
not
every
project
can
do
it.
Oslo.
Might
it
might
not
make
any
sense
for
that,
and
they
might
say
there
is
none
and
we
would
say:
okay,
that's
fine.
A
You've
got
the
hypervisors
that
you
can
switch
out.
Nova
you've
got
all
the
different
storage
back-ends
that
are
supported
by
cinder.
You've
got
all
the
different
plug-ins
supported
by
neutron,
and
so
I
don't
think
this
is
people
generally
disagree,
that
this
is
you're
going
to
have
to
have
some
level
of
differentiation,
and
that's
really
what
we're
trying
to
capture
with
these
concepts.
Does
it
mean
that
the
reference
of
limitation
has
to
have
multiple
like.
A
Or
just
that,
it
has
to
be
possible
to
be
extended
now.
What
we
were
basically
saying
is:
there
needs
to
be
something
you
can
get
where
you
can
basically
download
off
the
web.
That's
free
in
open
source,
where
you
can
build
a
complete
functional,
viable
working
platform,
and
there
needs
to
be
a
way
for
people
who
want
to
potentially
take
that
and
differentiate
it
in
some
way
and
still
fall
into
the
court.
And
that
is
the
logical
concept.
A
We're
trying
to
get
to
what
we
don't
want
to
do
is
make
it
so
that
you
have
to
buy
vendor
plugins
to
get
a
project
to
work
right,
there's,
no
open
source
alternative
or
no
viable
open
source
alternative,
but
we
also
don't
want
to
sort
of
say
it's.
A
hundred
percent
of
this
particular
open
source
stack
for
everybody,
and
so
we're
trying
to
figure
out
the
right
way
to
fund
middle
ground,
and
this
is,
I
think,
our
best
capture.
D
Speaking
of
which,
in
terms
of
the
technical
leaders
defining
which
set
of
code
within
their
project,
that
if
they
that
you
have
to
run
this
bit
of
code
to
be,
you
know
defined
as
using
that
project,
then
how
does
that
evolve
over
time
when
a
new
project
leader
comes
in
and
says?
Oh,
you
know
what
that
old
definition
garbage.
You
know
we're
doing
something
totally
different
and
just
going
a
whole
new
direction.
How
do
these
things
evolve
over
time?.
B
B
So
the
the
idea
here
is
that
these
this
code
is
verified
by
community
tests.
Okay,
it
doesn't
say
tempest
specifically
tempest
is
is
definitely
one
of
the
candidates,
but
we
could
have
a
broader
range
of
tests
in
that,
but
the
idea
is
the
openstack
community
maintains
tests
by
which
these
projects
are
verified,
which
is
it's
great
behavior.
We
want
to
encourage
that
and
then
the
expectation
is
these:
aren't
just
tests
that
run
in
the
lab
they're
tests
that
can
be
self-administered
or
remotely
admitted
or
remotely
administered.
B
So
if
you're
familiar
with
refstack,
the
idea
would
be
you
could
take
a
cloud
and
put
refstack
at
it
and
it
would
run
the
tests
or
if
you
were
private
cloud,
you
could
run
the
test
suite
yourself
and
get
a
result.
Right
and,
and
part
of
this
is
people
are
like.
Well,
how
do
I
know
I
have
an
openstack
cloud?
B
You
have
to
be
able
to
run
the
tests
against
it
right
for
the
stuff.
I
do.
We
actually
include
tempest
in
our
project
right,
I'm
I'm
leading
the
chrome
art
project
and
tempest
is
one
of
the
components
and
after
you
do
an
install
you
can
run
tempest
and
validate
that.
Yes,
I
actually
have
an
openstack
cloud
that
passes
tempest
so
that
validation
is
part
of
this
conceptual
framework
right
and
then
the
next
thing
is
well
wait,
a
second,
not
you
don't
have
to
pass
100
of
those
tests
right.
B
There
are
going
to
be
tests
that
are
new
or
for
different
components,
or
you
know
it
is
perfectly
reasonable
that
you
don't
pass
100
of
the
tests,
there's
only
some
of
them
that
we
have
to
identify
as
must-pass
tests
and
those
must-pass
tests
the
net.
The
final
box
here
is
that
the
must-pass
tests
define
openstack
core.
So
this.
B
A
B
B
It
should
show
up
as
a
benefit
in
rest
act
right
or
in
your
score,
but
it
doesn't
make
you
any
more
openstack
core
than
somebody
else.
This
is
the
list
you
must
pass
to
the
openstack
core
and
restack
would
probably
have
a
checkbox
that
says
hey
core
this.
This
map
passes
all
the
core
tests
right,
but
if
you
pass
more
or
even
if
you
pass
less,
that
should
be
that
that
might
be
okay.
B
So
here's
here's
the
here's,
the
idea
with
with
that-
and
this
is
where
it
gets.
It's
really
interesting-
is
that
if
you
have
things
that
are
special
specialized
tasks,
that
maybe
only
work
for
one
module
say
that
the
microsoft
team
writes
hyper-v,
specific
tests
only
pass
if
you've
deployed
hyper-v
great
they're,
not
likely
to
become
must-pass
tests,
but
I
would
love
to
have
them
in
the
community
of
tests,
because,
if
I'm
employing
hyper-v,
I
want
to
test
it.
B
So
this
is
this
is
where
the
concept
of
the
must
pass
test
is
really
interesting,
and
this
is
really
what
we
start
getting
into
with
a
very
demonstratable
version
of
core,
because
at
that
point
I
can
say
I
can
actually
collect
statistics,
particularly
we're
talking
about
this
today.
I
could
actually
look
at
a
trend
on
it.
I
could
collect
data
from
the
community,
which
is
really
what
we
want
to
be
able
to
do
and
see
in
the
field.
B
Oh,
these
tests
are
passing
in
90
of
my
deployments:
they're
likely
core
tests
where
these
were
only
20,
but
in
this
in
the
in
the
ice
house
release
they
moved
from
20
to
40
right
and
people
started
investing
in
in
making
sure
that
passed,
and
then
you
can
start
making
arguments
that
these
tests
are
use
cases.
These
use
cases
are
important
to
the
community.
B
G
B
B
E
B
A
chord
change
more
frequently
than
the
release
cycle
or
more
slowly,
it's
a
really
good
and
in
in
the
detail
sound
in
here,
we
actually
had
a
discussion
around
this.
The
idea
is,
is
that,
on
release
day,
there
is
a
body
of
tests.
If
your
deployment
passes
on
release
date
with
the
tests
that
are
included
in
the
release,
you
can
claim
openstack
core
for
that
release
right.
We
need
to
differentiate
the
mark,
and
this
is
so.
B
A
What
we
definitely
don't
want
to
do
has
been
a
situation
where
you
know.
Let's
say
you
guys,
have
deployed
the
havana
release
and
then
ice
house
pops
out,
and
you
can't
call
yourself
openstack
until
you
catch
up
to
ice
house
right,
and
that
certainly
can't
happen.
I
also
don't
think
we
want
15
different
open
stack,
certifications
available
at
the
same
time,
so
I
don't
know
how
we're
going
to
balance
that
yeah.
E
And
the
ultimate
problem
is,
if
somebody's
trying
to
track
much
more
closely
to
trump
and
things
are
changing
in
that
release,
cycle
that
are
going
to
inherently
change
the
depth
of
the
poor.
Do
you
all
of
a
sudden
become
not
forward
because
you're
not
keeping
up
with
the
latest
release
cycle
and
you're
keeping
closer
to
trump?
You
somehow.
H
A
Some
degree
we're
going
to
have
to
trust
that
the
community
is
going
to
be
rational,
yeah
right
I
mean,
and
this
comes
back
to
everett's
earlier.
You
know,
question
about
sort
of
changing
the
definition.
Of
course.
Really
we
have
these
same
risks
of
that
right.
Any
ptl
has
the
right
to
completely
rewrite
the
api
anytime.
They
become
elected.
You
know
ptf,
but
I
think
most
people
within
the
community
realize
that
shifting
the
api
radically
every
release
would
be
suicide
for
the
project
and
it
doesn't
happen.
A
I
think
we
have
to
sort
of
assume
that
core
while
it
may
evolve,
I
mean
I'm
hoping
you
know
we
get
towards
the
point
where
we
don't
have
backward
compatibility
issues.
You
know
where
core
evolves,
but
in
a
forward
direction
now
backwards.
These
kind
of
things
don't
happen
and
I
realize
there's
a
lot
of
hope
there,
but
I
also
think
if
those
are
the
kinds
of
behaviors
we
have
to
enforce
by
the
board
of
posing
rules
on
everybody.
A
A
I
think
that
the
unintended
consequences
of
that
would
be
worse
than
the
real
risk
of
like
some
kind
of
upheaval
or
somebody
sneaks
into
a
piece,
because
the
reality
is
if
ptl
changes,
something
it's
probably
because
a
large
body
of
people
in
the
project
felt
like
something
needed
to
be
changed
and
the
community
elected
that
person,
and
it
was
done
for
the
right
reason
right.
That's.
B
B
There's
an
interesting
and
there's
a
really
interesting
exit
clause
for
this,
which
allows
somebody
who
has
a
non-compliant
implementation
to
ship
with
the
rep,
the
reference
implementation
and
then
say:
well,
you
can
turn
a
switch
and
use
our
non-compliant
implementation
and
that
that
actually
would
allow
you
that's
one
of
the
ways
so
say.
Like
you
had
a
deploy,
you
had
an
infrastructure
that
didn't
use
keystone.
F
I
F
This
idea
has
a
lot.
It
puts
a
lot
of
emphasis
on
tests
right.
The
tests
are
going
are
going
to
become
so
important,
they're
going
to
become
basically
the
api
contract,
which
I've
always
thought
that
should
be,
but
here's
the
thing.
If
you
allow
different
implementations
rather
than
saying
well,
you
can
switch
it
to
the
reference
one
and
then
just
go
back
and
use
yours.
I
feel
like
that
sort
of
leaves
a
strange
opening.
F
What
about
saying,
there's
going
to
be
ways
to
make
the
tests
themselves
plug,
because
I
think
that
oftentimes,
the
problem
with
the
tesla
like,
I
think
it
would
be
almost
a
pot.
I
mean
it's
going
to
take
a
lot
of
elbow
grease.
So
just
like
yeah
just
point
at
that
thing
and
it'll
work.
You
know
the
first
thing
you're
going
to
do
is
I
tried
it.
K
Totally
it's
going
to
be
it's
going
to
be
like
if
you're
going
to
define
some
code
as
required
and
others
is
that
you
can
vary,
then
the
tests
cover
the
requires
up
have
to
be
the
ones
that
must
pass
and
the
ones
that
are
the
very
importance
that
that's
right
is
that
going
to
be
like
the
design?
Is
that
going
to
be
like,
I
don't
want
to
say
enforce,
but
the
goal
that
everyone's
going
to
have
is
that
if
this
is
required
code,
those
are
the
tests
that
must
pass.
B
Yes,
the
idea
is
the
reference
there.
There
would
be
no
reference
implementation
that
didn't
pass
the
must-pass
tests
right,
which
is
not
the
case
for
all
of
our
projects.
Right
now,
there
are
capabilities
that
that
are
in
neutron
that
aren't
fully
implemented
or
habited.
These
previous
releases
were
fully
implemented
for
the
reference
implementation.
B
B
B
B
D
B
The
openstack
and
and
so
part
of
what
I
I'm
hoping
all
this
drives
is
the
creation
of
tests
like
that,
and
then,
potentially
you
know,
the
user
committee,
whoever
starts
nominating
these
tests
must
pass
would
actually
be
able
to
say
you
must.
This
test
is
a
must
pass
with
a
score
of
30
or
above
or
something
like
that,
but
it's
based
on
rational
things
right.
This
is
in
the
field.
Most
customers
have
this
score.
We
feel
like
this
is
a
criteria.
B
What
we're
trying
to
do
is
stop
arguing
about
whether
or
not
dashboard
is
a
core
project
or
not
and
say
of
these
tests
of
the
dashboard
tests.
You
know
most
use
most
deployments
pass
them,
and
you
know
they
they
make
sense.
Or
if
I
was
a
ecosystem
partner
that
integrated
against
the
dashboard,
then
I
could
lobby
hey.
I
think
this
is
a
must-pass
test
and
then
you
could
have
a
discussion.
That's
very
tightly
bound
on
that
use
case,
which
is
the
goal
so
does.
F
F
B
Being
considered-
and
that's
that
is
the
current
state
right,
we
definitely
see
this
in
the
grizzly
tests.
You
know
tempest
was
not
passing
all
tests
for
our
deployments
until
the
you
know,
but
still
not
passing
100
of
the
tests,
which
is
okay,
we're
not
trying
to
do
that.
I
think
it's
going
to
come
back
to
which
tesla
must
pass
tests
and
that
some
of
those
I
would
expect
the
must-pass
tests
will
be
at
will
be
there
at
the
release.
Mark.
F
B
Self,
when
a
vendor
certifies
against
this-
and
I
need
to
make
sure
this
ends
up
surface-
I
think
it
is-
is
that
the
vendor
is
also
responsible
for
publishing
the
reference
architecture
they
certified
against,
so
there's
so
and
that
that
drove
randy
bias
was
really
involved
in
this.
This
is
an
important
point
from
pamela
and
it's
fun,
because
there's
actually
a
lot
of
these
positions
have
legacies
back
to
specific
board
members
who
have
very,
very
good
community
rationale
for
this
and
there's
a
conversation
goes
well.
B
We
need
to
have
openstack
reference
architecture,
so
people
don't
have
to
argue
about
it
and
the
idea
was
you
can
either
certify
against
one
of
the
published
accepted
openstack
reference
architectures,
that's
going
to
be
a
fair
to
resolve,
but
eventually
there's
probably
some
and
or
I've
published
my
reference
architecture
so
that
you
can.
You
could
hopefully
re-implement
the
tests
because
we
we're
not
we
do
not.
This
was
a
conversation.
B
A
The
other
thing
that's
implicit
in
this
is
that
you
know
the
rough
stack
effort
and
the
testing
effort
has
to
evolve
in
the
real
world.
You
know
they
look
today
as
like
the
campus
test
that
typically
run
on
dev
stack,
which
has
almost
no
relationship
to
the
way
people
actually
use
openstack,
and
so
this
is
why
the
ref
stack,
which
is
a
parallel
effort,
is
actually
somewhat
critical.
Is
that
ref
stack
of
multi-node,
you
know
one
or
more
real-world?
A
Looking
type
applications
needs
to
be
part
of
the
process,
because
what
you
can
do
is
vet
the
test
on
dev
stack
and
then
you
know
pointed
at
you
know,
hp
and
an
hp
availability
zone
and
then
complain
that
you
know
this
bunch
of
vms
running
on
laptop
work.
Fine
and
his
doesn't.
He
doesn't
need
to
be
openstack
right
and
that
doesn't
make
any
sense.
So
what
at
a
minimum
those
we
have
to
have
a
testing
ground
where
this
stuff's
being
developed?
F
B
A
G
B
B
You,
wouldn't
you
wouldn't
be
able
to
claim,
and
so
we're
still
working
out
the
details
on
this,
but
the
thinking
was
is
that
you
wouldn't
be
able
to
claim
the
grizzly
mark
until
you
can
pass
all
the
tests
for
the
grizzly
release.
Okay.
So
the
idea
is
that
there's
separate
marks
for
each
release
right.
L
M
B
So
you
can
try
and
cheat
if
you
are
a
company,
that's
cheating!
These
results,
you're
going
to
get
busted
really
fast.
If
you
are,
if
you're
a
private
individual
and
you
have,
you
use
the
test
to
make
sure
that
you're
in
interoperable
interoperable
with
other
clouds
you're
going
to
make
those
decisions
based
on
what
you're
making
them
for,
and
so
we
can.
We
we're
trying
not
to
create
a
lot
of
rules
around
around
that
until
we
need
them.
We
need
them.
K
B
I
really
want
to
have
happen
is
I
want
to
have
everybody?
Who's,
building,
openstack
products
right
and
doing
stack
deployments,
be
really
invested
in
running
the
tests
on
their
deployment,
because
then
the
tests
get
better.
The
code
gets
better.
We've
made
sure
the
tests
are
more
robust
if
you're,
in
a
situation
where
you
get
into
a
case
and
it's
you
know
you're
a
month
after
the
release
and
something
blows
up,
because
you
haven't
run
the
tests
until
then,
because
you're
about
to
release.
Shame
on
you
right.
B
You
know,
deployment,
sharing,
sharing
deployment,
details
and
things
like
that
that
we
actually
helps
the
community
a
lot
and
that's
I'll
step
back
and
I'll
I'll
I'll
mirror
something
that
monty's
been
really
good.
Taylor's
been
really
good
about
trying
to
drive.
He
wants
to
make
sure
that
everything
we
do
in
our
definition
encourages
people
to
contribute
back
to
the
open
source
project
right
point
number
four
in
this,
which
is
you
must
deploy.
Openstack
is
one
of
the
things
he
feels
very
strongly
about,
because
what
he
doesn't
want.
B
Somebody
to
do
is
implement
the
apis
and
then
walk
away.
We
want
to
have
a
reason
for
people,
even
if
they've
reimplemented
the
apis
to
still
be
active
in
in
source
code
in
the
project
and
not
just
take
our
spec
right
and
say:
hey
thanks.
Thank
you
for
defining
this
thing
and
building
a
market
for
us,
but
we're
not
going
to
contribute
you're
communicating
so.
E
E
E
E
G
Use
the
tradesmart
yeah
you
have
to,
but
you
can
deploy
openstack
and
never
use
the
trademark,
so
private
cloud
wouldn't
care
or
whatever
yeah
private
college
and
care
right.
I
want
to
go
out
and
implement.
You
know
an
amazon
compatible
cloud
would
have
a
bowman
stack.
I
could
do
that.
Never
even
expose
the
reasonable
comparison
might
be
like
the
new
ecosystem
right
so
like
the
center
is
like
easy
to
kind
of.
G
O
Buy
that
right,
yeah,
it
gets
back
to
why.
Why?
Because
this
is
important,
because
I
think
one
thing
we're
trying
to
get
is
different
than
it's
just
oh,
it
should
be
interactive
right.
So
that's
why
I,
in
most
cases
as
a
vendor
right,
if
you're,
the
only
guy
who
can
pass
the
test,
it's
it's
a
good
thing,
because
you
say
I'm
differentiated
right
in
this
case,
if
only
one
out
of
10
implementations
pass,
that's
a
bad
thing.
B
There's
no
internal
probability
whatsoever
on
core.
If
you
can,
if
you
add,
you
know
I'll,
go
back
to
my
fictitious
hyper-v
example.
If,
if
you're
a
product,
that's
differentiated
and
you
add
10
tests
or
100
tests
that
that
only
pass
for
you
and
the
ptl
and
they
come
in
the
community
and
they
rock
on
right.
What
you've
done
is
you've
actually
made
it
possible
for
people
to
validate
that
your
functionality
works,
but
they
don't
necessarily
become
core.
F
So
by
that
same
example
or
something
and
then
the
actual
reference
tests,
lots
of
the
tests
depend
on
features
that
cannot
be
possible
on
number
b.
So
then,
what's
what's
the
solution
there
does
voters
doing
that.
I
think
they
need
to
have
an
outlet
to
say
hey.
This
really
isn't
fair.
We
can't,
unless
this
is
going
to
be
part
of
the
system
in
which
case
you're
actually
disallowing
that
different
implementation.
These
simply
can't
be
part
of
this
backward
test.
Yeah.
A
Discussion
is
important
know
on
the
one
hand,
we're
sitting
there
saying.
Well,
you
can
have
these
sort
of
I'll
use
the
term
plugable
some
some
mechanism-
that's
replaceable,
but
your
test,
then
don't
actually
allow
it.
But
if
you're,
actually
fooling
yourself,
you're,
not
exactly
yeah
the
only
hypervisor
that
works
and
nothing
right.
B
But
we're
also
allowing
for
somebody
to
say
I'm
going
to
ship
you
a
hyper-v
cloud
that
doesn't
pass
core
test,
but
I'm
including
the
kvm
module
so
that
it
will
and
that's
why
that's
why
that's
an
if
they
include
the
kpm
module,
then
again
would
they
have
to
switch
the
kvm
driver
on
their
deployment
to
pass
the
test
if
they
were
so.
This
is
this
is
where
we
get
back
into
commercial
enablement.
It's
one
of
the
things.
A
Giving
the
customer
the
option
of
the
service
time
of
flipping
their
hypervisor
most
likely.
I
think
that's
where
you
know,
probably
where
that,
where
that's
a
trickier
issue,
I
I
think
we
fail
if
we
start
defining
a
bunch
of
tests
that
only
work
with
one
hypervisor
to
only
work
with
one
storage
system,
but
those
become
the
must-have
tests.
G
K
O
B
Most
deployments
pass
this
test
and
there's
this
one
hypervisor
that
doesn't-
and
so
you
can
say
you
know
what
we
actually
have
a
community
who
relies
on
this
feature.
We're
gonna,
we're
gonna,
actually
say
you
don't
get
core.
This
is
this
is
tough
love,
but
it's,
but
we
can
back
it
with
data,
which
is
what
I
really
want
to
say.
Look
the
fact
that
you
don't
pass
this
feature,
but
90
of
our
deployments,
use
it
or
expect
it.
G
G
A
I
mean
I
don't
think
any
of
this
is
like
the
intention
of
the
board,
sits
in
a
room
right
list
and
says:
okay,
all
right,
I
mean
I
do
think
it's
gonna,
be
a
discussion.
I
think
some
places,
there's
gonna
be
some
hard
discussions
right
where
there
are
gonna,
be
things
that
that
you
know
limited
different
people
haven't
implemented,
that
are
big
players
that
are
gonna,
have
to
decide
if
they're
gonna
step
up
and
do
it
or
not.
But
I
also
think
that's
part
of
what
we
have
to
do.
A
Some
compromises
will
have
to
be
made
or
that
that
you
know
will
never
be
reality
and
right
now
and
look,
you
know
it's
homegrown
examples
right
there.
There
are
a
lot
of
things
about
what
backspace
has
done
with
our
public
cloud.
That
is
very
different
than
the
traditional
implementations
and
some
of
that
we're
working
to
fix
we're
going
quickly.
Some
of
it
we
might
not
raise
until
we
get
faced
with
this
kind
of
dilemma
and
there'll
be
other
people
who
are
too,
and
I
think
that's
actually
good.
You
know
now.
A
I
think
if
you
go
to
a
whole
class
of
things
and
sort
of
say
we're
going
to
exclude
the
zen
hypervisor
because
then
doesn't
support
this
one
feature
that
kvm
does
yeah,
that's
a
little
broad,
but
on
the
other
hand
you
know
if
they
were
to
come
in
and
say
wait
a
minute.
Everybody's
got
ssh
key
pairs
and
rackspace
doesn't
tax.
But
if
you
want
to
certify
you're
going
to
invest
this
tax,
go
put
it
in
your
dome.
B
Part
of
the
conversation
here
and
the
way
I
see
this
actually
going,
which
is
exciting
to
me,
is
the
user
committee.
Actually-
and
this
is
this-
has
added
this
potentially
added
scope
and
work
with
the
user
committee,
so
it
has
to
go
through
a
vetting
process,
but
the
user
committee
actually
is
the
one
collecting
the
data
and
it's
the
logical
place
for
the.
You
know
that
conversation
to
happen
right.
The
ptl
owns
what's
required,
what's
not
required,
it
owns
getting
the
test
in
and.
B
Up
to
test
suites,
the
user
committee
seems
like
the
app
the
place
to
advocate
for
making
the
recommendation
if
this
test
should
be
in
or
out
and
and
one
of
the
things
about
this
is
is
I
don't
expect
this
to
be
so
binary?
I'm
at
zero,
I'm
at
90.
that
a
lot
of
projects,
a
lot
of
features
and
capabilities,
we're
going
to
see,
and
we
should
see
an
increasing
adoption
rate
on
these
tests
and
it
encourages
vendors
to
have
their
users
publish
their
results
right.
B
K
K
These
tests,
if
you
can
do
these
things,
then
you're
a
full-fledged
member.
So
it's
a
very
positive
thing.
You
can
get
added
in
as
a
part
of
openstack.
You
must
pass
these
tests.
Maybe
they've
read
some
other
tests
to
do
some
doctor
specific
things.
That's
fine!
That's
for
people
using
docker,
but
those
aren't
the
must.
A
Have
I
also
think
yeah
the
big
thing
we're
trying
to
do
is
this
is
much
more
about
protecting
the
brand
from
becoming
a
meaningless
word
right,
that
it
is
about
making
the
brand
exclusive
right,
because
it's
almost
like
we
want
to
do
the
bear
the
bare
minimum
that
that
leaves
enough
value.
That
people
see
the
brand
of
something
useful,
as
opposed
to
we're
trying
to
set
the
bar
so
high
that
a
very
small
number
of
people
we're
very
much
on
the.
K
Other
end
of
that
scale,
or
that
people
have
to
be
nervous
that
if
something
changes
slightly
that
somebody's
going
to
come,
you
know
the
trademark
police
are
going
to
come
and
move
them
on
the
head.
I
think
you
can
you
need
that
capability.
If
there's
somebody
who
does
go
rogue,
they
don't
give
a
damn.
They
just
go
out
and
do
their
own
thing
and
misuse
the
name
and
make
no
effort
to
comply.
Then
you
can
bring
in
lawyers
like
you
said,
but
I
think
the
main
thing
is
you
have
to.
K
M
M
M
A
M
Actually
be
ready,
is
it
a
reasonable
expectation
that
I
mean
that
that
seems
to
be
quite
a
a
very
high
bar
and
a
very
difficult
task
to
attain,
given
that
we
already
have
a
track
record
of
having
a
difficult
time,
keeping
up
with
just
the
basic
unit
tests
and
testing
the
basic
functionality
that
are
within
most
of
the
major
components
within
openstack.
So.
B
About
this
it
does
place
a
lot
of
pressure
on
testing
infrastructure,
right
and
testing
and
people
writing
tests.
I
I
don't
expect,
remember
it's
not
it's.
Only
a
percentage
of
the
taxes
and
the
tests
and
the
tests
that
are
must
pass
are
most
one
are
going
to
be
known
and
they
they
should
be
get
extra
attention
and
love.
I'm
assuming,
but
there
also
shouldn't
be
popping
up
right.
O
B
A
Like
I
actually
believe
that
I
believe
the
likelihood
would
be
more
along
the
lines
of
new
features
that
get
introduced
in
grizzly.
They
get
wide
adoption
during
the
six-month
grizzly
period
might
become
must-have
must-pass
tests
in
the
havana
cycle.
Yeah,
like
I,
don't
think,
you're
going
to
have
a
bunch
of
new
habits
and
show
up
in
the
must-pass
list
on
day.
One
there's
anything,
that's
that
new,
so
we
don't
really
know
right.
It.
A
M
B
It
definitely
it
definitely
changes
the
question
about
about
deprecation
statements
right
and-
and
I
think
once
again
I
want
to
go
back
to
data-driven
decisions,
and
so
I
what
I,
what
I
really
don't
like,
is
us
to
speculate
it
or
to
drive
a
stake
in
the
ground.
We
are
deprecating
the
code
at
grizzly,
because
that's
what
we
think
is
the
right
thing
to
do.
I'd
much
rather
be
able
to
say
you
know
what
sixty
percent
of
our
deployments
are
still
passing
the
nova
network
tests.
B
We
better
hang
on
to
those
things
because
they're
still
widely
in
use
and
ver,
you
know,
and
only
20
are
passing
neutron
tests
wow.
We
need
to
work
on
adoption,
for
that
and
part
of
the
thing
that
I'm
hoping
to
see
is
that
we
can
actually
start
actually
collecting
that
data
and,
having
somebody
raise
their
hand
and
say:
okay,
I've
this
past
has
never
passes
for
me.
I
there's
a
problem
with
that
right
or
you
know,
just
does
that
make
sense.
B
I
want
to
have
data
data
to
make
these
decisions,
because
I
know
if
talking
about
just
people
on
the
board,
we're
you
know
we
can't
agree
on.
Is
this
core
or
not?
But
I
I
know
I
can
talk
about
one
use
case
and
I
know
if
I
can,
you
can
come
up.
You
know
one
task
and
we
can
talk.
We
can
talk
about
those
much
more
rationally.
B
D
Question,
I
have
sorry
one
question
I
have,
and
it
was
touched
on
when
people
have
said
interoperability-
and
you
mentioned
ssh
is
a
big
part
of
it
is
images
in
order
for
a
cloud
to
be
useful
images
instances
do
the
tests
extend
into
what
those
images
can
do
at
all?
Is
that
taken
into
consideration
the
prime
example
being
clouded
you
know
and
what
it
can
do
for
you.
B
A
These
are
not
just
api
validation
tests
right.
There
has
to
be
behavior
validation
beyond
that,
and
certainly
a
crowd
in
that
case,
maybe
one
we
say
you
know
what
you've
got
to
be
able
to
build
quantitative
and
just
kind
of
work
kind
of
that
service.
Again
I
mean
whatever
those
list
of
things
are
that
I
think
have,
I
think,
could
actually
go
beyond,
because
if
I
just
validate
that,
I
can
make
a
call
and
build
a
server
that
doesn't
you
know
that's
to
some.
E
A
Not
only
can
I
build
a
server,
but
I
log
into
it
a
certain
way
and
it's
going
to
have
a
certain
you
know
and
and
to
some
degree
I
think
in
the
early
days
it's
less
about
whether
this
is
ideal,
but
it
just
starts
to
set
a
framework
of
what
we're
promising
people
and
the
promise
may
be
pretty
low
at
the
beginning.
The
promise
may
be
look
if
you're
running
openstack
we're
only
promising
this
basic
set
of
functionality
and
then
over
time
we
layer
that
up
so
that
it
gets
richer
and
richer
and
richer.
A
A
If
you
run
openstack,
I
know
that
I
can
upload
an
image
in
a
certain
format
and
boot
from
it
and
then
maybe
I'm
booting
from
it
and
it's
clouded
and
then
maybe
I'm
booting
from
it
it's
cloud
in
it
and
it
has
a
bluetooth
user
that
you
know.
I
know
my
keys
are
dropped
into
and
works
a
certain
way,
all
of
which
you
know,
I
think
the
further
we
get
down
that
path,
the
better
it
is.
A
I
think,
we're
probably
going
to
have
to
be
okay
with
starting
low
on
that
bar
and
working
our
way
up.
But
those
are
definitely
what
we
see
in
the
future.
At
some
point
is
behavioral
characteristics
to
go
beyond
what
we
don't
want
to
just
do
is
say
you
got
an
api,
you
can
call
the
api
and
get
a
return
code
back.
We've
got
to
have
something,
that's
more.
I
do
believe-
and
this
has
not
been
stated,
but
I
do
believe
at
some
point.
A
J
E
Kind
of
opposing
you
know
you
know
so,
there's
the
the
idea
that
to
get
good
interoperability
between
openstack
clouds,
you
want
as
much
test
coverage
as
possible,
but
then
it
then
that
starts
to
they're
on
the
side
of
you
know
becoming
core
may
makes
this.
You
know
this
elitist
club
that
only
a
few
people-
and
so
you
know
you
know
so
so
I
think
those
two
things
are
kind
of
at
odds
a
little
bit
so
somehow
we're
going
to
figure
out
how
we
find
the
sweet
spot
there.
E
Ultimately,
I
think
if
we
have
a
minimalist
enough
definition
of
core,
I
don't
necessarily
know
that
the
definition
of
core
has
to
evolve
on
the
same
release,
schedule
that
the
projects
do,
and
I
think
it
might
behoove
the
community
to
separate
those
two
things
out
and
have
in
a
different
cadence
for
the
evolution
of
what
is
cores
than
the
release
process.
I
think.
M
So
we
talked
earlier
about
this
idea.
Do
we
really
so
I'm
still
struggling
too
with
this
idea?
Do
we
really
need
core?
Can
it
just
be
openstack
and
something
I
keep
going
back
to?
Is
I
wonder
if
a
better
start
would
be
less
talking
about
what
core
should
be
and
we're
talking
about
the
individual
components
and
how
we
can
validate
those
individual,
individual
performance
and
maybe
having
trademarks
around?
M
I
can
say:
I'm
running
openstack,
compute,
open
contact,
storage,
open,
stack
objects,
you
know
whatever
those
might
be
and
get
those
first
right,
and
then
I
think
once
you're
collecting
the
data
we
have.
Those
basic
components
worked
out
of
how
we
can
define
whether
or
not
then
we
get
a
much
better
idea,
and
I
think
the
market
will
tell
us
much
more
about
what,
whether
or
not
we
even
need
or
need
some
definition
of
core.
It's.
B
M
B
F
Q
B
I've
heard
so
here's
here's
you
guys
you
guys
are.
I
mean
this.
This
is
really
exciting
to
me,
because,
right,
what
we're
saying
is
logical,
digested,
you're,
moving
towards
oh
okay,
I
understand
how
things
are
going
to
be
core,
and
now
I'm
like
okay.
Well,
that
means
that
the
trademark
core
is
going
to
shrink
because
it's
interoperability,
spec
and
now
I'm
going
to
have
variants
and
we're
going
to
have
to
deal
with
that
and
I've.
I've
had
really
really
good
discussions
with
people
saying
well,
okay.
B
B
A
A
R
A
I
do
think
you
know
to
pick
up
on
that
thought
because
I
I
haven't,
because
I
was
having
a
discussion
with
another
open
stacker
today
about
this
idea
of
how
how
do
we
innovate
more
inside
of
openstack,
because
we
do
have
a
problem
today.
Where
there's
this
idea,
you
get
it
and
you
build
it
and
it's
done
and
it
stays
forever
and
it
would
be
nice
in
some
projects
to
experiment
more.
A
You
tell
us
which
one
and
you
know
let
the
marketplace
determine
which
is
core
and
then
at
some
point,
because
that's
one
of
the
things
that
always
resonated
with
me
is,
you
know,
talking
about
representations
and
sort
of
the
other
places
right.
You
know
ip
tables
didn't
start
out
as
being
mandated
as
a
feature
of
linux.
A
There
were
lots
of
people
that
built
capabilities
to
manage
firewall
type
behaviors
in
linux
and
then,
when
iq
tables
became
used
by
80
of
the
people
out
there
to
do
it.
It
became
part
of
linux
and
one
of
the
things
that
I
think
we
don't
do
well
in
openstack
right
now
is
allow
innovation
to
happen
in
sort
of
a
competitive
way.
A
We
have
a
tendency
to
pick
one
project
or
one
way
of
doing
things,
decide
early
on
that's
right
and
deploy
it
without
any
marketplace
feedback
or
customer
feedback,
and
it
may
be-
and
I
hadn't
thought
of
this
before,
but
it
may
be
that
we
begin
to
use
this
core
mechanism
as
a
way
of
sort
of
differentiating
between
what's
happening
in
an
innovation
layer
versus
you
know.
This
is
the
stuff
you
can
depend
on.
A
K
Inclusion
in
the
standard
library
that
seemed
to
be
like
the
goal
of
every
project
to
become
part
of
the
standard
library,
but
a
lot
of
projects
found
out
that
once
you
were
in
you
couldn't
change
very
easily.
You
were
kind
of
stuck
because
now
everyone
was
depending
on
that,
whereas
if
you
were
outside,
you
could
continue
to
evolve
and
innovate.
The
other
problem
is
a
lot
of
things
got
in
the
standard
library
early,
that
kind
of
sucked
and
it
was
impossible
to
take
them
out.
K
E
A
Know
how
do
you
make
it
so
that
you
don't
feel
like
you're,
not
important
if
you're,
not
in
court?
I
mean
some
some
degree
that
almost
starts
to
place
a
penalty.
I
mean
you
don't
want
to
go
into
court
because
by
the
time
you're
in
court,
like
you
lose
a
lot
of
your
elbow,
you
lose
a
lot
of
your
innovation
space.
A
You
lose
and
there
are
certain
projects
that
you
know
may
not
want
to
enter
into
that
until
they're
really
ready
to
lock
it
down
other
things,
maybe
so
it
may
anyway,
it's
a
helpful
way
to
think
about
as
we
as
we
discussed.
This
may
be
a
way
to
use
that
outside
of
purely
just
sort
of
a
branding
place,
but
even
just
a
way
of
ourselves
of
saying
you
know,
because
I
like
the
idea
of
evolving
course
slowly
and
also
putting
a
really
hard
locker
round
that
says.
Look
you
don't
break
backward
compatibility.
A
C
This
is
how
you're
gonna,
like
really
embrace
appreciate,
ratios
by
finding
core
and
allowing
me
to
go
to
dell
and
buy
an
open
stack,
and
then
I
have
a
new
relationship
with
a
theme
done
by
openstack
and
have
them
still
work.
I
don't
actually
care
if
rackspace
is
core
or
not,
because
I
can
stop
paying
them
a
dollar
an
hour.
For
instance,
okay,
I'm
not
locked
into
them.
Okay,
I
might
have
like
a
three
year
contract.
C
The
way
most
work
I
pay
for
per
hour.
So
if
they
suddenly
come
out
of
course,
and
they
go
to
court,
it
doesn't
really
add
or
remove
value.
But
that's
one
of
the
values
for
me
is
when
I
buy.
When
I
buy
an
open
stack
from
here
or
an
open
stack
from
crazy
russians,
it
it
it
should
work
like.
I
should
buy
the
base
open
stack
and
it
should
work
right.
A
B
B
C
K
E
A
B
I
I
think
that
there
is
a
value
in
somebody
buying
a
cloud
from
dell
and
somebody
buying
one
from
hp
that
say:
they're,
openstack
and
being
able
to
have
some
certification
that
says:
okay,
these
aren't
the
stupid
stuff,
and
this
is
openstack
and
knowing
it
and
those
those
differences
matter
for
tools
like
you
know,
fog
or
stratus,
or
you
know
any
of
these
things
that
are
above
the
layer.
If
you
know
fog
is
a
great
example:
fog
has
versions
for
openstack
for
rack
space
and
for
hp
right.
B
Right,
but
that
that
is
a
fail
for
openstack
as
a
community
right,
and
so,
if,
whatever
those
differences,
are
we
build
tests
and
then
say:
okay,
I'm
going
to
make
sure
that
you
pass
the
fog
works
against
something
that
passes
the
test.
You
want
the
expectation
that
that's
going
to
you
know,
fog
would
work.
Openstack
fog
would
work
against
anybody
who
passed
the
tests
and
it's
not
it's
not
simple
to
do,
but
it
leaks
you're
driving
in
that
direction.
F
B
And
this
is
this:
to
me
is:
is
the
key
to
the
good,
a
good
definition
of
core
is:
if
it's
driving
us
it's
creating
a
practical
way
to
drive
towards
of
interoperability.
That
is
that
everybody
can
say.
Okay,
if
I
do
this
thing,
it
will
it.
It
moves
us
in
that
direction.
Last
year,
at
the
last
at
the
last
summit,
we
had
a
lot
of
enthusiasm
around
interoperability
and
it's
short
of
ref
stack,
which
didn't
quite
get
us
there
is.
We
had
no
way
to
actually
drive
community
behavior
towards
interoperability
and
right
core
is
important.
B
O
I
think
I
think
about
mental
health.
Besides,
just
moving
more,
you
know,
theoretically,
move
more
close
around
is
that
I
to
me,
if
probably
right,
by
an
hp
cloud
or
dao
cloud,
rackspace
cloud
and
something
new
new
innovation
comes
in
like
let's
say
12.,
I
should
be
reasonably
expect
that
to
overwork
in
the
car.
I
have
without
me
having
to
do
major
changes
to
the
to
the
code.
Some
for
someone,
that's
customized,
so
much
that
it
doesn't
actually
work
with
the
project.
Well,.
E
O
A
big
customer
today
who
wants
to
go
into
openstack,
but
they
won't
have
me
but
they're,
committed
to,
in
this
case
the
dual
offender
strategy.
So
what
they
want
to
know
is
by
this
12
or
some
other
project.
If
they
use
those
two
different
vendors,
they
open
stack.
You
can
actually
spin
it
up
on
both
and
reasonably
expect
that.
G
A
And
right
now,
quite
honestly,
no
it's
no
harder
to
do
amazon's
openstack
than
just
two
openstacks
right
I
mean,
and
I
I
think
part
of
what
we
believe
is
there
is
an
opportunity
to
make
it
so
easy
to
go
up
and
check
the
openstack
that
people
might
not
want
to
mix
that
and
we'll
see
whether
happens.
But
I
I
mean
just
thinking
of
the
rackspace
side
right.
A
We
we
need
this
because
we
have
debates
between
our
private
public,
but
our
private
public
cloud
stuff,
let
alone
you
know,
hp
and
rackspace,
and
we've
got
to
get
better
at
that
and
that
you
know
love
to
say
we
could
do
it
and
never
have.
To
put
you
know
this
kind
of
program
in
place,
but
that's
you
know,
I
think,
that's
going
to
be
part
part
of
we're
going
to
jump
in.
U
B
A
You
know
where
there's
a
test
where
there's
a
standard
image,
you
need
to
be
able
to
call
glance
upload
the
image
boot
and
instance
from
it
validate
when
it
does
certain
things
right
and-
and
so
you
know
which
begins
to
define
this
standard
image
format,
for
you
know,
or
maybe
two
or
three
right
now.
Is
that
going
to
happen
on
day,
one
of
the
definition
probably
not,
but
if
we
started
to
write
those
tests
and
start
to
see
that
those
tests
were,
you
know,
plain
and
used,
and
that
becomes
now
a
car.
F
F
A
G
B
B
M
To
have
a
hard
time
being
able
to
say
I'm
openstack,
I
run
openstack
core
because
of
all
these
weird
things,
but
me
running,
dev
stack
on
my
laptop
could
say:
hey
I've
got
openstack,
I'm
openstack
board
or
I'm
I'm
running
on
one
machine
in
rackspace
devstack
and
all
the
tests
passed
and
everything
and
say
hey.
I
I'm
you
know
super
awesome.
That
was
my
public
id.
G
M
A
Do
I
think,
I
think
it's
the
point.
I
just
think
we
have
to
ultimately
decide
if
we're
chasing
the
opportunity
of
creating
this
the
way
we
want
to
we're
going
to
not
do
it
because
we
don't
know
how
and
I
I
can
think
of
a
million
reasons.
This
none
of
this
will
ever
work
and
we
could
never
establish
core.
We
should
just
quit
tomorrow.
E
Despite
the
fact
that
we
will
have
a
core,
you
know
the
ability
to
say
I'm
encore,
the
only
real
way
to
know
is
for
the
people
that
are
using
that
software
to
to
really
you
know,
like
you
were
saying,
like
hey,
this
doesn't
work
worth
a
damn,
even
though
you
say
you're
on
core
right.
So
then
to
me
that
means
that
you
know.
A
Well,
I
think
I
think
that's
I
mean
this
is
where
I
get
a
good
question
if
we
never
get
there
to
where
this
actually
is,
but
I
asked
the
questions:
if
we
don't
know
how
to
get
there
from
the
starting
point,
do
we
not
start,
and
I
think
we
as
a
board
are
sort
of
saying
look.
We
can't
get
their
day
one,
but
that's
not
a
reason
to
start
with
something
and
work
towards
that
goal.
So
the
first
version
of
this
is
not
going
to
be
perfect.
A
J
A
E
Or
two,
where
openstack
has
changed
so
radically
every
release
I
mean,
I
think
two
or
three
releases
ago,
26
or
28
of
the
code
base
changed
and
we're
still
such
a
new
community
that
you
know
half
the
ship
we
used
to
push
to
the
core
things,
wouldn't
even
work
out
of
the
gate.
You
know
because
we
didn't
have
tests
for
them.
So
you
know
maybe
just
the
maturity
of
the
projects
and
having
the
testing
infrastructure
and
having
the
sea
ice
td
guys
working.
E
B
B
I
would
love
to
be
in
a
situation
two
years
from
now
where
we
are
completely
differentiating
the
market,
because
we
not
not
just
just
we
just
work
but
because
we
have
an
amazing
test
suite
that
sets
the
standard
for
what
an
open
source
project
regression
suite
should
be
sure,
because
that
to
me
creates
from
an
enterprise
perspective
that
creates
a
huge,
differentiated
value
right.
If
I'm,
if
I'm
looking
at
a
proprietary
cloud
infrastructure
and
they're
like
yeah,
we
test
it
internally,
we
have
all
this
stuff,
we
run
it.
No
problem.
B
Take
our
word
for
it
it's
great,
but
it's
a
totally
different
ball
game.
If
you're
like
look,
we
actually
have
a
growing
community
based
community
tests
and
when
you
got
it
when,
when
att
got
burned
because
somebody
changed
something,
then
they
wrote
a
test
and
they
put
it
in,
and
people
like,
oh
that
test
that
that
burned
me
too.
I
want
that
tested,
but.
E
I
15
minutes,
I
completely
guys
you
know,
I've
been
quiet
for
the
most
most
part,
but
this
has
been
a
really
good
discussion,
but
I
think
we're
trying
to
feed
too
much
into
this
idea
of
core.
I
mean
this
is
intended
to
be
as
inclusive
as
everything
else.
We've
done.
This
isn't
intended
to
be
exclusive.
This
isn't
intended
to
say
who's
cool
who's
inside
the
inside
club
or
any
of
those
things.
I
It's
it's
intended
to
help
protect
the
brand
of
what
is
openstack
and
to
help
help
people,
but
not
necessarily
be
the
only
definition
of
who
can
interoperate
who
can
work
together,
so
it
so
don't
tie
so
much
into
this
before
we've.
Even
you
know,
we're
just
getting
started
and
trying
to
figure
out
what
this
could
be.
Don't
don't
poke
too
many
holes
in
what
it's
not
already,
because
we
haven't
even
figured
out
the
the
basics
of
what
it
could,
what
it
could
be.
I
So
there's
a
lot
of
stuff
that
still
needs
to
be
done,
and
just
just
think
about
the
fact
that
we're
having
these
discussions
out
in
the
open
has
any
other
group
done
this
before.
Has
anybody
else
ever
had
their
board
meetings
in
the
wide
open?
No,
so
don't
don't
get
too
negative
too
quickly.
Just
and
in
fact
I
want
you
guys
to
get
in
and
really
beat
the
crap
out
of
the
tasks.
That's
what
we
need.
We
need
people
to
dig
in
and
say:
hey.
We
need
these
tests.
I
We
need
those
these
things,
I'm
not
so
sure
about
service
level
offerings.
You
know
being
able
to
say
that
you
know
if
you,
if
you
don't
respond
within
a
few
minutes,
that
that
you're
not
part
of
core
that
you
don't
pass
a
test,
but
that's
my
definition
of
that
shouldn't
be
the
only
answer.
It
should
be
the
community
and
everyone
that's
in
this
room
and
outside
in
the
community
making
that
definition.
A
F
It's
kind
of
an
open
source
definition
as
the
community.
The
board
has
kind
of
come
up
with
framework.
We've
got
ptls
that
are
putting
in
their
input.
We've
got
the
user
community,
that's
involved
and
everybody's.
You
know.
If
we,
you
know
we
we
treat
this
like.
We
would
treat
nova
or
swift
or
any
other
component.
The
framework.
B
And
I
I
I
actually
want
to
want
to
you
know:
I
love
that
you
guys
are
pressure
testing
this
right.
This
is
essential.
The
thing
that
we
we
fail
at
is:
if
we
come
back
and
we're
like
hey
guys,
here's
the
tablets,
here's
core
done
right.
We've
got
to
be
able
to
say
well
what,
if
this
happens,
what,
if
that
happens
as
long
as
you're
like
okay,
I'm
testing
you
to
make
sure
that
this
is
reasonable
and
you
I
love
that
we've
got
to
do
it.
B
I
want
you
guys
to
to
keep
doing
it
right,
and
you
know
be
aware
that
this
is
still
in
flight
and
we're
going
to
do
it
tend
towards
the
have
you
considered
this.
Is
this
a
way
to
solve
that
problem?
But-
and
actually
this
is
getting
good
to
you
know-
I
don't
want
us
to
go
all
night.
Yes,
but
you
know
there's
there's
something
I
I
I
and
all
these
conversations
with
honor
as
a
request
right
is
that
please
take
this
away.
You
guys
are
representatives
for
the
community.
B
You
know
continue
the
dialogue,
make
sure
that
you
tell
people
that
you
were
part
of
this
dialogue
right
that
you
were
you
sound
these
ideas
out.
They
make
sense
to
you
if
you
have
concerns
bring
them
right.
We
had
after
the
after
the
san
francisco
one.
We
had
a
really
great
long,
dynamic
chat
on
twitter,
some
of
the
classic
voices
about
you
know,
naysayers,
chimed
in
on
stuff,
and
we
had
back
some
forest
we're
not
trying
to
make
everybody
happy.
V
V
V
B
B
B
Community
and
I'll
work
on
this
we
owe
the
community
a
list
of,
and
we
did
this
with
the
ink
up,
and
it
was
really
effective
ink
up
with
the
incubation,
the
thing
that
just
described
incubation
and
integrated
releases
and
stuff
like
that,
we
said
we're
not
describing
what
chorus
in
this
project,
and
so
we
will,
we
will
come
back
and
describe.
These
are
things
that
we
are
not
trying
to
address.
Interoperability
is
one
of
them.
I
O
O
B
There
there
is,
there
is
actually
a
committee,
but
it
doesn't
it
doesn't.
Do
we
don't
really
have
great
ways
to
reach
out
to
the
users
per
se,
except
what
we're
trying
to
do
right.
We've
posted
this
on
blogs,
we're
we're
trying
to
reach
the
community,
we're
trying
and-
and
you
guys
are
part
of
a
broadening
spectrum
right.
We
actually
are
titrating
it's
one
of
my
favorite
words.
Sorry
we're
we're
we're.
B
B
So
you
know
we
started
in
oscon
with
a
very
with
a
small
event
with
san
francisco.
We
had
a
bigger
event.
You
guys
are
about
same
size,
san
francisco,
you're,
asking
great
questions.
I
I
will
tell
you
you're
turning
over
some
news,
new
rocks
but
you're.
Turning
over
a
lot
of
rocks
that
we've
heard
before,
which
means
we
have
to
do
a
better
job,
documenting
them,
and
that
doesn't
mean
there's
anything
wrong
with
with
that.
What
it
means
is
that
we're
getting
to
a
point
where
we've
actually
hit
right.
B
B
O
G
A
A
Go
both
of
those
things.
The
best
thing
that's
come
out
of
the
user
community
today
was
actually
all
the
statistics
that
they
gathered
through
surveying
the
user
base.
So,
while
there's
not,
you
know,
I
mean
tim
and
ryan
and
the
guys
that
are
on
that
committee
are
small.
As
a
committee,
they
have
been
able
to
reach
out
to
get
sort
of
surveyed
question
data
from
a
fairly
wide
audience.
So
you
know,
maybe
what
we
do
at
some
point
is
kind
of
go.
Okay,
you
know
we're
going
to
focus
on
these
tests.
B
R
To
leave
it
good
yeah
as
you're
saying
right
and
we've
had
a
lot
of
debates
about
0.2
made.
You
know
those
customers
were
very
used
to
devops
and
shut
puppet
configuration.
They
go
that
way,
but
we
constantly
hear
from
customers
who
are
not
there
yet
who
still
want
to
oh
they're,
never
mind
all
the
time.
B
A
And
you
can
go
to
vendors
and
say
well,
I
know
it's
not
core,
but
I
have
it
and
eventually
you
know
eventually
the
vendor.
You
know
eventually,
if
he's
not
getting
any
business,
because
everybody's
going
to
you,
because
you
have
it
right,
then
he's
got
a
decision
to
make
right
and
then
maybe
we
just
haven't
lost
before
I
mean
in
my
mind,
that's
that's.
How
this
evolves
is
the
marketplace
really
is
what
determines
how
we
measure
that
it's
harder
to
do
reality
than
conceptually
like.
E
E
B
So
part
of
part
of
what
to
me
the
thing
we're
trying
to
encourage
is
that
we
build
a
test
that
certifies
that
behavior,
that
that
use
case
that
I
find
important
right
and
if
that's
an
sla
or
a
time
I
don't
care.
I
want
those
tests
to
show
up
in
openstack
community
right.
They
might
not
be
campus
tests,
they
might
be
white,
but
I
don't
care.
I
want
those
tests
to
show
up,
and
then
you
can
run
those
tests.
B
E
B
B
What
I'm
hoping
to
do
is
align
them,
because,
because,
at
the
end
of
the
day
the
tests
are
the
use
cases
which
the
users
value
which
people
find
you
know,
that's
the
distance
value
that
we're
building,
and
so,
if
I
can
align
those
things
which
is
the
way
I
feel
like
we're
talking,
then
we've
got
a
good
thing.
If
I
fail
to
do
that,
I
might
define
like
today.
I
feel
like
we've
done
this.
We
just
defined
all
the
projects
at
the
time
of
foundation
as
core
projects.
M
I
think
the
more
important
thing
at
the
end
of
the
day
is
that
we
have
some
sort
of
test
to
validate
the
functionality
of
features
of
each
cloud
that
is
openstack
and
that
that
is
highly
visible
and
easy
for
people
to
run.
That
is
way
more
important
to
me
than
having
then
that
divine
some
sort
of
set
of
core
right,
and
I
think,
if
we
focus
on
that
more
and
then
get
the
data
like
what
you're
talking
about.
M
M
Immediately
look
and
say:
oh,
look,
these
support
exactly
what
I
need.
Oh
look,
they
somehow
goes
hey,
look,
they
support
this
and
we
don't
we're
losing
customers
to
them.
So
we
need
to
support
it
or
some
app
comes
out
that
says
that
is
everybody's
using,
but
our
cloud
doesn't
support
it.
So
I
would
much
rather
have
visibility
and
market
forces
driving
features
and
functionality,
rather
than
just
some
definition
that
the
ptl
is
made
up
of
what
core.
I
Should
be
so,
I
totally
can
I
respond
real
quick.
I
totally
agree
with
what
you're
saying
that
is
exactly
what
we
we
will
and
need
to
do,
because,
obviously
we
wouldn't
be
able
to
come
up
with
some
arbitrary
definition
of
what
is
core
by
next
month
or
even
in
six
months.
We
don't
know
exactly
how
we're
going
to
come
up
with
the
details
of
what
is
core,
but
the
thing
that
we
have
to
do
is
at
some
point
in
the
near
future.
I
We
have
to
come
up
with
the
what
the
brand
of
openstack
means
and
be
able
to
define
it
in
some
ways,
so
that
the
people
with
money
don't
walk
away
from
this
effort,
and
we
end
up
with
you
know
not
what
we
have
today
something
less
than
we
have
today.
So
if
we
don't
work
towards
keeping
the
the
companies
that
are
pouring
money
into
this
effort,
interested
that
they
have
something
viable
that
they
can
sell
and
interest
their
customers
in
purchasing
and
having
a
long-term
relationship,
we
will
lose.
I
So
we
have
a
huge
opportunity
here,
over
probably
the
next
year
to
maybe
even
outside
of
two
years,
to
come
up
with
a
really
awesome
working
definition
of
what
is
core
and
a
really
robust
set
of
tests.
Much
like
we
have
with
money
and
team
of
what's
been
done
with
the
ci
pipeline
is
really
unprecedented
and
super
awesome.
We
can
do
the
same
thing
with
the
testing
environment
as
well.
I
I
have
all
the
confidence
that
we
can,
but
we
don't
want
to
alienate
the
companies
that
are
pouring
money
into
this
right
now
and
they
have
to
have
something
they
can
sell
to
their
customers.
That
means
something,
and
unfortunately
it
means
a
trademark
so
that
that's
something
that's
mixed
into
this.
O
Yes,
I
suspect
will
happen
too.
Once
the
foundation
defines
what's
poor
becomes
good
oil,
it
becomes
a
check
box
for
incoming
users.
So
what
they're
going
to
say
is
while
there's
so
many
vendors
out
there
selling
openstack.
You
know
one
quick
way
for
me
now
the
choice
downs,
I'm
only
going
to
pick
the
vendors.
O
E
So
it's
gonna
cost
money
potentially
to
get.
You
know
the
resources
to
get
certified
by
core
that
small
vendors
are
going
to
have.
I
the
companies
that
are
understand
millions
of
dollars
into
this
in
order
to
give
them
a
piece
of
the
pie
back
right
like
to
be
able
to
give
this
brand
out.
But
you
know
I
don't
know.
M
And
you
know:
yes,
we
get
diluted
a
bit,
but
it's
a
lot
easier
to
then
after
we
have
data
to
start
to
constrain
that
in
and
to
me,
the
market
forces
will
weed
out
a
bunch
of
that
already
for
you
right.
If
someone
says
they're
openstack
people
are
going
to
find
out
really
quickly
that
either
they
are
aren't
or
there's
some
level
of
functionality.
They
do
or
don't
provide
and
are
very
quickly
going
to
determine
it's
not
going
to
be
because
they
have
some
cool,
beat
some
core
functionality
or
not.
B
B
So
what
we're
doing
is
look
if
you
don't
understand
how
good
tests
can
be
and
how
people
are
going
to
compare
products
based
on
test
results
and
real
data,
and
the
market
will
evolve
here.
If
that's
too
big
a
leak
for
you.
Unfortunately,
I
think
it
is
a
big
leap
for
for
people
who
don't
you
know
there
are
a
significant
number
of
people
in
this,
especially
the
the
non-community
focused
money
interests
in
openstack
and
god
bless,
and
we
need
them.
What's
that
for
openstack
yeah.
B
B
So
what
what
happens
is
is
that
that
it
creates
a
bridge
and
so
right
this,
but
what
you're?
What
you're
doing
to
me
is
exactly
the
test
that
we
want
with
this.
If
you
say
oh
overall
we're
driving
in
a
direction
this
drives
in
a
direction
where
we
don't
need
core
definitions
at
all.
I
actually
see
that
as
a
likely
outcome.
B
That's
a
success
outcome.
I
can,
in
the
short
term,
there's
commercial
interests
that
understand
core
and
they're.
They
will
put
up
with
the
fact
that
we're
using
tests
to
find
it
and
might
actually
play-
and
so
this
is
this-
is
our
carrot
if
you
will
to
help
help
bring
people
along
into
the
mindset
that
you
already
have
because
you've
seen
the
positive
effect.
O
N
E
A
Does
that
mean
we're
going
to
get
all
the
interoperability
that
every
user
wants
in
the
first
pass
before
now?
I
don't
think
so,
like
I
don't
know
that
we'll
solve
the
image
problem,
but
we
better
damn
well,
you
know
solve
you,
know,
80
of
the
core
api
that
people
know
they
can
run
code
against
is
going
to
be
the
same
somewhere.
A
You
know
completely
arbitrary
by
some
guys
in
the
back
room
right,
and
so
yes,
there
could
be
a
scenario
but,
like
rob
said,
what
we
wanted
to
do
was
come
out
with
the
tablets
that
the
big
money
guys
did.
This
is
gonna,
be
it
everybody's
gonna
follow
could
have
done
it
that
way,
and
then
that's
where
we're
going.
You
know
I
I
disagree
that
we
should
sort
of
say
interoperability
is
not
dealt
with.
I
think
we
should
say
it's
not
completely
solved
by
this,
but
I
do
think
right.
A
B
B
We'll
we'll
end
up
listening,
and
this
is
what
I
suspect
we're
not
listening
to.
You
know
a
you
know,
major
cloud
provider
like
rackspace
who
says
guys
we're
not
going
to
pass
any
keystone
test
if
you
make
keystone
required
it's
going
to
suck
for
us,
we're
like
okay,
that's
in
that
middle
30
percent
and
well.
So
so
then,.
E
Projects
or
programs
are
no
longer
core,
it's
really
about
the
functionality
between
a
set
of
them
that
is
defined
in
core
right.
There's,
no
such
thing
as
a
core
like
novus,
not
core,
but
the
one-third
of
nova
that
operates
with
glance
and
keystone
together
in
these
environments
is
now
core
and
nova
is
just
a
project
at
that
point,
just
like
trope
is
like
personally
I'm
not
even
I
don't
want
to
be
core.
B
B
Right
you're
requiring
a
reference,
there's
a
whole
bunch
of
stuff.
That
goes
with
that,
and
I
think
it's
going
to
be
a
tippy
scale
where
one
you
we're
not
going
to
have
one
a
project
with
one
must-pass
test,
we're
going
to
say
all
right,
there's
a
whole
bunch
we're
going
to
sort
of
build
up
a
certain
amount
of
tests
that
look
like
they're
candidates
and
they're
going
to
come
into
the
batch
and
that
whole
project
sure.
But
it
doesn't.