►
From YouTube: Kubernetes SIG Service Catalog 2018-05-14
Description
UPS broker
GA list
Charter
https://gist.github.com/MHBauer/d2a0bfb931574a57a1e943ba661813b4
A
A
A
A
Okay,
well
I'm,
just
gonna
get
right
into
it,
then
so
the
first
topic
is
actually
something
I
wrote
down,
so
usually
provided
services
are
a
thing
that
I
was
familiar
with,
because
I
used
to
work
on
Cloud
Foundry
and
the
other
thing
that
exists.
There's
not
necessarily
something
that's
in
part
of
the
OSB
spec
and
I
was
sort
of
aware
that
there
was
this
thing
over
here.
A
We
had
this
UPS
broker,
but
I
wasn't
really
aware
of
like
what
it
was
intended
to
be
used
for
how
nice
and
robust
it
was
so
I
was
taking
a
look
at
it
and
it
seems
to
me
that
it's
pretty
much
just
a
toy
like
it's
nice,
if
you
have
like
some
pre-existing
database
and
you
want
to
test
out
service
kind
of
like
see
how
it
works.
But
it's
not
really
I,
wouldn't
recommend
anyone
to
actually
use
this
to
actually
provision
a
user
provide
a
service.
A
Literally
everything,
because
the
thing
that
exists
right
now
is
little
thing
that
lives
entirely
in
memory
and
keeps
track
of
your
stuff
that
you
put
it
in
in
memory.
It
has
no
subsistence,
it
has
no
security
as
no
reliability.
It's
not
highly
available.
It's
not
scalable,
like
literally
nothing
about
it,
is
not
a
toy
and.
A
E
C
A
A
A
A
A
Jeremy
just
give
me
just
a
second
one
would
be
to
take
the
current
model
where
we
have
this
UPS
broker,
that's
the
sort
of
add-on
and
make
that
not
suck
so
make
that,
like
an
actual
full-fledged
component,
robust
reliable,
probably
got
to
stick
for
the
data
and
probably
the
fcd
somewhere,
so
it
doesn't
just
vanish
when
the
thing
goes
down.
A
second
option,
I
thought
of
was
merely.
A
Sort
of
adding
new
validations
that
allow
service
instances
to
be
created
without
an
attached
plan
or
class
which
would
allow
you
to
manually,
create
service
instances
and
mark
them,
as
usually
provided
in
some
way,
and
the
third
option
was
to
create
an
entire
new
object.
Type
user
provided
service
instance,
which
is
no
relation
to
the
current
service
instance.
Type
Jeremy,.
G
Yeah
so
I
think
we're
interested
in
two
types
of
things
here.
One
would
probably
be
like
just
that
user
provided
service,
I
I
think
that
maybe
creating
that's
something.
That's
just
in
a
resource
type.
A
full-fledged
broker
would
probably
be
sufficient
for
that.
On
the
con
related
note,
we're
also
interested
in
providing
like
a
registration
feature
where
we
can
take
a
managed
instance,
but
we
also
want
to
like
unbind
to
be
able
to
create
new
and
like
users
for
that
database.
G
So
I
started
working
on
a
broker
and
I
haven't
had
time
to
work
on
it.
A
little
bit,
there's
like
an
empty
repo
in
the
OSB
kit,
called
BYOB
they're
supposed
to
bring
your
own
broker
where
you
could
bring
like
a
Postgres
or
some
other
database.
It's
provisioned
like
in
the
cloud
and
you
like
register
the
credentials
like
you
would
for
a
UPS,
but
then
go
that
one
extra
step
like
actually
going
and
creating
users
inside
of
it.
So
it's
like
so
you
cast
plus
plus.
G
We
have
a
bunch
of
cases
where
people
like
are
migrating
and
they
want
to.
They
have
a
database
already
like
they're,
either
coming
from
Cloud
Foundry
and
they've
used
our
old
broker,
and
they
want
to
use
our
new
broker
and
they
like
want
to
register
that
thing
inside
of
it
and
continue
using
it
as
a
like
a
full-fledged
resource,
where
it's
not
just
a.
G
It's
functional
for
me
like
the
biop
thing,
but
I
haven't
pushed
it
yet
because
a
lot
of
other
things,
but
that's
the
capability
that
we
were
really
looking
for,
because
we
we
sit
as
like
a
migration
path
for
people
that
are
using
either
as
your
services
already
and
we'll
use
them
with
broker
or
are
migrating
from
Leica
from
our
old
broker.
It's.
C
G
Like
I
think
making
them
run
some
ex
unless
Service
Catalog
is
gonna,
run
it
and
install
it
as
part
of
like
the
Service
Catalog
control,
plane,
I
feel,
like
that's
an
extra
step.
It
seems
like
a
little
bit
of
overkill
for
something
that,
like
we're
just
gonna,
create
a
resource
that
does
nothing
really
other
than
exists.
Allow
you
to
use
via
Service
Catalog
right.
C
Okay,
yeah
now
that
wasn't
in
my
point
was
I
know
when
we
first
started
this
whole
work
effort.
There
was
a
desire
on
some
people,
decide
to
make
user
provided
services
act
and
look
like
just
like
any
other
broker,
which
is
why
we
created
this
UPS
broker
and
there's
nothing
about
sort
of
echoes
things
back
and
stuff.
C
You
know,
as
someone
pointed
out,
camera
who
I
think
was
J,
he
said
it
doesn't
support
asynchronous
operations,
and
should
it
does
it
need
to
all
these
various
things
come
into
play
and
I
think
it'd
be
a
whole
lot
easier
if
we
just
treated
service
instances
of
ups
type
and
it's
just
something
special
they're
not
associated
with
a
broker,
so
we
just
skip
the
calls
to
it.
We
know
we're
gonna
do
just
copy
the
credentials
which
are
the
parameters
into
a
secret
to
be
done
with
it.
It
makes
life
a
whole
lot
easier.
C
I
So
I
am
not
necessarily
against
the
idea
of
making
a
something.
That's
like
part
of
the
API
for
Service
Catalog,
that
is,
a
user
provided
service.
I,
think
that
if
we
want
to
go
down
that
route,
that
we
should
talk
about
like
how
we're
going
to
implement
that
I
do
think
that
also
taking
on
the
responsibility
of
saying
that,
like
we're
going
to
have
this
UPS
worker
thing
and
it's
going
to
be
more,
it's
more
than
a
toy
and
operate
able
and
production
is
a
very
large
task.
I
That
I'd
be
hesitant
to
expand
to
be
something
that
this
SIG
necessarily
took
on.
If
we
wanted
to
do
that,
it
might
be
a
good
idea
to
separate
like
that
broker
into
its
own
source
project,
and
if
we
want
to
do
that,
I
recently
figured
out
what
exactly
the
rules
are
for
donating
existing
code.
So
there
shouldn't
be
a
problem
there.
I
I
Yeah
I'm
dubious
about
like
having
a
single
special
case,
but
there
there's
probably
a
way
that
we
could
do
it
without
having
weird
like
switch
statements
in
a
lot
of
different
places.
It's
worth
thinking
about
what
the
right
way
to
do
it
is
I
mean
that's
that's
what
Cloud
Foundry
does
for
user
provided
services
for
Cloud,
Foundry
they're,
basically
like
a
special
case,
they
don't
go
through
the
broker
API.
I
B
A
A
F
C
C
G
I
Your
peace,
so
one
of
the
thing
that
I
think
we
ought
to
do
since
we're.
We
clearly
have
different
ideas
for
what
feature
we're
talking
about
is:
would
somebody
raise
their
hand
to
like
collect
all
the
use
cases
for
this,
so
that
we
can
be
super
clear
about
which
ones
are
which,
like
I've,
heard
of
at
least
two
people
calling,
or
it
heard
of
at
least
two
different
meanings
ascribed
to
user
provided
services
in
the
last
30
seconds?
D
I
C
D
D
G
H
B
D
I
B
H
B
B
B
C
Sorry
go
ahead,
I
was
gonna
say
for
my
point.
Do
I
think
the
list
looks
good
to
me
other
than
I
I.
Think
I
agree
with
pulling
up
the
guys
who
know
things
you
guys
mentioned.
I
would
like
to
add
UPS
brokers,
the
list,
with
the
caveat
that
if
we
could
solve
it
without
a
hue,
complication
and
I
think
Jonathan's
on
the
right
path
there,
but
I'd
like
to
get
that
in
there
before
1.0,
because
I
do
think
that's
kind
of
important
use
case,
at
least
for
us
I.
I
Yeah
I
actually
had
put
it
in
I'm.
Sorry
I
did
something
dumb
I.
When
I
read
this
list,
I
read
1.10
as
ODOT
I.
Don't
know
why,
except
that
I'm,
jet-lagged
and
I
was
quite
tired
when
I
was
looking
at
this,
so
I
added
that
into
one
dot
one
dot
Oh
mistakenly,
so
we
can
strike
it
from
that.
I
would
like
to
see
namespace
co-workers
before
1.0,
but
yes,
I
think
that
they
should
be
a
requirement
for
one
dot,
oh
and
so
should
be
present
in
this
list.
F
F
I
Another
part
of
my
professional
life,
like
I,
had
a
communication
forwarded
to
me
with
Stephan
Schwinn
ski
that
seemed
to
indicate
to
me
that
arbitrary
sub
resources
might
be
possible
with
CR
DS
I
will
send
that,
along
to
you,
Scott,
okay,
that
sounds
good
since
I
think
that's
what
you're
talking
about
the
plan
reference
sub
resource
right!
That's
right!
Okay,
yeah,
I'll,
I'll,
share
that
information
with
you.
D
I
Think
I
had
a
couple
of
other
points.
I
wanted
to
make
just
really
quick
I
do
think
that
CR
de,
like
weather,
we're
gonna
use
it
or
not,
is
like
correct
to
have
figured
out
and
implement
it
by
one
dot
o,
like
that's
a
that's
a
good
thing
to
be
part
of
that
milestone,
and
then
there
was
one
other
thing
that
I
wanted
to
talk
through
these
Ivy,
like
things
that
we
have
in
this
list
that
are
called,
are
back
Morgan.
Would
you
mind
scrolling
down
up
just
a
little
bit?
I
D
B
D
I
Feel
like
it
so
I
think
it
should
be
required
from
a
UX
standpoint,
because
I've
had
a
lot
of
feedback
that
people
think
it's
really
terrible.
The
way
that
it
works
now,
with
IDs
of
the
class
names
I,
don't
think
it
would
be
a
huge
amount
of
work,
probably
less
work
than
other
things
in
this
list,
but
I'd
be
willing
to
talk
about
it
offline.
If
you
wanted
what.
F
I
I
C
Paul
I'm
just
wondering
if,
if
SV
cat
was
a,
was
a
coop
control,
plug-in
that
didn't
that
wasn't
presented
in
such
an
awkward
way.
You
know
with
the
extra
words
in
the
command
line
so
that
people
felt
natural
to
or
it
felt
more
natural
to
actually
use
it
to
get
back
data
and
not
use
the
generic
who
control
get.
For
example,
they
just
use
coop,
coop
control
service
instance
get
or
something
like
that.
Do
you
think
people's
concern
about
IDs,
showing
up
would
still
be
an
issue.
I
A
F
F
A
A
C
D
F
I
I
A
F
B
A
I
F
I
can
do
it
with
like
I'll,
give
the
TLDR
and
then
Paul
can
correct
me
if
I
have
it
wrong,
but
the
core
OS
operator
SDK,
is
a
ways
that
you
can
do:
lifecycle
management
of
in
cluster
resources
in
the
way
that
we
might
launch
a
broker
in
a
kubernetes
cluster
and
then
ask
that
broker
to
inject
things
back
into
the
cluster
into
that
namespace.
So
it's
for
in
cluster
resources
like
a
CD
and
the
sed
operator
or
memcache
this
it's
a
resource,
that's
running
in
your
cluster,
not
an
external
resource.
G
Yeah
so
I
think
when
I
read
through
through
the
a
guy
I'd
use
that
CD
operator
a
little
bit
before,
but
when
I
read
through
the
like,
the
blog
posts
and
I
went
to
something
at
Kubek
on
and
heard
about
them.
I
feel
like
the
differentiation
is
like
the
operator.
Stuff
is
more
focused
on
the
things
you're
gonna
do
on
cluster
and
to
me,
service
cattle
are
more
brokers,
are
really
about
things.
You're,
probably
not
gonna
do
on
cluster
they're
gonna
be
somewhere
else
outside
of
the
cluster
I.
D
I
I
think
that
Scott
and
Jeremy,
like
you,
guys,
articulated
what
I
think
the
intent
of
like
operators
is
in
general
that,
like
just
just
to
be
really
specific,
when
we
talk
about
what
an
operator
is,
it's
basically
like
a
there's
two
parts
of
it.
There's
a
CRD
that
models
the
like
piece
of
software,
that
you
want
the
operator
to
manage
and
then
there's
a
controller
that
is
watching
that
CRT
and
doing
the
things
that
users
Express
with
that
and,
as
an
example,
I
think.
I
The
first
use
of
this
concept
was
that
poor
OS,
maybe
I,
seem
to
think
this
was
about
a
year
and
a
half
ago
was
building
a
an
operator
for
EDD
that
you
can
say
in
my
name.
Space
I
want
there
to
be
a
net
CV
instance
and
the
operator
handles
the
the
work
of
like
watching
that
CRT.
That
indicates
that,
for
that
specific
piece
of
software
I
have
men
putting
@cd
into
their
namespace
and
handling.
Things
like
like.
I
I
But
with
that
said,
that's
my
opinion,
as
some
dude
like
Red
Hat,
has
obviously
delivered
too
well
known
and
shipped
with
openshift
brokers
that
deliver
things
into
your
namespace.
So
there's
probably
like
a
gray
area
in
terms
of
as
the
operator
concept
that
comes
more
well-known,
whether
people
view
things
the
same
way
or
not.
But
that's
just
my
own
personal
opinion.
I
F
F
I
I'm
I'm
very
hesitant
to
expand
the
scope
of
Service
Catalog
beyond
open
service
broker,
API
I
kind
of
wish
that
we
had
chosen
a
more
specific
name
for
it,
in
fact,
because
there
are
like
two
or
three
other
things
that
people
have
are
calling
service
catalogs
that
I've
seen
in
the
ecosystem
recently,
but
either
way
you
slice.
It
say
that
we're
amenable
to
like
expanding
the
scope,
say
that
someone
else
builds
something
that
they
don't
want
to
like
conflate
or
have
an
integration
with
service
catalog,
like
that's,
probably
also
inevitable,
given
enough
time.
I
F
C
So
I
think,
if,
if
you
were
specifically
standing
in
front
of
people,
saying
I
represent
this
group
and
I'm
speaking
for
them,
then
I
would
agree
that
it
would
be
nice
if
we
can
get
some
sort
of
check
and
it
has
to
be
perform.
Oh
just
let
us
take
a
look
at
it
in
advance,
but
I
think
those
times
are
pretty
rare,
I
think.
In
most
cases
people
should
not
be
presenting
themselves
as
representing
the
group
they're
representing
themselves.
C
As
a
member
of
the
group
I'd,
the
only
case
I
could
think
of
recently
where
someone
was
representing.
The
group
itself
was
when
I
gave
sig
updates.
You
know
the
five
minute
blur
but
I
goofed
on
just
to
let
people
know
what
we're
working
on
and
then
even
then.
It
may
be
very
clear
when
you're
talking
for
the
group
versus
giving
your
own
opinion
and
I've
got
you
something
giving
your
opinion,
if
you
feel
free
to
say
whatever
you
want,
but
just
need
to
make
it
very
clear
where
that
line
is
between
the
two.
I
F
Just
just
thinking
just
thinking
now,
I,
you
know
it's
a
couple
things
and
like
the
there's,
an
article
I
think
some
news
surfaced
around
you
know:
Microsoft
releases
service
broker
and,
and
then
Google
wrote
the
service
broke
or
Service
Catalog
things
like
that
right,
like
how
how
these
things
get
mentioned
might
matter
to
us.
Yeah.
I
Unfortunately,
like
there
is
little
that
we
could
do
from
preventing
someone
that
didn't
understand
the
situation
from
writing
an
article
or
blog
posts
that,
like
conveyed
their
mistaken
understanding,
I
guess,
like
that,
seems
slightly
different
than
whether
somebody
is
giving
a
talk
and
saying
I'm
here
representing
the
sig
I.
Think
we
can.
We
can
do
something
about
that
and
that's
actually
a
good
segue
into
what
I
would
like
to
talk
about
next,
which
is
a
group
charter,
but
we
we
can.
A
A
Well,
that
stuff
may
have
sounded
great
for
sure.
My
understanding
is
that
those
were
rather
fly-by-night.
They
were
my
understanding.
The
process
was,
they
said
they
wanted
to
have
deep
dives
for
the
individual
SIG's,
but
they
didn't
reach
out
to
us.
It
was
up
to
us
to
reach
out
to
them,
be
like
hey.
We
want
to
do
once
the
SIG's,
Service,
Catalog
and
I
believe
it
was
Morgan
and
Kitty
who
took
them
up
on
that,
speaking
of
which
kitty
Europe
yeah.
H
As
somebody
that
gave
one
of
them
without
having
like
shared
the
slides
and
such
I
I
do
think
going
forward,
it
would
definitely
be
beneficial,
so
I
apologize
for
that.
I
definitely
should
have
reached
out
more
to
you
guys
I
kind
of
free
winged
it
towards
the
end
there,
so
yeah
I
think
for
the
next
cute
con.
It
would
be
certainly
great
if
we
had
just
a
sort
of
process.
Maybe
you,
let's
just
say
you
know
two
weeks
in
advance
or
something
have
a
presentation
to
the
group.
H
A
B
D
This
tag,
this
concept,
this
concept
I,
never
say
that
I'm,
not
speaking
for
the
group,
but
also
I,
never
say
things
like
you
know:
here's
where
the
group
is,
or
the
group
thinks
this
or
whatever
so
going
forward.
I
probably
will
start
saying
that
that
I'm,
not
speaking
for
the
group
I'm
speaking
for
tech,
only
that
might
be
another
good
thing
we
should
put
in
the
Charter,
but
I
would
really
hate
to
have
to
go
through
the
group
to
get
sign
off
on
any
presentation
related
to
Service
Catalog.
D
I
Do
you
need
permission,
it's
about
whether,
like
it's
about
giving
the
people
in
the
group
to
like
be
crowd-sourced
for
fact-checking
and
stuff
like
that,
because
it's
easy
for
those
things
to
maybe
have
like
a
verbage.
That
sounds
weird
for
somebody
or
that
like,
if
you
are
just
a
human
being,
and
you
make
a
mistake
like
someone
else
might
catch
it.
Is
that
specifically,
what
you're
really
thinking
about
yeah.
A
I
Have
the
discussion
now
about
like
what
a
Charter
is,
and
maybe
we
can
examine
that
question.
So
the
the
Charter
document
is
something
that,
like
is
a
concept
that
the
steering
committee
decided
on
for
that
that
there
should
be
like
a
single
place
where
the
roles,
rules
and
responsibilities
of
like
the
things
that
make
up
a
cig
are
written
down
for
each
group.
I
There's
a
template,
one
that
we
can
use
as
a
starting
point,
but
we,
the
idea,
is
that
every
sink
will
do
this
so
that
there
is
a
real,
up-to-date
accounting
of
what
the
rules,
roles
and
responsibilities
and
processes
are
for
each
group.
So
this
seems
like
a
good
candidate
for
something
that
we
could
have
some
verbage
around
in
the
Charter.
That
said,
I
think
Jonathan,
you
put
it
really
well
I'm
gonna
try
to
paraphrase
the
wording
that
you
use
and
I
think
you
basically
said
something
close
to.