►
From YouTube: Kubernetes SIG Architecture 9 14 2017
Description
A
Welcome
everyone
to
the
cig
architecture,
community
meeting
for
Thursday
September
14
2017
I-
am
your
moderator
and
co-lead
JCR
Jamar's.
Your
other
lead
is
Brian
grant.
Who
is
here
but
unable
to
speak
due
to
some
sort
of
creeping
malaise.
We
will
try
and
make
the
best
of
the
meeting.
The
agenda
is
available
to
you
at
all
times
for
your
review.
It
bit
dot,
Lee
/
sake
architecture,
and
you
will
see
the
attendees
and
meeting
minutes
there.
A
So
what
I
want
to
go
ahead
and
start
doing
is
just
take
a
quick
visit
on
the
action
items
that
we
have
from
last
week
to
see
if
we
have
any
updates
the
first,
those
is
Caleb
miles
was
split.
The
proposal
to
put
out
into
separate,
PR
and
I
know
there's
some
work
here,
but
I'd
love
for
Kim
to
speak.
To
that.
B
Yep
there's
work
going
on
there,
so
I
may
be
a
little
bit
robotic
conference
or
hotel
Wi-Fi
yeah,
so
I
just
split
out
the
proposal
I
need
to
finish
the
PR
with
a
template
on
it
itself
and
I.
Try
to
address
the
first
round
of
comments,
but
I
got
so
the
process
PR
is
up,
I
did
every
name
the
artifact,
but
that's
necessarily
particularly
interesting,
so
hopefully
I'll
be
able
to
get
the
actual
template
up
PR
up
soon.
So
we
can
iterate
on
that.
A
C
C
C
I
slack
us
for
me
a
little
bit
like
the
github
stuff,
where
you
know
I
try
and
keep
up
with
like
the
company
slack
I
can
barely
do
that,
and
the
kubernetes
slack
falls
away.
Unless
folks
mention
me,
I
I,
don't
know,
I,
don't
know
it's
very
difficult,
but
but
the
email
is
you
know,
email
would
be
I
think
at
least
right
now
this
week
work
yeah.
It's
tough.
C
E
A
A
Great
I,
like
it
so
next
bullet
point
is
Caleb
and
I
met
to
talk
about
the
sort
of
grand
design
of
their
RFC
proposals,
so
I
understood
it
in
better
detail
and
also
how
that
might
fit
into
a
product
management
type
process
or
backlog
management
for
for
functionality
that
it
works.
I
feel
like
we're
in
good
alignment.
I
just
need
to
get
some
extra
cycles
and
document
that
so
I'm
hoping
to
have
that
done
by
middle
of
next
week.
A
Ideally
obviously,
with
the
the
release
happening,
it's
pretty
I'm
pretty
well
taxed,
but
hopefully
get
that
done
soon.
I'm
really
excited
actually
that
when
I,
when
we
talked
about
it,
really
felt
like
there's,
there's
a
really
strong
steel
thread,
that'll
run
through
the
RFC
and
into
product
delivery
process
that
we've
talked
about.
I
can't
wait
for
that
to
feel
good,
because
right
now
the
one
of
the
big
takeaways
in
cig
release,
meetings
and
also
the
Burnett
meetings
is
the
product
and
the
pace
of
change
from
the
sakes
feels
very
disconnected
and
out
of
alignment.
A
F
A
A
Looking
at
it
right
now,
it
looks
like
the
last
change
was
24
days
ago,
which
is
not
not
to
me
singing
like
a
vibrant
back
lock.
So
I
would
love
to
call
everyone's
attention
to
that.
I'm
gonna
paste
it
again
in
the
chat,
so
everybody's
got
a
handy,
but
essentially
what
we
need
to
do
is
is
boil
this
thing
down
into
some
sort
of
priority,
so
I
would
love
to
either
we
can
talk
about
it
or
actually
the
right
way
to
do.
A
It
would
be
to
do
some
pull
requests
with
your
take
on
priority
with
some
commentary,
but
essentially
we
need
to.
We
need
to
seriously
get
this
in
order
and
also
add
things
that
are
missing,
because
Joe
had
some
things
that
we
probably
should
look
at
as
well,
such
as
what
is
the
actual
documentation,
slash
plan
around
breaking
up
the
repos.
What's
the
strategy
for
getting
the
staging
stuff
moved
over?
What
is
the
structure
for
the
incubation
process
moving
forward?
A
Is
that
actually
a
steering
committee
thing
so
there's
a
lot
of
things
that
we
need
to
get
get
moved
around
and
prioritize,
so
this
sort
of
thing
is
notoriously
hard
to
do
in
a
collaborative
meeting,
because
there's
no
good
way
to
vote
or
to
prioritize
this.
But
what
I'd
like
to
know
and
I
could
just
make
notes
in
the
agenda
is:
is
there
anything
if
you
had
to
pick
the
one
thing
that
we
had
to
get
done
on
this
stat?
C
I'm
happy
to
start
talking,
if
others
aren't
for
me,
I
think
getting
the
processes
down
is
probably
the
top
of
the
stack
and
then
you
know
and
I.
You
know
looking
as
a
backlog,
it's
kind
of
broken
up
that
way
and
then
we
can
use
some
of
those
really
critical
things
like
Brian,
just
posted
about
like
the
events
proposal,
or
maybe
you
know,
work
with
Daniel
to
sort
of
get
the
repo
breakup
you
know
stuff.
That
is,
you
know
then
ongoing.
C
Let's,
let's
try
and
sort
of
push
that
stuff
through
the
process
as
a
beta
test
of
the
process
to
make
sure
the
process
is
working.
Well,
so
we,
you
know
I
I,
think
if
we
try
and
take
up
any
of
the
technical
issues
before
we
have
that
process,
we'll
be
doing
a
lot
of
stuff
ad
hoc
that
we
should
have
that
we
should
have
sort
of
you
know.
You
know
a
recipe
and
a
flowchart
for
okay.
A
C
I
think
you
know
as
we
as
we
work
through.
You
know
those
first
things
for
those
processes.
There's
probably
going
to
be
folks
involved,
who
are
not
super
active
members
of
this
group,
and
so
it's
a
good
way
for
us
to
say
you
know,
get
honest
feedback
to
make
sure
that
we're
not
totally
huffed
paste
with
what
we
think
a
reasonable
process
is
I.
D
Would
also
say
we
probably
want
to
start
like
see
the
processes
as
a
pipeline
and
start
at
the
beginning
of
the
pipeline
with
the
proposal
ones
so
that
proposals
that
are
being
opened
now
have
the
information
and
the
structure
that
we're
wanting
to
kind
of
make
the
later
processes
like
review
and
and
things
like
that
easier.
Instead
of
having
to
go
back
and
fix
proposals
and
say,
oh
actually,
we
need
to
think
about
these
10
things.
C
C
C
G
May
be
part
of
the
templated
process
could
be
to
outline
scenario
is
when
you
should
go
to
the
architectural
committee
to
decide
if,
if
this
should
be
approved
by
them
cross-cutting
features
or
are
a
good
example.
But
if
it's
isolated
do
a
cig,
it
doesn't
make
sense
for
me
unless,
unless
it
percolates,
though,.
D
C
D
C
A
A
A
Brian
I
know
you
can't
really
talk
but
not
vigorously,
if
you,
if
you
feel
like
there's
enough
to
go
on
in
this
discussion,
maybe
reprioritize
the
backlog
based
on
your
your
opinions,
okay,
cool,
because
it
feels
like
there
is
but
you're
the
one
who
who
put
that
in
the
backlog.
So
I'd
love
for
you
to
be
able
to
to
interpret
it.
And
then
then
we
can
read,
read
great
the
discussion
around
the
backlog
again
so
cool
so
Brian
to
take
a
cut
at
reorganizing
the
backlog.
A
Great
calling
that
out
as
an
action
item
and
we'll
review
that
either
next
next
meeting
or
in
the
disc
Joe,
so
I
put
a
discussion
item
one
from
above
as
a
placeholder
for
what
we
decided
because
we're
in
a
situation
where
that's
a
more
broad
decision
than
that
and
we're
actually
going
to
reformat
the
backlog.
I
would
say
that
this
that
maybe
we
could
treat
the
remaining
part
of
the
meeting
is
either
review
of
the
things
we
talked
about
last
time
or
office
type
hours.
So
we
can
discuss
things
Brian
feelings
on
that.
A
A
A
A
A
A
B
How
one
question
that
I
have
for
Joe
I
was
unable
to
resolve
his
comments.
I,
don't
I,
guess
personally
know
of
a
better
high
level
metric
for
success
other
than
the
ability
to
build
together,
this
user
facing
documentation
like
the
release,
notes
or
the
release,
announcements
or
yeah
for
yeah.
For
the
usefulness
of
an
enhanced
proposal
process
I
would
love
to
hear
many
suggestions.
There.
B
We
saw
I
added
in
the
in
the
proposal
that
at
least
it
seems
to
me.
I
haven't
been
in
cig
release
and
sig
p.m.
that
it
creating
a
high
quality
proposal.
Is
another
cross.
Sig
function,
it's
a
special
case,
at
least
in
my
mind,
because
at
least
while
trying
to
watch
the
document,
a
our
tech
writers,
try
to
build
this
documentation
and
having
to
see
the
back-and-forth
they
have
to
do
it
so
I
mean
something
seems
to
me
to
change
there.
C
So
yeah
I
totally
agree
that
we
need
a
better
way
to
actually
understand
what
are
the
major
changes
going
into
a
release
that
we
can
pull
together.
You
know
the
checklist
around
documentation,
the
checklist
around
release,
notes,
so
I
get
no
argument
from
me.
There
I
think
the
question
in
my
mind
and
I'd
love
to
hear
other
sort
of
weigh
in
on
this.
C
You
know
it's
not
scoped
to
any
specific
release,
so
it
seems,
like
you
know,
any
sort
of
you
know
summary
of
what's
going
into
the
release
is
going
to
be
a
subset
and
maybe
references
these
these
proposals,
but
I,
don't
know
if
they're
necessarily
the
same
set,
and
so
that's
really
my
main
concern
here
and
I.
Think
I
saw
Clayton,
put
a
comment
in
there
that
that
you
know
features
or
whatever
we
call.
These
proposals
are
definitely
going
to
stretch
across
release
it
so
yeah
I.
B
B
Would
be
this
would
be
the
kind
of
the
centralized
place
to
find
all
the
information
such
that
you
could
during
the
release
cycle
when
you're
looking
at
the
issues
for
things
that
are
actually
scheduled
or
that
actually
should
have
land
that
actually
landed
in
the
release.
You
can
then
follow
back
rather
having
just
bunk
through
code,
to
figure
out
why
a
change
is
important
and
the
history
there
it's
all
its
in
one
place
and
that
so
it's
a
repository
of
information
and
not
tied
necessarily
to
a
single
release.
B
C
I
would
totally
be
on
board
with
something
like
you
know.
Instead
of
the
release
note
type
of
thing
that
we
put
in
changes,
we
have
a
reference
from
the
change
to
a
cap
and
then,
as
we
cut
releases,
we
have
all
the
actives
sort
of
in
the
process
of
being
implemented.
Caps
have
a
section
so
we're
like
well.
This
part
of
the
cap
got
implemented
in
one
point.
C
C
Stuff,
that
is
all
internal
that
is
not
release,
know
related.
Then
we're
going
to
want
to
have
caps
around.
So
it
just
seems
like
it's.
It's
it's
a
different
thing,
but
I
totally
totally
hear
the
desire
to
have
some
more
formal
process
and
automation
around
sort
of
release,
changes
in
the
release
notes,
because
it's
a
total
disaster
right
now,
yeah
and
I
mean
I'm,
not
a
manual
work.
Yeah.
B
I
guess
I,
don't
I
said
we
would
have
to
see
how
it
goes,
but
in
terms
of
having
a
many
changes
that
wouldn't
need
a
cut,
I
mean
I
think
that
the
cap
is
at
least
in
my
mind,
still
a
vehicle
for
communicating
about
a
change
so
that
it's
at
it.
It
contains
documentation
at
a
high
enough
level
for
a
tech
writer
to
produce
those
the
entry
in
the
release,
notes
and
so
yeah
for
things
that
are
like
bug,
fixes
or
critical
bug,
fixes
or
known
issues.
B
C
I
mean
like
one
rule,
we
could
do
and
I
don't
know
if
this
is
a
good
idea,
it's
probably
not,
but
just
as
a
sort
of
straw
man
as
we
could
say
that
every
user
facing
change
requires
to
be
rolled
up
to
a
cap,
and
so
that
would
force
folks
to
sort
of
bucket
these
things
together.
But
this
means
that
oh
I
want
to
change
the
column
layout
of
cute
control.
I
have
to
write
a
cap,
that's
probably
not
what
we
do
either
well,
but.
C
G
D
G
C
The
first
thing
we
can
do
to
make
things
less
Byzantine
is
have
clear
ownership
right
and
so
having
this
group
either
the
ones
who
sort
of
the
buck
stops
for
the
whole
proposal
process.
That's
at
least
something
which
is
something
that
we
really
didn't
have
with
with
the
future
process,
before
at
least
clear
sort
of
ownership
and
around
that.
G
A
A
That
tells
you
a
lot
about
what
those
need
to
look
like
and
what
they're
trying
to
do,
and
so
in
essence,
the
process
has
to
be
a
way
of
describing
deliverable
value
in
the
case
of
architectural
initiatives,
the
value
we're
delivering
may
affect
contributors
or
it
may
affect
future
iterations
of
the
product
or
the
ways
in
which
it
gets
implemented.
Sometimes
the
delivery
value
is
4/4,
user-facing
content
or
firm
for
cluster
operators
or
whatever.
A
That
is
so
as
long
as
we
have
those
those
define
and
then
the
process
is
smart
enough
to
provide
a
chain
of
custody
for
a
feature
or
whatever
it
is
we're
delivering
from
ideation
to
into
delivery
that
that's
that's
all.
We
have
to
account
for
and
I
think
that
Caleb's
proposal
is
very
strongly
rooted
in
that
I.
Don't.
A
D
B
A
A
So
Brian,
you
added
a
comment
on
their
measures.
How
many
features
use
the
process?
How
many
proposals
merge
before
the
code
does
and
latency
to
approval?
Those
are
those
are
fantastic,
I
I'm,
a
huge
fan
of
don't
don't
measure
anything
you
can
influence
and
those
all
seem
really
influenced
like
we
can
influence
those
things.
A
C
Mean
one
thing
we
can
do
is
that
we
can
have
some
of
the
caps
that
are
cross-cutting,
require
some
sort
of
higher
level
approval
and
then,
in
other
cases,
when
a
cap
is,
is
relatively
limited
in
terms
of
the
the
SIG's
that
it
heads
it's
more
of
an
informational
communication
device
versus
something.
That's
a
for
a
review
decision
making
in
fact
device
yeah.
D
I,
like
the
idea
of
having
questions
as
part
of
the
template
like
right
now,
a
lot
of
proposals
get
opened
and
we're
kind
of
counting
on
people
in
the
right
areas
noticing
that
those
exist
and
asking
those
questions
themselves
are
going
and
hunting
down
the
people
and
asking
questions
about
proposals.
And
if
we
can
kind
of
ask
some
of
the
cross-cutting
SIG's
like
what
questions
need
to
be
answered
for
new
proposals,
like
is
to
determine.
D
Is
this
something
that
has
impact
on
this
area
and
kind
of
either
make
that
part
of
the
template,
or
just
have
that
as
a
list
that
the
the
various
SIG's
can
maintain
not
to
be
burdensome
like
each
one
should
maybe
have
one
or
two
questions
just
to
kind
of
get
people
to
think?
Is
this
something
that
I
need
to
reach
out
to
this
thing?
For
yes,
know
kind
of
distributing
that
work
and
helping
and
helping
people?
Think
through
that
as
they're
going
to
open
a
proposal.
A
D
Yeah-
and
that
gives
us
a
concrete
way
to
engage
the
SIG's
say:
what
do
you
want
to
know
about
a
proposal
to
know
whether
you
are
interested
or
need
to
pay
attention
or
don't
care
and
that's
something
we
can
maintain
and
adjust?
You
know
if
something
comes
up
and
say:
oh,
this
smells
through
the
cracks
and
we
should
have
been
involved.
Oh
well,
what
question
would
have
triggered
that?
Let's,
let's
update
this
and
iterate
on
it.
A
A
A
A
There's
activity
going
on
in
chat,
Brian's,
asking
I
where's
the
proposal,
template
and
there's
another
it's
been
extracted,
but
not
in
a
Pierre
yet
so
in
case.
You're.
Looking
for
that
and
for
four
new
arrivee
brian
is,
is
sick
and
is
not
able
to
speak
so
keep
your
eye
on
chat
for
for
brian's
commentary.
B
A
A
A
A
A
B
B
D
Down
on
the
weeds,
but
as
we
start
like
putting
the
structure
and
data
into
these
proposals,
we
should
think
about
like
in
the
future
when
we
improve
these
and,
like
add
new
things,
revise
these.
However,
what
are
we
gonna
do
with
all
proposals.
I
know
we
kind
of
hit
this
issue
with
the
features
repo,
where
we
had
a
template
that
had
a
ton
of
stuff
in
it
and
then
a
bunch
of
features
got
opened
and
then
we
change
template
and
they're.
D
All
these,
like
ten
percent
completed,
opened
it
just
kind
of
lingered
on
I,
don't
really
know
what
we
want
to
do,
but
we
should
at
least
consider
like
this
will
happen.
We
will
want
to
adjust
the
template
and
adjust
the
metadata
and
we
should
figure
out
kind
of
what
we
want
to
happen
with
all
the
things.
A
B
A
I
think
that's
you
know.
Brian
I
think
that's
a
great
suggestion
to
update
old
Doc's,
because
that'll
also
suss
out
places
were
like
hey
this.
This
thing
has
metadata
that
we
actually
might
need
another
other
places,
so
I
think
that's
the
the
same
goal
as
Derek's
proposal
about
retro
actively
working
a
feature
through
the
process.
A
A
B
E
B
Yeah
yeah-
that
is
a
good
point,
but
I
guess
yeah,
it
would
be.
My
suggestion
would
be
to
you
either
and
for
blunderbuss
just
remove
the
rely
on
the
aliases
and
I
guess
kind
of
dovetails
with
something
that
Joe
and
now
I
guess
I
should
be
working
on
as
well
is
creating
a
list
of
the
list
of
contributors
and
associates
creating
that
team's
programmatically
in
github.
So
then
you
can
replace
all
the
individual
people
and
the
others
files
with
just
the
orders.
Aliases.
B
Good
enough
yeah
yeah,
that's
that's
true,
which
I
think
is
kind
of
I
suggested
to
punt
that
to
the
team
level
rather
than
trying
to,
however,
Auto
sign
a
single
individual.
Now
you
do
have
problems
with
people
claiming
but
yeah,
and
you
do
have
also
have
to
have
trust
between
the
members
of
the
sake,
since
anyone
could
then
approve
on
behalf
of
the
sig.
But
vui
is
kind
of
nice
for
that.
It
says
that
who
did
it
on
behalf
of
which
team
when
they
actually,
when
you
actually
merge
a
PR.
A
Yeah,
better
I
think
the
team
aspect
to
that
seems
smart.
So,
in
terms
of
you
know
something
you
said
Kevin,
which
I
love
is
that
it
changes
are
cheap
and
in
CVS.
So
it's
if
we're
version
control
so
like.
Why
do
why
are
we
so
concerned
or
what
not
about
some
of
the
making
it
out
of
bounds?
Change
like
what?
What
is
why
is
that
considered
such
a
high
risk?
Is
it
because
there
are
not
a
not
backstopping
processes
that
we
catch
such
a
thing?
Er
yeah,
because.