►
From YouTube: [WG LTS] Biweekly Meeting for 20230829
Description
[WG LTS] Biweekly Meeting for 20230829
A
Hey
everyone
welcome
to
the
working
group,
LTS
bi-weekly
meetings,
meetings
covered
by
the
kubernetes
code
of
conduct,
so
to
be
mindful
of
following
that.
This
is
being
recorded
and
will
eventually
be
uploaded
to
YouTube
I.
Think
a
little
bit
of
manual
steps
to
get
that
going
so
I'll
do
the
last
meeting
and
this
meeting
when
it's
ready
and
then
work
with
Nigel
to
get
the
automated
recordings
going.
It'll
be
much
easier.
A
B
A
C
D
B
A
All
right
next
up,
I
created
a
project
board
and
I
linked
it
into
the
the
front
matter
at
the
beginning
of
the
agenda,
doesn't
have
a
whole
lot
on
it
yet,
but
I
kind
of
captured
most
of
what
we
talked
about
last
week,
so
I
created
a
Google
doc
that
we
can
start
to
capture
questions
that
we
want
to
answer
a
suggestion
from
Nick.
So
that's
linked
down
here.
I
also
created
an
experience
in
friction
log
we
could
just
make
available
for
people
to
add
it
and
drop
in
stuff
and
I.
A
Think
Joe
maybe
had
added
something.
So
thanks
for
that,
so
folks
want
to
take
a
look
at
those
things.
That
would
be
super
super
great.
We
can
go
through
them
if
we
have
time
at
the
end,
just
kind
of
take
a
look
at
them
and
see
if
there's
any
feedback
or
comments
that
folks
have
before
we
more
open
them
up.
Beyond
this
group,
one.
E
A
F
G
F
So
I
I
guess
I
can
get
started
even
if
it's
not
showing
so
Jordan
me
Joe,
we've
we've
all
been
thinking
a
little
bit
about
sort
of
the
mechanistic
aspects
of
upgrading
kubernetes
and
we've
been
doing
so
with
a
lens,
obviously
for
LTS
right,
like
all
the
presumptions
that
we
have
today
are.
Is
that
like
and
all
the
policies
that
we
have
in
place?
Like
you
know,
beta
API
is
being
disabled
by
default,
and
you
know
our
feature
flag
progression
things.
F
All
of
these
things
presume
kubernetes
is
going
to
be
upgraded
from
end
to
n,
plus
one,
and
even
those
upgrades
can
be,
and
sometimes
often
are
quite
painful
for
end
users
or
people
managing
kubernetes,
and
so
we
have
the
stock,
which
proposes
some
Upstream
changes,
which
I
think
would
be
realistically
achievable,
which
allows
for
new
type
of
upgrade
flow.
It's
a
little
bit
more
granular
and
it
introduces
this
idea
of
a
compatibility
version.
F
While
it
applies
right
now
for
upgrades
from
n
to
n
plus
one
can
be
extended,
such
that
they
apply
in
an
LTS,
upgrade
like
a
skip
level,
upgrade
specifically
right
because,
like
we're
not
going
to
have
an
LTS
at
least
I,
don't
think
we
have,
because
we
haven't
actually
discussed
the
specific
mechanics
of
what
LDS
is
going
to
look
like
yet,
but
I
presume
we're
going
to
have
one
LTS
version
and
not
an
LTS
version
per
per
kubernetes
release.
That's
just
extending
the
kubernetes
support
window.
You
know
twice
as
long.
F
That's
that's
not
what
LTS
really
is
right.
So
LDS
is
supporting
one
thing:
past
the
support
window,
and
so
in
order
to
actually
do
that,
we
would
need
to
be
able
to
upgrade
the
LTS
version
to
the
lowest
supported
version
in
one
jump
and
so
having
a
compatibility
version.
Could
theoretically
allow
us
to
start.
You
know
an
N
plus
three
or
n,
plus
two,
whatever
kubernetes
version
in
a
compatibility
mode,
that's
similar
to
the
LTS
version
right
and
this.
F
So
if
we
encounter
a
bug
when
we
enable
those
features,
it
now
becomes
possible
for
us
to
just
disable.
Those
features
wait
for
a
pass
release
upgrade
to
the
next
patch
release,
but
everything
looks
exactly
the
same
right
because
we're
in
compatible
compatibility
mode
and
right,
and
so
it
allows
us
to
actually
even
like
skip
the
bug.
Potentially
during
an
upgrade
sequence.
F
F
The
gist
of
the
idea
is
in
the
stock
and
I
wanted
to
float
this
idea
by
the
LTS
group,
because
it
is
obviously
an
LTS
concern
and
we
will
need
to
make
a
number
of
policy
changes
in
order
for
something
like
this
to
happen
like,
for
instance,
we
would
need
feature
Flags
which
are
GA
not
to
be
deleted
from
the
code
base,
at
least
for
some
period
of
time,
at
least
for
some
period
of
time.
Yes,.
E
E
E
The
first
step
of
this
is
really
just
taking
that
comment
based
metadata
and
putting
it
in
actual
structured
data.
So
it's
the
very
minimal
low
risk
change.
It's
really
just
taking
comments
and
putting
them
into
a
struct
so
that
we
can
then
start
running
like
unit
tests
or
static
analysis
on
it
to
catch
problems
where
we
like
had
a
gap
or
didn't
do
something
in
the
right
order
or
in
the
right
number
of
releases,
like
the
the
initial
change,
is
very
low
risk
and
has
immediate
just
test
benefits.
E
It
also
formalizes
some
of
the
things
that
we've
been
doing
internally
in
the
API
server,
without
associating
them
with
a
feature
cake.
So
an
example
is
loosening
validation.
So
today,
we
just
sort
of
internally
have
a
validation
option
and
we
default
it
to
false
in
One
release,
and
we
default
it
to
true
and
the
next
release
to
allow
this
relaxed
validation
and
by
tying
that
to
something
like
a
compatibility
version.
E
E
F
Non-Upgrade
benefits,
for
instance,
today,
every
time
you
use
a
feature
flag,
there's
this
doc
that
you
have
to
update
with
you
know
when
you
introduce
that
feature
flag,
what
version
that
feature
flag
was
introduced?
This
can
now
like.
If
we
do
this
thing,
which
is
in
this
proposal,
we
can
Auto
generate
that,
and
no
one
will
ever
have
to
do
that
again,
which
is
like
kind
of
a
boon
for
anyone
developing
anything
right,
because
it's
always
kind
of
a
pain
in
the
butt.
F
E
Like
there's
work
to
do
there,
you
know
if
we
have
to
talk
to
everyone,
rolling
out,
features
and
say
like
what
would
it
look
like
for
you
to
keep
this
code
conditional
for
another
X
releases,
so
there's
work
to
do
there,
but
this
gives
us
a
pretty
clear
road
map
for
it.
Then
it's
a
matter
of
deciding
like
do.
Can
we
afford
to
do
that
work
and
getting
agreement
on
the
people
who
would
need
to
adjust
how
they
clean
up
old
stuff
once
it
hits
GA?
Basically,.
F
Yeah
so
we've
we've
all
we've
been
making
the
rounds
with
Civic
architecture.
No
one
seemed
adverse
of
the
idea.
Some
people
seem
to
like
it
so
we're
here
today
and
the
plan
is
to
go
to
Cluster
lifecycle,
since
they
do
a
lot
of
the
upgrade
flow
stuff
for
cube
admin
and
Cappy
and
stuff,
and
talk
to
them
next
week
about
this
thing
so
that
we
can
basically
get
consensus
from
the
community.
E
I
E
E
Oh,
oh
I
forgot
one
other
benefit
of
this.
So
today
we
actually
delay
some
changes
by
a
release
in
order
to
be
sure
that
we're
compatible
one
version
back
so
like
allowing
data
into
new
fields
or
loosening
validation
like
we
don't
have
any
way
for
the
operator
to
tell
us
no
it's
cool.
Actually,
this
is
a
brand
new
cluster.
E
You
don't
have
to
be
one
version
older
compatible,
so
we
artificially
delay
some
fields
and
features
and
validation
improvements,
just
because
we
have
to
because
we
have
to
assume
there
might
be
a
server
one
version
back,
and
so
this
would
actually
let
the
operator
accelerate
delivery
of
some
things.
If
you're
creating
a
new
128
cluster,
you
can
tell
the
components
your
compatibility
versions,
128.
Just
you
don't
need
to
artificially
DeLay
So.
This
I
I
really
love
this
idea.
Actually
Han
kind
of
pitched
it
to
me
and
I
was
like
oh
yeah.
This
would.
E
This
would
be
great.
It
lets
us
speed
up
delivery
by
a
release
in
in
some
cases.
So
that's
specifically
around,
like
the
validation,
loosening
things,
probably
not
so
much
feature
like
those
we
actually
need
to
prove
out,
and
you
know,
there's
still
a
point
where
it's
Alpha
and
we
need
to
prove
it
out,
but
like
just
the
validation
loosening
it's
like.
Oh,
we
made
a
mistake.
F
F
E
And
I
think
this,
this
information
would
be
necessary,
no
matter
what
we
did,
whether
it
was
dynamic
or
static.
We
need
this
information
instead
of
Starting.
By
codifying
the
information
doesn't
seem
like
it's
increasing
debt
or
putting
us
in
the
wrong
direction.
It's
just
sort
of
a
small
step
in
the
right
direction.
I
Typically
I
100
agree.
It
seems
like
a
great
idea
to
me,
but
I
wanted
to
have
asked
that
question
just
to
yeah
and
so
we're
all
on
the
same
page.
That
yeah,
like
we've,
got
to
do
something
like
this,
and
you
know
this
seems
like
a
pretty
good
idea
to
me.
I'm
having
the
data
in
a
structured
format
as
opposed
to
a
unstructured
required
requires
human
parsing
format
seems
like
a
win
anything
that
we
can
avoid.
Having
requires
human
pausing
seems
great
to
me.
Okay,
married.
G
F
E
E
What
this
concretely
would
look
like
today
when
you
go
to
add
a
feature
gate
and
you
put
the
Alpha
version
in
a
comment.
It
would
be
like
part
of
the
structure
of
the
Petri
gate,
so
you
would
record
the
minor
version
and
the
default
State
and
then,
as
it
progressed,
you
would
add
entries
to
that
feature.
Gates.
You.
F
Could
have
we
could
have
like
you
know,
we
have
stage
promotion
or
compatibility
version,
but
if,
if
your
binary
version
is
at
one
two
eight
and
you
set
your
compatibility
to
one
two,
nine
that
could
theoretically
mean
you're
enabling
Alpha
features
that
project
being
enabled.
Yet
something
like
that.
Yeah.
B
I
E
Let
me
finish
talking
about
what
Rita
was
asking,
so
adding
the
information
about
the
progression
of
the
feature
gate.
So
the
information
is
there
and
then,
when
a
teacher
graduates
to
ga
today,
we
say
lock
to
default
and
delete
all
use
of
the
feature
gate
from
the
code
base,
and
so
we
could
still
lock
it
to
default.
Some
there's
some
discussion
in
here
about
like
once
a
feature
graduates
and
a
server,
is
running
with
a
compatibility
version
of
that
release
or
higher.
E
Is
it
running
at
compatibility
version
128,
so
I'm
going
to
run
128
components
against
it
and
then
better
pass
so
adding
metadata
to
the
Future
Gates,
keeping
the
featured
gate
checks
in
place
for
at
least
some
number
of
releases
after
ga
minimum
is
probably
one
if
we
want
to
do
skip
level
stuff
more
than
one
release,
then
we'd
need
to
keep
those
checks
in
place
as
many
releases
as
we
would
want
to
do.
Skip
level
stuff
and
then
decorating
tests
with
the
the
version
information,
especially
around
components.
E
J
So
I'm
just
trying
to
wrap
my
head
around
for
the
purpose
of
bringing
in
new
features.
It
looks
like
this.
Could
this
idea
could
be
approach
on
a
rolling
basis
with
no
problem,
but
for
the
purpose
of
deprecating
features
it
feels
like
we
would
have
to
alter
the
the
timeline
or
necessarily
the
phase
with
which
we
do
deprecation,
because
we
have
a
certain
number
of
releases
within
which
we
flag
for
deprecation
versus
actual
deprecation
I'm.
Just
sorry,
my
thought
isn't
really
fully
formed,
but.
E
It's
a
good
it's
a
good
observation,
so
obviously
this
this
is
still
very
early
stages,
so
it's
possible
that
we
would
want
to
limit
the
compatibility
version
to
things
that
are
on
by
default,
so
things
like
beta
apis,
which
we
no
longer
turn
on
by
default,
We
could
decide.
Don't
need
to
be
part
of
this
or
we,
if
you
know
those
people
are
saying
nope,
that's
really
important.
Even
you
know
we
can
decide.
This
is
new,
so
we
can
decide
what
we're
going
to
do
here.
E
But,
yes,
a
new
server
should
be
able
to
emulate
the
configuration
and
endpoints
and
field
enablement
and
everything
that
an
older
server
had.
So
if
that
includes
continuing
to
be
able
to
serve
a
beta
API,
it
was
on
by
default
yeah.
We
would
need
that
to
be
informed
by
the
compatibility
version
again.
I,
don't
think
we
want
to
change
a
lot
around
what
we
let
people
do
like
twiddling,
individual
things
like
once.
E
A
feature
is
GA
in
like
128,
and
you
say
your
compatibility
versions,
128
I,
don't
think
you
should
be
able
to
turn
that
feature
off
same
thing
with
like
a
beta
API.
If
we
say
we're
gonna,
this
is
deprecated:
it's
not
going
to
be
served
in
128..
Once
your
compatibility
version
is
128
I,
don't
think
you
should
be
able
to
turn
that
back
on,
but
we
could
make
narrow
exceptions
specifically
for
the
compatibility
version
purposes,
but
yeah.
F
I
I
But
yeah,
if
at
some
point
in
the
future,
we
were
like
you
know:
wow,
we
we
exist
in
a
perfect
world
where
you
know
we
fixed
all
our
problems
and
we
now
allow
you
to
jump
like
five
versions
because
we're
allowing
you
to
go
two
years,
then
five
versions
would
be
the
minimum
time
that
you
would
need
in
order
to
be
able
to
do
deprecations
like
yeah.
That's
the
point
that
I'm
trying
to
make
and
get
you
the
thumbs
up.
That
looks
like
a
thumbs
up
from
Jordan,
so
I'm
happy.
H
Yeah
I
could
go
so
I
have
the
Arts
about
the
G,
whether
we
don't
mention
whatever
we
want
to
do
it
for
beta,
only
or
GA.
Only
apis
and
that's
interesting.
So
I
was
looking
at
this
thing
about
immutable
secrets,
for
example,
and
when
we
said
immutable,
Flags
was
true
or
false.
That
field
was
added
in
a
g
API
now
from
a
functionality
perspective,
the
old
server.
When
do
compatibility
mode,
it
has
to
understand
how
does
it
function
with
new
apis
being
added
in
GA?
E
Yeah
so
there's
we
draw
a
distinction
between
beta
endpoints
and
GA
endpoints,
because
those
are
entirely
like
once
the
beta
endpoint
goes
away.
Every
client
talking
to
the
beta
endpoint
is
entirely
broken,
so
there's
there's
no
sort
of
incremental
Evolution
for
beta
endpoints.
So
that's
why
Theta
endpoints
are
no
longer
enabled
by
default,
like
it's
just
too
problematic
to
attract
use
of
them.
E
New
Fields
added
to
existing
types
is
much
more
incremental
and
easy
to
do
in
a
backwards
compatible
way.
So
whenever
we
add
a
new
field
to
an
existing
type,
the
default
Behavior.
If
the
client
omits
that
field
has
to
stay
the
same,
and
so
then
the
only
limitation
on
how
quickly
we
can
roll
it
out
is
making
sure
that
the
oldest
server
knows
about
the
field.
So
it
can
preserve
the
data
in
it
and
validate
it
consistently.
And
so
that's
what
we
wait.
E
We
artificially
weight
a
release
when
we
add
a
new
field
before
we
allow
anyone
to
put
data
in
it,
so
that
the
older
server
will
preserve
that
data
and
not
lose
it
and
validate
it
in
the
same
way.
So
when
I
was
talking
about
limiting
to
like
not
including
beta
stuff,
I
wasn't
referring
to
that,
I
was
referring
to
the
the
end
points.
H
But
the
function
when
we
do
compile-
maybe
it
is
for
the
time
of
care
and
I'll-
refrain
from
going
deeper,
I
support.
My
understanding
only
do
we
have
to
do
any
functional
compatibility
also
because
Fields
may
add
it
as
Alpha
I'm
talking
about
particularly
about
Fields,
because
we
talk
about
HDD
data.
Would
we
have
to
do
any
compatibility
mode
and
would
be
would
cause
Court
sprawl
to
increase
for
longer
like
four
five
six
versions?
That's
the
not.
G
E
Right,
I'm
gonna
stop
sharing
my
screen
so
yeah.
So
this
is
a
sketch.
Please
ask
questions
on
the
dock.
That's
probably
the
best
place,
because
there's
a
lot
of
different
groups
participating
and
like
I,
said
or
like
concept,
we'll
talk
to
a
cluster
lifecycle,
but
then
also
probably
spin
up
an
actual.
H
A
F
A
All
right,
we
have
a
few
minutes
left
I
added
two
things
on
the
agenda
really
quickly,
one
the
experience
friction
log
I
can
share
my
screen
too.
Let
me
kind
of
look
at
it.
Real
quick
I
was
gonna
suggest
that
we
share
it
more
broadly,
if
folks
are
comfortable
with
that,
definitely
open
to
not
doing
that.
If
we
don't
want
to
do
it,
but
essentially
I
I
gathered
the
great
information
that
Jordan
put
into
the
meeting
notes
from
last
week
into
here.
A
A
A
E
E
K
A
A
Yeah
I
think
immediate
action.
Let's
review
that
and
see.
If
there's
anything
we
want
to
add
to
it
and
then
we
can
agree
to
share
it
more
broadly,
because
I
haven't
posted
it
anywhere
other
than
in
the
wglts
slack
Channel,
so
I
think
making
sure
that
it
lines
up
with
the
the
general
shape
of
things
we
want
to
just
let
people
share
with
us.
A
If
there's
any
specific
information
we
want
to
add
to
that
like
like
Jordan
pointed
out
name
would
be
useful,
so
maybe
we
can
review
that
this
week
and
then
we
can
share
it
more
broadly
and
decide
on
a
time
box
for
that
I.
Don't
think
two
weeks
is
enough,
because
it's
gonna
be
hard
to
get
it
out
and
share
with
people
and.
E
And
I'd
be
happy
to
like
have
people
add
more
details
as
we
in
the
future
one
one
thing
that
I
am
trying
to
do
is
like
understand:
root
causes
for
some
of
these
things
and
so
like
breaking
down
like
a
particular
experience
to
like,
were
there
particular
releases?
What
were
the
things
in
that
release
that
caused
problems?
E
Have
we
made
changes
to
try
to
address
those
things,
and
do
we
have
any
signal
on
newer
releases,
whether
those
changes
were
effective?
The
things
that
I'm
most
interested
in,
like
looking
to
make
changes
around
are
either
problems.
People
hit
that
we
hadn't
considered
and
haven't
actually
made
any
improvements
on
or
where
the
changes
we
made
they're
like
yeah.
We
got
up
to
that
version
where
you
said
it
was
all
going
to
get
better
and
we
still
hit
problems
like
those
two
signals.
B
E
A
A
So
if
you
could
add
anything
into
the
like
the
front
section,
how
the
stock
Works
about
specifics,
that
you
want
to
have
answered
there,
that
would
be
super
useful
I.
Think
a
useful
thing
would
be
to
do
analysis
and
maybe
invite
people
to
come
and
share,
and
we
can
ask
them
questions.
So
maybe
that's
another
thing
to
include
you
know:
can
you
come
to
the
meeting
and
share
with
us
or
we
can
reach
out
and
do
that.
E
Yeah
and
that's
actually
part
of
my
worry
about
smearing,
the
sort
of
supported
active
recommended,
kubernetes
versions
across
many
more
additional
miners
like
it,
it
means
that
someone
who
is
developing
something
that
needs
to
work
against
any
active,
supported,
kubernetes
version
now,
basically
can't
rely
on
anything
for,
however,
many
releases
we
support.
So
today
it's
bounded
to
a
year-ish.
E
You
know
year,
plus
a
few
months,
so,
if
you
know
cell
was
on
by
default
and
I,
don't
remember
one
27
for
security,
something
like
that
is
expected
to
graduate
in
129
so
like
around
the
time.
127
is
the
oldest
supported
release
in
open
source
and
in
like
major,
hosted
providers
management
providers.
You
can
pretty
much
depend
on
at
least
the
first
iteration
of
cell
validation
being
available.
If.