►
From YouTube: Kubernetes SIG Service Catalog 20170926
Description
- Cluster ID
- Name of ServiceInstanceCredential resource
A
B
C
C
C
C
C
B
Are
you
done
yeah,
okay,
it
just
raised
my
hand
just
to
give
a
little
bit
of
background
for
why
we
were
did
looking
at
this
issue,
for
those
of
you
may
not
have
been
paying
attention
to
this
particular
side
of
things
in
the
open
service.
Burger
API
specification,
as
part
of
the
context
object
that
we
send,
along
with
each
request.
B
This
request
is
actually
for,
because
there
are
some
environments
where
the
quote
platform
Asst
has
defined
by
the
service
broker,
API,
actually
spans
multiple
kubernetes
clusters
and
so
the
and,
if
the
service
broker
ever
needs
to
reach
back
into
kubernetes
or
the
platform
to
get
something
done,
it
may
need
to
know
which
exact
community's
instance.
This
request
was
specifically
related
to.
B
So
that's
why
we
need
this
unique
identifier
and
we've
been
trying
to
push
this
into,
to
create
score
because
other
people
to
express
an
interest
in
eating
similar
types
of
okay
start
type
of
a
field,
meaning
a
cluster
ID.
But
after
a
long
discussion
at
sega
architecture,
they
decided
well
for
right.
Now,
let's
go
ahead
and
just
let
each
individual
sort
of
part
of
communities
to
find
their
own
cluster
ID.
And
if,
at
some
point
in
the
future,
we
decide
to
harmonize
on
a
single
one.
B
A
A
B
A
A
I
think
there
are
a
number
of
questions
about
the
implementation
of
this.
That
I
have
I,
suggest
you
think
about
how
you're
going
to
ensure
there's
only
one
of
these
things,
which
is
an
API
semantics.
We
don't
have
anywhere
else
and
when
I
look
at
the
section
called
value
and
I
see
string
created
on
startup,
it
doesn't
say
startup
of
what
so?
Is
this
the
controller
manager
making?
This
is
the
API
server
self
bootstrapping,
which
is
another
thing
that
I
don't
think
we
do
so
it's
worth
spending
some
time
going
into
more
specifics
and
I.
A
The
other
thing
that
I'll
mention
is
that
II
I
could
easily
imagine
that,
like
it'd
be
faster,
if
you
need
something
right
now
to
as
a
stopgap,
so
you
can
add
something
to
the
controller
manager.
That's
like
this
is
the
cluster
ID
that
I
want
you
to
send.
I
would
have
no
problem
with
something
like
that
going
in,
and
then
once
this
resource
and
API
grabber
closer
to
fully
baked,
we
can
switch
it
over
or
hide
the
option,
all
that
kind
of
stuff.
A
B
You
had
some
some
questions
there,
but
it
was
more
just
looking
for
some
clarifications.
Is
there
any
objection
to
Morgan's
starting
to
head
down
this
path
and
I
asked
inquiry?
Concrete
decisions
is
yes.
This
is
ultimately
the
design
we
want
to
go
with,
but
rather
let
Morgan
continue
heading
down
this
path
because
it
seems
like
it's,
it
might
be
the
right
direction,
but
we'll
see
how
it
plays
out.
I
I.
C
There
were
a
couple
people
who
were
paying
me:
basically,
they
saw
the
sort
of
document
I
wrote
up
or
they
heard
the
discussion
dug
me
and
whoever
had
with
the
people
in
arch
and
basically
wanted
somebody
to
to
sort
of
create
a
creative
thing
in
the
features
repo
for
41.9
and
I.
Guess
we
gotta
have
to
I'm
not
familiar
much
but
I.
Guess
we
have
to
have
somebody
or
a
cig
or
something
to
to
push
it
or
to
own
it
or
to
do
whatever
the
process
is.
C
A
B
C
A
B
I
was
gonna
say
it
sounds
like
our
time
agree
best
serve
rather
than
trying
to
hash
through
possible
proposals
for
each
of
these
things.
Morgan.
Why
don't
you
take
the
AI
to
come
up
with
some
some
rough
ideas
for
how
to
do
each
one
of
these
concerns,
but
I
think
Paul.
You
would
you're
the
one
that
makes
that
pretty
much
mention
his
last
time
so
Morgan
once
you
take
the
AI
to
come
up
with
some
proposals
for
each
of
these
three
and
then,
when
we
have
concrete
proposals,
then
we
can
actually
discuss
them.
B
E
So
I
had
come
to
realize
just
recently
because
it
admittedly
have
been
kind
of
absent.
Lately.
I
came
to
realize
recently
about
this
name
change
from
service
binding
to
so
this
instance
credential
and
I
thought
it
was
odd,
but
I
just
kind
of
moved
on
I
didn't
care
that
much,
but
then
game
started
complaining
about
it
and
you
know
he's
his
criticisms
of
it.
I
think
are
valid,
but,
besides
being
extremely
difficult
to
type.
The
name
is
also
a
complete
misnomer
in
that
the
thing
that
it
represents
is
not
actually
credential
or
credentials
at
all.
E
It's
a
request
for
credentials-
and
we
already
have
a
word
for
that
in
the
OSB
vernacular
and
that
is
binding.
So
Aaron
and
Gabe
and
I
were
unanimous
on
that
within
Microsoft,
and
we
briefly
discussed
with
Paul
yesterday,
and
he
indicated
that
we
might
not
be
the
only
ones
unhappy
with
that
name.
So
I
asked
that
we
discussed
this
again.
B
Okay,
my
hands
up
so
just
for
some
history,
so
we
switched
from
binding
to
excursion
instance
credential,
because
binding
wasn't
accurate
as
well.
In
the
past,
we
were
trying
to
have
a
single
resource
that
represented
it
I'm.
Sorry
that
represented
the
notion
of
get
me
some
credentials
and
then
each
injected
into
something
so
actually
did
have
this
notion
of
quote
binding
within
it,
meaning
the
action
of
sticking
credentials
into
an
application.
B
A
So
I've
heard
a
lot
about
this
from
folks
that
are
at
Red
Hat
and
in
the
community
and
I.
Don't
think
the
name
is
great
I,
don't
think
it's
easy
to
explain
and
I,
don't
think
I
think
if
we
did
something
like
service
binding,
it
would
be
easy
to
explain
easier
to
explain
more
in
line
with
the
API
and
people
I
think
would
get
it
that,
like
you,
do
the
service
binding
and
then
to
really
use
it
in
your
application.
A
You
make
another
instance
of
another
resource,
so
I
don't
see
that
there's
a
huge
problem
with
like
having
binding
in
the
name,
and
this
is
the
time
to
change
it.
If
people,
if
people
like
do
not
like
this
name,
this
is
the
single
best
and
really
only
time
to
change
it.
So
I've
heard
enough
about
this
from
people
that
when
can't
approach
me
I
finally
said
okay
I've
heard
about
this
from
a
number
of
different
groups:
let's
get
it
back
on
the
agenda.
F
B
Okay
break
my
head
now:
I,
don't
really
have
a
huge
problem
with
going
back
to
some
of
like
service
binding
other
than
I.
Think
it's
gonna
be
really
kind
of
confusing.
If
we
do
introduce,
for
example,
Paul
you
would
suggested
hello,
is
it
tide,
preset
binding
or
something
like
that
right,
I
think
that's
going
to
be
really
kind
of
confusing,
because
never
going
to
two
resources
called
binding
and
only
one
of
them
actually
does
a
binding
I,
don't
believe
most
users
will
understand
the
first
use
of
binding,
meaning.
B
Oh
go
talk
to
the
service
broker
and
get
credentials.
Why
does
that
do
a
binding?
It's
not
actually
binding
to
anything
at
all.
It's
just
asking
for
credentials
and
I,
don't
think
most
who
even
really
will
know
open-source
provides
open
service
broker
ties
even
being
used
behind
the
scenes.
All
they
care
about
is
hook.
My
application
up
to
ascaris
they're,
not
gonna,
understand
OSB
at
all.
So
that's
my
biggest
concern
is
using
the
word
binding.
There
I
think
it's
going
to
be
even
more
confusing
when
we
introduce
the
other
objects
later
on.
B
F
I,
don't
think
those
should
be
called
bindings
at
all,
I
mean
they
just
basically
be
something
like
injectors
or
last-mile
helper.
So
god
knows
what
but
I
mean
their
function
is
very
specific,
which
is
gonna,
be
very
specific
to
a
particular
environment.
I
mean
I
I
had
hoped
that
they
would
be.
The
binding
would
basically
have
some
way
of
you
know
the
the
existing
service
binding
would
have
the
ability
to
be
pluggable,
so
you
could
define
behaviors
meaning.
F
There
was
this
change
to
go
ahead
and
only
introduced
very
low
level
primitives
and
leaving
a
lot
of
a
lot
of
behaviors
unspecified
or
left
us
an
exercise
for
the
passes.
I
guess
to
implement
now
so
I
assume
RedHat
does
something
with
their
findings
and
IBM
does
something
else
with
their
bindings
or
secrets
or
whatever,
but
I
don't
think
they
would
be
bindings
I
think
they
be
something
else.
B
In
that
case
they
call
them
service
keys
right,
so
they
actually
go
off
and
explicitly
from
the
command-line
me
and
user
perspective.
They
say
create
a
service
key.
That's
me
helps
solidify
the
idea
that,
if
wet
that's
really
what
we're
doing
in
our
world
here,
meaning
we're
just
creating
the
credentials.
We
are
not
doing
an
injection
aka
binding
using
the
word
binding.
There
really
isn't
appropriate
and
I'd.
Much
rather
follow
cloud
foundries
leave
in
this
case,
and
you
know
we
don't
like
the
word
service
and
sters
credential,
which
I
agree.
B
It's
a
horrible
name,
then
maybe
call
them
service.
Critters
instance
keys
or
something
like
that,
because
I
think
that
more
accurately
represents
what
we're
doing
here,
but
using
the
word
binding
when
we're
not
actually
finding
anything,
especially
from
an
end
user
perspective,
I
think
is
really
confusing
anyway,
Europe
you
give
me
denied.
Oh
I'm,
sorry
I
didn't
see
you
in
there
weird.
Oh
sorry,
you
scrolled
off
the
top.
Sorry
go
ahead:
Paul
hi,
guys
hi.
F
So
because
creating
one
of
these,
let's
see
creating
a
service
X
where
that
service
X
is
whatever
it
is,
actually
results.
Typically,
in
a
call
to
a
service
service
broker
and
in
the
binding
it
seems
it
seems
fine
to
not
introduce
yet
another
thing
called
service
ski,
but
keeping
it
as
binding.
I
mean
I
had
never
heard
anybody.
While
we
have
been
developing
and
people
using
it
to
come
back
and
saying
I,
don't
understand
what
service
binding
is
all
like
it.
F
E
Iii
would
echo
what
VA
just
said
that
that
I
don't
think
there
really
was
any
confusion
about
what
binding
meant,
but
you
know
if
we
want
to
be
consistent.
You
know
when,
when
we
create
a
resource
of
type
instance,
that
is
reflected
in
the
calls
out
to
the
broker
right,
you
you
make
an
OSP
call
to
create
an
instance.
B
Okay,
I
wanna
try
to
take
some
notes
at
the
same
time,
so
I
think
I'm
up
next,
let
me
know
which
I
can
make
sure
I'm
not
lying
yeah.
So
V
lay
I,
understand
what
you're
saying
but
I
don't
think
it's
necessary
a
fair
analysis,
because
we
don't
have
those
other
resources
in
the
model
right
now,
so
people
only
have
the
notion
of
a
bindings
right.
They
don't
have
the
thing
afterwards.
That
I
claim
is
going
to
introduce
the
confusion,
meaning
another
resource
called
binding
which
actually
does
a
binding
right.
I
mean
yeah.
B
We
could
call
them
injectors
instead
of
bindings,
but
I,
don't
think
that's
necessary
going
to
help
the
case
right
because
wait.
How
do
you
explain
the
word
binding
when
all
you're
doing
is
creating
a
secret?
What
are
you
binding
to?
Where
does
that
verb?
Come
into
play?
Add
I,
don't
know
how
to
explain
that
to
people
so
I'd
love
to
understand
how
you
might
explain
it
other
than
by
saying
service
broker
calls
a
binding
so
feel
a
you're
up.
F
Service
instance,
from
some
thing
and
in
when
I
say
thing,
I'm
being
vague,
because
in
kubernetes
there
is
no
same
concept
to
define
an
application
like
in
a
cloud
foundry
there,
it's
very
clear
where
you
want
to
go
in
those
credentials
from
or
basically
consume
a
service
from.
That's
what
we
are
really
saying
is
I
would
like
to
use
that
service
from
this
thing
and
in
kubernetes
we
don't
really
have
that,
but
the
intent
is
still
the
same,
which
is
which
we
sort
of
kind
of
had
with
the
pod
preset.
F
The
other
part
which
is
the
which
is
the
injection,
is
really
just
the
last
mile
consumption
that
defines
that
is
defined
by
the
what
I
call
the
runtime
environment,
so
the
runtime
environment
in
say,
Cloud
Foundry,
you
know
just
it
is
in
the
environmental
variables
and
you
get
some
stuff
swiped
into
the
environmental
variables
on
on
something
like
Google
App
Engine.
They
also
have
something.
Similarly,
you
can
get
these
things
injected
in
there
as
well
on
kubernetes,
you
know,
they're
the
it's
dealer's
choice
right
now,
right
you
basically
say
well.
F
I
know
this
is
secret
and
I
had
changed
my
pods
back,
but
also
there's
a
lot
of
helm,
charts
or
globe
eyes
or
whatever
else
we're
modifying
the
pod
spec
on
the
disk.
So
to
speak,
it's
not
really
desirable
and
you
would
want
to
go
and
just
define
a
behavior
like
a
decorator
where
you
just
basically
say
well,
you
know
what,
for
these
things,
just
inject
those
things
into
there
and
that's
not
really
a
binding.
It's
just
controlling
your
consumption
model
and
I
view
those
two
things:
that's
very
orthogonal
and
not
binding.
B
A
So
I
wanted
I
want
to
just
like
why
not
here
there
are
two
different
facets.
One
is
that
no
one
seems
to
like
the
name
service
instance
credential,
the
other
one
is
what
should
the
name
be
so
I
think
it's
pretty
clear
from
the
feedback
that
we're
getting
here,
that
we
need
a
better
name.
Does
anybody
disagree
about
that.
E
B
I
kind
of
understand
that,
but
at
the
same
time
we
had
sort
of
a
extra
knowledge
right
in
the
sense
that
we
all
live
with
the
open-source
broker,
API
spec
and
so
we're
kind
of
mixing
those
two
worlds
and
it's
easier
for
us
to
wrap
our
heads
around
these
things.
Right.
I,
try
really
hard
to
look
at
these
things
from
a
strict
end-user
perspective
right
and
III.
B
Knowing
that
we
have
this
other
resource
coming
along
in
the
future,
that's
gonna
be
doing
this
injecting
and
whether
you
want
to
call
it
injector
versus
binding.
It
all
means
the
same
thing
to
me
and
we're
gonna
have
to
resources
with
the
same
type
of
verb
on
them,
and
one
of
them
actually
isn't
doing
that
thing.
I'm
gonna
have
a
really
hard
time
just
to
find
out
the
people
who
aren't
living
and
breathing
with
the
open
servers
broker.
Api
spec
aren't
they
debate
basis,
to
wit
the
same
way.
B
B
B
Let
me
just
say
this:
so
can't
you
right:
it's
not
the
credential,
it's
a
request
for
credential
you're
right
I
mean,
and
you
know,
take
a
look.
We
we
want
to
be
Harper's
inaccurate,
saying
you
know,
service
key
requests
or
a
service.
Credential
request
is
probably
more
accurate
from
a
word
perspective,
I
agree,
Paul,
I,
don't
not
suggesting
we
go
that
route,
but
at
least
it's
not
implying
that
it's
part
of
the
injection
into
an
application,
because
you
may
never
actually
do
that
and
it
doesn't
have
to
be
done.
B
You
could
just
simply
ask
for
the
secret
I
mean
you
can
act,
you
can
simply
ask
for
the
credentials
to
be
created
and
then
export
the
secret
and
take
it
someplace
else.
That's
actually
what
some
people
do
in
the
Cloud
Foundry
world
right
and
and
there's
no
binding
at
all
in
this
entire
process.
So
again
it's
a
it's
a
case
of
we
have
a
verb
on
there
that
isn't
accurately
representing.
What's
going
on.
That's
my
biggest
concern
here
so
anyway,.
B
E
I
just
want
to
put
a
question
to
the
group
which,
which
is
what
what
do
take
kubernetes
out
of
it
completely
for
a
moment
and
just
speak
purely
in
terms
of
OSB.
You
know
what
is
it
that
that
we
believe
a
binding
to
be
because
Villa,
you
used
the
words
earlier
what
I
agreed
with
completely
that
it
was
an
explicit
declaration
of
intent
to
use
something,
and
does
anybody
disagree
with
that
because
I
disagree?
You
disagree
with
that
aspect.
B
I
Paul
I
apologize
for
jumping
the
queue
but
since
he
asked,
I
explicitly
disagree
it
because
of
the
use
case
where
you
can
just
ask
for
the
credentials.
If
you
look
at
the
open
service
broker,
API
spec,
they
encourage
you
to
pass
in
and
app
good
during
the
binding
request.
Right
and
that's
that
I
agree
is,
is
the
intent
to
say:
hey,
I'm
gonna
inject
it
to
this
particular
application.
B
But
if
you
don't
have
an
application
because
you're
not
going
to
you
know
you
don't
have
it
right,
then,
or
you're,
never
going
to
actually
inject
it
into
an
application.
I'm,
not
expressing
intent
to
inject
at
that
point,
I'm
just
asking
for
some
credentials
what
I'm
gonna
do
with
them
later
on.
You
don't
know
if
I
do
anything
at
all,
so.
E
E
App
gooood
is
an
optional
field.
Okay,
so
so
you're
saying
that
you,
okay,
so
you're
saying
that
hypothetically
you
don't
need
to
be
an
application
to
do
fine,
you
just
you,
can
just
submit
a
binding
without
saying
who
you
are
exactly
yes,
but
does
that,
but
does
really
make
it
not
a
declaration
of
intent
to
use
the
thing
it
might
not
be.
It
might
not
be
conveying
who
the
user
is,
but
I
think
the
fact
that
you're
trying
to
obtain
credentials
through
a
process
called
binding
is
still
a
declaration.
B
A
Okay,
so
the
I
think
that
there
is
a
way
to
potentially
make
everybody
a
little
happier,
or
at
least
equally
miserable,
so
for
clarity.
What
we
have
talked
about
these
IV
pod
presets
in
the
future
and
d-cap
services,
for
the
record,
is
to
have
a
another
set
of
resources
where
I'm
going
to
call
this.
A
A
Binding,
have
a
reference
to
this
thing,
and
that
means
you
would
create
this
one,
and
you
create
this
one
and
the
controller
that
backs
the
pod
preset.
For
the
me
cap
services,
my
name
would
watch
would
be
watching
open,
thermos
broker
binding
and
when
that
thing
became
ready,
it
would
start
doing
its
work.
So
what
I'm
thinking
to
myself
is
that
maybe
we
can
we
can
change
the
formula
a
little
bit
so
that
and
just
for
clarity
it'd,
be
super
super
extra,
clear
beyond
my
ordinarily
high
level
of
clarity.
A
Aha
so
say
that
to
forget
about
this
one
for
now
say
that
when
you
create
a
planetary
set
by
name
as
part
of
concept,
findings
back
similar
to
how
kubernetes
deployments
contain
the
pod
complete
or
pod
comes
the
ads
pod
can
place
so
what
it
positive
reset
finding
had
a
service
key
template
and
instead
of
creating
this
once
any
create
this
one.
What
if
you
create
this
one
and
the
controller
step
backs
this
one?
The
pipe
reset
line,
name.
A
These
might
be
the
same
API
server.
They
might
not
be
definitely
matter.
I
think
that
we
need
to
allow
people
to
build.
We
need
to
allow
them
be
able
to
build
outside
service
catalogs.
So,
let's
assume
the
difference.
So
this
controller,
when
it
sees
the
pod
preset
binding
it
created,
it
actually
creates
this.
A
A
A
Is
we
got
some
feedback
from
the
community
that
said
that
a
lot
of
people
aren't
interested
in
pod
preset?
They
don't
want
pod
presets
coupled
the
Service
Catalog
a
random.
They
don't
want
service
kind
of
like
coupled
to
pod
presets,
and
we
also
at
the
same.
You
know
around
the
same
time
we're
getting
feedback
that
other
people,
other
parties
in
the
community,
wanted
to
build
other
types
of
integrations.
A
So
the
idea
for
removing
the
pod
preset
fields
from
what
was
called
at
the
time
the
binding
resource
was
that
we
would
make
the
Service
Catalog
API
group
exclusively
focused
on
the
like
the
the
nucleus
of
what
you
need
to
interact
with
open
service
broker
API
and
for
integrations
like
pod,
presets
or
the
cap
services.
We
would
build
other
resources
outside
the
Service
Catalog
API
group,
maybe
there
in
our
API
server,
maybe
they're
not
that
would
handle
this
other
integrations.
Does
that
make
sense
to
you,
Ken,
Kent,
sorry,
yeah.
E
A
A
The
community
is
still
interested
in
pod
preset
as
a
mechanism
for
consuming
these
things,
but
it
became
pretty
clear
from
community
feedback
at
one
point
that
embedding
the
details
of
the
pod
preset
indirectly
into
the
resource
that
represented
the
open,
serviceworker
binding,
wasn't
the
right
formula
and
a
fair
amount
of
people
seem
to
have
objections
to
it.
So
it's
basically
the
same
type
of
behavior
that
we
had
always
discussed
visa
upon
preset
in
sirs
catalog,
just
in
a
different
resource.
B
F
F
Cloud
Foundry,
when
those
credentials
get
created
today,
the
unit
of
injection
is
names
babes
of
user.
A
unit
of
consumption
is
the
namespace.
We
are
basically
saying
that
these
credential,
please
give
me
some
credentials
for
a
particular
service
instance
and
I
will
use
them
from
the
namespace.
That's
what
we
are
saying
today
right
with
the
creation
of
the
credential,
so
we
do
have
a
consumer,
it's
not
just
any
credentials
and
they
are
not
existed
anywhere
or
they
are
not
available
for
consumption.
B
Okay,
so
my
hands
up
next
so
I
with
the
wording
you
use
V
lay,
isn't
quite
the
wording.
I
would
use,
but
I
understand
what
you're
saying
I.
Don't
miss
I
disagree,
you're
right
that
the
secret
is
created
into
a
namespace
and
it's
gonna
and
the
secret
is
scoped
to
that
namespace,
but
I
think
I
think
Kent's
question
about
you
know
what
the
heck
is.
A
pod,
preset,
binding,
thingy
I
think
that's
a
really
good
one
to
make
sure
everybody
level-set
here.
So
yes,.
F
B
Right,
which
is
just
you
know,
admit
to
be
lays
right
and
just
move
on
I
agree,
but
because
we
have
10
more
minutes,
we're
gonna
keep
going
so
so
Ken
again
more
history.
Here
you
are
correct
that
when
you
create
a
set
of
credentials,
those
credentials
are
put
into
a
secret
and
those
secrets
are
that
secret
lives
in
a
namespace
and
that
yes,
people
are
then
free
to
use
that
that
secret.
However,
they
choose
to
the
same
way,
they
can
use
a
secret
today,
however,
many
moons
ago,
we
decided
that
G.
B
Wouldn't
it
be
nice
if
people
could
inject
these
secrets
into
their
application,
mean
their
pods
without
explicitly
having
to
modify
all
their
spod
definitions
right
and
that's
where
we
came
up
with
the
pod
presets,
which
allows
you
to
say
created
a
brand
new
resource
called
the
pod
preset
and
say
for
these
pods
over
here
using
the
label
selector
inject
this
secret,
and
that
way
you
don't
have
to
modify
your
pod
spec
anywhere
right
that
that
pod,
preset
innocence
does
the
injection
for
you
automatically
under
the
covers?
Okay,
and
what.
C
B
How
I'm
sorry
say
it
again?
It
doesn't
how
it
basically
had
in
it
a
mission
controller
that
that
then
notice
the
spec
of
the
pod
spec
coming
through
the
system.
Is
that,
oh,
by
the
way,
I
was
a
pod
preset
that
wants
to
modify
this
guy
based
upon
labels
and
it
tweaked
it
under
the
covers.
For
you
automatically
sorry.
E
B
It
write
it
in
the
same
way.
You
can
tell
it
how
to
inject
secrets
into
your
pod,
like
modified
pods
back
it
up,
teetered
to
decide
that
the
pod
preset
allowed
you
to
mount
them
as
volumes
inject
them
environment,
variables,
I,
don't
member
had
all
the
various
options,
but
at
least
I
had
those
two,
and
if
we
people
wanted
more,
we
were
going
to
add
more.
B
B
Key
I
think,
but
I
think
it
I
think
is
proposing
something
similar
to
what
we
had
in
the
past
and
and
it's
because
of
all
these
various
sort
of
moving
parts.
I
want
to
make
sure
we
get
the
verb
and
the
words
right
on
these
things,
because
you
know
pod
preset
could
have
been
called
binding
in
my
opinion,
because
that's
really
what
it's
doing,
what
we
call
the
pod
preset
instead
right,
but
that's
why
I'm
very
concerned
about
what's
going
to
come
on
the
next
round?
We
start
introducing
words
that
actually
do
mean
binding.
B
A
A
B
What
I
would
recommend
and
I
agree
with
you?
What
I
would
recommend
is
that
on
tomorrow's
call,
people
presents
their
options.
They
would
like
people
to
consider
because
I've
heard
at
least
3
different
options
on
this
call.
I
heard
call
it
service
key.
Instead,
I've
heard
call
it
service,
binding
and
I
heard
your
pipe
reset
with
service
key
template
thing
embedded
under
that
camera.
Without
matter,
most
call.
B
Ok
seriously
so
I'd
like
to
have
on
tomorrow's
call,
people
present
the
options
and
then
give
people
a
day
to
think
about
it
and
then
I
guess
on
Thursday
vote.
Does
that
sound?
Ok,
because
I,
don't
I,
don't
think
we
want
to
rush
into
this
decision.
So
I
think
it's
fair
to
give
people
a
day
to
think
about.
What's
gonna
get
presented
to
them
tomorrow
in
terms
of
list
of
possible
ideas,
so
Paul
I
think
your
hands
up.
Is
that
it
again
or
is
that
old,
Paul?
F
So
before
we
do,
the
voting
I
would
like
us
to
at
least
agree
on
what
we
think
the
service
XYZ
is
representing,
which
is
why
I
was
trying
to
go
back
to
Ken's
point,
but
we
kind
of
went
back
and
forth
on
sort
of
kind
of
what
is
it
because
there
was
like
I,
think,
Doug
or
Paul
said?
Look
when
you
create
a
service
binding?
Let's
call
it
service
binding
in
the
kubernetes.
It
doesn't
do
anything.
F
It
just
makes
the
request
and
and
and
I'm
arguing
that
that
is
not
true,
because
it
actually
does
do
the
same
equal
to
as
it
does
on
Cloud
Foundry.
It
just
doesn't
stop
them
in
the
environmental
variables
it
fetches
the
credentials
and
stuffs
em
into
secrets.
So
at
least
before
we
do
the
boat,
we
should
all
agree
on
what
we
think
it
does
versus
what
we
think
it
may
or
may
not
do.
F
B
B
Okay,
so
what
I'd
like
to
propose
is
that
tomorrow,
people
come
with
their
brilliant
ideas
for
people
to
consider
and
delay.
Can
you
lead
the
discussion
tomorrow
on
what
you
just
said?
You
know
try
to
get
agreement
on
what
we
think
is
going
on
without
yeah
I,
guess
getting
bogged
down
by
the
names.
Is
that
what
you're
trying
to
look
for
yeah?
B
B
F
Like
no,
no,
no
so
I
basically
put
this
there
is
that.
Does
that
give
clarity,
I'm
saying
is
I,
don't
want
to
I,
don't
want
this
to
be
I.
Don't
want
this
to
be
a
discussion
and
what
should
be
renamed.
The
service
instance
credential,
thingamajig
or
II,
but
it
should
be.
What
should
this
thing
be
called
and
that
thing
we
need
to
understand
what
it
represents
before
we
can
name
it.
That's
what
I
am
after
Paul
use
your
legal
words
here.
B
F
B
A
F
A
Parenthesize
all
of
what
you
said
and
that's
what
it
represents.
We
are
out
of
time
to
start
reassessing
this
stuff.
I
think
the
only
the
only
question
is
is:
what
is
the
right
name
for
that
concept?
Does
anybody
disagree
that,
like
the
purpose
of
this,
seems
to
be
very
clear
to
me?
Is
it
not
as
clear
to
everybody
else
so.
B
E
So
palta
to
answer
your
last
question:
I
I
think
what
a
binding
is
or
whatever
we're
gonna
call.
It
he's
clear
to
me
and
to
expand
on
what
relay
say
vilius
at
last.
He
said
it's
not
just
a
request,
or
earlier
he
was
using
the
the
words
declaration
of
intent.
He's
saying
it's
more
than
that,
because
you
you
also
get
back
you
you
get
credentials
injected
into
a
secret
as
the
the
response
right
and
I
think
what
might
be
useful
to
everybody
is
I
actually
had
to
explain
yesterday
to
a
Microsoft
p.m.