►
From YouTube: Kubernetes SIG Service Catalog 20170921
Description
- Cluster ID
- API machinery rebase
- kubectl plugin
A
B
So
we've
been
going
back
and
forth
for
a
while
now
with
some
of
the
guys
in
the
and
the
core
team
trying
to
figure
out
how
best
to
generate
and
where
to
store
this
particular
ID
and
on
the
sick
architecture
call
today,
we
finally
got
her
resolution
and
the
paths
that
were
going
to
head
down
now
is
to
have
Service
Catalog
generate
its
own
cluster
ID
store
it
manage
it.
Do
whatever
easy
to
do
it
all
within
the
scope
of
the
Service
Catalog
API
server.
B
We
are
not
at
this
time,
gonna
store
it
within
communities,
core
someplace.
That
may
happen
in
the
future,
but
for
right
now,
because
we're
not
her
person
sure
who
else
may
use
it,
what
the
use
cases
are
and
since
moving
it
is
the
most
part
should
hopefully
just
be
an
internal
thing
that
should
not
really
be
exposed
to
users.
Hopefully
we're
gonna
stick
with
it
being
a
Service
Catalog
only
thing
right
now
and
keep
within
our
API
server.
So
you
see.
B
As
of
right
now,
Morgan
I've
been
talking
about
this.
We
were
thinking
of
possibly
just
creating
a
new
resource
to
hold
this
piece
of
information.
There
will
be
a
new
singleton
resource,
meaning
you
can
only
create
one
instance
of
this
type
of
class
or
have
a
very
object,
and
it's
basically
going
to
be
the
equivalent
of
a
config
map
kind
of
thing.
So
it's
gonna
have
just
one
properties
in
there
with
a
string
value
and
whatever
kind
of
constraints
you
want
around
it
in
terms
of
accessibility
and
who
has
write
access
to
until
like
that.
A
B
Response
I
got
back
today,
I'm
a
cig
architecture
call
was
they
did
not
wanted
to
be
in
the
core
as
of
right
now,
because
it
wasn't,
there
was
a
clear
consensus
that
there
was
a
single
UID
be
used
across
all
use
cases
that
wanted
to
support
some
sort
of
cluster
ID
and
until
they
were
confident
they
can
come
up
with
a
single
value,
with
a
single
string
with
a
single
format
they'd,
rather
each
a
particular
area
or
use
to
find
their
own.
As
of
right.
Now,
those.
A
B
It's
oh
I,
see
yeah,
so
one
of
the
problems
was
trying
to
stick
it
into
the
core.
Is
we
have
to
support
the
reported
resources
or
cruds
right
so
at
that
point,
we're
basically
creating
all
brand-new
resource
just
for
ourselves
anyway,
so
it
doesn't
take
a
whole
lot
of
sense
to
stick
it
into
the
core
when
it's
our
resource
under
our
control,
no
one
else
is
going
to
use
it,
but
us
I'm
not.
A
B
C
A
So,
like
I
said,
I
think
this
before
we
go,
adding
a
new
resource
to
the
API
server
I
think
it
would
be
good
to
write
this
idea
up
and
we
can
discuss
it
like.
We
have
other
things.
I
am
concerned
that
it's
potentially
a
lot
of
code
to
add
when
we
could.
We
can
also,
just
as
a
temporary
measure,
use
a
config
map.
B
B
I'm,
just
out
of
curiosity
I,
don't
care.
This
is
pushing
back
on
discussion.
I
definitely
wanna
have
a
discussion
to
make
sure
we
get
the
right
approach
and
I'm
not
saying
this
is
what
we
will
do.
I'm
just
telling
you
what
the
cigar
context
your
group
recommended
that
we
do.
I
am
curious,
though,
when
you
look
at
what
Morgan
recently
did
for
the
service
plan
split
and
stuff,
you
keep
describing
adding
another
resource
to
role
model
as
something
that
requires
a
lot
of
code
or
it's
complicated
in
some
way.
B
A
I
won
I,
don't
know
of
any
precedent
for
a
singleton
resource.
I,
don't
know
I'm,
not
sure.
I
can
immediately
think
of
all
the
the
implications
of
making
there
be
only
one
and
it's
it's
I'm
I
can
really
is
not
in
the
amount
of
code.
It's
the
implications
that
I'm
not
sure
that
we
can
think
of
and
I.
A
B
A
A
Ok,
it's
nice
to
have
some
kind
of
resolution,
or
at
least
path
forward
on
this
I
know
that
there
are
probably
people,
maybe
even
on
the
call
that
have
use
cases
that
are
starting
to
become
more
relevant,
where
a
single
broker
has
to
service
multiple
kubernetes
installations.
So
I
think
this
is
something
that
well
I'm,
not
sure
it's
necessarily
in
scope
for
beta,
because
we've
kind
of
been
in
a
holding
pattern
on
it
I
think
we're
all
probably
interested
in
it.
I
mean
I'm
personally
interested
in
seeing
resolution
well.
B
I
know
from
the
IBM
side.
We
definitely
have
a
very
strong
need
for
this,
because
our
environment
is
a
series
of
criminals
clusters
managed
by
or
serviced
by,
a
single
broker
and
sort
of
in
orga
a
control
plan
to
kind
of
sit
above
all
the
clusters,
that's
talking
to
with
the
deserves
broker,
and
we
definitely
need
to
know
which
career
next
cluster
things
came
from
and
that's
what
context
was
there
for
so
yeah,
not.
A
Interestingly,
if
I
remember
correctly,
the
guidance
the
Cloud
Foundry
gives
to
support
this
case
in
your
broker
is
to
ensure
that
you
use
a
different
URL
in
different
brokers
and
that
Cloud
Foundry
sends
like
the
referring
URL
or
something
in
the
request.
Header
and
the
broker
is
supposed
to
use
that
which
seems
a
little.
B
I'm
not
sure,
that's
quite
the
way
they
described
it.
The
way
I
interpreted
it
was
every
every
platform
should
have
a
unique
login,
basically
to
the
broker
right,
because
when
the
broker
registers
it
doesn't
just
give
a
URL,
it
gives
some
sort
of
authentication
mechanism
or
information
that
the
platform
will
use
when
he
talks
to
the
broker
and
it
that's
information,
whether
it's
a
separate
URL,
separate
user,
ID
and
password
or
whatever
that's
how
the
broker
can
distinguish
between
a
platform
and
that
and
I
agree
that
can
work.
A
B
So
I
remember
correctly,
I
think
Paul.
You
may
have
asked
me
to
talk
to
sick
architecture
about
whether
they
had
any
guidance
as
to
how
often
we
should
look
at
rebasing
our
code,
because
we're
dependent
on
the
API
machinery
and
stuff
and
I
think
this
was
around
the
same
time
that
we
were
going
through
quite
a
few
pains
because
the
API
machinery
was
going
through
lots
of
churning
and
granted
it's
not
as
big
an
issue
now,
because
I
think
they
stabilized
quite
a
bit,
but
the
feedback
that
I
got
from
mainly
Brian
grant
on.
B
A
And
I
believe
walther
vendor
has
said
that
part
of
his
time
allocation
is
to
help
us
with
rebase
--is.
So
that's
probably
relevant
information.
I
guess.
One
thing
that
I
am
I'm
wondering
to
myself
is
whether
anybody,
an
API
machinery
has
a
has
a
read
on
what
level
or
what
challenges
might
be
associated
with
running
a
1/8
machine.
The
aggregated
api
with
a
1:7,
aggregator
and
I,
see
now
that
Morgan
you've
got
your
hand
up,
go
ahead.
F
D
Actually,
yesterday
took
a
look
at
the
a
true
basing
not
unto
1.8
but
on
just
on
one
point:
seven
point:
six,
which
should
be
really
minor
release
like
by
looking
at
the
version,
but
actually
they
have
moved.
They
create
a
new
rapist
communities.
Api
give
me
this
cube,
open,
API
and
maybe
some
others.
So
a
lot
of
packages
are
broken.
Now
some
code
is
just
completely
removed
and
I
think
that
we
are
using
currently
global
API
scheme
for
registering
all
our
types
and
as
far
as
understood,
they
completely
remove
this
thing.
D
So
we
where
we
need
to
whether
to
switch
from
client,
go
global
scheme
to
communities,
global
scheme
or
actually
a
recommended
approach,
and
if
you
look
at
the
current
version
of
sample
it
s
over
is
to
actually
create
your
own
scheme,
your
own
registry
and
all
the
things
local
and
they
also
teaching
the
static
edit
functions,
which
register
your
schemer
scheme
in
the
global
API
scheme
and
all
such
things.
So,
basically
you
need
to
create
your
own
scheme
and
pass
it
everywhere.
D
Instead
of
just
reading
referencing
a
static
scheme,
so
yeah
I
I
didn't
expect
that,
but
even
in
one
point
seven
point
six,
there
are
pretty
major
changes
for
us,
I
mean
I,
guess
most
of
them
are
just
technical.
Basically
like
change.
They
a
package
or
write
with
APA
scheme,
basically
replacing
static
scheme
with
with
the
local
service
catalog
one
but
yeah.
C
D
You
can
take
out
a
lot
of
time,
I
think
that
it
is
still
viable
to
like
if
we
want
to
release
be
better
than
one
point.
Seven
point:
six
must
have
a
lot
of
like
I've
seen
some
security.
What
and
some
other
things
so
I
guess,
even
if
we
don't
want
to
jump
on
to
1.8,
we
should
probably
base
something.
The
latest
1.7
fix.
A
Okay,
good
good
contacts,
so
I
think
one
action
item
that
we
have
here.
Knowledge
to
your
hand,
is
a
one
action
item
that
we
have
is
we
need
to
assess
the
level
like
how
large
the
changes
are.
One
thing
that
we
were
I
think
still
trying
to
decide
or
had
punted
on
temporarily.
While
we
finish
other
design,
decisions
is
what,
whether
we're
going
to
use
the
the
one,
seven
money
or
some
other
version
of
the
API
machinery
and
the
initial
beta
release.
A
So
here's
an
action
item
I,
know
that
in-
and
this
is
mine-
my
own
action
item
I've
already
started
pinging
Walter
about
this
Walter
offender
has
told
me
that
he
has
time
at
least
he's
told
me
in
the
past
that
he
has
time
to
help
us
with
API
machinery.
Machinery
related
stuff
in
Service,
Catalog,
so
I
think
that
it
would
be
good
to
get
see
if
we
can
get
a
summary
from
him.
D
I
just
wanted
to
mention
that
at
one
point
an
8
is
already
frozen
now,
I
think,
and
there
is
already
a
branch.
So
if
we
we
really
want
to
do
Basin
to
1.8
make
sure
we
can
start
working
on
that,
but
yeah
I,
as
I
said,
I
started
doing
the
ribbon
to
1.76.
Just
thinking
that,
like
let's
do
the
like
small
step,
first,
just
to
clean
up
all
the
things
and
then
like
relation
to
major
changes
and
yeah,
it's
actually
I
think
this
is
a
good
idea.
D
A
F
No,
it's
just
to
kind
of
calm.
Carry
that
I'm
leaving
in
the
the
chat
there
is
that
you
know.
As
far
as
API
machinery
is
concerned,
they
have
no
guarantee
that
any,
but
anything
is
worth
workable.
Just
beyond
beyond
outside
of
cube
core.
So
you
know,
a
minor
release
for
cube
is
not
a
minor
release
for
them.
They
they,
don't
they
don't
care
everything's
broken
so.
F
Manipal,
you
know
we're
trying
to
use
this
because
the
argument
there
is
no,
we
don't
support
this.
This
is
not
a
supported
use
case.
So
if
we
don't,
if
they're
not
going
to
support
it
and
and
we
can't
push
them
to
support
it-
then
there's
nothing
beyond
rebase
when
everything
breaks
and
break
and
fix
it
that
that
we
have
so
I
just
I,
don't
feel
like
there's
a
I.
F
F
We
broke
the
major
version
for
one
point,
seven
point:
six,
but
that
library
does
not
have
the
1.7
foot
point
six
version
and
and
and
it
does
not
satisfy
the
sort
of
semver
agreement
of
you
go
from
point
five
point:
zero
two
point,
one
to
point:
two,
that
those
are
all
sort
of
compatible
and
that
they're
only
you
know
minor
bug,
fixes
they
change
major
stuff
all
the
time.
So
it's
not
a
there's.
There
is
no
semver
of
the
libraries
quote-unquote
there
because
we're
not
really
libraries
there
they're
still
in
the
core.
A
A
Yeah
and
Matt
has
commented
there
and
by
the
way
now,
I
see
that
your
hand
is
up
again
there's
a
long
term
plan
to
play
API
machinery
out
and
treat
it
as
an
SDK,
with
its
own
release
cycle
likely
in
2018.
So
I
think
people
understand
that
this
is
an
issue.
I
do
not
expect
the
like
major
changes
in
minor
releases
thing
to
get
better.
Before
that
happens,
you
are
for
me
now
go
ahead.
Yeah.
D
I
just
wanted
to
describe
how
how
do
I
clarify
which
dependencies
of
own
communities
libraries
I
should
set
so
basically
I
go
to
the
so
communities
main
repo
has
tags
for
each
release.
You
just
go
there
and
because
it's
mono
repo,
it
has
a
staging
folder
which
contains
all
the
other
rivers.
But
actually,
when
we
reference
put
the
document
dependencies,
we
put
the
defenses
on
the
mirrored
rapist,
so
you
have
to
go
to
into
staging
on
the
particular
tag
of
communities.
D
Map
mono
repo,
find
the
latest
commits
in
this
tag
and
then
go
to
the
other
repo,
which
is
a
matter
of
it
and
find
the
exact
same,
commit
basically
to
specify
it
and
actually
I
have
found.
The
yesterday
I
have
found
some
conflicts
that
API
server
uses.
Some
google
text
and
some
other
library
can
remember
google
net.
I
think
so.
D
Those
two
libraries
have
different
versions
in
api
server
and
in
communities
core.
So
when
you
do
the
glide
update
it.
Actually,
it's
like
prints
the
warning
that
there
is
a
conflict
between
two
versions.
You
basically
pick
one
of
them
so
yeah.
It's
not
it's
not
clear.
It's
a
bit
complicated,
yeah
I
mean
it's
doable
because,
like
basically,
you
just
depend
on
all
the
sources
and
like
as
long
as
the
API
is
between
these
sources
like
compatible.
It
just
works,
but
yeah.
A
D
F
I'm
just
trying
to
work
through
getting
this
sort
of
what
what
what's
the
merger
belen
state
here
and
I'm?
You
know
there's
right
now,
there's
three
different
plugins
in
there
there's
some
color
stuff,
which
I
don't
think
we
want
to
use.
You
know
raw
terminal
stuff,
so
I
you
know.
Maybe
we
need
to
pull
in
a
dependency
if
we
really
want
that.
F
F
F
A
B
A
My
hand
is
up
so
I
have
a
few
things
that
come
to
mind.
The
first
one
is
that
I
had
pain
to
Fabiana.
Franz
is
sick,
CLI
lead
to
review
the
plugins
I
wonder
if
he's
ever
like
gone
ahead
and
given
feedback
on
those
Morgan?
Do
you
do
you
know
whether
Morgan
or
Doug?
Do
you
know
whether
Fabiano's
take
a
look
at
them
yet.
A
F
A
The
other
one
is
that
I
I
need
to
circle
back
with
Fabiano
and
talk
to
him
about
this
in
terms
of
I.
Think
that
I
might
have
deliverables
that
have
been
at
a
band
that
I've
been
implicitly
responsible
for
that
I'm
now
concerned
that
I
may
be
dropping
the
ball
on
so
I
need
to
go
back
and
talk
to
some
folks
on
my
side
about
this
third
thing
is
I
would
prefer
so
I.
A
Don't
think
anybody
knows
how
to
package
cube
CTL
extensions,
yet
it's
probably
worth
thinking
about
what
we
think
the
best
way
to
package
them
is.
My
inclination
would
be
as
far
as
whether
we're
producing
one
or
many
binaries
to
produce
one
binary
that
does
the
classic
UNIX
binary
trick
of
it.
It
figures
out
what
name
you
called
it
and
then,
if
the
comes
that
thing
and
then
we
can
make
symlinks
into
that
in
the
plug-in
directory,
I
think
that's,
probably
logistically
simpler
and
likely
to
be
more
maintainable
over
time
would
be
my
gut
thing.
A
I,
don't
think
we
need
color
and
I
since
I.
Don't
think
anybody's
gone
out
and
said
it
I
wonder
if
anybody
has
like
a
strong
burning
desire
to
have
stuff
like
this,
for
the
initial
beta
its
we
didn't
talk
about
it
when
it's
been
in
when
we
talked
about
scope.
Is
this
something
that
like
people
want
to
ship
imminently
with
the
beta
release?
B
D
Yeah,
to
be
honest,
I'm
not
sure
if
they
like
the
cubes
it'll
plugging
in
in
its
current
form,
is
really
used.
Useful
I
mean
like
if
the
goal
I
guess
is
to
prove
the
UX,
but
like
in
communities
in
general
things
that
a
couple
from
each
other
ends
like
there
are
no
plugins
to
deploy
your
service
like
in
a
single
shot
with
like
service
deployment
and
ingress
created
all
together,
for
example,
or
anything
like
that.
So
I'm
not
sure.
Why
do
we
need
to
do
this
for
service
catalog?
That.
B
So,
from
from
my
perspective,
it's
it's
just
an
attempt
to
try
to
make
the
user
experience
a
little
bit
nicer
in
all
honesty,
I'm,
not
her
percent
convinced,
given
the
complexity
of
kubernetes
that
we're
going
to
be
able
to
actually
produce
these
in
a
fashion.
That's
that's
usable,
for
example,
I
think
registering
a
broker
might
be
able
to
be
done
very
easily
because
there
is
a
whole
lot
of
information
there
right
this
URL,
possibly
user,
ID
password
that
kind
of
stuff.
You
don't
have
to
necessarily
an
entire
yamo
file
for
this.
B
That
kind
of
information
creating
a
service
instance
that
might
be
useful
right
because
there's
not
a
whole
lot
of
information
there.
It's
the
service
name
and
the
service
plan,
and
then
you
have
to
give
it
a
name
of
what
you
want
to
call
this
thing
that
might
be
useful
to
people
the
binding
stuff.
We
haven't
figured
out
how
we're
gonna
do
ourselves
in
Yamla,
yet.
D
A
D
I
just
wanted
to
say
that,
like
this
experience
is
very
different
from
the
a
few
minutes
experience
and
it
could
be
actually
confusing
against
for
some
people
and
because,
like
we,
don't
provide
a
like
an
extra
abstraction
layer,
hiding
all
the
details
details
we
actually
like
do
the
patch
on
some
of
the
objects.
I
guess,
like
all
the
communities
complexity,
will
still
leak
to
the
user,
anyways.
So
I'm
not
sure
we
actually
fixing
any
problem
with
this
thing.
So
it's
it's.
D
A
A
My
hand
is
up
next.
I
have
not
looked
at
the
commands
recently
and
one
of
the
one
of
my
hopes
from
having
Fabiana
review
them
is
to
give
blessing
from
a
CLI
standpoint
that
the
things
that
were
being
done
were
in
line
with
kubernetes
conventions.
I
think
that
it
might
be
helpful
if
we
can
talk
about
these
commands
on
a
one
by
one
basis
and
probably
see
if,
like
some
like
broker
realists,
I
agree
with
you
Doug.
It's
probably
pretty
basic
and
probably
there's
just
about
one
way
to
skin
the
cat.
A
I
am
NOT
certain
for
other
things
that
it's
as
crystal
clear.
What
to
do
and
I
also
think
that
we
should
devote
some
thought
to
what
level
of
guarantee,
when
we
eventually,
since
I,
expect
that
we
will
eventually
make
a
cube,
CTL
extension
to
publish
porcelain
what
level
of
alpha-beta
GA
are
we
going
to
consider
I
I
think
it's
very
important
to
consider
CLI
surface
as
just
another
form
of
API.
B
So,
honestly,
I
I,
don't
think
it
matters
what
it's
called.
If
we
want
to
call
it
alpha,
even
though
everything
else
is
beta,
I
I,
don't
honestly
think
anybody
cares
and,
like
I
said,
my
biggest
concern
at
this
point
is
just
to
get
something
out
in
front
of
people
to
play
with
and
if
we
end
up
killing
it
the
week
later,
because
it's
that
horrible
I
don't
care,
you
know
it
was
alpha
I.
B
Don't
that's
fine,
but
I
do
think
because
we've
talked
about
this
in
the
past
and
the
work
has
gone
into
actually
developing
it
and
the
control
guys
did
all
this
work
I
grant
that
they
were
doing
it
for
the
reasons,
but
we
helped
push
them
along
I
think
it's
worthy
of
us
at
least
doing
the
experiment
and
if
it
never
leaves
alpha,
that's
fine
but
I.
Think
I.
Do
that
least
want
to
see
it
reach
some
kind
of
conclusion
to
actually
test
it.
Since
we've
gone
through
all
this
effort.
B
Because
the
honestly,
if
we
find
that
it's
not
useful
for
other
people,
I
mean
for
our
own
purposes,
I
think
that's
really
good
feedback
to
the
crew
control
guys
because
then
the
it
may
lessen
the
importance
of
them
doing
an
extension
mechanism
at
all,
but
I
think
I
think
it
could
be
useful
for
a
lot
of
purposes.
To
be
honest:
okay,.
A
A
A
That's
something
people
have
asked
me
for
personally
a
lot
in
the
community
and
Red
Hat,
so
I
think
it's
definitely
worth
thinking
about,
and
we
previously
had
a
consensus
that
we
were
going
to
do
a
realist
come
in
so
why
don't
Doug
or
do
you
want
to
put
something
on
the
agenda
for
a
Monday
and
we
can
do
like
a
detailed
look
or
maybe
not
super
detailed
but
like
let's
talk
about
which
commands
there
are,
and
we
can
think
before
then
about
how
do
we
release
it?
I'm
not
sure
I.
D
A
F
What
was
specifically
I
understand
that
that's
the
minor
release,
but
why
do
I
go
to
that
versus
the
the
1.81
and
it's?
What
do
you
think
I
mean
I
guess
maybe
we
just
need
to
follow
up
on
the
thing
next
next
meeting,
but
doing
that
versus
the
other
thing
in
terms
of
the
amount
of
work
is
11.6.
I
guess
is
probably
closer
to
1.8
and
whatever
we're
on
is
closer
to
1.7
point
six,
so
I
yeah
well
I.
D
D
D
F
D
I,
just
remember
that
in
one
point
a
there
were
a
lot
of
changes
about
code
generation
and
some
clients
client
go
things
I
believe
so
it
could
be
actually
really
really
pretty
painful.
So
I'm
not
sure
if
you,
if
we
are
ready
to
rebase
onto
one
for
a
straightaway,
so
I
would
still
prefer
to
finish
the
Y
1.70
yeah.