►
From YouTube: DefCore Community Call 2014 09 11
Description
15 minute DefCore Review
45 minute Designated Sections Discussion
A
Hello,
everybody
and
welcome
to
our
second
of
our
community
meetings
on
deathcore
for
September.
The
purpose
this
meeting
is
to
drill
into
the
designated
sections
discussion,
but
we
can
certainly
be
a
little
bit
broader.
The
agenda
is
to
spend
15
minutes
going
through
deaf
course
status
in
history.
I'm,
sorry,
I'll
be
sort
of
in
lecture
mode,
because
I'm
trying
to
give
us
the
background
really
quickly,
but
we'll
stop
at
the
end
of
that.
A
Take
questions
and
discussions
as
necessary
and
then
spend
the
remainder
of
the
time
and
I
do
want
to
keep
us
as
much
as
possible
to
the
strict
our
boundary
talking
about
the
topic
at
hand,
which
is
designated
sections
I'll,
explain
how
all
those
things
fit
together,
but
our
goal
is
not
to
necessarily
reopen
questions
for
deaf
corn
process.
We
certainly
can,
if
there's
a
need,
but
to
focus
in
on
the
specific
question
that's
being
asked,
which
is
about
designated
sections
and
I'll,
explain
how
all
that
fits
together
in
the
next
couple
minutes.
B
A
C
A
Def
core
is
a
subcommittee
of
the
board
whose
purpose
is
to
define
what
constitutes
the
commercial
core
for
OpenStack
use
of
the
trademark.
We
do
that
by
defining
capabilities.
Capable
is
your
broad
group,
the
functionalities
within
within
the
projects
designated
code,
which
is
required
code?
That's
that
needs
to
be
included
by
vendors,
to
use
the
OpenStack
trademark,
and
then
those
are
bundled
together
effectively
as
a
set
of
must
pass
tests.
A
So
we
use
the
capabilities
to
inform
which
tests
a
vendor
must
their
products
must
pass
before
they
can
use
the
OpenStack
trademark
and
we
use
Tempest.
We
could
be
broader
today
we're
using
tempest
as
the
benchmark,
so
it's
community
resource
driven
to
define
the
tests
and
the
capabilities,
and
the
overall
goal
is
interoperability
based
on
a
set
of
minimum
standards.
So
when
people
look
at
core
it's,
the
goal
has
been
and
is
consistently
driven
from
the
board's
perspective,
as
the
smallest
set
that
we
can
have
and
then
expand
it
to
be
larger.
A
And
it's
important
to
note.
There's
a
whole
bunch
of
details
with
this
I've
written
the
effect
of
a
book
through
a
whole
series
of
blog
posts
and
I'll
I'll
point
out
a
couple
of
those
where
we
talk
about
the
balance
and
stability
and
features
and
innovation.
But
it's
important
to
understand
the
integrated
release,
which
is
managed
by
the
TC
and
bringing
new
projects
in
through
an
incubation
process
into
that
that
integrated
release
core
is
a
subset
of
those.
A
The
thing
that
trips
people
up
sometimes,
though,
is
when
we
talk
about
deaf
core
we're
talking
about
commercial
use,
not
talking
about
the
technical
decisions
and
the
integrated
releases
or
those
are
the
body
of
code.
We
are
really
talking
about
how
OpenStack
brand
is
used
by
vendors
and
improved
way.
A
This
started
from
it's
been
a
long
long
running
process.
We've
been
working
on
this
for
well
for
two
years
in
Hong
Kong,
the
board
approved
these
guiding
principles.
The
guiding
principles
wark
walk
through
a
couple
of
major
topics:
the
starting
from
the
we're
first
working
on
a
definition
in
cord
that
applies
to
all
uses
of
OpenStack
public
private
banana
factories,
whatever
whoever
wants
use
OpenStack
we're
defining
core.
A
The
next
section
of
the
these
principles
are
that
we
have
a
set
of
required
code,
so
the
core
process
is
intended
to
not
be
an
API
only
specification,
but
be
a
code
plus
api
specification,
so
that
there's-
and
this
is
really
what
drives
today's
conversation.
This
concept
of
designated
code
projects
are
expected
to
have
a
reference.
Implementation
and
vendors
can
substitute
that
reference
implementation
with
other
components.
So
we
have
sort
of
these
required
pieces
that
are
designated,
so
we
call
designated
and
then
allowable
substitutions
from
that.
A
We
had
to
have
a
way
to
pick
which
capabilities
were
considered
required
in
core
or
not.
We
did
that
using
a
principles-based
approach,
so
we
defined
12
principles,
we'd
actually
defined
more,
and
we
settled
down
to
these
12.
This
12
break
into
four
major
buckets
about
usage,
technical
direction,
playing
well
with
others
and
taking
a
system
view
so
right
now
we
balance
all
all
12
criteria
against
in
these
four
major
categories.
We
we
have
scored.
A
A
The
Havana
information
will
effectively
be
used
to
bootstrap
the
ice
house
process
and
the
Geneva
process,
and
we
have
a
one
of
these
documents
here.
It
is.
We
have
a
deaf
core
process
document
that
shows
how
we
expect
this
to
go
on
a
release
by
release
cycle.
So
you
start
with
the
last
release
and
then
feed
it
into
the
into
the
system.
I
could
spend
a
whole
hours
just
talking
about
this
process
chart.
The
short
answer
of
it
is
is
that
there
will
be
a
capabilities
file.
A
There
already
is
one:
that's
in
Jason
we're
working
on
a
designated
sections,
Jason
file,
both
of
which
go
under
Garrett
reviews,
so
we
can
collect
community
feedback
and
those,
ultimately,
through
that
process,
end
up
being
voted
on
by
the
board
as
a
accepted
artifact
and
then
the
yellow
indicates
community
input,
we're
very
working,
we're
very
focused
on
getting
data-driven
input,
input
and
there's
a
project
called
restack
designed
to
collect
tempest
results
and
compare
them.
We're
actually
right
now,
at
this
community
input
phase,
where
we're
trying
to
get
community
feedback
about
the
designated
sections.
A
For
this
we've
also
been
getting
community
feedback
about
core
capabilities.
Those
things
are,
those
things
are
now
moving
towards
board
approval.
Next
Thursday,
the
board
has
already
acted
on
these
capabilities,
and
so
what
you'll
see
is
the
ones
in
green,
75
and
above
were
identified
as
Havana
core
capabilities.
A
significant
number
of
them.
A
A
A
normal
part
of
the
process,
so
what
our
experience
has
been
is
that,
while
we're
talking
about
principles
and
guidance
and
criteria,
they're
very
fuzzy
actually
presenting
people
with
a
list
of
capabilities
that
are
in
or
not
in
really
crystallizes
the
discussion,
so
that
people
understand
the
impacts,
and
then
we
use
the
principles
to
make
sure
that
when
we
have
issues
or
contention
which
or
an
open
community,
of
course,
we
do
that.
We
have
a
way
to
go
back
to
our
principles
and
guide
those.
A
A
A
D
A
Not
all
the
capabilities
of
a
project
but
a
subset
based
on
the
criteria
and
then
within
an
individual
project.
There
are
components
that
are
designated
or
not
designated
to
varying
degrees.
It's
also
possible
for
projects
to
have
no
required
capabilities,
no
core
capabilities,
and
in
those
cases
the
designated
sections
is
still
desirable
to
have
them
because
they
tell
vendors
what
where
to
upstream
and
what
parts
of
the
code
are
stable
and
long-term
long-term
maintained
and
where
they
can
make
alterations
and
substitutions.
A
However,
if
you
don't
have
a
required
capability,
there's
really
no
point
in
having
there's
no
there's
no
enforcement
for
designated
section.
So
if,
for
example,
Keystone
a
very
pertinent
example
had
no
tests
in
Havana
a
keystone
version
too,
because
there
were
no
tests,
there
were
no
required
capabilities
for
it.
Capabilities
are
only
derived
from
tests,
since
there
are
no
capabilities.
A
Designated
sections
in
Keystone
well
useful,
wouldn't
be
enforced
because
Keystone
itself
is
not
a
required
capability
for
Havana
I
know.
That
seems
a
little
silly.
Keystone
is
required
because
you
can't
operate
OpenStack
without
Keystone,
but
we
can't
test
whether
somebody
is
implemented
it
or
not.
Without
the
tests
to
select
road,
so
it
this
is
part
of
priming
the
pump
and
actually
making
all
this
stuff
work.
Def
core
is
not
building
tests,
we're
not
a
technical
body.
A
I
am
certain:
I
miss
something:
Oh
designated
sections,
okay,
so
the
topic
for
the
day
is
is
selection
of
designated
sections
for
that
code
and
there's.
This
has
been
going
on
for
quite
some
time.
I
used
the
analogy
of
your
baby's
ugly
to
help
Kristen
help
I
don't
want
to
resort
crystallized,
but
to
help
people
understand
what
we're
trying
to
do.
You
know
it
goes
back
to
the
joke.
All
babies
are
ugly
and
really
deaf.
Cora's
goal
is
not
to
pick
important
code
or
not
important
code.
A
Technical
decisions
would
be
made
about
whether
code
should
be
designated
or
not,
and
this
is
incredibly
logical
right
as
things
that
actually
drive
the
rests
or
common
implementations
or
cross-platform
operations
and
things
that
aren't
designated
are
things
that
are
vendor-specific
being
deprecated.
It's
if
it's
designed
to
be
replaceable
like
the
Nova
scheduler
or
if
it's
an
API
extension,
all
pretty
straightforward.
A
The
first
one
is
that
code
is
not
designated
by
default,
so
when
new
code
shows
up
in
the
project
it
is
not
designated
goes
back
to
the
babies.
If
code
is
going
to
be
designated,
it
becomes
a
decision,
a
positive
decision
that
we
make
that
helps
people
be
aware
of
change,
and
it
promotes
this
concept
of
small
core
designated
by
consensus
is
one
that
we've
been
having
discussions
about
since
we're
not
in
a
position
to
make
a
technical
decision.
A
We
have
to
be
able
to
listen
to
a
variety
of
voices
and
see
what's
going
on
by
and
large
components
of
code
that
everybody
agrees
should
be
designated.
They
just
agree
that
it
should
be
designated
where
there's
discussion
and
contention.
The
Deaf
course
process
says
we'll
listen
to
that
contention
for
a
while,
but
if
it
doesn't
resolve
itself,
we
have
to
make
a
decision.
Our
decision
is
not
designating
the
code
because
there's
there's
disagreement
once
again:
we're
not
making
a
decision
for
life,
we're
making
a
decision
on
a
per
release
basis.
A
So
actions
in
today's
discussion
are
really
limited
to
Havana,
and
it's
very
likely
it's
actually
exciting
to
watch
the
project's,
mature
and
change.
An
additional
code
could
be
designated
or
in
some
cases
less
so
it
could
be
designated
depending
on
on
how
time
progresses,
and
we
have
the
benefit
of
a
time
machine
in
this
case,
because
we
have
two
releases
effectively
done
after
the
Havana
state
and
then
the
final
is
that
it
designated
as
guidance
we're
not
trying
to
designate
we're,
not
creating
a
code
police
state.
A
It's
an
Apache
License
project
people
actually
have
a
lot
of
freedom
with
it.
Vendors
have
a
lot
of
freedom
with
the
project.
Our
goal
is
to
encourage
up
streaming
and
to
provide
information
right.
We
want
OpenStack
to
be
interoperable.
We
want
people
to
use
OpenStack
code,
but
we
don't
want
to
say
you
have
to
include
this
module
in
this
library
and
this
python
class
in
order
to
be
considered
OpenStack
we're
trying
to
make
the
guidance
much
more
rational
from
use
perspective
and
not
not
try
and
put
microscopes
into
everybody's
development
labs.
A
A
C
C
A
All
right
so
with
that
I'm
going
to
dive
in
to
the
designated
sections
and
what
we
did
yesterday,
that
I
think
proved
effective
was
we
went
in
the
reverse
order
that
we
tried
to
do
with
the
TC
when
we
discussed
it
before,
and
we
started
with
sort
of
the
less
contentious
discussions.
Then
we
moved
forward
from
there,
so
I'll
try
and
stick
to
this
order,
pretty
much
and
I'm
right
now,
I'm
going
from
these
very
straightforward,
simple
statements,
we
sort
of
wanted
to
make
it
easy
to
digest.
A
We
didn't
want
people
to
have
to
dive
into
the
details.
However,
there
has
been
a
considerable
amount
of
details,
as
files
in
variations
has
been
building
for
almost
a
year
since
we
started
it
and
so
for
Neutron
Havana
Neutron
there
were,
there
are
currently
no
designated
sections
in
part.
Neutron
is
not
part,
of
course.
Oh,
it
doesn't
take
much
discussion
on
it.
This
is
one
of
those
places
where
I
would
love
to
see
us
document
what
those
designated
sections
are
so
that
they
can
be
part
of
the
community.
A
The
community
discussion,
even
if
they're,
not
sorry
that
document
with
the
sections
are
and
potentially
even
identify,
designated
sections,
even
if
it's
not
an
enforceable
piece,
I
think
it
helps
us
prime,
the
pump
for
the
discussion,
one
of
things
that
we
spend
a
lot
of
time
discuss
in
conversation
about
last
night
in
the
1st
rendition
of
this
meeting,
was
building
that
documentation.
So
the
technical
justification
of
why
this
is
a
section
and
if
it
should
be
included
or
not
can
be,
can
be
had
we're
still
working
through
getting
this
into
Garrett.
A
Keystone
has
no
required
capabilities,
because
the
v2
was
the
only
API
that
was
mature
enough
for
us
to
to
classify
and
there
were
no
tests,
and
from
that
perspective
we
haven't
built
designated
sections
for
it.
I
would
love
to
see
some
designated
sections.
I
also
know
that,
even
if
it
had
required
capabilities,
we
would
be
challenged
to
make
keys,
don't
have
designated
code
because
there
are
existing
OpenStack
implementations
that
major
ones
that
don't
use
Keystone
and
there's
a
significant
community
consensus
that
Havana
Keystone
is
not
suitable
for
certain
scale
deployments.
A
The
concerns
about
the
implementation,
I
believe
those
are
being
addressed
in
in
the
host
Havana
releases,
and
so
we
will
certainly
be
revisiting
this
as
we
go
as
I
know
that
tests
are
showing
up
for
Keystone
so
that
we
can
do
that.
We
can
include
tests
in
the
next
iteration
now
pause
for
conversation
or
discussion.
A
So
you
know
this
is
one
of
the
one
of
the
challenges
to
me
with
this
process,
especially
bootstrapping.
It
is
getting
the
information
in
place
and
getting
tests
in
place
where
there
were
it.
We
certainly
didn't
have
a
chance
to
tell
people
before
Havana
anyway,
you
need
to
write
tests
or
their
your
code
can't
be
considered
part
of
the
core
definition.
A
Whether
you
want
that
or
not
is
a
different
discussion
and
so
I
think
we've
been
giving
the
message
very
consistently,
since
Hong
Kong
certainly
was
heard
in
Atlanta
tet
tests
and
writing
tests
become
a
core
commercial
metric
and
I
can't
think
of
a
better
message
drove
its
tech
than
that.
Frankly,
all
right
cinder
is
the
next
in
cinder.
A
The
designated
section
here
is
that
the
API
implementation
code
is
designated
so
in
this
case
there's
a
fair
number
of
intended
replaceable
sections
there's
a
API
layer
that
is
pretty
clearly
understood
to
be
the
API
layer
and
a
required
component
once
again.
I
know
that
there
was
significant
enhancements
and
cinder
in
ice
house
in
Juneau
and
will
continue
to
revisit
this
in
a
few
as
we
go
in
the
future.
A
A
I
Nova
Nova
is
an
interesting
case
in
this
one
because
we
ultimately
took
the
opposite
approach
from
the
other
projects
in
Nova.
The
position
is
that
all
of
the
code
is
designated
with
exceptions.
This
is
closer
to
when
we
were
originally
engaging
with
the
TC.
The
TC
was
was
more
in
line
with
all
code
except
and
we
kept
that
designation
with
Nova.
We
felt
like
that
was
appropriate
because
they
were
very
clearly
not
designated
section.
A
I
would
be
interested
at
some
point
to
see
and
compare
some
of
the
concepts
that
Shawn's
been
promoting
against
this,
because
I
know
that
there's
interesting
a
bit
of
overlap
and
how
these,
how
these
are
concepts,
are
working
in
it.
It's
nice
to
actually
see
some
some
community
consensus
around
this,
even
if
the
approaches
are
slightly
different,
alright,
so
that
that
takes
us
through
all
of
the
sections
except
for
Swift
I
would
pause
because,
once
usually
Swift
turns
into
a
larger
conversation,
it
ends
up
being
the
contentious
one
which
we've
always
known.
A
Okay,
it's
important
because
if
you
know
obviously
we
respect
is
going
to
dig
up
some
questions
and
it
leads
people
back
to
some
of
the
principles
that
we've
we've
been
discussing
so
far,
I
feel
like
in
everything
else.
People
have
accepted
that
the
principles
and
way
we've
applied
them
have
created
reasonable
results.
So
Swift
a
little
bit
trickier.
A
The
ultimate
position
the
Deaf
Corps
has
taken
for
swift
is
that
in
Havana
there
is
not
a
community
consensus
over
how
much
of
the
code
should
be
designated.
There
are
multiple
vendors
and
parties
who
felt
that
they
could
use
the
Swift
api's
and
pass
the
compatibility
tests.
However,
they
didn't
want
to
use
the
implementation
of
Swift
as
it
was
in
Havana
to
provide
those
capabilities
and
for
that
room
we
have
multiple
parties
speak
up
about
that.
A
We've
also
had
parties
on
the
on
the
other
side,
specifically
the
Swift
PTL,
say
no
I
think
it's
100
briam
hundred
percent.
You
need
to
have
these
pieces
in
because
of
that
level
of
disagreement
about
the
implementation.
Are
we
fall
back
to
our
principles
and
say
we
can't
make
a
technical
decision
about
this?
It
would
not
be
a
designated.
All
of
Swift
would
not
be
a
designated
section.
A
So
in
conversation
yesterday
we
had
a
request
and
think
it's
perfectly
reasonable
for
additional
clarity
on
what
the
sections
are.
John
Dickinson
is
provided
sections
for
us
to
discuss,
so
we
actually
have
some
basis
to
go
through
and
discuss
that,
and
then
we
haven't
yet
gone
back
through
to
the
people
who
felt
that
Swift.
Doesn't
it.
D
A
A
C
A
That's
12,
individual
people
expect
I,
don't
really
have
an
opinion
on
this.
I've
listened
to
a
lot
of
people
and
I,
hear
I,
hear
the
discussion
and
then
I
try
to
remove
myself
from
the
the
technical
and
the
political
and
try
and
go
back
to
what
our
principles
are
for
this
and
so
yeah.
It
is
what
it
is
in
that
sense.
A
I
have
heard
people
say
once
again,
I
am
not
the
technical
expert,
but
the
people
who
said
that
they
had
concerns
about
Swift
Havana
Swift,
with
designated
sections
thought
that
in
Juneau
they
could
actually
use.
There
could
be
designated
sections
around
the
proxy
layer
of
the
object
manager,
the
middleware
pieces,
and
that
those
could
actually
be
that
they
would
happily
include
those
in
their
product
I'm
relaying
that
I'm
not
committing
it.
Obviously,
because
they're,
not
the
person
making
those
technical
claims.
A
There
is
a
there
is
a
component
around
Swift
that
I
would
open
if
we
don't
have
more
discussion
around
the
designated
sections.
Oh,
and
there
is
something
to
show
so
along
those
lines.
I
would
encourage
discussion
not
just
about
Swift
but
around
anything
we're
working.
So
I
have
a
the
designated
sections
jason
file
in
which
this
information,
basically
the
same
information
I
just
presented,
is
encapsulated
in
Jason.
I
actually
did
a
better.
The
mapping
was
better
than
I
was
expecting,
so
we
were
able
to
capture
the
sections
and
now
engage
in
a
dialogue
about.
A
Designated
sections
per
project
in
a
much
more
moderated
way
once
once
this
first
pass
gets
gets
in,
we
will
be
able
to
take
patches
against
it,
and
so
I
would
encourage
people.
This
isn't
the
only
bite
at
the
Apple
by
any
stretch,
the
we're
expecting
board
action
on
this
next
Thursday,
but
once
again
Havana's
advisory.
A
It,
you
know
ice
house
is
going
to
be,
is
going
to
be
the
official
one
we're
using
this
to
prime
the
pump,
and
so
we
should
be
able
to
start
having
conversations
around
ice
house
almost
immediately
would
be
my
expectation
and
start
start
driving
those
things
forward.
So
this
is
this
is
the
file
for
designated
sections.
This
poll
had
a
minor
change
to
the
the
corset
also,
and
here
it
is
clicking
the
wrong
thing
anyway.
This
is
there's
also
adjacent
around
what
the
core
capabilities
are
and
how
those
are,
how
those
are
use.
A
A
And
I
know
from
the
attendance
most
of
the
people
that
have
been
talking
on
the
call
have
already
seen
this
and
heard
it
if
this
is
new
to
you
and
it
makes
sense
or
doesn't
make
sense
please.
This
is
this-
is
the
ideal
time
to
speak
up,
although
we'll
take
comments
into
which
way
you
want
to
give
them
carrier
pigeon
I
have
a
carrier
pigeon
stop
out
front
for
this
exact
situation.
A
A
B
Rob,
this
is
done.
I
think
I
would
feel
a
lot
more
comfortable
with
us,
leaving
Swift
out
from
a
from
a
core
perspective
from
a
desk
or
sort
of
designated
sections
perspective.
If
we.
C
B
A
B
B
You
know
provides
a
different
layer
of
abstraction,
maybe
than
what
people
want,
but
it
is
there,
and
so
if
we
had
some
sections
of
Swift
that
were
not
included,
I
might
be
more
comfortable
with
that
I
do
still
kind
of
feel
like
we
ought
to
be
encouraging
vendors
to
contribute
their
drivers
and
things
so
I'm
not
entirely
comfortable
with
us
saying
that
the
driver
layer
is
the
layer
where
we
want
to
allow
plugins
to
happen
outside
of
our
tree.
But
you
know
realistically
I
think
that's
not
a
thing.
We
can
completely
control
so.
A
You
add
it
you're,
adding
your
there's.
There's
two
there's
two
things
that
I'd
like
to
address
them
separately:
one
is
I,
the
people
who
are
objecting
to
Swift
are
making
technical
objections
and
I'm
we
do
need
to.
We
do
need
to
stage
a
single
topic
discussion
around
that
get
padded
gloves
and
let
that
discussion
happen.
I
do.
D
A
Do
fully
agree
with
you,
so
it
right
I
know
John's
very
passionate
about
this
I
there
there
are
most
swift's
f
is
Swift
and
react
and
slipped
I've
heard
it.
They
do
want
to
be
able
to
use
the
sections
of
that
code.
So
we
just
we
need
to
let
that
discussion
happen.
I
do
agree
with
you.
If,
with
I
actually
strongly
agree
with
your
premise,
which
is
why
I
wanted
to
follow
up
that
it
might
be
that
we
don't
want
required
capabilities
that
don't
have
at
least
some
designated
sections.
A
A
B
Sorry,
that's
the
premise
that
there
are
sections
of
the
code
that
are
not
required
sort
of
implies
that
there's
a
layer
that
is
okay
for
you
to
not
deliver
I
mean
that's
the
whole
notion
right.
It
doesn't
imply
it.
That's
what
that's
saying
and
so
a
natural
point
where
that
comes
up
as
drivers
and
I
would
hate.
For
example,
for
you
know,
big
company
a
to
not
deliver
the
drivers
for
working
with
some
piece
of
equipment
from
big
company,
be
that
if
their
competitor,
if
big
company
a
had
their
own
distribution,
so
I
don't.
A
B
B
I,
that's
a
legitimate
argument
and
I
haven't
completely
come
down
on
the
side
that
you
have
to
deliver
everything,
but
I'm
I'm
more
comfortable,
saying
that
about
drivers,
because
that's
sort
of
a
natural
applauding
point
but
I'm
not
completely
convinced
one
way
or
the
other.
That
is
a
good
idea
now
there's
frozen,
but
it
could.
A
D
A
They
want
the
whole
product
right,
then
they
will
do
that
and
we
have
custom.
We
have
vendors
who
offer
the
integrated
release
as
their
product
and
earth.
Like
you
know,
they
think
this
is
sort
of
silly
it's
just
we
just
ship
all
the
code
and
we
have
vendors
who
offer
much
more
constrained
versions
of
OpenStack
who
don't
want
to
be
forced
to
include
and
I
would
my
preference
would
be
to
let
the
market
choose
winners
and
losers
rather
than
the
board
or
the
technical
committees.
Sure.
B
Yeah,
like
I,
said,
I
see
both
sides
of
that.
What
what
is
more
troubling,
though,
is
the
idea
that
that
would
what's
happening
with
Swift,
where
it
seems
like
we
want
to
say:
we'd
have
to
provide
object,
storage,
but
you
can
provide
any
old
object
storage
as
long
as
it
talks,
codes,
API
and
that's
a
level,
so
I
was
trying
to
get
it.
B
You
know
there
are
some
levels
where
I'm
really
not
comfortable,
and
there
are
some
levels
where
I
just
think
it's
fundamentally
wrong
to
make
a
division
there
and
I
think
that
is
one
of
the
levels.
If
there's
zero
code,
then
that
should
imply
that
that
capability
is
not
required,
because
we
don't
deliver
API
specifications,
all
right,
we're
actually
pretty
bad
at
specifying.
What
are
at
the
ice
are
so
I'm,
not
sure
that
we
want
to
start
making
claims
or
asserting
things
based
on
those
definition.
I.
A
A
B
C
C
So
inward
I
don't
think
that
we
really
hit
those
people
up
effectively
yet,
and
we
should
probably
not
probably
I
think
we
should
do
it
as
soon
as
possible,
because
I
think
we're
ready
now
so
I,
don't
know.
If
you
remember,
Rob,
I
was
part
of
our
discussion
around
the
line
management
stuff,
and
you
know
the
hidden
fluence
was
I
brought
the
idea
of
copying
what
we've
done
with
operators
group.
You
know
that
which
is
effectively
a
subcommittee
subgroup
of
the
user
committee
and
creating
14
line
management
and
products.
C
People
I
think
we
should
do
that
now
and
have.
This
is
the
first
topic,
because
this
is
I
talk
to
a
few
people
at
VMware
and
they
had
no
clue
this
is
going
on
and
they
were
like
freaked
their
eyes.
That
thing,
though,
and
they're
the
ones
that
are
really
going
to
be
a
you
know,
I
mean
this
is
their
job
to
a
certain
extent
right.
It's
a
large
part.
The
carrying
that
OpenStack
brand
is
going
to
be
really
critical
for
them.
C
A
A
C
A
C
Just
I
mean
we
threw
you
know
your
contacts,
Rob
in
mine
and
few
others
I'm
sure
we
could
pull
together,
probably
20
people
from
different
companies.
That
would
fit
this
kind
of
fill
and
just
do
exactly
what
we're
doing
today,
you're
doing
today,
I'm
listening
and
just
tell
them
what
the
heck's
going
on
and
how
we
think
it
affects
them
and
you
know
started
listing
their
feedback
for
how
horrible
how
awesome
this
is.
A
D
A
Meetings
but
they're
they're,
they're
they're
supposed
to
be
going
through
and
and
explaining
the
coming
change
personally.
I
think
that
until
we've
the
board
has
said
this
is
what
Havana
will
look
like
everybody's
just
sort
of
snoozing
through
it
not
not
to
worry
once
it
once
we
actually
have
an
artifact.
You
know
like
dog
like
this,
is
literally
what's
been
happening
right,
you
have
an
artifact
in
people,
say:
hey.
D
A
D
D
Just
going
to
say
that,
with
what
I'm
hearing
this
morning
that
it's
going
to
be
critical
to
really
advertise
and
have
a
session
in
the
trademarks,
legal,
whatever
part
of
the
summit
that
goes
into
this
sort
of
detail
and
let
everybody
and
I
think
we
like
Rob,
said
we
really
need
to
have
the
Havana
artifact
defined
and
approved
by
the
board
I
hate
to
say
whether
they're
right
or
wrong.
But
until
it's
got
the
board
approval.
D
And
then
we
go
to
the
summit
and
socialize
it
amongst
those
marketing
and
other
people
who
are
on
the
money
side
of
these
companies.
We
we
won't
be
able
to
actually
get
the
decisions
for
what
what
we
need
to
do
for
ice
house
and
going
forward.
So
it's
going
to
be
critical
that
there's
a
summit
session
for
exactly
those
sections
that
was
John,
saying
that
will
don't
know
about
to
get
all
of
the
Deaf
course
stuff
out
there
and
socialize
amongst
those
folks.
D
C
Much
like
the
operator
scrip,
it's
really
critical
to
have
those
public
meetings
at
the
summit,
but
I
think
very
similar
to
the
operators
group.
There's
a
subset
of
the
people
that
show
up
the
operators
but
mid-cycle
summits
that
we
fell
to
now.
There's
a
small
subset
of
the
people
actually
go
to
the
summit
from
those
groups.
So
so
we
just
I
think
we
need
to
do
all
these
things.
They're
all.
C
That
have
already
been
convinced
to
already
know.
What's
going
on,
mostly,
there
are
movies
to
keep
showing
up
but
they're
a
very
small
percentage
of
the
actual
number
of
people
that
really
need
to
be
involved.
So
I
think
we
just
need
to
aggressively
do
outreach
and
find
dig
into
the
companies
and
DM
where
an
HP
and
all
the
rat,
so
every
everyone
and
try
to
pull
those
people
out
there
that
they
well.
The
way
that
I
was
thinking
of
it
is
the
good
analogy
is
when
we're
doing
stuff
on
the
board.
C
It's
much
like
making
a
law
in
Congress,
united
states
federal
Congress
and
where
we
think
we're
doing
it
with
all
the
right
information
and-
and
we've
done
our
due
diligence.
We've
debated
it
for
months
and
we
come
up
with
a
lot
and
then
the
law
goes
out
there
and
it
gets
a
little
bit
more
debated
mostly
on
the
political
talk
shows,
but
when
it
really
gets
home
and
when
people
really
find
out
and
understand,
the
law
is
when
it
goes
into
effect,
and
people
start
coming
on
either
side
of
that
law.
Net
I.
C
A
C
A
That
is
one
of
the
reasons
why
I
don't
want
us
to
not
have
the
the
harder
conversations
right
I
mean,
I
think
the
this
whole
discussion
around
Swift
has
been
an
important
test
and
gotten
people's
attention
about
what
we're
doing.
You
know.
I
think
that
we're
getting
to
a
consensus
point
where
swift,
api's
shouldn't
be
part
of
core
it
sort
of
addresses.
Doug,
I
I,
agree
with
your
point.
A
I
think
it
addresses
your
point,
although
it
also
just
has
people
you
know
so,
I
don't
have
to
worry
about
it,
but
now
and
they
don't
actually
have
the
discussion
that
you're
really
driving,
which
is
around
specification
of
the
api's
and
API
versus
implementation,
and
things
like
that
that
are
really
important
conversations
to
have
and
so
I
you
know,
I
we've
been.
We
were
successful
in
some
cases,
John
to
your
point
that
the
controversies
create
awareness
I,
certainly
don't
want
a
manufactured
controversy.
I
think
that's
horrible.
A
D
You
know
I
would
love
to
actually
see
a
panel,
whether
it's
at
the
summit
or
elsewhere,
but
recorded
of
some
of
these
folks.
It's
that
Sean
is
talking
about
the
product
managers,
the
VPS
and
whatnot.
A
panel
discussing
the
core
and
the
whole
concept
of
API
specifications
versus
API
code
and
and
other
code
are.
D
A
B
D
A
A
B
B
That's
no
surprise,
but
I
think
the
middle
there's
someplace
in
the
middle
that
will
make
enough
people
happy,
and
I
think
that
the
real
thing
that
we
need
to
be
careful
of
is
making
sure
that
the
actual
project
contributors
are
having
their
voice
heard,
and
it
sounds
like
that's
happening
so
that
that
is
also
good.
For
me.