►
From YouTube: Kubernetes SIG Service Catalog 20170612
Description
The SIG discusses criteria for:
1. Taking the catalog to beta (0.1.0 release)
2. Determining when an OSB feature is ready to release
A
B
A
Right
well
welcome,
Chris
mark
and,
let's
see,
got
a
few
things
on
the
agenda
today.
So
first
up
is
that
I
actually
realized.
Now
that
I'm
saying
pronouncing
the
sentence
that
I
don't
think
I
actually
emailed
the
cig
list
about
that,
which
is
my
bad
sorry,
everybody,
please
accept
my
apologies.
We
did
not
do
a
weekly
release
last
week,
so
the
ODA
10
release
will
be
on
this
Wednesday
and
the.
A
Hawk
atop,
my
head
I,
believe
the
largest
thing
in
that
release
will
be
a
support.
Preliminary
support
for
pod
presets,
so
you're
not
going
to
be
able
to
embed
a
full
pod,
preset
spec
in
a
binding,
but
you
will
be
able
to
specify
a
label
selector
for
it
and
the
name
that
the
pod
preset
should
have
and
the
if
you
specify
these
things,
the
the
catalog
controller
will
generate
a
pod
preset.
That
applies
is
applied
to
the
label,
selector
that
you
specified
and
it
will
consume.
A
A
A
A
Into
the
open
service
broker
API,
but
not
yet
released
whether
we
think
that
the
incubator
repo
is
fully
compatible
with
it
and
whether
we
think
it
can
be
released
in
the
spec
now
for
context.
No
pun
intended,
as
you
will
see,
there
is
a
there-
is
a
pull
request
which
has
been
merged.
To
my
surprise,
that
adds
a
new
context
field
to
the
provision
request
that
odd
lets.
A
So
I
suspect
that
probably
we
have
different
opinions
on
what
the
decision
plane
should
be.
But
here
is
my
own
idea
of
what
the
decision
plan
ought
to
be,
which
is
that
one,
the
catalog
incubator,
repo
I,
supports
this
feature
and
have
it
implemented
and
that
we
feel
comfortable
that
there's
nothing
about
the
feature
in
the
catalog.
That
would
cause
us
backward
compatibility
issues
in
the
future
so
like
for
any
particular
feature
that
is
proposed
to
open
service
broker.
A
Api
I
think
that
we
should
feel
comfortable
that
we
can
support
it
and
that
we
won't
have
to
make
a
backward
incompatible.
Api
change
so
support
it
in
the
future,
and
then
this
is
where
it
gets
a
little
bit
more
subjective.
But
I
would
also
like
for
us
to
have
some
idea
of
whether
brokers
that
intend
to
integrate
with
the
kubernetes
service
catalog
have
implemented
and
implemented
a
particular
feature
and
also
feel
comfortable
with
it.
In
the
same
way.
A
C
I
think
you
need
to
separate
out
sort
of
3:7
your
agenda,
meaning
for
release
versus
whether
we
think
of
features
is
good
enough
for
the
spec
itself
to
go
forward
because
for
release
kind
of
implied
to
me
when
I
first
read
it.
You
know
GA
level
on
our
stuff
I'd
like
to
keep
our
stuff
sort
of
in
sync,
with
the
spec
itself,
but
in
general
I.
Think
of
the
way
you
described
it
is
fine.
I
think
a
lot
of
it
does
is
very
subjective.
You
know,
do
we
feel
comfortable
going
forward?
C
A
D
So
yeah
I
agree
with
with
what
you
and
Doug
both
actually
born.
First,
a
real
current
would
OSB
spec
there's
a
but
though,
of
course,
we've
done
a
ton
of
testing
service
catalog
against
existing
brokers
and,
to
some
extent,
almost
all
the
existing
brokers
that
we've
tested
with,
including
our
own
Azure
broker.
They
fail
to
live
up
to
some
part
of
the
spec,
so
they
all
generally
work.
Well
enough.
D
E
Can
I,
yes,
so
I
think
it's
fine
for
brokers
that
conform
to
the
old
OSB
spec
like
to
actually
conform
to
an
existing
OSP
spec
that
we
pay
attention
to
backwards
compatibility.
However,
there's
a
lot
of
weird
things
that
existing
brokers
do
and
have
done,
and
I
have
no
interest
in
getting
into
a
windows
compatibility.
Nightmare
of
you
know
anything
ever
written,
but
does
something
crazy
that
we
have
to
make
sure
that
those
are
supported
going
for
word,
because.
D
Martin,
what
I
would
like
it's
just
for
for
brokers
that
are
popular
will
have
to
decide
what
that
really
means
later,
but
for
Rovers
are
popular.
You
can
do
the
basic
stuff
you
might
not
be
able
to.
You
know
provision
super
specific
cloud
sequel
instance
with
these
parameters,
but
you
should
provision
stuff
and
D
provisions
some
stuff
and
buying
it
online.
I.
Think
for
us
to
be
successful.
We're
gonna
need
to
do
that
with
a
bunch
of
brokers
or
out
of
the
box,
but
Martin
your
point.
D
Have
some
discussion
I
think
next
week
about
like
what
are
we
going
to
do
about
those
kind
of
brokers
and
how
we
going
to
go
about
making
brokers
writable
so
I'm,
getting
a
little
bit
out
of
scope
there
in
the
broker
land,
but
in
terms
of
compatibility
I'm
with
you
there
and
I
would
like
us
to
make
an
effort,
but
go
case-by-case
I'm,
saying
we're
not
going
to
support
that
broker.
Well,.
E
E
Let's
get
you
know,
you
know,
validation
for
brokers
like
are
you
or
are
you
conformance
to
the
AP,
is
and
obviously
we'll
start
with
the
existing
subcontractors
broker,
API
and
homeless
test
for
those
whatever?
If
you
not
conformant
and
I
would
be
very
much
against
doing
anything
to
try
to
make
those
run,
and
if
those
those
are
interesting
brokers,
they
should
fix
them.
Okay,
so
I.
A
Agree
with
Martin,
but
I
want
to
I
want
to
tease
apart,
like
the
four
or
five
different
facets
that
are
slightly
different
to
this
discussion.
The
first
one
is,
we
talked
about
like
Martin
brought
up
backward
compatibility,
so
there's
two
different
there's
two
different
facets
of
backward
compatibility.
One
is
that
the
the
eight
piece
of
Service
Catalog,
the
kubernetes
Service
Catalog
API,
needs
to
be
a
backward
compatible
like,
as
we
add
API
surface
for
new
features
in
the
catalog
or
corresponding
to
new
features
in
the
open,
serviceworker
API
is
back.
A
We
need
to
do
those
in
a
way
that
is
backward
compatible
and
in
this
context,
web
backward
compatible
means
is
that
if
I
have
a
client
for
version,
10
of
the
Service
Catalog
API
and
I
use
that
client
to
create
requests
X
against
a
version
n
that
I
should
get
the
same
result
when
I
do
that,
against
version
n,
plus
one
and
I,
don't
I,
don't
change
my
client
at
all
and
I.
Don't
change
anything
else
about
the
request
and
I
get
the
same.
A
If
a
broker
is
on
support,
subversion,
N
and
there's
a
new
version
of
the
API
released
n
plus
one
that
that
broker
should
still
be
able
to
work
with
version
10
and
version.
End
client
gets
the
same
behavior
whether
the
broker
knows
how
to
support
version
n
or
version
n
plus
one.
Now
there
are
like
and
I
think
so,
one
of
my
personal
things
that
I
would
like
to
change
about
hope
and
service
broker
API.
That
I
think
that
we
will
have
to
do
when
we
want
to
eventually
make
a
backward
incompatible
change
with
that.
A
A
A
My
personal
opinion
and
opinion
as
like
the
champion
role
of
the
incubator
repo,
is
that
we
should
not
have
any
special
casing
for
any
broker
ever
period.
Full
stop.
If
your
broker
does
not
implement
the
spec
correctly,
you
did
it
wrong
change
your
broker
and
I
think
it's
more
dangerous
than
a
slippery
slope.
To
me,
it's
more
like,
like
a
pit
of
lava
in
Super
Mario.
As
soon
as
you
start
special
casing
brokers,
you
are
just
doomed.
A
C
So
I
just
want
to
say
that
I
actually
think
we're
all
generally
in
agreement.
I
think
the
way
you
were
sort
of
stay
in
a
hard-line
there
and
I
think
Morgan
was
saying
the
hard
line
there
I
think
is.
Is
our
starting
position
I
think
if
I'm
not
the
sort
of
forwards
and
see
what
Aaron
was
trying
to
say,
there
is
just
if
something
comes
up
where
some
one
thing
is:
SPECT
compliance
but
they're
still
acting
a
little
odd.
It's
good
we're
going
to
take
on
a
case-by-case
basis
and
chances.
C
Are
it's
not
going
to
really
be
a
decision
for
us
to
make
in
this
group
it's
more
of
a
decision
for
the
spec
authors
to
decide
what
they
want
to
do
about
that
special
program
because
we're
going
to
be
at
least
going
to
try
to
be
100%
complied
with
the
spec.
So
if
there's
a
broker
out
there
that
isn't
spec
compliant
the
issue
isn't
with
us
issues
with
the
spec
and
they
need
to
get
resolved
over
networking
group,
not
ours.
C
C
I
wanted
to
jump
in
there
and
say,
from
my
point
of
view,
I
actually
do
think
it
is
ready,
with
the
caveat
that
we're
going
to
probably
need
to
add
more
to
it,
in
particular
the
cluster
ID,
not
just
the
namespace
as
its
know,
it's
in
there
today,
but
that's
an
additive
thing
going
forward,
but
as
of
the
current
version,
which
in
spec
in
terms
is
just
the
context
based
on
there,
I
think
that's
ready
to
go.
Yes,
I.
A
Know,
I
don't
disagree,
but
before
we
talk
about
contracting
by
the
way
that
was
me
there
was
that
in
there
excuse
me
before
we
talk
about
context,
I'm
curious
to
know
whether
we
is
like
in
a
vacuum
forget
about
specifics
of
features.
Do
we
feel
that
we
have
all
been
landing
on?
Basically,
the
same
page
I
think
we
have
but
I
think
there's
another
dimension
that
we
actually
haven't
talked
through
yet,
which
is
our?
A
Do
we
want
to
have
some
kind
of
criteria
that
we
need
to
be
able
to
certify
certain
Rover's
is
as
working
correctly
and
I
will
say
just
for
the
record.
That
is
not
a
realistic
criteria
to
have
for
this
particular
one
I
think
it's
something
that
we
would
want
to
converge
on
in
the
future,
but
we
have
no
such
thing
right
now
and
we
are
not.
A
D
So
I
would
love
to
not
have
a
special
case.
I
will
do
as
the
most
as
I
can
as
a
cure
to
this
repository
and
other
brokers
to
not
have
a
special
case,
but
I
can
say
that
we
have
tested
service
catalog
with
quite
a
few
different
brokers
across
lots
of
different
vendors,
most
like
as
I
said,
most
of
them
work,
but
there
are
thorns
that
need
to
be
addressed
in
order
for
these
brokers
to
work
with
service
catalog.
D
If
we
don't
address
them,
then
one
of
two
things
will
happen:
either
the
person
who
wants
to
use
the
broker
in
their
kubernetes
cluster
will
submit
a
patch
to
the
broker
and
fix
it,
or
they
will
ditch
us.
We've
seen
that
pattern
before
so.
Generally
speaking,
the
person
who's
using
the
broker
owns
the
broker
and
that's
great
because
they
can
fix
the
broker
and
it's
pretty
easy
to
deal
with.
We
have
gotten
a
few
people
coming
into
our
slack
and
asking.
How
can
they
make
a
broker
work?
D
Given
this
error
happens,
and
so
far
those
have
been
just
issues
with
our
UX.
We
can
tighten
up
some
part
of
our
UX
and
they
can
figure
out
what's
going
wrong
at
all
as
well
with
the
world,
but
we
I'm
saying
now
from
a
Microsoft
employee
standpoint,
we've
seen
people
who
have
not
decided
to
use
Service
Catalog
because
it
doesn't
work
with
a
broker.
D
So,
yes,
Doug,
I
I
will
raise
those
issues
as
I
can
and
I'm,
not
asking
anyone
to
write
special
case
code
proactively
I'm,
actually
not
asking
you
under
a
special
case
code
at
all,
but
I
am
staying
right
here
and
now
that
we
will
need
to
consider
the
case
where
a
broker
is
important
to
someone
and
it
doesn't
work
completely
with
Service
Catalog,
we'll
have
to
address
that
somehow
I'm
not
going
to
prescribe
how
we
need
to
address
it.
But
I
can
tell
you
that
so
far.
E
E
All
I'm
saying
is
that
I
don't
think
that
we
should
ever
make
changes
that
are
have
nothing
to
do
with
the
spec
of
open
source
broker
into
maze
catalog
in
order
to
make
them
work
so
either
we
change
the
broker
and
you
know-
or
we
say
they
trying
to
do
something
valid-
that
isn't
a
sort
of
specified.
There
is
no
way
to
specify
that
valid
behavior
in
the
open
source
broker
spec.
E
This
particular
item
environment,
in
my
opinion,
that
not
really
a
compliant
broker
the
fact
that
it
doesn't
work
on
use
it
in
brought
to
the
Medi
s
is,
is
about
its.
You
know
it
can't
be
certified
as
a
standard
broker,
and
we
should
understand
those
cases
and
again
drive
to
add.
Whatever
features
are
missing
to
local
stores
broker
spec,
it
made
somebody
sort
of
reach
reach.
You
know
around
the
curtain
and
then
like
do
something
with
the
for
the
environment
that
they're
assuming
they're
running
in
so.
A
For
example,
we
don't
do
plan
updates,
we
don't
do
parameter
updates
and
we
know
that
we're
not
compliant
yet
I
think
that
we
also
all
know
very
well
that
there
are
that
the
open
service
broker
API
before
it
became
open
service
program
was
a
foundry
service
broker.
I
came
from
my
culture
with
a
lot
of
oral
history
and
a
lot
of
unwritten
conventions,
and
so
I
think
it's
a
virtual
certainty
that
we
will
find
areas
of
the
spec
that
are
ambiguous
and
we've
already
found
a
ton
of
those
so
like.
A
C
Well,
I'm
going
to
stop
talking
Doug.
What
do
you
want
to
say
so?
Just
kind
of
said
rather
wrap
this
up,
because
I
think
we're
getting
to
the
point
now
where
it's
almost
like
we're
rattling
or
wordsmithing
over
text
that
were
actually
not
actually
looking
at
or
trying
to
construct
other
than
say,
I.
Think
Rhonda
green
meant.
Let's
wait
until
we
have
a
concrete
example
of
a
broker
that
wants
us
to
do
something.
We
don't
want
to
do
and
then
we'll
tackle
at
that
point.
A
I
think
the
point
of
what
I
want
us
to
take
away
is
that,
let's
give
people
the
benefit
of
the
doubt
that
are
having
trouble
getting
their
broker's
running
and
let's
work
with
them
and
we'll
handle
things
on
a
case-by-case
basis.
So
now
that
we
have
level
set
on
that,
I
tell
you
what
I'm
going
to
take
an
action
item
to
write
that
up.
A
A
A
A
A
Don't
think
that
and
I'm
confident
that
we
can
add
things
to
it
that
are
backward
compatible
in
the
future,
I
will
say
at
Red
Hat.
We
have
not
yet
implemented
this
in
any
of
the
brokers
that
we
care
about,
and
so
the
question
that
I'm
struggling
with
is
that
I
saw
that
this
the
whole
request
has
been
merged,
I'm,
not
sure
how
it
was
merged.
I'm.
Sorry,
this
is
the
poor
request
to
add
this
to
the
state
of
the
API
be
published
in
the
next
release.
I'm,
not
sure
how
it
was
merged.
F
A
To
the
extent
of
length
of
the
platforms
that
are
trying
to
implement
the
spec,
which
of
them
think
it
is
ready,
that
is
something
that
I
will
be
bringing
up
next
I'm.
Sorry,
tomorrow
on
open
serviceworker,
API
working
group,
but
it's
a
fairly
simple
feature:
I
I
would
like
not
to
do
things.
I
would
like
to
follow
some
kind
of
rules,
but
in
this
case
I
think
we
could
probably
live
with
it.
Staying
in
and
being
in
version,
2
12
its.
C
In
general,
I
agree
with
you,
Paul
I
was
actually
a
little
bit
surprised.
It
was
merged
as
well.
Having
said
that,
it's
water
under
the
bridge
we
could,
if
we
really
want
to
be
in
asks
about
it
and
asked
where
they
get
rollback.
I,
don't
think
it's
worth
it
at
this
point
in
time,
I
think
the
steps
you've
taken
in
the
the
other
working
group
to
ask
for
clarification
of
the
rules
in
the
process
and
try
to
restrict
or
about
that
going
forward
is
the
byproduct
is
the
right
way
to
go
as
of
right
now.
C
E
E
This
is
something
that
we
should
build
in
at
the
end
context
and
where
the
context
is
something
that
we
as
the
source
catalog
should
just
be
pre-populated
with
namespace
and
with
what
the
other
thing
that
the
Dunn
said
we
probably
add
to
it
and
I
think
was
cluster
or
something
like
that.
Is
that
really
something
that
we
should
be
prescribed
me
that
Halloween.
E
A
I
think
the
answer
to
that
is
that
the
as
far
as
I
understand
the
organ
space,
which
are
the
coordinate
system
for
Cloud
Foundry,
are
specified
by
the
platform,
and
we
definitely
need
an
area
to
send
the
kubernetes
coordinate
system.
The
problem
is
that,
like
the
way
that
D
the
way
that
the
API,
ideally
would
have
been
written
in
the
first
place,
does
that
add
something
like
context?
That's
just
a
bucket
that
you
can
send
whatever
send.
This
is
the
platform
that
I'm
that
I
am,
and
these
are
the
coordinate
system
pet
I'm,
sending
from.
A
Unfortunately,
we
did
not
have
reality
play
out
that
way,
and
there
are
first-class
fields
for
the
Cloud.
Foundry
coordinates
in
the
API
and
we
did
not
want
to
add
a
new
like
add
new
fields
for
kubernetes
coordinates,
so
I
think
there's
a
really
good
case
for
sending
it
and
here's
where
I
let
coq
because
he's
the
person
that
actually
wrote
the
proposal.
E
The
Cloud
Foundry
was
a
monoculture
right,
but
it
was
the
only
thing
that
used
service
broker
source
boxes
that
were
only
ever
written
for
Cloud,
Foundry
and
so
using
that
kind
of
a
convenient
sort
of
catch-all
for
making
lots
of
assumptions
about
your
environment
I'm
just
trying
to
figure
out
if
I'm
writing
a
service
broker.
How
do
I
write
a
service
broker?
E
That
I
said
earlier
is
that,
if
you
happen
to
know
who
happened
to
be
something
that
is
aware
of
boundary
is
aware
of
of
committees.
In
this
case,
you
might
wire
something
up
on
the
back
end
like
completely
out
of,
and
that
basically
says
hey
make
committees
names,
food
blah,
right,
I
would
rather
find
those
scenarios
and
put
those
in
cute
private
work.
No,
the
admin
or
the
like,
like
API,
whatever
you
guys,
are
calling
it
the
various
extra
people
that
kind
of
stuff
is
a
direction
where
you
can
start
locating
about
other
things.
E
C
C
If
they
just
need
to
be
able
to
know
whether
something
is
unique
relative
to
another
constants
that
we've
created,
because,
for
example,
they
may
want
to
limit
one
instance
of
a
service
per
context
right
so
I,
don't
like
I
said
they
don't
assign
you
to
understand
what
Morgan's
visited.
If
you
will
do
a
uniqueness
check
right
and
that's
that's
one
level
absurd
worker.
Now
there
are
other
service
workers
that
are
exactly
as
you
described
right.
C
They
understand
exactly
the
urban
spaces,
they're
going
to
understand
what
namespaces
and
they're
going
to
talk
to
the
platform
and
do
some
special
behind-the-scenes
work
and
those
are
more
advanced
hard
that
hard
coded,
but
smart
and
knowledgeable
brokers,
and
they
exist
out
there
because
they
can
do
other
things
and
we
need
to
be
able
to
help
those
guys
out.
But
to
your
original
point,
though.
Well,
how
do
I
make
a
very
generic
broker
that
doesn't
want
to
understand
anything
stuff
and
just
want
to
talk
to
everybody?
You
can
do
that.
C
You
don't
have
to
understand
context
and
that's
one
of
the
reasons
context
was
created.
It
is
to
allow
us
to
move
this
point
specific
stuff
into
a
field
where
you
could
say
if
you
don't
care
about
it,
Norris,
but
if
you
ever
do
need
it,
it's
all
in
one
spot
and
here's
how
its
defined
for
a
compounder
popcorn,
here's
how's
the
fight
for
a
group
that
is
platform
and
that's
and
that's
just
the
way
we
designed
it.
C
So
we
basically
support
all
three
different
types
of
scenarios
and
you're
the
one
that
you
are
most
concerned
about,
which
is
support.
Anything
under
the
Sun.
That's
fully
supported
the
weights.
Design
was
it
to
be
honest.
I'd
rather
have
to
Scott
discussed
this
discussion
in
spectral
group
rather
than
here.
A
C
A
Think
that
this
is
probably
more
appropriate
for
the
spec
working
group
and
and
I'm
happy
to
continue
the
conversation.
Offline
I
am
not
sure
where
this
leaves
us
I
think
we're
still
in
in
an
indeterminate
state
as
far
as
like
what
we
should,
what
we
should
take
it
back
to
open
service
broker
API,
but
that's
okay,
there's
that
that's
just
natural!
So
Martin.
Would
you
like
to
to
come
to
open
service
for
API
working
group
tomorrow,
I
was
planning
on
it.
Okay,
excellent.
A
We
should
have.
We
can't
really
release
a
beta
version
without
a
beta
ap
I.
So
there
are
two
facets
to
it,
which
is
what
do
we
need
to
do
to
make
the
Service
Catalog
API
surface
beta?
And
what
do
we
need
to
do
to
feel
as
though
the
catalog
incubator,
repo
as
a
whole,
is
a
beta
level
and
the
the
guidance
that
I
can
give
there
is
that
in
kubernetes?
Api
is
beta
means
that
well,
let's
talk
about
what
alpha
is
first
so
and
alpha
api
kubernetes
means
things
can
be
changed
or
deleted.
A
A
That
will
happen
and
it's
basically
used
your
own
risk.
So
what
beta
means
is
that
if
there
are,
if
there
are
backward
incompatible
changes
that
there
will
be
a
migration
or
conversion
between
B
1,
beta
1
and
B
1
beta
2
I,
there's
also
once
you
call
an
API
beta
the
the
constraint
of
there
should
be.
We
should
make
an
effort
to
have
a
data
migration,
all
right,
so
API
resources
that
are
beta
when
the
API
goes
to
GA
should
be
migrated,
so
data
should
be
migrated
when
something
goes.
A
Ga
and
GA
is,
but
also
a
beta
like
there's
still
the
expectation
that
there
might
be
bugs
and
then
GA
is
like
we're
only
going
to
make
backward
compatible
changes.
Obviously,
data
gets
migrated.
Naturally,
since
it's
only
backward-compatible
changes
and
to
make
an
impact,
incompatible
change
like
to
a
v1
API,
you
need
a
v2
alpha
one.
So
if
you're
going
to
make
a
backward
incompatible
change,
you
can't
do
that
within
a
v1.
A
It's
got
to
be
a
new
version,
that's
alpha,
so
we
have
been
talking
amongst
belay,
dug
in
and
myself
a
little
bit
about
what
the
criteria
should
be
and
since
I
have
the
bully
pulpit.
I
will
utilize
it
now
to
tell
you
my
own
personal
idea
of
what
it
should
be
and
I'm
going
to
pull
a
place
where
I've
written
this
up
on
my
phone
quickly,
so
I
can
look
at
it
and
I'll
just
I'll
throw
some
stuff
out
there.
A
If
you
make
a
backward
incompatible
change
to
a
beta,
API
and
I'm
lazy,
so
I
don't
want
to
do
any
work.
I
don't
have
to
do
if
we
can
implement
those
two
use.
Cases
I
think
that
we'll
be
able
to
have
a
much
higher
degree
of
confidence
that
we
can
betta
without
armed
without
making
a
backward
incompatible
change
like
if
we
were
to
go
to
beta,
and
then
we
implemented
these
things
I
think
we
might.
A
A
We
should
try
to
ensure
that
we
can
handle
things
like
if
I
made
an
instance
resource
and
the
provision
failed,
I
need
to
be
able
to
go
and
delete
that
as
an
example.
So
misbehave
brokers
should
not
torpedo
the
API
working
correctly.
I
guess
would
be
one
way
to
say
that
and
then
also
I
think
that
we
should
talk
through
broker
update
and
what
happens
when
you
call
a
broker's
catalog
endpoint
again
and
you
get
a
new
payload
as
gifts
from
the
last
day.
A
D
I
only
have
editions
I,
don't
have
opinions,
differing
opinions
on
what
you
said
about
broker
update,
so
I
can
give
my
additions
if
anyone
else
that
I'm
opinion
gotta
walk
all
said,
go
for
it.
I
will
take
that
as
a
no
okay.
So
one
thing
that
we've
seen
a
bunch
of
is
it's
very
difficult
for
people
to
grok
the
difference
between
the
core
kubernetes
api
server
and
the
service
catalog
api
server.
D
The
question
we
get
almost
constantly
on
every
show
every
demo
every
talk,
every
user
that
we've
seen
is
why
do
I
have
to
do
that?
So
one
criteria
that
I
personally
have
for
beta
is
to
have
this
thing,
working
behind
the
aggregator
and
have
our
documentation
up
to
date
such
that
no
one
has
to
get
the
Service
Catalog
API
servers
IP
or
create
a
coop
CTL
context,
and
ideally,
they
could
bundle
instances
and
bindings
and
potentially
even
brokers
with
helm,
charts
of
their
applications.
D
Since
we
use
helm,
charts
pretty
significantly
to
distribute
application,
and
that
is
so
that
a
single
helm
install
can
illustrate
the
power
serves
catalog
all
the
way
from
provisioning
through
binding
through
your
app
starting
up,
and
then,
on
the
other
hand,
when
you
do
a
helm,
delete
than
the
deletion
of
those
aforementioned
resources
with
teardown
the
application
and
unbind
and
be
provision.
So
you
can
kind
of
see
you
know
taking
all
these
steps
that
are
currently
in
our
walkthrough
and
compressing
them
down
into
potentially
to
command.
D
That's
super
powerful
not
only
for
demos,
of
course,
but
something
that
our
users
that
we've
shown
this
thing
to
have
requested
quite
a
bit.
So
that's
one
of
two.
The
other
thing
is
around
testing
I'm,
not
going
to
beat
a
dead
horse,
I'm
just
going
to
say
that
the
stuff
that
I've
talked
about
with
you
know
the
concept
of
real
brokers
and
having
edge
cases.
That
pause,
call
is
mentioned
as
well.
D
A
A
A
F
A
What
I
think
is
question
shanell,
here's
the
thing
is
that
I
actually
have
made
the
polar
question
was
merged
was
not
my
first
attempt
at
integrating
pod
preset.
Okay,
the
first
time
I
attempted
it.
I
basically
had
excuse
me
embedded
a
pod
preset
spec
in
the
in
the
binding
spec,
and
what
I
quickly
found
out
is
that
there
are
no
exported
validations
from
the
core
that
you
can
use
in
an
external
API
server
to
validate
part
of
an
object
like
that.
A
So
I
actually
created
an
issue
which
I
will
send
you
a
link
to
after
this,
to
try
to
figure
out
how
to
do
that.
One
thing
I
had
talked
about
was
fill
with
rock
and
with
some
other
folks
that
are
knowledgeable
about.
Such
things
is
having
like
a
special
endpoint
that
you
could
use
to
validate
API
types
that
may
not
be
API
resources,
but
base
a
way
to
validate
pull
API
resources
or
API
types
that
are
not
themselves
resources
without
actually
creating
a
resource.
A
I
think
that
this
is
one
of
the
one
of
the
many
gaps
that
no
one
has
started
thinking
about
yet
in
the
road
to
a
magical
land
where
all
api's
are
just
like
aggregated
and
work
together
beautifully.
But
it's
something
that
like
I,
can
think
of
a
few
different
extensions
that
are
going
to
be
based
on
their
own
API
servers.
That
will
probably
have
this
exact
same
problem.
We
need
to
feed
this
out.
Like
I,
said,
I
created
a
recent
issue
for
it,
and
the
issue
has
stayed
exactly
where
I
put
it
down.
A
F
F
I
had
a
second,
we
should
not
religion
apart,
we
said
but
go
about.
What
are
we
thinking
about
as
an
end
user
if
I
want
to
deploy
service
broker,
not
service
book?
Oh
sorry,
Service
Catalog
in
my
kubernetes
cluster.
What
is
the
general
guideline?
The
end
goal,
how
they
want
people
to
deploy
that
so.
A
We've
got
a
helmet
in
the
repo,
okay
and
I
I.
Think
that
the
the
fact
of
guidance
that
we
give
is
use
the
helmet
chart
if
you
need
something
more
right
now,
you're
on
your
own,
because
we
have
very
limited
bandwidth
to
support
those
things.
So
if
somebody
wants
to
do
something
else,
I
would
be
happy
to
talk
to
them
and
see
what
they
want
to
do
and
see.
A
D
Since
aeneas,
if
you
find
out
the
help,
chart
doesn't
do
something
that
it
needs
to
do
or
that
you
need
to
do,
submit
an
issue,
ping
ping
or
cc
me
and
and
others
if
you
think
others
need
to
know
as
well.
I
can
muster
some
resources
in
the
next
couple
of
weeks
to
update
the
helm
charts
if
it's
something
big
and
if
it's
something
small
I
can
probably
get
it
done
pretty
quickly.
Okay,.