►
From YouTube: 20210922 SIG Arch Prod Readiness
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
Okay,
hello,
everybody
today
is
september
22nd
and
to
2021.
This
is
the
community's
sake.
Architecture,
production,
readiness,
subproject
meeting,
and
thank
you
all
for
coming,
so
I
think
the
other.
We
have
two
things
on
the
agenda
because
I
wanna
find
out
from
david
analysis,
but
let's
get
started
with
the
discussion
of
of
cpu
manager
policy
feature
gates.
B
Hi
so
this
was
this
was
a
new
feature
that
was
introduced
in
1.22
cpu
manager,
police
policy
options
that
that
modifies,
the
behavior
of
cpu
manager
and
we
introduced
an
option
called
pcp
only
in
the
release
in
122
release
this
release.
We
are
graduating
this
feature
to
beta
and
we
are
trying
to
evaluate
what's
the
best
way
of
handling
experimental
options
that
can
get
introduced.
So,
in
addition
to
this
feature,
there
is
a
new
policy
option
being
introduced
in
1.23
release,
which
kind
of
distributes
cpus
across
numa
nodes.
B
So
I
think
john
and
I
had
a
discussion
on
the
best
way
to
handle
it.
One
was
obviously
to
have
feature
gates
corresponding
to
each
policy
option
that
gets
introduced,
but
then
that
is
a
bit
cumbersome.
So
we
came
to
the
conclusion
that
we
can
have
a
feature
gate
that
is
basically
for
experimental
options
and
as
as
the
feature
options
as
the
options
become
more
mature,
they
graduate
from
being
under
a
feature
gate
to
being
kind
of
enabled
by
d4.
C
B
B
D
B
D
Yeah
that
well,
they
kept
suggest
that
it's
being
renamed.
So
now
we
need
to
deal
with
whatever
the
we
need
to
like
deprecate.
The
old
feature
gate,
because
I
think
that
one
existed
already.
A
Right,
it
was
already
an
alpha.
Let
me
no,
no,
let
me
clarify
so
the
the
question
here
is
we
have
a
feature
gate
that
controls,
whether
you
can
use
this
policies
at
all,
and
the
question
is
that
if
you've
got
forget
this
specific
example,
this
is
really
a
general
question
right
if
you've,
if
you've
got
10
different
policies
today,
right
when,
when
the
overall
feature
goes
to
beta,
that
feature,
gate
is
going
to
enable
and
effectively
make
beta
every
one
of
those
options.
A
How
do
we
control
access
to
that
option
and
the
the
statement
was?
Let's
create?
We
have
two
options.
We
have
two
I
wanna
use
that
word.
We
have
two
ways
we
can
do
this
at
least
two
ways
we
can
do
this
one
is,
we
can
say
for
every
new
cpu
manager
policy
option
that
we
create
we're.
Gonna,
add
a
feature
gate,
and
so
in
order
to
enable
that
option
on
some
particular
cubelet,
you
have
to
pass
in
that
feature,
gate
and
otherwise
that
option
will
get
kicked
back
as
invalid.
A
A
They
come
out
from
under
that
feature
gate
now,
because
we
have
one
feature
gate
in
this
case
for
those
options:
there's
no
alpha
beta,
stable,
there's
basic
other
than
documentation,
there's
alpha
hidden
by
a
feature
gate
and
then
there's
the
core
feature
which
is
no
longer
hidden
by
a
feature
gate
once
it
goes
stable.
So
those
options
fall
into
that.
So
so
we
theoretically
could
add.
A
You
know
another
feature
gain,
but
the
question
at
hand,
I
think,
for
this
group-
is,
what's
too
burdensome,
what's
too
cumbersome,
what's
not
safe
enough
and
that
so
I
hope
that
clarifies
kind
of
the.
D
Yeah,
it's
the
reason
that
I
sort
of
jumped
in
as
I
don't
know
that
this
is
a
pr
question
like
to
me.
This
seems
like
a
wider
sig
architecture
question
because
we're
talking
about
like
how
we
want
to
manage
future
gates
which
isn't
limited
to
prr.
I
think
in
this
particular
cl
place.
Like
I
see
the
goal
of
prr
is:
can
the
thing
be
turned
off?
Can
we
make
it
stop
like
breaking
things?
D
Basically,
I
think
if
you
don't
specify
an
experimental
feature
gate,
then
it's
not
on
and
like
as
long
as
the
there's
a
risk.
Of
course,
if
the
implementation
goes
in
and
touches
a
bunch
of
stuff,
it
shouldn't,
maybe
adding
that
alpha
feature
gate
broke
some
things
and
then
it
affects
other
things.
But,
depending
on
like
how
it's
implemented,
it
might
be
really
hard
to
stick
all
of
that
behind
a
feature.
Gate
anyways,
and
this
is
a
risk
of
any
change
in
cube.
So
I
would
see
the
scope
of
prr
as
being
limited
to.
D
Can
you
turn
it
on
or
off
and
what
are
sufficient
mechanisms
for
that,
because
there's
lots
of
things
in
kubernetes
that
can't
be
feature
gated,
like
you
know,
metric
stability
doesn't
follow
feature
gates.
There's
like
a
number
of
things
with
like
log
transition
or
like
that
kind
of
thing,
that,
like
don't
follow
like
an
alpha
beta
sort
of
process,
creating
new
apis
does
not
go
through
alpha
beta
graduated
right.
It
follows
the
api
versioning
process
so
but.
D
D
Yes,
but
in
this
case
I
think
we
have
one
api
field
that
we
can
add
new
string
values
to
so
like
I
previously
like.
I
think
I
agree,
it
makes
sense
to
have
like
a
feature
gate
per
api
field,
but
in
this
case
it's
like
a
feature
gate
per
option
in
that
c
api
field,
which
is
not
precedented
as
far
as
I'm
aware,
but
in
any
case,
like
that's
a
question
for
you
know,
api
review,
that's
not
a
pr
thing.
A
E
So,
for
me
conceptually,
it
is
actually
a
field
in
the
api.
We
can
treat
that
that,
like
that
option
as
an
enum
right
and
then
like,
we
are
adding
a
new
enum
option
field.
However,
we
call
it
whatever
the
best
name
is
here,
the
the
value
yeah
exactly,
and
so
that
is
actually
part
of
the
api
to
me.
So
it's
it's
in
a
way
like
it's,
not
a
field
per
se,
but
it's
a
thing
in
the
api.
So.
D
I
should
clarify
it's
not
merely
like
a
flag
or
something
like
that.
Like
generally,
I
guess
I
don't
know,
what's
happening
with
working
group
component
base,
but
they're
disappearing,
but
generally
we're
trying
not
to
add
new
flags
to
components.
Everything
that
exists
as
a
command
line
flag
also
needs
to
exist
in
the
configuration
api.
So
like
every
time
you
change
something,
like
you
add
a
new
app
from
the
cubelet.
That
is
an
api
change.
Now,
it's
not
like
one
that
needs
to
be
serializable
by
clients,
but
it's
still
considered
an
api
change.
D
It's
still
like,
as
far
as
the
changes
you
need
to
make
in
the
code
base,
it's
almost
identical
to
a
regular
old
api
change.
It's
just
yeah.
D
E
Yeah,
okay,
that's
exactly
which
is,
which
is
roughly
what
I
was
trying
to
say,
so
I
think
that
I
would
actually
personally
prefer
to
have
like
a
feature
gate
per
per
value.
But
but
my
question
here
is
like:
why
did
you
so
so?
What
was
the
reasoning
before
be
behind
like
having
at
this?
This
like
feature
gate
paid
per
group
of
fields
or
per
current
because,
like
adding
feature
gate
is
too
expensive?
It
doesn't
seem
to
be
right.
It's
pretty
easy
to
us.
B
Yeah
I
was
going
to
mention
that
we
have
a
feature,
a
feature
option
being
proposed
this
release.
We
have
at
least
two
more
that
we
see
coming
in
the
near
future
and
then
there
are
possible
modifications
of
cpu
manager
that
might
happen
in
the
future,
based
on,
like
some
components
like
cmk
and
the
other
components
that
exist.
B
So
I
think
that
there
are
going
to
be
a
lot
of
cpu
options
and
that's
the
reason
we
thought
that
it's
probably
best
to
have
some
sort
of
an
experimental
feature,
gate
a
feature
gate
for
all
those
kind
of
experimental
options,
because
then
it
means
that
if,
for
example,
down
the
line,
we
have
six
feature
options.
We'd
have
six
feature
gates
associated
with
that
and
then
for
each
of
those.
B
We
need
graduation
process
kind
of
updates
to
the
cap,
which
and
of
course,
removing
the
feature
gate
if
the
option
becomes
beta,
and
that
seems
like
a
lot
of
process
for
something
that
is.
C
D
So
david,
just
to
like
from
another
example
in
node,
looking
at,
for
example,
swap
like
we
have
one
feature:
gate
that
controls
the
api
field
in
the
cubelet
configuration
and
the
initial
graduation
criteria
for
like
alpha
where
we
have
these
two
options.
Part
of
the
beta
criteria
is
maybe
add
another
option,
but
then,
like
you
know
by
that
point,
you
know
it's
going
to
be
turned
on
by
default,
like
that
new
option
is
not
necessarily
going
through
another
like
deep,
like
you
know,
full
feature
flag
cycle.
D
I
I
think
the
fundamental
question
on
the
table
is
for
a
given
api
field.
Do
we
have
separate
feature
flags
for
each
possible
new
value,
and
that
to
me
is
an
api
review
question,
not
a
pr
question,
and
I
don't
know
of
anything
that
we've
done
that
for
previously
in
the.
D
C
D
Be
tested
right,
it
needs
to
go
through
the
same
process
as
everything
else
and
perhaps
like.
This
is
the
complex
thing
in
some
cases
like
so
for
something
like
swap
right
like
that
feature
kind
of
has
a
life
cycle
that
will
graduate
as
a
thing
and
then
maybe
future
down
the
road
we
would
say.
Okay,
we
want
to
add
another
field
to
that.
There's
a
question
of
whether
or
not
so
like,
certainly
there's
like
a
feature,
but
then
there's
a
question
of
like
okay,
but
is
it
an
enhancement
so
like?
D
If
a
feature
is
like
what
you
might
call
it
confined
to
a
single
sig
right
that
doesn't
necessarily
need
to
go
through
the
enhancement
process?
It's
only
if
it
touches
multiple
places
or
apis,
or
that
kind
of
thing
where
it
might
cause
breaking
changes
that
normally
would
go
through
the
enhancement
process.
So,
like
there's
plenty
of
examples
of
things.
A
That
we
wouldn't
go
through
enhancements,
cpu
manager,
policy,
you're
gonna
need
that's
gonna
like
if
it's
gonna,
it's
gonna
need
like
david
saying,
graduation
criteria,
it's
gonna
need
some
of
that.
That
process,
my
my
so
I
was
thinking
more
from
the
user
point
of
view
in
managing
and
tracking
like
okay,
I
want
I'm
already.
I
already
don't
get
this
feature
unless
I
actually,
you
know,
choose
the
option
in
my
flag.
So
so
it's
not
like
you
can't
turn
it
off
in
the
sense
of
the
the
user.
A
Here
is
not
just
your
annual
user
coming
in
right.
This
is
the
admin
who's
setting
cubelet
flags,
so
how
much
protection
do
they
need
when
you're
talking
about
setting
they're
already
already
not
going
to
be
using
the
option
if
the
option's
broken,
you
can
already
turn
it
off
so
fruit
by
just
not
using
it
and
as
the
cluster
operator,
I'm
the
only
one
touching
my
cubelet
parameter.
I
don't
know
about
you
guys,
but
I
don't
let
users
do
that
so
to
me
it
it's
sort
of
like
okay.
So
now
I
have
to
go.
A
A
So
I
just
don't
see
the
point
in
it
other
than
causing
there's
two
two
ways
to
cause
confusion.
One
is
by
not
doing
the
way
doing
things
the
way
everybody
else
does
them.
That's
the
confusion,
I'm
picking
over
the
confusion
of
of
the
proliferation
of
feature
gates.
I
don't
know
what's
the
better
choice,
but
this
is
this
is
this
is
my
thinking.
D
As
an
admin,
I
would
say,
having
a
feature
gate
for
every
option
would
be
a
giant
pain
in
the
butt.
I
would
also
say
like
again:
prr's
job
is
to
determine
is
the
thing
working
properly
and
can
I
turn
it
off?
D
Don't
specify
it
thing
is
now
turned
off
like
this
is
not
a
thing
that
we
can
really
turn
off
or
on
at
runtime,
because
it's
part
of
the
cubelet
config.
It's
not
intended
for
that.
Like
restart
the
cubelet,
don't
pass
that
config
if
you
think
that
it's
broken
because
it's
limited
to
the
node
and
it
doesn't
have
like
the
ability
to
like
take
out
the
whole
cluster
or
something
to
me,
that's
acceptable
from
a
pr
point
of
view.
C
You
only
have
to
specify
two
feature
gates
or
a
feature
gate
and
a
flag.
If
you
wish
to
use
something,
while
still
in
alpha,
you
don't
have
to
specify
both
once
it
goes
to
beta.
I
find
the
solution
to
be
fairly
clever.
I
just
I
really
am
unclear
on
on
how
you
would
choose
to
graduate
a
new
option
from
beta
to
ga
without
having
criteria.
I
don't
I
don't
understand
that.
A
There
would
be
criteria,
I'm
not
sure
david,
like
nobody
suggests.
I
don't
think
anybody's
suggesting
there'd
be
no
criteria.
Our
all
we're
talking
about
here
is
this
mechanism
for
how
we
control
access
to
that
and
and
and
to
your
point,
how
we
make
it
explicit
when
a
club,
when
someone
wants
to
use
this
option,
they
explicitly
have
to
sort
of
state.
I
know
this
option
might
be
sorry
for
my
language,
but
I'm
going
to
put
this
feature
flag
on
here.
I
know
it
might
not
work
because
you're
telling
me
without
this
feature
feature
gate.
A
E
So
I
think,
different
time,
graduation
criteria
yeah.
So
I
think
that
at
least
how
I
partially
interpreted
david's
comments
is
that,
given
that
we
need
that
process
anyway
for
graduation
criteria
and
stuff,
like
that,
having
been
forced
to.
E
Graduate
the
feature
gate
itself-
it's
not
doesn't
seem
to
be
a
significant
overhead
for
that.
So
I
think
that
basically
referring
to
swati's
comments
is
that,
like
we
we
we
have.
We
need
to
have
this
process
anyway,
and
we
will
have
it
because
we
need
graduation
criteria
and
all
that
stuff,
so
it
will.
E
It
should
probably
be
going
over
some
over
a
cap
or
something
like
that.
Maybe
a
common
cap,
but
still
something
so
having
this
additional
feature.
Gate
doesn't
add
much
work.
In
my
opinion,
I
think
there
is
a
question
like
that
that
elana
said
that,
from
the
operator's
perspective,
operating
on
or
using
having
a
bunch
of
feature
gates
is
potentially
painful.
E
I
think
the
the
counter
example
here
is
like
let's
say
that
we
have
a
bunch
of
those
in
in
beta
already,
but
as
as
an
admin,
I
actually
want
to
disable
some
of
them,
because
I
I
want
to
wait
for
x,
y
and
z
until
they
ga,
because
I.
A
B
I
have
an
answer
for
like
for
in
order
to
disable
a
particular
option,
even
if
the
feature
gate
is
enabled,
if
you
don't
specify
the
option
in
the
list,
you
don't
you
don't
use
the
option.
So
it's
fairly
simple,
but
essentially
having
the
feature
gate
enable
gives
you
the
accessibility
to
that
option,
whereas
if
you
were
to
use
that
particular
option
without
feature
gate
enabled
you
wouldn't
be
able
to
access
it.
B
D
A
list
right,
so
I
guess
one
thing
that
I
would
be
that
I
am
a
little
bit
concerned
about
given
just
sort
of
the
discussion
is
we're
talking
about
like
okay,
you
might
have
10
experimental
options
in
the
future.
How
are
we
testing
the
matrix
of
all
of
those
being
on
or
off
like
that?
D
That
to
me
potentially
brings
in
problems
because
okay,
we've
got
like
10
options
and
if
I
specify
nine
secretly
there's
a
broken
code
path,
if
I
don't
have
the
tenth
one
like,
how
are
we
dealing
with
that
test
spread
in
turn
like
that?
That
becomes
a
little
bit
more
of
an
implementation
details
thing,
but
I
am
a
little
bit
concerned
if,
like
the
goal,
long
term
is
like
okay,
we
could
have
like
15
or
20
of
these
options,
and
that's
why
we
don't
want
to
have
a
teacher
flag
for
each
one.
D
Well,
then,
how
are
we
dealing
with
a
combinatorial
overhead
of
complexity
in
testing
of
like
okay?
Well,
we
have
15
features.
We
have
to
test
every
single
possible
combination
of
each
one
being
on
off.
Initially,
I
thought
well,
it's
you
know,
there's
like
10
different
features,
but
you
can
only
use
one
at
a
time
in
which
case
whatever,
but
if
it's
like
you
could
have
anything,
then
I
think
that
starts
to
go
down
a
path
of
like.
B
Want
that
is
a
good
point,
I'm
not
entirely
sure.
If,
like
I
think
at
this
point
in
time,
you
could
specify
multiple
of
those.
But
maybe
a
way
for
us
to
handle
is
that
we
kind
of
restrict
a
few,
which
it
may
be
some
of
the
options.
It
doesn't
make
sense
to
use
them
together
and
we
need
to
kind
of
handle
that
with
the
implementation
documentation,
because
the
like,
you
said
the
test
overhead
is
going
to
be
massive,
because
some
options
are
probably
not
going
to
make
sense
with
the
others
and.
D
Validation
and
like
a
okay,
we
say
that
you
can
and
cannot
turn
these
things
off.
But
if
the
issue
is
okay,
we
have
like
15
things,
then,
from
a
like
pr
perspective,
a
thing
that
we
do
need
to
check
is:
can
we
turn
each
and
every
one
off
independently
of
each
other,
and
then
we
have
a
really
big
test
matrix.
So
that's.
I
don't
know
that
that
came
up
in
prr
review
previously,
but
that
is
like.
I
initially
thought.
Okay.
D
Well,
we've
got
all
these
options,
but
you
can
only
use
one
at
a
time
in
which
case
okay,
sure
it's
kind
of
moot.
I
didn't
realize
it
was
a
list.
If
it's
a
list,
then
I
think
that
that's
something
that
we
missed
and
that
that's
something
that
we
need
to
consider-
and
I
don't
know
if
having
a
feature
gate
for
each
option.
There
makes
that
better
or
worse.
B
But
don't
you
think
like
as
the
options
get
introduced?
This
is
a
question
that
we
handle
at
that
point
because,
like
it
depends
on
the
option
itself
like
does
it
make
sense
to
use
that
option
exclusive
of
the
already
existing
options,
or
does
it
make
sense
to
use
them
in,
in
addition
to
the
ones
that
exist,
so
it
boils
down
to
like
as
we
as
we
go
on
and
more
and
more
options
get
introduced,
and
we
tackle
that
at
that
time.
D
Oh
yeah,
I
think
that
that
makes
sense.
I
don't
know
what
the
exhaustive
list
of
options
is
right.
Now,
though,.
B
Yeah
at
this
point
in
time,
I
think
we
just
have
two.
We
have
a
piece,
the
full
pc
cpu
only
and
there's
another
one
that
kevin
is
introducing.
So
those
are
the
two
that
we're
going
to
have.
So
what
we're
proposing
that
in
123,
we
have
the
feature
as
well
as
the
full
pcp
only
option
enabled
by
default
and
thus
graduating
it
to
beta
and
the
other
one
is
going
to
be
behind
the
experimental
options
and
that's
essentially
what
we're
discussing
at
the
moment.
C
Are
you
planning
on
having
it
sounds
like
this
particular
feature?
Gate
will
never
graduate
from
alpha
beta.
Its
point
is
to
be
alpha.
Are
you
planning
on
having
a
separate
one
for
beta
as
well
to
be
clear,
I'm
not
strictly
against
this.
I
do
think
it
might
make
sense
to
bring
up
in
a
more
general
sig
arch
call,
but
I
think
it
might
think
of
myself.
As
like
a
cluster
admin.
I
wanna.
C
A
So
that
that
was
an
open
question,
that's
something
we
could
potentially
do
as
we
need
to
do
that
so
right
now
that
wasn't
the
need,
it
would
have
been
an
empty
future
gate
that
did
nothing
in
theory.
We
could
add
one
for
that
purpose,
but
if
this
is
the
wrong
approach
entirely,
obviously
we
won't
so
okay,
I
guess
you
have
to
go
david
and
it
sounds
like
the
consensus
is
that
this
is
not
the
right
group
to
talk
about
this
sweaty.
A
A
Get
my
thoughts
on
it
as
well
and
and
then
we
can
talk
about
it
in
cigar
or
api
review
meeting
or
somewhere.
That
would
be
the
other
question
is:
do
we
need
everybody
cigar?
We
want
to
do
it
an
api
review
meeting.
I
don't.
C
Similar
discussion
would
have
happened,
so
I
don't
feel
like
this
was
a
waste
because
it
lets
you
write
that
email
and
say
people
who
are
interested
have
said
these
things.
B
I'll
I'll
draft
an
email
and
send
it
to
sig
architecture,
and
then
we
can
make
the
discussion
from
there.
Thank
you
so
much
for
your
time.
A
Yeah,
thank
you.
Okay,
so
david,
you
said
you
have
to
drop.
C
But
I
will
give
you
the
one
minute
update,
so
I
have
gotten
you
got
the
the
bigquery
data
set
created.
I've
gotten
the
data
imported
into
our
data
set
I've
gotten
it
manipulated.
So
it's
in
the
reportable
format.
A
C
A
A
Watch
all
right
thanks
thanks
david,
we'll
see
you
later.
I
think
that's,
actually
everything
on
our
agenda
did
anybody
else
have
anything
they
wanted
to
bring
up
or
we
can
get
half
an
hour
of
our
lives
back.