►
From YouTube: Kubernetes SIG Scheduling Meeting - 2019-10-10
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
So
hi
everyone,
as
you
may
know,
this
meeting
is
recorded
I
will
be
uploaded
to
YouTube.
So
let's
look
at
the
agenda
and
see
if
I
added
a
couple
items
I
would
see.
Others
I
did
move.
A
A
Great
was
good,
so
related
to
migration.
I
sent
a
br
to
disabled
out
of
tree
framework,
plugin
registration
I'd
like,
and
the
reason
is
that,
right
now
the
framework
is
in
flux,
there's
so
many
changes
happening
to.
So
there's
no
point
to
actually
claim
that
we
support
that
and
actually
having
that
is,
complicates
phase
one
migration.
A
B
I
saw
some
more
some
concern:
I
think
they
are
from
10
cents
for
China,
so
basically
they're
very
aggressively
trying
this
new
feature
and
yeah.
They
are
using
that
way
to
build
a
schedule
van
during
the
CME
keeps
that
schedule
and
build
their
own
stuff
right.
So,
but
basically
it's
the
instead
of
aggressively
says
that
we
don't
stop
all
this.
How
about
just
giving
an
explicit
warning
says
that
we
have
not.
You
know
we
are
experiencing
a
large
amount
of
API
changes
and
blah
blah
and
says
now
you
may
be
risk
in
using
this
feature.
A
A
Objects
like
the
scheduler
cache
and
we
need
those
at
the
time
when
we
create
the
different
registry
and
and
the
different
urgency
right
now
is
created
very
at
the
very
early
stages
of
the
creating
scheduler.
Basically,
in
the
like,
you
know,
AB
slash
servant
of
God
and
it
would
require
us
to
either
like
really
violate
some
basic.
You
know
coding
principles
like
throwing
in
global
batteries
or
the
place
or
basically
expose
the
internal
cache.
All
the
way
to
the
the
app
slash
server
that
go
file
so
I
mean.
A
A
You
know-
have
all
these
hacks
to
instantiate,
predicates
and
priorities
at
the
time
when
we
create
the
default
registry.
So
it's
it's
a
it's
really
a
tricky
plumbing
issue.
More
than
just
saying
that
we
don't
support
it
because
I'm
afraid
that
they
will
lower
face
problems
with
the
changes
of
the
of
the
framework
API
itself.
B
Yeah
Marchman
points
that,
in
the
form,
for
our
perspective,
to
make
our
code
more
consistent,
amongst
is
it
easy
to
maintain,
may
be
a
good
idea
that
in
the
external
users
perspective,
if
they
are
already
using
trying
this
aggressively,
and
then
we
tolerate
this
table,
then
we'll
just
stop
there
really
going
forward.
I'm
I
mean
I.
Just
don't
want
to
see
that
we
can't.
We
do
need
external
users
to
giving
to
give
us
feedback
and
how
that
direction.
If
it
looks,
looks
right.
B
Well,
yes,
well,
if
they
continue
using
current
interface
there
and
get
the
internal
cache,
is
male
and
get
the
volume
bender
cash
gets
new.
So
what
what
happens
to
their
use
case?
I'm
wondering
okay
yeah!
So,
basically,
if
they
are
clipping
using
our
interface
and
using
your
ladies
spear,
their
continual
registering
using
their
implementation
right.
So
what
they
that
the
cash
they're
getting
is
new
right.
It's.
A
A
C
A
C
A
Yeah,
it
is
a
trade-off
between
like
really
freaking
the
structure
of
the
code
slightly
and
supports
something
that
is
like
I
feel
it's.
It's
not
that
useful,
but
I
hate
it.
It's
like
I'll,
take
another
look
and,
and
try
to
either
create
those
handlers
somewhere
at
the
beginning
and
instantiate
them,
for
example,
as
global
variable
that
we
read
into
the
wait
time
when
we
create
the
registry,
the
very
early
stages,
or
we
do
registration
on
the
fly
at
a
later
stage
for
the
plugins
that
actually
need
those
those
handles.
C
D
First
one
is
the
D
scheduler
there's
some
talk
on
slack
about
upgrading
that
to
116,
so
I've
started
working
on
that
my
plan
with
that
actually
is
to
kind
of
do
it
in
two
parts
and
first
bump
everything
to
116
with
glide
that
it
has
now
and
then
once
that's
all
sorted
out
and
working
transition
to
go
mod,
just
kind
of
bring
it
in
line
with
everything
else
in
communities
right
now,
I,
don't
know
if
there's
any
opinions
or
concerns
about
that,
but
a
link
to
the
PR.
That's
progress
there.
It's
a
pretty.
D
B
E
B
E
D
B
E
D
It's
no
problem,
so
the
second
thing
was
Ravi
mentioned
to
me
today.
I
think
it's
a
good
question
to
ask.
Kim
count
is
next
month
and
I
was
wondering
if
we
have
any
plans
or
schedule
right
now
for
a
sig
face-to-face
and
maybe
just
some
kind
of
general
presentation
on
scheduling,
try
to
introduce
people
to
it,
get
some
more
contributors.
B
B
D
F
Know
there
were
some
issues
with
my
microphone
or
audio
system
whatever
so
any
anyway.
I
think
what
I
remember
I'm
not
sure
about
this.
But
what
I
remember
is
that
in
this
contributor
summit,
they
decided
to
not
have
any
face-to-face
meetings
for
4-6,
not
that
they
decided
that
they
don't
have
any
face-to-face
meeting,
but
for
particularly
for
six,
they
decided
to
not
have
face-to-face
meetings.
That's
what
I
vaguely
remember
from
conversation.
F
A
A
Okay,
so
the
docs
kubernetes
doc
says
that
this
system
supports
creating
pods
with
system
critical
priority
in
any
namespace,
and
that
doesn't
seem
to
be
true.
I.
Think
Bobby
in
the
past
sent
like
an
PR
to
disable
this
until
Kota
resource
quota
is,
is
implemented,
I,
don't
know
if
Bobby
remembers
yeah.
That's
that's
true,
so
yeah.
F
Basically,
I
mean
in
terms
of
coding
and
our
priority
by
itself,
there's
really
no
issue
with
with
letting
users
create
pod
file
or
any
pot
pie
or
any
names,
but
the
reason
that
we
decided
to
limit
it
is
that
if
you
have
untrusted
users
in
your
cluster,
you
can
create
pods.
Basically
in
multi-channel
scenarios,
if
you
have
untrusted
users
and
if,
if
they
are
allowed
to
create
any
part
with
any
priority,
the
the
problem
is
that
they
could
basically
kick
out
any
other
parts,
including
system
critical
parts
from
the
cluster.
F
So
this
could
cause
a
denial
of
service,
basically
in
a
cluster
and
could
take
down
the
cluster.
For.
For
that
reason,
we
decided
to
limit
those
priorities
to
queue
system.
Very
users.
Normally
don't
have
quota
to
do
now,
I
mean
untrusted,
users,
definitely
have
color
to
create
paths,
and
so
when
importing
huge
system
can
specify
those
priorities,
this
was
actually.
This
was
the
case,
and
we
decided
to
remove
this
when
coda
or
other
name
is
spaces
quota
by
priority,
basically
and
I
think
it
congratulated
to
paid
all
right.
A
while
ago,
yeah.
F
Been
available
for
a
long
time,
but
particularly
resource
quota
based
on
priority
is
so
basically
in
scope.
You
can
specify
a
priority
class.
For
example,
you
say
I
priority
and
all
system
critical
you
have
like
in
a
namespace
foo,
you
have
three
CPUs
and
things
of
that
sort,
so
basically
creating
a
coda
based
on
priority
was
something
that
did
not
exist
and
we
added
it
later
with
priority,
but
it
was
after
for
a
while
I
think.
It's
now
beta.
A
F
F
A
F
F
Namespace
is
scoped,
so
I
tells
you
where
you
can
create
these
pods
and
how
many
of
these
resources
you
can
use.
So
anything
not
anything,
but
almost
anything
can
be
defined
as
as
a
limited
resource,
including
the
number
of
parts
and
amount
of
CPU
or
memory
that
they
use
and
so
on.
Also
the
priority
and
I
mean
priority
is
basically
one
of
the
criterias
to
match.
So
basically
you
can
say
at
this
particular
priority.
You
have
some
was
so
much
CPU
or
so
much
memory
or
so
many
parts.
Okay,.
A
F
E
F
A
A
Okay,
thank
you.
So
much
I'll
see
you
next
week
all
right.