►
From YouTube: Kubernetes Community Meeting 20180809
Description
This is our weekly community meeting, for more information check this page: https://github.com/kubernetes/community/blob/master/events/community-meeting.md
A
Well,
hello,
Cooper
nartz
good
morning,
good
afternoon,
good
evening,
wherever
you
are,
this
is
Arun
Gupta
I
work
for
Amazon.
This
is
the
kubernetes
community
meeting
and
will
be
posted
publicly
on
YouTube.
So
please
be
mindful
what'd,
you
say
what'd
you
hear
what'd
you
hear
what'd
you
eat.
Everything
is
being
recorded
now
as
a
quick
courtesy,
please
mute
when
you
are
not
speaking
so
we're
gonna
get
started
with
the
agenda.
Usually
before
that
actually
do
I
have
a
note-taker.
We
need
somebody
to
be
able
to
take
notes
for
the
meeting.
A
A
B
So
our
release
112
the
main
things
to
note
that
are
listed
there
in
the
minutes
for
people
to
read.
But
basically
a
summary
is
were
pretty
much
halfway
through
the
release
cycle
and
time
is
flying
by
26
days
to
code.
Freeze
code
freeze
will
be
September
4th
and
our
release
target
then
is
three
weeks
after
that
September
25th
we're
looking
to
cut
a
beta
next
week
and
create
the
112
release.
Branch
will
also
be
enabling
CI
on
that.
B
C
A
A
All
right,
I
guess
all
efforts
are
focused
on
the
major
release
of
112
at
this
point
of
time
and
thank
you
Tim
for
all
the
dates
and
everything
in
the
meeting
minutes
we'll
jump
to
the
sig
updates.
Now
so
the
order
that
I
have
listed
in
the
agenda,
the
first
one
is
sig
scalability
Sean.
Are
you
online.
F
A
E
E
We
are
creating
a
new
way
of
tracking
work
and
Sagarika
texture
does
a
number
of
things,
including
providing
consultation
on
significant
changes
to
kubernetes
a
lot
of
those
take
the
form
of
API
reviews
and
cap
cap
reviews
or
consultation.
So
Jace,
the
co-chair
of
cigar
texture
created
some
tracking
boards.
We
have
a
repo
in
kubernetes
things
called
architecture
tracking,
and
we
have
three
project
boards
there.
One
is
for
kept
tracking
one
is
for
API
review
tracking
and
one
is
for
conformance
test
review.
E
Tracking
figure
architecture
means
to
approve
any
additions
or
removals
from
the
set
of
conformance
test
for
kubernetes
certification
and
we're
trying
to
find
ways
to
better
track
that
work.
Notifications
pretty
much
don't
work
at
all,
at
least
for
me
so,
and
we
have
a
number
of
things
to
track.
The
cross
repository
white
caps
are
in
the
community
leepo
and
the
number
most
API
changes
are
in
the
kubernetes
repo,
but
not
all
of
them,
so
we're
creating
some
project
board.
E
So
if
you
actually
want
to
get
onto
the
cigarette
structure
radar,
the
best
way
to
do
that
is
going
to
be
to
get
it
into
the
project
boards
and
then,
if
we
need
to
schedule
it
and
to
put
it
on
the
agenda
for
some
cigars
picture
meeting,
we
can
start
having
that
discussion
and
definitely
also
feel
free
to
use
the
terminated
architecture.
Mailing
list
to
reach
out
to
us.
I,
mostly
can't
monitor
slack,
so
the
mailing
list
is
probably
going
to
reach
more
of
the
relevant
people
today.
E
A
G
G
G
So
that's
one
of
the
things
and
the
other
one
is
birth,
which
is
our
performance
dashboard
and
we've
kind
of
launched
like
1v1
points
ago,
release
of
the
performance
dashboard
and
its
publicly
visible
to
everyone,
and
it's
basically
a
dashboard
having
various
kinds
of
metrics
that
we
get
from
our
scalability
CI
jobs
and
we
run
scalability
jobs
from
scale
of
100
all
the
way
till
5,000.
And
we
measure
some
of
these
and
they
should
be
available.
G
With
you
so
this
this
shows
historical
data
on
how
different
metrics
look
like
the
main
ones
are
basically
the
like
resource
usages
of
various
components
and
latencies
of
API
calls
and
things
like
these.
So
that's,
basically
what
I
have
from
tool
side-
and
there
are
some
lists
of
performance
work
as
well,
which
we,
which
either
we
are
actively
doing
or
have
delegated
to
other
syncs,
and
there
are
a
couple
of
main
ones.
G
So
that's
not
now
replaced
it
with
what
I
made
some
preliminary
experiments
and
it
seems
like
we're
able
to
scale
to
as
much
as
100,000
namespaces
right
now
we
are
on
a
reasonably
a
big
cluster
with
32
cores,
and
so
so
that's
one
of
the
improvements
and
the
other
one
which
is
still
work
in
progress
is
keeper
node
heartbeats.
So
so
this
is
also
another
problem
which
happens
for
large
clusters.
Is
that
right
now
cubed?
It
sends
a
heartbeat
for
a
node
every
10
seconds.
G
So
for
a
5,000
note,
cluster
of
this
basically
means
every
10
seconds.
You
have
50,000
edits
to
the
node
object,
so
so,
when
this
gets
stored
in
at
CD,
because
it's
City
stores
was
Jim
revision
history,
it
occupies
a
lot
of
space,
and
that
is
that
that
that
is
a
serious
limitation
for
last
clusters.
So
Voith
it
was
working
on
KP
and
he
submitted
this
KP
to
move
the
heartbeats
to
a
different
API
which
basically
uses
what
we
have
for
lease.
G
So
it's
basically
moving
the
heartbeats
stuff
to
a
new
API
so
that
the
node
objects
don't
don't
form
too
many
revisions
in
its
CD.
But
they're
dedicated
heartbeat
objects
for
heart.
This
still
work
going
on
at
this
point,
I
think
he's
added
the
new
API
already,
and
the
ball
is
now
in
the
hands
of
signor
to
make
changes
on
the
cubelet
side
and
yeah.
So
these
are
the
main
performance
work
and
the
final
one
is
about
our
CI
testing.
G
We
are
trying
to
deflate
our
jobs
and
because
there
are
quite
some
flakes
which
are
on
necessarily
failing
some
of
our
large-scale
tests,
which
we
don't
want,
because
those
are
expensive
and
they
give
us
really
valuable
signal
and
they're,
also
not
too
frequent,
because
they
take
quite
a
while
to
run
so.
We
are
kind
of
deflating
those
tests
and
making
them
more
robust
and
also
potentially
solving
a
regression,
a
scalability
regression
which
we
think
might
be
in
1.12,
but
we're
yet
to
get
there
so
yeah
I,
guess
that's
all
from
scalability
Singh.
For
now.
A
A
All
right
awesome,
then
we'll
keep
moving
along
and
thank
you
for
everybody
who
else
who
is
actually
pitching
in
with
the
nodes
I'm
sure
Parris
can
give
out
t-shirts
to
them.
Let's
go
to
6c.
Why
Shawn
Sullivan
you
have
you
saved
some
slides
and
George
I.
Believe
you
have
the
slides
ready
to
go
all
right,
bingo.
F
So
one
of
the
major
efforts
for
60
Li
has
been
trying
to
fit
in
the
client
and
move
more
of
the
complicated
logic
into
the
API.
So
this
this
particular
issue
has
been
it's
been
going
on
for
several
years,
so
I
just
concluded
a
link
that
actually
points
to
this
issue
on
github,
that's
been
going
on
since
2015.
F
These
plugins
are
meant
to
be
get
styled
plug-in
in
in
the
where
a
particular
binary
will
be
in
a
path
and
the
environments
and
flags
and
parameters
will
be
passed
to
that
binary.
If
the
compiled
in
coop
code
isn't
doesn't
understand
that
and
it
will
find
that
plug-in
using
a
naming
convention,
I
suggest
you.
You
look
at
the
cap
to
to
find
out
more
about
that.
F
In
order
to
support
the
plug-in
authors,
we
have
refactored
it.
What
we
call
a
generic
CLI
options,
library,
it
hasn't
been
pulled
out
of
core.
Yet
but
it's
it's
we're
in
the
process
of
trying
to
provide
support
for
plugin
authors
with
this
particular
library,
and
then
I
also
give
a
link
to
what
we
call
Pru,
which
is
a
proposal
for
managing
plugins.
So
the
the
cap
that
I
mentioned
before
is
how
the
plugins
work
and
they
don't
address
any
of
the
management
issues
associated
with
with
plugins
there's
a
separate
proposal
for
that.
F
Okay,
so
I'd
like
to
for
those
of
you
who
haven't
heard
about
customize
its,
it
is
a
new
project
in
order
to
manage
our
declarative
config
in
a
way.
That's
that's
different
that
uses
patches
and
overlays
instead
of
templating
like
helm
and
so
I
didn't
want
to
go
too
deeply
into
this.
Just
let
you
know
that
this
is
a
new
sub
project
within
sixty
line,
and
actually
we
have
one
of
the
major
authors
here.
If.
F
You
can
also
just
google
customize
or
the
Kay,
it's
the
first
result
and
it's
a
great
tool
to
just
focus
its
laser
focused
on
the
notion
of
generating
different
environments
like
productions
and
staging
from
a
common
base.
So
it's
just
that's
exactly
what
it
does:
okay,
okay,
so
so
I
just
wanted
to
mention
before
we
finish
that
our
first
version
of
our
Charter
is
out
for
feedback,
and
we
have
a
link
to
that.
It's
an
other
say
in
the
community
repo.
F
I
F
E
I
can
talk
about
it.
Yeah
customize
provides
a
way
to
express
Oh
No
for
the
most
part
repackages
a
lot
of
existing
heat
controller
functionality,
which
previously
was
imperative,
like
you
could
say,
keep
control
patch
something
something
or
keep
control
able
something
something.
So
we
had
a
lot
of
requests
for
expressing
a
bunch
of
these
commands,
creating
big
Maps
trading
secrets
or
undeclared
lis.
So
customize
enables
you
to
do
that
and
effectively
while
we're
previously
separate
commands
or
command
line
swags
you
can
put
into
a
into
a
single
file
so
that
addresses
about.
E
Eight
to
ten
long-standing
requests
and
keep
control
now
in
terms
of
the
actual
capabilities
or
what
you
can
use
it
for,
and
that
really
depends
on
use
case.
But
what
it's
really
targeted
for
is
facilitating
composition,
where
you're
actually
need
to
merge
information
about
your
configurations
for
multiple
put
sources
and
for
people
who
don't
really
want
a
different
abstraction,
then
the
API
resources
they
actually
just
need
to
combine
information.
E
It's
really
targeted
at
that
use
case
and
it
son
opinionated
about
how
the
patches
get
generated
or
how
the
bases
get
generated
or
whether
you
just
write
them
by
hand.
It's
a
tool
for
merging
those
things
together
using
the
exact
same
schema
as
the
API.
So
there
is
potentially
some
overlap
for
Elm,
there's,
also
a
blog
post
from
dick
iglesias
about
how
you
can
use
the
two
together.
If
you
need
to
do
light,
customization
and
you
know
and
you're
familiar
with
the
kubernetes
api,
customized
provides
an
easy
way
to
do
that.
Thanks.
F
E
If
you
look
in
the
community
repo
B
there's
a
document
called
for
Denny's
repositories
that
indeed
that
describe
this.
Basically,
we
are
moving
away
from
the
communities.
Incubator,
org
and
we
created
this
community
SIG's
org
to
give
SIG's
may
be
easier
for
SIG's
to
create
repositories
for
their
ongoing
work
as
needed
as
we
move
away
from
a
monolithic
repository
through
the
nineties,
everybody's
like
too
many
repositories,
I
think
we
have
over
100
now
having
a
single
github
or
proved
to
be
challenging
from
a
management
perspective.
A
Thank
you,
I
think
that
answers
the
question
as
well.
Very
well.
Thank
you
Shawn.
If
anybody
has
questions,
please
feel
free
to
reach
out
to
Shawn.
His
slack
idea
will
add
it
to
the
speaker
notes
as
well
to
that
meeting
agenda.
Now,
usually,
we
have
three
SiC
updates
and,
as
I
mentioned
in
the
beginning
of
the
call,
because
there
is
no
demo
this
week
we
have
taken
the
liberty
to
a
directory
of
fourth
sig
update,
so
I'm
happy
to
invite
initiative.
A
J
Okay,
great,
this
is
very
timely
because
I'm
actually
using
kubernetes
sakes
in
order
to
better
organize
sake,
AWS
so
Brian's
last
comment
is
extremely
valid,
so
see,
kws
has
specifically
focused
on
kubernetes
integrations
on
ec2,
but
as
we
are
increasing
our
focus
upstream,
we
also
want
to
organize
all
the
sub
projects
under
Zig
AWS
and
improve
our
contributions
upstream.
J
As
a
general
commitment,
we
are
looking
at
documentation
and
testing
where
we
can
do
a
lot
of
uplifting
and
improve
the
quality
of
whatever
is
done
in
the
kubernetes
codebase,
but
other
than
that
we
have
organized
certain
sub
projects.
So
my
goal
is
to
give
an
overview
of
what
those
sub
projects
are
and
I'm
representing.
The
sig
leads
today
that
is
a
Popeye's
Justin
as
B
and
Chris
Nova.
So
the
first
sub
project
I
wanted
to
highlight
is
the
Hep
C
Authenticator
project.
J
It's
actually
a
tool
that
allows
using
AWS
I
am
credentials
to
authenticate
to
a
kubernetes
cluster.
It's
integrated
with
AWS
I
am
STS
and
it
sends
pre-signed
para
tokens
to
enable
authentication
on
the
controller
side,
the
authorization
that
is
enabled
on
kubernetes
site
can
be
whatever
you
want.
In
amazon
eks,
we
are
using
this
tool
and
we
use
our
back
on
the
kubernetes
complete
the
authorization
process,
so
we
renamed
the
project
from
hep-c
Authenticator
to
EWS.
J
There
are
some
AWS
doc
updates
that
we
still
need
to
complete
upstream,
but
we
are
trying
to
work
with
users
in
order
to
improve
the
tool,
and
this
project
is
being
jointly
maintained
by
hep-c,
oh
and
AWS
eks
engineers
moving
on
the
second
sub
project
that
we
created
was
AWS
al
being
Gress
controller.
This
was
also
a
project
that
was
donated
to
us
by
core
OS
and
Ticketmaster,
it's
being
used
in
production
at
Ticketmaster.
J
For
over
a
year
we
have
some
customers,
like
blue
jeans
and
fresh
works,
working
on
it,
using
it
right
now
in
their
kubernetes
environments,
essentially
the
al
being
dress,
controller,
watches
for
ingress
events
on
kubernetes,
and
it
will
create
AWS
elby's.
In
order
to
do
so,
the
AWS
al
bees
that
are
created
can
both
be
internet-facing
as
well
as
internal.
J
Today,
the
ingress
traffic
for
all
the
controller
managed
manage
resources
can
reach
the
kubernetes
node
through
node
port.
This
does
create
some
additional
hops
for
customers
who
are
using
rest
controller,
so
we're
evaluating
options
and
designs
that
allows
users
to
directly
reach
the
part
that
they
are
trying
to
target
instead
of
using
the
node
boat
model.
There
are
also
multiple
other
feature
requests
from
customers
and
we
are
actively
working
with
Ticketmaster
and
core
OS
community
engineers
to
improve
this
project.
J
This
project
is
not
officially
integrated
in
Amazon
eks,
but
we
hope
that
at
some
point
we
can
make
it
stable
and
add
it
to
a
mazanik.
Yes,
the
third
sub
project,
this
we
are
working
with
Justin
SBE
and
said
Pollock
from
the
community.
Essentially,
it
uses
AWS
kms
and
works
with
it's
something
called
envelope
encryption.
What
we
are
doing
is
we
are
running
TMS
plug-in
as
a
G
RPC
server.
It
generates
local
Dex
and
it
can
cache
something
called
a
key
encryption
key
that
can
be
generated
from
a
remote
EMS
provider.
J
In
this
case
it
will
be
AWS
k,
ms
KMS
keys,
and
then
these
decks
can
be
used
to
encrypt
any
secret.
That's
coming
into
the
control
plane
and
it's
saved
in
to
EDD.
So
right
now,
Justin
has
B
and
said:
palak
have
given
us
a
good
start
in
terms
of
writing
the
code.
What
we
are
doing
is
trying
to
figure
out
what
could
be
the
scale
implications
is
the
caching
of
the
deck
enough,
or
how
can
we
do
key
rotation
and
what
could
be
the
limitations
of
this
particular
design?
J
J
The
community
has
helped
us
figure
out
a
bunch
of
issues
that
we
need
to
fix
on
the
EBS
side,
which
is
a
very
useful
feedback,
but
simultaneously
we're
also
figuring
out
how
to
improve
the
interface,
and
this
is
in
a
proposal
stage.
We
hope
that
we
can
get
the
CSI
driver
to
a
stable
path,
hopefully
in
1.13,
and
then
move
it
as
a
sub
project
into
c
k
WS.
J
So
the
folks
involved
here
are
yarn,
Haman,
deep
and
the
EBS
team,
and
if
you
guys
want
to
be
involved,
the
Google
Doc
is
available
and
you
can
make
your
comments
or
leave
your
thoughts.
There
I
also
want
to
talk
about
pod
identity
access.
This
is
an
ongoing
discussion.
We
talked
about
the
AWS.
I
am
Authenticator
which
allows
identity
to
be
available
on
the
kubernetes
worker
nodes,
we're
working
on
a
model
with
the
community
that
allows
identity
injection
inside
the
pod
directly.
So
there
are
multiple
community
proposals
here.
J
Cube
I
am
I,
am
for
q.k
I
am,
and
we
also
have
our
own
model
of
looking
at
OAD
C
and
integrating
service
account
tokens
into
the
API
server.
Our
team
mica
from
the
Amazon
ETS
team
is
working
on
this,
along
with
Nick
Dunne
and
some
of
the
community.
Folks
from
you
switch.
So
we
don't
have
a
clear
path
ahead
on
this,
but
this
is
a
sub
project
which
is
under
proposal
right
now.
If
you
have
any
inputs
or
thoughts
again,
the
Google
Docs
are
available.
J
Please
feel
free
to
comment
and
the
sixth
project
that
we
are
talking
about
again.
This
is
a
cloud
provider
AWS
project
which
is
focused
on
taking
CCM,
which
is
the
cloud
controller
manager
which
is
currently
in
tree
out
of
tree,
were
currently
it's
a
sub
project
and
sig
AWS.
We
are
completely
focused
on
making
sure
that
we
work
with,
say
cloud
provider
figure
out
the
governance
model,
which
is
normal
and
become
a
part
of
the
whole
sig
cloud
provider
effort.
J
As
a
strong
participant
of
say,
cloud
provider,
we
have
introduced
documentation
cap,
which
is
an
ongoing
problem
with
AWS.
There
are
lots
of
folks
interested,
but
the
documentation
is
a
little
bit
not
complete
and
were
trying
to
make
sure
that
we
have
certain
standards
established
and
we
will
be
the
first
one
to
follow
on
AWS
and
then
we
hope
with
support
of
Google
and
OpenStack.
J
We
can
improve
the
documentation
standard
for
both
entry
and
out
of
tree
CCM
implementation,
we're
also
working
on
the
out
of
tree
CCM
provider,
codebase
and
also
looking
at
how
to
enable
end
to
end
testing.
So
that's
it
from
me.
This
was
a
quick
summary
of
all
the
activities
we're
doing
in
cig
AWS
and
hopefully
it
was
useful
Thank.
A
Alright
I
saw
email
from
Chris
yesterday
about
AWS
cluster
API
and
she
also
asked
for
30
seconds,
but
because
all
the
siblings
have
done
a
fantastic
job
of
giving
an
update.
We
will
be
generous
and
give
a
minute
to
give
you
the
update
on
cluster
API
implementation
details.
Chris
thanks.
D
I
H
I
Felt
like
the
doodles
and
Docs
starting
work,
please
come
and
give
us
your
input
email.
So
if
you
have
questions
or
concerns
now's
really
great
time
to
get
involved
also,
we
have
a
call
for
action.
We're
trying
to
document
user
experiences
on
AWS
from
everything
from
experience
that
we
learned
when
we
were
ready
cops
to
keep
according
to
any
experience,
other
folks
have
had
as
well
to
build
a
common
knowledge
base.
A
Alright,
any
questions
for
Chris,
okay,
awesome,
listen!
You
can
share
your
screen.
You
know
cuz,
a
cig,
it'll
be
less
updates.
Are
done
back
to
that
was
speaker.
Alright.
Thank
you
so
much
alright.
So
the
stick
updates
are
done
with
that.
So
what
we're
gonna
do
is
we're
gonna
move
on
to
a
new
section
that
we
have
added
this
time.
At
least
Adam
would
like
to
provide
an
update
from
steering
committee,
and
you
were
on
hi.
C
Everybody
Aaron
converter
here
here,
friendly
testing,
lead
steering
committee
guy
and
sundry
other
things.
It's
been
a
while,
since
the
steering
committee
talked
to
you
about
stuff,
so
I
kind
of
wanted
to
share
with
you
where
we
were
at
I'm
going
to
share
my
screen
and
you're
going
to
experience
a
quick
mini
steering
committee
meeting
here
we
go
so
the
way
the
steering
committee
runs
our
meeting
is
we
use
this
handy
dandy
project
board?
Anybody
should
be
able
to
take
a
look
at
this.
It's
in
the
kubernetes
steering
repo.
C
Let's
see
here,
make
sure
that's
cool
alright.
Put
that
over
there.
So
the
way
we
run
the
meeting
is
we
walk
through
the
steering
board.
We
look
at
the
column,
that's
in
progress,
so
the
first
thing
in
progress
is
steering
committee
elections.
So
this
is
where
I
get
tell
you
that
we've
remembered
that
steering
committee
elections
are
supposed
to
happen
every
year
and
all
that
stuff
we
were
supposed
to
sort
out
immediately
after
getting
elected,
we're
almost
done
sorting
out
the
main
criteria.
C
The
main
thing
we
need
to
sort
out
right
now
is
what
the
criteria
is
for
members
of
standing
members
of
standing
are
people
who
can
actually
vote
in
the
election
last
year.
You
may
remember:
we
looked
at
owners
files
and
then
kind
of
had
a
like.
Please
just
email
us,
if
you
think
you,
you
weren't
included
in
the
initial
list
and
we'll
we'll
find
reasons
to
include
you
this
here
we're
trying
to
do
something.
C
That's
a
little
more
data-driven,
so
I
also
got
to
bump
graph
of
the
week
to
give
this
update
so
I'm
actually
going
to
sneak
one
in
here.
If
you
go
over
to
dev
stats,
there's
a
graph
or
I
guess
it's
more
like
a
table
called
developer
activity
counts
by
repository
group.
We're
gonna
take
a
look
at
people
who
have
made
contributions.
C
Those
are
like
anything
that
causes
a
github
event
to
happen.
Opening
an
issue
commenting
on
an
issue
opening
a
poll
requests
submitting
code,
helping
us
triage
issues,
we're
gonna,
take
a
look
at
how
many
people
have
done
this
across
every
repository
that
belongs
to
the
kubernetes
project,
not
just
KK.
We're
going
to
look
at
this
from
rolling
window
of
the
past
year,
and
so
we're
going
to
take
a
look
at
this
table,
export
it
and
basically
cut
it
off
the
I
think
it's
50
or
60.
C
So
if
you
want
more
details
on
that,
you'll
be
hearing
about
them,
because
we've
gotten
in
touch
with
Parris,
Pittman
and
Jorge,
Castro
and
I
think
they
were
volunteering.
Josh
burkas
is
a
third
person,
so
we
can
sort
of
D
bottle.
Let
those
two
folks
who
have
enough
community
management
duties
to
do
and
we're
gonna
start
getting
out
the
vote.
C
What
working
groups
are
and
how
you
working
group
in
the
context
of
governance
of
the
whole
project,
I
signed
up
to
do
this
and
I
literally
haven't
thought
of
yet
so
I'm.
So
sorry,
but
we've
realized
that
sometimes
what
steering
committee
needs
to
do,
especially
in
the
context
of
charters
and
and
project
wide
communication.
We
need
to
make
sure
that
SIG's
are
kept
up
to
date
and
that
SIG's
also
feel
like
they
have
a
point
of
contact
into
the
steering
committee
informally.
C
This
has
already
happened
with
the
number
of
SIG's
because
we're
all
pretty
active
in
the
community
and
we
are
all
either
chairs
or
leads
or
sub
project
owners.
In
a
very
and
a
variety
of
SIG's,
but
we
do
have
a
couple
caps
so
as
part
of
the
effort
to
review
charters
for
every
stake
which
I'll
get
to
shortly.
We
put
together
this
spreadsheet,
where
we
made
sure
we
had
at
least
two
people
assigned
to
every
sig
is
going
to
be
responsible
for
reviewing
their
charters
and
so
I'm
just
gonna.
C
C
The
steering
committee
I
want
to
just
give
a
huge
shout
out
to
her
for
actually
making
that
happen.
Loosely
speaking,
the
process
was
open
candidates.
Like
closed
voting,
we
ended
up
voting
and
I
can
go
to
the
pull
request
over
here
that
actually
added
the
members,
and
so
your
code
of
conduct
committee
will
be
Jay
singer.
Dumars
pairs,
Pittman,
Eric,
Harris,
Carolyn,
ban
I,
can't
I
can't
pronounce
your
last
name:
Carolyn
I'm,
so
sorry
and
Brad
iment
who's,
Brad,
Amman,
I,
forget
I.
Should.
C
Donor
program,
yet
Jennifer
Rondo,
of
course,
how
could
I
forget,
has
done
wonderful
work
on
the
release
in
Docs
stuff,
so
we're
gonna
have
an
inaugural
meeting
with
a
couple
members
of
the
steering
committee
who
have
capĂtulo
opinions
on
this,
but
basically
in
a
code
of
conduct
committee
is
going
to
be
empowered
to
do
their
thing.
What
is
their
thing?
You
might
ask?
Well
if
I
go
to
community,
if
I
go
to
committee
code
of
conduct,
the
readme
tells
you
some
things.
C
Okay,
finally,
the
one
that
gives
me
the
most
brow,
wrinkles,
the
Chartres
meta
issues.
So
I
have
this
like
over/under
bet
on
whether
or
not
we're
actually
going
to
within
a
year
of
the
steering
committee
having
been
elected
and
formed
actually
have
all
the
SIG's
describe
what
it
is
that
they
are
in
fact
in
our
Jeff
like
what
is
in
scope.
For
that
sake,
what
is
out
of
scope?
For
that
sake?
How
do
you
use
ik,
there's
been
a
bunch
of
back-and-forth
and
a
lot
of
opinions
and
I.
Think
where
we've
landed?
C
Is
we're
really
most
concerned
about
trying
to
get
an
initial
pass
on
scope?
From
a
variety
of
sakes,
we
put
together
a
template
that
kind
of
lays
out
the
standard
pattern
for
governance
that
we
anticipate.
Most
SIG's
would
want
to
follow
where
there
are
chairs
who
are
responsible
for
running
the
stake.
There
are
tech
leads
who
are
responsible
for
technical
decisions
and
sundry.
Other
things
we
had
a
couple
SIG's
approaches
early
on
with
charters
to
be
reviewed.
C
C
The
idea
here
is
this
stuff
doesn't
seem
to
happen
unless
humans
kind
of
get
together
in
a
room,
virtual
or
otherwise,
and
hammer
this
stuff
out
so
expect
to
see
steering
committee
members
showing
up
at
the
sync
meetings
for
which
they
are
responsible
to
help
push
this
stuff
through
the
reason
you
may
not
have
seen
a
large
push
for
this
just
yet
is
because
we're
still
kind
of
trying
to
figure
it
out
ourselves.
So
we
started
with
a
few
examples
that
came
our
way
or
you
know
early
starters.
C
Your
Charter
tells
us
what
is
in
scope,
both
in
terms
of
code
and
binaries
and
in
terms
of
processes.
They
also
do
a
good
job
of
telling
us.
What
is
out
of
scope
and
there's
really
not
a
whole
lot
else
to
talk
about
this?
Is
this
is
ideal
for
us?
This
is
going
to
help
us
focus
on
the
what
the
how
is
documented
in
the
template.
If
we
go
look
at
that,
let's
see
if
this
link
actually
works.
C
It's
act
together
on
this
sort
of
standard
template,
as
well
as
sakes
that
have
kind
of
still
got
to
figure
out
what
the
scope
is
before
we're
ready
to
open
it
up
to
broader
steering
committee
review
as
well
as
SIG's
that
just
are
kind
of
waiting
for
us
to
get
our
act
together
and
tell
them
exactly
what
you
do
and
how
you
do
it,
and
so
on
and
so
forth.
So
this
is
messy.
This
takes
a
while
we're
still
figuring
it
out.
C
We
consider
this
to
be
an
iterative
process,
even
though
it's
taken
us
this
long
to
get
here
and
get
everything
merged
when
we
do
it's
not
as
though
that
is
all
set
in
stone,
it's
more
to
help.
All
of
us
collectively
understand
what
the
project
is
and
who
owns
which
pieces
of
the
project
last
thing
I
want
to
mention.
C
Well,
no,
not
quite
the
last
thing.
So
go
back
to
the
meeting
agenda,
all
right,
so
I
already
plugged
the
steering
committee
elections
great
one
other
thing,
I'll
plug
is
the
meet
our
contributors
steering
committee
edition.
We
already
had
one
a
couple
weeks
ago:
I
don't
have
a
link
to
it.
Offhand
we're
gonna
have
another
one
September
5th
at
1:00
p.m.
Pacific
time
or
a
bunch
of
members
of
the
steering
committee
are
gonna.
Be
there.
If
you
want
to
ask
questions
of
us,
please
join
the
meet
our
contributors
channel
on
kubernetes
slack.
C
Finally,
you
had
a
discussion
last
week
about
sort
of
non
steering
committee
participation
I
wanted
to
start
illustrating
that,
with
this,
this
project
board
here
is
actually
something
that
nobody
on
the
steering
committee
put
together.
Jace
singer
dbar
is
helpfully
volunteered
to
like
help
us
run
our
meetings
a
little
bit
better
and
keep
track
of
things
a
little
bit
more
efficiently,
and
we
really
really
welcome
that.
We
find
ourselves
often
going
back
and
forth
and
meetings
over,
what's
the
state
of
things
or
who
said
what,
when
or
who
documented
but
he's
been
pretty
good
about.
C
Keeping
us
honest
and
would
love
to
like
help,
keep
us
honest
in
the
moment
when
we're
asking
ourselves
these
questions
instead
of
having
to
yell
at
the
recording
of
us
about
two
hours
later.
So
this
sort
of
made
us
think
that
there
there
are
often
times
where
we
kind
of
could
benefit
from
having
people
who
aren't
on
the
steering
committee
come
and
participate
in
our
meetings.
C
Code
of
conduct
committee
would
be
another
great
example,
and
just
in
general,
like
the
steering
committee,
is
a
bunch
of
really
over
committed,
overworked
individuals
who
really
want
to
get
everything
done
as
soon
as
possible,
but
also
have
20
other
things
to
get
done,
and
so,
as
we
kind
of
look
back
in
wish,
we
had
made
more
progress.
We
realize,
generally
speaking
the
times
when
we
make
the
most
progress
are
when
people
outside
of
the
steering
committee
bring
to
us
fully
baked
and
well-formed
proposals.
C
Be
that
on
how
the
project
should
be
run,
processes
or
the
formation
of
new
sub
projects.
So
just
one
example:
I
wanted
to
call
out
that
I
thought
was
kind
of
cool,
was
Christoph
Blocher,
basically
put
together
a
sub
projects
under
the
contributor
manic
contributor
experience,
Zig
I,
don't
sort
of
noticing
that,
like
the
way
we
manage
our
github
organizations,
permissions
branches,
BOTS
labels,
everything
is
kind
of
inconsistent
and
we've
been
seeing
this
general
trend
of
other
open-source
projects
with
kind
of
haphazard,
github
management
get
compromised.
I.
C
Think
homebrew
was
maybe
the
latest
one,
although
I
personally
am
willing
to
blame
that
on
Jenkins,
and
so
he
put
together
this
proposal
and
wanted
to
make
sure
that
the
steering
committee
had
a
say
in
it
because
it
was
kind
of
about
the
delegation
of
authority
and
powers
throughout
the
project.
Remember
our
job
is
not
to
do
our
job
is
to
give
other
people
the
ability
to
do,
and
he
also
made
sure
that,
like
security
was
folded
in
and
so
on,
and
so
forth.
C
So
anyway,
like
just
consider
this,
like
a
call
for
participation,
if
you
feel
like
the
steering
committee,
is
not
doing
enough,
where
you'd
have
ideas
about
how
things
should
be
done,
we
welcome
and
encourage
proposals
and
participation
with
that.
I
will
stop
sharing
my
screen
and
ask
if
there
are
any
questions
with.
K
C
C
Any
questions
for
steering
committee
or
Aaron
so
Josh
has
a
question:
can
non
steering
committee
members
join
the
actual
meetings,
no
we're
not
necessarily
inviting
the
public
at
large
to
come
in,
but
we
do
want
to
make
sure
that
we
have
the
ability
to
invite
people
to
the
meeting
if
they
have
something
that
we
as
a
group
me
to
discuss
collectively,
and
we
figure
it's
better
to
have
that
discussion
in
a
public
and
recorded
forum
as
opposed
to
you
know
in
a
mailing
list.
We
figured
like
that
high
bandwidth.
A
D
Office
hours
next
week,
at
the
usual
time,
looking
for
one
volunteer
for
the
West
Coast
Edition,
please,
click
through
sig
leads
the
update
for
you
to
give
the
SiC
updates
like
we
had.
This
meeting
has
been
updated
throughout
the
rest
of
the
cycle.
Please
follow
the
link
and
if
we
can't
get
your
schedule
just
reach
out
to
us
and
we'll
figure
something
out
and
we're
looking
for
more
community
demos,
we're
actually
down
to
only
two
people
and
the
demos
see
the
top
of
the
document
that
we're
taking
notes
in.
D
C
Okay,
so
let's
talk
about
the
github
management
sub
project
since
Tim
had
a
question
about
it
and
I
had
it
on
the
agenda
to
share
the
screen
again,
going
back
to
the
meeting
notes,
we're
taking
a
look
at
github
management,
sub
project,
so
I'm
basically
going
to
talk
about
it,
because
Christophe
has
a
standing
conflict
with
this
meeting,
but
I
kind
of
got
to
give
full
credit
to
him
for
putting
this
through.
What
is
the
project?
What
does
it
do
in
the
community?
Github
management
sub
project
responsibilities?
C
You
can
consider
this
like
our
sub
projects,
mini
charter,
including
what
we
are
responsible
for
and
what
we
are
not
responsible
for
this
one's
going
to
be
kind
of
a
fuzzy
area,
because
when
people
think
of
github,
they
kind
of
think
of
maybe
github
labels
and
automation
and
stuff
and
contributor
experience
and
stick
testing
are
still
kind
of
where
we
talk
about
the
ideal
processes
and
the
ideal
in
automation.
To
implement
that.
However,
the
github
management
sub
project
may
consume
some
of
that
automation
to
implement
those
policies
and
processes.
C
There
are
specific
policies
and
processes
we
care
about
things
like
who
should
have
Ord
ownership,
who
should
be
in
charge
of
what
are
the
policies
for
accepting
integrations
and
services
and
third-party
OAuth
apps
things
of
that
nature?
Who
is
the
github
administration
team?
Who
should
you
bug
in
person
if
yous
need
to
like
throttle
somebody
by
the
neck?
Although
pretty?
Please
don't
do
that.
We
chose
a
group
of
six
people
who
are
well-
okay,
unfortunately
mostly
Pacific,
but
we
did
try
to
distribute
around
the
globe.
So
we
do
have
some
kind
of
time
zone
coverages.
C
Not
all
of
them
are
from
the
same
company,
so
we
have
distribution
in
that
way.
We
have
folks
from
contributor
experience
and
folks
from
state
testing
because
of
the
automation
and
the
policies
processes.
So
we
feel
like
this
is
a
good
mix
of
people
to
have
or
ownership
rights.
Anybody
who
has
not
these
six
people
no
longer
has
or
ownership
privileges
over
any
of
the
github
orgs
that
we
teach.
C
What
are
the
github
orgs
that
we
manage
it's,
these
seven
github
orgs
right
here,
they're
a
bunch
of
non
actively
use,
github
orgs
that
we
kind
of
squat
on,
but
we're
not
really
actively
using
them
or
managing
them.
These
are
the
ones
that
we
want
to
make
sure
we
consistently
have
the
right
policies
in
place
for,
and
management
set
up
for,
okay
doot-doot-doot.
C
So,
given
that
I
just
said,
we
removed
org
ownership
privileges
from
a
whole
bunch
of
people.
We
may
have
broken
people's
workflow,
we're
not
entirely
sure
like
we
tried
to
do
the
responsible
thing
by
opening
up
a
github
issue
describing
what
we
were
doing
and
why
we
were
doing
it.
We
try
to
notify
everybody
who
was
going
to
be
affected.
We
had
kind
of
a
conversation
and
trying
to
answer
some
questions
and
answers'.
One
of
those
concerns
brought
up
was
like
well
I
kind
of
need
ownership
privileges
to
do
my
job.
C
Could
you
please
describe
to
me
like
how
am
I
going
to
do
my
job
now
that
I
have
to
ask
you
to
do
it?
Can
I
get
some
sort
of
SLO
for
what
this
means?
So
we
opened
up
the
full
request
document
RSOs,
so
under
github
management
opening
a
request
which,
whatever
I'll,
let
you
navigate
to
that
the
short
version
of
that
is.
We
just
asked
you
to
open
an
issue
on
github.com,
slash,
kubernetes,
slash
org.
C
So,
like
one
thing
that
is
kind
of
in
flux
for
now
people
joining
the
kubernetes
github
organization
asking
for
membership,
I
think
is
documented.
Right
now
is
kind
of
through
contributor
experience
and
people
send
an
email
to
a
Google
group
and
we'll
eventually
get
to
a
point
where
we'd,
rather
people
open
up
issues
on
this
repo,
so
that
we
can
fulfill
them
that
way.
C
But
if
you
want
to
add
Travis
or
circle
CI
to
your
repo
and
it's
being
blocked
or
prevented
for
some
reason,
and
you
want
to
go
bug
somebody
about
it,
you
go
file
an
issue
here
under
integrations,
get
started
and
we
have
an
issue
template
saying
yeah.
What
do
you
want
to
do?
Can
we
get
some
information
about
it?
Can
you
tell
us
what
you're
trying
to
do
and
any
additional
information
things
like
that?
C
Sub
projects
is
pretty
quick,
I
heard
that
described
earlier
in
the
meeting
here.
So
sub
projects
are
a
collection
of
1/2
and
repos,
or
packages
that
all
make
up
a
cohesive,
logical
unit.
We
call
it
a
sub
project
because
kubernetes
is
the
project.
The
other
thing
you're
doing
is
underneath
of
that
sub
project.
As
part
of
that,
every
single
repository
needs
to
have
an
owners
file
as
its
at
its
root.
That's
going
to
help
us
understand
who's
in
charge
of
this
thing.
Since
we've
opened
up
the
number
of
github
works
that
we
manage.
C
We've
identified
there,
a
number
of
projects
that
don't
yet
have
owners
files,
I
have
opened
up
issues
for
all
of
these,
and
I
will
be
nagging
you
again
and
again
again.
Until
this
is
closed,
the
other
thing
is:
if
you
have
a
sub
project,
if
you
have
a
repo
that
has
an
owner's
file,
you
may
not
have
actually
added
it
to
you.
60Ml
file,
which
sort
of
contains
all
the
information
about
our
project
and
is
used
to
generate
SiC,
reads
nice.
C
A
A
You're,
okay,
well,
maybe
covered
this
announcement,
maybe
next
week
in
that
case,
so
what
I
want
to
do
is
I'm
going
to
run
through
the
shoutouts
this
week,
the
first
one
comes
from
Paris,
thanks
to
Tim,
pepper,
jeffrey
seeker,
benjamin
other
Reuben
orders
for
great
responses
and
their
time
on
meat.
Our
contributors
yesterday
on
it
examples
of
good
mentors.
The
next
one
comes
from
Erin,
thanks
to
Morgan
Bauer,
for
his
efforts
in
working
with
cig
testing
to
get
service,
catalog
hooked
up
to
prop
rao
and
pied.
A
Next,
one
comes
from
jeremy
record
what
Aaron
said
tied
in
prowl
and
dope,
and
we
love
using
the
now
I'm
unfortunately
cannot
capture
their
gifts.
Here
comes
next,
one
comes
from
Tim
pepper
things
to
shout
out
to
George
Parris
zoom
and
any
others
who
have
been
working
for
months
to
improve
our
meeting
moderation,
abilities
and
best
practices
to
better
ensure
our
collaborations
are
constructive
and
resilient
in
the
face
of
potential
abuse.
Next
one
comes
from
Aaron
shout
out
to
Mathias
bird.
She
butcher
the
name
for
adding
pearl
repo
label
for
to
our
label,
sync
bot.
A
So
you
can
add
labels
to
your
repo
by
peering
a
file
instead
of
making
the
change
manually
with
admin
access.
Next
one
comes
from
George
shout-out
to
Andrew
Chan
for
sewing
out
neatly
five
for
the
contributor
site.
Last
one
comes
from
Aaron
shout
out
to
Manju,
not
to
matagi
and
dins.
His
name
is
mm
Cerebus,
but
is
definitely
more
popularly
known
as
dims
for
their
push
on
multi-org
e
to
e
test
images.
Ppc
64
Ellie
is
now
passing
note,
conformance
and
there's
a
link.
Thank
you
know.
We
pretty
much
had
a
very
packed
agenda.