►
From YouTube: Kubernetes SIG Service Catalog 20161031
Description
Special Halloween Edition. SIG service-catalog meets to discuss use cases for service producers and whether we should attempt to ease creating service brokers.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
Alright
welcome
everybody
to
the
halloween
two
thousand,
two
thousand
sixteen
edition
of
cigs
Service
Catalog,
I'm
your
host
Paul
mortuary
and
today
I
would
like
to
switch
things
up
from
the
last
few
meetings
and
let's
talk
about
what
does
it
mean
as
ache?
We've
talked
a
lot
about
consuming
services.
Let's
talk
about
producing
them
and
we
are
less
prepared
for
this
discussion
and
we
were
for
the
last
use
case
discussion.
We
have
no
list
already,
so
what
I
can
do
is
share
my
screen.
Yes,
thank
you.
Doug.
A
A
A
Can
make
no
recommendations
on
the
wisdom
of
trying
to
compete
with
the
pink
mohawk
alright,
so
I
just
did
a
very
brief
brain
dump
into
this
comment
here.
I
think
there
are
three
use
cases
fundamentally
and
the
first
one
I'll
just
dump
them
out
there,
and
then
we
can
discuss
the
first
one
is
on
like
a
SAS
provider
or
someone
that
runs
an
existing
service
broker
and
I
want
to
also
have
my
service
broker
published
services
into
a
coup.
Brunetti
service
catalog.
A
The
second
one
is
as
a
kubri
Nettie's
user
I
want
to
run
my
own
service
workers
so
that
I
can
participate
in
that
ecosystem
and
then
the
third,
which
really
should
have
been
the
second
in
hindsight.
But
the
third
is:
I
want
to
share
I'm
a
cougar,
Nettie's
user
and
I
I
have
here.
I
want
to
run
my
own
service
broker
so
that
I
can
share
services
in
my
name,
space
with
users
and
other
namespaces
I.
A
C
I'd
love
to
talk
about
a
number
two.
Just
so
I
can
understand
it
a
little
more
so
I
guess
the
scenario
is
your
queue,
brunette
ease
developer,
you
filled
some
API
and
you
want
to
publish
that
too
to
what
I
think
that's
I.
Think
that's
probably
my
first
question
is
it's:
is
it
too,
like
some
master
global
service,
catalog
lists
that
exists
out
there
and
if
so,
what
are
the
types
of
things
that
I
would
need
to
think
about
monetization
anyway?
A
The
number
to
use
case
to
me
is
like
I
might
be
crossing
the
streams
a
little
bit,
but
the
number
to
use
case
is
I
want
to.
I
want
to
run
a
service
in
Korea
Nettie's
that
users
of
the
service
worker
API
can
consume
that
may
themselves
not
be
other
crew
benetti's
users,
so
they
may
be
users
of
cloud
foundry.
They
may
be
users
a
another
orchestrator
that
that
also
uses
the
serviceworker
API
a.
C
C
A
And
I'm
I'm
comfortable
striking
number
two
for
now.
I
I
think
that
if
we
can
do
number
three,
we
can
probably
do
number
two.
So
I
is
anybody.
Does
anybody
disagree
with
focusing
on
the
first
and
third
use
cases
in
this
list
here
which
are
using
existing
service
brokers
in
the
catalog
and
then
sharing
services
across
namespaces
in
Coober,
Nerys
I
have.
D
D
Have
said
number
one:
okay,
it
is
out
dress
both.
I
see
it
as
different
from
number
one,
because
it
may
not
be
an
operator
of
a
service
broker.
You
may,
as
let's
say,
you're.
You
know,
SAS
provider
a
you
may
not
have
a
service
broker
already
may
have
not
built
one
and
as
far
as
number
3
goes,
the
service
would
not
necessary
inside
of
your
cluster
and
certainly
may
not
necessarily
exist
inside
of
a
namespace
in
your
cluster.
F
F
B
About
to
start
backwards
in
start
number,
three
for
a
sec.
Just
out
of
curiosity,
when
you
wrote
that
are
you
assuming
that
the
equivalent
of
a
service
instance
create,
would
create
another
instance
of
the
service
in
you
as
a
service
owner's
name
space,
or
it
would
create
something
inside
the
consumers
namespace.
These.
B
E
A
A
G
Maybe
not,
but
that's
what
I'm
thinking
is
the
that
there
is
going
to
be
a
mode
where
stuff
is
going
to
be
running,
that's
being
huntsman
up
and
everything
else
like
that,
and
then
there's
some
stuff
that
is
being
consumed
and
and
and
operated
on
using
this
this
catalog,
but
they
should
seem
less.
We
played
together.
A
A
Starting
over,
let's
formulate
the
use
cases
I,
I
would
suggest
for
the
first
one
and
I'm
going
to
type
this
into
the
the
the
notes
in
books
can
make
suggestions
in
Google,
Docs
or
verbally
that,
as
a
and
operator
of
a
cooper
Nettie's
service.
I
want
to
share
that
service
in
the
catalog
and
allow
users
of
other
namespaces
to
use
my
service
I.
A
A
H
D
D
H
A
Think
if
in
the
state
that
is
in
here
now,
the
difference
between
these
two
is
the
implication
that
in
the
first
one
the
operator
is
the
party,
that's
exposing
this
service
into
the
catalog
and
in
the
second
one.
Obviously
the
cluster
operator
is
doing
it.
Do
we
think
that
that
is
something
that
is
accurate?
It
should
be
retained,
or
should
we
edit
the
first
one.
A
So
since
we
have
about
40
minutes
left,
we
could
we
could
continue
talking
through
these
and
exploring
like
what
we
think
the
experience
is
like
or
we
could
move
on
to,
or
we
could
circle
back
to
the
other
use
cases
I
I
I
feel
like
this
is
progress,
but
there's
something
that
I
can't
put
my
finger
on
that
is
probably
or
that
is
missing
about
it.
I
guess.
B
Well,
I'd
like
to
dig
a
little
deeper
because
I
feel
like
the
use
case
is
a
fairly
high
level
and
by
kind
of
said
earlier,
I
feel
like
they
kind
of
boil
down
to.
I
want
to
create
a
service
broker,
so
I
wouldn't
mind
kind
of
brainstorm.
A
little
and
a
little
bit
is
for
my
own
selfish
reasons.
I
like
to
sort
of
understand
a
little
bit
more
about
kerber
Nettie's,
and
what
do
we?
B
What
do
people
think
would
be
a
crew
benetti's
thing
we
can
do
to
make
life
easier
for
people
to
create
a
service
broker.
Are
their
existing
patterns
and
cybernetics
for
doing
this?
They
or
is
it
completely
wide-open
and
at
anything
we
come
up
with
to
help
people
create
their
own
service
broker,
is
completely
new.
A
So
that's
a
good
question.
I
personally
I
think
that
so
I
think
it's
reasonable
to
facilitate
sharing
kubin
any
services
via
service
burgers,
because
one
surface
burger
API
already
exists.
It's
obviously
not
perfect,
but
using
it
lets
us
avoid
creating
something
new
which
I
would
prefer.
You
know
not
to
do
unless
we
had
a
very
strong
reason
to
do
so.
What
does
everybody
else
think
about
that.
C
C
Don't
know
if
it's
worth
brain
strain
but,
like
you
know,
do
we
envision
something
like
a
wizard
where
somebody
wants
to
share
something
like
the
first
thing
that
says
yes,
what
would
you
like
to
name
your
service
and
then
you
want
to
say
well
for
each
your
user?
Do
you
want
to
provision
a
new?
You
know
sort
of
resources,
if
so
link
off
to
the
mountain
charge
and
over
to
do
that
I'm
kind
of
just
hoping
that
maybe
it's
it's
not
such
a
start
from
scratch.
C
A
So,
like
one
thing
that
seems
like
it
would
definitely
be
a
possibility
is
that
we
could
build
a
skeletal
service
broker
that
had
the
bits
for
the
web
server
and
implemented
the
the
different
rest
endpoints,
that
the
service
broker
API
excuse
me,
expect
star
to
be,
but
then
to
fulfill
each
of
those
endpoints
calls
out
to
a
user-provided
entry
point
so
that
to
write
your
own
service
broker,
you
can
take
a
take
this
image
and
add
an
extra
layer
to
the
file
system.
That
has
the
entry
points
for
the
different
API
calls
right.
B
J
40,
please:
hey
yeah,
the
in
similar
similar
space,
there's
a
mesosphere
universe,
which
is
something
we
could
take
a
look
at,
but
I
actually
think
the
dais
proposal,
for
this
showed
the
prototype
that
they
were
working
on
is
sort
of
points
in
the
right
direction.
You
know
I
think
there
are.
The
broker
is
going
to
be
deployed
more
than
anything
else
to
a
the
deployment
technology.
J
So
I
think
there
are
some
primitives
and
communities
that
are
needed,
even
if
you're
not
sharing
your
application
with
other
applications
on
Cooper
Nettie's,
but
you're
just
you
know,
running
an
application
and
you
want
pls
credentials
or
something
like
that.
So
I
think
there's
some
general
mechanisms
there
and
then
you
know
if
people
build
a
helm
service
broker
and
an
open
shift,
template
service
broker
and
a
deployment
manager,
service
broker
and
an
ansible
service
broker
or
whatever.
J
Then,
if
you
have
some
deployment
templates
that
will
work
with
that,
the
point
of
mechanism,
you
could
potentially
just
register
a
different
repository
and
using
an
existing
off-the-shelf
service
broker.
All
right
that
would
be
I
think
completely
reasonable
if
you're
running
a
service
already
in
communities-
and
you
just
want
to
share
across
namespaces-
and
this
is
something
that
we've
is
at
if
you're
not
running
network
policy,
constraint,
network
policies
or
authorization
rules,
it's
something
that
just
works
today
and
the
service
broker
shouldn't
strictly
be
necessary.
J
J
A
A
What
I
wonder
I
was
thinking
about
this
over
the
weekend
is
I
was
trying
to
think
about
sort
of
the
continuum
of
complexity
for
responses
to
or
actions
that
needed
to
happen
in
response
to
a
provision
in
buying
calls
I
think
the
absolute
simplest
is
of
the
form
you
have
a
you
have
like
a
Cooper
Nettie
service.
You
don't
care
about
tenancy,
you
don't
really
have
any
need
to
differentiate
credentials
across
users,
or
maybe
you
don't
have
credentials
that
are
required
period
with
the
most
complex
being.
A
J
Not
saying
that
service
brokers
are
not
needed,
I'm
just
saying
I
think
you
know
some
less
than
say
dozen
service
broker
implementations
will
satisfy
a
lot
of
needs.
You
know
force
as
providers
I,
don't
know
how
much
commonality
there
is
among
SAS
provider,
sort
of
provisioning
and
binding
protocols,
so
that
remains
to
be
seen.
But
you
know,
Google
Cloud
announced
a
cloud
foundry
service
broker
recently
for
some
of
its
more
popular
services.
J
I
would
love
to
be
able
to
just
that,
use
that
in
communities
to
get
cloud
sequel
or
bigquery
or
whatever
it
is
and
have
similar
ones
on
amazon,
you
know
if
it
becomes
commonplace
that
allah
providers
built
provide
a
service
broker
api
for
their
existing
services.
Then
that
will
just
be
something
that
users
don't
have
to
worry
about.
They'll
get
that
for
free
when
they
run
cobra
Nettie's,
on
whichever
cloud
they're
trying
to
use
I.
D
Think,
there's
kind
of
there's
two
vectors
here.
One
is
what
was
mentioned
earlier:
kind
of
a
skeleton
service
broker
and
such
a
service
broker
could
be
used
to
create
such
a
skeleton
could
be
used
to
create
a
broker
for
whatever
cloud
provider
fairly
simple
you
all
you
have
to
do
is
just
decide
what
provision
means
for
that
thing
and
then
implement
it,
but
on
the
other
side,
Brian
I
think
you
may
have
alluded
to
this.
D
D
E
That
couldn't
that
command
mode
be
implemented
with
you
know,
with
a
service
broker
front
end
on
it.
So
I
mean
I,
know
your
demo.
You
should
have
had
as
a
standalone
separate
thing,
but
it
seems
like
a
trivial
to
actually
implement
such
a
service
broker.
That
was
generic
and
could
be
used
by
anybody
that
it
took
an
image
and
there
and
a
command
line
or
scripts
or
whatever.
D
Yeah,
that's
an
option
to
effectively
they're
the
same
thing
from
a
producer
standpoint
in
that
you
give
something
an
image,
and
you
tell
the
person
who
created
the
image
that
there's
a
there's
a
specification
for
what
the
command
that
will
be
run
inside,
that
image
will
do
and
what
I
must
return.
What
standard
in
looks
like
what
Center
out
looks
like
so
on
so
forth,
yeah.
A
A
A
C
A
C
C
Another
question
and
I
don't
know
if
we
can
want
to
discuss
this
but
like
as
if
I'm,
creating
the
service
worker
and
I
want
to
register
it
as
part
of
a
catalog
experience.
What
what
metadata
am
I
going
to
be
published
in
what
schema
am
I
going
to
be
using
to
describe
said
metadata?
Do
we
have
anything
out
there?
Yes,.
A
So
there
is
a
the
the
schema
is
dictated
by
the
service
broker.
Api
right
now,
like
if
you're,
if
you're
using
a
cloud
foundry
service,
broker
that
the
API
spec
dictates
like
the
content
and
structure
of
the
response,
and
that
that
part
of
that
API
and
response
messages
include
metadata
about
the
service.
D
D
D
Concerns
you
wanted
to
co
on
just
that.
Basically,
it's
just
basic
off
I
think
the
least
we
should
do
is
is
enforced
basic
auth
over
TLS
I,
actually,
don't
know
if
the
surf
broker
API
specifies
that
must
be
over
HTTPS,
but
if
we
do
keep
the
basic
auth
I
think
it
needs
to
at
least
be
that
for
purposes
of
the
Service
Catalog
API.
B
So
Aron
does
or
anybody
else
if
you
like,
you
can
also
join
the
service
worker
working
that
that
we
have
and
over
in
the
CNCs
land
x.
I
guess
not
really
cnc
avatar
in
between
where
we're
looking
at
making
some
modifications
a
specification.
So
we
welcome
to
put
over
there
too,
but
you're,
not
the
only
one.
That's
had
some
concerns
about
the
security
guy.
D
H
One
thing
that
I've
considered
as
as
you
start
thinking
about
a
broader
economy
of
service
brokers,
is
who
gets
to
name
what
and
wire.
So
if
you've
got
like
an
off-the-shelf
remote
service
broker
endpoint
and
it
exposes
plans
a
B
and
C
or
services.
A
B
and
C
with
plans
x,
y&z
name,
collisions
for
those
service
plan,
Perry
air
thing
or
just
come
into
question
kind
of
across
the
board.
H
A
If
memory
serves
I
believe
that
the
question
of
naming
collisions
isn't
handled
so
much
in
the
spec
as
identity
of
services
and
plans
is
based
on
their
their
grids,
so
each
service
and
plan
has
a
quid,
and
that
is
that
is
the
the
material
part
of
that
thing's
identity.
So,
and
if
anybody
can
correct
me
on
this,
I
would
love
to
know
if
I'm
wrong.
My
reading
of
the
docs
indicates
that
name
collisions
seem
like
they're
fine,
but
graded
collisions
are
not.
A
A
A
J
In
general,
and
as
you
mentioned
for
you
IDs,
those
are
generated
in
such
way
that,
with
high
probability,
their
unique
across
all
space
and
time
and
names
within
a
other
names
resource
names,
if
you
want
them
to
be
unique,
we
use
them
as
the
primary
key
in
a
CD,
and
there
can
be
only
one
at
any
given
time.
That's
the
fully
qualified
name,
including
namespace,
if
it's
a
namespace
resource
and
cluster,
if
it's
a
cluster
local
resource,
so
there
this.
A
Is
in
addition
to
what
you've
said:
Brian
there
is
some
some
mapping
or
disambiguation.
That
needs
to
be
done
once
we
get
further
into
this
to
say
the
so,
for
example,
the
the
coordinates
that
are
passed
along
in
the
cloud
foundry
service
broker.
Api
don't
match
one
to
one
with
the
types
of
coordinates
that
we
have
in
Cooper
Nettie's.
So
there
is
a
an
organization
and
then,
within
that
organization,
a
space
where
space
aligns
fairly
well
too
namespace.
A
But
organization
is
some
intermediate
thing
that
is
higher
level
than
what
our
namespaces
would
be
in
Cooper
Nettie's.
That
encompass
is
multiple
ones,
but
is
like
a
higher
level
of
hierarchy
that
we
don't
have
in
Cuba
Nettie's.
So
there
is
some
task
which
is
figuring
out.
How
do
Cooper
Nettie's
coordinates
map
into
this
API
and
how
you
would
fill
out
that
piece
of
a
request,
API
request
to
a
cloud
foundry
broker.
A
We
have
discussed
removing
the
CF
isms
from
the
API
there's
a
pull
request
for
it.
It
has
emerged
I,
I
feel
like
the
feet.
Org
and
space
coordinates
are
a
CF
ism
Doug.
Do
you
happen
to
remember
whether
that
pull
request
addresses
those
things?
I
know
that
we
talked
about
it
on
the
last
working
group
meeting
yeah.
B
J
H
B
It
depends
on
which
flow
you're
talking
about
say,
for
example,
the
create
service
instance
flow.
It
actually
gets
created
by
the
client
of
the
flow,
the
roads,
Cloud
Foundry
platform.
In
this
case,
when
he
talks
to
service
broker,
he
tells
the
service
broker
what
good
to
use
and
I
believe
from
a
historical
perspective,
but
the
reason
they
did,
that
is
to
make
the
call
item
potent
that
way.
If
you
could
replay
it
and
be
guaranteed
that
you're
going
to
be
creating
a
new
one,
every
single
time,
you're
going
to
get
the
same
thing,
yeah.
A
Yes,
so
those
squids
are
also
used
to
track
changes
when
a
broker's
updated
in
the
cloud
foundry
marketplace.
So
one
interesting
thing
that
that
differs
is
that
you
can
rename
service
brokers
in
a
cadre
marketplace.
That
does
not
seem
like
something
that
is
a
goal
for
us,
but
there
is
some
ability
to
rename
brokers
and
I
believe
also
that
you
can
rename
that
you
can
change
the
display
name
for
a
service.
A
A
B
I
I
Thanks
yeah,
you
bet
you
and
I
had
chatted
about
sort
of
how
we
want
to
get
people
kind
of
aware
of
the
same
same
domain.
That's
been
discussed
over
the
course
of
many
many
sig
Service
Catalog
meetings
and
at
least
I
and
a
few
others
would
like
to
see
demos
of
the
service
brokers
that
were
presented
a
while
ago.
So
one
of
those
was
from
the
Google
team,
I
think
Wesson
you
and
be
like
present
hit
that
one
that.
I
C
I
A
K
Hey
guys
stand
here,
I'm
new
to
this,
the
cig
up
attend
a
couple
times,
just
listening
in
mostly
and
tried
not
to
interrupt
just
curious
with
the
high
level
plan,
as
sounds
like
you
guys,
are
meeting
in
Boulder.
What's
the
strategy
time
frame
or
implementing
anything,
next
steps
like
from
a
high
level
perspective,
so.
A
At
this
moment,
I
would
like
to
agree
on
a
scope
for
v1
that
we
think
is
achievable
in
maybe
a
couple
of
months
two
to
three
months,
and
my
gut
tells
me
that
if
we
can
get
agreement
on
use
cases
and
on
the
mechanics
of
the
API
that
implementing
that
API
and
those
mechanics
will
be
far
less
effort
than
the
initial
agreement
was
it's
my
general
feeling
on
software
projects
so
I'll
and
I'll.
Let
anybody
else
speak
for
themselves,
but
that's
kind
of
where
I'm
at
right
now.
K
A
So
the
advantage
of
using
the
cloud
foundry
service
broker
API,
as
at
least
one
supported,
backend
API-
is
that
it
one
already
exists
to
has
an
ecosystem
behind
it
and
I
think
that
it's
good
for
expediency
not
to
have
to
invent
something
new,
especially
when
there
is
an
existing
effort
to
evolve.
That
API.
That
some
of
the
folks
in
this
in
this
group
are
already
working
on
I.
A
Do
think
that
we
have
to
be
able
to
support
different
back-end
api's,
like
I,
think
that
we
should
assume
that
eventually,
the
working
group
will
introduce
a
backward
and
compatible
change.
That
means
that
you,
the
users
of
that
API,
will
have
to
adapt
their
their
existing
implementations
in
that
the
folks
that
are
implementing
things
like
Service
Catalog
and
the
cloud
foundry.
A
Plaid
controller
will
have
to
handle
different
differentiate,
their
handling
of
things
according
to
the
backend
version
of
the
protocol
or
version
of
the
API
that
each
particular
broker
they
want
to
use
uses,
and
there
are,
there
are
parts
of
the
problem
space
that
aren't
really
covered
by
the
service
broker.
Api,
like
the
service
broker,
a
PIAA
is
necessarily
black
box.
A
There
I
think
there's
a
fairly
strong
interest
in
the
group
for
doing
white
box
and
Cuban
Eddie's,
but
we
have
been
attempting
to
keep
the
problem
spaces
narrow
as
possible
to
decide
on
like
what
the
right
nucleus
for
the
API.
It's
you
know.
The
other
kind
of
fundamental
questions
in
the
problem
space
are:
does
that
make
sense.