►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20210826
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,
thank
you,
everyone
for
joining
this
week's
sixth
scheduling
meeting
and
let
me
share
my.
A
Screen
today's
I
mean
whiterun
in
the
agenda,
so
mike
raised
a
very
detailed,
documented
cap
for
simplified
schedule,
component
config
so
mark.
Would
you
want
to
give
a
very
short
introduction
on
this
and
what's
the
motivation
here,
yeah.
B
So
I
put
together
this
cap
for
the
problem
that
was
brought
up.
That's
basically
for
england,
that's
not
aware
the
framework
scheduling
framework
right
now
has
a
number
of
extension
points
that
are
basically
irrelevant
to
end
users,
so
it's
cluster
administrators
that
are
just
trying
to
configure
the
scheduler
they're
important
for
developers
like
pre-score
and
pre-filter
to
get
that
you
know
pre-processing
stage
informational
stage,
but
for
users,
if
these
are
just
required
to
start
a
certain
plugin,
they
don't
care
about.
B
B
So
thinking
about
that,
I
kind
of
ran
into
a
number
of
questions
that
needed
to
be
answered
to
how
to
do
that,
and
the
first
thing
that
I
had
was:
how
do
we
define
what
are
the
relevant
extension
points
for
a
certain
plugin?
B
So
you
know
the
there
needs
to
be
some
sort
of
mapping
to
say
you
know
if
I've
enabled
this
plug-in,
it
is
a
pre-score,
pre,
filter,
score
and
filter
plug-in,
which,
for
entry
plugins
is
easy
enough
for
us
to
define
in
code.
We
can
hard
code
that,
but
specifically
for
out
of
tree
plugins.
B
Those
really
need
a
mechanism
to
be
able
to
communicate
to
the
framework
easily
that
these
are
the
relevant
extension
points
for
my
plugin,
and
so
the
second
thing
to
think
about
was
there's
a
request
for
how
do
we
maybe
configure
disjoint
sets
of
extension
points?
You
know
for
some
clusters,
users
might
just
want
the
filter
plug-in
to
run.
They
don't
want
the
score
plugins,
but
they
still
don't
want
to
have
to
go
and
it
will
pre-filter
and
filter
and
then
disable
score.
B
So
there
needs
to
be
a
way
for
users
to
configure
that
easily,
but
also
again
going
back
to
the
out
of
tree
plug-ins.
They
need
to
be
able
to
see
that
provide
the
option
to
users,
see
that
it's
been
set
and
then
communicate
that
back
to
the
framework
and
then
finally,
how
do
we
do?
All
of
this,
in
a
way
that's
compatible
with
the
existing
framework
existing
plugins,
so
that
there's
no
code
updates
required
for
out
of
three
developers.
B
Unlike
the
existing
extension
points,
it
isn't
specifically
part
of
the
scheduling
cycle,
but
I
think
that's
okay,
because
the
framework
itself
is
more
than
just
the
scheduling
cycle.
It's
instantiating
a
scheduler
and
passing
plug-ins
to
that.
So
this
is,
you
know,
a
instantiation
extension
point,
and
this
addresses
those
three
problems,
because
it
first
off
provides
that
communication
mechanism
for
plugins
to
talk
back
to
the
framework
through
an
interface.
Just
like
every
other
extension
point.
B
You
know
a
user
will
implement
this
extension
point
function,
just
like
they
would
implement
score
or
pre-score
filter
and
that
having
that
pattern
defined
gives
people,
you
know
useful
examples
and
makes
it
easy
for
us
to
document
and
provide
to
developers
that
want
to
add
this
if
they
desire
to
do
so.
B
For
the
second
problem
of
the
disjoint
sets,
if
we're
using
an
extension
point,
it's
plug-in
arguments
will
still
work
just
like
they
would
for
any
other
extension
point
function.
So
as
these
plugins
are
instantiated,
you
know
users
can
use.
The
existing
plugin
argument
features
that
we
have
to
say
you
know.
Perhaps
I
just
want
to
provide
a
no
scoring
option
for
this.
That
will
be
up
to
developers
to
determine
if
it's
allowed.
B
You
know,
as
they'll
have
to
implement
into
their
register
function,
which
is
defined
in
the
cap
more,
but
that
gives
a
way
to
then
communicate
that
back
to
the
framework
for
out
of
tree
plugins
that
we
only
want
to
set
the
filter
plugin.
B
So
then
the
third
thing,
without
breaking
any
existing
code,
adding
a
new
extension
point.
Any
extension
point
in
the
framework
is
optional.
You
know
code
isn't
going
to
stop
working
because
they
don't
implement
this,
there's
no
need
to
add
any
sort
of
mail
functions
or
anything.
B
B
You
know,
define
or
any
sort
of
new
structs
that
need
to
be
passed
around
besides
the
new
fields
in
the
config
api.
So
it's
really
a
drop-in
solution
to
the
existing
framework
that
it
makes
sense
of
the
context
of
the
framework,
and
it
works
really
nicely
with
all
of
the
existing
functions
that
we
have
to.
You
know
instantiate
the
current
plugins,
so
that's
an
overview
of
it
as
a
way
is
showing
here.
B
I
have
a
lot
more
detail
in
the
implementation
plans
and
I've
gotten
a
lot
of
good
questions
from
you
know.
Abdullah
and
wei
and
aldo
have
been
asking
you
know
about
why
certain
decisions
I've
made
here.
I
think
I've
been
able
to
get
to
a
lot
of
them
if
there's
any
other
questions
or
anyone
would
like
to
discuss
some
of
the
choices,
I'm
open
to
doing
that.
So
yeah,
that's
what
we
have.
A
Yeah,
thank
you
so
much
for
driving
this.
I
know
it's
necessary,
but
complicated
well
involves
a
lot
of
designs,
especially
you
have
to
make
the
curve
compatible
with
the
old
custard,
so
yeah.
I
gave
some
comments
in
there
in
the
in
the
pr.
In
addition
to
those,
I
I
think
I
missed
something
that
what's
the
future
direction,
so
so
so
right
now
we
have
to
make
it
compatible.
A
Yes,
that's
true,
so
I
missed
one
thing:
is
that
what's
the
direction
of
that
in
the
future,
so
that
suppose
we
can
dispose
the
current
to
like
some
config
field.
So
what's
the
direction?
What's
the
ideal
configuration
like,
I
suppose
that
we
can
just
get
all
the
plugin
which
implements
the
the
multi-point
extension
as
well,
so
as
to
make
an
ideal
configuration
there
right.
So
I
think
that
part
is
mixed
up
on
this
cap.
A
So
what's
the
direction
shape
we'd
like
to
see,
but
for
now
you
should
for
sure
we
should
make
it
compatible.
This
is
first
question.
My
second
question
is
you
mentioned
that
a
user
can't
choose
the
user
means
developers.
The
developer
can
choose
to
implement
the
way
multi-point
interface
or
not,
but
if
they
choose
to
implement
this,
I
suppose.
A
B
Yeah,
so
that's
totally
right:
let's
start
with
that
one!
You
know
if
a
developer
implements
this
into
their
plugin,
because
this
is
really
just
a
convenience
for
end
users
that
are
using
the
plugin.
B
So
if
they
choose
to
implement
that,
then
they
can
provide
that
to
their
end
users,
but
if
they,
if
the
end
users
still
want
to
use
the
old
config
they're
free
to
do
that,
and
we
actually
you-
and
I
came
up
with
a
couple
use
cases
in
the
discussion
for
where
users
might
want
to
use
the
multi-point
registration
for
a
plugin
and
still
have
access
to
maybe
disabling
all
of
the
default
plugins
that
are
in
the
cluster
and
only
using
their
custom
ones.
B
B
It
uses
all
of
the
current
functions
that
we
have
for
checking
if
a
plugin
is
already
registered,
so
it's
it
is
actually
pretty
amazing
how
easily
it
drops
in.
For
the
first
question
for
the
general
direction
of
like
the
ideal
config
for
this,
I
think
that
you
know
what
you're
saying,
if
I
understand
is
at
some
point,
we
try
to
migrate
all
of
the
plugins
to
using
this
multi-point
and
implementing
it
and
then
eventually
getting
rid
of
the
you
know
the
current
config
of
having
individual
options.
B
I'm
not
opposed
to
doing
that.
Eventually,
I
think
that
you
know,
like
you
were
saying,
the
compatibility
is
a
big
part
right
now,
so
we
don't
want
to
take
that
step,
but
I
think
for
all
of
the
entry
plugins
implementing
this,
for
each
of
those
would
be
really
trivial
part
of
adding
this
and
would
set
a
good
precedent.
B
As
you
know,
the
maintainers
of
the
scheduler
to
be
able
to
say
this
is
the
direction
that
you
should
be
taking
as
a
plug-in
developer,
and
you
should
provide
this
to
your
users
and
then,
as
we
gauge
the
adoption
of
it
moving
forward.
I
think
that
you
know
trying
to
deprecate
those
older
fields
in
favor
of
an
ideal,
simplified
user-facing.
A
Work
on
the
sometimes
it
needs
more
maintenance
efforts
right.
So
I
think
we
can
be
more
option
to
say,
like
we,
like
the
ideal
shape
to
to
to
sort
of
think,
maybe
in
the
future,
enforce
people
to
use
this
mod
point
only
and
if
you
want
to
disable
the
portion
of
your
plugins
variants,
like
disable
scoring,
you
can
use
some
mechanism
like
using
arguments
or
sort
of
to
do
that,
so
that
we
can
ideally
just
remove
all
the
score
filter
or
the
fields.
A
So
my
point
is
that
we
can
be
more
option
on
this
and
maybe
well
also
get
some
feedback
from
the
user,
whether
they
yeah
yeah.
The
favorite
of
this.
B
Yeah,
I
think,
like,
like
I
said,
that's
a
good
road
map
for
it.
I
don't
see
why
people
wouldn't
want
to
move
forward.
You
know
adopting
the
ideal
pattern
here
and
then
you
know
enforcing
the
multi-point
registration
would
be
as
easy
for
us
as
just
making
it
part
of
the
core
plug-in
interface.
If
we
wanted
to
be
that
strict
about
it,
that
people
would
need
to
update
it
at
that
point,
probably
when
we
remove
those
old
fields,
users
with
your
developers
and
then
have
to
update.
A
Yeah
and
another
comment
for
me
is
because,
when
I
reviewed
the
cap
I
was
confusing
on
some
combination
of
like
entry,
regular
versus
multi-point,
plugin
versus
intri
versus
enable
or
disable.
So
I
left
that
table.
Maybe
this
is
just
something
I
can
think
of.
Maybe
you
can
add
something.
So
this
is
the
combination
like
entry,
plugging
versus
software,
plugging
different
options,
so
each
I
think
would
maybe
we
can
come
with
come
back
with
a
table
explaining
the
detail,
semantics
or
motivations
here,
so
people
can
better
understand.
B
Yeah,
I
think
that's
a
good
idea.
I
hadn't
seen
this
comment
yet
all
right
sure
so,
but
seeing
it
now.
I
think
that
that's
definitely
something
that
should
be
fitting
to
because
you
were.
You
brought
up
some
good
points
about
you
know.
Some
of
these
aren't
clearly
obvious
what
might
happen
one
of
the
semantics
of
each
of
these.
I
think
that
when
you
start
to
dig
into
them,
they
do
have
definitions
already,
but
they're,
not
they're,
not
obvious
on
the
front.
A
C
I
have
a
few
thoughts
sure,
so
the
first
is
yeah.
I
think
let's
lay
down
where
the
user
stories.
I
think
the
main
thing
we
want
to
support
is
simply
someone
wanting
to
enable
and
an
entire
plugin
right
and
another
one
is
disabling
specif.
This
is
having
a
specific
extension
point
right,
yeah,
and
what
else
do
we
want
to
support?
The
disabled
star
today
meant
disable
anything
that
was
by
default
right,
disable
all
the
defaults.
C
For
that
extension
point
now,
it's
a
little
bit
unclear
what
it
means,
because
if
you
enable
a
plugin
right,
an
entire.
A
C
C
Does
that
disable
the
the
one
you
added
with
multi-point
that
does
not
disable
the
score
for
multipoint
or
not
yes,
yeah,
let's
lay
down
all
the
user
stories
and
yeah
that
table
will
help
help
clarify.
What's
the
intention.
C
What
was
your
point?
Yes,
so
your
point
is
kind
of.
What
do
we
want
to
do
in
the
future
right?
Do
we
want
to
allow
configuration
through
the
multipoint
and
through
the
individual
points
forever
or
not?
If
not,
I
guess
we'll
be
requiring
the
plugin
developers
to
to
have
a
configuration
for
disabling
specific
functionality,
but
if
we
are
already
doing
this
doing
this
multiplying
plus
single
points,
why
maybe
it's
not
worth?
Maybe
we
can
just
keep
supporting
this.
C
This
use
case
this
way
and
my
last
thought
is:
I
don't
really
see
it
kind
of
it's
kind
of
related
to
the
previous
point.
I
don't
really
see
the
need
for
register
function
right
if,
if
we
can
already
detect
which
points
are
are
implemented.
So
why
add
the
extra
burden
to
developers?
C
If
the
intention
is
to
be
able
to
disable
specific
specific
extension
points,
then
again
we
go
back
to
the
question.
Do
we
want
to
support
that
through
having
all
the
extension
points
in
the
configuration
or
through
an
argument,
but
even
if,
if
it
is
through
an
argument,
we
we
still
have
other
alternatives
right.
B
Right,
so
the
point
of
the
register
function
is
more
than
just
providing
that
configuration.
It
is
it's
a
necessary
way
for
the
plugin
to
define
its
mapping
for
what
extension
points
to
register
to
because,
like
you
said,
we
can't
just
determine
which
ones
are
available
for
it,
but
using
the
existing
plug-in
instantiation
functions
that
we
have
through
there.
B
I
have
some
code
samples
in
the
cap
that
show,
I
think
it's
like
update
plugins
list
yeah
right
up
there,
that
update
plugins
list
function
when
it's
passed,
a
a
plugin
set
that
that
e
dot
plugins
parameter
is
usually
just
the
main
profile
plug-in
set.
But
if
you
pass
it
the
specific
plug-in
set,
it
will
only
try
to
match
to
those.
So
it
kind
of
it's
not
a
hack,
it's
using
it
exactly
how
it's
defined
to
then.
B
We
can
map
these
plug-ins
to
their
register,
volt
types
and
if
anything
is
misconfigured
there
or
a
wrong
configuration
is
coming
from
the
plug-in.
An
error
will
be
raised
like
it
is
now,
if
you
have
a
plug-in
misconfigured,
so
it's
not
just
like
a
nice
configuration
or
a
feature
thing.
It's
actually
like
a
core
part
of
the
proposal
that
we
need
to
have
a
way
to
define
this.
C
Yeah,
but
I
I
mean
it's
not
necessary
that
we
pass
the
multi-point
through
this
loop.
We
we
can
do
it,
we
can
do
it
separately.
B
Yeah,
but
I
mean
what
other
way
do
you
have
where
an
out
of
troop
plug-in
can
say
that
these
extension
points
are
the
ones
that
I
want
to
register
for.
B
C
I
don't
I'm
not
convinced,
because
the
error
is
precisely
because
okay,
I
want
to
enable
reserve
for
this
plugin.
This
plugin
doesn't
implement
reserve
right,
but
now
we
are
going
towards
simplifying.
So
then
the
user
doesn't
care
about
what
the
the
extension
points
are.
The
user
just
want
to
know
just
want
to
enable
the
entire
plugin.
B
Yeah,
that
is
a
good
point.
You
know
if
we
get
rid
of
the
other
fields
and
there's
no
other
config
available,
then
we
can
go
through
that
extension
point,
but
I
think
until
we,
you
know
deprecate
the
existing
fields.
That
should
still
be
there.
C
No,
I
mean
it
doesn't
have
to
be
we.
We
can
keep
doing
the
error,
checking
for
this,
the
individual
fields,
but
for
multi-point
we
don't
go
through
this
process.
D
B
Okay,
yeah,
I
mean
that
can
work,
for
I
think
that
then
you
do
still
have
the
you
know
the
issue
of
passing
away
to
register
for
specific
specific
points
like
disabling
the
score.
Would
that
still
be
able
to
work
with
that.
C
C
Well,
we
we
could
change
that
right.
That's
why
yeah
we
could
clarify.
What's
the
new
interpretation
of
disabled.
D
D
D
Let's
get
that
like
really
properly
done
with
all
the
semantics
flushed
out
how
defaulting
is
going
to
work
in
general
for
these
plugins,
like
for
multi,
when
you
specify
a
multi-point
how
different
yeah,
I
think
we
discussed
it
on
the
on
the
cap
and
then
make
when
then
we
make
sure
that
this
api,
how
to
implement
this
api,
using
whatever.
D
B
Yeah,
the
you
know,
like
we
went
over
like
api
defaulting
and
stuff,
is
something
that
we
still
have
control
over.
That's
you
know
relevant
for
entry
plugins.
So
that's
just
the
same.
We
would
basically
update
our
set
of
default
plugins
to
just
use
multi-point
and
we
can
set
the
weights
through
that,
because
plug-in
waits
for
score
plugins
are
still
available
through
plug-in
set
right.
That's
the
type
that
we
get.
D
One
thing
that
is
going
to
be
good
with
the
like
getting
rid
of
the
register
function
is
that
the
defaulting
is
going
to
be
hard
coded
by
us,
so
they
don't
really
need
to
do
it
for
the
weight.
So
in
component
config
defaulting
logic,
we
set
the
weight
for
the
score
plug-in
the
default
way,
for
example
one,
but
we
need
to
propagate
that
to
the
score
plug
it
right.
D
B
No,
if
a
plugin
doesn't
have
to
for
defaulting
an
out
of
tree
plug-in,
could
do
that
if
they
wanted
to
provide
a
default
weight,
but
you
know
plug-ins
still
don't
need
to
provide
I'm
talking
about
entry
yeah,
I
know
entry.
If
we
define
entry
just
like
we
have
under,
I
think
it's
our
default
plugins
in
the
api.
We
have
the
weights
defined
for
score
there
if
we
just
move
those
weights
up
to
the
new
multi-point
extension.
I
can
add
an
example
of
this
into
the
cap
if
it
might
be
more
helpful.
B
Function
register
function
doesn't
handle
weights,
that's
handled
by
the
current
parsing
of
where
we
get
extension
points,
and
then
we
update
plug-in
list.
That's
where
the
weight
is
handled.
C
So
I
guess
that
would
be
another
thing
to
look
up.
Do
do
we
want
to
do?
We
want
to
have
multi-point
multi-points
weight
affect
something
I
I
think
we
should.
We
should
make
it
like
the
score.
B
I'll
add
an
example
of
you
know
what
effect
this
would
have
on
our
api
defaulting,
because
it
really
it
just
translates
one
to
one.
It
doesn't
have
any
effect
with
the
register
function
at
all
that,
like
so
that
example
right
there
multi-point
possibility
spread
weight.
B
C
Right,
so
that's
that's
what
we
are
saying
like
that
could
be
a
source
of
errors
that
what,
if
someone
forgets
to
copy
this
into
the
score.
B
Well,
someone
doesn't
need
to
forget
to
copy
it
it's
if
it's
set
in
multi-point.
It
will
get
copied
by
how
the
framework
works.
D
B
The
score
yeah,
so
these
are
just
the
the
plug-in
api
type
same,
one
that
we
have
already
so
the
same
way
that
it
copies
the
weights
now
for
functions
that
are
specifically
in
the
score
will
be
the
exact
same
method
that
it
takes
for
setting
the
weight
in
multi-point
plug-ins,
because
this
type
doesn't
matter
if
this
type
is
in
multi-point,
whether
it's
in
score
or
something
until
it's
actually
like
cast
to
an
interface,
it's
usable
by
any
of
them.
So
it
will
register,
will
copy
all
of
this
information
name
and
weight
into
the
score
list.
B
D
B
Someone
sets
the
weight
in
the
register
function.
You
know
that's
on
the
developer
of
the
register
function,
but
it's
going
to
have
no
meaning
right.
It
would
have
no
meaning
right.
B
We
could
set
it
to
have
a
meaning.
If
out
of
tree
developers
want
to
set
a
default
weight
for
their
plugin,
then
you
know
we
could
parse
that
I
included
the
weight
in
the
register
function
here,
but
after
abdullah
brought
that
point
up
in
the
discussion.
I
don't
think
that
I
should
have
the
weight
in
my
register
example,
which
is
lower
down
right
here.
It
makes
sense
in
the
multi-point.
C
So
yeah,
I
I
think
in
general
there
are
a
few
things
that
make
the
register
non-desirable
and
also
like
everybody
needs
to
implement
it
right
now,
so
it
would
be
better
if
out
of
three
plugins
can
directly
benefit.
You
know
they
don't
know,
they
don't
need
to
change
anything
and
they
already
can
can
can
support
multi-point.
A
C
A
Yeah,
I
I
also
when
I
started
looking
into
the
cab.
I
also
have
the
same
exact
same
concern
with
auto
and
yeah.
I
think
yeah,
making
a
paragraph
to
to
explaining
the
pros
accounts
can
make
the
readers
more
better
understanding.
Why
we
need
that
register
explicitly,
especially
that
if
you
mention
it's
optional
right
now,
so
what's
the
benefits
there
to
have
it
every
minute
versus
not
and
how
it
impacts
with
our
future
ideal
shape,
shape
of
how
the
tracking
config
looks
like
yeah.
That
would
be
how
helpful.
B
Yeah
I'll
add
you
know
a
pros
and
cons
breakdown.
I
think
we've
had
some
good
points
brought
up
here.
A
So
so,
right
now
it's
like
we
have
two
ways
to
to
to
get
multiplying
the
plug-in
register
into
the
particular
extension
point.
Why
is
the
versus
the
demo?
What's
the
static
configuration?
The
other
way
is
the
programmatic
way
to
implement
this,
so
how
maybe
they
can
conflict
and
what's
our
opinion
on
this
and
how
we
can
guide
the
user
to
use
a
static
way
versus
a
programmatic
way.
So
that's
the
yeah,
that's
nothing.
We
need
to
think
about.
A
Yeah,
I
think,
overall,
it's
in
a
good
shape
that
at
the
moment,
the
idea
I
I
buy
in
this
idea,
but
just
some
different
details
and
how
whether
we
need
this
interface
or
not,
and
what
specific
schematics
like
I
mentioned
earlier
in
the
table-
needs
to
figure
out
so
yeah.
We
can
spend
some
time
here
then
this
can
buy
us
later
in
the
future.
The
compute
confusion,
maybe
in
the
user
side
how
about
that.
A
If
not,
I
will
stop
the
recording
and
you
can
always
find
us
on
the
slides.
Okay.
E
Hey
folks,
I
just
wanted
to
introduce
myself,
I'm
the
123
release
lead
and
she
wanted
to
put
the
link
for
opt-in
for
enhancements
in
the
chat
here.
I
did
see
that
this
they
talked
about
the
features
that
they
are
going
to
be
planning
for
123
in
the
last
meeting.
So
I'll
just
put
that
in
the
slack
chat.
E
Yeah
once
under
the
cap
collection
time,
which
it's
the
fourth
one
you
just
add
in
the
enhancement
issue,
number.
E
Oh,
that's
right,
yeah,
so
yeah
just
add
in
the
the
enhancement
issue:
number
the
name,
the
signee,
the
sig
and
okay.
If
it
needs
docs,
it
requires
any
updates
to
the
documentation,
websites
and
also
just
the
link
to
the
cap.
A
The
best
key-
I
I
don't
think,
there's
any
feature
we
need
to
track,
but
yeah
we
can
just
I
can
discuss
with
the
other
and
later
if
we
have
some
more
of
you
in
the
table
yeah.
Thank
you
all
right.
All
right.
A
Yeah,
thank
you,
everyone
for
joining
today's
meeting.
We
will
see
you
in
two
weeks
and
have
a
nice
day.