►
From YouTube: Intro: Service Catalog SIG - Jonathan Berkhahn, IBM & Carolyn Van Slyck, Microsoft Azure
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Service Catalog SIG - Jonathan Berkhahn, IBM & Carolyn Van Slyck, Microsoft Azure
This is an introduction to the Kubernetes Service Catalog project. Service Catalog lets you provision cloud services, regardless of where they are hosted, directly from the comfort of native Kubernetes tooling. This works across platforms because we follow the Open Service Broker API, an open standard to provision and manage cloud services. Learn how you can use Service Catalog to access third-party services from your Kubernetes applications. We will walk through provisioning a database directly through Kubernetes and and then connect to it from an application running on the cluster.
To Learn More: https://sched.co/GrbS
A
A
A
A
So
if
you
would
like
to
become
a
user
of
Service
Catalog,
you
already
are-
and
you
want
to
tell
me
about
everything
you
hate-
maybe
you'd
like
to
meet
some
of
the
other
maintainer
x',
who
are
up
here
in
the
front
row
and
then
just
kind
of
see
a
demo
of
service
catalog
and
figure
out
if
you
want
to
get
involved.
So
if
that's
not
what.
A
Okay,
how
many
people
are
in
a
cig
already
and
know
what
a
cig
is:
okay
and
who's
from
another
cig
and
showed
up
just
because
they
want
to
know
what
it
is,
we're
doing
in
Service,
Catalog,
all
right
cool
for
everyone
who
just
raised
their
hands
for
that
last.
One
most
of
the
information
that
you
really
want
is
going
to
be
at
the
deep
dive
on
Thursday
and
have
more
information
about
that.
A
Okay,
so
the
people
who
aren't
familiar
with
special
interest
groups
or
six
it's
a
way
for
a
formal
way
for
us
inside
of
kubernetes
to
get
together
and
kind
of
figure
out
how
to
solve
big
problems
in
kubernetes.
Okay,
so
there's
sig
applications,
there's
like
sig
networking
and
we
have
sig
service
catalog.
We
have
a
formal
Charter
and
it
describes
how
we
operate.
A
You
don't
have
to
be
like
some
big
company
or
have
this
be
your
full-time
job
to
hang
out
with
us.
So
what
I'd
like
to
do
is
just
kind
of
go
over.
What
is
service
catalog
for
people
who
aren't
familiar
so,
like
I,
said
it's
the
open
service
broker
API,
that's
what
we're
involved
with
trying
to
make
available
inside
of
kubernetes,
and
what
this
is
is
an
API
that
describes
there's
all
these
managed
services
that
your
cloud
providers
offer
like
my
sequel
as
a
service
Redis
as
a
service,
I
love
databases.
A
So
there'll
be
all
my
explanations,
but
there's
way
more,
you
can
do
with
it
and
Cloud
Foundry,
which
is
another
platform
out.
There
came
up
with
a
way
to
make
it
possible
to
connect
all
of
those
cloud
services
into
your
platform
in
a
standard
way,
so
that
when
you're
talking
and
saying
I'd
like
to
provision
a
database
I'd
like
to
provision
a
message
queue,
it's
the
same
service
calls
it's
consistent
so
that
we
can
have
this
work
across
vendors
across
platforms.
A
So
people
who
have
brokers
is
a
Google
Microsoft.
Amazon
iBM
has
a
ton
and
a
whole
lot
more
people
have
made
their
own
and
contribute
it
to
the
ecosystem.
The
deep
dive
is
going
to
go
in-depth
as
to
what
the
API
looks
like
and
how
it
interacts.
All
we
care
about
is
that
it
gives
us
the
ability
to
hook
up
all
those
great
things
that
we
don't
want
to
manage.
We
don't
want
to
do
my
sequel,
backups.
We
don't
wanna
figure
out
how
to
do
upgrades
or
maintain
these
things.
A
A
So
here's
a
couple
examples
of
what
type
of
services
like
I'lli'll
talk
about
databases
all
the
time
because,
as
an
application
developer,
that's
what
I'm
most
familiar
with,
but
it
could
be
anything
it
really
doesn't
matter.
You
could
make
a
broker.
That
knows
how
to
talk
to
your
smoker
and
give
you
information
about.
What's
going
on
and
fire
it
up,
I
mean
it
doesn't
really
matter.
You
can
interact
with
the
real
world
or
with
clouds
and
on-premise
providers
even
could
set
up
their
own
things
as
well,
but
for
the
most
part
anything
with
states.
A
That's
what
we
like
to
offload
our
clusters
so
oftentimes
as
soon
as
I
explain
what
service
catalog
is
people
go?
Why
are
we
doing
this
again?
Why
do
we
need
this?
So
I'd
like
to
do
just
a
quick
little
experiment
of
if
you
didn't
have
something
like
Service
Catalog
or
all
their
alternatives
like
it's?
Not
the
only
way
to
do
it.
It's
just
that.
It's
way
to
do
it
inside
of
kubernetes,
without
leaving
the
kubernetes
tooling.
A
Is
that,
let's
say
I
want
to
make
a
database
and
hook
it
up
to
WordPress
inside
of
my
kubernetes
cluster?
If
I
don't
have
something
like
Service,
Catalog
I
need
to
go
to
the
portal
for
gke
or
Azure
or
whatever,
or
go
to
one
of
the
separate
command
line,
tools
or
use
terraform
or
something
else,
and
then
I
need
to
somehow
get
the
credentials
or
the
way
to
access
and
interact
with
whatever
service
I
just
created
back
inside
of
kubernetes
to
be
able
to
use
it.
A
So
there's
this
weird
disjointed
experience
and
you're
writing
a
lot
of
glue
code
at
that
point,
and
also,
if
I
do,
that,
kubernetes
knows
no
way
to
interact
with
whatever
was
there.
I
can
talk
to
the
database
and
connect
as
a
user,
but
what
happens
when
I
need
upgrade?
What
happens
when
I
want
it
to
go
away?
A
What,
if
I
want
to
change
service
levels,
because
all
of
a
sudden
I
need
to
scale
up
and
I
need
a
big
beefier
database
I
need
to
go
back
to
the
console,
go
back
to
the
portal
type
it
all
in
again
upgrade
maybe
sync
the
credentials
back.
Whatever
and
it's
kind
of
a
manual,
you
know
it's
why
we
have
DevOps,
so
that's
a
problem
we're
trying
to
solve
the
second
question.
A
lot
of
people
have
those
like
operators
are
really
cool.
Half
the
talks
here
about
operators.
A
Why
aren't
we
doing
that
instead?
So
the
problem
we're
trying
to
solve
of
connecting
a
platform
kubernetes
to
whatever
your
underlying
source
of
managed
services
are
like
your
cloud
provider,
it's
not
a
unique
problem
that
we're
trying
to
solve
if
every
single
operator
individually
tried
to
solve
it
for
themselves.
Every
time
you
use
a
different
one,
you
have
to
do
something
different.
You
have
to
relearn
their
system
and
each
one
will
have
different
sets
of
capabilities
which
is
kind
of
frustrating.
It's
not
not
easy
to
do.
I
don't
want
to
spend
my
time
reading
documentation.
A
The
other
part
of
this
is
that
the
source
of
the
open
service
broker
API
came
from
Cloud
Foundry,
and
because
of
that,
there
is
an
entire
marketplace,
an
ecosystem
full
of
existing
brokers
that
you
can
immediately
use.
I,
don't
have
to
rewrite
an
operator
for
one
of
these
services
if
it
already
exists
somewhere
else.
I,
don't
have
to
do
all
that
logic,
so
operators
are
cool,
I'm,
not
hating
on
them,
but
they
don't
quite
solve
the
problem
for
everyone
and
give
us
a
consistent
experience.
A
So,
there's
a
couple
different
ways
to
interact
with
service
catalog,
it's
something
that
is
installed
into
your
cluster
okay
and
you
can
work
with
it.
Using
cube,
CTL
and
I
can
just
type
in
cluster
serviceworkers,
okay
and
I
have
one
broker
installed.
A
broker
is
something
that
is
capable
of
interacting
with
this
underlying
system
that
can
provision
services.
For
me,
for
the
sake
of
bandwidth
demo
time
and
not
charging
any
money,
there's
a
little
demonstration
broker
called
mini
broker.
A
That
runs
really
nicely
on
any
cluster,
especially
mini
cube,
and
it
lets
me
provision
things
that
don't
cost
any
money
and
just
run
on
the
cluster
itself.
It
lets
you
simulate
how
to
work
with
Service
Catalog,
so
cube,
CTL
is
cool,
but
that
was
one
way
to
interact
with
it
and
it's
not
domain
specific.
So
sometimes
it's
easier
to
be
able
to
work
with
things
using
the
terminology
that
you
think
about
it
and
have
it
be
optimized
for
what
you're
trying
to
do
so
we
have
a
command
line
tool
SP.
A
Yet
a
little
bit
shorter
and
it'll
show
you
similar
information,
and
here
I
can
see
my
broker
and
it
supports
all
the
commands
that
keep
CTL
does.
But
again,
it's
optimized
for
showing
you
the
information
that
you're
you're,
probably
most
interested
in
so
I'm
gonna
describe
my
mini
broker
and
so
a
couple
pieces
of
information
here,
that's
interesting.
It's
mostly
the
URL.
Your
broker
doesn't
have
to
be
on
your
kubernetes
cluster.
It
could
be
somewhere
else.
A
You
could
host
a
broker
in
your
on-premise
installation
and
have
all
your
various
kubernetes
clusters
point
to
it,
but
at
the
end
of
the
day,
what
it's
doing
is
connecting
kubernetes
to
that
API
and
be
able
to
say
make
me
Services
bind
to
them.
Give
me
credentials
so
the
first
thing,
I
always
wonder,
is
like
what
can
I
do
with
a
broker
when
I
have
it?
A
A
As
a
managed
service
for
you,
so
here
we
have
Mario
DB,
MongoDB,
all
sorts
of
different
versions,
and
so
let's
talk
a
little
about
what
we're
seeing
here
is
Services
kind
of
get
grouped
into
classes,
which
is
a
related
set
of
things
like
my
sequel,
a
rabbit
message
queue
things
like
that
and
then
there's
different
service
plans.
Sometimes
it's
it
boosts
how
much
memory
and
things
you
have
available
to
you.
A
A
There
we
go
so
you
can
see
the
status
it
was
already
provisioned
successfully.
It
gives
you
a
little
bit
of
information
about
what
namespace
it
was
deployed
into
and
what
was
the
class
and
plan
there's
nothing
attached
to
it
right
now.
At
the
moment,
though,
so
there's
this
concept
of
I
make
a
service
instance.
Okay,
my
sequel,
but
I
could
have
five
six,
a
hundred
different
applications
and
micro
services
that
want
to
be
able
to
connect
to
it
and
get
credentials
for
and
be
able
to
interact
with
it.
So
it's
a
two-step
process.
A
A
There
we
go
so
I
have
a
binding
to
my
service,
and
this
doesn't
just
happen
inside
of
kubernetes
when
I
create
this
binding.
Just
like
when
I
made
the
instance,
it
talked
to
the
broker
and
it
made
a
database
and
then
came
back
and
said
all
right.
Great
we've
got
database
ready
to
roll
for
you
when
I
do
a
bind.
A
It
goes
off
again
talks
to
the
broker
and
says:
hey
I
want
to
be
able
to
create
a
connection
to
this
database,
and
it
can
return
to
me
credentials
to
connect
to
it
depending
on
how
your
broker
is
configured
and
set
up
like
what
Azure
does,
for
example,
is,
will
give
unique
credentials
for
every
binding
so
that
each
micro
service
is
connecting
with
a
different
set
of
usernames
and
passwords
and
what
it
does.
What
service
catalog
does
is,
after
you've
created
that
binding.
A
We
needed
a
way
to
connect
your
your
application
to
this
service
that
we
provision
now
and
what
we
do
is
we
create
a
new
secret
for
you,
so
I
have
a
secret
here.
The
name
of
the
secret
is
my
ID,
because
I'm
not
being
creative
and
inside
of
that
secret
or
a
whole
bunch
of
different
information
that
you
can
use
to
connect
to
it.
My
favorite
is
just
using
the
URI,
and
now
this
secret
data
that's
coming
back,
isn't
always
some
of
it
looks
the
same
between
different
clouds.
A
Sometimes
it
doesn't
that's
one
of
the
challenges
that
we're
working
on
in
Service
Catalog.
Actually,
it's
making
it
so
that
you
could
connect
to
a
database
that
was
made
on
IBM
for
my
sequel
and
connect
to
a
database
that
was
made
on
adder
or
gke
or
Amazon
and
be
able
to
still
rely
on
using
the
same
keys
in
the
secret.
So
that's
how
it
works
and
I
showed
you
everything
inside
of
SV
cats,
but
again
I
just
want
to
stress.
So
this
is
all
actually
standard
kubernetes
under
the
hood.
A
If
I
wanted
to
I
could
completely
ignore
SV
cat
and
just
use
QC
ETL
to
interact
with
it,
but
as
you
notice,
it's
a
little
a
little
bit
more
verbose.
It's
basically
just
dumping
out
all
the
information,
whether
or
not
they
may
be
relevant
to
you.
So
when
would
you
use
one
versus
the
other
I'm,
a
developer
on
Service,
Catalog
and
I'm,
constantly
trying
to
just
one
off
make
test
data
or
see
what's
available
or
troubleshoot
and
dig
in?
A
In
that
case,
the
SV
cat
tool
is
super
useful
to
me,
because
it's
showing
stuff
that's
targeted
to
what
I'm
interested
in.
But
let's
say,
for
example,
that
I
finally
have
figured
it
all
out
and
I'm
trying
to
package
and
deploy
my
application
and
move
it
from
dev
to
test
to
production
at
that
point,
I'd
probably
be
using
something
else
to
orchestrate
this
whole
thing
and
I'd
be
using
Y
Amal
and
manifest
Navy,
helm
templates
and
things
like
that
to
be
able
to
create
all
of
these
things.
A
Really
cool
I
want
to
contribute,
but
I
actually
don't
know
what
the
pieces
are,
how
to
get
in
anything
like
that,
so
Jonathan's,
going
to
give
you
a
lot
more
information
on
what
the
underlying
architecture
is,
what
are
the
components
and
how
do
they
all
fit
together?
He'll
be
going
into
some
of
the
tips,
tricks
and
gotchas
of
just
understanding
the
domain
of
service
catalog
as
well,
and
then
also
getting
into
what
are
we
gonna
do
in
the
future?
A
What
I've
shown
you
here
is
a
little
simple
case
right,
but
we
put
a
whole
bunch
of
new
features
out
this
year
that
go
from
being
a
toy
and
kind
of
like
yeah.
We've
demonstrated
how
to
do
this
to
being
able
to
actually
securely
operate
this
in
production
and
be
able
to
manage
it
for
more
than
just
the
first
day,
but
the
second
day,
a
year
later,
how
do
I
keep
working
with
us?
How
do
I
manage
large
multi-tenant
clusters
where
I
need
to
be
able
to
isolate
the
services
I'm,
making
isolate
the
brokers?
A
Things
like
that,
so
he'll
get
into
all
that
sort
of
good
stuff.
What
I'm
really
here
today,
for
it
to
be
honest,
is
we're
in
a
rebuilding
year
with
a
catalog.
We
definitely
have
core
people
who
are
available
all
the
time,
but
we
want
new
contributors,
there's
a
lot
of
surface
area,
new
features
and
not
enough
developers
to
make
this
happen.
So
if
you
are
even
slightly
interested
I
highly
encourage
you
to
introduce
yourself
to
one
of
us
after
this
and
go
hey,
I
want
to
get
involved.
A
That's
ok,
please
come
on
in
and
we
have
paths
that
go
from
someone
who
knows
nothing
about
kubernetes,
nothing
about
service
catalog
to
becoming
a
contributor
to
going
on
to
becoming
a
maintainer,
and
even
a
chair,
I
started
on
Service
Catalog
last
year
in
December
and
I've
used
Service
Catalog.
This
much
I've
used
kubernetes
this
much
and
a
ton
ago,
so
I
had
at
least
at
that
leg
up
and
now
I'm
a
chair.
So
we
definitely
don't
have
this
like
Illuminati
glass
ceiling.
A
You
can't
come
in
if
you're
interested
in
being
a
cool,
important
person
who
wants
to
do
fun
stuff
with
kubernetes.
We
have
space
for
you,
I
am
cool,
don't
laugh
at
me.
Ok!
So
here
are
some
of
the
things
I'm
gonna.
Try
to
like
pull
you
in
with
and
make
you
excited
to
join
us
Jonathan's
going
to
in
this
a
little
bit,
but
we
don't
you
see
our
DS.
A
Our
product
has
been
around
for
a
while.
We
were
pre,
CRT,
ok,
and
so
we
use
a
different
way
to
store
all
of
our
data
and
provide
api's
to
interact
with
service
catalog.
But
we
really
like
to
use
CRTs.
We
don't
have
enough
time
and
people
to
really
dig
into
this
and
maybe
contribute
a
bit
upstream
to
CRTs
to
make
fill
in
the
last
gaps.
A
A
Developer-Friendly.
We've
made
something
with
service
catalog
that
if
you're
a
dev,
ops,
II
person
who
isn't
afraid
of
you
Amal,
you
can
do
what
you
need
to
do.
It's
wholly
works,
but
if
you'd
like
to
just
be
able
to
use
it
and
focus
on
your
domain,
say
application
development
and
then
be
able
to
move
it
around
to
different
places,
we're
kind
of
like
missing
the
mark
on
the
user
experience.
A
So
we
have
a
cap,
kubernetes
enhancement
proposal
out
there
that
was
just
merged
I,
think
like
a
week
and
a
half
ago
to
work
with
siga
ops
to
make
something:
that's
portable,
so
I
can
move
it
around
and
we
need
developers
and
no
one
else
has
figure
out
how
this
is
going
to
work.
So
you
could
come
in
and
not
have
to
deal
with
existing
code
of
things
like
that.
A
It'll
be
really
fun
to
be
able
to
jump
in
and
be
able
to
work
on
things
and
the
API,
the
CLI
like
backend
control,
loops
and
all
the
fun
race
conditions
that
can
happen
on
that
side
and
just
really
improve
the
user
experience.
That's
that's
what
I'm
totally
interested
in
that's
what
I'll
be
working
on
next
year.
So
if
you'd
like
to
join
me,
we
really
need
people
couple
resources
to
have
available
for
you,
svk
Oh,
we'll
have
our
developer
guide,
more
information
and
demos
and
walkthroughs.
A
A
C
A
So
our
cig
does
not
own
brokers,
I
wrote,
mini
broker
and
so
I
kind
of
control
that
but
iBM
has
written
a
slew
of
brokers
and
that's
all
theirs
and
Azure
has
brokers
etc
and
each
one
of
those
the
way
we
make
them
play
nice
is
through
the
OSB
API.
They
all
have
to
adhere
to
that,
and
then
we
don't
have
to
worry
about
who
wrote
it.
D
A
Yeah
you
we
can
create
a
new
secret
or
use
an
existing
one
and
it'll
pack
in
all
the
data
that
came
back
from
the
broker,
sometimes
its
database
connection
info,
it
could
be
dashboard.
Information
say
that
you
deployed
something:
has
a
visual
GUI
somewhere
else,
whatever
it
is,
that's
important
to
be
able
to
interact
with
that
is
being
put
into
that
secret.
A
E
So
currently
you
are
correct.
We
don't
attach
to
a
running
pod
or
deployment.
That's
a
feature.
We
know.
Users
are
definitely
interested
in
it's
something
we're
working
on,
but
that's
one
of
those
things.
That's
gonna
require
changes
upstream
in
mainline
kubernetes.
So
there's
a
current
work
being
done
on
that
to
implement
a
feature
called
pod
presets,
but
that's
sort
of
a
future
plan.
F
A
Say
that
if
you're
provisioning
services
directly
off
of
a
cloud
provider
like
Amazon
or
IBM,
or
something
like
that,
they're
really
the
ones
owning
it,
some
of
them
are
open
source
like
the
Azure.
One
is
open
source,
but
if
you
were
interested,
you
can
usually
contribute
to
them,
but
the
day
to
day
decisions
and
people
saying
whether
or
not
something
is
worth
maintaining
or
accepting
is
going
to
come
from
them.
But
there
are
community
brokers,
like
many
brokers,
an
example
of
that
there
could
be
cool
stuff
that,
like
could
connect
brokers
to
IOT.
A
You
could
connect
brokers
to
home
automation
and
things
like
that,
and
that's
where
you
could
see
more
community
stuff.
If
you
have
neat
ideas,
for
example,
in
cheap
cotton,
Europe
Scot
demonstrated
how
to
like
connect
all
the
lights
in
his
house
and
turn
things
on
off
using
a
service
catalog.
That
would
be
something
where
none
of
the
vendors
care
and
you
should
totally
try
that
out
and
do
something
with
it.
I.
E
Can
also
offer
some
more
information
on
that.
So
from
my
experience
there
tend
to
be
roughly
three
categories
of
brokers
that
I
see
like
actually
in
the
wild.
The
first
category
would
be
like
main
platform
providers,
I
work
for
IBM.
We
provide
a
whole
bunch
of
brokers
on
our
kubernetes
platforms
that
we
wrote
provision
our
own
resources.
E
The
third
category
is,
there
are
actually
some
community
maintain
brokers,
so
I
used
to
contribute
a
lot
to
Cloud
Foundry,
so
that's
mostly
what
I
like
variance
with,
but
they
maintain
several
reference
implementations
of,
like
my
sequel
broker,
that
they
maintain
it's
an
open
source
project
that
adheres
to
the
thing,
but
it
like
actually
works.
It's
a
production,
ready
thing
that
you
can
deploy
and
use
with
your
own
platform.
B
E
There
are
some
brokers
in
the
wild
today
that
work
like
that.
However,
that
logic
has
to
be
implemented
on
the
broker
side.
Various
permissions
and
things
like
are
you
allowed
to
provision
the
service?
Are
you
allowed
to
delete
this
thing?
That's
sort
of
handle
the
broker
and
in
Service
Catalog
doesn't
interact
with
it
directly.
At
this
time.
There.
A
We
go,
there
is
a
user
interface
for
working
with
service
catalog.
This
is
something
that
bitNami
has
worked
on
quite
a
bit
and
they
have
this
really
slick.
Let's
see
if
we
can
make
this
ginormous
a
really
slick,
looking
a
dashboard
that
you
can
see,
basically
the
equivalent
of
that
Marketplace
command.
It
shows
you
all
the
different
classes
that
you
can
create
and
you
there's
just
like
a
visual
like
WYSIWYG.
Basically,
you
can
click
on
what
you
want
to
be
able
to
create.
It'll.
A
A
A
So
I
would
really
like
that
to
be
a
thing
diving
in
a
little
bit
to
why
we
don't
have
that
now
and
what
we
do
have.
So
we
don't
use
a
resource
per
type
of
thing,
type
of
service
that
you
could
create.
So
there
isn't
a
resource
cord
called
my
sequel
or
something
like
that.
We
have
one
resource
called
service
instance
and
our
back
operates
on
those
resources.
So
we
can
say
whether
or
not
someone
in
a
namespace,
for
example,
can
create.
A
Resources
can
bind
a
service
to
their
application
and
say
maybe
they
can
create
them
and
not
delete
them.
Things
like
that,
and
we
also
have
built
into
service
categories.
A
new
feature
is
catalog
restrictions.
An
operator
can
say
that
I'm
gonna
install
catalog
here
inside
this
namespace,
but
it's
just
for
my
my
devs
I.
Don't
want
them
to
spend
too
much
money,
so
I
can
limit
them
to
just
certain
classes
or
types
of
plans
that
are
on
the
cheaper
side.
A
E
Like
she
said
I'm
going
to
cover
some
of
this
in
my
deep
dive
session
on
Thursday
I
guess
it
is
yeah.
We
can't
restrict
at
the
global
resource
level,
but
we
do
have
lots
of
ways
to
affect
the
visibility
of
certain
instances
or
classes
such
that
you
know
only.
You
have
to
be
a
developer
in
this
namespace
to
be
able
to
see
it.
So
you
still,
let's
you
have
a
lot
of
utility
and
how
you
manage
things,
but
no,
not
globally,
using
our
back
yeah.
A
H
A
So
you
can't
upgrade
just
from
plans
say,
for
example,
you
have
the
free
tier
and
then
you
want
to
get
to
something
more
exciting,
but
we
also
have
the
ability
to
just
execute
our
actions
on
that
service
instance.
So,
for
example,
maybe
I
want
to
scale
or
I
need
to
be
able
to
do
backup
and
recovery
things
like
that.
Those
are
exposed
to
your
service
catalog
thanks
to
the
OSB
api.
So
it
is
consistent
across
brokers.
You
can
do
that
and
get
into
those
actions.
E
Are
up
to
the
brokers
themselves
to
implement
like
they
have
to
implement,
backup
and
restore
on
the
database?
The
generic
use
case
that
is
supported
is
upgrading
between
plans
so
yeah.
The
sort
of
case
guys
like
I,
have
a
little
database
I
want
to
create
it
to
a
big
database
like
that's
what
you
would
do,
yeah.
A
A
A
E
Yeah,
so
in
Oz
bappy
terms
that
would
be
upgrading
the
plan
that
your
service
instance
has
attached
to
it
and
yeah
that
goes
through
the
broker.
That's
a
specific
part
of
the
spec
that
allows
that
to
happen,
but
that's
like
a
mandatory
part
of
the
spec.
So
every
broker
allows
that
kind
of
upgrade,
but
like
the
backup
and
restore
that
kind
of
things
more
specific,
so
not
every
broker
would
support
that.