►
From YouTube: SIG Architecture Full Meeting 20180621
Description
A
A
If
you
are
following
along
after
the
fact
or
you
would
like
to
look
at
the
agenda,
it
is
available
at
bit
dot
Lee,
slash,
singing
our
contention
and
looks
like
there's
a
little
bit
of
AV
problems
in
the
Google
room.
So
hopefully
people
could
join
me
shortly.
So
let's
go
ahead
and
kick
the
meeting
off
here.
A
So
looking
at
the
agenda,
the
first
thing
we
have
up
is
they
talk
about
the
API
review
process
and
just
briefly
so
the
idea
behind
this
was
that
there
have
been
a
number
of
initiatives
over
the
past
couple
of
years
to
try
and
formalize
this
process
and
in
the
in
the
document
that
I've
linked
to
and
let
me
copy
and
paste
this
review
or
the
process
here
into
chat.
So
y'all
haven't
this.
This
document
is
actually
the
culmination
of
other
people's
efforts
and
trying
to
coalesce
them
into
some
sort
of.
A
Some
sort
of
document
that
makes
sense
for
people
to
follow
and
also
to
try
and
set
precedents
about
Sagarika
texture,
also
driving
some
policies.
So
the
idea
behind
this
is
that
we
essentially
are
reviewing
entry,
or
you
know
the
the
conformance
related
API
changes
and
putting
some
rigor
around
how
those
are
reviewed
and
approved,
and
then.
B
A
Obviously
there's
a
lot
in
here
and
it
took
me
until
pretty
much
this
morning
to
get
it
sent
out
to
the
architecture
list.
Just
so
it
could
be
reviewed.
I,
don't
necessarily
want
to
get
into
a
deep
discussion
on
it
today
or
just
bring
everybody's
attention
to
it,
and
we
can
review
it
asynchronously
over
the
course.
A
The
next
week
I'd
like
to
have
a
decision
to
proceed
as
soon
as
we're
able
to
do
that,
and
that
feels
like
there's
some
consensus
from
them,
but
at
the
process,
because
there
are
a
ton
of
caps
and
other
things
in
the
pipeline
that
have
API
overview
implications,
and
it
would
be
nice
to
get
this
sorted
as
soon
as
possible
so
that
we
can
all
those
forward.
And
so
please
take
a
look
at
the
document
at
your
convenience
and
we'll
go
from
there.
So
anything
that
you'd
like
to
add
Brian
or
anybody.
C
A
A
Essentially,
there
would
be
issues
in
a
repo
that's
dedicated
to
these,
so
there
would
be
a
kubernetes
/,
API
reviews
repository
and
then
essentially
the
there
is
a
role
there,
the
moderator
role
that
is
responsible
for
queuing
those
up
and
working
with
the
reviewers
to
prioritize.
So
we
use
the
project
Kanban
style
thing.
They
don't
actually
need
to
be
issues
right,
like
you
can
just
put
text
in
there.
You
can
link
to
issues
npr's
that
are
in
flight
and
they're
kind
of
easier
to
shuffle
around
yeah.
D
A
Need
to
stack
rank
them
to
get
them
bucketed
into
meetings
at
least
yeah.
My
my
idea
or
my
goal
was
that
these
issues
would
be
the
tracking
issues
would
be
stack
ranked
in
the
backlog,
so
whatever's
in
the
top
of
the
backlog
as
high
as
for
you
and
what's
at
the
bottom,
is
lowest
because
that
that
makes
it
really
easy
for
reviewers
to
rapidly
move
priority
up
or
down,
and
it
doesn't
make
any
huge
who
thought
process
it.
A
The
the
document
basically
indicates
that
the
reviewer,
if
they
feel
like
it,
needs
to
be
reviewed
by
more
than
one
person.
So
it's
something
with
complex
or
other
other
involved
parts
of
it
that
that
they
would
pull
in
other
folks
as
necessary
or
as
they
saw
fit
or
pull
in
sig
architectures.
So
part
of
the
part
of
the
idea
of
being
reviewers
that
you
have
the
discretion
to
make
some
decisions
about
how
widely
it
is
reviewed
or
what
the
impact
is.
So
in.
C
E
There
I
believe
it
was
discussed
that
the
this
was
not
the
domain
of
CGI
machinery.
That
API
was
sort
of
critical,
a
first-class
citizen
to
be
reviewed
by
anything
other
than
this
group.
But
I
think
it
would
be
worth
it
to
put
a
short
statement
in
the
doc.
Just
clarifying
that,
because
I
think
a
newcomer
to
this,
but
immediately
have
that
question
to.
E
A
No
I
agree,
so
we've
been
trying
to
identify
some
project
Sagarika
picture
much
like
some
projects
in
other
states
and
API
governance
is
actually
one
of
the
longest
standings
kind
of
sub
projects.
That
tree
creates
Sagarika
texture
and
there
is
an
official
list
of
API
reviewers
that
are
kind
of
crossed.
A
Sick
I
mean
generally
expect
proposals
and
api
is
to
be
vetted
by
the
technical
leaders
and
owners
of
sub
projects
within
individual
states
first
and
then
come
to
API,
reviewers
and
approvers,
which
there
are
you
know
explicit
list
of
those
people
for
issues
about
API
consistency.
You
know
APR
approval,
especially
for
whole
new
api's
I'd.
C
C
To
emphasize,
though,
that
historically,
the
process
is
get
your
Stig
to
sign
off
on
something
write.
All
the
code
then
get
an
API
review
which
inevitably
finds
something
that
you
need
to
change,
which
means
you
need
to
go
back
to
square
one,
but
probably
it's
the
week
before
code
freeze
and
so
you're
yeah.
A
C
It
depends
on
how
long
you've
been
on
the
project
and
I.
Think
people
don't
always
appreciate
that,
like
I
honestly
expect
to
review
even
like
single
field
changes
our
API
changes
and
they
need
the
same
level
of
scrutiny,
maybe
not
the
same
level
of
time
commitment,
but
they
need
to
be
scrutinized
and
they
are
subject
to
that
in
terms
of
conventions
and
whatever,
just
as
a
new
API
type
is
and
honestly
even
the
comments
around
a
field
because
they
now
carry
metadata
for
the
code
generation
and
other
things.
Those
are
subject
to
review
as
well.
F
I
think,
as
we
look
at
a
process
like
this,
it's
important
to
realize
that
there's
at
least
three
parties
involved.
There's
the
person
writing
the
API,
there's
the
reviewing
of
like
an
improving.
F
It's
also
important
to
recognize
that
there's
going
to
be
a
bunch
of
folks
that
are
auditing
the
process
that
actually
want
to
keep
track
and
sort
of
learn
from
it
and
and
so
having
clear
lines
of
sights
in
terms
of
which
EP
eyes
are
coming
and
what
reduced
look
like
the
types
of
things
that
people
are
looking
for.
I
think
that's
something
that
we're
really
missing
right
now.
F
There
is
no
place
where
we
can
go
and
actually
get
this
sort
of
flow
of
what
the
API
changes
are
that
are
coming
in
so
and
hopefully,
I
think
I
haven't
read
through
this
in
detail
Jase,
but
it
it
looks
like
you
know.
If,
if
we,
if
we
say
API
reviews
go
through
issues
with
labels
or
in
a
repo
or
what-have-you,
we'll
actually
go
ahead
and
and
get
there
yeah.
E
Yeah
I,
just
like
a
couple
of
the
things
that
you
said
and
Tim
said,
seemed
like
very
clear
guidance
on
how
the
overall
process
should
work
and
and
those
statements
aren't
in
the
dock.
So
I'm
sure
the
dock
is
probably
pretty
useful
for
the
reviewers.
But
in
terms
of
maybe
it's
an
audience
question
which
is,
if
you
want
an
API
change,
yours
that
loop,
you
should
expect
and
you
should
be
getting
a
sig
approval
as
I'm
looking
through
the
dock.
It
just
doesn't
say
those
things
generally.
G
The
way
things
actually
work
is
so
you
have
a
teacher
you
want
to
ship.
The
feature
introduces
a
new
API
or
modified
an
existing
it
yeah.
If
you
open
up
a
cap
or
design
proposal,
depending
on
what
you're
doing
you
associate
that
as
part
of
the
feature
when
you
open
that
up
in
the
next
future
rows
during
that
design
process,
you
should
be
getting
reviews
from
your
saying:
you
need
an
approver
there.
G
You
need
an
API
approver
listed
at
as
part
of
that
design,
process
and
part
of
your
feature
proposal,
and
that's
before
you
start
writing
code.
Now,
if
you
want
to,
you
can
start
writing
code
concurrently
with
the
design
process,
but
that
might
spend
a
lot
of
wheels
like
you,
probably
well,
once
your
design
gets
approved
and
once
that
gets
merged,
your
cap
or
whatever
gets
merged
and
the
feature
who
is
in
the
feature
repo
for
that
release.
A
That
that
whole
into
ends
to
be
better
document
and
that's
part
of
what
we
were
trying
to
do
it
kept
and
we
prune
down
from
the
new
process
for
a
while.
We
made
three
previous
attempts
this
time.
We
need
to
push
it
over
the
finish
line.
I
do
agree
that
we
need
to
make
that
much
clearer
to
the
community
and
I
think
we'll
have
to
presented
to
the
whole
community
multiple
times
likely
in
order
for
people
to
really
ask
that
Joe.
F
F
I
yet
I'm
not
saying
like
we
need
some
sort
of
process
here
and
so
I,
don't
think
of
that
it
has
any
teeth
and
that's
part
of
the
problem
that
we
have
here,
I'm
hoping
and
we
still
have
to
do
some
reconciliation
between
caps
in
the
future
process.
And
really
you
know
how
do
those
things
relate
to
each
other?
That's
something
that
I,
don't
think
has
been
done
yet
either.
You
know
Tim
is
here
like
hey
should,
should
you
have
to
do
it
kept
into
an
API
change?
F
That
seems
a
little
heavyweight
to
me,
but
like
we
need
this,
we
need
to
have
a
like.
You
want
to
make
some
changes,
here's
the
way
that
it
happens
and
in
wine
API
is
into
that
and
then
I
think.
On
top
of
that,
we
ought
to
recognize
that
we
do
have
choke
points.
We
do
have
places
where
we
can
say
yes
or
no
api's
command
line
flags.
F
G
Think
one
thing
that's
really
challenging
about
the
overlap
between
the
cap
and
the
feature
process.
Is
that
a
feature
lives
across
multiple
release
right
now,
but
if
feature
goes
out,
put
in
one
release
and
progresses
through
stability
right
and
it
kept
spans,
potentially
multiple
features,
as
well
as
multiple
releases
and
is
in
fact
a
living
document
about
how
we're
going
to
evolve
something
over
the
long
term.
Communicating
that
has
been
difficult.
G
A
I
did
all
that
work,
I
tied
the
feature
process
to
the
kept
process
to
the
release
process
and
all
that
stuff
and
I
met
quite
a
bit
of
resistance,
because
people
didn't
understand
exactly
those
delineation
that
you
said.
So.
It
may
be
time
to
unearth
that
prop
that
again
now
the
caps
are
a
little
more
well
understood
and
and
specialized
I
feel
like
that.
The
three
the
three
prongs
here:
the
kept
process,
they're
a
peer
review
process
and
then
features
process
tied
to
the
caps.
A
B
I
want
the
idea
here,
I
know
a
while
back
Wireless
Lebanese
manager
I
also
try
to
squeeze
out
this
problem.
So
I
have
the
proposal
like
the
project
issue,
which
is
serve
as
a
tree
line
issue
and
there's
the
meaning
of
the
holder,
feature
connect
across
the
magical
ripple
and
also
crossing
the
future
crossing
the
matically.
These.
Could
you
have
the
embryo
issue
to
tracking
through
so
then
we
could
build
off
the
ultimately
the
tool
to
generate
the
reporter
for
each
release.
B
So
you
have
some
very
nice,
and
here
it
is
the
issue
for
that
feature,
and
then
here
it
is
the
related
deliver
for
each
release
and
also
in
the
different
and
report
associated
or
reports
or
listen,
but
also
got
huge
pushback
around
the
community.
So
that's
the
any
process.
Is
we
don't
want
to
follow
any
process?
That's
just
well.
A
So
in
the
past
we
favor
velocity
and
features
and
lady
consensus
and
things
like
that-
I
mean
proposals
and
API
changes
and
key
ours
in
general
whenever
glazy
consensus,
but
we
need
to
get
that
message
across
that,
where
the
stage
of
ensure
v8
power
stability
is
more
important
and
consistency
is
more
important,
so
you
know
articulating
figuring
out
and
articulating
how
these
processors
do
work
and
then
iterating
on
the
processes
together
with
the
community
I
think
is
a
necessity.
At
this
point.
It
can't
be
of
total
freefall
people
doing
whatever
they
want.
F
Yeah
I
just
want
to
like
double
down
on
what
Brian's
saying
just
I'm
in
violent
agreement
there
and
it's
natural
for
things
to
slow
down
as
the
core
you
know,
nucleus
or
whatever.
We
want
to
call
it
actually
solidifies.
This
also
creates
the
right
incentives
for
people
to
build
on
top
of
our
extensibility
mechanisms.
It
should
be
painful
to
get
stuff
into
the
current
right,
because
it's
less
risky
for
people
to
build
stuff
outside
of
the
kernel,
and
we
should.
We
should
really
make
it
clear
that
that
yeah,
there's
gonna
be
process.
A
And
if
you
look
at
the
commit
graph
for
kubernetes
to
release
master,
it
is
down
into
the
right,
so
it
kind
of
has
the
right
trajectory
from
a
stability
point
of
view
for
like
the
past
two
years
and
part
of
that
is
success
and
getting
changes
out
of
the
core
part
of
is
just
harder.
We
have
a
thousand
open
PRS
right,
like
we
are
not
keeping
up
with
the
review
bandwidth,
even
with
Auto
closing
things
that
it's
a.
We
stopped
monotonically
increasing
by
a
hundred
PRS
every
release.
A
It's
not
going
down
either.
So
you
know
we
need
to
be
more
clear
about
about
the
bar
and
about
these
disability
mechanisms.
You
know
we
need
to
focus
more
on
things
like
testing.
You
don't
have
good
enough
test
coverage.
We
need
to
figure
out
how
to
keep
your
identity
useful.
We
have
a
bunch
of
these
challenges
and
we
need
to
get
rally
the
whole
community
around
addressing
these
challenges
and.
A
Get
more
people
than
just
Jordan
redoing,
random,
random,
API,
random
API
changes.
I
do
want
to
point
out
something
I
mentioned
in
the
chat
which
is
we
do
have
the
bots
still
automatically
identifying
API
changes.
Prs
incriminates
communities,
at
least
that
touch
types
are
no
files
are
automatically
flags.
So
that's
an
additional
audit
mechanism
that
we
could
regularly
use
to
keep
track
of
some
of
those
things
and
we
could
potentially
put
more
barriers
in
place
with
respect
to
approvals
for
those
PRS.
So.
G
G
G
A
It's
really
really
hard
to
keep
track
up
and
get
hub
notifications
for
the
past
two
years.
I've
not
been
able
to
make
work
for
me
at
all.
Do
we
have
to
show
for
how
flow,
as
we
do
for
because
I
get
seen
people
be
a
lot?
That's
an
open
question
that
should
be
answered
in
the
API
review
process,
for
sure
is
what
you
need
to
back
that
up
and
also
what
do
they
expect
to
happen
Adina?
C
But
we've
talked
about
this
for
a
long
time,
yeah
I
would
say
we
have
a
proposal
in
place.
It's
Jace's
doc,
it's
not
very
long,
and
that
way
it
has
a
diagram.
It
has
a
picture
as
a
diagram
and
so
I
think
that
should
be
the
place
where
we
iterate
I
took
a
couple
of
ideas
and
I
will
go
and
sort
of
reread
the
doc
and
see
if
I
can
put
a
little
bit
of
plain
English
expectations
in
there.
But
like
I,
don't
think
we
need
a
different
doc
or
a
different
process
and
yeah.
C
A
C
Would
say
all
API
reviewers
need
to
act,
that
they've
reviewed
it
and
at
least
a
representative
sample
of
sig
architecture
needs
to
also
act
that
they've
read
and
reviewed
it
I.
Don't
think
I
don't
want
to
turn
this
into
lazy
consensus.
I
want
this
lab
concrete,
like
you
know,
more,
a
peer
reviewer.
You
should
have
read
through
this
and
understand
it,
which
I'm
sure
I've
API
approvers.
We
should
get
sign-off
from
all
of
them
and
I
think
a
cig
architecture
like
anyway,
the
cig
who's
participating
as
discussion
has
a
week.
C
A
Okay,
cool
I
put
in
to
do
up
there
for
myself
to
add
so,
if
you're
in
the
API,
reviewers
Google
github
group,
consider
yourself
a
required
reviewer
and
I
will
take
care
that
and
either
next
week
or
the
next
meeting
yep
next
next
week.
Let's,
let's
have
let's
come
to
some
consensus
by
next
week
by
next
Thursday,
so
I'm
gonna
Pacific
Lee
call
on
since
he
does
a
lot
of
API
review
Jordan.
Do
you
have
any
specific
concerns
about
the
proposal
or
things
that
you
think
are
really
critical
that
are
missing?
H
Sorry,
I
Britt
through
it
once
briefly
I
think
overall,
it
looks
good
I
think
just
point
about
wait.
Where
in
the
process
do
we
hook
in
is
important?
I
can
see
both
both
ways.
If
you
come
in
too
early,
then
there's
a
lot
of
turn
before
the
sig
even
agrees
with
the
direction.
But
if
you
come
in
too
late
that
a
lot
of
work
has
been
done,
that
kind
of
gets
negated
at
the
last
minute,
so
I
think
that's
that's
probably
going
to
be
the
balancing
point.
A
Need
you
to
process,
we
need
API
consulting
and
that's
where
I'm
trying
to
do
things
like
I
think
we
need
better
linting
tools,
we
need
to
document
more
of
the
conventions.
Maybe
we
have
a
forum
like
this,
where
people
can
just
come
and
ask
for
guidance
or
a
feedback
or
a
help,
I
mean
we
already
have
people
doing
that,
and
then
the
official
review
and
approval
is
the
more
formal
process.
Yeah.
G
But
I
think
Jordans
point
is
more
like.
Maybe
we
should
just
have
so
like
have
sig
approve
will
be
a
prerequisite
to
API
approval
sake.
Generally,
it
doesn't
is
saying
this
is
not
the
direction.
I
think
this
particular
feature
should
go
in
period.
There's
no
point
to
reviewing
Nate
yeah.
Well,
I
agree
with
that.
Yeah.
C
Julie
actually
happens,
like
I,
think
I've
seen
in
general,
almost
every
API
changes
but
and
stuff
that
I've
ever
seen
has
been
something
to
sig
is
agreed
on.
It's
usually
the
challenges
are
just
some
of
the
more
subtle
nuances
the
system
get
lost,
which
is
like
a
cig
architecture
role
as
much
as
it's
an
API
review
rules.
Api
review
just
happens
to
be
the
place
where
architectural
things
get
surfaced.
C
A
F
C
That's
actually
a
good
like
I
bet.
You
there's
probably
like
the
these
are
good
things
to
add
to
the
dock,
to
like
just
go
and
make
like
a
quick
somebody's
rules
of
thumb
get
them
down.
Do
we
generally
feel
that
the
cig
architecture,
or
is
that
the
SIG's
job
is
to
make
sure
that
caps
exists
for
the
things
that
kept
exist,
in
which
case
day
or
can
always
just
at?
Do
we
need
something?
C
F
It's
totally
reasonable,
like
anytime,
any
of
us
are
reviewing
something
we're
like
wow.
That's
that's
kind
of
a
big
sweeping
change.
They
should
really
have
a
cap.
We
need
to
make
sure
that
the
community
is
aware
of
this
I.
Think
at
any
point
we
can
call
an
audible
and
say
hey.
This
group
should
probably
have
a
cap
once
something
goes
through
the
cap
process
and
it
goes
to
implementable.
The
the
you
know,
that's
good
for
everybody,
because
it
means
that
you
know
it's
it's
it's
that
much
harder
to
actually
undo
it
relitigated.
A
All
right
cool
I'm,
making
some
comments
to
myself
in
the
document.
If
anybody
has
thoughts
about
those
things
that
we've
talked
about,
go
and
just
add
to
those
comments,
your
your
ideas,
thoughts
well
yeah,
so
we
did
briefly
touch
on.
Do
we
treat
alpha
differently
than
beta
differently
than
v1
as
someone
who's
been
brought
in
on
a
v1
API
of
who-ville,
when
I
did
not
review
the
alpha
or
beta
I'd
have
to
say
that
it
definitely
needs
to
be
earlier
than
v1.
Maybe
not
you
know,
but
by
the
time.
C
F
Please
listen
to
more
stable
API
versions,
yeah,
okay,
so
I'll
be
concrete.
Here.
I
was
reviewing
the
cap
that
was
brought
up
in
the
community
meeting
right.
This
is
the
thing
around
the
namespace
stuff
and
there's
a
question
around
initializers.
Are
they
alpha
or
not
alpha,
there's
the
initializer
admission
controller,
but
then
there's
our
mechanism,
I,
don't
claim
we
tagged
you
in
that
right
and
I
think
commented.
C
F
I
so
I
was
reading
through
that
cap
and
initially
I'm
like
oh
this
all
C
or
D,
is
it
can
all
be
done
outside
great?
You
don't
even
need
to
actually
talk
to
anybody,
just
go
build
it,
but
now,
all
of
a
sudden,
it's
impacting
real
api's.
There's
that
alpha
thing
like.
Oh,
what's
that
like
moves
it
into
a
totally
new
category,
in
my
mind,
yeah.
C
Which
is
why
it's
a
cap
and
I
think
that
it
was
actually
that's
a
good
example
of
where
the
generic
mechanism
like
initializer,
was
a
great
example
of
we
made
two
generic
mechanisms.
One
of
them
didn't
quite
work
as
well
as
we
wanted
and
we're
kind
of
saying.
Maybe
we
want
to
hold
draw
the
scope
down
the
implicate
like
this
was
a
perfectly
timed
one,
because
we
were
trying
to
go
through
the
discussion
of
removing
generic
initializers,
and
this
is
the
example
of
something
that
is
a
use
case
that
is
very
difficult
to
do.
A
So
I
was
going
to
say
too
bit,
since
what
we're
trying
to
do
is
preserve
consistency
of
user
experience
across
all
API
implementations,
including
in
CRNAs.
Ideally
there
having
reviewed
an
alpha
state
makes
a
ton
of
sense
because
a
lot
of
the
conventions
and
the
implementation
mechanisms
will
remain
the
same
throughout
for
beta,
stable,
hopefully
so,
the
earlier
we
catch
those
and
get
people
using
good,
API
construction
hygiene
from
the
beginning
that
that's
just
better
for
everybody
and
makes
it
easier
to
review
over
the.
C
Long
haul
as
well,
okay,
most
architectural
problems
are
present
in
the
Alpha.
If
they're
going
to
be
present
at
all
so
I
think
from
the
perspective
of
Brian's
perspective
and
the
thing
about
you
know,
the
thing
I
noticed
is
like
the
last-minute
ones:
they'd
have
architectural
implications.
Those
are
almost
always
alpha.
It's
very
rare
that
we
are
ever
going
to
a
beta
and
find
an
architectural
problem.
All
right,
I
think
it's!
You
know,
we've
been
pretty
good
at
it.
G
I
think
one
of
the
challenges
that
I've
found
is
this,
so
you
do
a
capillary
design
proposal
and
then
you're
going
to
introduce
the
feature
is
alpha
right,
so
you
need
review
definitely
from
the
API
proof
approver
before
you
go
alpha
when
you
promote
it
to
beta,
you
need
to
go
through
review
again,
even
if
it's
identical
when
you
need,
when
you
go
ga
same
same
thing
right.
So
the
the
review
burden
is
at
least
three
hundred
three
times
and
if
you
change
anything
more
than
that
for
the
API
review
right.
B
E
C
G
C
Never
removed
Jordan
disagrees
to
me
like
I've,
never
felt
that
the
beta
most
of
the
beta
and
GA
moves
or
more
the
Sun
oh
stuff,
like
Joe's
point
about
when
we
change
defaults
going
across
groups,
but
not
changing
the
version
and
deployments
a
lot
of
those,
at
least
in
my
experience.
A
lot
of
those
are
this
works.
Is
it
still
working?
What
are
you
trying
to
do
this
novel
and,
if
you're
not
trying
to
do
anything,
it's
a
pretty
quick
approval.
Yeah.
H
C
Not
to
pick
on
six
storage
but
I
feel
like
they
get
out
the
thorny
API
ones,
which
is
that's
a
sick.
That
has
a
lot
of
API.
Surface
area
is
trying
to
do
a
lot
of
complex
things
is
really
important
to
the
ability
people
to
use
the
platform
for
what
they
want
to
do
with
it,
but
is
often
like
be
there's
a
lot
of
thorny
issues,
because
it's
just
a
complex
surface
area.
I
think
we
spend
a
lot
of
time
on
those
more
so
than
almost
any
other
thing.
F
A
So
I
Harris
didn't
raise
your
hand,
but
she
posted
something
in
the
chat.
So
I
just
want
to
call
that
out.
It's
a
good
point
all
this
stuff.
Yes,
we
should
create
documents.
We
need
to
present
it.
If
we
do
present,
it
will
be
good
to
record
that
as
kind
of
a
standalone
presentation
and
posted
to
YouTube.
A
So
we
can
point
people
at
that
similar
to
Tim's
code
review
workshop
Thanks,
so
people
can
understand
the
process
better
than
we
can
actually
walk
through
it
and
and
show
examples
what
we're
what
we
mean
and
what
we're
talking
about
and
how
the
whole
thing
works.
So
I
think
that
would
be
great
should.
A
That
would
be
super
helpful
I've
wanted
to
do
that,
for
so
many
things,
governance
things
everything
else,
so
this
would
be
a
great
pilot
to
test
that
worth.
Let's,
let's
definitely
consider
that.
Okay,
thanks
Paris,
okay.
So
let's
go
ahead
and
move
on
the
agenda
it's
about
halfway
through
our
time.
So
when
make
sure
it
has
enough
time
for
the
next
thing.
So
sad
are
you
in
the
room
there
I
can
I'm
over
here,
I'm
hiding
behind
the
camera.
A
So
last
week
we
had
a
discussion
in
architecture
about
how
we
can
continue
to
add
to
six
story
of
someone
just
raise
the
point.
Six
storage
has
a
very
large
API.
We
have
new
features
that
would
continue
to
want
to
add,
and
you
know,
kubernetes
as
a
whole,
we've
kind
of
decided.
We
don't
want
to
continue
to
expand
the
core
API
and
minimize
that
and
the
advice
from
sega
architecture
was,
for
the
snapshots
feature
at
least
to
try
and
implement
it
out
of
tree
using
crts
and
external
controllers.
A
We're
pursuing
that
now,
and
there
was
some
clarification
that
we
wanted
to
get
regarding
CR
bees
in
general.
There's
a
couple
of
use
cases
that
we
encountered,
so
the
question
essentially
is:
can
can
core
kubernetes,
binaries
and
API
objects
to
refer
to
CR,
DS
yeah,
no,
okay,
I
think
that
has
been
true
since
I
wrote
the
architectural
roadmap.
Okay,
talk
about
that!
It's
in
the
nucleus
it's
intended
to
be
built
upon.
A
If
we
look
at
the
pains
with
upgrading
versions
and
dealing
with
upgrades
and
downgrades,
and
things
like
that,
it
introduces
new
flexibility
that
I
think
we're
gonna
need,
and
so
just
in
terms
of
experimentation
of
features
and
reducing
the
amount
of
stuff
in
terminate
or
denny's
faster.
It's
definitely
aligned
with
the
directions
of
a
lot
of
things
that
were
in
the
project,
hang
on
them,
so
Joe's
up
and
then
I
believe
Jordan
and
then
Tim,
Tim,
I'd.
H
I
was
gonna:
ask
what
you
mean
by
referring
to
so.
Does
that
mean
like
having
a
name
field
like
a
foo
name
field
in
a
core
object,
and
that
is
implicitly
an
API
group
and
version
and
type
that
is
defined
by
a
CR
D
or
is
that
it
like
a
fully-qualified
like
here's,
the
kind
and
group
and
name
kind
of
like
we
do
for
owner
references
and
and
references
like
that.
A
Was
a
controller
dependency,
so
today
we
have
the
attached
detached
controller
and
we
want
some
way
to
be
able
to
figure
out
whether
that
step
should
be
skipped
or
not.
And
ideally
what
we
want
is
an
API
object
to
represent
an
external
CSI
driver.
That's
installed
on
the
system,
part
of
one
of
the
fields
for
that
new
object
would
be
whether
that
attach
step
is
required
or
not.
A
So
the
attach
detach
controller
now
has
a
dependency
on
this
external
C
or
D
object
and
I
wanted
to
figure
out
if
that
was
ok,
so
that's
a
controller
dependency
on
an
external
CRD.
The
second
use
case
was
a
API
dependency
on
at
CR
D,
which
is
for
the
specifically
for
the
snapshot
use
case
we
want
to
be
able
to
when
you
provision
a
new
volume
say
provision
this
volume
but
pre-populated
using
some
existing
snapshot.
So
would
it
be
okay
to
have
a
snapshot
source
added
as
a
first
class
field
in
the
BBC
object?
A
Even
though
snapshot
itself
is
not
a
core
API
object,
we
should
figure
how
whether
actually
appeal
that,
all
or
not,
because
it's
just
a
creation
time
art
act
but
other
you
know
other
than
that
cities
case
in
general.
I
would
say
yes,
I
think
we
need
to
look
at
custom
resources
for
as
dynamic
resources
and.
H
I
was
just
gonna
say
as
we
as
we've
seen.
People
will
do
lots
of
things
to
try
to
get
their
pet
features
into
kubernetes
api,
and
if
these
c
rd,
based
or
dynamic
based
api's,
become
things
that
the
core
relies
on,
then
we
should
expect
people
to
change
the
definitions
of
those
running
in
their
clusters,
and
so
conformance
tests
around
these
particular
API
is
if
they're
dynamic
KPIs
of
the
court
depends
on
but
are
mutable
by
particular
installations.
Conformance
tests
will
be
critical
for
making
sure
that
that
is
working
properly.
Thank.
A
You
with
that,
but
I
also
think
we
need
more
mechanisms
to
control
lifecycle,
those
kinds
of
things
that
cluster
depends
on,
and
we
had
these
things
from
the
beginning
of
time
that,
like
the
default,
namespace
keeps
system
namespace
as
we're
moving
towards
more
resource
to
find
policies
that
are
required
in
order
for
the
cluster.
Its
work
at
all,
as
we
move
towards
more
self
hosted
components
as
we
move
towards
component
config,
and
we
need
mechanisms
to
better
control
how
all
these
resources
are
managed
that
the
cluster
depend
on
critically
to
operate.
A
C
So
I
think
to
to
sod
the
you've
got
two
interesting
issues.
The
second
one
I
want
tackle
first,
which
is
intra
API
inter
API
linkages,
where
one
is
I,
think
that's,
okay,
I,
don't
think
we
have
a
lot
of
precedent
for
that,
so
I
think
I
was
being
nice,
so
I
think
you're
going
to
do
a
little
bit
of
trailblazing.
There's
going
to
be
some
error
handling
modes
that
you're
gonna
have
to
think
about
that
nobody's
had
to
think
about.
Yet
good
luck,
we're
with
you.
C
Somebody
said
earlier:
a
sort
of
a
built-in
API,
that's
defined
outside
of
being
built
in
and
a
non,
not
part
of
the
project.
Api
I
think
in
this
case
we're
shooting
for
an
API
that
is
in
fact
part
of
the
project
but
is
not
defined
as
a
built-in
I
think.
That's
the
goal
for
a
large
number
of
API
is
over
time
right,
like
in
the
limit
that
could
be
pod
right
and
when
we
can
do
pod.
As
that,
then
we
know
that
C
RDS
actually
built
enough
to
support
real
users
right.
F
So
I
think
you
know
in
that
particular
case.
It
is
worthwhile
to
think
a
little
bit
further
afield.
Around
okay,
I
wanna,
I
wanna,
you
know,
I
have
a
PV
PV
C
I
want
to
attach
it
to
a
volume,
that's
initialized
via
snapshot
via
clone
via,
like
I,
you
know
get
Reba
I
mean
like
I,
don't
I
think
we
should
be
thinking
about
there.
F
There's
gonna
be
a
continual
number
of
ways
to
initialize
volumes
and,
as
you
think
about
that
think
about
like
could
we
have
an
extensible
set
of
volume
initializers
that
people
can
register
maybe
like
a
CC
or
DS,
then
you
can
plug
into
vs.
special
casing
snapshots
versus
clones
versus
fill
it
with
zeros
fill
it
with
ones
filled
with
twos.
You
know
so.
A
The
cases
that
we've
had
a
git
repo
we're
in
the
process
of
trying
to
deprecated,
but
that's
definitely
use
case,
object,
stores
or
another
super
common
use
case
where
people
are
trying
to
work
around
them
using
fuse
and
things
like
that,
and
then
images
is
the
other
one.
Actually
container
images,
yeah
good
advice,
we're
gonna,
look
at
that.
It's
not
a
hard
set
thing,
we're
just
kind
of
think
about
it,
wanting
to
get
advice,
yeah.
C
A
A
F
Hey
there's
an
interesting
thing,
because
I
think
when
you
look
at
when
folks
do
controllers
and
operators
outside
of
the
core
there's
two
patterns,
one
of
them
is
that
we'll
have
controllers
that
actually
self
initialize,
the
CRTs
that
they
depend
upon
at
first
run
and
then
there's
other
there's
other
ones.
That
expected
to
be
an
you
know
an
install
time
and
administration
thing
to
actually
register
the
CRTs,
and
it's
really
all
over
the
map.
F
Personally
I
think
from
a
security
point
of
view,
it's
better
if
it's
an
explicit
installation
step
from
the,
so
the
controller
doesn't
have
those
permission.
So
I
think
some
of
this
is
that,
like
there's
a
difference
between,
does
the
system
initialize
that
versus
does
that
controller
initialize
it
because
at
the
end
of
the
day,
as
we
start
scoping
down
the
are
back
roles
for
controllers,
we
want
to
make
sure
that
they
don't
get
carte
blanche
to
be
able
to
manage
arbitrary,
C
or
DS.
That's
probably
not
a
permanent.
That's
not
a
runtime
permission.
G
F
G
F
A
Summarize
what
you're
saying,
try
and
avoid
it,
if
at
all
possible,
because
you
could
run
into
our
back
issues
and
dependencies
which
will
be
hard
to
manage
in
the
future?
Well,
in
the
same
controller
like
the
controllers,
it
just
needs
to
read
and
write
the
actual,
see.
Arnie
instances
you
know
doesn't
need
the
same
permissions
as
whatever
installs
the
actual
resource
definition
doesn't
need.
D
H
F
F
H
G
A
G
C
G
A
F
That
I
think
we're
missing
here
is
that,
as
we
change
the
number
of
binaries
that
we
ship
it's
gonna,
be
very,
very,
very
difficult
to
get
all
the
installation
mechanisms
on
the
same
page
around
this
stuff.
So
the
fact
that
we
don't
have
a
common
agreed-upon
tool
set
for
deployment
I
think
the
closest
we
have
is
cube.
Admin
means
that
we
don't
have
a
lot
of
levers
and
it's
going
to
be
more
painful
than
it
necessarily
needs
to
be
to
actually
make
that
transition
that
we're
talking
about
I,
also
plan
on
management's
on
my
radar.
D
G
And
I'm
so
glad
my
thought
was
really
around,
like
so
with
controller
manager,
it's
a
bounded
performance
and
utilization
footprint
right
as
well
also
a
bounded
monitoring,
surface
area.
So,
as
you
extrapolate
many
many
many
many
controllers,
the
resource
utilization
is
very
variable,
monitoring
service
is
increased
and
the
performance
of
the
overall
system
is
affected
in
ways
that
may
not
be
extraordinarily
predictable
and
Lee.
To
me,
like
that's
what
I'm
kind
of
concerned
with.
F
F
Three
concerns
here
is
that
can
we
logically
move
these
things
around?
Do
we
have
the
code
structure
that
we
can
repackage
them?
The
second
thing
is:
how
do
we
manage
install
if
we
actually
start
doing
some
of
that
stuff
and
then
the
third
thing
is:
how
do
we
qualify
the
operational
ongoing
operational
burden
of
that
right.
D
Actually,
I
think
the
only
reason
that
it
would
be
desirable
to
run
every
controller
separately
is
is
that
the
share
memory,
it's
more
efficient
to
run
them
together,
think
about
taking
the
shared
Informer
and
running
it,
maybe
out
of
process.
So
even
if
you're
running
in
separate
binaries,
it's
something
we
can
think
about
keeping
on
capacity
right,
David.
A
Yeah,
just
a
time
check,
we've
got
six
minutes
and
I
think
this
means
that
this
whole
conversation
is
critical
and
should
be
codified
in
some
sort
of
something
that
can
be
digested
by
other
stakeholders.
So
is
this
a
cap.
Is
this?
Something
else
is
this
a
roadshow
that
needs
to
be
well?
It's
not
a
cap
yeah,
that's
more
of
a
statement
of
direction.
A
I'm,
probably
we
need
to
produce
an
updated
architectural
roadmap
kind
of
dock,
which
says
this
is
our
current
thinking
about
the
direction
that
we're
going,
and
maybe
we
need
to
see
like
a
series
of
more
focused
docks
on
specific
issues
that
are
easier
to
digest.
I've
definitely
had
this
conversation
at
least
10
times
and
last
two
weeks,
so
I'm
gonna,
say
good
API
Machinery
produce
such
a
thing
about
just
so
happens.
I
have
a
deck
of
Sighs.
Another
word.
D
A
C
C
Do
we
think
that
CR
DS
that
are
effectively
part
of
the
project
again
at
Capeside,
I/o
prefix,
and
should
be
some
namespace
that
even
for
you,
I,
think
if
you
want
the
case
that
I/o
prefix,
the
suggestions
of
the
API
reviewers
I
agree
completely.
Tory
I
agree
completely
with
that.
The
point
is
that
we
haven't
really
governed
something
gates
that
I/o
as
API
groups.
It's
sort
of
been
a
free-for-all
have
storage
decades
that
I
it's.
A
Definitely
grown
organically
in
my
original
position
was
that
the
kind
of
the
built-in
API
is
the
low
layers
of
the
stack
wouldn't
have
to
be
suffixed
and
the
suffixes
would
mostly
be
used
for
the
extinction
universe,
but
now
that
the
machinery
well
so
anyway.
So
that
seems
to
be
true
a
long
time
ago,
just
organically
so
I
think
it's
reasonable.
At
this
point,
just
to
say,
the
project
itself
will
suffix
all
future
API
groups
for
consistency.
D
A
C
I
mean
I'd,
say
from
historical
precedent.
The
problem
really
is
that
we
have
really
just
two
classes
of
things:
things
that
are
eventually
going
to
be
part
of
the
project,
but
nobody's
willing
to
say
yep.
This
is
100%
sure
we're
gonna,
take
this
and
then
the
things
that
are
just
outside
the
project
and
pick
their
own
names,
I
I,
feel
like.
C
We
spend
a
lot
of
time
worrying
about
the
former,
but
the
latter
is
what
we
want
to
be
encouraging
anyway,
like
I,
like
things
being
at
home,
like
if
the
helm
resources
were
in
a
helm
that
I,
oh,
that
would
be
a
better
outcome.
I
think
for
the
project
as
a
whole
namings
hard
I'd.
Rather
people
come
up
with
short,
distinctive
names
that
match
their
use
case,
and
you
know
like
every
time.
One
of
those
outside
things
succeeds
like
getting
not
being
in
case
I
die.
Oh,
we
tether
as
an
ecosystem
depends.
C
That
nothing
lines
up
or
people
using
consistent
case
or
underscores,
but
that's
not
the
reason
not
to
do
it,
but
to
the
point
at
hand
with
storage
like
there
isn't
a
or
helm
driving
the
storage
work.
It
is
the
storage
sink.
So
should
it
be
storage
to
dock
gates
that
IO,
should
it
be
storage,
not
sink
Kingston
I
own.
C
The
Joe's
comments
notwithstanding
and
I
agree
with
Joe's
comments
that,
like
I,
think
we
want
to
keep
your
friends
close
and
your
enemies
closer
I'm,
not
saying
sod
is
an
enemy,
but
just
judging
by
the
amount
of
interactions
with
the
rest
of
the
system.
I
like
keeping
storage,
closer
and
so
storage
that
case
that
IO
does
seem
appropriate
for
storage.
C
C
The
idea
that
storage
is
outside
of
kate's,
that
IO
or
outside
a
bunch
of
people
from
the
system
coming
together,
trying
to
make
something
we're
trying
to
keep
attic
eights
that
IO,
so
that
the
that
we
have
the
freedom
to
expand.
But
it
is,
we
do
want
to
keep
an
eye
and
make
sure
that
everything
works
together.
Well,
and
you
know,
collaboration
together,
I,
don't
think
a
subspace
of
kate's.
That
IO
is
really
a
problem
for
storage,
so
think
about
what
you
guys
would
want
them
to
produce
to
be
and
that'll
be
part.