►
From YouTube: SIG Service Catalog Open Service Broker API Spec Review
Description
The SIG reviews the entire Open Service Broker API and creates issue for any gaps in compliance with the spec.
A
All
right
so
welcome
to
a
special
edition
meeting
of
kubernetes
big
Service
Catalog.
It
is
Tuesday
May,
9th
1400
hours
and
seven
minutes
on
the
eastern
coast
of
the
United
States
of
America
welcome
everybody.
Today
we're
going
to
go
through
the
open
service
broker,
API
spec
and
we're
going
to
create
some
issues.
If
we
feel
there
are
any
gaps
that
we
have
to
close
so
I'm
going
to
go
ahead
and
share
my
screen
and,
let's
see
say
here,
I'll
just
load
up
the
spec.
A
A
B
A
B
C
D
C
Now,
having
said
that,
for
debug
or
or
backwards
compatibility
issues,
I'm,
okay
with
us
having
a
flag
someplace
like
an
environment
or
something
that
allows
us
to
override
it
for
globally,
not
on
a
per
broker
basis.
We
have
that
cases
for
other
products
where,
for
some
reason,
someone
can't
step
up
and
I
need
to
send
this
old
version
of
the
header,
and
there
is
no
way
to
change
without
going
and
recompiling
the
product
and
that
wasn't
good.
Okay,.
D
E
D
And
I
just
want
to
be
very
clear
on
what
it
is
that
we
are
trying
to
do
here,
because
if
it
is
just
being
able
to
go
and
say,
hey
I'm
going
to
be
able
to
support
this
string,
that's
fine
I
trying
to
go
ahead
and
say
that
our
broker
is
going
to
support
in
different
versions
at
any.
Given
time
is
a
complete
disaster.
B
A
B
A
D
A
C
A
So
and
I
think
that's
a
valid
use
case.
So
if
someone
wants
to
go
ahead
and
create
that
issue,
we
can
we
can
debate
it
later,
I
think
for
now.
Let's
just
try
to
do
chainsaw
level.
Is
there
a
thing
to
talk
about
later
on
and
if
there
is,
we
can
make
a
we
can
make
issues
and
sort
of
mount
later
provided
people
are
okay
with
that
I.
A
The
only
other
thing
that
I
see
here
is
that
a
the
broker
might
reject
a
request
with
the
for
1/2
code
and
I.
Don't
know
that
we
would
necessarily
surface
that
in
a
way
that
was
understandable
to
people.
Do
we
need
an
issue
for
that,
like
handling
a
for
1/2
error
code
and
saying
Brooker
says
it
can't
support
this
operation
because
it
doesn't
support
the
version
of
the
API
or
Center
I.
D
D
Worried
about
is,
if
we
say
I
have
to
go
to
back
to
211
and
there's
something
that
has
been
attitude.
Then
we
have
to
keep
track
of
it
and
say
like
okay.
Well,
it's
a
211,
so
do
not
send
these
fields
or
some
like
that
or
sent
these
fields
differently.
That's
my
worry
and
and
I
think
that's
that
that's
the
part
that
I
think
is
going
to
be
a
disaster,
but
maybe
I'm
just
complicating
it
too
much,
but
it
seems
like
it's
a
very
tricky
moving
forward
to
support
and
then
have
the
condition.
D
B
D
A
A
A
D
I
think
there's
an
issue
on
this.
I
mean
this
is
part
of
the
reason
why
I
have
to
add
that
little
hacky
for
I'd
paired
up
and
then
I
think
Aaron.
You
and
I
talked
about
a
couple
of
different
ways
of
solving
this
and
I.
Think
in
your
issue
said:
here's
a
couple
of
the
Year
at
the
top
on
there.
You
go
okay,
Wow.
A
Is
a
really
good
question?
In
fact,
we
are
talking
not
right
at
this
moment,
but
on
going
in
open,
serviceworker
working
group
about
adding
token
based
off
and
then
also
adding
user
impersonation,
which
isn't
an
auth
thing
strictly
in
the
sense,
but
touches
that
area
so
yeah
there
there
are.
There
is
a
desire
from
many
folks
that
are
on
the
API
working
group
to
add
other
off
methods,
which
is
not
especially
surprising,
considering
that
the
current
options
are
nothing
or
basic
on
I'm,
getting
a
thumbs
down
on
basic
auth
in
the
room.
A
Think
I've
also
created
one
for
be
able
to
I've
done
some
work
for
ensuring
that
you
don't
continually
list
catalog,
but
there's
one
that
I
don't
think
that
I've
created
an
issue
for
I'll
check
in
a
moment
which
is:
is
there
a
use
case
for
having
a
configurable
relist
period
on
a
per
broker
basis?
That's
maybe
a
flag
in
the
API
that
would
be
like
Leila's
period
so
that
you
could
say
for
a
specific
broker.
I
want
you
to
research
this
one
every
day
or
I.
A
D
D
C
A
C
C
D
D
B
A
D
A
Actually,
okay
I
can
think
of
a
couple
things
here
and
and
I'm
not
sure.
If
we
we
can
create
issues
for
them
later
in
this
thing,
but
we
don't
support
plan
update,
yet
we
don't
support
parameter
update
yet
so
we
need
issues
for
those
does
it
has
anybody
on
this
call
had
experience
using
the
dashboard,
SSO
featured.
A
Because
I'm
wondering,
if
there's
anything
further,
that
we
need
to
do
for
dashboard
stuff.
For
one
thing,
if
you
look
at
the
dashboard
client,
it
does
say
that
it
gives
you
a
secret
and
anything.
That's
a
secret
should
not
live
in
our
resource
that
you
live
in
a
secret,
so
maybe
there's
an
issue
for
put
the
actual,
a
dashboard
secret
information
into
a
kubernetes
secret
somewhere.
A
D
A
C
A
A
C
A
A
A
What
there
is
three
of
these
required
permissions,
or
that
you
can
have
and
they're
basically
hooks
into
cloud
boundaries,
implementation
that
if
you
have
a
route,
if
you
have
requires
a
route
forwarding,
you
can
do
things
like
send
this
bind
resource
in
the
bind
request
and
say:
I
want
you
to
set
up
this
route
for
me,
which
we're
not
going
to
do
anything
for
that.
Yet
so
I
think
there's
like
probably
two
parts
of
this
which
is
for
now.
C
A
C
Of
kubernetes
right
and
so
it's
possible
for
an
environment,
a
particular
platform
to
support
that,
without
necessarily
getting
changes
from
the
Service,
Catalog
team
or
kubernetes
to
make
it
happen.
So
we
gotta
be
a
little
bit
careful
about
saying
we're
going
to
remove
some
of
these
things.
I
need
to
think
a
little
bit
more
about
it
by
July
be
a
little
cautious,
I'm.
A
Not
suggesting
that
we
remove
it
I'm
just
suggesting
that
in
in
the
interim,
until
we
know
what
the
story
is
going
to
be
that
we
either
have
a
warning
event
that
gets
generated.
That
says
this
might
not
work
correctly,
because
it
requires
a
permission
that
trigger
Nettie's
catalog
doesn't
support
yet
or
something
that's
like
you
can't
find
it
as
one
because
it's
not
going
to
work
right.
A
A
A
It
it
does
seem
like
something
that
I
guess
it'd
be
goes
into
metadata.
You
eyes
can
display
it
right
and
I
think
the
way
we've
been
creating
metadata
so
far
is
that
we're
going
to
treat
it
like
a
blob
and
you
I
can
do
what
they
want
with
it.
I
don't
see
any
particular
need
to
do
anything
different
for
this,
but
I
wonder
how
other
people
think
I
think.
C
A
E
A
So
right
now,
I
think
the
versioning
story
is
that
things
can
just
change
underneath
your
feet
right
now
and
there's
there's
nothing
in
the
spec.
That's
a
first-class
way
to
indicate
this
is
version
1.1
of
plan
XYZ,
which
is
not
a
great
story,
but
maybe
a
fact
of
life
for
us
until
we
can
make
a
little
bit
of
progress
on
the
open
source
there
I'm
sorry,
the
open,
serviceworker,
API
versioning
scheme
well.
C
D
C
A
E
A
A
A
A
D
Yeah
we
need
that,
and
that's
on
my
list
of
things
to
do
I
just
need
to
know
that
one
is
the
easy
part
for
the
most
part.
The
trickier
bit
is
where
the
check
that
how
early
in
the
pipeline
can
be
detect
that
an
async
operation
is
ongoing
when
you
are
trying
to
modify
a
service
instance
or
delete
it,
and
that
that's
the
issue
that
led
me
to
does
it
need
to
be.
Where
does
it
go?
The
binding
part
is
trivial
forward.
A
Now,
because
the
deletion
time
stamp
is
set,
we
don't
just
delete
the
instance
because
we
had
to
have
a
way
to
reconcile
on
it.
So
I
think
we
could
accept
the
delete
just
like
we
do
and
not
have
the
controller
do
any
work
until
the
instance
was
ready,
which
actually
might
be
the
way
it's
coded
now.
I
would
need
to
look
yeah.
D
D
See
a
bit
respect.
This
is
the
tricky
part
about
respect
which
basically,
the
last
sentence,
which
is,
if
you
attempt
to
perform
these
operations,
it
must
receive
a
four
hundred
response
with
the
error
message.
So
it's
it's!
It's
it's
going
to
be
very,
very
I,
think
I
think
the
semantics
could
be
can
provide
here
require
something
like
either
an
admission
controller
or
or
or
or
whatever
I,
don't
understand
the
rest
api
machinery.
But
this
is
getting
the
user
to
go
and
get
a
four
hundred
I.
A
A
Let's
I'll
just
read
it
aloud,
and
then
we
can
pick
it
apart.
It
says
the
marketplace
must
ensure
that
service
brokers
do
not
receive
requests
for
an
instance.
While
a
synchronous
operation
is
in
progress.
Yep
for
in
that
part,
makes
total
sense.
I,
don't
think,
there's
any
ambiguity
there
nope.
The
next
sentence
is
for
example,
if
a
broker
is
in
the
process
of
provisioning
and
instance-based
synchronously,
the
marketplace
cannot
allow
any
update,
bind
unbind
or
D
provision
requests
to
be
made
to
the
plan.
C
E
Yeah
I
think
it
just
is
like
probably
call
center
marketplace
to
live
like
RPC
style,
so
whether
accepts
the
request
or
rejected,
while
in
communities
you're,
just
lazy,
intent
righted
you
don't
synchronously
like
wait
for
request
to
be
processed
and
that
I
think
this
requirement
works
against
you,
religious
principle
of
reconciliation.
So.
A
If
this
refers
to
the
fact
that
the
platform
shouldn't
send
it
I
think
it's
fine,
the
next
sentence
adds
to
the
confusion
a
little
bit
because
it
says
a
user
who
intends
to
perform.
One
of
these
actions,
while
in
operation
is
already
in
progress,
must
receive
in
HTTP.
400
responds
with
the
error
message,
bla
and.
C
E
D
A
A
D
A
D
B
D
D
D
Oh
I
was
going
to
say
I
think
I
I
would
have
to
look
at
the
code,
but
I
think
what
I
did
is
I
made
the
I
made
a
condition.
So
if
you
try
to
create
a
binding
and
an
operation,
it's
asynchronously
on
go
and
I.
Think
I
made
a
condition
that
is
amazing
in
progress
and
then
so
the
user
Epis
can
understand
what
the
heck
is
going
on
and
then
venture
the
reconciler
shift
say:
okay.
Well
now
there
is
no
longer
a
thing
ongoing.
So
let
me
do
you
up
yeah.
A
D
The
instance
has
one,
and
then
but
I
think
it
is
obviously
yet
instance
at
the
status
bit
and
then,
if
you
come
in
and
try
to
create
a
binding,
I
think
I
have
to
look
at
it,
but
I
think
what
I
did
is
well,
regardless
of
what
I
did
I
think.
The
way
it
should
work
is
we
should
set.
The
condition
is
not
ready
reason
asynchronous
operation
ongoing
on
the
service
instance
and
then
once
the
async
operation
completes.
Then
we
proceed
with
the
binding
just
as
usual,
I.
A
D
A
D
By
duality,
we
should
have
the
same
semantics
on
the
deletion
of
the
binding,
so
we
would
come
in.
They
would
look
at
it
and
say
the
delete
timestamp
has
been
set
on
the
binding
and
we
would
say
okay,
but
we
are
not
going
to
take
any
action
on
it
and
whatever
the
brita
conditions
are
for
that.
We
will
do
the
same
thing,
a
sync
operation
in
progress,
and
we
basically
just
wait
until
that
goes
away
and
then
be
proceed
to
the
deletion.
Yeah.
A
D
D
C
A
A
Think
that,
like
aside
from
the
stuff
we
just
talked
to
the
in
a
vacuum
like
nothing
else,
is
happening,
the
async
mechanics
work
correctly.
Now,
we've
we
verified,
they
work
with
a
couple
different
brokers
that
we
have
and
I
don't
think
there
are
any
gaps
for
this
aside
for
the
ones
we've
already
talked
through.
D
A
A
E
E
A
A
Now
I
I
spent
a
little
time
last
night.
Looking
at
the
update
request
body-
and
it
seems
to
me,
like
previous
values-
is
sort
of
a
perhaps
a
misstep
in
API
design
that
they
have
to
live
with
because
it's
been
released
and
that
we
have
to
live
with.
I
am
inclined
to
say
that
we
should
never
send
these
they're
optional
and
they
make
no
sense
to
me
why
they
should
have
to
be
sent.
That
is
my
own
personal
opinion.
I
wonder
how
other
people
feel
about
that?
Well,.
C
A
C
E
E
D
C
B
E
A
C
That
you're
raising
and
a
saint's
your
question,
though
there
is
nothing
in
the
specification
of
talks
about
that
today.
We
do
have
a
conversation
going
on
around
how
to
initiate
conversation,
sort
of
conversations
from
the
broker
back
to
the
platform
on
behalf
of
the
user,
and
that
made
encapsulate
some
of
the
way
you're
talking
about
there.
But
as
of
right
now,
there's
nothing
in
the
spec
of
talks
about
it.
Yeah,
okay,.
E
A
A
D
A
So
I
I-
I
did
a
pull
request
a
couple
weeks
ago
to
ensure
that
you
can't
bind
to
a
non
binding
service.
I
just
created
the
issue
to
add
plan
bindable
bit
that
I
will
incorporate
into
that
into
that
work
or
I'll
make
a
note
later
that
it
should
be
incorporated
for
whoever
does
it
I
think
from
a
mechanical
standpoint.
Just
for
that
that
we
should
be
covered
by
that
one.
A
E
C
C
C
D
Get
finally,
no
I
think
I,
don't
think
that's
missing
it.
True
is
sorry.
So
the
only
thing
I'm
thinking
about
there
might
be
some
information
that
the
platform
in
each
country
firewalls
or
something
like
that,
if
you're
binding
from
something
that's
I,
have
a
hazy
recollection
that
I
thought
that
that's
what
it
would
be
useful
and
I
would
like
to
go
ahead
and
keep
it
at
these
until
I
get
a
chance
to
think
about
it.
Yeah.
A
C
Relay
I'm
not
suggesting
that
we
drop
it
from
what
we
sending
the
message.
I
think
we
have
to
send
it
in
the
message
itself.
What
I'm
talking
about
is
because
we
don't
send,
because
we
don't
have
any
additional
data
in
there.
We
don't
necessarily
have
to
have
an
entire
structure
for
it
Alice
at
least
not
at
this
point
in
time.
Right.
D
A
C
B
C
The
tool
because
earlier
you
were
saying
you
may
not
let
me
deal
the
issue
at
all
because
of
the
one
I
previously
open,
but
I
think
it
they're
two
separate
issues.
Mine
is
just
what
is
the
value?
You
need
an
issue.
We
still
need
the
issue
you're
opening
now,
which
is
stick
something
in
the
resource
itself,
because
when
someone
does
it
get
on
the
binding
resource,
they
should
see
what
we
think
is
the
app
to
it.
Whatever
that
may
be
now.
A
B
A
C
A
C
A
A
E
E
A
E
A
Okay,
so
this
is
what
now
is
that
is
that
again:
well
yeah,
okay,
this
is
what
I
was
talking
about,
that
a
I
think
we
could
use
a
little
clarification
here.
Maybe
an
example,
but
it
sounds
to
me
like
if
you
do
a
D,
if
you
do
a
provision
and
you
get
in
in
it
times
out,
you
should
in
the
case
of
a
provision,
it
sounds
like
you
should
continue
it
I'm,
not
sure
this
makes
a
lot
of
sense
to
me.
C
C
A
Like
you
might
incur
in
charge
back
just
because
you
created
one
right
exactly
exactly
yes,
okay,
so
I
think
it
sounds
to
me
like
we
should
use.
We
should
try
to
clarify
this
in
spec,
and
then
we
probably
need
to
have
a
an
issue
just
for
handling
these
orphan
scenarios.
That
are
the
result
of
time
outs
right.
A
E
D
A
Okay,
well
I'm,
going
to
call
it
ear
since
we're
about
20
minutes
over
I
will
go
back
and
fill
in
the
body
of
issues
that
I
created
that
still
need
to
be
filled
in
I.
Think
I
have
a
takeaway
here
to
ask
for
clarification
on
things
in
the
spec
and
Doug.
You've
got
some
and
I.
Think
DA's
got
a
couple
takeaways
that
he
had
as
well.
A
C
A
So
we
got,
let's
see
we
got
twelve
issues
out
of
this.
It
could
be
worse
all
right.
Well,
thanks
for
joining
everybody
and
I'll
talk
to
you
shortly,
I'll
discuss
times
to
meet
Tamar,
to
talk
through
some
of
this
stuff
that
we
had
discussed
on
monday's
sig
call
in
the
slack
Channel
all
right.
Thanks
for
joining
now
box,
Thanks
all
right,
yeah,
everybody.