►
From YouTube: Kubernetes SIG Service Catalog 20161024
Description
SIG Service Catalog discusses use-cases and requirements in advance of the coming face to face meeting.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
Then
all
right
welcome
everybody
to
be
Monday
october.
Twenty
fourth
meeting
of
six
Service
Catalog
today
I
want
the
discussion
to
be
around
the
remaining
time
before
the
face-to-face
meeting
in
Boulder
next
week
and
how
to
take
best
advantage
of
that
time.
So
let
me
kick
that
discussion
off
by
breaking
down
the
things
that
this
sig
is
going
to
do
in
two
different
swim
lanes.
The
first
one
land
is
like
what
is
the
Service
Catalog
supposed
to
do?
What
are
the
user
stories
and
use
cases
around
it?
A
The
second
is
what
is
the
API
going
to
look
like
and
what
patterns
are
there,
an
upstream
that
are
convenient
to
reuse
appropriate
to
reuse?
What
precedents
are
there
that
we
need
to
adhere
to
and
then
later
on?
What
does
the
API
look
like
and
then
the
third
swim
lane
is:
where
does
this
API
live?
How
does
it?
How
do
you
run
it
as
an
operator
and
how
do
you
federated
with
the
main
API
and
concerns
around
like
more
architecture
of
the
work
product
that
we
eventually
produce?
A
So
I
would
like
to
focus
in
the
remaining
time
before
the
face
to
face
on
the
requirement
swimline
because
it
will
work
best
if,
when
we're
speaking
to
one
another
in
boulder
that
we
all
have
a
shared
vision
for
what
is
this
thing
supposed
to
do?
And
what
is
the
experience
like
as
a
user
I
going
to
be
so
with
that
in
mind,
Seth
I
see
you're
on
the
call
I
wonder
if
you
had
a
talk
for
a
bit
about
the
agenda
that
we
composed
for
the
meeting
next
week.
B
B
So
let
me
let
me
step
back
and
I'll
begin
to
show
some
of
my
age
to
inconsistency
of
jumping
ahead
and
all
over
the
place.
So
Aaron
and
pole
started
with
an
agenda
which
was
like
here
the
the
specifics
of
what
we
want
to
get
done
and
Paul
and
I
talked
about
basically
what
he
just
reviewed.
The
three
swim
types
of
work:
sopo
I'm,
not
really
sure
what
you're
looking
to
get
out
of
me
because
I
feel
like
you,
you
you
to
get
over
and
did
pretty
well
there.
A
I
am
muted,
you
are
correct,
so
mostly
I
was
looking
for
what
we
talked
about
for
deliverables
and
I
can
just
go
through
them.
I
mean
I
think
they
boiled
down
to
I
exit
criteria
for
that
meeting
being,
ideally
that
we
have
a
use
case
document
and
a
user
story
that
articulates
in
non-technical
terms,
what
it's
like
to
use
the
catalog,
what
are
the
things
that
the
catalog
does
and
I?
A
What
integrations
are
we
expecting
with
the
catalog
and
back-end
api's?
So
the
second
swimlane
the
api?
What
does
it
look
like?
We
had
talked
about
I
manufacturing
consensus
on
what
verte,
what
nouns
are
in
the
API
and
what
are
the
relationships
between
them,
so
that
would
be
things
like
I,
presumably
will
have
a
resource
for
a
service
in
the
proposal
from
Deus,
it's
called
service
class.
A
A
A
I'm
reading
a
note
from
the
group
since
nobody's
saying
anything:
if
that's
the
case,
then
I
would
like
to
to
talk
to
use
cases
today
and
user
stories.
I
don't
know
if
anybody
has
seen
this,
but
there
is
a
pull
request
which
I'm
going
to
add
a
link
to
in
the
agenda
document
by
the
way,
I'll
put
a
link
to
the
agenda
document
into
the
chat.
A
So
Jade
from
google
has
added
a
a
pull
request
for
a
user
story
like
an
actual
creative
writing
tied
user
story.
Jays
not
here
so
I.
Don't
think
that
this
is
the
best
time
to
dive
into
that,
but
I
want
to
share
with.
All
of
you.
Excuse
me
so
that
I
that
we
can
all
start
looking
at
this
I'm
going
to
add
a
link
into
the.
A
A
A
We
can
discuss
before
monday
and
next
week,
so
that
we
can
try
to
make
some
progress
in
advance
of
next
week.
I.
What's
what's
the
temperature
of
the
group
with
regard
to
some
additional
meetings
this
week,
not
not
mandatory
but
optional,
and
if,
if
you
agree
to
write
up
a
use
case,
please
come
I
saw
a
thumbs
up
from
Weston
I.
A
A
A
Let's
go
right,
awesome!
Okay!
So
let
me
call
out
before
we
dive
into
this
thing,
that
it's
nowhere
near
complete,
I.
Think
myself
and
Doug
have
been
folks
contributing
to
this.
So
far,
I
want
to
get
some
more
people
from
the
group
involved,
but
with
those
things
in
mind,
let
me
just
dive
into
this
thing.
So
it's
it's
divided
into
two
sections:
there's
a
high-level
use
cases
and
then
there's
a
lower
level.
What
are
the
use
cases
for
integrating
with
the
cloud
foundry
Service
Worker
API?
A
A
The
second
one
is,
as
the
operator
of
an
existing
service
and
Cooper
Nettie's
I
want
to
be
able
to
publish
that
service
via
that
API,
so
that
I
can
participate
in
that
ecosystem.
I
can
share
my
service
across
namespaces
and
namespaces
and
Cooper
Nettie's,
etc,
etc.
Obviously,
this
is
a
very
sparse
list.
Anybody
feel
free
to
call
out
what's
missing
and
we
can
make
a
note
of
that
and
turn
that
into
a
takeaway.
For
somebody
to
write
up
a
use
case.
A
So
my
own
opinion
on
that
subject
is
that
I
think
black
box
is
a
no-brainer
I
think
that
there
are
there's
probably
a
lot
of
interest
around
white
box,
but
I
think
when
we
get
into
white
box,
there's
probably
a
significant
expansion
of
the
scope,
so
I'm
totally
fine
talking
about
white
box
it
one
of
the
challenges
might
be
avoiding
being
too
prescriptive
about
white
box
so
that
we
can
have
white
box
implementations
from
a
variety
of
contributors.
Doug
I
see
that
you
have
raised
your
hand.
Let
me
call
on
you,
oh
yeah,.
D
E
They
call,
let
me
just
ask
you
a
question:
has
this
group
but
I
know
what
happened
last
week
if
we've
shared
with
the
group,
the
some
of
the
progress
has
been
made
in
the
working
group
for
the
service
broker
with
the
cloud
foundry
folks.
Is
that
something
that
you
would
want
to
just
bring
people
up
to
speed
on
or
is
it
too
early.
A
I'm
happy
to
talk
about
it
I,
so
anybody
can
jump
in
who
participates
in
that
working
group
if
they
think
that
I've
missed
anything.
But
basically
the
last
two
working
group
meetings
have
been
around
governance
of
the
API
and
talking
about.
Where
is
the
thing
going
to
live?
I
think
they,
where
we
ended?
The
last
meeting
is
that
there's
going
to
be
a
neutral
github
repository
created,
I
think
the
name
that
they
settled
on
was
open
service
broker.
A
A
E
Yeah,
that's
right.
I
just
wanted
people
to
sort
of
understand
that
this
is
really
you
know
becoming
its
own
standalone
thing,
and-
and
so
it's
not
that
you
know
we're
supporting
the
cloud
foundry
thing
right
now:
it's
tied
to
cloud
foundry,
but
that
it
becomes
this
API
that
you
know
we
all
sort
of
can
can
evolve
together,
and
so
they
use
in
lots
of
different
contexts
and
and
being
as
flexible
as
a
service
broker.
E
A
So
that's
a
glad
that
you
brought
that
up
too,
because
I.
This
is
an
important
point
that
I
want
to
socialize
in
the
group.
Is
that
it's
it's
very
possible
to
me
that
II,
the
cloud
foundry
I'm,
sorry,
the
the
working
group
for
the
open
service
broker
API
may
wind
up
making
backward
incompatible
changes
so
that
will
need
to
have
some
ability
for
the
community's
catalog
to
work
both
with
the
v2
service
broker,
API
and
also
the
new
open
service
broker.
A
Api
I
think
that's
something
that
would
probably
be
profitable
to
keep
in
mind
while
we're
talking
through
the
use
cases,
because
it
frames
things
in
a
way
that,
like
any
particular
back
end,
is
probably
going
to
be
a
sibling
to
other
ones.
We're
not
we're
not
doing
we're,
not
building
something
that
should
be
designed
exclusively
to
work
with
one
backend
API.
A
Mean
just
to
kick
it
off,
I
think,
there's
a
whole
bunch
of
questions
around
catalog
management
and
I
still
would
love
to
figure
out
how
those
work
so
can
I.
What's
the
mechanism
for
like
adding
adding
stuff
to
my
catalog,
we
had
a
broker
to
do
that.
How
do
I
get
that
into
my
system?
10
somebody
cure
it.
B
A
Yeah
so
I
mean
just
general
around
importing
stuff
from
catalogs.
It
exists
out
there.
How
do
I
find
the
list
of
service
brokers
that
I
can
use?
You
had
a
thing
here.
It's
like
I
have
a
that
already
runs
a
service
broker
from
a
SAS
provider.
How
do
I
find
that?
Is
it
a
manual
ad
step
in
order
to
get
that,
or
is
there
some
sort
of
uber
list
of
service
brokers
really
catalog,
so
that
I
just
picked
this
up
automatically?
A
Okay,
I
tell
you
what
I'm
gonna
do
I'm
gonna
make
a
new
section
there
that's
like
sig
meeting
and
we
can
just
start
with
a
blank
slate,
and
this
is
probably
better
than
trying
to
adapt
things
into
what's
here
currently,
just
because
there's
not
much
so
I'm
going
to
go
ahead
and
start
recording
those
things
so
I
think
the
first
one
is
adding
service
brokers
into
the
catalog
and
Weston.
You
said
a
curation
catalog,
curation
and.
A
D
Definitely
just
the
second
part
of
it.
I
always
thought
that
some
of
the
curation
use
cases
that
are
being
talked
about
where
they
don't
even
want
certain
services
to
pop
up
at
all
in
the
catalog.
So
it's
not
a
question
of
turning
it
off
for
everybody
to
see
it's
just
I,
don't
want
them
to
be
populated
period,
and
maybe
that's
you
can
get
some
net
result
through
just
access
control
list,
true
yeah,
so
whether
they
wanted
to
completely
block
them
full
registration,
please,
okay,.
A
D
Mean
ii
had
some
use
cases
around
the
application.
What
was
the
word
that
was
used
in
the
PR
application
manager?
No,
oh
kieran,
the
exact
word,
but
you
know
the
guy
who
playing
the
application.
His
is
an
interaction
pattern
with
cod
with
a
community's
vision
and
find
services
to
his
application.
Okay,.
A
F
A
F
At
one
level,
yes,
the
question
is:
is
it
is
the
namespace?
The
only
thing
that
can
consume
services-
I
guess
is
there?
Is
there
like,
if
I
have
a
pot
of
spending
there?
Is
there
any
value
in
being
able
to
ain't?
No?
No!
No!
No!
This
is
actually.
This
pot
only
is
is
able
to
go
ahead
and
consume.
This
I
see
what
you
mean.
Okay,
so.
A
F
A
D
A
A
A
A
C
A
I
will
say
that
the
reason
that
I
articulate
articulated
it
that
way,
it's
that
over
the
weekend
and
today
I've
been
thinking
about
this
problem
and
I
sort
of
wonder
if
service
instances
should
not
always
be
named
spaced
and
if
they're
always
names
based.
Is
there
even
a
use
case
for
multiple
bindings
to
the
same
service.
F
Well,
the
one
use
guys
we
be
thinking
about
is,
if
you
have
multiple,
finally
to
the
database,
that
you
might,
for
example,
how
to
say,
like
fiend
axis,
only
for
some
section
of
the
database,
if
you
have
like
an
HR
database,
it
from
like
that
that
was
the
one
I'm
not
pretty
sure
that
it's
not
only
a
can.
You
know
made-up
example,
but
it's
certainly
something
that
we
be
kind
of
white
boarding.
This.
C
It's
possible
that
databases
aren't
really
the
best
example
for
why
you
might
want
two
things
in
different
namespaces
to
bind
to
one
common
service,
probably
the
best
example,
for
it
would
be
a
queuing
system
of
some
sort
where
you
have
two
different
applications
that
need
to
communicate
with
each
other
over
Q.
It's
imperative
that
they're
bound
to
the
same
queue
in
that
case.
A
So
let
me
set
to
expand
on
my
comments
that
I've
just
made
is
that
when
I
say
that
I
wonder
if
it,
if
you
need
to
have
multiple
bindings
to
a
service,
I,
don't
mean
that
should
be
possible.
That
I'm
questioning
whether
it
should
be
possible
for
multiple
namespaces
as
an
example
to
use
the
same
service.
I
have
no
question
that
that
should
be
possible.
But
what
I
wonder
is
whether
it's
necessary
to
for
that
to
be
represented
in
the
concepts
that
we're
talking
about
in
a
first-class
way.
A
A
They
both
want
to
use
the
same
service.
So
if
they
say
we're
talking
about
a
free
tier
here
and
the
broker
or
the
service
provider
is
just
backing,
this
free
tier
with
a
single
instance.
Is
it
even
really
necessary
to
have
a
single
service
instance
that
the
consumers
bind
against
or
can
you
just
have
both
of
them
say
they
want
to
use
the
service
and
they'll
get
the
same
instance?
I'm
just
I'm
wondering
if
there
is
a
need
to
represent
service
instances
I
in
a
global
way.
Does
that
make
sense?
Well,.
E
I
mean
the
interesting
thing
here.
I
think
is,
is
you
know,
do
you
want
to
limit
what
somebody
can
define
a
service
to
be
because
you
can,
through
the
service
broker
API
today,
you
could
certainly
have
create
service
instance,
always
return
the
same
instance
right.
If
you,
if
you
truly
a
singleton
multi-tenant
service
brand,
it
could
just
be
one
logical
service
instance,
but
the
pattern
would
be
exactly
is
saying
you
say:
I
want
to
service
instance,
and
then
you
bind
to
that
service
instance.
A
A
D
C
A
A
E
A
G
A
G
A
A
G
G
A
A
D
A
F
D
A
D
I
think
the
answer
has
to
be
yes
and
I.
Think
that
goes
to
number
six,
which
is
what
is
the
unit
of
consumption,
because
if
the
unit
of
consumption
is
a
namespace,
that
I
think
it
precludes
the
use
case.
You're
just
talking
about
that.
If
you
use
the
unit
of
consumption
to
be
down
to
the
pod
level,
that
I
that
I
think
it
allows
what
you're
talking
about
yeah.
D
A
D
A
Okay,
so
I
I
think
that
that
might
be.
If,
if
we
want
to
constrain
that
further,
then
I
think
that
that
will
take
some
work
and
I
suggest
that
I
suggest
that
we.
So
the
reason
is
that
what
I
expect
is
that
will
probably
expose
an
actual
service
crew
benetti's
service
into
a
namespace
when
you
make
a
binding
on
it,
and
there
is
no
way
to
prevent.
C
Personally,
I
feel,
like
that's
going
too
far,
that
the
unit
of
consumption,
one
of
the
things
that
you
did
with
the
steward
thing
is
we
said
all
right
here
is
a
rally
point.
This
rally
point
is
a
secret
or
potentially
a
service
binding
an
instance
of
a
service
binding
thing.
You
can
get
a
handle
on
and
consume
and
mount
it
into
your
application.
F
The
access,
control
or
quote
unquote,
being
able
to
go
ahead
and
see
those
things.
That's
to
me,
that's
one
part
of
the
equation.
The
other
part
also
is
how
the
reason
about
the
system.
So,
if
I
have,
if
I
have
an
application
that
has
multiple
pods
the
ability
to
go
ahead
and
understand
who
actually
is
using
services,
I
think
it's
also
very
important,
and
if
the
only
thing
that
you
have
visibility
into
is
that
well,
there's
some
stuff
in
this
namespace
that
uses
this
service.
That's
much
much
less
meaningful
to
me.
Okay,.
F
Yeah
I
think
that
that's
much
closer
to
what
I
think
would
be
beautiful
name
is
one
of
them
would
just
say:
I
just
want
these
credentials
the
bailiff
in
this
namespace.
Will
you
assume
that
that
namespace
is
cooperating,
AKA
friendly,
except
at
the
second
part,
which
is
hey?
I
really
want
to
go
and
understand
the
relationships.
F
Who
is
this
service
and
as
long
as
there's
an
explicit
mechanism
for
sewing?
Yes,
this
pod
or
these
pods
use
this
service.
To
me,
that
seems
like
a
very
desirable
feature
of
the
system.
Okay-
and
I
think
you're
saying-
is
that
the
way
the
surface
would
be
something
like
a.
I
have
seven
pods
coming
in
namespace.
Two
of
these
needs
access
to
service
x.
Now
you
declared
the
intent
which,
in
the
core
mechanism,
yeah.
D
This
could
be
based
upon
my
my
newness
to
kiruna
days,
but
let
me
ask
sort
of
possibly
a
very
dumb
question:
why
does
the
namespace
neat
vieira
involved
at
all
the
consumption
level?
What
would
be
wrong
with
simply
saying
for
each
pod
that
you
want
connect
up
created
a
binding
for
it
and
then
put
what
annotations
you
watch
inside
the
pod
spec?
Why
does
it
need
space
out
to
be
involved
in
the
picture?
Yeah.
B
A
The
namespace
needs
to
be
involved,
I,
think
so
that
you
know
the
subject
that
you,
you
know
the
target
namespace
they
can.
You
can
make
so
that
you
can
make
resources
in
that
namespace
and
that
you
have
a
longer
live
subject
than
a
particular
pod,
because
odds
may
go
away
right,
like
pie,
say
they
if
you're
using
deployments
a
pot,
isn't
a
good
subject
to
the
own,
the
consumption
of
a
service,
because
your
pod
will
go
away
when
the
deployment
is
when
you
got
a
new
version
of
your
application
to
well.
D
Yeah
but
I
could
get
out.
I
could
also
then
just
say
the
binding
is
like
the
life
cycle.
The
binding
is
the
same
as
the
pod
and
so
I
get
into
binding
each
time
it
gets
redeployed
as
a
worst-case
scenario.
I'm
not
saying
as
I
would,
but
I'm
just
trying
to
understand,
I
kind
of
understand
that
the
service
instance
might
have
to
be
bound
to
a
namespace
I'm,
not
completely
sold
on
that
yep
I
can
kind
of
by
that,
but
I'm
not
quite
sure,
I
understand
why
the
binding
has
to
be
the
namespace
level.
A
E
A
F
I
think
I
also
doug.
If
I
understood
you,
you
basically
made
a
point
about
life
cycle
as
well,
so
I'm
not
sure
which
is,
if
you
do
create
a
lake
like
what
does
the
life
cycle
look
like,
because
if
it
is
found
to
a
namespace,
then
having
bindings
come
and
go
buy
enough
might
be
trickier
right.
But
if
these
covers
in
your
cases
that's
fine
I
just
want
to
make
sure
that
that's
them
get
lost
in.
E
Guess
it's
not
fine
in
some
ways,
but
you
know
I
think
it's
also
important
to
try
to
decide
what
is
the
ideal
services
model
that
we
want
to
put
in
place
and
if
there's
something
that
kuba
Navy
doesn't
do
that
there's
some
capability
does
not
have,
and
maybe
we
should
bump
that
question
up
and
ask
the
new
bird
communities
people
about
know.
Can
we
could
we
make
this
work
in
smother
yeah.
A
D
I
think
marty
I
might
be
like
to
capture
morgans
point
there.
I
pensively
was
Morton.
Basically
I.
Take
a
high
order
question
he
was
asking
there
is
what
connects
it
be
bound
to
a
service?
Is
it
just
a
pod?
Is
it
the
generic
notion
of
a
app
application?
Is
it
a
namespace?
Is
it
something
else?
I
think
internet
question
might
help
answer
some
of
my
questions.
I
think.
H
There's
also
the
you
know
the
question
of
whether
binding
need
to
be
you
can
hose
into
multiple
parts.
If
you
think
about
how
this
works
for
applications
without
service
broker,
you
would
create
a
service
and
maybe
a
consistent
pic
map
or
secret
in
your
namespace,
and
then
you
would
explicitly
reference
at
least
our
secret
or
config
map
in
your
pod
and
ideally
disservice
as
well.
So
we
could
get
rid
of
the
default
environment
variables
for
services
that
get
set
up.
H
H
Well,
especially
if
we
go
with
something
like
a
clay
model,
you'll
have
a
claim
that
will
import
something
into
your
namespace
and
you
know
authentication
and
whatever
is
another
issue
as
well,
and
then
there
need
to
be
some
likely
some
kind
of
explicit
reference
to
to
the
claim
to
indicate
that
you're
actually
consuming
that
finding
from
the
pods
and
all
the
different
forms
of
pods
can
get
created,
arbitrary
controllers
and
whatnot.
You
know
whether
we
inject
the
degree
to
which
information
is
automatically
injected
into
containers.
H
A
H
I
think
you
know
number
16
of
consumption,
it's
not
sufficiently
clear
to
have
a
productive
conversation
about
that.
You
know
and
I
think
the
whole
monitoring
aspects
like
how
do
you
reason
about
the
system?
That's
yet
another
issue
which
doesn't
necessarily
need
to
be
conflated
with
the
other
things
I
mentioned
you.
H
A
So
I'll
put
brian
to
comment,
so
we
are
at
the
end
of
the
hour
and
as
someone
who
respects
everybody's
time,
I
would
like
to
meet
end
the
meeting
here.
But
I
think
this
was
a
really
great
discussion
and
so
I
wonder
if
what
is
the
appetite
of
the
group
to
meet
tomorrow?
To
continue
to
discuss
these
things,
we
haven't
decided
on
takeaways.
Yet
how
do
people
feel
about
like
a
half
hour
tomorrow
to
for
folks
to
volunteer
to
write
up
particular
use
cases.
C
A
All
right,
Dan
WIC
that
I,
you
have
made
a
comment
in
the
chat.
Why
don't
you
is
this
question
tomorrow?
When
we
talk-
and
I
will,
I
will
make
a
pull
request
to
the
incubator
repo
to
get
this
I
onto
the
internet.
I
dug
suggest
that
we
meet
at
the
same
time
tomorrow
that
that
sounds
great
to
me.
If
anybody
has
a
conflict,
please
eat
now
or
forever
hold
your
peace.
As
the
saying
goes,
that.