►
From YouTube: Kubernetes SIG Service Catalog 20170927
Description
- Renaming ServiceInstanceCredential
- Names of cluster-scoped resources
A
B
All
right
so
just
to
remind
everybody,
especially
for
the
folks
who
might
be
new
on
the
call,
if
you
want
to
speak,
just
go
to
do
plus
and
or
something
similar
in
the
chat,
so
you
can
get
on
the
speaker's
queue.
Let's
see
short
agenda
today,
Kent
you're
up
first
continue.
The
discussion
from
yesterday
yeah.
C
So,
just
for
the
benefit
of
anybody
who
wasn't
here
yesterday,
we
started
having
a
discussion
or
perhaps
a
rehash
of
a
previous
discussion
about
the
naming
of
a
particular
resource.
That
resource
is
the
one
that's
currently
named
service
instance
credential,
it's
a
name
that
is,
it
seems
universally
loathed
and
does
not
make
a
tremendous
amount
of
sense
and
that
it
may
be
a
misnomer.
C
We
had
a
lot
of
discussion
about
it,
a
lot
of
bike
shedding
about
it
yesterday
and
we
decided
that
we
were
going
to
put
it
to
a
vote
once
again
after
having
some
time
to
all,
consider
and
discuss
amongst
ourselves.
I
know
some
conversations
happened,
offline
between
various
people
and
some
people
may
have
a
new.
What
new
perspective
on
on
this
and
I
don't
have
too
much
else
to
say
about
it
today
unless
valais
has
anything
to
say
because
it
is
on
the
agenda
here.
C
D
Belay
you're
next
Nick,
you
sure
so
the
previous
hand
was
there
because
I
was
hoping
to
introduce
Scott
who
has
joined
the
group,
but
maybe
we'll
come
back
to
it
in
just
a
little
bit
but
yeah.
So
I
kind
of
feel,
like
I,
tried
to
go
ahead
and
convey
yesterday
during
the
meeting
that
one
of
the
we
seem
to
sometimes
focus
a
little
bit
on
what
is
happening
behind
the
scenes,
which
is
great
mechanically,
as
in
a
call
is
made
and
so
forth.
D
But
really
what
the
binding
is
representing
in
the
original
sense
of
the
the
spec.
It
is
that
it
is
represented
as
a
service.
Binding
represents
a
an
explicit
using
or
consumption
of
a
service
instance
from
an
application,
and
because
we
don't
have
one,
we
don't
really
have
a
notion
of
an
application
in
Cooper.
Maybe
a
namespace
as
a
consuming
application
seems
just
fine
and
dandy.
Semantically
speaking.
D
B
I
guess
to
just
her
falls
on
with
what
he
was
saying
there
it's,
he
was
promoting.
Basically
the
idea
that
a
Service
Catalog
his
job
should
stop
at
the
time
we
create
the
secret,
because
at
that
points,
taking
a
secret
and
ending
it
or
doing
something
else
with
it
is
basically
back
in
the
realm
of
normal
kubernetes
operations.
And
so,
if
you
look
at
it
from
the
perspective,
then
naming
this
resource
that
we're
talking
about
service
binding
where
the
binding
isn't.
This
will
be
namespace.
B
It's
something
I
can
buy
into.
That
seems
like
a
reasonable
thing.
To
think
of
my
only
caveat
if
we
choose
to
head
down
this
path,
is
that
we
get
agreement
that,
if
later
on,
we
choose
to
create
additional
resources
that
one
or
not
call
bindings,
because
I
think
two
things
with
its
name
is
gonna,
be
confusing
and
two
they're
viewed
as
generic
kubernetes
resources
to
manipulates
secrets
and
pods
or
mint
or
whatever
the
point
of
these.
B
These
utilities
is
they're,
not
Service,
Catalog
specific
there
there
to
help
you
take
the
output
of
service,
catalog
Nagant
secret,
and
to
do
something
with
them
later
on.
For
some
purpose,
the
reason
I
say
that
is
because
I
think,
if
we're
gonna
bind
to
the
rule
that
says
service
catalogs
job
stops
at
the
time
the
secret
is
created
and
that's
fine.
But
that
means
any
steps
after
there
are
generic
kubernetes
actions
and
we
may
create
some
helper
utility
resources
in
service
catalog,
but
they're
not
really
service.
B
A
Think
that
there
is
going
to
be
a
need
for
other
resources
that
watch
for
service
catalog
resources
to
become
ready
that
are
not
part
of
the
service
catalog
and
I,
like
the
naming
we
can
figure
out,
like
whatever
naming
we
need
to,
but
I,
don't
think
that
we
should
prevent
to
say
we're.
Never
gonna
make
resources
in
this
sig
that
even
watch
the
service
catalog
resources.
This
seems
a
little
may
be
premature
to
do
that.
I.
D
I
was
gonna,
go
and
say:
yeah
I
think
thanks
Doug
for
elaborating
a
little
bit
more
on
one
circle
on
what
we
talked
about
and,
as
usual,
putting
it
so
eloquently.
But
yes,
so
kind
of
my
gut
feeling
has
been
that
once
the
secret
has
been
created
and
once
it
means
he
munched
into
something
else,
a
it
is
just
normal,
kubernetes
stuff
and
its
face
its
face
by
anybody
else,
and
there
is
not
in
service
catalog
specific.
There.
D
Second
point
is
I
I
agree
with
both
Doug
and
Paul,
in
a
sense
that
yeah,
we
should
not
be
just
really
creating
things
that
are
just
different
kinds
of
bindings
on
one
hand
and
on
the
other
hand,
we
should
also
make
sure
that
we
cannot
say
that
we
will
never
ever
ever
create
something
called
with
the
name
binding
in
it
either,
but
I
think
Paul.
What
you're
talking
about
is
what
I
described
it
with
Doug
yesterday
more
of
a
helpers
or
utilities.
D
That
would
be
something
where
you
basically
define
some
kind
of
strategy
or
policy,
or
someone
like
that,
and
you
say
okay
well
in
Service
Catalog.
We
might
have
a
way
to
go
ahead
and
make
it
super
easy
to
go
ahead
and
take
these
secrets
and
stuff
them
into
environmental
variables
under
vcap
name
or
something
like
that,
but
it
would
be
operating
on
normal
kubernetes
things
and
it
would
not
be
something
service,
catalog
specific,
wherever
possible.
D
B
Thank
you
yes,
so
Paul
to
your
comment,
I
think
I
agree
with
you,
I'm
not
saying
we
shouldn't
ever
create
new
resources,
even
ones
that
watch
our
stuff.
It's
in
my
mind.
The
way
I'm
kind
of
thinking
of
it,
though,
is,
is
that
when
you
want
to
create
a
secret
that
contain
service
credentials,
there's
really
going
to
be
only
one
way
to
do
that,
and
that's
the
service
binding
thing.
Assuming
we
go
with
the
name
service
binding.
B
Obviously,
yes,
I
agree.
We
should
be
able
to
create
additional
resources
later
that
either
watch
for
secrets,
like
you
created
or
Wow
much
for
the
server's
binding
to
say
it's
dub
is
done
and
then
taking
some
further
actions,
but
they're
more
that
has
believed
I
said
they're
helping
utilities
to
take
the
next
couple
of
steps
after
the
secret
is
created.
What
I
would
like
to
avoid,
at
least
this
my
current
mindset
anyway,
what
I'd
like
to
avoid
its
notion
of
creating
a
different
flavor
of
template
or
a
different
flavor
of
binding?
B
That
has
a
template
kind
of
like
what
we
used
to
have
and
right.
You
know
I,
like
the
separation
that
we've
established
right
now
and
I'd
like
to
sort
of
make
sure
we
keep
going
on
down
that
path.
That
says,
we
have
one
thing
that
creates
a
secret
if
you
wanna
do
something
else
with
the
secret
or
multiple
Secrets
look
later
great,
but
a
different
resource.
We're
not
going
to
try
to
head
down
that
path.
We
were
before,
where
we're
gonna
start
munging,
multiple
semantics
into
one
resource
yeah,
that's
the
way.
C
You
know
you,
you
could
use
service
catalog
as
it
exists
today
without
using
all
of
those
future
pieces
that
that
we
may
build
and
that
whatever
you
know
things
that
we
graft
onto
this
for
the
sake
of
convenience
to
to
take
you
from
okay,
I
have
a
secret
to
actually
doing
something
with
that
secret.
You
know
other
than
the
manual
things
that
you
might
do
today.
C
You
know
if
we
want
to
graph
something
like
that
on
I'm,
not
convinced
that
that
that
the
creation
or
the
potential
creation
of
those
things
has
any
bearing
on
the
on
how
we
choose
to
name
things.
Indeed,
the
core
of
the
sig,
if
you
will
so
I
mean
I
I,
don't
think
as
a
for
instance,
to
make
this
a
little
more
concrete.
I.
C
Don't
think
that
we're
going
to
be
confusing
anybody
by
having
something
like
service
binding
in
the
current
namespace,
while
or
sorry
in
the
current
API
group,
while
having
something
like
pod
preset
finding
in
some
future
hypothetical
API
group
I,
don't
think
that
that
there
I
don't
see
any
inherent
confusion
based
on
the
fact
that
they
both
have
binding
in
the
name.
I
think
that
people
are
smart
enough
to
wrap
their
heads
around
this
stuff.
C
A
Very
similar
things,
so
let
me
say
some
make
some
things
explicit
as
far
as
my
overriding
philosophy
about
all
this,
so
one
I
do
not
think
there
should
ever
be
another
resource
that
I
do.
That
is
backed
by
a
controller
that
does
a
bind
operation.
I,
think
that
should
be
the
exclusive
province
of
the
resource
that
we're
talking
about.
A
My
third
point
is
developers
going
to
develop
and,
like
probably
somebody
will
come
along
if,
if,
if
the
community
finds
the
work
that
we're
doing
here,
compelling
which
I
think
we
have
good
reason
to
believe
they
will.
We've
got
a
very
significant
amount
of
interest
in
this
project
already
and
I
know
that
we
have
a
lot
of
different
vendors
present
here
that
are
going
to
be
delivering
this
to
the
at
some
point.
A
Think
that
will
probably
wind
up
with
like
a
Venn
diagram
type
thing
of
like
you
know,
just
looking
at
who's
present
here
today,
I
see,
we've
got
people
from
google,
we've
got
people
from
IBM,
we've
got
people
from
Red
Hat
we've
got
a
zoom
client.
That's
incredibly
misbehaved
and
will
take
over
my
screen
every
second,
when
I
try
to
minimize
it,
which
is
currently
doing
and
why
I'm
working
this
ever
so
subtly
into
my
narrative.
But
we
have
a
lot
of
different
vendors
present.
A
They
have
overlapping
interests,
not
everybody's,
going
to
be
interests
interested
in
the
same
types
of
integrations
and
when
we
get
to
the
point
where
we're
building
these
utilities
I
think
to
some
extent
we
need
to
let
the
people
that
are
interested
in
their
integrations
build
them,
whether
it's
in
this
repository
or
in
another
one,
but
I,
think
the
problem
that
we're
dancing
around
here
and
I'm.
Sorry
I've
been
so
long-winded.
A
The
zoom
client
digression
really
cost
me
a
lot
of
words,
but
whatever
the
key
that
were
we're
dancing
around
here
is
that
we
want
to
build
the
right
building
blocks
and
we
want
to
constrain
complexity
and
I.
Think
we're
all
talking
about
the
same.
With
regard
to
those
things.
Does
anybody
disagree.
B
D
Yeah,
so
I
was
basically
going
to
go.
I,
say
I.
Think
if
there's
no
disagreements,
I
think
we
all
good
with
with
the
notion
I
hear
saying
different
ways.
The
same
thing
yes,
I
mean
it
seems
to
me
like.
We
are
basically
saying
well,
okay,
we're
gonna
slap.
The
secret
names
place,
that's
a
good!
We
all
agreed,
that's
what
we
need
to
do.
We
are
doing
the
binding
guess,
it's
manically
makes
sense,
let's
call
it
service
binding.
So
do
we
need
to
do
anything
more
okay,.
B
B
Okay,
so
I
believe
the
current
proposal
in
front
of
us
is
to
rename
service
system
credential
to
serve
as
binding.
Does
anybody
think
they
need
more
time
to
think
about
this,
or
are
we
located
to
basically
make
a
decision
right
now,
because
a
lot
of
times
for
big
decisions
like
this,
we
let
people
have
a
day
if
they
want
it,
anybody
need
more
time.
Okay,
let's
take
the
easy
path.
First,
is
there
any
objection
to
renaming
it
service
binding
or
raise
your
hand,
windows
Oh
once
done
there
you
go.
B
B
A
I
think
whoever
whether
it's
me
belies
somebody
else,
I
think
that
there
are
a
number
of
very
critical
and
important
polls
that
should
be
merged
first.
So
what
I
suggest
is
that
II
I
think
there's
that
Matt
few
stapler
has
a
pole
for
the
in
progress
parameters
and
the
and
Jeff
peeler
has
one
for
orphan
mitigation
for
bindings.
Let's
go
ahead
and
get
those
merged
first,
because
that's
gonna
be
a
rebase.
That
is
not
fun
and
is
everybody
cool
with
that
I
just
I?
A
Don't
we
have
a
lot
of
people
touching
a
fairly
small,
codebase
and
I
I
think
we
should
get
the
impress
things
done
before
we
do
a
rebate.
We
renamed
these
resources.
Everybody
quote
that
and
I
also
think
those
poles
that
I
referenced
are
both
fairly
close
to
completion.
So
maybe
give
it
a
couple
days:
hey.
B
D
I
just
wanna
make
sure
that
you
say
that
you
want
to
wait
a
couple
of
days
before
doing
this
or
I
mean
I
would
like
to
go
ahead
and
basically
propose
that
we
tried
the
cram
all
of
these
seals
in
today.
If
possible,
I
mean
I.
Looked
at
some
of
them
made
a
comment
and
I
know
it
was
addressed.
I
think
it
was
Jeff
a
addressed
and
it
was
fine
and
I
think
it's
good
to
merge.
D
E
B
All
right
cool,
any
other
comments,
questions
all
right.
Moving
on
so
as
I
was
saying,
there's
a
nice
show
up
there,
1200,
which
talks
about
creating
a
namespaced
version
of
service
broker
service
clause
and
service
plan,
because
there
are
use
cases
where
people
would
like
those
two
types
of
resources
to
be
scoped
to
a
namespace
and
not
global
and
I'm,
not
suggesting.
We
do
that
now
for
beta
right
like
that,
but
rather
when
we
do
think
about
doing
that
in
the
future,
one
of
the
things
I
think
Paula
suggested
was.
B
We
may
do
something
as
simple
as
prefix
those
resources
with
the
word
local,
so
that
people
understand,
there's
a
service
broker
and
then
there's
local
service
broker,
where
a
local
service
broker
means
the
one
that
scoped
to
a
namespace
which
something
like
that
seems
perfectly
reasonable.
So
if
we
do
that,
though,
there's
a
problem,
our
current
service
instance
doesn't
have
the
prefix
local
on
it.
If
yet,
it
is
scoped
to
a
namespace
and
I
know.
At
least
IBM
has
a
use
case
where
we
want
a
global
service
instance
that
isn't
tied
to
a
particular
namespace.
B
So
what
I?
Like
people
to
think
about
I'm
not
going
to
push
for
vote
notes,
I
think
we
need
to
think
about.
It
is
I'd
like
be
able
to
think
about
whether
we
should
prefix
or
name
service
instance
to
local
service
instance.
That
way,
we
don't
have
to
worry
about
renaming
something
post
beta,
because
renaming
post
beta
it
could
mean
bumping
to
another
version
which
is
not
gonna,
be
good,
but
I
want
to
put
that
idea
out.
A
A
Well
sorry,
most
of
the
kubernetes
clusters
that
enable
our
back
ordinary
users
typically
do
not
have
access
to
to
work
with
global
objects,
and
so
I
think
that
the
default
for
an
end
user
is
going
to
be
like
my
service
instances
are
in
my
namespace
I
I'm,
also
not
immediately
sure
that
I
think
that
global
service
instances
are
a
the
right
way
to
accomplish
a
service
instance.
It's
globally,
usable
and
so
I.
A
I
am
very
curious
in
knowing
like
particulars
about
the
use
case,
which
maybe
we
can
discuss
later,
but
I
think
as
far
as
like
what
most
users
interact
with
a
service
instance
is
going
to
be
the
best
name
for
them.
Just
my
two
cents.
Having
heard
about
this
for
I
guess
maybe
10
minutes
since
I
saw
it
on
the
agenda.
B
Yeah
so
I'll
work
on
trying
to
get
a
write-up
on
some
of
these
cases,
the
one.
Unfortunately,
my
memory
is
on
its
way
it
should
be,
and
the
one
that
really
stands
on
our
mind.
That
I've
heard
from
our
guys
is
something
a
long
lines
of
they
need
to
create
like
a
DevOps
type
of
service
and
that
it's
not
necessarily
tied
to
a
namespace.
It's
more
global
within
the
cluster,
but
I'll
try
to
get
more
details
to
talk
about
that,
but
what
I
really
raise
my
hand
for
is
sort
of
the
flip
side
of
it.
B
I
think
you
yourself
even
mentioned
that
you
might
have
use
cases
where
service
brokers,
maybe
namespace,
specific
or
service
classes,
some
of
the
resources
right.
So
I'm
kind
of
curious
thinking
about
it.
From
the
you
know,
the
crude
way
of
doing
things.
How
would
you
recommend
we
differentiate
between
by
a
Google
full
service
broker?
Bors's
namespace
service
broker
would
be
the
right
cool
way
to
do
that.
Differentiation
so.
A
B
D
I
was
going
to
also
say
that
I
do
we
ever
envisioned
there
being
a
need
to
go
cross
clusters
but
being
able
to
go
and
consume
services
between
clusters?
I
don't
go
and
open
this
up
for
too
long
there,
but
it's
just
you
know
this-
that
cross
namespace,
what
systemic
one
and
and
and
cross
clouds
and
and
whatnot.
B
A
B
C
B
A
B
A
Share
the
screen:
he
must
share
the
screen
and
show
this
milestone,
because
his
I
I
think
this
must.
This
behavior
of
zoom
must
be
initiated
by
the
client
that
is
sharing
the
screen,
because
Morgan's
client
in
particular,
is
especially
grabby
about
my
screen
and
I.
Don't
think
that
that
is
something
that
has
to
do
with
Morgan's
personality
I.
Think
it's
the
version
of
the
client
that's
installed
on
his
computer.
A
F
Yeah,
it's
pretty
far
along
I,
mean
I,
think
the
bulk
of
like
the
logic
stuff,
is
done
in
the
process
rebasing
and
some
preparations
for
or
for
for
mitigation
PRS
that
are
pending
and
getting
that
in
line
with
the
work
that
I've
done.
But
that's
that's
pretty
close
to
being
ready
to
leave
with
you.
Okay,.
A
A
It
basically
doubles
the
memory
consumption
in
the
API
server
and
so
I
wonder
if
people
would
be
comfortable
moving
this
out
to
an
O
dot
1.1,
because
I
don't
think
that
we
need
to
gate
Oh
dot
1.0
on
it
and
I
also
know
that,
like
since
we're
going
to
be
we're
basically
releasing
a
micro
service,
that's
installed
in
kubernetes
that
I
think
that
users
will
be
able
to
iterate
pretty
rapidly
once
we
have
new
releases.
So
I
don't
know
that
this
should
block
o
dot
one
dot
o.
A
A
Okay,
well,
I
can
think
of
one
thing,
so
the
the
the
reason
that
this
is
is
in
the
long
term.
Important
to
us
is
that
there
is
a
experimental
feature
in
cube.
Ctl
that
lets
the
open.
Api
is
served
by
two
open
API
or
served
by
an
API
server,
tell
cube
CTL
what
columns
it
should
display.
So
this
is
probably
important.
Well,
this
is
important
for
us
to
have
in
the
long
term,
for
user
experience.
A
A
Assumes
that
there's
only
going
to
be
a
single
image,
so
I
am
hoping
that
maybe,
if
I
have
a
spare
hour
or
two
I
can
I
can
make
a
single
binary
that
has
the
both
sets
of
code
in
it.
That
does
the
classic
UNIX
binary
trick
of.
If
you
call
me,
API
server
I'm
an
API
server.
If
you
call
me
controller
manager,
I'm
a
controller
manager
or
we
can
have
sub
commands,
whatever
I'd
like
to
get
this
one
done.
A
I
don't
have
a
incredibly
strong
opinion
about
it,
but
it
would
be
very
convenient
for
us
at
Red
Hat.
If
we
did
this
and
I
think
it's
better
for
users
to
I
know.
At
least
one
person
in
the
last
week
has
come
to
me
with
an
issue
that
wound
up
being.
They
were
running
an
API
server
that
was
at
a
date
relative
to
the
controller
manager.
A
Okay,
next
one
is
our
back:
resources
in
helm.
Chart
will
need
to
be
updated
for
kubernetes
one,
eight,
that's
actually
not
strictly
true
kubernetes.
One
eight
supports
the
v1
beta1
API
version
of
our
back
I
think
we
could
get
away
with
that
that,
but
it's
also
fairly
easy
change.
If
somebody's
interested
in
making
a
contribution,
I
can
talk
to
you
about
how
to
do
that.
One
any
takers.
A
B
A
A
A
A
A
D
A
735
yeah:
let's
go
if
someone's
gonna
do
this
I
think
it
really
needs
to
get
done
in
like
the
next
week
or
it
needs
to
slip.
Yep
yep
and
this
one
scope
of
initial
beta
release
1098.
Can
we
close
that
with
no
action
I
mean
we
know
it?
What
that
one's
gonna
be
yeah?
That
was
more
like
a
placeholder
for
discussion
anyway.
Right,
alright
feel
free
to
go
ahead
and
close
that
one
Morgan,
while
you're
in
there.
A
B
G
D
So
the
one
thing
while
I
was
looking
at
the
admission
controller
for
the
things
there's
couple
of
times
and
through
all
the
like
service
classes
and
basically
crept
through
the
name
so
I
think
there's
some
places.
We
can
be
smarter
about
things
and
now
that
the
label
and
field
selectors
are
in
there,
we
should
be
able
to
utilize
those.
But.
D
A
A
A
A
Know
I've
been
thinking
about
that
one
today,
I
will
make
an
issue
after
this
and
I
think
we
can
probably
close
out
the
update
semantics
thing,
but
I'll
handle
that
later
on
when
I'm,
when
I'm
doing
this
stuff
and
actually
think
that
one's
pretty
easy.
So
I
might
just
cut
that
one
up
tonight,
because
I'm,
a
really
cool
guy,
we'll
see.
A
Ok,
so
I
think
it
sounds
like
we
have
a
couple
things
that
represent
open
questions.
We
have
almost
everything
else
in
progress
and
we
have
some
very
small
minor
things
left
to
do
afterward
by
the
way.
In
case
anybody
missed
this
in
the
chat.
We
would
probably
have
a
have
a
an
issue
that
said,
make
sure
make
sure
kubernetes
namespace
termination
correctly
handles
all
the
stuff
but
I
tested
that
and
it
works
yay.
A
So,
in
terms
of
in
terms
of
excuse
me,
what
can't
the
question
can't
ask
when
what
kind
of
timeline
are
we
looking
at
I
would
say
that
one
week
from
today,
I
think
that
it
seems
like
we
should
be
able
to
be
feature
complete
by
then
and
probably
bump.
The
API
I
think
that
it
would
be
prudent
to
have
a
another
week
after
that,
that
is
like
code
freeze
and
people
can
test
and
use
the
new
API
version
before
we
cut
the
initial
beta
release.
How
does
that
sound
folks.