►
From YouTube: Kubernetes SIG Service Catalog 20171106
Description
- 0.1.0 release retrospective
- Begin 0.2.0 prioritization
A
All
right
welcome
everybody
to
the
Monday
November
6
2017
meeting
of
kubernetes
6
Service
Catalog.
The
first
thing
on
our
agenda
for
today
is
retrospective
on
the
process
of
getting
to
1.0
and
Erin
I.
Think
you're
gonna
objectively
facilitate
that
right,
yeah!
Ok!
So
you
had
you
have
like
a
Trello
board.
You
are
going
to
use
for
that
right.
Yeah.
B
B
B
One
is
this:
one
is
fairly
simple:
it's
probably
familiar
if
you've
done
retros
before
we're
gonna,
take
five
minutes
to
focus
on
the
what
went
well
column,
put
in
up
to
three
cards
per
person.
You
can
create
a
card
by
clicking
the
add
new
card
link
there
once
everyone
has
created
their
cards
and
we're
the
five
minutes
are
up,
then
we're
gonna
go
in
and
vote
on
them
so
that
we
can
order
them
once
we're
done
with
voting,
then
we'll
move
on
do
the
same
thing
for
the.
B
E
A
B
B
B
A
B
A
B
F
B
B
B
All
right
we're
at
14
after
the
hour.
It's
about
six
minutes,
we've
done
under
what
went
well
so
I'd
like
to
go
through
these.
Give
the
author
of
them
a
chance
to
explain
any
further
if
they
want
to
so
starting
with
face
to
faces
were
awesome.
Whoever
wrote
that
do
you
need
to,
or
want
to
explain
anything
more
in
that
column,
excuse
yeah.
D
So
that
was
me
just
to
add
to
it
a
little.
Obviously,
I
thought
they
went
really
well.
I
love,
I
love
the
face
to
face.
We
had
cuz,
everyone
we've
had
I
think
has
always
been
really
really
productive
walked
out
of
there
feeling
accomplished
a
lot
and
I
hope
if
we
can
do
more
in
the
future,
but
I
just
thought
they
were
great
cool.
D
A
A
So
I
think
that
they
worked
very
well
at
what
they
were,
but
I
I
not
necessarily
say
that
they
were
an
efficient
way
to
do
it.
I
think
they
were
necessary,
I
I'm,
not
sure
if
this
sounds
like
a
criticism
of
them
instead
of
an
endorsement
I
guess
to
tease
it
apart,
just
to
make
sure
that
everybody
knows
what's
in
my
head
is
like
on
a
one-by-one
basis.
B
H
That
the
meetings
themselves
were
well
rain,
I
think
it
was
I
think
we
were
able
to
go
and
come
into
the
meeting
Sweden's
enough.
Prep
work,
the
noble
that
we
were
talking
about
and
then
it
wanders
blast
through
them
I'm,
not
necessarily
saying
that
we
always
were
able
to
go
ahead
and
get
the
peace
and
escape
discussions
result,
but
it
on
a
daily
basis
at
some
level,
but
I
mean
the
way.
These
random
meetings
were
very
efficient.
B
A
So
like
at
one
point
earlier
in
the
project,
there
were
times
when
it
like
the
merge
velocity
was
like
fairly
low
and
we
eventually
got
to
the
point
where
I
could
not
keep
up
reviewing
every
single
issue
every
in
pull
requests
every
single
day,
just
due
to
the
amount
of
stuff
that
we
were
putting
in.
And
if
you
look
at
like
the
last
several
codex
releases,
they
started
getting
really
big
like
20
polls
in
them,
and
we
started
doing
them
like
every
three
or
four
days.
Sometimes
so.
The
velocity
really
increased.
B
H
Once
alrighty
yeah,
no
no
I'm,
sorry
I
was
looking
for
the
unmute
button.
I
think
it
was
really
good
to
go
ahead
and
and
start
getting
user
feedback
because
some
of
the
design
discussions
like,
for
example,
the
naming
I,
think
it
was
good
to
go
and
get
some
feedback
from
that
saying.
That's
a
terrible
idea
so
be
very
beautiful.
Have
you
get
some
users
to
go
and
say
what
what
is
good
and
what
isn't
good
and
then
it's
hard
sometimes
when
you
just
designing
things
in
vacuum,
so
getting
getting
user
feedback
was
very
helpful.
B
C
A
B
A
So
that
I
did
that
one
and
you
might,
if
you're,
counting
you
you've
realized
that
I
put
more
cards
or
more
things
on
this
list
and
I
was
supposed
to.
But
history
will
vindicate
me
because
I
felt
more
things
than
I
could
limit
myself
to
three.
So
I
was
referring
to
that
like
when
Aaron
started,
doing
like
the
I
called
it
the
the
secretary
role,
not
in
the
sense
of
like
executive
assistant,
but
like
the
the
person
that
executed
the
meeting
agenda
and
like
the
rules
for
how
we
do
the
meetings.
A
I
thought
that
was
really
effective
at
getting
the
keeping
things
on
track
and
avoiding
raffling,
and
that's
something
that
really
helped
to
to
to
get
us
into
a
more
productive
mode
of
interaction.
So
I
thought
that
was
something
that
worked
very
well
a
after
after
we
kind
of
got
over
the
hump
and
learned
just
to
like
internalize
that
methodology
of
having
meetings
it's
kind
of
like
there
have
been
some
meetings
where
we
stuck
to
it
very
closely
and
other
meetings
that
were
looser
but
overall
I
think
it
pushed
the
group
in
the
right
direction.
A
B
D
So
that
was
mine
just
wanted
to
say
that
I'm
happy
to
see
all
the
influx
of
new
people
were
getting.
There
were
definitely
times
when
it
felt
like
we
were
slowing
down
a
little
and
people
were
getting
pulled
off
in
other
directions.
Doing
other
things,
I'm
very
good
with
that
myself
in
the
Keating
I
keep
getting
pulled
off
other
activities,
so
I'm
not
as
active
as
I'd
like
to
be
but
I'm
I'm.
B
B
E
E
D
E
B
Alright
larious,
so
now
that
we've
got
all
these
pretty
well
explained,
we
are
not
going
to
merge
them.
It
sounds
like
they
all
have
their
little
sort
of
differences
here,
I'd
like
to
leave
those
as
separate
what
we
are
gonna
vote,
so
the
way
that
voting
is
gonna
work.
Obviously
this
is
not
as
effective
for
voting
as
Trello
would
have
been
or
something
else.
What
we're
gonna
do
is.
Please
put
your
plus-one
in
its
own
row.
Don't
combine
rows,
don't
do
plus
two
or
anything
like
that.
B
B
B
D
D
B
A
D
B
D
B
E
B
B
F
B
B
B
B
It
looks
like
everyone
has
voted.
Has
anybody
not
voted
that
wants
to
vote?
Please
speak
up
now
or
put
a
plus
hand
in
the
chat
going
once
all
righty
now
to
count
I'm
gonna
put
the
totals
in
column.
B
looks
like
we've
got
two
total
votes
for
face
two
faces:
we're
awesome:
three:
total
votes
for
predefined
agenda,
one
total
vote
for
design
meetings,
help
to
establish
complex
topic
or
establish
consensus.
Use
me
three
total
for
design
discussions
on
daily
basis,
one
total
for
our
pace.
B
One
total
for
user
feedback,
two
total
weekly
and
daily
design
calls
with
productive
nothing
for
meeting
history.
Nothing
for
code
reviews
well
on
for
face
to
faces
were
helpful,
one
for
despite
everyone
being
remote,
three
for
meeting
secretary
three
for
the
new
plus
hand,
format
and
zero
for
flurry
of
new
people.
B
That
okay,
so
we've
got
three
tied
for
first
we've
got
row
three
predefined
agenda
before
each
meeting
helps
focus
our
discussions.
I'm
gonna,
bold,
those
meeting
secretary
role
was
useful,
also
tied
for
first
and
the
new
plus
hand.
Format
also
typed
looks
like
the
thing.
Those
are
like.
The
same
thing
right
looks
like
we
also
have
designed
discussions
on
a
daily
basis,
we're
quite
efficient.
We've
got
four
that
are
tied
for
first
Paul
to
your
point,
row
13
and
row:
14
are
pretty
similar.
C
B
Right
I
came
up
with
it,
so
why
don't
I
very
briefly,
describe
it
to
you
Scott
in
front
of
everyone,
so
that
people
can
correct
me
if
their
interpretation
was
wrong
if
they're,
if
their
interpretation
of
it
is
different
than
mine,
not
wrong.
Pardon
me.
So
what
we
do
is
a
speaker
queue.
We've
done
this
for
a
couple
months
or
so
in
our
design
meetings.
B
Generally
speaking,
the
person
who
someone
will
write
something
down
in
our
agenda
when
we
first
started
this
I
was
the
sort
of
meeting
secretary
other
meeting
secretaries
have
stepped
in
as
well.
The
meeting
secretary
will
introduce
the
topic
will
give
time
for
the
person
who
wrote
it
down
to
explain
it
in
discussion,
then
we'll
start
and
the
way
that
the
discussion
works
is
generally
the
person.
If
someone
wants
to
say
something,
respond
to
a
question,
make
a
comment
so
forth.
D
B
Good
yeah,
so
I
am
going
to
keep
those
separate
it
didn't
sound
like
we
had
any
objection
to
keeping
these
separately.
We
also
have
design
discussions
on
a
daily
basis,
we're
quite
efficient
and
predefined
agenda
before
each
meeting
to
help
focus
our
discussions.
It
sounds
to
me,
like
those
are
significantly
different,
or
at
least
different
enough
to
keep
separate.
Does
anybody
disagree
with
that
statement.
B
Go
months
all
right,
so
we've
got
these
four.
These
are
very
strong
indicators
to
keep
doing
these
things
since
we've
got
four
tied
for
first
place.
Generally
speaking,
probably
not
a
good
idea
to
go
to
second
place,
because
this
is
a
lot
of
things
to
consider.
Does
anybody
have
a
second-place
item
that
they
want
to
call
out.
B
A
B
A
Just
going
to
briefly
say
that
I
think
that
we
should
consider
all
consider
what
we
think
the
priorities
for
new
features
and
other
changes
in
2.0
should
be
and
that
we
should
come
to
the
face-to-face
in
November
in
Raleigh,
with
B
being
prepared
to
talk
about
those
and
also
know
the
capacity
of
our
own
organizations
to
staff
the
ones
that
we
think
are
important.
That's
pretty
much
what
I
wanted
to
say.
That's
all.
B
All
right
sorry
I
was
I
was
just
writing
down
the
top
three
top
four
things,
so
we
are
now
gonna
go
over
to
what
could
have
been
better.
Thank
you
to
Doug
for
calling
that
out.
I
apologize
for
forgetting
that
we're
gonna
do
the
same
thing.
We're
gonna
take
about
five
minutes
for
everyone
to
write
in
up
to
three
items.
They
think
could
have
been
better
and
then
we're
gonna
go.
Do
the
same
kind
of
voting
process.
So
please
go
ahead
and
write
in
your
items
that
you
think
could
have
been
better.
B
B
D
D
D
D
B
B
F
F
B
A
Yeah
so
I
added
that
one.
So
here's
here's
the
counterpoint
to
the
fact
that,
like
the
design
meetings
did
they
definitely
helped
us
to
work
together
as
a
group
in
to
get
over
the
hump
on
some
things.
The
downside
is
that
they're
really
expensive
so
like,
for
example,
we
have
in
this
meeting
right
now.
A
As
far
as
I
can
tell,
we
have
10
people,
so
that
means
that
this
meeting
costs
10
person
hours
and,
if
you
think
about
having
one
of
those
four
times
a
week,
that
means
we're
spending
40
person
hours
a
week
at
some
point
in
this
group
on
design
meetings
and
that
doesn't
even
count
like
the
count,
the
prep
time
and
then
the
follow-up
time
for
action
items.
So
I
don't
know
I'm
not
trying
to
cast
a
like
blanket
indictment
over
them,
like
I,
said
before
I
think
they
were
very
effective
I.
A
Don't
always
think
that
they're
an
efficient
way
to
do
work
and
for
me
personally
I
think
that
probably
we
should
try
to
be
judicious
in
the
future
about
what
we
think
actually
requires.
One
of
those
meetings
I
think
that
that
probably
that
should
be
easy
to
do
since
we've
we've
gotten
a
lot
of
the
the
broad
strokes
in
and
I.
Don't
see
there
being
like
a
lot
of
things
that
are
going
to
affect.
A
C
A
Once
sorry,
that
was
me,
so
what
I
mean
by
that
is
like
there
were
certain
of
the
things
that
we
had
to
get
consensus
on.
That
like
took
an
incredible
amount
of
time,
because
we
didn't
there
isn't
nowhere.
Yet
that
really
tells
the
story
of
what
the
kubernetes
design
doctrine
in
is
when
I
say
doctrine
just
to
level
set
on
what
that
means,
like
in
military
academies,
when
they
teach
like
battle
doctrine,
doctrine
is
not
a
set
of
hard
rules.
It's
a
way
to
think
about
how
to
do
things.
A
So,
like
design
doctrine
refers
to
thinking
the
kubernetes
way
and
I
think
that
that
is
not.
That
is
something
that's
like
not
an
issue
with
this
group.
It's
something
that
I
think
that
we
should
try
to
fix,
because
we've
uncovered
a
lot
of
things
in
the
process
of
doing
this
work,
but
especially
when
we
started
out
there
was
there
like.
A
E
B
A
That
was
my
last
one,
the
what
I
was
referring
to
is
like.
We
had
a
very
effective
face
to
face
in
Seattle,
where
we
kind
of
like
got
the
broad
strokes
painted
on
the
wall
for
like
what
five
or
six
different
design
issues
were
going
to
be
resolved,
as
we
still
wound
up
having
to
have
like
a
lot
of
design
conversation
after
that
that
it
makes
me
it
does
make
me
wonder:
should
we
have
done
something
differently
in
the
face
to
face
to
narrow
the
parameters
of
what
still
had
to
be
discussed?
A
Should
we
have
reserved
more
time
to
get
into
detail
in
the
face
to
face
so
that
we
could
have
produced
like
specifics,
for
the
API
changes
that
we
were
going
to
make
it
just
it
didn't
feel
to
me
like,
like
it
was
a
very
effective
meeting,
but
then
we
did
have
to
have
like
a
substantial
amount
of
discussion
and
re
discussion
on
the
design.
So
that's
it
all.
B
B
G
So
I
feel
like
the
the
month
and
a
half
or
so
before
we
had
initially
set
our
beta
release
at
the
end
of
September.
We
weren't
doing
a
great
job
of
assigning
tasks
and
making
like
planning
things
or
planning
things
so
that
we
would
be
able
to
hit
our
beta
timeline,
and
so
it
was
about
two
weeks
before
the
beta
when
we
really
started
to
ramp
up
everything.
G
G
B
B
H
F
H
H
B
H
I
just
felt
like
sometimes
there
was
some
code
that
that
was
not
necessarily
listed
as
a
requirement
for
like
the
beta
or
something
like
that,
but
then
there
was
a
need
for
it
to
get
kind
of
shoved
in
a
hurry
sometimes,
and
some
other
things
were
kind
of
left
out
like
well.
You
know
if
we
will
push
this
back
later
and
the
criteria
wasn't
always
clear.
H
D
Other
than
it
that's
related
to
the
previous
one
that
has
now
vanished
of
mine,
the
the
beta
testing
I'll
add
that
one
back
in,
but
it's
related
to
that
I
would
have
had
preferred
to
have
more
time
to
do
testing
because
we're
so
date.
During
that
time,
I
didn't
feel
like
we
had
time
to
do
that.
Okay,
Doug,
had
we
covered
yours
that
just
disappeared.
Yeah
was
the
interrupt
testing
god
with
the
system,
brokers,
okay,.
B
All
right
I
will
delete
rows,
16
and
17.
Then,
okay,
we
have
five
minutes
left.
I
would
like
to
ask
people
to
start
the
vote,
but
we
will
not
review
the
votes
until
next
meeting
because
we'll
need
that
time
to
go
over
what
we
can
do
to
improve.
So
please
everyone
start
the
votes
now
and
I
will
hopefully
be
able
to
get
to
summing
them
up
by
the
end
of
this
meeting.
B
B
B
B
B
B
D
B
B
Okay,
so
we've
got
a
first,
it
looks
like
we've
got
a
first
and
a
tie
for
second
number.
The
first
place
is
controller
code
is
very
long
with
a
bunch
of
O's
tied
for
second
looks
like
a
three-way
tie.
Some
code
got
in
very
fast
I'm
gonna,
italicize,
that
more
interrupts
testing
before
beta,
also
italicized
as
tied
for
second
and
focus
on
code
quality
and
testability.