►
From YouTube: Kubernetes SIG Service Catalog 20170801
Description
- Parameters - blob support
- Token auth: opaque vs. OAuth
A
A
B
Right
so
I'll
give
my
standard
speech
the
beginning
of
all
of
our
meetings.
I've
got
my
high
tech
speaker
queue
equipment
here,
so
we're
gonna
just
go
through
our
discussions
as
normal.
If
you've
got
something
you
want
to
add,
please
type
in
the
comments
plus
hand,
I'll
put
you
under
the
queue,
I'll
a
queue
and
then
I'll
get
your
turn
in
when
you
are
up
in
the
queue
FIFO
order.
So
with
that,
we've
got
two
items
on
the
list
for
today
August
first
section
of
the
document
I
just
post
post
it
into
the
chat.
B
B
C
Okay,
so
I
completely
I
have
almost
finished
the
proposal,
for
instance,
parameters,
design
proposal
and
I
completely
overlooked.
One
use
case
when
we
don't
want
any
manipulation
of
the
parameters
just
want
to
send
the
entire
JSON
blog.
It
could
be
just
in
line
Jason
or
could
be
a
reference
to
a
secret,
key
or
config
map
key,
which
contains
the
entire
book,
and
this
question
is
about
how
do
we
want
to
implement
this?
C
C
A
D
Well,
that's
just
right,
so
the
library
were
using,
it
was
in
the
form
we
give
it.
The
schema
is
in
the
form
and
we
get
back
a
JSON
blob.
Basically,
so,
with
the
current
proposal,
it's
actually
quite
hard
for
us
to
say
position
go
out
and
put
it
into
the
new
format.
Ultimately,
the
service
catalogs
is
going
to
have
to
take
this
in
a
new
format
and
put
it
back
in
through
this
bar,
which
seems
like
a
lot
of
work.
When
we
have
the
exact
system
that
we
ultimately
want,
imanakum
poker.
D
So,
with
the
current
format,
it's
going
to
be
a
little
tricky
for
us
to
show
the
user
what
the
parameter
values
are,
because
we
basically
will
have
to
really
implement
the
same
logic
as
a
Service
Catalog
doing
and
ordered
the
murders
and
handle
all
these
various
pipes
and
then
under
update
I'm,
not
sure
we're
going
to
be
able
to
do
with
the
current
design.
Well,
how
big
of
brewing
fine?
D
D
B
C
Go
ahead
well,
the
use
case
makes
sense
to
me
and
I
think
that
we
want
to
support
passing
the
entire
parameters
blob
there.
The
question
is,
we
need
to
manipulate
it,
so
the
inside
Service,
Catalog
and
I
think
that
there
is
some
limit
to
it's
like
we
don't
provide
the
framework
to
like
do
any
arbitrary
manipulations
to
the
parameters
just
to
avoid
extra
work
on
the
user
side
and
the
next
question
whether
the
which
of
these
options,
you
think,
would
work
for
you.
C
D
So
I
I
wasn't
clear
on
how
that
works.
If
you
have
a
blob
and
then
you
also
have
named
by
you
pairs
that
they
were
going
to
be
merged
rinses
or
they
initially
were
sort
of,
ideally
like
as
a
client.
So
if
we
have
the
blog,
the
creation
scenario
is
pretty
simple
for
us
right.
We
just
say
here:
here's
the
digging
blog,
that's
all
we
needed,
but
some
of
the
update
scenarios
get
complicated
with
merging.
If
we
start
to
mix
these
different
strategies,
all.
D
A
A
A
What
is
the
forward
compatible
way
to
handle
the
80%
case
to
allow
us
to
reference
parameters
from
a
secret,
and
the
reason
that
that
is
special
is
that
secrets
are
an
escalating
resource,
so
we
we
definitely
need
to
have
a
way
to
reference
secrets
so
that
people
don't
have
to
put
sensitive
information
into
this
API
resource,
for
instance,
and
binding
and
I
think
that,
with
the
right
strategy,
we
could
do
something
that
would
be
forward
compatible
with
other
options
that
we
chose
to
add.
I.
A
Think
the
design
work
that
has
been
done
so
far
is
really
good
but
and
I
do
think
that
we
should
try
to
consider
whether
this
API
is
getting
too
complex
and
what
the
80%
use
case
is
here
and
I
will
say
just
for
the
record
that
the
environment
API
for
pods
is
something
I
have
spent
a
lot
of
time.
Working
on
in
kubernetes
I
totally
appreciate
the
impulse
to
try
to
solve
all
the
problems
at
once
and
I
feel
like.
That
is
what
the
group
has
wanted
to
do.
I
do
just
I.
A
D
C
C
Don't
want
to
I,
don't
want
by
sharing
anymore
I
would,
just
just
like
would
like
to
stick
with
some
initial
design,
probably
if
current
design
looks
good
enough
just
to
come
up
with
like
this
is
the
concrete
issue.
We
have
a
current
really
having
the
proposal
and
I
would
like
to
make
a
decision.
Whether
we
want
to
address
it
and
like
I,
have
wasted
three
options:
can
we
choose
one
or
proposed
any
other
one?
C
B
A
My
preference
would
be
I
do
not
think
that
we
should
throw
the
design
work
in
the
garbage.
I
think
that
the
I
think
there
is
value
in
having
the
type
of
API
that
we
do,
but
I
also
think
that
it
is
a
real
challenge
for
folks
building
user
interfaces
around
the
safety
I
or
that
will
and
so
I
would
be
in
favor
of
having
a.
A
We
could
here's.
What
I
would
suggest.
Let's
do
parameters
from
secret,
key
blob
ref
as
a
first
step,
and
we
can
implement
these
other
things
in
subsequent
pull
requests,
but
I
think
that
now
you've
really
hit
the
nail
on
the
head
with
your
statement
that
we
have
no
other
way
to
do
this
now
and
I
I
just
do
not
want
perfection
to
be
the
enemy
of
progress,
uf,
okay,.
D
I
just
wanted
a
way
in
quickly
like
I
I.
Don't
have
a
strong
opinion
between
these
three
except
I.
Do
I
would
like
to
be
able
to
put
them
blog
on
a
secret
suspect,
because
there
were
in
the
UI
we
don't
know
which
parameters
are
sensitive
or
not
right.
Give
him
the
the
current
service
for
respect.
There's
no
way
for
us
to
know
just
looking
at
schema,
so
we
have
a
blog
and
we
want
to
you
know
we're
kind
of
taking
the
posture
that
didn't
use.
D
C
B
A
So
I
think
we
could
just
call
it
secret
Kiera
and,
to
me
I,
think,
there's
a
implication
if
you
have
parameters
from
and
it's
a
secret
key
breath
that
there
are
multiple
parameters
and
that
they
are
in
JSON
format
and
I
would
also
support
as
a
sibling
in
a
parameter,
strung
Union
pipe
to
do
an
inline,
an
inline
that
was
just
the
same
convention
that
we
use
for
modeling.
The
raw
inline
parameters
now
and
I.
Think
that
would
solve
solve
the
problems
that
we
had
a
hand
in
a
forward
compatible
win.
C
Forgot
what
a
go
yeah
so
secret
key
RAF
I
agree
that
is
probably
okay.
The
only
concern
is
that
we
have
already
secret
key
RF
in
the
parameters
section,
and
the
question
is
whether
it
will
be
confusing
for
the
end
users.
What
was
the
difference
between
parameters,
secret,
key
RF
and
parameters
from
secret,
key
F.
A
Think
that's
a
fair
point.
I
I
I
do
think
that,
like
there
is
a
limit
to
the
specificity
that
you
can
have
in
the
names
of
API
constructions,
constructions
like
there's
a
limit
to
the
amount
of
information
that
you
convey
without
having
to
a
user
that
hasn't
read
the
doc
all
right.
So
I
think
that
it
is
okay
to
have
things
named
the
same
way
in
those
two
different
contexts.
As
long
as
we're
extremely
clear
in
the
documentation
that
they
are
different,
yo
f.
B
B
Okay,
so
I'm
gonna
put
as
an
action
item
in
the
August
1st
2017
section
under
the
first
bullet
point
that
we
are
going
to
settle
on
the
suggestion
as
it's
written,
let
me
remove
the
blob
the
suggestion
as
it's
written
right
now,
I
think
Nile,
since
it's
your
PR
or
do
you
object
to
implementing
that
in
your
PR
and
then
we're
gonna
call
that
PR
done
and
ready
for
review
without
subject
to
any
more
design,
discussion.
I,
don't
know
if
object,
okay.
Does
anybody
else
object
to
that
idea?
I.
B
Cool
that
is
good
progress,
so
now
I'll
write
up
that
action
item
in
just
a
second
I'll.
Also
note
that
it's
not
going
to
be
subject
to
any
more
design
discussion,
we're
gonna
be
able
to
do
a
straight
code
review
and
assuming
everything
is
okay
in
the
code
review,
we're
going
to
be
able
to
merge
that
with
that,
are
there
any
other?
B
C
So
currently,
the
design
proposal
states
that
in
case
there
are
any
conflicts
between
duplicate
parameter
names.
We
just
apply
a
priorities,
basically
saying
that
within
a
single
section
with
the
list
of
parameters.
If
there
is
a
conflict
with
the
names
we
just
applied
a
lot,
the
rule
last
right
wins
and
between
the
section
we
have
a
have
ruled
that
parameters
overrides
this
section
from
a
parameters
from
embassy
and
duck
has
been
concerned
about
that
and
actually
I
have
other
concerns
as
well
that
how
safe
it
is,
and
do
we
even
like?
Do?
C
A
So
in
the
environment,
API
for
pods
I
implements
the
precedence.
It
does
not
implement
fail-fast,
since
this
is
fairly
similar
to
that
API.
At
least.
We
could
see
it
going
that
way.
Long-Term
I
personally
think
that
we
should
implement
the
same
precedence
and
that
the
lit
be
last
most
thing
that
clears
a
particular
parameter
should
win,
which
is
a
rule
that
we
have
in
an
environment
with
the
qualification
that
individual
environment
variables
take
precedent
over
things
that
come
from
an
end
from.
C
What
both
Paul
said
that
is
correct
and
I
can
explicitly
taken
these
rules
from
environment
and
I'm
from
I'm
still
not
sure
if
this
is
the
way
to
go,
but
I
think
that
for
current
design,
it's
okay
to
just
say
that
like
we
do
it
this
way,
and
if
there
are
more
concerns
in
the
future,
we
can
just
apply
this
emerging
conflict
resolution
strategy
later
and
it
won't
be
breaking
the
API.
Most
probably
is
just
the
rules
how
the
implementation
works,
so
I
think
it
should
be
fine
address
this
separately.
B
C
A
B
A
B
Okay,
so
what
we
have
here,
I
here
suggestion
it
sounds
like
Niall
and
Paul,
and
you
guys
seem
to
be
on
the
same
page
that
we
can
do
prioritize
overrides
now,
similar
in
similar
implementation,
as
what
pod
environment
variables
do
that
we
can
also
add
fail-fast
later
with
an
opt-in
field
to
opt
in
to
fail
fast.
When
we
add
it
later
and
with
that,
we
can
move
forward
with
implementation
on
prioritized
overrides
now,
I
see
Niall,
you
put
a
plus-one.
B
Okay,
so
I'm
gonna
put
that
down
as
an
action
item
Nyles
since
you
brought
this
point
up,
I'm
gonna
put
it
as
an
actually
I'm
for
you.
If
you
want
someone
else
to
do
it,
please
bring
that
up
in
the
channel
sounds
like
you'll.
Do
it
great
I'll
put
the
action
element
for
you?
We
don't
have
any
more
items
for
August
1st
today.
Does
anyone
have
any
last-minute
objections
to
this
point
or
other
items?
They
want
to
add
comments,
questions
underneath
now.
You
got
a
hand
up
go
ahead.
I.
C
Just
seen
today
the
question
from
Billy
about
the
bureau
talking
health
support
and
the
question
was
whether
we
want
to
support
specifically
Bureau
tokens
or
have
a
arbitrary
authorization.
Headers
I
do
prefer
current
design,
but
I
just
wanted
to
raise
a
question
if
there
is
any
anyone
having
an
opinion
on
this,
do.
C
A
A
So
I
want
that
to
be
known,
I'm
agnostic,
on
what
the
the
ultimate
solution
that
we
go
for
is
I.
Think
we're
very
close
on
the
API
I
think
that
Billy's
objections
were
basically
about
the
name
that
we
chose
so
I
think
there
should
be
a
way
to
do
what
we're
planning
to
do
in
the
current
work.
Quest
that
is
to
set
the
authorization
header
based
on
the
value
of
a
secret
key
I.
A
Think
that,
based
on
my
understanding
of
the
issue
that
we
should
have
a
way
to
say
what
the
I'm
a
way
to
indicate
in
the
API,
what
the
first
particle
is
going
to
be
so
like
if
it's
Bearer
have
a
way
to
indicate
there.
If
there's
some
other
scheme
have
way
to
indicate
that
and
now
I
need
to
pass
a
lot.
C
I
think
that
the
idea
from
really
was
that
we,
whether
we
store
the
entire
header
somewhere
in
the
secret
or
we
have
like
two
fields-
one
is
like
prefix,
which
would
be
bearer
for
the
beer
talking
and
anything
else
for
other
use
case.
And
then
the
value
injected
from
the
secret
and
I
do
think
that
beer
took
in
cars
like
eighty
percent
of
the
cases
and
I,
don't
think
it's.
Actually.
C
Potentially,
there
will
be
more
other
authentication
algorithms,
which
don't
involve
authorization
header
at
all,
or
have
a
very
different
way
of
having
like
multiple
requests
or
anything.
So
I
I,
don't
think
that
we
really
need
support
for
arbitrary
authorization,
header
and
it
will
I,
don't
think
it
will
help
us
to
solve
much
more
use
cases
than
just
the
ER
token.
B
Got
it
okay,
so
now
the
summer
you
have
from
you
is
that
error
token
covers
about
eight
percent
of
the
cases
you'd
like
us
to
have
support
for
it
now,
and
then
there
was.
There
was
some
other
language
about
how
we
might
need
to
support
some,
not
necessarily
single
header,
based
schemes
later
anyway,
that
about
cover
it.
Yes,
correct:
okay,
alright
Paul,
you
got
a
hand
up
go
ahead,
so.
A
B
B
A
A
B
So
what
I
will
do
is
set
an
action
for
myself
bring
this
up
tomorrow
in
the
context
of
merging
this
now
merging
this
tomorrow
and
then
having
a
follow-up
discussion
on
how
best
to
add
other
header
prefixes
going
forward,
given
that
this
is
a
forward
compatible
change
in
novels
PR
is
everybody?
Okay
with
that
anybody
not
like
that.
A
B
For
sure,
okay,
we've
gotten
through
our
third
item,
I'll,
ask
the
same
question.
I
asked
before
we
started
a
mist
is
that
you
want
to
have
anything
else.
They
want
to
bring
up
talk
about
comment
on
anything
going
once:
okay
and
cables.
I
have
noted
your
point
here
about
feeling
being
in
a
different
time
zone.