►
From YouTube: OpenStack DefCore Test Criteria Selection Meeting #1
Description
OpenStack DefCore Subcommittee meeting about Test Selection Criteria
https://etherpad.openstack.org/p/DefCoreTestCriteria
A
That
was
one
of
the
ones
I
had
said.
No,
do
you
see
that
is
being
related
to
the
same
thing?
The
stability
argument,
I
know
I
well,
I
see
there's
two
things.
One
is
we
want
to
make
sure
the
tests
are,
are
reliable
in
multiple,
multiple
environments,
but
no
I
actually
think
it's
a
question
of
the
code
underneath
the
test.
Also,
so
it's
that
that's
where
I
was
going
with
that
with
one
of
my
with
one
of
my
comment,
I
think
it's
the
same
you're.
A
What
you're
looking
for
is
we
trespassed
test
you're
more
likely
to
have
a
must-pass
test
if
you're
talking
about
test
code,
that's
been
stable
for
releases
right
right,
the
NDP
eyes
that
have
been
stable
for
multiple
release
right,
so
I!
Guess
as
the
open
discussion
point,
does
anyone
see
this
as
being
not
a
valid
criteria
or,
conversely,
not
broad
enough.
B
A
I'm,
sorry,
you
missed
the
the
previous
def
core
kickoff,
but
the
the
goal
is
definitely
to
have
a
set
of
tests
that
are
declared,
as
must
have
for
each
release
cycle.
What
we're
trying
to
do
right
now
is
get
a
set
of
tests
that
apply
to
havana
by
aight
house,
so
will
be
a
full
release
behind
and
then
to
catch
up
by
the
j
release.
I
believe
so
that
we're
actually
announcing
test
concurrent
with
that
release.
A
C
A
A
C
A
Believe
so,
but
I
think
we've
explicitly
punted
for
this
cycle,
how
a
must-have
test
would
be
removed
from
criteria
and
I
think
that's,
probably
appropriate
I
think
we
should
be
especially
cautious
about
churning
core
once
we
shouldn't
really
be
saying.
Well,
we
changed
our
line.
That's
not
far
anymore.
C
C
A
A
A
Yeah
hold
on
that's
a
criteria,
question
to
me
right,
there's,
there's
actually
one
of
the
criteria.
I
added
was
that
there's
a
community
aspect
of
data
coming
in
right
and
I
think
it's,
I
think
it's
reasonable
to
add
a
criteria
that
says
that
the
test
has
been
endorsed
by
the
project
as
a
mouse
past
has
its
perfect.
That's
a
recent,
very
reasonable
criteria
to
include
subtleness.
A
A
A
You
pass
these
tests
because
someone
may
never
move
off
of
Essex
and
they
still
want
to
maintain
yeah.
Very
very
true
I
mean
the
proposal
is
that
the
certifications
were
provided
over
as
per
a
particular
version,
as
per
a
particular
named
release
on
right,
I
think
we
measured
God,
we're
all
up
I'm,
sorry
to
interrupt
you,
but
if
you're
not
talking,
please
mute
we're
getting
a
lot
of
chalk.
A
A
If
the
tests
themselves
are
deprecated
by
the
project
or
the
TC,
then
the
scope
of
this
effort
is
specifically
that
we
can
only
choose
from
check
that
has
been
provided
by
the
technical
community
so
that
that
that
wouldn't
really
say
deprecation
is
back
in
the
hands
of
the
technical
project.
Leaders.
E
So
as
long
as
we
have
a
mechanism
that
still
preserves
that
capability
and
doesn't
sort
of
hold
some
old
feature
hostage
that
may
be
a
project
doesn't
want
to
maintain
I
think
the
idea
of
it
starts
small
and
it
essentially
only
grows
there's
a
certain
degree
of
backward
compatibility
or
backward
functionality.
I
think,
is
exactly
where
we
want
to
start
from,
but
first
a.
A
E
E
E
B
Are
adding
we
are
adding
new
versions
that
are
kind
of
parallel
versions,
so
I
think
that
the
criteria
here
is
about
you
know
before
the
test
that
locks
into
a
specific
version.
We're
saying
you
know
we're
going
to
be
committed
to
this,
for
is
maintaining
this
version
for
I,
don't
know
a
year
or
two
years,
something
like
that,
and
you
know
if
the
TC
are
going
to
kind
of
sign
off
as
this
being
some
thing,
that
is
valid
to
say
it
going
to
be
around
for
a
year
two
years.
B
C
A
A
A
A
A
A
A
E
A
A
A
D
D
D
I
well,
I
didn't
I
love
for
all.
My
secrets
is
always
so
much
fun.
I
would
say
that
that
one
would
be
I'd
agree
that
shouldn't
be
legal
encumbered
and
that
then
the
argument
there
would
be-
and
then
we
have
to
have
been
lawyers
have
to
argue
whether
or
not
they
in
a
hour.
We
would
have
to
have
a
legal
opinion
as
to
whether
AWS
is
encumbered,
which
I
believe
there's
different
difference
of
opinion.
D
I
mean
I
am
fine
with
us
having
a
thing
that
gets
us
with,
had
no
AWS
ask
or
I'm
perfectly
okay,
with
that,
I
I
just
I
think
that
we
get
into
the
weird
place
where
and
for
that
example,
we
had
there's
folks
who
think
it
is
and
folks
who
concurred
it,
isn't
and
yeah.
It's
so
I
love
the
legal
stuff.
That's.
D
A
B
B
A
A
Out
it's
going
to
be
a
whole
rat's
nest
of
things
that
we
would
have
to
commemorate.
Okay,
so
I
think
in
a
in
a
way
one
of
the
ways
to
handle
this
is
that
what
we're
saying
is
there
is
no
none
of
the
sub
communities
in
openstack
objects
to
this
testing
included.
Is
it
I'm
a
little
bit
concerned
about
the
double
negative,
but
what
we're
saying
is:
there's
no
legal.
All
concern,
there's
a
technical
concern.
There's
no
users
right
I
mean
there's
effectively.
A
C
A
A
Would
be,
is
there
any
community
inside
OpenStack
that
has
veto?
In
other
words,
does
the
TC
does
the
user
committee?
Does
the
Legal
Affairs
Committee?
Does
the
the
foundation
staff
for
any
particular
reason
the
docs
community,
if
they
feel
like
it,
is
impossible
to
document
appropriately
etc?
I
mean
I
would
say
no
I
would
say
the
point
of
making
this
a
committee
process
is
that
there
hasn't
been
an
easy
and
emerging
consensus
on
the
details
and
I
think
the
likelihood
is
we
will
have
somebody
who
objects
to
every
test.
A
A
E
Demonstrated
accessibility
is
this:
where
we're
talking
about
what
we
started
off
with
the
idea
of
a
plug-in
architecture
or
something.
That's
all
you,
because
that's
not
really
a
test
criteria,
issues
as
it
is
I
functionality
or
it's
something
behind
the
test,
and
so
I
was
just
trying
to
figure
out
if
you're
saying
the
test
need
to
be
extensible
or
if
the
thing
that's
being
tested.
These
some.
A
Think
the
Philippine
shelf
needs
to
be
demonstrated
is
extensible
in.
In
other
words,
if
there
is
a
create
volume
nominees,
great
volume
is
an
easy
example.
There's
create
volume
as
a
test
in
Tempest.
It
would
be
a
good
criteria
for
us
to
say.
If
we're
going
to
say,
create
volume
is
a
must-have.
Are
there
multiple
back-end
drivers
that
demonstrate
pre
volume.
E
A
B
B
A
B
B
B
A
A
Talk
through
the
rationale
for
this
right,
so
the
rationale
would
be
that
somebody
promotes
a
test,
is
must
past
it,
it
locks
and
implementation
in
that
that
we
actually
want
to
encourage
plug
ability,
and
so
yes,
the
purposes
criteria
is
to
say,
hey
guys.
Look.
We
really
can't
pass
this
test,
because
the
way
you're
storing
objects
should
be
pluggable
and
youth.
It's
not,
and
so
we're
gonna
pass
the
test
at
this
point.
So.
B
A
No,
that's
why
pluggable
is.
It
is
a
technical
community
decision,
but
let's
take
a
soon
as
an
example,
there
was
a
decision
to
say
keystone,
trinette,
foldable
backends
season,
but
the
reality
is,
there
isn't
feature
parity
in
keystone
across
the
back
ends
for
some
capabilities.
So
we
really
couldn't
say
these
capabilities
should
be
must
have
because
they
only
work
on
certain
backends.
In
case
where
we've
explicitly
said,
multiple
back-end
should
be
supported.
Okay,.
D
D
A
B
E
E
A
So
I've
just
restated
that,
as
where
the
code
has
an
extension
framework,
there
should
be
parity
in
capability
across
backends.
Is
that
for
like
extensions
instead
of
backends,
but
is
that
close
to
overall
trying
to
say
yes,
I
I
would
like
to
bring
out
sorry
I'll
bring
in
my
my
my
language
about
not
being
configuration
specific
as
a
yes?
C
A
A
D
B
E
I
feel
like
we're,
mixing
up
two
different
ideas,
which
is
what
is
yeah
there's
this
idea
of
what
code
or
what
what
implementation
or
projects
should
be.
You
know
considered
for
core
and
then
there's
the
test
that
actually
you
know
what
the
must-pass
tests
are
and
I
I'm,
not
sure
I
understand
how
plug
ability
impacts,
the
selection
of
the
test
and
functionality
other
than
you
obviously
want
them
to
behave.
The
same
way,
I,
usually.
A
E
A
E
E
A
Cultural
and
objective
component,
but
that's
not
the
objective-
is
in
our
objectives.
We
want
to
achieve
and
maintain
the
project
and
I
think
that
we
should
be
willing
to
talk
about
those
these
criteria.
So
it
could
be
that
what
I
said
was
very
contentious
and
you're
like
no
way
I.
Don't
want
that
as
a
criteria.
There's
another
part
which
says:
hey,
wait
a
second.
It
is
useful
for
us
to
encourage
plug
ability
in
the
projects
and
our
criteria
can
reflect
that
yeah.
C
A
D
D
I
think
I
agree
with
what
Tori
was
saying,
which
is
that
I
agree.
I
think
that
is
a
thing
that
we
as
a
community
want
to
want
to
encourage
and
that
we
that
we
want,
but
I
think
that
in
this
particular
case,
it's
not
it
just
like
it's
a
goal
for
a
project.
It's
not
really,
I'm
not
really
sure
that
I
could
looking
at
a
test.
I
could
I
could
tell
whether
that
test
meets
that
criteria,
because
a
implementation
would
fail
that
test.
It
could,
if
it
behave
differently.
D
A
C
A
Because
I
don't
think
that
a
plug-in
model
is
always
an
unmitigated
good,
I
think
they're.
There
are
projects
and
portions
of
projects
that
would
be
best
served
by
having
a
single
monolithic
implementation
that
works
with
it.
Well,
yeah
I
mean
I
religion,
novanet
I,
would
love
to
say:
novanet
should
be
core
because
it
works,
and
it's
filled
in
seventy
percent
of
OpenStack
deployments.
Neutrons
demonstrably
does
not.
Work
does
not
have
feature
parity
and
nobody
uses
it.
A
I
mean
just
to
be,
as
a
particularly
pointed
example
I
yeah,
but
that's
the
same.
That
same
example
creates
problems
because
making
it
a
core
test.
When
it's
been
deprecated
potentially
creates
problems
right.
We
actually
definitely
doesn't
pass
one
of
our
requirements,
which
is
that
it's
not
expected
to
be
stable
because
I.
A
Well,
I
think
it'll
tighten
decorative
part
of
its
part
of
what
we're
doing
with
this
is
steering
we're
where
we
expect
things
to
go
and
I
think
that
the
fact
that
nobody
know
the
network
is
a
poor
example,
because
we
actually
have
issues
with
the
fact
that
it's
not
pluggable
and
extensible
fact
that
it
works.
It
is
not
a
factor
of
the
of
its
monolithic
pneus.
It's
a
factor.
B
I'd
saying
in
terms
I
still
in
terms
of
Syria,
where
we
want
things
to
go,
it's
in
the
realm
of
interoperability,
not
in
the
realm
of
project.
Behavior
are
encouraging
projects.
You
know
to
take
certain
technical
decisions.
We
want
to
encourage
and
drop
losing
the
marketplace
here,
and
so
that's
I
don't
see
how
demamp
talk
ability
pack
stuff
all
right
relevant.
We
also.
A
D
A
D
I
mean
I
don't
I
don't
and
I'm
not
certain
that
that
is
absolutely
the
case,
although
I
think
you're
probably
right,
but
I
think
in
terms
of
the
testing
in
terms
of
defining
the
testing
for
interoperability.
I
think
that
the
criteria
that
the
Joshua
was
expressing
earlier
is
is
right
on,
and
this
is
the
criteria
that
I
think
is
important
here,
which
is
that
if
there
are
multiple
backends
for
for
a
capability,
we
expect
them
to
work
the
same
right.
That's
that's!
D
The
interoperability
thing
that
we're
trying
to
drive
home
here
I
think
that
the
discussion
about
whether
whether
or
not
we
want
to
encourage
plug
ability
or
I
think
is
a
broader
discussion
than
then
this
thing
that
we're
doing
here
today
and
I
think
it's
a
worthwhile
discussion
to
have,
but
I
think
it
said.
If
it's
a
much
scarier
cancer,
much
broader
can
of
worms.
You.
A
D
A
D
I'd
say
that
if
anything
we
have,
we
have
erred
on
the
side
of
more
plug
ability
than
we
should
have
if
we
have
erred
if,
if
this
has
gone
in
the
wrong
direction,
I
believe
it's
gone
wrong
in
direction
of
making
all
of
the
things
huggable
to
the
extension
of
sanity
and
and
so
I
think
that
we
probably
don't
have
to
spend
a
lot
of
time
in
encouraging
making
sure
the
things
are
are
pluggable.
That
seems
to
be
working
pretty
well.
Can.
D
A
Culture
on
this
and
say
that
we
believe
that
whole
projects
should
probably
be
extensible
or
in
other
words
the
way
Robbie
afraid
of
the
frame.
This
most
recently
chest
will
not
be
considered
for
projects
without
an
extension
framework,
but
I,
don't
think
that
every
capability
necessarily
needs
to
be
extensible,
and
that
was
like
right.
Don't.
A
Agree
with
it
right
guys,
but
we're
not
trying
to
dictate
technical
terms.
I'll
tell
you
from
the
spa
later
analysis
we
did
plug
ability,
isn't
important
for
the
ecosystem
success
and
for
adoption.
That
was
one
of
the
overwhelming
things
that
we
saw.
The
correct
area
is
a
place
where
the
board
directs
and
I
think
it's
entirely
appropriate
for
us
to
make
sure
that
the
criteria
reflect
the
direction
we
want
the
project
to
go.
Yeah.
D
C
D
List
and
and
the
reason
it's
contingent,
because
people
people
want
people
want
a
swift
self
combination
or
something
like
that,
and
this
were
actually
that
is
actually
in
work,
is
I.
Think
that
that
gets
there
that
will
this
will
cease
to
be
anything
that
people
even
bring
out,
because
it's
basically
when
they
say
things
in
general
should
be
pluggable.
What
they're,
trying
to
say
is
I
think
Swift
should
have
plugins.
Nobody
should
force
them
to
do
it.
You
know
so
they're,
just
a
clarified.
E
F
E
That
was
my
concern
is
that
we
were
doing
at
the
test
level.
I
do
think
in
a
different
alternative.
I
thought
was
we
used
in
some
cases
that
a
higher
waiting
or
higher
value
would
be
placed
on
tests
to
be
certain
criteria
and
I.
Guess
in
this
case,
I
could
see
that
things
that
do
run
across
multiple
back
into
insistently
might
have
a
higher
weight,
but
I
just
don't
know
that
we
want
to
go
to
the
point
of
saying:
well,
we'd
never
have
a
test
or
we'd.
Never
have
a
project
didn't
have
plugins
in
court.
A
That's
that
one
of
the
things
I
actually
like
is
we
there?
Is
it
there's
a
question
of?
Should
we
be
considering
a
waiting,
yeah
and
I
think
we
should
in
fact,
I
think
if
we
just
think
it's
a
criteria
as
being
should
or
improves
the
likelihood,
as
opposed
to
every
test
must
display
these
characteristics.
A
A
D
B
D
Now
I
fencing
I
think
it
actually
that's
the
same
as
I
think
that,
right
now,
it's
written
sort
of
sounds
like
it's
project.
Little
thing
I
think
this
actually
does
describe
something
that
is
is
talking
about
capabilities
and
without
saying
a
paragraph
of
text
that
doesn't
come
across,
and
so
that's
the
note
that
the
josh
sceptile
I
will
work
on
fixing
that
work
there,
fixing
that
wording
or
something
like
that-
yeah,
because
if
that.
D
Again,
it's
very
very
elemental:
a
service
have
different
have
different
if
there
are
different
things
that
you
can
do
that.
That
needs
to
be
discoverable
automatically
from
the
person
so
basically
like
you
shouldn't
have
to
as
a
user
to
go
all
the
way
back
out
to
the
user
thing
you
shouldn't
have
to
have
special
knowledge
about
the
open,
sat
college,
you're
running
against,
to
be
able
to
use
capabilities
that
may
or
may
not
be
there,
depending
on
the
deployers
choices.
D
That
should
be
something
that
should
be
discoverable
for
things
that
we
do
think
that
are
sort
of
validated,
possibly
be
or
possibly
not
be
there
that
you
should
be
able
to
programmatically
discover
that
from
your
initial
endpoint
to
the
capability
in
question,
or
else
if
that
is
not
the
case,
and
that
is
not
a
good
candidate
for
for
being
something.
We
consider
to
be
a
thing
as.
A
It
explicit
misspoke,
you
need
to
be
able
to
say,
hey,
you
I
know
if
floating
eye,
peas,
work
or
not
without
simply
trying
to
buy
the
floating
at
PE
or
alligator
floating
90,
and
have
it
fail
right?
That's
right,
I
understand
the
concept.
The
thing
that
I
find
a
little
bit
circular
is
that
the
definition
of
these
tests
are
ones
that
you
would
be
able
to
X
by
definition
expect
to
be
there.
So
the
fact
that
they're
discoverable
I'm,
not
sure,
is
really
a
requirement
for
them.
A
A
D
A
D
D
C
A
We're
not
arguing
it:
okay,
a
good
capability.
It's
definitely
good
capability
that
the
question
Alex
going
to
do
some
work
for
the
the
upcoming
problems
of
OpenStack
compatible
and
the
sort
of
nearly
core.
So
I
can
imagine
up
loud
since
that's
the
deployed
without
any
s3
or
Swift
support,
and
I
can
imagine
a
mark
that
allows
that,
but
that
required
that
it
was
easy
to
discover
from
the
Service
Catalog.
That's
with
wasn't
present.
A
A
Of
expressing
argument,
can
you
capture
that,
as
at
some
point
I?
That's
really
interesting
I,
and
this
is
one
of
those
behavioral
ones
where
I
do
think
that
we're
extending
behavior
for
four
people,
I'm,
just
I'm
worried
that
there's
going
to
be
some
base
pet
thing
that
we
want
to
make
sure
is
tested
that
isn't
discoverable
and
I
mean
no.
The
network
is
I.
Guess
one
of
those
classics
is
that
tell
you
to
prevail.
John
is
not
a
player.
A
A
A
A
Well,
if
we
are
soft
with
applying
this
criteria
and
we
only
apply
it
at
the
project
level
instead
of
at
a
lower
level,
around
introspection,
I
think
we're
fine.
In
other
words,
I'm
pretty
sure
all
of
the
services
endpoints
we
run
today
are
exposed
and
keystone
in
the
service
catalog
with
a
version
yeah
you
know,
and
then
we
can
be
more
harsh
with
applying
it
at
a
capability
level
later
on
yeah.
E
I
think
that's
the
way
you
have
to
think
about
it,
because
you
can.
You
can
certainly
tell
you
know
that
nova
is
there,
but
you
don't
necessarily
know
whether
the
floating
IP
extension
is
there,
but
right
doesn't
necessarily
mean
you
would
exclude
that
lower
level
feature
just
because
you
can't
introspect
a
particular
function.
Call
versus.
D
A
service
or
or
two
to
put
it
to
put
a
really
fine
point
on
it:
the
the
API
key
extension
that
the
Rackspace
and
HP
both
run
own.
You
have
to
know
about
it
before
talking
to
Keystone
in
the
first
place
before
you
know,
to
use
it
because
I
you
can't,
you
can't
ask
an
unauthenticated
Keystone,
whether
or
not
it
has
that
extension
and
therefore
you
would
like
to
use
an
API
key
rather
than
a
password.
A
F
A
And
a
good
discussion
about
it.
Okay,
now,
these
two
I
think
will
be
easy,
but
I
think
the
new
ones
will
be
hard
works
on
multiple
public
cloud
services
and
works
on
multiple
private
cloud
products,
the
notion
being.
If
people
are
using
it,
it
is
probably
a
good
argument
that
it
could
be
part
of
Corps
hi.
D
I
think
that
one's
tricky
so
I,
I
wrote
a
road,
an
argument
about
this.
One
down
I
think
it
might
be
in
Rob's
Rob
things.
He
said
something
very
similar
and
I.
Think
I
tried
the
yeah,
the,
but
I
consumers
are
really
quickly.
Might
I
agree
with
the
sentiment
here.
I
think
that
my
my
concern
is
that
we've
seen
this
actually
a
couple
of
times
now
designate
is
actually,
I
think
the
the
biggest
example
of
this.
Where
we
have.
D
A
A
D
A
A
toast,
so
what
is
ballin
timing
is
a
reasonable
roll
out,
but
they
have
a
couple
I
at
least
get
into
that
kind
of
complaint.
But
I
read
it.
If
we
put
the
criteria
in
and
say
we
are
certainly
favoring
things
that
are
proven
to
be
used,
but
the
committee
can
obviously
apply
expert
judgment
to
say
you
know:
users
have
been
clamoring
for
this
and
there
is
pressure
from
the
user
community
to
support
it,
even
though
it
is
right,
people
is
yet
Yahoo.
D
A
You
know
it's
possible
that
one
of
the
things
that
we
should
do
in
our
next
meeting
is
actually
look
and
see
if
there's
a
reasonable
system
of
weights,
because
at
the
end
of
the
day,
if
we,
if
we
can
say
okay,
something
that's
in
multiple
public
clouds
and
multiple
private
clouds
gets
a
weight
of
10.
Whatever
10
ranks
out
to
with
everything
else,
we're
going
to
end
up
with
a
force
rank
of
all
these
tests,
and
there,
hopefully,
will
be
an
obvious
cliff
between
the
must-pass
and
the
common
can
the
common
edge.
E
But
I
think
it
makes
sense,
we're
almost
implying
that
and
the
language
that
we're
using
there
already
I,
don't
know
when
we
can
get
to
something
that
specific,
but
I
think
it
also
begin
to
introduce
how
you
can
factor
in
things
like
if
we
had
community
voting.
If
we
have
pc
input,
like
all
those
things
become,
you
know
some
some
weighted
factor
and
then
then
you
score
the
test
in
the
ones
at
the
top
of
the
next.
Have
it
because
what
you're
saying
yeah.
A
And
I
what
I'm?
What
I'm
thinking
is
that
we
can
actually
do
it
based
on
data?
If
we
say
all
right
look,
we
actually
want
to
have
weights
these
fans,
then,
once
we
actually
have
the
items,
we
just
leave
the
weight
sort
of
open.
Knowing
that
when
we
started
actually
like
scoring
things,
then
we're
going
to
end
up
being
able
to
turn
the
knobs
a
little
bit
I.
C
Would
be
a
bit
more
a
bit
more
firm
than
this
by
saying,
okay,
we
are
going
to
define
a
set
of
criteria
that
are
going
to
be
applicable
in
six
months
or
in
a
year,
but
and
if
you
made
a
choice
not
to
follow
these
criterias
within
that
time
frame,
then
you
lose
the
right
to
use
the
name,
because
if
we
say
oh,
we
all
have
to
wait
until
everybody
implements
everything
before
we
can
test
it,
then
nobody
will
ever
implement
anything.
That's.
A
B
A
D
A
A
D
A
A
google
doc-
and
I
will
see
if
I
can
find
it.
Thank
you
in
the
previous
two
deathcore
meetings.
I
think
the
general
consensus
was
to
not
adopt
the
bulk
of
Shuttleworth's
proposal,
because
it's
a
little
over
reaching
for
what
we're
trying
to
do
right
now,
but
there
was
one
particular
criteria
that
were
interesting.
That
came
up
in
discussion
that
I
started
calling
the
shuttleworth
text
and
the
the
logic.
To
summarize.
I
will
give
you
this
this
link,
although
I'm
not
sure
if
I
can
actually
share
the
dark
with
you.
D
A
D
D
There
is
a
good
test
in
in
here
right
and
that
things
that
are
things
that
are
more
advantageous
or
that
make
more
sense
for
the
operator
to
run
then
for
the
user
to
run
because
actually
there's
a
large
portion
of
things
inside
of
I
mean
the
only
thing
the
operator
really
has
to
like
actually
has
to
run
is
like
Keystone
and
the
hypervisor
things.
A
lot
of
the
other
stuff
can
actually
run
in
VMs
themselves
well,
and
that
gets
a
magnet
to
store
micro
cloud
and
so
I
think
none
of
us
are
suggesting
that.
A
D
Definition
of
OpenStack,
no,
no
I'm
saying
right
here.
What
you're
saying
gets
us
to
a
place?
You
can
run
glance
in
the
cloud
you
can
run.
You
can
run
the
Nova
API
servers
in
the
cloud
weirdly
like
there's
you
can
you
can
you
can
go
nuts
on
this
right,
but
I
know
I,
know
what
you're
saying
in
general.
Other
thing
of
cannot
gets
us
potentially
to
a
direct,
a
weird
place:
yeah
all.
A
A
C
A
A
A
And
and
right
now,
no,
no!
No!
Look
at
the
logic
here,
if
I'm
using
a
cloud
that
has
gender
support
and
I'm
using
it
to
attach
block
devices
and
in
fact,
I
have
I'm
using
a
half
a
dozen
library
to
consume
block
devices
using
the
cinder
api.
So
I'm
using
foundry
or
open
shift
or
service
measure
a
bunch
of
it
and
I've
moved
to
another
cloud
that
does
not
have
similar
supports.
All
of
my
applications
are
broken
because
I
cannot
add
cinder
myself.
C
A
A
I
find
why
I've
been
writing
the
test
6
below
this
during
this
discussion.
Yes,
which
is
what
was
what
you're
describing
so
I
I,
think
these
are
actually
end
up
coupled
and
I
think
these
are.
This
is
actually
coupled
to
the
other
other
things,
but
this
is
what
I
was
saying
in
here.
Is
that
hey,
if
you
have
a
test,
that's
required
as
a
must
pass
by
other,
must
pass
tests
or
is
dependent
on
by
a
whole
bunch
of
other
capabilities.
Then
it's
it's
a
it's
probably
a
must-pass.
He
has
good,
don't.
A
D
I,
don't
think
the
thing
that
said
the
thing
is
I
just.
I
think
I
think
that
this
is.
This
is
likely
to
remain
contentious,
because
I
think
that
we're
likely
to
were
likely
to
remain
in
camps
of
people
who
favored
the
small
cloud
and
people
who
favored
the
large
cloud,
and
I
imagine
that
we're
not
going
to
achieve
consensus
enough
on
that
to
agree
that
this
is
a
good
or
bad
capability
in
terms
of
putting
it
into
into
it.
D
B
Are
more
likely
to
reach
consensus
here
if
we
keep
repeating
the
point
that
we're
talking
about
requirements
for
the
first
iteration
of
core?
So
if
we
start
with
a
core,
that's
a
small
cloud:
that's
not
ruling
at
the
future
in
future,
adding
things
like
he's,
but
I'm
perfectly
happy
talking
about
the
first
iteration
of
this
being
a
small
cloud.
B
B
D
I,
don't
I
think
that's
I,
don't
I,
don't
I,
don't
think
it
does.
I
think
there's
an
outstanding
thing
in
the
room
and
I
think
that
we're
all
ready
to
the
point
because
of
how
late
we
are
in
in
the
project
life
cycle,
where
we
already
have
a
technical
community
to
find
large
cloud
like
that
already
ago.
That's
that
monk.
That
elephant
is
in
the
room
right
so
to
save
it
on
a
first
iteration
we're
only
going
to
don
the
treat
with
things
that
were
maybe
in
folsom.
D
No
I'm
not
I'm,
not
arguing
that
I'm,
not
arguing
that
we
have
to
you
in
this
except
eat.
What
I'm
saying
is
that
the
technical
community
has
accepted
some
projects.
That
would
fail
this
out
of
hand,
and
we
know
that
some
people
aren't
really
crazy
about
that's
what
I'm
saying
that,
putting
in
a
criteria
that
say
that
we
strongly
wait
things
that
that
would
fail
things
that
we
already
know
our
are
in
the
integrated
release.
D
A
This
this
this
process
is
very
specifically
when
we
created
the
term
integrated
release.
The
vote
as
before
reema
between
the
board
and
the
TC
was
that
the
TC
was
welcome
to
consider
whatever
pieces
of
code
they
would
like,
but
that
any
endorsement
of
that
is
being
part
of
OpenStack
was
deferred
for
this
process
and.
D
That
OpenStack
has
already
been
defined
as
being
a
large
Wow.
No
sorry,
no,
I
know
I'm
not
I'm
sorry,
I'm
not
trying
to
say
that.
I'm
not
saying
that
OpenStack
is
already
defined
as
a
large
cloud
I'm
just
saying
that
we
we
have
things
in
that
are
that
are
there
being
developed
like
not
just
like
on
the
periphery
but
like
in
the
as
they've
gotten
as
far
as
individuals,
we
know
we're
going
to
have
to
discuss
them
right.
D
We
know
that
we
have
to
discuss
them
and,
and-
and
we
know
that
we
disagree
on
them,
so
I
think
that
I
think
that
putting
in
a
a
criteria
that
is
weighted
towards
one
side
of
that
agreement
into
the
criteria
that
we're
going
to
use
to
discuss
those,
I
think,
is
I-
think
that's
tricky
right.
I
want
to
discuss
those
I
think
it's
very
important
that
we
discussed
those,
but
I
think
that
I
think
that
waiting
in
which
direction
we're
going
to
fall
on
those
discussions.
A
D
D
Shouting
at
her
through
it
I'm
on
the
fence
and
I,
think
you
think
it
almost
describes
something
that
I
completely
agree
with
so
I
think
we're
actually
close
to
even
an
area
where
you
and
I
disagree
on
what
want
the
outcome
to
be
a
description
of
a
thing
where
I
think
we'd
like
its
work,
like
we're
close
on
this
like
there's
there
something
there.
You.
D
Do
think
I
do
think
somewhere
in
here
the
the
description
of
of
the
of
the
things
that
a
cloud
provider
a
cloud
of
ID
running
as
opposed
to
things
you
run
in
cloud
instances
as
an
end
user
I.
Don't
think
this
captures
it
fully,
but
I
think
that
I
think
that
there
is
a
useful
distinction
there
in
terms
of
because
the
thing
that
goes
obviously
in
my
brain,
obviously
too
far
to
the
side
that
most
of
us
can
agree
on.
D
This
is
definitely
far
as
like
the
the
WordPress
as
a
service
right
like
that's,
that's
clearly
something
of
content
that
runs
a
vm.
You
know-
and
I
think
that
you
know
nova
hypervisors
are
clearly
in
the
other
camp
and
somewhere
in
here,
there's
a
description
of
a
thing
which
is
a
general
general
description,
and
I
think
this
is
getting
closer
to
it.
I,
don't
yeah
I'm,
still
not
on
board
with
it.
I
think
this
is
getting
closer
to
it.
I
think.
A
Monty
and
I
at
some
point
are
going
to
agree
that
there
is
a
para
cloud
capability.
I
gave
a
talk
about
that
two
summits
ago,
maybe
three
summers
ago,
saying
that
I
think
there
is
some
general
orchestration
and
awareness
of
infrastructure
capability.
That
looks
a
bit
like
parts
of
heat.
I
just
think
heat
goes
too
far.
A
There
are
a
number
of
these
projects
that
are
that
are
beyond
infrastructure
capabilities
and
that
become
tricky
in
the
sense
of
this
multi-vendor
ecosystem
that
we're
trying
to
foster
right
when
I,
when
I
look
at
when
I
look
at
this
and
sort
of
along
those
lines,
I
think
a
lot
of
projects
have
a
path
into
OpenStack.
That
starts
as
being
run
on
OpenStack
Savannah
I.
Think
it's
as
it
is
an
example
that
you
don't
have
to
run,
but
that's
that's
sort
of
how
it
goes,
and
so
those
those
to
me
are
what
this
is
about.
A
Do
we
Savannah
going
to
be
core?
You
know
if
you
can
deploy
it
inside
of
OpenStack,
it
might
not
have
to
be,
and
we
therefore
we
shouldn't
shouldn't.
Wait
as
highly
heat
could
be
another
example,
and
but
there's
a
benefit
to
having
those
in
here.
It
actually
speeds
adoption
of
new
projects
and
the
capabilities,
which
is
what
we
want.
We
want
Kate
lube
and
then
maybe
this
maybe
is
good
or
bad
I,
don't
know,
but
we
want.
We
want
capabilities
to
come
in
using.
A
B
A
Is
a
bad
test:
it's
just
I
will
refine
it
over
time.
Do
you
want
to
move
it
into
the
proposed
discussion,
not
the
consent
that
they
get
out
of
out
of
agreed
upon
and
put
it
into
you
proposed,
because
I
think
it
will
take
more
debate
right
now.
The
counter
the
counter
that
is,
the
one
I
wrote
for
when
I'll
promote
25
now,
which.
A
D
A
Well,
yeah,
yeah,
weird,
okay,
maybe
Nick!
You
have
two
accounts
for
some
reason:
I
don't
know
anyway.
That's
why
sorry
go
ahead.
Row
I
could?
Are
you
only
allowed
to
edit
your
thing
because
it
might
be
me?
Oh
no,
everyone
can
add
it.
I'm
just
curious.
We
have
one
oh
yes
out
easily
and
then
that
would.
A
D
D
D
This
is
similar
to
the
thing
earlier
and
actually,
with
our
discussion,
the
b
VAR
that
these
are
weights
and
not
requirements.
I
I
have,
I
have
almost
node
no
objections.
I
basically
wanted
to
bring
up
again
that
I'm
I'm
I'm
concerned.
So
sorry,
no,
I'm
I'm
the
the
I'm
concerns
that
we
define
ourselves
in
terms
of
other
people
right
I,
don't
I,
don't
believe
that
it's
it's!
It's
necessarily
are
our
job
to
chase.
D
What
right
scale
thinks,
however,
I
do
believe
that
if
we're
talking
about
these
being
weights
like
hey,
if
this
is
supported
by
common
tools,
then
it's
probably
pretty
good
divided
that
it.
You
know
that
something
that
we
keep
in
cool,
like
that,
not
I'm
totally
under
like
so
that
I
think
the
way
we've
described
that
sway
is
my
concerns.
Are
we
do
that?
I
just.
D
D
A
D
A
A
A
I
have
a
strong
objection
to
say
must
be
recommended
because
the
point
of
this
process
being
collaborative
across
the
TC
and
the
board
and
the
user
committee
is
that
there
are
perspectives
specifically
from
the
users
that
they
feel
are
not
getting
acknowledged
by
the
technical
community
and
telling
the
users
to
go
talk
to
the
project.
Leaders
again
is
the
kind
of
thing
that
destroyed
the
Mozilla
community,
so
I
don't
want
to
duplicate
that.
A
A
I
will
scratch
this
I
would
scratch
this,
because
I
think
we
dealt
with
it
with
the
detailed
question
right.
There's
no
video,
but
I
would
say,
is
literally
saying
we
do
as
criteria
respected,
strong
recommendations
from
project
leaders
in
the
TC
because
they
may
have
in
mind
future
development.
For
instance,
it
said
hey.
We
really
want
the
entire
community
to
standardize
on
using
task
flow.
It
will
be
easier
for
a
make
that
up
if
task
flow
is
guaranteed
by
being
in
core
yeah.
Well,.
C
A
D
D
Is
that
there's
their
can
their
candy
things
that
the
good
you
know
the
technical
community
or
the
near
the
the
developers
are
like
hey
it'd,
be
really
helpful
if
this
is
n,
because
it's
got
to
help
us
do
these
next
things
that
we're
wanting
to
do
is
is
a
is
a
is
a
potential
waiting
right
rather
than
the
the
inverse
which
is
or
that
you
know
it
must
be
suggested
by
project
lead
or
whatever
the
other
one
was.
You
know,
so
it's
basically
like
if
there's
there's
a
whole
bunch
of
those
thank
dude.
You
really.
B
A
Designate
would
be
a
great
example
of
that
if
we
can
get
the
identical,
so
we
will
be
able
to
build
all
of
these
other
things
that
rely
on
it
right,
and
I
think
we
should
be
cautious
about
am
using
core
as
a
stick
to
require
public
clouds
down
to
deploy
the
abilities.
Yet
I
think
it
is
the
most
powerful
use
of
core
and
therefore
we
should
probably
not
do
it
very
often
yeah.
D
I
agree
I
actually
I
should
just
argued
huhs
on
panel.
No,
no,
yesterday
yesterday
and
we're
saying
yeah,
I
think
that
a
lot
of
the
stick
approaches
these
days
are
working
much
less
well
than
the
carrot
approaches
and
where
we
can
care
it,
something
and
not
stick.
It
I
think
that
I
think
that
we
we
lined
up
in
a
much
richer
place.
Yeah.
A
A
I
would
actually
like
to
wrap
it
up
if
we
can
and
let
people
think
about
it.
I
would
I
would
add
the
one
thing
that
I
I
think
it's
not
that
contentious,
but
maybe
it
is,
we
shouldn't
do
it,
which
would
be
just
that
the
past
the
test
pass
in
multiple,
multiple
conditions,
but
it's
right
that
it
reliably
passes
in
multiple
cases.
Oh,
you
mean
not
non
deterministic
test
values.
Well,
yes,
yeah,
but
also
that
it's
not
a
not
a
CI
gate,
specific
test
right.
Well,
we're
looking
for
things
that
are
actually
widely
implemented
capabilities.
A
D
D
D
E
I
take
what
just
came
up
before
and
some
of
the
discussions
we
had
were
things
like
I
mean
there's
a
set
of
things
that
might
work
on
a
devstack,
vm,
enabled
environment
that
the
minute
you
get
a
multi
dead
world
and
I
can't
Dave
a
specific
one
that
I've
never.
There
was
some
concern
that
devstack
is
not
representative
of
a
real
world
appointment
and
I.
E
A
D
As
a
whole,
and
also
not
to
make
this
about
see
I,
but
it
is,
it
is
a
thing
that
has
see
I
in
the
title
is
we
are.
We
are
very
strongly
working
on
multi-node
real
world
bare
metal
as
part
of
the
gate,
so
so
the
fact
that
a
single
node
devstack
thing
is
a
is
also
a
temporal
implementation
detail
at
the
moment.
Yes,
I
know
that
really
combined
with
that
combined
with
community
things
is
I,
think
I
think
it's
us
past.
This
yep.
E
C
A
So
I
would
I
wasn't
want
to
edit
the
admin
rights
and
the
reason
is
because
I
think,
while
they're
not
necessary
for
the
public
cloud
environments,
I
think
it
is
fairly
necessary
for
the
private
cloud
environments
and
as
an
easy
example.
The
capabilities
of
Keystone,
with
multiple
backends
for
things
like
or
multi-region
ourselves
or.
A
Of
filter,
scheduler
and
tagging,
and
some
of
those
maybe
even
very
simple,
functional
things
that
require
admin
privileges,
even
in
fact
even
validating
actual
quality,
JSON
functionality
of
different
users.
Permissions
restrict
the
API
calls
they
can
make.
Those
are
pretty
key
functionality
for
any
open
sex
product
and
something
that
folks
are
relying
on
that.
It
would
be
good
to
be
able
to
get
for
definition
around
I
guess.
A
D
A
A
D
But
I
think
the
thing
is
is
that
I
think
there's
there's
a
long-term
a
long
time
ago
when
we
started
talking
about
this
in
san
francisco.
That
thing
one
things
are
talking
about
is
is
by
getting
by
getting
the
scoreboard
up
of
all
of
the
things.
Then,
then
we
have
the
collection
of
things
that
we
can
use
to
to
start
making
the
mapping
association
with
the
various
marks
and
I
think
that
I
think
that
it's
entirely.
D
It
would
be
very
weird
if
we,
if
we
required
the
admin
things
for
use
of
a
mark,
that
only
made
sense
and
public
cloud
setting.
You
know
like
we're
trying
to
use
that
to
communicate
something,
but
if
we
are
wanting
to
communicate
information
about
about
what
the
private
cloud
experience
would
be,
then
I
heard
that
I
would
like
to
I'd
like
to
see
some
some
consistency
there
as
well.
Even
if
it's
not
something
the
HBO
Rackspace's
public
clouds
could
have
any
chance
of
of
certifying
on
as
well.
A
E
B
E
Guess
I
mean
I,
see
value
and
having
these
in
the
overall
score
card,
a
set
of
tests
that
you
run,
but
I
am
not
convinced
that
the
admin
tester
much
should
be
must
pass
as
opposed.
Why
did
be
nice
for
you
to
have
them
and
publish
you
where
you
are
on
the
scorecard,
so
you
can
compare
to
everybody
else,
but
that's
different
than
having
it
as
a
must-have
before.
C
F
C
D
I
think,
but
exactly
what
rob
was
was
saying
just
a
second
ago,
is
that
these
aren't
these
aren't
external
certifications,
we're
not
we're
not
going
to
be
gaining
near
cloud
and
and
giving
you
a
badge
or
not.
You
know,
and
so
if,
if
you
don't
have
a
public
accessible
endpoint
for
testing
these
things,
then
that's
not
we're
not
we're,
not
the
boogeyman.
D
At
the
moment,
we're
not
coming
back
and
and
we're
saying
these
are
the
criteria
and
you
meet
them
and
if
you're
a
public
cloud
and
if
no
one's
ever
going
to
see
that
you
can,
you
can
test
it
and
you
can
tell
you
yeah,
we
meet
that
and
no
one
will
ever
know.
Actually,
if
that
is
now.
If
that
is
true
or
not.
D
It
doesn't
because
the
thing
is:
is
it
no
one's
ever
going
to
come
chase
you
down
and
beat
you
up
in
that
case,
because
no
one's
ever
going
to
interact
with
you
were
saying
in
there?
It's
when
somebody
says
yeah
mine
mine,
meets
these
criteria
in
my
distribution
and
you
deploy
it
and
it
doesn't.
But
somebody
need
angry.
You
know
and.
F
A
Those
tests
might
end
up
being
very
important
for
ecosystem
development
and
commercial
development
of
OpenStack,
where
somebody
who's
counting
on
those
interfaces.
This
is
what
would
come
back
to
interrupt.
The
council
doesn't
arose.
Interface
is
being
available
in
order
to
use
the
cloud
in
a
certain
way
or
another
project
might
depend
on
those
interfaces
to
be
bootstrapped,
or
something
like
that.
That's
that
the
place
where
it's
perfectly
reasonable
for
us
to
have
it,
and
it's
not
going
to
hurt
the
public
clouds
yeah.
D
D
One
final
thing
to
lose:
these
are
these:
are
things
were
we're
we're
sort
of
defining
those
those
things
somebody
can
count
on
say
somebody
creates
a
tool
up
in
the
ecosystem
that
helps
you
helps
you
do
a
management
task
for
your
four-year
cloud.
They
don't
that
works
against
admin
interfaces.
There's
we've
now.
We've
now
got
a
we've.
Gotta
get
now
we're
going
to
mark
protecting
a
set
of
capabilities
that
people
can
expect
under
that
tool.
D
Author
can
say:
oh
yeah,
totally
I'm
going
to
the
right
one,
its
going
to
do:
OpenStack,
private
cloud
administration
and
your
public
cloud,
and
you
just
want
to
use
that
tool.
Then
you
can
actually
check
and
see
if
actually
you
it's
viable
for
you
to
use
it
because
you
know,
if
you
are
in
support
of
those
of
those
admin
api's,
then
you
know
that
that
you
you
can.
You
can
purchase
out
of
the
tool
ecosystem
if
you
chose
to
you
know
it's
like
I.
E
I
guess
the
only
concern
I
mean
I
generally,
okay,
with
where
you
go
and
I
think
you're
implicitly
now,
starting
to
create
a
public
and
private
cloud
core,
that's
different,
because
you
are
still
going
to
have
a
set
of
interfaces
that
actually
comes
out.
Those
we
support
core,
except
that
there's
some
portion
of
that
that
you
as
a
customer
can
access
I
mean.
E
A
C
A
That
would
make
the
course
smaller
and
I
think
that
that's
a
redoubtable
suggestion
I.
It's
interesting
that,
firstly,
I
don't
agree
with
that
as
a
criteria,
but
that,
under
that
rationale
it
does
help
us
not
allow
tests
that
we
don't
with
it.
It
keeps
the
core
smaller
here's
here's
my
suggestion
since.
A
At
a
time
that
what
we
do
is
we
we
stop
with
this,
I
lost
you
know
when
we
do
this.
If
somebody
has
a
test,
they
really
want
to
make
sure
we
discussed
today.
Then,
let's
do
that,
but
I
want
to
make
sure
we
spend
a
little
bit
of
time
talking
about
the
next
meeting
and
communications
up
to
the
larger
committee.