►
From YouTube: Kubernetes SIG Service Catalog 20180226
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
A
A
One
I'll
just
say:
Marco
is
already
doing
that
one,
but
it's
like
the
middle
of
the
night
for
him
right
now,
which
is
why
he
doesn't
join
usually
and
the
the
next
one
would
be
that
we
have
found
at
least
at
Red
Hat,
that
a
lot
of
users
are
confused
about
the
finalization
behavior
of
like
service
instances
and
service
windings.
So
I
was
thinking
about
that
a
little
bit
and
like
we
one
of
the
issues
that
we
have
identified,
that
we'd
like
to
improve
for
ODOT,
to
is
to
add
more
complete
doc
to
Service
Catalog.
A
So
I
wonder
if
anybody
has
some
cycles
to
help
make
that
happen,
because
I
think
we
we
can
work
through
that
a
lot
better
with
folks.
If
we
have
something
to
point
them
to
that,
like
add
more
than
a
walkthrough
level
document,
what
the
behavior
is
they
should
expect
on
and
that's
basically
it
cool
I.
B
Have
two
quick
things:
one,
it
sounds
like:
we've
got
three
working
groups:
we've
got
status,
updates
the
non
happy
pass
stuff.
It's
already
going
on
and
docks
so
it'd
be
nice
to
have
some
folks
split
out
and
sort
of
volunteer
for
each
thing
and
I
forgot
the
second
one
dear
me,
you
have
a
hand
up
so
go
ahead.
B
D
Can
you
give
me
now?
Yes,
okay,
yeah,
so
last
week
at
the
Mount
Ida
buff
meeting,
we
have
briefly
discussed
this
issue
that
we
should
probably
stop
working
instances
and
bindings
updates.
If
there
is
an
aggression
in
progress,
because
once
we
have
fixed
retry
retries,
it
means
that,
like
updates
could
be
blocked
like
for
a
week
which
is
not
very
nice.
Your
ex
I
guess
and
so
I
guess
we'll
have
three
options.
One
is
to
remove
this
working
behavior
completely,
so
the
second
option
is
to
add
some
admission
controller.
D
That
would
prevent
updates
like
that
with
belike,
optional
and
I.
Don't
know
IBM,
bluemix
or
some
other
installations
of
service
catalog
could
enable
this
admission
controller
if
it
is
still
important
for
them,
and
the
third
option
I
think
is
like
more
flexible
and
the
second
one
is
to
add
some
option
into
the
Merkur
spec.
That
would
say
that
this
particular
broker
doesn't
like
doesn't
need
this
porting
behavior
somebody
fault,
I,
wouldn't
wouldn't
enable
it.
But
if
the
particular
broker
cares
about
tracking
every
single
update
separately,
then
it
is
up
to
the
user.
E
First
of
all,
can
you
hear
me?
Okay,
I've,
never
used
the
speaker
on
the
machine
for
Lisa
head
says:
yes,
so
I
apologize,
I
haven't
really
read
up
on
this
much
just
sort
of
watching
it
from
the
side.
So
I
don't
think
this
is
a
implementation
detail,
I
think
now
you
can
suggested
that
some
implementations,
like
the
good
you
said,
like
the
IBM
platform,
could
data
flaggers
link
if
we
wanted
it
I,
don't
think
it's
an
implementation
choice.
I
think
this
is
more
related
to
the
spec
itself.
E
So
if
there
was
some
kind
of
change
that
we
wanted
to
make
here,
I
think
would
have
to
be
in
the
spec.
You
really
wanted
to
change
something
from
a
drastic
perspective
and
I.
Don't
think
it'd
be
wise
to
to
expose
this
at
a
broker
level
or
at
the
end
user
level,
because
this
is
really
something
that
happens
under
the
covers
that
neither
sigh
I
should
really
care
about,
and
by
that
I
mean
the
spec
basically
says
they
decide.
This
header
is
gonna
pass
along
to
tell
you
who
initiated
this
particular
change.
E
This,
that's
not
the
kind
of
thing
that
somebody
should
have
to
necessarily
hop
into
it's
just
part
of
this
itself,
so
I'm,
not
I'm,
not
thrilled
with
the
idea
of
of
making
changes
that
that
be
make
us
in
essence
violate
the
spirit
of
the
specification
but
but,
like
I
said,
I
apologize.
I
haven't
really
read
much
into
this
issue,
yet
I
need
to
do
that.
I
called
guys.
D
Go
ahead
now
so
I
was
gonna.
Ask.
Is
there
a
special
warning
wording
in
the,
or
is
this
back
about
the
requirements
for
this
user
in,
for
because
I
have
seen
this
that
there
is
a
context
or
something
was
it
where
you
can
pass
the
user
idea,
but
I
haven't
seen
if
there
is
any
specifics
about
like
what?
What
are
the
requirement
from
the
OSB
Spector
structure?
This
is
one
thing.
E
I
just
pasted
a
link
to
the
spot,
respect
it's
the
originating
identity,
header
and,
basically,
what
it
does.
It
says
this
is
the
this
is
the
end
user
that
caused
this
particular
action
to
happen
and
don't
don't
interpret
my
my
statements
here
is
saying
we
need
to
push
back
and
not
make
any
kind
of
change.
F
It
I
mean:
is
it
so
bad
that
the
last
cuz
I
think
that
if
the
behavior
that
we're
describing
still
fits
in
the
wording
here
cuz,
it
is
the
last
users
action
that
caused
this
request
to
be
sent?
It's
just
that
the
use
the
last
users
action
is
like.
The
user
has
to
be
aware
that
they
are
responsible
for
the
state
of
the
resource
that
they
are
submitting
and
that
could
state
could
have
been
altered
earlier
by
somebody
else,
but
you
are
ultimately
responsible
for
what
you
are
sending
to
the
broker.
E
Crap
crap,
sorry,
okay,
I,
believe
some
of
the
use
cases
relate
to
this
space
were
around
the
lines
of
the
first
person
who
made
a
change.
Has
the
authority
to
make
that
particular
change,
but
for
whatever
reason,
it's
failed.
The
next
person
comes
along
and
doesn't
have
the
authority
to
make
the
first
change,
but
they
can
make
the
second
change.
So
at
that
particular
point
in
time
having
the
wrong
user
associated
with
a
particular
change,
you
could
actually
not
end
up
with
the
right
end
results.
D
Yes,
so
I
agree
that
some
brokers
might
have
like
this
fine-grained
artwork
on
their
side,
but,
for
example,
if
we're
talking
about
some
like
in
our
in
our
architecture,
we're
actually
doing
the
our
break
on
the
community
side,
not
on
the
broker
side.
So
I
think
that
it's
not
like
what
I
don't
like
about
the
current
behavior.
Is
that,
because
some
brokers
probably
need
these
fine-grained
information
about
every
single
change,
we
actually
break
the
UX
for
every
user.
So
if
it's
possible,
I
I
would
just
make
this
behavior
optional.
B
F
Think
a
possible
solution
to
that
issue
would
be
to
have
a
like
a
rollback
action
that
we
could
do
for
the
spec
to
put
it
in
the
Erb.
To
put
it
in
the
last
happy
state,
it's
just
so
that
the
user
wouldn't
have
to
edit
the
spec
manually
to
make
it
match,
make
the
changed
parameters
that
they
didn't
want
to
take
authority
to
match
the
current
state.
So
that's
an
option.
A
Cool
go
ahead,
Paul,
so
a
rollback
thing
might
be
attractive
as
user
experience,
but
there
are
a
couple
of
things
that
make
it
hard
to
do
so.
For
example,
a
lot
of
users
are
going
to
most
of
their
parameters
from
secrets,
and
there
is
not
really
a
way
to
capture
the
state
of
the
secret
when
you
update
it
so
that
you
can
roll
it
back
later.
A
So
it's
going
to
be
tough
to
make
a
good
solution
that
that
does
that
that
come
like
actually
solves
the
rollback
thing,
and
the
other
thing
that
I
want
to
point
out
is
that,
like
the
admission
control
that
we
have
right
now
is
also
not
a
complete
solution
to
the
problem
it's
trying
to
solve,
because
you
can
update
a
secret
that
holds
parameters
out-of-band
and
a
smile
is
just
put
into
the
chat
like
we're,
not
really
blocking.
Those
updates
like
we're
not
blocking
updates
to
secrets
the
whole
parameters
at
all.
A
So
what
I
would
suggest
is
like,
if
there's
a
broker
that
like
like
well
one
at
a
high/low
I,
don't
think
that
we
all
have
to
agree
about
this
like
it
would
be
possible
to
relax
these
constraints
and
add
a
link
to
the
broker
spec.
That
says
that
allows
you
to
turn
it
on
turn
it
off,
and
we
can
talk
about
with
the
defaults
will
be
around
this,
but
I
think
that
it
should
be
possible
to
relax
these
constraints
and
add
a
very
strict
mode
that
prevents
the
updates.
E
D
D
G
Okay,
J
go
head
back,
I.
Think
one
of
the
driving
issues
on
this
was
getting
into
a
bad
state
on
an
update
and
not
being
able
to
recover
and
I
think
that
use
case
is
really
important
to
remember
as
we
you
know,
talk
about.
Perhaps
why
why
we're
in
the
scenario
trying
to
work
around
it
and
work
through
it.
B
Okay,
that
sounds
like
it
would
probably
be
part
that
could
probably
be
part
of
the
not
happy
path
working
group-
yes,
actually
I'll,
send
out
after
after
this
meeting,
probably
around
2:30
or
3:00.
My
time
I'll
send
out
adop
to
the
google
group
to
track
all
these
working
groups
with
just
some
explanation
of
how
I
propose
we
do
it
cool
with
everybody.
G
B
E
D
E
B
All
right,
so
we've
got
39
minutes
left,
it
doesn't
look
like
you've
got
a
ton
more
stuff
here.
We've
got
a
lot
of
bullet
points,
but
they
don't
look
huge
before
you
move
on
Niall
and
Carolyn
I'm,
going
to
just
shout
out
the
PRS
that
you
guys
want
from
you'd.
So
we've
got
1748
1751
for
non
happy
path,
related
things
in
1756
for
provisioning
by
external
ID.
So
now
and
Carolyn,
do
you
guys
have
anything
more?
You
want
to
say
about
either
of
those
I.
H
H
D
So
I
just
was
going
to
say
that
we
have
already
discussed
that
we
need
to
make
three
changes
in
source
work
for
not
happy
paths
and
two
of
them
have
already
ready
to
review
and
I'm
working
on
the
third
one.
So
with
the
review
because,
like
they
thought,
one
I
think
relies
on
the
first
two.
So
it
really,
it
would
be
nice
to
merge
them
first
and
act
or
disagree
or
was
if
this
behavior
is
the
correct
one.
B
E
So,
a
long
time
ago,
I
think
it
was
Dan
Khan
sent
out
a
note
saying
that
they're
willing
to
offer
up
either
35
minutes
sessions
or
80
minute
sessions
to
Stig's
that
want
to
do
some
sort
of
deep
dive
face-to-face
meeting
like
thing
and
they
were
going
fast.
So
by
the
time
we
got
in
our
requests,
the
80
minute
sessions
were
all
gone,
so
we
decided
to
ask
for
two
35
minute
sessions,
and
so
we
got
two
of
those
Wednesday
and
Thursday.
So
Morgan
and
kibbles
are
going
to
be
doing
that
presentation.
E
I
have
a
link
to
the
two
sessions
in
the
agenda.
Doc
and
that's
it
I
just
wanna
make
sure
people
are
aware
of
it.
So
hopefully,
offline,
Michael
and
Morgan
will
start
working
on
the
outline
and
stuff
and
I've
already
started
to
book
them
offline
to
see.
If
we
get
that
going
to
make
sure
it's
not
a
last-minute
thing
cool.
B
E
E
B
So
I
got
a
hand
up
kibbles
I.
Think
most
of
us
in
this
call
probably
have
something
laying
around
slides
or
documents
or
anything
to
contribute.
So
if
you
guys
want
reviews,
reach
out
I
think
to
the
Google
Group,
that's
probably
the
best
place
and
we
like
I
said
probably
any
of
us
can
help,
not
that
you
guys
don't
necessarily
need
it
or
not
that
you
guys
do
necessarily
need
it,
but
we're
all
bill
so
awesome.
Thank
you
and
Doug.
Why
don't
you
say
your
thing?
I
have
helpful
yeah.
E
Just
I
was
I
would
assume
that
both
Morgan
and
Michael
would
present
this
to
one
of
these
Monday
phone
calls
before
coop
GaN
just
to
get
some
feedback
and
make
sure
they're
not
going
off
the
deep
end.
But
hey
my
assumption
is
wrong.
Michael
can
correct
me,
but
that'd
be
my
assumption.
B
E
I
will
write
a
note
for
that.
So
no
objection
is
just
just
because
we
say
working
group.
Do
you
mean
just
a
group
people
that
go
up
on
the
side
and
meet
on
their
own
and
they
come
back
and
tell
us
what's
going
on,
or
do
you
mean
formalized
meetings
aside
from
this
Monday
one
I
mean
the
first
one.
Okay,
thank
you.
B
H
I
just
heard
up
from
number
of
people
in
the
mailing
list
that
they
were
interested,
but
there's
a
lot
of
waffling
between
doing
this
the
day
before
or
the
day
after
the
OSB
API
face
to
face
in
April
and
since
it's
starting
to
get
close
enough,
that
I
would
have
to
buy
ticket
soon.
I
was
just
curious
if
we
could
pick
a
date
yeah.
A
A
B
A
E
It's
fine
just
request:
please
don't
do
have
two
half
days,
I
I,
think
part
of
the
reason
you'll
may
not
do
both.
Is
they
don't
want
to
say
make
the
trip
longer
than
they
have
to,
but
just
doing
half
they
just
forces
them
to
get
the
worst
of
both
worlds,
so
big,
Monday
or
Thursday.
Let
the
chips
fall
where
they
may.
Okay,.