►
From YouTube: 2022-02-17 Kubernetes SIG Scalability Meeting
Description
Agenda and meeting notes - https://docs.google.com/document/d/1hEpf25qifVWztaeZPFmjNiJvPo-5JX1z0LSvvVY5G2g/edit?ts=5d1e2a5b
A
So
this
is
six
scalability
meeting
17
february
2022
and
I
don't
see
any
topics
in
the
agenda,
but
I
see
that
ciao
chan
post
question
here
in
the
ad,
so
I
guess
we
can
start
with
it.
A
So
do
you
want
maybe
to
to
explain
a
little
bit
more
about
this
issue?
So
I
guess
that
the
idea
is
that
what
do
you
mean
by
unlimited
list
requests
like
without
limit.
A
Yeah
yeah
so
yeah.
I
would
like
to
understand
a
little
bit
better.
What
do
you
have
in
mind
because
it
depends
so,
for
example,
if
if
someone
is
listing
from
watch
cache,
then
basically
we
don't
have
currently
option
to
to
just
send
part
of
the
list
and
basically
we
always
send
the
whole
whole
result.
A
A
Where,
instead
of
like
listing
something
you
can,
we
will
have
a
streaming
api
for
for
getting
the
list
of
things.
So
this
will
be
actually
much
better
solution
for
the
api
server,
because
then
you
don't
need
to
provide
any
any
limit
and
also
it
will
be
less
invasive
for
for
api
server,
because
currently,
when
you
try
to
list
some
huge
huge
objects,
huge
amount
of
objects,
then
it's
possible
that
the
api
server
will
run
out
of
memory.
So
actually
we
had
discussion
about
it
some
time
ago.
I
think
it
was
yeah.
A
It
was
this
in
december
9th
and
on
youtube.
You
could
check
out
the
recording
and
there
was
a
really
great
presentation
from
from
wukash
who
who
actually
prepared
cab
for
it,
and
it's
actually
related
to
those
to
this
listing
of
of
items
from
the
api
server.
B
Okay,
is
this
it's
cd
side
change
that
was
discussed
are.
A
No,
actually
it's
it's
mostly.
I
think
it's
mostly
api
server,
and
but
the
difference
is
that
okay,
so
and
now,
for
example,
what
what
what's
happening
is
that,
like,
let's
say
that
you
want
to
list
everything
and
it
comes
from
watch
cache
and
when
it
comes
from
watch
cache.
What
happens
is
that
it
copies
the
whole
list
of
objects
and
it
keeps
this
copy
till
till
the
receiver
receives
it
receives
it.
A
So
so
that's
what
was
very,
not
well
optimized
for
memory
of
api
server
and
basically,
instead
of
it,
we
will
have
streaming
api,
which
will
have
kind
of
constant
memory,
consumption
on
api
server,
and
if
you
are
making,
if
you
are
listing
something
from
the
api
server
and
you
put
resource
version
0,
then
basically
it
comes
from
the
api
server
and
you
don't
even
need
to
ask
it.
Ask
a
cd
for
for
the
result.
B
Right
so
just
to
set
context
on
where
we
are
coming
from.
So
we
see
unpaginated
range
requests
coming
in
to
hcd,
causing
ohms
on
its
cd
side.
B
So
our
proposal
here
was
to
never
send
unpaginated
requests
to
cd,
so
one
option
we
explored
was
to
have
this
pagination
in
hcd
client
and
have
the
api
server
say
that
I
want
to
honor
that
option,
but
ciao
found
a
problem
with
that
and
it
because
there
are
salt
options
that
sometimes
are
passed
in.
So
these
two
together
may
not
work.
B
So
if
we
go
down
that
route,
we
would
have
to
enable
it
only
when
sort
option
is
not
specified,
which
is
bit
limiting,
so
he's
exploring
another
change
on
api
server
itself
to
see.
If
we
can
pass
a
limit
basically
to
every
std
call
that
it
ever
makes
so
never
make
unpatchinated
calls
to
hcd.
A
Okay,
honestly,
I'm
not
very
familiar
with
this
part,
so
I'm
I'm
a
bit
yeah.
It
would
be
nice
if
wojtek
was
here
he's
way
more
familiar
here.
So
I
think
what
we
could
do
is.
I
can
follow
up
with
wojtek,
because
I
I
don't
feel
competent
enough
to
answer
this
question.
What
kind
of
issues
paginating
those
list
calls
to
at
cdd
would
have.
B
Yeah
sounds
good,
so
what
what
we
could
do
is
we
can
study
the
streaming
that
you
mentioned
the
details
of
that
9th
of
december,
we'll
check
that
out
and
we
should
have
a
follow-up
discussion
on
if
that
is
good
enough
for
us
or
do
we
need
something
else,
because
we
don't
necessarily
have
problem
only
with
the
api
servers
workings,
but
the
workloads
as
well.
Sometimes
the
workloads
drive
it
like
that,
so
that
can
also
be
an
issue.
A
Yeah,
I
guess
so
so
in
your
case,
I
think
it's
more
like
some
workloads
that
you
don't
have
control
over
right
and
those
workloads
are
are
making
calls
that
basically
don't
have
resource
version,
and
they
just
go
straight
to
at
cd
right.
B
Yeah
causing
zone
at
cd
side.
A
Okay
yeah,
so
I
think
I
have
pretty
good
understanding
what's
your
issue
and
I
think
I
will
just
follow
up.
So
I
will
just
add
action
item
for
me
and.
B
Sounds
good,
let
me
just
I
I
think,
chow's,
probably
having
some
audio
issue
or
something.
But
how
are
you
able
to
hear
us
or.
B
Okay,
we
will
follow
up
with
another
discussion
on
this.
A
C
Probably
one
thing
I
want
to
add
is
for
the
still
same
topic,
but
I
have
seen
some
streaming
proposals
yeah
previously,
so
it's
but
it's
for
informers
and
maybe
another
option
is
to
enable
it
for
all
the
requests
not
just
for
informers.
I
remember
in
that
proposal.
There
are
some
options
you
need
to
specify
like
the
most
recent
revisions
and
using
some
watch
instead
of
list.
C
A
I'm
just
thinking
if,
because
one
problem
I
can
see
it's
that
probably
we
cannot
change
api
easily.
It
kind
of
needs
to
be
backward
compatible
right.
So
this
could
cause
probably
some
problems.
C
Yeah
I
mean
it's
the
changes
on
the
api
server
side
right.
It
doesn't
need
any
client
side
chain.
A
Yeah
but
my
understand,
my
current
understanding
is
that
it
will
be
kind
of
new
api,
and
the
current
current
api
for
listing
has
already
quite
a
lot
of
a
lot
of
different
edge
cases.
So
it
might
be
a
bit
tricky
yeah,
but.
A
I'll
also
follow
up
with
that
one,
but
I
think
the
best
way
to
actually
talk
about
it
would
be
to
to
maybe
ask
in
the
cap
that
was
that
was
developed,
because
that's
a
good
question.
If
we
can
change
it
and
have
you
checked
if
anyone
asked
this
kind
of
question.
C
I
haven't,
but
I
guess
I
can
also
follow
up
on
that
I'll.
Do
more
research.
A
Yeah
yeah,
I
think,
did
you
see
the
cap
or
maybe
I
can
link
it.
C
I'm
not
sure
if
it's
the
same
ones,
it
is
using
the
streaming
for
leslie
informers
list.
A
A
Okay,
so
so
I
think
we
have
two
topics
that
we
can
follow
up.
I
will
coordinate
with
with
six
callability
members
and
I
will
get
back
to
both
of
these
questions.
Okay,
yes,
thank
you.
B
So
chaos
trying
to
rejoin
he
said
no,
not
sure
if
he'll
be
able
to,
but
we
can
follow
up.
If
he
has,
any
input
will
add
to
the
list.