►
From YouTube: Kubernetes SIG Service Catalog 20171218
Description
- CLI prototype demo
- UI introductions
A
B
B
D
E
D
Yep,
so
I've
opened
a
PR
for
this
and
in
the
last
week
this
is
just
a
demonstration
of
what
I
have
so
far
so
I've
decomposed,
the
plugins
I,
should
last
them
I.
Think
I'd
individual
like
create
service
broker,
with
certain
commands,
so
I've
decomposed
that
until
I
had
a
plugin
for
each
abstraction
each
resource
now
and.
D
So
so
far
for
all
of
these
I've
implemented
lists
and
get
also
sort
of
an
aside,
I've
been
working
sort
of
with
this
CLI
sig
sort
of
the
back.
Half
of
this
plugin
been
turning
it
into
a
library
for
generic
plugin
use.
So
I
PR
open
against
the
sea
lies
tube
control,
repo
as
well,
and
the
benefit
of
this
is
is
once
that's
accepted
and
I
can
merge
these
plugins
that
were
using
that
one.
D
It
should
be
much
quicker
to
get
things
up
running
so
I
have
listening
to
get
implemented
so
far,
but
it
would
be
pretty
easy.
Just
to
add,
you
know
the
rest,
crud
or
realist
brokers,
or
you
know
whatever
you
cared
to
do
so.
I
have
a
couple
brokers
running
on
my
kubernetes,
so
I'm
just
gonna
go
ahead
and
list
those
so
I
have
a
one
called
fake
services.
Well
looks
like
this
bug.
D
You
can
see
the
classes
are
listed
and
I
didn't
actually
go
through
and
instantiate
any
of
these.
So
that's
as
far
as
this
guy's
I
didn't
actually
create
instances
yeah.
So
this
is
just
sort
of
a
demonstration
of
what
I
have
working
so
far.
Are
we
interested
in
continuing
to
pursue
this?
Is
this
something
we
like
thoughts?
Discussions?
D
A
D
A
That
yet
and
lists
are
things
that
we
should
try
to
make
cute
Cpl
do
I
think
that
projects
that
want
to
prototype,
like
what
you
want
to
see
the
output
from
listen
get
to
be
are
useful
to
try
to
figure
out
where
we,
where
do
we
want
to
aim,
but
like
the
plugin
mechanism,
as
far
as
I
know,
is
not
supposed
to
allow
me
to
get
and
lists
so
I
was
trying
to
see
if
Fabiana
prawns
could
join
us.
Are
you
going
to
with
him
at
all.
A
I'm
definitely
interested
from
a
pledget
standpoint
for
things
like
created
in
instance,
and
create
a
binding.
My
own
opinion
is
that
we're
listening
at.
We
should
try
to
fix,
keep
CTL
in
general
so
that
we
don't
have
to
have
plugins
proliferate
in
the
community
instead
of
just
like
fixing.
Listen
again,
all
right,
yeah.
D
F
D
So,
in
terms
of
the
plugin
framework
for
cube
CTL,
you
can
yeah,
you
can
add
pretty
much
anything
because
you,
the
way
it
works.
Is
you
write
your
own
binary
and
the
CLI
passes,
control
to
your
binary,
so
I've
written
five
binaries
one
for
interacting
with
each
of
the
abstractions
so
like
and
currently
I
had
lists
and
get
for
those
five
abstractions
so
like.
If
you
wanted
to
be
able
to
filter
things
like
I
could
add
like
a
flag
to
plan
list
by
like
by
class
tested
in
like
a.classname,
okay,.
C
D
D
F
E
D
E
D
E
E
E
B
A
A
D
Next
plan:
oh
sorry,
that
would
okay
my
next
plans-
if
this
is
something
we're
interested
in
doing
we'd,
probably
be
adding,
create
and
delete
for
these
five
abstractions
and
yeah
I
could
do
relist.
Cuz
I
actually
already
have
most
of
the
code,
because
I
sort
of
person
come
into
that
under
the
old
way.
I
was
writing
them
so
that
that
would
be
where
I'd
be
taking
this.
The
next
step,
if
continuing
yeah.
A
I,
don't
think
we
need
to
delete,
since
we
already
have
super
CTL
belief,
but
I
would
definitely
I
definitely
think
there's
value
in
like
a
command
that
would
be
like
create
service
instance
or
create
service.
Finding
that
you
don't
have
to
baby
animals.
You
can
just
say
this
is
what
I
want
to
make
an
instance
of
is
what
I
want
to
do
is
find
to
about
that.
That
I
think
has
a
lot
about
it.
B
H
G
I
E
I
G
For
instance
the
the
aggregator
which
was
aggregating,
the
open
IETF
schemas
from
the
core
and
from
the
Service
Catalog
speed
server
did
not
produce
good
enough
schema,
it
duplicated
some
entries
and-
and
it
didn't
update
the
references
properly.
So
I
also
had
to
fix
that
and
there
was
no
proper
support
or
raw
extension,
which
is
used
in
service
instances
for
parameters
right.
So
I've
also
had
to
fix
that
and
then
then
breaks
the
you
GPL
itself.
G
J
E
E
G
H
E
E
E
G
Yeah
because
that's
in
the
open,
API
schema,
which
is
served
by
the
analog
API
server,
and
by
default,
there
were
only
two
columns
name
and
age
I.
Believe
oh
I
got
it:
okay,
Thank,
You,
ABS,
confused
okay,
I
mean
if
you,
if
you
look
at
the
right-hand
side
of
the
screen,
you'll
see
the
annotation
which
defines
the
column.
So
this
is
it.
A
G
B
E
Morgan,
do
you
have
the
PR
number
or
you
will
be
pasted
into
the
chat
and
actually
we're
getting
you
through
slack?
You
had
mentioned
actually,
okay,
any
other
Morgan
you
had
mentioned.
There
are
some
topics
you
want
to
discuss
that
seem
to
have
vanished
from
the
agenda.
Did
you
want
to
discuss
your
or
the
one
thing
that
I
had
about
this.
A
B
F
So
I
can
see
everything
about
it
like
when
it
last
fetched
in
the
catalog
and
then
I
can
get
say
the
classes
and
so
I
have
an
instance
using
my
sequel
here.
So
I
can
do
as
week
at
let's
do
like
subscribe
class,
my
Azure
DV.
So
it
gives
me
all
the
standard
intro
its
status
and
then
what
plans
are
on
it
and
then,
if
I
want
to
take
a
look
at
some
eye
instances,
I've
got
a
quick
start
here
using
WordPress.
So
I
can
say
a
speak
at
describe
incense.
F
And
I
can
see
if
I
do
tea.
It
shows
me
a
whole
bunch
of
information
up
and
down
the
hierarchy.
So
I
can
see.
You
know
the
name,
the
name
space
stuff
like
that,
what
classic
came
from
the
plan
and
the
broker
as
well
or
if
I
want
to
look
at
like
who
is
using
a
particular
plan
like
a
notice,
we
can't
describe
plan
standard
and
then
I
can
see
like
okay
I
have
two
instances
of
this
on
my
cluster.
So
that's
the
tool.
I
don't
have
provision
or
anything
like
that.
F
E
Well,
maybe
you
can
mute
I
think
it's
kind
of
from
your
side.
I
was
wondering
if
someone
maybe
I,
don't
know
if
it's
Carolyn,
Jonathan
or
Aaron
can
talk
about
the
possible
harmonization.
That's
going
on
here
between
the
the
plugins
stuff
that
Jonathan
was
working
on
and
the
Microsoft
service
cat
tool,
yeah.
B
I
am
happy
to
I'll
make
this
quick,
because
I
apologize,
I
didn't
put
my
hand
up.
We
talked
with
Phil
ratrock
at
KU
con.
He
laid
out
a
nice
plan
for
Jonathan
and
I
and
Carolyn
and
others
whoever's,
building
a
CLI
to
merge
some
kind
of
common
functionality.
Little
n
big
up
to
kubernetes
coop
CTL
the
repo,
and
he
wants
to
create
it.
There
clean
it
up
and
eventually
he
would
like
to
swap
out
some
of
that
common
functionality
in
coops
ETL,
with
this
common
functionality
in
the
coop
CTO
repo.
E
E
B
Can't
really
speak
to
the
plugins
from
Fabiano
and
Phil.
Both
of
them
have
kind
of
differing
opinions
on
what
plugins
should
be,
what
the
future
of
plugins
are.
Sv
cats
gonna
stick
around,
though,
until
there's
a
really
good
story
for
both
reading
and
muta
and
mutating
operations
in
core
coupe
CTL.
If
that,
actually
you
know,
if
that's
going
to
happen
or
not,
okay,.
A
It
looks
to
me,
like
we
have
a
potentially
very
useful
bit
in
different
places.
I
think
there
will
be,
but
it
will
make
sense
like
in
in
a
vacuum
in
the
kubernetes
good
system,
that
different
projects
will
want
to
have
different
plugins,
and
maybe
vendors
will
want
to
differentiate
certain
things
with
plugins,
but
I
do
think
that
it
would
be
best
for
everybody
if
the
things
that
we
agree
on
can
be
in
like
a
vendor
neutral
area.
A
So,
for
example,
a
not
to
pick
on
you
Microsoft,
there
were
probably
some
vendors
that
would
not
want
to
ship
something
they
came
from
like
a
Microsoft
repository
and
I,
don't
even
know
if
it's
in
a
Microsoft
repository
but
like
just
having
a
vendor
association
might
make
some
like
vendors
uncomfortable.
Some
other
vendors
are
uncomfortable
of
shipping
extra,
wiping
so
in
I
think
it
would
be
awesome
if
we
could
put
together
like
a
baseline,
plug-in
or
set
of
plugins
that
had
common
things
with
a
good
us.
A
So
I
think
everything
that
I've
seen
here
today
is
really
interesting
and
I'm
glad
that
people
have
been
prototyping
in
the
space
and
I
hope
that
we
can
work
together
to
have
something.
That's
like
a
base.
Bullion,
that's
just
we're
sort
of
Catalan
repo.
If
you
can
install
it,
gives
you
a
good
CLI
experience
around
a
thing.
Is
that
maybe
order,
but
that
are
just
like
intrinsically
not
easy.
A
I
do
think
that
we
should
make
cute
CT
I'll
go
as
far
as
we
can
get
to
go
so
I'm,
actually
pretty
pleased
that
the
open,
API
columns
are
turned
on
by
default
in
q1
9pc
CL
from
one
that's
which
to
enable
that
is
pretty
big
and
hairy
anyway.
That's
that's
it
for
me.
Thanks
everybody
that
showed
down
today,
cool.
D
F
B
Cool
I
have
my
hand
up
I'll,
be
quick,
so
yeah
we
built
this.
It's
an
azure
repo,
happy
to
donate
it
upstream.
If
people
are
interested,
that
was
always
our
plan
and
where
I
was
willing
to
do
it.
I,
don't
think
this
is
my
controversial
part.
I,
don't
think
coops
ETL
plugins
are
the
right
place
for
any
of
this
functionality,
because
this
is
domain-specific.
B
That's
why
we
built
it
as
a
separate
sea
in
the
first
place.
I
also,
don't
think
that
coops
ETL
plugins
are
ready
at
all
for
user
consumption.
Everything
from
the
user
experience
to
install
even
through
to
the
fact
that
you
have
to
type
coop
CTL
plug
in
X,
cube,
CTL
plugin.
Why
none
of
it
feels
right-
and
none
of
it
is
right,
in
my
opinion,
to
do
anything
simple
or
complex
on
server
catwalk.
That's
it
for
me,
any
other
comments,
questions,
hey
ter
in
reactions,
etc.
I,
don't.
A
Disagree
with
you
I
think
that
I
think
that
we
can
probably
try
to
do
both
right,
like
like
having
C
allies,
that
we
have
reasons
that
we
can
say,
like
you
know,
X
or
Y
thing
wouldn't
be
possible
to
implement
in
a
plug-in
right
now.
It
is
probably
good
feedback
to
drive
plugins
to
a
point
where,
like
it
means
where
you
would
want
to
use
them.
So
I
think
that,
like
I,
think
I
I
just
want
to
be
super
clear.
I'm,
not
trying
to
say
that,
like
any
project,
is
wrong.
A
K
Michael
I'm
sorry
I
thought.
If
I
got
up
on
all
your
issues
here,
I
have
an
issue.
Question
I
wanted
to
ask.
Is
so
I
like
the
work
I've
seen
here,
I'm
just
curious.
If
there's
thoughts
on
access
control
like
right
now,
it
looks
like
I
might
have
service,
can
I
can
do
whatever
I
want
to
whoever
I
want
I
want
so
I
assume
that's
kind
of
at
the
the
cards
in
the
future
I'm
just
asking
so.
A
That
was
a
topic
of
discussion
at
recent
face-to-face
in
Raleigh.
Yes,
the
distorting
answer
is
yes:
we
want
to
have
our
back
policies
or
another
mechanism
that
will
restrict
the
services
and
plans
that
you
can
see
as
well
as
used
the
the
TLDR
of
the
challenge.
There
is
that
it's
very
easy
to
right
and
our
back
rule
and
add
code
to
the
controller
about
checking
to
see
whether
you
have
a
particular
have
the
ability
to,
for
example,
provision
a
particular
service
or
plan.
A
It's
not
easy
to
implement
a
list
filtering
using
our
back
or
some
other
ACL,
so
that
is
that
is
a
great
unsolved
problem
in
that
area,
but
the
yes.
That
is
something
and
everybody
is
very
interested
in
and
that
hopefully,
will
be
part
of
like
release
and
as
soon
as
possible,
because
my
product
manager
is
at
Red
Hat.
One
is
super
bad.
A
lot
of
other
people
want
it
super
bad.
A
E
E
Guys
so
the
issue
here
is:
let's
see
where
to
begin
okay.
So
when
the
when
kubernetes
talks
to
a
service
broker,
it
includes
in
the
API
requests
a
little
chunk
of
JSON
called
context
which
includes
information
about
the
platform.
That's
making
the
call,
for
example,
on
the
Cloud
Foundry
world
that
includes
the
organ
space
in
the
kubernetes
world.
E
It's
going
to
include
the
namespace
related
to
force
net,
where
the
secrets
are
going
to
get
created,
doing
a
binding
stuff
like
that,
and
as
part
of
that
information,
we
need
to
include
a
cluster
ID,
just
some
unique
identifier
that
says
which
conveys
cluster.
This
request
is
for
because
there
are
some
use
cases
where
the
the
entity
making
the
request
to
the
broker
actually
spans
multiple
kubernetes
clusters,
and
so
we
need
some
unique
way
of
knowing
as
we
did,
the
broker
needs.
E
Some
unique
unique
way
of
knowing,
for
this
particular
platform,
is
making
the
call
which
specific
cluster
is
talking
about.
That's
why
we
need
this
cluster
ID
and
even
though
cluster
IDs
seems
like
a
pretty
generic
thing
for
kubernetes
in
all
the
discussions
that
we
had
with
the
core
team.
I
think
API
server
or
Sagarika
tech,
chure
I,
came
in
all
different
places
that
the
Morgan
talked
to.
They
couldn't
agree
on
where
it
should
live,
what
it
should
mean
in
terms
of
you
know
what
is
the
URI
I'm?
E
So
that's
why
Morgan
has
worked
on
this
PR
and
our
stuff
as
opposed
to
core
kubernetes,
that
summarizes
it
Morgan,
yep,
okay,
so
anyway,
as
part
of
Morgan's
PR,
he
created
a
new.
What's
right,
crazier
API
group
that
I
praised
for
it.
No
that's
in
the
same
group,
it's
just
a
new
type,
a
new
type,
okay
yeah,
so
he
create
a
new
type
to
to
hold
this
information.
E
A
So
so
my
question
is,
like
I've
actually
suggested
in
the
past,
when
this
came
up,
that
it
might
be
a
good
way
to
prototype,
to
add,
like
a
config
map
for
a
CLI
flag
for
the
controller,
and
it's
just
not
clear
to
me
what
the
API
resource
is
really
given
that
it
seems
likely
that
eventually,
there
will
be
some
first-class
insertion
of
this.
That
will
be
in
conflict.
L
E
E
A
A
B
Let
me
just
real
quick:
what
I'm
hearing
are
one
implemented
option
and
at
least
two
maybe
three
other
options:
I
think
it
would
probably
be
good
to
have
these
written
up
in
some
kind
of
concise,
summarizations
I
know
there.
We've
had
some
discussions
on
them,
I
think
I
heard
they
were
also
discussed
a
bit
of
the
face
to
face,
but
I've
never
seen
them
in
one
place
or
even
in
three
places
like
written
down.
B
E
E
We
head
down
that
path.
Is
that
problematic
at
all
and
I'd
reason
I'm
asking
is
because
I
know
I
think
my
first
start.
That
was
a
long
long
time
ago.
The
concern
about
storing
our
resources
in
farm
start,
storing
our
resources
as
third-party
resources
or
CR
DS
was
always
an
option,
but
I
think
as
a
recently.
That
option
is
no
longer
useful.
What
I'm
sorry,
but
that's
not
a
rule
or
not
a
requirement.
I.
A
It
would
be
to
to
store
the
value
of
the
cluster
ID
that
you
want
to
send
in
an
instance
of
the
config
map
resource
from
the
community
to
API
and
configure
the
controller
with
the
namespace
and
name
back
from
Sigma,
and
then
a
controller
on
startup
would
make
a
call
to
the
API
server
to
read
that
particular
config
map
and
pull
the
value
added.
Does
that
make
that
great.
E
I
think
that
the
same
thing
is
what
I
was
saying:
it's
just
back
in
the
back
of
the
time
when,
when
the
Service
Catalog
controller
wasn't
going
to
access
the
main,
it
was
gonna
access,
the
main
kubernetes
api
server.
For
for
our
resources,
right
back,
we
were
going
to
use
third-party
resources
or
c
rd
e.
A
A
A
The
CRTs
have
have
fixed
a
lot
of
things
about
the
implementation
of
third-party
resources,
but
they
do
not
support
multiple
versions,
which
is
probably
the
key
thing
that
still
makes
them
not
a
great
choice
to
store
a
resource
data
from
another
API
and
I.
Don't
I,
don't
think
that's
a
concern
for
this,
and
in
fact
we
already
read
the
namespace
uie
from
the
main
API
server.
So
I,
don't
think
I,
don't
think
it's
a
concern.
I
think
I'd.
E
E
Maybe
I'm
misunderstanding,
but
my
understanding
was
that
people
that
there
were
some
use
cases
where
people
wanted
to
keep
the
main
at
CD
four
core
kubernetes
completely
separate
from
Service
Catalog
resources.
So
they
may
actually
have
two
separate
at
CDs,
one
for
Cork
ooh,
one
for
Service,
Catalog
and
I
think
Paul.
What
you're
suggesting
is
that
that
may
be
true,
but
for
this
particular
cluster
ID
resource
go
ahead
and
put
that
right
in
Service
Catalog
at
CD,
but
into
core
kubernetes
at
CD.
I!
Wonder
if
that's
a
guess,
yeah.