►
From YouTube: Kubernetes Resource Management WG 20180425
Description
Meeting Agenda:
https://docs.google.com/document/d/1j3vrG6BgE0hUDs2e-1ZUegKN4W4Adb1B6oJ6j-4kyPU
A
All
right
well
welcome
everyone
to
the
April,
25th
resource
management,
working
group
meeting
of
two
topics
on
today's
agenda,
as
well
as
some
special
guests
from
I.
Guess
they
go
to
skilling
and
seeing
instrumentation.
So
thank
you.
First
up
on
the
agenda
was
talking
about
feedback
of
the
testing
work,
so
I
guess
about.
If
you
want
to
talk
through
that
sure.
B
B
Some
of
the
node
performance
features
that
people
are
gunning
to
add
in
the
kubernetes
ecosystem
and
have
some
objective
data
on
it.
So
main
reason
is:
there
are
some
low
level
optimizations
or
performance
optimizations
that
people
connect
to
add
in
the
cupola
tank.
You
want
to
have
a
way
to
objectively
measure
the
performance
of
these
workloads
with
and
without
the
feature
enable,
for
example,
that's
this
that's
what
this
proposal
is
about,
so
there
are
mainly
three
parts
to
this
proposal
or
three
components
to
this
proposal.
B
The
first
part
is
the
first
part
is
the
probationer
itself,
as
in
like
provision
of
kubernetes
cluster,
it
could
be
on
gcpd,
AWS
or
bare
metal
or
any
of
any
other
any
other
any
other
platform.
Second
part
is
the
test
run
or
itself.
How
are
we
going
to
run
the
test?
The
third
pass
part
is
the
result
of
regulator
and
graph
water
or
riffle
plotter.
So
there
are
several
options
for
these,
so
what
we
did
was
we
took
these
options.
We
discuss
this
proposal
with
the
cig
testing
community
and
the
the
initial
proposal.
B
I
think
it
is
discussed
at
the
end
here
where
we
have
a
roadmap,
a
phase
1.
What
we
are
planning
to
do
is
add
this
test
runner
to
so
the
node.
You
know
D
to
e
sub
directory
within
kubernetes
or
core
kubernetes
and
and
leverage
testing
for
as
much
as
possible.
This
with
same
option
with
six
testing.
There
were
I
hadn't,
seen
you
one
person
from
Red
Hat
and
another
person
from
and
Tim
Sinclair,
so
they
were
the
ones
who
are
doing
us
main
feedback
and
they
think
this
is
a
good
idea.
B
B
C
B
So
so
the
options
that
we
are
exploring
is
just
leverage
the
Queen
for
such
an
that
is
already
in
place
in
test
intra
and
then
publish
the
results.
So
in
case
of
I,
don't
know
if
people
have
seen
this.
That
is.
Actually
there
is
one
more
note
first,
but
I
don't
think
yeah
so
know
what
/
has
some
some
kind
of
result,
aggregation
and
graph
plotting,
not
sure
why
it's
not
loading.
So
that's
it
has
a
certain
set
of
graphs
published
there
with
respect
to
like
poor
creation,
latency
CP
usage,
some
of
the
metrics.
B
So
we
want
to
do
something
similar
for
a
start
with
single
node
runs.
The
workloads
that
we
are
discussing
is
something
Connor
and
I
have
been
working
on.
So
we
I
don't
know
if
this
is
visible
to
everyone,
but
we
did
some
preliminary
benchmarking
for
the
CPU
manager
with
and
without
the
CPU
manager
feature.
B
We
have
some
initial
results
for
some
workloads
which
are
which
are
like
select
kernels
that
perform
some
scientific
operations.
So
we
have
some
initial
results
from
there.
We
also
are
currently
working
on
getting
results
on
neural
network
training.
So
I
have
some
docker
images
here,
but
this
is
still
pending.
So
we
want
to
add
these
four
codes.
For
a
start.
B
This
this
framework
that
we
are
trying
to
build,
will
also
be
extendable
with
other
workloads,
at
least
that's
the
plan.
For
a
start,
what
we
are
trying
to
do
is
make
something
minimal
where,
where
it's
pretty
simple,
where
we
use
the
existing
mechanisms
to
provisionally
something
on
GCP,
run
the
tests
using
existing
mechanisms
such
as
tests
infra
and
then
somehow
plot
it,
at
least
that's
the
first
phase,
so
it
which
mentioned.
C
B
B
C
B
C
C
I
think
that
makes
sense.
I
recently
tried
to
set
up
given
as
end-to-end
tests
out
of
three,
and
that
was
a
huge
pain
that
doesn't
mean
it's
actually
painful
and
maybe
I
was
missing.
Some
easy
hacks,
but
I
I
spent
a
lot
of
time
just
trying
to
get
in
to
entice
working
outside
of
or
like
developing
into
interns
outside
of
core
criminals
repository.
So
it
probably
makes
sense
to
start
there.
B
B
C
B
B
B
So
I
have
some
experience
running
it
on
DCP
and
AWS
like
just
running
manually,
the
you
to
be
cast
while
I
was
working
for
cpu
manager,
ET
does,
nor
did
we
so
it
works.
Not
only
does
it
work
in
the
CSC,
the
environment,
within
communities,
it
also
works
in
your
own
DCP
cluster
and
this
cluster
yeah.
C
A
I
have
a
preference
that
we
start
with
no
de
and
the
cluster
one
Timmy
is
more
interesting
when
you
want
to
do
stuff
with
storage
and
I.
Don't
know
if
that's
like
in.
A
C
A
C
Okay,
I
mean:
do
we
cure,
like
I?
Don't
have
any
specific
objections
to
doing
at
the
node
level?
I
just
want
us
to
have
a
framework
that
would
require
low
maintenance
over
time,
and
so,
if
like,
if
you're
investing
a
month
or
two
getting
no
d2e
to
work,
and
then
we
have
to
reinvest
level
any
case,
I'd
be
bothered
to
make
the
choice.
C
B
I
also
explored
the
classic
test
and
report
back,
so
the
the
feedback
from
sick
testing
was.
They
were
fine.
With
this
plan.
We
need
their
support
because
we
might
need
to
make
some
changes
in
testing
for,
ideally,
we
want
to
make
any
changes
and
you
just
add
the
at
the
test
as
a
periodic
job,
and
then
we
be
done,
but
if
we
need
some
additional
features,
we
can
add
it
there
too.
A
C
C
The
framework,
depending
on
whether
it
lands
in
no
DVD
or
class
level
tests
it
might
become
part
of
signor,
are
suggesting
ideally
like
whichever
test
framework
it
is.
It
should
be
part
of
sick
testing,
so
I
feel
like
this.
Would
this
might
be
something
that
was
actually
per
test
case
rather
than
oh
yeah,.
A
I'll,
give
you
had
a
way
of
structuring
I
hate,
that,
like
political
structures,
need
to
then
bleed
into
code
structures
but
like
if
there
is
a
way
of
differentiating
like
the
framework
from
like
the
actual
test
and
then
having
an
owner's
file
that
associated
the
one
test
with
the
right
people
in
the
right
sig.
That's
probably
good,
but
I
mean
from
a
signal
perspective.
I
I
feel
that,
like
we
want
to
know
his
cpu
manager
is
working
well
across
releases.
So,
like
the
testing
information
is
critical
and
I
mean
I.
Have
no
objections
to
it.
A
C
C
C
C
B
C
A
Well,
thanks
logy,
and
if
there's
no
other
questions
I
guess
we
can
move
on
to
the
next
agenda
item.
So
I
think
the
next
agenda
line
represents
like
what
I
think
this
working
group
should
figure
out
best,
which
is
try
to
get
answers
to
unclear
technical
choices
that
span
SIG's,
so
I,
guess,
Sally
and
Frederick.
You
guys
have
put
together
a
brief
document
on
like
what
you
felt
sick
instrumentation
would
like
effective
monitoring
at
least
device
plugin
monitoring.
Do
you
guys
want
to
walk
sure.
B
E
D
Right
awesome
so
kind
of
the
the
key
objectives
we
wanted
here,
we're
that
we
we
wanted
to
make
metrics
less
centralized
through
the
cubelet
and
through
the
advisor
we
wanted
to
avoid.
D
A
F
G
D
D
A
And
then
to
make
sure
I
understand,
your
question
is
always
finding
out
more
data
fish
when
you're
separating
the
control
plan
versus
a
plane
argument
there
is
that
saying:
is
it
okay
for
the
key
components?
I
have
to
call
back
to
the
qiblah
to
get
the
enriching
data
and
therefore
it's
in
the
control
plane
path,
but
not
inside
the
data
collection
about
hey
all
right
is
that
is
that
a
right
way
of
phrasing?
Your
thinking
about
your
question.
C
D
Like
ideally
right
in
my
in
my
mind,
component
components
would
either
be
given
or
have
some
way
of
obtaining
all
the
necessary
information
right
so
like,
if
you
have
say
like
the
CRI
right,
CRI
plug-in
the
CRI
implementations
actually,
as
far
as
I
can
tell
get
enough
information
about
the
name
of
the
pod.
That
particular
container
belongs
to
through
the
pod
sandbox
metadata,
to
be
able
to
label
any
given
metric
about
a
container
with
the
container
name,
the
pod
name
and
name
space
that
belongs
to
right,
and
so,
though,
that
information.
D
So
when
the
when
the
CRI
implementation
exposes
a
metric,
say
CPU
usage,
it
should
expose
it
with
those
labels
and
not
say
we
rely
on
being
proxy
through
the
cubelet
and
then
having
the
cube.
Let's
say:
oh,
this
is
container
ID
blah
blah
blah
blah
blah,
so
I
need
to
attach
Chladni
and
and
the
namespace
name
to
it.
Does
that
make
sense.
H
D
C
D
C
A
D
So,
let's
do
this
in
my
mind.
One
of
them
is
that
we
don't
you
don't
have
the
cubelet
as
a
bottleneck
for
for
metrics
collection,
if
you,
if
you,
for
instance,
want
to
point
your
metrics
collection
software
at
all
of
these
individually,
so
that
it
can
monitor
that
they
monitor
the
weather.
Metrics
collection
succeeded
or
failed
individually
on
a
per
component
basis.
You
have
that
it
means
that
you
don't
have
any
extra
work,
basically
going
on
in
the
cubelet
more
than
is
needed
it.
It
eliminates
potential
sets
of
bugs
we're
like
the
container
runtime
thought.
D
One
thing
or
the
the
component
thought
thought.
One
thing
based
on
the
information
they've
had,
and
maybe
the
cubelet
had
a
slightly
newer
set
of
information,
and
so
it
attached
accidentally
attached
the
wrong
set
of
labels,
like
that
those
kind
of
bugs
don't
happen
because
all
the
all
that
identity
information
is
being
attached
together.
D
J
It
would
also
mean
that
the
the
the
information
basically
leaks
into
the
into
the
cupola
to
where
the
couplet
needs
to
know,
based
on
which
labels,
what
kind
of
information
to
to
collect.
And
then
we
end
up
with
a
similar
situation.
It's
it's
not
quite
as
bad
but
similar
to
how
the
adviser
is
compiled
into
the
couplet
today.
Only
that
we
have
a
application,
specific
logic
to
add
additional
metadata,
and
that's
basically,
what
we're
trying
to
avoid
here
right.
H
Like
example,
requiring
the
device
like
an
expose,
this
information,
the
pod
ID
in
the
information-
may
not
be
great
like
there
may
be
some
other
reasons
today,
yeah
because
of
what
we
don't
want
to
expose.
This
information,
like
the
API,
is
where,
like
example,
device
device
like
an
API.
We
have
been
holding
using
this
information
because
we
kind
of
don't
want
to
because
of
some
other
reasons
right,
so
acquiring
intimate
monitoring
pipeline
will
only
work
if
you
expose
this
information
may
not
be.
C
You
want
the
plugins
to
do
as
possible.
I
said
like
have
a
really
well-defined
scope,
and
that
way
we
can
have
some
reasonable
performance
and
portability
or
across
environments,
for
example,
on
the
other
hand,
or
monitoring
and
introspection
and
tracing.
You
would
need
as
much
information
as
you
can
get
well,
that's
sort
of
why
I
was
asking
initially
if
it
can
do
just
minimal
amount
of
work
such
that
it
enables
literally
every
possible
extension,
their
own
instrumentation,
like
whether
it's
monitoring
or
logging
or
facing
I
mean.
D
I
know
in
the
past
there
has
been
some
discussion
of
exposing
some
sort
of
like
pod,
identity,
API
or
something
off
of
the
cubelet,
so
that
things
running
on
the
node
could
do
associations
with
different
pot
identities.
I
I'm,
not
personally
a
huge
fan
of
that
approach,
but
it
could
be
one
solution
to
this.
G
A
G
G
A
Yes,
so
if
people
agreed
with
this
requirement,
then
obviously
changes
would
need
to
be
made
to
the
plugin
points.
I
mean
I,
agree
with
Sally
on
the
CRI
front,
that,
like
people
that
are
running
container
runtimes
or
knowing
you
would
monitor
those
container
runtimes
separately
from
the
qubit
itself
and
at
least
for
zri
run
times
that
would
be
running
out
of
tree.
A
If
that
would
be
container
d
or
cry
or
and
on
the
list
keeps
growing
like
production
deployments
of
those
would
still
mana
that
contain
around
time,
and
then
I
agree
that
the
container
run
times
have
sufficient
data
to
map
usage
information
to
the
pot
and
container
boundary.
It's
just
the
question
of
like.
Is
that
having
to
be
done
for
every
third
party
or
not
and.
D
Avoiding
having
more
custom
logic
in
the
cubelet
to
do,
you
know
like
oh
for
device
plugins,
we
always
need
to
add
this
information.
What
we
usually
you
add
this
information
or,
for
you
know,
network
plugins.
We
need
to
add
this
information
for
storage
plugins.
We
need
to
add
this
information
before
it
explodes
it.
You
know
it
also
like
if
we
need
to
add
extra
information
in
the
cubelet.
A
I
Think
you
want
to
like
limited
the
design
at
the
device
level,
because
a
currently
us
packing
is
always
a
positive
integer
resource,
but
even
in
the
future,
it's
possible
to
to
share
device.
I.
Think
like
just
in
midnight
that
device
level
may
have
some
limitation
and
also
you
know,
people
want
to
I
spot
device
level
metrics.
They
don't
have
to
be
associated
with
the
container.
K
Mostly
on
like
how
and
what
the
metrics
look
like
in
sort
of
format
and
stuff,
and
doesn't
necessarily
cover
very
much
of
like
how
different
things
you're
going
to
get
the
metadata
I
I
am
working
on
that
and
things
are
still
in
progress.
But
I
in
terms
of
abstraction
I.
Think
that
they're
explained
I
think
the
right
level
is
going
to
depend
on
the
metric
being
collected
and
I.
Like
the
model
like
this,
where
anyone
can
sort
of
watch
metrics
to
a
pot
or
container.
D
I
D
However,
you
look
like
right
like
if
you
want
to
Bo's
information
broken
down
by
pod
and
pod
container,
but
you
also
want
to
expose
information
by
by
device
in
general
or
something
because
the
device
is
like
shared
across
different
containers,
pods
or
something
like
right.
You
can
choose
to
do
that.
D
A
That
becomes
the
decision
of
the
device
vendor
itself
then
to
the
side
right.
So
if
you
start
treating
like
the
device
has
virtualized
to
some
degree-
and
you
can
do
that-
that's
split
then.
Yes,
you
would
need
to
figure
out
a
way
to
provide
pot
and
container
metrics
with
that
in
mind,
but
like
if
you're
a
device
vendor
who
knows
that
your
devices
are
handed
out
exclusively,
then
you
could
also
still
provide
pottery
container
metrics
and
then
I
guess.
The
key
blow
today
is
very
strongly
assuming
for
accelerator
stats.
That
is
exclusive
and
container
scope.
A
D
And
so
by
by
moving
this
decision,
how
into
the
specific
like,
but
we
want
to
I,
want
to
move.
I
would
like
to
have
monitoring
decisions
moved
as
close
to
the
people
who
have
the
best
idea
about.
What's
actually
going
on
right,
like
Cupid,
cannot
have
the
best
idea
about
everything.
Let's
go
because
it's
well
I
mean
that's
the
problem
to
see
advisor
eight
like
we're,
trying
to
put
all
everything
all
the
logic
for
everything.
D
In
one
place
late,
whereas,
like
you
know,
Nvidia,
presumably
knows
how
they
have
written
their
device
plug
in
the
best,
and
you
know
what
the
associations
are
and
what
the
constraints
are
around
that
system
and
what
the
corner
cases
are
and
whatnot,
and
so
by
saying:
okay
and
Vidya.
Here's
here's,
the
information
that
you
need
to
make
the
associations
between
potentially
between
device
and
pod,
make
the
decisions
that
make
the
best
sense
for
the
Nvidia
device
plug-in
and
expose
the
metrics
that
make
the
most
sense
with
the
association's
that
make
the
most
sense.
D
D
I
Given
that
we
are
also
discussing
like
I,
have
seen
in
nightwalker
and
storage,
really,
they
also
have
similar
requirements.
I
feel
where
perhaps
also
should
look
here,
some
folks
from
seeing
an
eye
on
the
sea,
I
say
to
say,
but
that
they
have
any
special
requirements
in
the
agar
like,
for
example,
I
think
Oh
si
si
they
they
are
not
tied
to
communities
and
I,
don't
think
they.
E
So
that
was
the
that
was
the
issue
we
were
facing
and
that
maybe
maybe
we
do
need
that
Association
and
the
device
wagon
API
to
have
container
and
a
device
that
beam.
But
it
becomes
complicated,
becomes
complex
at
that
point
when
if
we
want
to
have
a
separate
site,
our
continuing
monitoring
container
to
use
the
device
plug
in
India.
D
A
The
issue
I
would
say
that
it
was
a
concern.
A
race
in
the
talk
was
just
how
like
it
would
be
important
for
me
running
production
clusters.
You
know
that
the
source
and
target
for
my
metrics
are
both
mutually
trusted
and
then
how
easy
it
is
to
get
that
mutual
trust
in
in
that
work
in
the
world
presented
here
and
I.
Think
about
a
potential
proxy
yeah.
G
D
In
terms
of
authentication,
there's
basically
two
options
that
we
kind
of
thought
about.
The
option
I
prefer
because
it
leaves
things
still
more
aggregated
is
there
are
actually
several
kind
of
authenticating
proxies
and
we
use
them
extensively
in
open
ships,
for
instance,
and
we
could
probably
use
a
trimmed-down
version
of
one
of
these
that
basically
are
designed
to
sit
in
front
of
api's
and
provide
kubernetes
authentication
right.
D
So
they
they
know
how
to
do
token
based
web
hook
and
certificate
based
web
hook
are
back
and
and
authors,
authentication
and
authentication,
and
so
they
can
provide
that
for
you.
Even
if
you
don't
already
natively
support
that,
and
then
consumers
could
just
use
the
normal
kubernetes
mechanisms
that
they
used
to
use,
and
you
could
write.
D
Kubernetes
are
back
rules
about,
ok,
such-and-such
a
user
or
such-and-such
a
component
is
allowed
to
collect
node,
node,
metrics
or
any
component
any
no
component
or
such
and
such
a
thing
is
allowed
to
collect
node
metrics
only
about
this
particular
device
plug-in
or
only
from
the
CRI
or
whatever,
and
so
you
either
build
that
functionality
and
using
go
libraries
or
you
run.
One
of
these
little
proxies
as
a
sidecar
container
in
front
of
alongside
your
you
know,
alongside
that,
that
is
one
of
the
containers
in
the
demon
set.
They
new
device
plug-in
or
whatever.
I
D
I
I
think
that's
that
that
to
me
is
like
the
goal
of
adding
the
proxy
of
having
the
proxy
right
having
the
easy
to
consume
proxy.
Is
you
don't
have
to
you?
Don't
have
to
choose
to
write
in
kubernetes
specific
integration
in
terms
of
off
you
don't
have
to
deal
with
all
the
kuving's
off.
You
just
drop
this.
You
know
you
only
like
the
way
it
works
for
a
lot
of
the
components
that
we
use.
D
An
open
shift,
for
instance,
is
that
you,
you
have
them
listen
on
localhost
in
the
pod,
and
then
you
have
the
proxy.
You
know
bind
to
all
addresses
or
whatever
and
the
proxy
just
sits
at
the
port
that
normally
the
thing
would
be
monitoring
at
and
intercepts
all
requests
and
says:
does
it
have
a
particular
toe?
Does
it
have
the
appropriate
token
header?
It
goes
and
makes
the
are
back,
call
for
you
if
you
turn
on
making
our
back
calls
and
then,
if,
if
everything
is
copasetic,
it
passes
the
request
through.
G
C
E
D
Exactly
like
there,
we
could
you
know,
hypothetically,
you
could
also
use
prometheus
service
monitors
from
the
Prometheus
operator
right,
like
it's
I,
I
kind
of
left
that
open,
but
there's
a
number
of
options
that
we
can
do
that
kind
of
fall
under
kind
of
some
standard
humanities.
How
do
we
do
endpoint
discovery
in
general?
The.
A
C
Think
the
summary
API
is
was
never
meant
to
be
just
the
call
monitoring
pie.
Plate
was
meant
to
be
this
placeholder
until
we
have
this
alternate
pipeline.
So,
like
I
saying
earlier,
I
think
this
question
has
now
boiled
down
to
the
specifics,
how
somebody
would
be
out
of
the
qubit
and
like
how
cubelet
would
would
empower
other
other
third
party.
A
So
I
I
have
no
disagreement.
That
figuring
out
the
way
by
which
the
keyboard
could
make
this
information
down
to
third
parties
is
the
obvious
next
step,
I
think,
but
I
do
think
it
was
very
beneficial
to
at
least
others.
Discussions
understand
that,
like
being
able
to
get
metrics
delivered
from
the
author,
as
close
as
possible,
seems
to
be
like
a
pretty
uniform
agreement
across
the
group
right.
So
yeah.
C
D
So
I
mean
like
if
we
say
if
we
say
monitoring
should
be
distributed
or
we
design
a
system
where
monitoring
can
be
distributed,
and
then
someone
chooses
to
implement
all
of
these
constraints
on
top
of
the
advisor
like.
That
is
their
prerogative
right,
but
as
long
as
as
long
as
we
have
a
sufficiently
flexible
system
where
people
can
and
and
try
to
write
this
just
like
distributed
monitoring
like
non
distributed,
monitoring
should
just
strictly
be
a
subset
of
that
it
should
fall
into
place
on.
D
D
Of
metrics
and
how
we
deal
with
guarantees,
so
I
had
kind
of
imagined
this
system
in
which
you
basically
document
names
and
semantics
and
say
you
always
have
to
implement
these
metrics.
You
may
choose
to
implement
these
metrics,
but
if
you
do
they
have.
We
have
semantics
that
we
say
you
know
like
if
you
implement
Network
TX,
that's
always
Network
transmitted
bytes
and
if
you're
going
to
implement
network
transmitted
bytes
give
it
the
network
TX
name
right
and
then
there's
like
a
third
class
of
metrics,
which
is
this
whatever
like.
D
My
concern
with
that
was
mainly
that
alpha
and
beta
imply
progression
right
like
it
doesn't
make
a
ton
of
sense
to
me
to
have
certain
metrics
as
alpha
level
and
just
have
them
Alba
forever,
because
it
seems
like,
like
the
terms
alpha
and
beta
or
whatever
of
imply
that
eventually
had
the
Alpha
metric
will
become
stable
and
I.
Think
there's
always
going
to
be
metrics
that
we
don't
you
know
we
don't
want
to
guarantee
or
we
we
can't
know
the
entire
set
of
metrics
right.
D
We
don't
know
what
metrics
and
video
is
gonna
choose
to
expose.
We
don't
know
you
know
we
don't
know
what
metrics
certain
seer
eyes
might
choose
to
expose.
So
we
want
to
kind
of
have
this
positive
metrics,
where
we
don't
make
any
guarantees
about
them.
That
they're,
but
they're
never
gonna
become
stable,
but
they're
not
alpha,
because
they're
not
going
to
become.
K
D
I
was
kind
of
using
like
me
as
like
the
broader
kubernetes
developers,
right
like
where
we
as
kubernetes
developers,
are
not
necessarily
gonna,
say
and
Vidia
always
has
you
know
we're
not
gonna
know
what
metrics
and
videos
gonna
have,
and
we
don't
I
think
that
we
shouldn't
try
to
prescribe
what
metrics
and
vidya
has,
but
I
do.
Think
it's
valuable,
especially
in
the
case
of
things
like
CRI,
to
say
all
right.
You
might
not
expose
networking
metrics,
but
if
you
do,
you
should
expose
them
like
this.
You
should
expose
like
these
ones.
D
D
You
may
choose
to
expose
network
this,
these
types
of
network,
if
you
this
was
just
name
starting
example:
business
I'm,
not
saying
specific
ones.
You
may
choose
to
expose
network
because
people
find
that
useful
and
if
you
do,
you
should
expose
it
like
with
these
names,
because
you
know
people
want
these
for
confidence,
but
then
there's
all,
but
always
this
third
class
of
metrics.
That's,
like
you
know,
specific
to
Nvidia
or
specific.
D
K
Yes,
I
think
I
I
think
we're
closer
than
maybe
originally
seen.
I
was
thinking
of
it
more
from
the
perspective
of
say,
a
device
monitoring
agent
maintainer
that
you
know,
even
though
a
certain
metric
may
not
be
available
in
all
deployments
that
if
you
run
this
particular
monitoring
agent,
then
certain
metrics
are
alpha
versus
GNA
versus
I
was
thinking
more
from
that
perspective.
K
I
do
agree
that
it's
useful
for
us
as
a
community
to
keep
a
list
of
known
metrics
so
that,
if
I'm,
for
example,
implementing
a
new
CRI,
runtime
and
I
want
to
expose
the
same
metrics
as
others,
I
can
go
to
someplace
easy
I
think
that's
certainly
useful,
but
I
I
do
don't
think
and
I
don't
want
to
spend
too
much
more
time
care
because
I'm,
not
sure
I'm,
the
other
people
are
interested.
I.
C
Like
Commedia
offers
no
versioning,
yes,
I
think
at
least
recommending
it's
not
mandating
like
just
recommending
some
naming
schema
such
that
the
the
monitoring
experience
is
consistent
across
plugins
in
a
Karuna.
The
environment
would
probably
help
most
of
the
operators.
I
mean
we
do
subconscious
naming.
D
We
do
already
have
that
to
a
certain
extent,
it's
not
universally
followed
the
biggest
individual
component
that
doesn't
follow.
It
is
actually
see
advisor,
but
we
do
have
instrumentation
guidelines
that
all
kubernetes
components
are
supposed
to
follow
that
prescribe
metric
naming
label
naming
label
semantics
when
to
use
what
labels,
when
not
to
use
certain
labels,
for
instance,
never
use
the
UID
label
and
stuff
like
that,
and.
K
A
I
we
can
like
little
get
your
straight,
but
I'm
worried
that
my
laptop
battery
is
about
to
die
and
I
don't
stop
on
winning
the
meeting
last
forever.
But
I
wanted
to
thank
Sally
and
Frederick
for
putting
this
information
out
and
like
joining
the
call
today
and
then
like.
It
sounds
like
the
next
step.
That
I
hear
is
that
we
need
to
like
come
to
some
consensus
on,
like
the
set
of
options
that
are
worth
exploring
for
making
the
information
available
from
the
cubelet
and
it
sounds
like
bishops
are
like
on
the
Google
side.