►
From YouTube: Kubernetes SIG Service Catalog 20170712
Description
Design meeting:
- Secret Parameters
- Are ServiceClass and ServicePlan different resources?
- Binding vs. PodPreset
A
Welcome
everybody
to
the
Wednesday
July
12
2017
special
edition
meeting
of
six
Service
Catalog.
Today
we're
going
to
be
talking
about
which
issues
we
feel
are
required
for
bringing
the
Service
Catalog
to
a
beta
level.
So
Aaron
is
going
to
share
his
screen
and
has
generously
volunteered
to
to
take
notes.
I
will
be
honest
with
everybody.
I
have
not
had
a
single
moment
to
go
through
any
of
the
issues,
so
I
suspect
also
that
the
the
other
folks
present
on
the
call
have
not
had
a
chance
to
go
through
every
single
issue.
A
I
suggest
that
as
a
formula
for
this
meeting,
which
I
doubt
that
we
will
be
able
to
successfully
go
through
everything
in
a
single
hour
and
I'm
very
happy
and
interested
in
having
another
one
of
these
either
tomorrow
or
on
Friday
as
necessary
to
reach
a
conclusion.
Let's
just
talk
about
issues
and
we
can
get
a
read
of
whether
people
feel
they
are
necessary
for
beta.
Does
anybody
have
a
better
idea,
so
I.
B
Went
through
and
as
I
said
last
time,
I
tried
to
categorize
things.
I
did
put
the
top
three
issues
that
I
thought
were
either
either
very
critical
or
at
least
have
concrete
proposals
for
us
to
discuss.
Let's
have
a
listen,
I
was
assuming.
We
were
not
going
to
get
past
the
first
three
today
Breanna,
okay,.
A
B
A
And
the
salient
point
about
this
is
that
we
will
not
introduce
a
new
field
on
either
of
those
resources
that
have
to
be
encrypted
in
the
API
server.
We
will
not
do
any
of
the
other
clever,
but
probably
torturous
things
that
were
part
and
parcel
of
doing
that
that
have
been
discussed.
So
the
TLDR
is
that
we
can
reference
secret
keys
from
our
resources,
but
we
cannot
write
a
controller
that
watches
all
secrets
and
what
that
means
for
us.
A
In
the
in
the
short
term
is
that
if
we
write
an
instance
that
references
a
secret,
X
and
key
Y
that
we,
as
far
as
responding
to
a
change
in
that
secret,
like
say
that
I
have
a
secret
parameter
there
and
I
go
and
I
update
the
secret.
The
controller
will
only
be
able
to
respond
to
that
change.
If
there
is
a
if
there
is
a
rethink,
that's
done
in
the
controller
or
something
else,
changes
about
the
pod
create
a
watch
event
for
the
control.
Does
everybody?
A
Does
everybody
understand
what
that
means
in
terms
of
the
controller
periodically
realists
all
of
the
resources
in
our
API
and
reconcile
with
each
of
them?
And
since
a
change
can
be
made
to
the
secret,
that's
out-of-band
from
what
the
controller
watches
will
have
to
either
wait
until
we
pick
up
that
resource
that
references,
the
secret
in
a
realist
or
the
user,
will
have
to
do
something
to
that
resource
to
to
result
in
a
watch
event
going
to
the
controller.
A
Is
going
to
be,
but
it's
not
going
to
be
delivered
before
kubernetes
1:8
at
the
earliest?
So
that's
a
good
segue
into
long-term.
What?
What
we'll
do?
Instead
of
having
a
controller
that
watches
all
secrets
in
the
cluster
is
he
be
able
will
be
able,
in
the
controller,
to
do
individual
watches
on
secret
and
get
so
instead
of
watching
all
the
secrets,
we'll
be
able
to
say,
I
want
to
watch
secret
X
in
name
state.
A
Today,
you
can
write
an
R
back
rule
that
grants
access
to
an
individual,
a
resource,
so
coupling
that
existing
hardback
capability
with
the
coming
ability
to
watch
specific
resources.
We
can
have
the
right
usage
pattern
so
that
we
don't
have
to
have
a
controller
that
has
both
the
ability
to
watch
all
secrets
and
is
to
do
it,
which
is
the
thing
that
stigma
has
wanted
to
avoid
with
good
reason.
Does
that
make
sense
to
everybody.
C
Can
we
just
treat
the
secret
as
immutable
until
the
individual
secret
watch
is
implemented?
We
can't
because
they
are
not
immutable.
Well,
yes,
but,
for
example,
I
think
I
have
given
this
example
before
that,
like
with
deployments,
if
only
the
very
volume
is
updated
and
if
you
don't
redeploy
like
there
is
no
real
risk
on
deployment
to
make
sure
that
the
secrets
that
you
can
ejected
I'm
sorry.
A
A
Yes,
I
think
that
that
could
be
an
option,
I'm,
not
sure
that
that
would
be
the
kind
of
experience
that
people
would
would
want,
but
so
I
think
that
there
are
two
different
there's
two
different
facets
here:
that
we've
discussed
the
first
one
is
that
we
do
have
confirmation
that
we
can
make
a
solution
that
uses
references
to
two
secret
keys
from
our
API
I.
Think
that's
good!
We
have
some
closure
on
that,
and
the
the
second
facet
is
now
that
we
know
that
we
can
do
that.
A
What
is
the
right
experience
to
implement
for
people
since
we
will
not
have?
We
will
not
immediately
have
the
ability
to
do
the
type
of
watch
that
would
allow
us
to
implement
an
experience
where,
as
a
user
I
reference
a
secret
key
in
my
instance
as
a
parameter
and
then
I
say
okay
I'm,
going
to
update
that
secret
key
and
I
want
that
to
immediately
result.
A
In
a
and
when
I
say,
update
the
secret
key
I
mean
actually
update
the
secret
object
and
change
the
content
of
that
key
and
that
immediately
results
in
a
parameter
update
going
to
the
broker.
Oh
we're
not
going
to
be
able
to
achieve
that.
I.
Think
the
question
is:
what
is
the
the
best
thing
that
we
can
do
short.
C
Of
that
so
Paul
there
is
a
temporary
walk-around
I
think
someone's
have
suggested
in
the
issue
regarding
report
that
you
can
just
rename
the
secret,
which
means
that
you
will
have
to
update
the
binding
referencing
big
secret,
which
will
mean
that,
like
it
will
be
picked
up.
So
this
it's
like
a
cut
the
best
post
not
like
for
now
and
feel
like
you
know,
for
a
quarter
or
so
is
to
be
fine.
Yeah.
A
And
I
certainly
think
it
would
be
sufficient
for
now
because
ended
when
I
say
for
now.
I
mean
ingest
like
at
this
moment,
because
we
don't
do
any
updates,
so
it
would
totally
be
sufficient
with
today's
catalog
I
tell
you
what
I
think
that,
as
far
as
the
as
far
as
what
we
hope
to
decide
in
this
meeting,
I
think
that
this
is
definitely
something
that
has
to
be
done
for
beta
I.
A
Think
that
we
know
part
of
the
solution
now,
which
is
that
we
can
write
an
API
that
references,
keys,
I,
don't
know
if
folks
would
like
to
do
some
design
work
right
now
on
what
the
right
way
to
do,
what
the
right
way
to
use
that
would
be.
It
might
be
something
since
I
just
transmitted
this
information
that
maybe
we
can
talk
through
in
another
design,
meeting
very
near
in
the
future
in
the
next
work
days
and
and
perhaps
move
on
for
now.
B
I
think
I
think
it'd
be
good
to
sort
of
in
that
discussion
here,
because
I
think
people
need
to
go
off
and
figure
out.
Okay,
we
know
we're
okay,
now
secrets
for
other
things
than
just
injecting
the
pod.
So
now
I
think
it's
good
to
make
sense.
I'm
sorry
it'd
be
good
to
go
through
and
enumerate
all
the
sort
of
remaining
holes
around
our
use
of
secrets
and
parameters
and
stuff
like
that
and
then
come
back
on
a
different
college
and
people
have
had
a
chance
to
organize
their
thoughts
on
it.
Okay,.
D
A
B
Purple
before
we
move
on
all
right,
cool
moving
on
the
next
issue
on
the
list
is
scalability
retrieving
service
classes
issued
number
four.
Five
four
and
I
picked
this
one,
because
I
think
it
could
impact
our
model,
and
hopefully
it's
a
relatively
easy
one.
I
know
I
probably
does
inked
it,
but
the
basic
issue
here
is:
if
you
look
at
this
report
by
four
and
actually
hold
on
a
minute,
let
me
get
the
link
and
paste
it
into
the
chat.
B
So
the
basic
issue
here
is
that
service
class
resource
has
all
the
plans
nested
inside
of
it
the
plan
of
not
additional
resources
that
the
search
plan
points
to
rather
they're
nested
inside
of
ayres,
which
means
service
classes
really
really
large.
If
you
have
a
lot
of
clans-
and
it
gets
even
worse,
you
think
about
the
ability
for
plans
to
have
things
like
the
schema
definition.
Some
stuff
like
that,
which
we're
planning
added
to
the
spec
book
will
be
soon.
B
So
these
things
are
going
to
get
really
really
large
and
that's
going
to
be
a
scalability
problem
and
a
performance
problem
when
clients
want
to
list
out
all
or
they
asked
for
the
list
of
this
service,
offering
I
guess
the
Super's
classes
are
term
just
to
see
what
they
can
choose
from.
So
in
this
particular
issue.
To
think
the
very
last
comment
that
I
made
I
actually
put
a
proposal
in
there.
B
Those
are
the
three
columns
you
get
back.
We
list
out
the
marketplace,
so
that's
obviously
based
upon
their
current
user
experience.
Those
are
the
most
important
things
people
care
about,
seeing
at
a
very
high
level
when
you're
then
interested
in
a
particular
service
or
plan,
then
you
can
dive
deep
and
we
can
go
back
and
retrieve
the
individual
resources
for
that
plan
if
necessary.
But
that
was
my
proposal
that
I
want
to
discuss
here
and
see
what
people
thought.
A
So
I,
my
my
gut
reaction
is
I
think
there
are
a
few
I
closely
related
problems
that
are
bound
up
in
the
issue.
Let
me
let
me
give
my
off-the-cuff
decomposition
of
the
problems.
The
first
one
is
the
total
storage
required
to
store
a
serialization
of
a
service
class
and
all
of
its
plans,
given
that
there
are
potentially
unlimited
number
of
plans
associated
with
a
with
a
particular
service
class
and
I
am
pretty
sure
that
there
is
no
upper
limit
defined
in
the
spec.
Please
correct
me
if
I'm
wrong.
A
Plan
and
in
this
issue
is
now
in
the
validating,
through
implementation
phase.
If
I
remember
correctly,
is
that
each
plan
can
have
a
JSON
schema
for
create
and
update,
which
is,
in
my
opinion,
a
better
API
than
some
of
the
more
creative
approaches
that
we
talked
through
to
conceivably
save
space.
But
it's
not
so
good
for
saving
spaces.
It's
like
the
you
would
get
everything
right
on
on
on
every
plan,
so
I
think
there's
an
issue
of
is
plan
a
separate
resource
and.
A
That's
one
issue:
the
I
actually
had
a
different
I
expected
I
had
a
apparently
fulsome
memory
of
this
scalability
of
retrieving
service
classes
being
something
totally
different,
so
I
think
that's
one
issue.
The
other
is
if
we
do
separate
them,
is
there
a
as
doug
has
proposed
some
subset
of
the
information
that
would
be
convenient
to
have
present
on
on
the
service
class
itself
and
the
more
general
problem
of
like?
D
Did
I
miss
anything
yeah?
The
issue
was
opened
originally
to
try
and
address
reverse
deletes,
so
when
a
broker
is
deleted,
how
do
you
to
find
all
the
service
classes
that
it
owns
and
also
there
was
I,
think
there
was
some
similar
issues
to
deal
with
items
resources
lower
in
the
chain,
but
this
is
just
about
service
classes.
D
A
Since
that
is
the
case
and
I
have
to
imagine
that
there
are
going
to
be
a
number
of
other
issues
from
the
early
days
of
the
cig,
where
we've
gotten
much
better
at
delineating
issues
for
very
focused
specific
things,
I'm
wondering
if
we
need
to
create
like
individual
issues
for
the
different
facets
that
remain
to
be
solved
includes
this
one
out.
Yeah.
B
D
I
got
the
numbering
wrong,
so
I
I,
don't
have
it
open
right
now
there
there
was
an
issue,
I
bet
either
this
includes
or
references
this
one
that's
about
some
completely
different.
It
was
about
trying
to
traverse
from
a
broker
to
all
those
service.
Clubs,
that's
completely
unrelated.
What
we're
talking
about
here.
I
just
want
to
make
sure
that
we
don't
mix
the
two
things
together:
okay,
yeah.
B
A
A
D
A
Yeah
yeah
and
I
I
wasn't
trying
to
be
a
jerk
Aaron
I
was
trying
to
be
comedic,
but
the
the
the
short
answer
is
to
my
knowledge.
There
is
no
pagination
of
lists
or
get
verbs
in
kubernetes.
I
do
I
think
that
it
is
not
our
job
to
invent
it.
It
is
conceivably
possible
that
we
might
be
a
forcing
function
for
the
invention
of
such
a
resource.
I
definitely
do
not
think
this
SIG
is
where
such
such
a
capability
should
be
developed.
A
C
B
That
was
the
quiet
protocol.
It's
a
couple
of
lists,
but
just
to
circle
back
around
Erin,
while
I
do
think.
Pagination
may
be
a
useful
thing
in
this
general
context,
because
if
you
have
say
a
thousand
service
offerings,
no
matter
how
small
we
get
the
service
class
resource
down,
pagination
may
still
be
a
good
idea.
I
definitely
heard
that
in
general.
B
However,
for
this
particular
case,
I
think
we
need
to
be
able
to
solve
without
pagination,
because
even
a
small
number
of
service
classes
could
end
up
going
back
a
ton
of
data
simply
because
the
the
JSON
schema
itself
in
terms
of
relative
size
is
going
to
be
probably
far
bigger
than
the
information
we
really
care
about,
just
by
listing
classes
listing
the
server
classes.
So
we
we
need
to
address
the
given
for
smaller
cases
that
don't
require
pagination
in
general.
A
So
for
clarity
for
anybody
that
is
blissfully
unaware
of
this,
the
there
is
a
limit
upper
limit
on
individual
entity
records
of
one
megabyte
that
I
I've
heard
different
things
I've
heard,
though,
that
it's
a
hard
limit
and
that
it's
a
soft
limit,
but
things
get
extremely
slow
over
that
limit.
So
there
is
a
there's,
an
upper
bound
that
we
want
to
stay
under
a
one
megabyte
per
per
individual
resource
I.
A
B
So,
in
order
to
make
progress
on
this
and
I
definitely
don't
mean
to
try
to
push
anybody
to
make
a
hard
decision
here,
but
in
order
to
make
forward
progress,
what
I'd
like
to
do
is
ask
whether
the
proposal
that
I
laid
out
there
is
at
least
looking
like
it's
in
the
right
direction
or
whether
there's
something
fundamentally
wrong
with
it,
because
if
it's
at
least
in
the
right
direction,
then
we
can
say
ok.
Now
we
can
take
the
next
step
of
going.
B
The
next
may
take
the
next
step
in
terms
of
the
design
of
it
maybe
start
doing
a
simple
pr2
through
a
concept
to
play
with
it,
but
only
people
are
ok
with
that
general
direction,
and
there
is
an
alternative
that
people
like
to
consider
at
this
point
in
time.
Now,
if
the
answer
is,
it
may
be:
ok,
but
you'd
like
more
time
to
think
about
it.
That's
a
fine
answer
to
I'm
just
going
to
get
a
gauge
for
where
people's
heads
right
now
now,
like
I.
D
Think
it's
it's
probably
worth
having
a
three
or
four
day
kind
of
design
discussion
period
on
github,
so
we
can
suss
out
the
answer
to
your
that
question.
You
suppose
right
now,
Doug
I
think
if
nobody
comes
up
with
a
better
solution
than
that,
I
think
that
is
probably
the
way
to
go.
Modulo
may
be
having
getting
rid
of
that
referential
integrity
problem
that
Paul
said
yep
any
of
them.
Anybody
yeah.
A
I
have
a
nucleus
of
just
another
thing
that
might
be
worth
considering,
so
the
I'm
not
I'm,
not
quite
sure,
about
storing
some
of
the
information
in
like
I,
not
sure
about
the
element
of
like
make
plans
separate,
but
then
keep
some
of
the
plan.
Information
on
the
on
the
storage
class
itself
I
understand
the
motivation,
I'm
thinking
that
perhaps
there
might
be
a
there,
might
be
something
that
we
could
do
with
a
sub
resource.
A
Where
say
that
the
service
class
itself
doesn't
actually
have
any
of
that
information,
but
you
there's
perhaps
a
sub
resource
that
you
can
do
a
get
on
for
an
individual
service
class.
That
will
give
you
some
of
that
extra
information
and
you
won't
have
to
pull
all
of
it
down
on
the
wire
for
any
for
an
individual
service
and
I'm,
not
sure
if
that
is,
is
even
viable.
But
that's
the
element
of
uncertainty
that
I
have
about
it.
I
do
want
to
continue
thinking
about
it
to.
A
B
A
B
A
B
Same
time,
I
want
to
be
able
to
see
what's
available
to
me
as
an
end
user
and
the
user
experience
that
I'm
used
to
is
the
cross
boundary
one
which
shows
me
a
list
of
services
and
a
list
of
plan
names,
as
well
as
a
short
description
of
the
service
and
a
flag
on
each
plan.
Name
that
tells
me
whether
it's
free
or
not
got
it
so.
D
For
now,
because
this
is
I
have
two
concerns
or
ideas,
I
guess
not
really
concerned.
So
one
we're
right
now
really
addressing
a
data.
The
API
changes
that
we're
going
to
need
later
to
deal
with
scalability
issues,
I
would
venture
to
say
that
we
go
to
beta
I,
don't
think,
there's
going
to
be
anyone,
who's
got
10,000
service
classes
each
with
you
know,
X
number
of
plans,
but
we're
just
doing.
This
is
just
the
data
format
that
we
need
to
have
to
deal
with
that
case
later
on
right.
Does
anyone
disagree
with
that?
Well,.
B
D
The
data
changes
we're
making
here
not
only
deal
with
changing
the
API
before
we
have
to
freeze
it,
but
they
also
deal
with
the
storage
problem
right,
you
know
putting
out
plans
from
services
would
solve
both,
but
we
don't
necessarily
need
to
be
looking
at
or
talking
about
the
API.
As
long
as
the
data
format
that
we
have
right
now
or
I
should
say
the
one
that
we're
going
to
can
support
it
and
I
think
it
does
so.
It
sounds
like
we
can
build.
Even
we
could
even
build
some
kind
of
porcelain
CLI.
D
A
D
To
solve
the
storage
problem,
I
don't
see
any
way
that
service
class
the
service
plan
can
be
the
same
resource
yes
and
then
beyond
that
I
mean
I.
Have
my
opinions
on
listing
everything
all
at
once?
Others
have
other
opinions,
I'm
sure,
but
I
don't
think
we
need
to
decide
that
now,
as
long
as
we
can
support
both
and
I
think
we
can
I.
B
Agree,
what
are
your
thoughts,
I
think
I
agree,
but,
to
be
honest,
you
lost
me
a
little
when
you
were
describing
that
when
you're
trying
to
basically
separate
out
the
problems
from
the
data
model
from
the
API
but
I
do
agree
with,
though
I
think
you
both
are
saying
which
was
chances,
are
we're
going
to
look
these
two
resources
period,
I
think
so
far.
I'm
here
I
mean
oh,
we
disagreement
on
that
right.
D
B
D
I,
don't
think
it's
the
absolute
next
decision.
I
think
we've
got
some
time
to
make
it,
but
it
is
a
decision
we'll
have
to
make
some
time
in
the
nearest
future,
because
yeah
after
we're
in
data
or
GA
someone's
going
to
end
up
having
ten
thousand
service
classes,
each
with
ten
plans
and
they're
going
to
want
to
see
them
all
right.
Okay,.
B
So
then,
and
that's
when
we'll
have
to
figure
that
out
okay,
so
then,
then
going
back
to
taking
the
next
steps
on
this
phone
call
I
think
it
it's
back
to
what
you
asked
earlier,
which
is
give
people
three
days
or
so
to
look
at
this
and
think
about
it
and
see
if
they're,
okay,
with
the
general
direction
of
splitting
it
to
then
we
can
take
the
next
step.
Is
everybody
locate
with
that
they're
saying?
B
B
Down
on
the
notes,
because
even
my
proposal
I
assumed,
we
would
tweak
the
exact
list
to
probably
put
that
I
just
want
to
put
something
out
there
as
a
strong
proposal
to
get
us
moving
and
Paul.
If
you
can
I
would
love
to
find
out
more
information,
in
particular
a
pointer
to
an
existing
resource
that
has
this
sort
of
dynamics
of
resource
thing
you're
talking
about.
So
we
can
use
that
as
it.
B
B
B
D
And
so
for
those,
the
doc
I
wrote
next
steps,
as
everyone
reviewed.
The
proposal
and
I
also
took
note
that
we
kind
of
unofficially
decided
that
we're
probably
going
to
split
plans
from
services,
and
someone
is
probably
going
to
PR
that
as
a
prototype
after
we
take
the
next
few
business
days
to
decide
on
Doug's
proposal
number
issue
number
four
from
before:
okay.
B
Any
questions
comments
on
that
before
we
move
on
to
the
next
agenda
item,
all
right,
cool
all
right.
Next,
one,
this
one's
bigger,
it's
the
pod,
presets
stuff
and
bindings.
This
one
encompasses
a
lots
of
different
issues.
So
let
me
try
my
best
to
try
to
summarize
but
I
think.
Maybe
one
of
the
key
points
there,
obviously
they're
they're
going
to
others
are
there
are
many
I
think
secondary
issues,
but
I
think
probably
the
biggest
issue
here
is:
should
some
variant
of
pod
preset
be
embedded
within
the
binding
resource
itself?
I
hear
oh.
A
Go
ahead
so
I
have
spent
a
lot
of
time.
Thinking
about
that,
let
me
put
the
information
that
I
have
on
the
table,
which
is
so
for
those
that
are
like
relatively
new
to
the
sig.
We
historically
have
talked
about
pod
preset
in
a
kind
of
a
naive
type
of
way,
in
the
sense
of
that
that
reflects
how
it's
currently
implemented,
which
is
that
we
talked
about
pod,
preset,
template
being
part
of
the
binding,
a
part
of
the
binding
resource
and
that
the
controller
would,
after
doing
the
open,
serviceworker
binding
make
the
pod
preset.
A
So
the
I
do
not
think
that
that
was
necessarily
a
a
statement
of
like
that
is
the
exact
right
during
I
view.
That
now
is
more.
Like
straw,
man
conversation
to
illustrate
the
general
concept
of
a
linkage
between
binding
and
pop
reset
I
have
a
couple
pieces
of
data
that
made
me
think
that
they
should
definitely
not
be
part
of
the
same
resource.
So
the
first
is
community
feedback
null
doesn't
like
it.
B
A
B
A
It
is
seen
as
a
combination
of
too
prescriptive
and
unnecessary
API
surface
that
might
be
better
factored
in
another
way
to
allow
people
to
you
to
leverage
pod
preset
in
a
style
that
is
like
that.
That
is
essentially
the
same
as
what
we've
discussed
without
it
having
to
be
part
of
the
open,
serviceworker
binding
and,
along
with
this
I,
have
some
data
points
about
the
different
integrations
that
people
want
to
build.
A
A
Ok,
that's
perhaps
what
most
people
currently
developing
applications
running
kubernetes
might
want
to
do,
but
I
can
I
have
other
precedent
or
not
other
precedent.
I
have
on
some
other
use
cases
that
I
can
point
to
now.
That
I
think
are
valid,
that
we
should
enable,
and
when
and
I
will
name
some
of
those
immediately
following
my
next
couple
sentences.
I
think
that
the
pod
preset
integration.
A
A
Environment
where
people
are
going
to
playing
applications
to
both
kubernetes
and
Cloud
Foundry
and
I,
like
I'm
thinking
of
Doug's
use
case
for
bluemix
here,
where
kubernetes
is
kind
of
the
newcomer
and
as
far
as
I
understand
like
every
application
in
that's
currently
deployed
into
bluemix
with
a
you
know,
modulo
some,
like
small
number,
is
using
the
vcap
services,
a
method
of
getting
service
information
about
bindings.
I,
think
that
is,
that
is
a
valid
use
case.
To
want
to
be
able
to
do
the
same
type
of
injection,
which
I
think
is
a
bit
like.
A
It's
not
what
pod
preset
was
designed
to
do.
It's
very
different
from
the
way
that
the
kubernetes
ecosystem
is
used
to
treating
things,
but
I
will
call
this
for
just
for
discussions.
Sake,
be
Cap
service
of
style
injection.
So
that's
one
other
type
of
integration
that
I
see
as
being
distinct
from
pod
preset.
There
is
another
integration
that
I
think
is
probably
outside
the
scope
of
what
we
are
trying
to
accomplish
in
the
sig,
which
is
an
integration
with
open
service.
A
D
So
I'm
a
little
lost
here,
but
I'm
not
doing
it,
but
hey
everyone.
Let's
take
a
pause
for
a
second.
So
what
I'm
hearing
is
people
people
just
people
in
the
community?
Well,
they
they
don't
like
it,
because
it
too
closely
coupled
the
binding
wishes,
must
be
a
generic
OSB
integration
style
thing,
with
the
specific
way
that
binding
credentials
get
into
applications.
Is
that
accurate
just.
C
D
C
D
Yeah
you
know,
I
do
I,
do
want
to
get
into
that
the
cross
service
thing
at
some
point,
but
when
you
first
make
sure
like,
maybe
it
is
just
me
being
selfish,
but
I
want
to
make
sure
I
get
this
foundation.
Appalled
restate
how
many
if
this
is
the
correct
people
in
the
community,
don't
like
coupling
pod
preset
too
tightly
with
the
with
our
binding,
because
it
too
tightly
couples
the
OSB
integration,
with
the
way
that
OSB
binding
credentials
get
put
into
pods.
D
B
A
A
One
one
idea
that
I've
heard
discussed
in
other
venues
is
having
an
integration
that
would
alter
reefs
other
resources,
which
aren't
pots
that
are
in
the
ecosystem,
but
they
are
not
pods
and
then
there's
also
yet
another
flavor,
which
is,
is
a
you,
want
to
create
wholly
different
resources,
not
alter
another
existing
resource,
but
you've
got
some
special
pet
resource,
but
you
want
to,
and
pet
is
a
really
bad
way
to
describe
this.
You
have
an
arbitrary
other
resource
that
you
want
to
manifest
the
binding
to
so.
D
I'll
add
another
one,
which
is
what
we
do
is
absolutely
nothing
and
we
just
when
we
install
an
instance
we
use
helm
and
when
we
update
something,
whether
it's
the
instance
or
the
application
we
use
helm
and
the
application
the
pod
or
the
pod
spec
consumes
the
same
secret
that
the
binding
produces.
So
there's
not,
we
don't
rely
on
anything
except
for
templating
at
home.
Another
data
point
for
everyone
watching
people,
meaning.
D
B
I
was
I
was
going
to
say
so,
let's,
let's
stop
here
or
not.
Let's
start
to
wrap
this
up
here,
because
I
do
are
respectful
of
people's
time,
but
it
sounds
to
me
like
call
you.
You
gave
a
good
background
on
why
some
people
do
not
like
Kim
betting
or
are
linking
the
two.
Is
there
anybody
on
the
call
who
wants
to
make
an
argument
for
keeping
pod
preset
inside
of
binding?
B
Okay,
not
hearing
that
it
sounds
like
we
have
at
least
a
high-level
tentative
decision
that
that's
direction
were
going
to
go.
Obviously
we
need
to
get
a
couple
days
time
to
be
able
to
think
about
it,
who
are
on
the
call.
Yeah
least:
that's
that's
in
a
high-level
decision,
so
it
seems
to
me
like
the
next
decision
point
that
is
okay.
If
we're
splitting
the
two,
what
do
we
want
to
do
about
that
right?
Do
we
want
to
create
another
type
of
resource
like
partiers?
B
B
I'll,
take
the
action
item
to
write
up
a
note
to
the
group
in
one
end,
I
know
to
the
group
pointing
to
the
issue
and
then
put
the
more
detailed
thing
of
what
we
just
decided
into
the
issue.
So
people
can
look
at
it
before
even
I.
Don't
want
you
to
get
on
boy
pulpit
yet
is
because
I
do
want
a
heart
stopped
at
the
top
of
the
hour.
So
let's
first
decide
when
the
next
meeting
is
and
then
you
can
have
at
it.
How
does
tomorrow
work
for
folks
for.
E
E
Thank
you
and
I
also
wanted
to
say
that
we
to
throw
in
another
data,
point
that
we
had
talked
to
customers
that
were
really
interested
in
the
catalogue,
but
as
far
as
they
were
already
using
existing
systems
such
as
console
involved
to
consume
credentials,
and
so
the
integration
they're
being
able
to
send
it
outside
of
kubernetes
in
those
specific
cases
was
very
important
to
them.
I
think.
A
B
B
A
A
Integration
with
the
binding
and
the
benefit
of
building
another
resource
would
be
that
you
would
get.
The
behavior
of
the
lifecycle
of
this
pod
preset
would
be
managed
with
the
lifecycle
of
the
binding
so
that
you
wouldn't
have
the
pod
preset
being
created
until
the
binding
was
ready
and
when
the
binding
was
deleted.