►
From YouTube: Kubernetes SIG Service Catalog 20171009
Description
- Discussion of whether to cut beta release candidate
A
B
A
Billy
and
I
were
kind
of
chatting
in
the
course
of
talking
about
some
other
poll.
I
think
it
was
maybe
last
week,
sometime
and
I
think
as
we
go
through
this,
we
should
identify
which
things
ought
to
be
moved
out.
This
is
probably
a
superset
of
what
actually
we
need
to
to
ship
an
initial
beta,
and
so,
let's,
let's
talk
about
each
of
these
things
and
see
if
some
of
these
things
ought
to
be
moving
all
right.
A
D
A
A
A
E
E
E
A
A
So
I
I
did
not
say
that
that
would
be
backward
incompatible,
but
we
don't
want
to
remove
it
because
if
you
have
existing
plans
or
if
you
have
existing
service
instances
of
these
things,
then
you've
got.
Then
you
got
like
instances
that
you
can
like
look
and
see
what
they
refer
to.
So
this
is
part
of
the
previous
consensus
that
we
have,
which
is
similar
to
what
Claude
ponder
does
where,
if
you?
A
A
D
Yeah
I
I
remembered
the
consensus
before
I'll
just
cut
to
the
chase.
What
I'm
trying
to
say
is
the
beta
is
like
two
weeks
later
so
from
what
we
said:
we're
gonna
release
so
I'm
looking
to
aggressively
cut
what
we
can
cut.
This
seems
like
it's
a
good,
a
good
candidate
for
something
to
cut.
So
that's
it
for
me.
A
Okay,
well,
as
I
said
I'm
about
30
minutes
to
one
hour
away
from
submitting
a
pull
request
for
it.
I
don't
think.
That's
gonna
appreciate
appreciably
change
the
time
that
we
can
cut
a
release
candidate
in
I
think
we
can
still
cut
one
tonight
but
I'm
happy
to
sit
on
this.
If,
if
other
folks,
object--.
A
A
A
Okay,
I
think
this
one
can
so
my
own
personal
opinion
about
this
is
that
I
think
this
one
can
stay
in
I.
Think
it'll
make
it
much
easier
to
debug
things
when
users
are
using
this,
it
does
not
mean
that
we
have
to
delay
cutting
a
first
release
Canada,
so
I'd
prefer
to
keep
this
one
in.
Of
course,
that's
just
me
curious
to
know
what
other
people
think
all
right,
Aaron.
D
A
A
A
A
So
I
think
that
we
should
cut
a
release
candidate
tonight.
I
think
that
that
should
happen
after
the
poll
that
I
make
is
merged.
I
think
we
can
continue
making
fixes
and
polishing
things
like
log
messages
and
obviously
fixing
bugs
I
do
not
think
that
what
is
in
master
tonight
has
to
be
what
we
ship,
because
we're
still
gonna
have
some
like
tweaks
and
stuff
going
in,
but
I
think
that
we
should
try
to
cut
a
release
candidate
tonight
and
I.
D
D
A
Just
one
quick
question
and
I'm:
sorry:
if
this
has
been
addressed
and
if
I've
missed
it
somehow,
but
as
part
of
the
release
process,
are
we
planning
to
release
the
helm
chart
into
a
helm
repository
somewhere
like
the
kubernetes
charts
for
posit
or
e
well
Kent?
My
recommendation
to
you
is
to
gather
up
your
little
horses
and
hold
them,
because
we've
got
an
issue
for
that
to
discuss
in
this
list.
Okay
sounds
good
all
right,
okay,
so
this
one
using
an
unsupported
field.
Selectors
should
return
an
error.
A
A
A
G
A
That's
okay,
Chris
market.
If
you
get
it
done,
if
that's
great,
we'll
ship
it,
but
we
do
we're
trying
to
make
sure
that,
like
the
stuff
that
is
is
kind
of
icing
on
the
cake
like
is
pushed
out
to
another
release,
so
there's
kind
of
a
like
I,
don't
think
anybody's
gonna
die.
If
this
doesn't
go
in
to
ODOT
1.0,
I
would
love
it
if
it
did,
but
I
also
don't
want
you
to
feel
like
you've
got
to
work
night
and
day
to
get
it
done.
You
know
what
I
mean.
A
The
way
that
you
add
those
is
you
put
into
the
client
set
directory
a
file
called
resource
name,
underscore
expansion
go,
and
we
have
this.
We
have
this
make
target
that
removes
all
of
the
generated
code.
It's
written
in
such
a
way
that
it
will
just
basically
blast
that
entire
directory,
which
now
will
catch
code
that
isn't
generated
I,
wish
there
is
another
place
that
we
could
put
it
there
isn't.
H
Know
I,
don't
write,
plus
hand
axe,
so
I
was
trying
to
be
a
good
citizen,
not
a
renegade
like
you,
so
so
yeah.
So
basically,
there
was
the
chunk
of
code.
That
was,
you
know,
you
know
dead,
blog
or
basically
in
the
wild
one
rope
and
it
basically
host
our
Jenkins.
This
was
a
week
ago,
Monday
file,
Niall
and
I
were
looking
at
something
anyways
and
Jenkins
happily
kept
on
trying
to
test
it.
H
So
I
think
what
we
should
do
is
two
kinds
of
crime
on
one
of
them,
which
is
to
go
ahead
and
burn
upper
bound
on
how
long
a
given
P
R
will
lock
jenkins
up
for
one
thing
so
that
people
actually
get
some
feedback
and
the
second
one
is.
We
should
also
have
test
timeouts
in
our
tests
so
that,
if
some
things
don't
happen
in
reasonable
on
time,
we
we
error
those
tests
out
again
to
go
and
get
more
information
back
to
the
user.
C
A
I
I'm
just
gonna
say
it's
about
ready
fathers
last
thing
holding
me
up
on
this.
Is
the
unit
tests
for
these
field.
Selectors,
it's
just
it's
messy
and
I.
Don't
know
that
makes
much
sense.
I
can
thingy
afterwards,
but
I.
Just
I,
don't
don't
think
I
agree
with
doing
unit
tests
on
these
that
we
can't
pass
cleanly
with
the
field
selector.
A
A
D
A
A
A
They
do
not
show
all
of
the
API
features
and
they
are
a
good
place
to
have
things
that
show
different
API
features.
This
could
be,
you
know,
dot
one
dot,
one
candidate.
This
is
also
a
really
good
starter
one.
If
someone
wants
to
make
make
make
a
contribution
for
the
first
time,
I,
don't
think
it
should
block
beta
and.
A
A
C
C
H
A
It's
it's
fairly
easy
to
tack
on
it
made
like
I
I
could
live
with
tagging
it
on
to
my
current
pull
request
and
we
kind
of
release
candidate
tonight
anyway.
I
do
think
it's
important
that
we
kind
of
release
candidate
tonight
I'd
be
happy
to
do
it
like
honestly.
If
people
wanted
in
before
the
release
candidate
I'll,
add
it
and
I'll
just
work
late.
C
A
Now,
I
think
that
you
could
create
them
with
the
different
external
name
and
it
would
be
a
I,
don't
think
there
are
any
ordering
guarantees
are
the
order
of
lists
as
they're
retrieved
from
the
API
server,
so
I
think
it
would
be
anybody's
guess
it
would
be
non-deterministic
which
one
you
actually
got
resolved
to.
Okay,.
C
D
Okay,
Aaron
you're
up
yeah,
so
I'll
tackle
this
in
order.
I,
don't
think
it's
necessary
for
the
rc4
sure
if
it,
if
it's
going
to
be
fixed,
that
I
also
agree
with
Niall
should
be
in
a
separate
PR,
also
Paul,
no
need
to
work
late,
I
think
also.
This
does
not
need
to
be
in
beta.
This
is
a
bug
if
there
is
a
non-deterministic,
a
non-deterministic
behavior
here,
that's
what
betas
for
it's
the
fixed
bugs
good
belay
you're
up
yeah.
H
I
didn't
mean
to
imply
that
you're
gonna
go
and
do
it
anyways
that's
been
discussed,
meaning
I
don't
mean
to
being
a
huge
PR
to
address
everything
yeah.
It
seemed
like
we
could
tackle
this
in
the
same
PR
simple,
because
there's
a
logical
place
to
check
for
it
but
anyways.
What
I
really
think
is
we
should
not
hold
this
release
candidate
for
this
bug
or
the
other
one,
but
I
do
think
that
it
should
be
I
mean
don't
give
up
on
having
a
beta
with
known
bugs
at
least.
We
should
then
document
them.
Yeah.
E
H
C
A
I
was
just
gonna
say:
I,
definitely
think
that
we
should
that
we
should
fix
this
before
ODOT
1.0,
it's
fairly
easy
to
do
it's
not
a
lot
of
extra
code.
It
might
the
thing
of
it.
Is
that
my
so
only
with
concern
to
what
PR
does
it
happen
in
the
pull
request
that
I'm
working
on
Oh
actually
does?
Do
people
see
my
terminal
screen.
A
C
A
C
D
A
A
All
the
animals
still
work
because
we've
put
we've
used
in
the
nucleus
of
kubernetes.
We've
used
things
like
local
object
reference
with
the
idea
in
mind
that
we
would
change
to
an
object
reference
potentially
in
the
future,
which
would
be
a
similar
transformation
that
didn't
affect
old
clients
of
the
API
that
were
end-users,
but
it
would.
A
B
H
Yeah,
so
the
it
would
be
good
to
go
to
make
sure
we
have
a
good
understand
and
what
being
but
I.
What
would
it
be?
My
API
changes
because
there
seems
to
be
this
thinking
that
it's
okay
as
long
as
the
animal
that
the
customer
specifies
doesn't
change
or
JSON
or
whatever
else,
but
if
we
do
so,
I
have
been
thinking
sometimes
incorrectly.
Maybe
the
types
that
go
fields
are
the
ones
that
will
be
defined
the
at
the
API.
H
A
A
C
E
I
just
wanted
to
say
that
looks
like
in
communities
release
process.
They
don't
break
both
a
user
facing
API
and
glencoe
API,
but
we
can
do
differently,
probably
so
they
have
like
they
cut
releases
and
they
don't
break
the
things
inside
the
release.
Branch
I
think
it's
at
least
I
haven't
seen
the
case
where
they
break
anything.
C
A
H
I,
don't
have
a
I,
don't
I
just
want
to
make
sure
that
we
decide
what
our
API
is
going
to.
Look
like.
So
there's
the
poll
1350,
where
there's
been
some
some
more
than
lively
discussion
on.
If
there's
going
to
be
how
the
structure
is
going
to
look
like
so
at
least
I
would
like
us
to
agree
on
what
that
looks
like,
because
that
potentially
could
have
not
only
the
types
changes,
but
it
also
could
also
have
changes
that
are
going
to
affect
the
end
users.
H
A
Yeah
I
agree
with
Vela
I
think
that
we
should
understand
that
we
should
have
things
factored
my
own
preference,
for
regardless
of
what
we
have
to
do,
would
be
to
have
things
factored
so
that
we
can
start
adding
additional
fields
for
these
other
strategies.
For
saying
what
a
user
wants
before
we
go
to
beta.
So
for
me,
I
would
like
I,
think
it's
1350
I
would
like
that
one
to
be
finished
before
beta
I.
A
H
This
is
that
there
is
a
second
immobile
gamal
field
for
rather
than
inlining,
and
that's
what
I
mean
is
that
we
just
need
to
decide
that
the
demo
level,
if
you
were
introduced
this
level
or
not
and
and
and
and
then
then
that
said,
we
factor
in
pain
we
can
push
later
on,
but
that
it's
I
think
all
the
way
at
the
end
of
it.
I
think
there's
some
it's
in
the
conversation.
Ok,.
C
So
there's
just
a
minor
word
here.
First,
let's
finish
out
the
original
issue
and
then
we
can
come
to
1350
on
the
original
issue.
There
was
a
question
about
whether
people
should
be
able
to
reference
the
service
class
name
and
the
service
plan
name
by
something
other
than
the
human
readable
name
for
beta
Aaron
is
your
hand,
would
talk
about
that
or
is
it
up
to
talk
about?
1350,
okay,
go
ahead
and
then.
D
A
C
D
C
C
D
A
A
J
D
A
E
E
D
A
A
A
D
C
D
Like
if
we
cut
one
tonight
when
none
of
these
are
fixed,
if
none
of
these
are
fixed,
if
we
caught
it
tonight,
we'll
have
bugs
and
we
will
have
still
V
1
alpha
1
API
resources,
so
I
believe
if
we
do
have
V
1,
beta
1
resources
and
we
caught
an
RC
1
tonight,
I
think
that's
good.
We
should
do
that.
Okay,.
C
Okay,
my
hands
about
stacks
gonna,
answer
that
one
I
prefer
not
to
disagree.
It's
an
overhead
extra
overhead
maintenance
I
would
prefer
to
make
sure
that
nothing
goes
into
master
that
we
don't
want
to
go
into
the
final
beta.
Therefore,
we
don't
have
to
do
a
dual
merge
or
cherry-pick
writing
like
that.
Just
my
personal
preference
relay
Europe.
H
C
J
H
Right
so
basically
this
the
idea
is
that
today
there's
two
ways
to
specify
the
plan.
Sorry,
there
is
a
one
way
to
specify
the
plan
you,
as
you
specified
the
external
service
class
name
and
the
external
service
plan
name
in
the
future.
There's
gonna
be
multiple
ways:
there's
couple
of
limbs,
I
think
22
I,
don't
forget
1081,
oh
yeah,
and
they
talk
about
things
like
label
selectors.
They
talk
about
all
kinds
of
various
ways
of
doing
that.
H
So
my
worry
is
that
we
will
end
up
with
the
service
instance
back
that
has
like
you
know,
order
of
the
ten
fields
and
it's
gonna
be
confusing
the
user
and
it's
gonna
be
confusing
for
us
as
the
coders
to
keep
track
of
a
set
of
fields
that
are
basically
a
union
or
a
struct.
That
basically
says
here's
here's
things
that
we
can
specify
I
think
totem.
That
is
going
to
be
trickier
if
they
are
just
random
fields
instead
of
a
struct.
H
H
I'd
feel
base
on,
but
you
know
call
it
decided
man
actually
like
that
at
one
point,
I
was
told
that
we
don't
want
to
that.
Any
people
don't
like
to
have
these
extra
levels,
but
this
is
really
what
I
want
to
decide
at
some
form
before
RC
one
is.
If
we
are
going
to
add
this
extra
level,
then
let's
do
it
now:
okay,.
C
C
Proposing
a
yellow,
wrapper,
I
didn't
realize
it
was
actually
as
the
internal
structure
kind
of
thing.
So
actually
Aaron
can
you
scroll
back
down
to
those
to
the
bottom?
There's
two
examples:
yeah
so
between
those
two
I
agree
with
you
that
when
we
get
to
the
point
where
you
actually
do
support
other
selection
type
of
criteria,
there's
gonna
be
a
lot
of
choices.
There.
I
do
agree
that
that
can
be
kind
of
confusing,
but
at
the
same
time
the
user
is
only
going
to
specify
one
set
at
a
time.
So
it's
not
like
there's
gonna.
C
Have
it's
not
like?
There's
gonna,
be
you
know
this
way,
plus
another
way,
plus
something
else
after
that
that
people
can
get
confused
about
from
the
end
user
perspective
from
the
end
user
perspective,
it's
always
just
a
single
one
being
there
so
I
think
the
first
example
there,
where
it
says
our
current
example
is
perfectly
sufficient.
I,
don't
think
we
need
an
extra
rapper
like
desired
plan
chosen.
C
The
second
one
I
think
it
just
adds
an
extra
layer
of
complexity,
it
for
the
end
user
for
no
real
value
whatsoever,
because
the
entire
purpose
of
the
service
instance
is
to
select
the
service
class
and
plan.
But
why
bother
having
an
extra
layer
just
just
for
fun?
Basically
I
think
Paul.
Your
ham
is
next
night
Aaron
ahead
poem
you
have
to
Paul.
Yes,.
A
E
D
Yeah,
so
from
an
API
perspective
from
a
yamo
api
perspective
at
plus
one
are
you
Doug
I'd
also
like
to
see
us
kind
of
drive
the
other
coordinate
systems
by
use
case
after
we
release
something
and
from
what
I
saw
in
the
pr
I--.
I
think
I
only
looked
at
maybe
half
of
it
when
I
saw
so
far
a
plus
one
what
you
said
to
pause
it's
useful,
but
since,
if
we
don't
go
with
the
nesting,
which
I
believe
we
should
not.
I
think
that
this
thing
this
whole
PR
should
be
put
into
ODOT
one-on-one.
A
H
Sorry
good
today,
yeah
I
was
gonna,
say
I,
don't
yeah,
basically,
I
just
wanted
to
resolve
that
issue
of
getting
rappers,
because
currently
the
PR
does
not
have
the
extra
rapper.
So
we
are
good
with
that
I'm
fine,
with
holding
off
on
submitting
this
I.
Thank
you
Paul
for
trying
to
save
me
work,
but
I
don't
feel
super
strongly
about
it.
H
C
H
H
C
Okay,
so
technically
we're
over
time
on
this
one
I
think
what
I'm
hearing
is
main
that,
while
I
may
not
be
higher
percent,
unanimous
I,
think
I'm
hearing
most
people
say:
you're,
okay
with
not
putting
a
wrapper
there,
so
the
only
question
might
be
whether
it
goes
in
for
data
or
not.
Is
that
true?
Okay?
C
A
C
D
C
A
So,
honestly,
I
don't
think
we
have
to
move
to
view
on
beta
one
before
the
first
release.
Candidate
I
think
it's
so
what
we
could
do
today
is
we
could
we
had
two
choices?
We
can
wait
a
little
longer
and
somebody
can
rename
V
1
alpha
1
to
V
1
beta
1,
which
would
be
fine
with
me
and
by
wait
a
little
longer
I
mean
someone
can
go.
C
So
any
objection
to
a
policy
testing,
okay,
my
hand
is
up
only
because
Paul
I
assume
you
probably
are
volunteering
to
create
the
release
tonight.
If
not
I
can
do
it,
but
I
can
do
it.
Okay,
if
you
do
it
can
I
ask
that
you
follow
the
slightly
new
process,
which
will
make
sure
that
we
pick
up
the
right
yamo
files
for
the
charts.
All
right
have
the
right
version
number
in
there
as
opposed
to
up
the
end
of
files
after
we
create
the
release.