►
From YouTube: SIG Service Catalog 20170508
Description
The SIG discusses moving the catalog API to beta and a few design issues recently created, primarily around compliance with the Open Service Broker API spec.
A
Okay,
welcome
everybody
to
the
May
8
2007
meeting
of
kubernetes
SIG's
Service
Catalog
I
am
sharing
my
screen
with
the
agenda.
So
first
thing
is
that
we
would
like
to
be
able
to
take
the
API
for
a
Service
Catalog
to
a
beta
level,
which
in
kubernetes
is
important,
because
it
means
that
we
are
implying
that
we
will
we're
basically
stating
that
we're
going
to
be
backward
compatible
with
future
API
changes.
So
if
everybody
could,
please
take
a
look
at
issue
638,
which
is
linked
in
the
agenda
document.
A
There
are
a
couple
things
that
we're
sorting
through
and
it
is
on
my
plate
to
get
some
time
from
one
of
the
kubernetes
owners
to
do
an
API
review
process
week
so
that
we
can
pick
some
issues.
I
think
that
we
know
basically
the
set
of
issues
that
we
have
about
the
structure.
The
types
I
think
there
are
maybe
some
things
that
Doug
has
added
to
the
agenda
today.
That
might
be
more
subtle
than
necessarily
like
the
structure
of
the
API
that
we
should
talk
through,
but
don't
necessarily
have
to
solve.
A
100%
before
we
go
to
beta
because
certain
things
aren't
ready
for
yet
so
please
look
at
issued
638,
and
we
will
have
a
discussion
on
that
next
Monday,
which
will
be
May
15th
and
have
intend
to
try
to
take
things
to
beta
in
the
Odawa
know,
release
which
is
scheduled
for
May
17.
So
we
have
a
lot
of
design
issues
that
folks
would
like
to
talk
through.
A
One
thing
that
I
think
I
think
I've
talked
about
with
a
couple
different
people
I
know
I've
talked
about
it
with
delay
is
that
it
would
be
really
good
if
we
could
allocate
some
time
to
basically
go
over
the
open,
serviceworker
API
spec
with
a
fine-tooth
comb
and
create
issues
for
any
gaps
that
we
thought
we
needed
to
close
or
or
maybe,
if
we
feel
like
something
is
a
gap
close,
but
it
needs
to
test
around
it.
I
have
been
thinking
that
tomorrow
might
be
a
really
good
day
to
do
that.
I
think
viele!
A
B
C
B
A
A
We
can
also
do
is
we
can
also
kind
of
circle
back
later
this
week,
like
if
it's
more
convenient
to
have
it
on
Friday
I'd,
be
fine
having
it
on
Friday
and
honestly.
That
gives
us
more
a
chance
to
close
any
any
gaps.
I'm
hoping
I
can
close
a
couple
of
them.
That
I
think
we
know
about,
but
you
know
on
the
chance
that
there's
anything
left
to
do
probably
earlier
is
better
to
have
a
conversation
just.
D
E
D
A
Okay,
well,
it
sounds
like
we
should
perhaps
figure
out
the
vagaries
of
that
offline
and
see
if
we
can
start
talking
through
some
of
these
things.
Unless
anybody
objects,
let's
do
it.
Okay,
so
first
one
I'm
going
to
open
this
one
up.
Is
that
ideas
open
an
issue
asking
how
do
people
update
pod,
preset
label
selectors
and
a
spoiler
alert?
Currently
you
don't
because,
as
I
trade
off
in
order
to
get
the
like
beginnings
of
the
API
surface
out
there,
they
pod
presets
are
currently
immutable
in
the
API.
A
Because
of
that
all
right
now,
in
kubernetes
deployments,
we
don't
have
any
precedent
for
a
mechanism
like
this,
but
in
open
ship
deployments,
which
are
the
thing
that
was
eventually
upstream
to
make
kubernetes
deployments.
We
have
the
notion
of
a
trigger
I,
where
a
trigger
is
something
that
will
cause
a
new
deployment
to
be
created.
A
So
as
an
example,
we
have
a
trigger
that
that
so
in
open
ship,
we
have
a
set
of
API
resources,
that
model
images
and
in
image
streams
where
an
image
stream
is
like
a
logical
image
that
might
have
different
versions
created
for
it.
As
you
like,
rebuild
your
application,
and
one
of
the
triggers
that
we
have
is
an
image
change,
trigger
I.
A
B
B
So
the
if
you
look
at
the
issue,
I
basically
talked
about
here
inside
the
scenario
where
I've
deployed
a
deployment
and
obviously
inside
of
the
deployment.
There's
a
label
selector
that
Italy
described,
which
paws
make
up
my
application
I
then
have
a
corresponding
binding.
That
has
a
pod
preset
inside
of
there,
which
has
the
exact
same
level
selector
so
that
rule
by
deployment
and
the
bindings
or
the
credentials
that
can
get
created
will
get
bound
to
the
pod
preset
to
those
deployment.
B
B
C
B
C
It's
not
banned
like
we
haven't.
We
don't
reject
requests
where
you
might
do
that,
but
you
have
to
do
it
carefully
like,
for
instance,
if
you
change
your
label
selector
to
be
something
that
isn't
a
superset
of
what
it
was
before.
For
instance
like
what
happens
now,
your
deployment
things
that
had
zero
pods
right.
What
happens
there?
Yeah
there's
just
a
lot
of
weird
things
that
can
happen.
B
Okay,
because
I
was
I
was
thinking
of
a
scenario
where
I
might
whittle
the
label
selectors
to
include
you
know,
version
1
and
version
2
of
my
pods
and
I
eventually
kill
off
the
version.
1
side
of
things.
I
know,
they'd
I
know,
there's
a
rolling
upgrade
mechanism
within
deployment,
but
let's
say
I
want
to
do
it
sort
of
manually,
just
like
you're,
probably
saying
well,
don't
do
it
that
way,
create
a
second
deployment
pointing
to
version
2
right.
That's
what
you'd
recommend.
C
Sorry
so
maybe
I'll
just
I'll
say
that
there
are
situations
you
can't
do
it
I'd
have
to
think
about
that
one,
a
little
more
I'm,
not
sure
I
understand
enough
of
these
casing,
details
to
say
yes
or
no,
but
I
guess
I'd
say
it
is
complicated.
So
if
we're,
if
outs
use
case
for
targeting
for
pod,
preset
I,
think
it's
okay,
if
that
is
also
complicated
and
requires
a
lot
of
explaining,
maybe
extra
steps,
because.
F
B
C
B
A
A
B
Mean
I
would
almost
love
it
if
he
had
a
label
selector
resource
and
both
of
them,
both
three
female,
both
label
for
the
deployments
and
services
pointed
to
that
label
collector.
That
way,
you
can
update
label,
select
a
resource
and
it
just
magically
gets
updated
in
both
because
they're
both
is
referencing
it,
but
all
that
doesn't
exist
today.
A
Yes,
that
is
accurate.
That
does
not
exist.
Okay,
I
understood
this
differently
from
how
it's
being
explained
to
me
now,
I
do
think
there
is
another
set
of
issues
that
I'm
happy
to
talk
through
after
this.
That
are
the
ones
that
I
thought
of,
but
we
can
continue
talking
through
this
if
people
think
it's
useful
so.
E
A
A
So,
like
I
was
saying,
pod
presets
are
currently
immutable.
I
would
I
think
that
it
is
best
that
eventually,
they
become
mutable
in
ways
that
have
behaviors
that
users
want
and
on
my
list
of
things
to
do,
is
to
create
an
issue
or
taking
the
settings
API
her
to
beta,
which
I
will
include
in
that
that
we
should
work
out.
The
mutability
story.
I
also
made
an
issue
to
work
out
the
mutability
story
in
kubernetes.
A
There
are
basically
the
TLDR
is
what
I've
already
said,
which
is
that
it's
easier
to
start
with
them
being
immutable
and
recreate
them.
If,
if
you
need
to
alter
them
and
we'll
figure
out
that
all
the
right
ways
to
implement
mutability
in
the
future,
and
then
there
are
a
couple
more
facets,
which
are
this
fall
spelled
out
in
the
in
the
issue:
I'll
just
call
them
out
which
is
like.
If
you
have
one
resource
that
results
in
another
resource
being
created,
how
do
we
prevent
users
from
going
and
altering
the
resource
that
was
created?
A
I
know
that
in
different
UIs
for
kubernetes
or
in
the
ecosystem,
there
are
guards
and
say:
hey,
don't
don't
alter
this
thing
because
it
was
made
by
this
other
resource
and
then
that
there
is
the
story
that
I
started
talking
through
about.
If
we
make
pod
presets
mutable,
we
need
to
think
through
the
effects
and
what
users
would
expect
for
all
the
different
controllers
that
create
generations
of
pods
and
goodman's.
And
that's
that's
what
I've
got
on
that?
Subject:
I'm
having
to
move
along
just.
C
A
A
Yeah
and
there's
been,
there's
been
some
discussion
so
far
about
how
to
make
deployments
that
depend
on
specific
versions
of
a
particular
config
map
or
a
secret,
and
this
is
probably
similar,
actually
went
through
in
this
weekend
kind
of
plunge
some
comments
in
to
get
linkages
into
this
stuff,
the
deployment
stuff
to
our
issue.
So
hopefully
we
can
get
some
at
least
linkage.
You
can
get
hub
that
exists.
If
not
some
cross-pollination
of
ideas
do.
C
A
Okay,
so
we
might
want
to
cyber
on
this
like
offline
one,
where
I,
where
I
left
things.
If
my
understanding
was
that
there
had
been
a
PR
open
to
make
basically
make
a
snapshot
of
each
version
of
a
config
map
or
secret
as
a
separate
config
map
and
then
depend
on
that
one
in
the
deployment.
But
I
don't
think
it
went
anywhere
well.
A
A
Such
that
plan
names
and
service
names
are
mutable
right
now
we're
using
those
names
as
the
names
of
the
kubernetes
objects,
and
we
have
a
separate
property
in
service
class
on
plan.
It's
like
the
grid
of
those
things,
the
the
the
ID
is
supposed
to
be
stable,
and
what
Doug
suggests
is
that
we
use
the
ID
instead
of
the
display
name
as
the
kubernetes
name
and
then
use
those
things,
as
the
actual
coordinates
to
refer
to
those
service
classes
and
plans.
In
an
instance,
I
I
think
that
we
should
do
that.
A
It
sounds
like
we
basically
have
to
if
they
really
are.
Mutable
I
made
an
issue
to
clarify
an
open
serviceworker
that
they
are
immutable
and
like
call
it
out
explicitly,
but
I
think
if
they
are
immutable,
we're
kind
of
backed
into
a
corner
that
we've
got
to
use
those
things
and
it
kind
of
sucks.
If
we
have
to
go
that
way
for
people
that
are
just
writing
ammo
files,
but
we
can
probably
make
that
a
little
easier
with
porcelain
commands,
which
we
know
we
want
you
so.
E
One
thing
that
I
would
like
to
see
in
the
future,
probably
in
the
beta
cycle,
is
have
a
kubernetes
level
abstraction
from
name
to
whatever
we
decide
if
I
D
or
if
it's
the
broker
name.
So
this
in
a
way.
This
is
a
step
backwards,
because
it
sucks
that
you
have
to
reference
goods,
but
it
also
kind
of
paved
the
way,
or
at
least
makes
it
more
painfully
obvious
that
we
do
need
some
kind
of
abstraction
and
the
use
case
for
that
abstraction
is.
E
If
you
go
and
port
your
app
to
a
new
cluster,
you
shouldn't
have
to
change
the
name
or
the
guiit
or
whatever
we're
using
from
the
open
service
broker
side,
and
instead
you
should
point
to
arrests.
Like
kubernetes
manages
for
you
and
then
as
a
dereferences
that
pointer
it
figures
out
what
is
in
the
catalog
that
that
name
represents.
A
Yeah,
you
might
want
to
create
an
issue
about
that
in
general,
we
use
names,
as
coordinates
so
I,
when
my
best
version
of
what
you've
said
would
be
like
if
we
gave
if
we
generated
like
a
synthesized
name
but
I'm,
not
sure
that
that
could
be
stable,
because
the
names
like
the
display
name
set
a
change.
Well,.
E
B
E
Generates
the
name,
so
it's
thinking
like
something
like
take
object,
storage
example.
We
always
use
write.
The
operator
generates
a
resource
or
some
somehow
generates
a
name
called
object
storage.
But
then,
on
the
other
side,
in
the
speck
of
this
object-
storage
name,
it
says
what
in
the
catalog
that
actually
represents.
A
I
think
that
actually
the
field
would
stay
the
same,
but
the
weight
of
well
that
we
begin.
We
keep
the
fields
for
service
name
and
implant
name
the
same.
We
start
putting
into
those
things
the
ID
and
have
a
separate
field.
That
was
the
display
name
which
isn't
great.
But
if
that's
what
we
have
to
do
so
be
it
right
right.
E
Yeah
that
really
sucks
we
might
want
to
consider
changing
the
service
class
ref
in
the
instance
to
have
different
keys
like
one
key
can
say:
catalog
name
are
sorry,
one
key
can
say
service
gooood.
The
other
key
can
be
planned
gooood.
Instead
of
what
we
have
now,
which
I
think
is
service
name
and
plan,
name
yeah,.
A
If
we,
if
we
feel
like
collectively,
there's
a
strong
need
for
another
way
of
addressing
these
things,
then
we
could
it.
We
could
model
the
coordinates
that
we
use
as
like
a
particular
object
that
might
be
a
pointer
and
part
of
a
union
type
that
we
could
add.
Other
fields
too
for
different
variants
of
the
you
can
type
later
on.
Yeah.
A
About
in
the
instant
specs
that
we
could
introduce
a
new
type,
that
would
be
like
service
class
and
plan
coordinates,
crappy
name
just
for
discussion,
and
within
that
you
could
have
a
pointer
to.
You
could
have
a
pointer
to
an
object
that
had
service
class
name
and
plan
name
and
then
later
on.
If
we
devise
a
new
coordinate
system
that
was
better
for
whatever
reason,
we
could
add
that
as
another
pointer
field
in
the
same
object
right.
E
A
E
B
B
A
I
was
actually
pretty
surprised
that
the
name
of
the
thing
can
change
because
they,
for
example,
there
is
other
fields
like
they
say
not
to
change,
Weather,
Service's,
bindable
or
not,
if
I
remember
correctly,
but
you
can
change
the
name
all
over
town.
So
whatever
look
I
did.
Oh,
can
you
see
to
clarify
this
in
and
open
serviceworker
so
that
we
can
know
that
we're
making
a
decision
on
good
information
before
we
start
changing
I.
E
A
A
Right
so
next
one
is,
this
is
actually
a
dupe
of
an
issue
that
I
created,
so
we
might
want
to
close
in
this
one,
but
the
fundamental
problem
is
that
there
are
these.
There
are
three
fields:
we
really
need
to
figure
out
and
open
serviceworker
API,
one
of
them.
The
first
two
are
fields
that
exist
already.
There
are
the
org
and
space
IDs.
A
So
for
those
that
might
not
know
what
those
means
or
might
be
watching
on
the
internet,
and
maybe
haven't
seen
when
we
discussed
these
before-
is
that
Cloud
Foundry
has
a
different
taxonomy
for
were
the
units
of
software
that
are
deployed
into
cloud
foundry.
So
in
kubernetes
we
had
namespaces,
and
that
is
our
way
of
dividing
up
a
cluster
in
cloud
foundry.
A
B
A
A
D
B
D
The
only
reason
why
product
the
old
ID
thing
is
because
the
the
cluster
ID
seems
a
little
bit
different
in
the
sense
that
if,
for
example,
you're
running
multiple
coasters
and
an
organization
means
to
go
ahead
and
it
kind
of
bleeds
over
into
the
like
are
back
I
guess.
So
that's
why
I'm
not
sure
that
that
first
mapping
is
correct.
Yeah.
A
So,
in
addition
to
these
organ
space
fields,
there's
also
a
new
field
which
is
proposed
but
not
accepted
to
the
API.
Yet,
which
is
the
context
which
we
had
hoped
to
be
a
place
to
send
kubernetes
relevant,
coordinates
like
what
cluster
am
I
coming
from
what
namespace
MI
N
and
we
need
to
figure
out
what
do
we
send
there?
So
those
that's
the
fundamental
issue,
there's
as
usual,
incriminated,
land,
tons
of
entanglements
and
different
facets.
Doug
did
I
state
that
correctly
yeah.
B
That
just
wanted
to
touch
on
what
do
they
would
say
in
there
I
agree
that
org,
it
may
not
necessarily
be
a
best
match
for
cluster
ID,
but
given
the
fact
that
organ
space
are
required,
fields
that
we
have
to
send
today,
I
was
trying
to
think
of
what
would
be
the
most
useful
information
to
get
stick
in
there.
Even
if
it
wasn't
a
perfect
match.
Saving
the
context
field
that
Paul
mentioned
as
the
real
place
to
stick
in.
B
You
know
the
real
data
with
the
real
names,
that's
a
better
description,
because
I
wanted
us
to
be
able
to
try
to
at
least
talk
to
existing
brokers
today
and
provide
them
with
meaningful
information
if
they
did
try
to
talk
back
to
the
platform
when
I
figured
cluster,
ID
and
namespace
good
are
probably
the
two
most
important
things
that
we
have
to
offer
at
this
point
in
time.
That's
why
I
lump
them
into
living
space,
god.
D
It
would
be
interesting,
it
might
be
used
for
the
go
ahead
and
spend
a
little
time
understanding
what
decisions
state
broker
might
make
based
on
the
org
ID
I
totally
get
it
out
of
the
space
ID.
It
makes
sense
for
you
to
go
ahead
and
make
things
like.
Oh
I'm,
going
to
push
her
to
somewhere.
I,
don't
understand
what
the
org
ID
is
used
and
my
apologies.
If
it
solving
this
buck,
I
haven't
I,
haven't
read
through
it.
B
A
So
I
thought
of
a
couple
monkey
wrenches
to
throw
out
about
this
over
the
weekend.
Is
that
I
wonder
if
there
is
any
use
case
where
a
kubernetes
user
needs
to
send
like
a
particular
value
that
we
don't
have
in
kubernetes
like
say
that
they
need
to
send
a
Cloud
Foundry
org
ID?
Then
we
just
don't
know
about
I
wonder
if
we
might
want
to
have
fields
on
instance
that
govern
how
these
are
sent
for
instances
and
for
the
bindings
to
that
instance.
But
I
will
put
that
in
a
comment.
D
Because
I
think
I
think
today
what
happens
is
that
the
org?
Doesn't
you
think
I
have
to
go
back
to
that
efficiency
or
derived
by
the
Cloud
Foundry
controller
by
the
user,
making
the
request?
So
it
knows
because
there
is
import
their
for
it
nothing.
What
Paul
is
saying
is
that,
because
we
don't
have
such
a
way
to
come
in
and
say,
for
example,
hey
geo
controller,
give
me
an
org.
We
could
say
on
whether
it's
an
instance
basis
or
whether
it's
per
Reaper
space
is
go
and
say:
hey,
go
ahead
and
use
this
organization.
D
E
So,
to
add
on
to
that,
it
doesn't
org
is,
is
such
a
thing
that
it
doesn't
seem
like
a
developer
or
someone
submitting
an
instance,
whoever,
whatever
you
want
to
call
that
person
was,
we
wouldn't
want
to
make
them
the
person
responsible
for
setting
the
org
like
it
would
yeah
install
service
catalog?
Is
the
operator
probably.
F
A
B
D
B
D
B
And
yeah,
and
to
so
what
you
guys
know,
the
reason
that
this
came
up
is
because,
in
the
bluemix
environment
we
have
multiple
queries
clusters
out
there,
and
so,
if
the
only
information
that
they
come
client
service
broker
is
going
to
see
today
is
organ
space.
We
needed
a
really
good
way
for
him
to
get
and
I
did
some
kind
of
identifier
to
let
us
know
which
which
kubernetes
cluster
he's
talking
to,
or
it
is
being
active
on
here
now.
This
reminder.
A
A
And
I
had
a
discussion
about
this
before
and
I
seem
to
recall
that
you
brought
up
that
a
a
broker
could
use
the
thought,
like
the
auth
principle,
that
the
catalog
or
the
platform
was
authenticated,
as
basically
as
a
way
to
figure
that
out.
I
was
thinking
about
that
as
a
as
a
potential
like
stopgap
for
having
to
identify
cluster
identity,
because
cluster
identity
is
a
really
complex
topic,
I
think.
A
If
you
get
into
cluster
Federation
and
like
you,
you
might
have
different
facets
of
different
clusters
that
are
federated
differently
alike,
but
ultimately
refer
back
to
the
same
thing.
Without
getting
into
that
I'll
bring.
That
up
is
something
that
I
seem
to
recall
that
you
suggested
as
something
brokers
could
do
to
guess
at
that
information.
For
now
does
that
sound,
familiar
yeah.
B
B
Since
then,
the
world
has
changed
and
bluemix
has
changed,
and
now
we
actually
have
multiple
instances
of
kubernetes
under
one
platform.
So,
therefore,
you
could
think
of
it
as
one
gigantic
platform
talking
to
the
service
broker
and
that
brought
dad
that
platform.
What
he
talks
about
is
not
going
to
be
able
to
I'm
sorry.
The
broker
would
like
to
be
able
to
know,
which
instance
of
proven
edit
is
talking.
He
is
referring
to
just
for
the
platform
itself.
Unfortunately,
yeah.
A
So
I
think
that
if
I
read
between
the
lines
in
this
discussion,
I
can
easily
imagine
situations
that
might
have
some
similarities
to
this
in
Cloud
Foundry,
where
you
might
have
multiple
Cloud
Foundry
instances
that
have
organizations
in
spaces
that
span
multiple
collab
boundaries
and
I
wonder
what
brokers
do
today.
I
almost
think
this
is
another
case
where
we
might
want
to
edification
about
what
are
they?
What
do
existing
brokers
do
in
that
situation?
A
Is
it
a
real
situation,
etcetera,
I,
don't
I,
don't
think
that
we're
going
to
have
it
thing
that
we
can
point
to
immediately
as
being
a
good
Wester
ID,
so
I
liked
your
idea
of
using
different
credentials
for
different
clusters
so
that
the
broker
can
use
it.
Some
like
off
principle
as
that
last
coordinate
yeah.
B
Up
and
torn
down
all
the
time
now
the
other
point
of
I
agree
with
you
right
now.
We
don't
have
a
good
cluster
ID
I'm
do
investigation,
though,
because
I'm
being
told
that
under
Federation
we
may
have
something
close
to
a
cluster
ID
that
we
may
be
able
to
reuse.
I'm,
not
I,
represent
sure
what
it's
being
used
for
today.
So
I'm
still
doing
two
investigation
ever
see
whatever
use
it
or
not.
I'll,
let
you
guys
know
what
happens.
Would.
B
C
B
That
was
mentioned
in
the
issue.
What
do
we
call
a
cluster,
ID
or
search
house
ID?
We
definitely
could
do
something
like
that.
I'd
like
to
save
that,
for
after
we
exhaust
the
idea
of
using
something
that's
already
there,
or
so
that
can
be
used
more
global
level,
because
I
think
I
think
this
will
be
needed
for
other
purposes
just
be
besides
just
Service
Catalog,
so
I'd
rather
hold
that
off
right
now
that.
E
Up
our
sleeve,
so
I
did
I,
haven't
committed.
I
haven't
whatever
submitted
this
comment
yet,
but
that
was
one
thing
I
suggested
is
like
literally
man
line
flag
for
cluster
ID
or
org,
or
they
want
to
call
it.
There
are
a
few
different
names,
I
think
here
or
the
top
level
org
parameter.
I,
don't
want
to
solve
this
for
anything
else,
but
Service
Catalog.
So
I
I.
Just
warn
against
that
that
this
is
a
unique
situation
just
for
brokers,
I,
believe
yeah.
B
It
depends
well,
it
depends
on
which
issue
talking
about,
because,
if
you're
talking
about
what
the
stick
in
org
agreed,
that's
our
problem.
If
you're
talking
about
the
ability
to
identify
which
creates
cluster
you're
talking
about
particular
message
flow
I,
actually
think
that
broader
than
Service
Catalog.
In
fact,
Simon
play
me
to
an
issue
where
Brandon
Phillips
core
OS
mentioned.
He
has
used
cases
where
he'd
like
that,
a
cluster
ID
at
the
thing
as
well.
So
if
we
could
solve
it
for
both
that's
great
but
yeah.
B
C
E
B
B
A
B
C
C
B
B
So
with
that
with
in
mind,
I
thought
we
should
probably
stop
sending
the
namespace
ID
for
the
app
ID,
because,
even
though
technically
that's
kind
of
what
we're
doing
right
now
right
we're
binding
the
secrets
to
the
namespace
or
it's
available
inside
of
namespaces
to
say:
that's,
not
quite
accurate
enough
or
fine
grained
enough.
When
you
start
talking
about
multiple
applications
being
deployed
to
the
same
thing,
space
right,
the
broker
may
want
to
distinguish
between
those
two,
even
though
they're
in
the
same
namespace,
so
I
think
it'd
be
nice.
B
If
we
can
come
up
with
some
some
algorithm
or
something
that
can
generate
an
app
ID
on
a
per
application
basis,
and
we
need
to
then
obviously
discuss
what
defines
an
application.
Okay
and
as
a
strawman
proposal,
I
said
well:
let's
just
take
the
label
selectors
and
do
some
tracks
on
that,
but
I'm
open
to
any
idea
to
try
to
produce
something:
that's
more
fine-grained
and
just
make
there.
So
that's
the
idea
behind
this
one.
We.
B
A
B
A
Well,
like
places
down
the
readwrite
versus
read-only,
you
might
have
one
team.
That's
leg.
I
want
to
send
I,
have
a
separate,
read
only
connection
to
the
database
for
things
like
use
and
stuff.
I
know
isn't
going
to
invoke
a
store
procedure
and
then
I've
got
my
right
connection
and
maybe
I
want
to
do
some.
Some
switching
in
my
application
between
a
read-only
connection
and
a
right,
readwrite
connection
and.
A
E
B
What
does
that's
one
mention?
One
thing
of
one
of
the
issues
with
multiple
bindings
to
the
same
app
is
that
there
is
no
requirement
whatsoever
in
the
credentials
that
come
back
to
identify
which
one
is
which
right
and
so
as
an
application.
If
I
have
two
different
secrets
bound
to
my
application,
it's
not
clear
to
me
how
I
know
which
seek
review
applies
to
the
read-only
versus
the
readwrite,
and
there's
there's
no
guarantee,
without
without
on
other
abandon
communication
is
the
way
to
know.
B
D
B
B
Yeah,
okay,
so
this
last
issue,
so
this
issue
came
around
because,
as
your
as
I
was
working
through
with
the
gloomy
skies
about
you
know,
hooking
this
into
our
system
and
stuff.
The
idea
of
periodically
a
platform
is
supposed
to
check
with
the
service
broker,
to
see
if
anything's
change
in
its
catalog,
you
know
new
services
get
added
or
didn't
hear
it
or
whatever,
and
so
then,
of
course
you
have,
the
problem
of
a
service
gets
deleted
or
a
plan
gets
deleted.
B
B
Sorry,
the
service
itself,
if
all
its
plans
are
inactive
and
what
that
allows
you
to
do
is
to
basically
prevent
those
services
and
plants
for
being
visible
to
an
end
user
when
they
ask
what's
available,
but
it
allows
the
current
application
to
continue
on
its
merry
way
and
then,
as
they
end
up
killing
off
those
bindings
and
stuff
using
those
plans,
something
in
the
system
will
detect.
Oh
okay,
I
can
have
a
garbage
click
this
thing
and
then
things
can
slowly
start
disappearing.
So
that's
what
this
issue
is
all
about.
B
A
A
E
A
A
E
A
A
D
A
D
A
A
Okay,
so
I
have
one
last
thing,
which
is
that
I
was
a
Red
Hat
summit
last
week,
which
for
people
that
don't
know
it's
like
Red,
Hat,
GCT,
next
or
I,
know
dais
had
a
summit.
It's
basically
a
session
to
talk
to
Red
Hat
like
users
and
customers
and
stuff
like
that,
and
for
them
to
to
talk
to
other
customers
and
so
forth,
and
we
had
a.
We
had
a
keynote
that
we
showed
a
demo
of
the
open.
A
Shipped
integration
with
the
Service,
Catalog
and
I
had
a
talk
where
we
talked
about
the
mechanics,
low-level,
mechanics
of
the
API
and
a
civil
service
worker
that
were
working
on
and
there's
a
tremendous
amount
of
interest
amongst
users
of
OpenShift
for
this
stuff
and
in
the
kubernetes
community
in
general.
So
thanks
to
everybody
that
has
contributed
to
help
make
that
a
success
so
far,
and
that's
what
I've
got
anything
else.
E
A
Viel
a
has
got
to
jump
hurdles
in
the
dark,
all
the
different
kinds
that
we
have
in
this.
In
this
thing,
oh
okay,
that
reminds
me
of
one
more
thing,
which
is
that
going
back
to
a
previous
hurdle
that
we've
jumped
in
the
dark
I
opened
a
full
request
to
the
community
repo
changing
the
API
conventions
document
to
try
to
clarify
when
we
should
use
a
condition
in
one.
We
should
just
have
a
field
on
status
I've
reached
out
to
a
couple
of
the
kubernetes
owners
to
see
if
I
could
get
some
eyes
on.
That.
B
C
A
The
API
review
I
was
talking
about,
didn't,
have
a
chance
to
do
it
last
week
with
summit
and
some
other
stuff
that
came
up
that
I
had
to
deal
with,
but
I'm
going
to
see.
If
I
can
get
someone
to
look
at
it,
I
sincerely
doubt
you
will
get
interactive
time
with
them.
They
may
leave
comments,
but
I'll
see
what
I
can
do.
Okay,
thank
you
cool
all
right!
Well,
we're
one
minute
over
time!