►
From YouTube: Kubernetes SIG Scheduling Meetings 20170605
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
A
B
B
All
right,
if
you
guys,
once
you
start,
we
can
do
so
so,
basically,
based
on
the
agenda
items
that
I've
seen
in
the
emails
looks
like
the
main
items
were
like
1.7
went
down
and
1.8
items
and
1.8
items
are
mostly
around
well.
According
to
David's
emails
or
most
era,
priority
API
preemption
and
eviction
work,
so
I
I
am
NOT
very
much
up
to
date
on
the
burndown
41.7,
but
we
can
briefly-
or
maybe
not
so
briefly,
talk
about
priority,
API
and
preemption,
because
those
are
stuff
that
I'm
working
on.
B
So
as
far
as
the
work
itself,
the
API
work.
Basically
the
the
PR
to
add
these
fields
to
the
API
is
already
sent
out.
There
is
a
PR
sent
out
a
while
ago.
There
were
quite
a
few
comments
on
it,
although
the
the
main
bulk
of
the
code
was
very
small,
basically
just
adding
couple
fields
and
adding
the
validation
and
test
for
it.
B
The
reason
that
I'm
saying
that
the
eviction
on
the
node
must
be
in
sync
with
the
preemption
and
the
scheduler
is,
is
the
fact
that
we
don't
want
to
ping
pongs
between
these
two.
So
if
note
eviction
works
completely
differently
than
how
preemption
works,
there
is
a
chance
that
note
evicts
an
item
from
a
from
the
note
and
scheduler
believes
that
that
item
should
be
scheduled
back
so
scheduler
schedules
it
back
on
a
note.
Perhaps
may
it
may
even
pre
and
some
other
workloads
or
pause
that
no
didn't
preempt
earlier
or
didn't
have
it
earlier?
B
Should
I
should
use
the
right
terminology
for
these
two.
So
eviction
is
basically
the
work
that
note
does
to
excel.
To
remove,
apart
from
from
a
note
and
preemption
is
the
work
of
the
scheduler
does
to
do
the
same
thing,
basically
you're
removing
a
part.
From
a
note.
We
are
using
these
two
words
to
distinguish
between
the
two
anyways
back.
B
So
what
we
have
in
mind
for
the
eviction
is
that
we
are
going
to
use
priority
as
the
highest
weight
in
determining
which
part
should
be
evicted,
and
we
are
gonna
break
ties
based
on
use
it
above
request.
So
probably
we
are
gonna
use.
This
is
not
finalized.
Yet,
but
probably
we
are
gonna
use
the
percentage
of
usage
above
request,
so
whoever
has
the
highest
usage
above
request
will
be
evicted
first
if
it
has
the
same
priority
as
other
jobs.
Other
parts.
B
B
As
far
as
the
document
and
the
actual
org
concern,
I
haven't
written
the
document
on
a
fusion,
yet
I
will
do
so.
Hopefully,
in
the
cup
and
the
remaining
weeks
of
June
and
I
am
optimistic
that
we
can
get
all
cough
the
code
at
least
the
first
version
in
41.8
I'm
happy
to
answer
questions
or
concerns
that
you
guys
may
have.
C
B
B
You
know
the
priority
itself,
I've
written
a
small
document,
and
you
may
have
seen
it
already
that
there
are
so
many
comments
when
it's
close
to
hundred
now,
but
that
one
is
relatively
final
now
I
say
relatively
because
I'm
not
sure
if
it's
completely
final
but
anyways,
that's
more
or
less
decided,
I'm
pretty
sure,
there's
gonna
be
a
whole
lot
of
discussions
around
preemption
as
well,
but
once
it's
finalized
I
will
be
very
happy
to
get
some
help.
Sure.
B
B
C
It's
related
to
the
scheduler,
both
modular
extinctions,
that
we
have
been
working
on.
Jay
and
I
have
been
working
on,
but
1.7,
so
Jim
Eric
from
Google
has
been
helping
us
out
for
the
code
review.
Part
I
just
want
to
get
the
six
scheduling
feedback
on
that.
Let
me
post
the
pull
request
in
here
on
soon.
Okay,.
C
C
C
C
D
C
C
B
C
B
B
B
B
E
But
there's
a
couple
other
items
for
1.8
that
I
I
don't
know
if
people
have
on
the
radar,
like
the
demon
set,
modifications
that
folks
have
discussed,
and
there
are
some
PRS
going
around
that
I
haven't
really
dug
into
yet
I.
Don't
know
what
the
take
on
that
is.
Is
the
idea
of
moving
demon
sets
the
schedule
using
the
main
scheduler
in
scope
for
1/8.
B
That
would
be
because
right
now
looks
like
there
is
some
other
problems
in
in
demon
set
scheduling,
and
you
know
there
is
that
there
is
a
pyaare
already
sent
out
a
while
ago
and
it
needs
a
three
base
and
the
author
is
busy.
So
what
I'm
worried
is
that
we
may
do
some
work
on
fixing
the
current
issues
and
it
will
all
be
wasted
efforts
once
we
want
to
move
everything
to
the
scheduler.
So
maybe
you
should
put
some
effort
into.
E
That
move
the
one
thing
that
concerns
me
is
that
the
demon
set
scheduling
has
been
used
as
kind
of
a
backdoor
for
folks
to
get
some
initial
bootstrapping
in
place,
because
we
don't
have
all
the
primitives
percolated
throughout
the
system
in
order
to
do
proper,
bootstrapping
right
like
we
don't
have
one
shot
scheduling,
it's
not
an
official
feature.
You
know,
like
that's
an
example,
because
if
people
use
demon
sets
as
a
way
to
get
around
some
of
these
things
right.
B
But
at
the
same
time,
I
guess
there
are
some
road
blockers
for
moving
scheduling
of
demon
system.
Scheduler
like
there
is
this
other
problem
with
marking
nodes
as
not
really
you've
seen
that
issue
right.
So
if
there
is
a
networking
networking
problem,
then
they
all
know
these
will
be
marked
as
at
cubelet,
not
reading
or
whatever
that
label
is
and
that
prevents
the
scheduling
of
anything
on
it.
So
there
are
some
of
these
road
walkers
that
should
be
removed
before
we
can
truly
have
it
in
the
scheduler.
F
B
F
B
Information
to
know
what
are
the
items
we
haven't
discussed
them
really
thoroughly.
There
is
there's
a
list
of
several
items
and
that
email
investor
ate
about
the
agenda
for
this.
This
week's
meetings,
so
those
two
a
lot
of
those
items
are
related
to
my
work.
I
will
do
my
best
to
get
all
of
those
in
for
1.8,
but
I,
don't
know
a
lot
about
other
major
features.
B
B
C
B
E
The
general
take
was
that
that
should
be
implemented
outside
of
core,
so
I
mean
that
was.
That
was
the
thing
we
all
agreed
on.
Is
that
step
zero
but
90%
of
it
whenever
it
entails,
because
he's
gonna
have
queues
and
whatnot
would
be
implemented
outside
of
core
using
TBR's
and
then,
if
there's
something
that
we'd
need
to
push
back
into
core
that
we
do
that.
You
know,
after
a
thorough
evaluation,
I
see.
Okay,.