►
From YouTube: Kubernetes SIG Scheduling Meeting - 2019-09-26
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,
hello,
everyone!
So,
as
you
may
know,
this
meeting
is
recorded
and
it
will
be
uploaded
to
YouTube.
We
are
going
to
head
to
the
no
it's
dark
Vinay.
We
have
an
update
on
and
place
good
scaling.
B
Yeah
hi
good
morning,
so
it
is,
is
that
signaled
has
reviewed
it
and
approved
Don
Chen
from
signaled.
She
approved
this
previously
David
Paul
also
had
done
an
LG
TM
for
this,
except
for
the
policy
is
a
minor
comments
which
can
be
fixed
after
it's
merged.
If
we
decide
that
that
level
of
granularity
is
not
needed,
that's
the
debate
that's
going
on,
but
the
core
logic
of
it
seems
to
be
agreeable
to
signal.
B
So
at
this
point,
I
just
wanted
to
find
out
with
sig
scheduling
that
if
I
know
there
were
some
comments
from
you
and
Klaus
and
I
responded
to
them.
I
want
to
see
if
those
responses
are
satisfactory
for
both
of
you
and
if
it
is
then
wicket,
is
it
possible
to
get
a
lg
TM
and
approve
labels
from
you?
This
will
help
me
with
the
API,
take
it
to
the
API
review
and
tell
them
that
the
major
stakeholders
have
approved
it.
A
A
B
B
A
Okay,
so
the
other
agenda
item
we
have
is
a
bid
on
the
framework
migration,
so
I've
been
thinking
and
rethinking
and
rethinking
rethinking
how
to
make
this
really
really
safe.
The
lack
of
the
lack
of
canary
in
basically
is
is
what
basically
worries
me
about.
This
is
migration,
basically
the
idea
of
pushing
in
major
restructuring
without
the
ability
to
actually
test
it
in
production.
A
A
So
that's
the
the
high
Davila
idea
and
what
I've
been
doing
is
basically
trying
to
come
up
with
a
reasonable
approach
to
implement
it
and
I
think
I
have
that
I.
Have
that
done.
I
just
want
to
make
something
really
clear
about
this
conversion
layer,
even
though
that
we
are
converting
on-the-fly,
predicates
or
priorities
into
plugins
configurations.
A
A
Framework
plugins,
those
are
the
ones
that
users
can
disable
and
those
are
the
ones
that
actually
get
will
get.
You
know
one
directly,
not
through
conversion,
so
I
have
a
marathon
PR,
there's
another
one
that
actually
implements
that
I
eat
that
I.
That
idea,
after
that,
we
just
we
I
will
start
with
one
example:
priority
conversion
and
then
I
will
create
issues
for
for
the
rest
of
them.
So
there
are.
There
are
two
high
level
high
level
cases
that
we
are
going
to
migrate
for
the
migration.
The
priorities
and
predict
is
as
right.
A
Now
the
priorities
can
move
a
lot
faster
than
predict
is,
and
the
reason
is
that
we
have
a
lot
of
dependencies
from
the
actual
function,
calls
of
the
predicates
from
cluster
or
sphere,
and
that's
something
also
I'm
always
trying
to
prepare
for
and
make
sure
that
we
properly
properly
support
the
the
good
part
about
predicates.
Is
that
most
they
are
going
to
convert
into
filters
so
that
we
can
call
those
functions
directly.
A
Priorities
which
they
have
two
stages,
sometimes
scores
and
normalized
scores,
etc.
So
so
it's
it's
harder
to
actually
map
them
and
from
that
perspective,
we're
gonna
keep
the
predicate
functions
for
a
longer
time,
because
again,
as
I
mentioned,
there
are
external
dependencies
on
those
and
until
we
have
the
full
list
of
plugins
that
implement
the
exact
same
functionality,
we
it
will
be
hard
to
to
completely
remove
them.
A
A
Fail
the
scheduler
instantiation
if
we
create
a
framework
with
duplicates
plug-ins
under
the
same
extension
point.
This
will
also
help
us
in
during
during
migration
because
at
some
point
we're
generating
content
on
the
fly.
So
it
serves,
as
you
know,
a
verification
step
that
we're
not
doing
something
crazy
and
the
other
thing
is.
We
want
to
refactor
the
metadata
producer
for
predicates
so
that
they
correspond
more
to
three
filters
and
I.
Think
we
can
do
that
right
now.
So
right
now
we
have
a
simple
function
called
get
metadata.
A
We
have
a
single
struct
predicate
miss
data
it.
My
idea
is
to
basically
refactor
that
struct
into
a
collection
of
types
that
could
that
would
correspond
to
the
state
that
each
pre-filter
will
store
eventually
and
the
gate.
Predicate
metadata
also
be
refactored
into
function.
Calls
that
fill
in
these
subtypes
and
those
will
will
basically
be
called
directly
from
the
pre
filters.
C
C
Particularly
the
filtering
is
important,
I
think
and
the
way
that
we
designed
it
and
I
think
we
went
actually
to
a
bunch
of
other
equations
as
well,
and
none
of
them
worked
as
as
good
as
this
particular
one
is
that
we
want
to
have
a
set
of
default
plugins
that
are
going
to
be
that
are
going
to
be
called
in
a
certain
order.
If
someone
wants
to
add
to
these
plugins,
they
changes
at
their
own
plugins
and
they
are
called
after
these
default
plugins.
A
C
It's
important
I
think
in
order
to
basically
change
this
ordering
of
plugins,
it's
important
for
users
to
be
able
to
disable
plugins
and
that's
something
to
keep
in
mind.
I,
believe
you,
you
just
want
to
keep
that
ability.
You
just
don't
want
to
do
it
in
a
very
first
version
after
you
introduce
these
channels
correct.
A
A
What
we
will
have
during
migration
is
predicates
and
priorities
that
gets
translated
into
plugins
in
the
background,
so
from
the
user
scheduler
the
the
the
user
of
the
scheduler
perspective,
we
don't
actually
have
default
plugins,
they
still
deal
with
predicates
and
priorities,
and
that
makes
it
easier
for
us
to
to
get
to
the
finish
line
of
everything
that
migrated
and
then
once
were
there.
Okay,
everything
at
my
everything
is
pretty
good
as
plugins
we're
gonna,
say:
okay,
those
are
your
default
sets
of
predicates
and
different
set
of
plugins.
A
You
can
disable
enable
them,
as
you
wish,
and
we're
not
going
through
the
monthly.
The
translation
layer
at
all
translation
layer
will
be
there
only
for
compatibility
until
we
duplicate
the
policy,
and
it
will
be
there
for
the
cases
where
specify
they
specify
the
policy
specifically
explicitly.
For
example,
they
want
to
list
specific
predicates
custom
priorities
or
predicates
and
for
those.
A
C
C
A
Once
we're
getting
rid
of
once,
we
get
rid
of
predicates
and
priorities,
yeah
its
exact
sense
in
madness.
That
means
right
now,
indeed,
in
the
API.
What
I'm
saying
is
anything
that
gets
translated
from
a
predicate
little
priority.
It's
not
going
to
be
considered
as
a
as
a
as
a
default
pocket,
because,
because
what
the
user
actually
intended
to
do
is
to
actually
run
a
predicate
priority,
we
just
happen
to
run
it
as
a
as
a
framework
plug-in,
but
that's
not
something
that
the
user
will
be
able
to
disable.
A
Producer
to
produce
the
framework
conflicts
that
correspond
to
those,
so
those
configuration
that
gets
created
as
a
result
of
that
you
can't
disable
them.
So
that's!
That's
I!
Guess
my
my
my
point
at
this
point.
Even
if
you
specify
like
disable
everything,
nothing
is
gonna
get
disabled
because
we
don't
have
different
planets.
D
I
think
the
basic
idea
here
is
that
during
the
regulation
phase
there
is
only
one
function.
Unit
no
matter
is
called
predicates
or
studying
it's
responsible
for
their
specific
function,
for
example
to
make
these
on
the
holster
path.
My
future
works,
so
so
so
in
generate
in
your
users
perspective.
They
don't
need
to
worry
about
whether
is
internally
a
predicate
or
a
plug-in,
where
maybe
in
the
middle
of
migration
and
whence
that,
but
the
new
functionality
is
all
new
customized
stuff.
They
must
be
implemented
as
a
manner
of.
A
As
I
mentioned,
like
it's,
internal
details
is
going
to
be
hidden.
What
we
should
be
making
sure
we
we
preserve
is
the
is
the
API
mostly
like,
and
the
side-effects
of
whatever
they
passing
to
that
it
through
that
API,
for
example,
is
a
passive,
critical
or
priority
in
the
policy
should
get
executed,
but
the
interactions
between
them
like
if
they
pass,
if
the
passive,
predicate
or
priority,
and
that
gets
translated
down
the
line
to
control
config.
That
doesn't
mean
that
they
will
be
able
to
disable
it
through
the
API,
because
those
are
two
different
things.