►
From YouTube: kubernetes SIG Scheduling meeting - 2018-11-29
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,
I
just
started
recording.
As
you
know,
this
meeting
is
recorded
and
will
be
uploaded
to
public
Internet,
so
whatever
you
say
is
gonna
be
visible
to
public,
but
today
I
have
a
couple
of
updates
for
you.
Folks,
there
was
a
an
issue
recently,
you
know
in
the
scheduler.
This
issue
was
initially
discovered
by
our
scalability
team
at
Google.
A
So
I
was
honestly
a
little
bit
surprised
by
this
behavior,
because
I
felt,
like
those
parts
with
the
same
traditional,
necessarily
go
to
the
head
of
the
queue
but
later
on
when
we
left
at
the
top
algorithm
of
heap.
We
realized
the
reason
so
the
pop
algorithm
of
heap,
like
you
know,
you
can
read
the
text
books
as
well,
and
it's
the
same
implementation
in
go
libraries.
It
basically
swaps
the
head
of
the
queue
with
the
last
the
tail,
basically
with
the
last
element
in
the
queue
the
tail
and
starts
basically
removed
it.
A
Apart
from
the
end
of
the
queue
which
was,
it
used
to
be
the
head
of
the
queue
and
starts
running
heapify,
which
is
essentially,
we
arranged
the
heap
based
on
the
heap
algorithm.
But
since
all
these
parts
have
the
same
priority,
the
part
which
is
now
in
the
head
of
the
queue
and
usually
at
the
tail,
stays
in
their
head.
This
is
a
problem,
of
course,
because
the
part
which
was
at
the
bottom
of
the
queue
was
a
part
which
was
tried
recently
by
the
scheduler,
and
it
was
on
a
schedule
about.
A
So
it
goes
to
the
head
of
the
queue
which
tries
it
again,
and
so,
if
you
have
a
number
of
these
chances
already
scheduled,
we'll
just
keep
trying
these
on
the
schedule
of
all
pods
which
are
now
occupying
head
and
the
tail
dequeue.
This
is
a
problem
that
we
were.
We
have
sent
a
PR
to
address
the
the
way
to
address
it
is
that
the
scheduler
looks
at
the
priority
of
the
parts
and
orders
them
in
the
queue
based
on
their
priority.
A
But
if
the
priority
is
the
same,
then
he
looks
at
the
last
scheduled
time
so
parts
which
are
on
the
scheduler
both
have
their
have
this
like
timers
down
the
hadn't
already
I
mean
before
this
change.
I
mean
you've
always
had
it.
So
we
look
at
that
time
stamp
and
we
ordered
them
if
they
have
the
same
priority
bar
by
the
time
stamp.
If
these
are
new
parts
that
are
never
scheduled
or
schedule
has
never
attempted
to
schedule
them,
and
we
looked
at
their
creation
time
and
and
sort
them
based
on
their
creation.
A
I
think
this
also
addresses
a
problem
that
Sudesh
was
trying
to
address.
I
mean
this
is,
of
course
more
than
that
problem.
Only
Sudesh
was
trying
to
change
this
scheduling.
The
sorting
algorithm
of
the
scheduling
queue
to
sort
parts
which
had
the
same
priority
by
their
creation
time
and
I
was
a
little
bit
concerned
that
a
part
which
is
created
early
and
is
unschedulable
can
have
this
problem
that
we
just
talked
about
it.
You
know,
will
always
go
to
the
head
of
the
queue
and
the
scheduler
made.
A
A
We
would
like
to
plan
and
the
items
for
114
right
now.
We
have
a
few
items.
Unfortunately,
there
are
not
that
many
people
today
in
a
meeting
we
have
a
few
items
that
I
would
like
to
discuss
with
the
owners
and
assigned
to
them
and
basically
confirm
that
they
can
work
on
them
in
114,
I
speak
about
them
anyways.
Hopefully
they
will
take
a
look
later
at
the
video
or
maybe
meeting
notes,
and
then
they
can
come
back
to
us
if
they
cannot
work
on
them.
A
One
is
to
change
the
design
of
the
scheduler
equivalence,
cache
Jonatan
a.k.a,
mr.
Kidd
and
Harry
aka
restore
were
supposed
to
work
on
it
and
I
assume
they
are
still
gonna
work
on
it
and
finished
it
design
and
implementation
in
114.
So
it's
going
to
be
there.
We
are
hoping
that
Klaus
can
have
ganga
scheduling
an
early
version
of
ganga
scheduling
in
queue
that
in
1:14,
of
course
he
has
already,
but
that
prototype,
but
we
were
hoping
that
he
can
can.
B
A
A
Now
we
we
had
a
plan
to
implement
policy
edge
wing
policies.
The
problem
is
that
we
have
had
a
lot
of
discussions
about
how
to
design
scheduling
policies
and
the
policy
team
or
our
sick
earth.
People
have
had
various
opinion
about
that,
so
that
work
is
still
going
on.
Do
you'll
see
how
we
are
gonna
proceed
with
that
idea,
but
at
the
moment
I
am
NOT
super
optimistic
that
we
can
have
something
in
the
open
source
for
warm
14.
A
C
A
D
A
Far,
we
have
seen
pretty
promising
numbers
for
the
benchmarks
and
those
guys
released
yeah.
One
of
the
features
that
they
are
prioritizing
is
gang
scheduling,
yeah
I,
don't
know
how
much
overlap
we
have
between
the
two,
but
given
that
Satan
is
a
completely
different
scheduler.
Oh
yes,
it's
not
going
to
be
easy
for
a
lot
of
folks
to
completely
switch
to
per
se
them
at
the
moment
at
least,
and
what,
while
it's
still
not,
maybe
as
robust
as
their
default
scheduler
yeah.
C
D
D
D
Another
I
think
we
also
give
some
discussion
about
the
Kota
and
the
port
group
controller.
This
part
is
not
implemented
yet,
but
as
I'd
like
to
have
them
at
least
a
pod
whole
group
controller
you
import
for
him.
He
has
a
culture.
Part,
maybe
maybe
relate
a
little
context,
so
maybe
maybe
nasca
stab
yes,
and
maybe
maybe
you
know
the
downscaling
design
document
is
a
it's
not
much
Liat.
Yes,.
A
B
A
A
D
A
So
yeah
we
Ravi
is
not
here
today,
if
I'm
not
mistaken,
so
we've
had
this
idea
of
moving
these
scheduler
as
the
static
component
of
kubernetes.
I
would
like
to
hear
his
opinion
about
that,
and
then
Oh
way
is
here.
We
I
know
that
we
didn't
pursue
the
idea
of
supporting
multiple,
all
pods
for
inter
pod
Evan
ID
in
114
113,
because
we
decided
that
113
was
more
of
a
stability
release,
but
in
114
we
would
like
to
pursue
that
feature.
Do
you
think
you
had
the
time
to
work
on
it.
B
A
Great
thank
you.
We
would
also
like
to
move
pot
limit.
Priority
function
to
beta
Robby
was
working
on
it.
We
had
to
take
it
out
in
113
sort
of
like
last
moment,
because
some
of
those
tests
were
not
ready,
but
hopefully
we
can
have
it
in
114,
I,
don't
know
about
moving
balanced
number
of
attached
volumes
to
beta.
That
is
still
not
very
clear,
because
we
have
some
performance
concerns
about
that.
We
will
see
another.
A
Another
item
that
you
would
like
to
have
in
114
is
having
it
back
of
mechanism
for
on
a
schedule
about
parts.
The
idea
here
is
that
a
part
that
is
being
tried
many
times
and
it's
on
a
schedule
was
shouldn't.
Let's
say
that
this
is
a
high-priority
part.
This
part
go
obviously
the
head
of
the
queue
and
block
everything
behind
it,
so
we
should
have.
B
A
Of
mechanism,
so
that
this
part
is
backed
off
and
is
rescheduled
with
some
delay
if
it
turns
out
that
it's
on
a
schedule
of
all
and
if
scheduler
has
tried
it
a
few
times
already,
that's
something
that
you
are
going
to
add
so
another
thing
that
we
are
also
trying
to
do.
This
is
also
kind
of
similar
and
related
to
the
idea
of
having
a
backup
mechanism,
an
odds
optimizing
now
the
status
updates.
So
today
the
scheduler
retries,
all
the
unschedulable
parts
at
every
node
update.
A
This
is
needed,
but
the
problem
is
that
a
node
sent
a
node
updates
for
all
heartbeats
as
well.
So
no
it
sent
heart
beats
every
10
seconds.
Basically,
scheduler
receives
a
heartbeat,
which
appears
like
a
very
much
a
other
node
updates
that
may
may
have
more
in
formation.
So,
for
example,
if
I
know
it
has
a
new.
A
Is
going
to
be
a
node
update
if
it
has
a
new
team,
there's
gonna
be
a
new
update,
but
sometimes
no
it
doesn't
have
any
information,
and
this
node
update
is
simply
just
a
heartbeat.
We
receive
those
heartbeats
once
every
10
seconds
for
each
node,
so
you
can
imagine
in
a
custom
that
thousand
nodes
we
receive
by
we
I
mean
the
schedule
receives
a
hundred
node
updates
on
average
per
second
and
as
a
result,
the
scheduler
keeps
retrying
on
a
schedule
of
parts.
A
While
there
is
no
significant
change
in
the
cluster
that
could
make
these
on
a
schedule,
but
parts
of
schedule.
So
what
we
are
trying
to
do
is
that
to
look
at
these
node
updates
and
find
out
whether
these
are
actually
changing
something
meaningful
that
could
potentially
make
no
it's
feasible,
and
in
that
case
we
try
scheduling
parts.
Otherwise
we
just
don't
know
we
don't
want
to
strip
retry
those
parts
again
and
again.
I
have
one
item
in
my
agenda
to
work
on
the
scheduler
performance.
A
This
is
something
that
you
would
like
to
pursue
for
larger
clusters.
Scheduler
performance
in
larger
cluster
isn't
is
still
that
great.
So
in
right
now
in
our
scalability
task,
scheduler
throughput
is
about
like
55
pars
or
so
in
5000,
not
clusters.
You
would
like
to
improve
that,
hopefully
by
another
20
to
30
percent,
we
will
see
how
much
we
can
get.
I
will
be
working
on
that
and
114
I
guess.
A
A
A
D
A
D
A
D
A
A
Yeah
we
have
sort
of
like
by
default,
we
have
worst
fit
sort
of,
and
we
have
a
priority
for
for
most
used.
Basically
based
pick
the
gap
that
has
the
highest
amount
of
resource
utilization,
but
I
guess
what
you're
talking
about
there
is
right
is
best
fit
with.
Essentially
the
closest
match:
okay,
yeah.
A
A
D
A
B
A
Sounds
great
if
you
can
work
on
it,
that
would
be
great.
That
certainly
requires
us
to
seriously
consider
possibility.
I
mean
seriously
consider
a
performance
change.
We
don't
want
to
introduce
another
feature
that
would
cause
a
major
slowdown
in
the
scheduler,
but
that's
not
really
something
that
we
should
pursue.
F
D
B
D
A
C
A
We
can
now
I
just
considered
adding
more
features
if
there
are
not
making
it
too
slow
again.
So
yeah,
yes,
yes,
yeah
sure,
but
that's
a
good
point
that
class
product.
They
please
make
sure
to
look
at
that
P.
Our
class
has
me
and
I'm
pretty
sure
that
PR
won't
work
anymore,
because
we
have
made
a
lot
of
changes
to
the
code.
Yes,.
A
E
A
F
I
was
working
on
moving
the
event
handlers
as
part
of
the
cleanup,
so
I
updated
it
with
the
what
we
wanted.
So
if
you
can
take
a
look
and
see
if
it's
in
the
right
direction,
I'm
struggling
a
little
bit
on
how
to
make
the
trespass
I
think
it
might
be
something
with
how
I
might
have
made
a
mistake
in
the
PR.
So
I
am
I
want
to
put
more
effort
as
long
as
it's
in
the
right
direction.