►
From YouTube: Kubernetes SIG Service Catalog 2018-07-23
Description
how prow works vs our current process https://github.com/kubernetes-incubator/service-catalog/wiki/How-prow-works
deprecated org-guid content
irreversable deletion solutions
pr review from PRs called out earlier on slack
refactored charter based on feedback https://github.com/kubernetes/community/pull/2233
A
A
A
If
there's
something
in
particular,
you
wanted
to
chat
about
today.
Everyone's
welcome
to
edit
that
document
and
just
tack
on
their
thing,
they'd
like
to
talk
about.
We
usually
just
put
like
your
initials
or
name
at
the
beginning
and
then
what
it
is
you're
interested
talking
about,
I'll
just
be
following
through
this
agenda
doc
and
making
sure
that
everyone
gets
a
chance
to
speak
if
you're
having
trouble
getting
a
word
in
edgewise
just
type.
A
B
Sorry
I
had
to
fend
something
off
now:
we've
put
some
of
the
prow
automation
in
place
and
it
is
not
complete,
but
I
wanted
to
get
a
feel
for
how
everybody
is
feeling
about
the
you
know,
sort
of
new
new
workflow
in
that
you
know,
I
want
to
make
sure
that
everybody
is
notified,
that
we,
you
know,
lgt
m1,
LGD
m2
is
intended
to
go
away
and
that's
the
you
know
the
slash
commands
for
prowl.
Are
they
going
to
be
the
new
new
way
to
do
things
and
then
answer
questions
that
people
have
about
that?
B
A
C
I'm
not
the
answer
your
question
directly,
but
can
somebody
who
understands
the
process
just
write
up
like
a
very
short
like
a
half
page
list
of
commands
that
we're
supposed
to
do
now
going
forward
because
I
I
think
I
understand
the
difference
between
/l
g
TM
and
slash
accrue
or
any
other
things,
but
I
don't
know
for
sure.
If
my
thinking
of
it
is
actually
correct,
and
so
I'd
like
to
hear
from
somebody
on
our
team
who
actually
thinks
they
know
what's
going
on
I
just
tell
us
the
bare
minimum.
C
A
C
A
C
C
D
B
A
So
people
who
are
members-
and
let
me
just
talk
about
upstream
kubernetes
for
a
second
here
if
you're,
a
member
of
the
organization,
you
are
able
and
have
permissions
to
use,
/l
GTM
to
say
that
it's
been
reviewed
us.
Another
subset
of
people
are
like
reviewers
and
those
like
those
people
can
use
LG
TM.
It
depends
on
how
they
have
it
configured.
Basically,
I,
don't
know
how
we've
set
it
up.
I
think
we
only
have
a
perverse
actually
in
our
owners
and
approvers
as.
A
So
basically
approvers
can
do
slash,
approve
reviewers
can
do
/ld
TM
approvers
are
us,
also
have
reviewer
rights,
and
you
can
see
somebody
if
it's
like
in
an
area
where
there
just
aren't
a
lot
of
reviewers.
You
may
see
someone
who's
an
approver,
also
LG,
TM
and
approve
at
the
same
time
and
they're,
basically
taking
ownership
for
the
whole
thing
and
saying
if
this
is
screws
up
its
on
them,
I
hope
that
helps
at
all.
Basically,
what
that
means
is
you
don't
have
to
have
two
separate
people.
A
C
A
They're
under
the
proud
system,
there
aren't
two
LG
TMS,
there's
a
single
LG
g
TM
command,
which
applies
the
LG
TM
label
and
then
there's
the
approve
command,
which
applies
the
approved
label,
and
you
just
need
both
labels
in
order
to
merge.
That's
what
I
was
saying
it
can
only
you
can
get
through
with
just
a
single
person
if
they
have
the
ability
to
apply
both
labels.
No.
A
C
That
that
helps
because
I
would
have
naturally
just
always
done,
/gg
TM
and
then,
if
I
thought
of
the
second
one
I
would
have
probably
I
would
have
done
a
slash,
approve
thinking,
I'd.
No,
they
not
want
to
merge
it.
I
didn't
realize
that
slash
accrue
and
fighting
LG
TM
in
essence,
under
the
covers
right.
B
A
C
C
D
B
A
Was
very
important
because
we
have
had
a
number
of
times
where
PRS
are
merged
back
to
back
and
then
the
test
run
of
that
PR
is
stale
and
by
the
time
it's
actually
merged
in
his
master.
Those
tests
are
family
after
merging
with
the
latest
and
master,
and
it
never
should
have
made
it
in
so
we've
had
a
number
of
times:
we've
had
broken
master
builds
and
no
one
realized
it,
and
there
was
no
way
to
stop
it
before
we
merge
that
PR,
because
there
wasn't.
A
A
The
other
benefit,
it's
just
a
side
effect.
It
wasn't
the
reason
why
we
did
it,
but
as
we
get
people
who
are
used
to
working
prowlin
kubernetes
and
when
they
come
over
to
our
side,
they
understand
how
to
interact
with
us
and
do
contributions
as
well.
That
wasn't
the
reason
we
did
it.
It's
just
a
nice
to
have.
A
C
C
A
A
C
C
B
B
B
B
C
Yeah
yeah
no
I
I
understand
there
may
be
some
confusion
there,
but
for
anybody
that
cares
about
kubernetes,
they're
they're.
Basically,
writing
a
new
broker
at
that
point,
or
at
least
writing
new
code
for
be
the
curve,
a
side
of
things,
and
at
that
point
we
just
need
to
tell
them
in
our
documentation
or
something
to
look
in
the
context
that
maybe
it's
it's
as
simple
as
that
we
we
have
this.
B
B
B
D
C
D
C
A
Morgan
just
for
clarity,
so
those
two
individual
fields,
organization
and
space
goods,
are
being
deprecated
a
part
of
the
OSB
spec,
and
always
he
is
saying
you
should
start
using
these
contexts
if
we
put
that
in
our
inline
doc,
so
it
shows
up
in
the
go
doc.
Would
that
help
people
find
the
right
spot
to
help
avoid
that
issue?
We
had
opened
the
other
week,
I,
don't
know
I.
B
Don't
know
because,
because
again,
the
guy
was
writing
a
broker
or
he
was
adapting
a
broker
and
the
the
you'd
have
to
ask
that
that
that
guy,
who
was
basically
pulled
out
the
UID
and
then
you
know
you
could
see
the
code
he
iterated
through
all
of
the
stuff
which
is
not
not
efficient.
How
does
this
oh
yeah
cuz?
He
was
using.
He
was
running
a
broker,
not
consuming
our
client.
That
was
that
it
right
right.
So
so
you
know
I.
B
A
Know
one
thing
that
Jeremy
did
last
week:
is
he
added
a
new
section
to
our
documentation
specifically
for
operators,
and
then
he
started
filling
in
stuff
about
I,
believe
his
name's
based
brokers
and
service
restrictions?
What
if
we
had
a
similar
section,
that
was
for
people,
writing
brokers
and
just
had
like
very
direct
information
like
links
to
the
spec?
Obviously,
but
then
also
just
tips
like
this
is
deprecated.
This
is
what
you're
going
to
expect
us
to
put
in
the
contact
properties.
B
A
A
B
B
B
Cooper
now
do
you
see
a
name
space?
Okay,
so
it's
gonna
have
names
I'm
confused.
Now
we
can
hammer
an
out
as
part
of
issue
and
just
kind
of
just
I'm.
Looking
at
like
the
master
version
of
the
spec
and
then
I
go
to
the
213
version
of
the
spec,
and
it
says
namespace
is
in
B
211
and
then
over
here
it's
not
maybe
our
OS
b,
spec
tweet,
I
don't
know
I
need
to
go.
B
B
Somebody
would
have
to
look
at
the
code
to
know
what
it
is,
because
it
is
just
the
UID.
It
is
just
you
know,
a
string
of
like
gobbledygook,
so
I
think
a
a
thing
to
put
in
the
issue.
There
is
going
to
be
add
an
inline
comment
to
the
code,
because
that's
the
only
way
you
can
see
it
then
I
can
tell
when
you
say
to
the
code,
just
make
sure
I've
got
the
issue
right.
B
B
B
B
B
C
C
Now
it's
possible
that
the
working
group
could
come
back
and
say
the
way
we
want
to
support
these
is
by
using
the
stuff
that's
currently
inside
kubernetes
or
then
go
the
other
end
of
the
spectrum
and
say
no.
We
want
to
support
these
by
changing
crew
babies
in
some
way.
You
know
you
don't
know
where
it's
gonna
land,
if
we
do
have
working
group,
but
they
at
least
said.
C
Yes,
let's
just
have
a
discussion
about
whether
they
want
to
form
the
working
group,
so
they
didn't
make
it
sound
like
we
were
completely
insane
for
even
bringing
up
this
topic.
So
that's
forward
progress,
I
guess,
but
I
think
that's
kind
of
where
we
left
it
off
is
I
was
gonna,
send
a
note
to
the
coop
they
own
list,
seeing
who
else
is
interested
and
see
if
we
can
get
some
momentum
going
for
working
group,
you
started,
but
in
the
meantime
I'm
assuming
we
want
to
you
know
I
do
something
with
in
service
catalog.
C
A
Think
so,
I
added
just
a
clarification
to
make
sure
that
we
all
understand
that
the
scope
of
the
working
group
is
the
long
term
upstream
fix
inside
of
kubernetes,
because
it
may
not
just
be
Service
Catalog
that's
affected,
but
Service
Catalog.
We
won't
wait
for
whatever
comes
out
of
this.
We
may
come
up
with
an
interim
solution,
potentially
yeah.
B
That
was
right
to
me
so
moving
on
last
week
on
Thursday
afternoon,
yes,
whatever-whatever
Day,
July
19th
is
we
did.
This
is
recording
on
it.
I
posted
that
we
went
through
the
different
Aquabase
achill
II
went
through
the
different
options
that
we
felt.
That
would
be
a
good
short-term
solution,
and
then
we
said,
okay,
everybody
write
up
some
of
these
and
I
guess
we
have
a
separate
document
now
some
of
them
are
down
on
here,
and
some
of
them
are
in
this
document,
and
so
I'm,
not
sure
if
we
want
with
I
don't
want
to.
B
D
D
A
D
B
A
So
that's
what
each
one
of
these
items
was
attempting
to
kind
of
capture
would
just
be
like
short-term
impact,
long-term
impact
based
on
things
that
we
think
may
change
going
down
the
road,
namely
switching
to
CRTs
away
from
aggregated
api
and
then,
whatever
comes
out
of
the
working
group
and
their
recommendations.
How
do
we
consume
that
and
then
hopefully
not
have
another
breaking
you
like
API
change?
A
C
C
Only
thing
I
want
to
make
sure
is
that
gives
everybody
the
opportunity
not
just
to
read
and
think
about
the
document,
but
to
have
a
little
bit
of
a
back-and-forth
brainstorming
session
to
make
sure
they
fully
understand.
What's
being
said
and
proposed,
whether
that
is
going
to
be
done
today
or
next
week.
I
want
to
make
sure
that
people
have
time
to
digest
what
was
discussed
in
that
back
to
forth
I,
don't
want
for
zoo,
I,
don't
want
I,
think
it'd
be
a
mistake.
A
A
And
then
next
Monday,
one
of
the
chairs
or
any
one
of
the
maintainer
x',
can
can
kick
off
a
thread
on
the
mailing
list.
Where
people
can
vote
and
then
maybe
we'll
give
them
a
certain
number
of
days
to
vote
so
that
people
across
time
zones
or
if
someone
happens
to
be
out
on
Monday,
they
don't
have
to
be
physically
at
the
call.
In
order
to
be
able
to
vote.
A
A
C
One
thing
they
may
want
to
do
is
see
it
by
the
time
we
start
the
vote.
We
can
reduce
the
number
of
choices.
What
are
we
up
to
eight
choices
now
because
I
would
hate
it?
If
we
came
back
and
like
we
had
won
one
vote
for
each
right,
I
mean
that
would
be
awful,
I,
don't
know
so
I,
don't
necessarily
move
choices,
but
just
something
to
think
about
before
we
have
to
start
the
vote.
Yeah.
A
A
B
C
Same
and
it
would
be
nice
if
people
remove
choices
that
they
may
have
added
if
they
don't
actually
support
that
choice,
let
someone
else
react
if
they
do
to
support
it,
because
I
try
to
reduce
the
number
down.
So
if
there's
options
out
there
that
no
one
really
likes
I
know
I
probably
won't
get
a
vote,
but
I
think
it's
just
gonna
be
a
distraction
at
that
point
for
people
so
I'm,
rather
trying
to
remove
things
from
the
list.
If
no
one
is
actually
willing
to
champion
that
as
their
preferred
choice.
I
have.
C
B
C
B
D
B
B
B
B
B
B
All
right,
no
more
work
in
progress,
excellence!
Okay,
you
know
right
now.
I'm
gonna
try
to
fix
this
today
this
this
one
is
failing,
but
it
is
safe
to
ignore
because
it
doesn't
do
anything
yet
and
eventually
stuff
will
get
merged.
That
will
obsolete
that
that
test
run,
but
not
yet
so.
This
one
needs
a
second
reviewer
and
in
approve.
A
B
C
B
A
Has
to
do
with
adding
a
common
implementation
to
all
of
our
commands
in
SV
count
which
support
output,
because
otherwise,
as
well
as
I'm,
starting
to
add
tests
based
off
of
Jonathan's
new
test
pattern.
All
the
tests
are
having
to
explicitly
pick
like
table
format,
JSON
format
and
stuff
like
that,
and
it's
not.
A
The
tests
aren't
working
quite
right,
and
so,
if
we
just
switch
over
to
this,
we'll
be
able
to
take
advantage
of
the
fact
that
all
the
commands
actually
default
a
table
and
being
able
to
interact
with
them
will
just
be
more
consistent
and
follow.
The
patterns
that
we've
already
figured
out
for
namespace
commands
and
way
table
commands
stuff
like
that
was
mostly
refactor,
but
it
just.
It
just
makes
it
easier
to
write
tests
I,
like
refactoring
I'm
glad
someone
does.
B
A
I
had
one
note
about
the
Charter,
the
steering
committee
was
able
to
do
a
review
of
the
Charter
and
even
chatting
with
me,
a
dog
to
get
tweaks
and
wording.
Changes
in
I
got
them
to
agree
that
we
don't
need
to
redo
our
Charter
to
match
their
new
template
that
they
put
out
two
weeks
ago,
which
made
me
happy
so
I
think
I've
addressed
everything
that
they
wanted
changed
and
I'm
gonna
ping
them
for
a
final
look-see
right
after
the
meeting
excellent.