►
From YouTube: Kubernetes SIG-Scheduling Weekly Meeting for 20200618
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
A
Giving
guarantees
to
anyone
when
a
pod
can
be
scheduled,
scheduled
and
I'm
talking
here
primarily
about
latency
as
aloes,
and
so
this
document
explores
this
without
our
dependencies.
How
can
we
provide
SLO
s4
pods
that
do
not
have
you
know
dependencies
on
external
components
as
basically
this
is
as
a
first
step.
So
please
take
a
look
at
the
document.
I'm
planning
to
have
a
first
card,
its
implementation,
probably
this
cycle
as
experimental.
A
A
A
A
One
SLO
provided
by
the
scheduler
could
be
I
guarantee
you
that
your
pod
will
be
scheduled
within
Y
seconds
if
it
like
more
practically.
What
you
would
say
is,
if
you
give
me
like
X
number
of
pods,
then
I
guarantee
you
that
Y
percentage
of
them
are
going
to
be
scheduled
within
Z
seconds,
and-
and
this
is
this-
is
important
to
implement
and
deploy
predictable
services
on
top
of
on
top
of
kubernetes.
It's
also
important
for
us
as.
A
A
If
there
are
no
other
questions
about
this
of
our
concerns,
we
can
move
to
the
second
item
with
chairs
preemption
refactoring
into
a
post
filter.
So
this
is
progressing
well
with
way
react
refactoring,
most
of
the
code
that
currently
exists
in
genetic
scheduler
and
then
once
that
code
can
be
moved
as
is
into
a
post
filter.
So
where
do
you
have
any
comments
on
this?
So.
C
Yes,
yeah
last
time,
I
raised
the
I
think
is
a
huge
PR
and
address
adjusters
great
they're
into
several
Mobile's
yeah,
so
even
with
small
eyes
still
issue,
one
has.
The
X
has
an
L
label
on
there.
So
it's
it's
a
good
practice
for
both
for,
for
all
contributors
to
candle
speed,
a
large
peer
into
several
small
and
the
rebuild
of
reviewable
peers.
Yeah,
that's
a
best
practice,
our
reviewing
that's
a
good
suggestion
and
crying
I
think
70
or
80
percent
of
the
work
has
been
down.
C
So
all
the
hard-coded
preemption
logic
well
be
moved
into
a
default.
Preemption
package,
as
I
will
also
use
this
chance
to
reflect
existing
unit
tests
because
some
of
them
post
writing
styles,
as
well
as
the
maybe
some
useless
and
dead
code
is
there.
A
radio
stations
can
clean
them
up.
I
think
when
this
is
completed,
I
will
demo
it
a
bit
how
it
works
for
both
entry
usage,
as
well
as
adultery
usage
on
extending
the
post
filter
is
20
points.
For
example,
you
can
solve
some.
C
A
schedule
is
complete
conditions
that
the
default
preemption
is
not
able
to
handle,
for
example,
the
right
now.
The
default
preemption
logic
can
only
premium
the
past
on
a
single
note,
but
we
don't
want
to
limit
this
to
the
developers.
So
maybe
I
will
use
a
demo
to
the
movie
the
possible
solution
to
tool
to
fix
more
conditions
on
preemption.
So
our
our
general
purpose
is
that
we
open
the
extension
point
for
users
to
be
more
creative
and
do
whatever
premium
should
be
want.
So
that
is
the
publicly.
A
A
B
That
was
me
so
I.
What
I
added
here
was
young.
Actually,
when
I
don't
see
him
on
the
call,
but
young
went
through
and
for
the
core
v1
helper
specifically,
because
we
have
a
bunch
of
different
internal
dependencies,
so
we
just
have
to
break
it
down
by
package.
I
think,
and
these
are
a
big
one.
You
went
through
and
you
looked
at
all
the
core
view
and
helpers
that
we're
using
and
the
big
question
really
that
we're
having
in
this
thread
is
what
ones
are
stable
enough
that
it's
safe
to
copy
them
other
places.
B
So
you
don't
need
to
depend
on
them
and
what
ones
arse
is
there
still
a
chance
that
they
could
change
and
those
should
be
moved
into
some
sort
of
external
importable
location.
So
there's
a
couple
questions
going
on
no
thread:
yon
did
a
really
good
job
of
very
thoroughly
exploring
which
which
helpers
were
using,
where
they're
imported
from
and
what
they
provide.
B
But
my
my
take
on
this
is
that,
if
their
helpers
for
v1
API
types
and
those
API
types
shouldn't
really
be
changing
at
on
anything
right,
so
those
should
in
theory,
be
safe
to
duplicate
anywhere,
and
some
of
these
functions
are
simple.
Like
checking.
If
a
paint
is
tolerated
by
toleration,
you
know
that's
something
that
I,
don't
think
will
ever
really
change
right.
The
question.
A
A
I
know
it's
outside
scheduling,
but
I
think
it's
extremely
important
that
will
allow,
like
you,
know,
allow
us
and
maybe
probably
other
other
components
to
cut,
to
cut
these
dependencies
and
make
them
only
on
staging
those
helpers.
Moving
me
to
see
I
think
there
are
some
function:
utility
functions
already
in
stealing
yeah.
D
A
B
A
Try
yeah,
that's
not
gonna
yeah,
like
I,
think
I
think
we
need
a
more
targeted,
like
so
I
connected
with
them
directly
open
an
issue,
for
example,
to
like
make
your
best
guess
about
a
specific
function.
Moving
it
into
a
specific.
You
know,
staging
repo
and
start
a
review
and
I
will
you
know
start
the
conversation
around?
Will
door
should
be?
Maybe
the
first
case
appears
is
not
going
to
be
right,
but
at
least
really
force
them
to
start
the
discussion
and
and
and
start
the
ball
rolling.
A
B
A
B
A
A
Okay,
one
last
item
is
I'm,
proposing
to
cancel
the
5:00
p.m.
meeting.
We've
been
cancelling
it
pretty
much
consistently
for
the
past
few
months,
it's
sort
of
late.
This
meeting
and
I'm
not
sure
it's
providing
too
much
value.
So
we
have
two
options:
either
just
cancel
it
or
we
cancel
it
and
extend
the
bi-weekly
meeting
into
an
hour.
I,
don't
feel
that
the
second
option
is
necessary
at
this
point.
I
don't
think
we
are.
A
C
A
Yeah,
that's
what
I'm
suggesting
a
we
could
extend
it
to
and
I
think
one
hour
probably
is
too
much
like
we
can't
keep
going
with
the
current
setup,
which
is
happening.
I,
don't
think!
We've
ever
had
like
a
problem
with
it.
Unless
there
is
a
guest
other
than
that
I,
don't
know,
I
think
I
think
we're
already
good
enough
with
half
an
hour
yeah.
D
Let
me
recap
so
and
let's
say
an
old
has
attained
and
then
the
part
has
a
toleration
which
includes
a
toleration
seconds.
So
what
this
means
is
that,
basically
the
thought
wouldn't
be
wouldn't
be
affected
before
that
that
toleration
seconds
have
passed,
but
but
it
could
happen
a
new
part.
The
Haase
toleration
would
would
get
scheduled
and
it
would
basically
run
for
a
little
bit
and
then
it
would
be
affected
almost
immediately.
B
If
you
can
I
don't
have
the
leader,
but
oh
yeah
I
was
looking
at
that
with,
although-
and
it
seems
to
me
like
so,
the
point
is
like
if
the
node
has
a
no
executing-
and
you
have
a
toleration
for
this-
is
my
thinking
about
this-
that
if
you
have
a
toleration,
there's
no
execute,
you
should
still
be
allowed
to
be
scheduled
on
there,
and
just
because
you
have
toleration
seconds
applied
his
use
case.
The
person
that
reported
its
use
case
is,
you
know
a
third
second
toleration.
B
The
other
thing
is
that
the
taint
could
be
evicted
before
the
Toleration
removed
before
the
Toleration
seconds
is
up,
and
in
that
case
I
would
I,
don't
know
if
the
pod
would
be
evicted
at
all,
something
that
I
didn't.
Think
I've
been
the
issue,
but
it
was
reported
as
a
bug
and
I.
Don't
think
it's
clearly
a
bug
yeah.
B
D
A
B
C
We
don't
need
to
use
the
informer
to
get
the
update
immediately,
where
in
heaven's
life
we
just
need
the
lister
to
to
fetch
the
API
resource
best.
So
for
that
that
kind
of
resources
it
quite
depends
on
when
we
initialized
less
appropriate.
If
you,
if
we
don't
time,
we
use
that
Lister
to
get
the
resource
list
is
empty,
so
so
so
so
I'm
not
sure.
What's
the
best
practice
and
the
conventional
pattern
to
trigger
the
initialization
of
the
Lister,
so
I
personally
were
questioning.
A
I
guess
from
the
perspective
of
API
machine,
is
probably
that
you're
gonna
have
to
take
the
instance
at
scheduler
initialization,
and
in
our
case
this
is
like,
since
this
lister,
like
the
suction
budget,
Lister
is
mostly
going
to
be
it's
fraught.
It's
going
to
be
used
by
a
specific
plugin,
which
is
the
preemption
plug-in.
A
Then
to
me
it
sounds
clear
that
the
proper
place
to
to
do
that
is
in
the
cost
filter
of
the
instantiation
of
that
force,
filter
and-
and
so
you
basically
take
a
you,
take
up
like
a
you
know,
a
reference
of
it
at
that
point,
and
so
you
get
the
list
of
properly
initialized
and
I.
Think
this
makes
sense,
because
you
don't
want
the
shedding
from
factory
to
initialize
or
Lister's
and
and
get
everything
in
and
and
requested,
and
for
things
that
you
never
going
to
use
right
as
I
think.
A
C
C
E
Hey
this
is
Sean.
Can
you
guys
hear
me
cool
I
have
one
question
so
for
the
D
schedule
there's
a
couple:
people
that
are
new
contributors
that
are
interested
in
adding
some
features,
I
think
there's
some
github
issues
out
there
related
to
some
enhancements
and
I
guess.
My
question
is:
what
would
be
the
process
to
create
like
one
of
those
design
review
documents
like
Google
Documents,
like
there's
two
specific
issues,
I
can
think
of
that
we
might
want
to
use
that
process
for.
A
A
E
Sure
yeah
there
were
there's
some
people
hitting
me
up
in
Kunis
slack
that
want
to
contribute
to
the
D
scheduler,
so
I
think
so
explicitly
more
specific,
I
guess
on
this
I
think
there's
a
feature,
a
github
feature
issue
for
adding
an
option
to
filter
by
a
name,
space,
pods,
positive
it
by
name,
sis
and
label
selector.
So
I
think
these
might
be
good
things
for
new
contributors
to
work
on.
So
we
might
want
to
just
review
those
kind
of
feature
proposals
and
then
we
might
be
able
to
have
some
new
contributors
work
on
those.