►
From YouTube: Kubernetes SIG Service Catalog 20161003
Description
Summary: SIG Service Catalog is presented with two demos of two different prototypes for integrating Kubernetes with the Cloud Foundry Service Broker API and ecosystem.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
C
D
For
sure,
alright,
thanks
thanks
for
giving
us
some
time,
I'm
going
to
go
ahead
and
go
through
a
quick
deck
talking
about
how
we're
thinking
about
service
broker,
we've
got
new
projects,
we're
calling
steward
so
I'll
give
it
ensures
that
and
then
aaron
from
from
the
dais
team
is
going
to
run
through
an
implementation
of
the
cloud
foundry
mode.
Just
for
some
context.
Let
me
share
the
screen
here
and.
D
All
right
everyone,
my
screen
or
anyone,
see
it
I
can
see
it.
Okay,
awesome
how
I
get
the
chat
up
here
as
well.
Alright,
so
the
project
that
we've
been
working
on
around
the
service
burger
space
is
called
steward
and
steward
looks
after
all,
the
passengers
on
the
good
ship,
kuber
Nettie's
at
a
high
level.
When
we're
talking
about
applications,
no
application
is
an
island.
It
needs
services,
I
need
to
be
able
to
request
and
connect
to
those
services.
D
This
is
a
list
of
those
questions
that
sort
of
come
up,
which
should
be
no
surprise
to
go
folks
in
this
cig.
You
know
how
do
I
find
the
applications
of
my
the
things
that
my
app
needs?
How
do
I
request
access
to
those?
How
do
I
connect
to
those?
How
do
I
tell
my
app
to
use
those
things
and
then
from
an
operator
standpoint
is
how
do
I
expose
services
to
folks
on
the
cluster?
D
D
So
to
that
end,
we've
got
the
high-level
pieces
that
are
functioning
here.
We've
got
a
Service
Catalog,
which
is
persisted
as
a
third-party
resource
in
the
communities
API
we've
got
applications
and
application
developers
kind
of
lump
them
into
the
same
category,
some
notion
of
a
broker,
and
then
some
service
provider,
so
the
service
provider
would
be
something
like
Sen
grade
or
RDS,
or
some
configuration
of
software
that
gets
stood
up
broker
the
thing
that
mediates
access
to
that
as
end
in
the
application,
which
is
going
to
be
consuming
those
those
resources.
D
Overall,
we've
got
this
sort
of
cast
of
characters.
I
think
the
big
one
here
is
going
to
be
request.
A
bowl
service
is
that's
a
some
service
that
exists
in
the
context
of
a
Service
Catalog.
The
catalog
is
a
list
of
all
those
services
and
then
service
claim,
which
is
how
an
application
developer
packages
up
their
intense
to
get
access
to
a
service.
So
we've
got
the
notion
of
a
service
claim
steward,
sits
between
the
application
and
the
apt
at
bev's.
D
Along
you
know,
along
with
the
other
cloud
foundry
or
a
broker,
API,
so
stewards
responsibilities
at
the
high
level
up
it
will.
When
a
steward
starts,
it
will
publish
its
own
services
to
the
sir
to
the
Service
Catalog
in
the
third
party
as
a
through
great
resource,
then
we'll
start
watching
namespaces
for
service
plan
claims
and
manage
interactions
with
the
service
backends.
D
So,
as
a
service
plan
claim
arrives
in
the
cluster,
it
will
notice
that
see
that
it
matches
its
set
of
services
that
it's
watching
up,
we're
providing
and
then
it
will
call
out
to
Cloud
Foundry
service
broker,
call
its
home
or
instantiate
some
pods,
so
generally
the
workflow
at
a
high
level.
The
application
developer
will
create
a
claim
and
they're
in
their
application.
Namespace
and,
however,
they
deliver
that
through
a
straight
hitting
the
API
server
or
pack
that
claim
as
part
of
their
application
charter
using
coupe
CTL
to
create
it.
D
That
claim
gets
passed
in
the
claim
will
reference
the
catalogue
offering
by
service
ID
and
plant
ID,
which
is
borrowed
from
the
cloud
foundry
a
sort
of
broker
API
and
will
also
provide
a
target
name
for
steward
to
write
the
service
secrets.
So
we'll
say
you
know
in
my
name
space
at
this
secret
name,
please
inject
the
credentials
from
the
back
end
interactions
once
stewards
that
claim
it
will
manage
it
and
interface
with
the
back
end
brokers.
D
The
three
modes
I've
got
some
diagrams
here.
This
is
just
to
help
expand
on
what
those
modes
actually
mean.
So
again,
here
steward,
you
can
see
the
you
know:
get
v2
catalog
when
Stuart
starts
it'll
hit
the
cloud.
Foundry
service
broker
a
numerate,
all
the
services
and
plans
that
that
broker
provides
and
then
publish
those
into
the
service
catalog.
So
Stuart
acts
as
that
adapter
between
the
crew,
benetti's
universe
and
the
cloud
foundry
service
broker
universe
and
then,
as
claims
arrive
again
package
by
usual,
our
operators
within
context
of
criminals,
cluster.
D
Putting
here
you're
in
command
mode,
these
are
one
shot,
pods,
stewards
responsible
for
setting
up
the
pod
environment
and
it
will
call
into
whatever
image
it
is
configured
to
launch
it'll
call,
slash
bin,
slash
broker,
catalog
and
then
the
responsibility
of
the
contract.
Right
now,
oh
I
will
tend
to
omit
the
JSON
for
a
well-formed
Cloud
Foundry
I
catalog
same
thing
with
provision
blind,
unbinding
d
provision.
We
have
a
very
lightweight
API
or
these
pods.
D
That
has
the
information
that
it
would
need
to
be
able
to
service
those
requests,
and
then
the
last
mode
is
simply
tiller,
as
the
back
end,
so
we've
got
steward
can
start
in
a
couple
different
ways
to
interface
with
tiller,
where
it'll
install
that
the
helm
chart
when
it
launches
or
it
will
expect
the
chart
has
already
been
installed
and
then
just
so.
Those
are
the
three
modes
at
a
high
level.
Before
we
jump
into
the
demos.
Anyone
have
any
questions
at
this
said.
D
E
F
D
C
C
D
Deus
I'll
try
to
feel
the
the
question
so
actually
because
until
recently
there
have
been
issues
having
multiple
types
of
third-party
resources.
What
we
are
doing
for
the
moment
is
that
plan
claims
hour
or
service
plan
claims
rather
are
submitted
as
a
sort
of
config
map.
Yes,
the
output
is
a
secret.
The
only
thing
that
is
actually
third-party
resource
for
the
moment
is
the
entries
in
the
Service
Catalog,
so
entries
in
the
Service
Catalog
or
three
PRS
claims
or
config
maps.
The
output
is
a
secret.
B
Alright,
so
we
put
together
a
couple
helm
charts
to
show
off,
as
jason
said,
the
cloud
foundry
back-end
broker
implementation,
so
everyone
can
go
see
this.
It's
a
github,
/,
dais,
/,
Stewart,
demo,
dash
s3
and
again.
The
intent
here
is
we're
just
going
to
do
three
helm
installs
and
in
between
I'll
show
kind
of
how
everything
works.
So
the
first
thing
here
we're
going
to
do
is
we're
going
to
install
a
steward
and
the
backing
Cloud
Foundry
broker.
B
Actually,
let
me
go
back
here
and
explain
what
the
broker
is.
So
the
broker
is
an
s3
broker,
which
is
just
going
to
create
it's
going
to
create
an
s3
bucket
on
provision
and
then
it's
going
to
create
a
new
I
am
credentials
on
bind
and
it's
going
to
turn
those
IM
parentals,
as
well
as
the
bucket
name
in
that
secret,
that
we
were
just
referencing.
B
So
I'm
going
to
go
ahead
and
go
into
the
s3
service
provider.
Shark
I've
already
put
my
AWS
access
key
access
secret
into
my
environment.
Let
me
make
this
a
little
bit
smaller
here.
So
can
everybody
see
all
of
this
terminal
output?
Okay,
can
anyone
not
see
this
I
can
see
it
all
right,
great,
so
I'm
gonna
head
over
to
charts
s,
3
s,
3
service
provider,
I'm
going
to
do
that
helm,
install
just
copy
this.
B
B
So
you
can
see
here.
This
is
the
plan
that
we
just
created.
The
name
is
basically
parsed
out
as
the
name
of
the
broker
the
name
of
the
broker
here
and
then
this
is
the
service
name,
and
this
is
the
plan
name
and
as
we
go
through
as
you
go
through
the
demo,
you
can
see
the
output
yamma
love
this
and
see
quite
a
few
more
details
about
the
plan,
I'm
going
to
omit
that
for
now,
but
you
can
kind
of
catch
it
a
little
bit
here.
B
There's
a
plan
ID
and
there's
a
plan
name
and
so
on
and
so
forth.
So
let's
make
sure
that
pot
is
up
now
so
now
that
it's
running
we're
going
to
go
in
and
create
that
claim
and
again
the
claim
if
I
can
just
show
it
for
one.
Second,
the
claim
is
that
config
map
that
I
think
both
Jason
and
Kent
mentioned.
We
are
planning
once
you
can
get
multiple
third-party
resources
kind
of
reliably
posted
up
to
the
cluster.
B
We
are
planning
to
make
this
into
a
true
third-party
resource
and
Stuart
has
the
flexibility
implementation
wise
to
kind
of
make
that
transition,
but
for
now
it's
a
config
map
and
this
is
kind
of
what
it
looks
like.
So
this
is
the
reference
to
the
plan
and
the
service
right
now.
This
claim
ID
is
unused,
but
it's
expected
will
use
in
the
future.
B
B
You
surprising
here
this
is
pretty
much
exactly
what
we
put
in,
except
for
the
status,
so
this
status
is
a
read-only
field
for
the
application
and
app
dev,
and
it's
write
and
read
for
stewards.
So
once
steward
goes
through
kind
of
the
state
machine
of
the
provision
and
then
bind
state
will
see
the
status
of
bound,
get
output,
and
that's
how
we
is
the
application
operator
or
developer
knows
that
now
the
service
has
been
provisioned
and
bound
and
we're
ready
to
use
it.
B
So
now
that
we're
ready
to
use
it
will
do
the
last
step
here,
which
is
going
to
be
instantiate
our
program
that
we
actually
expect
to
be
able
to
read
that
secret.
So
again,
the
helm
chart
fairly
simple:
we've
got
a
we've
got
an
image
here,
that's
kind
of
been
pre
created.
All
it
is
is,
is
going
to
be
launched
as
a
job.
That
image
is
simply
going
to
upload
an
image
of
Crocodile
Dundee
and
in
this
specific
case-
and
that's
thanks
to
one
of
our
one
of
our
engineers
who
is
from
Australia.
B
B
B
B
That's
confronted
has
a
cloud
foundry
broker
in
the
background,
it's
fronted
by
Stewart
and
has
that
sort
of
standard,
Kuber,
Nettie's
interface
in
front
of
Stewart
that
we
can
take
advantage
of
as
the
app
developer
so
I'm
going
to
unshare
my
screen
right
now,
and
then
we
can
talk
about
some
questions.
I
see,
there's
a
bunch
in
the
chat
already.
B
C
B
No,
we
actually
don't
have
that
right.
Now,
just
for
a
little
bit
of
history,
steward
sort
of
as
the
very
first
day
we
did
have
steward
be
able
to
write
to
any
namespace,
so
it
kind
of
had
god
mode,
and
then
we
talked
about
the
service.
The
service
account
implementation,
which
you
just
mentioned,
but
we
haven't
quite
gotten
there
yet
so
right
now,
it
just
writes
the
secret
to
the
same
namespace
as
the
claim.
C
B
F
F
B
It
can
be
the
same,
but
there
are
actually
two
modes
that
Stuart
can
be
configured
for
when
running
in
tiller
mode.
So
the
one
that
is
very
similar
to
the
broker
is
provision
will
install
a
new
help
chart
and
then
bind
will
inspect
the
output
of
the
helm
chart
to
grab
credentials
to
write
back
to
the
secret.
The
other
ways
is
fairly
different
in
that,
when
Stuart
starts
up,
it
will
expect
that
the
chart
is
already
installed
and
provision.
Just
then
is
a
no
op
and
bind
will
then
go
and
sort
collate.
E
B
C
You
guys
considered
all
having
some
kind
of
convention
or
other
way
for
service
workers
to
report
back
that,
like
part
of
their
payload,
is
configuration,
it's
not
secret,
so
you
could
differentiate
by
creating
a
secret
or
populating
a
secret
in
a
namespace
versus
config
map
in
the
namespace.
That's
one
thing:
I!
I
struggle
with
a
lot
about
the
current
broker.
Api
yeah.
B
That's
an
excellent
point.
So
again,
a
tiny
little
bit
of
history
steward
originally
tried
to
guess
which
obviously
not
not
the
best
solution,
and
eventually,
after
kind
of
a
few
iterations,
we
decided
to
put
everything
in
a
secret
and
the
reason
for
that
was
we
couldn't.
We
didn't
want
to
at
least
extend
the
broker
response
API,
and
we
also
didn't
really
want
to
guess.
So.
C
D
C
G
Right,
well,
you
have
the
floor,
sir
okay,
so
we
don't
have
a
slide
deck,
but
I'll
just
walk
you
through
before
I
before
I
do
the
actual
demo,
what
we've
been
working
on,
so
we've
been
building
a
prototype
starting
more
from
the
from
the
vanilla,
Cloud
Foundry
model
of
the
principal
service
broker,
API
as
the
service
instance
and
service
management
API,
and
then
the
Cloud
Controller
service
or
system
that
lives.
On
top
of
that,
that
manages
different
brokers
that
live
in
different
places
and
manages
the
relationships
of
instances
and
bindings.
G
What
can
be
generalized
and
made
into
what
we've
been
calling
the
service
controller
that
that
management
system
and
then
how
we
can
use
the
service
broker
API
to
begin
to
deploy
and
manage
white-box
services
in
a
crew,
benetti's
cluster
and
within
multiple
crew
benetti's
clusters?
Really,
so
we
have
those
those
two
different
systems
we've
been
building
as
prototypes.
So
what
this
demo
is
going
to
go
through?
G
G
G
We
have
the
the
service
controller
running
and
we
have
a
service
broker
running
within
the
cluster
that
is
managing
the
catalog
and
the
instantiation
and
binding
within
the
cluster.
If
you,
if
you
think
back
to
the
previous
demo,
there
was
the
the
steward
that
does
the
procurement,
the
provisioning
and
the
binding
and
unbinding
and
d
provisioning.
That's
that's
the
same
relationship
of
the
service
controller
to
the
service
broker
that
lives
in
the
cluster.
G
Okay,
so
if
we,
if
we
talk
to
our
service
controller,
we
can
ask
it
what
what
it
has
for
services
to
deploy
in
it,
and
it
currently
has
nothing
because
it's
not
hooked
up
to
any
service
brokers.
So
the
very
first
thing
we
need
to
do
is
is
add
the
service
broker
for
our
cluster,
and
you
can
see
I'm
actually
running
everything
localhost
right
now
on
my
on
my
laptop
for
the
sake
of
the
demo,
but
this
broker
would
actually
be
running
in
the
cluster.
G
So
we're
going
to
add
this
here
and
we
could,
we
could
add
brokers
for
multiple
clusters
to
manage
across
clusters.
We
can
add
brokers
that
manage
blackbox
services
as
well.
If
we
wanted
to-
and
once
broker
has
been
added
similar
to
how
cloud
foundry
works
in
general,
we
now
have
available
to
us
the
catalog
from
that
broker,
and
you
can
see
here,
there's
there's
a
bunch
of
different
services
with
plans
that
we
can
deploy.
G
What
we're
most
interested
in
is
this
guestbook
nodejs
and
this
guestbook,
my
sequel,
each
of
which
have
a
single
plan
and
I'm
hoping
most
people
are
familiar
with
the
the
cloud
foundry
model.
But
if
you're
not
cloud,
foundry
allows
you
to
see
service
service
definitions,
each
of
which
has
a
name
and
several
plans
that
it
can
deploy
a
plan
being
a
way
to
parametrize
different
different
styles
of
the
service
you
want
to
deploy.
G
G
So
our
broker
is
is
implemented
in
terms
of
helm
right
now,
so
we
have
a
Service
Catalog.
That
is
dynamic.
You
can,
you
can
actually
manage
the
the
service
types
available
from
your
cluster,
add,
add
ones,
remove
ones,
update
them
and
each
service
type
each
plan
and
a
service
type
is
backed
by
a
helm
chart
that
can
do
whatever
it
wants.
In
this
case,
it's
just
going
to
spit
up
a
pod
with
my
sequel
running
and
a
service
to
expose
that,
and
if
we
want
to
we
cannot.
G
G
So
the
next
thing
we
want
to
do
is
create
a
new
service
instance
and
we're
going
to
this
our
app
and
it's
a
guest
book,
nodejs
and
I
believe
the
plan,
for
that
was
ok
s
and
again
this
is
going
to
interact
with
the
service
controller.
That's
going
to
ask
the
service
broker
to
to
create
an
instance
of
this,
which,
in
turn
is
going
to
use
helm
to
to
do
a
helm,
install
and
every
every
interaction
between
the
service
controller
and
the
broker.
G
Everything
the
service
control
tries
to
do
is
always
done
through
a
service
broker,
so
the
service
controller
really
doesn't
do
anything
but
interact
with
service
workers,
and
we
can
now
see
that
there
is
a
another
service
instance
called
app,
and
if
we
want
to
look
at
the
cluster
itself,
we
see
that
there's
now
a
second
service.
This
one
has
an
external
IP
pending,
but
this
this
no
Jas
services
is
broken.
It's
it's
not
going
to
work
because
it
doesn't
have
the
information
to
connect
to
my
sequel.
G
So
we
now
need
to
create
a
binding
between
these
two
things
and
what
happens
when
we
create
a
binding
between
these
two
things?
Is
it's
going
to
do
what
it
normally
does
with
a
service
broker?
The
service
controller
will
talk
to
them,
I,
sequel,
broker
and
say:
hey
I
need
a
binding
to
this.
It
will
get
back
credentials,
which
is
the
username
password
IP
port,
and
then
it
will.
It
will
talk
to
the
node
J
s.
G
What
we're
allowing
people
to
do
is
bind
from
services
to
services,
because
that's
how
you
create
a
hierarchical
application
model,
you're,
you're,
doing
service,
oriented
and
and
I've
just
been
given
the
feedback
that
I
need
to.
Are
you?
Let
me
just
see
it
looks
like
it
looks
like
the
the
vision
is
cut
off.
Are
you
able
to
see
it
you're?
Good?
Okay?
No,
it's
just
it's
just
one
person
who's
having
problems,
never
mind
Brandi.
C
G
So
so,
when
you're
building
a
service,
an
application
out
of
services,
you
have
services
talking
to
other
services
right.
The
the
the
cloud
foundry
model
is
really
kind
of
a
hub
and
spoke
model
where
you
deploy
a
bunch
of
services,
and
then
you
have
a
single
application
that
talks
to
those
services
when,
when
typically,
what
we've
seen
is
that
people
are
building
services
that
talk
to
other
services.
So
my
in
this
case,
my
sequel
is
a
service
and
no
Jas
is
a
service
and
they
need
to
talk
to
each
other.
G
So
in
our
model,
everything
as
a
service-
and
it
allows
you
to
create
intricate
graphs
of
services
and
even
start
to
take
services
and
Dropbox
or
take
multiple
services
and
draw
a
box
around
that
and
create
a
new
layer
of
abstraction.
That's
that
itself
is
a
service.
Does
it
does
that?
Does
that
answer
your
question?
If
you
have
something
specific,
that
I
think
it
gives
me
enough
for
now,
I'm
interested
in
more
specifics,
but
I
want
old
or
so
so
what
we've?
G
What
we've
done
here
is
we've
just
deployed
to
services
and
they
and
they
need
to
talk
to
each
other
and
eventually
so
so,
we've
deployed
to
services,
we
have
to
service
instances
and
those
two
services
instances
need
to
talk
to
each
other,
which
is
not
really
a
concept
that
exists
in
the
cloud
foundry
model.
Typically
you
deploy.
This
nodejs
is
a
cloud
foundry
app,
but
since
Cloud
Foundry
apps,
don't
don't
exist
outside
Cloud
Foundry,
we've
migrated
everything
to
just
say
everything
is
everything?
F
It's
so
called
the
cloud.
Foundry
model
is
asymmetric
and
this
model
is
metric.
It
differs
from
ya,
know
Red
Hat
proposal
and
that
it's
not
just
exporting
credentials
and
config
to
a
namespace
but
to
a
specific
I
use.
The
word
applications
that
a
service
just
to
avoid
confusion
with
other
communities,
terminology
sure,
but.
G
Yeah,
no,
no
problem,
that's
that's
a
it's
an
interesting
area
to
dive
into,
and
it's
it's
something
that
we
spent
a
lot
of
time,
trying
to
understand
once
once
you
get
rid
of
the
asymmetry
of
the
cloud
foundry
model.
What's
what
are
you
left
with
when
you're
binding
things
together
and
you're,
creating
relationships.
G
So
so,
we've
just
bound
these
two
things
together
and
what's
happened.
There
is
that
the
service
controller
has
initiated
a
bind
request
to
the
broker
for
my
sequel,
it's
gotten
back
the
credential
information
and
then
it's
injected
into
the
into
the
no
DJ
s
service
instance
again
interacting
with
the
broker
API.
So
so
the
service
controller
never
has
any
communities
native
interaction.
It's
always
interacting
with
the
service
broker
API,
which
creates
a
very
simple
relationship
of
the
controller
to
to
the
broker
for
the
crew,
benetti's,
environment
and
potentially
brokers
for
others.
G
Other
environments
as
well,
and
we
can
see
that
we
now
have.
We
now
have
two
service
instances
here
and
we
also
have-
and
we
also
have
a
binding.
That's
that's
binding
these
two
service
instances
together
and
now
I
realize
that
I
Shh
miri
share
my
screen.
Just
so,
I
can
show
the
fruits
of
our
labor
labor,
which
is
you
know
just
for
this
simplistic
demo.
G
G
G
Api,
we
were
not
in
the
business
of
dictating
that.
Thus
the
service
broker
is
implemented
in
terms
of
helm,
charts
and
the
creator
of
a
service
type
is
going
to
create
a
chart
and
they
can
you
know.
Obviously
a
chart
has
inputs
and
they're
able
to
do
whatever
they
will
with
with
those
inputs,
so
they
may
take
those
inputs
from
the
broker
and
store
them
as
config
maps
or
secrets
for
their
application
to
consume,
or
they
may
inject
them
directly
into
their
application
to
environment
variables.
G
Yes,
yep,
yes,
every
every
service
type
that
you
create
is
backed
by
a
chart,
so
so
the
workflow
is
I
have
a
container,
although
I,
that
is,
that
is
one
way
to
do
it.
You,
you
have
a
possibility
of
concrete
charts,
that's
which
is
the
demo
I
just
gave.
I
have
the
guest
book
nodejs
chart
and
I
have
the
guest
with
my
sequel
chart.
G
You
also
have
the
potential
for
more
generalized
charts
that
are
my
load
balanced
front-end
chart
that
one
of
the
inputs
is
my
container
and
and
does
a
certain
pattern
of
you
know
it
will
store
bindings
in
secrets
with
this,
with
this
style
of
naming
and
your
application
needs
to
be
built
to
know
how
to
consume
it.
That
way
so.
C
G
That
that's
as
I
that's
entirely
possible,
but
again
you
may
also
like
as
a
as
a
service
creator.
You
may
also
create
a
very
concrete
chart.
That
is,
you
know
my
application
and
it
does
something
very
specific.
But
but
definitely
you
can
have
multiple
different
archetypes
that
that
you
then
just
are
injecting
your
application
code
into
gotcha.
F
G
Becomes
quite
simple
because
everything
has
to
subscribe
to
the
service
broker
model,
so
sendgrid
provides
a
sendgrid,
provides
a
service
broker
which
implements
the
instantiate
and
bind
interfaces
of
the
service
broker
and
bind
is
responsible
for
returning
a
credential.
So
the
service
controller
expects
that
when
it
calls
bind
on
the
SendGrid
service
broker,
it
will
receive
credentials
back
and
then
it
will
inject
those
credentials.
In
the
same
way
it
did
with
the
with
the
my
sequel
credentials
into
the
into
the
consuming
service
instance.
G
Well,
the
final
motion
to
the
service
controller
is
to
pass
the
information
to
the
to
the
consuming
service
instances,
service
broker
and
it's
the
responsibility
of
the
the
consuming
services
templating
to
do
with
it.
What
it
will
so
there
a
bind
calls
for
both
both
in
divine
binding
know.
There's
the
bind
call
is
is
purely
a
call
to
the
to
the
producer
service
so
to
speak.
So
so
the
service
controller
would
step
one
Paul
bind
on
the
service
on
the
SendGrid
service
broker.
G
In
this
example,
okay
Idris,
it
would
receive
back
as
a
response
the
credentials
and
then
it
would
make
an
update
call
to
the
to
the
broker
of
the
consuming
service
instance.
I
think
this
is
the
new
configuration
for
this
service
instance,
which
now
includes
the
finding
information
for
sendgrid,
so
the
so
the
stuff
matters.
How
does
it.
F
G
So
so
this
the
service
broker
api
for
put
on
a
service
instance
as
a
parameter
section,
which
is
a
just
a
map
of
of
data,
and
so
so
what
we've
done
in
this
is
is
we've
said:
ok,
we're
going
to
carve
out
a
space
of
that
with
the
bindings
key
and
the
bindings
key
will
have.
Excuse
me
a
map
of
binding
name
to
credential
information
in
that
ok,.
E
G
But
in
the
in
this
world
now
of
service
instances
binding
to
service
instances,
it
may
be
that
there's
some
addition
that
could
be
made
to
the
service
broker
API
to
it
have
a
top-level
bindings
section
in
in
the
put
call
to
service
instances.
But
for
our
purposes
we
just
said
one
parameter
to
service
instances.
Now
is
the
bindings
that
it
needs
to
consume
and
the
service.
The
service
controller
will
inject
the
information
there.
So
it's
up
to
that.
C
G
Now,
what
we've
built
is
a
a
separate
service
that
air
quote
persists
this
information
in
memory
right
now,
but
we're
also
working
on
a
third
party
resources
interface
to
the
service
controller,
which
would
expose
these
things
as
crew,
benetti's
resources
and
these
things
being
service
types,
service,
instances
and
bindings.
Ok,
cool.
C
E
G
Yep,
yep
and
and
I
would
I
would
demonstrate
that
right
now,
but
we
haven't
demonstrated
in
a
while,
and
so
it
probably
go
wrong.
But
this
this,
my
sequel
service,
could
be
consumed
by
two
different
nodejs
front
ends
very
very
easily,
and
the
steps
for
that
would
be
I
would
create
my
second
one
and
then
I
would
just
create
a
binding
that
binds
that's
apt
to
to
my
sequel
and
it
would
create
another.
A
Brennan
now
I
gave
here
I'm
cure
Caesar.
Is
there
a
reason
you
chose
to
have
the
service
controller
maintain
its
own
API
and
state?
You
know
it
sounds
like
you're
entertaining
synchronizing
that
with
Cooper
Nettie's,
but
now
I'm
just
curious.
If
there
were
any
other
reasons
driving
that
architectural
decision
prototype.
G
Foo
we
so
so
we
start
we
started
like
I
said
in
the
beginning,
we
really
started
with
the
cloud
foundry
model
and
trying
to
understand
what
pieces
of
that
can
be
abstracted
or
extracted
and
generalized
to
create
a
service
management
system,
and
and
when
doing
that,
we
weren't
solely
focused
on
just
saying:
how
do
we
manage
services
in
a
single
crew,
benetti's
environment,
but
really
like?
How
do
we
manage
services
in
general,
possibly
across
multiple
environments?
And
so
we
were?
G
We
were
just
operating
with
the
simplest
use
case,
and
that
was,
you
know,
build
a
build
of
go
binary,
binary
that
we
can
interact
with
through
a
chestful
API
and
now
we're
trying
to
say
okay
well
well,
how
do
we,
how
do
we
integrate
this
seamlessly
from
a
user
experience
perspective
into
the
crew
brunetti
system
and
understanding
how
that
would
look
and
feel
and
and
and
whether
that
model
still
fits
once
we
do?
That
is
is
what
we
started
focusing
on
next
right.
A
Yeah
I
mean
makes
perfect
sense
and-
and
you
know,
I
think
you
know
I
trying
to
build
a
build,
something
that
isn't
or
explore
something
isn't
tightly
coupled
to
the
cabernet.
Tapi
certainly
makes
sense,
but
but
if
I'm
understanding
correctly,
it
seems
that
you
know
the
the
service
instance.
You
know
creation
sort
of
the
plan.
Registration
is
using
helm
right
now.
That
is
kind
of
the
de
facto
way
to
get
that
in
there
is.
That
is
that
accurate
yeah.
G
A
And
you
know
just
fer
fer
for
my
just
to
get
this
out
and
for
other
folks
on
the
call
it
seems.
As
far
as
I
can
tell
you
know,
there's
there's
sort
of
two
or
three
major
differences
between
service
controller
and
what
we
were
showing
before
with
with
steward.
The
first
is
that
it
seems
like
service
controller.
You
know
has
at
least
for
now.
A
This
is
some
API
and
state
versus
using
the
brunette
ease
to
store
the
contents
of
the
catalog
and
then
also
service
controller
uses
the
helm
chart
rendering
you
know
to
allow
for
more
flexible
use
of
the
binding
data
versus
secrets
injection,
which
is
what
stewards
using
that
and
then
maybe
the
third
thing
being
the
helm
supporting
a
few
other
modes
that
we're
kind
of
playing
around
with.
As
far
as
I
can
tell,
though,
seems
to
be
the
major
differences
and.
H
G
That
you,
okay
thanks,
there's
a
bunch
of
us
in
the
room
and
we're
all
wearing
headphones.
So
so
I
would
just
add
to
that
to
say
that
we
we
really
focused
on
keeping
the
service
controller
and
the
service
broker
as
separate
principal
players
such
that
the
service
controller
doesn't
understand,
cooper,
Nettie's
and
it
doesn't
understand
helm.
All
of
that
is
encapsulated
in
the
broker
and
the
more
we
can
do
that,
the
better,
because
whether
we
need
a
layer
of
abstraction
for
services,
whether
it's
the
cloud
foundry
service
broker
or
something
else.
G
But
when
you,
when
you
have
that
very
clear
api
for
managing
service
instances
and
managing
bindings,
you
get
you
get
a
very
you
get
a
bunch
of
very
nice
properties.
I
think
one
of
which
being
able
to
manage
across
multiple
environments,
and
so
I
think
just
to
just
to
add
your
point.
I
think
the
service
controller
really
doesn't
use
home.
The
service
controller
just
uses
service
brokers,
but
we
also
built
a
service
broker
that
uses
helm.
That
has
all
of
those
that
has
all
of
those
things
that
you
just
described.
G
I
G
G
Yeah,
that's
the
beauty
of
the
broker.
You
could
run
a
bunch
of
different
brokers
in
your
crew,
benetti's
cluster
and
one
of
them
could
be
using
helm.
We
we've
been
playing
with
a
broker
that
uses
the
google
cloud
platforms,
deployment
manager.
You
could
write
a
broker
that
just
uses
cube
control
and
deploys
things.
G
I
think
you
lose
a
lot
of
properties
like
the
abstraction
layer
that
home
charts
give
you
when
you
start
to
do
that,
you
have
to
start
defining
what
a
services
at
the
inn
broker
code
rather
than
in
the
in,
like
the
values
at
the
input
properties
and
things
like
that.
It
becomes
more
challenging
to
systematize
things,
but
but
yeah
you
could.
You
could
write
a
bunch
of
different
brokers
and
they
all
manage
things
in
your
cluster
in
different
ways
using
different
tooling.
Absolutely
that's
the
magic
of
the
service
broker
yeah
so.
C
No
I'll
clarify
it,
so
what
I
mean
is
that
the?
If
so,
if
you
push
on
to
the
broker
implementation,
the
responsibility
of
managing
crew
benetti's
resources,
that's
fine,
but
a
consequence
of
that
is
that
you
have
to
understand
how
to
interact
with
Cooper
Nettie's
to
build
a
service
broker.
That's
going
to
work
with
it,
so
I
think
it
has
utility
to
be
able
to
delegate
the
management,
accrue,
benetti's
resources
to
the
thing,
that's
on
the
other
end
of
the
broker
API.
C
In
this
case
it
would
be
the
service
controller
and
there's
nothing
to
stop
you
in
that
model,
from
implementing
a
broker.
That's
smart!
If
you
want
to
implement
a
burger
that
will
do
white
box
services
like
create
actual
deployment,
resources
and
I
pet
sets,
even
in
your
crew,
benetti's
namespace,
but
I
think
there
is
some
utility
to
having
a
be
a
controller.
That
is
whatever
you
want
to
call
the
thing.
That's
that's
calling
the
service
worker
API.
C
H
Would
have
to
die
well,
maybe
I
can
respond
to
that.
I
think
I
understand
what
you're
saying
it's
a
little
confusing,
because
we
talked
about
the
stores
broker,
both
on
the
consumer
side
and
the
producer
side,
and
so
confounded
really
only
has
the
producer
side
service
broker
and
what
we're
doing
is
we're
saying
that
everything,
even
consumers
are
modeled
a
service
brokers
and,
and
so
the
update
you
know,
sort
of
the
the
responsibility
for
propagating
in
the
environment
that
you're
in
is
with
the
code
that
is
running
in
your
environment.
H
So
if
you're
in
Cuba
Nettie's
and
you
consuming
a
service,
then
the
service
broker
on
that
side
knows
how
to
propagate
bindings
and
things
like
that
in
the
Cuban
Eddie's
native
way
right
and
that's
what
we've
done
with
the
service
broker.
We
instrumented
that
uses
helm,
but
if
you,
if
you
should
expand,
you
know,
we
don't
consider
cleaners
in
Island
right.
You
might
actually
have
a
service
graph
that
spans
proven
Eddie's
in
other
places.
H
Then
you
can't
have
the
service
controller,
know
how
to
shove
bindings
into
Cooper
Nettie's
and
enjoy
WS
and
into
you
know
in
anywhere
else.
So
you
have
to
delegate
the
responsibility
for
the
last
mile,
a
binding
propagation,
and
that's
why
we
sort
of
saying
there
is
a
nav
I.
You
know
the
service
brokering
bhai,
where
we
can
update
those
parameter
and
and
wherever
that
that
the
calling
code
is
coming
from
is
responsible
for
that.
That
helps
yes,.
C
So
I
think
Gabe's
comment
in
the
chat
that
there's
just
a
key
difference
in
approach
in
terms
of
like
how
I'm
thinking
about
this
and
how
you
guys
have
chosen
to
think
about
it
in
the
service
broker,
prototype
yeah
I
think
your
scope
was
more
ambitious
than
anything
that
I
have
imagined.
I
never
have
considered
the
use
case
of
managing
multiple
Cooper,
Nettie's
or
multiple
has
on
the
consumer
side
at
all.
From
a
single
instance
of
such
a
thing,.
D
Yeah
I
think
one
way
that
I'm
thinking
about
this
is
using
this
service
broker
API
itself
as
a
backward
adapter
into
an
application
environment,
so
that
put
on
that
service
instance
with
the
set
of
credentials.
Then
the
implementation
of
how
that
actually
gets
in
on
to
disk
is
something
that's
provided
by
the
package
application
that
makes
sense.
Yeah.
C
C
The
last
agenda
item
is:
if
there
is
interest
in
a
face-to-face
meet
up
at
cube
con
or
slightly
before
or
after
I'm
interested
in
reading
the
temperature
of
the
group
for
that
I
think
that
face-to-face
meet
up
so
really
awesome
for
one
thing
getting
to
see
other
people's
faces,
and
you
know
establishing
relationships
that
can
help
things
like
move
a
lot
smoother
and
give
you
some
contextual
information
that
you
would
never
get
on
a
sig
meeting
like
this.
So
I
personally
will
be
a
cube.
C
Con
I'll,
be
there
I'll,
be
in
Seattle
that
week,
starting
monday
and
I'll
probably
try
to
fly
out
on
friday,
I
think
Jason
I.
Perhaps
you
can
be
the
trend
setter
if
you're
interested
in
such
a
meetup,
could
you
just
put
a
plus
1
into
the
chat
and
we'll
well
allow
two
or
three
minutes,
4
plus
ones,
to
trickle
in
so.
C
I
H
C
This
week
and
we
can
work
this
out-
we've
got
a
little
bit
of
time
in
which
to
do
it.
So
I
thanks
everybody
for
your
demos.
I
think
this
is
awesome.
Food
for
thought
I
do
want
to
encourage
folks
like
if,
if
you
have
interest
in
bandwidth,
if,
if
you
would
like
to
contribute
use
cases
to
the
the
incubator
repo
for
the
community
service,
catalog
I
would
welcome
your
pull
request
and
I
am
going
to
be
setting
aside
some
time
this
week
to
to
get
a
more
complete
use
case
analysis
in
there.
C
I
have
a
number
of
different
things,
I'm
kind
of
juggling,
but
I
want
to
make
a
big
push
on
that
this
week.
I
think
I
think
that's
all
I've
got
unless
anybody
wants
to
say
anything.
You
are
already
or
I
think
that's
all
we
got
anything
else
going
once
going
twice
all
right
sold
to
all
of
you.
Send
the
check
to
my
house
see
you
all
on
the
Internet.