►
From YouTube: Kubernetes SIG Service Catalog 20161010
Description
Deis presents a proposal for modeling the service broker problem space in a Kubernetes API.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
Alright,
we
are
recording
cool,
so
I
wanted
to
let
everyone
know
that
we're
going
to
be
open
sourcing,
the
steward
repository,
if
everyone
remembers
Jason,
Kent
and
I-
talked
about
steward
last
week
in
the
first
of
two
presentations.
So
right
after
this
go
to
github.com
/
dais
/
steward
all
the
code
to
be
there.
We've
got
a
bunch
of
issues:
we've
got
some
design,
docs
demo,
instructions,
usage
instructions
so
on
and
so
forth.
So
look
forward
to
that.
B
C
So
so,
basically
I
know
the
topic
has
come
up
before
of
you
know.
Are
we
going
to
have
an
API
for
the
Service,
Catalog
and
I
believe
they're?
There
probably
was
some
consensus
that,
yes,
we
will,
although
I
don't
think
I
was
there
for
that
conversation.
I
missed
the
first
couple
cigs,
but
I
think
or
I
want
I
want
to
propose
that
it's
it's
time
that
we
start
talking
with
in
the
sig
about
what
that
API.
To
might
look
like
there's
a
few
reasons
for
that.
We
feel
internally
at
dais.
C
You
know
we've
talked
about
this.
We
feel
that
if
Cooper
Nettie's
included
the
the
primitives,
if
you
will
that
the
sinks
orbit,
sorry
that
the
Service
Catalog
is
built
out
of
that,
that
would
have
some
benefits
to
those
who
are
already
cooking
up
implementations.
So
you
know
Google
demoed
something.
C
What
we
think
this
looks
like
and
would
like
to
present
that
if
it's
okay-
and
this
is
by
no
means-
you
know
fully-
you
know
fully
polished.
This
is
like
a
rough
draft
and
it's
something
we
want
to
present
to
the
community
to
at
least
you
know,
begin
fueling
discussion.
So
is
it
possible
Paul
that
we
could
go
through
that.
C
So
I
will,
I
will
share
this
deck
with
everybody
after
the
meeting
so
Service
Catalog
API
giving
service
broker
zaku
pernetti's
native
interface.
So
there
are
some
motivations
that
I
already
kind
of
touched
on.
Here.
We
saw
some
good
prototypes
demoed
last
week
and
moving
forward
an
API
would
guide
those
continuing
efforts.
It
would
improve
the
user
experience
by
not
relying
on
compared
to
the
clunky
third
party
resource
types.
C
So
so
we
looked
within
Cooper
Nettie's
for
inspiration,
we
didn't
have
to
look
far
and
in
persistent
volumes
we
found
a
problem
space.
That
seems
like
it's
symmetric
to
the
problem
space
of
service
catalogs,
and
we
think
that
consistency
is
a
virtue
and
with
the
community
benefits.
If,
if
you
know
this
very
similar
problem
was
solved
with
a
similar
solution,
so
storage
class,
persistent
volume
and
persistent
volume
claim
seemed
like
they
could
be
a
good
model
for
Service
Catalog
API.
C
C
So
this
diagram
shows
that
the
resources
we're
proposing
be
created.
The
first
is
a
service
class
which
describes
not
a
service
but
a
kind
of
service.
The
second
is
a
service
instance
which,
as
the
name
may
imply,
describes
an
instance
of
a
service.
A
service
instance
is
an
instance
of
a
service
class,
so
one
is
the
recipe
and
one
is
an
actual
functioning
service,
and
you
know
I'll
give
the
usual
disclaimer
that
naming
things
is
hard,
and
you
know
these
names
obviously
are
all
subject
to
change.
C
It
can
reference
a
service
instance
if,
if
the
consumer
would
like
to
bind
to
an
existing
service,
but
it
can
also
reference
a
service
class
if
the
consumer
is
willing
or
wanting
to
have
a
dedicated
service
provision
for
them
and
again,
this
is
this
is
exactly
symmetrical
to
what
goes
on
with
persistent
volume
claims
right.
A
persistent
volume
claim
can
reference
a
persistent
volume
if
there's
a
particular
volume
you're
interested
in,
but
it
can
also
call
out
a
storage.
C
D
C
So
so
you
know
using
the
analogy
with
persistent
volumes
you
make
a
persistent
volume
claim
or
I
should
say
a
consumer
makes
a
persistent
volume
claim
to
say
either.
I
need
this
particular
volume
or
I
need
a
volume
that
has
these
characteristics
right.
So
you
may
reference
a
storage
class.
That
says
you
know
you
might
call
it
like
a
I.
Don't
know
the
names
are
arbitrary.
B
So
I
have
some
questions
about
this
and
I'm,
probably
not
helped
by
my
familiarity
with
storage
class,
because
I
keep
trying
to
fit
what
you're
saying
about
service
class
into
the
pretty
detailed
information.
I
have
about
storage
class
in
it
all
and
as
I've
been
opening
my
mouth
opening
my
mouth
to
save
these
things,
I've
decided
that
they
are
better
catch
until
the
end,
so
carry
on
okay.
E
Well,
that's
a
question,
oh
sure,
yeah.
What's
really
it
is
their
relationship
between
services
instance
claim
and
like
a
cloud
foundry
binding
because
it
sounds
kind
of
similar,
but
not
quite
and
since
that
a
binding
seems
more
like
a
realistic,
real
instantiation
or
linkage.
But
this
sounds
like
it
also
could
be
more
like
a
deferred
request,
kind
of
thing.
Yeah.
F
Sort
of
instance
model
it
was
first
used
with
pods
and
nodes,
and
then
it
deliberately
copied
with
persistent
volume,
claims
and
persistent
volumes.
The
binding
is
effectively
represented
in
the
claim
or
in
some
cases,
both
in
the
claim
and
in
the
instance
that
is
bound
to
which
isn't
the
case
for
knows,
but
is
the
case
for
persistent
volumes,
because
it's
an
exclusive
one-to-one
relationship,
so
there
needs
to
be
a
representation
of
that
exclusively
a
relationship
on
both
sides,
and
you
know
with
a
pod.
You
can
just
describe
properties
that
are
required
for
that.
F
A
node
has
to
satisfy
for
the
pod,
but
you
can
also
specify
the
node
directly
with
the
node
name.
So
this
is
another
instance
of
that
pattern
and
I
pasted.
Some
a
link
to
a
doctor
wasn't
completed,
but
that's
no
a
sort
of
a
write-up
of
this
of
this
pattern.
So
I
think
it
is
good
to
reuse
existing
patterns
from
the
system
if
it
fits.
B
I
will
also
add
a
little
bit
of
context
of
this
that
the
storage
class
is
meant
to
be
an
input
of
parameters
to
a
provisioner
that
goes
and
creates
a
persistent
volume
that
has
the
characteristics
that
are
defined
in
a
class,
and
so
my
I
will
call
out,
like
I,
keep
trying
to
make
sense
of
service
class
in
terms
that
and
I'm
having
trouble
so
I
wonder
if,
if
perhaps
I
don't
want
to
be
relevant
for
your
presentation,
but
if
we
can
discuss
that
later,
the
specifics
of
that
service
class.
That
would
be
great
yeah.
B
A
Carry
on
I
just
want
to
add
one
thing:
Aaron
from
Deus
we
had
discussed
sort
of
two
possible
versions
of
that
service
plan
resource
one
would
be
kind
of
internal
to
the
service
controller
which
can't
we'll
get
to
shortly.
The
other
one
would
be
sort
of
the
official
exposed
publicly
exposed
version,
but,
as
kent
said,
we've
kind
of
left
it
out
of
these
slides
here
and
think
could
be
helpful
to
leave
that
open
for
suggestions,
maybe
after
this
cig
or
at
the
end,
or
something
like
that
sure
yeah.
C
B
C
Okay,
so
I
just
have
a
couple
slides
here
that
that
kind
of
highlight
the
sims,
the
symmetry
with
persistent
volumes.
It
sounds
like
people,
don't
really
need
to
be
convinced
of
that,
so
I'm
just
going
to
go
through
these
really
quick.
The
idea
is
that
a
storage
class
like
a
service
class
is
defined
by
an
operator.
Storage
class
doesn't
describe
the
volume,
nor
does
the
service
class
describe
a
service
storage
class
describes.
A
kind
of
volume.
Service
class
describes
a
kind
of
service,
and
you
also
see
there
the
standard
disclaimer
about
naming
things
being
hard.
C
Okay,
persistent
volume
is
an
instance
of
a
storage
class.
Similarly,
a
service
instance
is
an
instance
of
a
service
class,
and
both
of
them
can
be
statically
provisioned
by
an
operator
and
then
bound
to
a
consumer
or
can
be
dynamically
provisioned
by
a
consumer.
So
I
highlighted
two
use
cases
earlier.
One
where
you
know
persistent
volume
claim
mentions
a
particular
volume
that
has
interests
in
mounting
versus
just
referencing
a
storage
class
and
saying
I
need
a
volume
with
these
characteristics.
C
The
service
classes
and
service
instances
are
defined
by
operators.
A
service
instance
claim
is
created
by
a
consumer
and
it
can
reference
the
service
class
or
a
service
instance.
I
guess
what
I
didn't
say
that
I
should
have
said
is:
is
that
in
the
case
that
a
service
instance
references
I'm?
Sorry
in
the
case
that
acclaim
references
the
service
class
it
dynamically
creates
the
service
instance
I
think
this
will
become
more
clear
as
we
push
through.
Okay.
C
E
So
one
thing
that
I'm
kind
of
wondering
about
is
for
persistent
volumes,
I
kind
of
understand
the
notion
of
you're
asking
for
imagine
what
you're
saying
correctly.
You
don't
necessarily
ask
for
a
particular
volume.
You
ask
for
volumes
with
a
particular
set
of
characteristics
and
you're,
saying
something
similar
here
and
I
get
the
sense
that
you're
saying
that
a
customer
would
come
along
and
say:
I
want
a
relational
database
or
something
like
that
with
a
certain
set
of
characteristics,
but
not
necessarily
come
right
out
and
say
I
want
my
SQL.
Is
that
correct?
Well,.
C
E
C
Instance
of
right,
so
that
so
that
so
there
are
two
use
cases
that
are
accounted
for
here.
What
one
is
where
somebody
wants
to
bind
to
a
specific
instance
of
a
service,
so
it
could
be
to
make
that
more
concrete,
which
you'll
see
in
the
examples
that
could
be
something
like
a
a
shared
zip
code
database
or
something
like
that.
I
think.
A
C
It
washes
service
instances
and
service
instance
claims
it
delegates
the
discrete
operations
to
the
appropriate
brokers,
so
those
operations,
obviously
I,
think
we're
all
familiar
with
provision
bind
on
buying
a
deep
revision
upon
bind.
It
manages
the
credential
bearing
secrets.
We
also
feel
there
there
might
be
room
for
the
addition
of
an
actual
binding
object
here,
which
somebody
asked
about
earlier
as
well
and
and
again,
I
I've
included
a
point
here
that
that
is
something
we've
borrowed
from
the
ingress
controller,
where
we
feel
that
there's
room
for
more
than
one
possible
implementation
here.
C
So
this
is
what
it
looks
like
kind
of
in
the
middle
here.
If
you
can
see
my
cursor,
we
have
the
Service
Catalog
controller
and
it
watches
service
instances
and
service
claims
in
response
to
the
creation
of
service
instances
or
service
instance
claims.
It
will
use
brokers
to
provision
optional
services
and
it
will
create
credentials
for
those
services.
C
C
You
know
the
credentials
could
just
as
easily
be
some
new
kind
of
type
like
a
binding
type,
and
you
know
it's
within
the
realm
of
possibility
that
a
binding
type
like
a
secret
or
config
map
could
be.
You
know,
mountable
to
the
file
system
are
usable
with
the
downward
API,
but
but
really,
the
idea
here
is
that,
after
the
Service
Catalog
controller
has
delegated
a
buying
the
operation
to
a
service
broker
and
received
back,
you
know,
connection
details
and
credentials
that
it
will
at
that
point
populate
some
objects,
be
a
secret
or
something
new.
B
Yeah,
that's
what
I
was
looking
for.
It
sounded
to
me
like
it
might
be:
creating
a
secret
out-of-band
relative
to
like
the
service,
burger
API.
But
what
I'm
hearing
is
you
take
the
response
of
the
bind,
a
call
to
the
service
broker
and
turn
that
response,
which
is
only
characterizes
secrets
right
now
into
an
API
secret
right,
correct,
yeah,
okay!
Well,
don't.
E
Make
sure
one
thing
I
think
I
agree
with
this
might
want
to
make
clarify
the
service
instance,
the
top
left
hand
corner
you
talk
about
that
first
and
then
kind
of
went
over
to
the
Service
Catalog
uses
part
I'm
assuming,
though
the
the
service
instance
gets
created
by
tucking
service
broker.
First,
yes,.
C
B
Not
in
this
mall,
ok,
so
I
think
that
there
are
a
couple
terms,
are
overloaded
in
your
proposal
and
in
the
service
worker
API.
So
I
entertain
me
if
you
will
to
start
from
the
beginning,
so
in
Cloud
Foundry
what
you
do
when
you
want
to
use
the
services
of
broker
offers.
Is
you
want
to
come
in
that
adds
that
service
broker
into
the
class
boundary
I,
Cloud,
Controller?
B
Ok,
the
Cloud
Controller
then
calls
the
service
workers
catalogue
endpoint
and
pulls
back
a
list
of
services
that
that
service
Booker
offers
when
I'm
hearing
is
that
in
the
scope
of
your
proposal,
I
you're
proposing
that
operators
going
add
those
services
service
instances
manually
is
that
right?
Yes,.
C
And
and
I
will
yeah?
Would
you
like
me
to
touch
on
why
sure
yeah
I'm
interested
okay?
So
so
we
believe
something
that
we
have
been.
You
know
as
we've
been
working
on
steward.
Something
that's
come
up
frequently
that
that
we
believe
is
is
probably
a
use
case.
Is
that
a
cluster
operator,
an
administrator,
probably
wishes
to
curate
what
kind
of
services
are
available
within
a
cluster.
C
Now,
if
I
as
the
cluster
administrator
said,
you
know
what
I
don't
want
anybody,
provisioning,
sequel
server
services
for
use
with
this
cluster,
then
you
know
I
need
to
have
a
way
of
addressing
that
in
my
and
my
way
of
addressing,
that
is
that
operators
create
service
instances.
So
so
a
service
instance
is
something
is
a
kind
of
service
or
I'm.
Sorry,
a
service
class
is
a
kind
of
service
that
is
available
in
a
service
instance.
It
is
an
instance
of
such
a
service.
C
B
C
And
no
so
there
so
we
do
have
a
security
model
with
this
as
well,
which
we'll
get
into
in
the
last
couple
of
slides,
but
this
has
more
to
do.
This
has
less
to
do
with
security
and
more
to
do
with
with
curation
we're
looking
at
the,
and
this
could
be
wrong.
This
could
be
a
wrong
way
of
looking
at
it,
but
we
are
looking
at
the
catalog
as
the
things
in
the
catalog
are
curated
by
an
administrator
yeah.
A
If
I
could,
if
I,
could
just
put
this
in
sort
of
terms
of
how
you
would
do
this
in
cloud
foundry
an
operator
adding
a
service
class
is
roughly
equivalent
to
running
that
command,
that
spins
up
the
broker
and
then
an
operator
creating
a
service
instance
is
roughly
equivalent
to
running
the
provision
command.
But.
E
C
Maybe
you
know,
I
said
I
think
that
I
don't
want
to
sweep
this
under
the
rug.
What
what
I
want
to
do,
though,
is
if
we
can
push
through
against
the
examples,
I
think
it's
going
to
I
think
as
Aaron
said
before,
I
think
it
will
illuminate
some
things.
Okay,
all
right,
so
this
next
slide
I'm
not
going
to
speak
to
it's
a
big
diagram.
It's
only
for
reference,
so
I'm
going
to
share
the
debt
afterwards,
and
you
can
all
go
through
this
at
your
leisure.
C
It
looks
big,
it
looks
complicated,
but
I
think
everything's
in
there
I
don't
want
to
waste
time
talking
about
it,
we'll
get
into
the
examples
here.
So
the
first
example
here
on
the
left
is
an
example
of
a
service
class.
So
this
would
be
something
defined
by
an
operator
and
given
an
arbitrary
but
semantically
meaningful
name.
So
this
operator
has
called
this
one
post-press
small
and
through
a
service
ID
and
a
plan
ID.
This
reference
is
basically
an
actual
recipe
that
a
broker
that
has
been
installed
is
capable
of
fulfilling.
C
C
So
now
that
something
exists
called
postgres
small,
so
again
it's
an
arbitrary
but
semantic
semantically,
meaningful
name
we
see
over
here
on
on
the
right.
We
have
an
example
of
a
service
instance
and
the
name
it
has
been
given
is
zip
code
DB,
so
again,
arbitrary
name
but
semantically
meaningful.
You
know,
at
least
in
comparison
to
you,
know
these
very
opaque
identifiers,
like
service
ID
and
plan
ID
we're
trying
to
give
things
meaningful
names
and
in
the
spec
you
see
that
it
references
the
service
class
and
it
references
postgres
small.
C
B
It
could
be
any
broker
because
I
asked
because
it
sounds
like
it
might
be
indeterminate
which
broker
is
going
to
satisfy
this,
which
is
something
that
is
it's
a
notion.
That's
not
present
in
the
existing
body
of
work.
That's
like
a
cloud
foundry
on
the
on
service
workers.
So
in
the
compound
remodel
a
service
was
analogous
to
service
class,
has
a
a
relationship,
one
too
many
broker
to
services
relationship.
So
there's
one
broker
that
uniquely
offers
a
service
class
right.
C
E
G
G
You
know
something
that
speaks
my
sequel
protocol
and
you
can
sort
of
ask
for
generically
and
it
could
be
satisfied
by
any
number
of
different
brokers,
but
it's
not
something
that
we've
already
spending
time
on,
but
the
service
class,
the
sort
of
the
generality
of
it,
seems
to
speak
more
to
that
and
the
service
ID
plan.
Id
you
know,
obviously,
is
this-
is
right
in
the
line
with
crowdfunding
I
can't
imagine
those
those
being
generically
ordered
by
different
servers
right
yeah.
B
One
of
the
validations
that
you
perform
or
that
the
cloud
foundry
Cloud
Controller
performs
is
that
the
service,
ID
and
plan
ID
are
uniquely
identify
their
unique
identifiers
and
they
there
has
to
be
referential
integrity,
as
I
understand
it,
between
the
unique
ID
for
the
broker
and
the
service
ID
and
plant
ideas.
So
if
you
have,
if
you
have
a
broker
that
returns
back
a
service
ID
that
already
exists
from
another
broker,
that's
a
validation
error
and
that
will
prevent
you
from
registering
that
broker.
Yeah.
C
C
It's
it's
known
to
the
operator
that
they
have
a
broker
available
to
them
that
can
fulfill
the
service
ID
in
this
plan,
ID
and
they've
created
a
service
class
that
just
attaches
a
friendly
name,
a
friendly
semantically,
meaningful
name
to
that
service
ID
plan.
I
do
care,
that's
all
it
is
there
there
there
isn't.
You
know
that
there
isn't
any
assumption
here
that
there
might
be
more
than
one
sort
of
broker
out
there
capable
of
fulfilling
this
yeah.
E
I'm
at
this
service
class
is
sort
of
like
the
output
of
a
clap
find
a
register
service
broker.
When,
because,
at
the
end
of
the
register
service
broker,
you
get
basically
a
list
of
services
that
are
available
to
you
in
the
marketplace,
and
I
think
each
one
of
those
things
in
the
marketplace
represents
your
service
class.
Here
I
have
that
ready.
Yes,
that's
that's.
C
Correct,
that's
that's
very
similar
to
think
the
thing
that
you,
the
only
thing
that's
different
here
is
that,
because
this
is
defined
by
an
operator,
the
contents
of
the
the
catalog
arcuri
did,
you
know
we're
not
we're
not
just
querying
every
broker
and
saying
hey
what
are
all
of
your
offerings
and
then
blindly
dumping
them
into
the
catalogue.
Okay,
yeah,
my
minor
difference,
but
yeah,
okay,
it's
the
same
thing,
though.
C
E
C
Compare
that
to
what
you
see
on
the
right,
which
is
a
service
claim
that
the
name
of
that
claim
is
my
appt
DB
claim.
So
this
is
an
example
of
a
consumer.
Just
needs
a
Postgres
database
for
their
own
use,
they'll
populate
it
themselves,
they'll
manage
the
schema
themselves
through
migrations
or
whatever.
They
don't
intend
to
share
this
with
anybody.
It's
it's
dedicated
to
them,
so
they
have
in
the
spec,
called
out
a
particular
service
class
post-arrest
large.
C
So
that's
a
semantically
meaningful
name
for
a
service
class
which
identifies
a
service
ID
and
a
plan
ID
that
some
broker
is
capable
of
fulfilling
and
once
again
specified
the
target
secret
that
they
want
the
credentials
written
into.
So
what
happens
in
response
to
the
creation
of
the
one
on
the
left
is
just
a
vine.
What
logically
happens
in
response
to
the
one
on
the
right
is
a
provision
and.
C
Suppose
that's
a
possibility
again.
I
did
model
this
after
persistent
volume
claims
and
and
so
I
the
inspiration
from
there,
and
this
is
pretty
much
the
way
that
that
that
works.
You
can
call
out
a
storage
class
and
if,
if
a
suitable
volume
doesn't
already
exist,
it
will
be
dynamically
provisioned
for
you,
I'm,
just
really
just
following
the
same
pattern
here
and.
A
Also
I
wanted
to
mention
one
proposed
benefit
that
we
have
here
is
that
when
you
do
something
like
on
the
right
you're,
actually
it's
possible
that
you
could
actually
be
guaranteeing
mutually
exclusive
access
to
that
resource.
We
would
do
that,
of
course,
by
having
the
service
controller,
not
create
a
publicly
accessible
version
of
that
service
instance,
and
in
doing
so
it
would
prevent
anyone
else
from
binding
to
that
service
instance,
which
of
course,
would
make
that
guarantee
that
the
person
who
created
originally
the
claim
would
be
the
only
one
who
can
give
you
them.
Yeah.
B
I'm
going
to
see
more
exploration
of
these
concepts
because
I
there
there
is
a
notion
of
visibility,
I'm
in
cloud
foundry.
That
I
think
is
someone
tied
up
in,
like
the
last
few
stanzas
of
the
conversation
can
I
also
ask
like
I
see
that
you
get
a
secret
and
I
I
I'm
guessing
target
secret
is
the
secret
that
you
want
to
create
in
the
meeting
space
of
the
first
instance
right.
B
C
C
C
B
Yeah,
that's
something
that
I
HC
being
useful,
because
then
you
also
get
injected
with
service
links,
environment
variables
for
that
service
and
there's
demand
in
the
community
for
a
mechanism
to
allow
explicit
linking
so
that
we
can
stop
generating
massive
amounts
of
environment
variables
that
we
can
be
back.
This
notion
awesome.
F
G
F
To
give
some
people
a
little
bit,
who
aren't
familiar
with
the
purses
and
volume
claim
persistent
volume
model
a
little
bit
more
context.
So
the
reason
why
I
person
yeah
both
purses
and
volume,
claims
and
purses
volumes,
and
also
both
pods
and
nodes.
There
are
a
few
motivations
in
the
pods
and
nodes
case.
You
know.
Obviously,
nodes
are
shared.
Multiple
pods
can
be
bound
to
note
and
share
those
resources,
and
that
also
matches
some
use
case
for
services
instances.
They
can
be
shared
amongst
potentially,
multiple
claims.
F
Another
is
the
scope.
The
nodes
and
purses
and
volumes
are
cluster
scoped,
whereas
pods
and
purses
million
claims
are
namespace
coat
that
you
know,
the
idea
is
that
the
nodes
and
purses
and
volumes
are
provided
by
the
cluster
and
then
they're
consumed
by
specific
users
in
a
specific
name
space.
So
I
think
a
little
bit
unclear
whether
that
is
also
the
case
with
service
instances.
So
that's
something
worth
thinking
about
and
then
also
nodes
and
person.
Volumes
are
expected
to
be,
at
least
in
some
use
cases.
F
Free
provisioned,
like
nodes,
are
pretty
much
always
pre-provision
today,
modulo
some
cluster,
auto
scaling
that
we
would
like
to
dynamically
provision
them
more
aggressively
in
the
future
and
purses
and
volumes.
You
know
an
administrator
might
need
to
manually
provision
some
ahead
of
time
depending
on
what
their
storage
solution
is,
but
we
do
have
four
public
clouds
and
other
environments
that
supported
dynamic
provisioning,
and
you
know,
as
discussed,
I
think
dynamic
provisioning,
especially
for
what
are
effectively
single
tenant
services
makes
sense
in
this
as
well.
E
Get
free
before
you
funk
acid,
just
one
question:
I
apologize
if
this
guy
asking
they
got
dropped,
but
when
you
talk
about
binding
there,
you're
not
actually
binding
to
an
application
or
something
running
inside
and
communicate
right.
You
just
turn
the
secret
and
it's
now
up
to
the
person
who
wants
it
visible
inside
of
their
application
running.
It's
like
you,
pay
to
grab
that
secret
and
make
it
available
to
or
whatever
means
they
want
right.
Yes,
that's
correct.
Okay,.
C
You
all
right
so
so
somebody
was
just
you
know
talking
about
about
things
existing
either
within
a
namespace
or
within
cluster
scope,
and
I
can
actually
speak
to
that
a
little
bit
here,
because
we
did
think
through
some
of
that.
So
I
used
the
word
global
here,
but
I
probably
should
have
said
cluster
scope,
so
service
classes,
like
storage
classes,
we
were
imagining
to
be
and
they
cluster
scope,
but
an
admin
may
want
some
of
those
classes
provisional
within
some
namespaces,
but
not
others.
C
You
know
imagine
that
you
have
two
different
teams:
we're
sharing
space
on
the
cluster
and
one
of
those
teams
is
full
of
you
know
top-notch
developers.
You
trust-
and
you
know
they'll
clean
up
after
themselves,
and
you
don't
mind
if
they
go
provisioning,
certain
expensive
things,
because
they'll
clean
up
when
they're
done.
But
you
have
some
other
team,
you
don't
want
them
doing
that.
C
There
needs
to
be
a
mechanism
to
enforce
that,
despite
the
fact
that
that
this
is
in
a
cluster
scope
where,
where
the
usual
protections
afforded
to
you
by
name
spaces,
don't
necessarily
healthier.
So
we
would
propose
that
we
could
create
something
called
the
provisioning
policy
that
would
be
a
way
to
constrain
the
dynamic
provisioning
of
services
to
consumers
in
one
some
or
all
namespaces.
B
I'll
add
some
context
which
I'm
not
sure
is
well
socialized
yet
in
the
wider
community,
because
it
is
ongoing
in
the
storage
signal
and
we
have
some
folks
about
working
on
it.
So
the
with
storage
classes,
he
it
looks
like
we're
going
to
try
to
solve
the
problems
that
provisioning
policy
solves
with
quota,
so
that
you
can.
B
You
can
quota
the
number
of
claims
of
a
particular
storage
class
within
it
within
a
namespace.
So
there's
a
couple
facets
of
this
of
one
objects
that
are
quoted
right
now.
If
you
don't
have
a
quota
in
your
name
space
for
that,
you
have
unlimited
access
to
it,
which
is
the
opposite
of
how
we
wanted
to
work
root
for
storage
classes.
B
So
there's
a
facet
of
this
work
where
we
are
making
when
I
say
we
I
mean
the
community
across
red
hat
Google
other
companies,
the
community
is
making
it
possible
to
express
that
a
particular
resource
is
precious
somehow
so
that,
if
you
don't
have
a
quota
to
find
for
it,
it
means
that
you
have
zero
quota
and
then
the
other
asset
of
it
is
like.
How
do
you
express
a
quota
on
these
arbitrarily
defined
storage
classes
and
and
count
them,
and
the
method
that
looks
like
is
going
to
be
used,
for
that?
B
Is
that
we're
going
to
define
a
the
way
that
you
reference,
a
storage
class
and
quota
will
be
something
like
storage
que,
ASI,
o
/
name
of
class,
so
I
think
it's.
It
should
be,
hopefully
understandable
how
those
two
primitives
can
give
you
this
kind
of
policy,
but
I
just
wanted
to
throw
that
out
there,
because
it's
been
a
topic
of
some
discussions
that
I've
been
involved
with
recently
and
I'm,
not
sure
how
well
socialized
it
is
yeah.
C
I'll
say
again
that
that
I
think
it's
a
benefit
to
everybody
when
similar
problems
have
similar
solutions.
So
if
that
pattern
emerges
is
as
something
that's
a
you
know,
a
good
solution
for
this
kind
of
scenario.
I
think
absolutely
the
way
that
we've
envisioned
the
provisioning
policies
could
probably
you
know,
move
aside
and
be
replaced
by
this
like
quota
strategy.
B
C
I'll
check
all
right
and
then
really
the
last
thing
is
binding
policy,
which
is
similar
to
the
provisioning
policy.
This
is
more
applicable
to
the
multi-tenant
scenario.
So
if
you're,
an
operator
who
has
statically
provisioned
a
service
instance
expecting
that
that
others
and
multiple
namespaces
may
be
binding
to
it,
you
may
want
to
restrict
what
namespaces
are
able
to
do
so
so
it's
similar
to
the
provisioning
policy,
but
it's
more
about
who
combined
rather
than
about
coopervision
and
that
takes
us
to
the
end
I
think.
C
B
Really
awesome
presentation
thanks
a
lot
to
everybody
from
jsm
is
involved
in
that
I
see
that
we
are
nearing
the
end
of
nearing
the
end
of
our
a
lot
of
time.
I
I
think
we
all
probably
had
different
tolerances
for
going
over,
so
I
wonder
if,
if
we
can,
if
we
can
agree
on
a
couple,
major
points
and
perhaps
discuss
in
slack
or
in
proposals
to
the
incubator,
repo
some
of
the
finer
points,
so
what
I
wonder
from
folks
is
this?
F
G
F
B
B
F
I
just
have
a
couple
of
questions.
One
is:
are
you
working
towards
prototyping
this
pattern,
and
I
also
just
have
a
point
which
is
you
know?
People
have
talked
about
wanting
to
know
specifically
what
services
are
bound,
what
other
services,
and
one
thing
that
came
up
when
we
discussed
the
clay
model
before
I
think
with
red
hat
proposal?
F
C
So
to
the
first
question
of
whether
anybody
is
prototyping,
this
that's
a
yes
and
a
no!
So
internally
within
deus
as
we
as
we
cooked
up
this
presentation,
we
were
really
really
basing
this
on
a
couple
of
things,
one
being
as
I
said,
we
drew
inspiration
from
how
these
things
are
already
solved
with
in
Coober
Nettie's
and
other
problems
faces
like
persistent
volumes.
But
then
we
also
looked
at
it
from
an
angle
where
we
were
trying
to
imagine
the
types
of
resources
that
we
wished
existed
as
we
had
gone
about
implementing
steward.
C
F
F
C
So
so
Gabriel
actually
had
proposed
that
we
may
want
to
augment
this
proposal
and
add
in
another
type
of
resource,
called
a
like
a
service
binding
or
something
like
that.
So
that
would
be
another
first
class
resource,
something
that
you
could
actually
query
to
kind
of
understand
that
map
of
what's
bound
to
what.
E
F
C
B
So
when
one
thing
that
one
reaction
that
I
had
to
this
is
that,
as
a
an
operator
of
a
like
multi-tenant
online,
has,
I
would
prefer
not
to
have
to
manually,
enter
the
details
of
every
service
that
I
wanted
to
expose
from
a
service
broker,
and
so
my
own
thoughts
about
this
have
been
like
I
sort
of
expected.
The
sea
service
broker
API
object
and
not
to
derail
the
discussion.
I'll
try
to
do
my
give
a
concise
explanation
of
this
say
that
you
have
a
say
that
you
have.
B
The
the
service
controller
is
watching
that
api
resource.
You
add
that
resource
into
the
catalogue
are
the
you
add
that
resource
an
instance
of
that
resource
for
the
service
broker
that
you
want
to
add
and
the
the
controller
goes
and
calls
the
catalogue
end
point
on
that
service
broker
and
populates.
B
You
add
some
level
of
indirection
like
a
visibility
flag
or
a
specific,
or
maybe
a
policy
object
and
have
a
special
resource
that
is
named
spaced
that
Anton
a
namespace
can
call
the
sea
which,
how
log
entries
are
visible
to
them,
and
I
right
I
recognize
that
is
a
little
bit
of
my
new
show.
But
the
rod
stroke
is
that,
like
as
an
operator,
I
want
to
easily
be
able
to
see
a
resource
representation
of
which
brokers
that
I
have
which
workers
I
have
and
with
their
statuses,.
C
B
Okay,
so
doug
is
noted
that
we're
at
time
now
we
went
over
last
time,
but
meetings
running
over
is
kind
of
a
pet
peeve
of
mine.
So
I'd
like
to
keep
this
within
the
bounds
that
we
scheduled
I
ad
I,
think
that
we
can
continue
this
discussion
on
slack
I
think
this
was
an
awesome
presentation,
it's
a
huge
step
in
the
right
direction,
and
so
what
I
suggest
that
we
do
is
next
step
sis.