►
From YouTube: Kubernetes SIG Scheduling Meetings 20170619
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
B
B
There
is
a
bunch
we
have
like
300,
I,
think
different
issues.
Now
that
people
have
gone
through
and
triage
to
concern
for
them
that
you
know,
there's
three
four
people
on
the
call
there's
no
way
we
can
tackle
all
300
of
those
issues,
it'd
be
nice.
If
we,
if
they're
a
community
oriented
such
that,
we
could
know
divvy
them
up
to
somebody
who
says
hey
I,
want
to
work
on
this
stuff.
I.
A
Start
to
address
this,
so
what
do
you
mean
by
divvy
up?
Do
you
mean
like
more
triaging,
or
you
mean
like
actually
have
people
implement
them
because
they're,
it
can't
possibly
be
the
case
that
there's
like
three
or
four
hundred
things
that
we
would
need
to
implement.
That
would
be
overwhelming.
So
what
what?
What
do
you
mean
in
purchase
specifically
well.
B
There
be
there,
probably
you
have
to
be
extra
labels,
but
they
don't.
Brian
doesn't
want
to
use
the
Help
Wanted
label,
but
some
way
for
us
to
say
and
like
if
somebody
shows
up
either
on
slack
or
whatnot
and
they
have
overtime
and
the
China
folks
could
to
be
involved
in
looking
at
that
list
of
items
and
be
able
to
take
apart
pieces
of
them
and
be
able
to
execute
on
them
right.
I.
A
A
C
A
C
A
B
A
D
Mean
I
just
wanted
to
point
out,
I
think.
Yet
when
you
talk
about
one
or
not
eight
items
right
so
I
know
like
I,
had
signed
up
for
a
scheduler
previously
I'm
sorry
I
did
not
spend
enough
time,
but
you're
definitely
like
for
1.8
I'm,
going
to
focus
mainly
on
this
schedule.
Just
wanted
to
point
it
out.
Okay,.
A
E
A
We
could
send
email
on
the
mailing
lists
to
see
if
people
are
so
we
just
we
need
to
divide
up
those
issues
if
in
a
some
kind
of
deterministic
way.
So
you
know
we
don't
have
multiple
people
wasting
their
time,
examining
the
same
issues,
but
yeah
divide
them
up
somehow
and
then
figure
out,
which
ones
or
help-wanted,
and
also
figure
out
how
we're
gonna
indicate
help
on
it
did
Brian
have
a
suggestion
on
how
to
indicate
help
want
it.
If
we're
not
using
the
Help
Wanted
label,
nope.
B
A
B
Priority
I
guess
is
like
the
simplest
thing,
but
but
that's
not
that
doesn't
it
does
it's
not
a
very
indicative
right,
yeah.
A
A
Well,
maybe
we
should
collect
there's
only
six
people
on
the
call
today,
so
we
should
probably
solicit
help
on
the
mailing
list.
It
would
get
a
broader
audience,
I
think
so
one
of
us
should
write
that
email
Tim,
like
I,
can
write
that
up.
Okay,
great
all
right,
so
should
we
talk
about
1.8
stuff,
so
a
vet
said
he
wasn't
working
on
a
scheduler
I
know:
Bobby
is
working
on
higher
the
priority
and
preemption
stuff,
and
actually
you
sent
out
a
design
doc
on
Friday
for
the
preemption
stuff,
which
did
anybody
comments
on
it.
C
A
A
F
A
Okay
yeah
at
some
point
we
should
convert
it
or
by
we
I
mean
you
should
convert
it
to
mark
down
and
make
it
an
official
proposal.
I
find
google
docs
easier
like
the
first
ten
people
who
comment
on
the
dock,
I
think
Google
Docs
is
easier
than
after
a
certain
point.
Then
it
becomes
actually
that's
true.
Coming
in
get
up
to
like
after
a
certain
number
of
people
are
commenting,
it
becomes
hard
to
track
what's
going
on,
but
yeah
anyway,
at
some
point
yeah,
you
should
convert
it
to
you
did
that
with
the
priority.
C
B
B
Then
I'm
gonna
be
working
towards
the
working
with
Andy
goldstein.
He
actually
recently
joined
fgo,
oh
really
yep,
and
he
did
the
component
carry
work
on
the
could
of
lip
or
not
the
cout,
proxy.
Sorry
and
he's
going
to
I
said
a
good
place
for
us
to
start
to
work
on.
This
would
also
be
the
scheduler,
because
we're
gonna
be
integrating
some
of
that
work
into
cluster
lifecycle
too.
So
so.
E
A
C
E
C
Ability
to
read
it
from
the
computer
still
they're,
providing
the
config
map.
However,
the
second
part,
which
is
applying
the
changes
at
the
time
that
the
comic
map
changes,
applying
the
changes
of
the
conflict
math
basis
to
disfigure,
not
there
so
I,
send
a
few
are
to
detect
the
changes
to
the
conflict
map
so
in
the
schedule
exists
and
relies
on
the
fact
that
cubelet
is
gonna,
restart
it.
So
as
soon
as
the
schedule
restarts
it
picks
up.
C
B
C
C
A
For
805
Tim
yeah
for
for
805,
okay,
so
yeah,
so
there
was
objections
to
restarting
I
wonder
if
we
can
find
some,
but
someone
said
well,
it
wasn't
to
the
restarting
it
was
to
their.
It
was
to
the
expo
I
guess
there
were
two
objections:
one
was
people,
some
people
weren't
sure.
If
restarting
was
the
right
thing
to
do,
the
other
was
some
people.
Weren't
sure
of
exiting
would
on
all
platforms,
actually
lead
to
the
scheduler
restarting.
And
if
that
didn't
happen,
obviously
that
would
be
bad.
I
I
mean
I
was
like
you
who
I.
A
C
First
of
all,
I
was
a
bit
surprised
that
I
was
the
creepiest
system.
That
button
react
to
the
fact
that
one
of
it
critical
components
is
exiting.
If
the
researcher
system
I
mean
the
system
would
be
very
unreliable
because,
anyway,
it
is
the
schedule
might
crash
or
any
of
the
other
components
of
the
system
may
crash,
and
it's
not
always
a
deliberate
exit.
So
that
said,
I
also
learned
recently
that
cubelet
does
the
same
thing.
So
humid
has
added
the
dynamic
configuration
and
it's
including
waffle,
but
Cuba
does
the
same
thing.
E
C
On
system,
whatever
platform
it's
on
and
basically
whatever
operating
system,
it's
aren't.
You
restarted.
I
think
that
the
situation
scheduler
is
better
because
we're
not
relying
on
external
components.
We
are
just
relying
on
our
own
opponent,
which
is
Cupid,
and
so
the
concerns
about
compatibility
between
platforms
and
all
is
not
really
there
so
I
mean
I.
Don't
want
to
say
that
since
Cupid
we
have
to
do
it
too
slow,
but
it's
something
that
is
a
common
practice
looks
like
so.
B
It's
a
common
practice
in
many
systems
like
because
when
you,
when
you
mean
you
mutate
state,
you're
gonna,
have
abnormal
behavior
for
a
period
of
time,
unless
you
have
like
strict
blocking
and
stuff
in
your
data
structures,
and
we
clearly
don't
have
that
I.
Don't
really
want
to
build
that,
because
it
seems
like
a
bug.
B
Factory
plenty
of
other
systems
have
precedent
for
changing
the
config
and
doing
a
hard,
reboot
or
recycled,
because
there's
high
availability
and
those
components
or
are
you
ensure
that
system
D
restarts
it
right
away
or
some
other
some
other
process
watcher
is,
is
forcing
the
restart
exam,
the
only
person
that
seems
to
be
knacking.
B
C
B
C
B
B
Well,
it
seems
like
there's
only
one
detractor
I,
don't
see
that
you
know
and
Jordan
has
a
lot
of
weight,
but
I
think
in
this
particular
case
I
think
there's
plenty
of
precedent
for
that.
Obviously,
the
cool
it
being
one
right
and
there's
plenty
of
experience
in
other
systems
where
they
do
exactly
the
same
thing
too,
because
the
state,
the
behavior
of
changing
the
state
and
its
underlying
data
structures,
unless
it
has,
unless
it's
built
from
the
ground
up
to
be
completely
isolated.
You're
gonna,
you're
gonna
walk
into
this
weird
indeterminate
behavior,
exactly.
C
B
B
There
are
scale
back
knobs
that
actually
exist,
and
anybody
that
has
a
cache
to
allow
you
to
load
slower
right
because
right
now
it
doesn't
aggressive
relisting
and
there
are
tools
at
least
we'd
built
it
into
the
controller
manager,
and
we
could
populate
it
as
a
scheduler.
If
we
needed
to
to
allow
you
to
load
that
cache
less
aggressively.
A
B
It
was
the
controller
manager
with
the
one
that
we
did
the
changes
to
originally
because
it
had
before
we
did
the
cache
reductions
where
we
had
share.
Caching,
it
was
populating
many
realists,
so
every
single
controller
would
relist
all
of
the
different
resource
objects
in
the
system,
and
one
of
the
modifications
are
made
in
the
one
four
one.
Three
one
four
touch
cycle
was
just
to
do
a
scaled
loading.
So
that
way,
if
you
had
a
failover,
a
controller
manager
for
whatever
reason
it
didn't
cause,
you
know
resonant
noise
in
the
system.
B
C
But
another
thing
is
that
Jordans
concert
wouldn't
completely
go
away,
even
if
we
did
restart
or
you
apply
the
configuration
without
restarting
the
scheduler,
because
a
lot
of
these
catchers
have
to
be
invalidated.
Anyways,
open
configuration
changes
so
I
need
to
report.
Most
of
the
caches
need
to
be
respected,
so
that
concerns
the
still
is
gonna
exist.
Even
if
we
apply
the
operation.
That's
that's
one
thing
and
then
thinking
thing
is
that
I
believe
that
change
of
the
configuration
or
the
policy
conflict
is
a
somewhat
rare
event.
C
A
D
A
I
yeah,
unless
you
know
I,
don't
know
if
anybody
else
on
the
call
has
comment
on
it
or
not,
but
anybody
else
have
anything
they
wanted
to
say
about
it:
I
guess
not:
okay,
yeah,
but
people
can
comment
on
the
issue
if
they
one
two
four
four
eight.
Oh
five
was
the
number
okay
I.
Guess
we
have
two
things
left
one
was
discussing
having
a
China
friendly
meeting
time
than
the
other
was
30.
A
Second
answer
to
the
question
of
best:
on
slack:
we
could
talk
about
that
trying
to
friendly
movement
meeting
time,
so
there
used
to
be
a
long
long
time
ago,
a
every
two
weeks
meeting.
It
did
not
last
very
long.
I
will
say
that
but
like
at
midnight
Pacific
time
on
the
week's
when
we
didn't
have
the
the
regular
2
p.m.
now,
it's
1
p.m.
A
meeting
and
I
ran
that
meeting
and
there
when
there
were
people
at
one
time
there
were
three
or
four
people
from
Huawei
who
were
working
on
kerbin
Nettie's
and
some
of
them
would
attend,
and
there
was
maybe
one
other
person
who
I
can't
remember
gu,
who
would
also
attend
sometimes,
but
then
the
like.
Basically,
people
stopped
stopped
coming.
A
It
was
useful
for
a
while,
but
like
there
was,
the
tenants
went
to
approximately
zero
and
so
I
actually
never
made
an
official
announcement
about
canceling
it,
but
because,
if
at
first
I
was
just
cancelling
it
from
week
to
week,
because
there
wasn't
anybody
who
was
saying
they
were
gonna
have
a
topic
to
discuss
and
then
just
never
got
around
to
officially
canceling
it.
So
there's
I
asked
on
the
mailing
list.
A
If
there
were
people
from
China
who
were
interested
in
having
a
kind
of
friendly
time,
because
Klaus
asked
for
it
and
I
believe,
four
people
will
responded.
Well,
what
I
asked
was
more
specific.
It
was
like
people
who
would
actually
commit
to
showing
up,
because,
like
lots
of
people
are
interested
in
lots
of
things,
and
that's
not
really
what
we
know
we
want
to
know
like.
A
Would
you
actually
show
up
and
so
for
people
from
China
said
that
they
would
show
up
I
didn't
ask
whether
people
who
weren't
from
China
would
show
up,
which
is
relevance,
I,
guess
and
then
there's
also
the
question
of
finding
a
time
to
time
to
meet.
It
seemed
like
an
evening.
Time
was
the
best
from
what
Klaus
was
saying,
because
kind
China
is
nine
hours,
I
mean
it's
the
the
easiest
way
to
think
of
it.
It's
like
nine
hours
from
Pacific
time
in
twelve
twelve
hours
from
from
East
Coast
time.
A
Right
I
mean
the
issue
I
think
was
if
they
had
stuff
they
wanted
to
talk
about.
Definitely
recording.
This
meeting
is
helpful
for
people
who
are
in
time
zones
for
which
this
is
inconvenient,
but
there
was
still
interest
in
they
expressed
interest.
At
least
Klaus
did,
and
these
other
people
said
they
would.
They
would
come
in
having
an
actual
wise
meeting.
A
A
B
B
A
B
A
D
D
A
D
D
B
A
A
A
F
A
F
A
A
Yeah
Bobby
says
he
doesn't
I.
Definitely
don't
but
I
mean
early
morning
like
like
9:00
a.m.
Pacific.
Time
is
midnight
in
in
China,
so
like
even
to
try
to
do
a
reasonable
time
in
China,
like
10,
P
yeah,
that's
like
7
a.m.
Pacific,
I
think
yeah
yeah,
it's
hard.
It's
hard
to
do,
I
mean
Europe
and
China.
You
can
do
those
together,
it's
just
hard
to
do
that
with
with
the
US,
and
we
did
occasionally
get
someone
from
Europe
very
rarely
came
to
that
other
feeding
time
because
it
was
9:00
a.m.
A
Any
other
comments
about
it,
alright,
so
why
don't
we
send
it
out?
I
can
send
out
something
to
the
mailing
list
and
mention
like
the
favorite
time,
was
7:00
p.m.
Pacific
time.
There
was
some
feeling
that
8:00
p.m.
might
also
be
possible
and
see
if
other
people
have
feedbacks
that
sound,
reasonable
yeah.
A
Okay
and
then
the
last,
unless
I
mean
people,
people
can
still
add
items
if
they
want
that.
So
I've
asked
on
slack
about
why
the
node
selector
uses
a
label
selector
syntax
that
includes
greater
than
in
less
than
whereas
the
pods,
the
pod
selector
and
all
of
the
other
labels
times
a
all
the
other
situations
where
we
use
label
selectors
yeah
does
not
does
not
include
better
than
or
less
than.
Sorry.
A
Let
me
let
me
let
me
restate
that
a
little
more
clearly
so
so
node
affinity
has
a
selector
in
it,
and
the
label
slim
test
label,
selectors
and
text
there
allows
greater
than
or
less
than
this
is
a
different
label
selector
syntax
than
is
used
for
the
label,
selector
used
in
pod
affinity
and
anti
affinity
and
all
the
other
scenarios
where
we
have
label
selectors.
And
so
the
question
is:
why
is
the
node
selector
one
different?
So
the
the
answer
is
so
Bryan
and
I
discussed
this
back
when
node
select,
node
affinity
was
being
designed.
A
So
my
original
proposal
was
that
we
should
add
greater
than
less
than
to
the
generic
label
selector
syntax
and
then
use
it
everywhere.
So
Bryan
Bryan's
argument
was
that
for
situations
that
are
selecting
pods,
it's
more
important
to
have
a
simpler
syntax
ie,
not
change
the
one
that
we
already
had.
So
he
had
two
arguments
because
and
I
had
talked
him
again
about
it
today,
just
to
review
with
this,
because
I
had
forgotten
some
of
some
of
what
the
argument
was.
E
A
A
I
suspect
the
node
selector
ones
are
all
the
node
affinity
is
also
written
by
humans,
but
anyway,
one
argument
was
that
it's
easier
to
understand
the
more
limited
syntax
like
like
without
the
without
the
greater
than
or
less
than
so
for
people
who
aren't,
who
don't
remember
like
the
more
limited
syntax,
the
the
regular
label.
Selector
syntax,
is
in
not
in
presence
in
absence,
it's
just
those
four
things
and
then
for
node
affinity.
A
We
add
to
that
greater
than
or
less
than
so,
there
was
some
argument
about
a
understandability
of
not
necessarily
like
just
reading
it
and
understanding
it,
but
of
being
able
to
reason
about
what
objects
it
would
apply
to
given
given,
like
you
know,
a
human's
understanding
of
what
labels
are
on.
What
objects
like
like
being
able
to
easily
reason
about
what
the
impact
of
the
of
the
selector
would
be.
It's
easier
without
greater
than
or
less
than
and
yeah.
A
So
now
that
that
was
one
argument
and
the
other
one
was
that
it's
kind
of
related
to
that,
but
that
it
would
be
it
was
something
like
it
would
be
easier
for
me.
More
efficient
for
automated
systems
that
are
trying
to
enforce
policy
rules
about
which
objects
are
being
selected
would
be
easier,
for
it
would
be
more
efficient
to
implement
those
rules
if
you
didn't
have
less
integrator
than
like.
A
So,
for
example,
if
you
want
to
have
a
rule
about
no
overlap,
no
overlapping,
selectors
or
like
like
how
many
pods
should
be
covered
by
a
monitoring
rule
or
or
something
like
that
so
Susannah.
These
are
kind
of
vague
reasons,
I
realize,
but
that
was
that
was
the
that
was
that
was
idea.
It
was.
It
was
human
understandability
and
also
kind
of
like
the
efficiency
of
implementing
policies
that
about
which
objects
would
be
selected,
and
so
the
original
brian's
original
position
was
that
we
shouldn't
extend
the
syntax
at
all.
A
I
made
an
argument
that
there
are
a
lot
of
situations
work
greater
than
a
less
than
is
useful
for
node
selection.
I
mean
based
on
based
on
some
of
our
experience
at
Google
and
and
so
on,
like
it
seemed
at
the
time
like
we
should
have
that
in
the
syntax,
although
it
was
not
I
mean
this
was
a
fairly
early
decision.
A
A
What
it,
what
it
would
mean
to
for
once,
extension
of
the
other
and
also
like
I,
don't
know
that
it
would
be
a
big
benefit
to
to
have
it
be.
You
know,
written
that
way.
I
will
say
that
the
the
node
select
or
the
logic
for
matching
node
selectors,
it's
the
same
logic
as
for
matching
label,
select
like
all
the
other
label.
Selectors
in
fact,
like
the
way
that
the
label
selector
matching
syntax
works.
Is
that
it
just
if
you're,
not
a
node
selector,
then
it
gives
you
an
error.
A
If
you
try
to
use
less
integrator,
then,
and
if
you
are
a
node
selector
and
lets
you
use
all
of
them,
so
the
underlying
matching
code
is
identical
for
node
selectors
and
all
of
the
other
label
label
selectors,
but
the
type
itself
an
API
file,
in
particular
the
type
for
the
comparison
operator,
whether
it's
the
four
types
or
the
six
types,
is
a
different
type,
but
I'm
not
sure
that
that
matters
FSG.
You
want
to
say
what
you
know
like
what
you.
D
Know
yeah
I
mean
thanks
for
explicit
yeah.
Actually,
my
my
the
second
question.
I
was
not
specifically
asking
like
extending
or
having
notes
letter
nor
cable
check
that
extension
of
people
sector
I.
Think
I
was
just
saying
like
why
we
did
not
extend
existing
label
sector
and
edit
more
operators
like
greater
than
and
less
than
I.
A
D
I
understand
that
so
Mike.
The
next
question
is
a
so
it
seems,
as
you
explained
so.
Port
infinity
and
NT
affinity
are
working
as
expected,
but,
as
I
also
pointed
out
like
in
the
document
like
to
be
here
mentioned
an
old
affinity
and
NT
affinity,
it
should
work
with
greater
than
unless
then
so.
Do
you
think
just
updating,
then,
would
be
good
yeah.
A
D
Okay,
so
maybe
like
I,
just
create
an
issue
like
we
could
just
update
that
and
actually
the
nothing
in
the
how
it
is
started.
Like
our
QA,
like
we
founded
the
I,
mean
RQ
found
an
issue
because
they
were
testing.
That's
all
I
get
started
so
I
mean
now
like
I
have
a
license
from
you.
So
I
can
at
least
say
like
it's
working
as
expected.
Yeah.
A
B
C
How
the
desk
yeah,
so
we
determined
that
it's
not
a
blocking,
actually
I
tried
to
reproduce
the
test
in
my
own
local
setup,
I
left
it
running
for
a
while
I
couldn't
reproduce.
Oh,
my
overall
assessment
was
that
this
is
probably
not
a
blocker
I,
don't
see
this
being
a
major
issue,
but
we
need
to
fix
the
flakiness
I.
Don't
think
we
need
to
fix
it
in
1.7.
A
E
A
A
Of
having
demons
that
control
or
death
alone,
which
is
something
that
we
would
like
to
do,
but
is
not
trivial,
given
all
of
the
weird
special
casing
that
the
demon
sets
controller
does
today,
I
mean
it
it
requires
thinking
about
which
of
the
behavior.
We
want
to
keep,
perhaps
all
of
it.
We
need
to
call.
A
A
Okay
yeah,
so
let's
we
should
take
a
look.
Take
a
look
at
that
yeah!
It's
a
worthy
thing
to
do
for
sure,
but
not
not
simple,
I
mean
I,
think
yeah,
it's
kind
of
like
once
we
decide
what
to
do.
It's
may
be
relatively
simple:
to
implement
but
figuring
out
what
the
right
thing
to
do
is
people.
B
Are
kind
of
what's
kind
of
little
weird,
we
need
to
be
careful
about
once
we
do
eventually
subsume
demons
that
behavior
or
scheduling
is
that
people
are
kind
of
relying
on
the
big
current
behavior
of
demon
sets
to
be
able
to
schedule
two
things,
even
though
they're
not
yeah
quote-unquote
schedule
right.
That's.
E
A
And
it's
related
I'd
completely
agree,
and
it's
related
to
this
bigger
issue
of
trying
to
replace
some
of
the
logic
that
uses
node
conditions
with
logic
that
uses
taints
instead
and
and
having
the
node
controller
or
SEP
taints,
corresponding
to
the
to
the
node
conditions
and
stuff,
like
that
and
Mark
was
going
to
work
on
that
at
some
point
relatively
soon,
but
yeah.
This
is
the
all
of
these
pieces
are
related
and,
like
you
said,
they're
related
to
cluster
lifecycle.
A
This
is
one
of
the
reasons
why
it's
tough
to
tell
this
is
why
it's
complicated
because,
like
you
said
that
people
are
relying
on
the
currents,
strange
behavior
I
mean
I
think
we
can
probably
with
proper
use
of
taints
and
toleration.
X'
like
we
produce
the
behavior
that
we
want
using
the
regular
scheduler,
but
it
requires
some
like
someone
working
through
the
details.
Yeah.
B
B
C
And
another
thing:
I
noticed
no
given
given
this
problem
and
somewhat
similar
problem
that
we've
seen,
for
example,
for
spreading
various
types
of
like
stateful
sets
and
replicas.
It's
an
odd
you
know.
I
had
I
had
to
add
stateful
set
to
spreading
at
some
point
and
I
had
to
go
and
change
a
lot
of
now
functions,
sort
of
like
trivially
to
add
stateful
sets
to
the
logic.
So
I
was
wondering
if
he
could
add
some
something
like
a
controller
for
various
types
of
control
is
probably
not
a
good
at
work.
C
C
A
For
themselves
well,
I
mean
I,
think
we
to
be
careful
not
to
make
it
too
complicated.
But
it's
like
yes,
if
there's
different
rules
about
how
the
different
controllers
are
handled
by
the
scheduler
then
have
having
a
way
to
like
configure
that
like
have
it
at
a
single
place
to
write
those
rules
of
a
seems
like
it's,
you
sort
like
like
if
we
should
always
spread
like
the
example
you
gave
like,
we
should
always
spread
pods
from
the
same
controller,
having
a
easy
like
having
an
array
or
somewhere
that
we
list
the
controller
types.
A
C
E
C
A
That
might
be
beyond
just
the
scheduler,
like
might
be
useful
in
general,
like
like
some
some
registry
for
the
different
controllers
and
what
the
what
the
proper
with
the
like
special
case.
Properties
of
them
are.
So
you
just
have
one
place
that
you
look
at
and
change
if
you're,
adding
a
new
controller
or
something
like
that,
I
mean
another
thing
we
can
try
to
do
is
make
the
scheduler
less
reliant
on
the
controller
type
like
I
mean
I
was
just
thinking
like,
for
example,
the
spreading.
A
We
could
get
rid
of
the
spreading
priority
function
and
just
have
the
controllers,
add,
preferred
anti
affinity
to
all
of
the
pods
that
they
create,
or
something
like
that,
and
so
like.
Obviously,
the
scheduler
would
be
easier
to
understand
if
we
didn't
have
special
cases
for
the
different
controllers.
Probably
so
I
don't
know.