►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20220811
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,
hi,
everyone
today
is
the
august
11th.
This
is
six
scheduling
meeting.
As
you
know,
this
meeting
is
recorded
and
will
be
uploaded
to
youtube.
So
please
adhere
to
kubernetes
called
conduct.
C
A
See
that
okay,
the
problem
now,
is
that
every
time
I
scroll
I
have
to
go
back.
C
A
Again,
so
that
I
I
get
to
pause
my
mind,
which
is
strange,
update
to
zoom,
but
like
I
hope
that
you
see
the
agenda
for
today
now
we
guess
we
can
start
with
the
memory
leak
issue.
So
this
is
an
fyi.
A
A
So
this
is
the
issue
that
we
have
at
hand
with
the
from
the
memory
league.
A
Yeah,
so
thanks
to
amy
wayne,
I
hope
I'm
pronouncing
the
name
correctly.
They
discovered
the
memory
leak
as
related
to
basic
leaking
go
routines.
You
were
creating
a
basically
a
sub-context
from
the
main
context
of
the
scheduler
and
we
were
not
canceling
it.
We
were
creating
threads
or
go
routines
to
process
the
nodes
in
parallel
in
the
preemption
phase
during
the
post
filter.
A
So
the
fix
is
basically
to
explicitly
cancel
this,
that
sub
context
and
the
function
and
the
bigger
issue
is
that,
like
that,
like
general
context
that
the
scheduler
creates
at
the
very
beginning
shouldn't
be
really
used
directly
should
be,
we
should
have
a
sub
context
created
for
scheduling
cycle
and
that
one
like
gets
basically
garbage,
collected
or
created
like
cancelled.
A
I
mean
on
every
scheduling
cycle,
I
believe,
and
so
even
if
we
had
those
issues
downstream,
they
would
be
caught
by
the
you
know:
the
scheduling
cycle
level
context
getting
cancelled,
but
like
for
the
hotfix,
we
we
just
fixed
that
specific
thing,
and
then
we
have
a
follow-up
pr
that
fixes
things
upstream
in
the
code.
A
We
are
discussing
also
ways
of
how
can
we
prevent
these
mistakes?
In
the
in
the
future
see,
maybe
we
can
figure
out
a
way
we
can
just
basically
future
proof
it.
The
problem
I
see
here
is
that
I
think
this
has
been
going
on
for
many
releases,
not
just
the
past
two
or
three
releases.
A
If
I
read
the
code
correctly
for
previous
the
the
code
history
and
I'm
surprised
that
it
got
flagged
only
today,
aldo.
C
Yeah,
I
think
the
the
thing
is
that
this
is
not
leaking
the
routine
itself,
because
the
routine
finishes.
What
is
leaking
is
the
context
and
then
the
context.
It's
it's
a
very
small
amount
of
memory.
That's
why
it
takes
like
a
few
days
for
the
for
the
scheduler
to
for
the
memory
to
grow.
A
That's
a
good
point
right
and
that's
why
these
scalability
tests
that
we
have,
which
basically
run,
I
don't
think
they
take
like
they
take
a
few
hours
only
even
though
they
create
so
many
unscheduled
cause
at
some
point
right
and
they
get
retried.
While
this,
why
the
cluster
is
scaling
up,
those
kinds
of
memories
didn't
show
up
and
and
so
the
on
those
cables
like
this.
So
so,
as
you
mentioned,
it
needs
to
run
for
a
much
longer
time
for
it
to
manifest
itself.
D
Yeah,
so,
according
to
the
analysis,
so
at
the
beginning,
I
I
was
in
in
the
impression
that
if,
if
that
say,
all
the
potential
nose
has
been
running,
that
means
the
cancer
there
inside
of
the
check
now
function
will
not
be
caught.
That
is
the
current
status,
so
cancer
function
will
now
be
cut.
So
my
impression
was
that
the
child
contacts
will
be
garbage
collected,
but
it
doesn't
seem
the
case,
so
that's
also
implies
for
the
cases
that
preemption
doesn't
help.
D
All
the
qualm
has
been
reached.
That
means
the
internal
cancer
hasn't
been
caught.
Then
we
will
have
those
issues.
The
child
contact
seems
to
leave
some
memories
out
there.
So
I
think
that's
the
the
problem,
and
another
minor
issue
is
that
we
didn't
pass
in
the
child
contacts
into
the
check
note
which
is
incorrect.
D
We
run
the
check
note
in
batch
like
16.
I
think
that's
a
default
number,
so
that
means
we
still
have
some
flying
routines
running.
Even
the
cancel
is
being
caught
because
we're
passing
the
parent
context
instead
of
the
child
context,
but
that
is
fine,
because
the
global
things
were
finished
eventually,
but
fixing
that
minor
bug
will
also
you
know,
gracefully
terminate
the
unnecessary
goal.
Teams
on
the
fly.
E
Also,
this
fix
is
quite
one-liner
and
it
should
be
easy
to
spot
it
in
the
code.
Has
anyone
tried
to
just
through
grab
just
to
see
all
the
places
where
this
with
cancel
context
is
created
and
if
there's
a
corresponding
differ
like
call
of
the
cancer.
A
And
that
guardian
might
not
finish
by
the
time
we
call
cancer,
and
so
it's
there's
still
a
lot
of
nouns
around
it
and
that
that's
the
to
me
is
the
scary
part,
so
it
doesn't
seem
like
there
is
like
a
general
pattern
that
we
can
follow.
It's
sometimes
it's
most
of
the
time.
We
think
it's
it's
case
by
case,
but
you
need
to
look
at
it
and
see.
Okay,
does
it
make
sense
to
call
when
to
call
cancer?
Basically.
C
E
Yeah,
that
makes
sense,
I
just
wonder
like
if
there
is
any
easy
condition
to
spot
like
it's
called.
For
example,
the
cancer
is
called
inside
a
function
which
is
then
like
processed
in
in
like
in
a
in
a
parallel.
A
Then,
like
you
might
be
calling
cancer
before
that
go
routine
finishes
right,
so
that,
like
that,
that
pattern
basically
invalidates
the
idea
of
proposing
a
pattern
where,
for
every
condition,
right
away
called
deferred
cancer.
So
it's
not
doesn't
apply
in
in
general
because
because
of
the
that
case,
right
of
like
basically
in
the
in
the
middle
agora
king,
gets
created
and
doesn't
finish
in
time
by
by
the
differ.
D
D
So
in
that
case,
if
we
pass
in
the
the
say
we
have
a
functionality,
is
this
create
a
schedule
with
startup
business
and
then
inside
that
we
created
information
and
started
in
from
factory,
because
inside
the
info
from
factory
it
actually
spin
up
the
long
running
go
routines.
So
if,
in
that
function
we
defer
the
cancer.
That
means
we
will
sort
of
close
the
child
parent.
Sorry,
the
child
contacts
passing
the
informal
factors
builder
functions,
so
that
doesn't
work
so
just
yeah
reminder.
A
I
think
in
in
general,
like
as
I'll
discuss
for
your
scheduling.
D
A
You
have
two
main
proteins,
the
main
one
right,
which
is
the
one
executing
school
socket
and
the
binding
one.
So
if
those
two
have
their
own,
like
you
know
context
that
gets
deferred
cancelled,
then
that
should
be
fine
right.
D
Yeah
we
we
should
do
a
thorough
check
if
the
I
think
you
mentioned,
that
goldberg
can
be
helpful.
D
A
A
Maybe
that's
why
they
they're
not
using
it
or
they're,
not
using
that
static
analysis
and
in
kids.
E
You're,
like
I
just
one
last
note
to
this,
like
you
might
check
just
to
check
the
other
place
like
to
just
locally,
for
example,
to
replace
all
the
context
with
cancel
with
some
wrapper
very
like
a
track
like
if
each
call
to
with
cancel
has
a
corresponding
cancel
location.
E
Just
like
every
time
the
with
cancel
is
invoked.
We
like
log
that
this
specific
new
context
was
created,
and
then
we
just
every
time
the
cancer
is
invoked.
We
locked
another
like
a
message
saying
that
this
specific
context
was
closed
and,
like
maybe
try
to
like,
do
one
to
one
like
a
mapping
to
see
like
if
at
least
help
that
helps
to
discover
like
a
missing
implications
of
the
cancer
function,
like
just
a
suggestion.
Maybe.
A
In
terms
of
metrics,
I
guess
it's
about
like
monitoring
like
the
memory
leak
takes
a
long
time,
probably
to
show
up
or
maybe
a
metric.
I
don't
know
if
there's
a
metric
that
we
can
expose
related
to
number
of
contexts
that
still
exists.
Maybe
not.
We
have
one
for
voter
for
go
routines,
but
I
don't
know
if
you
have,
we
can
have.
A
A
So
for
the
discussions
we
have
one
related
to
record
plug-in
metrics,
I
think,
is
that
you,
john.
D
So,
basically,
on
the
recording,
the
metrics
for
each
plugins
execution.
So
that
is
good.
But
when
you
see
some
like
scheduling
spike-
and
it
happens,
if
it
happens
that
on
that
cycle,
it
doesn't
fall
into
the
temperature
and
suffering
chance
so
that
you
don't
have
enough
information
to
correlate
the
scheduling
spike
with
particular
scheduling,
plugins
performance.
C
When
the
scheduler
config
goes
to
ga,
it
doesn't
mean
that
it
cannot,
you
cannot
add
new
fields.
It
just
means
that
those
fields
will
exist
until
there
is
a
v2.
C
C
This
configuration
doesn't
seem
particularly
worrisome
to
me
if
it's
needed.
I
think
it's
completely
legal
to
have
this
this
flag.
This
configuration
in
the
in
the
scheduler
configuration.
D
And
so
in
our
component
config,
we
actually
embed
some
spec
from
the
component
base
repository.
One
particular
field
is
called
debugging,
but
that
debugging
spec
is
so
associated
with
some
profiling
conflict.
So
I'm
wondering
if
we
want
to
support
some
debugging
related
fields.
We
can
make
it
a
dedicated
struct
so
that
it
doesn't
confusing
with
other
spec
like
regular
ones
like.
D
C
C
D
A
Are
comments
yeah?
What
I'm
saying
is
you
need
to
duplicate
like
it's
true,
it's
experimented,
but
when
you
duplicate,
then
you
duplicate
them
as
v1
right.
A
A
You,
if
we
use
like
you
know
we
just
create
a
struct
and
with
a
reasonable
name,
maybe
something
related
to
metrics
and
all
metric
configurations.
Slowly
start
to
go
there.
C
Yeah
hi
sorry.
C
So
sorry,
I
I
was
listening
and
so
what's
the
conclusion
to
go
ahead
and
write
like
a
pr
for
this.
C
Yes,
I
would
say,
go
ahead
and
we
just
we'll
figure
it
out
during
the
review
whether
the
name
makes
sense
or
whether
we
want
to
struct.
I
would
I
think
I
would
just
start
with
them.
C
C
E
C
D
D
I
think
so
another
requirement
says:
okay,
I
don't
want
to
shuffle
the
the
percentage
of
multiple
score.
You
just
start
with
syntax
zero
every
time
instead
of
shuffling
the
index
and
that
is
sort
of
another
one,
but
basically
no
follow-up
on
those
requirements.
So
we
don't
know
how
how
much,
how
much,
how
many
users
are
demanding
that.
E
Sure
so,
a
few
weeks
back
lucas
started
implementing
the
context.
Contextualized
logging
for
the
cube
scheduler
is
the
actually
cube.
E
Scheduler
is
the
first
component
that
is
getting
this
nice
improvement
feature
so
and
the
reason
to
to
mention
this
is
to
get
awareness
of
the
seekers
scheduling
group
and
to
also
discuss
if
there
is,
if
you
agree
on
the
approach
right
now,
the
changes
that
public
has
made
are
more
or
less
just
propagating
the
vlogger,
the
new
logger
and
replacing
the
k
log
with
the
new
logger,
more
or
less
keeping
the
same
the
same
key
value,
pairs
and
he's
he
is
avoiding
using
the
with
name
and
with
keys,
sorry
with
name
and
with
values,
methods
because
there's
been
some
performance
degradation.
E
So
the
if
you
have
like
some
time
to
take
a
look
at
the
pr
that
would
be
great
lucas,
provided
the
performance
measurements
for.
E
Changes
but
still
those
were
performed
most
likely
locally,
but
I
think
that
alda
already
checked
those
performance
measurements
and
he
didn't
have
like
any
any
like
like
this
agreements
with
that.
So
the
idea
was
or
is
to
to
go
ahead
and
see
if
there
is
like
any
performance
degradation
once
the
vr
matches,
and
if
there
are,
we
can
always
like
undo
the
changes
so
like.
E
A
So
that
issue
is
quite
long.
It
seems
there's
like
so
many
different
discussions
that
that
happened.
I
was
just
going
back
related
to
introducing
apis
on
the
pi
itself,
to
control
debugging
and
how
things
and
I'm
guessing.
We
are
not
pursuing
those
ideas,
and
at
this
point
this
is
only
about.
C
No,
the
the
overhead
comes
from
getting
a
log
from
the
context
because
if,
if
you
have
a
chain
of
context,
then
yeah
each,
if
you
you
say
like
get
key
from
context,
which
is
what
you
would
use
for
getting
the
log
if
it's
not
in
the
first
context,
it
goes
to
the
parent
and
so
on
and
so
forth.
So
if
the
your
context
is
very
deep,
the
context
hierarchy
is
very
deep.
Then
you
you're
always
going
all
the
way
all
the
way
up.
A
C
I
think
there
is
no
general
guidance.
E
No,
unfortunately,
not
because
lucas
was
mainly
involved
in
this
in
this
effort,
so
I'm
just
like
talking
on
his
behalf
more
or
less
but
like
what
you
just
mentioned
about
like
going
deeper
into
context.
That
is
like
a
perfect
concern
for
waiting
until
we
resolve
this
and
maybe
to
redesign
the
if
there's
way
to
redesign
the
the
searching
in
the
context,
I
know
to
maybe
to
introduce
some
sort
of
a
cache.
E
Instead
of
going
up
and
up
and
up
and
up
but
further
like
we
need
some
performance
measurements
first
or
at
least
find
a
a
differential
machine
where
we
can
measure
the
differences
like
I'm,
not
sure
how
far
the
the
the
context
is
actually
going.
But
I
think,
but
you
know
right.
Yeah.
A
And
this
is
this
like
a
kids
library
or
like
something
we
are
importing
from
the
outside.
Still
on
the
case
project
or
completely
it.
C
Right,
we
just
have
to
be
careful
and
we
we
have
to
start
small.
D
Yeah
I
have
one
comment
on
this:
is
that
so,
if
we
think
about
logging,
we
usually
the
most
useful
area
is
that
we
have
some
issues
or
we
have
some
unscheduled
parts.
We
check
the
logs
and
we
want
to
get
more
information.
So,
in
terms
of
this
practical
usage,
I
would
see
like
in
the
benchmark
test
the
preemption
test,
which
will,
although
it
doesn't
prompt
a
lot
of
unscheduled
parts,
but
it
will
like
the
first
attempt
of
the
scheduling.
D
I
would
say
to
craft
some
tests
that
to
prompt
into
some
unscheduled
parts
so
that
those
unscheduled
parts
can
go
through
the
ordinals
like
3000
or
2000.
You
know
to
generate
more
logs,
so
that
maybe
can
be
more
helpful
because,
if
you're
running
the
happy
path
of
like
scheduling
pass
in
the
3000,
now
you
actually
just
hit
by
default.
I
think
the
10
is
500
nails,
so
that
is
doesn't
generally
large
volume
data
to
look
into
potential
performance
issues
of
the
contextual
logging.
A
Right,
like
the
file,
the
login
file,
I
don't
know
how
you
process
it
and,
like
I
guess,
different
car
providers
do
different
things
right
like
they
tail
it
and
send
it
somewhere
else.
A
But
like
how
many
logs
you're
printing,
if
you're
like
is
one
issue
and
using
this
new
approach
for
logging
is
probably
a
different
one.
Am
I
understanding
correctly
what
this
distinction
right.
D
A
Yeah
I
get
it
right,
so
there
could
be
paths
where
we
have
deep
context,
but
those
paths
are
not
regularly
hit,
for
example,
at
least
in
our
benchmarks,
right.
A
E
I
don't
think
that
the
amount
of
locks
will
increase
because
or
like
I
haven't
seen
the
log
lines
produced
by
the
context
device
logging,
but
I
think
it
will
be
the
same
amount.
D
A
Or
confirm
that
there
are
known
recommendations
for
additional
testing
and
just
basically
back
that
we're
moving
forward.
E
E
Great,
so
we
have
mike
on
the
go
as
well,
so
might
like
still
feel
afraid
to
interrupt
me
at
any
point.
So
right
now
we
are
in
the
process
of
migrating
the
strategies
into
plugins.
E
E
We
don't
have
like
any
specific
deadlines,
but
the
idea
is
to
at
least
before
we
release
a
new
d
scheduler
release.
We
want
all
the
strategies
to
be
migrated
to
plugins
and
once
the
framework
or
its
first
limitation
is,
is
in
place.
E
We
are
happy
to
to
accept
new
suggestions,
how
to
improve
the
the
code
base
so
like
mike
like
do
you
have
anything
else
to
share.
B
Yeah,
I
think
that
that
was
a
pretty
good
summary
thanks.
Yan
has
been
taking
a
lot
of
the
lead
on
you
know,
getting
the
reviews
done
and
making
sure
that
these
strategy
migrations
are
going
well.
B
This
is
really
just
like
a
big
refactor
of
the
d
scheduler
code
base,
and
you
know,
although
the
framework
approach
and
the
plug-in
approach
is
going
to
be
great,
for
people
who
want
to
you
know,
extend
it
or
customize
it.
Maybe
there's
use
cases
out
there
like
that.
It's
also,
you
know.
B
Our
goal
is
to
create
like
a
a
much
more
maintainable
code
base,
so
that
we
can,
you
know,
build
this
more
towards
a
stable
tool
that
people
can
use
and
with
that,
a
bit
of
a
framework
that
they
can
develop
their
own
eviction
logic
with
so
yeah,
like
young,
said
this
shouldn't
impact
any
of
our
upcoming
descheduler
releases.
B
The
way
that
we're
migrating
them
is
like
really
similar
to
how
the
scheduler
migration
went
and
that
we're
kind
of
wrapping
the
migrated
plug-ins
in
functions
that
treat
them
as
the
new
plug-in
type.
While
we
are
working
on
the
other
strategies,
so
this
should
be
really
seamless
to
anyone.
That's
using
the
d
scheduler
currently
or
like
just
doesn't
care
about
this
at
all.
B
So
there
shouldn't
be
any
effects
for
that
and
if,
if
there's
anything
that
seems
like
it
would
delay
our
descheduler
release
significantly,
we
should
be
able
to
push
through
and
create
a
release
without
having
to
hold
anything
up
on
on
any
migrations.
But
they've
all
been
going
really
smoothly.
Thanks
to
everyone
that
has
been
contributing
and
yeah.
B
If
there's
any
feedback
feedback
feel
free
to
add
it
on
the
slack
or
bring
it
up
at
a
sig
meeting
or
in
github,
but
we're
like,
like
young,
said
trying
to
sort
of
focus
on
this
refactoring
effort.
Right
now
before
we
take
on
big
new
improvements,
so
yeah
thanks
for
bringing
it
up
yeah
and
thanks
for
all
of
your
work
and
for
everyone
else's
contributions.
A
All
right,
thanks
and
and
mike
are
there
any
questions,
comments.