►
From YouTube: Kubernetes Public Steering Committee Meeting 20190410
Description
A
Share
my
screen
for
those
who
don't
know
I
talked
before
last
time
about
boasting
for
the
rest
of
my
stun
and
then
writing
up
the
boasted
dock
and
handing
it
off.
My
objective
was
to
kind
of
be
a
little
bit
more
execution
oriented
start
to
treatment
while
still
and
I
just
kind
of
try
to
get
us
rolling
with
a
cadence
we're
kind
of
trying
to
burn
things
down
for
folks
who
saw
I
sent
an
email
yesterday
to
try
to
follow
up.
If
you
have
a
sign,
so
I
started
curating
some
of
the
agenda
items.
A
What
I
typically
do
in
some
of
the
other
meetings
too
is
I,
have
follow
up
on
action
items
it's
to
make
sure
that
we
kind
of
are
doing
what
we're
saying
or
doing
Paris
and
Brandon
and
Michelle
did
you
have
a
chance
to
discuss
the
CNC
FG
sweet
issue?
We
talked
about
last
time.
I
knew
there
was
a
ticket
that
was
supposed
to
be
filed,
but
I
don't
know
if
Brandon
and
Michelle
didn't
say
that
they
had
any
visibility
on
it.
A
A
C
Been
fantastic,
we
have
Domini
working
here,
the
college
you
know
she's
working
on
this
year's
draft
out
and
here's
a
few
other
folks
who
volunteered
to
review
would
put
together
a
Dougal
group
Oh
for
the
folks
who
expressed
interest.
Yes,
who
had
about
a
half
dozen
people
expressed
interest
in
working
on
this
sort
of
task
in
the
future.
So.
D
C
E
D
A
C
F
We
used
to
I,
don't
know
if
the
word
corn
doesn't
show
up.
We
don't
have
a
supermajority
here.
We
have
a
majority,
but
not
a
supermajority.
Oh
wait.
Maybe
now
will
you
do
that
now
that
Michelle
is
here
supermajority
supposed
to
the
two-thirds
right
anyway,
I,
don't
think
anybody
is
disagreeing
with
the
consensus
there.
I
kind
of
would
have
just
started
the
thread
off
and
if
we
have
no
verbal
objections
here,
I
think
we
can
proceed.
A
G
Awesome,
thank
you
and
three
and
we
started
this
effort
in
January
this
year
and
we
wrote
down
the
proposal
in
terms
of
why
we
think
consolidating
the
cloud
providers
would
make
sense.
Basically,
what
we
are
proposing
is
all
the
cloud
provider
6
will
become
sub
projects
under
the
cloud
provider
and
currently
the
sub
projects
at,
for
example,
Sega
WS
has
7
sub
projects,
they
would
all
move
under
C
cloud
provider
and
they
would
be
tagged
with
provider
tagging
which
sort
of
reflects
which
cloud
provider
the
sub-project
belongs
to.
G
But
this
would
also
give
us
an
opportunity
to
streamline
and
standardize
the
processes
with
respect
to
documentation,
release
cadence
for
all
the
out
of
tree
features
and
also,
as
we
started,
building
a
lot
of
cloud
controllers.
We
realized
that
this
might
be
a
better
approach
to
host
all
the
controllers
under
one
project.
G
So
the
reasons
for
doing
this
would
also
lend
itself
well
to
the
stability
of
the
core
code
base
and
we
wanted
to
make
sure
that
the
test
grade
efforts
that
we
did
in
sake
AWS
also
moves
across
each
of
the
sake
and
we
can
again
host
them
under
cyclic
providers.
So
that's
all
the
reasoning
that
we
have
written
out
there.
G
G
Most
of
this
actually,
when
we
started
this
effort
had
at
least
the
cluster
API
project,
I'm,
not
sure
and
under
you
can
correct
me
on
this.
The
reason
I
said
that
one
of
the
six
logistic
be
in
there
may
not
have
a
project
is
because
I
believe
that
cluster
API
project
was
move
under
was
going
to
be
moved
under
SiC
cluster
lifecycle,
but
the
rest
of
the
projects
have
a
rest
of
the
six
have
one
or
two
sub
projects
at
any
time.
Yes,.
I
G
One
is
the
entry
cloud
provider
into
out
of
the
tree
cloud
provider.
That
is
a
separate
effort
altogether,
because
there
are
some
interfaces
that
need
to
be
re-engineered
and
that
effort
is
happening
in
signal
provider
right
now
with
all
the
providers
working
together.
Yes,
but
there
are
some
smaller
sub
projects
that
can
end
up
as
controllers,
for
example,
the
ARB.
D
G
G
H
D
G
So
that's
a
proposal
we
are
suggesting
again.
This
is
something
that
we
have
to
discuss
with
you
all
and
also
get
a
get
agreement
on,
but
this
might
help
because
we
still
want
to
keep
our
user
group
being
supported,
but
we
don't
want
to
really
wait
for
the
user
group
governance
to
happen
before
collapsing
the
sub
projects.
G
G
The
third
aspect
was
the
quarterly
community
updates,
instead
of
having
each
said,
come
and
give
quarterly
community
updates.
Maybe
we
have
an
umbrella
as
the
cloud
provider
update
and
that
usually
remember
that
you
give
three
sixes
lot
to
speak
in
this
particular
format.
We're
suggesting
that
maybe
signal
provider
can
provide
an
umbrella
update
in
one
community
meeting
and
that
frees
up
some
slots
for
other
sales
or
other
discussions
as
well,
and
the
other
item
is
github
labels
and
notifications.
G
G
G
So
we
have
an
open
issue
and
that
is
being
tracked
by
sig
release.
I
think
Aaron
told
me
that
1.15
we
should
make
a
decision,
but
I'm
not
sure
when
that
decision
would
be
made.
But
the
idea
is
we
try
to
come
to
a
consensus
and
you
signal
provider
to
drive
that
consensus
into
each
of
their
provider.
Sub
projects
and
I
already
talked
about
test
rate
hierarchy.
A
A
J
E
K
G
The
idea
was
to
make
sure
that
nothing
changes,
which
means
the
current
co-chairs
I'll
just
take
ckw-
is
an
example.
The
current
co-chairs
will
remain
the
co-chairs
and
the
maintainer
and
the
reviewers,
which
is
me
just
in
a
couple
of
other
people
who
are
writing.
The
code
are
defined
in
the
owners
file.
We
need
bi-weekly
as
usual.
Nothing
changes,
it's
just
that
the
readme
doc
for
cig
AWS
would
not
exist
as
a
separate
standalone.
What
would
happen
is
it
would
go
under
the
meeting.
G
I
What
are
now
the
sub-project
associated
folks
like
who
would
be
affiliated
with
AWS
or
IBM
or
GCP,
or
any
of
the
other
individual
clouds,
like
their
leadership
responsibilities
and
their
individual
sub
project
does
not
change,
but
there's
no,
like
tech
lead
over
the
whole
cig.
It's
just
this
set
of
chairs
that
are
there
now.
Is
that
a
fair
summary.
H
And
so
we're
following
the
steering
committee
template
for
that
kind
of
falls
under
all
this.
What
falls
over
all
the
SIG's
right
and
that
has
specifically
calls
out
tech,
lead
sub
project
owners
members,
and
so
we
would
be
following
that
for
each
cloud
provider,
and
so
naturally,
we
would
assign
all
the
as
Nisha
mentioned.
We
would
assign
all
the
existing
chairs
for
each
provider
as
tech
means
under
each
sub
project,
representing
a
classified
I.
F
Think
you
just
answered
my
question:
I
can
just
slow
today
so
to
use
AWS
as
an
example.
Currently
there
are
a
number
of
sub
projects
associated
with
AWS,
such
as
the
IMF
educator,
the
ale,
the
ingress
Controller,
the
encryption
provider,
the
EBS
CSI
driver
the
eff
SCSI
driver
in
the
fsx
CSI
driver.
Are
we
suggesting
that
the
same
set
of
people
are
in
charge
of
all
of
those
code
bases,
or
are
we
suggesting
that
and
there's?
G
E
H
E
F
So
I
feel
like
as
written
the
duck.
The
proposal
does
not
make
it
clear
to
me
that
you
were
planning
to
collapse
all
of
the
repos
into
a
single
sub
project,
so
I'm
trying
to
be
careful
with
my
language
here.
The
provider
sub
project
hierarchy
bullet
number
six
says
that
the
current
sub
projects
will
be
transferred
over.
It
sounds
like
what
you
are
suggesting
is.
F
G
Okay,
so
to
clarify
cg
AWS
have
the
sub
projects
that
you
just
listed
right,
Aaron
we're
going
to
move
those
sub
projects
directly
under
signal
provider
and
tag
it
as
AWS.
That's
it
and
going
forward.
That
is
a
new
repository
under
sick
cloud
provider.
Now
it
would
not
be
sick
cloud
provider.
Has
a
sub
project
called
six
EWS
with.
G
F
F
A
G
G
H
Is
something
that
we
floated
on
before
and
one
of
the
reasons
why
we
didn't
follow
through
with
it
was
because
the
the
current
signal
structure
and
the
tooling
we
used
in
the
community
repo
didn't
support,
doing
this
without
having
to
collapse
all
the
owner's
files.
And
so
we
wanted
to
respect
all
the
individual
owner
spells
that
we
have
today,
which
is
why
we
kind
of
went
with
this
model.
H
A
I
was
gonna
mention
earlier
on.
We
kind
of
lack
a
better
formalization
for
this
type
of
hierarchy
inside
of
our
charters
and
I.
Think
it's
probably
on
us
to
follow
up
I.
Don't
think
that
should
stop
this
effort
so
long
as
it's
clear
to
the
parties
involved,
but
I
do
think
we
should
clean
out
up
from
a
governance
model
perspective
so
that
it's
clear
what
we
try
to
accomplish,
and
it's
a
it's
a
pond
steering
to
make
sure
that
we
do
this.
G
G
L
Think
the
one
thing
I
do
want
to
say
is
that,
like
you
know,
we
purposefully
didn't
want
to
be
too
prescriptive
about
the
charter
for
for
SIG's
to
leave
room
for
stuff
like
this
and
I.
Think
there
are
gonna,
be
SIG's
that
that
don't
fit
the
pattern
where
you
know
there
are
special
considerations,
so
I
think
this
is
totally
in
line
with.
You
know
the
the
way
that
we've
talked
about
SIG's,
and
it
just
means
that
it's
gonna
be
a
little
bit
more
work
to
sauce
out
the
Charter,
but
I
think
it's
it's.
F
Yeah
I
think
I'm.
Ok
with
that,
like
leaving
I
guess
it
seems
like
we
could
maybe
move
in
two
steps.
We
move
everything
over
as
is,
and
then
as
a
follow-up.
We
could
talk
about
how
to
effectively
collapse
things
that
still
gives
you
sort
of
the
governance
structure
that
you
need,
where
you
have
some
overarching
individuals
who
have
insight
where
oversight
of
a
particular
cloud
providers
interests.
But
you
have
sort
of
tech
leads
for
each
individual,
repo,
I,
just
yeah
I,
don't
know
infinitely
nesting
hierarchies
of
things.
F
F
A
F
G
F
H
F
H
So
there
so
we
explicitly
didn't
include
user
groups
yet
because
we
have
the
impression
that
the
definition
of
user
groups
is
still
being
formulated,
and
so
many
of
the
members
in
sequel
provider
are
in
the
user
group
governance
mailing
list
and
we
are
going
to
follow
up
and
make
sure
we're
involved
in
a
lot
of
the
early
discussions
around
what
you
should
look
like,
and
we
do
intend
on
being
one
of
the
earlier
adopters
of
these
groups.
And
so
the
intention
would
be
easy.
I
use
a
gripper
cloud
provider,
yeah.
E
E
So
we
definitely
need
that
there,
we
just
don't
know
who
will
show
up
to
help,
formulate
form
the
user
groups
and
lead
the
user
groups,
whether
it's
the
same
set
of
people
currently.
But
this
is
on
the
development
side
right.
So
we
need
actual
operators
and
people
like
that
to
help
see
that
I
think
you.
A
G
I
think
the
thinking
was
that
the
same
co-chairs
for
the
sake
provider
would
work
in
seeding
the
user
groups,
because
we're
aware
of
how
each
of
the
sub
projects
are
being
used
by
our
audience
and
by
being
part
of
the
governance
structure
which
Phil
is
driving
with
Domini.
We
were
hoping
to
simulate
that
structure
into
the
user
group,
but
as
a
second
phase
of
this
effort,.
A
F
Rather
not
vote
on
it.
I'd
love
to
live
in
the
world
where
the
cigs
were
empowered
to
make
this
decision
by
themselves.
It
looks
like
they
have
built
consensus
to
do
it.
We
appreciate
them
running
it
by
us
to
make
sure
that
everything
looks
good
but
I
think
there's
anything.
We
need
to
do
to
get
in
your
way.
F
H
G
G
I
E
A
I
think
this
is
a
weird
distinction
that
we
should
probably
lean
an
architecture
to
help
formalize,
and
that's
really
steering
is
that
things
that
the
core
needs
should
have
some
guarantees
and
consistency,
things
that
fall
outside
the
core.
You
know
it's
it's
up
to
the
provider
or
the
safe,
determine
their
life
right.
Yeah.
L
I
M
It's
a
Clayton
yeah,
we're
in
the
same
room
together,
what's
an
expectation
or
someone
consuming
kubernetes
do
we
are
we
are
we
kind
of
letting
the
dandelion
seeds
fly
and
saying?
Well,
you
know
this
stuff
may
be
all
inconsistent
and
change,
and
we
trust
people,
but
if
it
is
like
talk
to
that
project
area
like
talk
to
the
snake
about
that
like,
what's
the
that
was
I,
think
the
heart
of
it,
and
it's
not
that
we
expect
that
I
expect
this
things
to
be
not
responsible.
M
M
You
know
from
a
project
level
perspective
as
a
steering
committee.
We
are
explicitly
embracing
the
idea
that
there
will
be
six
in
different
areas
that
do
different
things,
that
work
on
different
life
cycles
and
make
different
choices,
and
they
won't
always
agree
and
that
when
they
don't
agree,
that's
okay,
because
that
is
the
choice
we
were
deliberately
making
to
be
a
diverse
and
heterogeneous
culture
rather
than
a
monoculture.
Yeah.
L
Yes,
I
think,
there's
examples
where
folks
have
come
to
architecture,
saying
hey:
we
want
to
move
XYZ
and
decor,
and
we
said
what
does
it
really
mean
being
corps?
Can't
use
the
extension
mechanisms
you'll
be
able
to
move
faster
and
you
won't
have
to
go
through
this
gatekeeping
exercise
of
presenting
things
to
architecture
because
it's
within
the
sig,
so
we
really
want
to
be
able
to.
You
know,
empower
the
SIG's
to
be
able
to
do
the
thing
now.
I
I,
don't
disagree.
I
just
want
to
make
sure
that,
if
we're
changing
the
governance
structure
that
the
governance
structure
was
aligning
to
the
way
of
improving
what
I
think
in
architecture
we
had
raised
as
a
concern
and
then
I
agree
with
James
that
this
does
improve
it.
I
just
want
to
make
sure
that
we
all
felt
that
way.
I
E
A
Our
natal
box,
the
conversation,
I,
think
we've.
We
have
broad
consensus
on
the
original
proposal
and
we
we
did
a
little
bit
of
by
shedding,
which
was
good
to
talk
about
the
implications
of
what
broader
level
API
constraints
could
occur.
But
is
there
any
other
last
things
we
want
to
address
here,
or
should
we
move
on
I
just
want
to
make
sure
that
we're
we
keep
to
a
time
box,
so
we
can
get
to
the
other
things
and
if
we
need
to,
we
can
follow
up
with
action
items
right.
So.
G
G
What
the
prioritize
should
be
should
be
document
and
improve
the
entry
club
provider
or
wait
for
the
auditory
cloud
provider
to
finish
and
then
update
everything
I
think,
like
Annan,
said
it's
p0
for
us
this
quarter
or
this
1.15
cycle,
and
yes,
we
all
are
aligned
to
making
that
happen
and
but
just
to
also
clarify
most
of
the
sub
projects.
Right
now
are
pretty
much
out
of
tree
they're,
not
KK
at
all,
and
for
anything
that
is
linked
to
KK.
A
specific
example
would
be
NLP
support,
which
is
entry.
A
Like
to
I'd
like
to
move
on
just
because
you
know,
I
want
to
be
mindful
of
some
of
the
other
things
that
are
in
the
agenda
and
there's
some
other
things
that
are
not.
If
folks
want
to
follow
up
I
think.
Perhaps
we
should
have
an
action
item
to
follow
up
on
the
update
to
the
Charter
for
next
week,
as
well
as
the
action
item
for
Aaron
to
log
the
potential
issue,
and
then
we
can.
A
A
K
I
apologize
for
bringing
this
up
again
slack,
but
we
would
like
to
ask
steering
for
help
far
as
helping
find
a
home
for
slack
user
moderation
as
like
we're
having
a
hard
time
doing.
Socotra
beuter
experience
things
and
also
managing
the
moderation
of
slack
we've
kind
of
basically
put
a
finger
in
the
dike.
We've
expanded
the
policies
and
got
a
bunch
of
new
moderators
and
all
that
stuff
and
clearly
we
think
that
there
should
be
a
new
sig
and,
unfortunately,
a
lot
of
us
are
too
oversubscribed
to
like
launch
a
new
sig.
K
N
L
And
just
to
be
clear,
George
I
think
you
know
we
talked
about
this
a
little
bit.
The
ideas
that
contributes
would
help
set
the
tone
in
the
policy
for
sort
of
what
makes
the
kubernetes
community
with
kubernetes
community,
but
just
some
of
the
sort
of
implementation
of
that
policy
sort
of
making
it
effective.
That's
where
we're
looking
in
organizing
people
and
or
efforts
around
that
is
where
we're
looking
for
help
is,
that
is
that
right,
yeah.
K
So
it's
not
so
much
like
a
CN
CF
hire
a
bunch
of
moderators,
it's
more
of
like
we
have
policies
and
things
in
place
that
just
need
to
be
taken
to
like
that
next
level,
and
you
know
now
that
we
have
things
like
the
CNC
have
help
desk,
which
we
have
direct
access
to.
We
can
kind
of
have
like
measurable
inputs
and
outputs
of
like
hey.
K
We
really
need
this
aim
as
opposed
to
before,
where
we're
kind
of
not
really
sure
what
to
ask
for
what
not
to
ask
for
so
kind
of
working
through
our
charter
now
to
make
more
things
more
explicit,
but
that's
like
a
long
ongoing
process
that
we
still
need
to
work
on,
but
slack
felt
like
a
a
place
to
start,
because
that
was
a
problem
point
that
we've
had
recently
and
you
know
an
area
kind
of
where
we
could
start
to
move
the
ball
forward.
So.
K
F
F
Is
this
the
thing
that
so
like
I'm,
not
sure
this
necessarily
falls
in
in
that
wheelhouse,
because
I
feel
like
that's
about
engaging
in
users
of
all
ciencia
projects
and
just
so
I
understand,
I.
Think
what
we're
talking
about
here
is
like
I,
don't
want
to
live
in
a
world
where
there's
one
slack
or
kubernetes
contributors
and
there's
another
slack
for
the
end
users
of
kubernetes
I
feel
like
that,
creates
firewall
between
the
two
communities
and
part
of
what
makes
kubernetes
like
really
great.
A
N
To
be
asked
asked
what
a
proposal
template
would
look
like
that's
kind
of
like
two
steps
down
line
first,
it
would
be
like.
Should
this
be
a
sake?
Should
this
be
a
committee,
so
we
can
just
like
tease
that
out
a
little
bit
more
and
I
think
we
can
do
that
on
the
thread
or
on
a
mailing
list
instead
of
here
right,
okay,
glad
you
brought
it
up.
E
F
Felt
like
there
was
a
lot
of
conversation
when
we
initially
discussed
slack
saying
that
staffing
up
with
new
people
and
adding
some
automation,
we
all
were
openly
acknowledging,
was
just
to
use
George's
words
like
putting
some
more
fingers
in
the
dike,
and
we
were
doing
that
temporarily
until
we
found
like
what
the
ultimate
and
desired
end
state
would
be.
Is
this
that
document
proposal
of
the
desired
end
state
or
is
that
forthcoming.
N
A
Great
any
last
words
with
regards
to
this
I
should
move
on
I'm
once
twice
three
times:
I'm
gonna
try
and
skip
over
the
I'm
going
to
go
through
the
important
soon
that
are
in
the
backlog,
because
we
only
have
five
minutes
left
and
try
to
get
teased
out.
Updates
that
might
be
might
have
happened,
funding
and
budgeting.
This
actually
falls
in
line
with
this
conversation.
I
know
that
Brandon
and
Michelle
were
on
the
hook
to
do
updates
here.
Both.
N
J
A
question
about
the
ecosystem
project
governance-
one
I
I'm
just
curious
about
what
it
is
about
because
from
what
I
understand
it's
about
developing
policies
and
procedures
for
donated
code.
But
we
already
have
that
and
the
github
management
team
is
responsible
for
making
sure
that
the
policies
are
followed
and
also
doing
the
actual
migration.
A
F
A
D
Caitlin
is
going
to
start
a
editorial
team
which
will
be
good
and
that'll
have
different
guidelines
and
qualifications,
and
he
set
up
similar
to
the
Burmese
team
for
an
open
and
transparent
blog
process
and
then
also
come
up
with
even
more
blog
guidelines
that
are
more
refined
and
then
sig.
Docs
is
going
to
own
that
as
a
sub
project,
and
that's
a
project
will
then
own
the
content
to
Quogue.
A
Oh,
there
are
a
couple
other
things
heat
better
underneath
this
umbrella
issue.
I
know:
we've
had
it
assigned
for
a
couple
of
times.
Do
you
folks
think
that
you'll
have
a
chance
to
take
a
look
at
some
of
these
other
ones?
I
know
we
discussed
the
blog
for
quite
some
time
last
time,
but
there
are
a
couple
of
other
issues
that
are
kind
of
lumped
in
together
with
this,
it's
possible
that
we
just
retitled
this
one
to
deal
with
one
item
and
then
break
out
these
other
ones
as
needed.
E
A
Project
there
is
a
couple
other
ones.
Those
are
all
the
important
students
that
we
have
one
of
the
ones,
that's
been
long-standing.
What
that
we've
talked
about
and
we've
wanted
to
address,
we
got
one
minute
left.
Perhaps
you
can
get
a
minor
update
to
see
where
we're
at
with
code
of
conduct,
documentation.
N
D
N
A
Just
for
for
prodding
formal
identification
next
time,
what
what
do
folks
think
is
the
best
way
for
me
to
follow
up
on
individual
issues
before
the
next
steering
committee.
So
we
can
get
an
update,
so
I
have
to
like
chaser
went
down
in
the
meeting.
Would
folks
like
me
to
last
time,
I
sent
an
email
to
the
lists.
We
prefer
when
people
prefer
like
an
earlier
email
to
the
list,
or
what
do
you
like
me
to
ping
on
the
individual
issues
or
how
ship?
How
do
folks
prefer
me
to
Gary
we'll
hear
a.