►
From YouTube: Kubernetes SIG Scheduling Weekly Meeting for 20230406
Description
Kubernetes SIG Scheduling Weekly Meeting 2023-04-06T17:00:00Z
A
Thank
you
all
right.
Welcome
everybody
to
another
sea
scaling
meeting
today
is
April
6th
2023.
My
name
is
Aldo
I'm
gonna
be
your
host
today.
As
you
know,
this
meeting
is
recorded.
So
please
adhere
to
the
cncf
code
of
conduct
all
right.
So
we
have
few
topics
in
the
agenda.
The
first
one
Abdullah
I,
believe.
Let
me
put
this
one,
so
we
I'm
doing
this
working
on
the
annual
report
for
the
for
the
project.
Scheduling.
Do
you
want
to
say
Do
you
wanna
talk
about
this
Abdullah.
B
B
B
C
Okay
and
the
next
one
is
to
redefine
the
ownership
of
the
non-life
cycle
controller.
So
basically
my
memory-
it
was
developed
by
class,
who
was
the
sixth
scheduling
co-chair
by
that
time
and
then,
but
in
terms
of
functionality,
actually
the
components
across
ccaps,
I
would
say
cross
signal
and
six
scheduling,
so
I
think
it
was
initially
belong
to
six
scheduling,
but
later
on
was
transfer
the
ownership
to
six
no
I
would
say,
and
then
now
it
seems,
there's
any
some
discussion
to
talking
about.
C
A
C
B
Just
please
give
us
advocate
here,
like
most
of
the
controller.
What
the
controller
is
doing
is
actually
trying
to
understand
the
node
status
and
then
just
applying
a
tent
or
a
or
like
yeah
flying
things,
basically,
so
why
it
was
developed
by
someone
from
sex
catering
in
the
past
I
don't
know
if
that
behavior
is
something
we
are
the
experts
to
maintain,
because
I
mean
applying
the
tense
is
not
the
biggest
thing
here
in
the
in
the
controller.
It's
basically
understanding
what
the
node
status
is.
B
A
So
basically,
one
of
actually
the
cap
proposal
is
to
split
this
controller
into
two,
because
it's
doing
two
actions
or
two
is
doing
basically
to
related
but
separate
things.
One
is
yes
adding
the
things
to
the
nodes
based
on
the
status
and
second,
it
is
a
victim
thoughts
that
don't
don't
have
the
Toleration.
A
So
maybe
once
the
controller
is
split,
it
actually
makes
sense
to
actually
to
give
one
of
them
to
node
and
the
other
one
given
in
in
scheduling,
because
the
things
and
tolerations
is
under
the
domain
of
of
scheduling
right.
So
maybe
that
that
could
be
the
outcome
once
the
the
two
con.
The
two
functionalities
are
split
into
two
controllers.
B
C
C
A
That
is,
that
is
true.
Actually,
yes,
so
the
the
two
functionalities
are
currently
split
into
folders,
so
I
we
could
already
do
the
separation
using
the
the
same
pattern,
so
I'll
I'll,
I'll
craft,
a
PR
and
send
it
for
review
for
to
signal
and
and
the
rest
and
see,
scheduling,
I
and
see
gaps
as
well,
of
course,
because
they
are
there
overall
Gatekeepers
of
Cube
controller
manager.
A
A
This
is
a
an
old
feature
that
never
graduated
from
alpha
into
other
stages.
Basically,
what
we
have
here
is
an
admission
plugin
that
can
understand
the
this
annotation
in
a
namespace
object
and
what
the
plugin
does.
What
the
admission
plugin
does
is
that,
based
on
The
annotation,
it
introduces
node
selector
into
the
nodes
that
much
that
are
created
in
this
namespace.
So
basically
it's
defaulting
no
selectors
for
annoying
space
and
again
this
never
graduated
from
Alpha.
A
A
A
A
So
my
my
thinking
in
terms
of
deprecation
would
be
that
we
we
take
some
time.
We
we
announce
it
and
then
we
remove
it
in,
let's
say,
as
any
other
beta
feature,
let's
say
three
releases,
but
the
question
Still
Remains
whether
we
should
keep
the
behavior,
regardless
of
how
long
we
take
to
from
how
long
the
deprecation
process
takes.
A
And
we
we
have
I,
guess
the
closest
precedence
I
can
think
of
that.
That's
a
similar
thing
would
be
limit
ranges
which
actually
I
don't
remember
if
they
are
namespaced
or
not,
but
that's
kind
of
like
the
the
defaulting,
the
only
default
pod
defaulting
mechanism
I
can
think
of
that
kind
of
could
be
used
as
a
precedence
but
regardless,
regardless
of
back
back
again
to
deprecation
the
The
annotation
has
Alpha
in
the
name.