►
From YouTube: Kubernetes Resource Management WG 20170927
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
All
right
so
welcome
to
the
I
guess
this
is
the
27th
meeting
of
resource
management
group
got
a
number
of
the
items
on
the
agenda
so
we'll
kick
it
off.
On
the
first
item,
which
was
Windows,
Device
plugins
one
nine
objectives
which
leads
into
some
of
the
areas
that
because
fish
were
just
chatting
about
so
yeah,
you
know,
are
you
leading
the
conversation
so.
B
E
E
So
that's
also
going
to
take
some
time.
So
what
I
would
recommend
is
like,
given
that
if
you
only
have
six
weeks
left
or
one-line
bacc,
it's
not
even
bring
up.
The
header
discussion
continue
to
remain
in
alpha,
let's
focus
on
making
sure
to
water,
it
cold
pieces.
We
have
our
solid
and
robust,
and
so
then,
when
people
want
to
like
extended
or
add
more
features.
E
C
A
lot
of
sense
to
me,
so,
let's,
let's
go
ahead
with
stability
in
that
case,
so
I
think
the
first
thing
to
address
is
the
fact
that
currently
two
tests
I
mean
testing.
They
exactly
I
was
looking
into
it.
A
bit
more
yesterday
might
have
the
solution
and
I
have
a
few
implementations,
different
I
think
this
is
the
first
thing
we
want
to
at
least
handle,
as
and
as
an
objective,
but
I
think
wish
you
mentioned
mostly
that
you
wanted
to
have
it
document
that
specifies
exactly
what
stability
means
to
you.
C
E
I
mean
concretely
the
thoughts
that
I
had
one
that,
like
device
plug-in,
should
scale
for
for
a
reasonable
chance,
so
let's
say
we're
creating
like
or
enough
50
or
100
pots
in
like
rapid
succession.
It
should.
It
should
continue
to
work
in
that
scenario,
and
so
I
mean
basically,
we
have
both
like
density
tests
and
soap
tests.
We
should
run
the
existing
infrastructure
through
those
density
and
sub
tests,
and
we
should
also
soak
is
also
going
to
like
make
sure
that
the
whole
plugin
structure
remains
stable
over
time.
E
We
already
have
a
pretty
awesome
test
as
part
of
1/8
for
for,
like
doing
more
intrusive
testing
for
by
like
restarting
different
components
and
seeing
if
they're
working,
fine,
so
I
think
like
we
should
just
run
it
more
I'd
like
both
density
and
soak
scenarios.
I
feel
like
those
are.
Those
are
those
some
of
the
ways
for
us
like
generate
more
signals
as
I'd,
like
also
like
identified
a
few
specific.
She
was
that
hard
to
be
fixed.
What
is
the
code
complexity?
E
It's
pretty
high
right
now,
one
and
and
it's
objective,
like
there's,
been
overwhelming
feedback
from
from
core
maintain
as
that
that
the
complexity
of
the
existing
code
is
is
quite
high
and
suppose
I
want
to
reduce
that.
So
that's
another
contry
item,
but
other
than
that
I
haven't
like
spend
time
in
the
device
plug-in
area
in
the
last
month
so
like
on
top
of
all
the
other
open
issues
around
that
yeah.
A
E
D
Suggest,
like
maybe
we
should
have
some
testing
libraries
for
that.
The
different
plugins
can
used
to
test
it
directly
by
stacking
implementations,
so
we
need
to
eat
we
test
and
in
the
ETS,
the
holy
cow
so
supporter,
some
like
to
Tomatoes
the
CPU
and
memory
resource
usage
over
given
give
us
back
in
and
hopefully
we
can
use
it
to
some
stress
test
to.
E
I
kind
of
second
notch
ago
saying
that
the
the
core
responsibilities
of
open
source
converters
and
upstream
is
not
specific
device
plugins
and
how
much
resource
they
consume,
but
it's
rather
the
the
cool
wood
ducks
in
the
couplet
and
the
API
itself.
So
on
I
think
I
mentioned
this
offline
right,
like
I.
Think
one
of
the
things
that
that
we
can
do
that
will
greatly
benefit
upstream
is
like
have
a
stub
implementation
of
a
device
plug-in
that'll.
Let
us
test
conformance
of
upstream
without
having
without
needing
GPUs
or
anything
of
that
sort
right
like.
D
I
see
on
the
caching
path
template
like
two
two
prices,
so
on
the
coolest
side
agree
we
want
to
have
like
a
fake
ID,
best
practice,
inclement
ation,
that
we
can
use
in
the
III
tester
and
eat.
We
know
this
hyster
that
just
it
has
to
cooperate
hard
to
make
sure
that's.
A
highway
regulation
doesn't
have
a
name
performance
concern,
but
I
think
like
it's
next
Ohio
to
also
have
some
like
a
generic
testing
library
like
different.
The
best
parking
implementations
made
just
to
reuse,
and
they
also
kind
of
like
I,
said
the
expectation.
C
So,
just
just
a
quick,
we
do
have
a
plugin
for
the
at
least
unit
testing,
but
from
the
e2e
point
of
view,
it
is
where
I'm
a
bit
more
confused
on
how
we
would
do
that.
You
mentioned
the
pipeline
fish
that
I'm
still
a
bit
unsure
how
we
expect
to
do
this
device
plugging
into
the
e
to
e,
because
we
have
to
generate
an
image
right.
E
I
thought:
maybe
you
can
sync
on
that
offline
I,
don't
know
if
we
can
like
this
cuz
that
verbally
it's
much
better
discussed
through
like
a
dog
or
through
an
issue,
but
on
high-level
I
was
thinking
that
we
can
write
a.
We
can
write
a
dummy
device
plug-in
which
will
expose
a
resource
fubar.
It
doesn't
really
have
to
be
an
actual
resource.
The
only
thing
that
they're
testing
is
the
whole
cubic
structure
works
so.
A
E
F
F
So
we
we
have
actually
been
discussing
this
problem
ourselves
right
now.
Our
our
plan,
at
least
initially,
is
for
kind
of
to
to
have
a
similar
kind
of
a
dummy
implementation
of
the
custom
metrics
adapter.
That
will
just
allow
us
from
end
to
end
tests
to
say
populate
these,
given
custom
metrics
and
in
kind
of
the
thought
was
the
same
idea.
Right
like
we
want
to
be
able
to
test
things
without
a
meaning.
F
You
know
hopeful
metrics,
set
up
and
B
without
having
to
be
concerned
that
you
know
maybe
we're
breaking
the
test,
not
because
of
something
that's
wrong
with
poor
kubernetes.
But
you
know
I
know
there
was
a
bug
in
prometheus.
That
happened
to
cause
it
to
return
negative
3000
or
whatever
like
we
were,
so
we
were
trying.
We
were
thinking
about
going
the
same
way
and
then
there
were
people
who
were
honored
on
this
thing.
F
C
A
F
Well
I
mean
so
I
think
it
it's
helped
get
the
the
back
driver
stuff
off
the
ground
pretty
quickly
more
quickly
than
it
otherwise
would
so
I
think
that's
been
successful.
Besides
stackdriver
and
prometheus,
there
haven't
been
a
ton
of
takers
so
far,
but
I
suspect.
As
we
move
towards
you
know,
key
a
will
probably
have
some
other
monitoring
solutions
so
come
on.
Megan
V.
E
Test
for
the
cubelet
side,
where
we
use
even
for
like
and
for
all
the
other
like
vendor
specific
device,
plugins
like
Nvidia
or
solo
play,
or
whatever
we
have
like
a
conformance
test
suite,
which
those
vendors
can
read
to
make
sure
that
their
device
plug-in
works.
So
I
think
one.
There
was
one
other
things
which
I
think
Jiang
was
tough
to
to
like
have
SDK
type
of
thing,
which
people
can
run.
Make
sure
that
they
are
is.
F
Somehow
like
has
like
a
flag
or
something
to
drop
in
drop
in
this
adapter
and
the
antenna
fat
sweet,
you
should
be
able
to
run
all
the
note
e
two
E's
with
your
with
your
adapter
instead
of
the
dummy
adapter
and
then
like
you
know
that
way,
there's
not
like
a
split
set
of
tests
or
anything.
It's
just
very
clear.
You
should
be
able
to
run
the
no
e
two
E's
and
if
you
can't-
and
you
have
a
problem
can
then
you
can
be
reasonably
certain.
E
Like
like
the
device
plug-in
code,
you
kind
of
separate-
and
you
can
just
run
those
tests
to
test
your
device
back
in
functionality,
so
I
think
we
already
have
ability
to
collect
familias
metrics
and
like
dump
them
into
a
shard
from
Italy
server,
which
is
what
we
use
for,
like
tracking
cubelet
performance
by
example,
or
or
like
API
server
for
start-up
latency
and
scaling
it
and
see.
Also
also
I.
Think
we
already
have
an
infrastructure.
Yeah
I,
just
don't
know
how
easy
it
is
to
reuse
it.
E
But
we
have
one
and,
and
so
I
think
like.
This
is
less
of
a
concern
for
us
when
I
do
want
to
stress
on
the
point.
The
road
just
talked
about
again,
which
is
the
responsibility
of
open
source
and
and
and
and
the
test
that
that
should
ideally
have
effect
like
submit
queue
and
entry
and
and
releases
should
not
be
tied
to
any
any
specific
device
plug-in,
because
the
responsibility
of
the
core
is
to
provide
is
the
extension
point
and
not
necessarily
support
for
each
and
every
artifact.
E
That's
that's
being
supported
through
this
extension
point,
because
if
we
go
down
that
path
and
we
sort
of
defeating
the
whole
point
of
accessibility,
but
it's
up
to
each
vendor
to
make
sure
that
either
they
use
upstream
critters
testing
system
or
not
and
make
sure
that
their
overall
integration
actually
works
right.
So
we
do
want
to
add
value
for
the
Cure
is
ecosystem,
but
only
make
sure
that
the
that
the
responsibility
is
very
clear
between,
like
the
core
upstream
versus
the
ecosystem,
yeah.
C
I'm,
so
sorry,
that's
a
pretty
good
transition
to
the
next
part
with
which
I
called
usability,
but
we
can
rename
if,
if
we
want
to
it's,
it
was
more
as
a
first
draft
for
the
name,
sir.
So
from
my
point
of
view
on
the
girl
API
is
that
currently
we
support
nvidia
gpus
with
google's
device
plugin
and
the
the
idea
had
behind
this
part
was
mostly
because,
on
the
last
at
least
four
is
at
1.8
milestone.
C
We,
we
started
saying
that
we
would
like
to
support
Solar
Flare
next,
but
unfortunately
we
couldn't,
and
so
in
my
point
of
view,
we
don't
really
have
at
the
plug-in
system.
If
we
only
support,
GPUs
and
so
I
agree
was
the
fact
that
it's
a
bit
annoying
to
specify
our
objectives
in
terms
of
supporting
a
specific
device,
but
I
think
it
would
be
a
good
objective,
at
least
for
1.9,
to
say
that
we
support
two
kinds
of
devices.
C
E
I
mean
I,
I
I
think
we're
all
completely
on
board
on
the
fact
that
we
want
additional
implementation
and
you
want
this
apiary
to
actually
help
the
ecosystem.
So
there's
no
questions
about
that.
I'm.
Just
saying
that,
in
terms
of
prioritizing
the
work
for
upstream,
there
are
two
parts,
one
is
like
stabilizing
the
existing
code
and
I'm
saying
that
that's
piece
and
then
there
should
be
one
item
which
is
like
extending
the
existing
API
to
meet
additional
use.
E
Cases
for
adding
support
for
new
devices
like
like
the
solar
flag
mix,
for
example,
or
like
maybe
in
for
the
band
and
so
on,
like
so
the
there
are
and
I
just
wanted,
like
stress
the
fact
that
we
should
not
like
let
go
of
the
p0
and
we
should
not
have
a
priority
inversion,
because
the
the
things
that
we
are
doing
as
far
as
stability
is
going
to
benefit
everybody
right.
So
I
completely
agree.
G
G
But
so
we
should
also
look
that
we
should
also
look
like
how
how
much
complexity
or
instability
this
change
is
asking
for,
for
example,
the
for
the
nix,
the
request
which
we,
the
request,
which
we
are
making
is
just
for
odd
name
so,
and
that
could
be
useful,
as
you
said,
for
other
device
plugins
as
well,
so
and
and
I
and
I.
Don't
think
that
we
should
really
make
up
elite
with
the
multi
network
supports
anyways.
Multi
networks
have
been
under
discussion
since
last
around
2
years,
and
still
today
there
is
there
is.
G
E
Yeah
so
I'm
we're
not
saying
that
we
should
not
do
this.
I
hope,
like
that's
clear,
all
he's
saying,
is
like
it's:
let's
communicate
as
clearly
as
possible
our
requirements,
and
so
that
like
when,
when
cumulus
as
a
project
is
giving
other
users
look
like
flu
to
extend
cristinita
use
cases,
we
give
them
the
confusing
guidelines.
A
A
E
Maybe
we
are
probably
lacking
some
other
functionality
that
we
function
on
standpoints.
Are
things
seem
to
be
working
for
now
and
if
and
if
you
get
to
a
point
where
the
hooks
are
necessary,
then
you're
also
like
exploring
other
means
rather
like
having
to
have
a
runtime
level
hook,
because
we
want
runtime
possibility.
But
that's
like
completely
aside
from
this
conversation.
I
D
Attention
to
pass
the
party
information
to
the
best
park
in
different
activist
Park
in
I
use
that
information
to
do
like
a
lot
of
scenes
and
we
may
not
to
have
more
invitations
in
terms
of
how
we
manage
different
kinds
of
resources.
The
that's
why
we
can
write
a
standard,
the
use
case
and
say
how
what
is
the
best
way
to
support
those
businesses
in
communities,
because
we
don't
want
API
to
be
too
flexible,
that
it
doesn't
do
any
kind
of
enforcement
in
terms
of
the
nikes
model.
E
C
Just
to
build
on
what
Jane
said,
this
is
something
I've
intentionally
left
out
of
the
objectives
for
1.9,
which
is
the
news
resource
model
that
fish
talked
about,
which
I
felt
was
something
that
you
you're
more
targeting
for
the
next
milestone.
So
one
point
ten,
but
do
you
have
any
more
thoughts
on
that
fish
is
as
in?
Is
there
am
I
wrong
on
that?
Do
we
are?
We?
Are
we
thinking
about
it,
but
you?
You
were
mentioning
a
few
times.
You
had
a
model
in
mind
and
that
you
would
publish
a
document
yeah.
E
It's
it's
it's
necessary
for
certain
scenarios,
like
mainly
for
a
playing
quota
limit
range
I'm
like
making
these
external
resources
easily
visible
through
through
like
command
lines
and
so
on.
So
I
think
like
there
is
a
there's,
an
immediate
use
case
for
it,
and
the
thing
is
like
because
already
did
some
great
work
on
on
exploring
some
of
the
week's
was
plugins.
So
my
the
thoughts
that
I
had
but
I
like
to
extend
that
and
Derick
and
I
sort
of
had
an
offline
conversation
about
it
a
couple
of
months.
Fine.
E
But
the
thing
is
like
I'm
I'm,
hoping
in
this
one
nine
timeframe
to
actually
propose
a
design
which
will
like
cover
extensibility
across
the
board,
and
this
is
something
that
we
have
to
discuss
with
the
overall
overall
like
community
and
not
just
like
us,
I
guess
in
this.
This
Chabad,
but
yes,
like
I,
think
I
think
I
do
want
us
to
start
tackling
that
and
110,
but
but
for
1/9.
Let's
I
prefer
we
focus
on
like
getting
the
existing
baseline
solace
and
I'm
not
like
spend
too
much
time
on
that.
Yes
agreed
this.
C
C
I
named
it
will
be
wording
because
the
objective
was
to
have
to
at
least
reword
in
the
first
time
the
documents,
the
design
plug-in
document
so
that
it's
easier
for
us
to
evolve
to
a
or
at
least
for
this
GSI.
So
sorry,
to
give
you
more
context,
we
had
a
meeting
with
Tim
Hawkins
and
fish
and
the
the
concern
was
that
we
have
to
plug
in
systems,
but
at
least
we
spoil
systems
great
abilities
and
that
if
we
have
three
plug-in
systems,
then
maybe
we
can
invert.
C
A
C
So
si
and
I
said.
Thank
you.
So
the
temps
concern
was
about
the
fact
that
if
we
have
three
different
plugin
systems-
and
maybe
we
could
at
least
converge
to
something-
that's
if
not
unified,
at
least
similar,
and
so
the
idea
behind
rewording.
The
device
bug
inspect
to
make
it
at
least
similar
to
the
CSI
spec,
was
that
so
we
could
actually
move
forward
to
this
similar,
at
least
in
the
first
time,
a
specification,
or
at
least
design
also
I,
think
it's
supported.
I
I
feel
like
the
device.
C
E
I
just
didn't
know
if
I
said
that
how
many
hearts
would
break,
but
when
you're
done
great
work,
but
then
one
from
the
storage
side,
it's
really
like
it's
a
30
or
35
year
old
domain
and
like
even
on
the
cumulus
side,
there's
been
lots
of
iterations
on
the
API
that
have
happened.
It's
been
like
the
entry
volumes
and
then
there
is
the
outer
free
volumes,
dynamic,
freshness
and
as
flex
volumes,
and
then
we
have
this
continuous
value.
E
So
you
like
try
this
over
and
over
and
then
came
the
device
plug
in
spike
and
then
like
it's,
this
sort
of
like
multi
orchestration
consortium
thing,
that's
doing
it
so
there's
like
lot
more
energy
and
findeth
going
so
I
mean
I.
Don't
think
we
should
like
give
I,
don't
think.
Like
we
shouldn
t
mean
ourselves
too
much
I
think
we
have
done
a
good
job
with
the
time
that
we
had,
but
definitely
we
can
do
better.
E
So
I
did
talk
to
Saad
and
I
didn't
explain
to
him
some
of
the
design
parameters
we
have
chosen
like
in
terms
of
having
dynamic
registration
and
odd
model
we
have
chosen,
and
so
on.
So,
and
so
he
was,
he
was
like
pretty
positive
about
that
and
he
was
trying.
It
was
actually
like
helping
solve
some
of
the
CSI
use
cases
too.
E
So
he
said
that
he
would
be
looking
at
taking
it,
but
people
look
at
to
see
into
our
device
plug-in
model
and
seeing
if
they
can
incorporate
some
of
those
design
parameters
in
a
CSI
spike
as
well
from
a
CNI
side.
It's
like
an
X.
It's
like
a
binary
exit
model
so
to
satisfy
Tim's
question.
I,
think
what
we
need
is
like
a
dog
that
describes
that
contrast
features
provided
by
each
of
these.
E
Each
of
these
different
extension
points
and
the
specific
design
choices
that
they've
chosen
for
for
like
providing
the
actual
functionality
and
make
that
they,
when
they
hook
into
the
pod
and
qubit
life
cycle,
and
then
what
sort
of
primitives
are
necessary
like
how
does
one
write
a
plugin?
Do
they
have
to
deploy
a
binary
or
not
like
how
is
life
cycle
of
a
plugin
handle
and
so
on?
So
it's
more
about
like
highlighting
the
different
design
choices
and
assumptions
made
for
these
different,
different
extensions.
E
So
from
our
side
from
the
device
plug
inside
I
think
we
can
supply
that
we
have
broadly
adequate
information
already,
but
we
probably
have
to
collaborate
with
with
the
CSIT
and
the
CNI
team
to
generate
this.
I
can
try
to
get
this
conversation
going
in
1-9
timeframe,
but
I'm
really
not
positive
about
that
it
might.
This
might
slip
into
1:10
and
we
can
say
that
this
is
something
that
we
eat
for
theta,
but
I
don't
know.
If
we
can
do
this
in
one
night
we
can
try,
but
it's
trying
to
be
optimistic.
E
C
E
We
need
like
three
to
four
implementations
for
us
to
like
first
finalize
the
functionalities
that
we
want
to
provide
and
see
whether
the
current
model
we
have
chosen
is
actually
going
to
work
like,
for
example,
in
the
case
of
CSI,
is
probably
about
like
20
or
quick,
like
20
plus
implementations.
That
would
that
would
sure,
and
so
like.
There
is
lot
more
data
available
there
to
make
the
right
design
choices,
and
here
we
don't
so
I
think
you'd
probably
benefit
from
from
advertising.
E
C
And
so
I
think
just
here
we
can
work.
We
just
said
mostly
where
we
have
really
two
objective
was
the
first
one
is
stability
which
is
p0
and
the
second
one
is
real,
that
I'm
talking
about
supporting
new
devices
at
least
API
wise,
which
is
really
more
p1,
and
so
the
stability
I
think
is
something
jiaying
and
I
are
going
to
at
least
take
offline.
C
We
have
a
huge
plans,
a
few
issues
to
open
and
a
lot
of
parts
to
review,
and
if
there
are
really
some
like
at
least
some
major
concerns
or
plans
on
how
to
do
specific
things.
At
least
the
first
one
I
think
have
noted
was
really
about
having
this
dub
a
device
plug
in
a
TV.
We
can
write
a
documents
on
that.
Does
that
seems
correct
to
everyone.
D
D
E
C
D
E
Because
a
lot
of
people
who
are
probably
not
on
this
call,
who
are
also
like
very
much
interested
in
helping
out
so
I,
would
probably
like
wait
until
all
the
information
is
available
clearly
on
Keith
Urban
and
then
start
figuring
out
the
owners.
Unless
someone
is
like
really
interested
in
doing
that,.
D
A
A
So
basically,
I
could
be
a
guaranteed
pugs
without
making
a
huge
page
request,
whereas
right
now,
I
think
when
this
alpha
feature
is
on,
you
cannot
be
a
guarantee
Pudge
when
making
no
huge
page
requests,
which
I
now
realize
saying
that,
if
that
was
true,
is
practicing
a
paddle
nuts.
Then
one
item
that
I've
been
thinking
that
I'd
unit
to
fix,
but
from
like
a
usability
standpoint,
I
think
so
far.
A
This
seems:
okay,
I'm
I'm,
not
in
a
mad
rush
to
promote
it
to
beta
in
one
night,
without
getting
some
additional
feedback,
but
I
didn't
know.
If
anybody
else
like
me
need
any
intel
or
others
have
started
experimenting
with
a
particular
workloads
using
this,
but
this
seems
more
isolated
than
say
the
device
plug
inside.
A
Basically,
if
I
have
reason
to
believe
that,
potentially
in
some
part
of
the
code,
I
wrote
in
1/8,
it
could
have
impacted
cause.
I
would
like
to
clearly
say
that
it
should
not
impact
cause
good.
Generally.
Speaking
above
that,
I
think
to
consume
huge
pages.
You
should
have
also
made
a
memory
request,
like
that's,
probably
the
one
validation
change
I
could
looking
to
make
like
I.
A
Don't
see
a
good
reason
for
a
best-effort
pod
to
really
be
consuming
huge
pages,
so
at
minimums
requiring
you
to
be
in
the
versatile
tier
does
not
seem
like
a
bad
thing
to
do,
but
yeah
that
was
the
one
split.
Otherwise,
the
limit,
the
restrictions
we
made
around,
limiting
the
number
of
page
slices
for
no
and
I.
Don't
really
think
are
that
problematic,
I.
E
Just
feel
like
the
restriction,
our
own
best
effort,
part's,
not
consuming
huge
pages,
is
probably
generally
applicable
to
any
other
resource
right.
So
maybe,
if
you're
coming
up
with
the
solution
at
all
the
for
inner
core
resources,
I
mean
generally
or
for
yeah
I
mean
for
other
integer
resources
too.
So.
A
Yeah
I'm
not
sure
about
things
that
we
used
to
say
we're,
opaque
or
not,
but
and
there's
less
of
a
resource.
I
can
so
closely
tie
it
through
that
I.
Don't
know
the
answer
that
one
I
guess,
but,
generally
speaking,
I
want
to
make
sure
that
huge
pages
are
not
a
part
of
the
Claus
model,
but
users
should
consume
them.
I've
at
least
the
personable
Claus.
A
A
The
other
items
that
come
to
mind
that
we
did
not
do
was
exposing
it
down
through
the
CRI
right
now
it's
at
a
pod,
sandbox
level,
that's
something
we
could
look
to
do
and
also
then
support
per
container
isolation.
I'm,
not
sure
in
my
own
view,
of
what
other
1-9
priorities
are
that
that's
something
I
need
to
I'm
motivated
to
sign
up
for
right
now
and
in
particular
it
seems
like
that's
a
broader
change
to
push
through.
A
A
So
on
the
site
last
topic
here
on
CP
manager,
given
that
Connors
not
here,
there
were
a
number
of
items
that
I
called
out
during
your
review
of
those
PR
xin
1:8,
but
I
wanted
to
get
solved
before
ever.
Thinking
about
moving
to
beta
and
I
wasn't
sure
if
any
of
the
folks
here
were
on
the
call
we're
interested
in
exploring
other
CPU
management
policies.
So
like
a
lot,
I
worked
on
into
the
static
class
and
not
much
is
happening
and
I'll
turn
their
policies
so
Jarius.
A
A
A
A
H
A
Break
down
but
yeah
my
bias
was
to
do
that,
but
the
problem
on
that
fish
is
like
right.
Now
we
only
really
introspect
the
pod
sandbox
see
groups,
but
not
very
much
deep
into
the
container,
see
groups
unless
we
are
ensuring
that
all
pins
are
killed
before
we
delete
the
pod
sandbox
itself,
but
I
still
don't
see
a
major
problem
in
going
dropping
down
to
the
container
see
group
two
reconciler
stays.
E
A
E
Know
I
was
just
editing
while
doing
that,
if
you
make
sure
that
the
pod
cebu
has
all
the
sets
that
are
being
allocated
to
its
containers,
but
might
be
good
enough
for
us
just
to
reconstruct
stable,
like
I
assume
that
the
main
thing
that
we
care
about
is
what
what
is
available
in
water
spring.
Right.
A
A
Okay,
so
I
think
I
don't
know
if
they
had
any
other
particular
items
to
cover
here.
No,
no,
because
did
you
get
to
look
at
the
if
set
priority,
Cisco
is
still
actually
going
to
be
needed
or
not,
or
did
we
work
around
that
with
Jeremy
he's
not
here
to
get
input.
E
E
D
D
E
A
I
guess
the
last
thing
I
just
want
to
I
want
to
make
sure
that,
from
from
my
perspective,
there's
no
other
things
that
we
didn't
already
start
in
the
flight,
but
I'm
interested
in
pursuing
in
1/9
and
I
just
want
to
make
sure
that
I
assume
bish.
You
feel
the
same
way.
I
was
there
any
other
particular
topics
that
folks
thought,
but
they
really
wanted
to
advocate
for
that.
We
haven't
discussed
and,
if
so,
I'd
be
curious.
K
A
K
B
A
My
initial
thought
on
that
is
its.
It
was
not
a
major
I
mean
the
sauce
issue
comes
up
pulsing
when
people,
when
I
like
dynamically,
add
and
remove
CPUs
I
I
had
a
sample
piece
of
work
out
there
that
basically
provision
huge
pages
from
a
daemon
set
and,
at
the
end
it
kind
of
kicked
the
keyboard
as
a
restart
as
a
poor-man's
restart,
which
was
fine,
because
it
didn't
really
impact
beautiful
workbooks
I'd
be
curious.
A
E
A
E
E
A
The
original
question
I
face
the
lengths
not
yet
have
we
provide,
which
was
a
dynamic
allocator
for
the
allocated
huge
pages
that
you
could
do
be
a
daemon,
so
in
practice
I'm
not
like
the
biggest
fan
of
it,
because
typically
we
wanted
to
reallocate
huge
pages
as
close
to
Bhutan
as
possible.
So
none
of
what
I
will
paste
here
actually
handled
like
what
happened.
If
you
could
not
actually
get
all
the
huge
pages
allocated
if
the
node
was
actually
under
heavy
use,
so
be
curious.
K
E
H
I'm
working
on
initial
performance,
benchmarking
report
right
now:
bad
metal
involvements
with
a
certain
certain
benchmark.
What
roads
also
Nicolas
Nielsen,
is
on
ice
on
the
call,
and
he
might
have
something
to
add
we
to
have
a
more
generic
performance,
benchmarking
or
CPU
manager
or
otherwise
for
communities.
Nicholas
I
do
that
yep.
L
I
think
mission:
you
know
the
context
of
what
we've
done
in
the
past.
I
guess
it
would
be
more
interesting
to
kind
of
measure
concrete
metrics
like
context
which
is
or
something
that
could
give
people
like
a
load
to
take
view
of
if
they
need
to
pin
their
clothes
or
not,
if
they're
actually
contending
present
for
something
I,
don't
know
if
there's
something
that
we're
gonna
work
on
immediately,
they
may
come
down
down
the
line.