►
From YouTube: Kubernetes SIG Service Catalog 20161026
Description
SIG Service Catalog reviews and agrees to use cases for listing, curating, and consuming services.
Agenda - https://docs.google.com/document/d/10VsJjstYfnqeQKCgXGgI43kQWnWFSx8JTH7wFh8CmPA/edit
A
Alright
welcome
everybody
to
the
October
26
special
edition
of
Coober
net
e
cig
service
catalog.
Today
we
are
going
to
try
to
a
mine
Jason's
pull
request
to
the
incubator,
repo
for
the
kernel
of
use
cases
that
we
can
all
agree
upon.
So
Jason,
would
you
mind
sharing
your
screen
with
that
quest
on
there
and
we
can.
We
can
go
through
those
yeah
sure,
okay,.
A
That
be
enough,
I
think
so
so
what
I
suggest
for
this
is
we
we
have
a
copy
of
this.
Why
don't
we
try
to
go
through
these
and
we'll
take
out?
Why
don't
we
take
out
anything
that
we
don't
immediately
agree
to
just
for
the
sake
of
getting
the
minimal
set
of
things
that
we
all
agree
to
into
the
git
repo?
Is
everybody
cool
with
that
all
right,
I'm,
not
hearing
knows
okay
Jason,
you
wanna.
Do
you
want
to
lead
this
part
of
it?
Sure?
C
Right
I
start
at
the
top
very
good
place
to
start
oh
I,
guess
before
we
start
does
anyone
have
questions
about
the
organization
of
this
thing?
What
why
we
kind
of
did
it
this
way
to
make
sense
all
right,
catalog
management,
so
as
a
user
I
want
to
be
able
to
register
a
broker
with
the
community
service
catalog
so
that
the
catalog
is
aware
of
the
services
services
the
broker
offers
any
injections
seems
straightforward.
C
A
So
I
think
these
use
cases
came
from
you
Weston
is
that
right?
Originally
yeah
and
I
made
some
comment.
So
it's
just
kind
of
it's
just
trying
to
think
through
the
local
development
story
a
little
bit
and
try
to
make
sure
that
we
have
a
way
for
I.
Don't
know
somebody,
that's
a
part
of
a
team
to
bootstrap
their
environment
with
a
set
of
services
so
that
their
first
tasks
is
not
going
in
registering
18
different
service
workers
that
their
team
happens
to
use.
A
But
I
do
think
that
it's
probably
something
that
we
can
push
out
for
now.
I
I
guess
we
had
I
briefly
like
brainstormed
about
this,
and
if
the
brokers
are
registered
with
the
controller
via
some
sort
of
yam
will
file,
then
that
seems
like
a
pretty
easy
way
for
me
to
sort
of
Export
Import.
Just
like
you
know,
create
coop
cuddle,
create
you
know
da
chef
and
then
appoint
her
off
to
the
list
of
service.
Workers
seems
like
in
a
reasonable
way
to
bootstrap
an
environment
with
a
single
movement
yeah.
A
So
that's
sort
of
what
was
in
my
head
too,
and
so,
as
you
mentioned,
there's
like
cute
CTL,
create
a
chef
that
will
take
a
single
file
that
has
a
bunch
of
different
resources
in
them
and
just
create
them
in
the
API
server.
And
that's
that's,
there's
also
a
cube,
CTL
export,
which
will
give
you
the
X
portable
version
of
something
like
it'll,
take
out
the
status
part
of
a
pod
and
other
status
fields
that
you
know
aren't
going
to
be
portable
across
API
servers.
So
I
think
that's
that's
a
these
use.
A
Cases
align
pretty
well
with
that
on
and
I
think
that
we
will
get
that
well.
So
this
is.
This
is
an
interesting
area
like
the
intersection
between
cube
CTL
and
the
main
API
server,
and
this
thing
I
want
to
say
that
if
we
build,
if
we
build
the
catalog
correctly,
we
should
be
able
to
find
a
way
to
get
those
things
by
virtue
of
how
the
catalog
is
architected.
B
I,
the
last
one
we're
just
talking
about
I
agree,
it's
a
valid
use
case,
I'm,
not
quite
sure
it's
as
simple
as
just
take
the
yellow
file
from
one
place
and
stick
into
another,
because
you
have
to
build
up
a
trust
relationship.
There's
accounting,
there's
procurement,
there's
money
involved
in
many
cases,
I
think
it's
a
lot
more
involved
in
it,
but
I
do
agree
with
the
use
case.
I
would
just
prefer
if
we
free
phrase
it
slightly
differently.
B
A
B
A
It
yeah
it's
fine,
we
can.
We
can
change
the
import/export
terminology.
I
haven't
reviewed
to
this
specific
text
that
you
proposed,
but
I
can
take
a
look
at
that,
but
I'm
fine,
I'm,
fine,
altering
this
to
be
a
little
bit
more
generic
okay.
So
the
next
several
lines
are
the
next
lines
down
to
49
are
carried
over
from
these.
A
These
are
more
detailed
write-ups
of
the
first
three
use
cases,
and
here
that
are
carried
over
from
work
that
Doug
and
I
did
in
this
use
case
document
a
few
weeks
ago,
really
I
think
they're
that
old,
so
there's
probably
not
a
need
to
go
over
them
now.
Why
don't
we
skip
ahead
to
the
next
section
unless
I
think
I
heard
someone
started
to
speak,
I
had
a
few
late.
If
you
just
sort
of
process
questions,
is
there
a
doc
that
were
sort
of
call
it
like
that?
A
D
Option
is
wiki
page
in
the
repo
which
is,
and
issues
are
great
for
deep
dives
on
specific
things,
but
if
we
want
to
accumulate
a
body
of
things
that
we
need
to
work
on
and
keep
up
to
date,
github
issues
have
proven
difficult
to
manage.
Although
there's
the
new
projects
mechanism
that
you
can
use
risers
ring
if
I
lose
that,
but
the
main
complaint
people
have
had
about
using
hues
and
labels.
Instead,
it's
sort
of
really
hard
to
figure
out.
D
E
A
To
get
the
discussion
and
github
and
I
forgot
so
I'll
leave
it
to
you
to
kind
of
define
what
you
would
like
to
have
a
student,
but
another
point
feedback
I
had
was
on
when
reading
through
this.
Even
when
you
get
to
the
first
use
case,
it
talks
a
lot
about
brokers
and
catalogs,
and
I
know
we'd
have
that
terminology
list,
but
for
someone
coming
at
this
pretty
new,
it's
a
little
we're
already
making
some
assumptions
like.
A
F
A
The
best
way
to
capture
that,
but
some
sort
of
intro
I
thought
would
be
pretty
useful
to
just
sort
of
set
the
groundwork
for
what
we
expect.
These
different
pieces
to
be
I,
don't
know
if
that's
the
definition
or
if
it
should
just
be
like
at
the
very
top
of
this
dock,
which
is
like
hey.
We
read
this
other
thing
over
here,
just
to
get
up
to
speed
before
reading
through
the
use
cases.
Yes,
so
that's
that's
a
really
good
point.
A
I
think
that
I
think
that
the
story
said
jay
posted
as
a
pull
request
like
that.
That
kind
of
format
is
probably
a
good
way
for
someone.
That's
totally
new
to
the
space,
to
kind
of
get
a
handle
on
what
the
the
nouns
and
verbs
and
the
space
are.
I
I
would
like
to
see
that
story
I
land
in
the
repo
and
be
the
thing
that
you
can
read
to
start
from
zero
and
at
the
end
you
feel,
like
you
understand,
I.
A
C
A
Okay,
so
noted
that
we
need
to
I
think
there's
there's
room
for
both
a
glossary
and
an
introductory
story
to
explain
the
basics
and
kind
of
a
english
prose.
I
think
jay
put
it
as
creative
writing
101
type
of
format.
I
think
there's
room
for
both.
I
and
let's
continue
refining
those
this
week
and
next
asynchronously
on
github
sounds
good.
Okay,
let's.
C
Let's
see,
don't
worry
the
cursor
there,
it
is
so
how're
service
is
identified
by
name
service,
name
and
ID
plan,
name
and
ID
I.
Think
that's
one
of
those
open
questions
worth
discussion
who
can
see
which
services
and
these
are
ya
and
who
can
see
which
service
instances
which
service
instances
are
globally
visible
from
the
catalog
curation
standpoint,
which
broker
provided
services
are
globally
visible,
which
namespaces
can
see
which
catalogue
services
and
then
the
catalogue
listing
the
service
types
and
instances
as
an
open
question.
Yes,.
A
11
I
I,
don't
think
that
these
are
invalid.
I
do
think
from
prior
experience
in
Coober
Nettie's
that
I
it
is.
It
can
be
easier
to
forego
questions
about
acl's
a
policy
are
back
etc
and
concentrate
on
the
core
mechanics
first
and
then
then
worry
about
the
questions
of
the
types
that
I
just
mentioned.
The
caveat
is
that
you
have
to
build
a
thing.
A
If
you
do
that,
you
have
to
build
a
thing
that
you
can
eventually
implement
policy
for
and
implement
our
back
over,
so
I'm
I
am
personally
okay
with
these
staying
in
I
think
it
may
be
convenient
to
table
them,
keep
them
in
there,
but
table
them
and
concentrate
on
the
core
mechanics
and
that
that's
what
I've
got
on
that
pc
o
app.
You
know,
speaking
of
core
mechanics,
I,
think
Doug
read.
A
Something
is
like:
should
the
catalog
have
service
classes
or
service
types
only
or
should
it
be
a
combo
of
service
types
and
service
instances,
because
it's
like
who
can
see
which
service
instances
are
those
exposed
through
the
catalog
or
they
expose
through
some
other
mechanism?
I
think
Doug
was
advocating
for
keeping
those
concepts
separate.
The
catalog
is
just
a
collection
of
service
types
that
you
can
offer
yeah
yeah
I
agree,
there's
some
discussion
that
needs
to
happen
to
nail
it
down.
B
A
A
B
A
B
D
Think
one
sort
of
meta
point
that
that
suggest
is
we
need
to
be
careful
about.
Terminology
has
come
up
a
few
times
in
this
discussion,
so
we
should
just
agree
to
use
the
terms
in
the
glossary.
The
word
service
should
never
be
used
without
qualification,
and
you
know
introducing
new
terms
like
broker
provided
services.
We
should
just
try
to
like
that.
Yeah.
A
I
think
that's
a
good
point,
so
why
don't
we?
Why
don't
we
amend
the
bylaws
of
this
meeting
and
say
that
will
will
merge
the
product
of
this
out
of
this
meeting
and
then
we'll
take
a
pass
through
we'll
find
one
or
more
people
to
take
it
pass
through
and
reify
all
the
terminology
in
the
glossary
in
this
document,
so
that
it's
consistent
with
fat
glossary
is.
Is
everybody
cool
with
that
yeah.
A
A
A
C
Alright,
so
requesting
services.
So
this
is
a
consumer
who
would
like
to
get
access
to
a
service.
The
first
one
is
how
to
ask
for
a
new
service
from
the
catalog,
and
the
second
one
is:
how
do
I
find
an
application
to
an
existing
service
instance
so
something
that
has
already
been
provisioned
and
just.
F
F
B
C
So,
let's
see
so,
we've
got
creating
something
getting
access
to
something
that
already
exists.
Then
this
last
one.
How
does
the
catalog
support
multiple
consumers
and
different
crew
benetti's
namespace
of
the
same
instance
of
a
service,
so
I'm
a
namespace
AAA
their
namespace
be,
and
we've
got
a
shared
service
that
we
would
like
to
both
bind
to.
F
F
E
D
C
B
A
C
C
So
73
and
75
I
think
these
are
both
have
more
to
do
with
provisioning
a
set
of
things
in
the
Ku
brunette
cluster,
which
will
provide
the
service
less
so
than
something
that
is
living
off
cluster
and
perhaps
from
me
by
a
cloud
foundry
service
broker.
So
as
an
implementer
of
a
service
provider
for
service
back
end
again,
I
think
this
is
a
noun
to
extract
on
communities
where
may
I
provision
communities
resources
so
that
I
may
provide
the
requested
service
and
paired
with
that.
C
A
I
think
so,
let
me
say
one
I
think
black
box
is
a
convenient
line
to
draw
now.
I
do
think
that
provision
in
line
73
may
refer
more
to
the
black
box
case
of
where
do
I
put
the
secret
that
I
need
to
use
a
black
box
service.
Then,
where
do
I
put
white
box
resources?
Jason
I,
don't
know
if
you
understand
it
that
way:
I
don't.
D
A
C
D
B
So
I'm
not
sure
where
this
goes
or
even
if
it
goes
anyplace,
but
at
some
point
I
think
we
need
to
have
a
concrete
decision
as
terms
of
the
interface
between
the
platform
and
the
service
broker
and
is
cloud
foundry
server,
kpi's
the
starting
point
for
that
I've
been
kind
assuming
it
was
at
least
my
starting
point,
but
I
want
to
make
sure
everybody
else
is
on
the
same
page,
because
otherwise
we're
going
to
be
disagreeing
without
necessarily
realizing.
I
put
it
that
way.
I
also.
B
F
C
C
D
I
think,
either
at
least
having
a
predictable
the
resources
and
names
for
those
resources
and
potentially
even
being
able
to
configure
the
names
of
those
resources
is
important
for
the
declarative
model
to
work.
Yeah
I
don't
want
someone
to
have
to
write
a
programmatic
client
to
create
something,
go
fetch
you
IDs
and
things
like
that
and
then
generate,
and
the
next
set
of
resources
to
consume
them.
Yeah.
B
C
C
B
I,
wouldn't
look
I,
think
the
idea
of
someone
on
the
crew
bernetti
side
of
things
being
on
the
platform
side
of
things
being
able
to
find
out
who
or
what
is
bound
to
a
particular
service
instance,
is
a
valid
query
in
general.
I
just
wasn't
sure
that
they
would
be
the
service
operator
because
I'm
until
I
interpreting
the
service
operator
that
service
provider
I
think.
B
A
Think
there
are
two
different
at
least
personas
that
may
be
interested
in
this
right.
Like
a
user,
an
application
operator
wants
to
know
which,
which
services
their
application
is
bound
to.
The
an
administrator
may
want
to
know
all
of
the
bindings
to
from
all
applications
to
all
services
and
there's
probably
some
middle
ground
in
there
to
that
I'm.
Not
thinking
of.
B
F
B
A
C
A
So
I
think
there
are
two
different
levels
here:
I
think
that
the
level
of
making
a
claim
is
probably
a
namespace
and
that
there's
a
different,
a
level
for
binding
that
could
be
up
I'm.
Sorry,
a
of
course
the
name
is
escaping
me.
The
thing
that
we
now
call
pet
set
arm
severed
employment,
that
is
the
that
is
the
target
of
a
binding.
F
F
F
See
like
I
just
want
to
make
sure
I
understand
it.
If
I
can
take
one
minute
ago
and
say
how
I
invested
it,
which
is,
there
is
some
kind
of
a
container
object.
Let's
call
it
service
binding
instance,
or
something
like
that,
and
it
has.
It
has
a
label
selector
and
the
label.
Selector
is
the
one
that
defines
the
the
units
that
that
the
consumption
is
tied
to.
A
D
Fundamentally,
it's
going
to
be
some
set
of
pods
with
the
name.
Namespace
is
the
short
answer.
Yes,
the
manual
way
of
connecting
them
would
be
to
have
some
reference
to
the
pods
that
consume
the
predictable
secret
information,
the
automatic
way
that
can
automatically
inject
that
information
and
ought
and
set
up
network
policy,
and
things
like
that.
We
use
a
ladle
selector
on
some
resource
like
service
instance
binding
or
service
innocence,
claim
or
whatever
it
is.
We
decide
to
call
it
or.
F
B
So
Brian,
just
for
my
own
understanding
carrying
forward
are
we
assuming
that
we
can
or
cannot
change
existing
curve,
daddy's
code
in
our
final
solution,
because,
though,
a
lot
of
what
you
describe
their
implied
is
sort
of
not
one
of
the
magic
happen
under
the
covers.
You
know
in
terms
of
things
appearing
within
your
pod,
but
that
would
require
a
changing
existing
code.
I
was
wondering
whether
that's
okay
or
not,
because
I've
been
kind
of
assuming
where
we
weren't
allowed
to
change
the
existing
code.
We.
D
Are
allowed
to
change
existing
code
I
would
prefer
that
changes
to
existing
code
not
be
only
usable
for
this
mechanism
I
most
amazing
that
we
would
need
other
extensions
or
automation
would
need
as
well
and
many
of
the
features
that
we
would
need.
We've
been
discussing
for
like
two
and
a
half
years,
so
this
merely
increases
the
priority
of
funny,
including
those
things
yeah.
A
D
Just
as
one
example,
if
we
want
to
hack
a
prototype,
we
wouldn't
have
to
make
changes
to
the
core.
We
could
do
something
like
put
a
unsatisfiable
node
selector
on
a
bunch
of
pods
so
that
they
don't
schedule
you
can
have
a
controller
come
in
from
the
side,
match
the
pods
against
the
label,
selector
and
rewrite
them
to
add
the
secret
volumes
or
environment
variables,
using
the
downward
API
or
whatever
we
want
and
remove
the
unsatisfiable,
no
selector
and
then
they'll
get
scheduled
and
it
all
we
could
write.
D
So
that's
our
work,
it's
not
very
elegant.
Well,
it
won't
work
with
a
role-based
access
control
enabled
probably,
but
but
you
know,
but
for
sure
it's
not
elegant,
so
we
would
want
a
more
first-class
robust,
easily
discoverable.
You
know
compatible
with
access
control
all
that
kind
of
stuff
solution,
but
the
solution
would
not
necessarily
be
specific.
The
only
service
binding
injection
got
it.
Okay.
Thank
you.
A
Yeah
so
just
to
say
a
few
words
on
on
top
of
what
Brian
said,
I
hope,
then
we
will
find
specific
issues
which
I
think
there
are
a
set
of
known
issues
that
are
things
that
we
want.
That
can
help
us
I
think
it
is
incumbent
upon
us
in
the
face
to
face
to
call
those
issues
out
probably
upfront
and
look
for
places
where
they
fit
in,
so
that
we
can
have
specific
things
that
we
take
away
to
say:
okay.
Well,
we
think
the
priority
of
x,
y&z
issue
being
implemented,
is
probably
high
from
us.
A
D
C
C
So
94
as
a
user
concerned,
consuming
a
service
instance
via
binding
I
need
to
be
able
to
understand
the
structure
of
the
communities.
Resources
that
are
created
when
a
new
binding
to
a
service
instance
is
created
so
that
I
can
configure
my
application
appropriately.
So
I
think
to
use
the
example.
This
would
be
the
structure
of
the
secret
that
is
mapped
that
bar
run
kuber
Nettie's
service,
binding
/
name.
C
C
D
Is
at
the
configuration
level,
for
example,
which
secret
you
would
reference,
or
also
at
the
application
level
like
inside
your
application,
you
need
to
understand
what
the
name,
location,
format
etc
of
the
data
is
so
that
you
can
ingest
into
application
and
yeah
I.
Think
that's
on
the
on
the
configuration.
C
D
It
sounds
like
it's
an
additional
level
of
detail.
It
needs
to
be
understood
compared
to
anyone.
I
think
this
is
something
it's
wig
is
going
to
be
useful
to
service
surface
it
through
the
service
broker
as
well
like
people
are
going
to
need
to
building
things
to
consume.
The
bindings
are
going
to
need
to
understand
what
the
service
broker
returns
for
a
given
service
instance
and
plazas
will
need
some
relatively
automated
way.
I'm
guessing
to
translate
credentials
returned
into
communities
resources.
Oh
yeah.
D
F
D
F
So
so
so
on
that,
for
the
cloud
founder,
you've
been
pushing
for
all
of
those
to
be
described
all
through
schemas,
so
Jason
ski
must
don't
tell
you
what
you
get
back
from
there
and
then
then
at
least
you
will
be
able
to
understand
what
the
heck
you're
supposed
to
be
getting
back.
Okay,
yeah!
So
that's
both
for
the
instances
and
the
weigh-in
as
well
as
on
the
out
it
gave
on
a
super
news:
the
blankets,
the.
C
D
C
F
Some
kind
of
handle
or
something
I
really
might
be
it.
For
example,
you
might
have
a
way
to
go
in
control.
What
kind
of
credential
you're
gonna
get
back
in
there
so
kind
of,
like
you
can
say,
give
me
a
size,
small,
medium
large,
you
might
be
able
to
say
I
actually
cuz.
The
code
has
been
written,
possibly
being
able
to
go
and
handle
certain
kind
of
connection
or
like
use
the
credentials.
C
A
C
B
B
D
Think
there's
a
question
of
if
you
need
different
types
of
bindings
to
the
same
physical
thing.
Would
you
represent
that
as
two
separate
instances,
or
is
the
same
instance
like
if
you
create
a
database
and
it
has
a
data,
the
data
port
and
an
admin
port,
or
something
like
that?
You
know:
how
does
that
work?
You
can't
really
create
two
instances.
Those
would
be
separate
databases,
so
you
have
11
and
one
binding
to
talk
to
both
probably
would
not
make
sense
for
clients
without
admin,
privileges
and
things
like
that.
I
think.
A
A
D
D
Also
has
some
kind
of
bug
for
a
band
port,
so
that's
a
week,
three
ports
would
be
on
a
large
number
of
applications,
and
those
ports
are
generally
authorized
differently
if
nothing
else,
all
sometimes
with
firewalls
and
sometimes
with
applicable
credentials.
But
certainly
there
are
distinct
pieces
where
you
would
expect
different,
I
guess
in
those
use
cases
you
would
expect
to
a
client
to
only
access
one
of
those
ports
at
a
time
rather
than
multiple
of
them,
something.
F
Naked
and
just
just
to
be
cleared
also
seems,
like
you
definitely
weren't,
going
out
the
case
where
a
like
you
would
what
you
would
not
want
all
the
applications
to
get
all
the
credentials
feeder
right
so
like
even
in
the
case
of
like
at
me
nana
and
like
read-only
access,
you
might
not
want
to
return.
Only
be
misunderstanding:
are
you
saying
you
always
return
all
of
everything's?
No.
C
One
way
to
think
about
at
least
the
one
way
that
I
think
about
this
is
that
each
of
those
facets
of
the
service
in
da
new
terminology
would
be
different
hands
right.
So
you've
got
services,
production
database
and
then
plan
has
admin
plan
as
user
finest
read-only
would
be
one
way
to
approach
that,
rather
than
but.
F
It
can't
be
the
thing
is
that
in
the
cloud
foundry
think
they're
quite
nebulous
on
it,
so
it
could
be
that
opposite
may
be
quite
a
service
instance
and
sedo
could
actually
pull
impervious
to
database
and
it
creates
the
tables
and
it
creates
everything
else
they
also
say,
but
then
some
of
that
could
be
done
at
finding
time.
So
it
could
be
that
you
might
have
a
database
and
you
get
your
own
set
of
tables
really
quite
a
binding
to
it.
F
A
F
D
So
anyway,
it
doesn't
sound
like
plan.
Is
the
right
way
to
do
this,
but
I
like
to
store
the
database
example
I.
Think
it's
also
true
for
a
lot
of
storage
systems.
I.
Can
you
just
imagine
when
you
bind
you
get
your
own
sandbox
like
it,
creates
a
volume
or
a
directory,
or
something
for
you
on
the
NFS
server
or
a
stuff
cluster,
or
something
like
that.
So
that
would
be
a
strong,
compelling
use
case
for
multiple
bindings.
If
you
actually
needed
different
buckets
to
put
data
in.
C
D
B
F
Could
it
seems,
like
the
easiest
you
guys
think
about
this
one
that
is
either
the
database
example,
but
even
something
like
using
like
Google
Cloud
Storage,
where
you
might
have
two
kinds
credentials
that
you
use
for
two
different
pockets
where
you
might
be
able
to
believe
from
one
pocket,
but
not
right
to
the
other
bucket.
Would.
B
B
F
F
A
I,
I'm
going
to
play
the
benevolent
dictator
card
here
as
the
owner
of
the
of
the
zoom
meeting
and
call
out.
We
have
two
minutes
left
before
the
hour.
I
don't
think
we're
going
to
sort
this
out.
Probably
on
this
call.
Let's
I
move
that
we
table.
This
is
something
that
needs
further
exploration
and
tried
to
move
on.
If
there's
any
ground
left
cover
in
the
dock,
I,
don't
know
what
you
guys
did
when
I
step
out
of
the
room
changed.
C
C
C
A
Let's,
let's
keep
that
in
there
I
what
I
would
like
to
wind
up
with
for
this
document
is
curse
by
precise
definitions
of
the
use
cases
and
then
a
detailed
examination
of
each
of
those,
or
we
can
put
this
kind
of
information,
so
I
think
this
content,
that's
on
lines.
110
through
113
is
probably
good.
Contextual
exploration
of
the
of
the
problem
space.
C
A
A
F
F
C
F
A
F
F
C
A
Yeah
I,
don't
I,
don't
even
I've
looked
and
I
haven't,
found
any
kind
of
documentation
of
a
bad
key
rotation,
but
I'm
no
way
in
a
cloud
foundry
expert.
I
would
I
would
love
to
be
wrong
and
say
and
find
out
that
there's
some
like
Nick
or
cranny
of
documentation
that
I
didn't
probe
I,
think
I
threw
this
in
for
kia
rotation,
but
I
didn't
know
if
it
also
applied
to
the
IP
address
of
the
endpoint
updating
yeah.
That's
a
good
point.
I.
A
F
A
C
C
A
Yeah,
so
this
is
about
like
when
what
is
what
is
the
update
story
when
you
have
a
service
that
has
instances
created
of
it,
someone
calls
the
the
brokers
catalogue
endpoint
again
in
the
cloud
foundry
model
and
slurps
in
the
new
service
definitions.
What
happens
to
the
existing
service
instances?
Are
they
updated?
What
happens
right,
yeah.
A
F
C
E
A
I'm,
I
will
say
to
like
we're
five
over
15
minutes
over
the
time
that
we
had
allotted
for
this
I
think
we
are
in
a
good
state
now
and
I'm
I'm.
It's
Edith
see
my
trigger
finger.
It's
itching
to
hit
the
merge
button
on
this
thing,
so
I
I
am
comfortable
calling
it
here
and
we
can
further
refine
this
in
subsequent
full
request
of
everybody
else
remains
on
the
call:
the
current
seat
of
power
in
Cooper
Nettie's
sake,
service
catalog
is
okay
with
I.
F
Think
it's
great
and
I
also
would
like
to
say
that
I
think
this
format
was
very
superiors
and
trying
to
wade
through
the
comments
on
the
github
and
and
what
those
conversations.
So
if
we
can
find
a
way
to
go
ahead
and
replicate
this
experience
will
be
forward.
I
think
at
least
I
found
this
to
be
super
helpful.
So
this
this
is.
A
A
C
Yes,
cool
I,
said
sort
of
a
few
action
items
that
I
gathered.
I'm
going
to
go
ahead
and
run
through
this
again.
We've
got
a
bunch
of
to
do's
all
expand
that
a
little
bit
spans
of
things
there.
I
will
start
the
noun
extraction
into
a
glossary
and
then
once
that
now
an
extraction
has
happened
then
also
grab
all
the
use
cases
for
consistency,
and
then
we've
got
the
actor
fix
up
things.
We
can
do
that
on
a
follow
on
PR
and
that's.
F
A
F
A
F
A
Yeah,
I
hope
so
I
did.
I
would
like
to
continue
talking
about
the
production
end
of
things.
If
we
were
to
meet
again,
I
would
say:
let's
table
all
this
and
let's
talk
about
sharing
services
across
cooper,
Nettie's
namespaces,
in
the
context
of
what
does
that
experience
like
I
think
that's
something!
That's
really
important
to
adoption
of
Cooper
Nettie's
and
a
there's,
probably
a
few
different
permutations,
of
course,
but
you
know
we'll
see
if
that's
possible
I
feel.