►
From YouTube: Kubernetes SIG Service Catalog 20170808
Description
- Scope of initial beta release
B
Thanks
Paul,
so
my
normal
spiel
is
as
follows:
we're
going
to
be
doing
a
speaker.
Q
I,
have
my
high
tech,
speaker,
Q
equipment,
ready.
If
you
have
something
you'd
like
to
add
the
conversation,
please
type
in
the
chat
plus
hand
like
I.
Just
did
I
have
the
agenda
up.
The
agenda
link
is
also
in
the
chat
right
now.
I
will
be
taking
notes,
but
I
will
not
be
sharing
my
screen.
B
So
if
someone
else
would
like
to
that's
totally
fine,
but
otherwise
this
is
a
live
updating
document,
so
you
can
easily
pull
it
up
on
your
own
machine
and
see
my
notes
as
I
type
that
so
with
that
we're
going
to
start
with
the
first
item
on
the
list
under
August,
8th
2017,
and
that
is
from
Paul
Morey
talking
about
issue
number
one:
zero,
nine,
eight,
the
proposal
for
the
scope
of
the
initial
beta
release,
so
Paul
go
ahead
and
take
the
floor,
and
you
can
start
talking
about
the
background
for
this
issue.
Okay,.
A
A
A
A
B
So
this
would
be
a
good
time
if
you
have
something
to
say
put
a
hand
in
the
chat.
This
is
the
time
for
all
of
us
to
object
or
add
something
to
the
list.
If
we
need
to.
If
we
don't
have
any
objections,
then
we're
going
to
reach
consensus
on
this
and
I'll.
Take
that
as
a
note
in
the
meeting
notes.
So
if
you've
got
somebody
say,
please
put
a
hand
up
in
the
chat
and
we'll
execute
the
speaker
queue
as
normal.
So.
C
B
C
B
A
You
have
your
hand
up
take
the
floor,
please
so
a
couple
things
fun,
Fabiana,
Franz
who's,
the
sig
COI
lead
has
been
apparently
in
parallel
doing
some
design
on
on
CLI
stuff,
so
Morgan
and
Fabiano
should
talk
to
one
another.
A
second
I
don't
think
this
should
be
required
for
an
initial
a
requirement
for
an
initial
beta
release
that
doesn't
mean
that
we
had
to
wait
until
GA
to
do
it
and
if
it
were
released
or
if,
if
we
had
something
that
people
wanted
to
use,
I
think
that
would
be
great
I.
A
D
D
The
second
thing
is:
is
this
list
all
our
all,
the
all
the
things
that
we
have
in
this
list?
What
we
call
p0s
aka
must
ship
or
are
there
things
like?
There
are
p
0,
p
ones
like
nice
hab,
so
whatever
the
convention
is
meaning
are
we
I
would
like
to
go
ahead
and
for
this
thing
focus
only
on
things.
We
must
ship
because
time
is
running
short
and
we
need
to
get
something
out.
B
B
A
B
A
A
B
All
right
so
I
have
two
more
people
in
the
speaker
queue.
It
seems
like
they're
both
related
to
this
topic,
so
I'm
gonna
continue
with
those
two
people
and
then
I
am
going
to
propose
our
consensus
at
that
point.
So
Nile
you,
you
said
I,
don't
think
we
need
it
for
beta
and
I
put
your
hand
up
for
you.
So
can
you
please
verbalize
that
and
also
add
some
more
detail.
If
you
have
it
yeah.
E
It
was
about
the
cube,
CTO
plugin,
so
I
don't
think
we
need
to
shrink
the
plugin
at
that.
It
is
required
for
beta
I'm,
not
even
sure
what
the
format
of
the
comments
should
be
and
I'm,
not
convinced
that
the
there
was
an
initial
implementation
of
keeps
their
plugin
and
I
am
not
sure
if
it
is
the
way
it
should
be
and
I
think
that
if
we
provide
anything
there,
it
should
be
closer
to
what
coupe
CDL
provides
for
the
core
resources.
B
A
A
B
B
D
D
It
seems
like
there's
two
ways
we
can
go
about.
The
modem
is
yes
for
the
beta
it.
Ships
with
the
conky,
which
is
there,
is
no
default
plan,
but
eventually
it'll
get
fixed
or
you
can
go
ahead
and
try
to
go
and
say
that
no,
no,
no,
no!
No.
For
beta.
We
need
to
support
the
default
plan.
I'm
fine,
with
either
and
I
volunteer
to
go
and
take
over
the
implementation
of
the
blah
blah
blah,
but
the
people
planning
I
can
do
that.
B
C
B
A
I
I
think
that
we
should
be
very
careful
regarding
what
V
lay
has
just
spoken
about.
I
think
that
what
he's
talking
about
is
the
feature
that
we
discussed
yesterday
we're
for
a
service
with
a
single
plan.
You
don't
need
to
specify
the
plane
and
not
a
more
first-class
baked-in
idea
of
user
provided
services
that
exists
without
a
broker
to
back
them.
Okay,
VA.
D
Basically,
I'm
saying
that
for
step
zero,
we
do
nothing.
We
just
mean
basically
ship
the
existing
UPS
broker,
as
it
is
the
the
the
step
one,
which
is
to
simplify
the
usage
of
it.
You
basically
don't
have
to
specify
the
plan
called
whatever.
If
there
is
only
one
I
would
argue
that
the
first
one,
which
is
shipping
UPS
as
it
exists
to
support
legacy
services,
is
met.
It
is
necessary
for
the
beta
I
think
the
the
second
one
is
absolutely
not
a
p0,
but
I
would
like
to
get
it
in
in
beta.
Okay,.
C
A
Ahead,
I,
don't
think
that
we
should
prevent
anybody
from
writing
code
for
issue
that
there's
a
consensus
on,
and
we
have
certainly
established
a
very
expensive
consensus
on
this
one,
so
I'm
all
for
it
going
in
I,
don't
I
think
it's
a
nice
to
have
and
yeah
I
think
I'm.
Just
echoing
what
people
have
said.
Vla
told
me
he's
very
interested
in
working
on
that
one
and
since
he
has
previous
experience,
writing
admission
controllers
I
would
imagine
he
can
probably
get
it
done
pretty
quickly.
B
A
Okay,
I
am
so.
Can
you
still
see
my
screen?
Yes,
excellent.
All
right,
so
I
think
there's
a
lot
of
interest
in
the
community
in
this
project,
and
one
of
the
motivating
factors
to
get
to
beta
is
that
a
lot
of
users
will
just
not
use
api's
that
aren't
at
beta.
Yet
and
we've
had
this
project
and
incubation
now
for
if
I
remember
correctly,
it's
like
10
months
I
think
it
would
be
great
if
we
had
a
an
initial
beta
release
by
the
time
that
kubernetes
1-8
shipped
and
so
before.
A
We
talk
about
ancillary
effects
of
that
and,
like
other
timelines
connected
with
that,
I
wanted
to
engage
the
level
of
interest
and
having
something
by
kubernetes.
1/8
Paul
wanted
to
mention
when
kubernetes
1/8
is
I
will
get
all
of
that
information
which
I've
collected
into
a
gist,
but
I
need
to
unshare
my
screen
before
you
that.
A
A
A
A
A
B
In
terms
of
in
terms
of
project
planning,
project
management
I'll
take
over
that
excuse
me
I'll,
take
over
that
responsibility
in
setting
up
making
sure
the
milestones
are
current
and
so
forth
after
we
decided
at
a
time
at
least
a
at
least
one
time
that
we
would
like
to
get
this
done
by
and
I'll
make
sure
that
everyone
has
regular
updates
on
our
progress.
So,
first
of
all
act
to
your
hand,
Paul
Doug
I,
think
you
have
something
to
say
there.
I
put
your
hand
up
for
you
regarding
your
+1
comments.
C
A
Paul
go
ahead,
yeah
I
think
that
it
will
be.
It
won't
be
the
end
of
the
world
if
we
shoot
for
that
date,
and
we,
you
know
miss
it
by
a
week.
I
think
that
I
think
actually
that
we
have
consensus
on
a
lot
of
this
stuff.
We
tend
to
spend
most
time,
obviously
on
things
that
we
don't
agree
about,
order
that
aren't
obvious
as
having
a
single
way
to
skin
a
cat.
A
I
mean
I'm,
sorry,
I'm,
switching
things
up.
We
still
have
to
finalize
the
names
of
all
the
resources
we
had
to
figure
out
what
the
kubernetes
names
of
service
class
and
plan
are,
and
there's
been
a
thread
on
the
mailing
list
and
and
also
cross
posted
to
the
cig
architecture
list,
because
it's
kind
of
a
problem
with
that
precedent
and
grooving
any
big
guys
we
have
to
solve
the
so.
Those
two
are
take
a
lot
of
discussion.
A
I,
don't
anticipate
the
generation
stuff
being
very
complex,
in
fact,
I
think
it
will
probably
be
much
simpler
overall
to
understand
and
less
code.
We
already
have
this
resource
for
plan
is
in
motion
and
a
number
of
these
other
things.
We
have
some
degree
of
consensus
on,
or
they're
already
done
or
they're
in
progress.
Now,
for
example,
I
think
we
have
some
degree
of
consensus.
A
Everything
under
burgers
I'm,
looking
at
instances
and
I,
think
that
the
parameter
stuff
is
almost
in
a
state
where
I
it
can
be
checked
in
we're
from
it
again
is
something
that
will
require
discussion,
but
there
are
really
not
very
many
ways
to
skin.
The
cat
plan
and
parameter
updates
to
I
think
are
fairly,
are
probably
going
to
be
fairly
easy
to
talk
through
user
impersonations
already
underway.
I
think
that
we
have
some
degree
of
consensus
about
when
an
instance
has
bindings.
A
This
one
I
also
think
is
very
few
ways
to
skin
this
cat
and
likewise
reject
plan
changes
for
services
that
are
not
plan,
updatable,
also
very
few
ways
to
skin
the
cat
and
then
there's
a
higher
degree
of
overlap
with
the
things
we
need
to
do
for
instances.
But
what
we
need
to
do
for
bindings
so
I
actually
do
not
think
that
it's
necessarily
an
insurmountable
amount
of
work,
but
we
definitely
tend
to
be
to
spend
the
most
discussion
bandwidth
on
the
things
that
are
hardest,
which
just
makes
sense
right
like
the
hardest
things.
A
Take
the
most
discussion,
most
effort
to
work
through
so
I
I
think
that
this
date
is
is
doable
and
I
also
can
say
that
Red
Hat
is
adding
two
more
engineers
to
this
project.
To
get
some
of
these
things
that
have
consensus
program,
so
we're
we're
interested
in
staffing.
This
effort
to
try
to
make
it
successful
by
this.
A
B
So
I
have
heard
before
I
move
on
with
the
speaker
queue
I
want
to
mention.
I
have
heard
two
separate
tracks,
one
is
what
do
we
want
and
the
other
is.
What
do
we
think
is
attainable?
So
I'd
like
to
try
to
establish
consensus
on
the
former
in
a
perfect
world?
Does
anyone
disagree
with
trying
to
get
a
beta
one
of
the
door
by
September,
26
2017
and
he
will
be.
E
B
B
A
Anybody
have
I
have
an
opinion
on
that.
Okay,
so
I
do
not
think
that
we
should
include
a
rebase
unless
we
discover
during
implementation
of
the
scope
that
we've
agreed
on,
that
we
have
a
dependency
on
the
1/8
machinery
for
a
particular
feature
right
now.
I,
don't
think
that
we
do
so
right
now,
I,
don't
think
it
should
be
necessary.
A
B
A
I
I
have
a
complimentary
use
case,
which
is
basically
the
opposite
of
the
opposite
of
nulls
is
that
I
would
I
would
strongly
prefer
not
to
have
to
rebase
unless
there's
a
very
good
technical
reason.
From
a
feature
standpoint,
it
sounds
to
me
like
now.
Your
requirement
comes
from.
It
sounds
like
you
have
a
vendor
directory
where
you
are
vending
catalog
in
conjunction
with
with
the
machinery.
Yes,
okay,
so
I
have
like
the
opposite
situation.
A
Think
I
think
we
might
want
to
just
play
this
one
by
year.
Honestly,
the
the
speed
of
the
last
rebase
was
pretty
fast.
If
you
take
out
all
the
time
where
we
didn't
actually
know
what
to
do
with
it,
so
I
don't
know
that
that
would
necessarily
be
too
disruptive
I
might
vote
to
put
that
one
in
a
nice-to-have
or
play
it
by
ear.
State,
okay,
Doug.
C
Please
take
the
floor.
Yeah,
so
I
was
originally
gonna
say
that
I
do
agree
that
it's
sort
of
more
in
the
category
of
a
nice-to-have,
I'm,
not
sure
I'd,
won
and
I
said
I
hold
up
the
beta
release
just
for
a
rebase.
If
that
was
the
only
thing
that
was
outstanding,
but
the
more
I
was
thinking
about
it.
The
more
I
started,
thinking
that
you
know
going
to
beta
is
a
pretty
big
deal
and
we're
purposely
trying
to
align
it
with
the
crew
BAE's
release
cycle,
starting
with
1.8.
C
C
So
from
that
perspective,
I'm
I'm
very
much
in
favor
of
pushing
really
really
hard
to
always
be
rebased
on
the
latest
version
kubernetes
so
that
as
crew
nays
gets
released,
we're
aligned
with
and
if
you
can
use
our
stuff
with
the
very
latest
thing,
because
that
to
me
is
kind
of
what
beta
means
right.
It's
almost
like
you're
ready
to
go
almost
production-ready
and
I've
booked.
The
core
infrastructure
is
set
in
stone.
So
there's
no
reason
why
we
shouldn't
be
able
to
keep
up
with
kubernetes,
so
I'd
suggest
that.
B
Dog,
that's
a
very
good
topic,
but
I'd
suggest
that
we
limit
this
discussion
just
to
what
do
we
need
before
V
1,
beta,
1
and
and
dug
for
you
to
put
an
item
on
the
agenda
for
tomorrow
about
what
should
we
be
doing
about?
Rebase
is
long-term
just
to
keep
purely
to
keep
this
discussion.
Super
super
focused
on
beta.
C
B
So
what
I've
heard
is
there
seems
to
be
I
may
have
the
Strongs
to
speak
up.
If
I
do
there
seems
to
be
a
consensus
on
let's
try
to
get
a
rebase
in,
but
if
we
don't
have
it
in,
then
let's
prefer
to
release
on
the
26th
without
the
rebase.
So
does
anybody
have
something
to
say
about
a
hypothetical
clearly.
A
A
We
could
we
could
say
that
say
that
it's
September,
25th,
1
8,
is
delayed.
I,
think
that
if
and
everything
else
is
done
and
in
good
shape,
except
for
machinery
I
would
be
in
favor.
In
that
case,
of
cutting
a
beta
one
like
Oh
dot,
one
dot,
oh
and
in
the
next
week,
cutting
ODOT
1.1,
which
is
rebased
on
to
the
machine.
A
B
B
So
what
I'm
gonna
do
is
put
right
here
where
I'm
typing
gibberish,
it
doesn't
show
up
yet
so
under
the
consensus
previously.
The
first
beta,
under
any
objections
to
the
proposed
scope,
I'm
going
to
put
optional
a
rebase
for
Kate's
one
bed
a
but
we're
not
gonna,
hold
up
a
release.
If
that's,
the
only
thing
left
sounds
good
to
me:
Doug
thoughts,
anybody
else,
thoughts,
okay
for
now,
okay
hold
on
one
sec,
while
I
write
that
in.
B
D
D
A
B
D
So
my
understanding
was
so
sorry
again
just
to
continue
since
I
made
the
question,
so
my
understanding
is
amongst
a
software
ship,
the
beta
in
kubernetes.
The
assumption
is
that
the
resources
will
be
migrated
able
or
whatever.
So
if
we
basically
ship
the
TP
ours
to
beta-
and
we
say,
but
it's
alpha
is
that
it
seems
to
me
like
it's
an
issue.
Am
I
complicating
this?
D
A
Don't
I
don't
think
it's
an
issue.
I
think
that
at
this
point,
most
of
the
users
that
are
actually
using
TP
are
understand
that
it's
going
to
be
deprecated
anyway
and
I
think
that
we
should
definitely
be
really
clear
and
say
we
are
going
to
use
we're
going
to
migrate
to
CR,
DS
and
TP.
Our
support
will
go
away,
but
I
don't
I.
A
Don't
think
that
we
need
to
migrate
it
if
the
I
think
that
it's
a
it
sort
of
holds
the
status
for
me
of
like
an
experiment,
and
there
are
known
issues
as
far
as
I
remember,
with
our
implementation
of
the
TP,
our
storage,
that
I
don't
think
it's
something
that
we
should
try
to
support
in
any
way.
Okay,.
D
B
Agree:
okay,
I'm
gonna,
so,
first
of
all,
sorry
does
anyone
disagree
that
we
should
make
sed
the
only
officially
supported
storage
back-end
for
beta
one,
if
you're?
Okay,
with
that
from
Microsoft
perspective,
that's
one
thing
that
is
okay
for
a
beta
one
from
Microsoft's
perspective,
any
objections,
okay,
I.
B
Would
I
will
mention
that
we
Microsoft
would
like
see
CPI
CRD
support
in
a
future
beta
before
GA?
Is
that
a
Freudian
slip
and
we'd
like
CPR
No
yeah?
We
would
like
CRD
support
before
GA,
but
it's
not
necessary
to
have
it
in
beta
one
okay.
So
we've
got
a
consensus
there
on
the
storage,
back-end
Doug.
You
are
next
up
in
the
queue
so
go
ahead
and
take
the
floor.
Yeah.
C
So
one
thing
that
I
was
wondering
about
is
the
migration
of
pod,
preset
to
an
issue
lasers
and
the
move
of
the
repo
to
be
under
our
remove
the
code
under
our
repo.
Is
that
something
that
we
need
to
do
for
beta
or
not
I'm,
assuming
this
probably
isn't
required
for
beta?
But
then
I'm
kind
of
wondering
is
do
ba.
We
make
any
promises
to
anybody
in
terms
of
the
timeline
for
that
I
have.
C
A
C
A
C
E
A
B
E
D
E
Like
yeah
or
just
being
kept
in
alpha
but
I
think
the
plan
was
to
move
it
completely
because
the
discussion
started
with
like.
Can
we
make
it
better
and
I
think
the
decision
was
not
they
can't
and
I.
Don't
know
I
mean
like:
if
will
they
actually
wait
until
we
implement
the
precept
before
removing?
Or
is
it
our
responsibility
to
remove
this
feature
from
community's
core?
How
does
it
work.
A
A
B
B
A
I
I
think
that
it's
very
productive
to
work
through
design
proposals.
As
for
requests
that
get
checked
in
I
think
a
valid
point
that
has
been
raised
is
excuse
me
is
that
in
crew
matys
would
check
them
in
and
that's
it
they're
more
of
like
a
record
of
this
is
what
we
did
before
we
started
coding
and
then
nothing
happens
to
them.
So
I
would
be
fine
with
checking
them
in
and
going
back
and
adding
to
the
proposal.
A
B
C
I
was
just
gonna
suggest
that
as
Paul
was
alluding
to
it.
This
is
gonna,
be
a
rathole
issue,
so
I'd
rather
just
save
it
for
another
discussion
or
another
day
actually
and
just
in
the
meantime
I
know
we
I
guess
it
was.
Last
week
we
agreed
that
it'd
be
nice
to
try
to
make
sure
people
include
documentation
there
PRS,
but
it's
gonna
be
really
hard
requirements,
as
you
don't
have
that
baseline,
yet
so,
just
as
best
you
can
on
existing
PRS
document.
B
C
B
A
B
B
It
is
more
than
acceptable.
It
is
sufficiently
adequate
all
right,
so
consensus
for
the
checking
in
proposals
is
that
we
are
not
going
to
check
in
just
proposals.
Instead
for
the
beta
one
implementation
period
and
I
can't
spell,
we
are
going
to
add
documentation
to
PRS
as
best
we
can
we'll
revisit
after
we
ship
theta
one
okay
Doug.
Thank
you
for
trying
to
find
the
time
understood
that
you
can't
promise
it.
I
too,
will
try
to
find
some
time
to
add
Docs.
B
It's
actually
something
that
I'm
going
to
have
to
do
in
a
couple
fronts
internally
at
Microsoft
anyway,
so
Doug
I'll
reach
out
to
you,
and
maybe
we
can
coordinate
something
sounds
good
beyond
that.
I
see
Paul
and
your
shared
screen
of
me
that
my
tongue
is
out
that
looks
really
attractive
and
beyond
that
we've
got
three
minutes
left
we're
not
really
gonna,
be
able
to
cover
anything
else
in
that
time.
So
we'll
get
three
minutes
back.
It's
my
small
gift
to
all
of
you.
So
thanks
everyone
we'll
see
you
tomorrow.