►
From YouTube: Kubernetes SIG Service Catalog 2018-08-13
Description
moving to kubernetes-sigs
positional vs named args in svcat cli
feature-gates
B
C
A
E
Right
hello
and
welcome
everyone
to
the
Argos
13th
meeting
of
the
kubernetes
sig
service
catalog.
If
you
would
like
to
follow
along
and
take
a
look
at
our
agenda,
I
just
pasted
it
into
our
group
chat.
I'm,
just
gonna
walk
through
what
we
have
on
here
so
far.
If
there's
something
that
you'd
like
to
talk
about,
that
isn't
on
here
feel
free
to
just
check
them
out
into
the
end
otherwise
Morgan.
The
first
thing
on
the
agenda.
Is
you
giving
people
secret
launch
codes
so
about
that
get
into
zoom
when
you're
busy
yeah.
D
Sorry
I
was
I
was
distracted,
I
was
I
was
just
somebody
who's
telling
me
there
were
rats
chewing
on
their
car
anyway
about
this.
These
are.
This
is
an
account
that
I
got
from
Paul
and
I.
Don't
you
know
I,
don't
know
if
I
mean
I'll
share
it
I
just
I'd
like
to
get
either
clearance
from
Paul,
or
you
know,
okay,
that
these
are
the
chairs
codes
or
whatever,
because
I
don't
want
to
I
want
to
accidentally
expose
something.
Oh
okay,.
E
D
F
Sure
so
last
week,
Aaron,
Creek
and
burger
came
in
to
ask
if
we
were
going
to
move
to
Caretti
cigs
anything.
This
is
like
the
second
time
or
at
least
not
the
first
time
this
has
been
discussed.
They
said
that
it's
not
written
down
and
official
yet,
but
it
probably
will
be
soon
so
I
guess.
The
first
question
is:
does
anybody
have
any
reservations
about
us
starting
that
process.
A
F
F
F
F
F
F
F
C
C
E
Yeah
I
know
I
mean
I
just
want
to
caution
that
in
general,
with
the
kubernetes
SIG's,
let's
make
sure
that
when
we
move
over
it's
at
our
own
pace
and
not
yeah,
other
interests
have
been
doing
this.
But
the
lack
of
guidance
means
that,
like
it's
pretty
likely
that
when
we
switch
over
it'll
break
stuff
for
a
little
bit
and
we'll
need
to
have
people
on
hand
to
kind
of
like
go
back
and
forth
and
get
something
fixed.
So
we
can
do
our
best
to
plan
it
out.
Yeah.
F
So
this
one
go
ahead
and
click
that
that
issue.
So
in
the
comments
on
this
issue,
there
was
some
discussion
about
whether
we
were
going
to
move
away
from
position
are
from
named
arguments
towards
positional
arguments
and
Carolyn
and
Jay.
Don't
remember
there
being
discussion
at
the
face-to-face
and
Jonathan
said
there
was
so
we
felt
like
the
best
course
of
action
was
to
come
back
and
discuss
it
here
again,
just
to
get
a
final
resolution,
and
then
we
can
include
in
the
meeting
notes
here.
G
Can
speak
to
that
if
you
want
yeah
go
for
it,
okay,
we're
trying
to
determine
how
to
best
use,
positional
arguments
and
flags
and
espy
cat.
So
for
positional
arguments.
That
would
be
say
if
you
say
SP,
cat,
foo
and
bar,
where
like
foo
are
you
know
the
information
you're
supplying
to
svk
a
flag
would
be
something
when
you
say
like
SP
cat
food
class
bar,
so
that
is
the
flag.
G
G
I
would
like
to
put
forth
proposal
to
move,
to
remove
mandatory
flags
and
switch
those
to
positional
arguments.
So,
instead
of
having
to
throw
that
class
room
name,
you
would
just
say
SP
cat
provision,
instance
name
class
name
plan
name
and
that
you
would
always
have
to
specify
those
arguments
in
that
exact
order,
and
my
reasoning
behind
this
is
that
mandatory
Flags,
don't
like
they
go
against
UNIX
command
line
convention
and
I
would
like
for
our
tool
to
fit
in
with
other
UNIX
command
line
tools.
E
G
E
E
Okay,
so
this
is
this
is
how
SV
cat
works
today,
when
there
are
positional
arguments,
there's
just
one
and
it's
the
name.
The
reason
why
I
originally
went
down
that
path
is
that
that's
how
keep
C
tail
works
so,
for
example,
keep
CTL
run
name.
An
image
was
actually
required
flag
and
then
the
other
reason
why
I
went
down
that
path
is
because,
as
you
add,
more
things
beyond
just
one
or
two,
it
becomes
a
little
harder
to
understand.
What
is
the
right
order
every
time.
A
E
G
E
When
I
made
SP
cat,
that
was
the
reasoning
behind
it.
So
let's
say
that
we
had
so
that's
what
it
was
like
the
example
like
background
on
why
this
is
what
I
was
just
trying
to
get
at,
so,
if
I
type
in
this,
they
want
to
be
able
to
create
a
plan
which
is
something
that
is
in
the
works
down
the
pipeline.
If
we
don't
have
required
flags,
it
would
look
like
this
versus,
as
we
can't
plan
name
class.
E
B
B
E
Bigger
so
with
flags
we're
given
a
place
to
put
in
extra
information,
anything
that's
required
gets
flagged
as
required,
or
something
like
that,
but
for
positional
arguments
we
basically
just
have
usage
or
this
description
fields,
but
we
don't
have
like
a
nice
defined
places
to
put
it
I'm
explaining,
like
that's,
why
I
went
down
the
path
I
did
and
I'm
concerned
that
if
we
add
things
more
interesting
than
what
with
the
issue
in
question
as
we
can't
is
it
registered,
then
we
have
like
meme.
You
are
all
versus.
E
Let
me
know
if
I'm
getting
this
wrong.
It's
just
off
of
my
top
of
my
head
like
this.
Is
the
wanting
question
like
this:
it's
not
that
that
is
worries
me.
So
much
as
like
this
one,
remembering
like
the
order
of
these
things
is
more,
are
required.
I
mean
honestly
I
would
imagine.
People
may
fall
back
to
gamal
at
this
point,
but
I
just
like
to
be
consistent
with
it.
So
there
you
go
I
just
want
to
type
up
what
we
were
all
talking
about.
A
There
are
required
arguments
which
is
kind
of
funny,
but
the
ones
that
I
did
come
across.
They
all
follow
that
pattern
of
you
know
the
it's
a
required
parameter.
There
isn't
a
flag
necessary
to
put
in
front
of
it.
Provisional
things
seem
to
be
just
fine
for
people.
I,
don't
see
the
value
in
requiring
flags
to
be
in
front
of
things.
It's
just
it's
just
extra
typing
and
extra
noise.
To
be
perfectly
honest,
I.
G
A
B
E
B
E
E
A
E
D
G
I
would
propose
that,
regardless
of
what
the
outcome
of
the
vote
is,
we
be
consistent,
so
were
flags
to
win.
Would
you
be
amenable
for
that
option
to
be
a
sv
cat,
registered
name
name,
URL
URL,
because
it,
it
seems
confusing
to
me
to
have
some
things
be
one
way
and
other
things
be
another.
Oh
you're.
A
E
A
He
was
asking
in
general,
it's
a
very
inconsistent
rule
to
me
and
that's
one
of
the
reasons
that
kind
of
bothered
me
when
I
first
came
across
coop
control.
It's
like
as
I
think
maybe
was
Jeremy
in
there
say.
Cou
control
is
kind
of
both
it's
like
well,
that's,
either
the
best
or
worst
of
both
worlds,
depending
which
way
you'll
get
it
right.
A
E
G
E
A
E
A
C
E
C
E
C
Okay,
your
screens
still
in
the
scratchpad
I
thought
this
was
about
the
feature
gates.
Alright,
so
I'm
doing
a
pull
request
enabling
originating
identity
to
be
on
by
default
and
I
was
creating
a
block.
Page
and
I
have
an
agenda,
a
link
to
the
kubernetes
dock
page
on
feature
gates.
I
thought
it
was
a
good
one.
I
started
pulling
over
and
using
it
for
Service
Catalog
documenting
our
current
features,
putting
the
the
tables
in
that
indicate
when
we
added
the
flag
that
kind
of
thing.
C
So
this
there's
a
nice
layout
here
they
basically
talk
about
three
types
of
fiji
gates,
alpha-beta
or
if
it's
GA
I,
don't
know.
If
we
want
to
talk
about
alpha
and
beta,
because
we
really
haven't
been
following
anything
with
you
know
and
generally
they
want
to
see
flags
go
from
alpha
to
beta
to
GA
and
several
releases
expire
between
the
settings.
It
doesn't
indicate
any
requirement,
for
you
know
two
releases
or
six
months.
Strength
like
that
and
I.
C
Don't
know
that
we
need
to
but
I
just
try
and
put
some
wording
around
this
and
I
thought
this
was
a
good
start.
Maybe
doesn't
matter
I
can
I
can
put
what
you
know
what
they
listen
upstream,
but
I
kind
of
wondered
if
we
just
want
to
go
with
a
alpha
or
beta
and
a
ga
flag
versus
alpha
beta
GA
that
make
any
sense.
C
Now,
that's
fine,
so
they
list
that
flags
are
generally
they
put
in
in
an
alpha
state
they're
about
what
alpha
is.
You
know
it's
experimental
that
kind
of
thing
in
beta.
They
say
it
should
be
safe
to
turn
on
in
the
in
a
production
cluster.
But
you
know
we
read
about
it
and
then
GA
is
you
know?
Generally
you
see
the
flags
go
from
false,
the
default
being
false
and
then,
by
the
time
you
hit,
the
flag
is
redefined
to
be
true.
Okay,.
E
G
C
E
C
E
C
C
It's
sitting
here
trying
to
resolve
one
thing:
I've
got
some
unit
tests
started
exploding.
Once
I
said,
originating
identity
was
defaulted
to
true,
anyone
knows
cut,
it
seems
to
me
the
context
should
be
required,
do
user
context
and
we've
got
unit
tests
that
have
nil
set
for
the
the
context
and
as
soon
as
you
start
saying,
originating
identities
on
it
wants
to
populate
the
context
with
the
or
wants
to
populate
get
pull
out
the
user
from
that
from
the
context,
and
the
context
is
nil,
it
just
blows
up
I
think.
A
C
Thanks
Doug,
so
it's
really
simple
to
add
the
context
to
the
unit
test.
But
then
I
got
concerned
from
some
of
the
comments.
Now,
let's
go
back
through
it
a
little
more
carefully
one
or
two
comments
indicated
that
if
the
user
didn't
specifically
set
who
they
were,
but
that
didn't
I'll
spend
a
lot
more
time
with
it
and
get
some
get
some
advice.
If
I
need
to
Thanks
sure
I
think.
C
E
All
righty
Jeremy
had
to
leave
any
next
time.
He
said,
he's
gonna
record
a
demo
for
us
using
namespace
broker
resources,
in
addition
to
catalogue
restrictions
to
kind
of
show
off
some
stuff
that
we
had
asked
for
from
our
own
customers
to
the
show
how
it
works,
and
so
he
was
gonna
demo
that
for
them
and
figured
he'd
done
with
that.
For
us,
too,
are
people
interested
in
that
yeah.