►
From YouTube: Kubernetes SIG-Scheduling Weekly Meeting for 20200423
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
welcome
to
this
week's
six
scheduling
meetings
and
this
meeting
is
being
recorded,
so
be
aware
of
what
you
are
seeing
and
it
will
be
public
in
the
internet
all
right
this
week.
There's
no
nobody
proposing
agendas
here,
so
I
just
generally
go
through
some
items
we
are
doing
in
the
last
two
weeks.
A
B
Yeah,
that's
going
good,
there
are
minor
blockers,
pretty
much
the
api
implementation
has
been
done
and
it's
a
matter
of
cleaning
up
our
code
and
moving
defaults
also
to
to
version
to
the
version
packages
and
that's
that's
the
end
of
it.
A
B
The
only
caveat
that
we
have
is
that
we
were
using
the
the
golang
serializer
or
the
serializer
which
didn't
have
doesn't
respect
casing.
So
we
and
we
forgot
to
add
json
tags
for
one
type
for
two
types.
So
we
had
to
for
backwards
compatibility.
We
had
to
add
a
factor
so
that
we
can
support
any
casing
for
those
two
types,
but
for
the
rest
of
them.
They're
fine
and
we
shouldn't
be
copying
that
hack
into
beta
into
the
beta
version
of
component
copy.
A
Okay,
so
I
think
the
the
direction
in
the
future
is
that
this
kind
of
arguments
will
be.
The
version
of
these
arguments
will
be
aligned
with
the
component
config
right.
So
my
question
is
what,
if
some
of
the
arguments
needs
adjustment,
for
example
in
this
version,
so
does
that
need
to
lift
the
component
config
version?
A
B
So
yes,
and
no
the
good
thing
about
having
the
version
types
and
having
them
as
embedded
types,
is
that
we
can
actually
release
versions
for
each
plugin
and
as
long
as
the
the
configurator
of
the
scheduler
puts
a
version
in
their
type,
they
can
mix,
they
can
mix
versions.
Okay,
yeah
we'll
convert
everything
to
internal.
So
that's
a
very
good
thing
about
this
version
is
key.
A
A
All
right,
that's
the
first
thing,
and
the
second
thing
I
want
to
mention
is
that
in
an
offline
discussion
among
me,
abdullah
and
and
aldo
we
are
going
to
change
the
formula
of
the
patapower.
Topology
spread
feature
a
little
bit,
so
there
are
several
changes,
maybe
well.
A
Where
will
happen
so
when
I
implement
the
the
project
spread
feature,
especially
for
the
for
the
softer
constraint,
which
means
the
the
the
strategies
that
schedule
anyway
in
the
in
the
api
spec.
So
for
the
for
that
kind
of
score
functions
in
the
alpha
version,
I
just
put
every
constraint
the
same
weight
and
choose
the
matching
parts
as
as
the
only
metric
to
measure
whether
we
should
prefer
to
schedule
the
incoming
part
to
that
or
not
prefer
to
schedule
to
that.
A
So
that
is
just
one
metric
so
that
doesn't
take
the
max
q
into
consideration.
I
mean
for
the
score,
not
for
the
future
for
the
score,
so
I
think
we
are
discussing
some
better
formulas
to
incorporate
the
max
queue
into
consideration
as
well,
and
also
we
may
change
some
default
weight
to
the.
A
For
example,
if
you
have
two
constraints,
one
is
on
zone
one
it's
on
node,
maybe
you
want
the
internal
score,
not
the
final
score.
Internal
score
for
the
zone
will
be
higher
than
the
node
right,
because
you
care
more
about
how
the
posts
are
balanced
across
zones
k
playing
to
know,
but
right
now
the
default
formula
just
take
them
at
the
same
weight.
So
that
is
the
second
thing
and
I
think
the
the
formula
itself
can
also
be
optimized
so
right
now
the
formula
is
just
take
the
matching
count
into
consideration.
A
So
we
are
also
and
also
there's
some
internal
formula
sort
of
taking
the
total
count
of
the
matching
processing
took
consideration
and
the
flipped
the
matching
part
sort
of
we're
going
to
change
that
from
a
little
bit
as
well.
So
a
lot
of
details
behind
that.
I
think
we
maybe
aldo
and
or
me
will
raise
the
umbrella
issues
to
to
list
all
the
ongoing
items
to
ensure
everyone
on
the
same
page.
So
that
is
for
improving
the
cut
bar
is
spread.
B
So
one
thing
to
notice
is
that
the
current
formula
is
provides
very
little
difference
among
nodes
compared
to
to
other
scores,
such
as
list
resource
list,
allocator
resources.
B
So
for
the
most
part,
what's
taking,
the
decision
ultimately
is
just
pretty
much
just
that
plugin
so
and
that's
because
the
because
of
the
formula
formula
we
are
using,
which
just
adds
the
this
course
for
for
a
for
a
zone.
B
So
I'm
I'm.
I
develop
a
very
dirty
script
to
test
a
few
formulas
and
kind
of
running
simulations
to
to
see
how
different
formulas
behave
and
yeah.
I
I
haven't,
found
a
optimal
solution
yet
because
yeah,
because,
as
you
keep
adding
as
a
zone
grows
in
size,
pretty
much
all
the
decision
is
only
about
zones
and
and
the
difference
between
within
a
zone.
The
difference
between
nodes
is
very
small
in
score.
B
So
yeah
again
other
plugins.
Take
all
the
decisions
in
that
scenario
as
well.
B
A
B
I'll
put
I'll
I'll
continue
experimenting
and
put
a
few
simulations
in
the
pr
description
when
I,
when
I
do
so.
A
C
Yeah,
so
I
went
through
that
umbrella
issue
today
and
just
collected
all
of
the
vr's
that
have
been
submitted
and
put
them
in
order
in
the
main
description
there
we've
gotten
a
couple
merged.
There
are
some
that
are
just
waiting
approvals
from
other
people,
some
that
need
rebases
and
the
only
two
so
far
that
have
been
kind
of
tricky
that
I
think
we
might
need
to
table
for
a
bit
are
there's
two
that
are
around
volume,
binding
and
volume.
C
Dependencies
which
abdullah
said
were
more
entangled
with
our.
I
guess
I'm
pulling
it
up
here.
We
have
a
dependency
on
the
volume
binder,
so
removing
dependencies
to
like
package
volume
might
be
tricky,
but
yeah.
A
lot
of
these
pr's
just
need
to
get
some
attention
from
like
there's
other
groups
that
need
to
approve
them
and
there's
discussion
going
on
in
the
brs.
I
don't
think
that
there's
anything
specific
that
can
be
sorted
out
in
this
meeting,
but
if
anyone
had
any
questions,
I
can
answer
them.
B
C
C
B
C
Yeah,
I
guess
api
machinery
would
be
a
good
spot
for
some
of
those,
because
that's
the
staging
repo
and
yeah
a
lot
of
these
are
just
like
getting
pod
status.
I
mean
that's
just
an
example.
I
thought
I
don't
know
if
that's
a
specific
one
in
here,
but
it
is
like
wrappers
around
handling
api
objects
a
lot
of
times
so
yeah.
C
That
might
be
an
approach
to
take
I'll,
have
to
go
through
again
and
look
at
specifically
what
some
of
the
problems
are,
but
our
big
ones
are
just
around
the
volume
dependencies
like
I
said,
the
others
are
kind
of
just
waiting
for
owner's
files
to
get
to
it.
C
A
All
right,
thanks
mark
and
before
I
continue
does
anyone
has
some
items
to
discuss
some
issues.
Some
questions.
B
I've
been
monitoring
this
bug
about
any
containers
not
being
considered
for
for
resource
allocation,
so
the
issue
is
fixed
now,
but
it's
taking
time
to
get
attention
from
release
reviewers,
because
this
has
to
go
back
all
the
way
down
to
116..
B
So
I
I
know,
if
any
of
you
have
any
or
know
anybody
that
is
responsive
enough.
Otherwise
I'll
just
join,
seek
release
meeting
on
monday.
A
So
the
background
is
that
in
the
scheduling
code,
there's
a
there's,
a
bug
that
we
didn't
respect
the
init
container
in
our
sum
of
the
score
plugins,
so
that
will
cause
some
parts,
for
example,
which
has
innate
containers
the
requests
in
the
unit
container
much
higher
than
the
normal
regular
request
can
be
referred
to
a
non-desirable
node,
so
that
is
kind
of,
but
we
we
just
fixed
that
and
that
issue
needs
to
be
back
pocket
back
party
to
the
lower
version
of
kubernetes.
C
C
A
I
think
that
is
pretty
much
for
our
ongoing
items.
Okay,
there's!
One
more
item
is
the
preemption
extension
point
design.
So
last
time
I
raised
the
the
brainstorm
issues
on
the
possible
options
to
going
forward
and
I
think
that
has
made
good
progress
so
for
each
point
there
are
several
options,
so
I
try
to
implement.
A
Some
draft
appears
on
those
and
compare
the
impacts,
so
that's
going
well,
I
think
the
right
now,
based
on
my
experience,
maybe
the
most
promising
way,
is
to
to
extract,
for
example,
a
preemption
handler
which
can
be
an
interface
to
to
have
all
the
necessary
logic
extracted
as
a
function
and
pass
that
interface
handle
to
the
let's
say:
post-filter
extension
point,
so
that
those
kind
of
information
can
only
be
used
in
the
post-filter
phase,
because
some
important
logic
can
should
be
passed
there,
like
called
the
filter,
plugin
called
the
pre-scope
plugins
to
make
the
preemption
logic
can
work.
A
That
is
overexposed
those
kind
of
information.
So
I
think
right
now.
I
think
that
is
the
most
promising
way.
So
it's
going
on
well,
I
think
it
maybe
can
be
included
in
the
119
release.
Oh,
but
by
the
way
the
119
release
will
be
very
likely
to
be
postponed
for
three
weeks.
I
think
for
the
final
date,
so
I
think
the
the
proposal,
the
the
old
proposal
date,
was
end
of
july
sorry,
end
of
june
right
now.
The
new
proposal
date
is
three
weeks
after
july.
1St
sort
of
just
let
you
know,
sounds
good.
A
All
right,
since
nobody
has
other
items
to
discuss
so
thanks
for
being
here
for
today's
meeting
and
let's
meet
maybe
next
week
or
next
next
week,
thanks
everyone
bye.