►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20210225
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
welcome
to
this
week's
scheduling
meeting
this
meeting
is
being
recorded
and
will
be
uploaded
so
be
aware
of
your
whatever
saying,
and
let
me
share
my
screen
to
go
through
the
agenda.
A
Okay,
I
suppose
you
can
see
my
screen
all
right.
A
Yes,
okay.
The
first
item
is
from
nick
rayne
and
his
proposing
idea
of
changing
the
current
behavior
of
how
we
deal
with
the
updated
part.
So,
basically,
currently
one
of
her
update
events
gets
triggered.
We
will
first,
firstly
check
whether
it's
assumed
and
if
it's
not
assumed,
we
will
just
have
different
behavior
depending
on
whether
the
the
same
part,
the
old
part,
is
in
the
unscheduling
queue
or
active
queue.
So
what
we
are
going
to
propose
is
to
to
unify
the
behavior
so
right
now
there
is
some
debatable
discussion
here.
A
So
you
said
whether
we
should
move
the
path
to
active
queue
directly
or
respect
the
part
off
policy.
So,
for
example,
if
the
part
haven't
been
experienced,
the
full
life
cycle
of
fake
off,
maybe
just
put
them
still
in
the
back
of
queue.
So
this
is
the
debatable
stuff
we
want
to
come
up
with
in
this
meeting.
We
have
some
discussion
here.
A
I
think,
finally,
I'm
convinced
and
also
abdullah
and
the
other
guys
agree
that
we
like
to
go
with
the
the
the
direction
that
we
want
the
path
to
be
backed
off,
because,
basically
there's,
if
you
put
the
part
back
to
the
execute
in
this
situation
that
may
make
the
low
priority
queue,
has
less
chance
to
be
scheduled,
because
if
you,
this
updated
event
happens
very
frequently,
you
may
be
there,
you
will
admit
the
hol
problem.
So
this
is
the.
A
I
think
it's
a
severe
problem
we
want
to
avoid,
and
if
we
go
with
the
current
behavior,
which
is
the
sorry
if
we
go
with
the
behavior
there,
we
put
them
into
the
backup
queue.
So
I
think
the
downside
is
that
maybe
the
path
will
have
a
slightly
delayed
scheduling
latency,
because
it
has
been
still
in
the
back
of
queue
so
yeah.
This
is
current
discussion
result.
If
you
have
any
ideas
or
objection
with
the
direction
you
can
raise
it
up
or
comment
on
this
issue.
A
And
another
thing
we
from
the
discussion
we
found
is
that
abdullah
raised.
Is
that
why
on
earth
we
should
care
about
whether,
if
it's
a
assumed
part,
why
we
care
about
which
attribute
the
podcast
has
updated?
So
this
is
another
problem
we
also
discussed
here
and
also
the
results
is
that
it
seems.
There's
no
specific
need
to
compare
the
update
to
to
check
whether
the
attributes
of
the
update
part
has
changed
or
not,
if
it's
a
zoom
part.
So
this
is
the
last
discussion
so
yeah.
A
A
B
Yeah
with
regard
to
the
documentation
in
general,
if
there
are
more
contributors
willing
to
up
update
our
documentation
that
that
that
repo
is
highly
outdated
in
terms
of
it
still
talks
in
terms
of
policies
and
and
things,
we
don't
really
want
to
promote
and
we
support
as
much
anymore.
So
we
we
want
to
move
all
of
the
documentations
to
scaling
profiles
and
plugins
and
whatnot.
A
A
C
Yeah,
so
this
is
just
more
about
the
dependencies
relocating.
C
From
the
last
we
talked
about
at
the
last
meeting
and
just
to
recap,
we
looked
at
a
couple:
different
approaches
for
refactoring
these
dependencies
out
of
our
plug-ins,
moved
to
three
or
four
different
approaches
that
we
could
take
for
that,
and
it
seemed
like
we
had
kind
of
reached
the
consensus
on
this
one
approach
here
and
that
was
moving
along,
but
it
has
kind
of
stalled
out
and
some
people,
I
think,
like
aldo
and
abdullah,
you
guys
raised
some
recent
concerns
about
it.
D
Sounds
good
sorry
for
the
late
supply
I'll
automatically
sorry
yeah,
yeah.
C
Yeah
dude
offline
I've
got
everything
that
I
thought
written
up
here,
I'm
open
to
anything
that
I'm
missing
or
any
any
strong,
counterpoints
and
yeah
just
really
trying
to
get
this
moving
along.
Because
we've
had
this
issue
open
for
about
a
year
now-
and
you
know
I
don't
want
to-
I
don't
want
to
see
that
stagnated
out
and
would
like
to
keep
being
productive
with.
C
D
That's
good
yeah
and
thanks
for
the
like
great
progress
you've
been
making,
but
I
guess
like
compared
to
a
year
before
now
we
have
a
much
clearer
direction
and,
like
you
know,
creating
that
staging
repo
and
figuring
out
actually
like
a
path
forward,
so
yeah
great
progress.
C
Yeah,
I
think
that
that's
something
that
you
know
we
had
that
goal
and
now
that
that
has
been
solved,
we're
kind
of
like
okay.
So
what
is
the
direction
that
we
should
take
now?
Which
is
why
we
have
these
discussions
to
once?
We
can
decide
a
direction
to
take
in
these
first
couple
of
plugins.
I
think
that
that
will
make
the
rest
just
kind
of
fall
into
place
when
we
can
follow
the
pattern
that's
been
established.
A
Yeah,
I
think
in
the
earlier
I'm
more
prepared
with
this
option:
yeah
something
goes
down
back
and
forth
yeah.
Thank
you
for
all
the
best
driving.
A
A
If
you
have
any
blog,
you
can
I'll
put
a
link
here,
you
can
propose
some
kubernetes
blogs
there
and
they
will
coordinate,
maybe
publicly
the
kind
of
1
21
blog
series,
and
also
we
have
a
code
phrase
it's
march
9..
I
think
all
the
major
code
changes
should
be
finished
by
this,
but
we
can
do
exception
requests
later,
so
this
is
just
one
place.
A
You
can
look
at
every
almost
all
the
dates
myself
and
this
website
is
also
very
useful.
This
has
a
short
name.
I
guess
cubaness
got
that
yeah,
okay
and
also
another
thing
is
that,
starting
this
year
each
sig
are
responsible
to
kind
of
come
up
with
a
annual
report.
This
template
to
answer
some
questions.
A
We
are
going
to
provide
this
as
a
sort
of
health
report
and
some
communications
channels
to
see
how
basic
goes
with
like
how
the
meeting
goes
with
how
the
audience,
how
the
users
react
and
how
we
treat
our
state
as
what
kind
of
sleep
we
really
all
the
stuff
has
yeah
sort
of
this
is,
I
know,
but
if
you
have
any
good
suggestion
on
this,
you
can
comment
on
this
pure
or
just
be
an
or
optional
report
at
the
last
one
about
priority
class
value.
A
So
yeah
I
can
give
a
short
introduction.
So
priority
class
is
also
associated
with
the
plus
class
value,
and
that
player
class
is
immutable.
You
can
only
create
or
directly
not
update,
so
ravis
come
up
with.
Ideas
says
that
there's
some
downsides
with
this
approach,
because
if
you
don't
support,
update
user
can
still
work
around
that
by
create
by
delete
and
recreate.
A
E
Yeah,
so
we
we
actually
made
a
mistake
when
we
were
releasing
open
shift,
especially
in
the
last
release.
Four
or
six.
We
have
given
the
maximum
possible
user
priority,
which
is
one
billion
to
apart,
and
now
we
realize
that
it
is
a
mistake.
We
are
not
able
to
update
it,
and
the
only
workaround
that
we
had
to
do
was
like
promote
another
part
to
use
the
same
priority,
and
there
is
a
chance
that
that
part
can
actually
preempt
or
on
the
cubelet
side.
E
That
part
can
be
evicted
before
the
higher
priority
point.
So
once
we
made
the
mistake,
we
did
not
know
how
to
like
recover
from
that.
So
we
thought
it
off
like
couple
of
options.
Obviously,
deletion
and
recreation
can
be
done,
but
we
have
another
entity
which
is
responsible
for
creating
those
priority
classes,
and
that
can
actually
do
only
updates
at
this
point
of
time.
It
cannot
do
the
deletion.
E
So,
as
as
part
of
the
workarounds,
what
we
had
to
do
is
we
thought
about
it,
and
we
we
felt
that
there
are
two
approaches
that
we
can
think
of
the
other.
The
first
one
is
let
the
priority
of
the
priority
class.
At
least
the
value
be
updated,
the
name
and
the
description.
Sorry,
not
the
description,
but
the
name
and
rest
of
the
fields.
They
are
still
going
to
be
mutable,
but
can
we
update
the
value
that
is?
E
That
is
one
approach
that
we
thought
of
the
other
approach
was
to
make
this
priority
configurable.
Obviously
I
think
that
abdullah
and,
I
believe,
aldo
and
all
those
folks
they
had
some
reservation
in
making
that
configurable.
E
So
I'd
like
to
know
what
is
the
consensus
here?
Do
you
want
a
cap?
How
should
we
proceed
with
this?
I
believe
most
of
the
members
are
fine.
The
community
members
are
fine
with
having
an
update,
but
the
question
is
more
on
the
lines
of
should
we
have
a
kept
for
it,
and
I
would
also
like
to
get
a
feel
of.
Why
do
you
think
the
updates
like
why
can't
we
expose
this
highest
priority?
Be
a
configurable
option.
E
A
I
think
if
you
want
to
it,
be
controlled
by
feature
gate,
maybe
you
we
need
more
input
from
the
api
machine
because
we
don't
have
this
pattern
thing
before
we
usually
have
a
field
making
it
looking
market.
That's
optional
and
yourself
did
you
get
consuming
that?
But
if
it's
a
specific
api
operation,
I'm
not
sure
is
secondly
viable
using
futuregate
controlling
that
yeah.
This
is
my
concern.
A
We
need
more
input
from
evpn
machinery
and
also,
I
think
a
cab
is-
is
needed
because
you
know
you
users
should
be
aware
of
this,
and
if
users
are
using
some
hacking
ways
of
pre
processing,
some
something
they
may
be
surprising,
if
you,
for
example,
provide
this
updating
stuff,
although
maybe
in
the
very
first
phase,
we
we
use
the
physically
to
control
this.
D
Just
one
note
regarding
the
update:
it's
a
backward
incompatible
change,
and
so
we
need
as
much
awareness
as
we
can.
Definitely.
The
last
call
is
for
api
machinery
to
approve
it
so
like
a
small
clip
just
basically
to
have
a
place
where
people
can
chime
in
and
discuss
whether
this
is
a
reasonable
thing
to
do
or
not
or
you
could.
D
What
you
could
do
is
tag
like,
for
example,
jordan,
leggett
or
daniel
smith
on
on
that
on
this
issue
and
get
some
information
of
like
whether
we
should
proceed
or
it's
a
like
a
big
no
like
we
can
do
this.
E
Yeah,
that's
what
I'm
hoping
like.
I
already
have
a
hack
in
place
hack
in
the
sense
like
I
have
a
work
in
progress,
pr
which
I
have
opened
against
openshift.
I
can
also
do
the
same
in
kubernetes
and
and
tag
jordan
on
it
and
then
see
what
his
thoughts
are
right.
E
E
Okay,
I'll
type
jordan
on
that
and
with
respect
to
exposing
the
the
highest
configurable
priority
to
end
user.
Like
do
you
have
reservations
on
that
too.
E
F
E
Be
in
the
scheduler
config
just
like
how
we
are
passing
like
disable
preemption
as
as
a
scheduler
config,
it
will
be
part
of
that
is
what
I'm
thinking,
and
by
default
it
would.
It
would
be
set
to
1
billion
and
say:
if
someone
chooses
to
change,
they
will
have
an
option
to
change
it.
At
the
same
time,
we
would
ensure
that
they
are
not
touching
the
system,
critical
priority
classes.
D
But
but
like
it's
a
I
mean
you
can't
keep
changing
like
updating
it
right
like
you,
can't
keep
increasing
it,
because
at
some
point
you
you,
you
shouldn't
cross
the
system
critical
right
yeah,
so
you
can
go
back
to
the
same
problem
at
some
point
like
once
you
raise
it
enough,
you're
not
going
to
be
able
to
raise
more,
and
I
don't
know
if
that
actually
solves
the
problem.
E
No,
I
think
the
problem
here
is:
if
someone
chooses
to
do
it,
it
is
fine
like
let
them
give
an
option.
Instead
of
saying
that
we
have
set
a
1
billion
maximum
value
for
you
and
like
I'm
predicting
more
in
terms
of
where
that
responsibility
should
fall
like
should
we
take
the
responsibility
in
the
sense
of
component
owner
like?
Should
we
tell
that
hey,
we
are
setting
that
value
for
you.
We
know
that
it's
not
going
to
be
beyond
1
billion
or
what
we
can
do
is
we
can
go
the
opposite
direction.
E
We
can
tell
the
people
hey
by
default,
you
said,
is
1
million,
we
are
giving
you
the
option
say
if
you
choose
to
change
it
to
two
billion
again
or
close
to
system
critical
priority
class,
you
would
have
the
same
problem,
but
it
is
up
to
you
if
you
want
to
make
it.
D
Right
but
like
it,
it
goes
back
into
what
problem
this
solves
right,
not
like
giving
more
knobs
meaning
there
are
more
ways
for
users
to
like
harm
themselves
right
like
when
they
set
up
the
cluster.
If
there's
a
reasonable
value
that
we
can
provide,
that
value
will
just
work
yeah.
I
think
we
should
have
got
it
and
I
think
it's
the
case
here.
I
don't
see
it
like
configuring,
this
solving
the
problem
because,
like
I
can't
imagine
having
more
than
one
billion,
you
know
priority
classes
in
a
cluster.
E
No,
I
I
agree
in
the
sense
that
I
mean
not
the
priority
class
as
such,
but
the
priority
value
associated
with
priority
classes
crossing
one
billion.
I
agree
with
you,
but,
as
I
told
we
have
made
a
mistake
and
we
have
two
approaches-
the
one
that
is
of
less
friction
for
us
at
this
point
of
time
is
exposing
this
via
a
scheduler
conflict,
and
I
am
not
saying
that
it
is
going
to
solve
the
problem.
It
just
gives
us
a
escape
hatch
at
this
point
of
time.
D
Like
we
can't
discuss
in
the
issue,
but
I
I
don't
know
if,
like
no,
I
see
old
minus
one
this
one
but
like
there's
a
community,
so
I
I
don't
know
I
I
don't.
I
don't
see
it
as
a
like
something.
D
E
Yeah
the
validation
exists
as
of
now
in
the
api
side
like
we
ensure
that
it
does
not
cost
one
billion
say
if
it's
a
user
defined
priority
class.
That
validation
exists
within
the
api
validation,
but
when
we
are
relaxing.
B
So
keep
in
mind
that
the
change
in
those
changing
validation
is
not
backwards,
compatible
causes
problems
during
upgrades,
so
in
general
the
api
reviewers
will
be
against
this
change.
There
are
ways
you
can
do
it,
but
I
don't
think
the
value
that
changing
this
validation
would
provide
is
is
worth
the
the
df
or
worth
the
hassle
of
doing
this
change.
E
Yeah
like
in
both
the
cases
we
have
to
like
when
we
are
doing
an
update,
we
have
to
change
the
validation
code,
updating
the
sense
when
we
are
updating
a
priority
class.
We
have
to
change
the
validation
code
and
when
we
are
updating
the
scheduler
say
if
we
expose
this
as
a
scheduler
now,
even
then
we
have
to
change
the
validation
code.
The
point
I'm
trying
to
make
is
in
both
the
cases
we
may
have
to
touch
the
validation
code
in
the
api.
Sorry.
B
B
Changing
the
immutability
of
the
value
is,
is
fine
versus
changing
the
maximum
without
value
is
not.
B
But
yeah
we
might
have
a
better
answer
from
the
api
reviewers.
Oh.
B
But
again
yeah,
I
don't
think
both
things
are
associated.
They
don't
necessarily
go
together,
but,
as
I
was
saying,
I
also
don't
think
this.
Is
it's
reasonable
to
change
the
maximum
value
because
it
the
the
value
provided
by
that
is
not
significant.
E
Yeah,
so
what
I'm
saying
is
I
mean
just
to
reiterate:
I'm
fine,
even
if
you
knack
this
proposal,
but
at
high
level.
This
is
how
it
would
look
like
we
will
expose
the
scheduler
config
by
default.
The
value
would
still
be
one
billion
say
if
the
user
does
not
provide
any
conflict,
but
the
user
safe
provides,
it
will
be
changed
both
in
the
api
validation
side
and
in
the
scheduler
config
versus.
A
E
Which
scheduler
file
are
you
referring
to
like
in
packages.
G
E
Safely,
changing
the
scheduler
config.
Why
should
we
change
something
in
the
api
folder
in
the
code
path?
Is
that
your
question.
E
Yeah,
like
say
if
the
user
gives
1.5
billion
as
the
configuration
value
as
of
now,
we
have
a
validation
code
in
the
api
server
package.
Gps
validation,
dot
go
or
something
which
says
the
highest
user
defined
priority
value
should
be
less
than
one
billion,
so
we
need
to
relax
that
restriction
and
we
need
to
ask
it
to
pick
up
from
the
config
that
was
given
by
the
end
user,
when
the
scheduler
is
starting.
E
A
I
just
feel
it's
a
little
weird
to
have
this
control
in
the
scheduling
side,
because
priority
class
is,
you
know
its
ap
object
and
all
the
defaulting
validation
maximum
control
should
be
resizing
the
api
server
side.
That's
my.
A
E
Okay,
yeah:
the
priority
resolution
happens
differently.
In
the
sense
it
happens
at
an
admission,
plug-in
level
and
most
of
the
ignition
plug-ins
are
actually
owned
by
the
apps,
and
the
validation
to
them
actually
also
happens
within
the
packages
api,
a
top-level
directory,
but
perhaps
you're
right
in
the
sense
that
it
should
be
owned
by
scheduler
or
scheduling.
E
A
Okay
and
yeah
we
yeah,
we
are
around
all
the
time
we
can
give
the
detailed
proposal
and
give
a
summarizer
proposal
here
and
involve
the
jordan
and
other
api
folks.
E
Yeah
so
I'll
tag
jordan
on
this
thread
and
you
guys
can
give
a
knack
or
rack
on
the
other
issue
too,
like
exposing
scheduler
config,
and
perhaps
if
you
take
one
of
these
approaches,
we
should
be
good
from
openshift.
A
A
A
All
right,
thank
you
for
thanking
everyone
for
joining
today's
meeting
and
have
a
nice
day
we'll
see
you
in
the
week
after
the
other.