►
From YouTube: Kubernetes SIG Service Catalog 20161128
Description
SIG service-catalog meets to discuss next steps after the code drop to the incubator repo.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
A
We,
the
folks
from
google,
sent
an
email
out
before
thanksgiving
soliciting
opinions
about
how
books
belt
with
the
with
the
code
drop
from
google,
and
I
see
that
there
is
a
response
from
the
dais
guys.
That
makes
me
think
that
we
should
will
probably
spend
a
significant
amount
of
time
discussing
this
today.
I
think
it
would
be
helpful
if,
before
we
get
into
specifics
about
where
to
go
from
here,
that
we
first
look
at
the
we
looking.
A
We
talked
about
perhaps
like
where
communication
broke
down
around
this
and
let's
talk
about
what
happened
and
how
we
can
prevent
a
communication,
this
mass
mismatches
in
the
future
of
this
type
and
then
talk
about
where
we
go
from
here,
so
to
frame
to
frame
this
further.
There
was
a
here's,
my
version
of
the
backstory
in
seattle.
A
On
the
monday,
before
cube
con,
we
had
a
rather
loosely
defined
agreement
that
google
would
cede
the
incubator
repo
with
a
portion
of
the
code
for
their
prototype,
and
that
is
what
was
demoed
at
the
the
last
week's
meeting.
So
I
had
a
I
had
the
gut
feeling
after
that,
perhaps
there
was
some
mismatch
on
expectations
and
I.
Think
that
is
product
to
discuss.
First,
I'm
sure
that
a
number
of
folks
on
this
meeting
have
opinions
on
it.
B
Well,
I
can
I
can
certainly
jump
in
this?
Is
Martin
and
sort
of
provide
a
little?
You
know
what
our
view
was
of
what
we
were
doing,
and
so
on
one
hand
you
know,
seeding
sort
of
the
basic
service
catalog
code
was
was
our
main
goal.
One
of
the
things
we
did
was
and
and
and
I
believe
we
talked
about
in
Seattle-
is
that
we
felt
it
was
really
useful
for
anybody
to
be
able
to
have
something
that
they
could
play
with
it.
B
B
You
know
the
actual
brokers
themselves,
whether
those
you
know,
those
don't
need
to
be
part
of
the
core
repo
I
think
that
over
time,
various
people
will
create
brokers.
You're,
not
sure
that
you
know
the
helm.
Your
dais
folks
will
will
create
you
know
their
own
helm,
based
broker
and
and
maybe
have
some
of
the
features
that
they
had
and
steward
and
I.
Think
that
that's
great,
you
know
we'll
probably
quite
brokers
for
ourselves
and
for
you
know,
things
for
Google
cloud
platform
and
and
I
think
that's
the
whole
point
of
the
the
extensibility
model.
A
Not
not
one
of
you
know,
X
or
Y
person
is
a
bad
person
because
they
did
a
thing
so
I
I
think
everybody
can
agree
to
that.
If
anybody
does
think
that
could
drop
in
any
way,
it
means
someone
is
bad,
do
speak
up
now,
but
otherwise,
let's,
let's
all
agree,
and
it
might
be
helpful
if
we
can
all
affirm
our
agreement
to
this
in
the
chat
via
some
other
way,
that
this
is
just
a
bad
clearing
in
this
match
and
we're
still
bffs.
I
see
I
see
people
nodding,
I,
see
Jason,
not
english,.
A
D
A
Did
not
most
mostly
there
was
a
there
was
a
demo
and
some
thoughts
from
the
google
folks
on
next
steps,
I
and
a
discussion
about
governance
for
future
polls
and
by
the
way
this
is
jogged.
My
memory
that
I
will
contribute
to
the
discussion
that
I
think
I.
Think
part
of
any
mismatch
that
may
have
happened.
I
probably
stems
from
the
fact
that
we
agree
to
a
could
drop
without
defining
governance
or
defining
expectations
specifically
around
how
we
were
going
to
carry
that
out
so
from
for
those
that
weren't
there.
A
So
I
think
that
the
mismatch
and
expectation
was
what
does
merge
mean
and
when
does
something
get
merged,
which
I
guess
is
a
finer
point
on
the
broader
notion
of
governance
for
this
ruthless
specifically,
so
I
don't.
I
don't
think
we
were
necessarily
taken
surprise
that,
taken
by
surprise
that
coat
showed
up,
because
that
was
discussed.
I
think
it
was
the
11-minute
merge
to
master
that
I
think
was
a
little
bit
surprising,
yeah
point
taken
and
I
will
agree.
I
was
personally
surprised
by
the
by
be
11
minute
latency
between
post
and
merge.
A
A
E
So
Martin
gun
home
spoke
about
sort
of
the
motivation
why
we
included
some
additional
code,
like
implementations
of
the
brokers
and
I
would
like
to
address
why
we
chose
the
means
by
which
the
code
landed
actually
recall
from
the
Monday
discussion,
suggesting
that
perhaps
splitting
the
code
or
building
it
in
in
terms
of
several
PRS
is
an
option.
But
the
group
gave
me
feedback
in
my
mind
kind
of
unambiguous
that
it
would
take
too
long
to
build
the
understanding
and
build
enough
of
the
body
of
code
for
it
to
be
useful.
E
E
Also
bring
in
so
that
it
actually
played
with
so
the
goal,
but
the
hope
that
we
would
we
would
do
this
in
multiples
here.
Prs
was,
I
would
say,
rejected
or
turn
down
by
the
group,
which
is
why
we
opted
for
the
one
PR
approach
with
the
additional
pieces
again
with
the
goal
to
make
everybody
in
the
group
quickly
exposed
to
the
code
and
be
able
to
identify
and
and
the
deltas
from
the
design
agreements
and
start
contributing
in
whichever
way
they
felt
appropriate.
I.
A
A
Feel
is
that
they
have
some
degree
of
input
as
things
go
in
and
those
are
two
two
factors
that
are
like
have
different
the
gravity
of
those
two
things
points
in
different
directions.
So
one
of
the
challenges
and
situations
like
this,
especially
you
know
when
we're
all
geographically
spread
out
and
a
face-to-face
meeting-
is
not
something
that
can
like
easily
be
done
spur
the
moment
is:
how
do
we?
How
do
we
have
find
some
degree
of
compromise
between
those
two
factors
on
so
that
we
end
in
a
situation
where
we
we
have?
A
The
is
those
both
satisfied
and
we
can
move
forward
without
like
accumulating
baggage
as
a
group
from
the
way
that
could
drop
was
done
and
I
I
do
wonder
you
know
at
some
point
we
we
should
close
out
the
what
happened
and
move
on
to
the
what
to
do,
but
at
the
risk
of
backpedaling
a
little
bit
I
wonder.
Does
anybody
feel
like
there
is
a
part
of
like
any
communication
mismatch
that
happen
around
this,
which
hasn't
been
explored
in
the
sig?
Already
in
this
sig
meeting?
Have
we
covered
everything
my.
D
A
C
Think
because
our
focus
has
been
pretty
exclusively
on
communicating
with
brokers
over
the
cloud
foundry
service
broker,
API
I
think
the
collective
understanding
was
that
there
should
be
plenty
of
brokers
that
already
exist
in
the
wild
that
one
of
these
that
this
controller
implementation
should
work
with
so
I'm
kind
of
thinking
that
the
inclusion
of
the
workers
may
have
defied
some
of
the
expectations.
Some
of
us
had
ok.
A
I
think
that's
fair,
but
can
I
will
mention
that
I
think
that
has
been
addressed
already
that
just
like
existing
example,
brokers,
aside,
I,
think
the
motivation
and
like
belay
either
Martin
feel
free
to
jump
in
if
I
don't
have
this
correct.
But
I
think
the
motivation
was
to
provide
something.
That's
like
that
was
in
cluded
in
the
code
drop
that
you
could
use
easily
yeah.
F
Maybe
he
just
felt
like:
can
we
go
see
me
anybody
I?
Guess
you
know
great
so
yeah.
So
that
was
really
the
intent.
Was
there
that
we
didn't
just
want
to
drop
a
bunch
of
code
and
then
have
people
have
the
go
in
and
sign
up
for
something
like
SendGrid
and
to
go
ahead
and
provision
account
there
or
whatever
else.
It
is.
F
There's
very
few
places
where
you
can
just
going
point
and
grab
a
service
program
say:
hey
look
it's
working,
so
we
felt
like
that
God
was
are
useful
inclusion,
so
the
be
cooling
get
started
with
batteries
included,
and
the
second
point
was
the
the
second
brokered
user
provided
service.
I
am
fairly
certain.
That
was
something
that
we
had
agreed
on,
providing
a
echo
service
that
would
allow
a
user
to
go
ahead
and
bring
in
existing
services
so
that
it
wouldn't
be
the
you
have
to
use
this
service
catalog
and
you
could
not.
F
A
A
Am
hearing
I'm
hearing
no
unaired
portions
of
miscommunication
I
do
think
that
it
will
be
productive
if
we
take
notes
on
the
dimensions
of
the
disagreement
just
for
posterity
they're,
not
disagreement,
but
communication
communication
mismatches,
so
I'm
opening
the
the
notes-
and
let
me
actually
share
my
screen
and
that
way
we
can.
We
can
all
tell
Paul
if
he's
got
something
wrong
before
he
goes
and
remembers
it
the
wrong
way
so
dimensions.
Can
everybody
see
my
browser.
A
G
That
is
a
legitimate
question
to
the
group,
something
we
may
just
be
covering
today
and
that's
fine
is
how
to
proceed
with
development.
So
we
had
suggested
in
the
thread
on
google
groups
that
we
start
filing
github
issues.
I
know
there's
some
other
PRS
out
there
that
amend,
what's
currently
in
master
just
to
bring
the
directory
structure
kind
of
more
in
line
with
what
Cooper
these
main
does.
So
it's
a
little
unclear
how
to
proceed.
I'm
like
it.
Let
me
pay
today
discussion,
though
so.
A
I'll,
add
that
that
what
is
the
follow
our?
What
is
the
process
going
forward,
so
I
think
that
I
think
that
I,
unless
I
missed
something
please
speak
up
if
I
have
that
probably
covers
the
the
dimensions
of
mismatch,
and
if
everybody
agrees
that
that
is
accurately
accounting
for
mismatch,
let's
move
on
to
what
should
we
do
moving
forward
from
this
point?
Is
everybody
cool
with
that.
A
A
H
A
A
A
Said
so,
if
we're
going
to
transition
into,
how
would
we
like
to
move
forward
on
this
subject
in
terms
of
agreeing
on
a
resolution
to
the
the
like
communication,
mismatches
that
have
occurred
with
the
seed
code
I
would
like?
If,
if
someone
has
an
opinion
I,
it
I
just
want
to
get
a
show
of
hands,
and
then
I
will
pick
somebody
at
random
to
begin
talking.
E
A
G
Sure
I'll
keep.
My
short,
I
think,
probably
my
least
controversial
opinion
is
to
start
creating
github
issues
and
assign
them
milestones.
Github
milestones
to
move
us
closer
to,
let's
call
it
an
alpha.
2
will
give
them,
maybe
the
seed
repo,
an
alpha
one
milestone,
so
that
we
know
how
to
proceed
concurrently
with
small,
focused
PRS,
and
that
will
answer
my
current
lee
biggest
question,
which
is
simply
what
is
the
work
that
I
should
do?
Basically,
okay,.
A
So
Aaron
does
that.
Does
that
I'm
hearing
something
different
that
was
in
then
what
was
from
in
I
am
hearing
a
different
thing
now
than
what
was
in
the
email
and
what
I'm
hearing
now
make
sure
I've
understood
you
correctly
that
you're
proposing
that
instead
of
the
revert
and
resubmission
of
smaller
PRS
that
you're
saying
now,
you
would
be
ok
with
let's
get
issues
described
and
attribute
them
to
milestones
in
github.
Is
that
accurate.
G
A
G
B
Alright,
so
you
know
I
mean,
as
I
said,
it
was
never
an
intent
to
sort
of
say
that
brokers
that
we
seated
really
needed
to
be
or
should
be
part
of
the
core
capability
of
the
catalog.
And
so
you
know,
one
proposal
would
be
that
we
just
back
those
out
completely
and,
as
I
said
earlier,
that
that
should
bring
the
code
lines
of
code
down
about
2500,
I,
think
and
if
that
makes
people
more
comfortable
and
that
it's
not
part
of
the
main
repo
I
think
that
that
would
be
a
benefit
for
the
community.
B
To
sort
of
you
know
just
yank
those
out
and
we
can
put
those
somewhere
else
so
that
people
can
separately
build
them
and
install
them,
and
you
know
still
play
with
the
system
will
have
to.
Obviously
you
know
create
more
steps
in
the
how-to
guide
of
how
to
get
a
system
up
and
running,
but
I
think
that
that's
probably
the
right
thing
to
do.
I
don't
know
if
other
people
feel
that
that
would
you
know
help.
But
you
know
that's.
B
Certainly,
you
know
again
from
our
perspective
is
really
just:
let's
just
try
to
get
the
fewest
number
of
steps,
so
somebody
can
get
something
running
on
their
machine
right
and
actually
tried
it
anyway,
because
we've
had
to
struggle
internally
to
where
we
talk
to
other
team
to
google
and
they're
like
well.
You
know
how
do
I
get
there
running
or
like
well
need
to
make
it
really
simple.
So
are.
E
A
A
H
Yeah
I
was
just
going
to
say
that
I'm
not
in
favor
of
removing
all
sample
brokers,
because
I
do
think
we
should
have
something
there.
That
runs.
To
be
honest,
I
haven't
taken
a
look
at
what's
in
there
right
now.
If
what's
in
there
right
now
is
too
complicated,
then
I'm,
probably
fine,
with
three
points
in
time.
H
A
A
Had
it
like
had
instructions
for
how
to
use
that
example
broker
image.
Until
we
got
to
the
point
where
we
felt
as
a
group,
there
should
be
something
that
goes
into
the
git,
repo
and
I.
Think
Morgan's
point
a
highway
of
question
is:
is
it's
a
good
one
to
acknowledge
that,
probably
eventually
we
will
need
to
at
least
have
a
mock
broker
in
the
repo
on
that
I?
Is
that
lives
with
the
code
that
we're
testing
and
the
integration
test
or
an
end
test
code
itself?
C
A
So
I
think
I
think
that
leaves
us
with
a
few
ways.
We
can
go
on
the
brokers.
We
could
move
the
broker
implementations
at
wholesale.
We
could
have
somebody
publish
an
image.
We
can
move
them
to
a
contributory
where
we
could
perhaps
have
an
a
gentle
person's
agreement
that
the
broker
code
that
exists
now
is
like
temporarily
just
for
demo
purposes
and
I
will
also
call
out
I.
Think
that
will
find
if,
if
this
hadn't
come
up
now,
I
think
we
would
find
like
that.
A
It
would
have
come
up
naturally
that
at
some
point
we're
going
to
have
a
lot
of
folks
that
are
interested
in
writing
brokers
and
we
I
would
prefer
not
to
have
to
tell
them
I
tell
somebody
that
was
interested
in
doing
that
and
they
had
to
start
from
scratch.
So
I
do
think
it's
possible
that
a
natural
work
product
of
this
group,
whether
it's
in
the
Service
Catalog,
repo
or
in
another
incubator,
repo
order
to
Nettie's,
is
like
a
library
that
you
can
use
to
get
to
like
a
web
server.
That
knows
how
to
speak.
A
The
broker
protocol
that
you
can
vendor
in
and
add
your
implementation
of
various
strategies
to
but
I,
don't
think
that's
something
that
we
should
shoot
for
immediately.
I
I
think
we
should
decide
an
expedient
way
to
to
agree
as
a
group
on
what
to
do,
but
we
will
probably
naturally
come
back
to
this.
So,
let's
see
shall
we
number
these
things
and
and
take
a
vote?
Does
anybody
want
to
do
something
different,
or
can
we
just
enumerate
a
number
of
them?
I
think.
A
E
For
completeness,
it
may
be
worth
stating
that
the
brokers
are
in
their
own
directory,
but
they
are
not
in
director.
That's
is
clearly
outside
of
the
core
system
they're
there
in
the
brokers
directory.
There
is
also
examples
directory
already,
which
contains
some
of
the
some
of
the
services
that
the
brokers
do
spin
up.
So
that's
one
option:
the
contrib
seems
like
another
option
that
was
proposed
so.
C
A
In
Coober
Nettie's
in
the
cooper
Nettie's
repo,
the
contributory
is
basically
what
is
what
is
the
analog
of
what
can't
just
described,
which
is
it's
it's
a
directory
that
the
has
far
fewer
far
lower
bar
for
what
goes
in.
We
did
eventually
move
or
take,
contribute
and
turn
it
into
a
separate
repo,
but
I
think
that
a
contribs
would
be
would
be
what
I
would
propose,
as
just
a
immediate
step,
to
take
in
fitting
with
the
the
interest
that
we
had
in
moving
that
stuff
around.
So
let's,
let's
refine.
A
A
E
Question
sure
that
apply
to
the
echo
broker,
which
we
call
user
mode
on
broker,
because
that
one
is
kinda
going
to
be
core
contribution
that
we
did
have
a
list
on
the
list
of
agreements.
Clearly,
the
commodities
broker
that
we
have
out.
There
is
more
of
an
example,
but
the
other
one
she
seems
like
more
core.
So.
G
So
one
thing
I
just
wanted
to
get
on.
The
notes
may
be
obvious
to
some
adding
some
documentation
at
the
high
level,
contribs
lash
brokers,
directory.
That
explains
why
they're
there
and
then
also
at
least,
has
a
pointer
back
to
some
docs
on
how
to
use
them
as
part
of
your,
let's
call
it
integration,
testing
or
just
figuring
out
the
world
of
Service
Catalog
if
you're
new
to
it.
Okay,.
A
I
think
that
is,
that
is
a
good
suggestion
and
I'd
like
to
handle
at
separately
from
the
initial
agreement.
We
have
on
the
move,
if
that's
okay,
Erin,
ok,
so
I'm
going
to
change
this
line,
that
I'm
editing
now
to
group
voted
on
and
adopted,
move
the
brokers.
So
what
I'm
going
to
do
now
is
I'm
going
to
make
an
issue
for
that
and
I
would
like
a
volunteer
to
to
take
that
I
will
assign
the
issue
to
you.
A
A
A
E
A
A
A
We
have
about
ten
minutes
left
and
I.
Don't
think
that
we
have
finished,
we
I
don't
think
that
we've
finished
talking
about.
Where
do
we
go
from
here,
but
I
would
like
to
call
out
that
I
think
my
read
of
the
virtual
room
that
we're
in
is
that
oh
I
think
most
of
us
are
interested
in
making
more
expedient
progress
on
all
service.
A
In
addition
to,
let's
also
try
to
our,
let's
also
say
as
a
group
that
if
people
want
to
make
progress
more
quickly,
that
we
can
use
the
mailing
list
to
bring
things
up
and
if
you're
interested
in
service
catalog-
and
you
have
opinions
that
you
want
to
make
known
that
you'll
check
the
list
so
that
we
can
make
more
expedient
progress.
I
realized
that
is
a
big
topic
to
get
into
and
so
I
wonder.
A
I
would
would
folks
be
averse
to
meeting
tomorrow,
in
the
same
time,
slot
to
continue
any
remaining
conversation
that
we
haven't
touched
on
here
and
by
the
way
also
talked
about
the
numerous
remaining
design
details
that
we
need
to
work
out
as
the
as
a
group,
both
on
the
high
level
of
how
does
the
API
work
and
then
also.
How
are
we
going
to
implement
the
API
that
we've
discussed
any
thoughts
on
that?
If.
G
A
A
F
So
I
have
two
thoughts
on
that.
Thanks
for
offering
do
that,
one
of
them
is,
it
would
be
great
to
go
and
be
able
to
share
that
sooner
and
have
a
type
agenda
or
tighter
agenda,
rather
than
your
own
discussion
and
second
of
all,
I.
Despite
the
slight
communication
breakdown
of
the
last
face-to-face
meetings,
I
found
the
design
discussions
with
the
whiteboard
be
extremely
useful,
so
I
just
want
to
throw
up
if
there's
any
appetite
for
doing
any
more
of
those.
As
a
group,
I.
A
You
know,
with
the
exception
of
the
the
communication
mismatches
that
we
had
about
the
code
drop,
we're
totally
awesome
at
establishing
consensus
and
I
think
there's
a
number
of
things
that
we
we
need
to
explore
in
that
way.
For
example,
we
got
really
as
far
as
add
a
broker
making
instance
bind
to
it,
but
we
really
haven't
talked
about
unbind
Indy
provision
yet,
and
we,
it
is
in
our
best
interest
to
talk
about
that
sooner
rather
than
later,
because
I
think
that
has
a
big
effect
on
how
we,
how
we
look
at.
G
G
So
my
feeling
is
that
we
have
a
very
good
foundation
from
the
boulder
and
what
I
understand
happened
at
the
Seattle
face
to
face.
Is
that,
given
a
longer
zoom
meeting,
probably
with
a
lot
more
screen
sharing,
we
can
make
pretty
good
progress.
If,
like
veal
I
said,
we
have
a
really
tightly
scope,
focused
I'm,
getting
a
lot
of
echo
I,
don't
sound
good
on
soup.
If
we
have
a
really
tightly
focused
agenda
for
the
day
for
the
two
hour
or
whatever
length,
zoom,
a
repeat,
yeah.
A
So,
in
the
event
that
we
had
a
zoom
that
was
longer
than
60
minutes,
I
I
think
that
a
prerequisite
for
scheduling
such
a
thing
would
be
a
very
tightly
focused
agenda
I.
Personally,
I
am
not
a
fan
of
meetings
longer
than
30
minutes
without
tight
attendez.
So
you
will
have
no
disagreement
from
me
on
that.
You.
A
Ok,
so
we're
approaching
the
time
limit
for
now,
I
I
don't
want
to
get
into
additional
discussions,
but
I'm
not
hearing
a
strong
disagreement
for
four
o'clock:
Eastern
Time
one
o'clock
pacific
time
tomorrow.
Let's
continue
this.
Let's,
let's
round
out
the
rest
of
the
discussion
about
next
steps
and
I
will
bring
optimistically
bring
a
single
design
thing
that
I
would
like
to
talk
about
tomorrow,
which
will
be
unbind,
and
we
can.