►
From YouTube: 20220810 SIG Arch Prod Preadiness
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,
everybody:
this
is
the
kubernetes
sig
architecture,
production
readiness,
sub
project
meeting
for
august
10th,
2022.
A
And
so
is
my
document
visible.
A
B
C
A
Well,
so
this
is
a
sub
project
of
sig
architecture.
So
this
is
why
it's
such
a
tiny
meeting,
because
there's
just
a
few
people
that
we've
managed
to
wrangle
into
doing
this.
But
what
we
do
is
we
look
at
as
new
features
come
into
kubernetes,
so
every
every
release,
there's
new
features
that
come
in.
We
review
those
features
for
what
we
call
production
readiness.
So
basically
the
idea
is
you
take
the
viewpoint
of
a
cluster
administrator
who's,
administering
thousands
of
clusters
and
ask
okay.
A
A
How
can
I
make
sure
that
it's
not
exploding
my
clusters
in
some
way
if
it
is
exploding
my
clusters
in
some
way?
How
can
I
roll
it
back?
A
How
do
I
monitor
it
all
of
those
pieces
from
the
point
of
view
of
of
that
cluster
admin
at
a
broad
scale,
and
so
we've
as
part
of
that
we
introduced
a
questionnaire,
so
in
kubernetes,
if
you
said
you're
new,
I
don't
know
how
many
you
are
all
of
the
kubernetes
open
source
community,
but
we
have
a
process
every
release,
every
every
sig
that
wants
to
add
some
feature
to
kubernetes
goes
through
this
communities,
enhancement
proposal
process
and
there's
a
bunch
of
requirements
that
they
have
to
sort
of
document
the
design
and
the
tests
and
all
this
stuff.
A
One
of
those
sets
of
requirements
is
they
have
to
document
their
production,
readiness
and,
depending
on
the
maturity
stage
of
that
feature.
Alpha
beta
ga
there's
a
sort
of
successive
ramping
up
of
kind
of
the
level
of
production
readiness
at
the.
C
A
Stage
we
pretty
much
just
say
you
should
be
able
to
turn
it
off
and
when
you
turn
it
off,
it
should
actually
like
not
break
anything
once
it's
off
and
it
should
not
break
anything
with
you
really
well
after
you've
turned
it
off,
often
like.
If
you
turn
it
off
and
on
again
you
you
can
do
that
safely.
So
that's,
basically
all
we
require
for
alpha
and
then
later
we
ramp
up
those
requirements
around
metrics
and
things
like
that.
A
A
We
have
right
now
only
three
people
to
review
all
of
those
caps
which
is
somewhere
in
the
order
of
80
caps
every
cycle,
so
that
leaves
us
with
each
more
than
you
know,
20
or
almost
30,
depending
on
the
cycle,
and
so
we're
looking
to
recruit
new
members.
So
we'd
love
to
have
you
involved
and
if
you're
interested
in
joining
that
team,
then
as
the
next
release
cycle
spins
up,
what
you
would
do
is
sort
of
shadow
or
you
do
some.
A
You
look
at
how
how
david
or
me
or
voice
and
voice
is
going
to
be
out.
So
actually
it's
just
going
to
be
david,
this
next
cycle,
how
we
do
those
reviews-
and
you
would
then
start
to
do
some
yourself-
that
we
would
we
would
look
at
and
sort
of
you
know,
give
feedback
on
and
eventually,
when
you
reach
out
you've
done
enough
of
them
over
a
couple
of
releases,
then
you
could
join
the
team
without
you
know,
without
that
oversight,
so
that's
kind
of
the
process
for
making
that
happen.
A
If
there's
no
comments
on
that,
we
go
to
our
very
short
agenda
david.
Did
you
have
anything
else
you
wanted
to
discuss
today
other
than
what
I
put
here
on
the
agenda.
B
No,
I
was
just
going
to
remind
you
that
I
have
not
assured
you.
I
have
not
forgotten
that
I'm
gonna
go
through
the
survey
data
but,
as
I
told
you
before,
it
was
likely
gonna
be
september
and
that
timeline
is
playing
out
just
as
expected.
So.
A
Of
people
here
so
we
just
make
it
make
it
happen
as
best
we
can-
and
I
did
I
did
mention-
I'm
I'm
working
on
getting
some
other
folks
here
involved
and,
of
course
david.
If
you
have
some
other
folks
at
red
hat.
Since
I
don't
know
if
atlanta,
when
she's
coming
back,
you
know
anybody
we
get
would
be
would
be
helpful,
and
I
know
you
know
that
as
well
as
I
do
yeah.
A
Okay,
awesome,
okay,
so
here's
the
issue
that
was
raised
on
slack,
unfortunately
mine's-
not
here
so
we'll-
have
to
just
discuss.
A
He's
would
like
more
guidance
from
this
group
about
what
an
acceptable
answer
is,
and
I
don't
think
you
control
is.
I
think
that's
a
last
resort
answer.
So
if
you
I'm
not
gonna
read
his
comment
basically
he's
saying:
is
there
another
way
other
than
cube
control?
A
To
tell,
and
if
you
take
that
viewpoint
I
mentioned
earlier
of
you-
have
thousands
of
clusters
or
in
the
case
of
rsres
many
many
more
than
that,
it's
not
really
reasonable
to
run
cube
control
commands
I
mean.
A
Yeah
to
say
is
the
feature
enabled,
if
you
want
to
say
like
is
this
feature
in
use
across
my
fleet?
That's
pretty
hard
if
you
have
to
run
a
keep
control
command
against
every
single
cluster.
I
mean
that
said,
we
have
to
be
sensitive
to
metrics
explosions,
and
things
like
that.
I
I
don't
know
if
we
can
export
a
metric
around
what
feature
gates
or
if
we
do
export
a
metric
around
what
feature
gates
are
enabled
in
each
component.
B
I
don't
know
whether
we
do
I
am.
I
am
okay
with
doing
that,
because
I
believe
it
could
be
its
own
metric,
and
so
it
may
have
many
labels
with
a
bunch
of
values,
zero
or
one.
But
the
way
you
would
combine
it
with
all
the
rest
would
be
through
prompt
ql.
So
so
the
cardinality
wouldn't
be
the
size.
But
not.
B
I
am
a
little
bit
spoiled
here,
because
open
shift
pretty
tightly
controls.
What
feature
gates
are
on
and
off,
but
just
in
general
I
can
get
behind
the
idea
of
exposing
a
metric.
A
It
wouldn't
be
just
it
would
be
in
each
component
right,
it
would
be
in,
and
that
means
in
each
instance
of
each
component
so
like
that
means
you
know,
you've
got
one
per
node
for
each
cubelet
or
more
than
one
if
you've
got
other
things
running
on
the
node.
You
have
to
think
about
that.
I
mean
that's,
not
a
lot.
I
don't
know
it's
not
like
a
cross
product
or
something.
A
How
would
you
use
that
in
your
queries?
I
guess
you
could
then
check
which
nodes
have
it,
which.
B
A
B
A
B
Yeah,
well,
it
wasn't
exactly
component
status.
We
faced
the
question
of
how
can
a
client
know
which
admission
plugins
are
and
the
answer
we
chose?
Is
they
can't
and
I'm
not
ready
to
extend
this
to
what
admission
plugins
are
enabled
but
feature
gates?
I
could
see
exposing
that
for
people
who
have
access
to
metrics
versus
people
who
have
general
cluster
access
right.
A
That
should
catch
the
majority
of
features,
because
everything
almost
everything
has
a
feature
gate.
There
are
things
that
are
built
out
of
tree,
I'm
just
trying
to
brainstorm.
Think
about
like
what
do
we
miss
if
we
do
this,
there
are
things
that
are
out
of
tree
that
are
enabled
by
installing
them
on
the
cluster.
B
I
think
the
next
question
we're
likely
to
face
is
four
features
that
are
both
opt-in
for
the
feature
and
then
choose
how
to
configure
the
feature.
Are
we
going
to
do
anything
else
and.
A
A
Yeah
right
like
if
you
look
at
like
the
one
that
pops
to
mind
a
recent
one,
that
I've
reviewed
a
bunch
of
times
is
like
the
the
cpu
policy
pieces
or
things
like
we
don't
want
to
flag
on
all
those
individual
policies.
B
A
B
Or-
or
I
guess
more
specifically,
if
the
sig
sig
node
in
that
case
decided
they
needed
to
whether
or
not
they
do
how
they
do
level
granularity
will
be
up
to
them
in
sig,
instrumentation
versus
something
like
this
for
the
feature
gate.
We
would
probably
just
build
something
generic
that
had
the
metric
and
then
had
all
the
different
labels
right.
A
B
So
then
the
question
becomes
that
would
probably
be
a
kept
for
127
or
we
want
to
try
to
do
it
for
126..
I
have
limited
bandwidth
in
126.
A
I
have,
let
me
talk.
Let
me
talk
with
folks
here
and
see
if
anybody
has
an
appetite
for
it,
I
I
don't
have
the
bandwidth
at
all.
B
It's
not
it's,
not
a
big
lift,
but
I'm
just
looking
realistically
at
what
comes
in.
We
got
to
get
through
all
the
caps.
I
have
some
implementation
prs
for
api
machinery
and
off
that
are
owed
reviews.
At
least
one
missed,
missed
125
by
just
a
few
days,
so
I
want
to
make
sure
it
lands.
A
When
would
let's
see
when
would
cap
freeze
roughly
b
for
126.
B
It's
possible
that
mayank,
just
given
the
direction
would
be
willing
to
do
it
himself.
We
should
ask
him.
A
Yeah,
absolutely
absolutely
so
all
right!
Well,
I
I
think
that's
a
good
start,
and
certainly
more
discussion
will
happen
on
a
cap,
so.
A
A
Okay,
so
I
don't
have
any
other
agenda,
I'm
happy
to
wrap
it
up.
40
minutes
early
unless
somebody's
got
something
they
want
to
talk
about.
B
Nope
that
that
works
for
me.
A
Okay,
I'll
follow
up
with
mike
and
then
I'll
follow
up
with
folks
here
whether
somebody
wants
to
pick
it
up,
as
you
know
something
to
do,
I
guess
probably
out
of
city
instrumentation
or
something
I
don't
know,
corsica
architecture.
I
don't
know
where,
where
it's
going
to
come
from,
who
the
primary
on
the
cap
will
be?
Okay,
awesome
thanks
david
thanks
attorney
good
to
meet
you
and
welcome
to
the
project.