►
From YouTube: DefCore Lighthouse.2 2014 06 04
Description
https://etherpad.openstack.org/p/DefCoreLighthouse.2
## Summary (by Rob Hirschfeld)
We covered the primary items in the agenda (matrix scoring, designated sections process, face to face agenda, bylaws meeting prep). We had some very productive discussions around scoring of capabilities that will be continued in the face to face meeting.
We resolve the following items about designated sections:
Michael as rep for TC to ask PTLs to define designated sections
We will encourage using "free text" to define sections for now
Designated Sections are ratified by TC (+1) from PTLs proposal (patches submitted)
TC Chair (+2) on final
If a project has no core capabilities then vendors are not required to include a designated section of that project.
A
A
A
So,
just
as
a
note,
we
we
actually
did
made
some
progress
on
the
matrix
score.
John,
Griffis
and
I
sat
down
after
the
TC
meeting.
Oh
the
one
before
last
that
the
one
before
last
and
completed
all
of
the
cinder
scores
and,
as
you
might
expect
most
of
those
ended
up
scoring
in
the
is
core
category,
but
a
lot
of
them
redmond
and
so
only
I
think
with
there's
only
one
real
change
that
came
out
of
that,
and
that
leaves
the
boy
I.
Don't
know
where
the
link
is.
A
A
Yeah
so
I
there
already
sorted
in.
So
that
means
that
we
have
these
things,
that
we
don't
know
what
they
are
the
treasure.
If
it
needs
to
help
us
figure
out
what
they
are
mark
and
Troy
we're
going
to
talk
about
that,
and
then
we
have
the
objects,
store
items
to
resolve,
and
that's
that
I
think
is
going
to
come
up
in
our
designated
sections
topic
and
probably
the
face
to
face.
Also
so
I
make
sure
you
get
throw
it
into
the
face
to
face
agenda.
A
A
C
C
A
B
A
C
B
A
B
D
A
Okay,
I
think
that
we're
jumping
ahead
a
little
bit
on
the
agenda,
because
I
think
we're
going
to
need
to
talk
about
the
designated
sections
we
should.
We
should
probably
do
the
agenda
last,
but
I
don't
mind,
jumping
back
and
forth,
so
that
we
can,
as
we
go
at
add
items
to
the
agenda
and
flush
things
out
there.
Okay,
other
comments
about
the
the
matrix
core.
C
I
think
it
seems
like
we
should
be
able
to
finish
it
up.
Right
I
mean
the
object
store
stuff.
We
should
be
able
to
score
regardless
of
the
determinations
on
designated
sections.
I
know
that
John
wasn't
super
happy
with
the
way
the
capabilities
were
described,
but
I
don't
know
that
we
can
do
anything
until
we
resolve
where
the
tests
are
coming
from
I.
A
A
A
E
A
A
A
A
A
A
A
We
have
have
a
bye
laws
change,
because
we're
moving
to
a
process
focused
way
of
doing
the
core
definition
instead
of
project-based,
and
so
we
need
to
define
that
in
the
bylaws,
and
there
had
been
some
discussion
about
what
type
of
governance
controls
there
are
on
the
changes
to
the
process
so
and
that
that
was
sort
of
where
the
rub
was.
The
process
is
basically
what
we've
been
defining
with
the
principles
and
the
criteria.
E
A
B
A
B
B
A
Exactly
and
one
of
the
one
of
the
realizations
we
had
when
we
were
talking
about
this
before
the
summit
was,
we
actually
think
we
have
enough
information
to
write
down
the
process
as
an
appendix
and
let
people
just
be
like.
Oh
ok,
this
is
what
they're
doing
it
makes
sense.
The
bylaws
can
just
say
you
know
much
much
more
general
follows
the.
B
A
C
C
The
the
question-
the
open
question,
then,
is
what
process
or
procedure
is
required
to
change
the
contents
of
the
appendix
that
is
the
process
that
def
core
uses
and
I
mean,
as
a
straw,
man,
a
board
vote
as
an
even
weirder
strawman.
A
board
vote
that
required
a
majority
of
each
class
of
board
member
board
director.
B
C
A
D
B
D
I
was
thinking
we
already
have
that
because
two
or
something
to
get
to
the
to
this
point
in
the
process
has
had
a
ton
of
TC
involvement.
So
I'm
not
I'm,
not
disagreeing
I'm,
just
trying
to
understand
what
was
meant
by
that
statement
because
it
seems
like
we've
are
the
TC
and
the
ppl.
I
have
been
heavily
involved
now.
C
B
B
A
future
change
like
we
change
the
the
board
has
decided
that
the
repository
for
the
information
moved
over
to
XYZ
service.
Even
that
kind
of
change.
We
should
still
bring
in
people
out
of
the
courtesy
of
almost
everything,
sir,
and
it's
kind
of
an
absurd
case
right,
but
I'm
just
making
something
awful
Tom
mater
well.
A
So
I
think
I
think
this
caused
a
lot
of
angst
because
we
didn't,
we
didn't
have
a
process
when
we
started
this
that
we
could
point
to.
But
now
we've
we've
got
principles
and
criteria,
and
we
sort
of
have
a
flow
going
with
dot
with
materials
that
people
can
look
at
an
extent
that
this
is
not
going
to
be
is
anxiety-provoking
as
it
was
when
we
just
did
right
into
making
bylaws
changes.
Yeah.
D
A
A
A
A
C
A
F
A
There's
a
couple
there's
a
couple
of
them:
I'm,
looking
back
through
what
what
happened
is
in
our
in
our
first
meeting
we
had
a
whole
bunch,
I
brought
up
the
lighthouse
1
items
where
we
looked
at
the
event
we
looked
at,
we
looked
at
work
and
we
identified
a
whole
bunch
of
items
that
needed
we
needed
help
with
and
the
first
one
was
one
of
them
is:
how
are
we
going
to
resolve
designated
sections
for
all
core
capabilities?
So
let
me
pull
together
the
questions.
F
A
F
A
E
A
C
C
So
then
back
is
back
to
the
action
which
is
yeah.
We
do
need
the
pts
to
at
least
draft
the
first
pass,
or
at
least
rubber-stamp
what
we
put
forward
is
a
straw,
man
and
say
yeah
that
looks
okay,
I
know
some
of
them.
Did
it
on
that
etherpad,
but
I,
don't
know
that
anyone
was
really
taking
it
seriously.
I
didn't
mean
it
to
be
terribly
serious
when
I
put
it
together.
E
F
F
A
The
one
of
the
reasons
why
I
think
the
blog
post
is
important,
and
some
of
these
other
questions
are
important-
is
they're
going
to
turn
around
to
you
and
say:
how
do
I,
how
how
do
I
deliver
that
to
you
and
I
think
we
we
should
either
we
need
to
put
make
it
as
part
of
the
face
to
face,
or
it's
a
TC.
It's
probably
a
TC
agenda
item
of
how
how
we
actually
want
that
delivered.
F
Yep
FL
and
Hayley
hey.
How
do
we
describe
it
to
vendors?
Is
it
just
freeform
text?
You
know,
you
know
a
paragraph
that
says
Novus
says
you
must
ship
I,
don't
know
every
hypervisor
driver,
picking
no
randoms
for
a
man
or
is
it
more
concrete
and
we
somehow
give
them
something
that
you
know
is
testable
in
an
engineering
manner.
So
we
have
to
work
out
exactly
what
we're
handing
over
to
the
vendors
as
well.
Ok,
it's.
C
B
F
Thought
I
don't
want
to
say
that
that
will
always
be
possible
because
I
haven't
like
we
don't
know
right,
because
we
haven't
seen
what
people
want
to
try
and
do
the
bit
that
concerns
me
is.
Ultimately,
this
is
going
to
end
up
being
something
that
people
will
want
to
hold
vendors
to
right,
and
so
it's
got
to
be
relatively
concrete
or
they
you
know,
I
bad
actor.
Could
weasel
word
around
you
know?
Are
we
defined
scheduler
in
a
slightly
strange
way,
to
avoid
doing
the
thing
or
we're
all
right?
You
see
what
I
mean
yeah.
B
F
C
Can
we
can
we
do
the
thing
that
we
always
do
in
def
core,
which
is
kick
the
ball
down
the
road
and
say,
as
a
first
pass,
for
you
know,
I
saw
/.
You
know
time
frame,
it's
going
to
be
free
form,
text
that
describes
in
reasonably
actionable
terms
the
modules
or
sections
that
we
believe
are
designated
and
then
look
at
it
in
the
next
cycle.
As
far
as
how
can
we
refine
that
and
make
it
more
testable,
I
think.
F
You
know
60
years
solving
a
problem
that
doesn't
actually
exist,
but
even
if
its
pros
I
think
it
has
to
be
relatively
concrete.
So
that's
more
tests
that
you
know
the
desk
or
committee
needs
to
apply
when
we
receive
these
things.
We
might
hypothetically
have
to
go
back
to
someone
and
say
we
need
that
to
be
a
little
bit
more
concrete,
yeah.
B
F
A
I
I
think
josh
is
right,
though.
I
think
that
you
can,
for
the
most
part
we're
going
to
have
its
you're
going
to
be
able
to
say
the
scheduler
Nova
scheduler,
that's
not
designated
we're
done,
or
you
know
it
that
the
people
haven't
into
you
and
understanding
what
these
sections
are
and
the
ones
that
aren't
then
we'll
get
concrete
and
we'll
have
to
does.
It
will
actually
have
to
put
markers
in
the
code,
but
I
think
for
the
most
part,
it's
a
pad.
A
B
A
C
Yeah
I
would
say:
let's,
let's,
let's
really
beg
the
ones
that
we
need
today
and
maybe
just
put
everyone
else
on
notice
that
hey
you
know
as
part
of
the
goal
of
being
in
core.
If
that
is
a
goal,
or
it
goes
along
with
your
project,
you
need
to
kind
of
think
about
designated
sections,
but
I
think
it
can
be
longer
term
I,
I,.
C
A
A
Or
the
the
what
I
was
wondering
is:
if
we
just
say
it's
04
right
now
and
and
Michael,
would
it
make
it
easier?
Give
you
a
stick
to
say:
hey,
look
right
now,
we're
assuming
there
are
no
designated
sections
in
your
code
unless
you
start
telling
us
otherwise,
the
only
problem
is
that
contradicts
what
the
TC
said,
and
so
that's
what
makes
it
more
aggressive
and.
E
A
F
Yeah,
so
basically,
I
think
this
will
probably
happen
in
the
form
of
each
PTL
is
asked
to
propose
a
review
in
garrets
against
the
governance,
repo
and
they'll
go
through
our
lightweight
voting
process.
Now
the
biggest
impacts
of
you
guys
is
that
probably
delays
the
war
by
at
least
a
week
right
because
theory
only
approves
hatches
in
that
repo
at
meetings,
but
it
would,
but
it
gives
us
a
nice
documented.
You
know
the
following:
people:
tick,
the
box
kind
of
process.
A
E
F
A
So
we
said
we're
going
to
we're
going
to
do
friendly,
ask
for
now
let
by
Michael
designated
sections
we've.
Let
leave
this
text,
which
is
good,
we've
decided
who
has
the
right
that
is
deciding
and
we're
saying
we're
focusing
on
core
capabilities
for
Havana.
Oh
there's,
actually
a
decision
in
this
which
is
saying
that
you
don't
need
designated
sections
from
a
from
a
branding
perspective.
We're
saying
you
don't
need
designated
sections
if
you
don't
have
a
core
capability
I've,
actually
like
the
document.
That
is
a
decision.
E
A
C
Think
are
you
doing?
Wow
I
was
talking
about
what
the
PTL
needed
to
work
on.
But
yes,
if
there
is,
there
is
no
Corky
of
abilities.
The
vendors
are
not
required
to
include
anything.
In
other
words,
if
there's
a
project
that
has
designated
sections
but
no
core
capabilities,
the
designated
sections
do
not
apply.
A
Yes
and
that
that's
something
that
is
in
this
in
this
post,
right
it
it's
in
the
bottom,
right,
yeah
and
so
I.
Just
to
me,
this
is,
if
it's
an
obvious
assumption,
but
I
want
it
to
be
explicit,
so
that
nobody,
nobody
is
like.
Oh
we're
designating
all
this
code.
Now
you
have
to
include
designate
in
your
OpenStack
product
eat,
because
it's.
A
A
A
C
F
B
A
A
C
A
A
C
A
I
would
I
would
what
I
would
do
is
I
would
add
I
meant
to
do
this
and
I.
It
I
forgot
to
send
out
the
the
reviews,
so
I'll
send
those
out
so
that
people
can
look
at
look
at
the
reviews
for
the
UI
stuff
that
we're
building
to
track
scores.
Dental
bungee,
if
you're
curious
about
what
those
things
look
like
read
the
reviews
there
we
go
yeah.
A
A
A
A
F
C
A
E
C
B
A
So
this
might
be
a
structural
change,
because
right
right
now,
we
are
making
there's
an
assumption
that
the
tests
inherit
from
that
this
why
I
stopped
Josh
the
core
tests
are
the
things
that
we
had
thought
originally
would
carry
the
score,
not
the
capabilities,
and
so
in
the
future
it
would
be
possible
for
a
test
and
a
capability
to
not
be
core,
but
most
of
the
other
ones,
to
be
core
I'm.
Okay,
if
we
want
to
roll
that.
C
I
think
we
need
to
score
capabilities
forever.
I
do
not
think
we
want
to
get
down
the
road
of
scoring
individual
tests,
even
storing
it
as
a
data
format.
I
think
we'll
go
insane,
but
because
we
do
need
the
scores
to
actually
reflect
meta
things
like.
Are
there
enough
tests
to
represent
that
this
is
stable
and
complete?
We
that's
not
a
that's,
not
a
characteristic
of
the
test.
It's
a
characteristic
of
the
capability
right.
C
Though
you
know,
we
need
a
null
capability
or
I
think
we
need.
You
know
if
there
are
tests
that
represent
a
specific
configuration.
That's
a
separate
capability,
it's
not
part
of
the
same
capability,
and
we
may
find
that
when
we
have
scenarios
where
all
of
the
tests
pass,
except
for
one
that
that
means
the
capabilities
are
set
up
wrong
and
all.
C
A
C
A
B
A
C
C
A
E
C
A
A
If
new
tests
came
into
a
capability,
they
would
come
in
into
that
category
and
then
it
would
be
pretty
easy
to
review
the
few
pests
that
you
might
want
to
promote
inside
the
capability,
because
you
look
at
the
core
capabilities
and
then
you
look
at
the
the
optional
tests
and
that
would
that
would
effectively
let
you
elevate
them.
I.
C
Would
rather
not
have
optional
and
just
say
skipped,
neither
must
pass
or
not
must
pass
I
mean
that's
the
principles
we
voted
on
right.
If
there
must
pass
tests,
we
talk
about
them.
If
it's
not
much
past
test,
it's
a
might
pass
test.
I,
just
don't
care
I,
don't
think
it
should
have
any
influence
on
this
score
for
a
test
that
only
passes
in
some
configurations.
E
C
D
So
so
Josh
mechanic
I
tend
to
agree
with
you
can
I.
Can
I
clarify,
though,
yeah
if
we
had
I
can't
even
think
of
a
case
I'm
just
trying
to
so,
let's
say,
for
example,
with
test
paths.
If
you
have
a
four
megabyte
vm,
but
it
failed.
If
you
have
a
four
gigabyte
vm,
would
we
have
two
different
capabilities
there
or
I'm
some
or
how
would
you
well?
No,
it's
more
likely.
E
C
Use
a
real
case,
live
migration
and
yeah
rather
than
saying
live.
Migration
is
part
of
the
Nova
compute
capability.
We
would
say
it
has
to
be
a
separate
capability
because
it's
known
to
work
in
Zen
and
not
kvm
or
VMware,
not
hyper-v
or
whatever.
It
is
hypervisor
specific,
which
means
it
can't
be
part
of
typical
interrupt
unless,
unless
the
vast
majority
of
deployment
support
it-
and
it
might
be
that
we
want
all
those
tests
in
there,
we
want
to
be
gathering
the
data,
because
there
may
come
a
date
where
every
hypervisor.
C
A
Let's
say
we
took
a
must-pass
test,
Nova
volume
or
none
no
time,
Nova
flavors,
and
that
capability
is
a
core
capability
and
somebody
writes
a
new
test
against
it.
It
that
test
may
or
may
not
be
a
core
test.
We
need
to
actually
say
well,
we
need
to
review
if
this
test
becomes
a
core
part
of
that
capability,
but
it's
clearly
part
of
the
capability.
We
just
don't
know
if
it's
must
pass
or
not.
No
yeah,
no.
C
E
C
E
C
A
A
C
I
agree,
but
I
don't
think
it's
a
case
of
putting
the
testing
and
calling
them
optional.
I
think
it's
a
case
of
having
them
in
a
bucket.
That's
it
was
putting
them
in
and
calling
them
skipped
until
it's
determined
that
there
actually
part
of
that
capability
and
that
their
their
representative
test,
in
other
words,
that
it
is
the
functionality
that's
and
not
the
test.
It's
broken
I
I.
C
D
C
A
E
New
test
would
come
in
at
the
at
the
release
point
so
Icehouse.
The
capability
includes
all
of
these
tests.
Juno
there's
a
larger
set
of
tests
that
must
be
met,
and
so
those
tests
would
be
for
for
each
new
release.
Unfortunately,
well
actually
the
test
should
be.
We
talked
to
QA
about
this.
The
test
should
be
delineated
so
that
they
aren't
special
functions
such
as
then
or
extensions
or
whatnot,
and
as
long
as
the
tests
are
well
segregated,
then
the
new
test
decision
should
be
fairly
straightforward
and
can
be
run
ahead
of
time.
E
C
About
this,
let's
have
a
bucket.
That's
part
of
that
JSON
file.
That's
all
of
the
tests
that
are
not
yet
part
of
capabilities,
and
then,
let's
use
patches,
submitted
against
that
file
to
propose
should
become
part
of
capabilities,
and
that
and
the
the
process
of
accepting
that
patch
should
probably
be
a
bunch
of
vendors,
running
ref
stack
and
seeing
if
that
test
passes
on
the
configurations
they
care
about,
because
if
it
doesn't
they're
about
to
get
flunked
out
of
being
core
certified
and.