►
From YouTube: Kubernetes SIG Architecture 20180426
Description
http://bit.ly/sig-architecture
Discussion on the charter
A
A
Am
your
host
Jay,
singer,
Dumars
and
co-host
of
the
sig
currently
is
Brian
grant
and
will
kick
off
the
meeting.
The
agenda
is
located
at
bit
that
Lisa
good
architecture.
If
you
want
to
follow
along
after
the
fact
and
see
the
notes
taken,
we
do
need
a
note-taker
volunteer,
so
I
am
unfortunately
not
able
to
do
it
this
time
due
to
technical
issues.
So
if
anybody
could
take
notes
as
we
go,
that
would
be
tremendously
appreciated
and
I
can
do
that.
If
you
look
oh
thank
you
so
much,
that's
very
kind.
A
Okay,
so
the
looks
like
so
just
digging
into
the
the
overview
of
the
agenda.
It
looks
like
we're
going
to
talk
trader
and
some
leads
and
how
that
fits
into
the
Charter.
So
first
off
is
the
Charter.
Pr
is
up,
there's
a
link
to
it
in
the
agenda.
I
will
paste
it
also
in
chat.
If
that
is
helpful,
of
course,
copying
is
not
super
easy.
A
A
So
yeah,
basically
right
now
we
don't
have
any
comments
on
it.
I
made
a
note
in
this
PR
in
the
in
the
comments
about.
There
was
a
running
discussion
that
wasn't
resolved
and
was
really
about
talking
about
company
affiliation
as
a
key
determiner
for
membership
in
the
lead
positions,
and
so
that
it
was
basically
largely
resolved
for
the
the
chairs,
because
the
chairs
are
considered
or
should
be
considered,
not
power
positions
in
a
sense
of
decision
making,
they're
really
administrative
trying
to
help
coordinate
resources
and
whatnot.
So
the
yeah.
B
A
And
so
then
the
remaining
discussion
was
around
the
technical
leads
and
whether
a
majority
of
technical
leads
were
required
to
be
not
of
the
same
company
and
with
three
technical
leads.
That
means
the
factor
that
everybody
has
to
be
from
a
separate
company,
so
that
is
where
the
discussion
is.
I
would
like
to
have
a
productive
discussion
around
this
and,
interestingly,
it
looks
like
some
of
the
edits
and
things
around
the
candidates
and
chairs
reticulate.
A
C
So
one
quick
thing,
though,
with
the
chairs:
they
do
not
only
do
certain
amount
adjust
to
go,
but
they
do
do
wrangling
during
the
meeting
and
if
one
company
has
the
ability
to
control
how
the
meeting
is
wrangled
that
can
lead
to
certain
kind
of
non-technical
kind
of
controls
over
it.
And
so
that
is
sometimes
why
chairs
from
multiple
organizations
is
desired.
Just
because
of
how
they
can
how
they
can
direct
the
flow
of
a
meeting.
Yep.
B
A
D
D
This
could
very
well
be
a
pretty
powerful
set
of
folks
in
terms
of
making
technical
decisions
that
that
the
the
avenues
for
appeal
are
going
to
be
relatively
limited
and
so
having
to
be
a
self-reinforcing
set
of
group
of
people
where
they
get
to
actually
nominate
their
replacements
doesn't
seem
the
right
way
to
actually
deal
with
that.
Has
that
much
power
in
control?
Again,
it's
gonna,
be
you
know,
there's
the
spirit
of
this
stuff
and
then
there's
sort
of
de
facto.
D
How
does
it
play
out
over
time
how
much
power
and
how
much
influence
does
this
group
have
and
then,
with
that
in
mind,
having
a
small
group
of
three
also
seems
fairly
limited
I?
You
know
a
huge
amount
of
respect
for
the
three
folks
that
are
named
there:
Clayton
Tim
and
Brian,
but
the
truth
of
the
matter
is:
is
that
I
think
you
know?
Kubernetes
is
a
bigger
project
than
those
three
folks
and
I.
D
Don't
think
that
they
represent
sort
of
the
the
breadth
of
a
lot
of
the
projects
that
are
ongoing
and
the
things
that
are
part
of
the
ecosystem,
so
I
think
we
need
to
make
sure
that
we
get
a
wider
swath
than
just
the
you
know.
These
super
super
core
components
that
are
represented
by
these
three
folks.
Let.
C
Me
it
can
I
ask
a
quick
clarifying
thing
in
that,
because
Joe,
you
talked
about
the
ecosystem
and
a
lot
of
the
projects
that
are
going
on
if
I
understand
it
right.
Sig
architecture
is
deals
with
the
architecture
of
core
kubernetes,
and
that
means
that
the
sig
technical
lead
wouldn't
be
able
to
say
step
into
dashboard
or
something
like
mini
cube
and
make
architectural
decisions
on
that,
because
it's
not
part
of
the
core.
It's
one
of
the
other
sub
projects
is
that
right
on
the
clarifying
for
for
scope
of
this
right.
B
C
B
I
think
also
something
about
that
is
that
we're
not
intending
the
technical
ease
to
step
into
any
sig
and
and
tell
them
what
to
do
necessarily
it's
more
of
an
arbitration
role
and
I
would
hope
it
doesn't
get
exercised
too
often
and
practically
speaking,
regardless
of
how
many
people
it
won't
be
able
to
be
exercised
very
often
just
because
they
won't
have
the
capacity
to
arbitrate.
Every
single
technical
decision
in
the
project.
Trust
me
I've,
been
there.
B
So
hopefully
those
will
additionally
shed
additional
load
off
the
technical
weeds
like.
If
you
look
at
the
responsibilities
it's
tried,
we
tried
to
design
it
to
be
fairly
limited,
to
keep
it
to
things
like
creating
new
sub
projects
inside
architecture
and
dealing
with
escalations
from
areas
of
the
project,
and
my
other
rationale
for
keeping
it
small
was
to
just
avoid
like
design
by
committee,
kind
kinds
of
things
and
we
can
potentially
grow
it
in
the
teacher.
B
If
we
need
to
I
think
it's
unclear
what
in
practice
it's
gonna
mean
I,
we
and
I
think
you
know
the
people
who
come
to
cigar
structure
so
far
for
consulting
and
advice.
You
know
I
think
we
try
to
be
respectful
of
all
the
opinions
that
are
raised
in
architecture
and
so
far
I've
had
pretty
good
discussions.
Api
review
is
the
most
common
case
and
that
specifically,
is
going
to
be
a
sub
project
and
we
can
deal
with
it
that
specific
issue
and
that's
a
project.
B
D
I
think
the
other
one
more
concern
here
is,
you
know
Brian
you're.
Obviously,
here
you
know
pretty
much.
Every
meeting
clayton's
frequently
in
attendance,
Tim
I
mean
we
haven't
seen
Tim
here
for
awhile
Clayton's,
not
here
right
now.
I
I
don't
feel
like
being
here
members
nope.
What's
that
you're
here,
yeah.
E
D
D
Different
role
than
this
role
right,
because
I
think,
if
we're
gonna
scope
this
for
just
curating
the
set
of
sub
projects
in
the
business-
and
you
know
for
save
architecture,
then
it
should
probably
be
the
set
of
folks
who
are,
you
know,
have
been
involved
with
save
architecture
over
time
and
and
Brian
just
got
done
saying
that
that's
a
very
different
job
from
technical
analyst.
That's.
E
True
but
I
mean
like
in
terms
of
I,
was
referring
to
in
terms
of
the
curation
of
what
is
or
isn't
in
terms
of
sub
projects
and
again
like
we're
kind
of
like
the
arbitration
part
I
think
is
the
most
important
part.
This
is
having
a
technical
backstop
for
arbitration
that
can
help
close
the
loop
but
I
agree.
The
set
of
roles
that
are
well.
B
B
D
Also
wonder
you
know
one
two,
three,
four,
five,
six
seven
sub
projects
right
now
there
are
sixteen
people
on
the
call
right
now,
Dan's,
probably
not
gonna,
volunteer
to
actually
sign
up
for
a
for
a
sub
project.
Oh
and
he's
listed
there
twice,
so
we
have
fourteen
people
on
the
call
right
now.
I
feel
like
we're
cutting
this
in
terms
of
the
participation
that
we
have
right
now
in
the
sig.
We're
cutting
this
pretty
fine
yeah.
B
We
could
definitely
fold
some
of
those
sub
projects
together.
What
I
did
to
create
that
list
is
I
took
the
initial
set
of
responsibilities
that
we're
in
the
original,
Charter
and
refined
it,
and
map
I
did
combine
a
couple
of
their
responsibilities,
but
I
did
map
them
mostly
one-to-one
I,
also
split
them
by
artifact,
which
it
doesn't
have
to
be.
B
There
are
lots
of
sub
projects
and
other
SIG's
that
combine
multiple
sets
of
artifacts
together,
like
API
machinery
has
tons
of
stuff,
so
a
lot
of
them,
like
all
the
client
libraries
fold
into
one
sub
projects.
So
we
can
definitely
do
that.
Deprecation
policy,
maybe
doesn't
need
to
be
a
separate
sub
project,
for
example,
so
I
mean.
D
So
practically
you
know
what
we've
seen
is
folks
have
a
gnarly
technical
issue
or
architectural
issue
that
cuts
across
components
in
kubernetes
they've
come
to
this
group
to
say:
hey
how
do
I
make
forward
progress
to
solve
this
problem?
What's
the
best
way
forward,
this
group
has
rendered
opinions
at
some
point.
There
may
be
hard
decisions
to
be
made
there.
D
That's
sort
of
the
primary
function,
I
think
most
folks,
just
looking
at
the
titles
will
assume
that
it's
the
sig
tech
leads
are
the
ones
who
are
actually
empowered
to
make
those
types
of
decisions
and
give
that
type
of
advice.
That
is
going
to
be
the
sort
of
de
facto
assumption
for
folks
coming
in
that's
different
from
the
set
of
responsibilities
that
you
have
listed
here
and
should.
D
The
name
of
the
role
technical
arbitrator
arbiter-
well,
the
but
an
arbiter,
is
that's
exists.
The
same
thing
right
I
mean
it's
like
people
are
like:
hey
I
need
technical
help
on
how
to
make
progress
with
something
in
kubernetes,
I'm,
not
sure
how
and
where
and
how
it
lands
where
to
make
forward.
There's
constantly
this
is
the
group
that
deals
with
you
know
this
cig
in
general.
Is
the
group
that
deals
with
with
teasing
that
apart
I
think
it's
useful
for
us
to
name
the
set
of
people
who
are
empowered
to
do
that.
D
A
C
A
C
Yeah
I
just
add
under
what
Joe
said
you
know.
One
of
the
things
people
are
gonna
do
is,
if
say,
they're
in
the
architectural
governance
you're
dealing
with
one
of
the
sub
projects
or
somewhere
else,
and
they
don't
like
the
answer
they
got.
They're
gonna
want
to
go
to
the
arbitrator's,
the
tech
leads,
and
so
that
you
know
well.
We
can
see
that
how
and
where
they're
from
and
who
they
rep
present
matters
in
that
because
of
somebody's
from
one
company
and
they
say
I'm
gonna
go
to
the
arbitrator's.
C
Who
are
my
company
and
try
and
get
those
things
will
happen.
I've
actually
heard
people
say
no
I'm
going
to
want
to
go,
do
something
like
that,
and
so,
when
we
look
at
who
they
are
and
the
responsibilities
that
they
have
in
writing,
we
should
probably
take
into
account
what's
going
to
happen
when
bad
actors
or
people
try
to
take
advantage
of
that.
F
Just
that
I
would
imagine
a
lot
of
this
arbitration
will
actually
happen
in
the
sub
projects.
So
if
someone
comes
to
the
sig
and
says
I
need,
you
know
to
understand
how
to
like
make
my
API
work
or
whatever
they
will
go
to
that
or
be
redirected
to
that
sub
project,
to
get
some
sort
of
opinion,
arbitration,
etc,
and
only
if
that
breaks
down
as
I
think
we
pointed
out
so
so.
I
would
hope
that
escalation
to
the
sig
leads
is
relatively
infrequent
very
infrequent.
Well,.
D
So,
first
of
all,
you
made
the
mistake
of
complaining:
sig
leads
in
the
detect
and
the
tech
leads
and
all
that
right.
So
so
that's
one
thing
right
there
and
in
number
and
number
two
is
that
I
think
yeah.
The
intent
of
this
Charter
and
of
this
process
is
to
have
these
issues
be
dealt
with
by
sub
projects.
I
think
practically
folks
are
gonna.
D
D
That,
historically
honestly,
I
mean
like
so
much
of
the
decision
making
in
kubernetes.
Up
until
now
has
been
person
to
person
talking
to
people
out
of
band.
We,
you
know
we're
trying
to
get
better
at
redirecting
people
to
actually
go
through
sort
of.
You
know
wearing
different
hats
going
through
certain
groups,
but
at
the
end
of
the
day
you
know
in
this
particular
sig.
There
will
be
a
set
of
people
who
have
a
certain
amount
of
power,
and
people
will
assume
that
that's
the
that's
the
the
sig
tech
leads
I
mean
Tim.
E
Or
Joe
just
alike,
I
kind
of
agree
in
one
respect.
I
disagree
in
the
other,
so
I
agree
and
there's
the
fact
that,
like
we're
all
wearing
like
seventeen
hats
and
it's
getting
really
confusing
just
to
switch
hats
day
to
day
between,
like
you
know,
that's
like
something
that,
like
we
as
mature
adults
in
a
community
to
have
correct
interpersonal
relations,
have
to
do.
E
I
was
kind
of
wondering,
like
there's
an
immense
amount
of
authority
that
approvers
in
projects
are
wielding
today
like
so
it's
kind
of
interesting
because,
like
you,
bring
that
up
and
I'm
thinking
like
people
make
massive
changes
for
good
reasons
within
six
today,
like
it's
not
really
a
like,
you
can
change
the
arc
of
kubernetes
significantly
within
a
sig
as
an
approver
of
a
project.
No
matter
what
and
that's
a
good
thing,
because
that's
delegating
you're
mostly
concerned
I,
think
about
the.
E
D
There's
there's
a
larger
issue
here
where,
as
you
say,
that
lots
of
people
make
sweeping
changes
and
it
happens
within
a
sig,
and
that
does
happen.
But
we
also
see
a
lot
of
times
where
people
make
sweeping
changes.
It
cuts
across
SIG's
and
they
find
the
the
minimal
set
of
users,
often
within
the
same
company
that
are
approvers.
And
then
they
showed
that
through
without
necessarily
getting
the
right.
Visibility
and
oversight
across
things
is.
D
Haven't
seen
that
recently,
like
you
know,
I
nothing
comes
to
mind
within
the
the
past
couple
of
months.
This
is
a
pattern
that
we've
seen
in
the
past
and
it's
something
that
I
think
part
of
us
getting:
the
SIG's
more
empowered.
It's
making
sure
that,
like
if
changes
cut
across
SIG's,
even
if
there
are
some
of
the
same
people
involved,
we
get
the
the
right
level
of
visibility.
D
B
D
So
where
is
there
an
API
document
covering
the
new
jot
stuff
that
that
that
Mike
has
done
right?
It's
like
that
stuff
was,
you
know,
I
had
to
like
call
an
audible
on
that
saying
we
should
have
a
document
that
should
go
through
API
review,
I,
don't
know
if
it
has
gone
through
API
review.
My
guess
is
that
he
reached
out
to
you,
know
Tim
or
somebody
at
Google
who
was
on
the
API.
Reviewer
got
a
rubber-stamp
there
actually.
E
If
Jordan
and
me
Jordan
will
say,
goth
hat
me
and
an
API
reviewer
hat
looking
Joe,
this
is
actually
a
good
point.
Cuz,
like
that's
a
working
group
that
has
represented
interesting,
a
bunch
of
SIG's
in
it,
including
the
owning
SIG's,
and
the
people
were
reviewing.
Who
are
backstops
on
that.
So,
like
I
mean
it's
a
good
example
it
it
definitely
may
have.
D
I,
don't
think
it
was
I,
don't
there's
no
maliciousness,
there
I
think
that's
just
an
issue
of
like
as
we
introduce
you
know.
New
TI's
like
that
I
I,
still
don't
feel
like
I
mean
that's,
that's
a
changing
the
trajectory
of
the
project
to
some
degree
we're
adding
more
and
more
auth
stuff.
Kubernetes
is
becoming
more
and
more
of
a
sort
of
ground
truth
auth
provider
in
a
bunch
of
places.
That's
an
architectural
decision
that
wasn't
run
by
this
group
is
run
by
a
set
of
people
who
wear
hats
across
SIG's.
B
G
B
A
F
Have
two
screens,
admittedly
so
I
hope
the
people
on
one
screen
and
the
presentation
on
the
other,
but
that's
fine
and
I
stopped
presenting
I
didn't
have
anything
concrete
to
add
really
other
than
the
fact
that
I
mean
we
do
have.
If
we
don't
like
the
way
a
given,
sig
is
operating.
If
we,
you
know
just
to
take
this
example,
if
we
think
sig
off
is
kind
of
doing
crazy,
stuff
I
think
we
do
have
the
ability
to
parachute
someone
in
there
and
I
mean
for
the
most
part.
F
We
have
the
key
SIG's
represented
on
this
thing,
and
if
we
do
think
that
they
are
doing
things
that
are
stretching
their
boundaries
or
doing
something
that
this
group
doesn't
think
is
a
good
idea
that
we
we
have
pretty
clear
mechanisms
for
addressing
that,
and
they
don't.
They
don't
have
to
involve
like
adding
a
lot
more
process.
They
involve,
you
know
telling
Clayton,
we
don't
think
sig,
of--this
or
Jordan.
Whoever
is
kind
of
involved
there
that
we
would
like
them
to
do
things
differently
or
parachuting
people
in
there
to
you
know,
influence
those
discussions.
E
Is
actually
interesting?
It's
like
everybody
you
mentioned,
including
all
the
leadership
of
sig
off
enough
of
the
representation
from
another
six
and
a
bunch
of
people
in
the
community
were
involved
in
those
kinds
of
things
and
like
I.
Think
that
is
a
good
example
of
like
I
would
say
that
all
the
stakeholders
were
there.
The
sign-off
perspective
is
kind
of
what's
interesting
because
it's
like
there
was
a
there's
like
you
know,
all
the
people
that
we
would
normally
delegate
to
to
make
that
decision
and
made
that
made
a
set
of
decisions.
E
But
what
causes
the
concern
into
Joe's
point
is
feeling
like
sig
architecture
should
get
to
say
that
and
the
kept
process
is
the
way
to
do
that,
but,
like
I,
would
kind
of
like
resource
management,
grew
scope
of
kubernetes
and
we
didn't
really
like.
We
didn't
officially
go
through
a
review
on
it,
but
like
there's
a
ton
of
work
there
and
basically,
we've
delegated
the
responsibility
to
grow
resource
management
to
the
working
group
and
they've
done
that
more
or
less
right.
E
The
device,
plugins
and
Nvidia
drivers-
and
you
know
all
this-
it's
like
there's
a
weird
I-
think.
There's
an
interaction
of
like
cig
architecture
is
a
Vito
group
and
weed
sounds
like
we
just
weak
on
that
process
of
like
when
the
cap
is
the
big
part
of
that,
and
that's
like
a
good
example
of,
like
all
the
technical
stakeholders
about
what
was
the
right
thing
to
do.
In
the.
A
C
D
B
D
Joe
yeah
I
think
you
know
my
concern
is
not
that
I,
don't
think
any
SIG's
are
off
the
rails,
I,
don't
think
anybody's
doing
anything.
Malicious
I
think
that
you
know
my
biggest
concern
is
again
I
I,
don't
think
we
necessarily
things
through
cigs.
We
don't
think
about
work
streams
for
cigs,
because
there's
a
lot
of
overlap
of
people
between
SIG's.
If
somebody's
insig
off
and
they
happen
to
be
an
API
reviewer
boom,
they
can
do
whatever
right
and
I
think
we
need
to
think
about.
D
B
B
So
I
mean
that
is
one
of
the
kinds
of
patterns
that
I
do
see
a
lot
where
either
people
don't
go
through
their
proposal
process
or
they
do,
but
they
don't
actually
attempt
really
to
push
it
through
to
closure,
and
that
is
something
I
was
whether
it's
kept
or
something
else.
I
would
like
to
try
to
solve
that,
so
that
there's
more
clarity
about
what
we're
actually
doing
and
whether
audrina
has
been
reached
and
whether
it's
done
and
things
like
that
and.
G
One
thing
I
would
like
to
see
is
kind
of
a
roadmap
for
a
feature
like
because
what
we
have
frequently
is
there's
a
there's,
an
agreed
on
goal
and
then
there's
an
agreed
on
first
set
of
steps,
and
then
there
are
other
issues
that
need
to
be
worked
through,
but
the
first
set
is
agreed
on
and
trying
to
figure
out
how
to
describe
that
and
represent
that
and
say.
Yes,
we
agree
on
steps
a
B
and
C.
G
Let's
go
start
working
on
that
and
then
the
hammer
hammer
outs
like
the
next
set
and
right
now
it's
unclear
like
what
I
see
our
design
Docs,
that
get
merged
with
kind
of
future
work
sections
and
it's
unclear
like
is
this
agreed.
This
is
not
agreed
or
they
just
sit
in
pending
and
it's
not
merged,
and
so.
E
E
E
D
E
It
we
gotta
finish
it
and
that's.
The
thing
is,
like
you
know,
the
proposed
like,
as
just
like,
we
have
a
ton
of
proposals
that
most
of
the
discussion
takes
place
in
the
first
week
or
two
or
months
and
then
prototyping
starts
and
they'll
be
like
a
comment
on
the
proposal
which
is
like.
Can
you
change
this
one
word
or.
G
E
B
I
Quinton
had
his
hand
up
and
Joe
had
his
hand
up,
but
I
wanna
I
think
we're
way
off
topic
and
I
kind
of
want
to
close
down
this
discussion
and
say
we
should
follow
up
on
the
Charter
or
this
is
a
note.
Take
this
as
an
open
item.
Please
make
suggestions
about
the
name
and
responsibility
and
other
aspects
of
this
role
and
I
will
take
a
look
at
collapsing.
Sub
projects,
Quentin
yeah.
F
My
perspective,
my
sense
is
that
we're
on
the
latter
of
those
view
we're
bogged
down
in
quite
a
bit
of
process
and
not
making
enough
progress,
sure
we're
making
some
mistakes
along
the
way
and
sure
we
could
have
had
some
more
complete
caps
and
things,
but
I
think
we
were
bearing
too
much
on
the
slowing
down
side,
but
but
I'd
be
interested.
What
the
rest
of
the
group
feels
about
that
Joe.
D
So
yeah
so
first
thing
that
I
remembered
what
really
bothered
me
about
the
the
Mike
thing
is
that
it
was
a
it
was
a
sig
off
a
P,
I
thing
and
then
I
turn
around
and
all
of
a
sudden
we're
creating
new
volume
types
right.
So
it
we
expanded
its
scope
and
it
was
like
none
of
that
stuff
was
brought
back
to
the
working
group
or
take
off
that
I
saw
I
might
have
missed
some
meetings
and
such,
but
it
was
like
it
was
all
of
a
sudden
boom.
D
It
brought
in
a
whole
new
set
of
things.
The
second
thing
is
is
with
respect
to
the
Charter
just
trying
to
solve
that
issue.
I
would
be
supportive
of
having
you
know,
out
of
sig
architecture,
coming
up
with
some
sort
of
technical
advisory
board
that
collapses.
Some
of
those
sub
projects
and
the
idea
of
the
tech
leads
recognizing
that
there's
just
going
to
be
a
ton
of
overlap
of
responsibilities
and
it's
gonna
become
a
mishmash
anyways.
So
that's
something
that
I'd
like
folks
to
consider
and
then
with
respect
to
Clinton's
issue,
around
sort
of.
D
Are
we
moving
too
fast
or
are
we
moving
too
slow?
I
think
that
the
project
is
in
dire
danger
of
having
lots
of
features
that
are
not
coherent
and
not
documented
and
collapsing
under
its
own
weight,
and
so
I?
Think
right
now,
in
terms
of
the
number
of
features
we
have
features,
new
features
are:
should
take
a
backseat
to
actually
making
the
project
usable
and
coherence.
D
B
So,
having
been
in
a
place
where,
before
people
were
accusing
me
of
slowing
down
the
project
from
reviewing
everything,
I
mean
that's
definitely
the
trade-off.
You
get
more
consistency
in
cohesion
if
you
review
with
smaller
number
of
people
just
by
nature
of
the
way
that
works,
but
it
indeed
it
slows
things
down.
If
you
actually
look
at
the
github
stats,
they
are
slowing
down
pretty
significantly
and
I.
Think
the
reason
is
mostly
not
process,
although
maybe
depending
on
how
you
argue
it.
B
Maybe
if
you
call
a
process,
but
it's
things
like
technical
debt
and
inability
to
grow
the
the
set
of
reviewers
and
approvers
and
route
issues
to
the
right
people.
When
the
project
was
smaller,
it
was
actually
easier
to
fan
out
things
to
a
larger
number
of
people,
because
it
was
more
obvious
who
those
people
were,
and
there
are
fewer
sources
of
changes
and
and
now
the
volume
is
just
so
high
that
it's
we
not
been
able
to
get
grips
on
the
routing
tasks.
B
Fanning
out
the
set
of
changes
to
the
appropriate
people,
not
random
people,
because
that
ends
up
being
noise
and
communicating
to
the
rest
of
the
project
about
the
technical
direction
that
we
actually
want
to
go.
I've
been
realizing
recently
that
that's
not
super
well
communicated.
So
we
need
to
find
like
we
don't
actually
have
like
a
community
tech
talks
or
interviews,
or
things
like
that,
or
even
talking
about
doing
API
reviews
in
this
meeting.
But
it
doesn't
have
broader,
not
attendance,
to
be
effective
at
communicating
to
the
rest
of
the
project.
A
B
So
one
thing
I
could
do
as
a
specific
action
is.
I
did
write
a
document
about
the
resource
model
and
they
get
in
it
knocked
quite
a
number
of
things
off.
My
document
design
dock
back
with
log
things
that
were
principles
that
we've
been
applying
for
a
long
time
but
were
undocumented
I
could
convert
that
to
a
talk
and
present
it,
for
example.
B
D
When
we
first
did
the
the
community
meeting
on
Thursdays,
you
know
when
I
first
created
that
I
think
my
goal.
There
was
to
do
some
of
those.
You
know
broad
architectural
decisions
api's
now
it's
morphed
into
being
a
more
outward
facing.
Let's
do
a
demo
on
a
report
type
of
thing,
but
I
feel
like
that
meeting.
Is
this
kind
of
drifting
a
little
bit
and
it
might
be
worthwhile
trying
to
retarget
it
to
be
more
contributor,
inward-facing
versus
versus
hey
here's,
a
cool
demo.
We.
B
A
Something
just
quickly
to
go
back
to
the
Charter
for
a
minute
and
the
PR
there's
a
very
important
proviso
in
there.
That
is
that
basically
there's
a
force
to
refresh
on
this
in
six
months.
So
if
people
are
worried
about
this
being
the
law
of
the
land
and
staying
that
way
forever,
there
is
an
and
there's
an
implicit
review.
Reach
reap
ratification
of
the
Charter
in
six
months
after
the
date
after
it's
merged.
A
B
Okay,
so
anyway,
please
do
read
the
charter
PR
we'll
try
to
get
some
feedback
next
week.
Meeting
is
cancelled,
so
I
guess
we
can
revisit
it
in
two
weeks,
but
if
you
do
have
time
in
between
traveling
and
and
whatnot,
please
do
try
to
take
a
look.
Matt
had
the
last
item
on
the
agenda.
I
did
external
tools,
controllers,
updating,
spec
versus
controller.
C
Furman
I
had
to
think
about
it
for
a
minute,
so
the
the
item
was,
we
were
discussing
the
applications
here,
TN
controller
and
one
of
the
things
that
was
in
there
was
there's
a
field
on
the
spec.
That
kind
of
says
the
status
is
the
thing
that
you're
doing
being
installing
is
it
installed?
Is
it
updating
and
whatnot?
C
The
question
came
up
about
shouldn't
that
be
on
a
status
object
instead,
and
the
response
was
well,
it's
external
tools
that
are
updating
this
things
like
coop
controls,
stuff
from
the
CLI,
not
a
controller
running
inside
kubernetes,
technically
or
typically
it'll,
typically
be
something
outside
like
a
CI
CLI,
that's
interacting
with
the
API,
and
you
know
an
ecosystem
tool
and
those
shouldn't
update
status.
At
the
same
time,
a
controller
running
inside
should
only
update
status,
not
the
spec,
and
so
the
question
became
is
what
can
update
stuff?
C
Should
a
CLI
running
externally
be
able
to
update
status
if
it
kind
of
makes
technical
sense,
should
a
controller
be
able
to
updates
back
in
like
where
does
this
come
from?
And
so
there
was
this
kind
of
unofficial
idea
of
controllers:
only
update
status,
nothing
else
and
external
tools
only
updates
back,
never
status,
and
if
there
are
fields
that
may
make
sense
on
the
other
objects,
you
have
to
kind
of
replicate
them
to
the
right
place
or
do
it
there
instead.
Does
that
make
sense,
yeah
that.
B
Makes
sense,
actually,
interestingly,
Wojtek
brought
up
a
similar
issue,
what
should
be
stuck
spec
and
what
should
be
status,
and
this
actually
is
covered
to
some
degree
in
the
API
conventions,
but
this
exact
way
of
slicing
it
is
not
so
that
would
be
a
good
thing
for
me
to
add
to
my
design,
doc
backlog
I
guess
so
there
are
a
few
considerations.
One
is
we
do
have
cases
where
controllers
update
the
spec
of
their
own
resources,
cluster
IPE.
Being
the
canonical
example,
and
people
have
pushed
back
on
that
and
said
well,
this
is
status.
B
Bla,
bla,
bla,
yeah
Jo
is
doing
that
thumbs
down,
but
the
reality
is
status
is
intended
to
be.
Infirm
is
intended
to
be
the
full
desired
state
intended,
including
things
that
are
set
by
automation
and
the
cluster
IP
is
an
example
where
it's
dynamically
allocated.
It
can't
be
read
arrived
from
observation
from
any
other
source.
So
the
reason
that
is
the
reason
that
it's
in
spec,
the
user
can
specify
actually
if
they
want
to
choose
their
own
IP
and
that
will
get
reserved
for
them.
Otherwise,
it's
left
to.
B
You
know
that
to
be
allocated
automatically
as
a
convenience
for
the
user,
but
you
know
at
that
information
we're
lost.
There
is
no
way
to
actually
read
arrive
that
information,
so
that
is
one
of
the
considerations
about
spec
or
status.
The
status
information
should
be
reconstructed
from
observation
of
the
resources
or
external
external
sources.
If
the
controller
is
controlling
some
external
entity
like
an
container
or
something
like
that,
so.
B
B
B
So
I
haven't
seen
a
specific
example:
I,
don't
I
didn't
quite
Drock
the
whole
application,
Sierra
CRD
scenario,
but
I
would
be
hesitant
to
put
things
that
are
set
by
like
a
manually
triggered
process
in
the
status
I
think
there
will
be
clients
that
set
a
number
of
fields
like
leader
election
was
one
case
we
were
discussing.
Currently,
that's
all
in
one
lump
and
an
annotation.
B
So
there
is
a
question
of
you
know
if
that
were
CRD
would,
which
would
any
of
those
fields
be
in
status?
I
need
to
go
back
and
look
at
some
of
those
things,
but
I
believe
all
the
fields
would
be
set
by
the
client
and
none
of
them
by
a
controller.
So
it
wasn't
obvious
to
me
that
any
way
should
be
in
status
so.
C
E
C
E
Anything
that
has
a
selector
is
almost
implicitly
saying
that
the
state
of
the
selectors
we
derived
like
you're,
saying,
observe
these
things.
These
are
all
appropriate
you,
whoever
is
looking
at
those
things,
is
the
one
who
knows
whether
this,
whether
they're
all
in
a
good
state
or
not,
not
the
person
who
provided
the
selector
okay.
C
D
D
You
know
if
you
have
multiple
actors
that
want
to
sort
of
annotate
the
status,
using
the
condition
pattern
where
they
can
add
to
that
array
may
be
having
an
owner
on
that
condition,
so
that
you
actually
understand
which
component
is
writing
what
part
of
the
status
in
an
extensible
way?
I'm,
not
sure
if
that
applies
here
or
not.
That
might
be
something
that's
worth
thinking
about.
B
So
we
actually
in
the
node
objects,
have
at
least
three
entities
that
are
writing
conditions,
cubelet,
the
node
controller
and
no
problem
detector
there.
In
many
cases
there
are
multiple
components
that
can
actually
write
those
fields
and
we're
actually
thinking
of
modeling
it.
As
sort
of
you
know,
who
has
the
lock
kind
of
thing,
so
that's
one
thing
we're
exploring
right
now,
but
some
of
them
would
be
only
written
by
the
node
problem
detector,
so
it
would
effectively
own
those
fields.
I
think
in
many
cases
that's
a
useful
pattern.
B
B
B
Automation
is
a
really
slippery
slope
yeah,
you
know
as
well
like
should
the
replicas
feel
being
status,
you
know
or
CPU
and
memory
should
those
that
you
know
if
it's
set
by
an
auto
scaler
or
something
like
that,
I
don't
know,
I,
don't
actually
think
that
makes
sense.
If
you
look
at
all
the
different
kinds
of
automation
that
we're
adding
and
admission
controllers
and
other
automated
components,
I
think
the
model
is
much
cleaner.
If
you
just
say
you
know
anything,
it
might
be
manual,
it
might
be
automatic.
E
Think
it's
worth
noting
that,
like
every
point
of
difference,
cause
this
confusion
and
so
like
any
case
where
you
have
multiple
riders,
you
know
it's
usually
an
exceptional
case,
so
you
kind
of
want
single
riders,
single
readers,
single
spec
single
status
and
where
it's
different,
try
to
keep
it
low
until
you
until
you
can
split
it
out,
like
it's
people
can't
like
you,
service
IP
causes
problems
because
people
don't
want
to
reuse
services
across
clusters.
Nodes
node
name
causes
problems
because,
most
of
the
time
a
human
doesn't
set
it.
E
D
Would
have
modeled
something
like
the
node
being
sort
of
like
you
know,
desired,
node
and
then
sort
of
assigned
node
and
actually
have
waves.
There
same
thing
that
the
cluster
IP
you
know,
even
if
both
of
those
things
end
up
being
part
of
the
spec
you
know
being
able
to
have
clarity,
for
this
is
the
actor
intended
to
write
this
particular
field.
I
think
helps
to
help
to
get
clarity,
and
so
a
lot
of
this
you
know
the
BS
that
were
sort
of
you
know.
F
The
way
yeah
we
running
into
very
similar
problems
with
Federation,
actually
we're,
and
we
ended
up
splitting
these
things
into
multiple
objects,
just
so
that
it
was
clear
that
this
is
what
the
user
asked
for,
and
this
is
what
some
controller
you
know
allocated
them
and
they're
actually
separate
objects,
and
they
have
single
writer
each
and
everything
gets
much
simpler.
All
right
so.
B
D
B
D
This
is
another
example.
I
think
we're
you
know.
Getting
this
documentation
in
the
right
place
is
making
sure
the
proposals.
Actually
we
know
what
the
status
is.
We
know
where
it
is.
There's
just
I
mean
there's
a
lot
of
great
content
out
there
there's
a
lot
of
great
thinking.
It's
just
not
communicated
in
a
way
where
folks,
you
know
well.
D
G
D
B
And
we
need
to
get
all
that
stuff
documented.
There
are
a
bunch
of
tables
and
other
things
that
were
a
little
bit
hard
and
maybe
didn't
really
fit
in
a
cup
proper,
but
I
think
he
was
planning
to
write.
I
kept
with
kind
of
the
it's
link
out
to
other
materials
and
the
markdown
conversion
and
stuff
seems
to
be
working
reasonably.
So
we'll
probably
use
that
approach
to
get
these
other
artifacts,
not
the
presentations,
probably
but
the
other
documents
can
present.
C
Okay,
I
do
have
one
final
question,
though,
hopefully
final,
the
whole
issue
back
to
the
technical
leads
and
companies
and
that
stuff
that
we'd
started
off
with
we
kind
of
got
off
track
from
it.
But
that
was
the
big
point
that
from
the
original
doc
and
even
from
our
meeting,
didn't
appear
to
be
resolved.
I'm
not
asking
for
it
to
be
resolved
now,
but
I
don't
get
the
impression
it
is
resolved,
and
so
how
do
we
go
from
here
with
that
I.
B
Put
it
to
do
on
that
and
charter
and
I,
and
the
to
do
is
basically
to
rewrite
the
roles
responsibilities
in
the
name
and
structure,
and
things
like
that.
So
I
also
will
made
a
notes
to
go
fold
some
of
the
sub
projects
together
and
make
those
responsibilities
and
authority
more
clear,
so
I
think
those
are
the
two
big
action
items
like
which
things
fall
under
API
review
or
architectural
review
sub
project
versus
what
things
roll
up
to
what
was
called
the
technical
leads,
but
I
agree.
B
A
better
name
is
probably
appropriate,
given
what
we
expect
the
responsibilities
of
that
role
to
be
so.
People
have
suggestions,
please
put
them
there
like
I,
hear
Joe
Joe
mentioned
some
kind
of
advisory
board,
or
something
not
a
hundred
percent
sure
that
that
fits.
But
that
would
be
one
thing
like
you
could
actually
sketch
that
out.
Advisory
board
here
are
the
responsibilities
and
then
people
can
evaluate
whether
it
fits.
So
if
we
have
a
couple
of
alternative
suggestions,
you
can
see
if
any
of
those
really
resonate
with
people.
I
think
that.
A
B
Aha
yeah,
so
thanks
to
everyone
who
helped
flesh
out
the
Charter
Jace
Quinton
Matt,
it
was
a
slog.
You
know
it's
like
several
hours
of
like
copying
in
the
template
and
going
through
and
chasing
down
the
sub
projects
and
refining
the
the
wording
and
working
out
details
about.
Oh,
this
procedure
doesn't
actually
say
how
it
should
work
at
all
and
things
like
that.
There
are
actually
some
things.
B
A
Want
to
add
one
thing:
real
quick,
this
is
just
an
aside.
Is
that
early
in
our
meeting
in
the
first
half
while
we're
having
this
discussion,
there
was
a
new
contributor
who
was
on
this
call
and
send
me
a
private
message,
saying
wow
I
finally
know
what
a
respectful
discussion
around
contentious
topics
looks
like.
So
that's
a
big
kudos
to
everybody
in
this
meeting.
Thank
you.
D
And
I
do
want
to
say
thank
you
for
for
for
Jason
Brian
for
slogging
through
the
the
Charter
stuff,
I
think
you
know
being
able
to
step
back
and
look
at
it
as
a
whole,
really
put
it
in
perspective
and
I.
Think
yeah
I
apologize
for
not
seeing
the
total
shape
until
you
guys,
you
know,
put
that
stuff
together,
but
but
thanks
for
doing
that,.