►
From YouTube: Kubernetes SIG Scheduling meeting - 2018-09-06
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
So
for
today
let's
see
what
is
what
is
done
for
112
and
what
is
left
to
be
done.
One
of
the
items
was
equivalents.
Cash
actually,
I
was
I,
went
back
and
looked
at
the
equivalents.
Cash
and
I
saw
that
in
the
past
six
months,
basically,
the
past
two
releases
I
have
previewed
pr's
and
dogs,
a
total
of
10
PRS
and
documents
for
the
equivalents-
cash,
mostly
I,
guess
PRS
for
making
various
changes
to
equivalent
cash,
and
we
are
still
at
a
position
that
we,
we
don't
feel
like.
A
11S
cash
is
there
so
it's
it
probably
makes
sense
to
have
equivalents
cash.
For
at
the
moment,
I
we
have
only
one
predicate,
which
is
which
is
interpret
affinity
and
that's
the
one
that
we
have
seen
significant
improvement,
but
even
for
that
we
have
had
some
new
optimizations
that
have
has
increased
performance
of
affinity
by
another
10x.
So
so,
even
for
even
for
that,
we
are
probably
not
going
to
see
as
much
improvement
anymore.
A
So
the
question
is
now:
should
we
continue
with
the
current
equivalents
cash
given
that
it
adds
quite
a
bit
of
complexity,
especially
with
respect
to
invalidation
and
the
race
condition
between
invalidations
and
the
regular
or
flow
of
the
scheduler,
basically
snapshot
again
running
the
predicates
and
everything
so
the
court?
The
big
question
for
us
at
the
moment
is
whether
it
makes
sense
to
keep
equivalents.
Cash
I
would
like
to
hear
his
opinion,
and
then
we
can
discuss
with
you
folks,
if
you
have
any
ideas
or
what
is
what
is
your
take
on
that?
D
So
actually
the
background
we
work
how
equal
in
cash
is
pretty
early,
which
at
that
time
we
don't
have
enough
scheduler
cash.
That
is
why,
and
that
time
you
connect
catch
works
very
well,
but
today
we
already
have
I
can
see
that
we
already
have
quite
enough
scheduler
cash,
and
are
you
talking
about
sorry
sorry
for
interrupting
sorry
talking
about
just
a
regular
scheduler
cash
that
cashes
notes
the
regular
schedule
accounts
when
we
working
on
the
criminal
Kashmir
Valley
people?
D
Actually
we
don't
have
enough
scheduler
catcher
for
not
only
no
decided,
but
also
the
pause
or
something
in
our
schedule,
cash.
So
that's
what
I
work
off
your
coding?
It's
a
it
is
likely
a
helper
for
the
scheduler
capture
actually,
but
today
we
have
put
enough
information
in
scheduler
cash
and
and
as
well
as
the
metadata
yeah.
The
last
thing,
the
benefits
that
we
couldn't
catch
is
limited.
Today,
that's
my
opinion.
That's
that's
what
I
feel
when
trying
to
improve
the
equal
in
cash
feature,
so
I
think
it
makes
sense.
D
A
Thank
you
for
for
sharing
your
opinion.
Yes,
you're
right,
so
one
thing
that
actually
you
mentioned
that
came
to
my
head
is
that
we
do
some
sort
of
some
amount
of
pre-processing
for
all
the
parts,
and
this
pre-processing
happens
whether
we
use
equivalence
cache
or
not.
So
there
is
basically
this
sort
of
fixed
amount
of
overhead
that
we
do
for
pre-processing
and
generating
metadata
per
pod,
and
that's
not
gonna,
go
away
with
equivalence
cache.
So
all
of
these,
in
being
in
place,
equivalence,
cache
becomes
less
important.
A
We
see
about
80
parts
per
second
can
be
scheduled
by
by
discovering
in
large
clusters,
which
is
actually
a
pretty
good
number.
It's
not
low
at
all
and
for
anything
around
like
2000
2500,
ish
clusters,
or
maybe
today
is
actually
even
more
than
that.
We
are
limited
by
the
QPS
of
the
API
server.
So
basically,
scheduler
is
fast
enough
to
exhaust
all
the
bandwidth.
That
is
hot,
that
it
has
from
data.
A
A
Every
time
I
make
a
new
change
to
the
cluster
or
to
the
scheduler.
We
need
to
think
carefully
about
whether
it
requires
invalidating
equivalents.
Cash
or
not.
So
all
of
these
combined
I
also
feel
like
you
may
not
need
equivalents.
Cash
or
not
I
mean
don't
need
it,
but
it
makes
less
sense
these
days
to
have
an
equal
asking.
Is
there
anybody
else
who
has
a
different
opinion,
or
do
people
generally
agree
with
me
or
the
one
type
I
would
like
to
hear.
E
Yeah
essica
agree
or
agree
with
you
that
he
couldn't
cash.
Maybe
maybe
me
not
gay.
We
enough
improved
for
the
performance
in
our
product,
so
we
also
do
how
similar
things,
but
this
will
be
in
the
butt
way.
You
worry
star
channel
feature
kids
becase
for
them.
No,
we
can
do
the
performance
improvement.
E
Furthermore,
such
as
the
feature
you
you,
you
submit,
you
want
or
tell,
and
some
enhancement
for
the
finally
about
documentation.
Yes,
I
think
a
way
for
the
scheduled
performance
away
when
you
start
can
of
feature
or
such
kind
of
improvement,
and
when
we
fun
like
we
need
start
a
general
general
cash
for
them
was
such
a
legal
cash.
We
can
evolve
this
later
yeah
and
the
photo
you
current
character.
I
think
we
use
a
pen,
some
common
Society.
We
would
like
to
isolate.
E
You
can
cash
in
see,
though,
for
you
know
you
write
a
data
with
furthermore
some
sailor
Chandra.
We
need
to
invalidate
the
cash
and
there's
there
were
several
there.
Civil
Code
cross
the
scatterer
code.
This
may
make
me
hard
to
manage
this
part.
Yes,
yes,
yes,
I,
think
well,
I
think
we
can.
We
can
we
revisit,
you
can
cash
whether
this
is
a
day
enough
improvement
compared
to
it.
A
A
B
E
Yes,
I
think
I
also
would
like
to
you
know
isolated
such
cannibal
code.
Again
just
one
place.
Yes,
I
know
when
pulled
up
day
to
winnowed
a
potato
in
several
things,
change
the
way
near
to
humanities,
Ukraine
cash.
Let's
make
up,
let
me
make
house
hard
to
maintain
our
code
and
it's
better
for
the
new
contributor.
E
A
And
another
idea
that
we
could
explore
it's
kind
of
similar
to
equivalence
cash,
but
it's
much
in
a
way,
it's
much
less
effective
and
it's
to.
Basically,
when
we
evaluate
a
part,
there
could
be
many
more
parts
in
a
cluster
with
and
respect
right.
So,
especially
when
you
create
a
large
deployment
or
each
create
a
lot
of
replicas
said
stage.
Was
that
one?
So
they
have
very
similar
aspect.
A
One
idea
is
that
we
put
all
of
those
in
sort
of
like
one
group
and
then
we
actually
try
scheduling
one
out
there
if,
if
one
cannot
be
scheduled
in
none
of
the
other
parts
in
that
group
can
be
scheduled.
So
basically
we
put
pending
parts
in
that
gun
and
that's
basically
our
equivalence
group.
Now,
yes,.
B
A
Of
the
many,
if
one
is
not
scheduled,
we
we
no
longer
is
scheduled
the
rest
time
to
schedule
the
rest
that
gives
us
some
performance,
the
improvement,
especially
in
clusters
that
are
always
under
resource
pressure
or
run
twice
together
minute,
because
they
all
have
a
lot
of
pending
parts.
This
is
especially
important
in
clusters
that
drawn
bad
jobs.
This
might
be
like.
Yes,
there
are.
E
A
B
D
This
really
sound
good
to
me.
That
is
actually
one
of
the
original
benefits
you
want
to
use.
It
kind
of
you
couldn't
catch
to
do
and
this
live
is
what
we
want
to
do
in
a
scheduler
and
one
thing.
Another
thing
on
information
is,
you
know,
I
think
when
you
fir
curse
own
to
make
the
common
scheduler
I.
Have
it's
the
motor
feature
stage,
because
you
know
we
are
trying
to
working
out
the
scheduler
framework.
D
A
Interest
of
time,
let's
move
on
to
our
other
items.
We
have
a
quite
a
few
since
way
is
here.
Wait
so
I
understand
that
tainting
note
by
condition
is
kind
of
promoted
to
beta.
So
there
are,
there
is
still
remaining
items.
Robbie
has
at
Senate
PR.
What
is
the
status
of
that?
Oh,
you
may
have
scheduled
demos
and
not.
A
A
A
Yeah
thanks
obvious,
you
know
I
can
ask
him
directly
as
well
so
Ravi.
Do
you
think
we
can
still
measure
that
PR
given
of
your?
We
are
after
code
freeze
now,
yeah.
B
C
E
E
A
D
Yeah
and
the
me
is
the
image
of
the
qualitative
insurance
right
now
on
track
for
one
per
12
and
and
of
course,
we
design
our
to
shape
the
end-to-end
test,
because
the
retest
image
is
too
huge.
So
the
the
sleep
test
people
is
very
worried
about
them.
So
we
should
a
very
well
designed
integration
test
minute
and
I.
Think
right
now
everything
works.
So,
let's
see
how
it
works
in
the
future.
Okay
sounds
good,
so
these.
A
A
E
For
for
the
gardening
I
update
another
round,
I
think
they're
in
there
is
another
round
design,
taco
review
yeah
and
we
are
going
to
only
keep
a
schedule
on
party
and
there's
a
proposal
right
now.
Yeah,
no
well
I'm
going
to
separate
the
lab
psych
amendment
in
the
other
proposal,
and
yes
and
there
we
also
have
a
discussion
about
the
transaction
in
the
automation
controller.
They
are
going
to
introduce
resource
our
results.
This
you
can
know
how
many
opposed
group
were
going
to
require
the
result
yeah.
E
No,
this
we
work
together
with
with
the
resource,
Quadra,
yeah
and
I,
just
a
keyword,
a
section
to
describe
this
teach
this
this.
This
part,
yeah
and
I,
will
go.
Do
another
detail,
design
document
to
how
to
implement
the
improve
implement
in
this
can
or
this
feature.
Yes,
we
need
to
work
together
with
a
resource
culture
for
this
part,
but
yes
in
kebab
caterer
we
already
have
such
candle.
We
already
have
gown
scheduling
all
costs
getting
EMV
in
here
without
automation
or
the
miss
introduction
part.
A
B
E
D
D
E
B
A
A
For
these
extension
points
for
113,
so
probably
we
are
gonna,
have
some
issues
quartz
and
some
of
these
smaller
pieces
of
this
scheduling
framework
are
gonna,
get
implemented
into
our
guarantee.
Scheduler.
That's
one
thing
for
2013
the
other
one,
the
other
week,
sort
of
like
longer-term
project,
which
we
have
been
working
on.
It
was
party
scheduling,
policies
that
we
have
been
working
with
this
sick
policy
and
Yassin,
and
the
company
has
been
working
on
the
PR
for
the
proposal.
B
A
That
is
added
or
like
a
cont
controller
that
is
added
to
components
so
yourself
or
that
I
might
is
here.
He
is
the
person
that
who
helped
us
build
the
optimization
for
affinity
and
anti
affinity.
I
would
like
to
thank
him
in
person
since
he
is
here.
Thank
you
so
much
for
your
contributions.
It
was
made
a
huge
difference
in
the
performance
of
the
feature.
We
definitely
needed.
Those
performance
improvements,
as
the
feature
was
really
slow,
as
some
of
you
folks
might
know,
affinity
an
anti
affinity,
we're
talking
about
pod
affinity,
a
not
a
affinity.
A
The
feature
was
about
a
thousand
times
slower
than
many
other
predicates
in
the
scheduler.
So
with
a
couple
of
optimizations
we
implemented
for
for
the
feature
we
saw
about
a
hundred
twenty
X
performance
improvement,
so
something
that
in
benchmarks,
we
were
saying
that
pod
could
take
like
six
hundred
millisecond
to
be
scheduled
and
anti-authority
in
a
large
cluster.
We
are
now
saying
it
being
scheduled
in
five
minutes.
So
there's
a
huge
performance
improvement.
I
am
really
excited
about.
That
way,
is
working
on
another
PR
to
address
an
issue
and
the
implementation.
A
Sorry
that
I
wasn't
able
to
review
it
more
quickly,
I.
There
is
like
this
purse
I
care
like
Google
right
now
going
on,
and
we
had
to
all
right,
our
self
assessment
and
all-
and
it
was
like
collide
with
the
code
freeze
as
well,
so
sorry
about
the
delay,
but
I
will
definitely
review
that
and
you
have
to
measure
it
in
112
as
well.
A
These
are
pretty
much
all
the
items
or
Ravi
is
gonna
help
us
to
basically
we're
gonna
discuss
our
plans
for
these
scheduler.
These
scheduler
is
basically
the
component
that
is
going
to
be
built
as
a
separate
component
for
now
at
least,
and
have
clusters
to
have
a
more
balanced
resources
or
well.
The
details
are
the
features
that
we
would
like
to
schedule
to.
Support
is
not
very
clear
at
the
moment
what
we
are
going
to
work
with
Robbie
and
over
it
had
to
figure
those
out
soon.
A
B
A
These
are
all
the
items
that
I
wanted
to
talk
about
today,
as
I
said,
we
are
gonna,
have
some
discussions
about
the
features
that
we
would
like
to
add
in
113.
If
you
have
ideas,
please
share
them
with
us,
or
you
know
we
have
this
screen.
We
have
this
spreadsheet
that
is
available
in
our
meeting
notes.
The
link
is
available
in
our
meeting
notes.
A
We
use
for
planning,
please
feel
free
to
go
ahead
and
add
your
feature
requests
or
if
you
are
willing
to
work
on
any
of
these
features,
please
go
ahead
and
comment
on
that
or
send
an
email
to
me
directly
you're,
going
to
consider
those
for
113
I
have
a
few
items
as
we
discussed
today,
and
also
some
other
stuff
that
I
have
in
mind.
I'm
gonna
update
the
spreadsheet
to
target
or
the
next
week.
Is
there
any
questions
or
comments.