►
From YouTube: Kubernetes SIG Service Catalog 20170731
Description
- Broker relist behavior
- Bearer token auth
- Union type for different modes of addressing service classes and plans
A
Okay,
welcome
everybody
to
be
Monday,
July
31st,
2017,
meeting
of
kubernetes
SIG's
Service
Catalog,
as
Jimmy
szalinski
is
observed.
Nearly
everybody
has
their
webcam
on.
So
this
will
probably
be
a
very
interesting
meeting.
Let's
see
first
up
on
the
agenda
today
is
is
further
discussion
on
broker
realist,
behavior.
C
B
B
Put
you
at
the
end
of
the
speaker:
queue
with
my
highly
technology,
speaker,
queue
system,
pen
and
paper,
and
we
are
going
to
start
in
the
agenda
here
with
Paul
talking
about
per
broker,
realist
behavior,
and
that
is
issue
number
7:05
I'm
going
to
include
a
link
to
the
document
here,
I'm
going
to
be
taking
notes
today,
but
I'm
not
going
to
be
able
to
share
my
screen,
take
notes
and
manage
to
speak
your
cue
all
at
once.
So
please
go
ahead
and
start
Paul
and
I
encourage
everyone
else
to
have
the
doc
open.
B
A
There
are
three
facets
to
this.
Overall,
the
use
case
that
we're
trying
to
solve
is
that
right
now
there
is
basically
a
single
realest
interval
for
every
broker.
That's
a
property
of
the
controller,
and
that's
not
really
enough.
So
the
things
that
we
want
to
enable
are
a
explicit
realist
interval
that's
configured
on
a
per
broker
basis.
A
We
also
and
in
addition
to
relisting
on
an
interval,
you
should
also
be
able
to
say
that
you
only
want
a
realist
when
a
user
manually
sets
its
time
and
in
addition
to
that,
there's
a
desire
to
have
a
porcelain,
a
CLI
command.
That
will,
let
you
say
something
like
keep
CTL
service.
Catalog
realist
broker
broker
name.
C
A
Basically,
the
proposal
from
an
API
standpoint
is
to
add
two
fields
to
Brooker
spec.
One
of
them
is
the
realist
behavior,
which
is
a
an
enum
that
can
right
now
be
do
it
on
a
duration
or
do
it
manual
only,
and
then
the
next
field
is
the
realist
duration,
which
is
a
meta
v1
duration,
which,
if
you're
not
familiar
with
that,
it
basically
allows
you
to
specify
the
interval
syntax,
we're
probably
all
familiar
with
like
1h
from
one
hour
and
the.
A
How
this
would
work
from
an
API
standpoint
is
that
the
default
in
this
proposal
is
that
the
behavior
should
default
to
a
duration
and
the
realist
duration
itself
should
default
to
I
shows
a
fairly
arbitrary
interval
of
15
minutes.
I
would
certainly
like
to
discuss
whether
that's
an
appropriate
value
as
a
default.
It's
more
of
a
strawman
to
start
discussion
on
and
if
you
specified
duration,
every
every
time
that
duration
elapsed,
the
controller
would
go
and
realist
the
realist.
A
The
broker
services
like
do
they
get
on
the
catalog
end
point
and
run
the
realist,
reconciliation
logic,
which
is
a
separate
issue
for
by
the
way
as
I've
just
remembered,
and
if
you
were
to
do.
If
you
were
to
say
manual
only
you
would
only
the
controller
would
only
do
that
when
the
user
specified
manually
that
it
should
be
done
so
to
handle
the
manual
case,
there
will
be
a
new
rest
sub
resource
for
brokers.
A
Sorry
I'm
failing
to
remember
if
we
have
to
check
some
right
now,
I
think
Jeff
has
just
added
one.
But
if
you
were
to
hit
this,
if
you
were
to
hit
this
sub
resource,
it
would
make
the
broker
look
like
it.
Hadn't
yet
been
reconciled
and
trigger
the
controller
to
go
and
fetch
the
catalogue
and
reconciling
so
you
in
the
event
that
you
had
a
duration
configured
for
relisting
a
broker.
A
You
could
just
use
this
same
endpoint,
which
is
exactly
what
the
CLI
the
porcelain
command
would
do
and
manually
relist
off
the
schedule
at
a
high
level.
That's
pretty
much
what
the
proposal
aims
to
do
and
how
aims
to
do
it.
I
I,
wonder
if
folks
have
any
reactions
to
this
other
use
cases
they
want
to
support,
eat
left
for.
E
So
my
question
is
that
you
need
to
store
the
somewhere
in
the
status
last
update,
timestamp
right
to
reliably
released
and
also
if
the
user
invokes
the
resource
for
releasing.
You
also
need
to
set
some
field
the
that
to
register
the
fact
that
released
was
requested.
Yes,
you
don't
just
synchronously
processed
it,
but
you
need
to
reliably
retry
releasing
right.
Yeah.
A
That's
correct
so
in
the
and
I
think
this
is
actually
spelled
out
explicitly
in
the
the
issue
text,
but
I'll
go
ahead
and
explain
it
at
that
level
of
detail.
So
currently
the
ready
condition
has
the
last
transition
time
field
and
that
stores
at
what
point
the
broker
became
ready.
This
it's
sufficient
for
our
purposes
for
this
to
just
have
that
sub
resource.
To
do
the
realist,
clear,
the
ready
condition
and
the
controller
will
say:
hey
I
haven't
worked
on
this
yet
I'll
go
and
realist
it,
but
you're
right.
It's
not
processed
synchronously
it.
C
A
That's
a
really
good
question
and
I
believe
there's
actually
a
separate
issue
to
deal
with
all
of
the
corner
cases
of
relisting.
This
is
basically
the
scope
of
this
one
is
just
about
establishing
the
interval
and
API
constructions
to
let
you
do
it
and
not
actually
solving
the
problem
of
what
happens
when
something
weird
unexpected
happens
during
a
realist.
So.
C
You
think
it
makes
sense
to
not
have
us
on
an
interval
then,
and
have
it
essentially,
unlike
API
calls
so
say,
I
actually
request
to
do.
An
action
like
I
want
to
create
an
instance
of
this
thing.
Then
I
specify
a
flag
that
says
go
out
and
relist
that
way
you
can
have
like,
and
it
comic-like
wait
a
step
through.
If
you
need
to
like
rollback
states.
You
can
say
this
is
what
the
list
goes
before.
C
A
It's
a
I
think
that
it's
sufficient
to
support
manual
only
so
that
if
you
want
to
make
I
all
of
your
brokers
in
your
instance
of
the
catalog
manual
refresh
only
you
should
be
able
to
do
that.
I'm,
not
sure
exactly
what
you
mean
about
a
lockstep
thing,
but
atomic
semantics
are
very
difficult
to
achieve
in
kubernetes
style
api's,
just
because
of
the
nature
of
the
system
right,
like
I
I,
think
it
might
help
the
discussion,
though,
if
you
clarify
your
suggestion,
a
little
bit
yeah.
C
C
A
A
Sure
so,
like
the
say
that
I
make
this
resource,
which
basically
I'd
want
to
post
I,
think
to
the
realist,
the
realist
sub
resource,
similar
to
how
the
binding
resource
and
the
core
and
again
the
naming
collision
haunts
us.
What
I'm
talking
about
is
there
is
a
resource
called
binding
in
the
core
API.
That
is
how
the
scheduler
makes
an
assignment
to
a
pod
from
an
upon
to
a
node,
and
that
has
a
a
special
type.
A
A
So
it's
possible
to
capture
that
in
like
an
API
level
construction,
but
we
have
no
notion
of
ordering
in
API
operations
and
you
have
to
you
know
you
have
to
basically
anticipate
that
any
API
action
might
be
taken
at
the
same
time
with
other
API
actions.
So,
for
example,
if
I
could,
if
I
had
a
resource
to
model
the
realist
request
and
I
created
it.
At
the
same
time
as
I
may
be
instance,
I
would
have
basically
no
guarantee
that
the
controller
would
be
able
to
process
the
realist
resource
before
it
started.
B
A
D
A
So
I
think
that,
probably
for
now
it's
sufficient
for
us
to
get
agreement
on
this
I.
Actually
I
do
want
to
point
out,
in
fact
that
if
we
did,
if
we
added
this
surface-
and
maybe
we
don't
need
to
wait
until
the
the
realist
behaviors
are
fully
figured
out
because
we
already
do
the
realist
so
we're
actually
not
making
anything
more
broken.
We're
just
controlling
the
interval
effectively
that
we
could
brave
but
I
do
it.
A
A
A
B
Let
me
put
a
suggestion
out
there
so
Paul.
Would
you
take
an
action
item
then
to
work
with
Jamie
to
come
up
with
a
solid
proposal
involving
that
extra
resource
get
that
proposal
done
this
week
so
that
we
can
talk
about
it
by
the
end
of
the
week,
Thursday
and
then
or
next
week,
with
implementation
in.
A
A
A
B
F
F
B
F
So,
partly
without
the
actual
solid
requirements,
I'm
just
going
to
speak
to
API
Machinery's
perspective,
Etsy
DS,
generally
not
good
for
large
objects.
It's
also
doesn't
tend
to
have
things
like
indexing,
which
I
guessing
is
going
to
come
in
as
one
of
the
primary
requirements
and
API
machinery
would
like
to
get
to
the
point
where
we
get
other
people's
data
out
of
our
@cb
instance.
F
Since
we
see
with
larger
customers
that
too
many
users
and
data
that
isn't
well
behaved
can
cause
problems
for
the
kubernetes
core,
so
we'd
like
to
see
is
make
something:
that's
a
little
more
generically
useful
for
use
cases
that
are
not
the
API
machineries
and
get
you
know
in
that
way.
You
know
convince
people
that
they're
better
off
over
there,
then
in
our
SVD
instance,
so
that
make
sense
or
should.
F
C
F
A
A
And
the
chat
saying
that
Walter,
it
would
be
good
when
you
create
this
message,
if
you
would
cross
posts
with
the
API
machinery
and
then
I
have
made
a
joke
about
@cd
killing
the
operator,
if
you
put
more
than
one
Meg
into
an
individual
record,
but
I
didn't
use
the
hand
thing
Aaron,
because
I
didn't
want
to
raise
my
hand.
Oh.
B
That's
cool.
That
was
a
feature
not
a
bug.
Okay,
I
wanted
to
make
sure
we
get
that
out
there
so
so
Walter
for
soliciting
feedback,
I
think
it'd
be
good
to
put
a
post
in
our
group
and
then
Paul
would
like
an
API
machinery
that
would
be
perfect.
I
think
you
can
put
a
timeline
on
it
for
how
long
you
want
to
let
use
cases
come
in,
and
then
you
can
come
back
to
this
group
and
or
API
machinery
as
well
go
alright.
B
E
So
currently,
we
support
only
basic
owl
support
and
the
current
types
API
is
just
having
a
link
to
the
basic
auth
secret
and,
in
order
to
add
the
support
for
other
authentication
types
currently
just
bearer
token.
We
need
to
change
this
API
and
currently
the
way
I
address.
This
is
just
by
renaming
basic
owl
secret
to
our
secret
and
adding
an
extra
field
secret
type,
which
is
essentially
a
enumeration
type
which
size
whether
it's
a
basic
health
or
beaver.
Talking
and
aaron
has
commented
on
the
GAR.
E
E
The
third
option
is
to
make
a
union
type
more
explicit
and
say
that
we
have
not
basic
our
secret
directly
but
have
a
basic
health
section
and
then
have
we
were
talking
our
section
and
then
whatever
other
authentication
type,
we
wanna
support
and
it
will
make
it
completely
flexible
and
isolated
from
so
like.
If
you
want
to
work
with
basic
out,
you
jump
into
a
particular
branch
of
this
type,
and
you
see
that
you
need
to
specify
the
secret
it's
something
like
that.
A
Yeah
so
I'm
personally
in
favor
of
a
union
type
for
this,
because
it's
very
tempting
to
feel
like
you
could
add
a
tight
field
in
that
your
existing
fields
would
be
portable,
but
I
think
that
we
have
an
example.
That
is
something
that's
a
valid
use
case.
That
would
shatter
the
fields
that
we
currently
have,
and
that
example
would
be
in
the
case
of
if
you
wanted
to
do
mutual
TLS
and
have
the
and
have
the
broker
authenticate
the
verify.
The
TLS
from
the
controller
to
the
broker.
A
So
if,
if
you
can,
if
you
can
frame
a
counter
example
that
we
could
do
TLS
with
a
secret
name
and
key,
that
would
be
fine
but
I.
Think
in
general,
my
strong
preference
from
previous
API
work
in
kubernetes
is
to
use
union
types.
Even
when
you
are
positive
that
you
can
get
away
with
a
type
field
that
changes
the
behavior
of
other
fields
in
an
object
spec,
because
if,
when
you're,
when
you
have
a
new
example
that
you
can't
fit
into,
then
you
have
to
add
a
new
top-level
field.
A
E
Sense,
yes,
that
makes
sense.
I'm
fine
with
this
and
I
agree
that
colorful
secret
type
is
basically
an
easy
way
to
implement
to
make
it
to
make
the
change
to
support
peer
of
talking.
But
if
we
start
using
like
it
x.509
or
any
other
authentication
mode,
it
will
be
irrelevant
because
for
some
types
of
authentication
we
don't
need
security
at
all,
for
example,
and
then
secret
type
doesn't
even
make
sense.
So,
yes,
I,
agree
that
probably
it
makes
sense
to
just
have
a
union
type.
A
B
B
A
D
D
That's
what
I
was
one
I
want
to
make
that
explicit
either
either
say:
oh,
it's
not
there.
Then
it's
no
auth
or
it's
explicitly
set
to
be
nothing
and
that's
know
also
whatever,
whatever
the
appropriate
thing
to
do.
There
is
that's
all
I
just
want
to
make
sure
it's
written
down
what
the
decision
is.
Okay,
Paul,
it's
the
ground.
We
have.
Nothing
is
nothing
so
yeah.
A
B
Morgan
you
correct
me
if
I'm
wrong
sounds
like
as
long
as
we
can
support
it.
You're!
Okay!
For
now,
yeah!
No
I'll!
Look
at
what
comes
out!
That's
all!
Okay,
all
right!
So
we've
got
the
suggestion
down
here.
That
sounds
like
Paul,
Nile
and
Morgan.
You
guys
are
all
ok
with
this
that
I've
written
in
the
notes.
B
First
of
all,
does
anybody
have
any
objections
to
what
I've
written
and
what
those
guys
have
come
up
with
going
once
all
right,
so
what
I
would
suggest
is
for
Paul,
Niall,
Morgan
and
possibly
others
to
take
this.
This
idea
put
it
into
a
new
proposal
by
this
week
as
well,
so
we
can
get
to
implementing
it
by
next
week.
Do
any
of
you
guys
have
objection
to
doing
that?
I.
B
So
now,
when
you
say
you're
gonna
make
a
change,
are
you
gonna
make
the
change
in
that
PR?
Yes,
I
will
just
update
it.
Okay,
I
think
that
the
PR
already
has
this,
but
just
in
case
I'm
wrong.
Can
you
put
in
the
the
initial
post,
the
o
P
from
the
PR,
exactly
what
is
happening
here
with
regards
to
the
old
field
in
the
new
field.
B
A
Sure
so
there
we've
had
a
few
discussions
about
what
the
right
mode
of
addressing
service
classes
and
service
I'm
sorry,
service
classes
and
service
plans
is
the
difficulty
is
that
open
service
broker
API
does
not
have
a
stable
human
readable
coordinate
to
use.
So
the
open
service
worker
API
has
an
ID
which
is
supposed
to
be
a
grid,
but
it
has
very
few
semantics
about
format.
A
A
There
there's
been
discussion
in.
Let's
see
if
I
have
my
issue,
numbers
right,
802
and
that's
primarily
where
the
discussion
has
been.
It
occurred
to
me
this
weekend
that
we've
been
falsely
or
arbitrarily
constraining
ourselves
to
try
to
find
a
one-size-fits-all
solution
for
this
problem
and
I.
Don't
think
that
we
actually
had
to
do
that
and
so
I
I
will
go
ahead
and
open.
The
I
will
open
the
pull
request,
which
I'll
then
link
into
the
dock
or
I'm.
A
A
part
of
this
proposal
is
that
we
use
the
open
serviceworker.
Api
ID
of
service
class
and
plan
is
the
name
and
have
a
separate
field
for
the
human,
readable
name
and
the
two
modes
that
I
propose
that
we
support
initially
are
to
address,
using
the
open
service
broker
ID
of
the
service
and
plan
directly
and
then
also
to
have
a
mode
where
we
reference
using
the
human
readable
names.
A
And
so
this
way
we
don't
have
to
try
to
find
a
one-size-fits-all
solution,
and
we
can
support
these
two
different
ways
on
how
I
propose
that
the
human
readable
names
work
is
that
I'm
sharing?
So
you
can
all
see
this
so
when
you,
when
you
just
use
the
open
service
worker
IDs
directly,
there's
a
field
in
this
Union
type
that
takes
on
the
direct
reference
where
you
specify
service,
class,
ID
and
service
plan
ID,
and
just
for
the
just
for
the
record.
A
A
This
type
also
has
fields
for
service
class
ID
in
service
plan
ID,
and
when
you
create
a
resource
that
uses
this
human
readable
name
scheme,
there
will
be
an
omission
controller,
dereferences,
the
human
readable
name
and
sets
it
on
the
service
class,
ID
and
service
plan.
Id
fields
of
this
human
readable
name
struck
as
it's
being
created,
and
then
the
controller
can
use
those
to
do
the
work.
A
So
some
points
about
this
that
I'll
mention
is
are
that
we
should
have
some
validations
for
this
to
make
sure
that
only
a
single
field
is
set,
that
you
can't
move
from
one
scheme
to
another
during
an
update
which
I
think
might
be
doable
in
the
future.
For
now,
we
definitely
shouldn't
do
it
because
it
seems
like
a
rat's
nest
of
corner
cases
to
get
into,
and
we
should
also
make
sure
that
a
service
that
the
service
class
ID
doesn't
change
during
an
update.
A
E
A
Where
does
the
instance
of
the
service
come
from
that
are
easiest
to
implement
if
we
use
a
union
type
now
and
I
personally
think
it's
best
to
be
explicit
about
what
the
original
intent
of
the
user
was,
which,
in
the
case
of
secret,
you
can't
recover,
because
the
the
string
data
fields
are
right,
only
I
argue
and
by
the
way
for
anybody
that
isn't
familiar.
What
knowledge?
What
nioh
is
talking
about
is
the
secret
API
resource
has
a
data
field.
A
A
Byte
arrays
in
JSON
are
treated
as
base64
encoded
strings
and
so
as
a
convenience.
There's
a
string
data
field
that
allows
you
to
specify
string
values
that
are
only
there
right.
Only
so
when
you
create
a
secret
that
populates
the
string
data
field,
it
results
in
the
secret
being
created
having
those
in
the
data
in
the
data
field.
You
don't
actually
get
the
string
data
fields
back
out,
which
probably
I
can
say
this
with
certainty,
because
I
am
actually
the
original
creator
of
secrets
and
I
can
tell
you.
A
A
B
So
now
I'll
get
to
you
and
just
once
again,
I
would
recommend
that
everyone
go
and
read
this
very
detailed
proposal.
It
looks
it's
like
I,
said
very
detailed,
looks
complete
in
terms
of
what
Paul
is
suggesting.
I'd
recommend
that
everyone
goes
and
does
that
as
soon
as
they
can
so
that
we
can
talk
about
this
in
more
detail.
B
E
A
B
Sorry,
I'm
just
typing
one
less
little
note
here:
all
right
so
does
for
now.
Does
anyone
have
any
questions
or
comments
about
this
point,
one
once
okay,
so
as
I
said,
I
think
what
I
personally
would
suggest
is
that
we
all
take
an
action
item
to
go
and
read
through
this
issue
post
any
comments
or
questions
in
the
issue.
B
A
A
I
also
find
commenting
on
github
to
be
irritating,
but
it
helps
a
few
consensus
faster
if
we
can
just
bite
the
bullet
input
comments
into
github
I
mean
otherwise.
You
gotta
wait
until
you
have
a
chance
to
talk
about
it,
and
then
you
gotta
go
and
like
if
there's
feedback
to
address
address
it.
So
I
appreciate
it.
If
everybody
who
has
an
opinion
on
these
subjects
would
be
willing
to
comment
on
it
and
github.
B
All
right,
sorry,
I'm,
writing
some
notes
here
on
the
action
items.
So,
as
I
said,
everyone
read
the
proposal
thoroughly
make
notes,
preferably
in
the
github
thread,
so
that
we
start
addressing
them
early
and
I
will
schedule
further
discussion
on
this.
For
later
this
week,
Paul
I
see,
did
I
address
your
hand
up
already.
Okay,
sorry
I
forgot
about
that
all
right.
Does
anyone
have
any
final
questions?
Comments
objections
on
this
last
point
today
on
once
all
right
now,
one
final
thing:
Niall,
you
had
a
hand
up
on
the
second
to
last
item.