►
From YouTube: Kubernetes SIG Architecture Office Hours 20171214
Description
A
Thank
you
yeah,
so
general
commented
in
the
slack
and
I
posted
on
the
issue.
The
reasons
why
this
came
up
in
architecture
and
I
think
either
Clayton
or
Jordan
raised
the
issue.
You
know,
and
both
of
them
are
a
guy,
approvers
and
so
yeah.
The
issue
is
purely
one
of
consistency
across
system.
What
kinds
of
api's
do
we
want
to
use
and
what
should
the
level
of
consistency
be?
What
should
the
requirements
on
those
api's
be?
In
the
past
we
pushed
back
on
introducing
some
new
types
of
a
guys.
A
For
example,
there
was
a
PR
at
one
point
for
a
web
hook,
API
for
the
cloud
provider
interface
that
had
totally
different
conventions
from
from
the
user
facing
API.
So
we
pushed
back
on
that
and
that
didn't
get
merged
and
we
eventually
decided
to
do
that
a
little
different
way
anyway,
but
I
posted
the
different
types
we
currently
have
to
the
PR.
A
A
So
I
started
writing
down
shortly
before
this
meeting
some
rationales
so
I'm
starting
creating
this
some
another
topic
for
today's
design.
Documentation,
backlog,
I
have
like
the
list
of
stuff
in
my
to-do
list
that
never
gets
out
of
things
that
come
up
in
PR
reviews
and
proposal,
reviews
and
other
discussions
that
need
to
get
documented
and
I
want
to
start
chipping
away
at
that
backlog,
as
well
as
surface
other
things
that
come
up
and
kind
of
more
systematically
in
the
future,
but
so
the
rations.
So
the
current
API
convention
is
applied
to
user-facing
api's.
A
Web
books
we
have
advocated
for
in
the
case
where
the
API
schema
the
may
also
be
used
in
one
of
the
other
cases.
Where
do
we
expect
a
large
number
of
hook,
receiver
implementations
where
hooks
make
a
simple
policy
decision
like
yes/no
or
other
or
where
Hulk
implementers
may
want
to
run
the
logic
on
a
functions
platform
or
something
like
that?
The
one
case
of
G
RPC
we
have
is
for
an
imperative
style
API
that
needs
to
be
reasonably
high
performance.
But
it's
we
expect
a
relatively
small
number
of
implementations
and
a
single
client
point.
A
So
it's
a
much
more
constrained.
Interface,
I,
don't
know,
I,
don't
remember
what
PRI
is
doing
about
versioning,
but
if
we
want
to
impose
like
meta
requirements
on
API
is
probably
some
kind
of
versioning
strategy
needs
to
be
one
of
them.
Whether
it's
you
know
support
two
different
API
is
for
an
extended
period
for
the
whole
deprecation
policy
period,
or
you
know
some
more
principled
form
of
versioning
as
TBD.
A
B
A
C
B
D
A
B
Guess
about
what
I'm,
what
I'm
trying
to
say
is
that
is
that
understanding
the
reasons
for
why
that
CD
moved
to
G
RPC
with
SC
d3?
How
that
impacted
the
system
as
a
whole
I
think
is
instructive
in
terms
of
informing
the
discussions
of
when
something
like
G
RPC
might
be
appropriate
in
you
know,
as
we
look
at
other
places,
that's
that's
all
I'm
trying
to
say
they're
kind.
It's
definitely
part
of
our
architecture,
whether,
where
they're
going
to
find
it
or
not.
That's.
A
A
great
point,
the
I
actually
think
we're
at
C
D.
The
change
to
binary
was
far
more
important
that
a
binary
protocol,
as
opposed
to
text,
was
far
more
important
than
G
RPC
versus
some
other
transport
mechanism,
but
but
definitely
that
should
inform
the
decision.
So
I
think
it's
clear
that
there
are
different
flavors
of
api's
in
different
use
cases.
You
know
the
LCD
one
is
not
a
declarative.
A
Api
has
basically
a
single
client
point
and
a
small
number
of
implementations,
which
is
one
at
the
moment,
may
not
stay
one
forever,
but
it's
one
at
the
moment.
So
in
that
way,
CRI
and
EDD
are
similar
and
I
think
the
kms
is
similar
to
that
there
were
some
missing
points
about
you
know:
what
is
this
T
with
respect
to
a
credential
management?
Does
it
make
it
different
from
everything
else
put
on
the
list
so
does
Jordan?
Did
you
want
to
say
anything
about
that
or.
D
I
actually
was
unsure
whether
we
were
expecting
this
to
be
credential,
but
first
I
was
sort
of
expecting
it
to
be
exposed
over
the
main
socket
locally.
So
you
weren't
having
to
hit
the
network
you
sort
of
get
into
chicken
and
egg
scenarios.
If
you
are
wanting
to
distribute
credentials
to
use
this,
but
this
is
being
used
to
encrypt
and
decrypt
credentials
distributed
via
the
API
ended
in
the
document
that
was
linked.
There
was
a
pretty
strong
agreement
that
this
would
start
as
a
local
socket,
so
we
wouldn't
be
going
over
network.
Okay,.
A
E
B
Think
I
mean
you
know
from
that
point
of
view.
It's
similar
in
some
ways
to
the
hash
record,
plug-in
model
where
it.
You
know
it's
a
little
bit
difference
because
it's
more
envelope
II
in
terms
of
it,
executes
the
thing
and
manages
execution
in
addition
to
using
G
RPC.
But
there
still
is
that
tight
coupling
within
a
within
a
local
context
versus
trying
to
do
this
over
the
network.
Yeah
and.
D
E
D
D
D
D
So
I
think
if
you
were
going
to
have
multiple
versions
of
the
runtime
service
for
CRI,
the
version
request
and
response
would
need
to
stay
backwards
compatible
and
the
version
is
the
first
tagged
field
and
from
what
I
can
tell
that
is
the
one
that
is
essential
in
determining
compatibility.
So
that
seems
like
a
reasonable
pattern
to
follow.
F
You
can
you
can
get
a
list
of
which
interfaces
which
ERP
C
services
rather
are
declared,
but
you
don't
necessary
to
clear
an
ooh
G
are
poor,
are
supported
by
a
service,
but
you
don't
so
you
want
to
get
them.
Declare
a
new
G
RPC
service
for
each
minor
bump,
so
I
wish
it,
which
I
presume,
is
the
point
of
the
version
field
so
that
we
we
can
essentially
do
some
versioning.
But
if
we
had
a
major
revision
of
the
API,
we
could
declare
kms
v2,
but
we
don't
have
to
declare
KMSP
2.1.
For
example.
A
B
Well,
I
think
I
think
just
having
I
think
there's
two
levels
of
discovery
here,
so
so
three
levels,
maybe
there's
the
yeah
there's
the
api
compatibility,
which
is
what
you
get
with
gr
PCM
protobufs,
where
you
know
that
at
least
you'll
have.
If
you
follow
a
certain
level
of
rules,
you'll
have
some
level
of
binary
compatibility,
there's,
discovering
semantic
rules
and
assumptions
right
and
that
may
change
over
over
things.
B
Even
with
the
same
interface,
you
may
say:
okay,
with
this
version,
we're
expecting
that
they'll
be
a
certain
set
of
rules,
and
so
that
helps
you
avoid
sort
of
user-agent
happiness
and
then
the
third
thing
is
being
able
to
do
true
introspection.
Where
you
can
say:
okay,
show
me
all
the
other
fields
and
all
that
and
you
can
write
generic
clients
against
it.
I
think
adding
a
version
method
to
a
G
RPC
service
lets.
You
hoist
from
sort
of
the
the
syntactic
compatibility
to
semantic
querying
right,
where,
if
you
add
a
new
field,.
D
B
D
Are
the
mean
if
you
send
that
field
that
changes
the
meaning
of
some
of
the
other
fields
like
what
should
happen?
That
probably
requires
a
version
buff,
because
in
order
to
use
that
thing
you're
calling
has
to
know
you
are
at
this
new
semantic
level
and
pay
attention
to
that.
Instead
of
just
ignoring
unknown
sort
of
field,
yeah.
B
Because
I
think,
if
we
look
at
C
and
I
and
all
the
issues
around
initializing
cni
and
what
happens
when
things
fail
and
where
the
failure
semantics
it's
exactly
the
same
interface
really
I
mean
it's
not
G
RPC.
It's
because
it's
an
exact
interface
but
but
there's
a
semantic
change
or
at
least
a
semantic
clarification
as
we
move
from
one
version
to
another,
with
C
9.
A
Okay,
so
I
think
we
have
a
decision
effectively,
which
is
G.
Rpc
is
appropriate
to
this
for
this
API
I'm
writing
down
some
in
the
documentation,
backyard.
I'm
writing
down.
Some
criteria
like
API,
is
imperative.
There's
a
single
in
system,
clients
and,
as
we
expect
a
small
number
relative,
leo
server
implementations,
and
it's
going
to
be
especially
it's
going
to
be
local
on
the
same
node
for
the
in
order
for
this
to
go
forward
so
just
like
in
general.
A
B
Yeah
I
would
say
I'd,
say
part
of
that.
Local
implication
is
that
this
is
essentially
outside
of
the
sort
of
authentication
authorization
model
that
we've
built
for
the
rest
of
kubernetes
right.
This
is
really
a
tightly
coupled
plug
in
early,
more
coupled
plug-in
mechanism,
and
then
the
the
you
know
we're
not
going
to
try
and
apply
kubernetes
off
across
this
right.
D
B
B
A
Why
it
says
backlog
so
at
the
very
top
of
the
document
there's
no
to
do,
which
is
to
review
like
run
complaints
that
we've
had
in
a
number
of
times
in
a
number
of
places.
Is
there?
Are
these
really
mega
threads
on
certain
design
issues,
especially
the
older
ones
like
260
or
things
like
that
and
there's
TLDR
at
the
end
or
like
a
pointer
to
a
design
proposal
or
anything
and
now,
especially
since
we're
Auto
closing
issues,
or
at
least
Auto
pinging
them,
and
at
least
for
the
ones
that
are
still
open?
A
That's
an
opportunity
to
go.
Take
a
look
at
those
and
say:
oh
yeah.
This
is
actually
what
we
decided
here
and
go
document
that
these
were
just
some
things
that
I
had
started
accumulating
and
discussions,
but
in
a
number
of
other
PR
reviews.
Some
question
came
to
me
before
we
had
the
formal
state
of
architecture,
and
there
was
some
discussion
in
some
decision
and
I
would
say:
please
go
update
the
guy
conventions,
or
this
other
doc
and
nine
times
out
of
ten.
That
never
happened.
A
So
I
do
want
to
make
sure
we
start
capturing
these
things.
In
a
more
systematic
way
to
build
up
that
case
law
that
Joe
has
talked
about
before,
so
we
don't
have
to
same
rehash
the
same
issues
over
and
over
again,
but
anyway
Daniel.
If
you
want
to
sign
off
and
you're
happy
with
where
this
landed,
I
think
you
can
go
now.
A
Okay,
anything
else
on
this
issue
before
we
move
to
the
backlog
generally,
since
we
were
one
do:
okay,
so
yeah,
so
the
backlog
generally
I
mean
they're
a
bunch
of
things
in
there
at
the
top
is
one
thing
that
was
actually
just
discussed
and
decided
in
Sag
architecture,
which
is
the.
When
do
we
use
conditions
versus
fields
versus
whatever
else
things
so
I?
Actually
that's
another
case
where
I'd
said
Oh
someone
please
write
this
down,
I
waited
for
a
while
and
nobody
wrote
it
down.
A
So
I
posted
a
summary
to
the
bottom
of
that
issue,
but
we
need
to
get
it
into
the
API
conventions.
Doc
Paul
Mori
had
prior
to
the
full
discussion.
Paul
Murray
had
actually
opened
a
yard
to
try
to
clarify
it
in
the
dock
because
similar
discussions,
there
was
confusion
and
sig
Service
Catalog,
which
is
mostly
comprised
of
people
who
are
needed
kubernetes
and
they
couldn't
figure
out
heads
or
tails.
A
So
if
there
are
other
things
which
you
know
have
come
up
in
reviews
before
or
in
Prior
cig
architecture,
you
know
office
our
questions.
We
should
try
to
get
these
added
to
the
backlog.
Even
if
you
don't
remember
what
the
answer
was
or
whatever
just
add
them
to
the
backlog
and
we'll
try
to
make
sure
they
get
resolved.
I
will
be
asking
for
says.
A
Part
of
the
purpose
of
the
cig
is
to
democratize
this
information
and
get
it
into
more
people's
heads
and
get
more
people
involved
than
just
behind
I'm
gonna
ask
other
people
to
write
up
some
of
these
things
kind
of
stand
out
to
work
a
little
bit.
It's
not
super
urgent,
because
I'm
gonna
be
out
until
January
after
today.
Basically,
but
but
I
would
like
to
start
getting
sort
of
a
system
in
place
for
documenting
this
kind
of
case
law.
So.
G
A
Thinking
we
should
write
it
down
in
actual
thoughts
documentation
for
cookies,
which
currently
is
in
kind
of
crossing
between
the
development
directory
like
these
are
the
conventions
of
the
project
like
the
API
conventions,
to
keep
control
conventions
and
so
on
and
design
proposals
directory.
Where
we
have
things
like
R&D,
so
I
don't
know
if
we
want
to
reorganize
that
stuff
yet
again,
I
mean
that
minimum
devel
directory
is
so
big
and
unstructured.
A
We're
probably
going
to
need
to
add
structure
like
I'd
suggested,
creating
us
an
API
machinery,
some
part,
because
a
lot
of
this
stuff
really
Machinery
but
organizations
aside.
My
basical
is
to
get
this
stuff
in
documents
and
then
post
links
to
the
documents
and
issues
and
close
them.
Okay,
not
closed
already,
but
not
not
just
half
the
content.
Only
in
the
issues,
because
that's
totally
undiscoverable
you.
B
A
A
A
A
Yeah,
so
so
in
any
case
needs
improving
the
history
yeah
that
came
up
in
that
discussion
too,
so
yeah
so
I.
If
this
is
an
area
where
you're
interested
in
in
helping
you
don't
need
to
know
everything
about
communities
to
get
started,
I
think
this
is
a
good
way
to
learn
about
why
kubernetes
is
the
way
is
so
I
just
I'm
gonna
make
complete
from
there
more
people
to
volunteers
to
help
out
with
that,
and
that's
a
really
about
all
I
wanted
to
say
about
about
that
right
now.
A
A
I'm
gonna
try
to
close
on
that
with
Aran
early
in
the
year
early
next
year,
but
for
now
I
think
it
was.
There
was
a
fair
amount
of
consensus
on
this
during
community
thread.
I
just
want
to
raise
it
here,
since
we
said
we
would
discuss
like
here.
The
conclusion
was
well
is
we
don't
really
have
good
infrastructure
for
managing
lots
of
orgs
and
it's
just
one
thing:
the
integration
tests
it's
actually
not
doesn't
really
strictly
fall
under
the
incubator
processes
falls
into
the
grandfathered
class
because
it's
moving
existing
code.
A
F
A
A
H
Guess
the
question
was:
what
is
the?
How
do
we
down
scope
this?
So
that
way
it
doesn't
sprawl,
because
there
was
other
parts
of
the
conversation
that
said
like
well
what
about
other
testing
utilities?
What
about
the
ETA
framework?
What
about
all
the
other
utilities
that
could
be
leveraged
from
different
locations,
because
this
this
conversation
sprawl,
so
that
the
scoping
down
to
the
specifics
was
what
I
was
looking
for?
I
see.
A
There
was
a
util
repo
I,
don't
remember
if
that
actually
got
created
and
populated
to
make
generic
utilities
that
aren't
for
any
specific,
necessarily
available
to
multiple
repos,
and
then
there
was
a
common
repo
which
is
kubernetes
specific
libraries
that
aren't
just
being
used
by
tests
but
may
be
used
by
to
control
by
controllers
and
other
things,
and
that
repo
has
been
created
and
not
fully
populated,
so
that
this
would
I
guess
be
sort
of
another
example
of
that.
But
it's
specific
to
the
intervention
test.
All
right,
trust
me,
I,
just.
A
H
There's
this
weird
line
that
I'd
want
to
like
have
people
to
think
about
before
we
start
doing.
This
is
like
what's
the
delineation,
where
do
we
stop?
Because
otherwise
we
we
sprawl
and
recollect
in
different
locations,
which
is
kind
of
what's
been
happening
right
either?
We
had
many
repos
that
are
all
small
and
we
agree
to
this
or
we
have
you
know
sprawling
repos
that
you
know
collect
coalesce
ideas,
the
chunks
yeah.
A
I
mean
to
some
degree
it's
a
Conway's
law
kind
of
thing,
because
what
we
see
in
contribs,
you
know
when
something
big
that
gets
a
lot
of
activity
moves
in
like
ingress
or
something
like
that.
It
tends
to
you
Dass
everyone
else
and
people
stop
paying
attention
and
then
other
things
don't
get
maintained
or
curated.
A
So
it
kind
of
depends
on
the
overlap
of
of
set
of
people
who
are
maintaining
stuff
and
the
amount
of
cohesion
of
the
stuff
within
the
repo.
So
I
don't
know
if
there
is
a
hard
delineation,
but
I
agree.
It's
worth
trying
to
come
up
with
one
on
the
eat.
We
test
fronts
by
the
way:
I'm
a
pretty
big
fan
of
moving
eat.
We
toss
into
a
separate,
well
II,
to
be
test
framework
into
a
sucker
Reba,
not
all
the
tests,
but
the
test
framework.
B
Okay,
so
there's
the
question
around
conformance
test:
is
that,
like
conformance
test,
should
be
it's
dangerous
to
version
conformance
tests
with
the
product,
because
then
you
think
well:
I
applied
the
latest
conformance
test
to
the
latest
product
right
and
and
in
reality
those
things
should
have
have
some
degree
of
decoupling.
Tefillah
de
t.
A
Right
so
we
also
do
run
the
the
end-to-end
tests,
including
the
conformance
tests
cross
version
to
try
to
catch
those
problems
so
like
we
run
the
old
eat.
We
test
on
the
newer
release.
You
can
on
the
theory
that
they
should
still
pass
and
that
catches
things
like
people
use
events
to
detect
things
in
end-to-end
tests
and
those
events
aren't
guaranteed
to
be
stable,
with
which
actually
I
guess
should
be
an
issue
on
the
sega
architecture.
A
Backlog
is
conventions
and
deprecation
policy,
and
so
on
for
events
now
that
we
have
a
more
principled
event:
api
under
development
and
a
best
practices
guide
that
has
been
written
and
we're
about
to
overhaul.
All
the
events
is
kind
of
a
good
opportunity
to
reset
the
clock
and
become
more
formal
about
what
makes
sense
as
an
event
and
what
doesn't
make
sense
as
an
event
and
what
kinds
of
guarantees
we
have
around
that
so
we
may
want
a
set
of
I
could
imagine.
A
A
A
B
Going
to
try
and
make
some
progress
on
the
kept
process
at
some
point,
so
more
feedback.
There
would
be
useful
and
I
think
a
big
part
of
that's
gonna,
be
tooling
I.
Think
getting
the
tooling
out.
The
gate
will
really
make
I
think
we
can
talk
about
tooling,
building
the
tooling
and
actually
seeing
like
hey.
How
does
this
come
together?
I
think
might
be,
might
be
a
good
way
to
let
sort
of
like
people's
imaginations
on
where
we
can
take
this
so
yeah.
A
B
A
H
B
B
I,
so
here's
the
thing
is
that
I
don't
know
I'm
not
comfortable
with
where
the
instructions
are
around
cap,
I'm,
not
comfortable
with
where
the
template
is
I,
think
it
needs
to
be
hosted
in
a
place.
That's
not
buried
three
levels.
Deep
I
was
a
little
bit
surprised
when
Caleb
actually
brought
it
up
at
the
contributor
summit.
I
did
not
know
that
that
they
were
gonna,
start
pushing
that
so
I
feel
like
in
my
mind,
I
feel
like
we
need
to
like,
like
we
need
to
get
a
house
in
order.
B
G
Think
when
clarification
there
is
that
the
the
purpose
of
bringing
up
the
summit
was
not
to
say
this
is
gonna,
be
the
enforcement.
It
was
that
people
are
routinely
saying
they
have
no
idea
what
it
kept.
It
is
nor
what
it
means,
and
they
have
no
idea
what
it
will
actually
mean
in
terms
of
implementing
things.
So
it
was
just
like
and.
G
B
Like
we've
been
jumping
the
gun
here
without
actually
having
wide
by
it,
because,
like
quinton,
sent
out
email
to
everybody,
saying
here,
try
out
kappa
and
like
I'm
like,
we
didn't
talk
about
that
right
and
the
same
thing
like
like,
if
we
were
presented
to
the
large
group
like
Caleb,
did
I
think
there
has
to
be
a
certain
level
of
certainty
and
we
have
to
have
some
questions
answered.
We
didn't
have
those
Inc
questions
answer
if
we
didn't
actually
have
that
discussion
and
so
I
think
in
some
ways
it
created
more
stress
and
more
confusion.
B
D
If
you
don't
like
the
futures
repo,
then
we've
got
kept
and
to
me
those
aren't.
Those
aren't
like
one
to
one,
because
right
now
the
features
repo
is
like
a
place
you
can
track
and
it
is
pointing
out
to
design
Docs
and
kept
seems
more
like
a
replacement
for
the
design
proposal.
Mishmash
that
still
requires
tooling
and
things
around
it
and
so
I
think
that
confused
a
lot
of
people
as
well
and
I
think
in.
B
Caleb
again,
you
know
no
I
don't
want
to
beat
up
on
Caleb,
because
he's
not
here
but
again
and
again,
he's
tried
to
create
this
equivalency
between
caps
and
release,
notes
and
I.
Think
there's
been
a
lot
of
pushback
to
that
over
time
and
and
we've
drifted
pretty
far
from
like
the
the
thing
that
he
started.
A
Will
definitely
want
to
use
it
for
for
different
purposes
and
that's
part
of
the
problem,
and
we
should
at
some
point
talk
to
em
and
say
release
process
and
where
the
boundaries
of
this
process
versus
other
processes
should
be
and
how
they
could
we
wait
about
any
case.
So
what
is
the
proposal
for
what
to
do?
And
people
are
gonna
be
starting
to
do
stuff,
even
though
a
lot
of
people
will
be
out
for
the
holidays
so
that
we
can
kind
of
hit
the
ground
running
yeah.
D
Daniel
and
I
were
talking
kind
of
after
the
kept
thing
at
the
computer,
Summit
and
I
think
the
two
things:
if
we're
gonna
ask
people
to
switch
the
two
things
that
seem
really
important
are
making
it
not
accumulating
processes
like
not
not
saying
well,
here's
a
new
thing
and
it
doesn't
actually
really
replace
the
old
thing.
So
now
do
two
things
so.
D
B
B
B
B
B
C
Can
add
tooling
to
our
current
process,
so
I
don't
think
that's
an
argument
in
favor
of
this,
like
I,
think
sure
it'd
be
nice
for
everybody.
If
all
the
processes
had
this
format,
but
it's
not
nice
for
people
who
are
writing
processes
to
write
a
writing
proposals
to
follow
a
new
process.
So
you
have
to
give
these
people
a
carrot
if
you,
otherwise
people
are
going
to
hate.
The
new
process
like
like
yeah.
B
C
B
I
think
I
think
something
that
we
can
do
as
part
of
this
group
here
is
that
we
can
actually
have
a
queue
of
caps,
that
we
want
to
review
right
and
I.
Think
I
think
that's
something
that
we
have
to
manage
and
not
all
cap
necessarily
not
all
caps,
Nesta,
pastor,
Daniel,
it's
a
great
organize
how
we
look
at
stuff
here.
The.
A
C
A
I
Can
I
ask
a
quick
question
here
because
a
few
things
have
been
brought
up
and
I'm
not
sure
how
we
would
even
do
them
right.
So
we
say,
sig
architecture
is
gonna.
Go
look
at
your
cap.
Go
do
one.
Where
does
somebody
go
to
learn
like
what
does
it
replace?
What
should
I
be
doing?
What
you
know
where
does
cigar
could
actually
say
we'll
review
this
like
where's,
that
landing
page
that
says:
here's
how
we're
consolidating
processes
on
this
it's
in
a
an
alpha
state.
I
This
is
what
you
get
for
it,
so
they
can
get
an
overview
of
why
they
should
do
it,
what
it's
replacing
and
what
they
get
out
of
it.
And
then
we
talk
about
things
you
know.
Joe
is
just
talking
about
tools
so
great,
so
we're
gonna
create
some
tools.
Let
you
search
caps
and
do
things.
Where
does
somebody
start
developing
code?
For
that
sure
I'll
go,
do
it
on
my
own
github
repo,
but
then
it's
got
to
come
in
and
we've
been
talking
about
not
wanting
to
do
that
anymore,
to
bring
it
in.
I
So
where
can
somebody
go
to
start
building
these
tools
in
order
to
you
know,
even
if
they
wanted
to
so
I
kind
of
see
two
practical
like
gathering
this
information?
We
talked
about
needing
and
presenting
caps
in
a
nice
way
and
then
building
tooling
to
kind
of
support
it.
Where
does
it
go?
There's
kind
of
the
practical
things
where
do
we
do
this
and
who's
gonna
sign
up
for
what
yeah
I
think
there's.
B
So
I
think
that
point
is
is
is
very
well
taken
and
I
think
that's
part
of
getting
to
the
point
where
I'm
gonna
feel
more
comfortable
and
inviting
other
people
to
get
involved
in
this
process.
We
don't
have
that
clarity
there
in
terms
of
how
and
where
we
build
the
tooling
I,
don't
know
I
mean
like
to
some
degree.
It's
like
you
know.
We
have
a
repo
for
the
website
right.
We
can
have
a
repo
for
the
Cape's
that
can
have
code
we
can
have
process
and
and
a
way
to
host
that
I.
B
You
know
III
would
be
in
favor
at
some
point
and
that's
something
that
we
should
talk
about.
I,
don't
necessarily
want
to
dig
into
it
now,
but
should
we
have
a
separate
kubernetes,
slash,
keps
repo
that
actually
just
hosts
that
and
move
it
out
of
the
rest
of
the
community
repo
which
really
is
sort
of
the
touch
point
for
SIG's
to
sort
of
a
sig
index
to
some
degree?
I
think
that's
something
that
we
should
look
at
also.
G
So
there's
two
things
here:
one
is
it.
This
is
calling
out
that
if
we're
gonna
make
process
changes
across
the
project
or
some
sig
is
driving
a
process
change,
we've
got
to
get
a
lot
better
at
how
to
do
this
because
one
yeah
it's
impossible
to
get
consensus.
And
then,
when
you,
when
you
think
you
have
it,
you
realize
you
don't
have
it
and
then
so.
G
It
creates
this
churn,
which
is
really
painful,
so
I'm,
hoping
that
maybe
we
retro
how
this
went
and
maybe
the
ways
that
we
can
improve
it
in
the
future,
because
it
feels
very
much
like
a
cart,
rolling
down
a
hill
out
of
control
and
and
that
shouldn't
be
how
it
should
because
this
I
mean
it's
all.
These
are
all
great
things
and
they're
actually
going
to
be
essential
to
the
survival
of
this
project
long
term,
but
damn
this
is
hard,
but.
B
And
I
think
we're
all
doing
it.
Part-Time
right,
I
think
that's
part
of
the
problem
here
too,
and
so
it's
these
fits
and
starts.
There's
not
a
lot
of
great
communication.
Yeah,
like
I
mean
obviously
I
was
really
taken
aback
when
this
was
when
this
was
brought
up
at
the
contributor
summit,
I
was
I'm.
G
B
A
G
And
the
the
product
angle,
though,
is
that
I
mean
this
is
the
thing
okay,
regardless,
if
it's
a
proposal
in
the
current
cargo
cult
or
if
it's
a
cap
or
whatever
the
implementation
process
around
how
we
track
that
work
and
tie
it
back
to
the
work.
That's
delivered
is
horrible
and
I'm,
saying
that,
from
my
experience
now
with
multiple
releases
and
everybody,
who's
worked
on
a
release
says:
oh,
my
god,
trying
to
assemble
all
this
into
some
conceivable
thing
is
really
hard
and
it's
a
lot
of
human
effort.
G
G
So
if
it's
a
Kepler
proposal,
the
the
reason
that
we
that
there
was
a
decision
to
at
least
cursorily
talk
about
Kemp,
which
turned
into
a
big
conflagration
of
the
summit,
was
it
people
need
to
know
that
that
part
eventually
is
going
to
change
as
well,
but
they're,
probably
going
to
see
the
implementation
details
change
faster,
so
that
was
I.
Take
personal
responsibility
for
the
shitty
role
out
there
and
I'm
I'm.
Sorry,
there's
like.
B
As
as
we
as
we
make
top-down
changes
right,
which
is
like
as
we
get
more
governance
as
we
have
the
steering
committee
as
we
actually
give
SIG's
more
power
to
actually
make
decisions,
we're
going
to
have
places
where
we
have
some
top-down
changes
and
any
time
when
you're
doing
that,
you
have
to
communicate
it
well,
and
you
have
to
have
clarity,
and
you
can't
just
sort
of
you
know
dribble
it
out
with
sort
of
a
ganking
weasel
words
and
that
type
of
stuff.
So
we
gotta
get
on
the
same
page.
I
So
with
all
this
in
mind,
though,
so
so
Joe
brought
up
some
some
totally
actionable
things
like.
Can
we
figure
out
where
we
want
to
stick
caps
and
then
go
create
a
nice
index
or
a
nice
readme
and
with
the
template
over
there
and
move
the
caps
we
have
there
and
get
it
at
least
that
place
ready
to
go
and
know
what
that
place
is
because
that's
something
we
can
do
between
now
and
when
we
meet
again
a
couple
I'll
sign
up
to
start
with
yokte.
B
H
You'd
have
to
do
a
piecemeal
so
like
if
you're
gonna
vet,
your
tooling
you're
gonna
need
a
history
of
caps
to
tie
together.
So
you
might
want
to
pick
a
specific
use
case
or
user
story
where
features
kind
of
chain
down
from
one
minute
feature
which
happens
all
over
that
repo
but
you'd
have
to
beautiful
mine
those
pieces
together
as
as
Jason
mentioned
earlier,
and
then
use
that
as
an
example
for
the
tooling
and
then
you
can
walk
backwards.
H
B
I
mean
so
like
I
I
want
to
say,
I'm
gonna
sign
up
to
do
this
like,
but
I'm
careful
of
I
know
how
hard
it
is
to
sign
up,
but
like
would
it
be
worthwhile
to
say,
let's
pick
say
five
of
those
proposals
that
we
think
are
probably
the
most
cornerstone
and
the
most
important
and
let's
use
those
as
our
guinea
pigs
to
essentially
move
those
into
the
kept
repo
and
sort
of
really
retroactively
week.
Epified
them
Joe.
B
A
A
I
I
That
one
of
the
things
about
creating
a
cap
repo
and
at
least
moving
kept
one
and
the
template
and
putting
a
readme
in
there
is.
You
can
also
create
a
doc
structure
e
and
then
tie
that
in
to
get
hub
pages,
and
we
can
point
a
k8s
thing
at
it
and
then
every
time
there's
a
change.
We
can
do
certain
things
to
rebuild
this.
There
are
options
there
for
us
to
start
building
a
very
basic
site
right
in
that
repo
to
start
doing
things.
I
It
won't
be
fancy
but
it'll
be
a
start
and
it'll
have
one
home
place,
and
if
we
just
do
that
as
a
first
step
and
then
the
second
step,
you
know,
besides
the
couple
the
template
and
kept
one
is,
if
you
want
to
pick
other
design
proposals
and
turn
them
into
caps
and
bring
them
in.
You
now
have
a
template
in
a
place
to
do
that,
and
it's
a
top-level
thing
that
that's
the
interesting
thing
to
me,
although
we
can
make
other
things
work
to
just.
B
A
Not
saying
they're
discoverable
today
I'm
saying
they
could
be
made,
discoverable
I'd,
not
sure
I
want
to
move
all
the
existing
proposals
again,
and
we
also
there's
currently
content.
That's
in
the
developer
directory,
which
is
relevant,
they're,
not
proposals
specifically,
but
it's
about
how
to
develop
kubernetes.
So
I
don't
want
to
split
the
move.
The
proposals
to
be
separate
from
the
other
developer,
documentation
and
I
agree
that
there's
is
a
discoverability
issue
and
that
we
could
make
nicer
documentation
and
I
would
love
it.
A
If
people
worked
on
that,
but
I
think
that
applies
to
how
do
you
contribute
to
communities?
How
do
you
do
development?
How
do
you
understand
the
key
book
code,
like
all
those
kinds
of
things
that
it
applies
equally
well
or
even
to
how?
How
is
the
project
organized
people
organized
around
SIG's
and
things
like
that?
Okay,.
I
Then
can
we,
alternatively,
maybe
at
the
top
of
the
community
repo,
get
a
caps
directory
and
we
move
the
temple
kept
one
and
put
a
nice
readme
in
there
that
fills
this
stuff
out
with
a
landing
page.
So
we
have
a
place
to
point
people
to
that's.
That's
very
I
mean
it
would
keep
it
in
the
community
repo
we're
not
talking
about
moving
design
proposals.
I
Yet
that
would
be
a
different
step
if
something
made
sense
to
move,
and
you
just
bring
kept
one
and
the
template
and
put
a
nice
readme
in
there,
and
then
we
can
look
at
what
to
bring
in
process
wise
from
that,
whether
it's
a
brand
new
cap
that
somebody
submits
or
if
it's
a
design
proposal
that
somebody
wants
to
do,
which
would
be
a
new
cap
based
on
a
design
proposal.
That
would
be
like
a
second
step.
Would
that
be
okay?
That
sounds
great
okay
and.
D
I,
only
the
only
thing
that
it
affects
for
any
other
part
of
the
process
like
issues
could
have
issues
whatever,
instead
of
linking
to
a
proposal,
will
now
link
to
a
cap,
and
so
like
it
decouples
all
of
our
existing
integrations
with
everything
else.
It's
just
what?
What
does?
What
document?
Do
you
reference
and
then,
as
we
figure
out
how
to
tie
more
things
to
caps
like
automatically
via
tooling
or
whatever?
We
can
kind
of
supplant
other
parts
of
the
process
as
well,
but
it.
B
G
B
B
B
The
maybe
call
out
sort
of
the
most
common
things
now.
Some
of
this
actually
starts
overlap
with
the
country
back
stuff
and
then
contributor
guide
stuff
that
that
I
know
that
George
and
company
have
been
looking
at
and
so
I'll.
You
know
we
need
to
close
the
loop
with
him
on
that
rock
drop
contributes
and
let
me
know
yeah
and
then
and
then
the
other
thing
is
that
we
can
start
building
tooling,
to
have
a
parallel
site
to
to
Kate's.
Do
that
was
really
community
facing
where
we
have
an
information
architecture
on
that
yeah.