►
From YouTube: Kubernetes SIG Service Catalog 20170809
Description
- Parameters for service instances and bindings
- Binding credentials API
- Bug: catalog creates pod with an annotation that is too large
- Rebasing after 0.1.0
A
B
Ball
not
doing
anything
different
I'm
we're
gonna
continue
to
do
the
speaker.
Queue
got
my
high-tech
equipment,
as
I
was
I
want
to
introduce
everyone
to
George
George's
from
hefty,
oh
and
he's
on
he's
a
part
of
the
community
team
included
a
score.
He
has
very
generously
agreed
to
help
us
take
really
good
detail
of
notes
for
today
and
hoping
that
everyone
acts
on
their
best
behavior
so
that
he'll
stay
with
us,
so
we're
gonna
do
the
same
thing.
We've
got
our
notes
here,
I
just
pasted
into
the
docs.
B
C
Yeah
we
have
discussed
this
issue
many
times
before
now.
It's
turned
into
the
minimal
improvement
of
the
existing
one,
so
we
currently
have
inline
JSON
support
and
we
needed
a
support
for
secrets
and
I
just
added
parameters
from
section
with
as
a
union
type
which
we
can
extend
in
the
future
and
for
now
it
supports
only
one
source
which
is
a
secret
key
or
reference
at
two
adjacent
blob
and
I
think
it
should
be
good
enough
for
most
people
who
were
requesting
this
feature
for
now
at
least
and
I
have
also
implemented
this
feature
already.
C
There
are
some
like
my
no
comments
from
Paul
I.
Think
I
will
dress
them
probably
today,
and
if
there
are
any
objections
or
or
or
requirements
for
making
it
equation
differently
or
blockers,
Quizlet
take
a
look
and
this
design
proposal
I
think,
should
reverse,
but
because
it
was
written
as
a
documentation,
not
as
a
proposal.
I
think
Paul
suggested
to
merge
it
after
we
merge
the
code
implementing
cool
so.
A
We
have
I
thought
that
we
already
had
consensus
on
this
I
think
your
code,
PR,
is,
is
ready
to
merge
modular.
This
coupled
knits
about
documentation
in
the
gotalk
for
the
types
I
suggest
that
we
go
ahead
and
merge
this
once
once.
You've
addressed
those
and
then
merged
the
the
doc
in
I
think
that
we
should
be
done
for
beta
with
this.
C
A
A
D
So
my
only
there's
a
really
bad
echo.
My
only
request
is
that
we
wait
until
the
end
of
the
day
or
tomorrow
or
so
and
then
once
it
reaches
you
know
the
two
LG
g2
can
emerge.
The
reason
I'm
asking
for
a
little
bit
of
delay
is
because
I've
been
meaning
to
review
the
code
I
just
to
do
it
yet
so
I'd
like
at
least
an
opportunity
to
have
one
more
day
to
get
a
chance
to
review
it
before
we
merge
it.
Why
don't
they
ask
okay.
E
D
B
D
B
B
A
B
C
Yeah
I
have
raised
this
issue
just
a
couple
a
couple
days
ago,
and
it
is
inspired
by
the
previous
PR
we
have
just
discussed
so
with
the
current
implementation.
The
way
binding
credentials
are
stored
is
split
like
each
key
in
credentials.
Object
is
split
into
a
separate
JSON
object
and
it's
stored
as
a
key
key
value
pair
in
secret,
but
previously
I
think
Sam
has
mentioned
that
there
is
a
limitation
of
this
approach.
C
It
was,
for
instance,
parameters,
but
it's
the
same
for
bindings,
that
secret
key
has
more
limitations
on
the
format
than
Jason
property,
for
example.
He
doesn't
allow
slashes
dollar
or
other
some
other
characters
which
are
valid
for
Jason,
which
means
that
if
any
of
these
characters
are
returned
as
part
of
the
credentials
object
response
from
broker,
we
will
fail
to
store
it.
This
is
one
problem
and
the
other
is
that,
like.
C
If
someone
to
process
the
credentials
as
a
blob
and
like
as
a
single
entity,
it
will
have
to
combine
it
back
based
on
the
key
value
pairs
in
secret,
which
is
also
I'm,
not
sure
if
it's
the
best
user
experience.
So
my
question
was
mostly
about
like
it
seems
that
current
implementation
is
a
nice
when
credentials
objects
is
returned
as
map
string
string
as
a
flat
map
and
it's
easy
to
inject
separate
values
from
credentials
as
environment
variables.
C
A
A
The
the
probably
the
immediate
thing
that
we
would
use
this
for
would
would
be
if
people
wanted
to
start
after
the
initial
beta
release
working
on
V
cap
services,
binding
that
would
be
on
top
of
the
open
service
broker,
binding
I.
Think
that
would
be
very
useful
for
this
I.
Don't
think
I
would
Bend
this
in
terms
of
the
initial
beta
as
a
nice-to-have.
A
I
would
prefer
not
to
have
additional
design
discussions
on
it
until
we
talk
through
some
of
the
more
pressing
things
unless
everybody
thinks
that
what
Niles
already
proposed
for
union
type
sounds
good,
in
which
case
if
we
can
get
a
quick
consensus,
I
think
that
would
be
great
sorry.
Distraction,
I
think
there
are
other
design
things
that
probably
are
higher
priority
to
talk
through.
First,
unless
we
think
it's
going
to
be
a
very
quick
consensus.
D
From
looking
at
both
of
the
issues
it
seems,
like
you
know,
one
of
those
would
cause
a
change
to
our
model,
and
so
from
that
perspective,
I
think
we
should
at
least
have
the
design
discussion
before
beta
relative
to
the
two
proposals.
No
I
think
you,
the
poster
you
have
in
that.
What
is
it?
One
1:09
seems
fairly
straightforward.
D
My
only
comment
on
that
is
I
actually
would
like
to
see
both
in
there,
because,
if
I
understood,
what
you
were
sitting
correctly
is
if
there
are
any
property
names
that
cannot
be
mapped
to
secret
names
because
of
a
character,
mismatch
that
they'll
basically
be
skipped.
So
I
would
like
the
ability
to
say
stick
the
entire
blob
in
there.
D
For
those
cases
where
I
know,
they're
gonna
be
things
that
won't
come
back
as
secret
keys,
but
I
still
need
access
to
them,
but
for
other
things,
I'm,
okay,
with
going
to
the
secret
key
to
get
them.
So
that's
why
I
I
do
see
a
need
for
both
but
I
think
between
the
two
and
I
think
what
you're,
proposing
and
1109
seems
fairly
straightforward
and
we
could
probably
come
to
a
fairly
quick
resolution.
I
think.
C
A
So
it
sounds
like
we're
pretty
close
together
on
this
I
as
far
as
Doug's
desire
for
both
I
think
that
can
just
be
another
union
type
option,
so
we
could
have
the
flat
matte
type
style.
What
we
do
today
is
one
option
we
could
have
shove.
It
shove
everything
into
a
single
secret
key
as
an
option,
and
then
we
can
have
another
option
for
both
and
I
think
those
would
be
forward
compatible
and
mmin
like
we're
pretty
close
to
consensus.
D
Right,
Doug
get
a
hand
up
go
ahead.
Yeah
between
the
two
proposals,
I
prefer,
the
one
or
1109
I
I
find
the
Union
type
to
be
kind
of
clumsy
because
it
requires
wrappers
around
everything.
I
think
the
way
novel
is
laid
it
out
there.
It's
it's
very
straightforward
and
easy
for
someone
to
get
there
and
it
allows
for
one
or
both
without
having
to
create
yet
another
type
of
thing,
meaning
another
union
type.
I
think
I,
think
1109
simplicity
is
is
overwhelming
to
me.
A
All
right
go
ahead.
Paul
I
think
that
we
should
recognize
that
this
is
a
situation
where
we
intended
to
rathole.
So
why
don't
we
go
over
specifically
what
is
proposed
in
1109?
It
sounds
like
we're:
gonna
try
to
get
design
consensus
on
that
on
this
now
and
that's
fine,
let's
look
at
11:09,
so
we
can.
We
can
discuss
it
together.
B
A
D
B
B
A
Okay
share
my
screen,
I
will
share
my
screen
and-
and
we
can
just
look
at
this
quick
and
I-
think
that
we're
very
close
together.
So
hopefully
people
can
look
at
this
knowledge.
You
can
explain
the
proposal
and
let's
just
get
a
consensus
on
it
and
move
on.
Does
that
work
for
everybody
or
I,
don't
even
have
to
share
my
screen.
George
has
already
done
it,
but
then
he
second-guessed
himself.
A
C
So
at
the
top
we
see
that
the
way
it's
currently
implemented.
So
at
the
top
level
of
specification
we
have
a
single
secret
name
field
and
the
problem
with
it.
I
have
listed
like
three
issues
which
I
have
already
mentioned
already,
that,
like
secret
key,
is
its
limitation
also,
when
we
split
the
values
from
credentials.
If
it
contains
some
specific
types,
other
than
objects
like
JSON
array
or
integer,
or
something
else,
we
can't
tell
what
was
the
value
type.
C
It
could
be
a
problem
and,
as
I
said
before,
that
like,
if
credential
is
not
a
flat
map
string
string
but
something
more
complicated,
it
doesn't
help
to
you
to
inject
environment
variables.
You
have
to
manipulate
this
data
anyway,
and
it's
easier
to
manipulate
the
raw
just
blob,
rather
than
trying
to
merge
it
back
in
from
key
value
pairs.
So
the.
C
So
it
could
be
either
the
same
approach
as
we
currently
have
for
secret
name,
but
it
will
be
a
separate
field
called
secret,
with
a
secret
ref
containing
the
name
of
the
secret
to
put
the
value
in
and
the
separate
one
is
secret,
key
ref
which,
which
is
will
be
used
for
storing
the
entire
JSON
blob,
and
potentially
we
can
have
other
fields
as
well.
At
this
level,
that's.
B
A
From
what
I've
heard
so
far,
I
think
that
we
have
a
consensus
on
most
of
this,
and
the
consensus
is
that
we
should
support
these
methods
individually.
I
do
not
think
that
we
have
a
consensus
on
how
to
support
both
of
them,
and
so
here's
what
I
suggest
I
suggest
that
we
adopt
what
now
is
proposed
in
1109
and
both
of
the
flavors
that
I
think
are
have
like
we
have
different.
A
My
read
is
that
we
have
different
two
different
flavors
of
how
we
would
support
both
I
think
that
we
should
split
that
into
a
separate
issue
and
discuss
it
separately,
and
let's
get
consensus
on
this,
both
of
the
flavors
that
we've
discussed
are
forward
compatible
with
this
API.
So
that
would
be
my
suggestion
that
lets
us
focus
the
discussion
on
what
we
do
agree
on.
We
can
move
on
in
Doug,
I
think
you're,
primarily
interested
in
supporting
both
simultaneously.
A
B
C
I
think
it's
just
more
exclusive
of
what
this
secret
means,
because
four
bindings,
for
example,
which
is
a
secret
name,
it
doesn't
like
suggest
you.
What
is
this
secret
name?
Is
it
output?
Is
it
input?
Is
it
for
credentials
or
something
else?
It's
just
secret.
Well,
if
you
put
it
inside
credentials,
it's
clear
that
you
say
that
I
want
to
put
the
secret
credentials
into
this.
D
C
So
my
initial
proposal
was
to
not
have
both
things
specified,
but
I
think
if
we
want
to
support
multiple
things
by
looking
at
the
community's
api's
and
the
way
we
have
implemented
instance,
parameters,
I
would
suggest
that
we
don't
still
don't
support
setting
in
multiple
Wells
at
a
time,
but
we
can
provide
a
list
of
outputs
if
it
makes
sense.
So
if
you
could
just
say
put
it
into
a
secret
and
into
this
secret
and
into
this
secret
key
ref
and
like
how
many
times
you
want
to
put
the
result
into
it's
up
to
you.
C
D
C
A
G
G
B
F
Yeah
it
was,
there
was
an
issue
with
the
way
we
were
creating
a
pod,
preset,
I
guess
and
that
we
there's
an
annotation
that
gets
created
that
was
too
long
and
doesn't
validate
downstream.
So
we
would
get
a
failure,
but
if
it's
just
something
to
pay
attention
to
when
we
bring
back
prod,
presets
or
whatever,
so
you
know
as
it
is
I
guess,
there's
there's
probably
not
anything
to
you
since
I
just
wanted
to
make
sure
that
we
pod
presets
were
going
away.
This
has
been
on
here
for
I,
guess
a
week
or
two.
F
A
B
D
A
B
D
Was
not
able
to
get
ahold
of
him?
Okay,
I
think
that'd
be
more
interesting
than
my
conversation,
but
okay,
so
this
was
added
only
because
we
were
talking
about
yesterday
and
I
had
an
AI
to
add
it.
Basically,
what
I
like
to
guess
do
have
a
discussion
about
post,
1:8
or
I
guess
opposed
beta.
How
often
do
we
want
to
rebase?
Do
we
want
to
track
the
community's
release
going
forward
and
just
to
sort
of
focus?
D
The
discussion
and
I
put
out
a
proposal
for
people
to
throw
darts
at
once
we
go
beta
I
propose
that
we
try
to
make
sure
that
we
align
with
the
Correa's
releases.
We
could
do
it
more
often
if
we
want,
but
at
a
minimum
we
try
to
release
on
time
with
Chron's
releases
and
when
we
do
so,
we
rebase
on
top
of
that
kubernetes
release,
that's
being
released.
A
D
I'm,
a
little
confused,
so
I'm
yeah
dry
I
have
no
problem
starting
a
thread
or
discussion.
Someplace,
that's
no
big
deal
but
I'm
not
quite
sure
what
I
would
be
asking
about,
because
my
gut
reaction
is
that
it's
sort
of
up
to
each
incubator
project
to
decide
whether
they're
in
a
position
to
rebase,
often
or
not
so
I,
would
think,
would
almost
be
like
a
per
projects
decision
to
be
made
in-house
I
wouldn't
I
have
a
global
decision
kind
of
thing,
mate.
So
I'm
not
quite
sure.
What
are
you
asking
so.
A
I
think
the
general,
the
general
problem
statement
is,
should
there
be,
should
we
establish
a
an
expectation
in
the
community
that
extensions
like
this
will
rebase
on
a
particular
schedule,
or
is
it
up
to
every
project?
And
if
we,
if
we
decide
at
like
the
cig
architecture
level,
that
there
should
be
a
uniform
thing
that
people
try
to
do?
A
What
should
that
thing
be
the
without
so
I
can
see
an
argument
that
there
should
be
some
guidance
that
we
give
to
extensions
like
this,
because
I
think
that
it
might
be
very
confusing
to
users
and
the
community
in
general.
If
we
have
like
ten
extensions
and
three
of
them
always
rebase
on
the
machinery
as
soon
as
its
release
and
three
of
them
always
rebase
on
the
machinery
of
release
behind
and
four
of
them
just
do
whatever
they
want
at
any
given
time
it
will
probably
be
confusing.
A
C
My
suggestion
was
just
if
we
want
you
to
rebase
as
soon
as
the
new
release
is
out,
which
would
probably
have
whether
a
branch
on
to
master
all
the
time
or
have
it
PR
started
one
two
weeks
before
the
releases
out,
so
that
we
can
review.
We
can
fix
all
the
issues
and
as
soon
as
the
release
is
out,
it's
basically
just
change
the
hash
commit
and
that's
it
should
be
that
that
easy.
F
F
So
we
need
API
machinery
to
have
an
opinion
on
when
they're
going
to
cut
their
release
essentially
ahead
of
time.
You
know
they
need
to.
They
need
to
be
ready
a
week
in
advance
or
something
and
I
think
that's
probably
possible,
but
we
need
API
machinery
on
board
to
you
know
have
something
for
everybody
to
build
on
consistently.
E
I
was
just
gonna
say
you
also
might
be
one
of
the
first
tools
to
ask
about
this
issue
at
all.
So
if
anything,
you're
kind
of
helping
sig
arch
to
kind
of
what
else
is
there
sulla
tater
of
communication
in
between
SIG's
right?
If
it's
like,
hey,
what's
how's
everybody
else,
gonna
rebase,
even
if
it
seems
like
such
a
simple,
you
know
what
I
mean.
B
D
You
are
in
the
queue
as
well
go
ahead.
It
so
I
guess
this
question
is
more
for
kibbles
I,
don't
I
I
think
you
probably
understand
the
infrastructure
of
our
build
stuff,
a
lot
better
than
most
of
us
here.
So
I'm
asking
you
how
difficult
you
think
it
would
be
to
set
up
a
Travis
kind
of
job
that
would
rebuild
our
stuff
on
a
regular
basis
on
kubernetes
master
infrastructure.
D
Michael
you
so
there
are.
We
do,
though,
Mike
okay,
you
can
just
answer
in
the
chat,
then
okay,
because
that
might
be
something
that
we
might
want
to
do.
Just
as
a
side
thing
say,
you
know
set
of
a
cron
job
kind
of
thing.
So
once
a
night
it
does
a
build
basing
on
coop
coop
master,
and
we
can
just
see
how
that
goes.
D
H
Just
curious
on
sort
of
kind
of
and
and
my
concern
is
creating
a
an
automatic
process
that
nobody
does
anything
about
it.
So
we
assume,
for
example,
that
that
new
version
of
Cooper
Navy
starts
coming
out
and
everything
just
continuously
breaks.
Everything
else
is
somebody
gonna
go
in,
do
anything
about
it.
Are
we
just
gonna?
Basically,
you
know
waste
resources
and
create
errors,
and
nobody
does
anything
about
it.
I
mean
I'm
perfectly
fine
to
go
ahead
and
have
something
that
ensures
that
once
something
is
expected
to
work,
it
stays
working.
H
A
Making
it
easy
to
establish
which
versions
of
these
dependencies
work
with
one
another
is
suggested
to
be
solved
by
having
a
release,
branch
or
tag
for
each
of
them.
That
is
the
kubernetes
release,
so
you
can
put
in
the
glide
llamo.
For
example,
you
could
put
API
machinery,
1.80,
API,
server,
1.80,
etc,
etc,
etc,
which
I
think
would
be
pretty
helpful
since
it
was
pretty
hard
for
us.
It
read
had
to
figure
that
out
during
the
first
release
and
I.
Think
Atlassian
had
some
trouble
with
that
too.
Their
first.
H
D
A
D
Dead,
your
next
go
ahead,
yeah,
so
civilians
question
I'd
like
to
get
into
a
mindset
where
our
ultimate
goal
is
that
we
could
rebase
anytime.
We
want
and
I
think
kubernetes
would
be
benefited
if
it
got
into
the
mode
where
they're
gonna
assume
people
are
going
to
be
ven
during
their
their
code
and
their
api's
and
stuff,
and
so
they
cannot
break
people
even
for
one
night.
I
master
I
think
that's
sort
of
the
ultimate
goal.
D
So
if
we
can
take
the
arrows
for
the
for
that
for
that
goal
and
help
push
them
in
that
direction,
I
think
that'd
be
goodness
and
so
be
late
to
your
specific
thing:
I'm,
okay,
with
the
model
where
we
say
you
set
up
these
cron
jobs
or
whatever
and
initially
we're
not
going
to
notify
by
it.
If
things
fail,
things
fail
and
we're
gonna
try
to
fix
the
best
we
can,
but
then
we
get
to
the
point
where
things
do
pass
on
a
regular
basis.
D
I
think
at
that
point,
yes,
I
think
we
should
take
on
a
task
of
nagging
the
heck
out
of
people
to
get
them
to
fix
it.
The
minute
they
break
something
and
and
at
some
point
I
think,
should
we
hopefully
moved
into
the
main
crew
minetti's
repo
as
a
process
or
test
set
of
test
cases
or
something,
but
for
right
now,
I
think
I
think
we
should
help
out
that
the
bigger
be
IDs
team
and
then
try
to
see
if
we
can
let
her
lay
down
a
process
that
may
be
able
to
follow
later
on.
C
So
my
suggestion
was
that
I
don't
think
the
automatic
job
can
really
work
well.
One
of
the
reasons
is
that,
for
example,
when
EPA
machinery
or
we
need
to
start
preparing
the
next
release,
they
cut
the
release
branch
and
continue
all
the
fixes
inside
this
branch
and
master
is
still
there
and
they
can
break
things
after
they
make
a
cut.
So
if
we're
still
rebasing
on
on
to
master,
it
doesn't
help
us
to
rebase
on
to
the
release.
C
C
Potentially
we
can
have
our
master
being
dependent
on
the
master
of
the
of
the
EP
machinery,
for
example,
and
once
they
cut
the
release,
we
do
cut
release
as
well,
something
like
that,
but
then
I
guess
our
releases
should
be
in
sync
with
the
releases
of
Machinery,
which
are
like
three
months
or
so
major
releases
and
the
rest
is
minor.
I,
don't
know,
okay
to
us
via.
H
Yeah,
so
through
two
thoughts,
one
of
them
is
I.
Think
we
already
my
hesitation
is
a.
We
already
have
our
plates
for
pulling
up
people
to
do
work
that,
for
this
one
doesn't
seem
like
kind
of
a
biggest
problem.
We
should
be
solving
right
now.
Putting
resources.
Second
point
is:
is
this
not
something
that
might
be
tackled
by
sick
testing
or
whatever?
That
could
be
sick
test
or
basically
Erik
fader
from
front
from
Google
and
and
to
see
if
they
can
do
it?
H
If
the
goal
truly
is
to
go
and
have
something
in
the
kubernetes
master
branch,
that
does
this,
then
it
seems
like.
Maybe
we
should
have
approached
them
and
saying
hey.
What
are
your
thoughts
on
this?
Do
you
have
any
plans
on
this
or
or
so
forth,
but
I
just
know.
We
are
super
physically
trying
to
get
the
beta
and
take
it
on.
Extraord
just
seems
sketch.
B
Cool
so
I
put
my
hand
up
I
want
to
share
my
take
my
hat
off
and
share
my
subjective
opinion.
Yes,
Doug,
as
Doug
said,
this
would
be
a
post
beta.
One
thing:
I
would
still
be
against
trying
to
boil
the
ocean
and
solve
this
for
everybody,
let's
figure
out
what
works
for
us,
and
then
we
can
suggest
something
else
upstream
to
either
sig
architecture
or
stake
test
collaboration,
but
we
can
bring
this
up
as
well.
We
could
even
bring
it
up
now
so
say,
GARCH
and
say
this
is
something
we're
struggling
with.