►
From YouTube: SIG Architecture Office Hours 20171116
Description
A
C
One
of
the
things
that
we
decided
last
week
was
that
if
we
don't
have
any
items
for
office
hours,
we'll
turn
it
into
a
working
session
around
a
specific
topic.
Now
we
can
go
ahead
and
do
that
right
now.
I
do
think
that
there
is
some
urgency
around
some
of
the
issues
around
both
API
review
and
sort
of.
How
are
we
gonna,
you
know,
is
how
does
the
architecture
relate
to
the
API
review?
C
Processes
is
one
thing
and
then
specifically
around
the
idea
of
like
what
is
the
form
and
format
of
web
hooks
and
how
does
that
apply
to
both
the
admission
controllers
and
these
new,
this
new
G
RPC
interface,
coming
from
the
secret
encryption
api's
that
are
being
generated,
which
again
is
kind
of
webhook
ii
type
of
thing.
So
we're
introducing
you
know
going
into
into
1/9
we're
introducing
two
new
forms
of
call
out
from
the
wait.
B
C
I
think
part
of
that
is,
and
you
know,
is
I'm
trying
to
find
a
thread
that
I
have
here,
but
anyways
I
think
you
know.
One
part
of
this
is:
is
that
I
don't
see
and
maybe
I'm
just
not
tied
into
the
right
loops,
but
I,
don't
see
a
record
of
what
are
the
API
decisions
that
we're
taking
up?
Where
were
they
discussed?
How
are
we
applying
this
consistently?
C
It
seems
to
be
what
a
lot
of
these
discussions
are
happening
off
list
outside
of
a
sig
outside
of
of
something
that's
actually
trap
or
if
they're
happening
in
a
sig.
It's
very
much
a
parachute
in
type
of
thing,
and
it's
very
difficult
to
actually
get
the
scope
of.
What's
going
on
with
respect
to
our
API.
Well,.
B
I
think
a
lot
of
it
is
just
gonna
get
out
in
the
past,
so
I
think
there
does
need
to
be
a
conservative
effort
to
document
generalizable
decisions
in
the
API
conventions.
I've
asked
that
to
be
done
in
the
past
and
it
usually
hasn't
happened.
So
we
probably
need
to
get
closure
of
issues
on
making
sure
that
those
types
of
things
actually
get
documented
so
I
have
that.
Let's
not
discuss
it
in
depth
right
now,
but
I
did
put
the
API
reviews
on
the
agenda.
B
So
just
hopefully
we
can
quickly
knock
something
out
so
how
to
engage
with
sig
architecture.
I
think
there
are
issues
that
people
want
to
ask
us
about,
but
they
just
use
github
notifications
or
slack
and
I-
don't
see
them
for
about
a
week
if
or
something's
in
case
of
the
month,
when
I
clean
out
my
email
so
well,
good
I
mean.
B
C
B
B
I
agree,
I,
think:
that's
that's
why
this
stuff
needs
to
get
documented.
We
need
to
make
more
progress
on
documenting
the
conventions.
You
call
that
case
law
I
think
until
we
in
favor
of
that,
but
not
only
did
I
not
notice
it,
but
apparently
nobody
else
responded
either
so
and
I'm,
not
the
only
one
in
these
lists
or
imagined,
or
things
like
that.
So
slowly,
things
are
not
getting
sufficient
visibility.
D
Gonna
take
an
action
item
to
send
an
email
to
it
could
be
nice
to
have
like
introduced
she's,
reminding
everybody
that
and
also
CC
leads
to
say.
You
know,
here's
the
caricature,
here's
what
we
do
like
I
know.
We
presented
the
community
meeting,
but
you
might
have
missed
it
and
just
get
people
on
line
with
it
and
I
think
another.
Another
aspect
is
that
we
don't
have
a
decision-making
hierarchy.
We
don't
know
who
our
tech
leads
are
I
mean
we
kind
of
do
it
Brian.
D
B
B
So
we
have
a,
we
do,
have
a
documented,
concrete
list
of
API
approvers
and
it
includes
five
people
today
which
have
had
a
lot
amount
of
involvement
with
a
lot
of
today's
api's
I.
Think
much
like
we've
made
efforts
to
expand
the
reviewer
and
approver
pools
for
other
parts
of
the
projects.
We
should
try
to
do
so
here
as
well,
but
that's
going
to
require
you
know
the
documentation
I
mentioned
before,
as
well
as
mentoring,
and
things
like
that.
So
I
think
we
should
follow
that
we
do
have
more
or
less
the
reviewer
approver
pattern.
B
We
also
have
some
amount
of
sink
coverage
because
Clayton,
Tim,
Eric,
Jordan
and
I
have
been
involved
in
many
of
the
SIG's
and
we
try
to
let
the
Stig's
somebody
from
the
state
individuals
things
do
the
first
line
design
in
review
before
final
approval,
but
I
do
think
and
we're
jumping
kind
of
ahead
into
the
API
approval
process.
Part
of
that
process
will
be
to
delegate
and
assign
approvers
and
reviewers
for
specific
API
issues.
We
can
also
we've
also
discussed
doing
some
design
reviews
I,
don't
think
we
can
do
it
for
every
single
field.
B
Change,
for
example,
but
we
may
want
to
do
it,
certainly
for
totally
new
API
mechanisms
or
cutting
new
ground
on
the
API
conventions
or
escalations
where
people
cannot
agree
and
things
of
that
nature.
We
might
also
want
to
have
a
formal,
formal
set
of
criteria
for
going
to
beta
and
GA
things
like
that.
C
So
I
do
want
to
bring
up,
we
mean
so
Brian.
The
idea
of
concentrating
on
the
approvers
and
the
approval
processes
is
important.
I
think
it's
also
really
important
that
we
actually
concentrate
on
the
communication
process
around
this
right.
I.
Think
ton
of
folks
who,
like
like
being
able
to
watch
where
the
API
changes,
are
incredibly
highly
leveraged
in
terms
of
understanding
where
the
priorities
and
where
the
changes
are
in
the
project
in
general.
C
Don't
think
that
the
approval
process
is
as
much
of
the
problem
you
know
and
there's
probably
stuff
to
be
improved
there
as
much
as
the
communication
process
around
this.
We
really
need
to
be
able
to
to
have
people
sort
of
mind-meld
and
understand
where
things
are
going
and
in
how
we're
applying
these
these
these
rules
and
these
conventions
I
don't
think
that
there's
a
way
for
people
who
are
not
sort
of
monitoring
every
cig.
You
know
that,
so
that's
the.
E
So
take
a
timeslot
and
say
we
are
going
to
as
part
of
our
release
process
do
a
review
of
all
the
api's
that
got
added
in
one
9ne
api
review
after
this
point
must
go
through
this
process
and
start
putting.
Those
part
of
the
release
process
is
very
reasonable
and
a
concrete
thing
we
can
practice
like
starting
next
week
or
week
after.
B
F
A
question
about
these
API
reviews,
so
is
this:
do
we
think
less
free
to
do
in
architecture?
I
mean
this
seems
like
a
specific
in
that
area
that
it's
conceivable,
that
we
have
a
cig,
API
and
these
pies
are
like
permanently
immersed
in
API
design
and
consistency,
and
all
of
these
things
right
so
there's
so
much
overlap.
There
I
mean
yeah.
E
B
Yeah,
so
I
really
want
an
official
notion
of
sub
projects
and
mini
SIG's
have
multiple
sub
projects
that
don't
all
have
the
same
participants
with
the
same
leads
SiC
Network,
for
example,
has
Q
proxy
and
ingress,
and
those
have
largely
disjoint
sets
of
people
working
on
them.
That's
at
various
times,
maybe
now
they
don't,
but
in
the
past
they
had.
The
gaps
obviously
has
home
and
workload
api's,
which
have
seemed
more.
B
No-Stick
architecture
should
not
review
every
single
field,
take
change
to
every
single
API,
but
that
should
definitely
not
be
the
case.
We
need
to
put
enough
standards
and
linters
and
whatever
else
in
place
that
doesn't
matter
that
the
last
that
happened,
I've
been
there
before
and
yeah
it
just
totally
does
not
scale.
It
can
easily
consume
all
the
time.
Yeah.
E
I
would
break
it
into
categories
most
API
changes,
there's
a
very
loose
touch
point
having
the
conventions
be
obvious,
and
people
knowing
who
to
ask
to
go
get
conventions,
like
is
a
sync
communication
challenge
and
then
the
hard
stuff
is
the
kind
of
thing
like
Joe
brought
up
it's
like
do
we
want
to
add
to
our
PC
to
the
API
server
like
it's
like
that's
the
thing,
that's
definitely
sig
architecture,
overlapping
with
UK
review,
and
that
takes
a
lot
of
time.
Those
are
the
hard
PRS
and
I.
C
D
E
No
there's
this
is
not
the
this
is
the
pass
to
catch
the
things
that
happen.
This
is
the
focus
you
which
is
all
the
API
changes
that
happen
in
a
release
need
a
formal
like
we
should
go
like
we're
doing.
We
do
we
kind
of
do
it
more
release,
notes
but
like
as
the
set
of
API
changes
at
code
freeze
is
the
last
chance
to
correct
an
API
change
going
out.
It's
a
double
check,
not
the
initial
got.
B
Yeah,
this
is
another
area
where
I
think
teacher
branches
with
help,
especially
for
major
API
work.
It's
what's
happened
with,
for
example,
with
some
of
the
workload
API
changes
the
process
to
do
it.
That
feature
branches
is
kind
of
painful.
You
end
up
in
this
situation
where
stuff
can
be
half
done
or
half-baked,
or
what,
if
you
do,
decide
that
our
changes
are
made
they're
very
hard
to
revert
after
after
multiple
TRS,
so
for
some
of
these
major
new
API
is
I
think
doing
work
in
a
future
branch
which
is
kind
of
beginning
review.
Now.
C
E
Are
always
like
be
it's
the
human
part
of
it,
which
is
like,
like
I,
would
kind
of
say
it
as
the
point
of
it
is
just
to
stop
the
thing
that
we
can
never
undo
not
be
it's
the
it's
that?
Yes,
we're,
really
sorry
that
we
didn't
catch
this
earlier.
Yes,
the
process
broke
down.
Yes,
you
did
everything
in
good
faith,
but
if
you
do
this,
we
will
live
with
this
forever,
and
this
is
our
last
chance
to
catch
it.
E
D
E
E
B
A
C
E
C
E
Example
that
I
think
where
I
would
talk
about
this
is
the
issue
you
raised
about
adding
new
Z
1
beta
2
on
deployments
right
near
the
end
and
leaving
you
out,
be
you
and
beta
1
and
then
changing
the
defaults.
Like
that's
something
that
code
freeze,
we
don't
want
to
be
doing
it
at
release.
Freeze
we
want
to
it
at
code
freeze
and
with
this
yeah.
B
So
there
was
a
question
also
I
added
it
to
the
backlog
earlier
about
what
do
we
do
with
the
architectural
roadmap?
So
this
is
where
I
think
the
road
map
could
really
really
help
because,
for
example,
for
the
workload
API
is
we
actually
had
a
road
map
like
in
this
release.
We
want
to
go
to
beta
in
this
release.
We
want
to
go
to
be
one
if
we
have
that
sketched
out
for
like
the
next
several
releases,
we
know
what
things
look
or
on
the
horizon.
We
can
actually
schedule
these
reviews
far
enough
in
advance.
B
C
Any
big
part
of
this,
though,
is
that
and
I
don't
know
how
to
deal
with
this
because,
like
it
goes
beyond
the
API
changes,
but
like
taking,
that
example
of
actually
moving
deployment
out
of
extensions
into
apps
and
going
from
B
1
beta
1
to
B
1,
beta,
2
and
stuff,
like
that,
not
necessarily
the
wrong
thing
to
do.
I,
don't
think.
We've
got
all
our
ducks
in
order
in
terms
of
communicating
this
to
people
it
was,
it
was
the.
E
E
C
Gonna
make
mistakes
so
there's
no
doubt
about
it.
I
think
it's
just
a
matter
of
communication,
but
I
think
there's
other
things
where
it's
like
a
lot
of
times.
I'm
like
I,
find
out
about
stuff
when
I'm
reading
the
release
notes
for
a
release.
Right
now,
like
you
know,
I'm,
not
Brian,
I,
don't
actually
like
memorize
all
the
issue
numbers
because
I,
don't
think
the
dude
sleeps
right
dude,
but,
like
I,
think
a
lot
of
other
people
are
like
you
know,
it's
I
think
pretty
much.
Everybody
finds
stuff
out
during
the
release.
E
C
E
E
We
need
to
work
with
cig
testing,
its
state
context
to
automate
at
least
the
pre
gathering
of
important
designs,
changes
and
so
forth,
and
then
look
at
how
evaluate
how
that's
working
and
then
look
to
revise
that
in
future
releases
to
get
better
at,
we
should
be
able
to
realistically
generate
an
80%
correct
list
of
important
changes
without
humans
being
involved.
Yeah.
E
Tags
too
many
today
and
like
nobody's
looking
at
that,
but
like
if
it
was
cigar,
sale
I,
get
to
begin
at
the
middle
of
a
release
in
cig
architecture.
We
do
a
quick
pass
on
our
auto-generated
list
and
be
like.
Has
everybody
talked
through
all
of
these
or
you
know
like?
Have
we
done
a
beer
like
maybe
like
we
get
a
little
bit
more
hormones
to
talk
about
calling
and
surfacing
this
up
and
disseminating
the
information,
because
ok.
B
E
E
C
G
A
couple
concrete
and
was
that
Clayton
I
would
call
out
some
of
the
lenders
that
we
have
and
the
sed
storage
tests
as
examples
of
the
types
of
things
we
want
to
see
associated
with
in
a
new
API
change
like
fixtures
that
we
can
keep
of
every
version
that
say
this
JSON
and
this
yeah
Milan.
This
proto
was
valid
at
release
X,
and
it
should
always
be
valid
going
forward
that
we
can
just
add
to
that
corpus.
Yeah.
H
We're
working
on
two
things
in
that
space:
one
of
our
team
members
is
working
on
an
API
linter
looking
for
PR
I,
don't
know
any
day
now
and
something
else
Mehdi
was
has
been
talking
about.
I,
don't
know
where
it
is,
but
he's
been
looking
at
something
that
makes
sure
that
the
open,
API
spec
remains
backwards,
compatible
between
visions,
yes
to.
E
E
H
G
H
B
B
H
E
Was
gonna
raise
this
as
like
a
general
architectural
principle
that
I've
kind
of
been
talking
to
a
few
people
about,
but
like
we're
at
the
point
in
Cube,
where
sometimes
worse
is
better,
which
is
we
can
we
can
like,
we
can
fix
things
by
creating
new
things,
but
it
doesn't
actually
make
the
project
better.
Like
changing
the
patterns.
E
Changing
the
ideas
like
we
talked
a
little
bit
about
this
and
then
v1
v2
ap
is
like
there's
a
cost
associated
with
every
change
we
do
and
I
I
want
us
to
at
least
consider
that
during
high-level
design
and
architecture,
which
is
sometimes
it's
okay
to
just
keep
doing
the
thing
we're
doing
and
look
at
involved
in,
you
think
it
doesn't
apply.
My.
B
My
number
one
most
important
principle
is:
consistency
is
more
important
than
correctness.
So,
unless
we,
it
is
a
important
thing
to
change
and
there's
concrete
value
and
important
value
that
comes
out
of
it
and
we're
gonna
sign
up
to
eventually
fix
old
things.
Then,
in
general,
consistency
is
easier
for
clients,
developers
and
users
to
deal
with
yeah.
H
E
The
initial
review
we
actually
said
like
in
the
initial
review.
There
was
a
design
point
put
on
one
of
the
fields
about
as
long
as
we
suspect
that
it
might
not
be
that
the
client
is
allowed
to
not
fill
this
out
in
the
response
for
fairness,
performance
related
reasons,
and
we
think
we
can
make
that
be
same
for
the
implementer
like
admissions
kind
of
a
special
case,
because
there's
one
consumer
of
the
admission
chain-
and
it
can
be
a
little
bit
more
stronger
versus,
like
the
other
api's-
are
consumed
by
every
client
in
the
world.
E
C
One
of
the
things
that
I
think
would
be
worthwhile
as
we
talk
about
sort
of
what
our
conventions
around
web
hooks
and
this
in
some
ways
goes
beyond
this
is
how
do
you
register
web
hooks?
What
is
the
twisty
maze
of
TLS
certificates?
Can
we
rationalize
that
stuff
right
because,
as
we
add
more
and
more
web
hooks
getting
some
consistency,
there
might
be
helpful
also,
and
so
that
looks
beyond
the
API
to
sort
of
what
is
the
experience
for
as
people
actually
go
ahead
and
use
these
things
so.
A
So
we
have
two
different
use
cases
for
hooks
today.
Right
there
are
single
hooks
called
from
single
places
right.
Those
are
things
like
authentication,
authorization
and
image
review
web
hooks
today
right
and
then
we
have
a
new
kind
of
hook
for
admission,
and
the
admission
hook
is
one
where
the
configuration
about
where
to
connect
is
shared
amongst
all
API
servers,
instead
of
being
targeted
of
a
specific
one
in
all
those
cases.
A
H
C
G
C
D
G
Think
all
the
ones
I'm
aware
of
taken
cube,
config
for
connection
and
again
queue
config
as
a
wrapper
for
connection
data
was
a
structure
that
fit
the
purpose,
but
arguably
it
could
be
tweaked
I.
Think
more
interesting
is
the
considerations
around
the
topology
of
the
hook.
Is
that
a
one
to
one?
Is
it
a
many
to
one
type
of
thing?
Do
we
need
to
be
able
to
support
targeting
a
URL
or
a
service
that
type
of
thing
that
would
affect
the
way
you
would
spec
out
that.
G
And
as
we
do,
that
I
think
the
types
of
information
that
we
were
talking
about
for
the
authorization
hook
in
particular
seem
very
applicable
to
general
hooks
like
what
what
are
the
versions
in
and
out.
What's
the
connection
information?
Are
you
targeting
URL
or
service?
Those
don't
seem
specific
to
one
particular
hook.
That's
a
kind
of
general
set
of
things
you
need
to
answer.
C
Yeah
I
and
that's
that's
essentially
I-
don't
necessarily
need
to
come
to
a
decision
right
here.
I
think
it's
just
a
matter
of
life
when
we
think
about
documenting
API
conventions,
and
we
got
to
look
beyond
just
sort
of
like
what
is
this
stuff
on
the
wire.
What
is
the
experience
probably
configure
in
this?
None
you're.
C
A
G
C
Think
this
is
a
pattern
itself.
Also.
Is
that,
like
there's
these
past
discussions,
those
aren't
very
accessible
to
a
lot,
a
lot
of
people
who
haven't
sort
of
lived
through
it
and
have
those
battle
scars
and
at
some
point
those
past
discussions
need
to
be
boiled
down
to
something
that's
more
accessible
to
a
wider
audience.
Yeah.
B
B
C
C
E
New
type
of
thing
from
the
agency,
so
I
would
say
one
thing
which
I
think
is
useful
is
at
some
point
like
I,
don't
think
as
we
continue
to
evolve
cube
I
could
imagine
at
some
point
us
defining
G
RPC
equivalents
for
many
of
the
hook
points
we
have.
If
G
RPC
continues
to
be
successful
and
we
would
adapt
and
say,
like
you
know,
I,
don't
see
any
reason
why
at
some
point
the
webhook
admission
channel
could
do
G
RPC
calls
in
addition
to
web
book
based
on
settings.
B
And
so
I
just
want
to
throw
out
there
that
the
GRDC
team
sits
on
our
building
now.
So
if
there
are
specific
asks
of
them
and
we
report
to
the
same
VP,
no,
they
are
specific
ass.
Then
please
send
them
our
way.
I'm
pushing
right
now
to
figure
out
whether
some
of
our
API
patterns
are
actually
portable.
E
And
like
Daniel
did
the
doc
I'll
say
everything
that
I
know
Daniel
wants
to
says:
Daniel
did
the
doc
about
the
upfront
questions
on
G
RPC
there's,
certainly
an
option
that
we
could
generate
like
we
do.
Otherwise,
a
G
RPC
schema
for
our
API
from
our
core
API
Docs.
It
would
not
be
a
RPC
like,
but
it
might
be
good
enough
to
work.
E
So
there's
I,
guess
like
one
of
the
things
I
would
say
is
that
the
physical
upfront
cost
of
every
new
API
for
declarative
config
is
a
very
key
thing
like
our
user,
facing
API
is
somewhat
distinct
from
our
downward
api's
see
Ric
and
I
are
clearly
downward.
Api's
kms
is
clearly
a
downward
API.
Webhook
sits
on
the
edge
I
have
noticed,
as
we've
talked
about
webhook
extensions,
so
there's
a
there's,
an
ongoing
discussion
in
capi
machinery
about
and
daniel.
This
is
another
thing
that
Daniel
cares
about.
E
I'm
just
gonna
read
Daniels,
mind
and
pull
it
out,
which
was
David
and
I
and
Mike
have
been
going
and
prototyping
like
webhook
authorizers,
webhook
extensions.
We
want
to
reuse
our
existing
machinery
to
do
that.
The
problem
is,
is
then
those
are
now
exposed
in
the
upward
discovery.
Api
like
we
treat
them
like
API
objects.
We
get
a
whole
bunch
of
things
for
free.
We
have
our
framework
in
place.
E
We
have
discovery,
but
now
they
start
showing
up
to
end-users
and
they're,
not
really
intended
for
consumers
of
the
system
there
downward,
not
upward,
and
so
in
some
cases
it
might
have
actually
been
easier
to
do.
G,
RPC,
webhook,
gr,
BC
or
GRB
C
authorization,
webhook,
G,
RPC,
admission,
webhook,
G
RPC,
whatever,
because
at
least
it
offers
a
set
of
tools.
It's
a
little
bit
less
friendly
to
clients,
and
that's
kind
of
the
distinction
between
downward
and
upward
is,
if
you're
in
doubt,
for
API
some.
G
We-
and
we
do
that
today,
so
the
same
API.
Is
that,
like
a
subject
that
cause
review,
the
API
server
can
answer
that
and
that's
how
the
cubelet
delegates
authorization
decisions
to
the
API
server
today,
but
then
that
can
also
be
outward
facing
to
some
hook.
That's
served
based
on
whatever
that
thing
wants
to
serve.
That.
E
C
Think,
though,
what
I
mean
you
talk
about
reusing
the
API
machinery
for
doing
some
of
this
stuff,
I
think
there's
other
machinery
that
we
need
to
take
into
consideration.
This
is
things
like
our
sort
of
proto
SDK,
where
the
SDK
is
client
go.
How
does
that
relate
to
this?
What
is
our
documentation
around
this?
C
You
know
and
it's
a
different
audience
right.
I
mean
it's
like
sometimes
you'll
head,
the
SD
like
this
is
my
Microsoft,
showing
your
SDK
and
their
k4,
and
then
they
have
a
file
system,
SDK
and
there's
different
SDKs
for
different
audiences
and
developers
yeah
conventions,
but
we
need
to
think
in
terms
of
sort
of
like
hey.
This
API
is
in
this
group,
so
it's
actually
going
to
be
part
of
this
sort
of
experience
and
we
need
to
think
through
the
documentation
and
the
experience
of
that
also.
We
can't
ignore
that
and.
C
D
E
Seen
I've
watched
the
cockroach
DB
guys
sort
of
struggle
like
G
RPC,
isn't
perfect
yet
and
I
want
to
see
Jerry
PC
get
better.
Ideally
at
some
point
we
need
to
stop
and
Daniel
and
I
talked
about
this
he'd
love
to
talk
about.
This
is
like
at
some
point.
We
are
building
a
microservices
framework
for
our
upward-facing
things
and
we
need
to
be
cautious
about
how
far
we
go
down
that
because
there
is
a
level
of
the
glue.
E
But
we
talked
about
this
in
a
previous
call
with
off
and
services
and
certificates
and
the
API
server
talking
to
backends.
We
are
talking
about
building
out
things
that
are
basically
micro
services
frameworks
for
our
specific
cases,
and
there
are
other
projects
and
tools
out
there
that
are
trying
to
solve
this
problem
generally
for
kubernetes.
We
have
yet
had
to
do
hard
defeating
there,
but
likes
busy
and
Misty.
Oh,
are
both
examples
up
we're
reinventing
specific
solutions
to
generic
solutions.
Those
would
like
to
provide.
How
do
we
mentally
organize
the
invest
that
we
make
in?
E
You
know
doing
this
API
extension
to
backends
logic
versus
the
saying
you
know
what
at
some
point,
you
should
just
install
sto
and
that's
your
problem
and
we'll
have
a
recommended
path
to
do
that.
If
you
want
to
do
identity,
SH,
installs,
fire
or
whatever,
like
those
kinds
of
things,
we're
not
there
yet,
but
we're
starting
well.
C
E
Like
and
actually
that
that
intervention,
Joe
I
think
productively
has
led
to
container
identity.
Talking
about
this,
as
the
things
that
Mike
is
kind
of
looking
at
now
is
a
very
concrete
way
of
taking
something
that
is
in
cube,
coupled
moving
it
and
using
the
extensions
generating
feedback
taking
the
hit
and
then
working
with
the
other
projects
to
take
their
use
cases,
and
so
that,
if
it's
extensible
for
this
core
thing
that
just
has
to
gradually
transform
it
also.
B
B
The
intent
of
this
is
actually
more
of
a
roadmap
than
my
original
roadmap,
doc
that
Clayton,
Tim
and
I
put
together
and
basically
the
intent
is
to
make
it
clear
what
directions
the
projects
as
a
whole
is
headed
architectural
II,
organizationally
code
wise
and
try
to
put
some
stakes
in
the
ground
about
milestones.
We
want
to
hit
to
get
people
rowing
in
the
same
direction,
so
I
think
we
it
needs
to
be
fleshed
out
a
little
bit
more.
We
will
want
to
publish
it
and
ask
for
input
from
various
SIG's.
B
We
are
trying
to
staff
parts
of
it
on
our
side.
I
would
like
to
get
help
I,
don't
think,
there's
a
lot
of
controversy
anymore
on
most
of
the
things
that
are
that
we're
doing
I
pretty
much.
Everything
in
that
dock
is
underway
anyway,
already
I
sent
out
the
the
data
from
devastates.
That
shows
the
only
increases
to
blah
see
the
project
had
come
from
adding
repos
and
part
of
that
is
due
to
github
issues
like
problems
with
Apple's
notifications.
B
B
Yeah
I
pretty
much
we're
at
a
point
where
everything
new
net
new
that
we're
adding
component-wise
particularly
needs
to
go
into
a
separate
repo,
not
into
communities,
communities
and
I
would
even
like
to
start
down
the
path
using
future
branches
and
the
recent
changes
dig
testing
made
to
move
everything
to
a
single
project.
So
we
don't
need
to
spin
up
new
projects
for
new
release
branches,
and
things
like
that
gives
us
most
of
what
we
need
for
to
be
able
to
add
branch
tests
just
be
a
PR
to
the
testing
for
repo,
so
I'm.
B
Definitely
the
multi
repo
and
feature
brand
stuff
is
not
the
only
thing
in
that
dock.
There
are
a
lot
of
extension
points
and
other
changes
being
made
that
are
in
there,
but
you
know
making
it
clear,
for
example,
that
we
are
trying
to
detangle
keep
control
dependencies
that
were
trying
to
make
even
bergens
queue
actually
work,
and
these
are.
These
are
important
things
for
people
to
be
aware
of
so
we
don't
continue
to
increase
debt.
Yeah
practically
try
to
reduce
it
sure.
I
I
You
know
you
talked
about
staffing
and
I
know
that
comes
in
for
maybe
a
handful
of
companies
here,
but
in
a
typical
week
for
kubernetes
itself,
kubernetes
kubernetes,
there
are
people
from
like
90
different
companies,
90
some
different
companies
who
contribute,
and
that's
just
the
average
there's
a
lot
of
people
across
this
community
at
a
lot
of
different
companies,
and
then
there's
people
not
associated
with
companies,
and
so
the
question
is,
is
how
do
we
help
lead
them?
Help
them
have
a
picture
of
what's
going
on
in
a
way
they're.
I
Not
all
gonna
go
read
long
documents,
they
want
to
be
able
to
visualize
and
very
quickly
understand,
and
so
how
do
we,
you
know,
produce
something
that
helps
them
go
okay.
This
is
what
we
should
do.
This
is
where
we're
going
and
then
help
communicate
that
out.
So
it's
it's
in
a
manner
that
can
be
consumed
by
the
masses
rather
than
a
handful,
and
here
I'm
just
talking
about
the
contributors,
not
even
the
masses,
beyond
that,
just
the
contributors,
yeah.
D
B
You
know-
maybe
we
we
just
don't
know
how
to
do
this,
but
we
have
been
trying
to
do
this
for
four
years
and
I
have
to
say
my
experience
is
that
more
than
90%,
other
contributors
drop
off
and
don't
sustain
so
there's
a
huge
churn
cost
for
explaining
these
cont
complex
issues
and
trying
to
ramp
people
up
and
even
in
cases
where
we
initially
thought
you
know
some
contributor.
He
was
doing
it.
B
Part-Time
was
gonna,
be
able
to
step
up
and
make
a
concerted
effort,
and
you
know
get
their
PR
through,
which
basically
requires
not
just
time
on
Friday
nights,
but
every
day
of
the
week
to
keep
things
moving
forward
with
the
level
of
pace
of
this
project.
Realistically,
it
has
to
be
people
working
full-time,
whether
they're
working
for
a
company
or
not
like
just
in
Santa
Barbara
I
think
is
maybe
the
unique
example
of
someone
who's
kind
of
works
for
himself
to
some
degree
whose
push
made
major
contributions
to
the
project.
B
But
we
do
have
over
a
hundred
people
who
are
who
are
paid
to
work
on
Cobra
Nettie's,
not
just
Google
and
Red
Hat,
but
at
a
number
of
companies
now
and
companies
are
coming
on
board
like
IBM,
who
want
to
want
to
contribute
and
ranking
up.
Those
people
is
is
definitely
hard.
They
come
from
very
other,
maybe
seemingly
related
projects,
both
very
different
technical
conventions
and
it's
just
time
consuming
to
ramp
them
up
on
the
nitty-gritty.
So.
I
B
F
I
F
Met
I
think
the
comment
was
made
earlier,
that
that
there
is
a
certain
amount
of
detail
that
that
is
required
and,
and
the
only
way
I
can
think
of
of
getting
around.
That
is
to
have
an
executive
summary
at
the
top.
If
you
don't
want
to
read
this
whole
thing,
but
you
want
to
like
vague
idea
of
all
the
content,
read
the
executive
summary,
but
it's
by
definition
not
going
to
cover
all
the
required
material
and
if
you
want
to
require
material,
you
read
the
other
20
pages
I
mean.
I
We've
got
to
come
up
with
a
way
to
communicate
it
and
it
isn't
working
and
so
being
able
to
by
mean
that's
one
of
the
reasons.
There's
been
talk
of
diagrams
and
things
like
that,
because
you
can
speak
a
lot
in
the
picture
and
it
doesn't
give
you
all
the
my
new
details.
It
doesn't
link
off
to
all
the
issues,
but
it
helps
people
understand
general
pictures
of
where
we're
going
and
what
we
mean
yeah.
C
C
C
C
F
Just
read:
I
just
read
that
architectural
roadmap
I
think
it's
called
document
20
on
page
one
I
think
for
17
pages,
I
mean
I
happen
to
think
that
it's
an
extremely
good
document
I
mean
it's
clearly
a
bit
rough
around
the
edges
and
it
could
probably
be
abbreviated
by
30%
or
something
like
that.
But
I
mean
there's
a
limit
to
how
much
you
can
throw
away
without
losing
critical
information
and
some.
F
Let's,
just
let's
just
get
it
into
MD
and
get
it
linked
in
the
right
place.
So
when
you
go
to
like
sig
architecture,
you
get
a
like
a
link
directly
to
this.
Is
you
know
current
thinking
on
architecture
and
by
all
means
we
can
update
it
every
you
know,
however,
often
we
think,
but
let's
get
it
out
there,
rather
than
in
some
kind
of
labs,
I'm.
B
Happy
with
that
I
mean
executive,
summary
was
architecture
MD,
and
this
is
getting
down
to
the.
What
is
community's
topic?
I've
tried
to
summarize
it
a
couple
of
times.
Architecture
and
ghee
is
more
about
where
we
are
then,
where
we're
going.
Maybe
we
could
write
a
similar
summary
about
where
we're
going.
They
just
have
I.
B
F
C
I
think
the
thing
to
keep
in
mind
is
that
good
editing
not
only
condenses,
but
it
also
structures
it
in
a
way,
that's
more
consumable
easier
to
scan
easier
to
easier
to.
Actually,
you
know
write
and
it's
a
skill
right
and
I.
Think
you
know
it's
like.
Are
you
going
through
the
process
of
writing
the
book
you
see?
You
know,
I
saw
some
of
this
stuff
actually
come
through
right
and
and
actually
viewing
it
as
a
product
is,
you
know,
is
it
is.
It
is
a
thing
in
and
of
itself.
Okay,.
B
I
Just
gonna
say
I'm
Brian
to
jump
on
one
thing:
real,
quick.
You
know
you
talked
about
slide
decks
and
other
communications.
The
way
that
we
use
to
maybe
create
and
brainstorm
and
collect
stuff
together,
isn't
necessarily
the
best
way
to
also
share
it
with
the
masses
and
so
to
expect
dual
purpose
out
of
something
may
end
up
being
a
little
too
much
sometimes,
and
so
there's
no
criticism
on.
I
B
Okay
sure
yeah
I,
mostly
my
aim,
was
to
with
these
Docs,
was
to
sort
of
figure
out
for
myself
what
we
thought
we
should
do
and
put
it
into
one
place
that
I
could
point
out
and
at
least
have
other
people
who
are
somewhat
informed
to
be
able
to
read
that
and
agree
or
disagree.
I
agree
that
it
was
not
targeted
at
communicating
to
the
masses,
and
that
really
shows
so
anyway,
we
have
five
minutes
left
I
did
want
to
get
to
the
kept
process.
B
B
C
Just
structural
right,
no
I
think
it
is.
It
is
actually
a
pretty
major
update
of
the
template
in
terms
of
the
names
of
the
sections.
I
think
the
feedback
from
Tim
was
really
like.
Why
we're
using
a
lot
of
specialized
terminology
here
which
may
make
a
ton
of
sense
in
the
Rost
community,
but
it's
very
alien
to
focus
that.
B
C
Am
trying
to
remember,
like
I,
can
look
at
the
the
changes,
the
the
the
previous
version,
but
you
look
at
some
of,
but
basically
what
it
is.
It's
like.
What's
the
scope?
What's
the
proposal
and
let's
talk
about
the
proposal
both
in
terms
of
the
nitty-gritty
details,
but
like
user
stories
of
like
I,
was
able
to
do
this
now.
I
can
do
that.
C
Let's
encourage
people
to
think
about
that
and
then
a
section
around
sort
of
risks
and
mitigation,
specifically
I
called
out
security,
and
what
is
the
impact
that
this
change
could
have
on
the
large
ecosystems?
How
cuber
Nettie's
is
used,
infused
and
developed
right,
because
I
think
you
know
everything
we
do
has
ripples
right.
So
what
are
the
ripples
of
this
thing?
Hopefully
it's
not
super
controversial
I.
Think
it'll
maybe
make
this
thing
a
little
bit
more
more
approachable.
C
The
next
thing
on
my
list
is
this
is
the
template
that
was
updated
based
on
I
want
to
go
back
and
there's
there's
the
buddy
document
to
that
which
is
documenting
the
process
that
really
needs
some
help.
Also,
and
and
I
also
want
to
prioritize
getting
some
sort
of
like
Hugo
like
sign
up
or
something
like
that,
that
actually
sort
of
makes
these
things
cross-linked
and
searchable
and
indexed,
because
I
think
that
right,
you
know
we're
we
need
it.
B
Okay,
yeah,
so
in
terms
of
testing
it
on
a
few
more
proposals,
do
you
think
we're
ready
to
do
that?
Could
we
present?
Could
you
present
it
community
meeting
and
we
can
maybe
get
some
ideas
about
some
SIG's
that
could
try
it
out
and
then
we
could
go
to
those
things
and
about
what
proposals
are
on
the
prize
and
for
110.
Then
I
mean.
C
B
C
B
C
Good
I
would
love
to
get
to
the
point
sometime
very
soon,
after
cube
con,
even
though
we're
you
know,
gonna
be
in
the
midst
of
December
to
at
least
to
get
that
process
out,
get
something
where
it's
like.
We
really
want
people
to
use
this
thing.
If
you
use
it,
you
that
priority
for
getting
a
lot
of
eyes
on
it,
you
know,
will
get
to
the
point
where
you
know
we
don't
we
can't
make
decisions
completely
binding
yet,
but,
like
you're
gonna
have
a
lot
of
air
cover.