►
From YouTube: Kubernetes SIG Scheduling Meeting - 2019-09-19
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
Okay,
hi
everyone.
So,
as
you
all
know,
this
meeting
is
recorded,
I
will
be
uploaded
to
YouTube,
so
I
guess
I
can
start
to
the
items
we
have.
The
less
I
have
two
quick
items
on
my
side,
so
the
first
one
just
reminder
for
the
release
scheduled
for
1:30
17
is
going
to
be
shorter
than
the
previous
cycles
because
of
the
holidays
next
mid
next
month,
but
within
a
month
total
15
enhancement,
freeze
and
then
a
month
after
that,
November
14.
We
would
have
the
code
freeze.
A
So
if
you're
working
with
a
feature
that
would
require
enhancement,
freeze,
please
submit
it
as
soon
as
you
can
looking
at
the
list
of
tasks
that
we
have
planned
for
117
I,
don't
think
we
have
any
other
than
all
those
topology
spreading
and
I
might
have
something
for
the
framework
migration
for
the
frame
of
migration.
It's
not
going
to
be
strictly
like
an
alpha
beta
G.
A
feature
is
mostly
restructuring
and
refactoring.
In
general
D
factory.
C
A
It's
basically
providing
an
and
a
new
API
in
the
component
conflict.
Allow
specifying
a
default
value
for
probably
for
the
topology
key
is
for
default.
Spreading
right
now
is
fixed
for
zone,
but
if
you
want
to
make
it
configure
with
the
new
should
have
something
and
component
config
to
allow
users
to
specify
or
understand,
specify
the
default
spreading.
Topology.
A
A
That
will
allow
me
to
create
the
ARS
that
others
can
can
address
in
parallel,
and
what
I'm
trying
to
do
right
now
is
to
figure
out
the
how
the
configuration
would
work
out
and
basically
the
dependencies
that
we
have
you
have
to
independence
is
the
configuration.
Api
is
one
dependency,
so
we
have
the
policy
and
the
component
company
you're
just
trying
to
figure
out
a
way
to
methods
and
the
other
one
is
cubelets
and
both
other
other
components
that
actually
call
our
products
directly.
So
this
is
less
critical.
A
D
So
this
is
just
a
follow
up
from
last
week
eye
to
eye
test.
One
was
to
see
if
there
are
any
concerns.
You
know
that
Klaus
had
some
comments.
I
responded
and
I
was
wondering
if
there
are
any
open
concerns
at
this
point,
the
the
one
comment
that
was
regarding
how
to
handle
race
condition
during
resize,
so
we
looked
at
potentially
you
could
use
the
max
of
resources
and
resources
allocated
for
requests
and
the
status
resources
limits
for
the
limits.
D
However,
at
the
point
of
admission
we
can
we
don't
expect
this
to
be
like
a
long
outage.
There
can
be
temporary
situation
where
and
the
memory
is
being
reduced
or
a
CPU
is
being
reduced.
That
particular
node
on
which
the
pod
whose
CPU
or
memory
is
being
reduced,
is
offline.
Then,
overall,
there
might
be
a
slight
cluster
resource
over
scripture
over
subscription,
but
this
shouldn't
be
a
common
thing.
D
In
any
case,
we
I
talked
about
this
with
signal
on
Tuesday,
and
if
this
is,
if
this
does
become
a
problem,
it's
a
few
lines
of
code
change
to
fix
it.
So
we
figured
we'll
go
with
the
simple
brush
for
now.
We'll
use
the
resources
and,
as
it
is
currently
done,
we'll
just
use
it.
It's
just
gonna
become
mutable
for
the
limit.
D
Ranger
I,
don't
believe
there
is
any
issues
we
have
to
just
make
sure
that
the
min
and
Max
are
respected,
and
we
can
either
cap
it
at
the
min
max
levels
or
we
can
reject
the
request
if
it
is
not
compliant
with
the
min
max.
It's
fine,
so
I
just
wanted
to
ask
if
there
are
any
concerns.
Besides
that,
from
the
scheduling
side,.
A
So
I
guess
at
the
end
of
the
day,
I
mean
whatever
feature.
Would
water
oxidation
going
with?
We
need
some
like
to
experiment
with
it
and
have
some
data
points
on
how
come
or
not
differ
different.
You
know,
corner
cases
that
you
talked
about
occur
so
I'm
fine
with
with
what
the
Cape
is
proposing,
and
my
hope
is
that
during
alpha
we
will
get
some
feedback
on
how
often
these
universe
conditions
will
happen
and
how?
How
would
that
actually
impact?
A
You
know
the
cluster
in
general.
My
my
hope
is
that
we
will
have
a
solution
that
makes
the
cluster
in
a
in
a
good
state
eventually
like
fish,
basically
eventual
consistency,
so
it
doesn't
matter
if,
if
we
have
race
condition
at
some
point,
but
it's
not
as,
for
example,
the
cubelet
projects,
the
port,
for
example-
and
it
gets
affected
eventually
I
get
to
see
schedule
somewhere
else,
I,
guess:
I!
Guess
that's
fine!
Okay,.
D
So
the
only
other
thing
that
I
needed
here
in
the
cap
for
APA
review
I
need
to
mention
approvers
from
each
sig.
That
is
going
to
be
impacted
by
this
cap.
But
signal
is
the
biggest
impact.
Six
scheduling
is
a
fairly
small
impact
and
auto
scaling,
which
is
a
consumer.
They
all
have
almost
zero
impact,
except
one
of
the
proposed
policies
is
getting
pushed
to
them.
So
I,
just
want
to
know,
can
enlist
in
the
approvers
list
from
signal
is
a
two
or
class
you.
D
A
A
A
E
So
what
we
want
to
do
is
add
a
custom
resources,
scheduling
for
schedule
which
provides
fleet
policy
and
priority
based
atomic
scheduling
for
the
CRD
resources.
We
hope
that
users
can
describe
the
CRD
resource
as
a
whole
and
cognitive
schedules,
the
ERG
as
a
whole,
and
then
I
want
to
introduce
the
backgrounds
of
this.
E
Actually,
a
many
companies
use
kubernetes
as
the
underlying
platform
for
their
deep
learning
platforms,
deep
learning,
job
you
usually
use
GPU
to
track
and
as
the
scale
of
the
job
increases
distributed,
training
becomes
inevitable,
which
single
training
job
must
use
multiple
poles
at
poles
to
host.
However,
users
often
only
care
about
how
many
resources
our
number
to
be
exactly
the
number
of
the
GPUs
to
use
for
for
training
job
rather
than
the
distribution
of
the
backend.
E
So
at
the
same
time,
since
the
result
is
configuration
and
current
usage
of
the
cluster
is
unknown
to
users,
there
may
be
some
problems
where
result
allocation
is
determined
by
user
defined,
a
group,
so
the
first
one
is
the
hours
and
power
resource
allocation.
If
the
job
is
divided
into
a
multiple
small
grant
thoughts,
it
will
cause
unnecessary
interaction
of
head
between
the
pods
and
the
second
is
the
job
starvation.
E
If
the,
if
the
available
resources
of
the
class
cannot
satisfy
the
large
grant
job
request,
the
job
will
not
be
scheduled
for
a
long
time,
especially
when
small
grant
jobs
or
pods
are
scheduled,
and
the
last
problem
may
be
results
that
deadlock
when
some
when
some
part
of
a
job
are
scheduled,
the
remaining
part
cannot
be
scheduled
and
the
current
occupied
result
is
cannot
be
released.
So
the
result
is
that
the
Lord
may
happen.
D
E
In
summary,
we
hope
to
implement
the
following
functions.
The
first
is
the
users
only
needs
to
describe
the
overall
results
requirements
of
the
CR
D
and
the
trustor
should
automatically
completed
the
splitting
of
the
CR
date
spot
according
to
the
total
amount
of
resulted
and
the
current
cluster
results
usage
and
in
the
second,
is
all
parts
belonging
to
a
single
CRT
as
a
scheduler
automatically,
which
means
or
or
nothing.
That's
all
our
issue
about
okay,.
A
So
if
I
get
that
correctly,
so
you
want
to
specify
a
new
a
new
resource
start.
They
describe
it
as
custom
resource
at
C
or
D,
and
you
want
specify
a
high-level
resource
requirements
that
being
CPU
memory
or
number
of
GPUs
and
scheduling
time
we're
gonna.
Just
the
scheduler
should
try
to
schedule
that
whole
CRD
on
the
cluster
or
on
a
specific
node.
E
A
E
D
A
E
A
E
A
Let's,
let's
take
a
specific
example:
you
create,
let's
call
it
the
CRE
that
you
talked
about.
It's
called
a
pod
group.
Okay
in
the
pod
group,
the
spec.
You
just
specify
the
amount
of
resources
that
you
want
to
allocate
for
that
pod
group,
but
you're
not
specifying
the
number
of
parts
that
this
pod
groups
splits
to
right.
Yes,.
A
So
the
scheduler
was,
you
know
watching
for
that
part
group
picked
it
up
and
then
what
happens
next?
Do
you
want
the
scheduler
to
reserve
resources
and
then
call
the
split
API
to
split
the
resources
we
already
reserved
or
you
go
to
call
this
plate
and
then
you're,
gonna,
you're,
gonna
startin
to
pause
and
then
the
skater
was
just
go
ahead
and
schedule
the
parts
normally
as
I
was
doing
right
now.
E
E
Based
on
our
our
discussion
and
before
we
propose
the
following
principles:
first,
we
need
the
cube
scheduler
to
support
the
scheduling
force,
the
Rd,
but
it
does
not
sure
I
needed
to
understand
the
CRT.
Many,
because
the
give
a
diversity
of
CRT
and
then
the
function
that
means
understand
of
the
CRT
is
implemented
by
the
user
according
to
the
characteristics
of
TRD
and
the
scheduler
calls
the
function
through.
The
schedulers
extend
to
mechanism
which
CRD
needs
to
be
scheduler
depends
on
the
configuration
and
the
based
on
the
above.
Just
design
principles
are
pretty
liberally.
E
Concept
on
the
systems
is
ad
below.
First
is
the
cube.
Scheduler,
this
part
is
a
function
extension
to
the
default
schedule
and
melly
included,
including
first
determine
which
CR
these
need
to
be
scheduled
according
to
the
configuration,
and
the
second
is
inputting
implement
management
of
CRT
and
pause
in
the
unified
scheduling
queue,
and
the
third
is
cooperate
with
post
praetor
to
complete
the
atomic
scheduling
of
CR
D.
And
then
we
comes
to
the
pasta
Vader.
If
malfunction
is
responsible
to
the
schedule
of
requests,
the
splitters
created
the
zr
d
into
pod.
A
E
E
F
A
So
the
idea
is
sometimes
like
large
training
jobs.
You'll
have
to
split
it
into
into
multiple
tasks,
basically
to
to
to
do
the
training
in
on
different
data
points,
so
a
parsec
aliy
going
to
be
usually
a
single
process.
Basically,
even
if
it
is
not
a
threaded,
it's
going
to
be
confined
to
a
single
node
or
maybe,
if
it
is
designed
to
use
a
single
GPU,
then
you're
out
of
luck
using
multiple
GPUs
without
splitting
your
training
into
multiple
pods.
A
A
A
A
So
like
in
at
the
higher
level,
what
you're
asking
for
is
something
like
cost
scheduling,
but
you
want
it
to
be
more
flexible.
Basically,
you
don't
want
to
specify
the
the
group
of
parts
that
you
want
to
be
scheduled
ahead
of
time.
You
want
it
to
be
decided
at
at
runtime
and
that's
why
you're
proposing
this
split
API.
E
A
E
A
I
mean
you've
already,
okay,
so
so,
basically,
what
you're
going
to
that,
like
the
only
thing
that
you
you're
gonna,
create
an
object
and
that
object
is
basically
you're
using
just
for
the
schedule
to
call
you
back
right
so
and
the
object
contains
the
CRD
that
you
mentioned
contains
opaque
data
to
the
scheduler.
So
the
scheduler
has
like
really
nothing,
no
knowledge
of
that
and
what
in
front.
But
you
still
need
from
the
scheduler
some
information.
A
E
A
Exactly
you
can't
clearly,
like
enhancement
may
be
kept
so
that
we
can't
comment
on
it,
but
I,
but
I
understand.
What's
trying
to
do
what
you
want
to
be
done,
I
guess:
I
just
want
to
make
sure
that
we
we
don't
at
all
like
have
the
mean
student
to
to
to
do
what
you
want
to
do
and
and
that's
why
we
have
to
have,
for
example,
a.
B
C
B
A
I
predict
it's
feasible,
then
maybe
you
can
submit
a
kit
with
with
a
more
concrete.
You
know,
proposal
of
what
the
I
would
look
like,
etc,
like
we
will
take
a
look
at
the
at
the
current
issue
and
try
to
better
understand
how
to
solve
your
problem,
and
if
there
are
no
available
solutions
we
can.
We
can
discuss
what
you're
proposing
to
add.
A
If
you
look
at
the
schedule
there
are,
there
are
ways
we
can
schedule
pause,
so
there
are
priorities
and
where
the
priorities
is
to
spread
far
as
and
use
use,
nodes
that
have
lower
utilization
and
one
of
these
priorities
actually
does
the
opposite.
So
it
basically
tries
to
prioritize
nodes
with
higher
utilization
so
that
you
basically
try
to
co-locate
or
as
much
as
possible
so
that
it
don'ts
you
don't
spread.