►
From YouTube: Kubernetes SIG Service Catalog 20161025
Description
SIG Service Catalog discusses what consuming a service looks like to the user.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
All
right
well
welcome
everybody
to
the
october
twenty
fifth
meeting
of
the
cooper
Nettie's
Service
Catalog
sig.
This
is
a
special
meeting
to
continue
discussion
from
yesterday
in
advance
of
our
face-to-face
in
Boulder
next
week.
So
today,
I
would
like
to
focus
on
a
single
use
case
and
really
even
arguably
just
a
single
facet
of
a
use
case
and
talk
exclusively
about
what
does
it
mean
qualitatively?
Let's,
let's
forego
any
implementation
specifics
and
maybe
we'll
get
there
if
we
can
come
to
a
qualitative
agreement?
A
A
B
C
And
dug
in
your
world,
do
you
envision
credentials
being
different
from
the
endpoint
it's
connecting
to
or
how
dress
like
in
the
in
the
credential
world
in
the
cloud
boundary
it
has
the
endpoint
baked
into
it
right,
that's,
basically,
a
host
port
user
and
password.
Is
that
what
you
think
in
here?
It's
all
the
same
thing
to
make
credentials
coordinates,
although
all.
A
Does
anybody
have
anything
they
want
to
add
to
that?
One
thing:
one
question
I
have
you
mentioned,
be
cash
services
I,
it
feels
like
be
kept.
Services
is
subtly
different
in
that
that
may
contain
multiple
bindings
to
multiple
services,
and
is
that
material,
yeah,
so
I
think
that's
a
good
point
just
to
call
it
out
to
folks.
It
may
not
be
familiar
with
the
cloud
foundry
model
in
the
cloud
foundry
model.
You
have
a
service
instance
and
you
can
bind
your
application
to
that
service
instance
and
what
happens
when
you?
A
A
So
I
was
that
a
cloud
application
yeah,
ok,
so
the
there's,
an
environment
variable
called
vcaps
services
that
gets
its
value
is
like
a
JSON
representation
of
both
the
endpoint
that
you
need
to
talk
to
to
work
with
a
service
and
the
credentials
and
like
username
password.
If
there's
some
kind
of
API
key,
they
all
go
in
to
this
JSON
struct,
which
is
the
value
of
the
speed
cab
services,
environment,
variable
and
write.
A
A
The
thing
that's
interesting,
at
least
from
my
perspective,
is
that
if
you
are
bound
to
multiple
instances
of
the
service
or
bound
to
a
service
multiple
times,
the
cap
service
is
a
little
bit
challenging
in
the
way
that
it
would
express
that
and
I
think
that
was
one
of
the
things
that
we
previously
discussed
is
wanting
to
support.
So
I
am
an
application.
I
need
for
my
sequel,
databases
and
I
want
to
call
you
know
blind
four
times
too
and
gets
different
service
instances
each
time
for
a
short
in
use
case,
for
example.
A
So
one
thing
that
I'm
hearing
in
that
I'll
pose
for
discussion
is.
Do
we
want
to
support
v
cab
services
is:
is
that
a
goal
that
we
have
to
make
it
so
that
an
application
moving
from
Cloud
Foundry
to
confer
Nettie's
would
be
able
to
not
change
the
parsing
of
vcap
services?
Is
that
something
we
want
to
do.
A
D
A
B
E
Yeah
I
think
it's
yeah,
that's
a
good
topic
for
a
future
discussion
about
how
we
actually
enable
that
you
know
for
sure.
If
applications
are
not,
clients
are
not
familiar
with
be
cab
services
today
and
then
the
way
you
would
do
this
without
the
service
broker
mechanism
is
you
adjust
play
the
secrets
and
or
config
map
and
use
the
downward
API
to
plumb
that,
in
whatever
form,
a
client
application
expected?
Are
they
that
the
environment,
variables
command
line
or
file.
E
A
E
I
think,
fundamentally,
you
know
the
credentials
will
get
and
should
get
captured
using
native
communities
mechanisms
and
there's
still
a
lot
of
flexibility
on
how
you
represent
things,
even
within
those
like
those
secret
and
can
pick
nap
or
return
key
value
maps
right.
So
there
could
be
a
variable
name,
decap
services
in
your
secret,
although
that
would
be
pretty
weird
because
it
would
contain
the
service
discovery,
information
as
well,
which
normally
we
would
put
in
a
service.
E
But
yes,
I
think
it's
I,
don't
know
it
makes
sense
for
there
to
be
one
standard
for
all
applications
versus
you
know.
Different
existing
conventions
for
different
applications
certainly
eventually
like.
If
we
look
at
how
this
works
inside
Google
there's
one
uniform
way
of
doing
it,
then
that
really
makes
it
easy
to
consume
arbitrary
services
from
any
other
application.
If
you
don't
have
to.
E
G
G
G
A
working
group
as
well
is
when
you
create
the
binding
that
maybe
you
can
provide
some
mapping
of
how
the
how
the
values
get
mapped
into
your
environment
and
I
could
imagine
that
doing
it
in
a
vcap
services
compatible
way
would
be
maybe
an
option
you
could
put
in
there
so
that
it
was
something
it
explicitly
say.
He
exposed
these
because
the
client
is
expected
in
the
cab
services,
horses
just
being
immoral.
F
G
A
There's
also
a
variable
substitution
feature
that
allows
you
to
compose
environment
variables,
the
values
of
other
environment
variables,
I'm,
not
sure
that
you
could
get
all
the
way
to
what
vcaps
services
is
I
think
you
could
probably
get
pretty
close,
but
if
it
might
be
a
bit
of
doing
with
the
current
feature
set.
So
I
think
I
think
the
synthesis,
though,
that
I'm
hearing
from
the
group
is
that
we
think
that
one.
A
E
F
E
A
Would
we
be
happy
to
sort
of
take
a
half
measure
and
say
that
the
credentials
thing
can
be
an
opaque
key
value
thingy
and
let
the
service
consumer
and
the
service
producer
pass
it
through
kind
of
like
Cloud
Foundry
doesn't
call
that
good
enough
for
v1,
rather
than
trying
to
tackle
the
tight
opinion.
Templating
situation
here.
E
F
One
of
the
pieces
of
information
I
would
like
to
see
is
some
kind
of
reference
to
documentation
about
the
service,
so
there
is
a
swagger
doc
or
something
about
service.
You
are
consuming
and
you
know
maybe
that's
available
within
that
service,
but
having
a
reference
to
it
from
phone.
The
catalog
I
think
it
would
be
captured
by
at
this
moment.
A
A
With
the
additional
information
that,
in
the
future
I
think
egress
is
going
to
be
incorporated
into
network
policy
and
just
a
tiny
piece
of
context.
One
of
the
use
cases
for
that
is
there
are.
There
are
cluster
operators
that
want
to
manage
the
connectivity
of
pods
to
the
outside
world
and
connectivity
of
pods
to
other
pods
and
namespaces
other
namespaces.
So
I
do
think
that
in
the
long
term,
probably
the
notion
of
consuming
a
service
has
to
include
network
connectivity
into
and
out
of
that
service.
A
I'm
not
I,
think
provisioning
is
kind
of
an
overloaded
term.
So
I'll
answer
that
question
more
generally
and
say
that
I
I
see
that
it
might
be
part
of
the
the
catalogs
responsibility
for
creating
resources
that
are
beyond
a
single
just
beyond
a
service.
A
secret
config
map
so
like
one
thing
that
I
could
see
happening
in
the
future
is
that
the
catalog
or
a
controller
could
be
responsible
for
creating
a
network
policy
object
in
the
consumers.
A
Namespace
that
made
it
possible
for
a
pods
that
are
running
in
that
namespace
that
match
a
certain
label
selector
to
to
connect
to
the
service
or
connect
to
the
endpoint
presented
for
community
service
for
a
Service
Catalog
service.
But
that's
a
little
prescriptive
and
in
violation
of
the
terms
that
I
said
now
where
we
were
not
going
to
talk
about
this
implementation.
Specifics
yet
so
forget
I
said
that
and
maybe
we
can
find
a
way
to
strike
it
from
the
recording
or
I'll
use
on
and
in
black
ya
know.
C
E
Yeah
and
so
already
it's
the
case
that
we
take
this
into
account
when
deploying
service
on
communities,
for
example,
if
you
create
a
service
of
type
load,
balancer
terminates
can
make
sure
that
firewalls
are
open
for
you
and
things
like
that.
It's
both
your
service,
so
you
know
I
think
it
does
make
sense
to
be
somewhere
part
of
this.
A
The
information
required
to
use
a
service
should
be
present
and
the
Cooper
Nettie's
native
concepts
it
should
be
or
should
be
realized
in
the
crew
benetti's
native
concepts.
It
should
be
possible
to
adapt
those
resources
into
a
format
that
and
application
can
consume.
There
is
some
threshold
between
our
on
one
end.
A
A
C
A
A
Let's
see
so
we
have
about
20
minutes
remaining.
Let
me
take
the
temperature
of
the
group.
Do
we
think
as
a
group,
it
is
better
to
continue
at
this
very
high
level
and
talk
about
another
use
case,
or
is
it
it
more
advantageous
to
talk
about?
What
does
this
look
like
in
terms
of
in
terms
of
the
native
humanity's
resources?
A
C
A
So
it's
like
they're,
reasonable
expectation
of
the
consumer.
Is
that
once
you
get
in
credentials
that
you
can
connect
to
the
thing
that
you
just
contradictions
for
okay,
I,
put
a
sentence
in
there
that
reads:
consuming
a
service
means
that
you
get
the
Cuban
Nettie's
primitives
containing,
coordinates,
credentials
and
configuration,
and
that
you
have
network
comment
connectivity
where
it
is
needed.
Does
that
encompass
everything.
E
Yeah
so,
as
I
said
in
the
email
thread,
I
don't
think
we
need
to
complete
everything
together
or
have
everything
to
have
a
useful
solution,
like
one
part,
is
actually
getting
credentials
that
you
can
access
somehow.
That
would
be,
for
example,
creating
a
secret
in
your
namespace
could
satisfy
that,
but
there
could
still
be
some
manual
work
to
consume,
that
into
your
container,
by
modifying
your
pods
back,
for
instance,
or
riding
in
an
it
container,
or
something
like
that.
E
A
So
I
think
that's
a
really
good
point
and
I
can
I
can
second
that
so
for
context.
I
have
actually
personally
worked
on
a
secrets:
config
map
downward
API,
a
fair
amount
and
the
overriding
like
design
intention
has
been
to
to
provide
like
an
eighty
percent
solution
that
allows
you
to
gather
remaining
twenty
percent
yourself
if
you're
not
satisfied
with
the
first
dating
so
I'll.
A
B
B
In
my
mind,
I
keep
waiting,
namespaces
and
Cooper
Nettie's
to
sort
of
like
spaces
in
in
Cloud
Foundry
right,
it's
just
a
space
where
people
can
upload
applications
to
and
and
it's
like-
maybe
a
department,
though
staging
area
for
example.
Is
it
one
particular
space
and
in
communities?
I
get
the
sense
that
namespace
is
something
similar
where
it's
not
meant
to
be
used
for
just
a
single
application,
and
it's
meant
to
be
a
place
where
you
can
group
applications
by
whatever
means,
or
whatever
group
mechanism
mean
something
to
you
right
and
I
would
sense.
B
Then
that
secrets
are
the
mechanism
by
which
sensitive
information
is
shared
and
secrets
are
namespace
scoped.
So
that
then
implies
that
secrets
are
in
essence,
visible
to
all
applications
within
a
namespace.
Now,
that's
somewhat
different
than
something
inside
cloud.
Foundry,
where
each
application,
even
if
they're
insane
space,
does
it
necessarily
see
the
secrets
or
in
this
particular
case
the
credentials
that
other
applications
are
using
to
talk
to
various
services.
So
there's
a
little
bit
of
annoyed
with
wanna
call
security,
but
there's
a
little
bit
of
separation
there
and
I'm.
A
The
separation
that
you're
discussing
implemented
via
vcap
services,
population
for
apps
and
so
like
within
a
space
you
may
have
multiple
apps
and
each
app
is
responsible.
Well,
someone
is
responsible
for
binding
each
app
to
a
service
that
it
has
to
use
and
they
get
injected
with
the
cap
services
based
on
those
bindings,
so
that,
amongst
the
applications
in
a
single
space,
you
might
have
varying
degrees
of
overlap
with
the
credentials
that
each
app
can
see
relative
to
its
peers
in
the
same
space.
Is
that
right,
yeah.
B
Basically,
each
application
have
its
own
vcap
services,
because
each
one
is
bound
to
a
different
service,
so
each
application
only
sees
the
credentials
for
the
services
that
it
talks
to,
which
is
I.
Think
somewhat
different
in
the
path
are
heading
down
with
communities
where
any
app
can
basically
grab
the
credentials
from
any
other
app.
As
long
as
they're
on
the
same
namespace,
yeah.
E
E
You
know
the
openshift
projects
on
so
you
know-
and
we
originally
discussed
that
this
might
be
similar
to
say
projects
in
GC
or
something
like
that.
So
you
can
think
about
it
as
a
scope,
for
maybe
a
single
team,
I
wouldn't
say
it's
a
scope
for
like
a
whole
department.
Probably
I,
wouldn't
recommend
that
maybe
a
cluster
would
be
a
scope
for
a
whole
department.
E
I
mean
all
the
pins
on
a
bunch
of
trade-offs
depends
on
how
big
your
clusters
actually
are:
tanzanite
operations,
teams
work
and
some
what
kind
of
separation
you
want
between
Deb
staging,
a
prod
and
all
kinds
of
things,
but
I
would
like
to
see
namespaces
used
officially
as
fine
grain
is
for
individual
applications
like
I
would
like
to
deploy
a
helm,
cart
into
its
own
namespace
and
facilitate
communication
across
namespaces,
because
namespaces
provide
a
really
convenient
scoping
mechanism
for
unique
affine
names
for
smoking
label.
Selectors.
E
For
providing
fine
grain
oo
authorization
using
something
like
role-based
access
control,
so
you
know
we
don't
have
a
lot
of
patterns,
we
don't
some
people
are
using
it
that
way,
and
there
have
been
a
couple
of
blog
posts
about
Lisa's
and
nays
music.
Don't
think
you'll
use
them
for
separating
dev,
staging
and
prod
other
people.
These
clusters,
for
that
so
I,
think
there's
a
pretty
broad
range
of
ways
to
use
namespaces
and
we
do
have
mechanisms
that
help
people
subdivide
namespaces
label.
E
Selectors
are
a
common
thing
out
a
common
way,
although
that
requires
agreement
effectively
among
everybody,
you
playing
in
the
name
same
name
space
as
soon
as
how
you
apply
labels
to
their
resources,
so
they
don't
get
overlapping
little
selectors
unintentionally
and
we
talked
about
mechanisms
that
would
potentially
forced
some
rules
about
about
labels
being
applied
on
projects.
But
we
don't
have
that
yet.
Yeah
there's
also
service
accounts.
C
E
I
was
getting
to
that,
so
you
can
actually
create
a
service
account
multiple
there's
a
default
service
account,
but
you
can
create
additional
service
accounts
and
for
individual
pods.
You
can
specify
which
service
account
you
want
to
use
and
the
service
account
can
be
used
to
restrict
what
secrets
can
be
accessed
federal
pods.
You
can
actually
put
a
list
of
secrets
on
a
service
account
and
say
this.
These
pods
can
only
access
the
secrets
that
provide
is
sort
of
a
defense-in-depth
a
little
bit
against
odds
grabbing
secrets
from
someone
else.
E
It's
also
sort
of
an
comment
on
the
user
to
set
up
whatever
authorization
rules
say,
are
back
rules
for
control
allowing
which
users
and
service
accounts
can
access
which
resources
within
the
namespace
I've
actually
just
about
to
start
a
thread
on
sig
on
about
making
it
easier
to
do.
/
object
access
control.
You
can
express
that
with
our
back
today,
but
it's
really
cumbersome
and
I.
Think
the.
C
So
it
sounds
like
we
can
do
all
of
everything's
here
and
if
it
almost
seems
like
a
cop-out
to
go
and
say
it's
a
service
and
user
has
to
do
everything
to
go
ahead
and
have
a
setup
that
sort
of
kind
of
works
I
mean
that's.
What
I'm
I'm
really
feeling
a
little
bit
positions
here,
but
we
are
basically
saying
will
slap
a
secret
in
namespace
and
it's
up
the
user
of
the
posture
than
the
go
ahead
and
know
all
the
right
things
to
make
sure
the
right
things
happen.
C
A
That's
just
my
opinion,
so
Brian
do
do
I.
Have
it
correct
that
you
think
namespaces
are
a
good
at
starting
a
starting
border
of
encapsulation
to
work
around
for
the
catalog,
with
the
implication
that
we
can
get
into
finer
grain
mechanisms
like
service
account,
service
accounts
and
label
selectors
at
a
later
time,.
E
A
So,
just
just
some
extra
context
on
that
dive,
like
I
have
seen
namespaces
of
all
different
sizes,
I've
seen
name
spaces
that
have
a
single
app
I've,
seen
namespaces.
That
team
share
and
I
think,
like
part
of
part
of
the
promise
empower
communities,
is
that
it
allows
cluster
operators
to
have
some
discretion
in
how
they
provision
namespaces
and
what
what
dividing
lines
they
use.
A
I
tend
to
agree
with
Brian's
Brian's
sentiment
that
initially
namespaces
are
probably
a
good
granularity
to
look
at
divisions
among,
and
we
can
definitely
add
things
like
a
service
account
scoping
of
secret
visibility
at
a
later
time.
But
it's
probably
useful
for
the
initial
discussion
to
focus
on
spaces.
A
B
I
was
actually
very
glad
that
you
guys
mentioned
the
idea
of
one
app
her
name
space,
because,
even
though
I
don't
really
like
that
as
an
approach,
it
I'm
glad
that
it's
not
google
insane
to
think
of
it.
That
way,
if
you
did
want
that
level
of
security,
as
for
the
rest
of
it,
yeah
I
need
to
go
back
and
think
more
about
it,
but
I
have
a
feeling.
You
guys
are
probably
right
that
that
main
space
is
part
of
the
right
scope
for
this
stuff.
B
F
A
The
question
is:
when
there
is
a
user,
a
UI
for
the
catalog,
what,
as
a
particular
user,
what
services
do
you
have
the
ability
to
see
we
do
have
we've
been
calling
that
that
concept
curation
so
far
and
we
do
have
use
cases
that
we
have
that
I
put
into
a
github
issue
that
I
created
around
it
so
you're
that
that
is
not
a
question
unique
to
you
I,
wonder
though,
if
it
might
be,
actually
we
have
five
minutes
left.
So
maybe
we
can
table
that
for
now
and
see
a.
A
F
Catalog
of
services
that
I
can
consume
and
I
initially
was,
was
thinking
that
would
be
all
those
old
services
in
your
namespace
like
by
default,
and
everything
else
would
be
an
external
service
but
which
we
only
have
one
yep.
It
is
possible
to
only
have
one
service
for
namespace.
The
catalog
isn't
much
use.
A
The
I
think
perhaps
there
may
have
been
some
confusion
about
the
deployment
of
applications
into
namespaces
and
how
how
deep
or
wide
is
a
namespace
and
what
we've
been
talking
about
is,
as
a
initial
assumption,
the
assumption
that
there's
really
fundamentally
only
a
single
application
in
a
namespace
so
that
we
can
defer
a
discussion
of
things
about
further
subdivided.
Namespaces
like
service
accounts
label,
selectors
are
back
etc.
Until
later,
does
that
clarify
things
at
all,
I.
E
Mean
especially
if
we're
focused
on
the
black
box
case,
mainly
initially,
you
would
expect
the
black
box
service
to
be
somewhere
else,
not
sign
your
name,
space
walk,
you
run
your
stateless
front
end
and
it's
consuming
a
database
or
something
like
that.
I
already
SPECT
out
to
be
a
common
case.
Yepper.
A
A
So
we
have
about
three
minutes
left
I
think
this
is
this
been
a
really
good
discussion?
I
think
this
clarifies
things
a
little
bit
further
I
wonder
if
we
have
a
volunteer,
who
will
put
their
hand
up
to
write
this
up
into
a
use
case
and
submit
a
pull
request
to
the
incubator
repo
to
capture
this
concept.
A
I'm
happy
to
help
collaborate
on
that.
If
you
want
okay
I
well,
do
you
want
to
take
the
token
so
to
speak
or
take
the
baton
on
that
one
Jason
and-
and
we
can
put
our
heads
together
when
you
make
a
pull
request
or
before
it
sounds
good
awesome.
Okay,
anything
else
in
the
remaining
two
minutes
that
we
have.
B
Like
that,
I
could
help
arrange
that
so
speaking,
just
for
myself,
I
personally
would
love
that
kind
of
thing,
but
I
wouldn't
want
to
subject
the
entire
group
to
that,
because
I'm
feeling
I'm
more
new
than
most
people
here
so
I
went
mind
like
a
very,
very
optional
phone
call
for
that
information.
I
went
want,
may
get
an
official
meeting,
though
just
because
I
don't
be
able
to
feel
like
they
have
to
show
up,
but
I
would
love
to
get
that
gun
in
background
yeah.
A
I
think
that
would
be
useful.
I
am
wondering
to
myself
whether
such
a
deep
dive,
worse
shallow
dive
so
to
speak,
already
exists,
but
we
can
certainly
schedule
something
and
record
it
and,
as
as
you
all
know,
I've
been
recording
the
meeting.
So
whatever
comes
out
of
that
is
something
that
we
can
share
with
the
the
community.
E
Okay
and
yeah
I
guess
just
one
other
thing
I
would
point
out,
is
a
lot
of
these
effects
have
been
discussed
in
the
past
before
the
service
broker
idea
was
proposed
and
I
think
many
of
them
will
still
want
to
implement
independent
of
the
service
broker.
Okay,
come
up
with
a
way
of
automatically
injecting
secrets
into
pods
ones,.
E
You
know
in
particular,
a
bunch
of
like
a
prudential
credential
generation
is
something
we've
discussed
for
a
long
long
time
and
I
think
that
would
be
a
useful
thing
to
support
independent
of
this
one
mechanism
as
well.
So
I'll
try
to
point
out
those
existing
issues
and
discussions
where,
where
they
come
up
and
we
can
try
to
figure
out
how
to
make
sure
that
they
work
really
seamlessly
but
for
the
service
broker,
but
also
that
is
possible
to
invoke
them
independently.
A
Where
appropriate,
yeah
there's
I'll
give
a
big
plus
12
that
Brian
I've
been
trying
to
to
call
out
things
that
are
areas
where
we
can
make
some
advancements
in
the
core
that
are
usable
by
everybody,
but
I.
Think
I,
think
that
is
one
of
the
cross-cutting
value
adds
that
we
can.
We
can
provide
in
the
sig,
is
making
advancements
on
those
things,
and
also,
I
will
call
out
that
I
am
hoping
to
have
automatic,
secretive
or
config
map
injection
in
environment
variables
proposal
out
pretty
soon
me
or
somebody
from
my
team
all
right.
A
B
C
B
E
So
and
the
mailing
list
hasn't
been
used
very
much
I,
don't
know
if
people
are
using
slack
and
honestly
do
to
my
meeting
schedule
and
whatnot
I
can't
pay
attention
to
slack.
So
you
know
people
one
kind
of
broader
participation
that
personally,
would
prefer
the
you
did.
A
mailing
list
or
github
issues
idea
has
its
own
challenges,
getting
how
many
zillions
of
notifications
I
get
from
gabe,
but.
E
A
Okay,
well
maybe
in
advance
of
tomorrow,
then
we
can
discuss
both
the
agenda
and
the
specifics
of
the
items
on
the
agenda
in
advance
of
tomorrow's
meeting
and
try
to
work
more
asynchronously
all
right.
Thank
you
very
much.
Everybody
for
attending
it
is
appreciated
and
I'll
see
you
all
on
the
Internet
yeah.