►
Description
The Kubernetes service-catalog project is in incubation to bring integration with service brokers to the Kubernetes ecosystem via the Open Service Broker API. A service broker is an endpoint that manages a set of services. The end-goal of the service- catalog project is to provide a way for Kubernetes users to consume services from brokers and easily configure their applications to use those services, without needing detailed knowledge about how those services are created / managed.
In this session, Paul Morie and Andrew Block provid a deep dive into the beta release of the service-catalog that is being made available for use in conjunction with Kubernetes 1.7
A
Hello,
everybody
and
welcome
again
to
yet
another
OpenShift
Commons
briefing.
Today
we
have
two
Red
Hatters
with
us.
Paul,
Murray
and
Andrew
block
Paul
has
been
working
diligently
on
kubernetes
and
on
the
Service.
Catalog
and
andrew
has
been
deploying
it
lots
of
working
on
getting
ready
to
deploy
it
in
different
places,
and
we
thought
since
1.7
kubernetes
is
out
the
door.
This
would
be
a
good
time
to
do
an
update
and
an
overview
on
the
Service
Catalog.
B
C
Sure,
thanks
Paul.
So,
as
Diane
mentioned,
my
name
is
Andrew
block
I'm,
a
principal
consultant
with
Red
Hat,
consulting
and
I
specialize
in
red
hats
cloud
and
integration
solutions
and
work
primarily
with
our
customers
to
adopt
and
implement
these
technologies
within
their
organization
and
I'm.
Also
here,
as
we
mentioned
by
Paul
Mori,
who
can
kind
of
give
an
introduction
about
what
he
is
currently
doing
in
the
kubernetes
ecosystem,
Paul
yeah.
B
So
I
work
on
a
kubernetes
at
Red
Hat
and
most
recently,
I've
been
leading
the
six
service
catalog
special
interest
group
in
the
kubernetes
community
and
in
addition
to
that,
I
am
on
the
working
group
committee
for
the
open,
serviceworker
API
and
in
general
kind
of
track.
All
things.
Engineering,
things
related
to
catalog
and
Red
Hat.
C
Awesome
thanks
Paul,
so
during
today's
session,
we're
going
to
talk
about
a
number
of
different
topics.
First,
we're
going
to
start
talking
about
some
of
the
common
patterns
that
are
utilized
for
service
creation
and
consumption,
and
a
desire
to
have
a
more
streamlined
process
will
then
introduce
the
open
service
broker
API
and
talk
about
its
history
and
how
it
relates.
Today,
then,
we'll
discuss
the
efforts
there,
I'm
going
inside
the
kubernetes
community
and
the
efforts
that
are
being
done
to
consume
the
open
service
broker.
C
Some
of
the
theoretical
concepts
behind
the
Service
Catalog
ecosystem,
we'll
discuss
some
of
the
implementations
that
have
derived
out
of
the
service
catalog
and
within
the
open
ship
ecosystem
and
then
finally,
we'll
highlight
some
of
the
features
that
will
be
available
with
the
release
of
OpenShift
version
3.6.
I
next
slide.
C
So
when
creating
applications,
developers
typically
need
to
access
some
form
of
service
in
which
they
can
connect
their
applications.
To
this
typically
takes
the
form
of
a
database
that
provides
back-end
storage
or
a
message
queue
that
can
be
used
to
connect
multiple
dispersed
systems.
It
also
can
may
include
resources
within
an
existing
software
as
a
service
solution.
Now,
I
work
with
many
organizations,
both
big
and
small,
and
one
of
the
common
challenges
that
I
see
are
from
application.
Teams
is
the
efforts
that
they
need
to
work
through
to
make
services
available
to
them.
C
These
systems
are
typically
not
maintained
by
the
application
teams.
So
in
most
cases
they
need
to
make
some
form
of
requests
for
the
service
to
be
made
available
to
them,
such
as,
as
I
mentioned
earlier,
a
creation
of
a
database
or
queue
within
a
messaging
system.
But
then,
once
they
have
those
provisions,
how
can
they
then
make
use
of
the
new
service
available
so
in
the
next
slide?
C
D
C
C
Team
will
then
allocate
the
resources
and
it
makes
the
details
back
to
the
originating
requester.
Now,
in
many
cases,
this
whole
process
may
involve
the
interaction
of
multiple
teams
and
require
multiple
approvals
along
the
way.
Now,
heaven
forbid,
a
portion
of
that
request
was
submitted
incorrectly,
as
that
will
only
surveyed
the
time
that
it
takes
to
make
the
service
available
to
the
application
teams.
I've
been
with
many
customers
and
to
get
some
simple
resources
you
may
think
of
it
simpler
resources
available
for
them
to
start
using.
C
It
can
take
anywhere
from
a
week
to,
depending
on
the
complexity
and
the
number
of
approvals
that
are
required,
it
could
even
take
up
to
a
muffin
in
today's
world.
That's
a
long
time
next
slide.
So
would
it
be
nice
if
there
was
some
sort
of
central
locations
for
which
providers
of
a
service
could
make
their
assets
available
to
consumers
and
for
consumers
to
have
a
process
which
they
can
manage?
C
The
lifecycle
of
services,
possibly
in
some
sort
of
simple
interface
or
dashboard,
where
users
can
be
self-sufficient
now
ready
had
has
a
product
called
cloud
forms
that
can
be
used
to
provide
some?
Don't
some
form
of
catalogue
of
services?
However,
the
difference
here
is:
we
want
to
have
a
more
desired,
a
desirable
standardized
process,
and
that's
really
what
the
open
service
broker
API
set
out
to
do.
Next
slide.
C
There
are
two
primary
parties
involved
in
the
open
service
broker.
Api
first
is
the
endpoints
that
becomes
an
internet
intermediary
between
a
platform
and
the
entities
that
provide
a
set
of
services
which
are
better
known
as
service
brokers.
The
catalog
listens
for
requests
and
execute
actions
on
behalf
of
the
behavior,
on
behalf
of
the
related
brokers,
the
service
brokers
themselves
of
the
components
to
implement
these
open
service
broker.
Api
next
slide.
C
So
the
open
service
broker
API
has
come
a
long
way
since
the
concept
of
the
service
broker
was
open
sourced
by
VMware.
In
the
Cloud
Foundry
ecosystem
in
2011,
and
at
that
time
it
was
mostly
exposed
and
contained
of
database
services.
So
this
includes
my
sequel,
Redis,
MongoDB,
rabbitmq
and
Postgres,
just
to
name
a
few.
C
Now
since
then,
two
major
milestones
have
occurred
in
2013,
the
entire
platform
was
rewritten
and
released
as
a
version
2,
which
extended
the
flexibility
of
the
platform
and
in
2015
asynchronous
processing
was
incorporated
to
decouple
the
catalog
for
the
broker
during
the
long-running
operations
such
as
provisioning.
It
sometimes
takes
a
few
minutes
to
provision
a
new
database
or
new
service
that
asynchronous
processing
really
helped,
and
then
last
year
in
2016,
the
open
service
broker.
C
Api
specification
was
officially
released,
paving
the
way
for
additional
platforms
outside
the
Cloud
Foundry
ecosystem
to
make
use
of
the
specification
next
slide.
So
just
to
recap,
from
the
prior
slide,
the
open
service
broker
API
is
a
successor
of
the
cloud
foundry
service
broker
and
included
in
this
open
service
broker.
Api
is
the
exist,
the
entire
existing
ecosystem,
along
with
the
API
portion,
and
to
expand
upon
some
of
the
events
that
occurred
last
year
in
2016,
the
workgroup
the
open
service
broker.
C
Api
was
formed
in
September,
and
the
public
announcement
occurred
in
December
next
slide,
so
the
open
service
broker
API
currently
has
contributions
and
representation
from
a
number
of
companies.
These
companies
and
include
Google,
pivotal
IBM,
Fujitsu
and,
of
course,
redhead
who
are
making
a
lot
of
strides
on
this
effort
and,
if
anyone's
interested
in
browsing
the
specification
it's
available
out
on
github,
so
I
highly
encourage
those
interested
to
take
a
look
at
the
content
next
slide.
C
C
Scoober
Native,
Service,
Catalog,
special
interest
group
or
TIG
is
working
on
the
open
service
broker.
Api
is
the
interface
and
the
kubernetes
service.
Catalog
is
implementation.
It
is
the
integration
between
kubernetes
and
brokers
that
implement
the
open
service
broker.
Api.
Now
the
history
of
the
sig
parallels
many
of
the
efforts
of
the
open
service
broker
API.
Thus
it
was
formed
in
September
of
2016.
B
So
one
thing
that
I
want
to
know
before
we
get
started
is
that
the
Service
Catalog
is
currently
in
an
alpha
state
and,
as
part
of
going
to
beta,
we'll
probably
be
making
changes
to
the
names
of
some
of
these
resources
in
terms
as
they
relate
specifically
to
the
Service
Catalog
at
some
point
before
beta.
So
do
keep
in
mind
that
the
names
for
some
of
these
things
might
change
slightly.
B
B
The
the
foundational
concept
of
the
open,
serviceworker
API,
is
really
the
serviceworker
itself.
The
service
broker
is
an
entity
that
manages
a
set
of
capabilities
that
are
called
services,
so,
for
example,
a
service
in
this
lexicon
might
be
something
like
a
database
as
a
service
services
have
plans
which
are
a
specific,
offering
routier
that
service.
So,
for
example,
our
database
as
a
service
might
have
different
tiers,
starting
with
free
and
going
up
to
medium
and
large,
which
might
have
to
pay
for
when
we
instantiate
a
particular
services
capability.
B
Relationship
between
a
service
instance
in
an
application
is
called
a
binding
so,
for
example,
continuing
our
database
as
a
service
metaphor,
a
binding
might
equate
to
credentials
being
created
in
the
database
that
our
instance
represents
and
being
returned
to
the
users,
so
they
can
use
it
in
a
consuming
application,
and
just
for
the
record
here,
application
is
meant
as
a
very
general
term
that
just
describes
code
that
will
access
or
consume
a
service
so,
for
example,
our
web
application
that
requires
database
credentials.
We
can
think
of
as
an
application.
B
There
are
really
only
five
fundamental
operations
in
the
open
service
worker
API.
The
first
is
catalog
management,
and
this
is
an
instance
where
we
have
a
slightly
inconvenient
overload
with
some
of
the
other
names
that
are
in
the
mix
when
we
say
catalog
management.
Here.
What
we
referred
to
is
that
the
broker
the
I'm
sorry,
the
open
service
broker
API
has
an
endpoint
that
returns
the
list
of
services
that
that
particular
broker
offers.
B
The
provision
endpoint,
is
how
you
access
the
facility
for
creating
new
instances
of
a
service.
The
bind
endpoint
allows
you
to
create
new
bindings
and
then
there's
also
an
unbind
operation
that
uses
delete
with
the
same
endpoint
that
removes
a
binding
and
then
a
deep
revision
operation
that
uses
delete
with
the
revision
implant
that
removes
an
instance
Oh
the
architecture.
The
service
catalog
is
very
similar
conceptually
to
the
architecture
of
kubernetes
itself.
B
B
So
let's
take
a
look
at
the
high-level
architecture,
so
we
can
visualize
some
of
these
things.
You
can
see
on
the
left,
the
CLI
you
can
think
of
that
as
being
either
the
CLI
or
any
client
of
this
API
talks
to
the
the
kubernetes
Service
Catalog
API
server,
the
Service
Catalog
controller
is
watching
the
API
server
and
events
that
indicate
that
things
have
happened
to
resources
in
that
API
server.
That
controller
should
process,
and
then
you
can
see
also
that
the
catalog
controller
speaks
to
all
of
the
brokers
in
the
system.
B
One
thing
I
want
to
emphasize
here
is
that
the
broker
is
the
component
that
manages
a
set
of
capabilities.
The
service
catalog
is
the
integration
between
kubernetes
in
those
brokers
that
uses
the
open
service
broker
API.
So
it's
important
to
make
a
distinction
between
the
service
catalog
and
a
particular
broker.
B
The
catalog
controller
is
also
responsible
for
talking
to
the
primary
kubernetes
api,
which
it
needs
to
do
it
for
things
like
ensuring
that
a
namespace
exists
or
namespace
resources
and
for
manifesting
the
results
of
bindings
back
into
kubernetes,
so
the
model
that
we
have
for
the
kubernetes
Service
Catalog
API
is
very
simple.
There
are
only
about
4
resources,
although
we've
recently
decided
in
the
sig
that
we'll
probably
split
one
of
these,
which
I'll
talk
through
as
I
get
to
it.
So
the
current
API
resources
that
we
have
are
the
broker
resource
is
fairly
self-explanatory.
B
Here's
an
example
of
a
service
class
resource.
If
you
take
note
of
the
parenthesized
numbers,
you
can
see
some
important
things
about
this.
The
service
class
has
a
reference
to
the
broker
that
provides
it.
It
has
a
field
also
that
says
whether
the
service
is
bindable.
Not
all
services
are
bindable
or
makes
sense
to
use
with
the
binding
most
of
the
ones.
That
immediately
probably
come
to
mind
are
things
that
you'd
want
to
bind
to,
but
not
everything
is
findable.
B
The
service
class
has
an
array
of
the
services
plans
that
have
some
information
about
that
plan.
For
example,
a
it's
tough
to
show
on
a
slide
like
this,
but
one
of
the
things
that
a
broker
can
provide
about
a
plan
is
a
schema
for
what
parameters
that
plan
accepts.
I
also
want
to
note
that
service
class
is
a
global
resource.
B
So
here's
an
example
of
an
instance,
remember
instance,
represents
an
intent
to
provision
a
new
logical
instance
of
a
particular
capability.
I
and
I
do
not
call
out
that
the
instance
resource
is
namespace
scoped,
so
just
to
make
this
clear
broker
and
service
class
are
global
instance
and
later
we'll
see
binding
or
namespace
scoped.
B
So
the
instances
spec
has
a
reference
to
the
name
of
the
service
class
that
it
is
an
instance
of
and
which
plan
of
that
service
class
the
instance
is
currently
on.
There
are
also
parameters
and
I
want
to
call
out
that
the
Yambol
for
the
parameters
will
very
likely
change,
since
we
recently
made
a
decision
on
that
that
I'll
talk
through
a
little
later
on
the
list
of
parameters
is
optional,
but
they're
frequently
used
to
change
attributes
the
service
instance.
That's
provision,
here's
an
example
of
a
binding,
like
instance.
B
B
B
The
important
things
about
1.6
are
that
in
1.6
we
added
initial
support
for
the
API
Hager
aggregation
feature
that
I'd
spoke
about
earlier,
and
the
cube
CTL
client,
which
the
OC
client
is
based
on
added,
really
good
generic
resource
support.
So,
prior
to
this
cube,
CTL
+
OC
were
only
able
to
show
rich
descriptions
of
resources
that
there
was
code
compiled
into
the
client
for
and
in
kubernetes
1:6.
The
generic
resource
of
work
made
it
possible
to
have
a
much
more
native
experience
when
working
new
API
servers
that
aren't
known
to
the
client
already.
B
So,
in
addition
to
the
kubernetes
one,
six
cluster
or
open
should
three
six
cluster
I.
You
need
to
have
the
core
infrastructure
deployed,
which
is
the
Service
Catalog
API
server,
the
Service
Catalog
controller
and
the
API
server
has
to
be
configured
in
open
strip.
Three
six,
the
OSI
cluster
up
tool
can
do
this
for
you
and
there
will
be
installer
support
that
allows
you
to
set
up
the
catalog
when
you
create
a
new
open
ship
cluster.
B
What
happens
is
that
the
controller
will
contact
the
broker
on
that
the
broker
specs
URL,
and
it
will
fetch
the
that
brokers,
catalog
of
services
and
transform
them
into
the
service
class
resource
and
then
persist
that
back
into
the
kubernetes
service,
catalog
API
server.
Here's
a
picture
of
all
this
happening
so
first
off
the
platform
operator,
creates
a
new
broker
resource.
B
So,
like
all
other
kubernetes
api
s,
the
service
catalog
api
is
in
tension
based
and
what
this
means
is
that
when
we
create
a
resource,
it
represents
our
intention
that
something
should
happen
so
to
provision
a
new
instance
of
a
service
class.
We
create
a
new
instance
resource
and
supply
parameters.
If
we,
if
the
service
class
and
plan
that
we're
using
accept
them
and
the
controller
gets
a
watch
event
saying
that
a
new
instance
is,
it
has
been
requested
and
goes
and
talks
to
the
broker
to
provision
or
protocol
provision
a
new
instance.
B
B
After
that's
persisted,
the
catalog
controller
gets
a
watch
event
and
calls
provision
at
the
broker.
The
broker
does
some
work
to
allocate
a
resource
and
replies
to
the
catalog
controllers,
saying
done
or
possibly
is
ongoing
asynchronously
which
we'll
talk
about
in
a
second
and
then
the
Service
Catalog
updates
the
instance
with
the
status
that
reflects
what
happened,
whether
the
provision
was
successful,
whether
there
was
a
an
error
talking
to
the
broker,
or
maybe
the
worker
said
we
couldn't
provision
that
instance
right
now.
That's
reflected
in
the
instance.
Resources
status
so,
like
I,
said
provisioning.
B
A
new
instance
can
sometimes
take
a
long
time
if
you've
ever
provisioned
a
new
database
from
a
database
as
a
service
product.
You
probably
are
familiar
with
the
that
it
can
sometimes
take
several
minutes,
and
this
is
where
the
asynchronous
support
and
the
open
service
broker.
Api
becomes
very
useful
because
it
gives
the
catalog
controller
a
way
to
check
back
with
the
broker
and
see
what
is
a
provision?
That's
asynchronous.
B
So
here's
the
float
for
that.
The
catalog
API
server
detects
a
new
instance
resource
and
we
actually,
in
the
catalog
controller,
say
that
we
can
always
support
asynchronous.
It
depends
really
on
whether
the
brokers
service
needs
to
be
provisioned,
synchronously
or
not,
or
rather
whether
it
supports
asynchronous
provisioning
and
if
it
does
support
asynchronous
provisioning.
It's
possible
possible
for
the
broker
to
return
in
HTTP
202,
which
tells
the
catalog
controller
that
the
broker
has
chosen
to
implement
this
provision
asynchronous
asynchronously.
B
The
catalog
control
will
then
update
the
status
to
show
that
an
asynchronous
operation
is
happening
for
that
instance,
and
will
call
the
broker
back
at
the
right
endpoint
to
pull
the
status
of
the
operation
periodically
and
once
that
succeeds
or
fails.
The
catalog
controller
will
update
the
status
on
the
instance
resource
and
send
it
back
to
the
API
server.
B
Excuse
me
so
we've
talked
about
bindings
a
little
bit
just
to
refresh
everybody.
A
binding
is
a
relationship
between
an
application
and
a
service.
The
open
service
broker
API
supports
multiple
types
of
bindings
for
credentials.
Logged
rain
and
routing
the
logged,
rain
and
routing
services
are
very
cloud
foundry
specific
in
the
implementation.
B
So
currently
the
kubernetes
service
catalog
only
supports
credentials
binding
what
credentials
bindings
are,
are
sort
of
what
they
sound
like
you
do,
a
binding
between
an
application
and
an
instance
of
a
service,
and
you
get
a
secret
containing
information
about
how
you
should
use
that
service.
So,
for
example,
the
secret
that
you
get
might
contain
coordinates
that
you
dial
the
service
at
it
might
contain
credentials
like
username
and
password.
It
might
contain
an
API
key
and
it
might
contain
some
configuration
parameters
like
kua
or
the
settings.
B
B
The
catalog
API
server
does
a
similar
grid
generation
to
give
the
binding
a
coordinate
to
use
in
the
open,
serviceworker
API.
The
catalog
controller
then
gets
a
watch
event
saying
that
a
new
binding
resource
has
been
created.
It
calls
bind
on
the
broker
updates
I'm.
Sorry
next
it'll
create
a
secret
with
the
result
of
the
binding
and
then
update
the
status
of
the
binding
resource.
B
So
we
talked
about
how
to
make
these
things.
Let's
talk
about
how
to
delete
them
in
the
intention
based
API
world.
The
way
to
trigger
that
something
should
no
longer
exist
is
to
delete
it
and
the
way
that
we
handle
this
in
kubernetes
is
that
when
a
bind
or
instance
resource
is
deleted,
we
actually
don't
delete
it
right
away.
We
set
a
time
a
deletion
time
stamp
on
it
and
that
creates
a
watch
event
that
the
controller
receives
and
allows
it
to
do
work
to
clean
up
thanks.
B
So
in
the
case
of
a
binding,
when
we
delete
a
binding,
that
binding
is
just
updated
with
a
set
deletion
timestamp,
and
that
gives
the
controller
an
opportunity
to
delete
the
secret
that
it
created
and
call
the
broker
back
and
tell
it
to
remove
the
binding
same
thing
with
instances
when
you
delete,
in
instance,
resource
it,
tells
the
controller
to
I'm
sorry,
it
results
in
that
instance
having
a
deletion
timestamp.
The
controller
sees
it.
B
B
So
as
I
as
I
said
just
to
recap
deleting
a
binding
results
in
that
binding
being
unbound,
the
secret
will
be
created
the
controller
or
insight
the
sequel
seeker
will
be
deleted.
The
controller
will
talk
to
the
broker
and
tell
the
broker
to
delete
the
binding,
and
then
the
resource
disappears
same
thing
with
deep
revision.
Once
you
delete
an
instance,
the
controller
will
invoke
deep
revision
at
the
broker
and
finish
deleting
the
binding
I'm.
Sorry
finished,
deleting
the
instance
resource.
B
C
Paul
so
as
the
sync
service
catalog
continues
to
evolve,
implementations
of
the
open
service
broker
API
in
the
form
of
service
brokers,
have
started
to
emerge
next
slide.
Three,
in
particular
of
note,
with
regards
to
open
shifts,
are
the
template
service
broker
the
ansible
service
broker
and
the
amah
service
broker.
The
template
service
broker
will
wrap
the
existing
open,
shipped
templating
scheme
within
the
lifecycle
of
the
open
service
broker.
Api
do
you'll
be
able
to
leverage
the
same
template
that
you
have
been
continuing
that
you
have
been
using
since
the
early
days
of
open
ships.
C
First
and
three
within
this
broker.
The
ansible
service
broker
incorporates
the
concepts
of
ansible
playbook,
bundles
or
apbs
to
leverage
the
ansible
ecosystem
to
manage
the
lifecycle
of
services.
Now
there
is
a
prior
commons
briefing
that
was
dedicated
to
the
concept
of
ansible
playbook
bundles
and
the
ansible
service
broker.
C
So
I
do
highly
encourage
you
to
locate
the
recording
on
youtube
and
the
the
OpenShift
common
briefing
blog
to
revisit
those
concepts,
and
finally,
is
the
entry
and
mock
service
broker,
which
will
be
a
component
of
the
messaging
as
a
service
platform
that
is
currently
being
developed
by
Red
Hat.
It
provides
the
capabilities
to
allocate
messaging
services
such
as
queues
or
topics
for
use
by
applications
next
slide.
C
So
when
enabled
in
open
ships
3.6,
the
catalog
provides
a
new
user
interface
for
users
to
explore
the
available
applications.
Along
with
the
new
workflow
for
deploying
applications,
you
will
be
able
to
walk
through
each
of
the
operations
of
the
open
service
broker
API
as
the
application
is
deployed.
Now
these
enhancements
are
just
part
of
the
continued
evolution
of
the
open
ship
user
experience.
The
user
interface
has
come
a
long
way
since
openshift
was
first
released,
and
this
is
just
yet
another
step.
It's
really
amazing
to
see
the
evolution
come
about
next
slide.
C
So
for
those
of
you
who
are
looking
to
create
your
own
service
broker
a
service
broker,
software
development
kit
is
available
to
help
jump-start
those
efforts.
It
provides
a
baseline
set
of
boilerplate
code
of
written,
go
and
subs
out
all
the
necessary
open
service
broker,
API
functions
now,
service
brokers
can
be
written
in
any
language,
and
this
type
of
SDK
can
be
ported
necessary
to
the
languages
that
you
are
currently
developing,
such
as
Java
C,
sharp
you
name
it.
It's
very
easy
to
implement
these.
C
By
next
slide,
so
while
we've
covered
a
wealth
of
information
during
this
session,
it
really
only
scratches
the
surface
of
what
the
open
service
broker
API
can
offer.
Here
are
a
set
of
links
that
you
can
browse
at
your
leisure
to
learn
more
about
the
open
service
broker
API
and
the
efforts
on
implementing
them
within
the
kubernetes
community
next
slide
and
we've
saved
the
best
for
last.
We've
talked
a
lot
about
the
theory
of
what's
occurring
in
the
upstream
community.
C
D
C
Server
and
the
controller
manager
and
included
are
two
of
the
brokers
that
we
described
earlier.
The
template
service
broker
and
the
ansible
service
broker,
and
for
those
of
you
who
are
looking
to
run
the
service
catalog
locally
within
their
own
hopeful
development
environment,
a
new
parameter
has
been
added
to
the
OC
cluster
up
tool
to
simplify
the
provisioning
process
using
the
Service
Catalog
parameter
when
starting
and
running
OC
cluster.
Up
now,.
C
I
do
want
to
note
now,
since
the
service
catalog
is
available
as
a
technology
preview
feature
when
it
is
enabled
it
is
embedded
into
a
number
of
core
services
with
an
open
ship,
and
by
doing
so
it
does
change
the
level
of
support
provided
by
Red
Hat.
So,
while
I'll
encourage
you
to
view
and
my
customers
to
start
looking
at
implementing
this
ecosystem
within
both
your
and
their
organizations,
do
keep
in
mind.
This
should
only
be
done
in
a
development
environment
and
not
a
production
environment.
C
As
of
this
upcoming
release,
now
we
want
to
thank
you
for
attending
this
session
today.
We
really
hope
that
it
provided
some
valuable
information
into
the
open
service
broker.
Api
specification
work,
that's
being
done
in
the
upstream
kubernetes
community
and
the
features
that
will
be
available
in
the
next
version
of
OpenShift.
A
Alright,
with
that,
if
there
is
one
question,
that's
come
up
from
Johnathan,
that's
in
the
chat
that
you
should
try
and
get
answered
with
the
ansible
and
language
support.
Do
you
imagine
replacing
some
of
the
functionality
of
cave
kubernetes
templates
he's
asking,
because
he
would
love
to
have
more
logic
in
how
to
instantiate
services
from
a
template
feature.
B
The
progression
that
I
usually
describe
to
people
that
are
curious
about
this
is
that,
if
you
can
use,
if
you
can
accomplish
what
you
want
just
with
an
open
ship
template
use
an
open
ship
template.
If
you
need
something
more,
your
next
step,
your
best
next
step
is
probably
to
go
to
ansible
and
write
an
ansible
playbook
bundle
and
if,
for
some
reason
that
doesn't
work
for
you
and
you're
very
interested
in
writing
your
own
code.
At
that
point,
you
should
check
out
the
sdk
to
write
your
own
Brooker.
Does
that
answer
your
question.
A
E
E
Thank
you
I.
Just
you
know,
we've
been
struggling
with
it
and
and
going
to
ansible.
We
were
thinking,
you
know,
that's
that's
a
pretty
drastic
step
and
I
was
wondering
if,
because
you
guys
have
kind
of
knee-deep
in
that,
if
that's
an
issue
that
you
guys
have
seen
a
lot
and
if
you
thought
about
making
the
ansible
playbooks,
you
know
coming
up
with
you
know:
templatized
ansible
playbooks,
to
try
and
make
it
easier.
E
So
you
said
the
very
next
step
is
to
go
down
to
ansible,
but
that's
a
that's
a
big
step
to
make,
because
you
have
to
you
have
to
write
a
lot
of
ansible
to
create
the
resources
in
kubernetes
and
I'm,
wondering
if
you
guys
had
kind
of
template
resources
available
for
somebody.
You
know
wanting
to
experiment
and
ansible,
but
not
knowing
where
to
start.
B
C
C
One
of
the
benefits
of
the
ansible
flavor
bundles
in
that
ecosystem
is
there
are
a
number
of
modules
that
have
come
out
of
that
ecosystem
that
represent
a
lot
of
the
objects
that
are
kubernetes
objects.
So
you
can
easily
create
services,
deployment,
configurations
routes
using
only
a
few
lines
of
code
and
it's
very
thin
as
all
ID
potent,
so
it
will
be
able
to
manage
the
lifecycle
of
OpenShift
very
very
easily.
So
you
don't.
D
D
A
A
Yeah
and
Anders
just
posted
the
modules
that
are
leveraged
by
a
lot
of
the
existing
ape
ansible
playbooks
examples
that
we're
going
to
have
on
another
ansible
playbooks
and
ansible
service
broker
commons
briefing
in
a
couple
weeks,
so
I'll
post
the
date
for
that
soon
they've
got
some
new
stuff
coming
up
and
wanted
another
chance
to
update
everybody.
So
that'll
be
some
more
on
that
and
there
is
earlier
briefing
to
that
as
well.
On
ansible
playbooks
features
me
I
want
that
all
on
tails,
so
I
don't
see
any
other
questions.
A
So
I
want
to
thank
Paul
and
Andrew
for
their
time
today,
and
this
video
will
be
up
on
open
shifts,
vlog
vlog,
DeLucie
comm,
probably
in
a
day,
depending
on
how
fast
the
internet,
gods,
work
and
uploads,
and
if
there
are
other
topics
that
you
want
to
hear
about,
especially
things
relating
to
the
kubernetes
1.7
release
and
things
that
are
coming
out
with
that.
Please
let
me
know
and
I'll
try
and
course
I
wanted
to
speaking
on
that,
but
other
than
that.