►
From YouTube: Discussion of API Priority and Fairness for kcp
Description
v0.6 design discussion.
A
All
right
so
we're
here
talking
about
how
to
adapt
api
priority
and
fairness
for
kcp
and
during
the
last
community
meeting.
I
think
we
discussed
you
know
most
of
the
issues.
I
think
it
you
know
needs
to
have
some
recognition
of
the
workspace
concept.
We
need
to
have
a
concurrency
limit
per
workspace.
A
To
my
mind,
the
biggest
question
was
you
know
what
sets
the
concurrency
limit
per
workspace
who's?
Who
decides
how
how's
that
conveyed
and
then,
as
someone
who's
new
to
the
project,
I
just
need
wouldn't
mind
and
we
might
need
to
record
this
part
just
some
understanding
of
how
to
you
know
do
development,
how
you
know,
features
that
exist
in
both
base,
kubernetes
and
kcp.
You
know
how
they're
both
being
developed
concurrently
with
forked
code
bases
and
coping
with
that
kind
of
good
stuff.
A
B
Of
course,
you
want
something
which
is
controlled
by
the
kcp
admins
billing
is
involved
and
all
this
stuff.
I
would
move
that
aside
for
the
moment.
I
would
just
try
to.
We
come
up
with
some
numerical
specification
of
what
we
want
to
to
throttle
or
to
the
seats.
I
think,
use
the
number
of
seats.
Something
like
that
right
right,
yes,
put
that
put
it
on
some
workspaces,
try
to
translate
it
in
the
background
to
p
and
f
in
some
way.
B
That's
the
task
right
and
basically
try
to
prove
that
pnf
can
bring
us
what
we
need
just
with
two
workspaces,
one
super
noisy
limited
throttle
down
and
the
other
one
has
paid,
so
they,
the
other
one,
wants
to
get
their
their
quota
in
seat
terms
whatever,
and
they
are
not
disturbed
by
this
noisy
neighbor.
Something
like
that.
A
A
A
B
A
B
B
A
B
A
B
A
A
A
A
B
A
A
A
A
B
The
users
like
like
a
cloud
api
is
pretty
low
qps,
it's
not
qps,
it's
a
different
concept,
but
same
idea,
and
we
have
to
protect
the
system
to
survive
like
the
system.
Controllers
have
to
get
their
share,
whatever
happens,
and
every
user
should
basically
get
their
promised
chair.
So
we
can
make
a
test
at
the
end.
Like
100
users,
everybody
does
as
much
as
you
can
like.
Using
using
clients.
Storm
produces
a
storm
onto
the
kcp
instance,
and
system
should
survive
like
system
controllers
and
every
user
gets
here.
Something
like
that.
That's
basically.
A
And
I
think
the
thing
you
wrote
earlier
earlier
is
really
getting
to
the
essence
of
it.
If
we
have
two
workspaces,
one
of
which
is
loaded
heavily,
you
know
and
and
the
clients
are
offering
say
we
give
each
workspace
100
seats,
the
clients
have,
you
know,
300
threads,
that
are
trying
to
occupy
a
seat
all
at
once.
One
one
workspace
has
300
clients,
the
other
workspace
has
50
clients,
the
one
with
the
50
should
get
its
50
right,
and
the
one
with
the
300
should
only
get
the
100
at
a
time.
B
Yeah
yeah,
exactly
that's
great.
I
think
we
are
on
the
same
page.
This
is
it's
a
good
definition.
I
think
we
have
to
write
it
down
not
now,
but
afterwards,
asynchronously
and
so
before
we
go
into
the
second
part.
We
need
a
problem
definition,
that's
fine.
We
have
to
write
some,
I
mean
the
problem.
Definition
is
more
or
less
already
the
demo
script
like
what
we
expect,
what
we
show
in
a
virtual
game,
or
it's
not
coded
afterwards,
but
we
use
this
style
to
to
give
our
goals
for
prototypes
so
for
june.
B
Basically,
in
this
case,
so
we
have
to
get
to
that
point.
We
can
do
it
asynchronously.
At
the
end,
there
should
be
an
epic
india
next
week,
where
the
steps
are
written
down
like
the
user.
These
are
visible
steps,
so
the
user
stories,
basically
for
the
demo
and
any
technical
action
items
we
have
to
do
so.
Something
must
like
that
must
be
the
output,
but
we
can
send
cards
and
corners.
That's
that's
all
fine!
It's
a
goal.
I
think
we
have
now
that's
perfect.