►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20210128
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
All
right,
hi
everyone,
so
this
meeting
is
recorded
and
will
be
uploaded
to
youtube
so
yeah
just
to
follow
up
on
waze
pr
regarding
the
surfacing
the
field
plug-in
name.
A
C
Very
high
level
summary
on
that.
Pr
is
that,
in
accordance
that
to
make
efficient
moving
between
different
queues,
we
have
to
know
which
plugin
in
the
part
failed
by
and
in
the
first
pr
I
introduced
the
fair
planning
in
the
status
object,
data
structure
and
abdullah's
idea
is
that
we,
if
we
only
care
about
the
specific
status
like
on
schedule
and
on
scheduler
unresolvable?
Maybe
we
should
change
the
name
to
on
to
on
scheduler
product
instead
of
failed
plugging.
C
So
I
I
think
about
that
and
think
that
maybe
we
should
in
the
very
beginning,
no
matter
the
latter
logic
is
just
in
the
beginning.
We
should
record
whatever
the
the
the
plugin
name.
It
failed
by
no
matter
it's
the
abnormal
error
or
meaningful
scheduling,
error
like
on
schedule.
C
So
in
the
first
beginning
in
the
status,
I
still
keep
the
name
as
fair
plugin
and
but
in
the
later
logic,
in
the
runtime,
especially
in
the
fifth
era,
I
will
include
a
field
called
unscheduled
plugin,
so
because
feed
error
only
makes
sense
when
you,
when
you
are
doing
some
phase
like
pre-filter
and
filter,
so
it
doesn't
quite
make
sense.
If
you
return
the
abdomen
error
in
our
current
workflow,
that
error
is
just
being
totally
written
instead
of
recognized
like
an
indicator
to
moving
parcel
sort
of
like
so
this
is
the
change.
A
So
we
have
two
items
on
the
agenda
mike
particularly.
D
Yeah,
so
I
just
wanted
to
talk
about
these
two
things.
One's
new
one
is
older,
ongoing.
The
first
one
is
for
the
d
scheduler.
I
linked
an
issue
and
a
work
in
progress.
Pr
here.
That's
just
talking
about
trying
to
add
what
I'm
calling
informed
strategies
to
the
descheduler.
D
Basically
have
some
strategies
able
to
optionally
run
with
an
informer
in
their
own
separate
threads
from
the
periodic
weight
loop.
That
is
how
the
descheduler
currently
has
to
run
or
as
a
crown
job.
Basically
the
same
thing.
D
So
I
started
to
started
this
pr
just
using
the
two
node
strategies
as
a
starting
point
to
get
this
pattern
down,
and
so
those
those
are
node
affinity
and
node
taints
those
two
strategies
that
justific
pods
based
on
if
the
node's
labels
have
changed
or
the
nodes
taints
have
changed.
D
D
So
that's
that's
the
main
thing
that
we're
looking
at,
but
there's
also
some
design
input
there.
I
have
more
of
the
description
in
the
issue
itself
and
the
working
product.
The
progress.
Pr
is
there.
So
if
anyone
just
wants
to
check
that
out,
get
some
feedback,
that
would
be
really
great.
This
is
kind
of
a
change
from
I
mean
it's
a
big
change
from
how
the
descheduler
is
currently
designed,
but
it's
something
that
a
lot
of
people
ask
about.
D
At
least
I
do
all
the
time
people
want
digischeduler
to
immediately
react
to
certain
changes
and
some
of
the
strategies
that
the
scheduler
has
like
pod,
topology
spreading
or
like
low
note
utilization
are
probably
too
complicated
to
implement
that.
But
you
know
it
relies
on
just
too
many
different
types
of
fluctuating
events
in
the
cluster
to
have
a
stable.
D
You
know
this
is
what
triggers
a
run
of
the
strategy,
but
I
don't
see
why
we
can't
have
this
kind
of
hybrid
design
where
some
strategies
can
run
like
that
and
others
don't
have
to
so
that's
in
there.
If
anyone
wants
to
check
that
out,
I
don't
know
if
anyone
has
any
comments
on
it
right
now,
but
if
not,
I
can
go
ahead
and
talk
about
this
second
item.
I
have
here.
A
One
one
thing
to
note
here:
yeah:
I
I
like
this.
I
like
that
you're
going
that
direction
of
you
know
rather
than
running
as
a
crown
job
but
reacting
to
to
events,
and
one
thing
to
look
at
is
what
we
and
aldo
in
the
past
have
discussed
like
that
framework.
For
you
know,
event,
registration
and
whatnot,
so
you
could
probably
benefit
from
the
same
ideas.
A
So
so
that's
my
feedback
or
suggestion.
Basically-
and
I
I
do
agree
with
you-
that,
like
a
from
first
glance
like
some
strategies,
it's
to
be
hard
to
react
to
events,
you
just
need
because
of
their
complexity,
so
having
a
hybrid
approach
makes
sense,
but
for
the
ones
that
do
they
could,
for
example,
register
to
some
events
that
they
can.
You
know,
react
to
efficiently
so
yeah.
A
Basically,
my
feedback
is
look
at
what
we
and
is
doing
right
now
and
all
those
talking
from
the
past
about
how
we
do
efficient,
recurring,
you're,
probably
gonna.
D
A
C
D
Yeah
and
reusing
like
whatever
we
can
kind
of
helps
with
the
other
goal
of
like
aligning
the
descheduler
more
with
how
the
scheduler
runs,
which
kind
of
goes
into
the
next
point
here
about
cleaning
up
the
scheduler
dependencies
that
I
had.
If,
if
we're
all
good
on
the
first
one,
I
can
just
update
on
that.
D
So
this
is
an
older
issue
that
we
open
it's
almost
a
year
old.
Now
we
started
the
goal
of
trying
to
clean
up
scheduler
dependencies
on
internal
kubernetes
packages,
basically
with
the
ultimate
goal
of
being
able
to
independently
import
plug-ins,
and
maybe
even
the
framework
sections
itself
in
other
projects
like
the
d-scheduler,
so
that
the
d-scheduler
could
use
be
tied
to
the
exact
same
logic
as
the
scheduler
and
create
a
beautiful
harmony.
D
D
The
approach
that
I
think
that
we
really
need
to
take
to
this,
because
when
I
started
this
issue
is
just
kind
of
like
anyone
that
finds
any
helpers
feel
free
to
come
in
and
just
clean
them
up
all
out
of
the
scheduler
packages,
which
we
got
a
lot
of
help
and
contributions
from
that.
But
it
also
is
a
little
all
over
the
place,
and
some
of
these
helpers
are
touching
a
lot
of
different
places
in
the
code
base
which
need
a
lot
of
approvers
looking
at
it
now.
D
D
A
lot
of
them
are
actually,
there
are
a
number
that
aren't
so
tied
in
that
could
probably
be
pretty
close
to
being
able
to
be
imported
in
other
places
without
bringing
in
the
rest
of
core
kubernetes
with
them,
but
there
are
some
that
have
some
tough
dependencies
slick,
some
plugins,
I'm
looking
at
node
resources
right
now.
These
node
resource
plugins
depend
on
some
feature:
gating,
which
is
not
easily
made
external.
D
So
I
think
similar
to
how
not
all
the
d
scheduler
plug-ins
will
be
able
to
be
run
informed.
We
might
not
be
able
to
break
the
dependencies
on
all
these
plugins,
but
the
main
point
that
I
want
to
say
is
that,
starting
at
the
plug-in
level
and
then
working
our
way
back
is
probably
the
approach
that
we
want
to
take
now
and
I'll
update
this
issue.
D
Saying
that
and
saying
what
I
found
about
this
opened
a
couple
pr's
the
past
couple
days,
just
from
that
approach,
starting
with
like
volume
zone
stuff,
just
whatever
small
dependencies
that
could
be
moved
but
yeah.
A
I
have
a
of
suggestions
here,
yeah
one
with
relate
regarding
cube
features.
I
like
I.
I
gather
that
your
the
most
important
thing
is
to
deco,
like
have
the
plugins
not
depend
on
any
other
packages
right,
so
that
this
is
the
most
important
part
from
perspective
of
having
external
components
linking
to
the
scheduler,
you
don't
care
about
the
scheduler
core
per
se,
you
mostly
care
about
the
framework
and
the
plugins,
and
so
what
I
suggest
here
is
for
resource
for
plugins.
That
needs
features
like
depend
on
features.
A
We
should
pass
them
as
parameters,
somehow
not
necessarily
as
a
plug-in
config
parameter
like
we
don't
want
to
be
part
of
that
api,
but
I'm
wondering
if
there
is
a
way
to
to
pass
them
in
as
a
flag
rather
than
the
plugin
itself,
linking
to
the
feature
package.
A
A
So
that's
one!
The
other
thing
is:
have
you
looked
at
ways
to
automate
this?
Basically,
maybe
we
should
have
an
import
enforcer
somewhere
in
the
framework
package
for
the
plugins
that
we
know
is
cleaned
up
so
that
we
don't
regress
that
we
enforce
that
they
don't
link,
they
don't
link
specific
packages
and
we
prevent
adding
ones
that
we
don't
want.
And
then
we
keep
updating
the
enforcer
as
we
clean.
D
D
Yeah
yeah,
that's
a
good
idea.
I
don't
know
how.
I
know
that
kubernetes
has
like
these
import
restrictions
sections.
I
don't
know
how
to
configure
those
exactly,
but
I
know
I
know
what
you're
talking
about
and
that's
a
good
idea
to
prevent
the
regression
and
what
you
said
about
the
feature
getting
to
yeah
like
a
lot
of
these
are
really
just
checking
like
if
this
features
enabled
then
do
this
section
of
code.
D
D
So
those
are
those
are
just
my
two
points,
any
feedback
on
there.
I
would
really
like
to
get
moving
on
the
scheduler
dependencies
section
now.
I
also
think
that
the
more
that
we
can
clean
up
like
starting
with
the
plugins
and
maybe
going
into
the
framework
and
breaking
that
out,
because
I
think
before
we
talked
about
maybe
moving
that
to
staging
like
last
year.
I
don't
know
if
that's
still
a
plan
more
of
a
long-term
goal,
but
that
would
make
compiling
custom
schedulers
a
lot
easier.
A
Just
thinking
about
this
like
quickly,
I
think
and
aldo
can
probably
correct
me
you
could
regarding
feature
flags.
You
could
change
the
internal
type
to
add
anything
you
want
and
that
wouldn't
be
like
part
of
the
api,
because
it's
not
in
the
staging
repo,
where
the
extent
of
the
version
api
exists.
A
So
that's
fine
like
so
you
could.
You
could
change
the
internal
type
of
the
of
any
plug-in
config
to
include
flags
to
to
basically
set
the
feature
gates
that
you
want
to
look
at
and
you
should
be
fine.
D
A
He
wants
to
cut
the
dependency
on
the
feature
package
so
that,
like
the
plugins,
don't
link
that
package
in
and
what
I
was
suggesting
is
the
scheduler
itself
will
depend
on
it.
Basically,
when
you
instantiate
the
plugin
you
could,
you
could
set
these
flags
and
fields
that
we
add
to
the
internal
conflict,
types
that
make
sense.
E
E
A
Yeah
we
had
a
hack
in
the
past
that
worked,
but
yeah
I
mean
either
way
I
think,
should
be,
should
be
doable.
C
C
A
A
E
A
But
I
mean
we
should
check
if
that's
an
acceptable
pattern,
basically
slightly
departing
from
the
external
one.
It's
just
an
idea
how
we
can
you
know
plum
in
these
flags.
A
The
other
one
is
again
to
encapsulate
them.
You
know
like
there
would
be
like
a
yeah,
which
I
think
it
would
be
in
the
registry.
Basically,
you
need
to
change
the
way
that
we
the
new
functions
of
each
plugin,
which
is
also
a
valid
option.
I
think.
D
Yeah
I
mean
the
the
implementation
parts,
the
details.
We
can
talk
about
and
a
pr
play
around
with
different
setups
to
see
how
it
looks.
I
think
that
the
point
of
what
you're
saying
is
that
there's
other
ways
that
we
can
check
these
feature
gates
without
having
to
link
right
out
to
package
features
and
check
you
know.
Is
this
enabled
that's
the
point.
D
Okay,
well,
that's
that's
all
that
I
had
to
say
on
these
two
things.
Please
check
out
those
two
links
and
I'll
be
updating
the
dependency
issue
with
some
more
updates.
If
anyone
else
wants
to
keep
helping
out
with
that
I'll,
look
at
the
imports
of
the
plugins
and
see
what
we
can
clean
up.
Thank
you.
E
E
A
Was
the
only
two
items
on
the
agenda?
Any
comments.
E
D
E
I
think
I
have
a
contributor
that
could
help
in
one
or
two
weeks
so
yeah,
if
you
think
some
of
them
are
higher
priority
than
those
that
are
abandoned.
I
think
we
can.
I
can
ask
this
contributor
to
to
do
them.