►
From YouTube: Kubernetes SIG Architecture Community Meeting 20180315
Description
A
B
B
This
is
rename
the
the
community
repo
to
the
contributor
repo
or
something
like
that
to
to
help
to
to
clarify
those
lines.
But
as
we
did
that
one
of
the
things
that
came
up
is
there
is
this
repo
called
from
trig,
which
apparently
has
a
bunch
of
abandoned
stuff
and
hence
what
stupid
that
I
think
they
got
assigned
to
the
country
back
saying
and
I'm
like
that's,
probably
not
not
their
thing.
Yeah.
B
I
assume
would
be
probably
Brian
for
this
for
this
sagen
and
it's
relatively
new,
so
it's
hopefully
not
too
bad
the
the
relationship
between
so
as
part
of
this
process.
There's
going
to
be
some
level
of
insight
and
oversight
from
the
steering
committee
to
make
sure
that
the
the
scope
that's
defined
in
each
sink
charter
doesn't
overlap
and
that
we
we
don't
miss
huge
parts
if
there's
a
question
around
the
scope
of
the
project
in
general.
B
A
B
I
so
just
quick
update,
I
was
I
was
given
an
update
on
like
there's
some
slow
progress
being
made
on
the
contributor
site,
with
contrive
X
and
figuring
out
the
sort
of
about
the
lines
of
ownership
and
how
that's
going
to
work
relative
to
relative
to
the
the
documentation.
So
folks,
and
hopefully,
as
that
comes
online,
we'll
have
some
place
where
we
can.
B
The
host
caps,
where
they're,
searchable
and
findable
and
the
whole
deal
so
start
getting
more
visibility
into
that
stuff,
which
hopefully
will
help
to
motivate
the
process.
And
then
I
talked
about
the
seed
charter
process
and
how,
as
somebody's
assigned
to
each
dig,
I
haven't
looked
at
that
spreadsheet.
B
Yet
that
Fred
and
created
but
I
assume
for
sega
architecture,
probably
hugh,
prayin
and
then
and
then
just
a
little
bit
around
sort
of
approval
of
cig
charters
by
the
steering
committee
to
make
sure
that
the
scope
is
appropriate,
not
overlapping
between
SIG's
and
then,
if
there's
a
question
around
scope
with
a
project
as
a
whole
that
gets
deferred
to
to
save
architecture.
Just
a
quick
summary,
some
of
the
stuff
that
we
talked
about
yesterday
and
the
steering
committee
me
yeah.
C
B
C
Since
then,
we
have
also
started
flushing
out
finer
grain
sub
projects
that
live
within
kubernetes
kubernetes.
We,
it
is
a
requirement
for
any
sig
that
wants
to
get
a
new
repo
in
the
community
SIG's
or
to
that
the
sub
run
sub
projects
that
are
listed
in
60ml
and
enumerate
any
ones
that
are
missing.
So
a
couple
of
sticks
have
done
that
already.
The
sig
apps
did
that
the
areas
in
the
kubernetes
communities
are
for
the
workload
api's
and
API
machinery
has
done
theirs
as
well,
so
so
that
there
are
some
safe,
they
got
new
repos.
C
D
C
C
And
the
other
thing
we're
doing
is
creating
github
topics
for
all
the
SIG's,
so
you
know
random
people,
label
github
repos
with
the
kubernetes
topic,
so
that
one's
not
really
usable
but
for
the
content.
E-Cigs
org
at
least
I
start
I
created
a
bunch
of
more
kubernetes
specific
topics
and
we
should
propagate
those
to
all
the
other
repos
as
well.
C
C
F
E
C
E
C
Gate
them.
So
let's
not
discuss
that
in
this
meeting,
because
that's
more
of
a
steering
committee
thing,
a
number
of
people
in
this
steering
committee
expressed
that
they
want
to
stick
cloud,
and
there
are
people
who
are
like
being
where
in
IBM
are
currently
blocked.
Based
on
that
decision,
but
nobody's
actually
pushed
that
over
the
finish
line
like
actually
actively
working
on
making
a
suit
cloud.
Okay,
so
running
is
send
email
to
the
steering
committee
sure
and
we
can
try
to
get
that
moving.
C
C
C
C
C
Things
that
are
not
in
the
Charter
are
the
concrete
sub
projects,
the
leadership,
technical
and
otherwise
organization
of
the
cig,
decision-making
processes,
and
things
like
that.
So,
let's
see
if
I
can
find
Phil's
documents
yeah
so
in
the
Governance
Committee
steering
Governance
subdirectory
in
the
pace
that
to
the
chat
as
well.
In
the
community
repo,
a
sick
governance,
a
couple
of
state
governance
Docs
were
created.
C
Navigate
my
Windows
here
so
things
like
you
know:
if
we're
gonna
add
a
sub
project,
how
does
that
get
decided
or
for
the
conformance
definition,
sub
projects?
Who
are
the
leads
of
that?
So
the
way
I've
been
handling
sub
project
leads
is
by
specifying
them
using
the
pre
existing
owners
role
and
the
community
ladder
owners
has
been
smashed
together
with
maintainer
x',
and
now
we
just
have
the
technical
leads
for
sub
project.
We're
currently
calling
owners
I'm
not
wedded
to
that
name,
but
that's
what
it
was
already.
C
A
A
Your
question
on
that
so
there's
sort
of
an
in
taxonomy
developing
around
having
groups
as
those
things.
How
does
that
work?
What
groups
so
like
the
github
groups,
I've
seen
in
I,
was
looking
at
somebody's
one
six
thing
and
they
had
the
approvers
is
actually
like,
say:
XYZ
approvers
and
it's
a
github
group
that
II
mean
Courtney
are
a
team.
I'm,
sorry,
sorry,
sorry,
yeah,
team,
github
team,
so.
C
First
of
all,
gap
teams
absolutely
cannot
be
the
authoritative
source
of
information
about
who
is
in
what
role
they
just
they
absolutely
copy.
The
there
are
a
bunch
of
reasons
for
that,
like
they're,
not
visible
to
people
who
are
not
members
of
the
org.
There's
no
audit
trail
of
modifications
to
that.
C
A
C
C
Or
the
steering
committee
/
contributor
experience
thing:
okay,
I
mean
here.
You
know
we
can
work
with
the
things
that
have
been
defined
so
far
and
maybe
try
to
predict
a
little
bit
where
the
puck
is
going,
but
the
existing
sig
leads
roles
will
be
split
into
more
specific
roles.
So,
for
example,
you
know
coordinating
the
meetings
and
the
agendas
and
those
types
of
things
which
Jase
and
I
are
doing.
C
That
is
becoming
a
chair,
a
chair
rule
which
I
think
is
straightforward
transition
and
then,
on
the
technical
leadership
side,
there
are
a
couple
of
different
proposed
models.
There's
a
technical
lead
model
where
one
or
more
people
can
serve
as
kind
of
over
technical
leads
for
overall
direction
and
escalation
and
deciding
vetting
new
sub
projects
or
deciding
what
sub
project
an
issue
falls
in.
If
it's
unclear
and
things
like
that,
and
then
you
know,
the
individual
sub
projects,
as
I
mentioned
before,
will
have
owners.
So
one
possible
model
is
just
like
a
collection
of
all.
C
C
G
G
B
One
thing
I
want
to
bring
up
here
is
and
I
think
this
is
a
question
for
architecture.
There's
a
bunch
of
code
that
is,
you
know,
falls
between
the
cracks
between
different
SIG's
and
I'm
thinking,
something
like
say
the
bender
tree
right
and
you
know
being
on
top
level
zone
owners.
You
know
it's
not
uncommon
to
get.
You
know,
I,
think
those
things
sort
of
sort
of
bubble
up
there
I
think
to
some
degree.
Save
architecture
will
be
a
little
bit
of
a
sort
of
catch-all
kitchen
sink
for
some
of
these
things.
C
C
G
C
G
G
B
B
C
We're
we're
trying
to
split
those
into
multiple
buckets,
like
there's
utilities
that
aren't
even
specific
to
kubernetes.
There
are
utilities
that
are
used
in
API
machinery,
there
utilities
that
are
used
across
API
machinery,
controllers,
queue,
control
and
other
things,
so
that
those
things
are
we
have
common
repo
that
we
were
going
to
put
things
in,
although
I
don't
know,
if
any
of
those
code
moves
that
actually
happened,
so
I
think
in
some
of
those
cases
you
know
we
just
need
to
pick
a
cig
to
own
some
of
those
things.
C
H
Know
who's
gonna
make
a
similar
comment.
I
honestly
think
we
have
enough
real
architecture,
problems
that
we're
you
know
behind
on
that
we
should
try
and
avoid
earning.
You
know
shared
libraries
and
things
like
this.
We
can
just
as
well
arbitrarily
choose
some
other
cig
which
has
people
interested
in
it
and
that
can
own
it.
It's
the
worse
of
choice
than
us,
owning
anything
yeah.
B
I
I,
just
again
it's
it's
unclear
which
cig
that
would
be
and
I
think.
As
we
start
doing,
some
of
this
stuff,
we're
gonna
find
that
there
is.
There
are
gonna,
be
sort
of
corners
of
the
codebase
that
nobody's
excited
to
pick
up
but
ya,
get
assigned
to
a
cig
regardless,
just
because
that's
the
logical
place
for
them
to
be
I'm.
B
C
B
C
B
H
C
B
But
my
argument,
Quentin,
is,
is
assigning
code
to
the
right.
Sig
is
an
orthogonal
problem
to
whether
that
sig
has
capacity
or
not
it's
just
a
you
know,
and
you
know
in
six
can
bifurcate
they
can
but
off
new
efforts.
If
it
becomes
clear
right,
we
can
look
at
that.
That's
why
we're
building
this
sub
project
are
caPSURE
to
create
a
structure
inside
of
a
cig
sure.
H
No,
no
to
be
clear,
I
wasn't
I,
wasn't
advocating
that
a
signal
having
bandwidth
means
that
it
doesn't
have
to
own
something
that
clearly
fits
within
its
purview.
What
I
was
arguing
was
that
for
things
that
do
not
fit
in
the
purview
of
cig
architecture,
they
shouldn't
be
earned
by
cig
architecture,
just
because
there's
no
other
reasonable
home
for
them.
H
B
Yeah,
if
we
can
find
a
better
place,
then
yes,
let's
do
that
in
terms
of
we
should
create
a
home
for
them.
I
think
one
of
the
things
that
we're
gonna
find
and
I
think
that
this
a
cloud
example
shows
this
is
that
just
because
we
think
there
should
be
a
cig
around
X,
Y,
&
Z.
We
can't
make
it
happen
unless
somebody
steps
up
and
says
yes,
I,
want
to
like
pull
together
the
group
and
form
this
sig
right.
It's
just
a
matter
of
you
know:
it's
a
volunteer
army.
G
G
Or
what
do
we
do
with
the
ones
that
aren't
owned
and
and
kind
of
chase
where
that
should
go,
but
we
can
probably,
in
the
short
term,
not
deal
with
the
what-ifs
and
look
at
what
do.
We
know
that
we
own
and
then
we
can
create
the
governance
based
on
that
and
then
deal
with
kind
of
auditing
what's
not
owned
later
and
deal
with
it
then
yeah,
because.
C
C
A
C
I
mean
my
week
is
not
looking
so
good
either
so
I
mean
there
is
no
deadline
on
the
six
to
create
charters
at
the
moment
and
SiC
architecture
is
not
one
of
the
SIG's
that
urgently
needs
new
repose,
so
I'd
say:
there's
probably
less
urgency
on
state
architecture
than
some
of
the
other
SIG's
I
would
stay.
You
know
for
the
people
who
are
participating
in
some
projects
like
Kemp
I,
think
the
first
thing
might
be
to
do
is
to
just
like
get
the
sub-project
house
in
order
in
terms
of
identifying
and
cooler
the
owners.
C
G
G
C
I
B
Well
and
I
think
I
think
part
of
that
sub
project
is,
is
working
with
the
CNC
F,
to
figure
out
the
tools
and
the
policies
around
vendor,
II
and
and
dependencies
in
general.
So
this
is
not
just
sort
of
like
you
know,
owning
and
approving,
but
the
work
that
you're
already
doing
Tim
there,
which
which
we
all
appreciate.
Thank
you.
G
B
B
C
C
Conformance
yeah,
so
that's
those
are
kind
of
the
general
areas
that
are
defined
so
I
think
some
of
those
I'll
try
to
come
up
with
some
kind
of
sub
project
categorization
for
and
first
and
there
is
actually
work
ongoing
and
some
of
them
like
documenting
and
defining
the
the
overall
system
architecture.
I
had
previously
created
a.
C
H
Quick
question
dude
and
what
I
see
vortex
on
hey
probably
has
the
best
answer
total
so
I
wonder
if
there's
an
aspect
to
performance
and
particularly
relating
to
architecture
like
if
we
needed
to
we
are
connect
stuff
for
performance
and
scalability
reasons
with
that
fall
within
six
scalability
stroke.
Whatever.
C
C
J
J
H
J
A
J
C
K
A
C
A
I
K
C
I
think
one
thing
cigs
themselves
need
to
do
is
actually
speak
out
when
this
kind
of
thing
happens,
just
email,
kubernetes,
dev
and
say
hey.
We
have
these
this
important
work
for
these
important
issues.
We
need
more
people
like
I,
used
to
look
across
the
whole
project
and
periodically
send
out
email
saying
we
need
more
work
in
these
four
SIG's
or
whatever,
but
the
project
is
too
huge
for
me
to
know
everything.
That's
going
on.
Yeah.
F
K
No
there
it's
more
than
just
a
people
problem
to
like
it's
a
general
UX
problem
where,
in
order
for
people
to
get
the
signal,
they
have
to
run
a
cluster
of
size,
X
right
and
there
are
other
ways
to
do
it,
but
not
all
of
that
stuff
has
been
percolated
so
that
it's
super
easy
for
any
operator
to
run.
You
know
a
coop,
Mart
cluster
or
to
spin
up
a
set
of
hollow
nodes
in
an
environment
that
allows
them
to
do
a
set
of
tests
right.
So
then,.
C
K
H
Shortage
of
resources
and
I
was
just
gonna,
make
a
comment
that
I
think
sometimes
for
SIG's
themselves
by
themselves
to
identify
that
they
have
a
lack
of
resources,
problem
and
actually
stand
up
and
say
we
need
help
is
sometimes
difficult.
It's
I
think
it
would
be
super
useful
for
this
group
and
all
the
steering
committee
to
to
lend
strong
support
in
cases
like
that
and
say,
and
we
believe
this
is
really
important
for
the
project
in
hand.
H
C
C
Way,
I
think
it's
good
for
us
to
give
them
support
and
not
expect
the
sinks
to
solve
these
problems
on
their
own.
You
know
the
sex.
Do
you
need
to
speak
up
about
it
like
this?
Is
the
I
mean
I
was
somewhat
aware
of
some
people
at
Google,
shifting
around
and
Tim
shifting
around
and
whatever,
but
this
is
the
first
I've
actually
heard
that
there's
work,
that's
not
getting
done
because
they
don't
have
enough
people
yeah.
H
H
But
one
thing
I've
seen
in
that
group
in
particularly
as
the
work
is
really
difficult
and
and
it's
easy
to
have
a
lot
of
Talking
Heads
sitting
around
a
table
as
opposed
to
people
solving
the
real
problems
so
yeah
it
gets
back
to
defining
the
skill,
sets
that
are
required
and
being
very
selective
about
the
people
that
you
allocate
to
those
tasks,
because
otherwise
you're
setting
people
up
for
failure.
Yeah,
okay,.
C
So
I
want
to
we're
a
little
bit
off
topic
again,
so
I
think
we
have
made
it
about
as
much
progress
as
we're
gonna
make
on
the
Charter
in
this
meeting.
So
I
just
want
to
call
make
a
call
for
other
topics
before
we
adjourn
is
I
actually
need
to
in
five
minutes
early
to
go
to
get
ready
for
my
next
meeting.
I
C
K
E
G
G
I
I
mean
for
DEP
seems
completely
appropriate
for,
like
normal
repo
same
repos,
the
communities,
communities,
Rico,
he's
not
sane
and
proposals
do
adopt.
Our
sort
of
staging
model
have
been
summarily
shot,
as
probably
is
correct,
and
until
something
like
Vigo
actually
is
viable
and
exists.
Dep
sort
of
in
its
current
form
doesn't
really
work
for
the
main
committees,
repo.
We
can
either
limbo
go
down
or
we
can
follow
on
these
other
paths,
but
for
smaller
repos
I
would
wholeheartedly
advocate
Deb.
If
you
can
make
it
work.
H
I
H
I
The
problem
is
the
via
state
involves
taking
everything.
That's
in
staging
and
fully
evicting
it
out
into
separate
repos,
which
makes
every
sort
of
non-trivial
change
to
the
system
require
multiple
pr's
that
have
to
be
coordinated
and
merged
in
the
right
order,
and
tests
will
have
to
change
in
order
to
be
pulling
the
right.
You
know
synchronization
points
and
it
quickly
gets
ugly.
So.