►
From YouTube: 20200312 SIG Arch Community Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
The
problem
statement,
if
anybody
doesn't
recall,
was
that
there's
a
problem
with
the
way
defaults
are
applied.
That
defaults
are
applied
on
Reed.
So
anybody
who
reads
an
object
at
time,
X
and
then
reads
it
later
at
time.
Y
might
get
different
results,
even
though
the
underlying
object
has
not
been
written
to
at
all,
and
this
causes
pain
for
some
controllers
that
do
things
like
hash
the
results
of
those
Reed
and
use
that
as
a
change
detector
to
trigger
things
like
deployment,
rollouts
and
so
in
the
very
short
term.
B
B
C
B
It
has
some
pretty
broad
implications
and,
as
I
started,
writing
through
the
through
the
dock,
I
realized
it
was
pretty
huge
in
scope,
and
so
the
discussion
led
to
you
know.
Maybe
we
should
just
fix
those
controllers
and
then
how
should
we
fix
those
controllers?
So
we
have
sort
of
talked
about
generation
and
generation
is
great
if
you're
covering
the
whole
spec.
In
this
case,
we
don't
really
want
to
cover
the
whole
speck
of
er.
The
template
of
a
deployment
conveniently
template
has
a
generation
embedded
into
it
because
it
has
metadata
embedded
into
it.
B
A
Well,
I
think
in
this
meeting
we
have
a
lot
of
stuff,
flaking
and
I.
Guess
that's
David
saying
this
is
more
attention
to
detail,
so
I
mean
I
think
for
our
purposes.
Unless
somebody
has
specific
concerns,
we
should
just
link
to
it
and
understand
that
we're
making
progress,
I'm
I'm,
resolving
the
issue
yep.
B
C
I'd
say
that
covers
my
update,
also:
okay,
yeah,
if
you,
if
you
read
the,
if
you
read,
we
did
talk
about
it
a
little
bit
in
API
machinery,
but
as
mostly
we
got
the
conversation
started
I
like
fixing
our
document.
This
is
a
huge
task
and
I
don't
know
if
anybody
has
the
bandwidth
just
to
sign
up
to
own
that
right
now,
so.
B
That's
I
think
that's
a
separate
issue,
so
I
watched
the
the
10
minutes
or
so
of
the
reporting,
and
there
was
clearly
two
issues.
One
is
our
Docs
are
our
week
here.
The
other
is
what
we
do
about
this
case,
I
think
about
this
case
and
and
whether
we
need
a
gym
or
general
solution
or
not
and
I'm
willing
to
help
with
those
Doc's
in
fact,
I'm
sort
of
eager
to
it.
B
Having
read
through
it
and
started
to
edit
it
I
would
be
eager
to
put
together
sort
of
an
info
architecture
outline
of
what
we
want
the
docs
to
look
like
and
then
start
pasting
and
there's
a
lot
of
good
content
there.
It's
just
poorly
organized
and
so
building
that
content
back
into
a
new
structure.
I
would
very
be
very
eager
to
help
with
emphasis
on
help
with
not
do
completely.
On
my
own.
C
B
I
think
it's
good
and
I'm
actually
happy
with
the
direction
of
it,
because
I
didn't
really
want
to
do
this
change
anyway,
but
it's
not
conclusive.
We
haven't
reached
a
full
conclusion,
yet
I
think
notably
absent
from
that
conversation.
Are
the
people
who
own
the
controllers
that
are
doing
the
hashing.
C
B
C
B
So
I
some
point
again:
I
don't
want
to
tread
into
too
much
API
machinery
here
at
some
point,
I
tried
to
for
anybody
for
context.
The
defaulting
system
is
type
aware,
so
it
looks
for
any
type
that
has
a
pod
spec
and
applies
defaults
to
that
and
and
for
every
other
type
that
has
defaults
registered,
which
is
really
clever
because
you
get
it
everywhere,
and
it's
really
not
clever
because
you
get
it
everywhere.
So
we.
D
D
So
the
controller's
already
have
the
ability
and
most
of
the
defaults
we
apply.
We
apply
directly
to
pod
uses
inside
pod.
The
cubelet
is
the
one
where
we
have
problems
with
an
API
server
upgrade
can
make
all
your
containers
restart
across
all
Cubans
that's.
So
there
are
two
categories
of
problems:
the
split
type
defaulting.
We
already
have
a
little
bit
of
a
ability
to
target,
so
we
could
make
some
progress
there
without
radically
changing
the
way
we
structure,
our
API
objects.
D
D
C
B
D
Be
quick,
I
put
some
thoughts
around
the
pluralization
stuff,
it
intersected
with
Tim's
PR
and
then
I
got
distracted
by
that.
So
I
just
put
the
thoughts
that
I
had
up
in
a
work-in-progress
thing,
mostly
what
I'm
interested
in
there
is
making
the
current
guidance
less
confusing
and
making
sure
we
call
up
test
scenarios
that
you
should
think
about
and
write
that
would
have
caught
the
problems
that
we
ran
into
where
we
blew
at
this
in
the
past.
The
second
thing
the
flowcharts
I,
had
not
started
on
Christmas.
C
Last
week,
I
kind
of
wonder
if
we
want
like
a
shared
working
group
or
sub
project,
or
something
between
API
machinery
and
Sagarika
texture,
to
talk
about
this
because
I
think
it's
a
holistic
like
says
it's
a
problem
that
we
need
to
think
about.
The
whole
problem
like
fertilization,
especially
some
of
the
recommendations
that
how
to
actually
do
it.
Overlaps
with
Union,
in
my
mind,
at
least
and
I,
think
we
want
to
make
sure
that
that
we
have
the
same,
probably
solve
it
in
similar
ways,
possibly
with
key
mechanisms.
C
A
C
A
C
A
Okay,
well
maybe
Daniel.
You
could
just
write
in
the
agenda
right.
There
put
a
few
bullet
points
of
like
we
hear
the
ear.
That
will
be
the
main
goals
of
this
group.
I
mean
right
unless
what
you
and
David
just
said
and
anything
else
that
it
pops
in
mind
and
then
at
least
gets
it.
I
don't
have
to
copy
down,
and
while
we're
talking,
okay.
A
Since
we're
talking
to
you,
so
you
said
that
Tim's
mostly
covered
yours,
but
you
you
were
talking
about
immutability
and
the
thing
we
wanted
to
the
the
AI
for
you
was
to
just
kind
of
put
down
a
small
sketch
of
like
here's.
Here's
what
we
need
to
do
in
the
documentation
or
what
we
need
to
explain
better
around
immutability
not
to
actually
do
the
work,
but
just.
C
A
A
Okay,
so
sub-project
readouts.
This
will
actually
be
brief.
This
time
crowd
readiness
we
we
met
yesterday
and
we
have,
as
most
of
you
should
know,
we
ran
a
survey
a
few
weeks
ago,
a
couple
months
ago.
Maybe
now
and
we
we
got
decent
response
there.
We
got
almost
80
boxes,
it's
somewhat
self-selected
crowd,
of
course,
but
it
still
gives
us
some
signal.
A
So
we
we
went
through
a
bunch
of
questions
and
what
we
don't
have
anything
prepared
right
now
to
present,
but
I
think
that
next
time
we
come
back,
we'll
have
a
deck
that
we
can
talk
about
our
conclusions
and
interesting
things
of
note.
I,
don't
know
David.
If
you
want
to
mention
a
few
of
the
things
we
noticed
yesterday,
I
will.
E
Say
that
one
of
the
things
we
noticed
was
that
people
have
gotten
very
used
to
depending
on
beta
features
and
that
one
likely
outcome
is
resurrecting
the
no
perma
beta
cap
and
finding
an
enumerated
all
that
remain
notifying
them
and
then
saying
if
we
can
go
ahead,
push
that
through
demerged.
The
vast
majority
of
clusters
were
relying
on
beta
features
very.
A
Very
small
percentage
of
respondents,
this
allowed
beta
features
in
production
and
a
very
small
number
of
the
disabled,
specific
beta
features
for
any
any
reason.
The
other
thing
that
was
shocking
and
a
little
bit
scary
was
that
a
very
large
number
of
people
enabled
alpha
features
in
production
clusters,
which
was
a
little
worrisome,
but
real
bit
we'll
go
more
details
on
that
one.
We
actually
have
a
something
a
little
bit
cleaner
to
present
right
now.
It's
it's
more
ideas
and
raw
data
on
conformance
hippies,
not
here
today,
I'll
just
say
quickly.
D
F
Fiber
one
so
I
wanted
to
bring
up
a
cap
that
was
sent
out
to
the
clique
architecture
mailing
list.
This
is
the
cap
on
third
party
content
and
documentation,
I'm
hoping
sig,
Docs
kind
of
move
move
this
one
forward
initially
arose
out
of
you
know:
sick
dogs
had
a
policy
existing
internally
around
dual
source
content,
but
in
particular,
there's
been.
F
You
know,
changes
where
commercial
vendors
want
to
PR
changes
into
Doc's
that
feel
more
like
a
vendor
pitch
than
something
that
is
specifically
focused
on
on
the
open
source
upstream
documentation,
since
they
got
kind
of
created
this
tap
to
have
a
written
down
formal
policy
that
kind
of
encodes
okay.
These
are
the
things
that
we're
going
to
look
for
when
we're
dealing
with
documentation
so
that
we
can
have
a
consistent
policy
across
everything
that
they
publish
around.
What
is
okay
for
to
go
into
docs
on
the
official
cooperate
on
a
website
and
what
is
not?
F
What
feels
too
much
like
a
vendor
pitch?
It's
been
reviewed
by
a
number
of
folks
from
sigdoc
and
from
around
the
community.
I
know,
since
the
call
went
out
to
Sagarika
tech,
chure
I
know
Hakan
without
a
chance
to
review
it.
I
wanted
to
bring
it
up
here
kind
of
visually
and
see
if
there's
any
other
comments
or
discussion
that
we
want
to
generate
here
or
how
big
architecture
feels
about
something
like
this.
A
Christopher
I
was
just
looking
at
that
trying
to
catch
up
on
on
the
history,
because
I
remember
this
came
up
here
a
couple
months
ago
and
and
I
think
we
asked
sick
Doc's
to
go
to
steering
and
then
I
heard
steering
said
to
go
back
to
saying
arch,
which
is
kind
of
a
difficult
place
to
put
the
docs
team
in,
but
so
it
looked
like
there
was
some
now
some
suggestion
of
not
going
through
with
this
capita
there's
just
another
change.
That's
it's
more
limited
in
scope.
Can
you
can
you
explain
the
difference
there.
A
Well,
I
mean
it
so
there
was
a
there
was
a
PR.
Oh,
is
this
the
one?
They
were
truth?
There's
the
cap
and
there's
the
PR
around
and
it
looked
like.
There
was
a
request
that
this
is
the
cap.
But
then
there
was
another
PR
down
here
and,
like
I
said,
I
still
need
to
spend
a
little
time
with
this
to
catch
up
completely,
but
there
was
another
PR
suggesting
this
one
be
withdrawn.
So
where
are
we
this
time
out
for
tomorrow?
I
think
there
was
a
suggestion,
or
today.
F
Discussion
that
kind
of
spurred
out
of
that
was
a
and
something
that
said
you
know
I'm.
Definitely
looking
at.
As
with
my
steering
committee
member
had
on,
is
the
there
there's
a
lack
of
clarity
around
some
of
the
stop
in
the
cap
process,
including
like
the
oh?
No,
you
should
go
talk
to
steering,
oh
no,
you
should
go
talk
to
say
GARCH,
oh
no
is
no!
It's
all
in
your
place
like
dusk,
and
you
just
make
all
the
decisions.
F
There's
some
like
unclarity
about
that
and
that's
why
I'm
trying
to
step
in
and
help
help
Shepherd
this
one
through
okay,
there's
so
there's
the
two
pieces
here
is:
the
cap
is
more
stating
like
what
the
goals
of
the
policy
are
and
what
the
problem
is
that
we're
trying
to
solve
the
implementation
of
the
cap.
So,
comparing
to
like
you
know
something
in
Cabrera,
Scoob
readies,
where
you
have
like
the
goals
and
the
design,
and
then
you
have
the
actual
implementation
that
happens
in
code.
F
F
It
basically
provides
us
with
a
design
document
to
go
back
to
in
the
discussions
around
us
sure
that,
if
there's
future
challenges
that
their
future
changes
that
we
want
to
make
to
this
policy,
we
have
that
history
encoded
in
a
caste,
even
though
this
isn't
necessarily
going
to
be
implemented.
In
code,
so
I
I'm
definitely
a
supporter
of
let's
do
this
in
a
cap.
Let's
get
the
cap
reviewed
and
sign
off
and
go
through
that
process,
even
though
it
doesn't
it's
more
complicated
to
go
through
that
process.
D
F
A
Okay,
so
current
status
is
that
the
what
we
need
to
pass
this
cutoff
but
I,
think
has
it
gotten?
I
I
haven't
had
a
chance
to
fully
catch
up
on
it.
So
I
would
like
to
do
that,
but
I
guess
it
looks
like
it's
gotten
comments
from
a
number
of
other
folks
at
least.
Is
there
anything?
Your
goal
here
is
to
bring
to
the
attention
of
this
everybody
in
the
sake
here
and
get
a
little
more
feedback
before
we
go
forward
with
it?
Is
that
what
you
think.
F
So
at
this
point
like
it's,
definitely
been
through
a
number
of
rounds
with
feedback
and
we're
trying
to
yeah
see
if
there's
anything
from
this
group,
that
this
group
finds
like
objectionable,
that
we
need
to
like
slow
the
process
back
down
or
there's
problems
with
the
cap
that
we
need
to
revisit.
At
this
point,
a
lot
of
it's
been
hammered
out.
A
lot
of
it's
been
bite
shedded.
D
My
reading
of
this
was
as
long
as
the
owners
of
the
existing
content
that
would
be
affected
are
aware
and
have
a
roadmap
and
don't
object
to
this,
and
this
doesn't
provoke
lots
of
trying
to
get
projects
into
the
kubernetes
project
just
so
they
could
include
their
Docs
then,
and
the
current
version
addresses
both
of
those.
Then
I
I
have
no
objections.
I
think
it
is.
B
I'll
reread
it,
my
main
objection
was
that
it's
way
more
nuanced
than
what
it
was
proposed
by
when
I
read
it
a
couple
days
ago.
Right,
we
don't
really
know
what,
in
the
project
mean.
This
is
like.
Is
that
other
CN
CF
projects
are
they
allowed
to
advertise
there?
How
about
other
open
source
projects
that
fill
gaps,
that
commodities
doesn't
implement
like
network?
B
A
F
That
would
be
definitely
ideal,
like
yeah.
Being
able
to
kind
of
sign
off
and
move
forward
with.
This
is
is
the
place
that
we're
at
with
a
number
of
folks
that
have
reviewed
it,
I
think
it's
in
a
very
good
place.
So
definitely
if
you
haven't
reviewed
in
a
while,
so
you
do
and
yeah
anybody
that
wants
to
kind
of
like
sign
up
for
that.
Reviewer
I
know
myself,
Derek,
Carr
and
him
have
all
signed
on
to
that
already.
F
H
H
We
called
for
a
review
again
last
week
so
that
coming
to
this
as
well
I'm
going
to
start
to
read
the
cap,
that's
where
the
proposal
to
let's
just
close
it
implement
all
of
the
feedback
that
we've
gotten
in
consensus
from
the
community
so
far
and
call
it
a
day
came
from.
We
went
to
steering
committee
a
week
ago
a
steering
committee
Shrugged,
so
my
my
hope
is
that
this
process
will
wrap
up
quickly
and
decisively
and
coming
to
this
with
fresh
eyes.
Five
months
in
is
less
than
ideal
to.
C
Be
clear,
I
wasn't
volunteering
to
like
jump
on
and
add
a
bunch
of
comments.
I
was
trying
to
figure
out
what
what
what
you're
looking
for
and
I
think
you've
made
it
clear
that
you're
looking
for
a
list
of
people
where,
if
all
these
people
say
yes
and
then
you're
good
and
these
people
have
time
to
read
it
and
say
yes,
that
close
to
what
you're.
Looking
for
yes,
this!
Thank
you,
okay,
what
fix
do
you
believe
need
to
say?
Yes,.
G
Yeah,
that
was
my
understanding
as
well
Kristoff,
so,
like
I'm
I
had
reviewed
it
over
the
weekend.
I
thought
the
attempt
here
to
define
a
policy
was
better
than
the
absence
of
the
policy,
so
this
felt
like
an
improvement
and
I
know.
Jordan
had
reviewed
it
as
well,
so
I
come
I'm
happy
to
help
Shepherd
that
with
DIMMs
or
Jordan
or
myself,
but
seems
like
at
least
two
folks
here
in
say:
guards
were
okay
with
it.
A
B
G
D
Like
I
said,
the
the
feedback
from
my
side
was
addressed,
so
I'm
happy
with
it
and
the
owners
of
existing
content
that
would
be
affected
by
this
also
weighed
in
and
their
concerns
were
addressed.
So
those
two
things
were
the
main
things
I
wanted
to
see
out
of
this
and
I
feel
like
that
was
accomplishment
so
I'm,
happy.
Okay,.
A
A
Basically,
where
do
we
want
to
start
with
this?
This
is
a
cap
that
that
has
been
lingering
for
some
time
a
couple
of
years
it's
been
under
implementation
and
was
just
pushed
out
of
118,
and
so
you
know
this
was
a
very
bad
contributor
experience,
and
so
several
of
us
got
together
to
discuss
it
and
Tim
rode
up
this.
This
note,
after
our
discussion
and
I,
don't
know
Tim.
If
you
want
to
get
the
highlights
or
or
I
should
go
ahead.
B
Yeah
I
mean
I,
wrote
it
up,
but
it
was
really
the
result
of
a
lot
of
conversations.
The
long
story,
relatively
short,
is
we
had
a
contributor
who
had
an
idea,
a
feature
proposal
which
addressed
use
cases
that
several
of
us
thought
were
real,
like
I
have
people
yelling
at
me
still
today
about
not
being
able
to
do
this.
He
came
up
with
an
API
that
seemed
like
a
reasonable
compromise
and
got
approval
from
from
not
to
call
out
names
but
Derek
in
in
sig
node
and
went
through
with
his
implementation.
B
Nobody
reviewed
his
implementation
for
several
releases.
It
has
been
languishing.
He
said
to
poke
people
and
I
personally
feel
really
guilty
about
it,
because
he's
poked
me
I
did
an
API
review
and
then
it
languished
again
looking
for
code
review,
it
wasn't
important
to
anybody
and
anybody
who
could
approve
it
and
when
it
push
finally
came
to
shove.
We
realized
that
the
folks
who
are
gonna
be
stuck
holding
the
bag
for
this
sig
note
weren't,
actually
that
comfortable
with
it.
B
Like
you
know,
we
pressured
sig
node
into
approving
this
kept
when
it
maybe
wasn't
the
right
design,
and
we
should
not
do
that
for
this
contributor
it's
on,
because
we
have
a
design
that
actually
solves
real
use
cases.
We
have
a
contributor
who's,
actually
worked,
really
hard
to
get
it.
This
far
and
we're
kind
of
putting
the
brakes
on
it
and
we
don't
really
have
a
clear
metric
for
what
he
needs
to
do
to
fix
it.
A
Yeah-
and
we
don't
have
that
and
but-but-but
what
we
are
trying
to
make
better
we're
trying
to
learn
from
this.
As
part
of
that
post-mortem
is
again
some
revisions
and
suggestions
around
how
we
manage
caps
and
features
and
their
implementation,
and
so
one
thing
we're
gonna
do
is
propose
the
idea
of
any
given
cap.
That's
coming
to
the
fig,
have
a
shepherd,
and
that
shepherd
is
somebody.
A
We
would
like
to
add
in
the
idea
of
a
shepherd
for
a
cap,
and
that
shepherd
is
somebody
who
will
really
be
we're
sort
of
accountable
for
removing
that
cap
through
the
process
to
delivery
the
borrower.
For
that,
as
it's
written
in
the
comment,
is
tech
lead
for
the
city,
one
of
the
tech
leads
I'm,
not
sure
if
that's
the
right
bar,
but
we
can.
A
We
can
kind
of
debate
that,
but
it
has
to
be
somebody
with
enough
investment
and
involvement
and
credibility
in
the
sig
that
that
they
can
actually
get
it
done,
and
part
of
the
problem
is
that
in
this
case,
the
contributor.
This
was
somebody
who
was
relatively
new
to
the
community
at
the
time,
and
really
this
is
the
main
thing
he
was
doing,
which
is
great,
and
we
want
to
be
able
to
grow
people
in
that
case,
but
without
a
real
investment
from
somebody
who
is
very
closely
involved.
A
The
priorities
of
the
sig
it's
difficult
to
make
that
happen
so
anyway,
that's
one
of
the
proposals
is,
is
to
do
that
is
to
you
had
a
shepherd
to
move
it
along.
Another
thing
that
we
saw
happening
here
is
that
over
time,
our
understanding
of
the
problem
that
the
cat
was
trying
to
solve
changed,
and
so
we
don't
have
a
anything
in
our
process
right
now
around
caps
to
give
them
any
kind
of
time
out
or
re-evaluation.
A
Somebody
could
come
along
write
a
cap
they
could
get
approved
as
implementable
and
then
that
person
could
change
jobs
and
no
longer
be
involved.
In
could
be
nice
and
it
would
see
if
there
is
implementable
for
two
years
and
then
when
we
bring
it
up
when
somebody
tries
to
somebody
new
comes
along
and
says
this
is
great
I
want
this,
it's
implementable
and
starts
to
implement
it.
A
They
could
be
wasting
their
time
because
that
the
whole
the
project
could
have
moved
on
in
a
different
direction
or
or
maybe
it's
just
not
as
relevant
anymore,
for
whatever
reason
or
it
doesn't
even
work.
The
design
is
not
the
right
design
anymore.
So,
in
any
case,
when
we
get
to
not
lather
on
too
long,
the
the
idea
would
be
two
things.
A
One,
the
shepherd
and
the
second
thing
the
ability
to
reevaluate
caps,
sort
of
on
a
timeout
basis
which
we're
also
talking
about
doing,
and
it
comes
out
of
production
already
used
to
with
the
betta
features
and
even
with
moving
from
alpha
to
beta
to
GA
I.
Think
we
need
to
put
some
timeouts
on
these
things.
You
know
or
or
mechanisms
where,
if
it
doesn't
happen,
you
know
it
gets
reverted
or
it's.
At
least
there
needs
to
be
some
kind
of
exception
process
to
say:
hey.
I
One
note
here,
I
think
this
one
also
ran
into
scope,
which
is
the
scope
of
changes
to
certain
parts.
The
product
for
project
are
dramatically
higher
in
terms
of
interactions
overhead
and
we
don't
do
a
good
job
of
assessing
that
in
caps.
It's
something
that
a
skilled
person
probably
got
checked,
but
it
doesn't
show
up
in
the
caps
I'd
like
to
see
a
little
bit
more
rigor
in
the
caps
of
this
theme
probably
needs
to
make
some
rough.
I
A
And
time
investment
do
we
have
it?
We
do
I
think
there's
some
something.
Some
lip
service
paid
the
risks,
but
do
we
have
any
real
because
I
mean
part
of
the
reason
right.
You
don't
want
to
change
something
that
that
core
right
is
the
risk,
not
even
necessarily
the
time
Daniel.
You
know
something
yeah.
E
Think
opting
in
as
a
as
someone
who
yeah
I
like
this
and
I
would
Shepherd
it
through
is
at
least
a
way
to
to
for
someone
to
opt
in
and
say
yep.
This
is
important
enough
to
me.
It's
a
high
enough
priority
for
the
sig
that
I
will
help
get
this
in
not
just
if
this
appeared
in
the
product
I
wouldn't
be
upset,
which
I
think
is
the
current
more
yes,.
B
G
Is
making
me
luck
alike?
We
had
disagreements
on
this.
My
concern
is
like
even
going
back
to
the
earlier
discussion
on
production
rightness,
which
is
once
it
got
in
here
on
alpha
I
felt
like
people
would
use
this
and
I
didn't
think
it
was
when
I'm
reviewing
the
PR
I.
Think
getting
is
that
responsible,
given
what
we
see?
Yes,.
I
What
I
would
say
is
that
that
ties
into
scope
right,
it's
it's
the
design
time
and
then
it's
the
iteration
time
and
then
it's
the
brain
power
required
for
someone
to
page
back
into
large
chunks
of
the
code
into
their
mental
cache,
which
only
ever
comes
out
of
the
budget
they
have,
which
is
like
the
combination
or
so
it's
like
it,
I
think
we're
still
being
for
a
certain
subset
of
caps.
We
are
and
you're
not
correctly
scheduling
caps
into
the
available
time
realistically,
yeah.
G
G
That
that
was
what
led
me
to
thinking
like
in
a
world
where
people
are
doing
more
preemptable,
VMs
doing
more
sorts
of
things
exotic
around
cube
like
the
alpha
criteria.
We
said
this
is
not
needed
for
alpha,
but
maybe
for
beta,
like
that
meant
a
third
of
those
users
might
be
hitting
right
on
expected
outcomes.
We're.
B
Trying
to
bias
towards
action
and
trying
to
unblock
people,
but
we've
reached
a
point,
at
least
for
some
of
these
subsystems,
where
that's
really
the
wrong
to
do
and
I
think.
In
this
case
we
were
trying
to
say
well.
This
seems
like
a
good
enough
use
case
that
are
good
enough
solution
for
the
use
cases,
and
it's
got
some
corner
cases
and
we
can
live
with
that
and
I
think.
Actually
you
weren't
ready
to
live
with
that
and
I
was
not
the
one
who's
gonna
have
to
live
with
it,
so
that
was
really
wasn't.
C
Wanting
a
Sig
TL
to
champion
like
we
actively
support
and
drive
caps
and
not
to
sign
off
and
be
like
yeah
I'd,
be
okay
with
that
I
think
that's
better
than
our
current
state.
But
we
should
be
honest
with
ourselves
about
how
many
fewer
caps
were
gonna
put
through
under
that
model,
because
there's
only
so
many
sig
tiel's,
and
we
only
have
so
much
time
during
the
day
right.
A
B
Yeah
I
would
have
been
happy
if
there
was
like,
let's
rewind
the
clock
to
the
beginning
of
this
proposal,
and
we
should
have
said
boys
signaled
people
coming
at
you
from
the
sig
network
side.
This
is
a
real
problem
for
some
sig
net
worth
users.
It's
really
important
to
us
that
we
find
a
solution
here.
You
know.
Is
there
somebody
that
you
can
delegate
to
within
sig
node
who
is
willing
to
Shepherd
this
all
the
way
through?
C
I
E
B
So
to
this
particular
cap,
like
the
use
case,
still
exists
and
I
still
have
people
who,
literally
this
morning,
we're
asking
me
what's
going
to
happen
with
this.
Now
that
you've
completely
crapped
on
it
and
I,
don't
have
a
really
good
answer
for
them.
You
know
we
don't
need
to
do
it
here,
but
I
would
like
to
go
back
to
you
Derek
and
the
rest
of
sig
note
and
say:
like
do
you
agree
with
the
use
cases,
and
do
you
have
somebody
that
you
can.
B
G
Introducing
sequencing
among
containers
and
a
pods
lifecycle
needs
to
be
solidified
for
just
the
item.
I
called
out
on
alpha,
which
is
I
power
down
a
host
right,
I
I,
very
much
feel
the
the
worry
that,
like
like.
If
I
read
an
article
about
an
f-16
running
three
kubernetes
clusters,
I,
don't
know
if
that
has
an
alpha
feature
on
or
not
right
and
I,
don't
know
them
the
outcome
of
what
happens
and
so
like
something
as
basic
as
powering
out
a
computer.
I
don't
want
to
surprise
something
yeah.
G
We
said
I
volunteered
to
say
we
will
make
the
power-down
case.
Work
correctly
for
existing
pod
particularly
run
graceful
termination,
but
like
I,
would
revisit
this
and
say
this
cap
is
way
more
comfortable
to
me.
If
I
know
an
alpha,
we
are
not
already
excluding
problems
that
were
brought
up
in
the
initial
kept
review,
so.
B
E
A
I
I
had
an
additional
comment
that
I
wanted
to
add
just
in
general,
so
I
noticed
as
I
was
kind
of
digging
through
some
problem,
debugging
that
there's
a
lot
of
areas
of
the
project
that
seemed
to
be
loosely
covered
under
both
people
actively
spending
time
on
it
or
ownership,
is
kind
of
people
are
pulled
in
a
lot
of
directions.
I
think
maybe
it's
a
queue
up
topic
for
next
time,
but
some
of
the
areas
the
project
feel
a
little
haunted
forest
at
haunted.
I
Forest
is
a
strong
and
unfortunate
word,
but
there's
areas
that
I
think
the
knowledge
in
people's
brains
has
decayed,
and
so
as
I
was
really
ERISA
myself.
With
some
parts
of
the
code,
I
was
kind
of
asking.
I
saw
a
lot
of
things
where
I
was
like.
Oh
that's
not
right,
that's
not
right!
That's
not
right!
That's
not
right,
which
got
me
thinking!
You
know.
I
I
Some
of
that
through
caps,
but
like
in
the
example
here,
I've
been
deep
in
the
cubit
for
a
couple
weeks
now
and
I
just
keep
finding
things
and
there's
lots
of
people
who
have
the
domain
expertise,
but
they're
all
told
in
a
lot
of
directions
and
I
found
enough
stuff
that
was
fairly
low-hanging
but
required.
A
fair
amount
of
skill
to
ask
you
know
is
the
balance
of
where
we're
forcing
maintainer
x'
to
where
maintainer
x'
are
spending
their
time.
Is
there
some
things
we
can
send
of
eyes?
I
A
I
Have
enough
I
found
something
that
I
was
like?
This
is
horrible.
We
should
not
be
doing
this
and
the
person
who
added
it
was
me
five
years
ago,
and
that
was
one
of
those
like.
Oh
that's,
not
good.
Just
there's
bits
of
the
code
that
are
pretty
old
that
there's
bits
of
the
code
that
are
very
new
I
was
you.
It
was
useful
in
this
context.
I
For
me,
it
got
me
thinking
about
the
bringing
a
lot
of
how
the
system
is
supposed
to
work
and
how
the
system
is
actually
working
into
view
at
the
same
time,
and
it
was
very
useful
least
in
terms
of
like.
Oh,
this
is
a
bug,
but
I
don't
know
that
any
individual
person
who
like
who
comes
in
and
looks
at
this
code,
wouldn't
necessarily
spotted
it.
What
we
do
more
to
incentivize
the
sorts
of
cross-project
turning
over
the
compost
pile
occasionally,
and
so
we
can.
A
I
And
some
of
this
is
it's
actually
less
about
the
fixes,
then
making
sure
we're
putting
ourselves
back
and
so
like
it's
a
great
example
and
I
was
talking
with
us
on
signo.
It
is
like
it
sometimes
takes
up
to
20
seconds
for
a
pod
status
update
to
propagate
from
the
time
it
happens
back
to
a
user,
and
just
you
know,
that's
like
a
oh.
You
know
this
is
like
at
a
low
latency
thing.
I
It's
something
that's
sick,
scalability
could
own,
but
nobody
probably
would
have
brought
it
up
to
six
scalability
unless
somebody
had
been
looking
at
it
and
so
looking
for
opportunities
like
that,
for
what
I
would
call
casual
review
of
what
we
have
created
over
the
years
in
a
way
that
relook
sand
things
with
a
fresh
eye,
I
think
might
be
very
useful.
It's.
G
G
I
More
than
end
to
end
mindset,
maybe
that's
a
good
way
of
framing
a
derek,
is
like
what
are
our
have.
We
re-evaluated
some
of
our
end
end
goals
for
the
project
in
a
long
time,
and
that's
a
you
know:
what
can
sig
architecture
do
to
incentivize
or
suggest
or
enable
other
SIG's
to
suggest
or
support?
Well,.