►
From YouTube: Kubernetes SIG Scheduling meeting - 2018-07-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
A
B
A
Individual
access
to
the
document,
but
even
that
is
not
required
because
that
the
same
document
is
basically
converted
to
a
PR
and
is
available
in
our
community
Docs.
So
if
you
go
to
kubernetes
community,
there
is
a
PR
that
has
this
scheduling
framework
for
pozzolanic.
That
said
thinking
more
about
the
scheduling
framework,
and
you
know
all
the
future
steps
to
make
it
like
the
default
scheduler
like
letting
it
soak
for
a
long
time,
probably
and
then
backward
compatibility
issues
has
theme
and,
of
course,
the
development
of
it
itself.
A
I
was
thinking
that,
instead
of
going
through
all
that
steps,
which
is
probably
going
to
take
a
very
long
time,
we
can,
alternatively,
bring
some
of
the
good
ideas
of
the
scheduling
framework
into
our
time
to
schedule
and
an
example
is
creating
more
more
like
logging
points
in
our
conscious
scheduler.
In
a
way,
our
schedule
today
is
more
or
less
like
your
framework,
although
it's
not
built
like
a
framework
in
a
sense,
but
our
our
predicate
and
priority
functions.
B
A
A
B
A
A
Persistent
volume
binding
is
now
inside
the
scheduler
code.
That's
something
that
we
from
the
very
beginning.
We
knew
that
it's
not
a
great
pattern
and
we
wanted
to
avoid
it,
but
we
didn't
have
any
other
option.
In
fact,
one
of
the
most
important
reasons
that
I
thought
about
creating
a
framework
and
not
going
with
the
current
design
was
exactly
because
of
this
particular
logic
that
that
was
brought
into
this
scheduler.
A
So
if
we
create
another
plug-in
point
by
default,
we
are
probably
but
well
if
I
said
that
one
of
the
first
candidates
to
be
moved
to
that
like
a
like
a
plugin
for
this
extension
point,
is
going
to
be
the
persistent
volume
button.
So,
given
that
we
have
already
tests
for
that,
we
can
of
course
ensure
that
existing
tests
will
not
break
by
making
this
change.
We
can
test
it
that
way
at
least,
and
then
we
have
other
logic
like,
for
example,
GPGPU
binding.
A
B
So
the
third
question
that
I
have
is
thank
you
that
answers
my
question.
So
the
other
question
that
I
have
is
for
the
new
plugins
for
the
new
framework.
We
were
thinking
of
having
two
different
types
of
extensions.
One
is
having
it
compile
and
then
the
other
is
going
to
be
an
external
mechanism
similar
to
http
or
JSON,
which
we
not
here,
which
we
haven't
decided
yet,
but
most
of
the
changes
we
are
going
to
make,
they
would
be
in
place
plug-in
additions
like
at
the
compile
time.
A
So,
of
course,
this
is
not
in
process.
Plugins
are
not
gonna
work
for
everybody,
not
everybody
wants
to
compile
or
recompile
their
rather
scheduler.
However,
I
think
most
people
also
do
not
need
instruments.
Probably
you
know.
The
users
which
were
or
not,
tech,
savvy
or,
and
that
takes
up
is
another
right-
will
probably
take
people
who
are
not
like
scheduled
experts.
We
do
not
want
to
really
change
anything
in
this
scheduler
I
would
expect
some
of
these
folks
who
really
want
to
create
custom.
A
Scheduler
are
okay
with
recompiling
the
code,
but
one
thing
that
we
need
to
do
is
that
you
know
today:
I
are
a
scheduler.
I
cannot
call
it
a
monolithic,
because
we
have
these
like
concepts
of
having
priority
and
predicate
functions
which
are
not
inside
the
guts
of
the
scheduler.
But
there
are,
there
are
still
kind
of
integrated
inside
the
scheduler,
and
there
are
feature
is
I
can
name
for
DM
preemption,
particularly
preemption,
that
is
like
inside
the
guts
of
the
scheduler.
A
So
you
cannot
easily
change
it
or
remove
it
or
if
there
are
changes
to
the
scheduler,
and
you
make
some
other
customization,
then
keeping
up
with
the
rhythm.
Basically,
master
branch
of
kubernetes
could
be
challenging
for
users,
but
if
we
create
a
complete
separation
so
that
these
in
process
plugins
only
interact
with
the
scheduler
yll
defined
interface,
which
we
are
going
to
provide
backward
compatibility,
then
things
become
easier
so
like
creating
an
API
inside.
A
The
scheduler
that
are
going
backward
compatible
will
make
will
make
that
true,
maintenance
of
custom
schedulers
easier
for
our
users
and
of
course
we
are
going
to
keep
supporting
the
external
external
plugins
as
well,
but
those
are
usually
not
as
fast,
so
they
may
not
be
great
for
all
these
cases.
So.
B
A
A
In
my
scheduler
framework,
design,
I
didn't
have
any
particular
design
for
external
external
plugins,
because
there
are
things
to
figured
out.
One
is
basically
whether
performance
of
these
external
plugins
is
important
or
not.
Of
course,
performance
can
be
always
important,
but
if
we
have
all
the
other
building
in
process
plugins
where
the
performance
of
those
should
be
as
critical
as
as
not
having
any
other
option.
A
Basically,
if
you
didn't
have
any
other
option
for
extending
as
well,
then
we
definitely
had
to
think
about
performance
of
extent
external
once
more
carefully,
but
now
maybe
the
performance
of
those
are
not
as
important
in
case
of,
for
example,
GPGPU
networks.
If
you
finding
performances,
is
not
that
important
you've
seen
that
binding
network
sources
sometimes
can
take
in
the
order
of
minutes
so
being
a
fraction
of
a
second,
faster
or
slower,
doesn't
matter
at
all
to
these
plugins.
So
we
some
of
the
use
cases
may
exist
for
other
people
as
well,
and.
B
A
Guys
may
not
care
as
much
about
performance
other
people
who
care
about
performance
pain
may
want
to
go
and
build
deep
in
process
plugins
anyway.
Going
back
to
your
point,
I,
don't
feel
that
necessarily
this
is
necessary
need
for
changing
the
current
extension
mechanism.
Unless
people
tell
me
that
they
have
use
cases
for
it,
but
I
haven't
heard
that
many
and,
in
fact
I
don't
think
there
are
that
many
users
who
are
using
these
extensions
so.
B
I
mean
one
thing
that
I
could
talk
is
from
the
perspective
of
device
plugins,
where
they
want
to
have
accounting
and
core
scheduler
for
the
different
types
of
device
plugins.
So
that
is
something
that
I
would
personally
not
prefer.
The
scheduler
core
is
going
to
increase
and,
and
it
becomes
difficult.
So
if
you
have
the
extender
mechanism
for
those
kind
of
resources,
it
would
be
helpful,
but
I
don't
know
if
the
current
extinction
points
for
extender
are
good
enough.
Further
right.
A
B
In
process
would
work
fine,
but
we
should
be
careful
of
like
we
should
not
allow
too
many
things
to
be
in
the
core
scheduler
right
I
mean
if
the
device
flag
and
listing
itself
is
taking
some
time
safe.
There
are
like
five
five
device,
plugins
and
then
again,
accounting
them
like
how
much
of
them
have
been
used.
How
much
of
them
are
not
being
used
if
it
takes
like
quite
a
bit
of
time,
they
should
be
in
the
external
plugin,
not
an
imprecise
plugin,
because
not
many
people
may
care
about
those
things.
A
I,
don't
expect
the
in-process
plugins
be
any
difference,
so
Infosys
plugins
are
not
expected
to
just
do
anything
they
like
and
they
are
you're
not
expected
to
be
integrated
inside
the
core
of
scheduler.
So,
as
I
said,
the
process
plugins
must
communicate
with
the
core.
Only
a
well-defined
interface
and
that
well-defined
interface
is
gonna,
be
maintained
back
will
be
backward
compatible,
but
otherwise
we
don't
provide
anything
to
these
any
other
interface
to
these
external
to
these
in
process
plugins
and
that
way,
I
am
hoping
that
maintenance
concerns,
but.
A
B
A
B
A
A
Guys
is
present
today
and
our
meeting
I
think
so
way
is
correct
me
if
I'm
wrong
clay
is,
has
joined,
IBM
and
is
working
on
some
of
our
items
and
scheduling
he
has
accepted
to
work
on
cooling
tanks,
not
any
mode
by
condition
to
beta
and
112
is
working
on
that
he's
also
going
to
work
on
moving,
yes,
daemons
at
scheduling
by
default,
scheduler
to
2
beta
in
the
112
as
well.
Thank
you.
C
I'm
new
to
the
to
scheduling,
sick,
so
x-ray
I
work
for
IBM
for
a
long
time
for
nine
hours,
yeah,
I,
work
for
for
nine
years
and
recently
I
change
to
another
department
which
is
focused
on
open
source
development.
So
they
put
me
in
the
scattering
so
yeah.
This
is
my
second
week
in
this
new
team,
so
I
I
like
to
start
with
some
bug
fixes
and
some
like
those
two
features-
combination
to
promote
the
alpha
feature
to
a
better
future
to
get
familiar
this
littell
and
also
do
the
contribution
to
the
community.
C
So
before
joining
this
team,
I
also
working
on
some
project
related
with
with
kubernetes
in
the
past
two
years,
so
that
is
based
more
stuff
on
top
of
cabin
area,
so
so
I
basically
use
in
the
beginning.
You
see
Rd
and
use
sorry
in
the
beginning.
You
TBR
and
then
your
C
idea
to
extend
that
community
behavior
and
to
meet
some
business
requirements
so
yeah
very
space.
Okay,.
A
C
A
That
is
true:
I
I,
don't
object
using
sororities
I
think
that's
a
good
thing
to
do
actually
but
I'm,
not
so
sure
about
the
object
that
he
has
proposed
and
also
the
approach
that
he
has
chosen.
So
I'm
gonna,
I'm
gonna,
comment
more
on
on
that
proposal,
but
his
proposal
is
out.
I
would
like
to
invite
the
community
to
go
and
read
that
proposal
and
comment
on
it.
If
you're
interested
in
gang
scheduling
there
is
a
PR
and
are
on
github.
So,
okay,
let's
see
oh
the
image
locality
priority
function
is
merged.
A
We
need
to
improve
testing
for
that.
I'm
gonna
follow
up
on
that
myself
and
that's
pretty
much
it
I
would
like
to
hear,
but
the
progress
of
hawala
folks
are
under
posted
on
project
or
the
firmaments
scheduler,
but
we
haven't
heard
any
updates
in
a
while.
If
you
guys
see
this
video
later,
please
tell
us
how
you
guys
are
doing,
and
then
there
is
also
promotion
of
the
scheduler
too
to
a
standard
component.
I,
don't
know
if
you're
Ravi
or
let's
see
how
this
is
not
here,
I
believe
probably
or
rubbish.
B
A
There
is
also
another
effort
going
on
and
that's
with
respect
to
party
scheduling
policies,
so
we
are
working
closely
with
the
with
the
folks
in
the
policy
team
and
hopefully
we
are
gonna.
Well
actually,
yes,
you
know,
I
guess
told
me
that
is
gonna
update
the
proposals,
so
we
are
gonna,
see
an
update
under
a
proposal
as
well.
If
you're
interested,
please
go
ahead
and
comment,
there
is
a
PR
as
well
you
can.
You
can
find
all
these
PRS
and
the
links
to
them
and
in
art
spreadsheets.
A
This
spreadsheet
is
available
in
our
in
our
Google
Docs
and
I'm
in
the
link
to
the
spreadsheet
we
are
following.
The
work
is
available
to
the
understand
the
Google
Docs
and
the
Google
Docs
is
linked
to
our
meeting
airport.
So
these
are
I.
Guess
all
the
things
that
I
wanted
to
say
if
you
have
any
I,
have
one
more
question
from
some
of
you
folks,
the
two
who
are
present
in
this
meeting,
but
if
you
have
any
other
questions
about
scheduler,
please
go
ahead
and
ask
now.
B
Related
to
discussed
him
now,
one
thing
I
would
like
to
know
is:
there
are
lots
of
new
people
who
are
interested
in
contributing
like
a
have
been
seeing
quite
a
lot
of
things
and
offline
in
the
slack
channel
as
well.
So
I
would
like
to
get
started
on
creating
a
new
contributors
document,
but
for
that
I
need
some
help
from
you
Bobby
and
then
I
take
some
help
from
others
as
well.
So
I
think
Jonathan
has
started
this
proposal
Whelan.
B
He
was
asking
everyone
to
create
good
first
issues
from
the
issues
that
they
have
created
and
like
I
have
done,
but
I
did
not
see
much
from
other
folks,
so
I
think
I
can
use
this
as
a
reminder.
So
if
anyone
has
created
issues
in
the
past
or
if
they're
creating
now,
if
you
think
that
contributed
first
contributed
issue,
please
label
them
appropriately,
so
that
people
can
get
started
on
it.
Yes,.
A
This
one
one
thing
and
as
a
good
thing
to
do,
is
to
actually
label
these
issues
with
help
needed
or
help
wanted
something
like
that.
I
guess
there
is
a
label
for
this,
and
that
way
we
can
easily
find
these
issues.
Usually
they
should
be
simpler
issues.
We
don't
want
to
waste,
it
create
major
issues
like
Help
Wanted,
because
and.
B
A
A
B
A
The
one
thing
that
I
wanted
to
ask
you
guys
is
that
how
do
you
feel
about
having
this
kind
of
like
weekly
and
to
different
time
meetings?
We've
tried
it
for
a
while
now
and
we
kind
of
like
started
it
as
a
I.
Could
try
a
lot
more?
We
wanted
to
see
if
it
works
for
folks
or
not
I,
don't
know
how
many
are
okay
with
this.
If
you
dislike
it,
let
me
know
either
now
or
later.
If
you
don't
want
to
say
publically,
let
me
know,
and
I
will
try
to
maybe
change
things.
B
A
See
later,
I
see
so
yeah
that
the
challenge
is
that
then
it
becomes
like
7:00
p.m.
in
California,
which
is
like
usually
the
time
that
people
want
will
not
be
available.
So
I'm
not
commuting
back
home.
It
becomes
a
little
bit
challenging,
but
I
hear
what
you're
saying
how
about
you
know
was
it
working
in
better
in
the
past
that
we
had
like
Y,
weekly
one-hour
meeting
at
noon,
PDT
or
PST?