►
From YouTube: Kubernetes SIG Service Catalog 201170905
Description
- beta progress
- Kubecon F2F
- credentials-like output handling for binding
- reconciled properties of instance / binding in status
B
Thanks
alright,
so
thanks
Morgan
for
sharing
your
screen,
we're
gonna
be
working
off
of
that
standard
notes.
Document
I
put
the
link
into
the
chat
for
that.
As
usual,
we're
gonna
be
doing
speaker
queue.
I've
got
my
high
tech
queue
equipment.
You've
got
something
you
want
to
add,
put
hand
plus
hand
or
some
variation
thereof
into
the
chat.
I
just
put
an
example
in
there
and
with
that
I'm
gonna
get
started
with
two
administrative
items.
B
Second,
is
I.
Wanna
do
give
update
on
our
progress
towards
beta,
so
quick
reminder.
We
decided
that
we
are
going
to
have
our
first
beta
release
of
Service
Catalog
coincide
with
the
kubernetes
1.8
release
that
is
scheduled
for
September
22nd.
There's
a
link
there.
You
can
see
to
the
kubernetes
release
document
for
1/8.
Currently
I
have
a
link
here
for
the
V
0.10
milestone.
There
are
20
open
issues
and
I
believe
we
have
spoken
about
at
least
three-quarters
of
those
issues.
So
take
a
look
at
those
and
we'll
be
bringing
those
up.
This
week
we.
B
Otherwise,
today
we
can
talk
through
each
of
those
later
today,
if
we'd
like,
but
I,
want
to
get
through
the
rest
of
my
announcements
here
so
final
announcement,
we
do
have
a
poll
open
for
the
face-to-face
time
for
khue
kham.
This
is
the
final
reminder
to
vote
on
that
I'm
going
to
close
the
poll
tomorrow
and
then
I
will
also
at
that
point,
announce
the
result
of
the
poll
and
request
a
room
for
us
to
meet
at
the
time.
That's
got
the
majority
of
the
votes.
Excuse
me
the
most
votes,
not
majority.
B
The
link
to
the
poll
is
the
last
bullet
point
I
haven't
highlighted
here,
so
go
vote.
There
try
to
vote
by
the
end
of
today
I'm
going
to
close
the
polls
tomorrow
just
before
our
meeting
all
right,
so
that
is
it
from
me
Paul.
You
are
writing
up
something
right
now,
actually
review
status,
all
right,
Paul
go
ahead.
Take
it
away
all
right.
A
C
B
A
B
A
This
one
is
underway
right
now
and
nearly
ready
to
review
if
I
remember
correctly,
Jeff
yep,
that's
right.
Okay,
what
this
one
is
about
is
right.
Now
there
is
nothing
to
prevent
someone
who
has
access
to
create
a
broker
resource
from
stealing
service
account
token
that
they
don't
have
access
to.
So
this
adds
an
SAR
check
mission
controller
that,
when
you
add
a
new
service
broker
resource
emission
controller
checks
to
ensure
that
you
have
the
ability
to
get
the
secret
that
you
specify
as
part
of
the
broker
resource.
A
A
A
The
next
one
is
our
original
proposal
for
the
scope
of
the
initial
beta
I
wonder.
Do
folks
think
that
we
can
we
can
close
this
one
out.
I
guess
I
had
an
action
item
from
this
to
send
a
message
to
the
Google,
Group
and
and
I
believe
that
that
was
it
so
I
guess
I
need
to
actually
follow
through
dot
through
on
that
action
item.
B
A
A
D
C
D
F
D
Or
is
it
true?
Yes,
yes,
you
get
yeah
I'll
sign,
that's
myself
and
I'll
take
it.
So
should
this
be
in
ODOT,
one
I
think
it
should
that
way.
People
at
least
understand
that,
even
if
we
don't
support,
updates
updating,
this
secret
will
have
no
effect
whatsoever
and
we're
just
gonna
go
with
whatever
whatever
was
there
when
the
resource
was
created.
Oh
this.
A
A
I'll,
take
that
one
all
right,
so
the
next
two
are
worth
in
mitigation
and
I
have
a
standing
action
item
which
I
haven't
gotten
to
yet
because
we
cut,
we
got
a
little
bit
ahead
of
ourselves
and
we
had
to
work
through
some
of
these
other
things
with
status.
First,
my
plan
is
to
have
an
orphan
Mitigation
written
proposal
to
look
at
tomorrow,
but
that's
what
those
two
are.
A
A
If
anybody
is
interested,
I
think
that
someone
can
begin
working
on
this
now
and
it's
only
really
fully
testable
once
we
support,
updates
but
I
think
that
it,
someone
can
begin
working
on
it
now
and
it
will
be
at
least
partially
testable,
partially
testable
before
we
actually
have
updates
working.
Does
anybody
want
to
put
their
hand
up
for
this?
One.
D
So
actually
Paul,
that's
one
of
the
things
I
wanted
to
brainstorm
with
you
on,
because
I
think
that
one
and
committees,
names
of
service
class
and
plan
versus
open
source
broker
goods
are
related,
yeah
they're,
definitely
related
yeah.
So
I
wanted
to
brainstorm
with
that
with
you
first
before
someone
sparse
coding
it
up.
Okay,.
A
I
think
that
sounds
fine,
and-
and
we
can
talk
about
that-
one
tomorrow,
Doug,
you
know
what
we
could
also
do
is
have
that
conversation
on
this
zoom.
So
other
people
are
interested
in
talking
through
it.
We
could
we
could
do
it
in
public
yeah.
Let's
see
how
it
goes.
Okay,
all
right!
So,
let's
see
next
one
is
determine
how
to
handle
deep
revision
request
to
an
instance
with
bindings.
We've
talked
through
this
one
and
it
has
a
pull
request
associated
with
it.
That
I
will
link
into
the
chat,
because
that
is
ready
for
review.
A
A
A
D
A
D
A
Okay,
so
I
hear
no
controversy
about
waiting
until
we
solve
some
some
other
questions.
Next,
one
is
published,
helm,
charts,
a
helm
repo,
and
this
is
assigned
a
Erin
I
haven't
heard
you
mention
it
in
a
while
so
I
wonder
if,
if
you're
you're
still
working
on
it
or
if,
when
what
the
status
of
this
one
is
I.
A
A
C
C
E
B
Right
so
we've
got
two
action
items
from
the
status
reviews.
Paul
is
gonna,
make
a
proposal.
Sorry
is
going
to
post
the
scope
of
initial
beta
to
the
Google.
Group
he's
also
going
to
close
the
scope
issue
after
the
fact
after
he
makes
that
post
I
will
go
through
as
well
and
I'll
make
sure
that
all
a
dot
one
dot
OPRS
have
that
milestone
on
them,
with
the
hope
that
it
becomes
easier
to
review
the
higher
priority.
Pull
requests
all
right
with
that
anybody
have
any
remaining
questions.
E
So
this
is
a
trivial,
always
be
spec.
If
you
have
raced
and
I
just
wanted
to
get
the
feedback
from
you.
What
do
you
think
about
that?
So
currently,
only
binding
has
the
arbitrary
output
section
in
the
response
called
credentials,
and
there
is
no
way
to
return
something
like
static
information
about
the
instance.
For
example,
if
you
have
provision
some
ec2
or
whatever
in
its
it
has
an
IP
address
or
URL,
or
something
like
that.
You
can't
return
it
from
provisioning
requests.
E
You
have
to
remember
it
somewhere
and
once
you
create
a
binding,
you
have
to
remove
reach
on
it
as
part
of
credentials,
object
and
I.
Think
like
in
some
cases
where,
for
example,
instance
is
not
bindable
like
technically
there's
nothing
to
like
no
credentials
to
be
generated.
What
I
see
is
having
to
create
a
fake
biding
returning
the
ascetic
instance,
information
is
a
little
bit
redundant.
So
my
question
is
whether
it
is
okay
to
add
some
section,
to
instance,
response
similar
to
credentials
to
return
some
information.
D
A
A
If
I
remember
correctly
from
the
face
to
face
that,
like
even
during
an
async
provision,
you
have
to
be
able
to
give
that
information
back
immediately.
Does
that
sound
accurate
to
people
clicking
right
now,
because
I
think
you
have
to
give
back
that
entire
response
up
front
and
I
could
see
there
being
an
objection,
because
brokers
might
not
have
all
that
information
up
front,
but
I
definitely
think
this
makes
sense
and
I
I
think
it
would
be
good
to
write
it
up
and-
and
we
can
talk
about
it
in
a
working
group.
B
B
A
A
Just
to
recap
what
we
talked
about
before.
Basically,
the
the
proposal
was
to
add
and
in
progress
properties
and
external
properties,
to
the
status
of
instance,
and
instance
credential,
those
representing
like
what
one,
what
the
controller
is
currently
working
toward
and
to
what
the
broker
knows
about
so
just
to
talk
through
an
example
when
I
make
a
service
instance,
the
controller,
when
it
started
doing
work,
would
set
the
in
progress
properties
to
be
hey.
A
If
we
should
send
parameters
for
the
update,
the
spec
in
service
worker
API
spec
says
that
you
should
only
send
parameters
as
part
of
an
update
request
if
the
user
actually
wants
to
change
them
and
that's
why
we
need
to
check
some,
but
that
that
was
the
gist
of
it
and
then,
when
the
controller's
done
doing,
work
and
and
gets
is
successful
in
making
sure
the
broker
knows
about
a
particular
set
of
properties.
It
will
update
the
external
properties.
A
G
A
So
I
think
it's
very
similar
it.
It
may
be
change
a
little
bit
based
on
things
that
I
realized
needed
to
be
in
there.
While
I
was
writing
it
up.
I
would
not
say
it's
substantially
different,
but
I
haven't
it's
been
a
while,
since
I
looked
at
the
original
suggestion,
oh
and
I
think
that
the
user
information
we've
already
talked
through
about
about
this
actually
I
think
does
original
suggestion
was
a
write-up
of
a
conversation
that
he
and
I
had
so
I
guess
it
would
maybe
be
kind
of
my
original
suggestion
to
I.
G
I,
don't
care
whose
proposal
base
I'm
just
saying
this
is
not
a
whatever.
It
is
just
to
say
that
we
basically
had
a
acknowledgement
that
we
need
to
keep
track
of
who's
modifying
anything
in
order
for
us
to
go
and
be
fully
compliant
with
the
spec,
and
now
we
and
and
then
we
decided
that
we
all
are
gonna
do
a
subset
of
it,
and
now
we
are
basically
moving
towards,
in
my
mind
again
what
is
very
closed
in
in
in
that
that
front.
G
So
I
guess
it'd
be
good
to
go
and
look
at
that
and
see
what
the
different
just
either
add.
Whatever
was
missing
from
that
or
to
go
ahead
and
say
we
are
not
going
to
do
that
now
of
XY
and
Z
or
or
whatnot,
but
it's
starting
to
get
the
point
where
this
is
getting
more
complex
and
it
might
be
useful
to
say:
do
we
add
5%,
more
complexity
to
it
now
and
get
closer
the
letter
of
the
spec,
especially
because
I
don't
think
we
have
to
allow
for
multiple
concurrent
operations.
G
D
G
I
am
saying
that
it
is
eerily
similar
to
something
that
we
dismissed
earlier
on
as
too
complex,
okay,
and
it
is
missing,
I
think,
given
our
face-to-face
discussion,
where
we
do
not
allow
concurrent
operations
on
a
service
instance.
That
means
the
video
have
to
keep
the
array
of
a
list
of
mutation
operations.
So
I
think
that
if
we
only
add
who
made
this.
G
Sir,
increased
properties,
I
think
may
be
in
great
shape
as
far
as
being
compliant
with
the
OSB
spec,
but
I
haven't
read
through
the
whole
thing
and
I
just
I
wanted
to
say
I
I
guess
I
would
like
to
go
ahead
and
look
at
the
previous
proposal
a
take
a
little
mental
day.
For
that
and
say
I
think
that's
the
only
thing
missing
and
I
think
coupled
with
no
concurrent
mutations
and
the
ingress
properties
we
might
be
in
in
a
decent
state.
As
far
as
the
spec
compliance
goes.
Okay.
D
Okay,
so
now
that
I
understand
where
you
coming
from
okay,
let
me
to
me
to
try
to
address
your
concern,
so
I
think
it
would
be
useful
to
take
this
one
step
at
a
time
and
in
particular,
looking
at
what
Morgan
is
showing
on
the
screen.
The
service
instance
status,
struct
and
focusing
just
on
the
in
progress
properties,
which
is
really
nothing
more
than
a
look.
Sorry,
it's
which
is
really
nothing
more
than
a
snapshot
of
the
spec
as
seen
by
the
broker.
Okay.
D
Now,
the
reason
that
I
think
we
need
that
is
because,
even
after
the
service,
catalog
controller
is
done
with
all
its
processing
and
everything's
all
completed
users
may
make
changes
to
the
spec
going
forward
and
those
spec
changes
may
be
invalid
or
busted
or
whatever,
and
they
may
not
work
right,
so
they,
the
spec
itself
at
some
point
in
the
future,
could
be
in
a
bad
state,
and
so
the
reason
that
we're
putting
a
copy
of
the
spec
into
the
status
is
so
that
they
know
what
the
broker
sees.
You
know.
D
Basically,
what
is
the
current
state
of
the?
So
that's
why
that
property
needs
to
be
there
so
now
notice,
it's
not
an
array
right,
so
it's
not
meant
to
represents
multiple
operations,
so
the
concurrency
stuff
that
you
mentioned
is
definitely
still
true
and
we're
not
allowing
an
array
to
be
in
there.
So
does
that
address
your
concern?
Relatives
at
first
property.
G
G
A
D
I
I
think
it
kind
of
depends
on
on
delay,
because
I'm
soaking
in
some
mixed
signals
from
you
really.
It
sounds
like
you're,
okay
with
the
in
progress
properties,
and
you
may
actually
even
be
okay
with
the
external
properties,
because
that's
kind
of
the
same
thing
other
than
it's
for
the
external
secrets
and
then
you're
saying
we
need
to
add
the
user
information.
So
I'm
not
quite
sure
what
your
concern
is
because
I
think
everybody
agrees.
F
B
So
tell
you
what
it
sounds
like
so:
first
of
all,
Paul
year,
you're
on
deck
I'm
hearing,
first
of
all,
it
V
Lindo.
You
guys
sound,
like
you're,
pretty
close
to
agreement
here.
So
why
don't
you
guys
take
this
offline
talk
about
it
after
and
then
meanwhile,
Paul
want
you
to
go
ahead
and
dig
floor.
Yeah.
A
I
think
I,
so
I
I
think
that
if,
if
each
of
these
fields
had
the
user
information
encoded
on
them,
that
that
things
that
we
would
be
in
great
shape
and
I
would
be
happy
to
add,
add
those
and
I
see
no
reason
why
we
couldn't
just
capture
all
this
in
a
single
issue
in
a
single
pole,
request
I
think
we
talked
through
the
semantics
at
length
in
the
face-to-face
I
think
we're
all
saying
the
same
thing
with
different
words
and
confusing
each
other.
That's
my
suspicion.
D
Go
ahead,
Doug,
I!
Yes,
with
one
caveat,
is
it
really
user
info
on
a
per
property
basis
or
the
obeisances
order
for
the
resource?
I
thought
it
would
be
for
the
whole
resource
its?
It
is
for
the
whole
resource.
Okay,
that's
why
I
thought?
Okay,
then
I'm
in
agreement,
yeah
all
right
go
ahead
of
you
later
yeah.
G
I
was
gonna
say
that
I
think
what
I
would
like
to
do
is
volunteer
Doug
to
make
sure
that
the
original
proposal
that
they
had,
if
is
inspect
compliance
for
this
one,
because
that
had
all
the
corner
cases
and
I
think
some
of
those
corner
cases
have
been
removed
again
because
we
do
not
allow
concurrent
updates
so
I
think.
The
only
thing
that
is
missing
is
the
user
info,
but
I
would
like
to
go
ahead
and
and
have
Doug
take
a
look
at
the
original.
G
Only
I
think
it
just
needed
to
be
told
who
made
this
change
and
I
think
if
we
only
had
a
name
user
info
to
the
last
known
good,
we
will
be
good
shape
or
user
info
in
the
in
the
in
progress
and
there
and
roll
it
forward
to
external
state.
Once
it's
done,
I
think
we
might
be.
Okay,
but
I
I
I
can
either
look
at
that
and
confirm
that
or
or
you
know,
but
since
that
volunteered
I
think
he
should
do
it.
A
I
guess
I'm
I'm
not
I'm,
still
not
sure
what
the
request
is
really
so.
The
the
write-up
that's
from
16
days
ago.
That's
on
the
screen
right
now
is
right
above
what
Doug
and
I
talked
about
just
one
on
one
before
the
face
to
face,
and
we
talked
through
different
aspects
of
this
at
the
face
to
face,
and
then
basically
my
comment
there
at
the
end
is
like
incorporating
everything
that
we
had
discussed
in
the
face
to
face
and
the
the
new
version
of
this
thing.
G
A
G
A
G
A
D
D
But
I'd
be
late
to
your
to
your
request
or
the
volunteer
of
me
that
you
did
I'm
okay
with
going
back
and
double-checking
to
make
sure
this
covers
all
the
cases
that
we
care
about
for
SPECT
compliance
without
all
of
the
complexity
of
concurrency
at
concurrent
updates,
I'm,
pretty
sure
it
does.
But
if
you'd
like
to
does
have
a
day
to
think
about
this,
some
more
and
have
me
double-check
it
I'm
more
than
okay.
With
that.
G
A
B
A
D
A
G
I
was
just
nods.
Fine
I
was
just
answered
the
question
so
that
I
guess
that's.
What
I
would
like
to
kind
of
go
over
here
is
to
go
and
say
that,
instead
of
having
the
user
info
on
who
modified
what,
when
I'm,
where
that
we
can
look
at
it
saying
if
we
put
it
into
this
one
thing,
because
I
could
certainly
see
it
being
useful,
we're
in
progress
properties,
I
think
they
were
called
where
that
would
have
the
user
info.
G
So
if
it's
an
async
operation,
you
could
see
who
basically,
who
requested
the
current
ongoing
operation,
that
I
can
see
that
being
very
useful
and
obviously,
if
there's
only
these
two
places
where
keep
track
of
it.
That
seems
attracted
to
me
because
I
think
status
contains
all
the
information.
Then,
at
one
point
where
you
can
look
at
and
saying:
here's
the
current
ongoing
operation,
here's
the
the
current
properties,
here's
the
previous
ones.
So
from
there
it's
trivial
to
go
and
Bildad.
G
B
B
D
B
A
Ahead
Paul,
so
I
I
just
wanted
to
recap
for
Vila
yeah.
We
said
that
we
didn't
need
to
have
these
daily
design
meetings
anymore
and
then
we're
like.
Oh
wait,
there's
just
a
couple
more
things
to
talk
about,
and
so
I
think
that
we're
nearing
the
end
of
the
daily
design
meetings.
But
there
are
where
I
think
we're
on
real
soon
now
status
for
when
the
last
one
will
be.
G
So
two
things:
first
of
all,
this
soon
thing
is
funny
because
it
places
my
wind
that
these
windows,
all
over
so
when
I'm
asked
to
speak
I,
always
have
to
go
hunting
second
of
all,
yeah
I
think
it's
I,
think
it's
fine,
I
mean
Paul
and
Doug
have
spent
way
more
time
on
this.
All
I
was
trying
to
do
was
a
not
to
confuse
this
issue
anymore.
G
B
Going
once
all
right,
we
will
have
a
meeting
tomorrow,
September
6th
same
time,
same
place,
I
believe
there
was
at
least
one
item
that
someone
mentioned
that
they
want
to
talk
about
tomorrow.
I,
don't
remember
what
it
is.
So
if
you
have
one,
please
add
it
to
tomorrow's
agenda:
I'll
create
the
boilerplate
for
that
right
after
this
meeting.
Otherwise,
with
that
I
see
everybody
tomorrow,
thank
you
all
bye,
bye-bye.