►
From YouTube: Kubernetes SIG Service Catalog 20170920
Description
- K8s names of service classes and plans
- CLI experience
- List of plans in service class?
A
A
Yes,
okay,
all
right!
So
when
we
go
and
take
a
look
at
that
thing,
I
made
one
change
to
this
yesterday
or
one
change
to
this
today,
which
is
that
the
fields
that
were
called
OSB
service
name
OSB
plan
name.
I
changed
to
the
external
service
name
and
external
plan
name,
because
that
will
align
better
with
the
external
name
fields
in
service
class
back
in
service
plan.
Spec
I
did
have
a
chance
to
talk
to
Microsoft
about
this
and
they
are
they're.
Okay.
A
With
this
proposal,
they
have
an
additional
ask,
which
is
attitude
that
they
want
to
do
after
that
implemented
and
that
additional
ask
which
I'll
create
a
I'll
create
an
issue
for
is
to
be
able
to
use
instead
of
the
external
service
name
in
this
plan.
Name
use
the
external
IDs,
as
opposed
to
the
kubernetes
names,
haven't,
have
an
alternate
selection
mode,
where
you
say
the
external,
the
external
ID
and
the
reason
that
they
want.
That
is
because
and
I
think
this
is
actually
a
very
sensible.
A
They
want
to
be
able
to
write,
helm,
charts
or
templates
or
just
yell
resources
that
are
proof
against
name
changes,
and
so
the
scenario
that
they
want
to
prevent
is
they
write
a
chart
that
references,
the
service,
name,
Kent's,
incredible
service,
they
publish
that
chart
and
then
they
have
a
them.
The
team
that
operates
the
broker
is
like
oops.
We
should
have
called
it
Kent's
stupendous
service.
Another
chart
doesn't
work,
so
this
does
not
change
anything
about
this
proposal.
A
It's
just
an
alternate
mode
that
they
want
for
addressing
these
things
and
I
think
it
would
be
easy
to
implement
as
a
purely
additive
thing.
So
with
that
in
mind,
that's
a
that's
a
plus
one
from
Microsoft
I
wonder.
Does
anybody
else
have
any
questions
comments
about
this?
We
decide
that
it's
a
consensus
that.
B
A
A
There
gonna
be
an
expectation
that
those
external
names
are
kept
up
to
date
in
the
service
instance
Peck
right
now.
No
there's
nothing
in
the
proposal
that
says
we're.
Gonna
keep
them
up
to
date
for
a
name,
change,
okay,
I
think
it
would
be
possible
to
do
in
the
future.
I
I,
don't
see
it
as
a
requirement.
Now.
B
Okay,
so
since
my
hands
up
so
just
to
be
perfectly
clear,
then
there
could
be
a
difference
between
what's
in
the
spec
versus
reality,
and
if
the
user
wants
to
see
not
what
the
name
was
when
they
requested
it.
But
what
the
name
is
as
it
currently
stands.
They
need
to
follow
those
reps
in
there
to
the
actual
service
class
or
plan
and
look
at
that
name
in
there
right
right
now:
yeah,
okay,
cool.
C
Belay
I've
rolled
so
since
I'm
making
these
changes
right
now,
I'm
also
able
to
go
and
document
them
hear
a
little
bit
more
about
the
behavior,
which
is
that
these
were
jotted
down
at
the
time
of
creation
and
updated
whatever
and
then
I
will
say.
I've
also
said
that
those
those
two
pieces
below
paragraphs
are
the
ones
who
you
know
go
reps.
I
will
capitalize
for
paul's
enjoyment.
D
B
A
However,
in
one
seven,
there
was
a
feature
added
to
cube
CTL,
where
the
open
API
spec
can
indicate
which
columns,
cube,
CTL
should
show
and
what
they
should
be
named.
Main
key
at
Google
has
a
pull
request
open
for
this,
but
there
are
some
questions
lingering.
It
related
to
the
fact
that
you
currently
have
to
Coast
host
the
open
API
for
the
for
the
core
API
to
anyway.
A
It
looks
like
it
is
possible
for
us
to
define,
without
adding
code,
to
cube,
CTL
a
way
to
show
the
columns
and
my
copious
spare
time,
I'm
hoping
in
the
next
24
to
48
hours
at
latest
the
weekend
to
spend
some
time
fiddling
with
this
branch
and
seeing
if
we
can
make
a
really
nice
keep
CTL
get
experience,
which
I
think
is
something
that
would
be
very
valuable
if
we
were
able
to
do
so.
That's
that's
a
thing.
A
A
E
Yeah,
that's
right.
I
gotcha
noticed
in
respect
that
the
the
plans
is
an
array,
so
the
broker
presumably
can
specify
an
order
and
we
were
trying
to
display
the
plans
in
the
order
from
the
broker.
But
when
the
plans
were
split
out
of
the
service
class
resource,
there's
no
longer
an
array,
we've
lost
the
order.
A
B
I,
don't
think
there
are
I
I.
Think
it's
just
a
JSON
array.
It's
just
the
mechanism.
They
used
to
return
them.
I,
don't
think
we're
supposed
to
infer
any
ordering,
and
especially
not
a
quote,
preferred
list
order,
meaning
there's
no
route.
The
first
one
is
not
something
users
should
use
over
the
last
one.
People
should
pick
them
based
upon
the
QoS
properties
right
there,
the
cost
and
stuff
like
that.
E
I
buy
preferred
order.
I
didn't
mean
that
the
first
one
in
the
list
is
the
one
that
brokers
want
you
to
pick.
I
just
meant
that
this
is
like
a
display
order.
So
maybe
preferred
order
was
a
poor
choice
of
words,
but
you
know
I,
don't
know
that
the
spec
says
that
I
don't
know.
The
spec
makes
a
statement
about
that
at
all.
But
since
we
were
getting
them
back
as
an
array,
we
were
trying
to
keep
the
order.
C
It
reminds
me
a
little
bit
of
issue
of
how
do
we
deal
the
parameter
order
and
in
the
schemas,
and
it
might
be,
if
there's
a
way
to
go
ahead
and
specify
that
or
at
least
tied
in
the
wording,
we're
gonna
say:
yes,
it
should
water
or
no,
it
shouldn't
be
and
then
come
back
and
then
I
I
think
we
are
gonna
have
to
stash
something
away
on
the
service
on
the
broker
that
keeps
track
of
the
order
and
I
don't
think
we
can
do
it
in
service
classes.
I
think
that's
in
the
broker.
B
Yeah
so
I
so
I'm
up
next,
so
I'd
be
a
little
concerned.
I'm
not
I'm,
not
dead,
set
against
it
because
I
haven't
enough
thinking
about
it.
But
my
initial
gut
reaction
is
it's
a
little
concerning
that
we
might
actually
make
the
order
matter
because
then
you
could
do
a
realistic
appearance
or
dur.
Then
there
would
be
before,
but
everything
else
is
the
same.
Does
that
mean
the
platform
has
to
reflect
that
new
order?
And
what's
the
significance
of
that,
I'd
almost
prefer
to
just
say
it's
a
platform
choice
they
are
given
display
names.
B
It
seems
perfectly
reasonable
to
me
and
maybe
at
most
the
spec
give
a
recommendation
that
says:
hey
you
may
want
to
alphabetize
them,
but
otherwise
I
don't
think
the
spec
necessarily
has
to
provide
an
order,
because
the
minute
you
do
people
are
gonna,
try
to
infer
things
into
it
that
we
probably
didn't
intend
the
exact
same
way
that
not
saying
anything,
Sam
inferred
an
ordering
right.
It
gets
it's
a
very
slippery
slope.
So
anyway,
that's
finally
that's
my
initial
comment
on
it.
Levi
you're
up
you.
C
B
A
Getting
clarity
would
be
good,
I
think
that
we
can
assume
that
they're
unordered
for
now
one
option
that
we
have
to
ensure
that
people
do
not
read
into
things
is.
There
is
a
hook
in
the
registry
infrastructure
that
allows
us
to
canonicalize
an
object
before
it
gets
persisted,
which
gives
you
a
chance
to
do
things
like
sort,
an
array
that
kind
of
thing,
so
we
can
ensure
that
they
are
always
persisted
in
a
in
alphabetized
order
or
reverse
reverse
alpha
alphabetized.
E
To
me,
like
from
a
user
experience
perspective
like
I,
don't
see
why
we
would
want
to
prevent
and
stalkers
from
saying
this
is
the
order
we'd
like
them
displayed
like
it's
sort
of
like
the
parameter
ordering
in
a
form
where
a
certain
order
might
make
sense.
You
know,
and
only
the
broker
knows
that
so,
but
regardless
yeah
I
think
it
needs
to
be
clarified
in
the
spec
so
like
whatever
the
decision
is
I'm
stream
like
form
what
we
do.
E
A
I
do
think
that
one
thing
I
have
been
thinking
about
is,
if
possible,
I
think
it
would
be
good
to
have
a
list
of
plans
and
I
know
that
I
previously
said.
I
didn't
think
that
we
should
do
this,
but
I
changed
my
mind.
So
I
think
it
would
be
cool
to
have
a
list
of
plans
on
the
service
class,
at
least
the
plan
names
and
maybe
another
field.
That's
like
references
to
the
actual,
I'm,
sorry
yeah
to
the
actual
service
plans.
I
think
it
would
be
good
to
be
able
to
display
these
in
queue.
A
B
D
B
The
same
concerns
so
so
my
hands
up
forth
on
it
so
Paul
would
it
be
horrible
if
for
beta,
we
left
it
out
and
then
got
feedback
on
the
user
experience
to
know
whether
we
can,
whether
we
should
add
it
later
since
adding
it
obviously
is
additive.
It's
not
gonna
break
the
schema,
but
if
we
move
adding
it
now,
then
realizing
we
don't
need
it
later
would
be
a
bad
change.
I
wonder
whether
we
should
live
with
it
for
now
and
then
possibly
revisit
after
beta
I.