►
From YouTube: Kubernetes SIG Service Catalog 20170726
Description
- Broker relist behavior
- Broker TLS configuration
- Instance parameters
- Defaulting plans of service instances
- Broker update semantics
A
All
right
welcome
everybody
to
the
July
26
2017
earth,
335,
a
continuity
version
of
Service
Catalog,
coming
to
you
at
1600
hours,
Eastern
Standard,
Time,
I'm,
now
going
to
turn
the
meeting
over
to
Aaron
Schlessinger,
who
you
may
be
familiar
with
from
all
prior
service
catalog
meetings.
Aaron,
you
have
the
floor.
B
Ok,
everybody
thanks
for
joining
so
today,
I'm
going
to
be
purely
a
facilitator.
So
what
we're
gonna
do
today
is
obviously,
as
we
always
do,
go
through
the
list.
You
can
find
that
list
doc
I'll
paste
the
link
for
the
doc
in
case
somebody
doesn't
have
it
and
what
we're
gonna
do
when
as
we
go
through
this
list,
is,
do
something
called
a
speaker
queue.
So
in
the
past,
we've
had
discussion,
which
is
great
I,
want
to
add
a
little
bit
more
structure
to
the
discussion
so
that
everybody
gets
a
fair
chance
to
speak.
B
So
if
you
do
have
something
to
say
in
the
middle
of
the
discussion,
please
write
in
the
chat,
hand
or
plus
hand
either.
One
is
fine
and
you
will
be
recorded
as
wanting
to
speak
of
course,
and
we'll
get
to
you
in
FIFO
order.
Doug
has
put
an
example
in
there
and
also,
as
Paul
has
said
since
I'll
be
managing
the
speaker
queue
and
facilitating
the
discussion.
I
would
love
for
someone
else
to
be
the
note-taker.
B
A
D
B
B
A
A
A
That
is,
like
realist
broker,
that
will
hit
the
sub
resource
and
let
give
you
a
CLI
way
to
do
that.
So
I
wanted
to
put
that
out
there
for
folks
to
go
and
take
a
look
at
so
that
we
can
discuss
it.
It's
something
that's
important
to
us
at
Red,
Hat
and
I
have
a
feeling
it's
important
to
focus
in
the
group.
We
have
previously
gotten
consensus
that
we
should
do.
We
should
solve
this
problem,
and
now
we
have
a
specific
proposal
to
evaluate
EOF.
A
I
think
that
would
be
I
think
it
would
be
great
if
folks
could
read
it
and
comment
on
it,
and
perhaps
we
can
talk
about
it,
maybe
early
next
week,
so
folks
have
a
little
bit
of
time
to
think
about
it,
but
at
Red
Hat
we
do
have
it
it's
staffed
for
somebody
to
work
on
it.
So
it
would
be
great
if
that
person
could
begin
work.
If
we
can
arrive
at
a
consensus.
A
B
B
A
So
the
gist
of
it
is
that
currently
we
hard
code,
the
flag
on
the
broker
client
that
activates
in
secure
TLS
can
verify
and
that's
not
really
suitable
for
production.
So
it's
also
very
common
in
the
the
ecosystem
to
have
to
have
processes
that
do
not
have
root
sign
certificates.
So
we
really
do
need
a
way
to
be
able
to
to
configure
the
CA
bundle.
That's
used
to
verify
the
that
the
verify
the
TLS
configuration
of
the
broker.
A
So
basically,
the
proposal
is
to
follow
the
precedent
that
already
exists
in
the
API
registration,
API
group,
and
basically
there
are
two
fields.
There's
a
field
called
in
secure
TLS
in
secure
skipped,
TLS
verify
that
governs
whether
the
that
flag
is
set
to
skip
the
TLS
verification
and
then
there's
also
a
byte
array
field
for
the
CA
bundle.
That's
used,
and
this
is
what
the
aggregator
already
uses
and
I
think
that
we
have
basically
the
exact
same
concerns.
So
I
think
there
are
three
permutations
to
just
quickly
talk
through
the
first
one.
A
Is
you
don't
want
to
verify
the
TLS
of
the
broker
you
can
set
unsecure
skip
verify
and
by
the
way,
let
me
just
say
aloud
that
the
proposal
is
that
we
just
add
those
two
fields
to
the
burglar
spec.
So
if
you
didn't
want
to
verify
the
TLS
of
the
broker,
you
can
set
the
insecure
skip,
TLS
verify
field.
If
you
wanted
to
rely
on
the
root
certificates,
for
example,
if
you
have
a
certificate
authority
sign
broker,
that
is
you.
A
You
could
just
not
set
anything
and
it
would
go
out
to
the
system
roots
and,
if
you,
so
that
would
be
suitable
if
you
have
a
root,
sign,
broker
or
II.
All
of
your
needs
and
kubernetes
are
part
of
a
private
key
infrastructure
that
configures
the
root
certificates
to
be
the
roots
plus
your
organization's
signings
see
a
bundle
or
some
combination
of
those
and
then
the
the
last
one
is.
A
B
A
If
we
have
no
objections
here,
I
will
probably
am
my
copious
spare
time
because
I'm
a
really
cool
happening
guy,
maybe
start
hacking
on
this
after
I
finished
from
my
next
couple
tasks.
I
won't
start
immediately.
It
probably
won't
be
tomorrow,
but
it
might
be
on
Friday
and
of
course,
I
wouldn't
expect
that
to
be
merged
immediately,
but
this
is
really
important
to
anybody
that
wants
to
eventually
use
Service
Catalog
in
production,
so
I
am
very
interested
in
getting
it
taken
care
of
shortly.
B
E
It's
here
on
the
lease:
if
you
scroll
down,
it's
I,
think
it's
the
last
item
here
to
discuss
today
and
currently
after
merging
rebase
11.7
between
between
controller
manager
and
API
server,
we
always
pass
the
insecurity
verify
flag,
but
it's
like
it's
not
the
best
solution.
I
guess
we
should
probably
solve
it
the
same
way
by
providing
see
a
bundle
or
something.
B
Okay,
so
I'll
pose
a
question
to
the
group:
should
TLS
verification
from
controller
manager
to
broker
be
treated
as
part
of
the
same
work
item
as
TLS
verification
from
controller
manager
to
the
Service,
Catalog,
API,
server
and
Paul.
You
have
a
H
stand
up,
which
I
assume
is
a
hand.
So
please
go
ahead.
It's
just
silent!
That's
what
it
stands
for
is
silent.
A
A
Okay,
I
think
so.
I
definitely
think
that
we
we
need
to
be
able
to
verify
the
TLS
in
the
controller
manager
of
the
API
server.
I
have
look
at
the
I.
Look
at
that
as
orthogonal
from
the
API
surface
and
associated
code
to
to
do
the
broker
TLS,
because
they're
one
one
is
a
behavior
of
the
control
and
one
is
a
like
functional
attribute
of
the
controller
at
a
very
fundamental
level.
B
So
it
sounds
like
we
should
address
this
per
broker,
TLS
config
now
and
then
down.
The
list
is
the
the
controller
manager
to
Service
Catalog
API
server
issue
which
we
can
address
later,
and
it
sounds
also
like,
if
there's
already
the
flag
for
it,
then
we
don't
really
have
to
do
anything.
Is
that
is
that
accurate
to
say
Neil,
Paul
and
everybody
else
even.
A
B
B
B
Great,
so
we
won't
put
a
timeline
on
the
prototype
in
the
meantime.
I
think
this
is
issue
1060
I
might
have
that
wrong.
But
in
the
meantime-
and
please
put
comments
on
the
issue:
if
you
have
them,
if
you
don't
have
them
now
than
have
them
later
in
the
next
couple
days,
issue
1064
next,
alright,
so
we'll
move
on
Neal
with
instance,
parameters
secret,
multi
map,
secret
multi,
key
map
limitations-
that
is
ten
to
twenty
eight
I,
think
mouthful.
F
E
So
the
P
R,
for
supporting
secret
parameters,
in
instance,
is
almost
done
and
we
agreed
that
we
will
have.
We
will
support
different
ways
of
passing
parameters
to
instance,
and
currently
we
have
three
and
we
could
probably
add
more
and
for
now
it's
multi
key
secret
map,
single
key
secret,
JSON,
blob
and
inline
Jason,
and
for
these
question
is
for
one
of
them
with
multi
key
secret
map.
E
So
currently
record
is
written
the
way
it
requires
each
value
in
key
to
be
a
valid
JSON,
and
the
question
is
whether
we
should
change
it
to
to
treat
it
as
a
plain
string
without
trying
to
pass
it
as
a
JSON
or
anything
and
just
which
means
that
with
multi
key
secret,
you
can't
can
only
pass
map
snap
map
of
string
to
string
and
like
if
you
want
to
pass
some
JSON
subtree,
you
have
to
use
a
single
key
jason.
Well,
if
it
works
for
everyone,
I
can
make
this
change.
Okay,.
B
C
E
G
C
I
definitely
agree
with
the
map.
With
this
map
of
string
to
string
yeah
I,
don't
like
the
idea
of
forcing
users
to
Jason
encode
all
their
values.
It's
not
I,
don't
think
that's
natural
for
people,
but
at
the
same
time,
I
do
think
we
should
support
the
idea
of
people
putting
part
of
their
data
in
secrets
and
part
of
their
data
as
a
normal
config
map
or
just
inlined
or
something
else
so
another
way
I
want
to
be
able
to
support
more
than
one
mechanism
at
a
time.
B
C
B
C
Maybe
that
was
it
yeah.
So
basically,
in
this
comment,
I
listed
off
some
of
the
use
cases
I
thought
of
where
data
would
come
from
and
I
wanted
to
know
whether
people
thought
that
was
the
right
list
or
whether
there
were
others
or
whether
include
things
in
there
that
weren't
appropriate.
Although
I'll,
let
you
guys
read
the
list
that
was
on
the
screen
right
there.
Okay.
H
Yeah,
just
one
quick
observation
that
if
we
update
the
CEO
lies,
it
has
the
kind
of
provision
sort
of
assessments
or
buying
we're
gonna
have
a
similar
problem
where,
if
you're
passing
parameters-
and
you
need
to
pass
a
boolean
or
something
you
might
not
be
able
to
do
it,
if
we're
always
cheating
in
this
point
stream.
Well,
maybe
that's.
Okay.
H
Just
try
to
think
ahead
because
I
actually
like
whatever
we
decide
here,
is
probably
what
we'll
want
to
do
on
the
COI
as
well
for
passing
parameters
or
maybe
compat
casing
on
the
CLI,
which
would
be
kind
of
ugly,
but
a
lot
of
support
in
any
type.
So
I
guess
I
also
wanted
to
ask
for
the
merging
strategy
and
I'm
just
trying
to
help
envision
how
that
would
work.
It's
like
I
have
a
secret
with
the
Jason
blob
and
then
have
another
Jason
in
the
incident.
H
So
it
would
like
go
through
and
try
to
merge
all
the
keys
into
one
object
and
then
handle
conflicts,
and
would
it
do
like
five
nested
objects
when
they
try
to
do
like
how
sophisticated
would
it
be
like
I
feel
like
it's
a
little
bit
complicated?
Maybe
it's
okay,
I!
Guess:
I'm,
not
clear
on
the
value
of
doing
that.
B
A
Commanding
and
a
backward
compatible
manner,
and
also
have
this
pull
request
open
for
quite
a
while
and
I.
Think
that,
what's
in
his
pool,
request
now
is
very
productive
and
it
gives
people
a
way
to
use
secret
information
and
parameters
without
having
to
put
it
into
a
resource
that
doesn't
have
the
right
semantics
to
store
secret
information
in
so
I.
Think
that
we
should
differentiate
between
is
knowledge,
pull
request
ready
to
go
in
versus?
B
A
B
A
E
Yeah
I
just
wanted
to
briefly
mention
that
for
merging
strategy,
I,
don't
think
we
need
want
to
support
any
smart
merging
of
like
deep
conflict
resolution
or
anything
I
would
just
quickly
fail
on
any
conflict.
But
it's
probably
a
separate
discussion.
I
wanted
to
say
yeah
and
the
only
change
in
my
core
PR,
which
I
need
to
do
before
merging
I.
Think
it's
to
switch
from
map
from
string
to
JSON,
to
bat,
from
string
to
string
for
multi,
key
secret
and
I
think
that's
it.
B
B
Please,
no
abusing
the
cue
systems,
no
daus's
of
the
queue.
Thank
you
okay.
So
what
I'm
hearing
is
that
we
should
come
back
and
discuss
yeah.
We
should
come
back
and
discuss
emerging
strategy,
but
prefer
to
get
Neil's
PR
in,
as
is,
does
anybody
disagree
with
that
decision
strategy,
whatever
we
want
to
call
it
right
now,.
B
Okay,
so
I'm
not
hearing
any
disagreement
with
that
any
objections
to
the
PR.
So
what
Doug
is
writing
up
right
now,
kneeled
to
make
tweaks
that
he
needs
to
make
to
the
current
PR
and
get
that
in
sounds
like
the
right
thing?
Paul
I
get
to
you
in
one
second,
but
we
certainly
since
we're
going
to
do
that.
We
certainly
should
come
back
and
discuss
merging
strategy
later
in
a
follow-up
Paul
go
ahead.
I.
A
A
There's
there's
a
parameters
field
right
now.
Actually,
if
I'm
failing
to
remember
if
it's
called
parameters
or
alpha
parameters,
if
it's
called
alpha
parameters,
we
can
easily
say
that
that
field
is
deprecated
and
we'll
remove
it
in
a
future
release.
But
I
would
like
to
avoid
breaking
people
that
are
currently
used.
Yeah.
That's
that's
too
bad
I'd
like
to
avoid
breaking
people
that
are
currently
using
it
with
that
giving
them
some
lead
time,
but
we
can
talk
about
that
on
the
issue.
Unless
people
really
want
to
talk
through
it
right
now,.
B
A
A
B
B
B
E
C
E
Requirement
in
this
spec
is
that
duplicate,
create
requests
both
foraging
in
instance
and
creating
abiding
should
be
harmless
and
don't
lead
to
provision
and
duplicate
resources.
They
just
should
so.
There
is
a
like
explicit
saying
that
if
the
parameters
have
been
sent
before-
and
they
are
exactly
the
same-
just
return,
200,
okay
and
do
nothing.
Okay,.
A
So
I
think
that
we
need
it.
So
first,
let's
address
the
the
facet
about
it
evidenc
or
idempotency.
I
don't
think
that
I
don't
think
that,
because
that,
just
because
a
duplicate
request
should
give
you
back
a
200
I
do
not
think
that
implies
that
it
is
acceptable
to
continually
make
provision.
Requests
and
I
could
I
suspect
that
eventually
will
probably
rate
limit
traffic
to
to
brokers
on
a
per
broker
basis,
and
that
would
definitely
interfere
with
rate
limiting.
B
A
The
I
think
the
check
sums
are
aligned
more
with,
like
there's
the
checksum
of
the
spec
and
then
there's
the
checksum
of
the
parameters
separately
from
that,
because
since
we
now
have
this
level
of
indirection
between
the
instant
spec
and
binding
spec
well,
assuming
in
the
future,
we're
going
to
get
it's
not
relevant
today
for
bindings,
but
in
the
future
it
seems
likely
will
get.
Finding
updates.
A
A
Here's
the
thing
we
can't:
we
can't
have
one
that
just
does
both,
because
we
don't
have
the
the
API
server
actually
updates
the
checksum.
Currently
I.
Guess
we
could
we
could
futz
around
with
it.
Maybe
we
can't
rule
out
being
able
to
have
just
one,
but
we
do
need
to
be
able
to
differentiate
an
update
versus
a
create
and.
A
B
A
B
F
B
But
yeah,
okay,
cool,
okay,
I,
don't
see
any
more
hands.
Any
last
minute
comments.
Questions
for
this
going
once
okay.
So
let's
move
on,
we
covered
this
next
point
a
little
bit,
at
least
in
the
earlier
TLS
discussion.
So
Neil
can
you
just
briefly
repeat
the
summary
of
what
TLS
verification
between
controller
manager
and
API
server
means
yeah.
E
So
as
part
of
your
basing
on
21.7,
the
communication
between
controller
manager
and
API
server
was
broken
due
to
TLS
verification,
so
to
avoid
hard
coding,
I
just
added
a
flag
to
controller
manager
to
keep
Telus
verification
and
I
didn't
do
anything
from
that
and
I
I
and
pulls
out
that
we
already
support,
say
C
a
bundle
in
controller
manager,
but
I
haven't
seen
it.
We
should
probably
check
if
it.
If
that's
the
case,
update
the
round
chart
and
yeah.
A
B
B
C
Okay,
so
the
last
call
was
last
call:
we
talked
about
how
potentially
we're
currently
doing
user
provided
services
may
not
provide
the
best
user
experience.
I'm
particular
forcing
people
to
bring
up
a
user
provided
service
broker
was
a
little
bit
awkward,
as
well
as
forcing
them
to
define
an
instance
with
a
plan
name
of
default,
even
though
it
doesn't
have
plans
just
didn't
feel
quite
right
either.
C
So
I
took
an
AI
to
go
off
and
see
if
there
was
something
we
could
do
here
to
make
it
a
little
bit
better
after
looking
at
this
and
actually
to
address
when
all
suggested
last
time,
which
was
why
don't
we
basically
skip
the
service
broker
concept
entirely
and
just
go
with
straight.
You
know
let
the
user
create
the
secrets,
and
then
they
can
use
hot
preset
or
POC
reset
binding
we'd
ever
come
up
with
and
just
do
the
binding
themselves
manually
and
that
that
sounds
really
cool.
C
But
the
problem
was
I
found
with
that
is
from
an
end
user
perspective.
They
now
don't
have
the
ability
to
see
a
an
instance
representing
that
secret
than
essence
right,
because
if
you
run
into
a
situation
where
you're
in
an
environment
where
one
person
is
going
to
be
creating
all
the
service
instances
because
they
have
the
authority
to
do
so,
but
then
you
have
another
person,
who's
solely
responsible
for
doing
the
binding,
because
they
don't
have
the
authority
to
create
the
instance,
but
they
can
actually
hook
it
up
to
applications.
C
That
person
does
the
hooking
up.
The
applications
should
be
able
to
just
do
the
equivalent
of
a
give
me
the
list
of
service
instances
and
see
the
user
provided
instances
show
up
the
exact
same
way
as
normal
service
instances.
They
shouldn't
necessarily
know
the
difference
between
how
they
were
created,
normally
versus
use,
provided
so
I
didn't
think
that
that
way
was
gonna
work
for
us
just
from
a
usability
perspective.
So
then
I
started
thinking.
Okay!
C
Well,
if
I
want
that
functionality
of
being
able
to
say
give
me
the
list
of
service
instances,
regardless
of
whether
they're
normal
versus
user
provided
the
way
I
could
think
of
doing.
It
was
to
pretty
much
overload
instance
spec
itself,
and
so
my
proposal
here
is
to
say:
if
you
look
on
the
screen,
you
see
three
different
fields:
they're
out
of
the
service
class
name,
the
planning,
the
parameters,
those
are
currently
what
signals
that's
currently,
what's,
in
instance
spec.
So
what
I'm
suggesting
is?
C
We
have
a
reserved
service
class
name
of
something
like
kubernetes
user
meta
service
or
something
like
that
when
that
is
used
and
name
must
be
absent,
which
basically
means
plan
name
is
now
optional.
When
that
reserve
service
plan,
our
service
class
name
is
not
used,
then
it
then
plan
name
is
required.
C
Then
we
can
use
the
parameters
field
to
store
the
credentials,
whether
that's
in
line
pointing
to
secrets.
We
can
use
the
exact
same
mcmechen
ism
that
we're
doing
for
parameters
in
other
places,
but
I
think
that
should
give
us
what
we
want
if
we
had
the
appropriate
logic
into
the
covers
to
handle
those.
Those
checks
and
I
think
that
is
gonna
provide
the
consistent
user
experience
that
I
think
we
need
going
forward.
So
let
me
go
ahead
and
stop
there
cool,
okay,.
E
C
So
the
from
the
from
the
users
perspective,
the
life
cycles,
the
exact
same
Ukraine
instance.
You
then
bind
to
the
instance
that
doesn't
change
at
all.
What
would
change
is
under
the
covers,
rather
than
the
controller
calling
out
to
the
broker
to
do
the
create
binding
call.
It
just
uses
the
parameters
as
the
credentials
immediately.
It
doesn't
need
to
go
off
to
the
third
party
to
get
it.
It
has
all
the
information
already
so
Clemente,
but
so
for
the
end
user
perspective,
there's
no
change
whatsoever.
It's
the
exact
same
lifecycle.
B
A
So
I
will
avoid
making
a
statement
about
whether
I
think
that
we
should
do
this
for
now,
but
I
will
make
a
statement
that
I
don't
think
this
should
be
a
requirement
for
beta
it's
it's
not
actually
part
of
the
open,
serviceworker
API
spec.
It's
part
of
the
experience
that
Cloud
Foundry
is
built
around
it
and
I.
Think
that
having
a
similar
experience
is
good,
I'm,
not
sure
if
it's.
If
this
is
a
must-have
for
beta,
because
I
my
concern
would
be
that
it
would
complicate
the
controller
significantly
just
wanted
to
throw
that
out.
B
G
C
G
C
G
C
C
Because
what
I
was
saying
earlier
of
I
think
requiring
people
to
stand
up
a
an
explicit
broker
to
get
this
functionality
is
feels
very
awkward
to
me
as
I
was
playing
with
it.
If
I
like
a
lot
of
extra
work,
when
I
thought
it
should
be
sort
of
built
into
the
system
and
also
when
it
is
a
separate
broker,
the
plan
name
is
right.
Now
a
required
field,
and
in
order
to
create
a
user
provided
service,
you
have
to
give
it
a
plan
name.
C
G
I
think
I
didn't
get
a
good
user
experience
got
it
I.
Also
remember
that
we've
had
discussions
in
the
past
about
if
there
is
a
plan,
if
there
is
a
service,
that
only
has
one
plan
that
it
might
be
optional
is
meaning
we
would
just
choose
whatever
or
am
I
dreaming.
They
can
be
able
to
talk
about
them,
cuz
that
would
address
the
second
yeah.
C
G
C
You
still
have
more
yeah
I
was
I,
was
gonna,
say
I
like
a
lot
of
things,
I,
don't
care
so
much
about
getting
the
functionality
and
for
beta,
even
though
I
do
think.
It's
a
critical
piece
to
function.
I'm,
okay,
with
pushing
out
the
implementation
of
it
host
beta,
but
I
do
think
the
design
needs
to
be
agreed
upon
before
beta
Neely,
because
if
something
happens
like
let's
say,
we
actually
have
got
my
proposal
here.
C
A
In
general,
for
special
cases
like
this,
I
would
be
in
favor
of
making
a
union
type
that
if
we
can
find
some
construction
of
that
Union
type,
that
yields
the
yields
the
right,
a
good
experience
for
things
that
aren't
user-provided
and
also
lets.
You
indicate
that
something
is
either
provided.
I
think
that
that
would
be
the
best
way
to
do
it,
and
then
we
don't
necessarily
have
to
block
on
figuring
out
the
design
and
adding
new
semantics
for
fields
and
stuff
like
that.
A
I
am
Not
sure
that
if
say
that,
like
saying
we
decide,
we
want
to
have
user
provided
services
I'm,
not
sure
that
the
best
API
for
that
is
to
is
to
have
the
same
fields
take
on
different
meanings.
I
think
this
were
Union
type
kind
of
shows
its
value,
so
we
might
just
consider
that,
but
yeah
I
agree
if
Union
type
versus
change
meanings
of
the
fields.
Probably
it
would
be
best
if
we
decide
whether
we
want
to
do
this.
A
B
C
I
just
want
to
clarify
that
I,
don't
think
I've
changed
the
semantics
of
any
of
the
properties
in
there
with
my
proposal,
but
the
only
thing
I
would
ask,
though,
is
I
I'm,
not
wedded
to
my
exact
proposal.
That's
fine!
The
only
thing
I
would
ask,
though,
is
if
people
don't
like
the
proposal
that
they
put
concrete
alternatives
into
the
issue
itself
rather
than
us
just
leaving
it.