►
From YouTube: Kubernetes SIG Service Catalog 20170710
Description
- LGTM process
- Design meetings
- Which issues are needed for beta
A
All
right
welcome
everybody
to
the
Monday
July
10th
2017,
meeting
of
kubernetes
sig
service
catalog
on
the
planet,
Earth
in
the
Alpha
556,
be
continuity
of
the
multiverse,
welcome
and
I
hope.
Everybody
had
a
good
fourth
of
July
week
or
if
you
are
not
an
American
or
located
outside
the
United
States
that
you
just
had
a
nice
week.
I
did
and
welcome
back
everybody
that
was
gone
so
first
thing
on
the
agenda.
I
wanted
to
talk
about
the
ldcm
process.
A
B
But
basically
you
know
we
were
changing
a
policy
temporarily
based
on
somebody
being
out
and
either
either
to
two
LG
teams
is
good
enough,
all
the
time
or
it's
not,
and
we
can
decide
to
do
Phil.
You
can
do
some
other
process
whatever
and
that's
all
I
said
is
that
you
know
we
should
like.
If
we
feel
like
that's
okay,
then
let's
just
change
the
policy
overall
and
it
sounded
like
there
was
a
lot
of
agreement
that
you
know
we
didn't
need
the
you
know
ultra-conservatives.
B
A
Pony
marking
Gann
home
and
so
I
that
that
certainly
was
not
the
appearance
that
I
would
ever
want
to
have
of
compromising
on
quality.
I
spent
a
little
bit
of
time.
Thinking
about
this
like
I,
said
last
week,
and
so
here
are
my
thoughts
on
3lv
PMS,
which,
like
I,
think
that
if
you
watch
the
videos
and
if
you
paid
attention
in
the
meetings
and
been
at
the
meetings,
you
can
probably
tell
I'm
not
a
fan
of
3lg
p.m.
I
am
I
the
things
that
I
that
I,
don't
like
about
a
3ld
can
process.
A
Think
for
for
me
personally
I
those
two
things
have
gotten,
at
least
in
my
own
mind,
to
be
less
of
an
issue
after
having
several
months
of
working
with
with
people
like
I,
think
that's
just
sort
of
a
natural
ingredient
to
establish
that
trust
and
I
also
think
that
we
are.
We
very
much
agree
on
scope
to
a
much
larger
extent.
A
Now
that
then,
maybe
that
we
did
in
the
beginning
as
an
example
at
this
point,
I
think
most
of
the
most
of
the
code,
changes
going
in
and
by
most
I
think
I
really
mean
all.
Since
we
we've
said
in
our
last
meeting
that
we
were
going
to
focus
exclusively
on
kind
of
stabilizing
things
and
making
the
integration
with
the
open,
serviceworker
API
really
solid.
A
So
the
need
for
that,
like
checkbox
from
a
lot
of
people
to
me,
should
be
very
diminished
and
I
also
feel
that
if
it
slows
things
down
quite
a
bit,
it
makes
for
a
lot
of
extra
work.
Trying
to
get
things
in
so
I'm
not
finished
talking
yet,
but
I
don't
want
to
just
be
a
talking
head.
I
also
want
to
be
a
listening
head,
and
so
now
I
will
listen,
while
other
people
share
their
opinions
about
like
do
you
agree
with
the
observations
that
I
made.
C
So
my
take
on
it
is
I
agree
with
some
of
what
you
said
in
terms
of
things
aren't
as
ambiguous:
there
isn't
as
big
a
learning
curve
anymore
for
people,
and
so
there
is
a
lot
more
I
guess
used
to
word.
Trust
involved
right.
People
have
more
faith
in
the
PRS
that
are
coming
in
and
I.
Think
in
that
perspective.
I
do
agree
with
that.
I'm,
not
sure
I
agree
that
that's
necessarily
the
third
LG
TM
is
necessarily
as
sort
of
a
a
blind
checkmark
as
you
kind
of
implied.
C
C
With
a
couple
of
caveats,
one
being
that
the
first
one's
a
little
bit
fuzzy
but
I'd
like
to
put
out
there
person
to
action,
as
is
if
the
two
LG
teams
come
from
a
company
other
than
the
one
who's
supposed
to
propose
the
PR,
and
if
we
have
a
quote
gentlemen's
agreement
that
says
for
bigger
PRS
in
particular
ones
that
are
involved
design
decisions
like
some
of
the
design
issues
we
have
later
on
an
agenda.
Those
require
more
than
two
LG
TM,
but
no
one
if
they
want
to
formalize
it.
C
A
D
C
C
E
Think,
there's
an
alternative
to
actually
dropping
the
number
of
LG
teams
as
well.
If
someone
is
going
to
go
away,
gets
full
another
direction,
there
could
be
a
policy
around
handing
off
or
we
do
this
internally
at
corliss.
If
someone
is
going
to
go
on
vacation,
they
basically
need
to
get
their
priorities,
sort
it
out
and
have
somebody
else
be
appointment
for
all
the
different
things
that
correct
working
on
and
so.
A
Work
in
general
I
do
not
think
that
the
pool
of
people
that
actively
contribute
to
the
repo
is
large
enough
to
have
that
be
a
solution
in
a
vacuum.
Okay,
that's
fair,
but
I
do
appreciate
you
speaking
up
and
by
the
way
I
we
don't
usually
get
newcomers,
but
I
think
your
news.
So,
let's
as
an
interrupt,
allow
you
to
introduce
yourself
sure.
E
A
Well,
welcome
Jimmy
thanks
since
we
picked
on
Jimmy.
Is
there
anybody
else,
that's
new
that
wants
to
introduce
themselves
now,
I,
don't
think
so,
based
on
and
based
on
who
I
see
in
the
chat.
So,
okay?
Well,
thanks
for
introducing
yourself,
Jimmy
I
I
have
no
major
issue
since
I
for
the
time
being,
having
an
agreement
that
person
from
company
X
should
not
lgt
M
another
PR
from
someone
another
person
accompany
X
I
would
be
okay
with
that
in
Doug,
I've
now
forgotten.
The
second
thing.
C
A
What
we
do
in
kubernetes
that
I
have
found
to
be
very,
very
successful
when
we
bother
to
do
it
and
like
many
things
in
kubernetes,
it
is
not
done
with
uniform
consistency,
but
it's
worked
for
me
personally
in
the
past.
Is
that,
for,
like
large
new
features
odd
at
one
point
long
ago,
would
make
a
pull
request
to
the
docs
proposals
folder
in
kubernetes
itself,
to
work
through
design
issues
and
the
nice
thing
about
doing
that
forget
about
whether
they're
checked
in
or
whatever
the
nice
thing
about
doing.
A
A
So
I
would
say
that
how
about
this
is
that
at
what?
If
people
think
about
like
when
there's
a
new
substantial,
where
the
decision
plane
is
kind
of
a
judgment,
call
a
substantial
change
that
we
should
write
a
proposal
somewhere
to
capture
it
and
agree
on
it
before
any
code
gets
written
sort
of
like.
If
you
need
to
code
it
to
prototype
it,
that's
cool!
A
D
A
A
Think
that
that's
one
of
the
things
that
makes
like
the
kubernetes
community
really
awesome,
and
so,
when
we're
talking
about
algae
teams
like
I,
think
what
has
always
been
present
in
my
mind
and
almost
vited
by
the
same
token,
like
almost
never
fully
articulated,
is
that
I
do
not
I
I.
Think
that
anybody
with
like
some
substantive
comments
that
that
they
should
be
addressed,
whether
it's
in
that
full
request
or
in
a
follow
up
but
like
I,
don't
think
that
substantial
and
well-founded
AB
feedback
should
ever
be
ignored.
A
Regardless
of
whether
it's
somebody's
50th
issue
did
commented
on
or
their
first
so
I
don't
know
if
that
clarifies
anything
about
my
state
of
mind
for
people.
But
it's
something
that
I
realized
over
the
last
week
that
maybe
I
haven't
explicitly
said
enough
in
these
discussions
and
I
think
it
kind
of
amounts
to
like
maybe
not
an
expression
of
good
faith,
necessarily
but
a
willingness
to
receive
feedback,
regardless
of
who
it
originates
from
whether
they
can
lgt
em
things
or
whether
they
can
do
a
particular
mechanic
and
get
her
or
not.
C
It
does
say
no
cause
I
agree
with
you,
I've
never
committed
off,
but
it's
like
I
was
never
concerned
about
people
ignoring
comments
or
feedback
stuff.
Like
that,
that's
never
my
concern.
My
concern
was
usually
more
along
the
lines
of
you
know.
Someone
put
the
P
R
in
Friday
morning
and
by
Friday
evening
it's
already
made
merged
right
and
I.
C
Issues
don't
care
about
it's
always.
It's
always
focused
on
the
bigger
design
issues.
That
worry
me
so
going
back
to
your
proposal
of
saying,
okay,
people
need
to
open
up,
say
an
issue
first,
and
we
need
to
ask
you
the
design
to
the
issue
or
whatever,
in
advance
of
that
of
bigger
design
VPR's
being
submitted.
Then
yeah
I
think
that
that
that
address
was
my
concern.
Okay,.
A
So
I
think
that
we
should
permanently
go
to
two
LG,
TMS
and
I.
Think
that
the
this
this
is
extremely
similar
to
what
upstream
does
upstream
kubernetes
calls
it
a
reviewers
and
approve
we're.
You
need
an
LD
TM
tag
in
an
approval,
tag
and
I
believe
that
github
has
just
released
a
feature
that
is
like
basically
exactly
what
embodies
exactly
the
the
way
that
the
upstream
process
works.
A
So
I
I
think
that
for
now,
let's
just
do
LG
team,
LG,
TM,
1,
&,
2
labels
and
I
will
take
an
action
item
to
figure
out
like
if
the
the
github
mechanism
is
sufficient
or
if
we
need
some
piece
of
infrastructure
from
upstream.
But
for
now
let's
just
agree
that
we'll
do
2
LG
TM
s
in
design
issues
need
to
have
a
proposal
or
need
to
have
something
that
is
like
in
the
issue
open
for
it
in
github
like
this
is
how
it's
going
to
be,
and
we
agree
to
it
before.
A
Someone
makes
a
full
request
with
me:
I
guess
additional
caveat
since
we're
all
pedantic,
nerds
and
someone's
probably
thinking
of
this
situation,
which
is
like
what
if
I,
was
prototype.
What
if
I
was
prototyping,
something
and
I
really
liked
it
and
I'm
going
to
write
a
proposal
for
it,
but
I
want
to
make
a
full
request
so
that
people
can
easily
see
it
and
react
to
it.
D
We've
got
four
items
that
must
pass
in
order
to
merge
at
PR.
We've
got
open
for
at
least
one
business
day.
We
have
a
veto
label,
the
three
LG
TMS
and
then
a
fourth
one
augmentation
and
test
cases,
I
I,
don't
really
think
I
think
the
fourth
one
must
obviously
stay,
but
what
about
the
first
to
examine
for
one
business
day
and
veto
label?
How
do
people
feel
about
those
two
requirements?
I.
A
C
I'm,
okay,
with
dropping
that
one
and
on
the
second
one
I,
still
think
if
someone
feels
strongly
enough
to
the
state.
No,
no,
no,
please
stop
I
think
there
should
be
some
sort
of
label.
That
indicates
that
my
only
request
is
going
to
be
early
Anil
if
the
switch
different
veto,
no
LG,
TM
or
not
LG
down
or
whatever
that
there
are
the
proper
term
is
so.
D
C
A
C
A
C
D
D
A
And
I
think
that
would
be
okay,
I,
that's
something
that
we
might
want
to
come
back
to,
but
it
definitely
mirrors
our
experience
in
the
early
days
of
kubernetes,
where,
as
Red
Hatters,
we
did
not
want
to
merge
Ireland
poles,
and
this
was
back
in
the
day
when
people
were
actually
hitting
the
green
button.
So
it
really
was
like
three
years
ago,
two
and
a
half
years
ago
and
I
think
that
is
a
good
good
faith.
Type
of
thing
we're
still
a
fairly
new
a
part
of
the
community
and
I.
D
C
A
A
A
E
C
So
this
weekend,
I
went
through
all
the
open
issues
and
tried
to
pull
out
the
ones
that
I
thought
were
were
well
basically
block
by
some
sort
of
high-level
design
decision.
And
if
you
look
further
on
the
agenda
under
designed
issues,
I
tried
to
sort
of
list
all
the
ones.
I
thought
you
need
to
design.
C
While
we
have
so
many
big
outstanding
issues
and
we're
all
particularly
hard
to
get
the
beta
so
I'd
like
to
propose
that
we
have
an
additional
phone
calls
at
least
one
more
week,
preferably
as
late
as
possible
in
the
afternoon,
so
that
our
friends
in
Australia
might
be
able
to
join
I,
believe
4
p.m.
Eastern
is
6
a.m.
so
that
may
be
doable
for
them,
but
I'd
be
willing
to
go
later.
If
that
makes
it
easier
on
people,
but
I
just
want
to
get
at
sensing.
A
That
would
be
a
really
good
idea
and
I
think
I.
Think
you're
right
I
think
there
are
a
few
things
that
have
like
said
that
we
do
probably
need
to
discuss,
as
a
group
I
would
be
I
tell
you
what
I
don't
want
to
commit
to
too
many
late
meetings,
but
I'd
be
totally
happy
personally
to
do
one
more
a
week
and
I
think
that
we
should
repurpose
this
meeting
to
also
be
design
discussions
as
much
as
possible.
C
That
works
for
me
obviously,
I
think
that
the
biggest
thing
here
is
make
sure
that
people
understand
that
they
call
is
no
longer
going
to
be
primarily
a
status
call
kind
of
a
thing
or
a
sync
up
call
it's
going
to
turn
into
a
design
session.
So
if
you're
interested
in
the
design
discussion,
don't
skip
it
as
bit
point
yeah.
D
I
have
two
requests.
One
we
have
I
will
do
this
if
no-one
else
picks
it
up.
Then
we
have
someone
to
take
notes
on
this
everything
in
the
design
discussions
and
put
them
into
a
Google
Doc,
that's
saved
forever.
The
second
thing
is
I
think
it
is
worth
it
to
have
status
and
maybe
retro
or
both
so
I
would
like
to
keep
that
in
some
form,
I'm
open
to
ideas
and
when
to
put
it
and
how
to
do
it.
It's.
C
D
I
will
have
to
miss
this
Wednesday,
but
beyond
that,
I
can
come
and,
like
I
said,
I'll,
take
the
notes
and
organize
and
everything
good
5:00
p.m.
Eastern
work
better
for
you,
I'm
going
to
be
traveling
this
Wednesday
to
go
for
calm.
So
nothing
really
will
work
like
the
following
Wednesday's
everything
after
that
will
work
and
work.
A
For
would
work
better
for
me.
Let's
do
four
for
now
and
and
we'll
see
how
many
people
show
up
okay
for
works.
Okay,
I
will,
since
if
I
do
not
do
this
now,
I
will
probably
forget
to
do
it,
so
I
will
go
ahead
and
make
a
calendar
invite
now
for
that
so
I
think
next
up
is
talking
through.
How
do
we
think
some
of
these
issues
should
be
bend
or.
C
So
because
this
list
was
just
put
together
basically
yesterday,
if
people
feel
like
they
need
more
time
and
want
to
go
back
and
click
their
clocks
and
not
necessarily
do
the
design
discussion
today,
I'm,
okay
with
that
and
save
it
for
Wednesday.
Otherwise
it
made
maybe
one
or
two
on
here
that
we
could
possibly
look
at
picking
off
because
they're
not
they
can
require
a
whole
bunch
of
planning
in
advance.
A
A
C
I
can
I
suggest
that
if
people
think
that
my
initial
swag
at
this
list
is
incorrect
in
terms
of
forgiving
the
binning
that
they
make
a
comment
to
that
effect
in
there,
because
honestly
I
would
rather
spend
time
on
windows
call
talking
about
issues
that
we
all
agree
need
to
be
solved
for
beta
and
say
the
discussion
about
which
bucket
they
go
into
for
offline
discussions.
I
think.
A
D
All
right
cool,
so
I
would
love
to
be
able
to
be
there
on
Wednesday,
but
I
can't
what
I
would
like
to
see
out
of
these
discussions,
adding
any
Wednesday
or
Monday
discussion
or
whatever
else
there
may
be,
is
to
have
a
design
doc
come
out
of
the
items
that
are
discussed
so
I'll
take
the
first
one
on
the
list:
scalability
of
retrieving
service
glasses
so
to
have
a
new
Google
Doc
come
out
of
that
meeting.
That
discusses
the
problem,
the
solution
and
then
implementation
notes,
if
appropriate.
D
A
D
Yeah
I
mean
I've,
seen
Google
Docs
use
as
seen
below
press
use.
The
medium
is
not
a
big
deal
to
me.
Okay,
but
whoever
is
taking
the
notes.
I
think
needs
to
be
responsible
for
doing
that
and
partially
by
extension,
responsible
for
keeping
the
group
on
track
to
delivering
that
proposal,
design
doc
other
name
by
the
end
of
the
session
yeah.
E
A
Yeah
yeah
I
mean
I
get
up.
Yes,
once
an
idea
has
critical
mass.
We
shouldn't
single
thread
on
whoever's,
taking
notes,
but
maybe
I
just
misheard
Aaron
a
little
bit.
Someone
needs
to
take
notes.
Yeah
someone
definitely
needs
to
take
notes.
I,
don't
think
that
person
has
to
be
the
one
that
writes
up
the
specific
proposal.
I
think
that
person
could
just
take
notes.
Okay,.