►
From YouTube: OpenShift Commons Briefing #105: Service Catalog Update (Release Candidate V 0.1.0) with Paul Morie
Description
Release Candidate 0.1.0 of Service Catalog is now out the door and its Kubernetes’ incubation process continues, it’s time for another update from the Kubernetes Service Catalog team lead, Paul Morie (Red Hat) to give a progress report and a demo of Service Catalog in action with OpenShift.
A
Well,
hello
and
welcome
again
to
another
openshift
Commons
briefing,
this
time
we're
going
to
be
talking
with
Paul
Murray
again
he's
one
of
the
leads
for
the
kubernetes
sig
on
the
Service
Catalog
work
and
you've
got
a
release
candidate
going
out
that
he's
going
to
give
us
an
update
on
and
it's
going
to
go
along
today.
So
ask
your
questions
in
the
chat.
We're
gonna
try
and
do
a
Q&A
at
the
end
and
I'm,
hopefully.
A
B
Well,
hello,
everybody
out
there
in
internet
land,
I'm,
Paul,
Maury
I
lead
the
Service
Catalog
effort
at
Red,
Hat
and
I'm.
One
of
the
sig
leads
in
the
kubernetes
community
for
Service
Catalog
and
I'm
on
the
Gobind
service
broker,
API
TMC
and
today
we're
going
to
be
talking
about
the
kubernetes
Service
Catalog,
both
kind
of
an
overview
and
refresher
for
people
that
haven't
already
seen
this
concept
and
are
familiar
with
these
things
and
then
also
talking
about
much.
B
A
B
Talking
about
an
overview
of
open
serviceworker
API,
which
I
see
a
misspelled
on
the
slide
here
array
and
then
we're
going
to
talk
through
the
Service
Catalog
API
in
kubernetes.
What
the
key
concepts
are,
what
the
main
resources
are
and
how
they
work
together
and
then
we're
gonna
see
a
little
bit
of
Service
Catalog
in
action
and
open
ship.
Three
seven.
B
B
I
don't
want
to
track
communication
with
different
parties
and
I.
Definitely
don't
want
a
post-it
note
handed
to
me
at
the
end.
That
tells
me
how
to
use
this,
so
the
service
catalogue
isn't
meant
to
centralize
these
things
and
open
service
broker.
Api
is
meant
to
define
the
interactions
between
a
catalogue
or
platform
and
the
entities
that
actually
provide
those
services
which
we
call
service
brokers.
B
So
to
just
double
down
on
that,
because
this
is
an
important
concept
that
I
found
there
to
be
some
confusion
on
in
the
kubernetes
community
and
of
its
service
broker
API
community.
Let
me
just
repeat
that
again,
so
the
open
service
broker
API
defines
a
set
of
defines
an
HTTP
interface
between
a
platform
and
the
entities
that
provide
services
which
we
call
service
brokers.
A
service
broker
is
the
component
of
a
service
that
implements
the
open
service
broker
API.
B
There
are
a
number
of
different
vendors
that
are
present
at
the
open
service
broker
API
table
in
the
working
group.
Obviously
Red
Hat,
there's
also
probably
fairly,
obviously
a
pivotal
presence
because
of
the
origin
in
the
open
service
broker,
API,
which
we'll
talk
a
little
bit
about,
but
Google
IBM,
Fujitsu,
ASAP
and
actually,
since
I
originally
created
this
slide.
Several
months
ago,
there
have
been
a
number
of
other
vendors
that
have
that
have
started
having
folks
at
10
like
Microsoft,
at
what
a
C
n,
occasionally
and
so
there's
a
number
of
different
vendors
and
it.
B
The
pool
of
vendors
that
are
interested
in
this
is
growing,
which
I
think
is
is
a
good
bellwether
for
us
as
folks
that
are
implementing
the
API
and
kubernetes
and
the
community
around
it.
That
it
seems
like
adoption,
is
going
up
so,
like
I,
said,
open,
serviceworker
API
originated
as
the
Cloud
Foundry
Service
Worker
API
in
2011,
and.
B
Mid-2016,
the
Cloud
Foundry
folks
were
having
users
and
users
of
Cloud
Foundry
coming
to
them
and
saying
we
really
like
the
service
concept.
We
want
to
use
this
in
other
platforms
that
aren't
CloudFactory,
obviously,
probably
the
biggest
gorilla
in
the
room
in
that
in
that
scenarios
kubernetes,
which
has
become
extremely
popular
over
the
last
three
years.
B
So
in
June
2017
we
made
our
first
significant
change
to
open
serviceworker
API
introduced
this
context.
Profile
concept,
which
is
sort
of
the
first
thing
that
began.
The
decoupling
of
the
API
from
Cloud
Foundry,
specific
concepts
and
context
profile
is
a
way
for
a
platform
to
send
coordinates
for
their
own
platform.
B
In
our
case,
kubernetes
about
the
about
the
context
for
an
API
request
and
we'll
talk
a
little
bit
more
about
this,
but
it's
very
important
to
us
for
kubernetes,
because
we
were
able
to
begin
sending
the
kubernetes
namespace
instead
of
using
the
buckets
for
Cloud
Foundry
coordinates
which
are
called
Oregon
space.
So
later
in
September
2017,
we
had
another
really
significant
release
where
the
three
top
things
that
are
interesting
and
important
to
us
are
that
service
brokers
can
now
communicate,
parameter
schemas
for
their
services
that
they
offer.
B
So
what
this
means
is
that
there
there's
always
been
parameter
support
for
services,
so
you
can
specify
particular
parameters
when
you
request
that
a
service
is
created,
but
you
really
had
to
know
about
those
things
before
you
did
that
the
parameter
scheme
is
important
because
it
allows
the
service
broker
itself
to
communicate
to
a
platform
that
integrates
with
it.
What
parameters
it
expects
for
certain
operations?
B
So
the
next
one
is
excuse
me
the
originating
identity,
and
what
this
is
is
a
way
for
a
platform
to
send
information
to
a
broker
for
a
particular
operation
that
describes
the
actual
user
of
the
platform,
that's
creating
or
requesting
a
particular
operation.
So
this
is
really
important
to
us,
especially
for
use
cases
where
brokers
provision
services
into
kubernetes,
which
you're
gonna
see.
We
have
a
few
different
brokers
at
Red,
Hat
that
we've
developed.
B
So
this
is
important
to
us
because
it
allows
us
to
use
the
users
quota
and
our
back
rules
in
kubernetes
to
check
and
see
do
as
a
user.
Do
I
have
permission
to
do
this
and
then
also
to
Al
those
resources
against
my
quota
and
then.
Finally,
we
added,
in
a
kind
of
roundabout
fashion,
support
for
additional
auth
flavors
in
the
API
before
this
2.13
release,
the
only
official
off
method
in
the
API
was
basic
auth
and
there
a
number
of
significantly
more
secure,
flavors
of
authentication
that
are
available
to
us.
B
So
we
use
an
open
shift
already
that
you
might
be
familiar
with,
for
example,
token-based
authentication,
which
you
get
as
part
of
getting
a
kubernetes
or
hoping
shift
service
account.
So
this
is
another
really
important
one
to
us
at
Red
Hat,
because
it
allows
us
to
use
kubernetes
service
accounts
and
their
tokens
to
secure
brokers,
which
is
really
really
important.
B
So
I
have
a
timeline
here
that
I've
already
kind
of
talked
through
this.
It's
mostly
here
for
folks
that
might
want
to
dig
into
some
of
these
details.
I'll
go
through
it
again,
just
for
completeness
and
also
because
it's
kind
of
interesting
to
me,
so
you
can
see
that
the
Cloud
Foundry
service
broker
API
began
in
2011
at
VMware
and
initially
there
was
just
support
for
five
fixed
types
of
services
there,
my
sequel,
Postgres
rabbitmq
of
MongoDB
and
Redis-
and
this
is
really
interesting
to
me.
B
B
Instead
of
just
having
the
service
burger
have
to
do
the
work
within
the
life
span
of
a
single
HTTP
call.
This
is
really
powerful
because
it
lets
service
workers,
do
a
lot
more
work
and
opens
up
the
possibility
to
create
services
that
require
a
significant
amount,
significant
amount
of
time
to
stand
up.
So
then,
as
I've
already
talked
about
in
2016,
it
was
renamed
to
open
service
broker
API
and
then
in
2017.
B
B
So
that
brings
us
to
the
centerpiece
of
this
briefing,
which
is
the
kubernetes
Service
Catalog,
and
you
probably
already
have
an
idea
of
what
this
is.
Even
if
you
haven't
seen
the
kubernetes
Service
Catalog
before,
because
of
what
I've
already
talked
to,
but
just
to
put
a
fine
point
on
it.
The
kubernetes
Service
Catalog
is
an
integration
between
kubernetes
and
brokers
that
implement
the
open
service
broker
API
another
little
history
lesson.
Here.
B
But
one
of
the
foremost
things
that
I'll
mention
I'll
definitely
mention.
This
again
is
that
the
the
Service
Catalog
is
really
one
of
the
first
proving
out
of
the
concept
of
making
an
extension
to
kubernetes,
which
has
an
architecture
similar
to
kubernetes
itself,
and
something
that
was
a
challenge
for
us
in
this
group
is
that
the
cig
originally
was
populated
with
folks.
B
We
released
our
first
beta
release
of
Service
Catalog,
and
this
is
a
really
important
milestone
in
the
kubernetes
community,
because
when
you
call
something
beta,
it
means
that
you
have
to
maintain
API
backward
compatibility
with
it,
and
that's
that's
important
both
for
users
in
the
set.
A
lot
of
users
won't
touch
things
that
are
helped
up,
because
it
could
be
quicksand
right
like
it
could
change
underneath
you
and
that's
what
the
purpose
of
alpha
is
is
to
designate
those
things
that
are
still
really
in
the
beginning
of
their
development
as
being
so.
B
But
it
also
kind
of
means
that
people
with
a
high
tolerance
for
change
are
going
to
be
most
interested
in
this
thing,
so
beta
is
very
significant
to
us
at
Red
Hat,
also
because
it
means
that
we
can.
We
can
take
off
the
tech
creamy
designation
in
open
ship
3:7
for
service
catalog,
which
is
important
for
us,
and
it's
important
for
users,
because
users
know
that
there's
going
to
be
backward
compatibility
with
future
API
changes,
so
the
primary
contributors
are
players
that
I've
already
kind
of
mentioned
a
little
bit
red
hot
Red.
B
We
try
to
be
a
friendly
bunch
in
the
sig
and
it's
also
a
good
way
to
learn
urban
Eddie's
without
some
of
the
overload
effect
that
you
might
have.
If
you
go
and
try
to
look
at
the
main
kubernetes
repository,
it's
a
lot
smaller
than
thank
you.
Burnett
ease,
kubernetes
doe,
alpha
to
beta
what
changed
a
lot
of
things
that
turns
out
from
a
feature
standpoint.
B
We
now
have
support
for
that
originating
identity
feature
that's
in
the
open
service
broker,
API
now,
which
is
important,
especially
to
us
at
Red
Hat
having
a
lot
of
broker
provision
resources
back
into
kubernetes
and
open
shipped
and
then.
Finally,
we've
completed
the
implementation,
open
service
broker
API
in
kubernetes
by
adding
support
for
plan
and
parameter
updates
for
instances
of
services.
So,
if
I
make
a
service
instance
and
that
service
supports
plan
updates,
like
going
from
a
bronze
plan
to
a
gold
plan,
I
cannot
do
that
in
the
Service.
B
B
That
allows
you,
as
a
cluster
operator,
to
register
new
API
servers
that
provide
new
API
groups
and
resources
with
kubernetes
and
allow
your
users
to
use
the
things
just
like
they
were
part
of
the
main
kubernetes
api
server,
which
is
a
really
fundamental
capability
to
the
story
that
we
expect
to
be
dominant
for
how
you
extend
kubernetes
in
the
future
and
we'll
talk
a
little
bit
more
about
this.
Once
we
get
into
the
API
details,
we've
also
had
a
significant
refinement
of
the
API
resources
in
terms
of
what
the
kubernetes
way
of
doing
things
is.
B
There
were
some
unique
challenges
that
we
had
to
get
over
due
to
the
different
styles
of
kubernetes
api
s
and
the
open
serviceworker
api.
But
the
end
result
is
that,
as
a
user,
you
can
now
take
a
look
at
one
of
your
service
instances
and
get
a
much
better
idea
of
what
is
actually
happening
currently
and
what
the
last
thing
to
complete
that
the
broker
knows
about
which
gives
you
a
much
better
idea
on
the
ground
of
exactly
how
the
thing
works,
which
is
very
important
and
also
what's
happening.
B
Probably
and
then
last,
but
certainly
not
least,
we
vastly
improved
the
error
handling
in
the
Service
Catalog.
So
we
cannot
correctly
handle
operations
that
timeout
or
fail,
and
we
can
also
correctly
handle
the
corner
cases
like
if
a
user
creates
a
new
service
instance
and
it's
being
provisioned
and
then,
while
it's
being
provisioned,
they
deleted
will
handle
that
correctly.
Now,
where
that
was
something
that
wasn't
especially
mature
during
the
early
out
of
releases,
so
Service
Catalog,
API
concepts.
B
Here's
where
we
get
into
the
nitty-gritty
of
the
nitty-gritty
details
of
exactly
what
this
API
looks
like
in
kubernetes
we're
going
to
just
talk.
First,
very
briefly
about
the
operations
that
are
part
of
the
open,
serviceworker
API,
because
the
API
resources
we're
going
to
talk
about
mirror
these
things
to
a
very
great
degree.
The
open
service
broker
provides
five
fundamental
operations.
A
broker
can
tell
you
which
services
it
offers
and
then
there's
a
provision
operation
where
a
new
instance
of
a
service
is
created
and
new
resources
are
allocated.
B
There's
a
bind
operation
that
creates
resources
to
allow
applications
to
communicate
with
an
instance
of
a
service,
and
then
those
last
two
have
symmetrical
operations
where
they
get
deleted.
So
when
you
delete
a
binding,
it's
called
unbind
where
the
binding
is
removed
and
when
you
delete
in
service
instance,
is
called
D
provisioning,
where
the
resources
associated
with
that
service
instance,
a
D
allocated
and
the
instance
is
delete.
B
When
we
talk
about
these
concepts
in
kubernetes,
let's
just
put
a
very
specific
fine
point
on
these
things.
A
service
broker
is
something
that
manages
a
set
of
capabilities
which
we
call
services.
A
service
class
is
a
particular
capability
managed
by
a
service
broker,
and
the
canonical
example
that
most
people
can
relate
to
about
this
is
a
service
class
might
be
a
database
as
a
service
service
classes
have
plans
which
are
a
specific
tier
or
offering
of
that
service.
B
B
B
The
API
server
is
backed
by
a
controller
that
is
watching
the
API
server
and
responding
to
events
that
the
API
server
sends
out
about
the
resources
that
it
stores
the
controller
is
the
entity
that
actually
implements
the
behaviors
of
the
Service
Catalog
API,
and
in
this
case
the
controller
is
doing
the
work
of
talking
and
communicating
to
the
brokers
and
saying
to
the
broker.
We
want
to
make
a
provision
a
new
instance.
B
Here's
a
pictorial
representation-
and
you
can
see
on
the
left-hand
side
of
the
screen
this
box,
for
the
CLI
you
can
think
of
this-
is
just
being
any
client
right
like
it
might
be
a
user
using
the
CLI.
It
might
be
a
that's
programming
against
the
service,
catalog
API,
it
might
be
the
open
ship
console,
but
clients
speak
to
the
API
and
for
simplicity
sake
in
this
picture.
We've
omitted
the
API
aggregator,
but
they
speak
to
the
API
using
going
through
the
API
aggregator.
B
The
Service
Catalog
controller
is
has
established,
watches
on
the
API
server
and
implements
the
behavior
of
talking
to
the
brokers
that
are
registered
into
the
catalog
and
then
is
persisting.
Changes
back
into
the
Service
Catalog
API
server,
for
example,
to
update
the
status
of
the
different
resources
and
also
persisting
information
about
bindings
into
the
kubernetes
api.
Using
a
secret
resource.
B
So
when
we
talk
about
the
API
resources
of
the
Service
Catalog
API,
there
are
five
of
them
and
if
you
saw
our
last
Commons
briefing
on
the
Service
Catalog,
you
notice
that
this
this
number
climbed
up
by
one
which
I
will
talk
about,
but
there
are
basically
three
resources
that
are
mostly
for
cluster
operators
and
to
resources
that
end
users
use
the
the
ones
for
operators.
Are
the
cluster
service
broker
resource
cluster
service
class
cluster
service
plan?
B
These
are
cluster
scoped,
meaning
they
live
outside
of
a
namespace,
and
these
are
for
cluster
operators
to
use
to
register
a
broker
in
and
then
a
register
a
broker
in
the
catalog.
And
then
the
controller
creates
these
cluster
service
class
and
cluster
service
plan
resources
to
model
the
services
that
are
in
the
catalog
in
flame
that
they
get
back
from
the
broker.
The
service
instance
and
service
binding
resources
are
how
the
user
creates
new
instances
and
bindings
to
service
instances.
B
B
Service
worker
this
resource
represents
a
particular
broker
that
the
Service
Catalog
should
show
services
and
plans
from
you
can
see
that
this
resource
is
spec
and
I.
Think
yeah,
you
should
be
able
to
see.
My
mouse
has
a
hoops
has
a
URL
where
the
catalog
should
contact
that
broker
and
then
also
has
auth
information
where
you
can
in
you
can
reference
a
secret
that
has
a
authentication
token
to
communicate
and
authenticate
to
that
broker.
B
So
let's
look
at
a
picture,
and
this
is
a
little
out
of
date,
but
I
think
that
it
will
still
be
very,
very
clear.
Just
the
resource
names
have
changed
and
there's
a
new
resource
that
isn't
captured
on
here,
which
I'll
talk
about
so
in
step.
One,
the
cluster
operator
makes
a
broker
cluster
service
broker
resource
and
creates
it
in
the
Service
Catalog
API
server.
The
catalog
controller
gets
an
event
saying
that
that
new
cluster
service
broker
resource
was
added.
B
It
goes
and
in
books,
this
catalog
endpoint
at
the
actual
broker,
which
is
running
you,
you
know
potentially
in
the
same
cluster
kubernetes,
cluster
or
somewhere
out
on
the
internet,
and
it
gets
back
a
payload
from
the
broker
that
contains
information
about
services
that
broker
offers
in
their
plans.
So
the
service
catalog
controller,
transforms
that
information
into
the
cluster
service
class
and
clusters
service
plan
resources
and
persist
those
back
into
the
Service
Catalog
API
server.
B
So,
let's
look
at
cluster
service
class
and
cluster
service
plan,
really
quick,
the
cluster
service
class,
as
I've
said
it
represents
a
particular
offering
in
the
catalog,
and
one
thing
that
you
will
notice.
If
you
use
the
alpha
version
of
the
API
is
that
the
name
here
is
is
actually
a
an
ID
you'll,
also
notice
down
here,
that
we
have
these
external
ID
and
external
name
fields
in
the
spec
and
the
reason
for
this
well.
B
B
So,
let's
take
a
look
also
at
the
I'm.
Sorry
I
skipped
over
something.
So
last
thing
on
this
slide.
The
spec
plan
updatable
field
describes
whether
instances
created
of
the
service
can
change
plans.
Not
every
plan
supports
this
or
I'm.
Sorry,
not
every
service
support
is
this,
but
some
services
do
support
changing
from,
like
a
bronze
plan
to
a
gold.
B
With
these,
we
had
to
use
open
service
broker,
might
D
as
the
name
of
these
resources
for
now,
because
the
names
can
change
and
there's
also
you'll,
see
on
here
in
the
spec,
a
free
field
that
indicates
whether
there's
a
monetary
cost
for
this
plan,
so
that
kind
of
rounds
out
the
resources
that
are
created
by
the
cluster
operator
and
then
the
catalog
in
response
to
the
cluster
service
broker
resource
being
created.
Let's
talk
about
the
service
instance
resource,
which
is
the
central
resource
that
users
interact
with
to
create
new
instances
of
these
services.
B
In
the
future,
we
will
probably
have
name
spaced
versions
of
the
service
broker
services
service
class
in
service
plan
resources,
so
that
users
can
set
up
a
broker
just
in
their
namespace
without
exposing
that
broker
to
the
rest
of
the
cluster
or
having
to
have
permission
to
create
the
cluster
level
brokers.
So,
let's
dig
into
this
thing.
As
I
said,
users
use
the
human
readable
names
to
specify
what
service
in
plan
they
want
to
make
an
instance
of
so
you'll
notice.
B
B
They
say
the
user
provided
service
and
the
default
plan
and
the
Service
Catalog
controller
resolves
those
to
the
actual
kubernetes
names
and
sets
these
reference
fields
so
that
it
can
translate
between
what
the
user
wants
and
what
are
the
coordinates
of
those
things
at
ease
and
then
you'll
see
below
that
there's
an
external
ID
field.
This
is
generated
by
the
Service
Catalog
API
server,
and
it's
the
ID
of
this
service
instance.
B
That's
actually
used
to
communicate
with
the
open
service
broker,
API
and
then
below
that
you'll
see
that
there's
a
parameters
field
and
you
can
specify
parameters
either
in
line
like
we've
done
here
and
I
realized.
Now
that
the
credentials
bucket,
that's
part
of
the
parameters,
that's
very
poorly
named,
you
should
not
put
credentials
in
line
into
a
service
instance.
You
should
instead
reference
them
from
a
secret
which
I
didn't
have
the
space
to
show
here.
B
But
that
is
another
thing
that
you
can
do,
which
we
always
put
parameters
into
a
secret
when
you
use
the
open
ship
console
so
that
sensitive
information
doesn't
go
into
a
resource
that
doesn't
have
the
right
protections
on
it.
But
let's
talk
about
before
we
get
too
lost
in
the
details.
Let's
talk
about
the
workflow
when
I
create
this
resource.
So
as
a
user
I
create
a
new
service
instance
resource
in
the
API
server,
it
gets
that
ID
generated
for
it.
B
It
gets
the
references
resolved
to
the
actual
service
class
and
plan
and
I'm
sorry
gets
the
ID
generated.
The
controller
gets
an
event
saying
that
the
service
instance
was
created.
It
resolves
the
service
class
and
service
plan,
and
then
it
talks
to
the
broker
and
says
we
want
to
provision
a
new
service
instance
with
this
idea
of
this
service.
In
this
plan,
the
broker
then
goes
and
does
the
work
to
allocate
that
resource
and
it
might
use
the
old
synchronous
style
word.
B
Maybe
the
service
broker
can
just
do
this
work
and
one
HTTP
call,
or
it
might
tell
the
catalog
controller-
hey
I've
accepted
your
request.
Call
me
back
and
see
if
I'm
done
yet
and
keep
calling
me
back
until
I'm
done
and
service
catalog
control
handles
that
coordination
and
ultimately
updates
the
status
of
the
service
instance
to
let
the
user
know
what
happened
and
reflect
on
the
service
instance
status.
What
parameters
the
broker.
B
These
are
a
couple
slides
about
asynchronous
provision
I
on
this,
so
that
you
have
a
chance
watching
the
video
to
to
drill
into
the
details
here,
I'm
running
a
little
short
on
time,
but
this
slide
is
fairly
self-explanatory,
so
I'm
gonna
skip
over
it
and
go
to
service
binding.
So
a
binding
is
a
relationship
between
an
application
in
a
service
instance
and
you'll
notice.
This
resource
is
also
named
spaced.
B
B
Currently,
you
can
just
refer
to
a
service
instance,
that
is
in
your
name
space,
but
in
the
future,
it's
very
likely
that
we
will
have
the
ability
for
you
to
make
a
binding
to
a
service
instance.
That's
in
another
name,
space
that
you've
been
granted
access
to
and
then
finally,
the
last
part
of
the
spec
is
a
secret
of
the
name
of
a
secret
to
inject
the
binding
credentials
for
for
this
service
binding
into
and
that
secret
is
created
by
the
Service
Catalog
controller
and
will
ultimately
hold
the
credentials
for
that
service
instance.
So,
let's.
B
Our
picture
again
consumer
creates
a
new
service
binding
in
the
API
server
controller,
detects
that
new
binding
it
talks
to
the
service
broker
that
offers
that
service
and
says,
let's
make
a
new
binding.
Can
the
broker
does
the
work
to
do
that
and
hands
credentials
back
to
the
Service
Catalog
controller?
And
then
the
catalog
controller
creates
a
kubernetes
secret
with
the
binding
credentials
and
updates
the
binding
service
finding
resource
service,
finding
resources
status
to
show
what
happened
to
it.
B
When
you
want
to
remove
these
things,
it's
very
easy.
You
you
just
delete
the
kubernetes
resources
that
correspond
to
the
thing
that
you
want
to
remove.
So
if
you
want
to
unbind,
you
delete
the
service
binding
that
you
want
to
get
rid
of,
and
the
Service
Catalog
controller
does
the
same
kind
of
thing
where
it
tells
the
broker
to
unbind
a
particular
binding,
and
when
you
want
to
deep
provision
an
instance
of
a
service,
you
do
the
same
thing.
You
delete
the
service
instance
and
catalog
controller
handles
talking
to
the
broker
about
that.
Now.
B
What's
really
exciting
to
me
is:
there's
been
a
lot
of
work
in
the
console
to
enhance
the
service
catalog
experience,
so
you
get
really
nice
icons
for
services
now,
if
the
broker
communicates
what
icon
to
use
back
to
you,
this
is
pretty
central
part
of
the
landing
page
and
there's
been
a
lot
of
work
to
incorporate
all
the
API
constructions.
That
I
referred
to
about
status
into
the
console
to
reflect
things
back
to
users
about
what
is
going
on
with
a
service
that
they've
provision
so.
A
B
You
can
see
what
image
dependencies
it's
got
and
you
can
click
through
then
and
choose
a
plan
once
you
choose
that
plan,
you
can
provide
some
parameters,
and
these
are
driven
off
of
the
parameters
schema
that
I
referred
to
earlier
in
an
open
service
broker
API.
So
this
just
to
drive
home
exactly
how
important
that
is.
That
allows
us
to
make
a
user
interface
that
can
tell
users
what
knobs
they
have
to
set.
B
So
I
don't
know
about
folks
watching
this
call.
But
it's
really
awesome
to
me
to
think
about
all
the
different
possibilities
that
this
enables.
It
makes
easy-to-use
Vav
open
ship
console
I'm,
really
impressed
with
the
work
that
Red
Hat.
U
XD
and
the
OpenShift
UI
team
is
done
for
this
really
cool
stuff
and
that's
that
is
basically
the
end
of
it,
so
hope.
B
A
A
couple
of
questions
and
and
moat
and
mostly
I.
Think
though,
if
you
go
back
to
the
end
mask
question
here,
one
was
asking
that
whether
it
the
unmask
service
broker
was
going
to
be
available
in
the
launch
of
open
ship,
three
points
and
I
believe
so,
but
he's
wondering
you're
sitting
in
the
middle
of
the
engineering
team.
So
maybe
you
know
better
I'm.
A
So
we'll
post
this
slides
for
this,
this
talked
into
a
blog
post
and
tomorrow
or
Friday.
What
we're
going
to
record
the
demos
of
all
the
OpenShift
3.7
capabilities
with
the
service
broker
and
include
that
someone
is
asking
you
to
come
to
see
this
to
will
a
PV
catalog
items,
potential
EVP
part
of
three-point-seven
I.
A
A
This
this
session
has
run
pretty
long
and
I
really
do
want
to
get
the
demos
out
there.
So
I'm
gonna
I've
asked
Paul
to
record
them
separately
from
this
and
then
we'll
post,
those
on
blog
OpenShift
comm,
hopefully
by
the
end
of
this
week
and
they'll
tweet
that
out
and
send
it
to
the
mailing
list
as
well.
A
Paul
is
going
to
be
with
me
and
a
whole
bunch
of
other
open
shifters
on
August
August,
right,
December
5th
in
Austin
Texas
the
day
before
coupon
and
talking
about
service
broker
and
be
there
and
available
to
answer
questions
as
well.
So
if
you
haven't
registered
yet
for
that
event,
please
do
so
it's
going
to
be
really
a
lot
of
interesting
conversations
with
upstream
project
leads
and
people
who
are
deploying
openshift
on.
A
So
we
hope
to
have
you
all
there
with
us
as
well.
That
really
brings
us
to
the
end
of
the
hour.
Paul
did
a
great
job
giving
an
overview,
and
we
will
post
this
as
soon
as
possible
and
I
will
make
an
announcement
on
the
mailing
list
as
well
and
in
social
media.
We'll
probably
record
the
demo
is
live
as
well
with
a
little
Q&A.
B
A
B
A
And
to
the
AWS
question:
John
David
Duncan
from
AWS
will
also
be
at
the
open
chip,
Commons
gathering
and
I'm.
Pretty
sure,
that's
what
he's
going
to
be
talking
about.
So
please,
please
do
join
us.
There
there'll
be
a
lot
of
good
content
that
will
get
you
up.
So
that's
what
we
have
and
we'll
sign
off
for
now.