►
From YouTube: Kubernetes SIG Service Catalog 20161017
Description
Proposal around Service Catalog API Spec; discussion of multiple controllers and Service Broker Types
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
B
So
then,
moving
on
down
to
the
API
precedence
Kent
originally
decided
to
base
the
concept
here
in
on
persistent
volumes
and
ingress
controllers
and
I
totally
agree
with
that.
The
data
structures
and
persistent
volumes
and
how
both
the
submitter
or
the
consumer
interacts
with
them,
and
the
KU
béarnaise
API
interacts
with
them
are
so
similar
to
what
we're
talking
about
here
in
service
catalogs
that
it
kind
of
just
after
Kent
showed
me
I
just
kind
of
got
it.
B
B
Excuse
me,
a
controller
against
these
things
against
these
services
that
consumers
of
the
cluster
will
be
requesting.
So
just
like
getting
us,
ingress
controllers
are
just
a
pas.
That's
running
that
watches
the
event
stream.
We
want
the
controller's
to
be
a
pod.
That's
running
that
watches
the
event
stream
for
these
specialized
resources
that
consumers
will
be
submitting
to
request
a
service
request,
access
to
a
service.
So
then,
moving
on
down
to
Cunha's
resources.
I'll,
let
people
read
these
for
themselves.
There
are
four
new
resources
that
we're
proposing.
B
We
have
previously
discussed
some
implementation
details
about
how
to
actually
represent
these
and
sort
of
what
the
flow
will
be
implementation
wise
from
now
until
they
end
up
in
some
excuse
me
in
some
official
capacity
and
finally,
whether
or
not
that
ends
up
in
the
core
is
I.
Think
still
up
for
debate
as
well,
but
briefly
going
over
these
service
class
is
the
kind
of
service
it's
roughly
equivalent
to
what
a
storage
classes
service
instance.
Just
as
it
sounds
as
an
instance
of
a
service
class.
B
Both
service
class
service
instance
are
going
to
be
bindable
or,
I
should
say
claimable
by
a
consumer
and
we'll
get
into
the
specs
of
that
in
a
second,
of
course,
there's
a
claim,
which
is
how
the
consumer
interacts
with
the
instance
in
the
class
and
then
the
claims
result
is
a
binding.
The
binding
is
more
or
less
at
this
point,
a
pointer.
B
Well,
first
of
all,
it's
a
record
that
someone
is
using
a
service
and
then,
second
of
all,
it's
a
pointer
to
all
of
the
credentials
and
connection
information
and
so
on
and
so
forth
that
the
claim
produced
this
diagram
below
kind
of
kind
of
reflects
that
it
may
need
a
little
bit
of
work.
But
to
me
I've
stared
at
a
bunch,
so
I'm
biased,
but
it
kind
of
defines
the
workflow
that
a
consumer
and
an
operator
would
go
through
to
set
up
a
catalog
or
consume
a
catalog
in
a
cluster.
So.
A
That
will
be
like
something
that
would
take
a
year
to
get
like
critical
mass
on
conservatively
speaking.
Another
thing,
I'll
call
out
is
that,
like
there's
been
a
lot
of
work
already
done
in
the
cord
to
create
API
groups
so
that
we
don't
have
to
have
a
single
have
a
single
leg,
not
monolithic,
but
a
single,
very
large
API,
so
going
along
with
that.
A
I
think
that
it
is
a
pattern
that,
like
we
want
to
facilitate
to
build
things
that
live
outside
the
core,
but
look
like
they
are
part
of
the
core
via
API
Federation,
and
if
it's,
if
it's
not
clear
like
it
folks
of
talk
heard
me
talk
about
heard
me
talk
about
building
a
separate,
API
server
and
the
pass
and
federating
it
with
the
main
one.
That's
the
concept
that
I've
been
talking
about
and
now
I'll
mute,
so
I
can
mute
slack
because
it
is
driving
me
crazy.
B
Yep,
thanks
for
the
former
Paul
I,
actually
want
to
go
back
up
to
motivations,
there's
still
some
discussion.
The
PR
on
motivations
and
I
will
probably
be
removing
that
language
about
clunky
third
party
resources,
because
third
party
resources
may
very
well
be
sort
of
a
step
in
that
direction
towards
either
federal
types
or
in
that
year
or
more
time
frame
getting
them
into
the
core.
I
wrote
clunky
originally
because
right
now,
the
implementation
of
third-party
resources
is
far
from
ideal
and
we
kind
of
discovered
all
of
these
implantation
courts.
B
I
should
probably
just
call
them
warts,
because
they're
the
kind
of
hinder
almost
all
usages
of
two
or
more
third-party
resources.
We
found
all
that
stuff
when
we
were
building
Stewart
so
anyway
yeah.
It's
very,
very
true
that
we're
going
to
probably
be
taking
a
multi-step
approach
to
actually
implementing
these
types
and
what
Brian
said
I
completely
agree
with
I.
Don't
think
anyone
believes
that
they're
ready
for
prime
time
so
anyway,
going
through
these
example
resources
they
kind
of
start
simple
and
then
get
a
little
more
complex.
B
So
service
class
is
pretty
much
what
it
sounds
like
it's
a
class
of
services
very
similar
to
a
storage
class,
but,
as
Paul
pointed
out,
the
the
kind
which
it
here
is
represented
as
a
name.
It
may
be
a
lot
more
coarse
than
what
storage
classes
represent,
whereas
a
storage
class
might
represent
a
specific
size
of
disk
on
Amazon
or
specific
size
of
disk
and
disk
access
pattern
on
google
cloud.
This
is
probably
going
to
be
more
like
I
just
want
a
Postgres
database.
That's
in
some
arbitrary
category
called
small.
B
That's
still
up
for
debate.
There's
been
no
decisions
made
there,
but
that's
what
kind
of
goes
along
with
a
lot
of
the
use
cases
we've
discussed
so
far,
and
then
additionally,
in
this
pack
and
play
excuse
me
that
speck
has
a
service,
ID
and
plan
ID.
Those
are
pointers
to
an
internal
catalog
that
we
expect
the
service
controllers
Service
Catalog
controllers
to
contain.
So
these
things
may
very
well
matched
to
a
backing
service
at
a
and
plan.
Id
that
a
back-end,
Cloud,
Foundry
service
broker
would
provide,
for
example,.
A
Yeah,
so
so
this
is
where
I
felt
that
there
should
be
a
service
broker
resource,
because
I
think
that,
like
he
and
I
don't
want
to
put
words
into
your
guy's
mouth
and
all,
but
I
read
this
and
I
feel
like
if
I
put
myself
in
there
like
bring
the
mind
of
the
author.
Like
you
mentioned,
it's
there's
some
like
other
internal
layer
that
I
controlling
those
about
and
I
feel
like.
A
We
need
to
externalize
that
so
that
all
of
the
all
of
the
the
primary
actors
in
the
system,
entities
in
the
system
are
first-class
resources,
and
maybe
we
make
it
so
that,
like
you,
don't
necessarily
need
a
broker
resource
to
have
a
service
class
or
service
instance
like
we
can
facilitate
the
one-off
approach
or
if
there's
like
a
thing,
that
we
want
to
write
a
controller
for
that,
doesn't
have
the
same
brooker
notion
a
lot
for
that.
But
I
think
brooker
should
be
a
first-class
resource
here.
Yeah.
B
B
All
I
would
need
is
to
just
know
to
create
a
claim
that
references,
a
specific
service
class
or
service
instance,
and
then
the
operator
is
the
one
who
knows
how
to
create,
create
the
service
controller
in
the
cluster
to
watch
for
the
class
or
claim
or
instance,
but
it
the
reason.
I
think
that
it
makes
sense
to
add.
The
broker
is
not
specifically
for
the
app
dev,
but
for
the
operator
to
have
sort
of
a
definitive
record
of
what
brokers
are
in
about
and
what
should
and
should
not
be
listening.
Yeah.
A
B
Yeah,
but
I
think
what
I'm
going
to
do
is
after
I
address
all
of
your
other
commentary
and
others
commentary,
then
I
would
either
like
to
merge
this
and
just
make
a
note
like
a
to
do
essentially
and
then
get
the
commentary
on
the
broker
later
or
at
least
finish
up
everything
first
and
then
put
a
new
broker
side
elicit
comments.
Just
for
that
section,
yeah.
A
B
So
I'm
going
to
move
on
down
serves
instances,
essentially
it
just
as
it
sounds.
It's
an
instance
of
one
of
the
service
classes.
So
the
example
we've
given
here
is
it
points
to
a
specific,
zip
code
database,
a
specific
database
in
one
of
the
provision,
postgres
databases
you
can
see
below
in
the
spec.
It
actually
points
to
a
service
class
which
indicates
what
kind
of
database
it
actually
is.
And
then,
if
we
go
down
these
match,
these
bind
our
skis
me.
These
claims
match
to
the
instance
versus
the
class.
B
So
this
claim
is
called
a
single
tenant
claim
and
if
we
go
down
to
the
first
element
below
the
spec,
it
points
directly
to
a
service
class.
I'll,
explain
the
mechanics
behind
this
in
a
second.
But
essentially
what
this
is
saying
is
that
the
thing
the
Service
Catalog
controller
behind
the
scenes
should
provision
and
bind
to
the
given
class
and
that
effectively
ensures
that
the
consumer
who
submitted
this
claim
is
going
to
have
exclusive
access
to
the
provisions,
postgres
large
database
and
then
the
second
element
there
under
target
binding.
B
It
just
points
to
the
service
binding
that
will
be
output
and
that
service
binding
will
have
pointers
to
all
of
the
credentials
that
tell
the
consumer
how
to
connect
to
that
postgres
and
then
feels
they're
not
written
by
the
consumer.
They're
just
written
by
the
service
controller,
to
update
on
what
is
the
progress
of
the
provision
and
bind
operation.
So.
A
B
B
So
as
it
stands
right
now,
you
can
see
status
in
there
and
the
status
is
the
thing
that
will
change
actually,
along
with
the
status
description,
but
once
we
started
adding
more
details
about
the
output.
Excuse
me,
the
output
credentials
and
the
fact
that
the
thing
is
done
binding.
It
actually
got
confusing
even
for
us
to
try
and
manage
which
services
were
bound
and
where
are
their
credentials.
So
we
decided
to
add
this
kind
of
very
small
shell
called
service
instance
binding.
That
represents
the
fact
that
a
claim
has
been
completed.
C
A
B
Yeah
I,
don't
think,
there's
any
technical
reason
why
all
of
the
stuff
in
services,
since
bindings
status
field,
couldn't
go
into
the
claim,
but
just
for
reference.
What
we
have
now
inside
of
the
we
actually
have
an
extra
field
in
the
existing
claims
that
steward
uses
and
that's
very
overloaded
and
it's
actually
implementation-specific
as
well.
So
the
helm
steward
writes
a
completely
different
set
of
things
into
that
field
as
the
cloud
foundry
steward.
B
So
it
it
just
felt
a
little
bit
more
messy
than
having
a
brand
new
resource
called
binding
at
both
acts
as
the
indicator
that
a
thing
is
using
a
service
and
also
acts
as
sort
of
the
central
location
that
points
to
all
of
the
secrets,
config
maps
and,
as
Jason
said,
the
other
resources
that
we
might
output
in
the
future.
So
a
little
bit
ly
Google
engineers
you're
missing
today.
D
For
an
off-site,
but
on
the
Google
side,
we've
been
thinking
about
binding
as
a
first
class
thing
as
well.
I
mean
this
idea
that
these
are
all
the
intense
for
connections
between
applications
that
you
know
that
that
exists
and
that
have
passed
back,
successful
credentials,
just
just
kind
of
makes
sense,
especially
if
you're
starting
to
think
about
okay.
D
A
To
the
the
storage
nouns
so
like
I,
look
at
service
instance
claim
and
I
think
that's
persistence.
Persistent
volume
claim
right
on
so
persistent
Boing
plane
has
a
status
that
tells
you
whether
it's
bound
and
I
feel
like
like
there's,
not
anything
that
is
so
intrinsically
different
from
from
this
aspect
of
like
storage
versus
serviceworker
services,
to
merit
like
doing
something
that
would
be
like
having
a
binding
resource.
In
addition
to
claim
for
persistent
volumes,
does
that
make
sense.
B
That
does
to
me-
and
that's
actually
me,
that's
the
most
powerful
argument
against
the
binding
object,
so
it
may.
It
may
be
that
we
take
this
out
and
then
see
how
reasonable
it
is
to
represent,
like
Jay
said,
represent
that
connection
information,
so
that
you
could
build
a
graph
and,
like
we
were
saying,
represent
the
information
about
all
of
the
output
and
credentials
info.
It
may
be
that
we
put
that
into
the
claim
and
then
just
see
how
implementations
handle
the
Hana
I'm
actually
open
to
either
way
this
binding
for
me
and
I.
B
Think
I
speak
for
at
least
Jason,
and
can't
you
guys
correct
me
if
I'm
wrong,
but
I
think
for
us.
This
is
a
direct
result
of
thinking
a
little
bit
more
about
the
output
of
a
claim
in
the
context
of
what
we
saw
in
steward
and
they
also
the
context
of
what
we
saw
for
kind
of
use
cases
going
forward.
Yeah.
A
So
just
another
another
idea,
all
throughout
their
like.
Instead
of
calling
as
first
class
fields
like
each
particular
different
API
resource
that
may
have
been
created
as
the
result
of
a
binding,
we
could
just
have
a
list
of
references
that
are
tight
diagnostic
that
carry
the
type
information
as
part
of
the
status.
A
D
Yeah
I
mean
this
is
Jerry
I'm,
relatively
new
to
Cooper,
Nettie's
and
I've
thought
of
these
things
in
terms
of
service
management
concepts
as
opposed
to
communities,
object
concepts,
and
this
generic
thing,
like
a
claim,
is
I,
want
to
use
anything
whether
it's
storage
or
service
type
or
service
instance.
Is
it
a
lot
I
mean
it
seems
like
it
would
be
more
intuitive
if
you
had
verbs
that
refer
to
the
thing
right,
like
I,
want
to
mount
storage
I
want
to
bind
to
an
instance.
D
I
want
to
deploy
a
service
type
I
mean
I,
can
understand
the
desire
for
consistency
across
all
things,
and
so,
and
you
know
again,
I'm
not
been
part
of
the
companies
can
be
here
long
enough
to
really
weigh
and
authoritative
Lee,
but
but
but
to
literally
answer
Paul's
question
is
this
intuitive
yeah?
It
seems
like
it'd
be
more
into
it
as
if
the
verbs
were
related
to
the
nouns
they
were
dressing.
A
Yeah
so,
like
I,
think
I
think
the
difference
is
that
when
you
make
a
claim
on
a
service
class
and
instance,
gets
provision
for
you
and
your
ultimately
bad
to
that
instance
of
that
right
here
in
the
ad.
It's
great.
So
this
is
this
is
perhaps
an
area
where,
like
the
analogy,
isn't
100-percent
between
storage
and
services,
but
I
think
maybe
the
commonality
is
that
you
always
bind
to
a
service
instance
in
this
proposal.
But
you
may
also
have
a
may
also
have
a
claim
against
a
class
right,
yeah.
B
I'm
not
sure
if
it's
confusing
to
have
to
overload
this
you,
this
kind
of
service
claim,
because
it
like
I,
can
go
down.
If
you
look
in
the
multi-tenant
there's
a
service
claim
that
has
a
service
instance
in
its
back
instead
of
a
service
class,
and
that
subtle
that
to
me
is
a
subtle
difference.
That
means
very
different
things.
B
B
So
it
depends
on
the
broker
implementation
too,
but
let's
say
you
had
a
broker
that
on
provision
created
a
new
database
instance
and
then
on
bind
gave
a
just
gave
credentials
to
that
database
instance.
The
service
controller
implementation
would
map
the
creation
of
a
service
instance
to
provision
and
then
the
creation
of
the
service
claim
to
either
provision
+,
bi
or
just
bind
ok.
A
A
B
Pull
request,
sure
I
think
it
definitely
needs
some
more
clarity.
At
least
if
this
is
indeed
is
a
valid
use.
Case
I
happen
to
think
it
is,
but
I
think
just
the
fact
that
we
have
a
claim
that
can
do
two
wildly
different
things
just
by
changing
one
field,
just
personally
that
that
might
be.
That
might
not
be
the
best
thing,
but
anyway,
yeah
I'll
continue
down.
I
just
actually
just
mentioned
the
multi-tenant
use
case.
You
just
point
to
claim
to
an
instance,
which
represents
an
already
provisioned
thing.
B
B
Think
internally,
we
basically,
we
also
did
it
as
a
basically
just
a
set
of
four
different
curl
commands
as
well.
So
the
point
is
that
these
are
implementable
by
anyone
and
they
can
do
anything
but
Paul,
as
you
said
already
in
the
PR,
we
might
want
to
provide
a
controller
just
as
a
reference
that
just
translates
the
claim
into
backing
Cloud
Foundry
service
broker
calls
so
I'll.
Let
you
guys
read
all
these
implementation
details
and
if
there
are
questions,
either
comment
here,
if
you've,
if
you've
gotten
to
it
or
put
them
on
the
PR.
A
Oh
they're,
just
a
key
is,
is
correct.
I,
I
did
say
on
the
poor
request
that
I
think
that
we
should
provide
a
controller
that
knows
how
to
speak.
The
clock,
Andre
service
broker
to
point
o
API
I.
Think
if
that
thing
that
I
just
referred
to,
is
good
enough,
that
you
shouldn't
have
to
write
another
one.
If
you
have
your
own
plans,
where
you
think
you
needed
and
you're
going
to
write
your
own
and
and
add
something
to
it,
I
think
you
should
be
able
to
I.
A
Definitely
think
that
you
should
be
able
to
run
multiple
controllers
that
handle
different
back-end,
ap
ons.
So,
for
example,
the
say
that
I
want
to
run
a
controller
that
is
my
adapter
to
Cloud
Foundry,
sir
broker
API
I
should
be
able
to
do
that
and
also
run
one
that
is
white
box
like
I
I,
think
it
is
it's
a
little
different
than
ingress
I
think
ingress
is
another
good
analogy,
but
it's
not
one
hundred
percent
like
so
with
ingress
I
think
operators
will
be
like
well.
A
I
only
want
to
deal
with
one
type
of
that
I
want
to
manage.
I.
Think
it's
a
little
different,
because
there's
I
expected
we'll
have
like
a
bunch
of
different
approaches
that
people
want
to
take,
and
we
also
know
that,
like
the
best
sorry
not
the
best,
but
the
most
mature
API
in
the
space,
the
cloud
foundry
serviceworker
API
is
also
pretty
limited.
Right,
like
we
can't
account
for
white
box
things
and
communities
in
that
API.
So.
A
Motivation
for
us
to
be
able
to
develop
alternative,
api's
or
like
say
someone's,
to
make
some
additive
changes
to
plat
boundary
service
broker,
for
whatever
reason
and
I
think
we
should
support
multiple
types
of
controllers,
working
on
the
same
set
of
API
resources,
I
kind
of
wonder
if
there's
any
strong
feelings
about
that
in
a
group,
any
strong
gut
reactions
books
want
to
share.
At
this
point.
A
I'm
not
hearing
anybody
saying
no
so
so
one
thing
I've
been
wondering
about
since
Saturday
when
I
was
looking
at
its
full
request
is
what
is
the
right
way
to
account
for
that
design
goal?
Do
we
annotate
these
resources
with
the
controller
that
handles
them?
I,
don't
think
there
is
any
existing
precedent
in
Coober
Nettie's.
The
one
possible
area
precedent
is
that
we
want
there
to
be
a
eventually.
We
want
people
to
be
able
to
implement
their
own.
A
A
storage
like
persistent
volume,
dynamic
provisioners
that
work
with
storage,
class
and
PV
and
PVC,
but
I,
don't
think
that
we
have
any
and
I
could
be
wrong
about
this,
but
I
don't
think
we
have
a
robust
scheme
for
a
whining
particular
resources
with
the
actual
controllers.
Yet,
and
there's
been
a
question
in
that
domain
of,
like
was
the
alignment
of
storage
class
to
provisioner
that,
as
far
as
I
know,
is
still
unsettled.
So
I
had
only
more
questions
and
no
answers,
but
that
is
what
I
have.
B
B
B
Alrighty
cool
so
then
the
last
two
visibility
we've
pretty
much
followed,
I
believe,
with
the
exception
of
service
instance
binding,
because
that
doesn't
exist
in
persistent
volumes.
As
you
said,
Paul
the
first
three
service
class
service
instance
service
instance
claim
those
are
those
follow.
Persistent
volumes,
so
service
class
and
serves
instance
are
clustered
global.
The
claim
is
namespace
scoped.
B
A
B
Same
with
us
and
I
think,
instead
of
so
instead
of
answering
that
question,
we
essentially
added
security
mechanisms
to
address
the
different
types
of
instances.
So
if
we
go
down
to
the
binding
policy,
the
binding
policy
effectively
allows
service
instances
to
always
be
global,
but
then
define
which
namespaces
can
interact
with
those
service
instances.
A
So
I'm
not
I'm
not
positive
that
we
necessarily
need
a
policy
object.
Forget
it
to
do
this
so
like
we
have
role-based
access
control
that
we
can
use
on
whatever
push
this
api,
that
can,
I
buy
service
account,
give
you
permissions
on
endpoint
and
burn
that
you
can
use
with
it.
I
think
that
both
of
the
policies
are
kind
of
subsumed
by
it.
I
think
I
I
do
think
it
is
a
goal
to
have
our
back
over
federated
api's
with
the
core,
so
we
might
get
that
for
free
from
that.
B
E
This
is
Kent
I
just
want
to
lay
in
on
one
thing:
you're
yep
service
instances
get
names
faced
a
problem
that
we're
going
to
run
into
is
the
scenario
where
you
have
a
multi-tenant
service
that
now
exists
in
some
namespace
and
you
may
have
consumers
and
multiple
namespaces
that
need
to
bind
to
that
service
and,
and
that
could
be
quite
problematic
if
service
instances
exist
in
the
namespace.
Instead
of
being
cluster
global
I.
A
A
But
I
also
think
that,
in
the
use
case,
conversation
is
probably
complicated
enough.
That
I,
don't
think
anybody's
prepared
to
have
that
off
the
top
of
their
head,
I
will
say:
I
am
definitely
not
prepared
to
have
that
one
off
the
top
of
my
head
and
probably
warrants
some
additional
thought
stop
being
put
into
writing
before
we
can
decide
on
them.
Yeah.
B
We've
mentioned
quotas
already
I
I,
don't
know
what
that
will
look
like
yet
so
I
basically
wrote
TBD
in
there
and
then
in
this
final
note,
essentially,
as
is
service
controllers
as
written
in
the
stock,
the
service
controller
would
have
a
fairly
large
burden
of
enforcing
these
security
mechanisms.
So
if
we
do
go
a
namespace
route,
our
back
would
take
care
of
a
lot
of
that,
but
there
would
still
be
some
potentially
non-trivial
implementation
that
service
controllers
would
have
to
do
around
security,
so
subtly
I,
don't
think
I
have
a
good
answer
for
it.
B
Sounds
good,
so
this
was
in
chat,
I'll,
repeat
it
here,
Brian
asked.
If
we
have
a
list
of
open
questions,
we
do
not
have
a
list
I've
taken
some
notes
and
I
I'm
planning,
at
least
to
add
them
to
the
bottom
of
this
doc.
But
if
anyone
has
a
better
idea
how
or
where
to
put
them
but
I'd
like
to
do
it
that
way,
how.
A
A
Kool-Aid
are
open
questions
I
think
that
it
would
also
be
good
since
we
are
now
talking
about
API
if
we
had
some
folks
from
the
group
who
are
willing
to
do
some
research
on
API
Federation
and
some
of
the
like,
what
are
the
current
capabilities
of
the
generic
API
server
and
so
forth
and
started
thinking
about
how
do
we
actually
build
this
thing
and
federated
with
the
main
API
I?
Don't
necessarily
think
anybody
needs
to
call
out
that
they
want
to
do
that
now,
but
I
will
say
that
I
am
interested
in
doing
that.