►
From YouTube: Kubernetes SIG Service Catalog 20170727
Description
- Instance/Binding parameters deep dive
A
All
right
welcome
everybody
to
the
July
27
2017
edition
the
kubernetes
6n
this
catalog
today.
We're
gonna
have
some
ongoing.
We're
gonna
continue
the
ongoing
design
discussions
around.
What
do
we
need
to
do
for
beta
and
what's
the
right
way
to
do
the
things
so
I
don't
know
Aaron?
Were
you
gonna,
be
the
objective.
D
B
A
D
B
B
You
follow
me,
let
me
say
a
few
things
before
we
start
sure
muscle
memory-
yeah,
that's
okay,
no
worries,
so
you
guys.
Probably
everyone
already
noticed
that
there
are
items
for
July,
31st,
August.
First,
all
the
way
through
to
August
7th
those
result
from
the
action
items
from
yesterday
to
follow
up
on
certain
things.
B
You'll
notice,
though,
that
they
go
all
the
way
out
to
August
7th,
because
Doug
is
gonna
be
out
next
week
and
the
items
that
are
far
out
there
are
things
that
he
he
either
needs
to
be
here
to
introduce
or
reintroduce,
or
he
needs
to
be
here
as
part
of
the
discussion.
So
we
are
going
to
be
covering
at
least
those
things
in
the
future
design
meetings.
B
But
of
course
the
next
design
meeting
will
be
on
Monday,
July
31st
and
if
you
have
something
is
to
talk
about
in
that
meeting,
just
add
to
the
list
as
normal.
So
Jeff.
Thank
you
for
taking
notes
today.
We're
gonna
continue
doing
the
the
speaker
queue
so
for
anyone
who
wasn't
here
or
forgot,
if
you
have
something
you'd
like
to
contribute,
please
just
type
plus
hand
just
like
this
into
the
chat
and
I'll.
D
B
D
D
D
So
I
have
listed
them
here,
so
one
is
the
least
support
by
having
a
way
to
support,
to
specify
more
than
one
source
of
information.
Another
is
merging
strategy
for
emerging
different
sources,
all
together
to
give
the
final
Jason
and
another
is
ease
of
use
for
most
common,
simple
use
cases,
and
during
this
discussion
we
have.
We
have
had
I
think
three
different
proposals,
slightly
changing
the
current
proposal,
but
it
still
wasn't
good
enough
and
in
the
end
we
came
back
to
the
I
think
this
is
well.
D
This
was
one
of
the
initial
ideas
in
the
instance
prior
to
support,
at
least
in
the
issue,
taking
the
approach
from
environment
from
and
trying
to
apply
to
instance,
parameters,
and
it
had
a
bunch
of
limitations
like,
for
example,
no
way
to
distinguish
string
from
JSON.
There
was
some
other
stuff
again.
It
was
mostly
about,
like
in
variable
environment
rate,
will
suggest
my
upfront
string
to
string,
and
we
need
something
more.
We
need
to
be
able
to
express
string
to
JSON,
basically,
and
this
time
we
have
tried
to
solve
this
problem.
D
So
we
have
name
field
type
which
is
optional
by
default
string,
but
you
can
specify
jason
and
maybe
in
the
future,
cut
something
else,
and
then
the
value,
and
this
way
we
can
express
basically
any
structure
we
want,
and
the
emergence
strategy
will
be
exactly
the
same
as
with
environment
variables
and
for
they
can
solution.
For
example,
environment
from
implementation
says
that
values
are
more
important
than
the
values
from
sources.
What
direct
values
and,
in
case
of
any
conflict,
the
last
well
value
means
there
is
no
error
or
exception
or
anything.
D
And
if
we
just
follow
these
rules,
I
think
it
should
be
pretty
easy
for
the
users
to
understand
how
to
use
it.
And
this
is
the
example
of
specification
which
allows
us
to
basically
express
any
kind
of
information,
both
sensitive
and
non
sensitive
taken
from
in
line
and
taken
from
whether
config
map
or
secret
or
secret
key,
and
there
are
two
different
sections
parameters
and
parameters
from
first
is
to
express
separate
fields
and
parameters
from
is
to
inject.
D
E
D
E
B
A
The
first
thing
I
wanted
to
say
is
that
a
jephthah
zoom
window
that
has
people's
video
on
it
is
flickering
very
rapidly
and
consistently
yeah.
There
we
go
second
I
think
that
I
had
misread
actually
that
proposal,
so
I
realized
that
after
I
typed
in
that
I
had
my
hand
raised,
I
will
think
yeah.
Let
me
think
someone
else
can
talk.
Sorry
about
that.
B
So
since
there
are
no
hands
up
I'll
throw
in
a
note
here,
I
have
notes
written
yesterday.
I
believe
by
was
Doug
was
a
note
taker
I
think
yesterday,
some
someone
seems
to
have
said
that
we
should
discuss
merging
strategies.
Another
time
and
I
set
up
a
call.
One
of
my
actions
was
to
set
up
a
call
to
discuss
merging
strategies
later
and
that
is
scheduled
for
August
3rd,
which
is
the
first
day
that
Doug
is
back.
So
there's
just
a
note.
Note
that
that
happens,
that
will
happen
on
August
3rd.
D
Go
ahead
and
yell,
so
yes,
this
this
is
true
about
Doc's
concern
was
once
we
merged
current
proposal.
It
becomes
income
incompatible
with
other
design
proposals
and
he
wanted
to
finalize
the
design
first
before
making
any
changes
merged-
and
this
is
this
was
the
initial
idea
and
yeah.
It
turned
into
completely
redesigning
whole
proposal.
Okay,
Paul.
B
A
For
the
record,
I
accept
your
apology.
Aaron
you'll
have
to
you'll
have
to
send
me
your
address,
so
I
can
send
your
receipt
to
you
all
right.
So,
having
had
a
chance
to
think
about
it,
I
had
some
questions
about
like
the
details,
so
I
think
it
might
be.
Okay,
so
I
have
a
few
I
guess:
I
have
a
few
corner
cases
so
say
that
we
have
in
the
parameter
section
we
define
a
value
for
parameter
food
and
then
I,
one
of
the
parameter
from
things
say.
A
D
So,
yes,
it's
a
merging
team
and
environment
variables
has
already
a
strategy
for
this
and,
as
far
as
remember,
they
say
that
any
value
taking
from
sources
is
being
overridden
by
directly
in
line
injected
value.
If
there
is
a
conflict
and
if
there
are
multiple
sources,
conflicting
with
each
other
or
multiple
in
line,
maybe
as
well
conflicting
with
each
other.
The
last
item
in
the
list
winds,
so
he
looks.
B
D
A
D
D
A
I
think
there
are
probably
some
facets
of
what
the
right
exact
API
construction
is,
but
before
we
talk
about
those
I
am
wondering.
What's
the
algorithm
for
dealing
with
a
value,
that's
supposed
to
be
raw
JSON
I
would
imagine
that
it
would
be
to
take
the
data,
that's
in
whatever
the
sources
and
to
have
a
to
treat
that
as
JSON
deserialize
it
into
a
map.
A
D
D
Basically
it
is
basically
a
duck
typing,
and
if
someone
wants
to
pass
it
as
a
string,
not
as
a
JSON
with
we
can't
do
this
and,
for
example,
if
someone
passes
a
value
of
string
with
the
text,
true,
we
can
think
of
it
as
a
bad
boolean
and
pass
it
as
a
as
a
like
row
value
right.
But
then
the
user
won't
be
able
to
pass
through
as
a
string
which
some
broker
could
only
accept
so
I
I
would
prefer
to
be
explicit.
Oh.
E
A
A
Somehow
in
the
spec
by
the
spec
I
mean
it
has
to
be
explicit
in
the
API,
whether
you
should
treat
the
value
as
a
string
or
as
a
as
JSON
and
I
I
think
we
do
agree
on
that
facet,
I'm,
not
sure
if
we
necessarily
agree
on
what
the
right
API
construction
is,
but
if
we
agree
that
it
should
be
explicit,
we
can
perhaps
start
talking
about
what
the
right
API
construction
is.
Okay,.
B
A
D
B
F
B
A
Yeah
I
was
gonna
suggest
that
the
issue
is
great
for
the
record.
I
am
the
creator
of
the
environment
variable
API
constructions
in
the
core
for
this,
and
it's
very
complicated
I
think
that
I
think
that,
following
those
kind
of
semantics
and
having
consistency,
there
is
really
good.
But
it's
complicated
enough.
That
I
think
it
would
be
great
to
have
somebody
write
up
a
proposal
document
that
outlines
all
these
behaviors
then
that
we
can
further
get
agreement
on
because
they
are
very,
very
complex
before
we
start
writing
code
and
I'm.
A
Sorry
and
all
that
you've
already
started
writing
code
on
it.
But
experience
shows
me
from
basically
doing
the
same
problem
in
the
core
that
the
semantics
are
much
more
difficult
to
pin
down
than
you
might
think,
and
they're
very
much
past
my
threshold
for
something
that
I
think
that
we
should
write
down
and
like
a
design
document.
D
I
can
start
writing
this
document
as
a
separate,
correct,
er,
I
guess
if
we
want
this
finally
get
merged
as
a
separate
document
in
our
report,
repo,
then
yeah
I
think
this
is
good
work
so
about
the
examples
here.
I
was
going
to
say
that
like
I
have
a
PR
in
progress
which
we
can
take
a
look
at
just
like
how
the
mechanics
work
here,
but
yeah
I
think
proposal
works
as
well.
G
A
I'm
trying
to
think
of,
if
there's
a
single
place
to
point
you
I,
can
definitely
point
you
to
where
the
types
are
specified
in
the
core,
but
the
design
work
since
we
kind
of
organically
did
this
over
many
different
features
was
spread
out
over
numerous
different
proposals.
So
I'll
do
what
I
can
to
find
those
for
you
and
I'll
definitely
link
you
to
where
the
types
are
specified
in
the
core.
A
I'm
not
I
think
if
we
have
consensus
on
this
general
direction,
we
don't
necessarily
have
to
give
it
another
treatment
in
a
design
meeting.
We
I
guess
we
can.
If
there
are
some
things
that
we
find
especially
difficult
to
talk
through
on
github
but
I'm,
fairly,
confident
that
Nala
can
put
together
a
bulletproof
proposal
and
will
shred
any
doubts
that
folks
have.
B
A
B
B
B
B
B
D
E
B
D
B
D
With
the
third
I
think
it's
still
we
could
we
can
slightly
discuss.
Is
that
a
current
implementation
of
parameters,
support
instance?
It's
got,
has
a
field
called
parameters
and
I
have
no
idea
how
to
correctly
handle
this
situation
if
we
want
to
support
backward
compatibility.
So
what
if
the
new
field
is
called
alpha
parameters,
then
at
some
point
we
ditch
the
program
and
we
have
to
rename
back
from
around
us
to
parameter
store.
I,
don't
understand
the
mechanics.
D
B
A
We
have
consensus
around
this
stuff
and,
since
our
consensus
is
towards
a
direction
that
we
can
add
new
things
in
a
backward
compatible
way
to
me,
that's
good
enough
to
break
and
compatible
incompatibility
with
the
existing
API,
which
is
itself
alpha
and
I
only
ask
that
we
give
people
advance
notice,
which
I
said
I
would
do
as
a
takeaway
yesterday,
once
we
had
some
consensus,
so
it
might
be
time
to
say
heads
up.
We
know
that
this
API
surface
is
going
to
change.
A
Going
on
I'm,
sorry
that
that
wasn't
what
I
thought
we
were
talking
about,
I
thought
we
were
talking
about
wholesale,
just
changing
the
semantics
of
the
parameters
field.
Oh
but
you're,
not
you're,
not
suggesting
remove
it
and
I
said
so.
The
existing
field
is
called
parameters
and
I
think
we
have
a
design
consensus.
That
Neal
is
gonna,
go
right
up
and
once
I
mean
at
this
point,
I
think
we
know
the
API
is
gonna
change.
A
A
Once
it's
imminently
going
to
go
in
okay
and
we'll
give
people,
maybe
a
week,
I
think
I
think
by
the
time
the
proposal
is
finished,
we'll
have
enough
clarity
on
what
it's
going
to
go
in
that
we
can
give
people
a
week's
advance
and
say
it's
gonna
change
on
this
date
be
prepared.
So
once
we
get
to
that
point,
we'll
send
additional
advance
notice.
That
does
that
make
sense.
F
I
said
two
points:
one
of
them
is,
it
seems
like
there's
a
few
few
of
these
fields
and
or
resource
names
that
we
are
planning
on
changing,
so
I
wonder
if
it
makes
sense
to
go
ahead
and
spend
a
little
time
looking
at
seeing.
Are
there
any
additional
fields
that
we
think
might
be
changing
at
this
point
and
then
maybe
sending
a
note
to
list
saying?
F
Okay,
if
it
turns
out
that
it's
only
that
resource
names
and
the
parameters
then
send
a
note
saying:
hey
here
are
changes
that
are
coming
heads
up,
but
I
think
it'd
be
useful
to
go
ahead
and
look
at
a
few
different
fields
as
well
and
see
do
we
think
they
are
and
then
maybe
change
them
to
alphas
or
whatever?
Now,
rather
than
later,
and
as
far
as
as
far
as
I
forget,
who
it
said,
do
we
want
to
keep
on
making
iterative
changes?
I
think
it'd
be
better
to
go.
D
My
question
was
whether
weather
really
proposes
to
make
an
EM
announcement
as
I
like
a
single
document
or
to
make
all
VPR's
merged
at
the
same
time,
because
I'm
a
little
bit
concerned
about
getting
everything
merged
at
the
same
time,
because
it
means
if
there
is
one
feature
which
is
still
not
implemented.
We
will
have
to
wait
until
it
is
done.
Yeah.
F
I
was
I
was
thinking
about
sending
a
notice
out
simply
because,
if
somebody
misses
a
particular
announcement
or
whatever
else,
they
won't
see
it,
whereas
if
there's
a
big
one
with
the
using
HTML
tag,
every
place
pleasure
making
sure
that
everybody
sees
this
announcement
and
there's
an
easy
way
to
track
them.
I
wasn't
proposing
doing.
F
B
B
Okay,
any
other
comments.
Questions
concerns
is
about
just
generally
instance,
parameters
or
more
to
vilas
point
about
fields
in
general.
During
our
alpha
releases,
yeah
I
had
my
hand
up
sorry
Paul,
so
I
did
I
hold
on.
What's
like
now
did
I
get
you
already
I
apologize
I.
Think
I
did
okay,
go
ahead,
Paul
yeah.
A
So
I
definitely
second
delay
of
what
I
think
your
assertion
was
that
we
should
try
to
make
as
few
breaking
changes
as
possible.
I
I
think
that
means
that
we
should
be
very
smart
about
how
we
plan
changes
that
will
that
will
break
and
and
plan
the
release
that
they're
going
to
be
in
so
like,
for
example,
I
think
we
all
expect
resource
names
to
change,
we're
definitely
going
to
change
this
field.
A
I
think
that
it
would
be
best
to
try
to
batch
them
into
the
same
release
so
that
we
have
as
few
releases
as
possible
that
we
have
breaking
changes
in
I'm,
not
sure,
if
I'm
not
sure,
if
I
think
that
renaming
fields
to
indicate
that
they're,
specifically
alpha
is
going
to
do
more
good
than
harm.
But
we
can
definitely
discuss
that
as
a
separate
thing.
D
Okay,
now
go
ahead
yeah.
My
question
was
about
the
binding
parameters,
so
I
think
we
have
mentioned
before
that
and
Doug
has
asked
me
in
in
DPR.
Why
I
didn't
do
it?
I
didn't
I.
Do
this
already.
So
if
we
change
the
instance
parameters
to
make
it
more
flexible,
it
could
be
beneficial
to
make
binding
credentials
output
flexible
as
well.
It's
not
going
to
be
the
same
type.
Obviously,
because,
like
we
have
different
semantics,
but
if
we
want
to
make
this
change,
we
can
do
that.
D
I
would
prefer
to
keep
this
change
separately,
but
if
we
say
that
like
we
want
to
have
similar
features
to
be
released
at
the
same
time,
we
can
start
discussing
this
as
well,
but
I
think
that
we
have
already
hijacked
like
several
discussions
on
this
instance.
Parameters
and
I
would
prefer
to
keep
it
a
bit
for
offline
discussion
in
the
issues
and
cars.
A
Okay,
Paul,
okay,
so
I
think
I
think
there
are
two
different
facets
here:
that
we
should
be
really
explicit
about
teasing
out
so
bindings
also
have
parameters
and
I
think
that
when
we've
been
having
this
discussion,
we're
really
agreeing
on
what
is
the
general
purpose:
API
construction
for
specifying
parameters,
two
things
and
that
for
input
parameters,
two
bindings,
that
we
should
just
use
the
same
API
constructions.
Does
anybody
disagree
with
that.
A
B
A
B
So
this
sounds
like
a
pretty
good
decision.
Point
I
will
verbalize
the
decision
here
and
ask
if
anyone
has
objections,
so
the
decision
I've
heard
is
we're
going
to
Nile
you're
gonna
write
up
a
proposal
and
design
document
in
a
PR.
For
how
generally
we
deal
with
input
parameters
to
instance
and
binding
once
we
have
consensus
there,
and
everyone
agrees
on
that
design.
We
will
then
implement
it
for
both
instances
and
bindings.
B
Put
your
hand
up
in
the
chat.
If
you
do,
could
you
repeat
that
sorry
so
step?
One
nyle
will
write
a
proposal
and
design
doc
on
how
input
parameters
work
for
binding
an
instance
step
two
we
get
everyone
bought
into
that,
so
we
make
changes
as
necessary
so
that
everyone
agrees
and
step
three.
We
submit
one
PR
to
implement
that
design
for
binding
parameters
and,
for
instance,
parameters.