►
From YouTube: Kubernetes Public Steering Committee Meeting 20210712
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Welcome
to
any
members
of
the
community
that
we
have
here
looks
like
we
have
several
of
you
and,
of
course,
welcome
to
all
of
our
syrian
committee
members.
It's
nice
to
see
you
as
well.
Yes,
we
do
have
a
code
of
conduct
today,
as
always,
please
be
excellent
to
each
other.
This
is
a
governance
meeting,
so
we
do
conduct
business
a
tad
differently
than
some
of
our
sig
meetings,
where
we
technically
argue
with
each
other.
We
governance
argue
with
each
other
here,
so
there
is
a
tad
bit
of
difference.
A
There
are
a
little
bit
of
rules
today,
since
I'm
running
this
show.
I
want
to
make
sure
that
everybody's
heard.
So
one
thing,
that's
really
important
is
context.
We
have
a
full
agenda
today.
So
if
you
are
on
the
agenda-
and
you
have
one
of
these
items
that
you
were
bringing
up-
you
get
three
minutes
to
give
us
context.
A
A
I
do
see
some
sig
business
on
the
agenda
and
I
did
try
to
bump
that
up
a
little
bit
like
sig
service
catalog,
you
were
at
the
bottom.
I
bumped
you
up
just
take
note
to
that,
but
other
than
that,
let's
get
into
the
show
cool
all
right.
So
first
things
up,
we
have
better
selection
of
chairs
and
tls
I'll
share
my
screen
too,
as
we're
talking
who
wants
to
take
the
context
for
this
dims.
A
B
I
can
at
least
tee
it
up,
so
there
was
a
there's
been
some
ongoing
discussions.
We've
had
discussions
on
this
topic
for
for
quite
a
while,
but
there
were
some
discussions
around
how
sig
chairs
are
selected
and
around
potentially
putting
in
term
limits
for
for
sick
chairs
right.
B
A
standardized
way
across
the
community
for
for
selecting,
sig
chairs,
some
of
them
are
done
via
like
nominated
by
current
sig
chairs
and
sick
leadership,
and
then,
like
contestants,
achieved
from
the
sig
itself.
There
have
been
specific
examples
where,
like
a
role
like
a
chair,
tech
lead,
there's
been
like
a
mini
election,
that's
been
set
up
within
a
sig
there's
yeah.
There's
been
various
examples
that
that
have
happened
as
far
as
how
to
do
it,
but
there
isn't
like
a
a
complete.
B
You
know
uniform
way
of
doing
this
across
the
across
the
project.
So
the
the
discussion
is
kind
of
around.
Should
there
be
a
uniform
way
of
doing
this?
Should
there
be
more
resources
provided
for
sigs
to
be
able
to
to
select
their
leaders?
Do
we
potentially
make
the
like
right
right
now,
the
the
tech
lead
role
in
a
sig
is
optional.
Do
we
make
that
potentially
mandatory?
B
Is
that
something
that
should
be
mandatory
across
six
and
then
some
thoughts
and
discussions
around
life
cycles
around
these
roles?
So
is
there?
You
know
there
are
a
number
of
sig
chairs
or
tech
leads
that
have
been
in
that
position
for
a
significant
amount
of
time.
Is
there
some
sort
of
life
cycle
policy
that
we
should
have
for
those
type
of
roles
to
allow
for
basically
to
allow
those
the
the
folks
that
are
in
those
roles
having
like?
B
Okay,
here's
like
a
defined
like
potential
exit
period
that
either
you
need
to
like
re-run,
re-figure
things
out
or
just
you
know,
make
sure
that
you
have
a
succession
plan
in
place.
There's
been
some
healthy
discussion
on
a
number
of
these
issues
on
the
the
issue
itself,
but
I
think
it
was
wanted
to
be
brought
up
here
to
kind
of
continue
these
discussions
and
see
if
there's
any
conclusions
that
can
be
drawn.
D
E
Thought
that
was
a
good
summary.
It
seems
like
there
are
three
sort
of
categories
or
directions.
This
is
going.
One
is
like
the
mechanisms
for
proposing
and
selecting
leads.
The
second
is
the
the
terms
and
term
limits,
and
then
the
third
was
sort
of
like
the
tl
role
being
optional
mandatory.
E
I
think
all
of
those
are
great
conversations
to
have.
I
think
it's
difficult
to
have
all
three
at
the
same
time,
so
I
I
wonder
if
we
could
maybe
split
those
into
distinct
things
and
focus
on
the
maybe
order
them
like
say,
which
ones
do
we
think
are
most
important
and
then
drive
one
of
those
to
a
conclusion.
A
All
right,
I'm
plus
one
as
well
right.
Do
we
have
any
conclusions
on
any
of
the
three
items
that
jordan
mentioned
either
mechanism
term
limits,
tl
roll.
F
A
E
That
oh
go
ahead.
B
I
I
just
wanted
to
ask
the
question
like
when
we
talk
about
required.
The
one
thing
that
is
not
clear
from
the
issue
is
by
required.
Does
that
mean
a
an
individual
can
hold
both
roles
at
the
same
time,
because
right
now,
the
way
our
our
governance
docs
are
worded?
If
somebody,
if
a
if
a
particular
sig,
lacks
a
tech
lead
role,
then
the
responsibilities
that
would
normally
be
a
part
of
that
role,
kind
of
devolve
back
to
the
chairs.
B
If
we're
talking
about
requirement,
do
we
want
to
allow
somebody
to
hold
both
roles
at
the
same
time?
Does
that
defeat?
The
purpose?
Does
it
matter?
I'm
not
sure.
E
I
don't
know
if
you're
using
hands
paris
or
we
should
just
jump
all
over
each
other
yeah.
E
Okay,
all
right,
I'm
in
favor
of
requiring
a
name
associated
with
tech,
lead
just
to
be
clear
about
function
across
cigs
like
it's
really
confusing.
When
someone
says
oh
acting
as
chair
of
x,
I
am
doing
why
and
we
have
to
go,
look
and
say:
oh
well,
does
this
sig
have
tech
leads?
E
Have
they
separated
out
particularly
role?
Oh
you're,
a
chair.
This
is
more
a
tech
lead
decision.
It's
just
confusing,
like
you
need
it's
sort
of
confusing
to
understand
who's,
doing
what
to
ease
the
transition.
I
think
it
would
make
sense
to
say
sigs
that
currently
just
have
one
person
in
that
role.
E
That
person
can
is
de
facto
serving
as
chair
and
tech
lead,
and
so
I
I
don't
want
to
increase
overhead
for
sigs
who
are
currently
being
successful.
So
I
would
say
the
same
individual
can
hold
both
roles,
but
we
need
to
recognize
its
distinct
responsibilities
and
that
that
makes
it
simpler
to
say
like.
E
Oh,
this,
all
the
tech
leads
do
x
and
all
the
chairs
do,
y
and
in
some
cigs
the
same
person
can
hold
both,
but
at
least
it
starts
to
clarify,
like
these
are
two
buckets
of
responsibilities,
and
if
you
want
to
do
both-
and
you
can
do
both
and
there's
no
one
else
in
your
sig
who
is
able
or
wants
to
do
that,
like
that's
fine,
but
it
makes
it,
it
makes
it
more
consistent
when
we're
working
across
things
and
just
understanding
like
all
right.
B
As
far
as
like
how
we
move
forward
on
this,
I
think,
like
you
know,
as
we
indicated,
I
think
we
should
kind
of
split
these
three
discussion
items
out
into
separate
like
three
separate
action
items,
but
I
wonder,
should
we
like?
Should
we
have
a
feedback
cycle
here
with
with
the
the
active
chairs
and
tech
leads
and
say,
like
hey,
you
know
we're
opening.
You
know
have
a
request
for
comment
for
this.
B
Like
period
of
you
know,
x
number
of
weeks,
please
give
us
feedback
on
these
specific,
these
three
specific
items
and
how
you
feel
about
them
and
how
it
applies
to
your
sig
and
that
kind
of
stuff
and
then
see
if
we
can
draw
some
conclusions
as
far
as,
if
there's
consensus
among
the
community
to
move
forward
on
these
on
these
three
items,.
B
Because
I
think
at
this
point
the
from
the
discussion-
that's
on
the
issue
right
now,
I
don't
know
if
I
can
draw
a
conclusion.
As
far
as
like
do
we
have
consensus
on
moving
in
any
particular
direction,
but
I
think
what
this
discussion
does
define
fairly.
Well
is
here's
the
three
key
suggestions
that
have
at
least
some
momentum
behind
them
that
could
improve
the
space.
E
B
I'm
generally
in
favor
as
well,
but
I
would
like
to
like
seek
feedback
from
the
from
the
the
chairs
and
tech
leads.
That
would
be
impacted
and
then
like
see,
if
there's
we,
if
we
like
populate
this
discussion,
a
little
bit
wider,
if
we
get
more
of
a
clear
sense
from
from
the
community,
if
they
back
that
that
as
well.
A
All
right,
so
what
I'm
hearing
is
we're
going
to
break
this
issue
into
three
dimms?
Do
you
want
to
take
that
as
an
action
since
you
originally
filed
it,
or
would
you
like
me
to
do
it
today
either
one
is
fine
I'll
put
james
paris
and
then
the
next
thing
I
heard
is
that
folks
want
chairs
and
tech
leads
to
weigh
in
on
each
separately
with
a
time
box
and
then
potentially
get
on
the
community
meeting
schedule
for
discussion.
A
E
I
will
note
we
didn't
talk
about
the
actual
mechanism,
for
how
leads
are
selected
or
proposed
so
like
having
terms
without
that
mechanism
is
a
little
weird,
but
I
I
do
think
there's
benefit
to
saying,
like
every
x
period,
like
leads
have
an
opportunity
to
step
aside.
You
know
reevaluate
re-up,
whatever,
like
even
with
our
current
selection
mechanisms,
but
but
I,
if
we
were
ordering
these,
I
would
probably
put
the
like
proposal
selection
stuff
ahead
of
like
strict
terms,
because
it
doesn't
make
a
lot
of
sense.
Otherwise,.
B
How
we
select
the
chairs
may
be
the
one
that,
like
we
need
the
most
feedback
on,
because
again,
looking
through
the
discussion,
that's
already
been
had
that's
the
one
that
that
at
least
my
interpretation
is,
I
feel
like
has
the
least
clarity
as
far
as
the
the
specific
mechanics
around
it,
and
while
you
know
the
the
prevailing
suggestion
on
how
we
could
do,
that
better
is
voting
the
the
the
problem
there
that
nobody
really
seems
to
have
a
clear
answer
is
then
defining
who
gets
a
vote.
B
D
Put
it
down
or
something
yeah
I
don't
know.
I
feel
like
with
all
of
these
things.
What
I
the
context
I
lack
is
data
to
help
understand
the
state
of
the
state.
So
we
all
off-handedly
mentions
that
you
know
some
things
do
this
or
that,
but
I
don't
have
like
a
table
or
I
have
not
read
your
wonderful
summary
of
the
awesome
annual
reports,
but
I'm
going
to
take
a
wild
guess
and
say
that
how
each
state
uses
their
leadership
was
not
something
that
rolled
up.
A
D
D
I
could
go,
read
that
and
be
corrected,
but
I
feel
like
okay
terms,
I
don't
know.
A
D
Long
any
of
the
chairs
have
been
around
the
overwhelming
thing
that
I
have
been
hearing
in
back
channels
is
like
what
specific
problems
are
we
trying
to
solve
with
this,
and
I
appreciate
that
we're
having
the
discussion
without
getting
into
those
concrete
issues,
but
I
think
some
data
on
some
of
this
stuff
might
inform
what
we
need
to
do.
G
A
D
Of
the
leads
who's
been
around
since,
like
I
would
also
wonder
what
the
enforcement
mechanism,
like
four
term
limits,
if
you
have
a
problem
child
like
me
who
just
has
been
around
forever,
I'm
happy
this.
A
D
Helps
if
I
can,
I
provided
data
on
which
state
students.
D
But
I
would,
I
think,
I'm
going
to
assume
you
all
are
having
the
discussion
in
private.
Perhaps
of
what
specific
problems
is
this
trying
to
address,
because
overwhelming
my
time
when
steering
taught
me
that
attempting
to
do
sort
of
top-down
mandates
requires
the
will
and
bandwidth
to
enforce
those
and
more
of
what
I
have
seen
happen
is
kind
of
a
less
a
fair
delegation
approach,
like
kind
of
like
letting
each
sig
do
what
is
most
appropriate
for
them.
D
And
balance
of,
if
their
behavior
meets
our
community
or
us.
A
A
All
right.
Thank
you,
y'all!
Our
next
one
is
the
rollsville
the
roles,
visibility,
pr
that's
on
sort
of
a
same
similar
as
we
get
into
like
members,
and
things
like
that
and
what
people
do
here.
Let
me
share
my
screen
I'll
go
ahead
and
give
the
extremely
quick
context.
A
This
is
a
pr
that's
addressing
roles.
The
problems
that
we
were
trying
to
solve
were
people
getting
visibility
within
the
project
that
are
doing
hard,
work
that
are
not
in
six
ammo
like
chairs
and
tech
leads
also
just
trying
to
establish
some
uniformity,
uniformity,
as
well
as
adoption
of
other
roles
within
other
cigs.
A
We
heard
from
chairs
and
tech
leads
that
this
would
be
helpful
as
well
as
other
members
of
the
community,
so
I'm
going
to.
Actually
I
tried
to
pile
two
things
onto
this
pr,
as
you
can
tell
so,
I'm
gonna
go
ahead
and
take
out
the
the
tech
lead
piece
based
on
comments
from
steering,
and
then
here
is
the.
This
is
really
where
the
meat
and
potatoes
comes
into
play
with
the
addition
of
the
other
roles
piece
in
sig
governance.
A
So
it's
just
listing
why
we're
doing
this
and
the
exam
and
links
to
example,
rule
books
for
other
sigs,
and
it
also
talks
about
how,
if
the
other
role
assumes
any
kind
of
duty
from
terror
tech
lead.
That's
not
temporary
example
running
meetings
full
time,
then
that
would
need
to
get
approval
from
steering
anything.
That's
taking
away
a
duty
from
a
chair
or
tech
lead
on
to
someone
else
would
need
to
be
approved
by
steering
everything
else
just
needs
to
be
on
a
sig's
readme.
B
G
Looks
good
to
me.
I
also
love
to
comment
about.
I
mean
we
discussed
this
in
some
previous
steering
meeting
that
we
would
send
an
email
to
kdf
with
one
week
lazy
consensus,
so
people
at
that.
D
E
I
think
this
is
largely
recognizing
something
that
some
cigs
are
already
doing
so
sig
release
architecture
are
two
examples
of
sigs
that
have
sub-projects
and
have
pretty
well-defined
processes
for
those,
and
what
this
is
trying
to
do
is
surface
that
and
make
that
visible
up
in
the
top
level
sig
document.
E
So
currently
it's
done
in
an
ad
hoc
way
in
an
unstructured
way
sort
of
in
the
markdown
box
for
the
sigs,
and
this
is
saying
that,
if
you're
going
to
have
roles
in
subprojects
like
put
them
here,
so
it
makes
it
more
discoverable
and
something
like
notifying
kdev,
like
oh
you're,
you're,
defining
things
for
your
sig
like
just
get
visibility
to
it.
That's
that's
my
impression.
D
Correct
no
context
or
or
like
super
old
school
take
is
like.
I
thought
this
is
what
revisions
206
charter
worth,
because
the
charter
sort
of
defined
like
the
deviations
from
the
standard,
governance,
thing
and
char,
and
then
I
thought
we
kind
of
had
an
established
process
for
changes
to
charter
that
need
to
sign
off
by
steering.
F
So,
at
least
there's
sorry
go
ahead.
Bob
we
worded
it
that
way
like
a
lot
of
the
roles,
you
know,
aren't
necessarily
direct
chartered
responsibilities,
the
ones
that
would
potentially
impact
a
chartered
election.
I
should
revise
it
a
little
bit.
F
We
asked
that
if
any
of
the
roles
of
the
chairs
or
tls
have
any
of
their
tasks
delegated
out,
it
would
be
a
chartered
update
with
that
part
requiring
approval
from
steering
the
other
part
can
be
a
bit
more
ad
hoc
like
it,
doesn't
necessarily
need
steering
approval
for
a
group
to
create
a
role
like
for
contributes.
Like
the
events
lead
for
a
contributor
summit,
I
I
don't
think
that
necessarily
needs
additional
steering
approval
for
that
sort
of
thing.
B
We're
trying
to
also
grant
clarity
around
like
what
changes
so
specifically
we're
calling
out
here,
if
you're,
making
a
change
to
a
a
role
or
responsibility
that
would
normally
be
a
chair
or
tech
lead
and
something
that
is
covered
by
the
charter
and
covered
by
the
sick
governance
process.
Calling
out,
like
those
things,
require
a
charter
change
and
if
it
doesn't
fall
into
that
bucket,
then
it
doesn't
require
charter
change
and
us
it
can
kind
of
go
ahead
with
it,
because
it's
within
the
within
the
scope
of
what
they're
already
responsible
for.
E
Right
so
aaron
to
your
concern
about
like
governance
changes.
This
is
primarily
oriented
at
roles
that
aren't
governance,
related,
they're
operations
related
and
so
we're
just
trying
to
make
it
clear
that
cigs,
who
can?
Who
do
that,
which
is
encouraged.
It's
a
good
way
to
organize
stuff
and
bring
people
in
like
how
we
recommend
they
do
that
and
operations
roles,
definitions
and
surfacing
that
that's
that's,
not
governance
that
doesn't
need
steering
approval.
It
doesn't
need
a
charter
change.
D
So,
yes
totally,
I
was
just
advocating
for
the
last
day
fair.
I
don't
think
this
is
totally
in
line
with
that,
the
like
little
whatever
niggle
I
have
in
my
head.
I
don't
know
what
the
right
word
for
that
is,
but
the
little
itch.
That's
that
I
want
to
scratch,
is
like
production,
readiness,
reviewer,
for
example.
D
It
seems
like
it's
taking
a
pretty
like
it's
kind
of
a
bottle
or
like
the
api
reviewer
process,
it's
kind
of
bottlenecky
and
that's
the
sort
of
thing
where,
like
I
feel,
like
that's
gotten
a
fair
amount
of
visibility
through
just
general
involvement
in
the
release
process.
But
I'm
wondering,
if,
like
those
are,
the
sorts
of
things
that
are
totally
fine
to
go
under
steering's
radar
or
if
that
kind
of,
like
kind
of
sort
of
being
putting
a
choke
point
on
the
project
in
those
sorts
of
areas.
B
I
would
say
that,
like
in
in
those
particular
cases,
at
least
my
my
initial
kind
of
like
view
of
them
is
those
are
within
the
scope
of
something
that's
already
dedicated
to
sick
architecture
as
part
of
their
charter
as
like.
These
are
areas
of
responsibility
for
cig
architecture.
B
How
sig
architecture
goes
about
naming
and
defining
those
roles,
at
least
in
my
my
view
at
the
moment
is
like
that
is
optic
architecture,
how
they,
how
they
end
up,
organizing
it
sig
architecture
is
in
a
unique
place
where
they
are
delegated,
like
cross-project
responsibilities,
and
they
have
that
ability
to
block
in
ways
that,
like
not
a
lot
of
sick's
have,
but
the
the
scope
of
those
roles
doesn't
necessarily
exceed
what
their
already
chartered
abilities
are.
B
So
if
they
chose
to
organize
those
in
a
slightly
different
way,
then
it
doesn't
to
me.
I
don't
necessarily
feel
that
that
that
needs
steering
approval.
I
would
hope
in
that
case
the
sig
architecture
would
be
making
sure
that
they
have
consensus
and
are
like
engaging
other
stakeholders
themselves,
but
at
a
like
core
governance
level,
I
don't
think
that
necessarily
needs
an
extra
layer
of
of
steering
review
as
long
as
they
aren't
exceeding
the
exceeding
the
bounds
of
their
charter.
A
Sounds
like
what
I'm
hearing
is
we're
taking
off
the
tech
lead
line
at
the
top
we're
going
to
open
up
a
new
pr
for
that
one
and
decide
and
discuss
there
for
that
line.
Put
the
musts
at
the
top
and
then
it
sounds
like
we've
got
a
general
consensus
to
merge
true
or
false.
H
Yeah,
most
of
us
are
here
waiting
in
the
wings
as
it
were.
H
So,
just
by
way
of
explaining
sort
of
the
background
behind,
what's
going
on
in
service
catalog
service
catalog,
the
project
itself
has
sort
of
fallen
into
disuse.
A
lot
of
the
various
stakeholders
in
the
project
have
moved
on
mostly
to
opera
operator
based
solutions
for
the
things
they
used
to
use
service
catalog.
For
so
it's
it's
just
seen
a
lot
less
use
these
days
than
it
used
to
in
the
past.
H
That
said,
there
is
still
a
need
for
a
little
bit
of
the
secret
sauce
behind
service
catalog.
The
idea
of
findings
of
there
being
some
programmatic
way
to
attach
provision
services
to
running
applications,
and
that's
what
the
service
binding
idea
really
is
about
is
about
taking
that
that
little
bit
out
of
service
catalog
and
implementing
it
in
a
generic
fashion
that
can
be
used
with
more
things
than
just
service.
Catalog.
H
G
So
I
forgot
who's
the
liaison,
but
I've
been
talking
to
a
service
catalog
folks.
One
thing
we
did
discuss
was
that
it
might
make
more
sense
for
service
binding
to
go
to
sick
apps
instead
and
maybe,
like
y'all,
could
elaborate
on
this.
So
like
it's
not
clear
to
me,
why,
then
we
talked
about
this,
but
like
maybe
for
the
rest
of
the
folks.
G
It's
not
clear
like
why
the
service
binding
project
needs
to
go
to
sex
service
catalog,
because
if
I
understand
correct,
there
isn't
really
a
coupling
between
the
two
like
the
service,
binding
project
and
service
catalog,
because
none
of
them
depend
on
each
other
and
the
service
bindings
project
must
be
able
to
continue
to
buy
in
services
that
are
not
provisioned
by
an
open
service
broker.
Api.
E
I'll
jump
in
here
a
little
bit,
the
the
specification
itself
is
designed
to
act
as
a
bridge
between
the
service
world,
some
sort
of
thing
that
needs
to
expose
and
points
and
credentials
and
applications
and
therefore
doesn't
particularly
sit
in
either
right
like
it
does.
Actually,
its
scope
encapsulates
details
around
the
service
side
outside
of
applications
themselves.
E
So,
from
our
perspective,
when
we
first
started
exploring
and
reaching
out
to
sigs,
we
didn't
have
a
preference
for
either
one
we
reached
out
to
sig
apps
first
in
fact,
and
got
no
response,
and
after
a
couple
of
months,
without
a
response
there
we
reached
out
to
sig
service
catalog,
which
was
more
receptive
to
it.
I
don't
think
that
we
have
a
strong
preference
in
either
direction
for
where
we'd
like
to
land
it
feels
like.
In
both
cases,
sig
charters
will
need
to
be
expanded
to
accept
them,
but
we've
had
really
great
work.
E
E
Yeah
I
I
had
this
is
jordan.
I
had
been
on
the
charter
update
pr
review
and
most
of
my
questions
with
the
expansion.
I
started
having
trouble
sort
of
telling
for
a
particular
topic,
whether
it
would
fall
under
this
or
under
sig
apps,
and
so
I
I
also
had
similar
questions
about
like.
Would
it
would
it
be
simpler
to
sort
of
model
this
project,
or
this
external
repo
or
whatever?
E
As
like
a
subproject
of
sig
apps?
One
of
the
things
we
try
to
avoid
is
charters
that
overlap
in
unclear
ways
so
that
for
a
particular
future
decision,
it
makes
it
harder
for
someone
in
the
future
to
say.
Oh,
I
want
to
do
a
thing
like
do
I
go
to
sig
apps
about
this,
or
do
I
go
to
sig
service
catalog
about
this
and
so
right
now
the
current
state
of
stick
service
catalog.
Is
that
it's
very,
very
scoped
and
this
sort
of
makes
it
much
less
scoped.
E
So
I,
in
terms
of
just
a
benefit
for
contributors
as
well
like
the
overhead
of
running
a
sig
is
non-trivial,
and
so,
if
the
thing
you're
mostly
interested
in,
is
like
a
sigs
repo
to
do
stuff
with
and
like
a
way
to
tie
into
the
kubernetes
project,
a
subproject
of
an
existing
sig
is
probably
going
to
be
much
lighter
weight
for
you
and
give
you
all
the
same
benefits
of
being
able
to
like
exist
in
the
kubernetes
cigs,
repos
and
stuff.
Like
that.
E
Confusion,
I'm
not
sure
I
agree,
maybe
I'm
just
easily
confused.
I
mean
at
the
point
where
it
talks
about
enabling
application
developers
to
consume
cloud
providers.
E
Self-Hosted
services-
like
that's,
that's
very
general,
and
it
I
I
could
easily
see
it
either
being
under
sick
network
or
sick
apps,
like
sig
network,
has
the
sort
of
endpoint
service
discovery,
side
of
things
and
say:
gaps
has
like
the
application,
custom
types
and
and
ways
to
sort
of
have
a
define,
a
bundle
of
stuff
that
you
know
inject
in
configuration,
values
and
things
into
your
apps,
and
so
I,
the
the
goal
of
this
is
describing
seems
like
a
good
goal.
B
Yeah
and
the
just
to
jump
in
here
like
the
the
expansion
of
the
cir,
the
service
catalog,
like
charter,
like
as
as
the
charter
is
defined
today,
it's
very
specific
in
scope
that
it's
like
the
thing
that
you're
enabling
communication
with
is
like
an
off
cluster
service
and,
in
that
way,
you're
not
necessarily
overlapping,
with
apps
and
network
they're,
both
enabling
consuming
of
services
on
cluster.
B
So
the
the
specific
wording
there
around
expanding
to
like
configuration
and
discovery
and
connectivity
of
services
in
cluster.
That
to
me
is
like
the
very
specific
like
that,
takes
the
scope
from
like
being
very
closely
defined
to
very
wide
and
now
overlapping,
with
other
cigs
and
other
other
defined
responsibility
areas
in
apps
and
network.
B
As
far
as
as
far
as
those
pieces,
at
least
I
I
I
say
that
like
if
there's,
if
I'm
misunderstanding
like
I
would
love
to
hear,
if
there's
like
clarity
that
could
be
friend
like
it
is
like.
Is
that
actually
the
the
case
that
that's
what's
happening?.
C
Not
really
because,
basically,
the
the
idea
behind
this
is,
it's
still
about
provisioning,
say
stateful,
the
the
confusion.
I
think
that
the
most
the
biggest
confusion
is
caused
by
the.
C
So
when
we
refer
to
services
in
say,
osb
context,
which
is
why
I'm
saying
removing
the
usb
just
allows
you
to
tackle
the
exact
same
problem
that
as
bappy
does,
but
maybe
in
a
different
way,
that
is
more
native
to
kubernetes,
like
using
a
set
of
custom
resources
and
whatnot.
So
basically
we're
talking
about
so
in.
In
this
context,
a
service
is
a
database
or
a
message,
bus
or
something
like
that,
where
your
application
operator
would
say
hey
I
want.
I
want
this
message.
Bus
and
I
want
to
do
that
in
a
standard
way.
C
B
It
does
make
the
space
a
bit
clearer,
but
I'm
not
sure
that
it
necessarily
answers
like
the
the
more
the
most
pertinent
question
is
like.
Where
does
this
go,
and
I
think
you
know,
jordan
made
a
comment
in
the
chat
about
engaging
and
having
like
a
focused
discussion
on
this
between
apps
network
and
service
catalog,
and
try
and
understand
to
get
feedback
as
far
as
like
making
sure,
specifically
that,
like
each
of
the
three
sigs
and
their
respective
charters,
are
clear
that
we
know
okay.
B
So
in
this
this
case,
where
does
this
particular
effort
go?
And
where
is
I
hopefully
minimize
overlap
and
where
there
is
interaction,
making
sure
that
there
is
like
very
clear,
clear
guidelines
around
that?
As
far
as
like
when
one
group
needs
to
interact
with
another
group,.
G
Aaron
was
making
fine
in
the
chats.
I
thought
he
would
be
interested
in
talking
about.
D
It,
oh
I
don't
know
yeah,
I
I
I
just
there's
a
thing
called
a
working
group
that
allows
well
specifics
to
collaborate
on
an
ongoing
basis
on
some
kind
of
effort.
For
example,
there
was
the
apply
working
group
which
helped
implement
service,
not
apply,
which
required
collaboration
between
api
machinery,
and
actually
I
don't
know
what
other
six
but
other
things
I'm
wondering
if,
like
essentially
I'm
kind
of
wondering
what
the
concern
is
over
the
idea
of
what.
D
If
the
service
catalog
was
not
a
cig
anymore,
like
what
is
lost
by
doing
that,
because,
if
there's
interest
in
just
really
kind
of
driving
this
forward
and
making
progress,
I
feel
like
we
have
seen
good
success
with
working
groups
and
it
can
also
kind
of
table
or
defer
the
conversation
about
like
yes,
but
where
should
this
really
actually
truly
live
like
that?
Can
be
kind
of
sorted
out
as
things
proceed,
but
it
it
is
very
clearly
a
concept
that's
used
for,
like
this
work
is
going
to
require
coordination
and
input
from
multiple
six.
B
Like
to
the
the
the
service
catalog
and
service
binding
folks,
like
specifically
like
what,
what
is
the
goal
as
far
as
what
we're
trying
to
find,
are
you
looking
for
a
permanent
home
for
an
existing
piece
of
of
software?
Is
there
like,
or
is
this
more
like
a
design
like
hey?
We
have
a
design
that
we
need
to
go
in
and
implement
and
want
to
coordinate
between
groups
like
where
are
we
as
far
as
the
maturity
curve?
For
this,
this
particular
initiative.
E
So
I'd
say
from
the
from
the
service
binding
specification,
we're
quite
mature
at
this
point
relatively
stable
and
we're
looking
for
a
home
inside
of
kubernetes
to
land.
We
think
that
the
service
catalog
is
a
good
option
for
that.
Right,
like
fundamentally
I
I
agree
with
constantine
like
this-
is
just
another
variant
of
how
do
I
get
credentials
to
an
application
right?
It's
not.
E
The
only
place,
certainly
like
I'll
I'll,
definitely
accept
that,
like
apps
cigaps
is
another
good
place,
but
I
think
one
of
the
holdups
here
is
if
we
do
choose
to
land
or
if
you
know,
if
we're
adopted,
we
want
to
be
adopted
by
service
catalog
service
catalog
does
require
an
expansion
of
their
charter
to
sort
of
make
that
work.
B
Yeah
that
makes
sense
like
because
the
the
the
the
gray
area
that
exists
today
for
this
particular
initiative,
I
think
we're
probably
going
to
need
some
charter
changes
somewhere,
anyways
just
again
like
if,
if
we're
going
with
like
finding
a
permanent
home
for
this,
I
think
somebody's
probably
going
to
need
a
charter
change,
no
matter
what
to
to
enable
that,
but
yeah.
E
E
F
Other
place
that
might
honestly
be
a
good
home,
for
this
would
be
the
cncf
if
it
is
just
a
spec,
well
spec,
in
a
reference
implementation,
especially
if
it
doesn't
quite
align
with
a
kubernetes
sig
directly.
E
Yeah,
I
think
one
of
the
reasons
kubernetes
directly
seems
appropriate
for
us
is
it
is
the
entire
specification
is
built
on
a
foundation
of
kubernetes
isms
right?
It's
not
something
that
could
more
broadly
exist
in
the
real
world.
It
specifies
crds
and
the
interactions
of
controllers-
and
you
know,
depends
on
you
know
all
of
sort
of
the
mechanics
of
the
kubernetes
platform
itself.
In
order
to
be
useful
for.
E
I
did
want
to
bring
up
one
one
more
point
and
this
this
was
actually
what
surprised
me
a
little
bit
when
I
saw
the
pull
request,
bring
to
expand
the
charter
service
catalog
the
service
catalog,
stick
in
general
has
sort
of
been
less
active,
and
so
it
surprised
me
to
see
an
expansion
of
a
sig
that
I
I
don't
know
that
there
are
like
up-to-date
recorded
meetings
and
sort
of
the
annual
report
process
that
just
went
through
like
that's
not
completed.
E
Yet
I,
and
so
I'm
I'm
hesitant
to
expand
the
charter
for
a
sig
that
either
is
has
been
less
active
or
just
is
you
know
the
people
in
leadership,
they're
oppressed
for
time,
and
so
I
know
you
said
you
would
approach
to
the
gaps
about
this,
but
stick
apps
has
been
more
active
than
sig
service
catalog,
and
so,
if
all
you're
looking
for
is
a
home
for
this
project,
I
would
tend
to
lean
towards
sick
apps.
E
Just
because
there
are
more
people
involved
there
and
it
has
been
more
active,
but
but
I
think,
pulling
pulling
in
the
folks,
music,
apps
and
sync
network
just
to
make
sure
there's
clarity
about
what
this
is
and
would
be.
A
good
next
step.
A
All
right-
and
that
ends
this
discussion,
but
let's
wrap
this
up
with
some
things
that
we
need
to
take
away.
Can
we
trust
the
liaisons
for
apps
network
and
service
catalog
to
bring
this
together
in
an
issue.
A
To
get
the
feedback
is
that
a
good
next
step
and
then
looks
something.
E
A
E
Probably
tag
them
into
the
charter
change
and
then
maybe
set
up
a
in-person
meeting
to
force
a
force
of
time
bound
on
it.
A
Zoom
and
then
it
sounds
like
there
might
be
some
discussions
around.
Could
this
be
a
working
group?
Could
this
be
hosted
in
cncf
and
should
service
catalog
be
as
sick.
B
Yeah,
I
think
those
are
orthogonal
the
the
core
issue,
but
like
questions
that
should
be
asked,
I
think
it's.
If
I
remember
correctly,
I'm
the
liaison
for
service
catalog
bob
is
apps
and
derek
is
network.
A
All
right
so
erin,
I
just
bumped
you
up,
because
we
are
running
out
of
time
so
aaron
you
filed
an
issue
for
google
workspace
automation
and
you
wanted
to
talk
about
it.
D
Yeah:
apologies,
if
you
all
hear
the
fire
trucks
going
by
okay,
I
come
to
you
hat
in
hand.
First
asking
who
here
has
read
the
issue
from
steering
and
is
familiar
with
it:
three
hands.
Okay,
the
context
for
everybody
else
is
that
there
is
a
we
used
to
call
it
g
suite.
It's
called
google
workspace.
Now
it
is
a
thing
that
handles
calendars,
emailing
lists
and
could
handle
a
whole
a
whole
bunch
more
like
google
drive
and
auditing
of
document
access,
and
things
like
that.
D
I
believe
it
is
also
kind
of
the
keys
it
is
perceived
as
the
keys
to
the
kingdom
to
like
the
kubernetes
dot,
io
name.
Like
the
gcp
organization,
we
have
called
kubernetes.io,
which
hosts
all
of
the
community
project
infrastructure
that
is
funded
by
the
cncf,
is
tied
to
this
workspace
and
historically
it
it
has,
I
want
to
say,
like
four
or
five
super
admins,
which
are
people
who
are
capable
of
doing
anything
with
it.
D
Three
of
those
people
are
kubernetes
steering
committee
members,
one
other
person
is
igor
and
there
may
be
one
other
person
from
the
cncf
that
I'm
not
aware
of.
I
used
to
be
one
of
the
older
holders
of
the
keys
to
the
kingdom
when
I
was
on
the
steering
committee
and
I
helped
out
dims
set
up
sort
of
automation,
around
management
of
mailing
lists
at
the
kubernetes
dot
in
using.
D
A
D
A
burden
for
them
when
it
comes
to
managing
the
google
workspace
that
give
the
keys
to
the
kingdom
too.
Some
things
that
I
know
are
our
pain
points
are
like.
The
management
of
the
majority
of
our
mailing
lists
is
not
great,
because
most
of
them
are
on
the
public.
D
Google
groups,
instead
of
our
google
workspace,
google
groups
thing
and
theoretically,
the
automation
that
like
dims
and
I
helped
develop,
might
just
do
that,
but
it
might
not
quite
work
at
scale
and
it
might
not
quite
provide
all
of
the
permissions
we
need
to
do
this.
We
start
talking
about
doing
groups
with
hundreds
and
hundreds
of
members.
D
We
may
end
up
getting
slapped
with
like
email
emails
on
github
type
stuff,
but
essentially
I
would
have
broadened
it
from
there
to
be.
D
Like
you
know,
I
think
it'd
be
really
great
if
every
sig
had
like
a
shared
drive
and
documents
lived
on
that
shared
drive,
so
that
we
didn't
have
to
worry
about
documents
magically
going
away
when
some
person
deleted
them
from
their
personal
g
drive,
or
I
want
to
make
sure
that,
like
I
have
this
hope
and
dream
someday,
because
I'm
somebody
who
works
on
kubernetes,
if
you
could
use
like
animal
to
manage
our
calendars,
I
think
that'd
be
really
cool
to
do
like
a
github
based
thing.
D
We
could
just
open
up
a
request
into
the
ama
file
and
have
it
make
the
calendar,
appointments
and
stuff.
So
I'm
thinking
of
stuff
like
that,
and
then
the
other
thing
is
just
specifically
from
a
category
perspective.
I
am
finding
that
there
is
troubleshooting
and
introspection
that
we
cannot
do,
because
we
don't
have
sufficient
permissions
to
dig
into
the
group's
apis
and
a
few
other
things.
So
when
I
get
paid
with
troubleshooting
requests
for
like,
why
cannot?
Why
can't
I
access
this
particular
cluster?
D
I
can't
use
this
wonderful
tool
called
like
iam
troubleshooter
that
can
specifically
enumerate
which
permissions
a
person
has
blocks
at
the
wall
of
google
group
stuff.
In
the
issue.
I
have
a
proposal
that
I
was
moving
on
a
while
ago.
It's
not
really
fully
formed
when
I
shopped
it
around.
I
got
a
whole
bunch
of
ideas
about
like
what,
if
you
did
this,
what
if
you
did
that
so
I'm
coming
to
you
hat
in
hand
asking
like.
D
I
want
to
turn
that
proposal
into
something
that
is
more
fully
formed
and
baked,
but
in
order
for
me
to
go,
do
the
research
to
figure
out
exactly
what
scope
of
access
I'm
asking
for
I'd
like
to
get
an
account
as
a
super
admin,
specifically
because
it's
kind
of
a
pain
in
the
butt
to
create
new
service
accounts
and
then
link
them
to
the
appropriate
scopes
for
the
appropriate
level
of
api
access?
It's
a
bit
of
a
song
and
dance,
and
I
feel,
like
the
current
three
holders
of
those
keys,
are
a
little
bandwidth
constrained.
A
D
As
my
carrot
and
then
sort
of
my
time
and
status
as
an
emeritus
member
as
a
way
of
proving
that,
like
I
will
not.
A
A
Jordan,
do
you
want
to
say
your
question?
I
can,
if
you
are.
E
I
I
like
the
idea
I
like
the
goal.
My
only
question
in
this
is
lack
of
knowledge
of
what
this
means
like.
What
does
this
mean
for
private
groups?.
D
That
is
specifically
why
I'm
suggesting
I,
and
only
I
have
the
the
permission
to
do
this
super
evident
thing
for
a
bit
because
it
could
be
super
admins
might
be
able
to
see
that
I
don't
know.
I
think
I'm
just
asking
like
if
you
are,
if
you
are
willing
to
trust
me,
that
I
won't
go
digging
around
with
that
stuff,
specifically
interested
in
what
will
avoid
all
of
that
from
an
automation
perspective.
Bob
has
a
hand
too.
F
Yeah
for
for
what
it's
worth
superman
admins
cannot
see
it
unless
they
explicitly
add
themselves
to
the
group,
so
they
there
is
like
an
audit
trail
of
any
of
that
stuff.
It's
the
same
thing
with
access
to
like
the
code
of
conduct,
private
drive
that
is
not
accessible
to
an
admin
that
they
have
to
be
added
to
the
group
first
to
be
able
to
see
it,
and
that
leads
the
trail
yeah.