►
From YouTube: Service Catalog in Action - Paul Morie, Red Hat
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
Api
I'm
gonna
talk
a
little
bit
about
how
you
can
make
your
service
available
and
I'm
gonna
show
also
a
joint
project
between
Red,
Hat
and
Rocket
chat
as
an
example
of
like
an
ISV
that
has
worked
with
us
to
expose
their
service
in
this
manner
and
then
I'm
gonna
show
a
new
project
that
I'm
really
excited
about
about
making
new
brokers.
So
here
we
go
Service
Catalog
in
five
minutes.
A
The
TLDR
of
open
serviceworker
API
is
that
it
is
a
mechanism
that
insulates
a
user
that
wants
to
provision
a
new
instance
of
a
particular
service
from
how
that
happens.
If
you've
worked
in
companies
large
and
small
you're,
probably
familiar
with
this
concept,
you
may
have
a
passing
familiarity
with
making
a
ticket
to
get
something
to
happen
like
getting
a
chassis
wracked.
Getting
a
new
database
created
all
that
kind
of
stuff.
A
Raise
your
hand.
If
you
like
making
tickets,
you
know
I,
don't
see
any
hands
and
I
you'll
notice,
that
my
hand
is
not
up
here.
So
I
think
we
all
are
on
a
similar
emotional
wavelength,
about
tickets,
making
them
waiting
for
them
to
happen,
etc,
and
that's
where
the
value
proposition
open,
serviceworker
API
really
hits
the
sweet
spot,
because
a
service
broker
that
manages
the
operations
of
provisioning
a
new
service
creating
bindings
to
them
when
you
want
to
use
them.
A
A
So,
let's
talk
about
the
high
level
details
of
that
open,
serviceworker
API
has
basically
five
operations,
which
is
convenient
because,
like
I
count
on
my
fingers
a
lot
since
my
brain
isn't
very
good,
and
this
matches
the
number
of
fingers
that
I
have
so
we
got
catalog
management,
which
is
what
services
does
my
broker
offer?
The
next
one
is
provisioning,
which
is
how
do
I
make
a
new
instance
of
that
service,
and
the
canonical
example
that
we
used
to
explain
this
stuff
is
say:
a
service
might
be
database
as
a
service.
A
So
you
provision
a
new
database
and
then
you've
got
your
database
that
you
can
use
binding.
Is
you
want
to
consume
that
service?
You
want
to
consume
that
database
in
an
application
and
write
to
it,
read
from
it
and
then
you've
got
the
symmetric
pairs
of
those
two
things
unbinding
in
deep
provisioning
service.
Catalog
is
a
integration
point
between
OpenShift
and
kubernetes,
and
one
or
more
brokers
that
implement
this
open
service
broker,
API
and
I'm
going
to
show
in
a
little
bit
the
mechanics
of
how
that
all
fits
together.
A
But
essentially,
Service
Catalog
sits
between
you
as
a
user
and
brokers
that
are
out
there
connected
to
the
catalog,
so
you
actually
have
to
know
even
less
about
open
service
broker
API
than
someone
who
implements
it
or
implemented
service
catalog.
You
basically
just
get
to
say
what
you
want
and
when
you
want
to
use
it
and
when
you're
done
you
the
resources
that
represent
those
things,
they
go
away
really
quick,
because
I'm
sure
this
is
at
least
somewhat
interesting
to
the
people
in
this
room.
A
The
architecture
of
service
catalog
is
similar
to
the
architecture
of
kubernetes.
In
that
service,
catalog
has
its
own
API
server
and
presents
API
resources
that
have
the
same
kind
of
spec
and
status
pattern
as
other
resources
and
kubernetes
that
you
might
be
familiar
with
that
API
server
is
backed
by
a
controller
that
is
going
and
doing
the
work
of
actually
talking
to
broker's
that
implement
this
API
and
it's
an
eventually
consistent
API,
just
like
other
API
in
kubernetes.
A
So
in
three
seven,
as
we've
already
mentioned
in
passing,
the
Service
Catalog
is
supported
in
OCP
37
there's
support
for
it
in
the
installer.
You
can
create
a
new
cluster
with
service
catalog
enabled
you
can
upgrade
a
three
six
cluster
to
three
seven
and
install
the
catalog
in
doing
that,
and
we've
recently
fixed
some
some
bugs
around
that
experience
that
should
all
be
working
great
in
our
next
Arado
release.
So
you
get
the
catalog
infrastructure.
A
You
get
two
brokers,
there's
a
template
service
broker,
which
is
an
implementation
of
the
open,
Service
Worker
API
that
uses
openshift
templates
underneath
to
provision
and
bind
to
services,
and
you
get
the
ansible
service
broker,
which
I
think
probably
there's
some
degree
of
familiarity
with
this
ansible
thing
in
this
room.
People
have
probably
heard
of
that
and
then
also
you
can
easily
create.
A
So
on
that
now,
let's
talk
about
making
your
service
available.
Those
two
brokers
that
we
talked
about
are
easy
on
ramps.
If
you
can
write
an
open
ship
template,
you
can
integrate
with
the
template
service
broker.
If
you
have,
if
you
can
write
ansible
playbook,
so
you
can
integrate
with
the
now
called
the
automation
service
broker,
which,
just
for
the
record
I
believe,
has
the
coolest.
Oh
I'm
I'm,
showing
my
jokes
all
that
stuff
hold
on
a
sec.
I
think
I
closed
my
window.
Well,
that's
all
right!
A
These
two
brokers
are
easy
on
ramps,
like
I
was
saying:
if
you
can
write
ansible
play
books,
you
can
expose
a
service
via
the
ansible
broker
and
I'm,
going
to
show
an
example
of
that.
Let
me
see
if
I
can
hit
this
button.
The
right
way.
This
I
think
for
the
record
is
the
coolest
logo
in
the
container
space,
the
tentacle.
A
So
I've
got
a
an
OSC
p37
cluster
running
in
ec2,
it's
in
the
US
east
one
region.
So
it's
going
to
be
maybe
a
little
slower
than
if
it
was
running
closer
to
us,
but
it'll
work,
it'll
get
the
job
done
and
I'm
gonna
show
Rocket
chat,
being
provisioned
via
ansible
playbook
bundle.
So
basically
an
ansible
playbook
bundle
is
a
container
image
that
has
the
ansible
runtime
and
it's
got
ansible
playbooks
for
these
provision.
A
Bine
unbind
and
deep
provision
operations
that
when
the
Service
Catalog
calls
those
operations
and
open
service
broker
API
the
ansible
broker
just
runs.
Those
runs
a
pod
that
runs
that
ansible
playbook,
and
this
is
a
really
cool
example
to
me,
because
we
at
Red
Hat,
initially
developed
a
version
of
this
and
then
VR
is
VE
channel
actually
worked
with
rocket
chat
and
they
have
full
rights
to
the
ansible
playbook
repo
and
actually
maintained
this,
which
is
really
cool.
A
A
Just
a
note
to
myself:
alright,
let's
go
ahead
and
create
this
thing
so
when
I
had
create
what
happened
is
there's
a
kubernetes
service,
catalog
resource
called
service
instance
that
was
created
in
my
project
and
when
I
create
that
resource.
It
represents
my
intent
to
provision
a
new
instance
of
this
rocket
chat
service.
So
I
created
it.
The
Service
Catalog
controller
is
watching
Service,
Catalog,
API
server
and
says
AHA.
There's
a
new
service
instance
that
I
need
to
make
real.
A
So
it's
gonna
go
out
and
talk
to
the
instable
broker
and
say
I
want
this
service
I
want
this
plan,
ansible
Brooker
says.
Thank
you
very
much
for
letting
me
know,
I'm
gonna
go
and
do
it
and
it
will
in
in
this
particular
flow.
Since
there's
work
to
do
here
that
you
can't
really
squeeze
into
a
single
API
call
it'll
say:
I've
accepted
your
request.
A
A
A
Excellent
question,
so
the
question
was
when
I
think
there's
actually
a
couple
different
questions.
There's
one
question
of:
does
the
service
catalog
run
under
a
particular
service
gate
account
and
then
there's
a
closely
related
question
of?
Does
a
particular
Broker
run
under
a
service
account?
The
answer
to
both
those
is
yes
and
to
just
take
it.
Apart
a
little
bit,
the
service
catalog
runs
in
its
own
namespace
under
a
service
account
that
is
limited
in
what
it
can
actually
do.
A
The
ansible
service
worker
actually
runs
in
its
own
namespace
under
its
own
service
account.
That
is
permission
to
do
only
the
things
that
it
needs
to
do
well
back
this
down.
We
had
too
much
good
luck
there
so
need
to
fit
it
all.
On
one
screen
you
can
see
here,
I
just
got
all
the
pods
in
all
the
namespaces
and
there's
ansible
service
broker
itself
ansible
service
workers
at
CDR
running
under
their
own
namespace.
A
We've
got
my
namespace
here
with
a
rocket
chat
pod,
which
seems
like
this
was
a
perfect
question.
Timing
wise
because
looks
like
the
thing
is
done,
and
there
are
a
couple
other
layers
of
security
here.
So
when
the
Service
Catalog
is
talking
to
the
ansible
broker,
it
is
sending
information
about
the
the
namespace
that
is
requested.
A
The
the
namespace
that's
requested
that
the
instance
be
provisioned,
and
it's
also
sending
information
about
itself
so
that
the
broker
can
authenticate
that
the
Service
Catalog
is
actually
using
a
service
account.
That's
able
to
talk
to
it
so
there's
a
special
are
back
rule
that
when
the
broker
gets
requests,
it
does
a
kubernetes
subject:
access
review
check
against
a
special
verb.
A
Basically
that
says
you
can
call
me
so
that
you
can
make
sure
one
that,
just
because
you
know
where
the
ansible
broker
might
be
listening
for
requests
that
you
can
only
get
it
to
do
things
for
you.
If
you
have
permission
to
talk
to
it
and
then
add
another
layer,
the
ansible
service
broker
itself
is
protect
from
the
rest
of
the
system
with
our
back.
So
it
can
only
do
the
things
that
it's
supposed
to
be
able
to.
B
A
So
that's
a
really
good
question.
The
question
just
for
the
record
was:
can
you
apply
a
security
context
constraint
to
the
service
account
that
the
ansible
service
broker
runs
as
so,
for
example,
if
you
want
to
make
sure
that
the
the
ansible
service
broker
is
pods
only
run
within
a
certain
UID
range
totally
possible
to
do
you
do
that,
just
like
you
would
configure
an
SCC
for
any
other
service
account.
A
A
A
A
This
project
used
to
be
called
the
go
open,
serviceworker
skeleton
and
keep
that
in
mind
when
I
finally
get
to
my
joke
slide,
because
I'm
not
gonna
build
a
broker.
Yet
I
was
thinking
while
I
was
thinking
about
how
to
do
this.
The
right
way
like
I,
said
I
called
it.
The
skeleton
and
I
was
thinking.
You
know,
there's
people
skeletons
and
we
draw
all
these
pictures
on
whiteboards,
where
these
boxes
are.
What
are
the
box
skeletons.
Look
like
I
think,
there's
four
bones
in
the
box
skeleton
so
I'm
drawn
on
the
whiteboard
here.
A
I
got
my
frob
you
later
box,
sir
my
widget
or
whatever.
There
are
four
bones
that
keep
the
skin
of
this
box
in
the
square,
shape
that
we
know
and
love
I,
don't
know
what
their
names
are,
but
if
I
apply
my
x-ray
vision,
that's
what
I
see
it
was
a
better
joke
when
the
thing
was
called
the
skeleton
I
kept
it
in,
because
my
wife
likes
it
and
I
know
who
I
work
for
so
let's
actually
build
a
broker.
Now,
so
I
am
going
to
clone
this
thing.
B
A
B
A
I'm
gonna
show
you
the
stock
one
first
and
then
we're
gonna
code,
one
so
to
deploy
this
to
OpenShift.
I
just
had
to
type
make
push
the
play.
Openshift
it's
going
to
build
a
binary
for
the
broker.
It's
going
to
deploy
and
build
a
container
image
for
it
to
play
that
into
my
open
shift,
that's
running
in
ec2
and
it
deploys
a
very,
very
simple
example
service
and
that
thing
is
gonna
pop
up
in
the
service
catalog
overview
in
the
web
console
in
a
second
here.
A
A
So
here's
an
example
of
what
the
service
broker
resource
that
indicates,
your
intent
that
the
catalog
should
consume
a
broker,
never
mind
the
the
error.
That's
completely
expected
we're
gonna
see
a
new
one
pop
up
and
it's
gonna
look
ready
in
just
one
second,
but
the
spec
for
this
thing
is
basically
just
a
URL
for
where
do
I
talk
to
it?
A
A
A
So
when
you
go
to
implement
your
broker
with
this
project,
you
basically
have
to
do
four
things.
You
can
wire
in
your
own
CLI
options
and
implement
a
so.
You
implement
the
type
that
has
the
options
you
implement
a
method
that
takes
those
options
and
makes
a
new
instance
of
a
business
logic
that
has
the
the
brokers,
business
logic
and
you
implement
the
business
logic
for
your
broker.
So
there's
a
very,
very,
very
simple
example
here
and
since
I.
A
A
So
services
have
metadata
among
them.
Is
the
display
name,
image?
Url,
there's
a
couple
other
things
here:
they're
kind
of
conventional
in
across
kubernetes
and
Cloud
Foundry,
we're
actually
open
serviceworker.
Api
originated
services
have
plans
which
are
tiers
of
services,
so
in
our
database
as
a
service
example,
a
plan
might
be
like
a
bronze
plan
where
maybe
you
get
a
tablespace
and
a
like
multi-tenant
database,
and
you
know,
maybe,
when
you
get
slash,
dotted
you
upgrade
to
the
the
gold
tier.
That's
like
a
dedicated
database,
no
other
tenants,
SAP
in
your
I
ops,
etc.
A
A
A
A
A
Versioning
and
we'll
see
this
pop
up
in
a
minute
here,
so
open
serviceworker
api
currently
doesn't
have
a
first-class
notion
of
a
version
of
a
service.
The
pattern
that
seems
to
be
pervasive
in
the
community
is
to
project
versions
onto
plans,
so
you
might
have
a
plan,
that's
like
Postgres,
9,
2
and
another
plan.
That's
9
6
and
since
this
is
a
high-level
overview,
I
didn't
go
into
the
ins
and
outs
of
updating,
but
services
can
be
plan
updatable.
A
A
A
A
Ideally,
this
will
be
like
a
batteries
included
experience
where
you
get
good
practices
for
security.
For
example,
we
mentioned
the
are
back
rule
that
the
ansible
service
worker
and
template
service
broker
check.
I
would
like
to
have
that
built
in
also
an
easy,
on-ramp
and
built-in
baseline
useful
metrics
for
Prometheus.
A
She's
awesome
check
her
out
on
Twitter
and
I
have
some
resources
in
here
for
when
we
share
this
deck
that
call-outs
to
open
serviceworker
api
service
catalog
the
cig
in
kubernetes
commons
briefing,
where
I
go
into
exhaustive
detail
about
all
of
these
resources.
That
would
kind
of
hinted
about
today
linked
to
the
automation
broker
and
the
USB
starter
pack.
So
thanks
a
lot.