►
From YouTube: [WG LTS] Biweekly Meeting for 20230815
Description
[wg lts] Biweekly Meeting for 20230815
A
A
Muted
myself
somehow
figured
we
could
go
ahead
and
do
maybe
just
a
quick
round
of
intros
a
few
people
on
here
that
I
know
a
few
people
on
here
that
I
don't
know,
and
then
we
can
kind
of
dive
into
figuring
out
what
we
want
to
do.
With
this
working
group.
We
have
a
charter
that
was
approved
and
had
a
lot
of
input
from
a
lot
of
folks
and
contains
some
high-level
goals
about
what
we
want
to
accomplish
with
the
working
group.
A
So
I
thought
it
would
be
good
to
start
there
kind
of
dive
into
what
we
want
to
do
as
the
first
part
of
this
and
then
maybe
discuss
how
we
want
to
track
work
and
going
forward,
perhaps
creating
a
get
a
project
board
and
then
in
subsequent
meetings.
We
can
follow
along
that
and
check
in
on
status
to
make
sure
we're
pushing
some
things
forward.
A
B
Hey
everyone
I'm
Jordan,
like
it,
also
been
around
for
a
while
I
work,
a
lot
on
the
API
API
review
sites
like
architecture,
a
lot
of
stuff
like
that
really
interested
in
compatibility
and
sustainability.
So
I
was
around
for
the
last
iteration
of
the
LTS
working
group
and
pushed
a
lot
on
some
of
the
dependency
stuff
like
how
we
stay
on
sport
at
Go
versions.
B
A
G
Yeah
so
I'm
Vince
power
I'm,
not
in
any
other
kubernetes
thing,
so
I'm,
not
as
cool
as
everybody
else
here
I
work
at
Dell
in
an
internal
kubernetes
group.
So
we
long-term
sustainability
is
a
big
deal.
So
I
thought
I'd
see
what
I
could
help
out
with
this
organization
to
see.
If
we
can
get
things
moving
forward.
I
Howdy
everyone
I
managed
to
rejoin
on
Cell,
since
my
service
provider
decided
that
midnight
was
a
good
time
to
kick
off
maintenance,
as
you
can
hear,
I'm
from
Australia
I
work
for
ISO,
violent
and
I
was
previously
a
chair
of
the
wrglts
in
its
previous
incarnation
and
yeah.
For
those
of
you
who
are
end
users
I
also
was
an
end
user
when
I
first
started
with
LTS
as
well.
So
thank
you.
I
J
You're
up
hi,
I'm,
Noah
Abrahams
I
am
a
TPM
at
Oracle,
mostly
I
spend
my
day
working
with
contributors,
but
in
previous
incarnations,
I
have
done
quite
a
bit
in
regulated
Industries,
and
you
will
hear
that
as
my
routing
and
cry
through.
Most
of
the
conversations
we
have
here,
I
will
pass
it
over
to
Rita.
L
E
M
N
Sure,
first
time
using
zoom
in
a
while,
so
hopefully
my
mic's
working.
Can
you
hear
me
all
right,
sweet,
so
I'm
from
Red
Hat
work
on
openshift
haven't
done
a
whole
lot
of
stuff
Upstream
kubernetes
Community,
but
I
spent
a
lot
of
time
working
on
topics
around
life
cycle
and
how
we
can
keep
our
customers
upgrading
fitting
into
something
that
we
can
support
and
trying
to
you
know,
I
think
someone
mentioned
customers
can't
generally
upgrade
every
few
months.
O
Can
you
hear
me
yep
hello,
everyone?
My
name
is
pavna
I
am
an
end
user
I
provide
a
kubernetes
platform
for
our
internal
customers
and
I
did
participate
in
the
1.25
release.
Theme
and
I
was
interested
in
this
working
group
because
yeah,
it
is
a
pain
Point
as
an
end
user,
where
we
are
not
able
to
keep
up
with
the
releases
so
happy
to
participate
in
the
kubernetes
community
again.
Thank
you.
Q
Hi
folks
can
can
you
hear
me
I
had
issues
without
you
earlier,
oh
cool,
yeah,
I'm,
Nicola,
I'm,
working
at
Giants
Forum
as
a
platform
engineer,
jansform
is
providing
kubernetes
as
a
service,
so
we
have
our
managed
kubernetes
that
we
run
for
our
customers
on
multiple
Cloud
providers
as
well
as
on-premise
So.
Lately
we
have
been
rethinking
our
release
model
in
general
and
one
of
the
topics
that
popped
up
was
kubernetes
LTS,
long-term,
long-term
support
in
general.
Q
R
A
S
Cool
I'm
Caroline
I'm,
the
project
manager
for
the
rk2
and
k3s
distros
in
Susa.
We're
super
interested
in
this
group
I'm
honestly
here
to
be
a
fly
on
the
wall.
I'm
not
super
technical,
but
I
am
here
to
see
what
our
team
can
do
to
contribute
because
it's
sort
of
early
for
them.
So
I'm
here
as
a
representative.
T
C
U
Hey
folks,
can
you
hear
me
I'm
Dan
bodrus
I'm
at
AWS,
working
on
ecas,
I've
worked
on
ecast
anywhere
and
the
uks
distribution
spend
some
time
thinking
about
the
kubernetes
support
life
cycle
and
how
golang
fits
into
that
things
like
that.
So
yeah
I'm
interested
to
see
how
this
group
Works
unfolds
and
see
what
I
can
offer
as
well.
A
B
B
A
Really
cool
to
see
so
many
end
users
here
I
think
it
really
really
is
great
to
see
just
so
many
people
from
different
different
users
of
kubernetes
contributors,
and
so
many
different
folks
interested
in
this
topic.
I
think
it's
it's
super
cool
all
right.
So
with
that
in
mind,
I
thought
it
would
be
good
to
jump
into
the
maybe
discuss
what
the
initial
scope
of
work
for
the
working
group
should
be.
What
things
do
we
want
to
tackle?
First
well,
I
think
Vince
has
a
co-worker.
A
A
Okay,
so
we've
got
a
pretty
I,
think
pretty
wide
scope
for
what
the
charter
has
in
mind.
As
we
went
through
this,
you
know
there
are
certain
things
that
are
going
to
definitely
be
out
of
scope
of
this
and
that's
life
cycle
of
projects
outside
of
kubernetes,
designing
and
executing
on
changes
that
clearly
fall
into
an
individual
Sig's
responsibilities.
That's
really
what
sigs
are
responsible
for,
and
this
is
a
working
group.
So
there
is
no
code
that
will
come
out
of
this
working
group
and
then
finally
Technical
and
end
user
support.
A
Since
we
don't
own
code,
we
don't
have
any
specific
passive
ownership,
so
that
leaves
a
whole
bunch
of
different
things
in
scope
and
I.
Think
the
first
bullet,
that's
under
here
collecting
input
to
better
Define.
What
long-stem
for
long-term
support
looks
like
with
regards
to
kubernetes
releases
might
be
a
good
place
to
start
totally
open
to
anybody
else's
input
there.
Does
anybody
have
any
anything
that
they
think
would
be
a
good
place
to
start
with.
A
You
know
we
have
some
questions
up
here,
that
we
thought
we
would
be
good
to
gather
through
some
surveys.
So
in
use
versions,
I
think
there's
always
shifting
picture
around
that
there
have
been
some
efforts
through
prod
Readiness
and
some
other
things
to
kind
of
get
an
idea
about.
What
are
what
versions
are
being
used,
but
I
think
it
would
be
good
to
maybe
start
with
that
as
a
set
of
set
of
data
to
work
from
and
again
building
on
that
some
constraints
on
deployment
and
upgrade
patterns.
A
J
Yeah
I
I'm,
going
to
start
by
immediately
throwing
a
wrench
into
things,
because
I
never
got
to
comment
on
the
issue.
Never
got
around
to
making
comments
on
this
I
see
one
fundamental
flaw
in
the
very
first
part
here,
but
it's
the
primary
drum
that
I
want
to
beat
on,
and
that
is
the
people
that
are
focused
on
in
this
particular
statement
are
people
that
are
already
running
kubernetes
and
not
people
who
have
already
been
excluded
from
running
kubernetes
because
of
the
existing
LTS
cycle.
J
D
It
might
be
good
to
not.
Everyone
here
might
be,
as
involved
in
the
release,
sketch
cycle
and
schedule
and
and
understand,
sort
of
what
what
the
current
release
periods
or
or
like
it
might
be
good
to
just
give
an
overview
of
like
what
is
what
is.
Why
is
there
even
a
need
for
long-term
release?
I
think
a
lot
of
people
might
have
an
idea,
but
maybe
not
everyone
does
I.
Think
it
probably
just
worth
stating
that
like
kubernetes
has
a
14-month,
basically
maintenance
period
for
each
minor
version.
Minor
versions.
D
Maintained
for
security
or
bugs
or
whatever
by
Upstream
vendors
might
have
extended
versions
after
that,
but
the
that's
the
the
primary
release
of
strain
and
then
releases
happen
three
times
a
year.
Minor
versions
of
kubernetes,
so
the
the
Cadence
is
is
typically
for.
Point
releases
is
typically
around
once
a
month
and
as
Jordan
called
out
at
the
beginning
of
the
call.
We
now
have
all
the
maintained
versions
of
kubernetes
on
maintained
versions
of
go
and
plan
to
going
forward.
D
D
Not
primarily
partially,
at
least
driven
by
by
the
needs
of
kubernetes
and
large
project
go
projects
like
kubernetes,
Jordan
or
or
Jeremy,
or
anyone
else.
You
wanted
to
add
anything
else,
but
that's
kind
of
the
just
the
Baseline
of
what
what
we're
working
with
as
far
as
current
support
by
the
community,
and
so
anything
outside
of
that
would
be
kind
of
in
scope.
For
for
this
group,
I.
B
B
Control
planes
currently
have
to
upgrade
every
minor
version
that
can
be
done
every
four
months.
If
you
want
to
stay
on
the
latest
or
it
can
be
compressed
to
sort
of
upgrade
upgrade
upgrade
through
those
rapidly,
but
they
do
have
to
hit
every
minor
version
currently.
So
those
are
two
additional
sort
of
pieces
of
information
that
inform
what
users
and
vendors
currently
have
to
do.
A
G
B
K
D
A
A
A
All
right
so
in
the
charter,
I
think
be
good
exercise
for
anybody
that
hasn't
read
it
yet
to
go.
Take
a
look
at
that.
We
can
do
some
of
this
asynchronously
since
time
is
not
not
a
great
time
slot
for
everybody.
We
we
have
some
things
called
out
in
the
the
charter.
As
Noah
mentioned,
there
is
a
thing
not
called
out
in
the
charter,
people
that
can't
use
kubernetes
to
begin
with,
because
of
the
current
support
policy.
A
I,
don't
know
how
we
can
survey
those
folks
because
I
don't
know,
we
know
who
they
are,
but
that
would
be
a
good
perspective
to
gather
I
think,
but,
starting
with
the
folks
that
are
using
kubernetes,
would
you
know
Gathering.
Some
of
this
data
be
a
good
first
next
step
to
better
understand
what
we
need
to
do
or
or
what
opportunities
there
are
to
improve
things
for
folks
going
forward.
B
I
think
I
would
like
to
understand
how
some
of
the
changes
that
we've
made
over
the
past
couple
years
have
moved
the
needle
I
know.
We
hear
a
lot
about
an
ability
to
upgrade
or
difficulty
and
upgrade
or
incompatibilities
on
upgrade
and
we've
actually
made
a
lot
of
changes
over
the
last
couple
years,
and
so
it
would
be
helpful
to
hear
from
people
who
are
having
difficulty
and
whether
they've
kind
of
made
it
to
the
points
where
we
made
those
improvements.
B
We
we
don't
want
to
over
train
on
on
the
past
like
if
there
were
problems
that
we
had
two
years
ago
that
we
actually
made
changes
for.
We
don't
want
to
do
a
ton
of
work
now
to
help
people
who
maybe
would
already
be
helped
by
those
improvements,
but
if
people
have
made
it
to
those
versions
and
are
still
having
difficulty
like
that
would
be
really
good
to
know
as
well.
D
D
D
I
Okay,
I'll
try
and
keep
this
quick
because
we're
almost
done,
but
the
a
couple
of
things
I'd,
recommend
a
survey
and
stuff
would
be
pretty
useful.
It
was
pretty
useful
last
time,
I
think,
but
it'll
take
a
little
while
to
get
that
off
the
ground
if
we
want
to
get
moving
fast,
I
suggest
starting
a
gdoc
or
something
like
that
where
people
who
are
attending
the
meeting
can
just
drop
some
relevant
data
about
what
they're
doing
here.
I
Some
of
the
things
that
you
haven't
that
we
have
in
the
charter.
That's
like
a
really
good
way
to
get
very
fast
feedback
and
to
have
a
central
place
to
coordinate
around
I.
Think
it's
probably
going
to
be
useful.
Maybe
next
meeting,
maybe
the
meeting
after
to
spend
a
little
bit
of
time
talking
about
what
we
did
previously
and
sort
of
you
know
that
that
will
be
a
good
source
of
some
of
the
changes
that
were
made
previously.
I
mean
I.
I
Think
the
stuff,
like
the
the
node,
skew
14
months
of
support
that
sort
of
stuff
that
came
out
over
the
previous
rounds,
but
it'd
be
just
good
to
go
through
a
couple
of
those
things:
yeah
and
yeah.
I,
guess
those
are
my
two
suggestions
in
game.
Api
we've
had
a
really
good
success
with
just
making
like
a
general
gdoc
available
where
people
could
dump
things
into
works
really
well
for
async
stuff.
Okay,.
A
There
was
a
question
in
chat
if
it
would
be
possible
to
get
a
list
of
the
changes
that
have
happened
since
the
last
time.
The
working
group
happened.
I
think
that
would
be
useful
to
put
into
a
single
place.
Just
so
folks
can
see
everything
like
the
the
change.
That's
going
to
land
today
or
be
made
public
today
with
the
SKU
support.
There's
a
lot
of
things.
A
B
Yeah
I'm
happy
to
take
that
as
a
AI
I
can
okay,
yeah
and
anyone
else
who
wants
to
add
things
that
I'm
not
aware
of.
That's
fine
I'll,
probably
just
toss
it
in
the
notes
here
and
then
we
can
hoist
it
into
various
things.
If
there
are
things
that
people
aren't
aware
of,
we
can
do
like
blog
posts
and
more
public
things.
We've
done
some
of
that,
but
I'm
always
happy
to
Signal
abuses.
E
On
that
topic,
something
I've
seen
come
up
a
few
times.
Is
people
get
confused
if
they
know
they're
at
version?
You
know
what
you
know
1.21
or
whatever,
and
they
know
that
they
shouldn't
be,
and
they
don't
know
exactly
what
will
break
for
them
if
they
go
to
1.27,
say
and
when
they
start
trying
to
figure
it
out.
They
see
okay,
well,
this
API,
this
API
okay,
that
might
be
a
problem
or
maybe
it
isn't
and
I
know
that.
E
There's
a
lot
of
different
efforts
out
there
to
kind
of
give
people
a
way
to
programmatically
introspect
their
cluster,
to
figure
out
hey
what
are
my
actual
risks
if
I
am
going
to
try
to
upgrade
or
change
this
cluster
and
I
know
we're
all
thinking
launch
a
new
cluster.
Well,
that's
not
realistic
for
many
end
users
for
many
reasons,
so
I'm
wondering
if
we
want
to
kind
of
consider,
instead
of
just
giving
people
lists,
giving
them
also
some
ability
to
tell
if
those
lists
apply
to
them.
D
Q
B
If
every
change
had
an
Associated
like
here's,
how
you
can
tell
if
this
is
an
issue
for
you-
and
there
is
some
of
that
like
there's,
there's
metrics
and
audit
ways
to
look
at
the
auto
log
for
an
API
and
say,
like
oh
I,
can
see
that
I
actually
have
five
applications
using
this
API.
That's
going
to
go
away!
The
next
release,
like
that's,
that's
their.
It's
often
left
as
an
exercise
for
the
cluster
administrator
to
kind
of
take
that
information
and
do
useful
things
with
it.
G
And
there's
tools
like
Pluto
I,
think
is
one
of
them
that
we'll
do
compatibility,
checking
to
check
your
cluster
for
things
that
are
going
to
be
deprecated,
one
of
the
big
pushbacks
I
get
is
people
want
to
do
they
want
their
dream
is
to
skip
control,
plane
upgrades
because
they
we
ship
bundles
to
customers.
You
know
that
are
for
embedded
offerings,
so
it
gets
complicated,
which
you
know,
I
explained
all
the
time,
but
it's
yeah,
it's
just
the
more
compatibility
Checkers
we
can
get
that
cover
more
of
the
apis.
The
better
life
gets.
R
One
of
the
things
that
I
have
heard
around
from
customers
is
certification.
I,
don't
know
if
that
is
being
talked
about,
regulator,
Industries
or
gov
Industries
they
go
through
I
upgrade
and
I
have
to
test
that
everything
works
and
it's
certified,
and
sometimes
they
don't
do
it.
They
assign
it
to
vendors.
Now
for
every
new
version.
They
have
to
pay
someone.
So
we
talked
about
how
quickly
you
can
do
three
version
upgrades
annually,
maybe
for
control
plane
and
go
with
it.
R
But
I
don't
know
that
process
well
to
say
that
it's
not
a
matter
of
going
rapidly
through
four
versions,
but
a
matter
of
like
paying
for
each
particular
version.
So
I
don't
know
if
that's
talked
about
I,
don't
know
the
nuances
of
that
use
case,
but
if
some
anyone
knows
more
about
it,
I
would
love
to
hear.
B
That
that
might
be
an
area
where
the
node
level
skip
upgrades
could
be
useful.
It
depends
on
what
the
certification
needs
to
look
like
if,
if
they're
needing
to
certify
the
machines
that
the
workloads
are
running
on,
then
it's
possible
that
you
know
the
control
plane
is
not
touching
their
workloads,
but
the
control
plane
could
upgrade
through
what
the
machine
that
their
programs
are
actually
running
on.
They
could
certify
125
and
then
they
can
certify
128
and
wouldn't
need
to
do
in
between.
J
For
for
some
of
those,
it
is
going
to
depend
on
individual
jurisdictions,
legality
that
might
go
in
along
with
what
certifications
are
required
and
where
they
are
required.
So
first
so,
for
example,
I'm
here
in
Nevada,
you
all
know
what
regulated
industry
I
might
be
involved
in
and
Mining.
Yes,
mining
totally
mining
for
some
places.
J
B
Another
aspect
of
skippable
upgrades
that
people
don't
talk
about.
A
lot
is
skip
level
upgrades
with
downtime,
so
you
can't
operate
control
planes
at
more
than
one
version
of
SKU
actively,
but
the
API
server
has
to
remain
compatible
with
everything
that
was
ever
persisted
to
NCD,
and
so,
if
you're
in
a
cluster,
where
it's
actually
okay
to
take
your
control
plane
offline,
you
can
do
a
skip
level
upgrade
that's
offline.
B
Api
server
remains
compatible
with
everything
ever
persisted
at
CD.
So
if
you're
looking
for
ways
to
catch
up,
that
is
an
option.
People
sort
of
assume
you're
going
to
keep
it
online
and
available
all
the
time.
But
you
know
if
your
use
case
makes
more
sense
and
it's
more
important
to
you
to
catch
up
quickly
and
you
can
take
the
control
plane
offline
and
do
it
skip
that
will
work.
N
Student
is:
is
that
another
way
of
saying
that
if
you
had
a
way
to
do
an
atomic
update
between
any
versions,
that
would
work
that
that
was
sort
of
my
reading
of
the
version
skew
document,
because
it
talks
a
lot
about
aha
clusters.
But
if
you
have
a
situation
where
it's
just
like
one
particular
host,
it's
not
an
AJ
cluster.
If.
N
I
Okay,
thanks
so
Jordan
does
that
does
that
take
into
account
the
like?
You?
Are
you
jumping
three
versions,
but
in
the
in
the
in
the
second
one,
some
you
know
some
things
got
deprecated
and
the
third
one
they
got
removed
or
is
that
are
we?
Are
we
manage
the
windows
for
deprecation
and
removal,
so
that
can't
happen.
B
I
B
Now
you,
you
hurt
your
rollback
story
so
like
if
you're
going
one
version
by
one
version
by
one
version
by
one
version,
you
can
bring
a
new
API
server
in
and
then,
if
you
know
it
doesn't
come
healthy
or
whatever
you
can
take
it
out
and
start
the
old
version
back
up
and
everything
is
fine.
If
you
bring
one
three
versions
newer
in
it,
it
can
start
writing
stuff
to
NCD
that
the
API
server
three
versions
back
will
choke
on.
So
you
hurt
your
rollback
story
that
that's
the
main
downside,
yeah.
D
I
F
B
D
B
D
D
D
F
B
B
That
would
make
that
you
know
possible
or
more
reasonable,
but
there's
a
lot
of
sharp
edges
there
documenting
that,
so
that
it's
clear
what
people
can
do
and
then
thinking
about
how
we
want
to
improve
things
like
do.
We
want
to
make
some
of
those
sharp
edges
better
or
are
there
other
directions
that
we
want
to
go
like
understanding?
B
The
frustrating
thing
about
skip
level
upgrades
is
I
would
say,
probably
half
the
time.
Nothing
will
have
happened
to
change
so
that
it
actually
would
be
fine,
but
that's
a
really
terrible
like
percentage,
and
it's
pretty
obscure,
like
understanding
when
something
changed
that
would
break
it
is,
is
really
difficult
to
do
and
so
you'll
find
people
who
are
like.
Oh
yeah,
we
do
skip
level
upgrades,
they
work
fine,
it's
like
well,
they
work
fine
so
far,
but
you
sort
of
got
lucky
and
that
that's
difficult.
B
I
G
B
When
when
different
data
gets
persisted
NCD
or
when
you
upgrade
across
the
deprecation
boundary
or
like,
there
are
various
things
that
we
do
out
of
abundance
of
caution
like
when
we
relax
validation
or
type
validation,
we
want
to
be
really
careful.
A
new
API
server.
Doesn't
let
data
get
persisted
that
would
make
an
old
API
server
lose
its
mind
and
so
like
we.
B
We
do
we
rolled
that
tightening
or
loosening
out
over
multiple
releases
and
if
you
skipped
those
you're
at
risk,
if
someone
wrote
to
the
API
in
a
way
that
made
use
of
that,
you
know
looser
or
tighter
validation,
and
so
it's
like
you're
you're
at
risk.
Maybe
you
got
lucky
and
maybe
no
one
actually
wrote
data
the
API
that
was
problematic,
but
you
got
lucky
so
like
there's,
there's
a
variety
of
things
that
can
put
you
at
risk.
If
you're
doing
six
level
upgrades-
and
it's
not
always
obvious
what
the
risk
is.
R
O
B
B
R
The
problem
that
happens
in
with
the
customers
I
work
with
the
say
that
oh
I,
unders,
I
I,
know
what
you're
saying
me,
but
I
don't
understand
what
you're
writing
here,
because
APM
Machinery,
of
course
right.
How
do
you
bridge
the
gap?
Maybe
if,
if
they
knew
it
better,
they
could
understand
things
differently,
maybe
ask
for
different
things.
They
are
right
now
saying
us.
Let
me
do
ski
version
update.
Let
me
go
through
three
versions
at
a
time.
R
R
I
B
And
you
get
back
to
what
Bridget
was
talking
about
where
you
know
we
have
docs,
but
then
someone's
like
I,
don't
know,
I
have
this
cluster
I,
don't
know.
What's
in
this
cluster,
which
of
these
10
caveats
apply
to
this
cluster
like
I,
have
no
idea,
I
agree
with
Bridget.
Let's
talk
about
how
to
track
work.
A
A
Some
of
the
things
that
have
been
done
so
far
to
improve
the
experience
in
the
docs.
We
can
hoist
that
into
another
doc
later
on.
As
one
action
item
we
can
determine
if
we
want
to
do
this
documentation
of
how
to
do
offline
bumps
and
all
the
caveats
that
go
along
with
that
did
we
have
any
other
major
action
items
that
we
wanted
to
to
track,
and
then
we
can
talk
about
how
we
want
to
track
them.
B
I
think
we
should
document
current
state,
at
least
for
ourselves,
to
understand
what's
possible,
even
if
we
don't
turn
it
into
a
website
facing
thing
that
we
point
users
to
do
like
understand
the
current
state
and
put
things
in
place
to
sort
of
keep
the
abilities
we
already
have
and
not
lose
those.
So
it
might
be
testing
or
something
like
that.
A
G
E
I'm
also
happy
to
help
with
blog
posts,
as
well
as
Rita's
point
about
the
docs
we
have
right
now.
We
should
probably
make
sure
that
we
not
just
all
of
the
corner
cases.
Nobody
is
going
to
recommend
your
support,
but
just
the
straight
up
docs
that
are
supported,
tested
cases.
Rita
pointed
out
the
specific
doc.
We
should
go
check
into
okay.