►
From YouTube: Kubernetes SIG Scheduling Meeting 2018-04-26
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,
let's
start
hello,
everybody
and
welcome
to
our
Sigma
team.
Our
agenda
today
is
an
update
on
items
for
111,
particularly
priority
and
preemption.
2
beta
is
on
track,
so
for
equivalence,
cache
I
believe
is
in
and
is
on
track.
Jonathan
should
know
better
and
Harry,
if
is
in
the
meeting
I,
but
I
believe
they
are
on
track.
So
we
are.
We
basically
have
to
wait
and
see
how
our
tests
will
be
in
the
next
week
or
so.
A
A
B
A
C
Yeah
I'm
having
trouble
connecting
from
this
computer.
Sorry
so
I
guess
the
as
I've
been
learning
the
scheduler
codebase.
The
question,
on
my
mind,
has
been
what
is
the
go
API
of
a
scheduler
because
we
have
a
lot
of
you
know
exported
symbols
that
don't
seem
like
they
need
to
be
exported,
and
so
I
was
wondering
if
the
sake
in
general
had
a
maybe
clearer
picture
of.
A
Yeah
so,
unfortunately,
we
don't
have
any
very
clear,
very
clear
guidelines
about
what
what
can
be
used
from
scheduler
and
what
cannot.
There
are
some
components,
particularly
autoscaler
and
demons
as
controller
that
use
some
of
the
scheduler
API
and
I
guess
it
has
been
kind
of
ad
hoc
or
basically
based
on
the
needs
of
other
components
that
we
have
exposed
certain
libraries,
mm-hmm,
I
guess.
The
only
way
we
can
know
today
is
to
look
where
they
are
used
in
the
code
base.
A
But
if
you
think
there
are
certain
things
that
are
currently
public
and
shouldn't
be,
and
you
don't
find
any
usage
for
those
components,
all
right
to
say,
okay,
you
can
possibly
think
about
removing
them
and
we
can
communicate
and
you
know,
send
emails
I.
Let
everybody
know
that
you're
gonna
remove
that
publicly
available
yeah.
B
D
A
C
A
A
A
D
A
D
A
E
A
C
A
C
E
A
little
confused
about
how,
if
it's
not
just
like
capital
letters
they're
starting
word,
capitalized
words
exports.
What
hackery
people
who
error
things
are
going
on,
but
and
sciences
mostly
go.
Perhaps
though,
like
are
there
particular
scheduling,
expertise
that
could
be
brought
to
the
problem.
Is
that
silly
I?
Don't.
C
Know
that's
a
valid
question.
Nothing
about
this
seems
like
a
scheduling
problem
to
me.
It's
more
just
like
a
generic
go
project,
question
I'm
new
to
the
scheduler
and
I'm
new
to
the
go
language
so
I'm,
looking
at
things
and
asking.
Why
are
they
this
way
and
and
if
there's
agreement
that
there's
a
better
way
than
I'm
willing
to
push
towards
that
so
Jen,
but
generally.
A
A
The
libraries
remain
the
same
as
they
are
today.
They
may
change
the
functions.
We
may
change
the
arguments
to
functions
and
a
lot
of
this
and
we
may
end
up
breaking
other
components
if
they
use
them.
If
you
want
to
use
something
like
this
part
is
schedulable
on
this
note
or
not,
you
can
probably
provide
a
library
that
can
tell
you
that,
and
we
can
provide
some
sort
of
guarantees
that
in
the
longer
term,
you
will
support
that.
E
A
B
One
thing,
although
I'm
sorry
like
I,
missed
the
initial
party
like
what
was
the
right
object
context,
but
regarding
exporting
I
would
say
because,
like
based
on
my
experience
with
cluster
capacity,
I
think
two
or
three
important
at
least
two
important
things
so
that
we
were.
We
would
want
to
export
all
the
ways
I
mean
what
one
is
related
to
capacity,
but
other
parties
in
general,
like
first
of
all
like
how,
if
someone
was
to
create
a
create,
an
instant
of
a
schedule
or
outside
of
the
default
schedule
on
how
to
do
that.
B
So
basically
exporting
that
part,
for
example,
just
create
a
scheduler,
and
we
just
have
this
similar
instance
of
their
to
schedule.
A
default
scheduler
I
completely
agree
with
that,
because
previously
previously,
because
of
so
much
refactor
like
we
I,
have
seen
oh,
it
was
really
pain
to
rebase
klutzes
capacity.
Because
of
that-
and
in
fact
this
thing
might
be
helpful
in,
like
you
know,
that's
not
usual
also
where
someone
wants
to
create
a
different
scheduler,
but
still
wants
to
stay
like
make
it
based
on
default.
Scheduler
on.
A
All
of
us,
I
guess,
I
agree,
and
actually
one
of
the
one
of
the
things
that
I
was
thinking
about
when
I
was
thinking
about.
Like
scheduling
framework
was
exactly
like
that.
I
was
thinking
that
we
should
probably
have
a
library
that
a
lot
of
plugins
can
use
and
maybe
other
components
which
are
also
enough
to
scheduler.
For
example,
the
customer
schedulers
cannot
use
as
well.
So
they
definitely.
B
And
I
think
regarding
whether
knowing
whether
a
pod
could
be
scheduled
or
not,
yeah
I
think
for
that
I
would
say
like
exporting
predicates
and
priorities
in
some
way,
so
that,
like
we
can
pick
them
were
selectively
and
then
based
on
demo,
like
whatever
tool
is
using
dozer
based
or
like
or
like
I
mean
all
the
political
authorities
are
exported,
and
let's
say
we
have
some
outside
tool.
Then
can
pick
those
predicates
and
priority
selectively
so
and
can
decide
and
what's
a
selectively
of
educational
priorities,
that
port
could
be
scheduled
or
notor
right.
A
Yeah
yeah
exactly
so
what
I
said
was
just
a
example
of
what
we
can
export
them.
What
we
cannot.
This
is,
of
course,
not
something
that
is
finalized,
and
we
should
definitely
stick
with
this,
but
did
this
was
just
an
example
of
what
can
be,
for
example,
as
you
said,
be
exported,
and
some
of
the
as
I
said
earlier
course,
ordering
functionalities
of
the
scheduler
should
probably
be
exported
and
we
should
keep
supporting
those.
A
Okay,
so
I
actually
didn't
look
at
my
emails
that
you
just
quickly
see
if
there
is
any
other
item
on
there
and
so
I.
You
also
would
like
to
remind
everybody
that
we
are
going
to
queue
con
next
week.
So
next
week
and
a
week
after
we
are
not
going
to
have
any
scheduling
meetings
and
we
are
going
to
resume
and
I
guess.
A
So
me,
seventeenth.
Alright,
we
are
gonna
resume.
Our
Sigma
teams
on
May
17th,
if
you're
going
to
kill
coin,
will
be
very
happy
to
see
you
Jonathan
and
I
are
gonna,
give
a
talk
on
scheduling,
deep
type.
I,
don't
know
how
useful
it
will
be
for
you
guys
who
are
already
familiar
with
the
scheduler
but
you're
more
than
welcome
to
attend
I,
don't
think
it's
a
deep
yeah.
C
A
Deep
dive,
we
decided
we,
actually,
we
were
thinking
about
what
to
what
to
present.
There's
some
cigs
use
it
as
a
sort
of
like
face
to
face
meaning,
but
we
decided
to
actually
make
it
a
little
bit
more
useful
for
a
broader
audience
that
they
attend
Q
Khan.
So
we
decided
to
give
a
introduction
about
the
scheduler
as
some
of
the
more.
A
D
A
You
know
so
far.
My
understanding
or
my
investigations
show
that,
yes,
of
course,
scheduler
performance
drops
or
throughput
drops
in
prisons
of
preemption,
but
that's
inevitable.
I
mean
scheduler
starts.
Looking
at
all
the
you
know,
when
a
part
is
not
scheduled
about
this
starts.
Looking
at
all
the
notes
again
starts
removing
and
adding
parts
and
figuring
out
what
is
the
minimum
set
of
victims
that
it
can
choose
on
different
notes,
basically
on
all
the
nodes
of
the
cluster.
A
So
of
course
it
it's
a
relatively
heavy
operation
and
it's
expected
that
performance
is
not
going
to
be
as
on
par
bit
like
a
scheduler
that
doesn't
do
preemption,
but
other
than
that.
I
haven't
seen
any
other
major
area
that
we
can
improve
performance
of
a
scheduler,
but
you're
certainly
welcome
to
try
and
see
if
you
find
any
areas
that
we
can
make
improvements,
there's
no
particular
P
or
other
than
a
couple
of
PR
that
I
sent
to
change
affinity,
an
entire
finicky
performance
other
than
that
I
don't
have
any
PRS
do.
A
We
don't
know
so
when
it
comes
to
scheduling
and
or
scheduling,
high-priority
parts
we
oftentimes
do
not
want
to
sacrifice
the
schedule
ability
of
high-priority
workloads
to
performance,
so
even
if
it
takes
some
time
to
to
find
victims
and
to
schedule
a
high-priority
part,
we
are
willing
to
take
that
time
and
schedule
the
high-priority
part.
That's
why
we
don't
really
care
if
it
takes
yeah.
D
A
A
A
Your
test,
we
definitely
do
in
India
scalability
tests.
There
are
scalability
measurements
as
far
as
I
know.
The
way
it
works
is
that
they
should
create
a
large
cluster,
then
start
creating
a
large
number
of
parts
and
then
measured,
maybe
I'm
wrong
I'm,
not
very
confident
about
all
their
tests.
But
that's
my
understanding
about
how
they
test
through
the
scheduler.
A
D
A
A
One
thing
to
consider
here
is
that
you
must
make
sure
that
those
parts
that
are
created
in
the
first
establishing
in
low
priority
parts
set
their
graceful
termination
period
to
zero,
otherwise,
the
scheduler
to
put
drops
not
necessarily
because
of
preemption
logic.
It's
because
that
those
parts
are
not
gonna
clear
for
a
long
time
after
they
are
preempted.
So
we
need
to
think
about
all
these
when
you
create
the
test.
E
A
You
know
pods
in
kubernetes
can
have
graceful
termination
gear
when
they
are
preempted
anyway
right
so
and
if
they
said
the
graceful
termination
period
kubernetes
respect
that
we
need
to
make
sure
that
they
don't
set.
When
we
are
testing,
scalability
or
throughput
of
a
scheduler,
we
must
make
sure
that
they
don't
set
graceful
termination
period.
Otherwise
the
scheduler
will
not
be
able
to
schedule
the
higher
priority
parts
for
a
long
time
after,
for
example,
30
seconds,
which
is
the
default
waste
which
I
mentioned.
A
B
B
B
A
B
Said
I,
don't
know
whether
we
have
talked
about
the
scheduling
policy
or
not
I
mean
I
saw
the
last
update
and
it
looked
much
better
than
the
previous.
So
but
I
haven't
seen
much
feedback
from
at
least
people
from
and
see
the
schedule
angle.
So
I'm
not
sure
like
if
we
or
if
you
guys,
are
going
to
discuss
that
in
cube
cone.
Also
during
Yukon
meetings
really.
A
E
A
D
B
It's
not
going
to
block
priority
and
preemption
and
like
we
have
one
dot,
I
mean
yeah,
that's
fine!
If
we
have
the
Alpha
in
1.8
Alba,
but
what
about
the
some
admission
pill
again,
implementation
that
that
is
going
to
be
based
on
that
scheduling
policy?
Are
we
storing
that
well
or
it's
just
scheduling
policy?
We
are
planning
for
doctor.
A
B
Yeah
one
more
thing
I
would
like
to
point
out,
because
previously
we
have
had
admission,
kill
again,
cells
that
are
based
on
a
schedule,
feature
select,
notes,
Lecter,
sentience
and
tolerance,
and
we
have
a
different
plugins
like
one
for
notes:
Lecter
one
for
Tess
intelligence.
But
so
now
are
we
planning
to
have
just
one
at
missile,
plugging
that
targets
the
whole
scheduling
policy,
or
are
we
still
okay
to
have
a
separate
plugins
that
targets
maybe
specific
feature
or
feature
of
their
scheduling
policy
on
specific
feature
of
a
scheduler.
A
Yeah
definitely
I
mean
these
people
who
are
who
are
trying
to
implement
this
and
they're
designing
it.
Hopefully
we
all
think
about
the
ways
that
they
are
gonna
separate.
These
pieces
as
well
and
I
I,
do
see
any
major
issue
with
having
one
single
admission
controller,
but
maybe
they
decide
to
do
it.
Otherwise,
if
it
makes
us
I,
haven't
really.
A
E
B
E
Yeah
I
think
that
the
question
is
sort
of
then,
how
do
you?
How
flat
do
you
make
policies,
and
do
you
expect
that
decomposition
and
the
complexity
sort
of
come
is
has
a
way
that
you
can
plug
in
in
like
layers
or
is
that
expected
to
be
a
tooling
outside
of
kubernetes
and
I?
Actually,
don't
have
against
for
that?
I
would
love
a
things
yeah.