►
From YouTube: 20230208 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
All
right,
hello,
everybody
today
is
February
8th
2023.
This
is
kubernetes
Sig
architecture,
production,
Readiness,
subpractic
Meeting.
So
let's
yeah,
let's
get
started.
So
let
me
display
the
screen
we're
one
day
from
sorry.
One
second,
tomorrow
is
get
freeze,
I
have
on
my
list
about
10
or
ish,
so
left,
all
of
which
I've
looked
at
and
a
number
of
which
are
reading
sick
approval.
I
need
to
I
need
to
pull
myself
off
of
I,
don't
need
to
be
rude
in
enhancements
and
then
I
will
make
my
life
easier.
A
A
This
is
you
know,
cap
that
is
that
is
about
server-side
apply
in
Cube
control,
which
today
is
you
know
the
default.
Behavior
is
client-side,
apply
and
clients
might
apply
and
there's
a
there's,
a
separate,
there's
a
separate
cap
around
what
we
call.
What
what
we're
calling
the
team
is
calling
apply
set.
That
goes
in
a
great
deal
about
how
broken
a
client
sign
apply
is
wonderfully
so
it
makes
total
sense
to
try
to
move
off
of
it
and
right
now
nobody's
limited
Limited.
A
It's
happened
to
a
limited
extent,
even
though
server
side
applies
been
GA
for
a
number
of
Cycles,
because
the
defaulting
Cube
control
is
still
client-side
apply.
So
this
cap
and
anybody
from
cxcli
who
wants
to
chime
in
and
correct
me
or
elaborate.
Please
do,
but
this
tap
is
saying:
hey,
let's
change
the
behavior
of
queue
control
so
that
by
default
it
uses
server
side
apply,
which
sounds
great
it
actually.
By
default
it
uses
an
auto
mode
where
it
sort
of
tries
to
figure
out
whether
things
were
previously
applied
with
client-side
apply.
A
If
so,
use
client-side
apply.
If
not
you
server
sign,
apply,
I.
Think
that's
great.
In
principle,
my
concern
is
and
I
I
stayed
here
in
the
in
the
issue,
and
the
comment
is
this:
is
a
pretty
dramatic
change
from
the
point
of
view
of
customers,
tooling
or
users
tooling,
so
people
who
are,
who
built
a
bunch
of
tooling
that
caused
Cube
control
directly,
currently
don't
specify
the
server-side
apply
flag
to
true
or
false,
most
of
the
time
and
so
they're
getting
client-side
apply.
A
So
all
of
a
sudden,
it's
going
to
shift
by
default,
a
ton
of
behavior,
so
I
was
concerned
about
that
I.
On
the
one
hand,
I'm
I'm
sympathetic
to
the
idea
that
we
need
to
be
able
to
make
progress
and
change
default
Behavior,
but
I
wanted
to
bring
this
to
the
broader
production,
Readiness
group
and
maybe
to
see
architecture
tomorrow
to
get
I
think
this
needs
visibility
project
wide
before
we
would
make
such
a
dramatic
change
too
default,
behavior
and
I'm
curious.
What
other
people's
thoughts
are?
I
see
Katrina.
B
Yeah
I
just
wanted
to
point
out
that
Antoine
isn't
here
and
he's
the
one
who's
leading
this
cup,
but
we,
we
did
have
a
pretty
lengthy
discussion
at
the
Sig
CLI
meeting
this
morning
about
this
one
and
I
think
we
concluded
that
we
can't
really
do
anything
huge
in
time
for
this
release,
because
we
don't
really
have
the
workable
plan
figured
out
here
like
what
does
this
progression
actually
look
like,
and
how
can
we
make
it
not
disruptive
to
users
it's
possible
while
still
achieving
our
goals,
the
one
thing
that
we
were
still
considering
and
I
guess
we
are
not
sure
if
this
still
requires
the
kept
or
what
exactly
would
be
involved
is
potentially.
B
If
we,
if
we
agree
on
what
Auto
Moon
would
mean,
perhaps
we
could
introduce
auto
mode
behind
an
alpha
environment
variable
so
in
127,
so
people
could
try
auto
mode,
but
it
would
even
be
exposed
by
default
and
certainly
wouldn't
be
the
default,
the
default
value.
So
we
thought-
oh,
maybe
maybe
that
little
thing
would
be
a
useful
experiment
towards
this
goal
and
and
could
still
make
it
in
but
the
bigger
plan.
We
we
all
agreed
in
the
beating
I
think
is,
is
not
ready
for
127.
mucho.
Would
you
agree
with
that
synthesis.
C
Yeah
that
that
sounds
totally
fine
I
mean
we
decided
that
we
want
to
actually
start
moving
in
the
right
direction
by
providing
something
the
environment
variable
as
an
opt-in
and
then
probably
maybe
some
kind
of
a
warning.
Although
we
had
issues
about
what
kind
of
warning,
if
we
don't
know
what
the
plan
will,
what
the
future
will
be.
So
that's
where
the
environment
variable
has
a
starting
point
to
figure
out
all
the
details
and
try
to
put
together
a
concrete
plan
about
the
progression
which
we
would
start
working
on
in
the
next
release.
A
That
that
sounds
perfect.
So
then
what
I
would
do
and
David
I
see
your
hand
up
and
I'll
just
reply.
I
I
would
suggest
that
you
just
change
the
cap
to
be
server.
Side,
apply
auto
mode
as
an
alpha
feature.
It's
environment,
flag,
protected
and
the
cap
can
move
forward
in
this
release.
No
problem,
then
David.
D
B
So,
if
we,
if
we
do
pivot
this
cap
to
or
onto
it,
we
have
to
sync
with
him
if
he
pivots
this
kept
to
be
that
auto
mode
flag,
do
we
then
need
another
cap
for
like
this
overarching
plan
to
somehow
eventually
get
or
or
do
we
then
retitle
it
like?
How
does
that
work
we'll.
A
Retitle,
it
and
I
would
evolve
this,
so
this
would
be
alpha.
Alpha
is
protected
by
a
fly
of
environment
variable
when
we
go
to
beta.
You
would
decide
whether
beta
so
in
apis.
Now
we
beta
does
not
mean
on
by
default,
but
in
other
feature
dates
it
does.
You
could
decide,
probably
on
a
per
cap
basis,
whether
beta
means
on
by
default,
and
at
that
point
we
would
have
to
have
the
discussion.
I
think
that
David's
bringing
up
of
like
do.
A
We
even
keep
the
same
name
or
is
it,
and
that
would
be
six
CLI
would
figure
that
out
right,
like
maybe
it's
a
better
idea
to
do
what
David
suggesting
Alpha
we
don't
need
a
separate
cap.
It's
where
it's
functionally
it's
it's
the
same,
conceptually,
it's
the
same
thing
we're
trying
to
do.
It's
just
we're
adjusting
how
we're
doing
it
as
we
move
from
alpha
to
Beta
to
GA,
okay,.
C
B
Okay,
I'll
opt
it
back.
I
opted
it
out
of
the
release.
Yesterday,
I'll
opt
it
back
in
now
on
that
basis,
so
to
David's
point
that
that
is
actually
something
that
that
Antoine
brought
up
in
the
informal
conversations.
I,
don't
think
it's
it's
mentioned
as
an
option
anywhere
on
the
on
the
public
facing
PR
at
this
point,
but
they're
they're,
just
so
many
different
ideas
that
we've
had
about
what
we
could
do
to
make
this
smooth.
B
What
how
much
we
need
to
disrupt
users,
because
there
are
differences
versus
things
that
we
can
make
them
not
care
about,
and
that's
that
discussion
and
the
amount
of
options
that
we
have
there
are
why
we
decided
that
we
need
to
keep
the
kept
going
across
127
to
like
have
a
chance
to
actually
go
through
those
and
and
make
a
plan
that,
like
end
to
end,
makes
sense
before
we
move
on
it.
D
Okay,
that's
that's.
Fine,
I
was
just
suggesting
it
as
an
option
where,
like
you
know,
I
know,
there's
a
lot
of
effort
into
like
trying
to
make
it
nice.
But
honestly,
if
we
get
to
a
point
where
it's
we
can't
technically
make
this
nice
is
going
to
cause
a
transition
for
all
the
users
who
need
to
figure
out
what
they
need
to
do
one
way
or
another.
It
may
be.
C
D
The
kindest
thing
is
to
just
make
a
new
command,
clearly
Sunset
the
old
and
then
yeah.
If
you
guys
decide
you
really
want
the
name,
you
could
move
back
after
a
year
of
space
or
something
where
the
name
has
been
cleared
out.
I
just
a
server
side
apply
is
such
a
useful
feature.
I
would
hate
to
see
it
forever.
Log
jammed
client-side
on,
we
didn't
know
how
to
gracefully
transition.
D
A
A
Considering
this
as
a
server
sign
feature
as
well
I,
it
seems
to
me
like
there's
this
effectively
a
long
screed
about
how
broken
client
side
apply,
is,
and
then
we're
like.
So
let's
keep
doing
it
and
and
I'd
rather
say
like
let's
not
yeah
Katrina.
B
Yes,
the
relationship
in
my
mind
is
that
the
way
that
the
pruning
behavior
is
currently
implemented
is
tied
to
the
implementation
of
client-side
apply
and
is
also
broken
in
ways
that
aren't
really
related
to
client-side
apply
itself,
but
like
the
pruning
implementation
itself
is
fundamentally
broken.
So
that's
the
that's.
The
focus
of
this
cup
is
like
how
or
the
other
brother,
not
the
one.
B
That's
on
the
screen
is
like:
how
do
we
address
the
pruning
feature,
decouple
it
from
the
implementation
of
clients
that
apply
so
that
it
will
work
with
server,
so
I
apply,
I
want
everyone
to
use,
and
how
do
we
make
this
a
feature?
That's
going
to
work
for
the
ecosystem,
so
that
that's
kind
of
the
where
some
of
the
complexity
comes
from.
B
We
had
a
conversation
at
kubecon,
really
great
discussion
at
one
of
the
unconference
sessions
about
what
it
would
take
to
finally
move
forward
here,
because
this
is
a
an
area.
That's
had
multiple
proposals
over
the
years
that
have
never
managed
to
gain
traction.
So
we
were
trying
to
have
that
discussion
with
a
broader
Community
Beyond,
just
six
CLI
like
what
do
we
need
this?
B
To
look
like
for
it
to
be
successful,
and
one
of
the
things
that
was
particularly
emphasized
in
that
conversation
is
that
there
are
tons
of
tools
out
there
that
already
have
this
concept
in
some
way
or
another
and
are
already
doing
their
own
version
of
it,
and
we
can't
leave
them
Stranded
by
making
our
own
thing
and
saying
everyone
has
to
do
it
this
way,
so
we're
trying
to
develop
a
solution
that
has
that
ecosystem
compatibility
angle
at
its
very
core
and
so
to
sort
of
attempt
to
address
your
question.
B
I
Wish
Justin
was
here
too,
but
the
reason
why
we
are
not
up
front
at
least
proposing
either
crd
or
built-in.
With
the
you
know,
the
information
we
need
as
proper
Fields
I
would
love
that
in
some
angles
for
sure.
But
the
reason
we're
not
doing
it
up
front,
at
least,
is
that
we
have
as
a
core
goal
to
be
able
to
accommodate
the
existing
usage
of
parallel
parent.
C
A
Yeah
I
I
I
shouldn't
have
derailed
that
this
call
with
that
I
appreciate
that
response
and
I
wanted
to
make
sure
it
was
called
the
David's
attention,
because
it's
something
I'm
sure
of
interesting,
but
it
sounds
like
he
already
was
looking
at
it
and.
C
A
Else
did
but
great
answer.
I
I
have
maybe
a
slightly
different
opinion,
but
this
wasn't
the
place
to
talk
about
it.
All
right,
I
will
stop
talking
and
I
think
the
next.
Oh,
yes,
sorry.
B
Well,
since
we
were
just
touching
on
that
anyway,
I
saw
that
you
said
that
prr
was
good,
but
you
didn't
actually
tag
it.
So
I
was
wondering
if
there
was
something
holding
that
up
that
I.
A
A
Is
is
Swati
here,
I
I
think
this
is
resolved
I.
She
answered
my
question
and
then
she
just
needs
to
put
it
into
the
cap
and
wear
or
guts.
So
I
think
we
can
skip
this
one
unless
she's
here
to
talk
about
it.
She
said
she
wasn't
sure
she'd
be
here.
A
Okay,
then,
the
next
item,
surrogate.
E
Yeah
I
just
wanted
to
bring
up
a
few
house
cleaning
kind
of
issues
like
first
is
we
close
this
Dynamic
Google
config
PR
like
cap
for
a
long
time
like
it
was
deprecated
and
removed
and
I
wanted
to
document
that
Pro
happened,
I,
don't
know
whether
it's
important
or
not
I,
just
so
that
it
may
be
something
we
want
to
like
put
for
like
so
how
the
consistency
sake.
So
if
anybody
has
permissions
to
approve
it,
it
will
be
great
yeah.
E
So
this
cap
was
removed
like
stable,
meaning
that,
like
it's
a
dynamic,
Google
config,
so
it
was
removed
I.
There
is
no
other
label
behind
stable,
okay.
E
Okay
and
I,
don't
think
so.
We
introduced
a
new
field
last
time,
new
question
last
time
about
node
Resources.
By
the
way,
it's
very
useful
question
I
already
see
people
trying
to
answer
it
and
like
getting
started
thinking
about
some
implications.
Very
good
I
also
have
this
another
PR
about
a
removing
mention
of
dynamic,
Google
config
from
a
questionnaire
so
I
guess
we
need
to
do
it
after
enhancement,
freeze
and
I.
E
Wonder
if
I
need
to
add
some
bulk
update
of
all
other
cap
checks
right
now
to
to
change
the
question
or
I
just
need
to
like
send
this
as
a
small
change
in
every
cap
owner
will
do
that.
We'll
do
update.
A
I
mean
if
you
want
to
clean
it
up,
that
would
be
wonderful,
no,
no
problem
there.
That's
where
it
becomes
useful
that
I
can
just
approve
improve
them
all.
So
maybe
do
it
before
I
remove
myself
from
that
list,
and
then
we
can
just
go
through
and
approve.
E
Next
Monday
then
ish,
okay
and
finally,
I
wanted
to
bring
up
this
question
about
clarification
of
integration
versus
end-to-end
tests.
I've
been
reviewing
a
lot
of
KR
key
apps,
and
every
time
there
is
no
Clarity
with
integration
and
end-to-end
means.
So
people
have
two
tactics.
First,
tactics
to
say:
integration
tests
are
not
relevant.
You
will
cover
everything
in
end
to
end
and
second
tactic.
E
Just
repeat
a
paragraphs
like
literally
I
saw
like
people
with
a
piece
and
what
they
wrote
in
integration
tests
into
end-to-end
tests,
mostly
because
there
is
no
clear
delineation.
What
is
integration?
What
is
end
to
end
and
given
I
only
looked
at
signode
caps,
mostly
I
only
glanced
on
other
areas.
Maybe
there
are
better
delineation
of
this
tests
in
other
six,
but
for
signaled
it's
currently
I,
don't
see
a
good
good
way
to
tell
people.
This
integration
is
sent
to
end.
D
Test
integration
is
a
package
inside
of
our
test
folder.
It
is
different
than
ede
because
it
doesn't
take
an
already
running
cluster.
What
it
does
is
IT
wires
up
various
components
with
whatever
arguments
are
needed
to
test
them
and
the
launch
system
that's
most
useful
for
features
in
the
API
server
and
off
areas
where
you
are
trying
to
wire
up
configuration
attests
web
hooks
or
various
special
parameters
that
you
can't
control
from
inside
of
an
ede
test.
So
so.
D
A
Awesome,
thank
you.
Well,
that's
our
official
agenda
but
I
believe
David.
Your
thinking,
Shadows
might
have
some
questions.
I.
D
A
D
I'm
just
looking
to
see
if
there
are
outstanding
questions
on
the
remainder
that
someone
would
like
to
talk
about,
live
otherwise
I'm
happy
to
get
back
at
it.
C
A
All
right,
thank
you.
Everybody
great
discussion
and
I'm
glad
we
were
able
to
resolve
the
issue
for
the
6cli
cup.
We
won't
be
doing
it
tomorrow
in
the
cigar
architecture.
Then
one
less
thing
to
deal
with
all
right.
Maybe
we'll
cancel
that
meeting
thanks.
Everybody
bye.