►
From YouTube: Kubernetes SIG Scheduling Meeting - 2019-09-05
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
Yeah,
so
just
a
quick
update.
First
of
all,
congratulations
to
Allah
for
taking
or
birth
the
responsibilities,
it's
mostly
responsibilities.
Unfortunately,
it
does
not
come
with
a
lot
of
benefits.
It's
mostly
responsibilities
for
you,
but
I'm
sure
you
will
be
a
great
lead
and
he
will
come
up
with
a
lot
of
projects
and
ideas
to
improve
the
scheduler
and
the
reason
that
I
actually
decided
to
so
it
was
mainly
mainly
because
I
my
priorities
inside
Google
has
changed.
I
have
moved
to
another
project.
B
B
It's
mostly
basically
me
hi
I
would
like
to
switch
things
once
in
a
while
and
try
different
things
who
knows.
I
might
come
back
again
to
the
cluster
management
side
one
day,
but
for
now
I've
decided
to
try
other
projects.
I
cannot
really
talk
much
about
them.
These
are
basically
just
like,
futuristic
and
exploratory
projects
in
a
different
team,
I
googled.
Hopefully
you
will
see
some
cool
products
out
of
all
of
these
projects.
B
That's
mostly
about
me,
but
I'm
sure
things
will
go
even
better
than
before.
Abdullah's
supervision
in
the
sig
and
I
wish
him
luck
and
I
also
would
like
to
thank
everybody
who
made
this
a
great
experience
for
me.
I
enjoyed
really
much
working
with
all
of
you
guys
and
I
am
so
humbled
for
that
I
see
so
much
interest
and
enthusiasm
among
you
guys
to
contribute
and
be
a
part
of
this
big
effort.
Thanks
again.
A
A
A
A
So
the
first
item
on
the
on
the
on
the
list
is
probably
something
you
know
ready
and
it's
moving
mostly
from
1.16
or
it's
a
continuation
of
1.16
effort
in
the
framework
that
Bobby
and
others
started
as
they
were
continuing
this
work
by
basically
really
migrating
into
the
framework.
So
we've
mostly
finished
the
framework
or
the
extension
points
have
been
implemented
and
now
we
would
like
to
add
actual
functionality
into
it
by
converting
predicates
and
priority
functions
into
plugins
into
the
framework.
A
A
Upgrade
or
move
from
alpha
to
2
beta
we'll
try
our
best
to
move
as
many
as
we
can,
but
but
really,
the
goal
is
to
make
sure
we've
thought
about
everything
with
regards
to
the
scheduler
I
will
give
us
a
different
work
so
for
this
one
I'll
be
mostly
trying
to
Shepherd
this
effort.
I
will
be
creating
soon.
A
A
The
movement
to
d2
the
framework
and
a
part
of
it
is
also,
for
example,
hugging
me.
Those
custom
priority
functions
that
we
allow
to
define
in
the
D
in
the
policy
right
now
we
want
an
equivalent
to
them.
Another
thing
is
that
that
we
need
take
care
of,
is
some
D
feature
or
lock
affiliation
items
that
apply
to
the
old
priorities,
but
don't
predicates
I
don't
apply
to
the
plugins,
such
as
always
always
executing
all
predicates.
A
So
there
is
a
few
small
items:
I
just
wanted
to
take
a
closer
look
at,
like
you
know,
a
high-level
look
first
before
we
start
actually
moving
in
and
good
thing
that
we
are
in
code
fees
right
now,
so
we
have
the
opportunity
to
actually
look
into
this.
Take
our
time
before
I
actually
start
implementing
and
moving
things
and
submitting
PRS
once
the
freeze
is
over.
C
A
So
the
second
item
is
is
owned
by
Aldo
and
it's
basically
a
continuation
from
1.16
and
it's
mostly
about
making
the
schedulers
default.
Apologies.
Reading,
configurable
and
one
thing
we've
accomplished
in
1.16
is
even-odd
spreading
now
it's
in
alpha
and
we
hopefully
soon
take
it
to
to
beta
once
we
have
that
I'm
proposing
to
actually
implement
this
default
feature
using
even
pod
spreading.
A
First,
we
already
we
will
remove
some
redundancy
and
the
second
thing
is
we
remove
the
potential
conflict
between
the
the
default
spreading
and
even
pod
spreading
that
I.
Don't
think
we
we
thought
about
that.
Yet
because
even
false
reading
is
in
alpha
and
is
not
enabled
I,
don't
know
if
folks
had
any
thoughts
about
this
before
or
any
feedback
on
this.
B
So
I
think
well,
I,
think
well,
first
of
all,
even
participating
can
be
a
predicate
and
those
default
spreading,
or
only
priorities.
Basically,
in
our
previous
terms,
in
newer
terms,
I
should
basically
call
it
even
participating
can
be
also
a
filter
and
those
default
spreading
only
scoring
functions
right,
so
they
don't
necessarily
conflict
with
one
another.
In
that
sense,
if
that's
the
case,
but
even
participating
can
also
be
scoring
as
well.
So
in
the
case
that
scoring
is
provided,
I
would
say
that
the
weight
of
even
part
is
spreading.
B
The
score
must
be
a
lot
higher
than
the
rate
of
default
spreading,
so
that,
if
both
are
are
done,
the
even
part
is
spreading
prevail,
explicitly
and
even
and
the
default
is
spreading,
basically
will
be
effective.
Only
when
even
participating
gives
the
same
score
to
the
same
two
to
two
different
nodes
and
then
the
default
spreading
may
differentiate
between
the
two
that
have
the
same
others.
Otherwise,
if
different
nodes
have
different
scores
that
are
given
by
even
for
the
spreading,
then
whatever
even
participating
has
given
is
basically
the
main
metric
for
us.
C
A
A
B
A
Yeah
so,
but
that
depends
on
how
they
specify
what
what
default
configuration
the
the
admins
specify.
So
it's
up
to
them.
So
if
we
really
want
to
provide
something
very
flexible
in
terms
of
configuration,
allow
them
to
do
anything
they
want
like
a
default.
One
could
be
very
simple,
and
that
should
have
the
same
overhead
as
if
we
were
to
implement
it
like
I,
don't
know
how
we
would
implement
differently
from
even
participating
even
yeah.
B
A
B
A
And
this
is
the
other
thing
so
when
we
think
about
the
default
spreading,
it's
going
to
be
based
on
exactly
that,
so
it's
going
to
be
for
services,
replicas
sets,
etc.
So
so
that's
exactly
exactly
so
what
so
the
the
default
spreading
API
that
we
will
add
into
the
component
config.
Even
we're
gonna
allow
them
to
specify
okay,
which
collections
or
we
can
just
do
it
at
the
same
way
that
we're
doing
it
right
now
with
with
the
default
spreading.
So
we
don't
allow
them
just
specify
labels
or,
like
you
know,
selector
so
specify.
C
B
C
C
Yeah,
it's
a
long
discussion
topic.
Actually,
we
have
plans
I
think
several
months
ago
you
know
release
about.
We
just
tried
to
form
the
buffer
to
do
this.
So
basically,
I
think
I
I
talked
to
Jeremy
it's
offline
about
some
potential
issues
and
some
aspects
we
want
to
include
there's
a
issue
there
yeah.
We
just
want
to
increment
them
one
by
one
and.
A
A
You
know
like
running
from
head
every
time.
The
way
that
we
do
right
now
already,
but
we
want,
like
you,
know
more
breakdown
and
for
it
first
for
various
for
separate
for
support,
but
we
already
have,
for
example,
for
affinity,
but
we
have
it
for
the
part
that
implements
as
implemented
as
a
predicate,
but
not
the
one
that
cement
as
priority
so
it'd
be
nice
to
talk
about
everything.
Yeah.
A
A
D
A
Sounds
good?
Okay
thanks
the
next
one
is
scheduler
APRI
cleanup,
so
I
opened
the
thread
dawn
on
slack
with
the
court
like
cord
organization
channel,
and
it
seems
that
we
can
actually
move
code
around
even
API
code
around
without
a
cape
or
anything
or
to
Perdition.
So
it's
up
to
us
to
do
it
and
it's
up
to
the
users
to
figure
out
the
new
package
place
and
link
to
it
as
long
as
we
keep
the
preference
as
they
as
it
is
with
their
with
their
registration
as
well.
A
So
what
I
suggest
here
is
to
clean
up
a
little
bit
the
confusion
about
API
and
API.
Is
we
have
both
similar,
similar
naming
named
packages
and
what
we
can
do
there
is.
We
have
actually
two
things
under
API
right
now,
one
that
is
the
policy
which
basically
defines
how
we
configure
the
scheduler.
The
other
part
is
the
extender
API.
So
my
suggestion
here
is
to
split
it
into
two.
So
one
is
gonna
move
into
the
api's
country
and
it
would
be
basically
part
of
component
country.
A
Unfortunately,
it's
gonna
move
as
v1
because
it
is
b1.
The
other
part
extenders
is
also
gonna
move
under
api's,
but
it's
not
under
AP
is
concrete.
It's
gonna
have
its
own
package
just
api's
extenders
extenders,
and
that
one
also
has
to
be
v1,
so
that
cleared
clears
up
the
code,
but
we
still
have
after
we
do
that
this
weekend,
you
now
moving
forward.
I
think
we
need
to
do
something
occasion
work
and
to
get
more
stuff
into
the
component
config.
We
still
have
to
think
about
how
we
support
configuration
via
config
map.
A
I,
don't
know
if
you
guys
anyone
thought
about
actually
loading
component
config
itself
from
config
map,
because
right
now
the
component
config
is
basically
a
fire
that
we
load.
So
if
you
want
to
keep
supporting
the
model
of
either
configuration
configurating
the
schedule,
we
are
fine
or
a
config
map.
We
can
do
that
for
the
config
for
the
fuel,
scheduler
config
start
itself,
and
so
that
will
allow
us
to
basically
clean
up
all
the
valleys
fulfilling
at
the
old
ones
and
and
integrate
them
roll
them
into
the
into
the
component.
A
C
A
Specify
a
flag,
though,
like
right
now
you
have,
we
allow
few
flags,
so
the
one
like
there
are
I
think
three
flags
in
the
schedule
like
the
non
deprecated
deprecated
ones.
One
of
them
is
the
component
config
file,
so
we
can
provide
two
flags
and
one
is
the
component
config
file,
the
other
one
is
the
one
config,
maybe
I,
don't
know
like
the
config
map
name
or
what
about
like,
namespace
and
name
so
that
solves
the
chicken
and
egg
problem.
A
A
The
way
that
is
implemented
right
now
doesn't
really
allow
multiple
permit
plugins
to
collaborate
to
coordinate
on
way
to
accept
pod.
If
multiple
permit
plugins
would
like
for
the
pot
to
be
placed
in
the
weights
and
and
and
provide
a
timeout.
So
if
that
case
happens,
if
two
or
more
returns
awaits
with
a
timeout,
then
in
the
future,
if,
if
the
logic
of
these
plugins,
that
decides
whether
to
accept
the
pod
or
not
decide
to
actually
accept
the
pod,
it
wouldn't
really
take
into
account
the
the
the
the
other
plug-in.
A
So
we
really
need
to
change
the
API
to
accept
the
pod
pair
plugin,
probably,
and
we
need
to
take
into
account
the
time
out
basically
to
keep
you
know
modifying
the
time
hour
based
on
which
plugins
have
accepted
the
pod,
and
we
probably
also
need
to
provide
some
sort
of
a
mechanism
to
say
which
plugins
are
still
has
still
not
accepted
the
the
pod
so
that
they
can
also
better
coordinate,
and
maybe
one
plug-in
would
like
to
wait
until
the
end
to
accept
the
part
they
don't
want
to
accept
it.
In
that
you
know.
A
Halfway
through
specifically,
gang
scheduling
will
probably
require
such
behavior,
so
I
mean
there
are
a
lot
of
things
and
throw
us
about.
This
needs
to
be
hashed
out
as
well.
So
I
create
an
issue
and
I
wonder
if
someone
is
interested
in
it
to
pick
it
up
and
and
and
see
how
they
can
define
a
bitter
API
for
Kermit
and
probably
implementation
as
well.
B
Yeah
I
mean
we
need
to
have
a
proper
design
for
this
think
carefully
about
all
the
details
here.
One
obvious
solution,
as
you
mentioned,
is
like
multiple
rates
and
each
plug-in
maybe
can
have
access
to
all
the
weights,
and
but
it
can
approve
only
its
own
weight
and
and
then
by
doing
that,
plugins
can
decide
when
to
approve
or
wait
for
other
plugins
to
approve
first
and
then
they
approve
and
things
of
that
so
but
this
is
just
a
very
preliminary
idea.
It
might
not
work
in
all
cases
when
someone.
A
A
There
are
a
couple
of
flashlights
that
I
moved
from
1.16
Israel
resource
coder
scope,
selector
to
GA,
I,
didn't
really
look
into
this
closely.
I
will
look
at
the
PR
that
Bobby
put
a
link
to,
and
the
other
item
is
graduating
conflict
to
be
one
bit
alone.
This
is
gonna,
wait
until
we
change
all
the
parameters
into
nullable
ones,
so
that
we
can
distinguish
between
a
default
value
that
we
want
to
have
and
go
Lang's
default
value
and
that's
yeah.
A
C
Know
Nikita
in
the
6s
there,
because
all
the
incubators
projects
will
have
will
be
deprecated,
yes
or
just
suggesting
is
to
move
them
into
the
convenience,
seek
organization
so
yeah.
We
should
do
there
sooner
than
later.
I
think
Randy
and
Mike
active
maintainer
and
reviewer
in
Iskenderun.
So
the
UK
team
took
this
idea.