►
From YouTube: Kubernetes SIG Service Catalog 20170720
Description
Design meeting:
- Should we move PodPreset to service-catalog API server?
- Relaxing strict check on OSB ID characters
- Modes for binding - format of credentials secret
- Plans for CRD support
- Parameters
A
A
All
right,
so
the
first
thing
on
the
agenda
today
is
to
talk
about
migrating,
the
settings
API
group
and
the
pod
preset
resource
into
Service,
Catalog
API
server
and
implementing
the
pod
preset
behaviors
with
an
initializer.
So
in
case
anybody
watching
or
attending
might
not
be
clear
on
what
this
means.
A
pod,
preset
resource
and
slangs
API
group
are
currently
in
the
core.
A
The
generic
resource
support
and
keeps
ETL
that
the
catalog
resources
used
to
do
rich
describes
without
information
actually
being
in
cube
CTL
about
the
resource
and
we
most
importantly
elect
initializers,
which
are
a
mecca
to
do
emission
control
type
activities
without
compiling
code
in
kubernetes.
So
this
is
sort
of
a
classic
chicken
and
egg
problem
in
kubernetes,
where
we
want
a
set
of
machinery,
but
we
don't
have
it,
and
so
we
have
to
use
kind
of
the
best
tools
that
we
have
at
the
time.
B
Is
there
any
reason
that
we're
moving
it
to
service
catalog
other
than
were
the
main
use
of
it
right
now,
because
I
it
makes
it
very
uncomfortable
to
move
it
to
our
group
because
it
feels
like,
if
it's
part
of
our
group,
then
we
should
have
the
freedom
to
pretty
much
do
whatever
we
want
with
it
and
that's
going
to
make
it.
So
it's
no
longer
a
generic
resource
available
for
anybody's
use.
A
So
there's
a
few
different
concerns
bound
up
there.
Let
me
address
them
and
what
I
think
is
reverse
order.
I.
If
we
move
the
settings
API
group
to
our
API
server,
that
it
doesn't
mean
that
not
anybody
can
use
it,
it
means
that
you
have
to
install
the
catalog
to
use.
It.
I
think
that
the
motivation
for
moving
it
to
our
API
server
is
at
a
pod.
Preset
was
basically
conceived
to
solve
the
problem
of
injecting
binding
information
for
catalog
I.
A
B
Let's
say
we
decide
to
move
it
to
Service
Catalog
and
we
decide
pop
preset
needs
to
have
a
tweak
to
it.
That
makes
it
a
little
less
generic
and
more
specific
of
Service,
Catalog
I.
Think
that's
a
fair
thing
for
us
to
do,
because,
as
part
of
our
domain
at
that
point
is
under
our
API
server
right.
Whereas
if
we
keep
it
somehow
under
the
core,
then
it's
then
we
can't
necessarily
make
it
specific
to
one
group
like
Service
Catalog
right.
B
It
has
to
remain
generic
purpose
resource
and
so
I
think
there's
a
big
decision
here
right.
Is
it
really
meant
to
be
a
generic
resource,
because
if
it
is,
then
it
really
should
not
be
part
of
our
group,
maybe
to
be
part
of
a
more
generic
utility
group?
I'm,
not
part
of
core,
but
I,
don't
think
it's
be
part
of
Service
Catalog.
At
that
point,
I.
B
Okay,
let's
say
we
take
PI
preset
and
we
decide
you
know
what
there's
no
reason
that
pod
preset
and
pod
preset
binding
we're
going
to
merge
the
two
and
we're
just
going
to
make
them
be
the
link
to
the
to
the
instance
access
key
order.
We
decided
to
call
it
optional
that
way.
Yeah,
you
don't
have
to
use
it,
so
you
can
still
use
in
a
generic
sense,
but
there's
a
pointer
to
the
key.
We
need
it
and
that's
that
maybe
pavia
service
catalog
specific.
A
I,
don't
think
that
we
want
to
do
that
anyway.
I
think
that
we
should
look
at.
We
should
look
at
this
like
it's
being
incubated
in
our
repository,
but
it's
not
potentially
not
going
to
permanently
live
there
I
know
that's
the
outlook
that
Brian
Graham
has
on
it.
I
think
that
this
would
be
like
a
convenient
place
to
incubate.
It
I,
don't
think
it
long-term
necessarily
lives
in
service,
catalog
and
I.
Do
think
that
we
should
avoid
entangling
a
pod
preset
functionality
with
the
catalog,
except
via
a
resource
that
links
the
two
so.
B
A
So,
specifically,
what
I
would
what
I
imagine
as
the
the
transformation
would
be
to
move
the
entire
settings
API
group
to
our
API
server
and
retain
it
as
a
distinct
API
group,
and
that
way
we
could.
We
could
relocate
it
in
another
API
server
at
another
time
and
add
a
new
controller
to
our
controller
manager.
That
acts
as
the
the
entry
that
the
initializer
talks
to
in
the
core.
B
B
A
The
desire
is
to
bring
pod
preset
to
beta
in
in
1:8
I
think
that
Google
is
willing
to
staff
the
effort
to
move
it
to
our
repository
and
there
they
have
a
person
they
have
person.
Two-Nil
has
been
on
some
of
our
meetings,
who
is
tasked
with
bringing
it
to
beta
and
doing
a
programming
work?
Does
that
answer
your
question
I'm
not
sure
I
remembered
all
of
it.
So.
A
C
D
Yeah
is
a
pod
preset,
as
you
know,
I'm
just
going
by
how
I
understand
the
'god
service
stuff.
It's
the
same
api
group.
It
doesn't
matter
which
service
or
interest
that
it
gets
served
under
the
specific
API
group
yeah.
That
is
correct.
That's
what
the
caveat
that
everything
is
by
the
aggregator
yep
and
you
know
that
all
works.
D
A
D
D
C
A
Know
then
it's
our
goal.
It
is
a
goal
of
kubernetes
to
move
it
out
of
the
core
I've
realized,
since
we
started
talking
about
this,
that
we
don't
have
Sanel
or
anybody
else
who
is
working
on
this
I
actually
present
today
and
I.
So
I
wonder
if
we
might
want
to
cut
the
discussion
on
here
and
table
this
for
the
Sigma
meeting
for
Monday
well,.
C
A
B
Yes,
the
typically
vamonos
down
there
to
think
of
my
name
next
to
it.
The
question
here
is:
do
we
want
to
remove
the
restriction
on
the
gooood
check
for
external
ID
and
replace
the
validation
to
make
sure
it's
a
good
and
replace
it
with?
Just
basically,
nothing
say
it
has
to
be
a
non
empty
string,
and
this
being
during
about
the
fact
that
the
open
source
program
has
spec
defines
this
as
a
string
it
recommended
it
is
a
good
but
doesn't
mandate,
it
be
a
good.
B
A
C
C
C
It
would
be
more
wise
for
us
now
to
add
a
little
bit
of
permissive
'ti,
but
not
take
any
opaque
string
and
then,
if
we
find
a
significant
number
of
brokers
at
passing,
zero
with
non-breaking
spaces
or
emojis
or
whatever
else,
we
can
evaluate
those
in
a
case-by-case
basis
and
concurrently
right
now,
we
can
try
to
go
add
language
into
the
spec.
That
makes
that
better
specified
yeah.
C
So
Doug
I
wanted
to
clarify
the
sentence.
You're
writing
right
now.
I,
don't
want
to
add
more
restrictions
to
the
current
ones.
I
want
to
relax
the
restrictions
a
little
bit
to
account
for
the
I
think
this
one
is
too
specifically
to
allow
a
dot.
Well,
I
would
like
to
add
permittivity
to
allow
the
dot,
but
not
go
all
the
way
and
just
take
an
extreme
I'm.
E
A
little
confused
by
that
so
I'm
all
for
us
driving
something
in
the
spec
immediately
to
say
you
know.
Maybe
this
should
just
be
a
do
it,
but
the
spec
is
very
clear
that
this
just
needs
to
be
a
global,
unique
identifier
and
if
we're
saying
we're
going
to
relax
for
this
character
and
then
this
character
in
this
character,
it's
going
to
be
a
huge
pain
in
the
ass,
whereas
the
spec
is
very
clear.
Why
are
we
making
choices
that
are
outside
of
that
I.
B
Tend
to
agree
enough,
that's
my
concern
is:
if
we
deploy
this
thing
into
a
product
and
then
some
Rover
comes
along
and
says,
hey
I'm,
going
to
add
a
backslash
character
in
there,
something
like
that
right,
the
the
guys
deployed
this
are
now
basically
screwed
and
they
have
the
way
for
us
to
buy
a
fix
to
it.
When
the
when
everything
is
that
compliant
today,
so.
E
C
E
E
F
E
And
we're
going
to
have
to
open
it
up
to
that
and
open
it
up
to
something
else.
Fix
is
sweet,
so
here
there
is
no
specs
that
worse
inform
so
I'd.
Rather
us
either
leave
it
as
a
GU
it
and
try
to
drive
that
add-in
aspect
or
conform
with
the
spec
and
try
to
get
the
spec
changed
and
when
the
spec
changes
we
we
make
it
more
restrictive.
So.
C
That
so,
let's
say
that
the
spec
does
change
Brendan.
Let's
say
we
say
we
get
into
the
spec
language.
It
says
it
must
be
a
good
I
think
we
will
I
think
that's
a
if
we
have
a
very
good
argument
for
making
it
required
as
a
good
or
required
as
some
well
formed
string.
If
we
currently
were
to
allow
any
string,
it
would
be
much
much
more
difficult
to
go
back
and
start
requiring
a
good.
Then
why.
E
Would
we
have
now
and
make
it
more
permissive
I
would
assume
that
that
spec
change
would
would
involve
a
service
broker
version
change,
and
so
the
new
brokers
would
be
conforming
to
the
new
version,
and
we
would
again,
we
talked
about
supporting
multiple
service
broker,
API
version,
spec
version
yeah.
Absolutely
it
seems
like
like.
C
A
F
A
Either
does
I
don't
think
that
the
issue
of
whether
this
is
an
identifier
is
actually
put
to
bed?
Yet
we
have
a
lingering
issue
of
whether
we'll
address
services
or
service
classes
and
plans
by
their
by
their
names,
which
I
think
can
change
or
their
IDs,
which
are
supposed
to
be
static.
Does
anybody
remember
that.
A
Do
think
it
is
because
if
you
can
send
a
space
for
this,
then
we
can't
use
it
as
as
an
identifier,
so
we're
locking
ourselves
we're
essentially
sorting
out
and
other
design
issue
at
this
time
too.
If
we
decide
that
we
are
going
to
allow
characters
that
won't
make
a
valid
kubernetes
identifier,
I,
don't.
A
A
Ui,
though
I'm
talking
about
in
EDD,
if
we,
if
this
so
as
I,
understand
it,
this
ID
is
the
only
stable
coordinate
that
we
actually
have
for
a
service
or
a
plan.
And
that
means
that,
if
that
we
have
to
validate
those
things
as
valid
names
in
kubernetes,
if
we're
going
to
use
that
as
the
name
of
the
object,
which
is
something
that
we
talk
to
doing,
because
we
don't
support,
name
changes.
B
B
C
Doug,
you
don't
you
and
Brendan
you
guys.
Both
have
I,
don't
dispute
this.
You
guys
always
have
a
super
excellent
point
right:
we're
not
spec
compliant
right.
Now
my
concern
and
I'm.
Sorry,
if
I
haven't
expressed
this
properly.
My
concern
is
that
if
we
go
to
any
string
right
now-
and
then
we
say
okay
now,
the
spec
has
changed
to
be
good.
We
are
we
as
a
Service
Catalog
team
are
screwed
right,
so
we
have
a
problem
either
way
we
go
and
what
I've
met.
F
E
C
E
Action
any
spec
change,
that's
breaking
that
I
missed
a
lot
of
what
you
said.
Brennen
someone
was
coughing.
Sorry
I'm,
just
saying
you
know
the
spec
is
going
to
be
versioning
with
breaking
changes,
but
I
think
that's
the
point
and
I
don't
think
this
is
unique
to
this
particular
thing,
any
any
change
to
the
spec
as
the
potential
to
to
cause
this
issue.
Yeah.
C
That's
true,
I
think
if
it's
like
nursing,
you
should
probably
we
should
probably
take
this
issue
and
blow
it
up
in
scope.
How
are
you
going
to
support
there's
another
issue
for
this?
How
are
we
going
to
support
major
version?
Spec
changes
right
because
that's
we
are
now
talking
about
that
effectively.
So.
E
B
F
B
C
Does
can
you
right?
There
are
the
two
issues
with
going
to
just
the
string
that
I've
heard.
I
think
you
know
well
what
the
issues
are
with,
if
not
going
to
just
the
string,
but
the
two
issues
I
have
heard
for
going
to
justice
string,
our
the
backward
compatibility,
/
spec,
upgrade
situation
and
the
possible
using
this
thing
as
a
kubernetes
identifier,
problem.
C
B
A
B
A
So
next
on
the
agenda
is
a
question
from
Dan
Wilson,
who
I
don't
think
is
a
president
currently
but
he's
been
he's
been
working
on
using
the
hash,
Ecore
volts
serviceworker
with
a
log.
In
fact,
that's
the
that's
where
he
found
the
issue
with
the
validation
on
name,
and
he
wanted
to
know
where
to
put
examples.
C
B
C
C
B
D
A
A
B
So
I'm
definitely
a
favor
of
the
idea
of
allowing
that
information
get
in
there.
Somehow
I
need
to
think
more
about
these,
like
mechanisms
do
it,
but
I
definitely
favor
of
making
that
information
available.
Just
a
quick
question
for
you:
would
it
be
horrible
if
we
just
always
created
a
well-defined
key
and
stuck
it
in
there
that
way,
the
person
doesn't
need
to
explicitly.
You
are
the
way
to
ask
for
it.
A
F
F
F
F
But
if
you
use
to
supply
secret
key
ref
instead
of
secret
drift,
I
will
put
the
entire
credentials
object
as
a
block
into
this
key.
Something
like
that.
So
right,
I
can
imagine
this
type
compatible.
Group
by
course,
both
ways
of
whether
we
send
it
in
missiles,
input
or
just
put
the
result
of
credentials
back
to
communities
and.
G
F
C
B
A
Think
there
there
are
two
or
three
different
facets
here
for
the
purposes
of
expedient
resolution
of
the
of
the
issue
that
we're
talking
about.
Is
it
okay
if
we
just
constrain
the
scope
to
just
be
the
mood
for
binding,
it
sounds
to
me
like
API
constructions
aside
and
people's
preferences
on
those
like
no
one
says:
there's
absolutely
no
way.
We'd
ever
need
to
do
this.
It
sounded
like
people
are
open
to
it.
I'm,
not
sure
whether
that
means
it's
needed
for
beta
I.
A
B
C
A
So
Union
sites
are
are
useful
in
this
regard,
because
you
can
add
new
options
for
configuring.
What
the
what
a
new
value
the
Union
type
can
take
on
take
on
in
a
backward
compatible
way.
So
what
we
could
do
is
I
have
a
union
type
of
one
option
and
that
way,
if
we
decide
that
we
want
to
add
something
new
in
the
future,
we
can
do
it
in
a
backward
compatible
way
and
have
it
nestled
lovingly
in
the
right
place
in
the
API.
That.
B
C
A
A
C
A
B
So
I'm
a
little
I'm
still
a
little
confused,
I
think
I
understand
Nell's
proposal,
but
I
still
think
it's
different
and
Paul.
You
try
to
pull
us
back
around
to
the
to
the
use
case
of
where
to
put
the
credentials
into
the
secret
or
how
to
put
them
into
a
secret
I
thought
your
proposal
was
was
changed
slightly
after
what
I
said
about
using
a
default
thing,
but
I
thought
your
proposal
was
going
to
be
try
to
take
all
the
keys
from
the
JSON
website.
B
A
B
A
Right
anyway,
I
don't
want
to
I,
don't
want
to
shove
the
entire
payload
in
into
a
secret,
unless
someone
specifically
asked
for
that
in
it
like
I,
don't
want
to
do
both
the
map
style
and
a
specialty
with
the
entire
payload,
because
that
sounds
like
we're.
Basically
adding
approximately,
like
50%,
more
storage
required
for
catalog
secrets.
F
B
A
B
A
A
A
C
B
F
C
A
A
A
G
C
A
C
To
why
we
dais
at
the
time
wanted
TP
ours,
it
was
from
a
use
case
from
a
few
of
our
customers
that
didn't
want
to
have
pods
speaking
to
EDD.
We're
SED
was
the
same
entity
that
the
kubernetes
core
was
using.
Yeah
dave
is
dead.
Who
cares
now?
We
still
have?
We
still
have
seen
the
same
complaint,
but
that
doesn't
necessarily
mean
we
need
to
use
CR
DS
for
TP
ours,
whatever
we
want
column
right
now,
Aaron.
F
I
think
your
question
is
actually
whether
we
want
to
continue
the
support
or
keep
er
once
it's
reached
from
1.0.8
to
be
compatible
with
the
one
point
six
of
given
ages.
Now,
where
we
want
be
a
CRT
support,
but
still
will
be
a
like
to
be
our
support
in
1.6.
Do
we
want
to
support
GPRS
in
1.6,
I?
Guess
that's
the
question.
C
C
A
C
I
would
like
to
I'll
put
this
on
the
agenda
for
next
design
meeting,
which
is
yeah,
haven't
merged
27,
yet
I'm
working
on
a
nail
I'm,
not
reviewing
like
that.
So,
just
to
finish,
my
thought
I
would
like
to
have
the
discussion.
I'll
put
it
on
for
next
design
meeting
about
whether
we
should
move
forward
with
CR,
DS
and
I
can
present
that
use
case
again,
I'll
remind
everyone
about
what
the
concern
is,
etc.
That's
all
for
me.
A
B
C
Put
an
agenda
item
down
first,
for
whenever
the
next
design
meeting
is
and
yes,
I
can
write
a
I,
don't
know
if
I
should
call
a
proposal,
but
I
will
write
a
document
that
describes
why
a
we
wanted
PPR
in
the
first
place,
we
being
dais
and
be
what
their
continuing
use
cases
for
us
to
want.
Storage,
not
at
storage.
Besides
at
CD
that
the
core
talks
to
okay.