►
From YouTube: OpenShift Commons Briefing #31: Services, linking & Catalogs in Kubernetes and Openshift
Description
Making it easier to link services in OpenShift, within a project/namespace or across projects, as well as linking OpenShift services to other services in your data center or the public cloud is an important ongoing objective. The Kubernetes services model is at the core of this effort. The upstream work in the Kubernetes and Origin community will then feed into OpenShift.
The goal is to make it easier to find and consume services in a consistent manner, as well as to make it easier to link services to deployments. This then serves as the basis for publishing catalogs of predefined services and enabling service consumption metering and billing. This session will give a progress report on our efforts and outline the tasks ahead.
Anyone interested in helping us build out this functionality in OpenShift 3 and looking for a place to contribute is encouraged to attend. Related Trello Card: https://trello.com/c/oLWi6AHf/167-service-catalog-catalog
For the latest information on OpenShift 3.1 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally. The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
A
Hello
all
and
welcome
to
this
we're
actually
doing
this
live
from
pucon
here
in
london
and
andy
is
back
east
in
the
united
states
and
he's
andy
goal.
Sign
is
our
principal
software
engineer
and
he's
been
working
on
openshift
for
a
number
of
years,
so
I'm
going
to
let
him
introduce
the
subject
of
services,
Lincoln's
and
catalogues.
We've
got
a
number
of
folks
here
sitting
with
me
from
pro
tab
on
so
I
will
let
them
talk
through
my
microphone
and
the
Q&A
session
starts.
A
B
Right
Thank,
You
Diane,
so
my
name
is
Andy.
Goldstein
I
am
a
principal
software
engineer
with
red
hat
I'm.
The
team
lead
for
our
cluster
infrastructure
team,
which
focuses
on
Cooper
Nettie's,
so
within
openshift
are
a
big
part
of
the
foundation,
is
Cooper
Nettie's,
so
today's
talk
will
be
covering
services
linking
and
catalogs
as
they
relate
to
both
Cooper
Nettie's
and
open
shift.
So
here's
what
I'm
going
to
talk
about
today,
services
linking
and
catalogs.
B
So
for
starters,
if
you're
deploying
something
into
Cooper,
nutters
or
open
shift,
whether
it's
a
series
of
micro
services
or
a
large
java
application,
for
example,
those
things
are
going
to
be
deployed
using
pods
and
a
pod
is
just
a
collection
of
containers
and
pods
come
and
go,
though,
you
probably
need
some
way
to
consistently
reference
database
or
a
web
service
or
a
memory
cache
that
your
micro
services
or
your
applique
need
to
talk
to.
So
that
brings
us
to
services.
What
is
a
service?
B
It
is
an
abstraction
that
allows
us
to
not
have
to
worry
about
pods
that
are
transient,
and
it
instead
gives
us
a
consistent
way
to
to
reference
your
database
or
your
cash
or
whatever
you're,
trying
to
talk
to
so
a
service
inside
of
Coober
Nettie's.
An
open
shift
is
something
that
sits
in
front
of
pods
via
a
label.
B
Additionally,
we
have
dns
integration.
If
you
have
that
enabled
in
cooper
teddies,
and
it's
also
out
of
the
box
with
open
shift.
So
rather
than
having
to
remember
an
IP
address,
you
can
use
dns
to
communicate
with
your
services
and
the
service
acts
as
a
load
balancer
in
front
of
the
pods
that
it
is
it's
sitting
in
front
of
and
requests
that
go
to
that
service
are
delivered
most
of
the
time
round,
robin
among
the
pods
that
sit
behind
it.
B
B
Your
IT
department
has
an
existing
oracle
database
or
an
existing
web
service
that
has
been
around
since
before
you
deployed
openshift,
and
you
want
to
be
able
to
reference
that
service
in
the
same
manner
that
you
would
use
if
you
were
referencing
a
series
of
pods
that
are
fronted
by
a
service,
and
so
in
this
case,
as
a
user
or
an
administrator,
you
would
manually
manage
the
endpoints
that
that
service
is
sitting
in
front
of
instead
of
having
a
label
selector.
That
takes
care
of
that,
for
you
automatically
so
here's
an
example.
B
B
Value
of
postgres
and
the
second
one
is
for
the
environment
and
we're
looking
for
a
production
pod
and
in
addition
to
specifying
a
selector,
you
specify
at
least
one
port,
and
this
makes
sure
that
the
service
is
listening
on
port
five,
four
three
two
and
it
is
targeting
port
five,
four
three,
two
inside
of
the
containers
or
inside
of
the
pods
that
it's
sitting
in
front
of
so
here's
a
graphical
representation
of
what
that
might
look
like
you'd.
Have
your
DB
service
that
gets
a
cluster
IP
address.
B
I
picked
one
at
random
here:
1000,
dot,
15
and
you'll
see
three
pods,
two
of
them
pods
one
and
two
have
matching
DB
names
and
environment
labels
for
postgres
and
prod,
and
you
can
see
each
pod
has
a
unique
IP
address.
The
third
pod
has
a
different
value
for
the
environment
label.
Stowe.
In
this
particular
example,
the
DB
service
is
going
to
communicate
with
pods
one
and
two,
but
not
pod.
Three
and
to
the
right
of
the
DB
service.
I
have
listed
what
the
DNS
entry
would
look
like
by
default
for
this
particular
service.
B
It's
the
name
of
the
service
d,
be
followed
by
the
name
of
the
name
spacer
project
which,
in
my
example,
is
Andy
and
then
dot
SVC
cluster
dot
local.
So
how
can
you
talk
to
the
service?
There's
two
ways
you
can
do
it
I
just
mentioned
dns
and
there's
one
other
mechanism
which
is
environment,
variables
and
cooper.
Nettie's.
B
An
open
shift
will
automatically
create
environment
variables
for
you
that
allow
you
to
to
look
up
the
host
and
the
port
of
your
service
and
these
environment
variables
are
automatically
created
and
automatically
injected
into
your
pods
when
they
are
created
and
started.
Now
there
is
an
ordering
issue.
You
do
have
to
make
sure
that
your
service
exists
before
the
pot
is
created.
B
Otherwise
the
you
won't
have
these
environment
variables
accessible
in
the
pod
and
that's
why
DNS
has
an
advantage,
because
DNS
is
going
to
work
any
time,
regardless
of
if
you
create
the
service
first
or
if
you
create
the
pot
first.
So
how
do
we
find
services
I?
You
can
definitely
run
OC
get
services
or
cube
control
get
services,
and
this
will
list
all
the
services
in
a
single
project.
Not
super
easy
to
make
this
work
across
projects.
B
You
can
have
it
lists
services
in
every
project,
but
that's
going
to
give
you
everything
and
it's
going
to
be
hard
to
to
filter
out
the
weeds.
It's
not
a
curated
list,
it's
just
literally.
Every
single
service
that
you
have
access
to
will
show
up
when
you
run
that
command
across
projects
and
similarly,
where
it's
not
a
curated
list,
if
I
did
want
to
to
expose
one
of
my
services
so
that
other
users
could
find
it
effectively
if
I
wanted
to
publish
it,
there's
no
command
for
doing
that.
B
Right
now,
which
is
why
I
have
some
question
marks
after
OC
there
you
could
grant
users
read-only
access
to
a
project,
but
even
then
the
default
policy
for
the
viewer
role-
I,
don't
believe,
gives
you
access
to
two
things
like
secrets,
if
you
needed
them
to
to
to
communicate
with
a
service
for
credentials
and
and
doing
this,
granting
it's
pretty
broad.
If
I
give
somebody
read-only
access
to
my
project,
they
get
to
see
pretty
much
everything
in
there
and
I
would
probably
much
prefer
it
to
be
more
restrictive.
Where
I
could
explicitly
say.
B
So
one
thing
that
we're
proposing
is
being
able
to
link
configuration,
details
and
secrets
to
a
service
and
the
proposed
command
that
we
have
is
OC
link
and
so
I
have
two
examples
here.
Where
I'm
saying
I
would
like
to
link
adb
cred
secret
to
my
DD
service,
and
I
would
like
to
link
a
DB
config
map
to
my
DB
service
and
what
this
will
do
is
add
a
new
annotation
that
contains
a
list
of
the
referenced
items,
and
this
is
just
a
proposal
for
right
now.
B
B
B
So,
let's
take
an
example:
deployment
config,
this
one's,
pretty
basic
I've,
stripped
out
some
items
that
aren't
relevant
to
this
example.
But
I
have
a
deployment
config
called
front
end.
It
has
two
replicas
I,
have
a
selector
to
find
and
I
have
a
single
container,
that's
running
the
andy
/
front-end
image,
whatever
that
happens
to
be,
and
it
exposes
one
port
on
8080.
So
what
would
it
look
like
to
do
linking
here?
B
B
Another
one
is
finalizing
the
environment
variable
and
volume
conventions,
and
just
what
the
user
experience
looks
like
around
that
a
couple
more
outstanding
questions
are:
should
we
do
the
server
side?
We
do
a
client
side.
If
we
do
it
client-side,
it
is
fairly
easy
to
get
the
moving
parts
going,
but
it
means
that
every
client
would
have
to
implement
the
same
or
similar
logic.
B
B
So
what
are
we
proposing
for
publishing
a
service
to
a
catalog
OC
create
catalog
entry,
give
it
a
name
in
this
case
and
EDB
I'm,
saying
that
I
want
the
entry
to
reference.
The
SVC
/
DB
service
from
my
name,
space
I
want
to
put
it
in
the
default
catalog
and
I'm,
going
to
give
it
a
description
of
Andy's
TV
service,
and
this
will
create
a
catalog
entry
for
that
service
and
here's
a
sample
of
what
that
might
look
like.
B
So
you
can
see
that
the
the
name
is
filled
in
as
and
ETB
the
catalog
is
default.
It's
got
my
description
and
then
I
have
a
reference
field
in
here
that
references.
What
namespace
the
service
lives
in
what
kind
of
resource
it
is
in
this
case
of
service
and
the
name
of
that
particular
resource
which
is
DB.
And
similarly,
if
I
wanted
to
take
a
look
at
what
service
catalogs
existed,
I
could
run
OC
get
service
catalogs
and
in
this
example,
you
can
see
default
finance
and
IT.
B
So
how
do
you
use
a
catalog
entry?
Well,
because
the
services,
or
whatever
is
in
the
catalog,
can
come
from
multiple
namespaces
and
you
may
not
have
access
to
two
get
those
resources
from
a
given
name
space.
We're
doing
something
similar
to
persistent
volume
claims
where
we're
having
a
service
claim
and
the
service
claim
is
a
resource
that
you
would
create.
That
indicates
your
desire
to
use
an
entry
from
the
catalog,
but
it
doesn't
exactly
give
you
the
immediate
ability
to
just
reach
into
someone
else's
project
and
and
get
access
to
their
data.
B
So
here's
my
example:
OC
creates
service,
claim
my
DB
being
the
name
and
then
I
specify
that
I
want
it
to
come
from
the
default
catalog
and
I'd
like
to
use
the
anti-tb
entry.
So
what
happens?
When
you
create
a
claim?
We
will
have
some
code
running
in
a
controller
that
processes
the
claim,
and
the
first
thing
that
would
happen
is
that
claim
would
be
evaluated
to
determine
if
it
should
be
admitted
or
rejected,
and
that
could
go
a
few
different
ways.
B
It
could
be
an
automated
decision
where
you've
got
a
policy
of
some
sort
that
determines
who's
allowed
to
who's
allowed,
to
create
claims
feels
allowed
to
consume
catalog
entry
items
from
particular
catalogs
or
it
could
be
custom.
It
could
go
through
some
sort
of
workflow
process
where
you
need
to
have
some
manual
intervention
where
a
manager
needs
to
approve
a
claim,
for
example,
and
finally,
once
a
claim
is
admitted,
it
will
be
fulfilled
in
whatever
manner
is
necessary,
based
on
the
type
of
the
entry,
that's
in
the
catalog.
B
So
here's
an
example,
let's
say
I've
got
my
catalog
entry
that
we
were
looking
at
before
for
Andy
DB
and
on
the
left.
I've
got
an
Andy
project
that
has
the
three
resources
that
we've
been
discussing
today
so
far.
The
DB
service,
the
DB
cred
secret
and
the
DB
config
map
and
John
here
wants
to
create
a
service
claim
to
use
this
particular
entry
from
the
catalog
and
so
John
creates
that
service
claim,
and
once
it
is
admitted,
the
controller
would
go
and
create
something
that
looks
just
like.
B
What's
in
Andy's
project
you'll
have
a
my
DD
service,
a
DB
cred
secret
and
a
you
config
map,
and
these
items
represent
basically
copies
of
the
data
that
is
in
Andy's
project
at
a
point
in
time,
and
the
the
service
itself
would
most
likely
be
configured
to
point,
do
Andy
service.
So
if
you,
if
you
attempted
to
connect
to
the
my
DB
service,
it
would
just
redirect
or
potentially
be
a
cname
over
to
the
Andy
service
or
to
be
a
DB
service
in
the
ante
project.
B
So
I
mentioned
that
there's
different
types
of
catalog
entries
for
entry
references.
One
of
them
could
be
serviced
and
that's
the
example
that
we
just
looked
at
where
you
would,
or
the
controller
would
copy
the
service
and
any
associated
configuration
and
secrets,
it'll
copy
that
information
into
new
resources
in
the
destination
project.
So
that's
where
John's
project
got
new
resources
with
the
data
copied
from
Amy's
project,
another
type
of
reference
could
be
a
template,
so
this
would
be
a
way
to
publish
a
template.
B
B
So
there
are
still
a
lot
of
to
do's,
and
this
is
where
we
are
really
looking
for
community
help
and
community
input
I'm
going
to
be
starting
some
design
and
prototype
and
would
definitely
appreciate
any
help
if
anyone's
interested
in
providing
some
assistance.
We
are
looking
for
feedback
on
the
user
experience,
though,
all
of
the
examples
that
I
presented
in
this
presentation
so
far
are
not
set
in
stone.
B
So
we
want
to
make
sure
that
we
get
the
best
user
experience
both
from
commandline
perspective
and
from
the
the
web
console
perspective,
which
I
didn't
even
haven't
even
discussed
yet
so
any
feedback
on
user
experience
would
be
extremely
helpful
feedback
on
the
service
broker
API.
We
need
help
defining
that,
so
that
we
can
make
sure
that
that
has
a
good
user
experience.
Other
things
we
need
to
figure
out
our
TLS
support.
B
So,
for
example,
if
you've
got
a
an
external
service
for
even
an
internal
one
and
I
and
I
create
a
claim
and
I
get
a
new
service
for
my
project.
If
I
try
to
make
a
TLS
connection
to
that
service,
it's
probably
going
to
have
the
wrong
hostname.
So
there'll
be
a
mismatch,
because
I'm
trying
to
talk
to
my
service
in
my
project
when
it's
really
the
certificate
is
valid
for
a
different
project.
So
we
need
to
figure
that
out.
Security
is
a
big
one.
B
Figuring
out
who's
allowed
to
publish
to
a
catalog
who's
allowed
to
consume
various
items
or
entries
is
something
that
we
definitely
need
help
with
multi-tenant
networking.
If
that
is
enabled,
then
just
creating
a
cname,
for
example,
from
my
new
service
to
the
original
service,
is
not
going
to
work
because
most
likely,
the
the
network
won't
allow
those
connections
to
go
through.
So
we
need
to
figure
out
how
to
poke
those
holes
appropriately
and
then
finally,
just
keeping
data
in
sync.
B
If
I
have
a
config
map
or
a
secret
and
I
go
ahead
and
do
a
claim
against
that,
and
then
the
original
data
changes
say
the
password
changes
I'm
not
going
to
be
made
aware
of
that,
unless
we
figure
out
some
way
to
handle
that.
So
these
are
a
series
of
to
do's,
I'm,
sure,
there's
probably
a
lot
more,
and
we
definitely
will
appreciate
any
community
help
we
can
get
so
in
closing.
I
want
to
thank
everybody
for
listening,
and
the
first
link
I
have
on
the
page.
B
Here
is
the
Trello
card
that
we
have
for
the
proposal
that
exists
upstream
and
the
Cooper
Nettie's
repository.
The
second
link
is
to
our
open,
shipped
origin
code
base,
and
the
third
plank
is
to
Cooper,
Nettie's
and
I,
want
to
thank
everybody
again
for
listening
and
I
will
turn
it
over
to
questions
at
this
point.
All.
A
Right,
thank
you.
Andy
there's
one
question
right
off
the
bat
from
rich
carpenter
around
the
security
stuff
and
he
says
in
the
example
of
the
DB
service
claim,
with
the
project
client.
Making
the
claim
need
to
get
their
own
credentials
seems
it
might
be
a
security
risk
to
have
any
other
projects,
making
the
claim
have
access
to
the
same
credentials
as
the
creator
of
the
service
right.
B
So
we
definitely
appreciate
that,
and
what
we
are
thinking
is
that
that
will
probably
be
multiple
phases
and,
for
starters,
we
most
likely
would
just
have
the
credentials
be
shared,
but
we
are
definitely
interested,
whether
it's
with
template,
provisioning
or
the
service
broker
model
or
another
one
that
we've
yet
to
come
up
with.
We
do
want
to
to
provide
the
ability
to
generate
/,
whether
it's
it's
per
pod
or
per
project,
or
what
the
appropriate
scope
is.
A
C
B
What
was
the
question?
When
will
we
have
service
broker
support?
Yes,
I.
Don't
have
an
ETA
on
that.
At
this
point
we
need
to
define
the
API
and
then
I.
There
are
still
several
moving
pieces
to
figure
out.
For
starters,
there
is
no
code
for
any
of
this
right
now.
It's
all
theoretical,
though
I
am
planning
to
start
prototyping
very
soon
and,
like
I
said,
we
will
definitely
appreciate
any
input
and
collaboration
on
any
part
of
this,
including
the
service
broker.
True.
C
D
Alandi,
this
is
who
I
am
commanded
from
promise
line
and
I
want
to
know
it's
a
question
about
security.
How
can
you
manage
your
own
service
in
a
public
service
catalog,
for
example,
if
I
want
to
change
something
in
something
in
a
sacred
or
in
a
complete
data,
a?
How
can
I
change
that
and
reference
in
every
everyone
who
is
claiming
that
service
right.
B
D
On
another
question
were
in
your
proposal:
I
miss
a
sony
information
about
the
security
policies
I
of
one
service
in
a
Service
Catalog.
For
example,
a
if
I
have
to
look
upload
my
service
to
a
service.
For
example,
the
default
said
miss
cuttle.
Everyone
can
change.
I
can
update
that
service.
Oh
no
I,
suppose
that
not
so
maybe
we
we
need
some
security
config
to.
We
need
to
act
at
some
security
config
to
that
service.
D
B
I
definitely
agree
I,
if
you're
looking
at
the
screen
now
I
have
the
proposal
that
I've
submitted
to
Cooper,
Nettie's
and
highlighted
is
security
and
figuring
out.
What
to
do.
There
I
agree
one
hundred
percent,
with
what
you
said
and
I
think,
what's
probably
going
to
happen,
is
there
will
be
an
initial
round
of
prototyping
just
to
make
sure
that
what's
in
the
proposal
is
feasible
and
that
probably
won't
include
security
to
start
off
with,
but
we
obviously
wouldn't
want
to
really
ship
anything
without
security
built-in.
A
B
B
A
C
A
B
Could
I
got
understand
the
question
so
I
don't
have
an
answer
right
now.
I
I
think
the
goal
here
is
just
to
avoid
having
lots
and
lots
of
copies
of
services
in
individual
namespaces
that
all
point
back
to
an
original
service
so
that
if
the
credentials
change
or
the
config
changes,
you
don't
have
to
to
refresh
that
sort
of
thing.
I
think
that's
I,
like
that.
We
just
need
to
figure
out.
A
A
B
So
we
are
hoping
to
get
something
in
433
and
we
are
trying
to
figure
out
in
addition
to
doing
the
prototyping
we're
trying
to
figure
out
where
this
code
is
ultimately
going
to
live.
We
would
like
to
have
it
be
something
that
users
could
run
on
Kuber
Nettie's
as
well
as
openshift,
but
it
it's
probably
not.
The
Service
Catalog
portion
of
it
is
probably
not
something
that
would
be
considered
a
core
Cooper
Nettie's
feature
edition
and
whereas
linking
I
think
is
probably
has
a
better
chance
of
getting
into
the
core
project.
B
A
Awesome
well,
thank
you
very
much
for
taking
the
time
to
do
this
presentation
today.
I
think
it's
opened
a
lot
of
eyes,
there's
also
an
awful
lot
of
interest
in
getting
this
work
done
sooner
than
later,
so
I'm
sure
you'll
get
some
comments
back
on
that
Trello
card
and
a
few
volunteers
to
help
you
in
your
prototyping
efforts
and
once
we've
got
a
prototype
up,
I'd
love
to
have
you
back
to
show
it
off
on
the
as
another
commons
briefing
in
the
not-too-distant
future.
A
Let's
see,
there
may
have
been
one
more
question
that
pops
in
well.
I
think
that's
what
we've
got
so
thanks
very
much
for
coming
today
and
please
reach
out.
If
you
have
more
questions
and
join
us
on
on
our
weekly
community
meetups,
there
are
thursdays
10
to
11
on
IRC
channel
4
openshift
dash
dev,
so
that's
that'll,
be
tomorrow,
depending
on
where
you
are
in
the
world.
Alright,
thanks
again
and
we'll
talk
to
you
all
next
week,
you.