►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20210114
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Okay,
yes,
so
right
now
we
have
a
camp
proposal
about
the
load
of
your
scheduling
and
we
include
two
plugins.
Those
two
plugins
may
need
to
retrieve
some
real-time
metrics,
such
as
average
and
standard
deviation
of
cpu
and
memory
usage
for
all
nodes
and
right
now
the
design
includes
a
third
party
which
is
called
load
water.
So
the
load
water
needs
to
get
those
node
metrics
and
keep
them
store
them.
It's
responsible
to
store
them
or
keep
them,
and
then
to
expose
some
apis
to
other
scheduling
plugins.
B
So
those
plugins
can
consume
those
data.
So
so
I'm
I'm
just
wondering
like
because
I
know
most
of
the
companies
have
their
own.
A
monitoring
stack
such
as
splunk
promise
us
by
default,
and
those
monitors
stack
already
kind
of
implement
the
functionality
we
want
to
rely
on
the
third-party
component
called
load
water.
So
whether
we
should
just
include
a
package
to
support
different
popular
monitoring
stack,
we
should
always
just
support
the
load.
Virtual
api.
C
A
C
C
B
Yeah
yeah,
so,
in
addition,
so
right
now
the
the
load
where
scheduler
plugin
plugins
already
supported
the
load
water,
api,
but
load
water
right
now
is
not
maintained
by
kubernetes.
B
Scheduler
plugin
ripple
is
maintained
by
paypal
right
and
we
initially
designed
that
because
we
want
to
extend
the
data
analysis
part
to
more
advanced
algorithm,
but
right
now
those
plugins
still
do
not
need
to
use
those
advanced
algorithm
and
it's
what
those
plugins
need
is
just
some
average
and
standard
deviation
of
cpu
and
memory
usage.
So
such
aggregation
was
already
like,
so
so
a
lot
of
monetary
stacks
already
provide
such
aggregations.
B
For
example,
permissions.
You
can
query
promises
to
directly
get
the
average
standard
deviation
for
a
particular
metric
in
a
certain
time
window,
and
I
think
splunk
support
that
as
well
and
then
so
so,
in
addition
to
support
apis
going
to
the
load
watcher,
should
we
support
more?
I
mean,
should
we
support
like
permissions
apis
and
splunk
apis
as
well,
so
people
who
do
not
want
to
deploy
load
watcher
can
use
their
own
monitoring
stack.
A
Directly,
so
I
don't
know
if
anyone
here
is
familiar
with
with
those
mechanics,
but
I
would
suggest
that
you
ask
this
question
in
sync:
instrumentation,
so
you'll
be
able
to
get
better
insight,
but
I'll
I'm
wondering
if
anyone
on
the
call
is
familiar
with
lord
watcher
and
and.
B
B
So
so,
if
it's
just
doing
the
aggregation,
such
as
taking
the
average
and
standard
deviation,
I
think
other
monitoring
stacks
are
also
supporting
that,
especially
like
when
I
talk
to
people
from
red
hat,
for
example,
and
they
openshift
by
default,
use
promises
monitoring
stack.
So
for
them
it's
just
load.
Water
is
redundant
component
because
it
get
aggregated
data
from
permissions
and
then
expose
it
again
within
the
scheduler,
and
then
the
scheduler
plugins
will
consume
data
from
blood
water.
B
B
And
I
know
so,
most
of
the
companies
will
probably
use
either
permissions
or
splunk
out,
develop
their
own
monitoring
stack
and
for
all
monitoring
stack.
They
they
will
expose
data
of
some
level
of
aggregation
erased
apis.
So
the
so,
if
we
add
support
in
loadable
scheduler
plugins
for
some
popular
apis
like
permissions
blank,
so
people
have
flexibility
and
then
they
are
not
limited
to
use
only
load
water.
D
B
Oh
okay,
okay,
yes,
yes,
we
are
indeed,
we
are
indeed
planning
to
work
on
the
the
support
of,
for
example,
promises
because
really
there's
a
lot
of
people
using
promises
by
default
for
their
monitoring
stack
and
we
we
definitely
will
leave
the
options
as
configurations
to
configure
it
either
for
permissions
or
for
load
virtual
for
splunk.
B
A
A
link
to
the
cap
on
the
chat
just
so
we're
familiar
with
the
context
more
immediately
right.
C
C
So
the
best
way
forward
is
still
that
make
it
a
parameter
in
the
plugins
and
the
config
the
target
url,
so
that
in
the
plugin
runtime
you
can
fetch
the
data
from
the
load
watcher
and
in
the
water
side
you
can
do
whatever
you
want
to
aggregate
and
do
what
kind
of
other
things
or
to
make
it
a
more
common
framework
to
to
consume
the
the
kind
of
metric
data.
So
that
is,
I
think,
that's
the
original
way
to
going
forward.
C
Mean
I
mean
so
right
now.
The
the
key
part
is:
how
do
you
define
your
target
load
watchers
so
that
the
water
data
can
be
consumed
by
plugging
right
so
right
now
the
option
is
that
you
have
to
define
that
as
a
parameter
in
your
plug-in
argument,
right
yeah.
If
I
understand
correctly,
you
are
pursuing
that
make
it
more
more.
E
E
C
Part
so
that
upon
the,
for
example,
the
start
of
the
schedule
you
are
aware
of
that
there
is
a
component
that
can
fit
you
the
monitoring
data.
So
I
think
that
eventual
goal
might
be
a
little
challenging
might
be
a
little
challenging
right
now,
because
you
can't
not
assume
those
kind
of
components,
existing
environment
for
all.
C
B
We
will
still
support
load
water,
definitely
because
we
cannot
assume
other
everyone
deploy
permission
source
blank
for
example,
but
so,
for
example,
permission
so
so
so
what
load
water
is
mainly
doing
right
now
is
the
aggregation
of
data
right.
It
can
get
raw
data
from
from
kubernetes
metric
apis
and
then
keep
it
in
the
time
window
and
do
the
aggregation,
but
such
aggregation
was
also
provided
by
promises
and
splunk.
B
So
what
I'm
suggesting
is,
instead
of
like
forcing
the
the
low
loadout
scheduler
plugins
to
use
only
load
version
api.
We
can
make
it
configurable,
for
example,
like
we
can
provide
the
premises
endpoint
and
so
as
an
option.
We
can
provide
splunk
our
splunk
api
as
endpoint
as
the
option,
and
then
we
can
denote
which
option
you
want
to
use
when
users
deploy
their
plugins.
B
Because
all
of
those
would
be
rest
apis
and
all
all
of
the
apis,
all
of
those
monitors
that
can
return
you,
the
aggregated
data
we
need.
A
So
let
me
try
to
just
to
try
to
recap
and
make
sure
that
everybody's
at
the
same
page,
so
you
have
now
that
we
we're
looking
at
at
least
I'm
looking
at
the
kip,
I'm
looking
at
the
graph.
A
So
you
have
a
component
called
load
watcher
which
is
like
a
pod
or
a
service
running
outside
the
scheduler,
explore
an
end
point
for
your
plugin.
That
is
running
in
the
scheduler
to
look
up.
Metrics
right,
yep,
aggregated
metrics
and
you're.
Saying
that
you
want
there
is.
There
is
a
possibility
to
basically
not
have
load
watcher
at
all
directly
fetch
these
aggregated
data
from
another
endpoint
and
you're,
saying
that
it
could
be
prometheus
directly
or
yes.
A
B
So
I
I
think
I
I
know
how
to
change
the
existing
code
to
to
allow
to
support
that
yeah.
It's
just.
I
would
like
to
know
general
your
opinion
whether
the
community
will
support
that.
Now.
It's
some
some
features.
Other
people
will
will
like
yeah.
A
I
think
you
would
want
to
get
in
touch
with
the
kip
author
and
see
their
opinion
on
on
this
one,
but
I
don't
see
a
reason
if
you're
able
to
abstract
that
interface
inside
the
plugin,
and
then
you
provide
different
implementations
right,
one
that
talks
to
load
like
knows
how
to
talk
to
load
watcher
another
one
knows
how
to
talk
to
prometheus,
etc.
I
don't
see
why
not
and
as
way
mentioned,
you
could
have
a
plug-in
parameter
to
allow
you
to
select
which
exact
endpoint
for
metric
for
letters.
A
B
Yeah
yeah,
definitely
so
you
are.
This
also
helps
sort
out
the
options
to
to
enable
it
yeah.
This
is
something
I
want
to
do
and
I
just
want
to
get
everybody's
opinion
about
it,
and
I
see
so
so.
Yes,
we
we
want
to.
We
actually
want
to
support
this
option,
because
most
of
our
clusters
are
using
perm
measures
as
the
monitoring
stack
by
default.
B
I
will
probably
talk
to
older
people.
We
work
together
on
the
cap
and
then
we
will
later
bring
this
again.
You.
A
Can
you
can
open
an
issue
under
the
scheduler
plugins
and
get
the
discussion
started
there.
A
Any
other
topics
anyone
wants
to
discuss.
D
There
is
one
one
announcement
that
I
would
like
to
to
share
so
this
time.
Starting
from
this
release
the
release
team,
the
secret
release
is
not
going
to
automatically
track
caps.
We
we
have
to
opt
in
so
at
some
point.
We
need
to
as
a
seed.
We
need
to
decide
with
which
caps
we're
gonna
graduate
or
or
add
to
the
release,
and
then
we
have
to
communicate
that
to
the
to
seek
release.
C
D
Yeah,
so
in
that
sense
I
would
like
to
ask:
let's
see
if
we
have
some
particular
caps,
we
were
really
thinking
of.
F
We
have
the
random
downscale
one
that
I've
been
trying
to
get
the
feedback
put
in.
I
don't
know
if
I'll
target
that,
for
this
release.
D
Yeah,
we
definitely
want
that,
but
that's
more
on
seek
apps.
Oh
true,
right,
yep.
A
So
we
have
the
node
name:
sorry,
no
space,
selector
and
pod
affinity
and
the
affinity
that
I'm
working
on.
D
Aware
sounds
good
from
my
side.
I
would
like
to
add
the
v1
beta
2
component
config,
but
but
that
doesn't
imply
any
any
new
caps.
So
that's
outside
of
that
kind
of
tracking.