►
From YouTube: Kubernetes SIG Scheduling Meetings 20180104
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
Can
add
if
they
want
anything
and
then
we
can
go
through
them
in
some
order?
We
have
the
1.10
plan,
which
we
haven't
actually
started.
I
guess
the
really
any
like.
Usually
we
started
the
discussion
for
a
release
plan
on
the
mailing
list
first
and
then
discuss
it
in
the
meeting
started
no
endless
discussion
first,
but
people
can
bring
up
stuff.
They
want
to
talk
about
here.
Of
course,
there
was
some
interest
in
talking
about
resource
classes.
A
Tim
Sinclair
brought
that
up
and
then
also
resource
quota,
Mike
Rubin
who's,
not
here
yet
want
to
talk
about
how
we
can
get
more
contributors,
helping
out
with
things
like
code,
reviews
and
stuff
like
that,
and
then
I
want
to
talk
about
the
scheduling.
Sig
leads
I,
having
done
not
to
make
it
a
huge
surprise,
but
I
wanted
to
get
feedback
on
the
idea,
because
there
isn't
currently
any
official
process
in
kubernetes
for
determining
who
the
sig
leads
are.
I
am
working
less
on
scheduling
lately
and
Bobby.
A
Who
is
one
of
my
colleagues
at
Google
and
has
been
coming
to
these
meetings
and
you've
seen
on
on
github
and
so
on
has
been
doing
a
lot
more
work
on
scheduling,
and
so
my
pozole
is
to
just
simply
replace
him
with
me.
If
there
are
any
objections
with
that,
we
should
talk
about
them
and
then
we
can.
We
can
escalate
to
the
to
the
whatever
the
forgot,
the
name
of
the
steering
committee
right.
A
D
Thing
which
I
also
mentioned
an
email
is
what
to
do
with
the
email
switch
controller,
scheduling
logic
that
is,
that
is
a
bigger
controversy.
I
think
it
cannot
really
address
it
in
today's
meeting
and
I'm
writing
a
design
dog.
So
probably
it's
better
if
we
discuss
it
in
our
next
meeting
once
that
design
dog
this
way.
Okay,.
A
D
E
It's
part
of
the
110
cycle,
stuff
I,
wanted
to
there's
a
bunch
of
old
work
and
bugs
that
are
filed.
We
have
a
backlog
of
235
items,
some
of
those
are
actual
bugs
with
and
some
of
which
are
like.
We
have
not
promoted
things,
so
we
have
this
weird
history
or
legacy
where
we
have
half
annotation
half
fields,
because
you
know
we
had
that
weird
split
over
time
and
some
of
those
annotations
will
have
to
go
through
promotions
at
some
moment
in
time
like
the
node,
selector
or
there's
a
couple
other
ones.
E
A
We
should
definitely
go
through
and
see
if
there
are
any
features
that
we
are
still
supporting
in
the
annotation
form
and
and
deprecated,
and
remove
those
and-
and
if
it's
the
case,
that
we
haven't
even
created
fields
for
those
yet
like
when
we
move
those
features
to
beta
or
something
like
that,
we
should
we
should
create
fields
for
them.
In
other
words,
like
you
know,
we
should
replace.
A
We
should
move
those
along
the
path
of
replacing
the
annotations
with
fields
for
any
of
the
scheduling
features,
and
that
was
certainly
our
intention
all
along
and
it's
possible
that
we
didn't
finish.
That
process
like
we
certainly
may
have
left
some
of
the
Alpha
annotations
in
there.
In
addition
to
enabling
the
new
field
version
of
the
of
the
feature.
So
that's
it.
That's
a
good!
That's
a
good!
A
That's,
a
very
good
solution
for
a
very
good
suggestion
for
a
cleanup,
because
I
think
having
those
there
is
gonna
confuse,
confuse
people,
people
wonder
which
should
they
be
using
the
field
version
or
the
annotation
version
of
the
feature,
so
that
that
sounds
like
a
good
idea.
How
do
you
propose
we
tackle?
That
I
mean
this
actually
ties
in
to
kind
of
Mike.
The
thing
Mike
Rubin
wanted
to
talk
about,
which
was
like
how
we
can
get
more
community
participation
in
some
of
these.
D
As
a
lot
of
people
have
come
to
me
and
have
asked
this
question
and
my
answer
to
them
has
been
giving
them
some
ideas
about
what
are
the
options
and
giving
like
the
search
queries
to
find
all
these
remaining
items
and
4/6
scheduling
what
I've
seen
a
lot
is
that
a
lot
of
people
go
and
pick
up.
Some
of
these
a
feature
requests,
but
people
are
usually
very,
very
hesitant
to
take
on
Fox.
F
Of
course
it's
open
source,
it's
glamorous
I
mean
it's
like
you
know,
and
it's
it's
more
satisfying
initially.
Also
right.
You
know,
I
found
that
an
open
source,
you
know,
adding
a
feature,
is
you
know
it's
easy
to
understand
and
the
satisfaction
loop
is
very
direct
and
understanding
the
value
of
you
know,
testing
or
benchmarking
or
some
of
the
other
pieces.
Is
it's
a
little
more
indirect,
even
though
the
value
may
be
a
lot
higher.
But
if
that's
controversial,
let
me
know
that's
just
sort
of
what
I've
seen
in
open
source
even
outside
of
kubernetes.
F
E
That's
that's
common
in
open
source
in
general,
people
gravitate
towards
the
shiny,
and
you
know
the
stalwarts
have
a
tendency
to
clean
up
the
mess.
That
is
a
result
of
it
right,
but
the
problem
is
we're.
We
have
this.
We
need
to
develop
a
methodology,
not
just
within
this
sig
but
broader
across
the
project.
Many.
F
Other
things
have
methodologies
that
work
pretty
well
and
that's
what
I
sort
of
wanted
to
come
today
that
so,
if
I
give
you
a
little
bit
of
context,
I
work
at
Bobby
and
Bobby
was
talking
to
me
about
some
of
the.
You
know
the
the
feeling
that
you
know
and
Bobby
for
misrepresenting
you
please.
Let
me
know
that
you
know
Bobby.
F
He's
gonna
be
on
leave
a
little
bit,
but
he'll
be
back,
but
I.
Don't
really
think
that's
the
systemic
answer.
How
do
you
balance
the
desire
to
add
functionality
and
features
and
then
build
a
healthy
cig
that
can
be
educated
and
make
priority
calls
and
deal
with
the
fact
that
what
if
you
know
Bobby
wins
the
lottery
and
then
is
gone
forever?
You
know,
I
think
the
cig
right
now
would
not
be
in
a
great
place.
F
You
know
what
we
do
in
other
SIG's
is
we
have
the
idea
of
Shepherd's,
so
when
you
start
doing
your
planning
for
a
release,
every
feature
needs
to
not
just
have
a
developer.
You
also
have
to
pair
it
with
a
shepherd
who
is
going
to
be
both
being
able
to
add
guidance
and
context
or
the
feature
for
the
developer
if
it's
a
new
developer
and
then
also
do
the
code
reviews-
and
this
has
worked
out
really
well
in
a
lot
of
the
other
SIG's,
the
downside
is
when
we
first
start
the
process.
F
What
we
find
is
that
throughput
of
functionality
in
the
stake
it
drops
pretty
heavily
because
you
generally
don't
have
enough
Shepherds
to
you.
You
bring
to
light
the
real
situation
early
on,
which
is
that
you
may
not
have
enough
Shepherds
to
shepherd
in
all
the
functionality
through
through
the
state
for
that
release.
But
then
what
you
do
is
you
start
empowering
folks
who
say
great,
you
know
if
you
want
to
add
functionality,
you
know
you
want
to
chop
wood.
You
got
a
chocolate
and
carry
water.
F
A
This
is
what
this
is,
what
I
was
gonna,
say,
I
think
I
think
you
know
we
got
pretty
severely
fragmented
when
the
what's
called
the
resource
management
working
group
formed
that
kind
of
pulled
off
a
lot
of
the
people
who
used
to
come
to
the
six
scheduling,
meetings
and
I'm
actually
worried
that
the
multi-tenancy
working
group
is
gonna,
make
things
even
worse
and,
and
so
I
I
think
that
we
have
to
address.
We
have
to
at
least
consider
the
problem
that
Tim
brought
up
is.
This
is
actually
what
I
was
thinking.
C
F
I
think
that's
okay
and
I.
Think
that
we're
this
is
great
because
we're
actually
talking
about
the
real
problems.
What
I
have
found
really
interesting
about
the
scheduling,
team
and
scheduling
and
kubernetes
in
general?
Is
it's
often
seen
as
a
very
glamorous
piece
of
technology
of
kubernetes
and
that
many
many
times
people
have
come
to
me
and
said
I
would
love
to
work
on
scheduling
and
in
the
past
there
hasn't
been
as
much
of
a
driving
need
in
open-source
for
their
other
things
that
were
more
urgent.
I
really
am
very
optimistic.
F
E
I
think
it's
an
ongoing
process,
it's
kind
of
like
a
continual
in
marketing
campaign,
because
we've
actually
had
people
come
in
and
get
all
the
way
to
maintainer
level
like
Klaus,
but
now
he's
working
on
other
things
right,
so
it
it's.
You
need
to
can
I
likely
the
idea,
but
it's
a
it's
part
of
a
ongoing
maintenance
of
the
cig
to
have
like
this
ongoing
recruiting
campaign,
because
without
fresh
blood,
what
has
a
tendency
to
happen
is
either
they
get
rejected
by
their
employer.
E
G
F
With
the
next
piece,
so
I
think
that
there's
like
three
or
four
things
that
are
coming
to
light
in
the
conversation
or
maybe
already
obvious
to
everyone,
but
we're
just
collecting
once
here
one,
is
that
the
sig
isn't
that
big,
the
other
one
is
that
we.
It
feels
to
me,
though,
that
even
given
it's
not
healthy
to
have
us
depend
on
just
one
engineer
or
two
engineers
and
I
think
that
actively
right
now
and
correct
me
if
I'm
wrong
with
David
focused
on
other
things
driven
to
them
by
mostly
the
company.
F
G
I
mean
I
mean
a
vest,
has
largely
been
focused
on
being
our
scheduling,
SMA
and
he's
been
training
up,
Ravi,
who
folks
seen
working
on
the
DS
scheduler
I.
Think,
like
your
your
story
of
people
who
are
interested
in
scheduling,
I,
think
that
describes
Robbie
to
a
tee
avi
is
new
to
the
community
I'd
love
to
see
him
mature
and
and
be
able
to
go
through
the
ladder
that
Tim
was
discussing.
I
mean
obviously
I.
Also
look
at
the
incoming
bug
rate.
You
know
that
we
get
in
our
product.
G
It's
reported
by
I,
actually
don't
find
that
we
get
a
ton
of
bugs
on
the
scheduling
side
at
this
I'm,
not
sure
how
the
broader
community
feels,
but,
like
relative
to
say
you
know
people's
pots
not
running
properly
or
something
it
seems
scheduling.
Is
it's
not
the
thing,
that's
being
a
source
of
pain,
you're.
F
Anticipating
my
next
statement
like
so
it's
a
great
segue
I,
agree:
I,
don't
think
this
is
a
hotbed
of
I.
Don't
think
we
need
like
the
40
engineers.
Maybe
we
have
in
some
of
the
other
SIG's
I
do
think
that
we
need
a
core.
The
core
should
probably
be
more
than
to
two
companies
and
more
than
definitely
like
one
person
from
each
company,
which
is
why
we
made
the
decision,
at
least
at
Google,
the
staff
it
with
two
people
and
I'm,
hoping
that
you
know
maybe
Red,
Hat
or
somewhere
else
will
staff
it
yeah.
F
A
I,
don't
think
the
problem
is
as
much
that
we
have
tons
of
people
trying
to
add
features
and
they
have
unrealistic
expectations,
because
we
can't
find
enough.
You
know
senior
reviewers
to
take
them
on
I.
Think
the
problem
is
more
like
the
backlog
that
that
sort
of
started
this.
This
discussion,
the
Tim
Tim,
was
talking
about
where
we
don't
have
anyone
to
deal
with
like
200
issues
identifying
which
ones
would
be
good
for
new
people,
which
ones
are
no
longer
irrelevant
and
should
be
closed
and
send,
and
so
on
that
that
kind
of
thing
we.
F
D
G
There's
a
number
of
things
like
now.
We
say
we
put
under
the
SIG's
scheduling
umbrella
outside
of
the
course
guide.
So
yeah
I
mean
that
that
was
the
cluster
capacity
tool.
There's
the
D
scheduler
component.
Well,
I
quota
is
awkwardly
under
sake,
scheduling.
It
sounds
like
which
was
new
to
me,
but
I
mean
I'm,
not
aware
of
it
like
anyone
at
Red,
Hat,
trying
to
push
a
new
say,
scheduler
or
a
new
incubator
project.
In
this
domain
like
to
me,
the
ongoing
shop
would
just.
G
G
F
F
You
know
the
the
additional
engineers
in
both
red
head
and
Google,
and
that
sounds
great
to
me,
but
I
want
to
make
sure
that
we
keep
it
clear
and
lastly
and
I'm
gonna
say
this
in
front
of
Bobby
and
maybe
he'll
get
angry
at
me.
Sometimes
I
think
Bobby's
willing
to
take
on
a
lot
and
then
realizes
at
the
end
of
the
quarter.
You
know,
do
you
know
who's
really,
really
pushing
himself
to
get
things
into
that
release,
and
it's
happened
once
or
twice
already.
I
want
to
make
sure
that
we
have
set
expectations
appropriately.
E
E
E
F
Of
work,
so
it
sounds
like
you
know
if
we
can
say
for
sure
that
we've
got-
and
this
is
news
to
me,
which
is
great,
which
was
I'm,
really
glad
we're
talking
about
it,
that
we've
got.
You
know
four,
mostly
dedicated
people's
me
dedicate.
It
means,
like
eighty
percent
of
their
time
in
cig
scheduling
by
the
summer.
Well,.
G
A
G
To
know
what
the
I'm
looking
at
a
six-month
roadmap
RedHat,
we
want
to
see
priority
and
preemption.
Go
to
beta
I
mean
I
the
design
proposal.
If
we
go
talk
to
it,
I
I'm
trying
to
reduce
the
requirements
that
you
need
to
satisfy
that
we
obviously
have
customers
and
we
need
to
support
the
scheduler.
We
have
at
least
two
people.
You
know
with
deep
expertise
now
in
the
scheduler
growing
and
I
don't
plan
for
them
to
go
anywhere,
but
III
feel
like
I'm,
echoing
you
Mike
in
that
I'm.
G
Not
lobbying
for
major
new
feature
enhancements
in
the
scheduler
beyond
party
preemption
in
110.
I
would
like
to
see
that
these
scheduler
continue
to
evolve,
but
that's
outside
of
the
core
cube
release.
So,
and
ideally,
we
can,
you
know,
track
community
around
that
aside,
for
my
traditional
scheduling
expertise.
So
that's
we
already.
D
That
some
of
these
people,
some
of
these
people
that
you
mentioned
at
particularly
two
guys
who
are
working
from
Red
Hat
site,
are
working
on
an
incubator
project
right.
But
for
these
goes
around
the
cluster
capacity
to
so
the
or
not
that
much
involved
with
like
a
review
process
or
fixing
bugs
or
any
of
I
mean.
G
That
that
might
be
a
sign
of
them
just
not
knowing
that
they
are
needed.
So
if
you
feel
that
you
need
to
reach
out,
I
mean
I
am
pretty
much
expecting
our
mom
I
would
like.
If
there's
any
help,
you
need
Bobby
to
get
priority
and
preemption
out
the
door
and
keep
110
I
mean
those
two
people
I
just
named
to
you
are-
are
on
the
hook
for
that
same
basic
need
right.
B
Looking
like
yeah,
definitely
like
a
priority
and
3m
cell
is
really
important,
but
regarding
other
issues
on
backlog
behave,
I
think
one
thing
we
have
noticed
is
what
I
noticed.
We
have
not
really
categorized
their
priorities
like
how
high
priority
is,
how
high
priority
they
are
so
maybe
like
once.
We
have
really
clear
idea
like
how
high
priority
they
are.
Maybe
then
we
might
go
and
spend
more
time
on
them.
Oh,
so,
smart.
E
Instead
a
couple
of
releases
ago,
I
spent
in
order
to
bouts
of
time
clearing
through
the
backlog
and
like
literally
a
week
plus
of
just
sorting
I,
don't
remember
what
release
it
was,
but
it
was
a
while
ago,
where
all
we
did
was
we
wanted
to
have
quotes
with
quote
unquote,
stabilization
release
and
I
think
it
was
the
time
we
did
graduated
affinity
and
attention
toleration
shift
which
was
like
it's
actually
a
year
ago
now,
but
that
there,
in
that
time,
I
spent
in
learn
amount
of
time
trying
to
shuffle
sort
and
prioritize
the
entire
backlog
of
the
scheduler,
and
it's
an
ongoing
effort.
E
F
E
Can
be
part
of
the
responsibilities
I
think
it's
also
important
that
the
people
that
are
filing
the
issues
that
are
opening
things
to
are
looping
people
in
so
that
way
we
get
priority
resolution
over
time,
because
otherwise,
if
it's
blank
right
over
time,
I
don't
have
enough
time,
sometimes
to
always
sort
through
the
backlog
right.
So
right
now
for
as
far
as
other
SIG's
are
concerned,
we
have
probably
a
much
smaller
backlog.
You
know
them
other
62b.
A
A
You
know,
since
the
beginning
of
this
sake,
I
always
watch
the
thigh
issues,
they're
filed
and
and
and
make
sure
that
that
we
address
the
things
that
look
like
like
potential
serious
bugs
or
what
happened
so
I,
don't
think,
there's
any
p0
stuff
in
the
backlog,
but
I
don't
think.
We
know
the
distribution
between
like
p1
p2
p3
in
the
backlog
and
that's
that's
kind
of
the
thing
that
we
need
to
figure
out.
F
E
F
E
F
200
of
them,
then
you
know,
maybe
you
can
just
divide
them
up
into
four
groups
and
assign
them
to
like
four
people,
and
then
everyone's
got
like
50
and
they
can
get
that
done.
Hopefully,
in
you
know
an
afternoon,
I
hope
that
you
know
triage
in
50
of
them
shouldn't
take
too
long.
It
sounds
like
there's
a
few
things
going
on.
One
of
them
is
understand.
What
is
the
future
work
that
we
have,
and
then
you
know
also
when
we
do
our
planning
today,
I'm
sorry
I'm,
a
little
ignorant.
A
F
Dim
storage
does
that
a
lot
I
don't
know
if
they
still
do
Derek
you
can
confirm,
but
I
think
one
of
the
benefits
of
that
is
that
it
lets.
You
really
understand
you
can,
let
you
add
annotations
like.
Is
there
a
shepherd?
You
can
tell
I'm
very
focused
on
that,
because
if
you
don't
figure
out
who's
going
to
be
reviewing
the
code,
when
you
start
it
and
you,
then
you
realize
you
can
quickly
realize
how
to
prioritize
yeah.
A
F
Yeah
yeah,
so
then
I,
you
know
it
sounds
like
we're.
Hopefully
gonna
be
okay,
then,
if
you
know
this
sounds
like
there's
new
information
that
it's
come
to
light
like
Derek.
Are
you
if
you
take
a
look
at
the
other
cross-cutting
efforts?
Are
you
at
least
convinced
and
that
Red
Hat
should
continue
to
invest
the
efforts
of
those
two
people
in
six
scheduling?
Let's
just
say,
till
the
next
two
or
three
releases,
I,
think
you're,
not
that's.
Okay,
I'm,
just
asking
I
mean
I.
Think.
G
Think
it's
a
matter
of
like
some
of
the
stuff
that
our
folks
were
working
on
were
under
the
scheduling
umbrella
and
we
were
outside
the
course
scheduler
I.
Don't
really
I'm,
not
encouraging
our
folks
to
go
build
more
of
those
things
right
now.
I
want
to
the
people
who
are
here
now
I
mean
we've
direct
people
on
sticks
to
be
there.
For
the
long
term,
I
mean
to
David's
point
on
how
you
select,
sig,
leads
and
stuff
I
mean
I,
think
it
should
be
associated.
G
F
A
So
I
had
one
one
comment
which
was,
and
we
will
we've
covered
a
bunch
of
issues
here,
but
with
regard
to
the
planning
issue,
we
definitely
need
to
set
up
the
110
spreadsheet
and
start
talking
about
what
we
want
for
110,
but
I
think
also.
It
sounds
like
we
should
have
maybe
a
six
to
nine
month
or
even
year,
plan
for
what
we
are
planning
to
work
on
in
this
sig
because,
like
while
you're
talking
a
couple
of
things,
came
to
mind,
one
was
the
cube
arbitrator
which
has
been
hanging
out.
A
G
A
Are
as
Tim
mentioned,
which
we
moved
to
beta
about
a
year
ago,
we
they've
been
hanging
out
in
in
beta
for
a
long
time.
There
are
some
open
issues
that
we
need
to
address
primarily
around
scalability
concerns
for
a
couple
of
them,
but,
and
so
that's
something
that
I
think
we
should
put
on
the
plan
for
this
year.
I,
don't
think
that
anybody
has
time
for
110
to.
C
A
But
so
so
I
think
that
my
point
is
just
that,
like
I
think
we
need
a
110
as
we've
done
for
every
release.
We
need
a
110
spreadsheet.
We
just
haven't
set
it
up
yet,
but
I
think
we
should
also
just
to
give
the
community
an
idea
of
what
we're
thinking
of
for
the
whole
year
year
long
process,
what
we're
thinking
of
or
this
year
so.
F
I
think
there's
three
points.
One
is
I
think
we
need
to
publicize
what
we
think
is
important
to
do,
because
I
believe
that
there's
a
mean
going
on
in
kubernetes
that
yeah
six
schedule
names
kind
of
dead.
There's,
not
a
lot
left
and
I.
Think
that
that's
one
thing
we
should
probably
but
maybe
have
a
community
meeting
and
out
you
know,
presentation
of
the
sig.
Let
them
know
that
there's
still
a
lot
of
vital
work
that
has
to
get
done.
F
G
I
guess
yeah
I
generally
agree
with
you.
One
question
I
have
David
when
you
talk
about
roadmap
is
like
the
challenge
we
see
right
now.
Is
we've
offered
a
lot
of
scheduling
primitives,
but
not
a
lot
of
tools
to
make
it
easy
to
take
advantage
of
them,
and
so
I'm
trying
to
rationalize
in
my
head
is
like.
Is
that
in
the
scheduling
domain,
or
is
that
more
in
the
domain
of
sig
apps
right
like
what's
that
I'd.
F
G
I
guess
the
challenges
I
see
and
I'll
just
be
frank
about
it.
A
little
bit
is
like
a
lot
of
this
ties
into
the
multi-tenancy
work.
I
think
David
that
you're
you're
looking
to
do
like
my
major
issue
with
the
priority
preemption
right
now
is
it's
not
clear
how
I
take
advantage
of
it
in
a
multi-tenant
environment.
G
So,
like
a
lot
of
these
things,
are
cross-cutting
I,
don't
think
people
necessarily
nervously,
always
the
right
stick
to
go
to
for
them,
but
in
my
head
longer
term,
when
I
look
six
to
12
months
out,
I'm
expecting
a
way
of
demonstrating
to
rpms
and
our
users
that
this
is
how
you
make
natural
use
of
affinity
and
anti
affinity
and
all
that
stuff
that
we've
been
adding.
You
know,
I,
think
a
little
bit
at
the
beginning
of
that
was
some
of
the
stuff
that
fish
had
done
to.
G
A
I
think
I
agree
with
Michael
I
mean
I.
Think
I
think
that
this
is
the
right
place
to
start
for
those
those
tools.
I
think
we
can
see.
You
know
if
it
makes
more
sense
later
to
move
it
to
different
say.
We
could
consider
that,
but
I
do
agree
that
that
general
class
of
problem,
whether
you
like
you,
thought
tools
like
Mike
did
or
the
user
experience
around
the
schedule
or
primitives.
G
F
That's
great
Derek
and
I
think
it's
also
really
important
too,
because
I
think
that
if
the
people
in
the
what
I've
noticed
a
tendency
is
when
engineers
are
just
doing
the
infrastructure
and
not
working
on
the
systems
that
consume
them,
they
can
sometimes
lose.
They
can
miss
opportunities
and
then
usability
suffers.
So
that's
one
of
the
other
reasons
why
I'm
very
excited
to
hopefully
give
Bobby
breathing
room
and
I
keep
talking
about
Jonathan
like
he's
not
here,
but
he's
sitting
right
next
to
us.
F
A
Right
so
we
should
it
sounds
like
we
should
crowdsource
the
110
spreadsheet,
as
as
we
usually
do,
and
then
also
do
something
longer-term
to
give
people
an
idea
of
the
scope
of
what
we're
thinking
about
for
2018
in
the
sig.
That
sounds.
That
sounds
like
like
good
thing.
We
only
have
about
19
minutes
left.
E
Are
the
action
items
that
we've
got?
Can
you
numerate
them?
So
we
didn't
just
so
I
think
one
thing
he
mentioned
was
crowdsource
a
spreadsheet,
so
we
need
to
get
a
spreadsheet
in
place.
The
second
thing
that
I
really
would
like
help
with-
and
it
not
just
be
me-
would
be
to
divide
up
the
backlog
such
that
we
go.
Somebody
goes
through
and
it's
not
fun
and
it
doesn't
take
an
afternoon.
E
It
takes
way
longer
because
you
need
to
read
through
the
history
of
some
of
this
stuff,
and
some
of
it
is
cross-cutting,
and
some
of
it
is
legacy
problems
that
have
existed
since
epoch.
So
it's
it
takes
a
while
to
suss
through
it
all
and
to
assign
relative
priorities
and
determine
whether
or
not
we
should
close
them.
If
someone
could
help
me
live
with
that
adventure,
I
can
help
do
pieces
of
that,
but
it's
gonna
take
a
while
I
can.
A
I
can
help
with
that
Tim
I
mean
the,
because
I
think
that
you
and
I
are
probably
the
only
two
who
have
the
context
from
multiple
across
the
multiple
years
over
which
lease
these
were
filed
and
not
never
handled
so
I'd
be
great
you'll
be
great
if
more
people
can
help,
but
I
think
that
the
two
of
us
needs
to
be
involved
in
that.
Since
this,
like
you
said,
there's
a
lot
of
history
for
some
of
these
things,
yeah.
B
D
F
Sounds
like
one
action
is
crowdsourcing
the
spreadsheet,
the
other
one
is
chewing
through
the
backlog,
and
you
know,
hopefully
if
we
can
get
people
besides
David
and
Tim
involved,
maybe
some
of
the
newer
issues
so
maybe
take
that
to
a
thread
and
figure
out
the
best
way
to
do
that
and
then
the
last
one
is
maybe
looking
at
future
planning
beyond
just
110
release.
Is
that
correct,
David,
yeah.
A
F
Ideas
for
2018
and
then
maybe
finally,
a
community
meeting
to
talk
about
like
we're
doing
and
that
there
there
are
things
coming
out
and
including
you
know,
people
who
may
not
feel
comfortable
delving
in
the
deep
pieces
of
the
scheduler
but
are
interested
in
coming
up
with
usability
tools
and,
and
you
know,
systems
and
ecosystems,
to
help
make
it
easier
to
work
with
ya.
Know.
D
F
Side
note:
one
of
the
things
that
really
made
me
surprised
was
that
some
of
the
support
people
in
Google
and
RS
Ari's,
we're
very
familiar
with
kubernetes,
tend
to
give
scheduling
bugs
to
the
the
networking
team
you
know
and
so,
and
also
have
a
very
dim
sort
of
understanding
of
what
scheduling
pods
are
and
and
how
the
system
works.
And
so
you
know
possibly
even
I,
don't
know
what
sort
of
educational
things
we
have,
but
a
YouTube
movie
might
not
be
a
bad
idea
or
some
way
of
educating
folks.
F
A
So
I
consider
I
was
gonna.
Go
to
that
next
I
considered
that
a
separate
nobody
said
anything
else.
So
yes,
we
could
go
on
to
that
so
yeah.
So
I
mentioned
at
the
beginning
that,
like
that
less
involved
in
scheduling
these
days
and
Bobbie
as
Michael
has
alluded
to
is
kind
of
taking
over
or
at
least
as
the
on
the
Google
side,
as
kind
of
a
lead
and
in
the
scheduling
area,
and
so
I
was
hoping
that
he
could
take
my
place.
It
sounds
like
there's
some
interests
from
RedHat
and
getting
a
vet
involved.
A
Any
official
process
yet
for
for
figuring
out
who
the
cichlids
are
and
and
I
did
talk
to
Tim,
Sinclair
and-
and
he
was
amenable
to
me-
stepping
down
and
having
Bobby
replaced
me,
but
we
both
felt
like
we
should
discuss
it
at
the
meeting
and
if
ash
is
also
interested
like
Michael,
said
I,
don't
think,
there's
any
reason.
We
can't
have
three
three
leads,
so
maybe
we
should
just
get
feedback
from
the
folks
who
are
on
the
call
right
now.
A
B
A
And
I
know
that
also
one
of
the
things,
one
of
the
reasons
why
there
isn't
a
procedure
yet
for
replacing
sig
leads
is
I,
think
that
Joe
Beda
and
maybe
some
others
were
interested
in
trying
to
define
I
sorry,
this
weird
echo
over
there
trying
to
define
multiple
roles
like
someone
would
be
kind
of
the
administrative
lead
of
the
sig.
G
I,
just
on
that
I
think
Tim
can
touch
upon
this.
We
talked
about
that
yesterday,
a
little
bit
in
the
steering
committee
meeting
and
the
idea,
if
there
being
a
consistent
set
of
roles
that
you
could
apply
across
all
the
SIG's
is
somewhat
challenging.
Given
the
divergent
nature
of
a
lot
of
SIG's,
the
one
thing
that
was
going
to
come
out
I
believe
soon
was
filled
with
rock
and
Joe
we're
working
on
a
survey
that
would
send
out
to
SIG's
about
how
they
do
basic
procedures.
So
we
can
kind
of
crowdsource
ideas
on
water.
G
If
anything
we
want
to
formalize
and
practically
from
my
perspective,
I
think
it's
up
to
the
state
to
decide
a
little
bit
right
now
and
how
they
want
to
handle
leadership.
I
think
from
I
by
I,
don't
know
how
anyone
else
feel,
but
I
feel
like
just
a
a
note
to
the
mailing
list.
Describing
you
know
the
change
of
situation
for
you
David
and
then,
like
a
lazy
consensus
approach,
seems
seems
fair
right,
I,
don't
think
this
has
happened
very
often
I'm,
not
aware
of
other
SIG's
that
have
transitioned
much.
A
A
A
E
A
Yeah
that
makes
sense
that
makes
sense.
Okay,
so
the
other
items
on
the
agenda
were
there
was
some
interest
in
talking
about
resource
class
and
priority
for
in
in
in
Reese
quota
I
think.
Originally,
there
was
some
confusion
about
which
one
people
want
to
talk
about,
but
then
the
consensus
was
actually
people
wanted
to
talk
about
both.
So
let's
do
resource
class
first
because,
like
I,
think
that's
mostly
been
in
the
in
the
resource
management
working
group.
A
G
I
think
this
can
be
a
quick
conversation,
so
resource
class
was
a
concept
that
came
out
of
our
face-to-face
last
year.
Red
Hat
did
go
in
prototype
it
so
because
Chowdhury
did
a
nice
prototype
with
a
mesh
I
think
did
bias
time.
I
think
we've
all
in
in
the
end
of
your
resource,
magic
work,
work,
meaning
we
all
agreed
to
defer
further
discussion
of
resource
class
host
cube
110
in
favor
of
dedicating
our
energies
on
graduating.
The
things
we've
already
started.
G
A
G
More
consensus
in
that
group
that
you
know
not
to
push
it
right
now
and
FS.
There
has
been
interest
from
other
members
of
the
community
I
think
some
folks
from
eBay
had
discussed,
wanting
to
potentially
explore
the
prototype
that
was
done
to
see
what
they
could
do
with
heterogeneous
devices,
but
like
pretty
clearly
in
the
other
group
where
this
came
out
of,
we
had
agreed
to
defer
it
for
the
time
being
so
I
to
me,
the
more
pressing
concept
we
can
talk
through
needs
is
the
priority
attention.
Yeah.
A
E
There
was
just
traffic
on
the
community
stuff
and
in
looking
through
it,
there's
a
bunch
of
pitfalls
that
were
associated
with
doing
that.
But
if
no
one's
pushing
it,
then
let's
just
content
differ
because
priority
is
the
highest
priority.
Preemption
are
the
high
priority
things
that
we
should
be
focusing
on
great.
A
A
Like
nobody,
I
just
want
to
make
sure
we
give
space
for
people
who
might
disagree
with
this.
What
we're
saying
but
I,
don't
hear
anyone
disagreeing
if
somebody
does
feel
strongly
about
the
resource
class
thing.
The
issue
number
is
782
in
the
community
repo
and
feel
free
to
ping.
That
and
say
you
have
some
that
I.
G
G
I
guess,
from
my
perspective,
I
want
to
be
able
to
see
a
priority
and
preemption
graduate
to
beta
and
at
least
for
the
use
cases
at
Red
Hat
that
we've
explored
and
I
can't
know
for
the
other
community
members.
I
guess
I'd
be
curious.
What
my
perspective
is
the
major
thing
I
need
to
be
able
to
do
is
have
a
way
of
default,
denying
usage
of
a
particular
priority
in
a
particular
namespace
or
a
set
of
namespaces,
and
so
the
first
route
that
we've
gone
to
try
to
pursue.
G
That
is
using
quota
mechanisms
to
do
that.
It
may
turn
out
that
that's
not
necessarily
the
the
best
way
of
doing
it
but
like
if
we
had
a
means
to
default,
deny
or
restore
usage
of
a
priority
to
a
particular
set
of
namespaces
or
outside
of
the
quota
system.
I
would
have
no
concerns
with
priority
and
preemption
graduating,
so
I
did
at
a
later
time.
We
wanted
to
quota
those
priority
bans
separately.
G
I
think
we
could
do
that
after
the
fact
to
be
honest,
but
I
don't
have
a
strong
use
case
need
to
for
our
users.
Right
now
to
say,
I
gave
you
this
much
quota
at
this
much
priority.
My
more
immediate
need
is
I
need
the
equivalent
of
critical
pod
annotations
to
be
satisfiable
via
priority
that
can't
be
abused
by
our
end
users
and
having
some
way
of
having
a
default,
deny
yes/no
in
a
namespace.
It
would
be
completely
sufficient,
so
it.
A
Seems
to
me,
like
the
cleaner
way
of
doing
it,
is
to
make
it
part
of
priority
to
make
it
part
of
quota
I'm,
not
saying
it's
the
only
way
to
do
it,
but
I'm
just
curious.
Why
why
you
think
that
it
shouldn't
be
done
as
part
of
quota?
In
other
words,
like
I,
know,
I
quote,
if
you
don't
just
submit
just
to
make
sure
people
other
people
on
the
call
understand
what
the
this
alternate
is
like.
A
G
To
be
clear,
the
design
that's
been
iterated
on
I
think
is
pretty
close
to
this
last
set
of
comments
that
were
from
me
that
gave
him
a
way
to
do
it
via
quota
and
in
fact,
at
Red,
Hat,
veikkaus,
Chowdhury
had
gone
in
prototyped
and
I
think
he
was
reaching
out
to
Harry
explaining
the
outcomes
of
that
prototype.
The
issue
is
like
Tim
had
introduced
some
concern
that
you
know.
Maybe
this
was
a
step
too
far.
G
I
think
Klaus
did
the
same,
but
if
the
goal
of
the
community
is
to
be
able
to
graduate
it,
I
just
want
to
make
clear
that,
like
from
my
standpoint,
the
graduation
criteria
is
just
the
ability
to
default
and
I.
Admittedly,
right
now
default,
deny
via
quota
is
a
bit
cumbersome
because,
like
the
default
is
you
have
everything
and
so
that
that
might
make
it
cumbersome
or
awkward.
G
Only
in
like
your
cube
system,
namespace
area,
overt
shift,
infer
namespace
so
like
if
we
can
get
a
priority
preemption
to
being
equivalent
to
the
critical
potti
notation,
then
like
that
to
me,
is
enough
of
a
success
to
support
it
going
to
beta
whether
or
not
you
do
quota
around
it
or
quota
priority.
I
think
that
that
can
come
later
honestly.
I
can.
D
G
The
other
idea
that
Clayton
and
I
batted
around
a
little
bit
is
like
we
have
mutating
web
hooks
in
validating
web
hooks
that
were
added
in
coupon
9
like
if
we
were
to
pursue
a
solution
that
was
like
being
able
to
deploy
a
web
hook
to
a
cluster
that
couldn't
respect
that
config
to
say
whether
or
not
this
namespace
was
allowed
to
use
that
priority.
That
would
be
fine
as
well
I.
Just
couldn't
I
can
appreciate
classes
concerns
about.
He
thinks
it's
stepping
on
some
other
work
and
yeah
I.
G
Don't
want
us
to
have
to
iterate
on
this
item
too
much
if
it's
getting
community
trepidation
and
to
be
frank,
everything
that's
there
is
pretty
close,
as
you
know,
Bala
to
like
me
being
slow
to
figure
out
where
it
should
get
to
so
I'm
someway
arguing
against
my
own
comments
and
I'm,
but
like
veikkaus
did
prototype
it
does
work,
it
would
meet
our
needs,
but
it's
it's
not
the
only
way
to
meet
our
needs.
He.
G
A
D
G
G
That
was
configurable
and
what
because
hit
admit,
but
either
way
the
point
being
like
is
the
need
to
quote
a
priority
super
high
for
you
guys,
or
do
you
have
a
similar
need,
which
is
you
want
to
protect?
What's
in
your
cube
system,
namespace
well,.
D
G
But
maybe
will
have
clear
use
cases
that
drive
that
requirement.
I
guess
is
my
thought
like
right
now
it's
a
bit
speculative
on,
like
like
I,
don't
have
an
end
user.
That's
asking
for
my
operators
only
get
five
pods
at
cluster
service
priority,
or
something
like
that,
like
it's
more
like
I,
want
to
be
able
to
satisfy
what
critical
pod
annotations
provide
using
this
new
tool
and
like
when
our
various
customers
can
then
start
exploiting
priority
and
preemption
a
lot
further.
Maybe
we
get
a
clearer
input
signal
on
what
the
right
next
is.
Yeah.
A
G
C
D
D
C
G
You
know
that
you
do
some
other
pattern
we
explore,
which
has
a
new
priority
configuration
resource
and
not
just
like
on
the
priority
entity
itself,
and
then
a
third
option
would
be.
We
do
some
pattern
that
matches
annotations
on
a
namespace,
but
that's
that's
that's
something
we
can
wrestle
with
or
think
through.
It's
just
where
I
was
today
when
I
was
trying
to
think
about
you
know:
what's
the
minimum,
we
can
do
to
make
me
comfortable,
deploying
priority
in
production.
D
Annotations
is
somewhat
similar
to
to
like
having
an
external
extra
field
in
namespace,
but
it's
oh
I,
don't
know
anyway,
it
might
be
a
little
cleaner
and
it
may
be
easier
to
get
rid
of
if
we
decided
in
the
future
that
we
don't
want
to
go
this
path.
Therefore,
I
don't
know
how
exactly
it's
gonna
work.
It's
like
limiting
the
priority.
To
sum
up
in
the
namespaces
I
feel
like.
D
A
That's
a
little
more
radical,
but
that
might
be
the
direction
to
move
because
I
think
I,
don't
know
your
experience
Derek
if
you've
worked
with
the
quotas
stuff
a
lot
more
than
than
anyone
else
on.
This
call,
but
like
I,
think
the
feeling
I've
gotten
from
people
is
that,
like
it
probably
never
should
have
been
her
namespace
and
that
making
it
global
would
be
a
lot
simpler.
G
C
G
Users
have
been
trained
a
little
differently,
I
think
what
I
apprehensive
on
your
on
your
suggestion,
David
a
little
bit.
It's
like
I,
if
I
would
like
to
find
the
minimum
solution
needed
to
just
satisfy
a
default
in
high
criteria
that
doesn't
slow
priority
preemption
from
being
more
broadly
available
and
like
radical
redesigns
of
quota
are
not
something
that
facilitates
that
to
be
honest
and
we
get
a
lot
of
value.
A
And
also
like,
we
have
also
talked
about
like
trying
to
talk
to
you
guys
about
up
streaming.
The
project
request
template
stuff
so
that
you
could
have
to
do
what
you're
talking
about
more
simply,
and
that
would
be
another
another
approach
that
would
that
wouldn't
require
making
a
quota
be
global
anyway.
Sorry,
maybe
I
should
have
brought
up
any
of
this
and.
G
And
there
are
other
constraints
that
you
might
be
brushing
over
with
global
quota,
that
it
becomes
a
shared
locking
problem
and
it
it
only
works
appropriately.
If
you
have
about
a
hundred
namespaces
in
a
covering
quota,
we've
had
some
that's
like
our
scaling
of
appreciation
on
that.
So
well
there.
What
is
difficult.
G
Yeah
so
Bobby,
how
about
this?
Like?
Let's
proceed
as
far
as
like,
we
can
talk
a
little
more
on
the
issue.
I'd
like
to
nominate
a
veg
to
you,
know
kind
of
be
my
proxy
here
a
little
bit
and
if
you
were
talking
about
a
shepherding
model
handling
the
default
deny
on
priority.
Preemption
I
would
be
happy
to
make
him
be
that
voice
and
across
the
three
of
us.
We
can
iterate
on
that
in
the
next
week,
but
like
the
the
smallest
solution
that
satisfies
my
need
as
I'm
I'm,
okay
with
and.