►
From YouTube: OpenStack Core online meetup Oct 22
Description
Community Discussion about OpenStack "what is core" process
A
You
know
core,
or
you
know,
a
larger
component
of
the
OpenStack
project
and
so
wet
as
it
became
clear
that
the
board
had
to
define
these
things
that
in
the
bylaws
when
they
were
formed,
it
just
picked
all
of
the
current
projects
and
decreed
at
the
time
that
they
were
to
be
core.
That
isn't
necessarily
a
workable
discussion.
We'll
get
into
why
some
of
things
that
our
core
might
not
be
core
things
that
aren't
core
right
now
should
be
core
and
there's
a
lot
of
interesting
conversation
to
be
had
about
that.
A
But
it
became
clear
very
quickly
in
discussions
that
it
was
not
going
to
be
an
easy
conversation
right.
There
there's
a
lot
of
very
passionate
people
about
different
aspects
of
this,
about
trying
to
make
sure
that
OpenStack
stays
innovative,
trying
to
make
OpenStack
be
stable,
making
sure
that
OpenStack
has
a
strong
interoperability
trying
to
help
companies
who
have
commercial
interests,
figure
out
what
they
have
to
include
and
what
they
don't
have
to
include.
If
they're
going
to
repackage
OpenStack,
you
reduce
the
confusion
around
it.
A
That's
really
a
big
mind
map
that,
where
we
tried
to
map
app
attentions
I'm
not
going
to
go
through
that.
That's
that's
in
my
blogs.
You
can
look
at
that,
but
what
we
identified
very
clearly
is
that
the
within
OpenStack
there
are
you
good
conflicts,
good
tension
between
innovation
and
stability
between
commercial
and
open
source,
interest
between
api's
versus
implementations,
all
right!
A
There's
all
these
places,
where
the
the
very
essence
of
OpenStack
has
a
duality
to
it
and
so
trying
to
resolve
that
was
ultimately
where
we
had
to
come
come
through
and
we
got
to
a
point
just
looking
back
on
history,
where
we
identified
something
like
plugins
with
time.
We
work
on
plugins
extensibility
points
is
being
essential
and
we've
been
walking
through
the
process
to
where
we
are
today,
which
is
a
set
of
ten
positions
about
how
we're
going
to
define
core
and
I'm
about
to
walk
through
those
ten
positions.
A
But
before
I
do
I,
there's
a
couple
things
I
need
to
stage
up
now
that
I'm
done
with
the
history.
The
first
one
is
that
that
the
purpose
here
is
not
to
say
this
is
core.
This
isn't
core
we're
not
defining
that
tonight.
The
purpose
is
to
define
the
process
by
which
we
are
going
to
figure
out
what
score
not
for
in
the
discussions.
A
A
B
A
But
if
you
want
to
scroll
them
in
IRC,
that's
awesome,
I'm,
happy
too
happy
to
entertain
them
and
in
some
cases,
there's
some
questions,
I'm
going
to
anticipate
and
try
and
answer
as
I
go
through
the
process
flows
and
one
of
the
things
that
people
need
to
understand
is
I've
talked
to
a
lot
of
people
about
this,
and
I'll
actually
represent
different
people's
positions
on
this.
This
is
not
my
position,
I'm
really
working
hard
to
try
and
make
sure
that
I'm
presenting
a
position
of
consensus,
sort
of
that
comes
from
having
a
lot
of
discussions.
A
The
other
thing
that
I
would
ask
when
you,
when
you
listen
to
this,
is
to
consider
that
the
goal
is
not
simply
to
define
core
the
goal,
for
what
we're
doing
is
also
to
make
sure
that
OpenStack
culture
is
something
that
we,
you
know
that
we're
doing
something
that
enforces
OpenStack
culture
and
that
sounds
sort
of
vague.
But
it's
not
it's
very
specific
OpenStack
is
an
open
source
project.
We
want
to
make
sure
that
people
have
reasons
to
upstream,
to
have
high
quality
code
to
engage
and
understand
what
OpenStack
is
about
that.
A
We
want
to
lean
the
project
through
implementation
and
proof,
and
you
know
it
actually
deliveries
the
really
core
cultural
components
for
what
OpenStack
is
about,
and
so
one
of
the
things
to
ask
as
we
go
through
this
process
is.
Does
this
process
reinforce
the
cultural
things
that
we
want
OpenStack
to
achieve
right?
It
doesn't
do
us
any
good
to
define
OpenStack
core
and
then
have
people
say
well
that
sucks
I'm
going
to
fork
it
all
over
the
place
and
then
we're
going
to
have
we're
going
to
be
competing
with
our
own
community.
A
So
there
we
very
deliberately
look
at
this
process
and
ask:
are
we
defining
the
core
process
or
in
core
itself
in
a
way
that
encourages
the
community
to
grow
and
thrive
or
not?
And
so
I
always
preamble
this
the
flowchart
by
talking
about
you,
know
that
exact
thing,
because
it's
important
not
just
to
look
at
the
technical
aspects,
commercial
aspects,
but
also
the
OpenStack
community
aspects.
A
A
And
this
is
backed
up
by
there's
a
lot
of
text
on
this
blog
post
that
actually
goes
into
what
these
items
are
and
then
there's
a
whole
bunch
of
links
from
they
go
backwards.
If
you
want
to
drill
into
spider,
chart
and
history
and
implementation,
I
think
I
feel
like
I've
written
a
small
book
about
OpenStack
core.
At
this
point
so
I'm
going
to
let
me
go
through
the
floor.
The
flowchart
Nomo
will
start
taking
questions.
Do
people
understand
the
before
I
do
this,
and
this
is
implementation?
A
A
C
Be
given
to
so
that
would
be
the
only
thing,
it's
kind
of
a
commercial
aspect
or
the
trademark
aspect
to
this
effort.
It's
by
no
means
the
only
reason
to
do
it,
but
it
is
one
of
the
one
of
the
things
that
has
a
definite
timer
on
it.
The
longer
that
we
let
the
OpenStack
brand
kind
of
hang
out
there
without
a
good
definition
of
what
the
opus
deck
brand
means
the
last
control
we
have
over
it
so
right,
it
needs
to
be
done
sooner
than
later,
then,.
A
B
A
There's
a
it's
a
really
good
question:
it's
worth
it's
worth,
taking
a
minute
to
answer,
so
trademarks
are
actually
the
only
enforcement
mechanism.
This
is
the
primary
enforcement
mechanism.
The
openstack
foundation
has
against
the
use.
If
we
just
willy-nilly,
let
anybody
say
anything
about
OpenStack,
then
it
becomes
really
impossible
for
a
user
of
OpenStack
or
an
operator
of
OpenStack
to
know
that
they're
getting
OpenStack
right.
They,
the
quality
of
the
brand,
would
diminish
because
it
wouldn't
be
interoperable
right.
A
We've
heard
really
clearly
that
that's
a
value
so
part
of
core
is
to
define
base
components
that
you
can
make
interoperate.
It
helps
people
who
are
using
OpenStack
understand
what
they're
getting
that
they're.
Actually,
you
know
is
a
thing
that
is
OpenStack
and
if
they
get
it
from
one
one
person
right.
A
If,
if
somebody
got
the
Red
Hat
distribution,
then
of
OpenStack,
then
they
would
have
a
reasonable
assurance
that
if
they
switch
to
the
Susa
one
or
the
a
bunch
of
one
are
now
the
HP
one
or
the
marantis
one
and
the
Rackspace
oneness
we're
getting
the
liberation
of
distributions.
It's
exactly
the
reason
why
we
want
to
have
core.
We
want
to
be
able
to
say
these
things
must
be
included
in
court.
Sean's
been
leading
the
training,
effort
and
training
has
exactly
the
same
question.
A
If
you're
going
to
get
OpenStack
certified
training,
which
is
OpenStack
training
without
certification,
there
needs
to
be
some
consistency
that
says
this
piece
is,
you
know
a
required
component
for
OpenStack,
it
doesn't
limit
us,
and
this
is
part
of
the
what
we'll
talk
about
in
the
process,
though
it
doesn't
mean
that
there
won't
be
things
in
the
project
that
are
integrated
right.
This
is
one
of
our
key
words
is
integrated
into
the
release.
B
A
A
A
It's
not
even
api's.
It's
really
services
and
capabilities
that
the
community,
whether
it's
operators,
users,
ecosystem
vendors,
right
cloud
providers,
can
say
distinctly.
They
are
compliant,
and
this
really
came
to
a
head
in
its
come
to
a
head
in
a
lot
of
different
places.
In
some
cases,
the
stay
out
of
that
one
in
the
rack
space
versus
HP
were
both
running
I.
Guess
it
was
Essex
at
the
time,
but
implemented
slightly
differently
and
therefore
not
you
know
didn't
have
the
same.
A
You
know
that
you
actually
had
different
versions
of
fog
had
to
be
run
against
each
one,
but
yet
both
comply
it
can
we
clear
an
e6,
sorry
starts
with
diet
blow
and
I'm
gonna
die
a
blow.
Sorry
about
that
right.
Thank
you,
but
both
of
them,
according
to
the
OpenStack
definitions,
were
OpenStack
clouds.
A
So
you
know
we
want
to
have
a
definition
of
core
that
is
specific
enough.
That
and
now
now
I'm
getting
straight
into
the
process
flows
that
the
user,
that
the
community
is
not
just
users,
the
community
of
OpenStack
understands
what
they
can
expect
as
the
core
pieces
and
that
even
builds
on
integrated
projects
that
then
rely
up
running
trove
and
trophic
specs
Nova
api's
to
be
accessible.
That
you
know,
trove
has
an
expectation
that
Nova's
there
so.
B
So,
to
summarize,
it's
kind
of
like
the
made
for
ipod
mark
on
my
headphones
right.
What
we're
really
trying
to
do
is
provide
a
definition
that
says
if
you
write
a
theme
that
uses
OpenStack
as
long
as
you
limit
yourself
to
the
things
that
are
actors
core
anybody
who
uses
the
word
oak
OpenStack
should
be
able
to
run
your
app.
Is
that
a
fair
summary
that
that.
B
A
Let
me
hold
that
one,
because
I
do
let
me
get
to
that:
okay
co-parents,
a
great
question
yeah,
so
I'm
going
to
move
the.
So
through
all
this
process,
we
sort
of
boil
things
down
into
these
ten
positions
and
they
they're.
Actually
they
build
on
each
other
and
they're
color-coded,
because
they
do
group
a
little
bit
so
starting
in
the
top
left.
A
We
start
with
what
we've
been
saying
that
implementations
are
core,
can
use
the
OpenStack
trademark,
so
the
we
want
the
OpenStack
brand
to
mean
something,
and
so
this
is
this
is
our
leverage
point
we
could
actually
say.
Oh
you
are,
you
know
you
are
like
OpenStack,
but
you're
not
and
you
but
and
you're
not
complying
with
core.
So
you
can't
use
the
trademark
so
that
that's
our
ultimate
lever
and
it's
the
ultimate.
We
want
the
brand
to
mean
something
be
something
valuable
and
what
we've?
A
What
we're
saying
is
core
is
a
subset
of
the
whole
project.
So
there
are
our
integrated
projects.
There
are
components
that
are
important
in
OpenStack,
but
might
not
be
core.
So
core
is
not
we're
not
trying
to
create
a
single
umbrella.
Core
is
by
design
a
smaller
part
and,
and
one
of
the
challenges
we
have
with
this
is
getting
over
the
idea
that
a
project
is
less
if
it's
not
core.
A
A
You
know
what
we're
looking
for
here
is
a
least
common
denominator,
core
definition,
and
when
people
talk
about
this
one
of
the
places
we
have
great
animated
discussions
is
the
idea
of
well
okay.
Great.
If
core
is
this
Universal
definition?
Are
we
going
to
end
up
having
core
definitions
that
apply
to
specific
usage
models?
A
That's
downstream
stuff
right
now
we're
looking
for
a
universal
core
subset
rights,
the
base,
so
that
sort
of
defines
core
and
its
applicability
into
the
ecosystem.
Technically
we
implement
it
like
this.
We
require
the
use
of
designated
code
frameworks.
What
that
means
is
that,
in
order
to
be
core,
you
must
use
OpenStack
code.
A
In
some
cases
we
we
call
those
plugins
before
or
extensions.
It
doesn't
matter
in
this
definition.
What
we're
doing
is
we're
saying
the
technical
technical
board
boards
in
OpenStack
will
say
this
must
be
in
and
this
this,
this
part
of
the
code
must
be
there,
and
this
there
are
people
who
feel
this
always
generates
a
lot
of
discussion.
A
This
is
this
is
considered
essential
to
help
drive
community
behavior
and
anti
and
non
forking,
because
we
want
to
make
sure
that
people
are
using
OpenStack
code
and
not
just
creating
an
API
equivalent
and
then
effectively
creating
a
second
shadow
OpenStack.
This
requires,
if
you're,
going
to
use
the
OpenStack
brand,
you
must
choose
the
OpenStack
code.
The
designated
aspects
of
the
OpenStack
code,
I'm,
going
to
keep
drilling
I,
know
we'll
come
back
to
this
point,
and
then
we
have
a.
We
have
a
choice.
A
A
project
must
have
an
open
reference
implementations
that
means
that
if
you're
implementing
Neutron
networks
there,
you
must
have
an
open
reference
implementation
that
implements
the
functionality
of
OpenStack
networking.
That
is
a
required
peace.
There
could
potentially
be
more
than
one.
There
must
be
at
least
one
open
reference
implementation.
We
very
much
want
to
be
completely
away
from
the
idea
that
functionality
that
OpenStack
offers
might
be
unavailable.
Unless
you,
you
have
a
proprietary
component
that
doesn't
mean
that
it's
the
most
the
open
reference
implementation
might
not
be
the
most
performant.
A
It
might
not
be
scalable,
it
might
not
meet
a
ton
of
actual
operative
needs,
but
the
capabilities
of
the
OpenStack
must
have
an
open
reference
implementation
and-
and
this
is
it's
very
important-
that
this
is
an
and
and
vendors
may
substitute,
alternate
implementations.
So
if
I
have
a
neutron
plugin
that
implements
all
of
the
functionality
of
the
reference
implementation,
I
can
ship
that,
instead
of
the
reference
implementation,
okay,
either
one
is,
is
acceptable.
A
Both
of
them
are
paths
through
being
core,
so
either.
The
reason
why
that's
an
and
is
I
can
be
successfully
OpenStack
core
with
a
proprietary
implementation
as
long
as
it
passes
the
next
set
of
positions
so
so
far
we're
walking
down
with.
We
now
have
this
branch.
They
come
back
together
to
say
we
have
open.
A
We
have
we
verify
OpenStack
using
open
community
tests,
so
I'm
actually
really
proud
of
how
much
testing
and
CI
and
continuous
deployment,
which
is
enabled
by
the
that
is
part
of
the
OpenStack
project,
and
so
this
position
actually
lays
out
we're
expecting
that
the
OpenStack
itself
will
be
valid,
verified
by
open
community
tests
and
that
those
tests
can
be
remotely
or
self-administered.
So
the
idea
here
is
that
we
have
a
body
of
tests.
A
A
A
If
you
don't
have,
if
you
have
a
private
cloud
that
has
no
external
connectivity,
you
could
self
administer
these
tests
and
make
sure
that
that
you
also
are
in
compliance
and
one
of
the
things
we
did
not
want
to
do
in
having
these
discussions
was
to
create
the
need
for
OpenStack
police
force,
running
around
handing
out
certification
stickers
for
openstack,
and
that's
why
it's
either/or
remote
for
self
and
then
so.
The
trick
is
now.
We
have
this
body
of
tests,
I.
A
A
A
A
A
A
No,
so
so
you
missed
that
piece
so
specifically
and
Monty
I
know
this
is
this
is
a
very
important
point
to
you
and
I
sometimes
think
of
this.
This
required
use
of
code
frameworks
box
as
your
box,
because
you
very
specifically
we
are
requiring
use
of
OpenStack
code
in
the
definition
of
core.
You
cannot
be
a
core
OpenStack
project
without
using
OpenStack
code,
and
that
is
part
of
the
cultural
tests
of
making
sure
that
people
drive
innovation
back
to
the
project.
So
it's.
D
Go
ahead,
so
we
nice
when
I
read
something,
says
designated
code
frameworks
to
me.
That
sounds
like,
but
you
must
use
flask.
We
must
use
pecan,
you
must
use
wsm
a
frameworks
are
the
bits
that
we
build
large
replications
out
of,
but
my
expectation
from
this
is
that
would
be
saying
you
must
use
Nova
and
you
may
drop
a
vendor
plugin
into
nova.
D
A
Open
to
other
language,
we
had
some
discussion
about
this
in
previous
meetups
and
what
out?
What
ask
is
let's
hold
that
for
as
part
of
the
discussion
and
I'm
entirely
open
to
it,
and
if
we
can
come
up
with
better
wording,
I
will
I
would
love
to
see
it.
So
let
me
let
me
just
wrap
this
up
and
then
we'll
we'll
come
back
to
that,
because
that
is
one.
B
A
And
specifically,
specifically,
this
is
so
when
we
first
proposed
this.
We
used
the
word
plugin
and
extension
and
and
that
got
an
allergic
reaction
frankly
from
the
ptl's
in
the
TC,
because
it
was,
it
seemed
to
be
stipulating
and
implementation,
and
so
what
we
did
was
we
pull
back
and
said.
Look
the
TC.
You
tell
us
what
things
we
must
require
from
a
code
position
and
where
it
is
safe
for
people
to
substitute,
and
that
is
that
is
up
to
the
TC
to
decide
what
we
know
is.
A
We
do
want
to
be
able
to
allow
vendors
to
substitute
pieces,
so
Neutron
plugins
are
a
great
example.
Cinder
plugins
are
a
great
example,
alternate
hypervisors,
great
examples.
You
know
there's
a
lot
of
places.
We
enable
people
to
make
changes
in
OpenStack
and
based
on
the
spider.
We
really
want
to
encourage
that
that's
great
behavior,
as
long
as
you
can
implement
them
as
long
as
there's
a
reference
implementation
that
doesn't
require
you
to
use
a
proprietary
implementation
right.
D
A
Thank
you
and
do
there's
because
there's
interesting
mitigations
that
we
have
and
we
get
a
little
bit
further
alone,
so
I
just
walked
through
the
point
where
we
had
a
open
community
tasks.
That
could
be
self-administered,
and
this
is
this
is
where
we
get
into
the
real
meat
of
what
makes
something
core
or
not.
So
everything
else
is
sort
of
here's
what
we're
packaging
and
then
we're
saying
you
know
what
of
these
tests.
Some
of
them
will
be
chosen
as
must
pass
tests.
A
It
is
actually
the
board's
responsibility
based
on
way
to
governance,
is
set
up
to
identify
what
is
core
identifying.
What
his
core
would
be
identifying.
What
is
a
must
pass
test
or
not,
there's
an
expectation
and
in
our
discussions
that
we'd
have
a
nominating
process
that
would
be
facilitated
by
the
user
committee
and
there's
a
whole
bunch
of
implementation
to
put
around
this.
A
A
So
if
I
build
an
OpenStack
deployment
and
make
it
completely
out
of
the
box
and
set
it
up,
I
should
be
able
to
pass
all
the
must
pass
tests
with
my
reference,
implementation
and
I
would
know
that
I
have
an
OpenStack
core
cloud.
If
I
then
substitute
a
vendor's
component
into
that
and
pass
and
once
again
pass
all
the
must-pass
test,
then
I
can
also
say:
I
am
OpenStack
core
or
if
I
have
a
clot
on
a
public
cloud
service
that
passes
all
the
must
pass
tests.
A
I'm
going
to
switch
off
of
I'm
going
to
switch
off
of
this
and
go
back
to
visual
so
that
if
people
I
don't
know
if
it's
helpful
to
see
me
talk
or
not
but
see
there,
we
go
and
then
I'll
trust
people
to
refer
to
it
back
on
their
own
from
the
the
web
page
cool
all
right.
So
any
anything
to
add
for
that,
that's
that's
sort
of
the
the
description
I
usually
give,
and
then
we
can
drill.
We
can
start
drilling
into
questions.
B
B
B
D
B
C
B
A
This
is
where
that
that
clause
that
that
first
blue
box
comes
in.
If
you
are
not
running
the
designated
code
frameworks,
then
you
are
not
core
and
so
the
situation
you're,
describing
if
somebody
patched
it
and
didn't
upstream
that
patch
I
would,
I
would
say,
they're
not
core
anymore.
Now
we're
not
going
to
create
a
police.
A
B
B
C
B
D
D
The
code
has
to
be
visible
in
the
community.
Let's
say
it
hasn't
passed
review
its,
but
it's
up
in
here.
Oh,
that
is
at
least
that
the
function
that
people
can
be
collaborating
on
it
and
benefiting
from
it
and
saying
ye
is
part
of
one
for
me,
I,
don't
know
if
that's
sufficient,
but
I
think
it's
definitely
necessary.
So.
B
A
What
we
want
to
do
is
we
wanted
to
find
us
based
on
implementation,
so
actually
getting
field
data
about
what
tests
are
passing
in
the
field
at
WIPP
sites
right
actually
look
at
it
and
if
we
could
say,
oh,
you
know
what
only
thirty
percent
of
OpenStack
deployments
based
on
some
measure,
I,
don't
I.
Don't
we're
going
to
have
to
figure
that
out
used
the
cells,
then
those
tests
wouldn't
become,
must
pass
tests
and
then
you
would
say
Nova
what
cells
is
not
core.
D
C
A
D
D
A
A
But
I
would
expect
basically
you've
made
a
couple
of
different
cases
and
I
think
they're
really
interesting
cases,
but
several
of
them
would
involve
known
extension
points
and
so
a
lot
of
what
we'd
expect
and
the
cultural
tests
on
the
core
flow
here
is
that
we'd
actually
expect
somebody
who
wanted
to
do
that
type
of
change
to
upstream
the
change
as
a
plug-in.
Extensibility
point
and
say:
look
I'm
not
going
to
share
this
way.
I'm
doing
things
with
you,
but
I'm
going
to
identify
an
extensibility
point.
A
I'd
like
to
see
added
and
how
an
expect
that
you
will
help
you
they'll
actually
upstream
the
extensibility
point
with
a
reference
implementation,
so
they're
in
the
clear
on
doing
that.
Some
of
what
you're
describing
also
is
around
release
boundaries.
So
we've
discussed
this
a
little
bit.
When
do
you
actually
certify,
and
so
the
expectation
is
that
the
tests
that
you
did
for
a
version
say
ice
house
right
would
be
certified
within
a
certain
time
period.
Ideally,
within
two
weeks
it
could
be
longer,
as
the
the
board
would
actually
say.
A
A
The
market
would
actually
punish
you
if
you
misrepresented
that
you
would
certified
against
ice
house
and
then
change
that
for
the
fact,
if
you're
doing
a
colonel
patch
or
something
like
that,
it's
most
likely
going
to
be
a.
Maybe
I'm
naive
on
this.
But
it's
going
to
be
against
code.
That
you're
trying
to
get
in
for
the
next
version
we're
trying
to
create
a
stable,
predictable.
You
know
we'll
know
it
when,
at
the
feature
freeze
point
we
should
know
what
the
month
most
Pat
must
pass
test.
A
B
I
want
to
reinforce
that
I'm,
not
necessarily
trying
to
describe
Ilene
champ,
let's
say
I'm
trying
to
land
a
really
big
feature
and
I
wanted
to
be
in
the
required
for
upstream
bro,
but
it
takes
me
more
than
one
piece
get
it
to
a
stage
where
upstream
is
willing
to
take
it,
but
I
have
customers
using
it
sure.
Does
that
mean
for
that
transition
period?
I
have
to
stop
calling
myself
cool,
even
though
I'm
trying
to
play
by
the
rules.
It's.
B
Lattice
so
sales
to
keep
going
with
that
example.
As
thousands
of
lines
of
quoted
it
took
more
than
one
relates
to
land
in
upstream,
but
that
wasn't
for
lack
of
trying.
It
was.
You
know,
who's
written
for
a
specific
use
case,
and
then
that
had
code
had
to
become
more
general
before
it
was,
you
know,
a
consensus
could
be
reached
so.
B
A
D
B
And
again,
I
want
to
reinforce
the
Rackspace,
doesn't
necessarily
get
my
honor
to
speak
for
rackspace
I'm.
Here
it's
just
a
dude,
but
yeah
rec
space
has
done
this
in
the
past
right
and
what
you're
effectively
saying
is.
We
would
have
to
change
the
entire
way
we
developed
things.
We
would
have
to
do
them
in
small
chunks
incremental
e
in
upstream,
and
that
would
be
significantly
slower
and
sometimes
maybe
slowness
isn't
possible
when
you
were
running
a
large
public
cloud,
I
don't
know
exactly.
D
A
A
D
There's
a
bunch
of
changes
to
the
code,
which
means
that
if
you
look
at
the
code
running
in
the
right
space
public
cloud,
this
the
code
currently
in
track
in
the
scenario
they're
not
the
same.
But
all
of
that
code
because
rackspace
know
they
wanted
to
be
public-
is
up
and
Gareth.
It's
just
not
useful
for
anyone.
Yet
because
when
you
look
at
it
and
Garrett,
it's
got
a
thousand
minus
one
zone.
D
To
me,
that
seems
like
a
situation
where
they
should
be
able
to
retain
the
trademark.
The
tests
pass
that
playing
in
the
community
they're
not
walking
off
and
going
down
their
own
little
silo.
That
seems
like
the
behavior
we
want
to
encourage,
but
I
think
they
should
get
the
reward
I
strongly
surreal.
Knowing
that.
B
D
A
B
And
maybe
we
could
be
more
exposed.
Maybe
in
that
scenario,
what's
expected
is
that
Rackspace
goes
to
the
TC
and
asks
for
a
hallway
pups
crew.
We
are
running
these
patches.
They
are
in
the
review
process.
They
don't
cause
any
required
tests
to
fail.
We
publicly
disclose
we're
doing
this
thing
on
the
understanding
that
we
have
tried
very
hard
to
land
it.
What.
A
What
you
have
just
described
to
me
is
a
very
is
a
very
good
test
for
what
we're
talking
about,
and
actually
one
of
the
reasons
why
I
like
this
approach,
because
Rackspace
can
come
back
and
say
concretely,
I
am
passing
all
of
the
core
tests.
I
am
interoperable
from
that
perspective,
and
you
know
I
think
that
if
you
came
back
and
said
I,
the
code
that
we're
using
is
in
you
know
is
in
OpenStack
it's
in
the
up
streams
and
in
these
designated
areas
I
would.
A
I
would
say
that
that
would
be
an
argument
where
you
could
do
it.
We
might
want
to
explicitly
enable
somebody
to
do
that,
although
I'd
rather
handle
it
as
a
as
an
exception
process
I.
This
is
one
of
those
things
where
you
know
we
don't.
When
we
discuss
this,
we
didn't
want
to
create
a
legalistic
definition.
A
It
would
be
different
if
they
had
patches
proprietary
patches
to
core
and,
up
to
frankly,
we've
seen
this
to
an
extent
where
there's
changes
to
Swift
that
people
sort
of
put
in
that
aren't
accepted
as
part
of
the
body
of
Swift
to
create
Swift
compliance
and
Swift
ends
up
being
an
interesting
test
for
these
things,
where
you
can
comply
with
the
api's,
but
not
implements
lift,
and
so
in
that
case
is
waiting
pass.
If
Swift
is
core,
the
Swift
isn't
core
two
different.
We
we
end
up
with
different
questions.
A
B
I
think,
to
be
honest,
continuous
deployment
makes
this
worse
to
write
because
I'm
already
in
a
world
in
which
I'm
taking
code
out
of
gear,
I'm
trying
to
run
it.
I
discover
I
found
a
bug.
I
fix
that
bug
in
my
continuous
deploy
and
then
I
try
and
push
that
bug
fix
upstream,
while
still
running
forwards
with
deploying
this
thing.
So
so
you
know
I,
imagine
any
to
any
team.
That's
continuously
deploying
it
will
be
constantly
jumping
away
from
upstream,
but
then
trying
to
merge
this.
A
I'm
totally
in
favor
of
that.
Here's
the
trick
that
the
it's
supposed
to
be
a
point
in
time
statement
we're
not
trying
to
say
that
every
moment
of
every
day
you
must,
especially
if
you're
a
continuous
deployment
shop.
You
must
be
in
compliance.
What
we're
trying
to
do
is
establish
for
this
release.
Here
are
the
tests
that
you
must
pass
be
in
this
week?
A
Well,
you
get
you
guys
are
describing
great
cases
where
I
think
that
if
you
look
at
what
you
know,
if
you're
ahead
of
trunk
on
this
I,
don't
think
we're
going
to
have
issues
with
OpenStack,
especially
if
you
pass
the
tests.
I
think
that
without
the
tests,
the
questions
you're
asking
are
open
up
cans
of
worms
that
would
be
a
mess
with
the
tests.
I
think
it
becomes
much
more
straightforward.
A
You
can
say
I
pass
the
test
for
havana
at
this
point
in
my
cloud,
and
this
was
the
state
of
my
code
and
then
you're
at
that
point.
You
are
now
OpenStack
core
and
if
you
advance
beyond
that
point
and
you're
still
passing
a
test
work,
we
should
be
good
that
that's
not
a
problem.
The
point
is
that
we
want
to
be
able
to
give
you
a
milestone
point
where
you
can
certify
I
am
in
compliant
with
OpenStack
and
I've
remain
in
compliance
because
I'm
passing
the
tests.
A
B
C
D
Prefer
a
much
simpler
test
rather
than
something
of
intent.
We
are
sort
of
predicting
the
future
I
just
like
to
say
if
the
code
you're
running
is
in
Garrett
and
it's
visible
to
either
the
security
team
or
to
the
core
team
for
the
component
and
you're
responding
to
review
your
not
using
this
to
a
code
dumped
there
and
walked
away
those
two
things
in
gear
and
you're
responding
to
go
review.
That's
enough!
For
me
to
be
confident.
The
organization's
is
moving
forward
in
the
right
direction.
Yeah.
B
D
B
D
C
Sorry
I,
so
there
is
an
important
distinction
between
the
spirit
of
law
and
the
rule
of
law
and
the
I'm
using
the
word
bought
very
loosely
here,
but
also
the
interoperability
piece
compared
to
the
implement
the
implementation
of
the
code
base.
So
those
things
we
we're
going
to
have
to
separate
in
some
ways
because
the
if,
for
instance,
a
implementation
goes
far
off
the
reservation
and
is
no
longer
interoperable
and
it
is
a
service
provider
with
other
patients
of
OpenStack.
C
That
should
be
a
problem
now,
if
that
last
for
a
long
period
of
time,
let's
say
months
and
months
and
they're
not
no
longer
interoperable
with
other
implementations
of
OpenStack.
Therefore,
customers
that
used
to
be
able
to
use
it
now
can't
because
they're
they're
compatible
with
home
exact,
and
this
other
implementation
was
but
isn't
anymore,
that
that
should
be
a
significant
problem.
But.
D
D
A
And
if
I
think
it
would
be
worthwhile
to
make
the
statement
that
we're
expecting
you
know
you
must,
you
must
run
the
OpenStack
code,
but
it
that
it's
acceptable
to
have
code
in
advance
of
the
release.
You
know
basically
ahead
as
long
as
it's
been
contributed
to
the
community,
it's
not
going
to
be
acceptable.
A
B
A
So
I
was
going
to
vector
away
a
little
bit.
We
were
talking
about
in
it
6b
6b
on
this.
This
actually
I
think
comes
back
into
the
same.
This
is
a
good
segue,
so
we're
talking
with
six
with
item
6b
about
substituting
implementations
is
that
if
the,
if
the
vendor
does
not
pass
all
the
relevant
tests,
the
vendor
is
required
to
include
an
open
source
reference
of
limitation.
Oh.
A
Sorry
this
this
one's,
this
one's
me
maybe
needs
to
be
improving
in
the
wording.
The
idea
here
is
that
if
I
was
give
a
scenario,
let's
say
that
I
had
a
OpenStack
appliance
and
that
OpenStack
appliance
had
a
storage
back
end.
That
was
not
in
that
didn't
past
the
compliance
tests
did
it.
It
had
slightly
different
performance
characteristics
and
there
were
tests
that
failed.
A
The
idea
would
be
that
somebody
purchasing
that
appliance
could
use
the
open
source
reference
implementation
if
they
needed
to,
and
they
wouldn't
be
beholden
to
have
a
implementation
of
OpenStack
that
didn't
pass
all
the
tests.
So
the
idea
of
60
was
that
somebody
could
sell
an
openstack
cloud,
get
it
to
pass
all
the
tests
and
then,
with
the
users,
permission
substitute
out
pieces
that
then
didn't
pass
the
tests,
and
so
the
idea
here
is
that
we
want
people
to
be
if
they
buy
something.
A
We
want
them
to
be
able
to
be
OpenStack
compliant,
but
we
recognize
there
might
be
some
cases
where
a
vendor
has
a
component
that
doesn't
pass
all
the
tests
and
they
still
want
to
ship
it.
A
really
good
example
of
that.
To
me
would
be
if
you
had
a
storage
back-end
that
didn't
didn't,
pass
all
the
tests,
but
was
still
adequate
for
for
for
your
needs
or
was
an
experimental
driver,
something
like
that.
It
lets
you
make
alterations,
but
the
users
still
have
the
way
a
way
to
get
all
of
OpenStack
gonna
help
clarify
things.
B
A
I
think
that
it
would
I
think
what
you're
saying
for
a
service
provider
would
be
exactly
right.
If
it
would,
it
would
allow
somebody
say:
I
just
want
OpenStack
core,
then
this
is
the
one
that
I
have
and
if
they
had
enhancements,
they
could
provide
an
alternate
I,
think
you're
right
for
a
service
provider.
You'd
have
to
simultaneously
provide
different,
multiple
implementations,
because
at
that
point,
if
you
didn't
pass
tests,
you
wouldn't
be
core
and
you
couldn't
claim
your
OpenStack
so
somewhere
you're
going
to
have
to
provide
that
okay
now
I.
A
One
of
the
things
I
do
believe
is
that
I
think
core
is
going
to
be
pretty
small
at
the
end
of
the
day.
For
this
in
this
pass
in
that'll
that
the
functionality
that
we,
you
know
that
we're
going
to
have
interesting
arguments
where
people
believe
things
are
absolutely
required.
I
think
the
Venn
diagram
is
going
to
be
a
relatively
small
subset
of
the
total.
A
A
So-
and
this
is
one
of
the
things
that's
important
with
this-
is
that
we
want
to
be
able
to
have
the
community.
Ultimately,
the
market
enforce
some
of
this-
that
one
of
the
things
that
we
would
expect
people
to
do
is
have
published
the
reference
architectures
or
for
OpenStack
to
publish
reference
architectures.
A
She
said
right,
oh
well,
if
you
put
the
symmetrix
on
the
left
side
of
your
room,
that
would
have
passed,
but
you
did
the
right
hand.
Sorry,
we
can't
tell
you
how,
to
the
left
hand,
side
right.
I
think
that
the
market
is
going
to
have
a
lot
of
influence
once
we've
defined
these
patterns
to
sort
of
pressure
people
to
be
in
compliance,
maybe
I'm
naive,
but
it's
only.
C
A
A
really
good
point,
but
one
of
the
things
that
we'd
like
to
do
is
have
people
not
hung
up
on
one
hundred
percent.
Obviously
you
have
to
pass
core,
but
we're
word
over
700
tests
right,
so
it
you
know
there.
I
would
expect
that
one
of
the
things
that
we're
trying
to
do
is
have
people
write
a
lot
more
tests
more
tests.
A
Where
you
have
to
be
able
to
say
you
know,
I
passed
the
tests
for,
and
we
were
talking
about
flavors
at
the
last
summit
for
for
a
flavor.
You
know
that
involves
quantum
networking
in
this
configuration,
but
not
another.
Networking
I
did
quantum.
It's
so
close
to
the
hundred
percent
and
I
blow
it
when
I'm.
At
the
end
of
the
day,.
A
A
A
They
were
allergic
to
the
word.
Plugging
I
can
the
word
so
so
what
happened
is
when
we
originally
came
up
with
this.
The
big
insight
from
spider
from
the
spider
discussions
was
that
plugins
were
necessary.
This
sounds
like
it
sounds
really
silly
at
this
point,
but
what
what
we
realized
was
that
we
had
to
have
an
OpenStack
had
to
have
a
way
to
allow
coach.
D
A
The
issue
with
plugins
were
there
were
a
couple
of
them.
The
first
one
was
not
all
projects
implement
plugins,
and
so
the
tc's
didn't
want
to
be
forced
dictated
that
their
every
project
must
implement
plugins
and
some
projects
like
Oslo,
don't
there's?
No,
it's
just
going
to
be
a
hundred
percent
I,
don't
see
any
way
to
do
plugins
on
it,
so
the
allergic
reaction
was
hey.
Bored
get
out
of
the
technical
pie.
Tell
us
what
you're
trying
to
accomplish
and
we'll
figure
out
the
right
way
to
do
that
right.
Right.
C
A
D
A
C
Not
exactly
how
sure
how
we
say
it,
but
the
one
of
the
the
more
I
talked
to
groups
outside
of
OpenStack
about
open,
sac
and
I
have
to
exploit
it
down
into
really
simple,
straightforward,
but
technobabble
terms
that
the
idea
of
that
OpenStack
is
not
trying
to
set
standards,
but
by
implementation
is
really.
The
implementation
of
OpenStack
is
the
strength
of
open
sac
which
keeps
it
vibrant
in
in
lieu
of
setting
standards
to
try
to
code
against.
C
That
is
something
that,
whatever
we
say,
and
maybe
just
sings
equity
said,
does
that
that
we
need
to
get
across
that?
It's
that
what
we're
trying
to
do
is
ensure
the
stability
and
longevity
of
the
code
base
by
implementation
of
the
code,
since
that
is
how
open
stacked
lives
and
breathes
that
they
say
that
writer
well,.
C
A
A
D
A
D
A
A
A
C
A
B
D
No
just
the
boat,
no,
no
posts,
the
two
different
things
when
you
put
it
in
gear:
oh
you
mean
it
means
you've
signed.
The
CLA
means
it's
under
the
apache
license
and
the
means
that
can
be
used
by
everybody
that
is
very
different
from
other
than
github
and
it's
under
proprietary
license.
Unless
you
show
the
code
but
not
user
right
moment,.
B
D
B
D
A
Well,
open
the
ec2
api's
are
actually
a
really
good
test
point
on
this
I'm
they're,
an
extension
so
they're
not
going
to
be
in
the
required
subset
one
of
the
things
that
I
like
about
this-
that
if
we
get
data
that
the
ec2
api's
are
passing
tests
in
a
considerable
percentage
of
deployments,
then
we'd
have
an
expectation
and
could
be
you
know
they
could
become,
must
pass
tests
and
thereby
become
part
of
OpenStack
or
the.
In
order
to
do
that,
you
would
have
to
write
tests.
A
You
would
have
to
have
those
tests
passing
at
a
substantial
number
of
sites
you
have
to
have.
You
have
to
go
through
a
vetting
process,
and
so
one
of
the
things
they
haven't
talked
about.
Much
is
that
you
know
these.
These
tests
are
not
going
to
just
pop
into
existence
and
then
become
most
past
tests.
D
Its
different
ways
that
make
more
sense
to
me,
which
is
the
side
of
the
pond
two
separate
dimensions
we
hear
about
one,
is,
can
uses
two
pins.
That's
got
the
math
and
will
do
the
job
and
the
tests
define.
The
common
set
of
this
is
what
you
can
expect
out
of
any
openstack
cloud.
The
must
pass
tests
so
in
an
API
replacement.
D
D
The
interesting
thing
about
an
API
rewrite
is
that
what
you're
actually
saying
is
we
want
to
seek
way
upon
to
that,
develop
even
off
to
the
side
for
a
period
of
time
to
build
up
something
too
much
better
and
then
pivot
it
into
place,
which
is
a
TC
operation
where
they
say
we're
going
to
take
that
code
base
and
deprecated,
and
that
code
base
is
going
to
come.
The
new
shape
group
so
I
think
again.
I
would
say
that
the
new
code
base
has
to
be
in
Garrett.
D
That
has
to
be
in
the
OpenStack
project,
modern
step
forwards
for
something
that's
cool
I
mean
it
should
be
self-evident,
and
it's
going
to
need
the
program,
not
the
project
or
program
which
is
aiming
to
do
a
replacement
to
be
collaborating
with
it.
But
I
think
saying
that
has
to
be
designated
upstream
code
is
enough
because
it
up
stiff
notice,
PTI
was
behind
this.
They
will
be
able
to
bless
that
new
code
base
as
soon
as
it
appears
and
say.
A
The
reason
for
that,
having
that
block
is
to
do
it,
is
to
drive
exactly
that
behavior
right.
What
we
want
to
do
is
we
don't
want
people
to
fork.
We
want
these
contributions,
especially
in
the
common
areas
to
be
driven
back
into
the
project
and
an
emergency
project
and
part
of
the
we've
had.
This
is
a
discussion
actually
with
Monty.
A
Is
it
ideally,
somebody
who
needs
a
capability
in
in
the
shared
code
in
that
upstream
code
would
be
incentive
to
push
it
back
in
so,
let's
say
in
the
in
the
sender
plug-in
you,
you
want
to
be
able
to
have
live,
vol
migration
and
in
order
to
have
live,
vol
migration,
you
must
patent.
You
must
expose
additional
API
as
well.
The
person
writing
that
plugin
would
have
to
then
push
that
shared
code.
We'd
have
to
invest
in
helping
make
the
reference
implementation,
support
it
and
then,
ultimately,
that
would
enrich
the
project
as
a
whole.
A
Even
though
it's
you
might
need
a
proprietary
implementation
to
fully
fully
baked
it
in
and
if
yeah,
if
they
wanted
it
to
be
core,
it's
entirely
fair
that
they
might
have
the
capability
and
not
have
it
be
core.
But
then
the
api's
wouldn't
wouldn't
express
it,
and
this
is
what's
really
cool
about
this,
requiring
it
to
be
shared
code.
A
C
D
A
A
No-
and
that's
that's
my
expectation,
this
is
I've,
been
trying
to
capture
these
things,
but
you
know
we're
transitioning
off
to
this
getting
beamed
last
formal
process
written
up
in
all
in
all,
in
all,
it's
glory
and
being
part
of
the
OpenStack
wiki,
the
the
goal
and
actually
we're.
We
should
wrap
up
because
people
people
need
to
go
and
we've
gone
on
or
90
minutes.
A
Where
we
leave,
the
board
actually
needs
to
take
some
motions
and
put
these
things
in
place
and
at
that
point
we're
going
to
have
to
write
these
down
and
create
the
FAQ
the
documentation,
the
wiki.
Obviously
so
that
will
come
I
just
I
didn't
want
people
to
feel
like
we
already
wrote
you
engrave
these
things
in
in
stone
and
couldn't
they
couldn't
object
if
something
seems
wrong.
Just
like
we
change
the
language
today,.
B
A
They
say
that
I
love
it
so
that
the
board
ultimately
is
by
bike
the
according
to
the
bylaws.
The
board
ultimately
has
to
certify
the
tests.
In
some
earlier
discussions,
it
seemed
to
me,
like
the
user
committee,
is
really
because
the
test
represent
use
cases
that
we
see
in
in
production,
that
the
the
user
committee
should
be
responsible
for
nominating
which
tests
or
must
pass
tests
and
helping
organize
that
effort
and
then
on
the
the
TC
is
responsible
for
actually
production
of
the
tests
and
identifying
the
tests
and
enforcing
the
tests
are
created.
A
So
one
of
the
things
I
liked
about
this,
as
we
thought
about
it
and
discussed
it
was
it.
There
was
actually
a
discrete
role
for
every
component.
If
the
community
right
the
tc's,
creating
testuser
committees,
collecting
data
about,
what's
implemented
the
board
for
doing
a
certification
and
being
sort
of
the
last
stop
on
this
process.
A
B
A
Believe
that
this
is
going
to
create
a
lot
of
commercial
interest
in
tests
and
part
of
my
I'm,
a
huge
test
been
one
of
my
goals
with
this
is
that
we
create
a
commercial
reason
for
people
to
be
putting
engineers
in
to
test
and
writing
tests,
and
so
an
example
would
be
if
I
was
in
the
ecosystem
and
I
have
written.
You
know
product
that
required
OpenStack
to
work
in
a
certain
way
and
there's
a
lot
of
them.
A
A
D
You
were
an
operator
and
you
think
that
having
shall
we
say
a
particular
responsiveness
from
your
API
is
important
thing
and
you
want
that
to
be
something
everyone
should
have
so
that
people
do
is
your
cloud?
Don't
state
I
can't
depend
on
that,
because
I
fight
the
Penal
that
I
lose
most
by
then
the
portability
are,
you
can
say,
hey
look.
We
want
to
enable
this
passive
users
to
really
get
out
there
news
our
stuff.
D
We
need
to
help
that
become
part
of
the
mark,
which
means
we
need
to
give
tests
there
and
we
need
to
help
the
reference
implementation
passive
always
and
we
need
to
get
enough
users
enough,
deployers,
deploying
it
with
us,
then
working
that
the
the
user
growth
will
certify.
This
is
a
reasonable
thing
to
require
all
locals
their
clouds,
to
afford
and
board
to
sign
off
on
troop
and
there's
a
clear
path
thing
to
say.
If
you
want
to
guarantee
this
to
all
your
potential
users,
this
is
how
you
do
it.
Yes,.
D
A
That
that
strikes
me
is
a
very
positive
cycle.
Right
I
think
there
are
ways
that
you
could
potentially
have
a
game,
but
by
using
actual
test
passing
in
the
field,
rather
than
people
arguing
in
a
boardroom
whether
or
not
this
is
a
test
or
not.
I
think
that
the
implementation
based
results,
our
mud,
you
know,
help
prevent
the
gamification
of
it.
Otherwise
you
know
you
also.
A
C
A
A
C
A
It's
an
idea
that
we've
had
in
some
discussions.
I
don't
think
it's
finalized.
Yet
we
need
to
figure
that
out
and
I'm
the
overload
of
the
user
committees
of
concern
for
this,
and
so
we
need
to
figure
out.
If
we're
going
to
do
that
and
then
the
foundation
has
to
decide
to
fund
it,
and
you
know
the
whole
thing.
The
same
thing
is
true:
with
using
ref
stack
or
not
a
lot
of
these
implementation.
A
C
A
C
Thinking
is
that
we
would
create
a
committee
that
would
not
we
need
another
committee,
but
one
that
has
specific
focus
of
implementing
some
something
like
Rev
stack
and
the
other
half
of
the
responsibility
would
be
working
with
the
TC
to
define
what
are
the
core
tests.
I
would
think
that
would
be
a
different
makeup
than
the
current
people
that
are
involved
with
the
user
committee,
but.
C
A
Totally
agree-
and
I
know
I
think
I
think
this
is
a
discussion
for
the
board
as
what
the
next
phase
is
right.
We
are
going
to
need
a
committee
we're
going
to
have
to
figure
out
how
to
implement
it,
we're
going
to
have
to
figure
out
how
to
pick
the
tests.
We
you
know
in
the
in
the
process
we
haven't
even
said
they
were
using
the
tempest
tests
right.
It
could
be
that
it's
tempest
plus
others.
It
could
be.
You
know
we,
those
are,
those
are
still
implementation.
A
A
B
A
I'm
happy
to
have
the
conversation
with
you
guess
and
then
I'll
be
in
your
time
zone
in
a
couple
of
weeks.
So
if
something
else
occurs
to
you,
yeah
actually
I
like
to
always
close
on.
On
the
same
note,
you
know
everybody
can
as
much
as
we're
trying
to
be
accessible.
Not
everybody
in
the
community
participates,
and
it's
really
important
for
people
to
understand
that
this
you
know
what
we're
talking
about
is
being
vetted
and
being
discussed
and
were
accessible
to
the
to
the
conversation
and
ideas
about
it.
So
please
help
us
represent.
A
You
know,
what's
going
on
and
and
the
process
and
that
you
need
to
listen
to
it,
you,
your
opinions
have
been
heard
and
that
if
it
makes
sense
great,
if
it
doesn't
make
sense,
keep
bringing
it
up.
We
want
to
keep
talking
about
it,
but
you
know
that
is.
This
is
part
of
a
process
and
thank
you
for
participating.