►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20201217
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,
sorry,
I'm
five
minutes
late.
So,
as
you
know,
this
meeting
is
recorded
and
we'll
be
uploaded
to
youtube.
We
can
open
the
agenda,
but
one
action.
One
item
I
wanted
to
go
through
is
the
list
of
features
we're
planning
for
for
121.
A
We
have
another
item
here,
which
is
from
our
tool,
discuss,
feasible
solutions
to
fall
back
on
if
metrics
are
not
available.
A
B
Abdul
yeah
good
morning
also
a
couple
of
months
back.
We
discussed
about
real
load
over
scheduling,
plugins
and
we
have
contributed
kp
for
that.
I
have
certain
things
to
discuss
and
seek
advice
or
solutions
for
for
a
specific
problem.
So
the
problem
statement
is
this:
when
so,
the
plug-in
that
we
have
depends
on
metrics
provider
to
get
the
usage
metrics
of
a
cluster.
B
So
if
this
metric
server
or
provider
is
not
available
like
let's
say
it
crashes,
or
fails
for
a
long
time,
what
solutions
or
what?
What?
What
is?
What
is
something
feasible
that
we
could
do
so
that
we
can
still
achieve
the
goal
of
the
plug-in,
which
is
to
do
bin
packing
so
per
the
initial
design?
B
I
had
something
in
mind
to
fall
back
to
allocation
based
scheduling
instead
of
using
metrics,
but
I
want
to
know
if
something
else
is
possible,
for
example,
changing
the
scheduler
profile
of
parts
dynamically
or
something
of
that
sort.
C
So,
if
I
understand
correctly
so
you
are
trying
to
see
if
there
are
some
dynamic
kind
of
functionality
in
framework,
so
that
in
some
cases
that
your
plugins
dependence
is
not
present
due
to
some.
Whatever
reason
you
want
to
sort
of
disable
that
plugging
or
switch
to
another
plugin.
So
that
is
your
intention
right.
B
Yeah,
either
switch
to
android
plugin
or
contain
some
failures,
stayed
within
the
same
plugin
and
fall
back
to
some
other.
You
know
solution
which
doesn't
depend
on
metrics
anything
of
that
sort,
which
would
be
like
a
good
solution,
unacceptable.
C
I
don't
think
if
you
specify
a
specific
profile,
you
can
dynamic
change.
The
register
plugin
within
your
profile,
that
is,
is
not
supported,
but
you
can
just
ignore
that
plugin.
If
your
practice
dependency
is
not
present,
that
is
possible,
so
just
to
know
that
that
should
go
for.
A
You
like
more
more
concretely
one
thing
you
can
do:
plugins
have
access
to
shared
shared
state
called
cycle
state.
A
One
thing
you
could
do,
for
example,
in
a
pre-filter
you
can
check
if,
like
which
set
of
two
plugins,
you
want
to
have
run
in
that
cycle
and
you
can
create
a
state
that
says
okay
plug
in
one
plugin
two
now
when
filter
runs
or
even
pre-filter.
For
these
two
plugins,
like
like
that
filter
that
prefers
that
that
checks
I
mean
like
dynamically,
which
which
plug-in
should
run,
should
run
the
very
first
one.
A
So
it
sets
that
flag
in
cycle
state
and
then
and
then
those
two
plugins
again
they
play
nicely
together.
They
check.
Okay,
I
should
run
or
the
other
one
should
run
and
like
this
is
a
like.
This
is
the
one
way
that
I
can
think
of
where
you
can
do
this
dynamically,
so
you
would
have
all
the
plugins
registered.
You
have
to
do
that
because
static
file.
A
B
To
do
yeah,
even
that
is
fine,
so
a
follow-up
question
on
that,
so
the
the
plugin
that
I
have
that
we
have
tries
to
do
back
bin
packing
based
on
usage,
so
something
I
would
want
to
fall
back
would
be
say
logic
similar
to
the
native
plugin,
which
is
most
located
resources,
so
is
it?
Would
it
be
fine
to
build
something
duplicate
or
is
it
okay?
If
the
plugin
that
I
have
depends
on
most
allocated
resources
plugin
to
be
able
to
do
this.
A
B
In
some
cases,
so
what
I'm
trying
to
say
is
the
so
the
solution
you
mentioned
to
switch
between
two
different
plugins,
so
the
plugin
that
we're
contributing
is
already
one
of
them
and
the
fallback
would
be
the
native
plugin
which
is
okay,
so
is
it
okay
to,
for
the
you
know,
the
within
the
profile
to
depend
on
calling
a
score
of
a
different
plugin.
A
I
mean
you
would
have
to
yeah
you
would
you
would
have
to
modify
the
I'm
wondering
if,
if
we
should
have
some
sort
of
like
a
generic
way
of
saying
dynamically,
whether
a
plugin
should
run
or
not
yeah,
and
then
you
can
configure
that
on
the
fly.
E
Have
access
to
what
is
registered
in
the
profile,
and
you
could
just
similarly
like
check
off
of
that
and
enable
or
disable
something
in
your
filter,
plug-in
like
in
pre-filter
check
that
I
mean
we
could.
A
Look
like
I
mean
technically
when
we
create
the
cycle,
we
create
the
cycle
state
on
each
scheduling
cycle,
so
we
could
change
like
we
could
have
the
new
function,
for
example,
take
on
a
parameter
like
with
this
key
value
and-
and
it
would
be
a
known
key
value,
which
is
the
set
of
plugins
that
will
that
will
run
in
this
cycle.
A
And
the
caller,
or
whoever
is
creating
the
cycle
state
would
know,
would
yeah
we
need
to
to
to
to
basically
populate
this
and
I'm
guessing.
We
do
have
that
information
at
that
time,
but
but
we
need,
like
probably
some
refactoring,
make
sure
that
this
whole
thing
works
nicely
with
nice
dependencies.
F
Can
make
some
comments
and
yeah,
so
this
is
from
apple
sorry,
I
I
I
I
was
late,
so
I
I
just
heard
we're
talking
about
some
probably
dynamic
and
the
config
of
the
plugin
other
thing.
So
I
think
we
have
a
requirement,
probably
similar
one
and
I
shared
with
we
and
probably
offline
and
where
I'll
go
so
so
far,
the
the
plugin
and
the
scheduling
framework
supports
right.
F
We
create
multiple
profiles
with
the
customer
plugins,
but
it's
aesthetically
and
configured
so
what
we
have
used
cases
when
we
create
the
custom
scheduling,
sometimes
maybe,
depending
on
the
cluster
runtime
information,
that
we
want
yeah
selectively
or
dynamic,
configure
plugins.
So
this
is
something
I
think
in
long
run,
probably
useful.
F
So
one
example-
and
we
have
is
we
want
to
have
some
advanced
scheduling
and
do
some
optimization
said
if
we
have
a
group
of
homogeneous
and
ports
right
and
when
we're
scoring
some
of
them,
and
maybe
we
can
reuse
the
previous
results
and
yeah
to
assign
the
nodes
to
similar
identical
ports.
But
whether
or
not
that's
yeah
is
a
very
useful
feature,
but
by
that
we-
and
sometimes
maybe
we
want
to
skip
under
some
plug-in,
but
the
net
has
to
be
decided
and
determined
at
wrong
time.
F
So
overall-
and
I
I
just
thinking
yeah-
that's
probably
something
again-
the
this
group
community
can
think
about
it,
whether
or
not
that
is
the
important
thing
and
dynamically
and
configure
plugins.
But
I
understand,
I
I
think
is
the
reliability,
simplicity
and
the
writer
trade-off
and
the
new
features,
and
we
have
to
be
very
careful.
I
just
want
to
yeah
chip
in
and
I
we
do
see
some
requirements
and
needs
yeah
for
the
dynamically
yeah
configure
plugins
at
runtime.
A
Right
and-
and
so
there
are
two
levels
to
it-
one
is
at
some
point
during
the
cluster
life
cycle.
You
want
to
dynamically
change
the
set
of
plugins,
it's
really
infrequent
and
there
is
another
where
you
say.
No,
I
want
to
change
the
behavior
I
might.
I
might
want
to
change
the
behavior
between
scheduling
attempts.
A
So
there
are.
Those
are
two
completely
different
requirements.
The
first
one
usually
is.
Basically,
we
have
a
config
map
and
then
we
watch
for
the
config
map
and
then
on
each
change
on
the
config
map.
We
reload
the
configuration
we
we
recreate
the
the
all
the
profiles,
etc.
So
that's
some
form
of
dynamism,
but
it's
not
fine-grained.
It's
you
can
yeah
it's
it's,
it's
it's
coarse,
green
and
then
the
other
one
is
like
really
dynamic.
A
Pear
scheduling
attempt,
I
guess
abdul
was
talking
mostly
about
the
latter,
and
you
won
like
at
the
beginning.
When
you
were
started
to
talk
about
this,
I
thought
you
were
talking
about
the
former,
which
is
like.
B
Yeah,
so
I
so,
I
think
my
requirement
would
be
met
even
with
the
first
thing
that
you
mentioned
the
former,
because
the
fallback
that
we
have
won't
be,
you
know
very
frequent.
B
It
would
be
only
in
the
case
of
the
server
not
being
available
for
a
very
long
time,
or
you
know
something
very
rustic,
so
the
plugin
that
we
have
is,
okay,
you
know
to
you,
know,
let's
say,
avoid
a
node
which
doesn't
have
metrics
available
and
those
things,
but
what
I
would
be
looking
for
is
something
that
will
change,
as
you
described
in
the
first
case,
for
a
longer
period
of
time.
So
when
finding
the
first
requirement.
A
Right,
the
problem
with
the
config
map
approach
is
that
you
want
some
sort
of
external
process
to
update
the
config
map,
and
so
you
need
an
external
controller
that
decides.
Oh,
these
components
are
available
available.
Based
on
that,
I'm
gonna
update
the
config
map
with
how
the
scheduler
should
be
running
the
the
approach
where
we
do
everything
inside
the
scheduler
and
dynamically
change.
A
Things
pay
like
on
each
scheduling
potentially
on
each
scheduling
attempt
is
that
you
need
the
schedule
itself
to
be
aware,
like
you
have
a
pre-filter,
as
I
mentioned,
to
to
probe
the
external
components
and
say:
okay,
those
are
not
available,
and
so
I
have
to
update
the
like
for
this
specific
scheduling
cycle.
Those
are
the
set
of
plugins
that
should
that
should
run,
and
I
I
do
see
a
use
case
for
both
I'm
just
saying
that
those
are
two
different
ones.
I
wasn't
sure
which
one
you
want
was
was
referring
to.
F
Yeah
abdullah
yeah
that
very
good
points,
and
I
honestly-
and
I
I
didn't
think
too
much
about
this
too.
So
maybe
even
some
of
my
comments,
I
I
think
were
off
topic
for
this,
particularly
in
the
case,
and
we
we
are
talking
about
today
so
generally,
and
I
just
started
thinking
and
high
level
in
a
goal
right
and
we
have
one
goal.
F
This
make
the
scheduler
and
all
the
scheduled
behavior
become
more
dynamic
and
adaptive,
but
I
would
consider
then
there
are
two
probably
and
the
message
approach
like
you
described
and
yeah
first
is
yeah
the
the
profile,
the
plugin
and
the
configuration
itself
or
another
one
is
just
a
runtime
behavior
yeah.
I
think
that's
a
good
point.
I
I
I
haven't
yet
thought
carefully
about
that.
F
A
I
suggest
just
so
that
we
we
have
time
for
for
the
rest
of
the
features
abdul
or
yuan.
You
create
an
issue,
describe
your
use
case,
and
then
we
can
discuss
like
what
granularity
of
configurability.
We
should
provide
yeah.
How
I
I,
I
really
think
it's
useful
like
I
imagine
there
will
be
use
cases
for
it,
but
yeah
we.
We
won't
have
a
longer
discussion
on
what
all
these
cases
are
like,
so
that
we
brainstorm
on
like
where
those
notes
should
exist.
A
Okay,
so
on
this
spreadsheet,
I've
listed
a
few
issues
that
we
might
want
to
tackle
for
121,
and
I
encourage
you
please
like
add
comments
on
this
spreadsheet.
Let
me
playing
it
on
the
chat.
A
If,
if
you
have
any
other
other
things
or
just
basically
open
an
issue,
and
then
we
can
add
it
to
the
to
this
tracker
sheet
and
the
the
purpose
of
this
sheet
is
basically
for
us
as
a
checkpoint
of
how
much
progress
we've
made
during
the
time
the
lifetime
of
the
of
the
release
in
every
in
every
sig
meeting.
E
Could
you
add
the
there
just
thank
you.
A
A
Portobello,
spread
constraints
should
be
taken
into
account,
so
that
here
like
this
is
the
more
the
ideal
solution
is
to
get
basically
scale
like
portable
spread,
semantics
and
scale
down.
There
are
use
cases
being
described
that
that
needs
this
more
than
affinity
and
on
the
affinity,
and
I
don't
think
that
this
skater
actually
is
is
a
good
use
case
for
it.
A
Now
it
might
turn
out
that
using
like
really
implementing
this
in
in
the
replica
set
controller
might
be
too
expensive
and
so
simply
doing
things
randomly
might
might
just
work
as
as
good,
but
I
just
throw
the
idea
there
like
to
take,
what's
probably
spread
into
account,
just
to
see
what
what
people
think
about
it
so
mike
will
take
on
to
that
one.
Without
this
exact
one
or
doing
you
know
random
scale
down
and
again,
this
is
in
the
context
of
what
apologies
trade.
A
A
The
the
second
one
is
refactoring
yeah
dependency
of
the
framework,
I'm
guessing
mike.
You
continue
to
do
this
with
with
john.
E
Yeah,
this
is
going
much
better
now,
especially
for
120
that
we
have
the
new
helper
repo,
so
that
should
pick
up
a
lot
of
speed.
This
release.
A
The
third
one
is
adding
namespace
selected
to
pod
affinity
spec.
So
this
is
mostly
right
now
we,
you
can
list
a
list
of
like
namespaces
explicitly,
but
that
doesn't
allow
you,
for
example,
to
say
I
want
this
set
of
namespaces,
like
some
sort
of
you
know,.
A
A
regular
expression,
kind
of
thing,
or
even
something
simpler
and-
and
this
is
useful
for
cases
where,
for
example,
you
want
to
do
one
two
one
odd
to
note
assignment
across
namespaces
right
now.
It's
like
and
you
don't
know
what
those
namespaces
are
like,
for
example,
you're,
a
service
provider.
A
You
create
namespaces
for
each
user,
you
have,
but
you
need
one-to-one
placement
across
all
the
users
that
they
share
this
set
of
nodes,
and
so
you
need
to
do
like
required
quantity
affinity
between
pods
across
all
namespaces
or
a
set
of
frame
spaces.
So
you
can-
and
so
this
this
basically
gives
you
the
the
flexibility
to
do
that.
There
has
been
some
precedence
here
as
well
for
using
airspace
selector.
A
The
main
pushback
we
got
initially
from
jordan
is
performance,
but
I
think
we've
solved
like
most
performance
issues
related
to
affinity,
whether
it's
required
or
preferred
any
questions
or
feedback
on
this
one.
Does
this
sound
important.
C
C
A
C
A
A
A
Yeah
I
mean
we'll
have
to
go
through
api
review,
anyways
yeah
sure,
and
then
we
have
efficiently
queuing.
So
I
hope
that
we
seriously
consider
this
this
cycle.
It's
been
moving
from
since,
like
one
point
19,
I
guess
or
18.
so
way
as
interested
in
this
one
as
well
in
the
context
of
yeah.
C
C
For
example,
if
you
have
a
group
of
paths
and
the
one
we
have
an
unscheduled
part
belong
to
one
task
group
we
definitely
want
or,
for
example,
if
you
have
one
part
belonging
to
a
one
part
group,
and
that
part
is
schedulable
for
sure
you.
C
Maybe
you
want
some
ability
in
the
scheduling
framework,
to
move
all
your
cyberlink
paths,
which
belongs
to
the
same
pulse
group,
to
be
moved
back
to
the
active
queue
efficiently.
Instead,
randomly
depends
on
the
underlying
implicit
semantics
to
move
them
back,
randomly
sort
of
like
that.
So
that
is
maybe
pretty
useful
for
this
kind
of
scenario,
and
I
will
consolidate
all
the
requirements
and
propose
a
design.
A
Then
duplicating
custom
plugins.
This
depends
on
the
progress
we're
gonna
make
with
v1
beta2.
Sorry,
that's
under
under
yeah,
getting
component
config
to
b1
beta2
integration,
test
ben
benchmark
of
diagrams
reports.
So
I'm
not
sure
if
this
one
we
will
continue
to
do
this,
but
we
might
we
might
be
able
to
so.
I
guess
this
is
for
for
adi.
G
A
Okay,
hold
on
the
other
ones,
are
speculative,
really
the
second
type,
the
other
two.
Unless
we
have
strong
demand
for
them,
they
they
will
probably
need
to
start
with
the
cap,
so
refactoring
assume
forget
and
to
reserve
unreserved
plugin
again.
This
depends
on
the
kind
of
plugins
we've
been
seeing
in
the
external
repo
and
there
there
has
been
a
request
to
actually
get
those
out
refactored
and
the
other
one
is
extension
points
for
queuing,
dequeuing
and
updating
parts
as
well.
So.
A
A
A
Yeah
we
have
a
pr
for
the
implementation
and
that's
pretty
much
it.
I
don't
know
if
the
scheduler
folks
would
like
to
add
their
stuff
here,
but
mike.
If,
if
you
would
like
to
please
let
me
know.
E
Yeah
that
that
pod
topology
one
was
finished
in
120,
so
I
don't
know
if
this
is
for
121.
We
could
probably
remove
that
from
here
and.
F
Abdullah,
just
two
clarification
questions
so
so
this
feature
we're
talking
about.
I
I
saw
the
titles
here.
It's
actually
for
121
right,
that's
the
plan,
so
I
saw
it's
kubernetes.
120
120
is
already
released
right,
sorry,
which
one
I
I
mean
the
features
and
we
we
are
talking
about
it's
target
for
121,
right
release.
C
F
Yeah
property
is
typo.
I
just
want
to
yeah
okay,
so
but
the
other
features
in
the
sheet
of
120,
and
so
I
just
I'm
looking
at
the
release
note.
So
all
these
features
already
released
right.
The
120
I
mean
our
plan
or
is
any
because
I
also
see
the
d
scheduler
under
something
there
as
well
and
yeah
yeah.
I'm
just
curious.
A
A
A
All
right
any
final
thoughts,
all
right
have
a
good
break
everyone,
so
next
meeting
is
going
to
be
in
the
new
year.