►
From YouTube: OpenStack DefCore Elephants.3 2014 01 07
Description
OpenStack DefCore meeting recording
Notes on https://etherpad.openstack.org/p/DefCoreElephant.3 (with timestamps!)
B
C
D
D
B
C
D
F
B
B
Cool
I'm,
hoping
we
can
stay
pretty
close,
pretty
tight
on
the
agenda,
I
think
there's
some
specific
action
items
that
I'm
hoping
we
get.
We
come
out
with
around
what
you're
actually
moving
forward
on
some
of
these.
These
they
were
big
ticket
work
items
that
we
need
to
start
jumping
on,
and
so
I've
already
started
a
template
for
desk
for
alpha
dot
4.
B
So
we
can
start
an
agenda
for
that,
as
we
have
done
online,
ok
and
the
first,
the
first
thing
I
would
know
it
is
I
sent
the
summaries
out
to
the
to
a
broader
audience,
and
then
I
posted
a
deaf
core
summary
and
Al
Allen
and
Joshua
had
both
had
a
chance
to
look
at
that
before
before
I
posted
it
on
I'm
planning
to
take
those
and
then
to
submit
to
the
community
that
I
was
hoping.
If
you
haven't
read
the
summary
post
I
did.
Let
me
throw
a
link
to
it.
B
B
B
C
B
Go
out
to
the
community
and
give
them
an
update
on
where
things
are
going,
the
response
that
I
saw
from
the
summary
of
death,
Corps
and
everybody
we've
accomplished
a
huge
amount,
in
my
opinion,
so
far,
we've
been
really
active,
did
having
a
lot
of
meetings
has
been
very
positive
people.
People
like
seeing
the
board
being
responsive.
C
Okay,
you
know
it
might
and-
and
we've
talked
about
this
earlier-
we
took
our
early
drafts
and
we
ran
them
past.
Our
our
largest
detractors
I
think
it
might
be
worth
doing
that
again
with
this
status
update
and
particularly
the
finalized
draft
criteria.
Okay,
so
I'm
happy
to
take
that
action
again
for
the
folks.
I
ran
and
passed
last
time,
George
Reese
under
Schaeffer.
C
B
G
G
Can
talk
really
quickly
and
just
give
a
state
up
what
we
learn
so
far,
the
in
terms
of
the
test
case,
so
I
was
trying
to
do
that
like
very
shortly.
So,
if
we
look
at
the
tempest
test
is
actually
have
the
four
major
category.
The
first
one
is
ABI
test.
The
second
is
scenario
cast
third
command
line
like
client
s
and
stress
test.
We
have
not
yet
to
understand
fully
what
stress
Tess's,
and
we
will
do
that
next
time.
G
So
then,
in
api
test
is
mostly
the
API
using
the
token
and
NS
air
we
further
dissect
it
out
and
because
there's
no
question
earlier
to
say,
as
for
the
percentage
of
API
coverage,
so
before
we
down
into
the
percentage
of
AP
I'd
coverage,
we
try
to
look
at
for
the
api
test.
What
are
the
components
that
being
test?
So
that
is
what
this
table
is.
So,
as
you
can
see,
most
of
the
api's
has
a
concentrate
on
compute
and
also
object
storage.
G
So
for
the
so
total
number
of
tests
in
here
we
category
that
also
engaged
test
and
smoke
tests.
In
generally,
the
smoke
test
will
run
about
10
minutes.
The
the
complete
gate
test
is
about
45
to
one
hour
and
total
number
of
tests
in
ABI
test
is
a
thousand
two
hundred
the
number
there
and
there's
two
interface,
the
JSON
interface
and
xml
interface.
So
those
are
the
api
test
and
the
next
tab.
G
We
give
the
detail
and
we're
going
to
dive
into
and
trying
to
look
at
the
percentage
of
API
being
coverage
for
each
of
the
tests.
But,
from
my
point
of
view,
is
more
that
the
api
test
could
be
coverage.
But,
as
we
know,
we
have
a
lot
of
option
configuration
option
and
that
will
be
very
hard
to
really
know
what
configuration
are
important
to
to
cover
and
that's
what
we're
going
to
do
next
time,
then
we
die
quickly
into
a
scenario
test.
So
before
we
move
on,
is
there
any
questions.
C
G
C
B
C
G
And
then
the
senior
real
test
and
the
CLI
test,
those
that
test
using
the
official
opens
that
client
that
the
clients
so
is
Nova,
client,
a
keystone,
client,
etc.
The
test
is
very
different
from
the
api
test,
which
is
used,
the
service,
endpoint
and
token
etc.
So
the
tone,
the
the
purpose
of
scenario
test,
is
go
across
different
components,
but
you
do
see
in
a
few
test
scenario.
G
G
The
important
thing
here
is
these
tests
use
the
official
client
interface,
so
is
not
like
the
api
test
and
then
the
the
COI
test
itself
again
is
kind
of
just
like
the
scenario
test,
but
just
one
on
one
component,
there's
some
overlap
between
the
COI,
the
client
s
and
the
scenario
test.
So
that's
what
we
have
summarized
for
you
today,
okay,.
G
G
G
And,
and
and
I
did
not
do
the
detail
on
seven
to
ten,
because
it's
just
one
component,
it
does
a
detail
of
the
test
itself.
It
doesn't
go
across
the
components,
so
it
it's
just
not
not.
It's
not
a
test
k
to
come
up
to
I
feel
like
these
two.
This
item
may
be
should
belong
to
the
DCO
I,
but
it
doesn't
matter
at
this
time
so
next
time
we
look
at
stress,
test
and
more
important.
G
C
B
B
So
what
we
so
I
guess
we're
going
to
need
to
get
to
create.
Maybe
we
should
wait
until
we
talk
about
the
criteria,
because
that
really
is
where
I
would
run
with
next
steps
is
taking
this
work
and
then
jump
figuring
out
how
we're
going
to
start
doing
the
criteria
score
as
a
pass
and
I
have
some
types
and
thoughts
around
how
this
is
going
to
intersect
with
criteria.
C
You
know,
via
whatever
mechanism
the
tests
are
written
to
use.
I
guess
this
comes
back
to
one
of
the
early
discussions
about
deaf
core
back
with
and
restack
before
the
board
approval
the
compatible
one
folks,
John
jean-pierre
reached
out
to
say:
hey.
Do
you
want
to
include
compatible?
One
is
part
of
the
test
suite
and
it
doesn't
use
the
official
libraries
it
uses,
alternative
clients
and
the
same
argument
could
be
used
for
the
Boche
CPI
as
part
of
cloud
foundry
which
uses
fog.
C
B
C
B
You
a
complete
opt-out
answer,
yes,
which
is:
let's:
let's
take
the
test:
we've
got
put
the
criteria
on
them
and
see
what
happens:
okay,
because
that
and
then,
and
then,
if
we
want,
if
we
bring
in
other
there's
nothing
in
the
principles
that
limit
us
to
the
the
exact
sweet
and
tempest.
So
it
would
be
reasonable
for
people
to
bring
the
other
tests
and
see
how
they
measure
against
the
criteria.
B
B
No
I
I
think
that
we're
going
to
get
tangled
in
the
criteria
discussion.
If
we
talk
about
next
steps,
because
the
DA
thing
to
me
and
unless
there's
something
what
I'm
seeing
is
that
we've
got
a
body
of
tests,
we
have
some
scoring.
We
now
have
a
spreadsheet
that
has
all
the
tests
in
it.
The
next
thing
that
I
think
to
do
is
to
start.
B
C
I
mean
I
guess
my
my
concern
is
to
start
applying
criteria
without
the
sample
output
of
the
ref
stack
of
running
those
tests
against
a
bunch
of
different
cloud
environments
is
what
worries
me
I
think
we'll
get
I
mean
I
agree.
We
have
to
do
that
because
we
don't
have
the
data
yet,
but
I
would
be
more
comfortable
if
we
had
the
data
before
we
started
talking
about
the
criteria
as
it
applied.
I'm.
B
Not
expecting
us
to
score
all
1,200
something
test
I
I
I'm
hoping
for
next
steps
is
between
now
in
the
next
meeting
now
I'm.
Jumping
to
next
steps,
anyway,
is
that
we
will
do
it
we'll
figure
out
here
a
sample
set
that
we
think
is
we're
scoring.
That
is
going
to
give
us
enough
data
to
to
know
if
the
criteria
right
and
then
I
got.
F
B
B
C
B
E
B
C
Neutron
has
almost
zero
coverage
of
anything
in
the
gate.
It
has
one
test,
object,
storage
has
zero
coverage
of
XML,
or
there
is
a
you
know.
Volume
has
volume
and
compute
both
have
almost
equal
coverage
of
XML
and
JSON,
so
it
may
be
that
there
is
an
easy
conclusion
that
says
if
the
broader,
if
we
care
about
XML
for
interrupt,
maybe
we
should
encourage
people
to
write
some
test
coverage
on
the
XML
side.
Now
that
would
be
what
George
Reese
would
say
if
we
showed
him
this
slide.
B
B
E
B
C
C
B
H
They
robbed
the
other
thought
I
had
this
destroy
I,
just
look
into
the
API
detail,
section
I'm
wondering
if
it
would
make
sense
to
just
take
a
pass
at
capabilities
based
on
the
test
lists
of
the
baby
and
I.
Don't
remember
for
sure,
but
I
thought
we
kind
of
talked
about
potentially
scoring
capabilities
and
then
realizing.
There
may
be
multiple
tests
along
with
a
capability
that
that
thought
is
fairly
like
out
in
the
list
of
tests,
that's
in
there
and
it
might
not
be
a
hundred
percent
accurate.
H
C
C
I
mean
one
of
the
one
of
the
goals
we
had
had
in
kicking
off.
This
whole
discussion
of
coverage
was
to
loop
in
the
docs
folks,
because
it
may
be
that,
logically,
the
way
the
capabilities
are
described
in
the
docs
is
the
right
way
for
us
to
roll
them
up,
or
it
may
be
that
there's
something
about
the
semantics
of
the
underlying
API
that
make
it
easier
to
identify
what
the
capability
is
that
make
sense,
because.
B
C
Was
I
was
just
seconding,
Troy
tomans
point,
which
is
that
yes
rolling
these
up
to
capabilities
and
then
scoring
the
capabilities
with
criteria
is
probably
the
better
approach,
and
maybe
we
can
learn
from
the
docs
or
sort
of
you
know
intersect
the
docks
with
this
list
of
tests
as
a
way
of
identifying
what
the
underlying
capabilities
are.
You
know
AKA
security
groups
of
the
capability,
and
there
may
be
a
dozen
tests
in
here
that
relate
to
to
that.
C
B
H
H
We
may
want
to
group
those
at
a
higher
level,
but
then
I'd
be
willing
to
take
the
spreadsheet
initially
and
just
you
know,
try
to
do
a
first
pass
filter
and
see
what
that
leaves
us
in
terms
of
what
at
least
what
number
of
capabilities
look
like
they're
represented
based
on
the
test
names
that
we
have
in
the
current
sweetie.
And
then
it
may
make
sense
to
take
that
listing
compared
to
the
API
dachshund
to
see
there's
the
obvious
missing
pieces.
H
H
F
B
G
H
H
C
B
That
and
I
I
want
to
make
sure
we
have
consensus
that
this
is
a
thing
that
we
want
to
push
because
I,
based
on
what
and
Eileen
could
go
over
this
from
the
legal
legal
committee
subcommittee
meeting
I.
This
isn't
good.
This
isn't
going
to
be
a
oh
yeah.
That
makes
sense.
Let's
go
topic,
you
think
we're
going.
H
C
I'm
personally,
really
motivated
to
take
it
on,
but
I
am
keenly
aware
that
it
might
be
appropriate
to
divorce
that
from
def
core
I
think
it
I
think.
It
really
really
helps
with
the
definition
of
programs
and
projects
and
openstack
in
the
intersection
of
the
mark,
with
the
use
of
the
community
mark
versus
commercial
mark.
But.
C
A
And
I
apologize,
I
missed
the
last
def
core
meeting,
so
I
may
be
doing
a
little
bit
of
ketchup
here,
but
I
know
on
the
the
legal
meeting
we
had.
There
was
a
robust
discussion
on
this
Pete.
This
point
and
I
think
net-net
towards
the
end.
We
were
sort
of
looking
toward
def
core
to
help
give
us
the
answer.
If
you
will
so
that,
then
we
could
then
figure
out
the
legal
implications
here.
B
C
C
B
C
E
C
C
C
We
have
this
message
about
OpenStack
as
being
the
platform
of
the
future
of
the
data
center,
and
you
know
the
intersection
of
these
three
circles
and
the
best
way
to
express
that
mission
and
that
definition
of
OpenStack
is
to
organize
the
OpenStack
projects
and
programs
according
to
this
more
logical
arrangement
and
we're
going
to
do
the
right
things
by
the
changes
to
the
bylaws
and
the
trademark
policy
to
make
that
work
and
to
eliminate
confusion
and
to
lower
the
amount
of
noise
around
new
programs
and
new
projects
etc.
But
I
don't
think.
E
Yeah,
I
think
I
think
the
there
there
like
a
lot
of
different
uses
and
and
kind
of
overlapping
areas
that
come
into
play
with
this,
which
I
think
is
what
makes
it
not
not
just
a
you
know,
even
an
easy
thing
to
explain,
but
but
even
less
easy
to
kind
of
get
everyone
on
the
same
page.
But
I
think
that
you
know
from
from
the
perspective
of
how
we
talk
about
OpenStack
and
how
we
market
it
and
and
describe
it.
E
We
really
have
moved
away
from
projects
or
programs
or
anything
that
that's
kind
of
at
a
component
level,
and-
and
we
really
are
trying
to
talk
about
capabilities
and
in
general,
we
talk
about
the
three
buckets
of
compute
storage
and
networking
and
we're
actually
working
on
some
updates
to
kind
of
bring
that
along
even
even
farther
and
abstracting
away
those
components,
because
it's
just
confusing
at
that
level.
So
I
think
I
think,
from
sort
of
the
messaging
and
marketing
perspective
it's
it
makes
a
lot
of
sense.
E
I
think
the
the
area
that
becomes
it
becomes
tough
is,
is
you
know
these
things
are
are
actually
part
of
OpenStack.
You
know
they
are
really
in
terms
of
software,
they
are
open,
sac
and
and
and
they
go
through
an
official
process
and
get
approval
and
are
developed
under
a
fishin.
And
so
it's
kind
of
hard
to
to.
E
A
So
polite
because
I
guess
I
was
I'm
a
little
bit
confused
to
like
even
before
we
get
to
the
technology
piece
because
you're
right,
that's
the
big
news
from
the
marketing
messaging
side.
So
how
specifically?
How
are
you
talking
about
OpenStack
where
you've
moved
away
from
this
project
program,
because
I
mean
oftentimes
I,
get
kind
of
hung
up
on
that,
even
as
well,
even
when
I'm
trying
to
talk
about
it
externally
to
someone
I'll
get
sort
of
wrapped
up
in
the
project
program
piece
of
it?
How
do
you
kind
of
eliminate
some
of
that
confusion?
A
A
C
E
D
H
E
The
object,
storage
capability
and
will
say
this
is
what
you
use
it
or,
and
we
talked
about
the
block
storage
capability,
and
this
is
what
you
use
it
for
those
match
up
to
12
12
programs
which
have
single
projects
in
them.
But
then
we'll
also
talk
about
things
like
shared
services
like
a
service
registry
and
identity
service.
E
You
know
an
image
service
and
we
have
these,
so
we
kind
of
roll
it
up
to
at
a
capability
level
and
again.
This
is
because,
especially
as
the
number
of
projects
and
programs
and
everything
have
proliferated,
the
the
it
it's
very
clear
that
that
is
a
confusing
message
to
people
who
are.
You
know
just
looking
for
something
that
it's
kind
of
put
in
the
more
familiar
product,
marketing
terms
that
they're
used
to
out
in
the
in
the
you
know
in
their
everyday
jobs.
We're.
B
E
Some
of
the
some
of
the
bylaws
changes
that
we
that
we
talked
about
in
the
legal
call
where
we,
where
we
kind
of,
want
to
remove
the
the
list
of
projects
from
the
bylaws
and
and
and
kind
of
be
less
specific
at
that
level.
I
think
are
actually
good
approaches
to
take,
because
I
also
think
that
you
know
that
I
think
we've
made
progress
in
this,
but
I
think
that
the
one
thing
that
I
I
feel
certain
about
is
you
know.
E
E
I
would
like
to
see,
as
an
approach
is
really
to
to
sort
of
put
less
specificity
directly
in
the
bylaws,
because
it's
kind
of
the
hardest
thing
to
update
and-
and
you
know
I
mean
I
think
we
can-
we
can
talk
about
exactly
what
that
means,
because
I
don't
have
the
full
answer
on
that,
but
I
think
you
know
moving
away
from
from
basically
they're
being
in
just
an
approved
list
of
core
projects
is,
you
know,
is
a
good.
Is
a
good
step.
I
think
that
the
thinking
about
the
the.
E
You
know
one
of
the
things
that
we
talked
about
in
that
meaning,
as
well,
was
sort
of
using
the
using
OpenStack
paired
with
a
project
name
and
a
standalone
sense
versus
in
kind
of
a
you
know,
a
release
sent
and
I
think
that's
something
to
the
that.
It
would
make
sense
to
clarify,
because
I
don't
think
that
it
that
you
know
if
somebody
is,
is
off
using
only
OpenStack
telemetry
or
something
like
that.
E
You
know
that
the
they
should
give
the
impression
that
there
that
they're
kind
of
running
what
would
commonly
be
thought
of
as
OpenStack
I
think
like
some
of
those
things
are
areas
where
there
can
be
a
lot
of
clarification.
Then
I
think
this.
You
know
some
of
the
wording
in
the
vial
is
right.
Now
is
potentially
confusing.
B
B
A
Yeah
I
completely
agree
with
that.
It
makes
a
lot
of
sense
both
what
you
and
Jonathan
are
saying,
mark
I
think
we
do
need
to
have
more
flexibility,
so
we
can
go
forward
and-
and,
like
you
said
to
I
mean
that
I
think
is,
you
know,
as
we
guys
were,
pointing
out
earlier.
Look
with
the
projects
almost
two
years
in
from
at
least
boo,
moved
over
to
the
foundation
and
we've
already
seen
significant
changes
since
then.
So,
if
we
can
have
just
allow
ourselves
more
flexibility
in
the
future,
I
think
that
will
be
really
helpful.
A
G
B
Need
to
do
this
and
I
think
we
want
the
flexibility
and
I
like
that.
What
I
don't
want
to
do
is
this
right
derail
another
legal
committee
meeting
this,
because
because
people
get
their
head
their
head
explodes
when
we
say
you
know
when
we
say
all
right,
salamat
ER,
you
can't
say
salam
eater
is
OpenStack
telemetry,
you
have
to
say
OpenStack
telemetry
project
salamat
ER.
But
if
that's
the
right
thing
to
say
that
we
just
need
to
agree
that
that's
what
we're
going
to
do
and
then
disseminate
that
that
is
the
message
it
right
and.
D
On
this-
and
I
will
say
I
don't
want
to
you
know-
you
know-
I
think,
as
a
matter
of
context,
I'm
dealing
with
another
open
source
organization.
I
can't
talk
about
because
it
is
in
public
yet,
but
who
is
wrestling
with
these
types
of
issues
and
the
use
of
certain
word
subscribe
programs
or
projects,
etc,
so
that
so
this
is
not
a
situation
is
limited
to
OpenStack
yeah.
I
think.
F
D
D
E
Things
that
is
it
blocking,
because
if
there's
a
specific
thing
that
we
want
to
overcome
and
that
might
actually
give
more
focus
to
the
discussion
versus
you
know
kind
of
I
think
right
now
we
look
at
it
and
we
know
that
there
are.
There
are
things
that
that
we
should
try
to
fix.
But
maybe,
if
you,
if
you
can
lay
out
like
a
specific
thing,
that's
just
getting
blocked,
then
again
it
will
give
us
kind
of
a
straight-line
path
to
attack.
First
I
think.
B
I
think
that's
the
key
question.
Thank
you
for
asking
it
I
feel
like
it
is
blocking
us
moving
from
a
project-based
definition
for
core
to
a
test.
Capability-Based
definition,
of
course,
and
so
I
feel
like
as
long
as
people
are
trying
to
make
projects
like
sumama,
tur
or
whatever
comes
up
so
I'm,
just
the
one
that
hit
first
into
a
core
project
and
they're
worried
about
that.
E
Well,
I
think
that,
like
with
the
salah
meter,
telemetry
thing,
you
know
the
what
the
project
team
is
trying
to
solve
for
is
just
is
to
to
be
able
to.
Actually
you
know
to
call
their
the
work
that
they're
doing
that's
being
included
in
the
OpenStack
release,
OpenStack
and,
and
the
you
know,
I
think
that
the
way
the
bylaws
are
worded
right
now,
you
can
interpret
that
as
as
saying
that
they
have
to
be
a
core
project.
/,
the
bylaws
I
think
that
moving
like
changing
that
language
to
something
that
is.
E
You
know
III
think
that
mark
radcliffe,
you
had
even
thrown
out
a
sort
of
like
a
a
line
on
that
that
legal
call,
something
like
you
know,
the
core
OpenStack
project
is
the
is
the
set
of
capabilities
for
which
you
know
test
paths
that
are
approved
by
the
board
and
the
technical
committee,
or
something
like
that.
I
mean
just
something
that
that
simplifies
that
and
puts
a
a
clear
line
that
gets
crossed
in
the
bylaws,
and
it
doesn't
have
to
say
exactly
how
that
line
is,
is
maintained
on
an
ongoing
basis.
E
It's
just
the
responsibility
of
the
board
in
the
technical
committee.
I
think
like
that
would
be
to
me.
That's
a
that's
kind
of
like
the
bylaws
step
that
the
then
over
time
we
can
adjust
that
we
can
add
things
to
it.
We
can.
We
can
move,
rework
it,
but
it's
within
the
the
it's
actually
in
the
power
of
the
poor
of
the
board
and
the
technical
committee
instead
of
you
know,
being
something:
that's
that
has
the
required
by
law
changes
all
the
time
right.
B
D
G
D
Want
to
do
something
less
if
it
requires
a
bylaw
change
but
I
think
intertwining.
The
discussions
at
this
point
is
not
productive.
I
I
think,
let's
define
what
we
want.
Let's
define
what
the
best
cases
for
what
we
want
to
do
and
then,
if
we
decide
that
we
don't
want
to
do,
we
cite
needs
a
bylaw
change
and
we
decided
we
don't
want
to
do
it.
Then
we
can
slim
it
down,
but
I
think
we
need
to
make
the
case
for
what's
right
technologically
and
then
decide
how
to
implement
it
legally
guys.
C
I'm
going
to
I'm
going
to
offer
a
little
bit,
I'm
gonna
offer
a
little
bit
of
yelling
as
a
service.
Here
you
is
been
going
on
for
three
years
and
it's
making
me
so
bloody,
angry
I,
just
I
can't
even
express
it.
The
word
OpenStack
is
absolutely
losing
value.
It
is
becoming
synonymous
with
crap,
experimental
science,
software
that
doesn't
work
and
the
number
one
reason
for
that
is
almost
anything-
can
go
out
and
call
itself
OpenStack.
So
we
have
things
like
Neutron
chapter
two
years
doesn't
even
have
basic
feature:
parity
with
Nova
network.
C
The
code
is
an
unworkable
mess.
It
was
just
had
a
major
refactor
between
one
version
and
another
such
that
we
can't
even
back
for
it
Fitch's
fixes
now,
and
yet
it's
known
as
OpenStack
networking
to
the
exclusion
of
Nova
Network,
which
is
seventy
percent
of
the
deployed
codebase.
So
the
reason
that
we
have
this
discussion
in
the
first
place,
the
reason
we
put
it
in
the
bylaws
is
because,
if
we
can't
limit
the
things
that
can
call
themselves
OpenStack,
the
term
OpenStack
ends
up
having
no
value
at
all,
and
that
is
the
situation.
C
We're
ending
up
with
so
def
core
is
lovely
as
a
theoretical
exercise.
To
say:
hey
would
be
nice
if
things
that
we're
called
OpenStack
worked
with
each
other,
but
if
we
can't
also
limit
that
things
outside
of
def
core
shouldn't
be
called
OpenStack,
unless
basically,
they
work
we're
in
a
very
poor
position.
C
So
the
proposal
here
is
to
say:
can
we
dilute
the
number
of?
Can
we
limit
the
number
of
things
and
go
around
saying:
hey
we're
OpenStack,
X
and
pick
a
new
term
we're
OpenStack
telemetry?
What
if
the
health
dilemma
tree
means
so
that
the
word
OpenStack
is
not
getting
stamped
on
things
that
nobody
uses
and
they
basically
don't
function.
I.
C
C
The
reason
the
bylaws
with
that
responsibility
between
the
TC
and
the
board
was
because
the
understanding
was
the
TC
even
then
did
not
see
themselves
as
having
the
authority
to
control
what
could
use
the
term,
but
only
the
authority
to
control
whether
or
not
they
were
following
the
approved
process,
and
that
was
the
whole
discussion
that
went
into
the
integrated
release
definition
as
well.
The
only
thing
the
TC
is
agreeing
to
is
that,
yes,
they
are
following
the
process.
C
They
use
stack
Forge,
they
have
code
reviews,
they
built
a
committee,
a
community
and
and
and
they're
integrated
with
our
mailing
list
and
our
sense
of
self.
But
the
definition
of,
should
it
logically
be
part
of
infrastructure
as
a
service,
or
does
the
code
actually
serve
any
of
the
common
needs
of
the
folks
who
are
consuming
the
rest
of
OpenStack?
They
punted
that
has
been
punted
to
the
board
and
we've
done
nothing
with
it.
The
balls
sitting
on
the
ground.
C
B
I
strongly
agree
with
you,
and
this
is
why
we
kept
it
on
the
agenda
for
this
committee,
because
if
we,
if
we
don't
have
some
control
of
OpenStack
or
what
it
means,
then,
when
we
actually
surface
out
of
rest
deck
or
a
set
of
tests
and
capabilities
at
defined
core
we're
going
to
find,
we've
diluted
the
core
statement,
and
so
I
guess
I'm
not
ready
to
drop
this.
It.
H
Just
like
they
just
add
I
mean
just
added
to
that
point.
I
think
one
of
the
few
things
that
open
that
the
foundation
does
own
is
the
OpenStack
brand
and
if
we
don't
start
putting
some
mechanism
around
how
it
gets
used
and
where
it
can
and
can't
be
used,
benefit
will
continue
to
his
values.
So
I
mean.
H
And
then
I
tend
to
agree,
I
think
the
program's
mechanism
for
doing
that
is
clearer,
at
least
in
a
way
we
talk
about.
It
then
champion
near
the
other
elements
that
have
been
coming
out
there
so
I.
Do
you
think
it
is
an
important
topic
that
the
board
needs
to
stay
on
too
I?
Don't
think
we
can
just
drop
it
so.
B
Here's
what
I
don't
want
to
we've
gone
more
than
20
on
this
I
hate
to
be
timekeeper,
but
it's
helpful
that
we
have
consensus,
be
deathcore
that
this
is
an
important
topic.
I
think.
The
next
thing
we
need
to
do
is
have
needs
to
get
on
the
board
agenda
and
I.
Think
before
that,
we
need
to
talk
to
the
TC
as
in
a
joint
meeting
and
work
this
and
at
least
find
out
if
the
TC
is
going
to
have
an
allergic
reaction
or
supportive
reaction
and
find
out
what
the
allergies
are
too.
E
Another
aspect
of
it
is
if
we,
because
I
think
that
you
know
Josh,
you
make
a
lot
of
really
good
points
there
and
I
think
I
still
think
that
that
perhaps
there's
some
way
to
actually
get
these
retirement.
The
the
output
of
these
results
even
earlier
into
the
process,
because
I
think
that
the
the
you
know,
if
you
look
at
the
like
the
graduation
requirements
and
everything
that
the
TC
has
has
been
putting
together,
I
think
they
do
care
about
the
functionality
and
how
well
it
works,
but
they
don't
necessarily.
E
They
haven't
taken
the
time
to
kind
of
build
up
a
set
of
inputs.
That
are
the
same
kind
of
thing
that
we're
talking
about
here,
and
so
you
know,
I
think
that
it
actually
would
be
would
be
really
great.
If,
if
this
was
something
that
became
part
of
the
incubation
process
was
actually
like
starting
to
develop
tests
along
these
lines.
C
Yeah
I
totally
agree.
I
still
think
this,
the
you
know,
the
separation
from
projects
to
programs
was
really
useful,
but
the
equation
of
a
one-to-one
relationship
between
program
and
project
broke
all
of
the
usefulness
of
that
separation
and
and
that's
I,
think
what
we're
trying
to
get
back
from
is
to
say
we
need
to
have
fewer
programs,
they
need
to
be
tightly
managed.
They
need
to
represent
really
a
very
fundamental
blessing
by
OpenStack
that
that
that
the
things
in
this
program
are
what
we
believe.
C
Openstack
is
and
should
be
in
the
future,
and
you
know,
but
I
think
you're
right,
I
think
and
rob
to
respect
your
role
as
time
deeper
if
the.
If
the
right
next
step
is
for
us
to
go
and
have
a
joint
session
with
the
TC
on
this
topic,
then
let's
go
do
that
at
the
earliest
opportunity,
but
the
last
six
times
we
have
proposed
a
joint
session
with
the
TC.
They
have
not
made
the
time
for
it.
C
C
C
B
Think
I
think
that
they'll
be
receptive.
If
there's
a
single
topic
meeting
that
for
for
this-
and
they
understand
it-
I
mean
I.
They
definitely
make
time
when
when
when
they
feel
like
the
board
is
doing
something.
They
don't
agree
with
right
that
we
saw
that
with
the
spider
spider,
stuffed
I
got
plenty
of
direct
TC
interaction
based
on
spider
and
and
we
had
a
lot
of
discussions
and
it
improved
things.
So
let's
try
that,
but
I
think
it
needs
to
be
on
the
board
agenda.
B
A
E
B
C
B
C
C
E
B
All
of
the
tests,
because
that's
part
of
our
our
filtering
process,
is
to
collect
feedback
about.
What's
going
on
so
Chris
tack
is
the
public
face
of
how
all
this
all
this
stuff
is
going
to
go
and
josh
has
been
leading
the
charge
and
has
the
been
dedicating
the
resources
into
the
into
getting
making.
B
H
B
So
the
idea
is,
we
want
to
put
the
use
cases
out.
This
is
david
lin
well,
and
I
had
sat
down
after
her
previous
meeting
and
come
up
with
this
list
and
it
hasn't
been
vetted
vary
widely.
So
this
this
is
sort
of
our
first
exposure
with
it,
but
what
we
did
independent
of
the
persona
work
was
also
going
on.
B
We
created
some
Sona
categories,
so
there's
ops
users
prospect
is
somebody
considering
OpenStack
vendor
the
foundation
itself,
because
we
think
there's
a
vested
interest
in
that
and
then
there's
there's
another
vendor
who
relies
on
the
OpenStack
api's,
and
this
is
what
we
tried
to
do
with
the
numbering
is
actually
cross
cross
link
numbering
so
we
we
had
things
seem
out
of
order,
it's
because
we
kept
adding
at
the
bottom
so
that
our
numbering
wouldn't
get
broken
and
went
through
and
tried
to
identify
these
these
items.
It's
a
really
fun
discussion.
B
We
probably
need
a
almost
a
dedicated
meeting
to
review
these,
but
the
idea
was
that
we
went
through
to
find
a
Minimum
Viable
Product
that
and
that's
the
highlighted,
yellows,
the
things
that
we
think
we
need.
We
must
have
in
April
there's
a
lot.
We
actually
want
all
these
things
done
for
April,
but
the
yellow
one
seems
like
a
required
step.
C
C
D
B
C
And-
and
just
did
so,
everyone
is
clear.
This
is
just
basically
the
burn
down
list
of
what
David
will
be
working
on
implementing
and
restack
in
what
order,
because
we
could
build
everything
forever.
But
if
we
need
to
use
this
tool
to
complete
the
Deaf
core
work,
we're
not
going
to
have
every
feature
we
might
want
done.
I
do.
I
do
not
have
any
infinite
size,
dev
team.
F
B
Side
of
this,
which
is
a
containerized
version
of
tempest
that
uploads
the
results
to
restack,
so
we're
working
on
both
sides
of
this
that
doesn't
really
show
up
in
these
use
cases.
But
there
is
a
an
effort
to
try
and
make
it.
So
you
can
take
tempest
in
a
container
in
linux,
container,
run
it
in
a
local
environment
and
then
have
it.
You're
basically
be
self-contained
and
then
upload
the
results
to
restack
as
a
single
pass
and
we'll
use
that
I.
F
C
B
B
C
B
That
all
right,
thank
you,
so
I
would,
I
would
caveat
this
very
in
the
sense
of
that.
We're
not
we're
not
looking
to
perfect
the
criteria
right.
What
we're
trying
to
do
and
let
me
pull
up
the
page
but
we're
trying
there's
three
there's
13
criteria.
If
you
haven't
reviewed
them,
please
take
some
time
to
review
them.
B
There
were.
There
were
a
couple
of
significant
things
that
came
out
of
the
subcommittee
or
for
the
criteria.
One
is
that
we
made
the
decision
that
they
would
be
weighted
so
of
the
thirteen
criteria.
Some
of
them
will
be
considered
more
important
than
some
of
them
less
important.
We
don't
know
what
the
late
should
be.
C
G
B
C
B
B
G
B
Might
have
just
postponed
the
conversation,
but
it
made
it
easier
to
get
consensus
and
then
the
idea
is
these
criteria
are
not
the
final
criteria.
They
are
tests,
they're
their
preliminary
criteria
that
we're
going
to
use
to
see
if
the
whole
process
works,
so
I
would
actually
ask
us
to
exit
this
meeting
with
a
hey,
yay
verily.
These
preliminary
criteria
are
good
enough
that
we
can
evaluate
a
subset
of
the
thousand
something
tests
against
these
criteria
and
and
start
start
seeing
if
wait
here.
Basically,
a
proof
of
concept
for
the
whole
process
can.
C
B
That,
but
but
that's,
but
the
thing
that
that
seemed
to
help
with
this
is
that
we're
going
to
find
that
I
suspect
three,
two
or
three
of
these
criteria
are
not
useful
and
that
these
are
three
things.
We
missed
two
or
three
things,
and
it
lowers
everybody's
blood
pressure
if
they
realize
that
that's
the
expectation.
C
D
D
C
A
A
C
F
E
G
D
G
D
D
B
B
D
D
B
Of
the
plan
we
have
going
with
Lauren
to
promote
this,
so
we
will
definitely
do
that.
I
think
that
the
pedal
is
really
going
to
hit
the
metal.
Don't
think
that's
the
right
analogy
when
we
start
in
the
immediate
next
step,
which
is
we
start
actually
taking
tests
and
applying
the
criteria,
and
then
people
are
going
to
start
looking
through
capabilities
that
they
think
are
important
and
being
whether
or
not
they
score
it.
B
B
B
I,
go
back,
I
gotta
get
a
new
book,
a
sports
analogy,
all
right,
so
awesome
so
for
next,
what
I
would
suggest
is
we
put
on
a
two-week
cadence
for
these
meetings
stay
on
it
but
I
guess?
What,
since
we
have
consensus
of
this
I
want
to
review
the
next
steps
we've
got,
but
the
cadence
of
the
meeting
is
going
to
determine
that
is
too
weak,
cadence
the
right
cadence
so
go
back
to.
D
C
C
A
first
pass
on
identifying
capabilities
based
on
the
test
lists,
so
I
think
we're
gonna
I
would
suggest
for
the
next
two
weeks,
let's
get
really
active
on
the
mailing
list
and
just
try
and
post
an
update
every
couple
of
days
on
on
we're
already
with
these
various
activities,
but
I
think
the
next
major
piece
of
work
is
to
do
a
first
pass
on
applying
criteria
to
test
the
criteria
and
I
think
we
have
two
actions
to
finish
before
we
can
do
that.
One
is
the
capabilities
identification.
B
C
B
F
B
C
B
F
B
Okay,
so
we're
going
to
everybody's
going
to
get
homework
I
the
only
reason
I
would
schedule.
Another
meeting
would
be
to
have
a
deadline,
because
I
think
we
need
to
have
these
the
capabilities
as
the
first
pass.
Screening
all
need
to
be
in
the
next
two
weeks.
If
we're
going
to
stay
on
schedule
and
so
right.
G
B
H
H
H
C
C
You
so
there
may
be
a
couple
of
these
like
like
criteria.
Six
should
reflect
future
technical
direction.
It's
going
to
be
hard
for
us
to
score.
That
I
mean
it
may
be
that
you
know
Monty
and
we
can
rely
on
Monty
and
Nicholas
bar,
say
and
other
folks
that
are
on
both
the
TC
mark,
mcloughlin,
sorry,
that
are
on
both
the
TC
and
the
board
to
help.
But
most
of
us
would
be
stretching
to
feel
like
we
understand
what
future
technical
direction
from
the
TC
should
look
like.