►
From YouTube: Kubernetes SIG Service Catalog 20170831
Description
- Block updates to resources while controller is doing work
- Concerns with splitting serviceclasses and plans into separate resources
A
B
Thanks
guys,
so
we're
gonna
proceed
as
usual
today,
according
to
the
agenda
also,
as
usual,
we're
gonna
stick
with
the
speaker
queue
system.
So
if
you've
got
something
you'd
like
to
say
just
typed
hand
in
the
chat,
I'll
keep
track
of
the
speaker.
Queue
with
my
high
tech
speaker
queue
equipment
with
that
we're
gonna
get
started
with
the
schedule.
The
first
item
on
the
schedule
is
about
blocking
updates
to
resources.
While
the
controller
is
doing
work,
that's
issue
number
11:49,
and
that
is
you
Paul.
So
why
don't
you
go
ahead
and
take
the
floor?.
A
A
C
Mute
button:
okay,
it's
hard
to
say
if
we're
having
the
status
and
then
we're
having
like
the
operation.
That's
that
sort
of
to
me
reads
a
sort
of
state,
so
maybe
I'm
misinterpreting
that,
but
if
we're
establishing
sort
of
another,
you
know
we're
adding
status
to
the
thing
or
were
then
whatever
we're
doing
with
that,
then
I'd
like
to
see
a
basic
state
machine
diagram
a
little
hand
draw,
and
this
is
what
causes
X
to
move
from
provision
to
update
to
D
provision
or
whatever,
not
nothing.
E
C
C
C
A
B
D
Up
next
go
ahead:
yeah
I,
just
wanna,
make
sure
he
understood
what
was
going
on
here.
Cuz
I
must
try
to
understand
how
this
PA
changes
stated
or,
and
don't
don't
what
I'm
saying
is
I
push
back
on
a
state
diagram
I
think
that's
usually
a
good
thing
in
general.
So
do
you
understand?
You
know
how
things
through
the
system
I'm
just
trying
to
say
how
good
PR
actually
brought
up
the
need
for
a
state
diagram
where
we
didn't
need
one
before
I.
A
B
C
B
D
B
We
digress
alright,
so
we
did
yesterday
decide
that
we'd
like
to
come
to
a
consensus
on
this
proposal
as
it's
written
so
before.
I
start
writing
that
down.
This
would
be
the
last
chance
for
someone
to
bring
up
objections
or
ask
questions
before
I
write
our
consensus
so
last
chance
going
once
anybody
I
have.
B
Already,
let's
move
on
to
the
next
point:
this
was
originally
posted
by
Morgan
and
it
referenced
some
concerns,
Doug
hats,
but
both
of
you
guys
down
as
the
tenors.
So
this
is
a
round
issue.
Number
11:06
and
I
believe
Doug
hats.
The
concerns
with
splitting
apart
plans,
so
Doug.
Why
don't
you
start?
Okay,.
D
You
alright,
so
when
I
was
reviewing
Morgan's
PR
last
night
for
splitting
out
plan
from
service
class,
I
noticed
that
the
plan
name,
the
the
name
on
the
resource
called
service
plan
right
now
is
just
being
set
to
the
name
that
was
provided
to
us
from
the
broker,
which
is
fine,
but
the
broker
scopes
those
names
down
to
the
service
themselves
or
itself,
meaning
you
can
have
two
different.
You
can
have
two
different
plans
with
the
same
name
as
long
as
they're
in
two
separate
service
classes.
D
Now,
because
we
use
the
plan
name
as
the
kubernetes
resource
name,
that's
obviously
not
going
to
work
for
us,
because
the
way
we
have
it
set
up
right
now
is
service
plans
are
actually
global,
and
so
the
name
can't
just
pick
up
the
name
itself
from
the
broker
wine
Lily.
Why?
Finally,
hopefully
that
makes
sense
so
I
know
Paul
had
a
brief
chat
with
Morgan
about
this,
and
he
thought.
D
Well,
maybe
what
we
should
do
is
prepend
the
kubernetes
service
plan,
name
with
the
service
class
name,
so
it
becomes
MySQL
free,
for
example,
and
obviously
that
that
works
in
the
sense
that
it
makes
it
hopefully
unique,
but
it
doesn't
present
necessarily
the
best
user
experience,
because
now,
when
the
user
goes
to
create
their
instance,
they
need
to
provide
the
service
name
has
MySQL,
then
the
plan
name
has
to
be
MySQL
free
as
opposed
to
just
free.
So
it's
not
a
horrible
user
experience,
but
it's
not
the
best
either.
D
So
it
just
kind
of
got
me
wondering
whether
we
should
look
at
other
options
here,
like,
for
example,
when
in
the
instance
or
I
guess,
I
should
have
one
of
the
piece
of
information
that
makes
this
movie
more
interesting.
Is
insights
inside
its
service
instance,
dot,
pland
name.
We
right
now
have
that
plan
name
as
a
string.
It's
not
an
object
reference
now.
D
In
my
mind,
I
understand
this
is
just
something
I
have
in
my
mind:
it's
not
necessarily
codified,
but
because
it's
just
a
string
and
not
an
object
reference
that
gives
us
the
opportunity
to
twiddle
it.
However,
we
want,
before
we
actually
programmatically
turn
it
into
an
object
reference
and
go
find
the
plan
with
that
name,
which
means
we
could
allow
the
person
to
still
put
free
in
there.
But
then,
when
we
go
to
look
it
up,
we
can
prepend
it
with
the
service
class
name.
D
That
way,
even
though
the
plan
itself
is
called
free,
the
user
never
had
to
actually
write
free.
They
always
just
write
free.
So
that's
one
option
now,
of
course,
that's
not
necessarily
great
because
then
you
have
a
little
bit
of
a
disconnect
between
what
the
users
kind
of
referencing
and
what
the
thing
is
actually
called
funky
there.
So
what
I
want
to
do
is
just
to
bring
this
up
and
see
if
anybody
has
any
ideas
about
whether
we
this
is
a
concern
or
whether
there's
other
ways
to
address
it
and
before
I
sort
of
yield.
D
My
time
I
just
wanted
to
mention
that
there
is
one
other
option:
I,
don't
know
how
I
feel
about
it,
but
another
option
would
be
to
move
some
of
the
data
from
the
plan
resource
back
into
the
service
class,
meaning
it's
things
like
the
plan.
Name
now,
I'm
not
saying
to
duplicate
in
both
places,
just
try
it
out
move
it.
D
People
shouldn't
ever
really
reference
the
plan
directly
by
name
I.
Don't
think
I
should
ever
really
have
to
do
that.
So,
if
that,
if
that
name
is
just,
for
example,
the
ID
of
the
plan,
it's
not
that
big
a
deal
because
it's
always
gonna
be
accessed
programmatically
through
some
traversal
mechanism,
users
aren't
gonna.
Have
that
could
ever
happen
ever
have
to
type
that
out
themselves.
D
B
A
A
D
That
that
definitely
avoids
the
problem
to
some
extent.
I
am
a
little
bit
concerned
about
the
usability
side
of
it
because
I
think
for
the
most
part,
people
will
be
exposed
to
the
service
independent
of
the
plans.
Right
so
resemble
you're
going
to
look
for
a
database,
you're
gonna,
look
at
MySQL
and
they're
gonna
say:
okay,
what
are
the
plant
associated
with
it?
You
know
free
versus
paid
kind
of
a
thing
and
so
I
think
their
mental
model
is
while
they're
related.
D
D
So
that's
a
little
bit
of
concern
from
the
usability
side
of
things
from
the
programmatic
side
of
things.
I
think
it
gets
a
little
bit
dangerous
because,
whatever
concatenation
mechanism,
we
have
what,
if
that
happens,
to
align
directly
with
some
other
service
plan
that
already
exists.
For
example,
I
know
it's
a
horrible
example,
but
let's
say
there's
a
MySQL
service
and
if
plan
is
planned
one
and
then
someone
creates
a
MySQL
planned
service
whose
plan
is
one
when
you
can't
need
all
that
stuff
together.
A
Lock
that
right,
I
also
thought
of
where
else
this
breaks
down,
as
we
had
a
lengthy
discussion,
lively,
lengthy
discussion
about
optional
plan
names,
oh
yeah,
the
when
a
service
only
has
one
plan.
So
how
about
this
one
thing
that
I
think
we
should
think
about
is
I.
Do
not
personally
like
the
like
I
agree
with
you
on
a
usability
issue.
It
will
look
a
little
bit
janky
on.
A
Possible
that
in
the
long
term,
most
of
the
users
of
this
API
are
going
to
be
using
it
via
UI,
like
in
the
open,
shipped
console
and
Sam.
Correct
me
if
I'm
speaking
out
of
turn
as
someone
that
doesn't
know
anything
about
you
eyes,
but
the
in
the
open
ship
console
I
think
we
could
hide
this
from
people
and
likewise
than
any
other
web
UI.
We
could
hide
this
notion
and
then
I
also
expect
that
and
we've
we've
had
a
lot
of
interest
in
this.
G
D
A
It
would
certainly
be
possible
to
do
I,
don't
I,
don't
know
of
any
other
API
resource
that
works.
That
way
in
kubernetes,
though
so
I
think
most
people
would
expect
such
a
field,
whether
it's
called
name
or
whether
it's
reference,
and
you
put
the
name
in
the
the
references
in
field
to
actually
refer
to
the
kubernetes
name.
Yeah.
D
I
I
agree,
it
is,
it
is
definitely
Genki.
My
my
concern,
though,
with
saying
oh,
we'll
just
fix
this
up
with
porcelain
from
the
command
line
or
stuff
is
throughout
my
way
too
long
career.
Every
single
time,
I
hear
people
say
that
it's
usually
a
sign
that
something
is
way
too
complicated
and
it's
something
is
music
fix,
because
that
just
means
your
UI
is
as
serious
problems.
B
A
B
B
A
I
think
sane
is
relative.
I
personally,
don't
think
that
if
you
have
to
type
service
name
again,
I
think
I've
seen
worse
in
my
career,
it's
maybe
worth,
unfortunately,
siga
architecture
was
today.
It's
maybe
worth
a
chat
with
cig
architecture
about
how,
if
is
it
okay
to
do
this,
because
I
can't
think
of
any
precedent
for
doing
it.
B
Well,
yeah
I,
just
put
my
hand
up
to
respond.
They're.
Putting
the
service
in
front
of
the
plan
is
totally
fine
with
us.
Yes,
so
saying
is,
is
just
to
have
a
way
to
do.
This.
I
probably
should
have
left
off
saying,
but
to
have
a
way
to
do
this
in
a
manifest
instead
of
relying
just
on
porcelain.
So
that's
it
well.
A
I'm
sorry
I
think
I
think
that
you
may
have
misunderstood
what
I
meant
so
I.
Here's
the
specific
thing
I
was
saying
so
like
say:
you've
got
my
sickle
service
and
you
got
free
plan
and
the
thing
that's
janky
about
the
way
that
we
had
to
make
the
communities
names
because
of
how
those
names
are
scoped
into
SP
is
we
have
to
call
the
objects
of
the
plan,
my
sequel,
free
and
by
porcelain.
I
meant,
though,
that
we
could
have
like
a
create
service
instance,
cube
CTL
extension
that
you
would
say
create
a
service
instance.
A
B
F
I
just
wanted
to
point
out
quickly
and
I'm,
not
sure
how
much
of
a
problem
this
will
actually
be
in
practice,
but
depending
the
service
name
to
the
plan
name
does
not
necessarily
guarantee
uniqueness
like
at
the
end
of
a
service.
There's
the
same
as
the
start
of
another
plan.
You
could
essentially
have
Coors
inks
in
your
name.
D
C
D
D
F
A
Yeah
I
am
close
to
an
agreement
with
you
Doug,
but
I
I
know
that
for
one
of
our
brokers
it
will
just
this
will.
Your
suggestion
will
break
because
we
generate
default
names
that
are
just
default
plans
in
one
of
our
brokers.
That
I
know
about
so
I
wonder
if
we
can
just
as
a
temporary
measure,
because
I
don't
I,
don't
want
to
block
the
PR
either
I
know
well
the
tax
associated
with
rebasing.
D
A
A
F
I
was
just
going
to
throw
out
another
possibility.
I
don't
know
if
this
is
better
or
worse
or
ugly,
but
you
can
generate
you
know
in
these
unique
by
character
spring
at
the
end
of
the
plan.
Name,
if
you
want
to
guarantee
uniqueness,
or
at
least
be
pretty
sure,
you're
going
to
get
something
unique,
that's
possible!
Well
as
program
name
service
plan
name,
it's
too
long.
A
So
Sam
I
get
where
you're
coming
from,
but
we
have
to
detect
if
names
changed.
So
we
need
something
consistent,
I
think
external
idea
would
be
so
suitably
terrible.
It
passes
the
terrible
name.
Just
that's
our
bar
I
love
it
that
could
also
be
a
name
plus
external
ID
would
would
be
still
bad
enough,
but
left
terrible
because
at
least
you
conceded
the
plan
name
in
there.
B
B
B
B
B
We're
good
with
external
IDs,
so
we're
not
gonna
vote
on
this
one
which
one
do
people
want
to
do.
Do
you
want
to
do
name
plus
external
ID,
external
ID,
whatever?
What?
What
are
the
ideas
on
the
floor?
Yeah
I,
like
I,
like
name
first
and
I,
put
that
in
the
in
the
minutes.
Okay,
so
plan
name
plus
external
ID,
is
what
I'm
hearing
is
that
any
objections
to
that?
B
B
D
B
A
So
we
talked
in
the
face-to-face
about
having
a
record
in
the
status
of
what
are
the
field
values
or
what
are
the
property
values?
Property
is
like
plan
parameters.
You
said
that
the
broker
actually
knows
about
I
wrote
up
a
proposal
for
doing
this,
for
instance,
and
binding,
and
the
proposal
is
that
for
well.
Let's
talk
about
service
instance,
excuse
me
or
service
instance.
We
will
add
to
the
status
two
new
fields.
A
One
is
the
in
progress
properties
and
it's
a
record
of
what
properties
we're
currently
performing
in
action
on
a
spur
and
then
the
other
is
external
properties.
That'll
be
a
record
of
what
properties
the
broker
knows
about.
For
this
instance,
of
course,
names
I
in
about
five
seconds.
Thinking
about
we
can
change
names
as
we
find
things
that
are
better
and
the
reason
that
we
need
the
in
progress.
A
One
is
we
might
have,
even
though
you
can't
change
the
spec
while
you're
doing
something
to
these
objects,
you
might
have
a
scenario
where
a
secret
changes
a
command
and
it
changes
the
changes.
The
parameters
that
you
would
send.
So,
let's,
let's
dig
into
what
these
things
are
really
quick.
So
for
a
service
instance,
the
type
that
holds
this
information
is
called
service
instance
property
estate
again
about
two
seconds
on
a
name:
I
have
got
the
plan
name,
it's
got
the
parameters
where
those
are
the
actual
parameters
that
we've
set,
with
the
exception
of.
A
If
we
sent
a
particular
parameter
source
from
its
secret,
we're
going
to
put
redacted
into
this
blob
so
that
we
can
see
that
we
sent
them,
but
that
the
we're
not
going
to
show
the
values,
because
this
can't
be
an
escalating
resource.
And
then
we
have
to
store
a
checksum
for
the
blob
of
parameters
that
we
sent,
because
when
you
update
an
instance,
you
have
to
be
able
to
detect
whether
the
user
intended
the
parameters
to
change.
A
You
should
only
send
the
parameters
during
an
update
if
the
user
actually
wanted
them
to
change
any
questions
about
this
before
we
go
on
and
I
guess,
I
will
add
to
that
that
when
you
complete
an
operation,
you
update
the
external
properties.
I'm.
Sorry,
when
you
start
an
operation,
you
set
the
in
progress
properties
and
when
you
complete
it,
you
move
the
external
properties
to
you,
move
the
in
progress
properties
to
the
external
properties
and
you
unset,
the
in
progress
property,
cool.
D
All
right,
Doug,
you
are
up,
go
ahead:
yeah
I,
apologize!
If
you
already
explained
this
either
just
now
or
through
the
issue
itself,
for
some
reason,
I
just
haven't
or
remembering
it,
the
in
progress
properties,
one
I'm
not
sure
I,
understand
why
we
need
to
keep
the
list
of
property
names
in
there,
because,
whether
they
change
or
not,
you're
always
gonna
go
back
to
the
secret
itself
and
grab
the
latest
stuff
right.
D
We're
planning.
You
know
you
can
use
that
later
on,
say:
oh
I
want
to
create
another
one
of
these
things,
so
I'm
going
to
use
it,
but
just
the
key
names
by
themselves.
Don't
really
help
you
a
whole
lot.
So
I'm
not
sure
I
see
value
that
that's
definitely
true,
but
what
I'm
trying
to
understand
is
even
if
we
choose
to
save
the
property
names
in
the
external
properties
structure,
because
for
some
reason
we
do
see
value
in
keeping
that
I'm,
not
sure
I
see
the
value
in
keeping
it
for
the
in
progress.
D
F
F
A
A
D
A
D
B
B
B
Does
anyone
else
have
anything
they
want
to
share
any
comments,
any
questions,
anything
they
want
to
add
to
the
agenda
going
once
all
right
go
check,
action
items
and
besides
that
I
will
see
everyone
on
the
Internet
and
then
again
back
here
at
the
next
design
meeting
September
5th,
Tuesday
September
5th.
Thanks
a
lot,
everybody.