►
From YouTube: 20201119 SIG Arch Community Meeting
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
Hello,
everybody:
this
is
the
community's
link
architecture,
community
meeting
for
or
whatever
the
day
it
is
today
november.
19Th,
2020
and
we've
just
got
a.
A
Attendance
problems
so
we'll
see
if
we're
able
to
handle
these
items
swat.
No,
we
did
not
hear
you
okay.
So
the
first
item
is
alternative
platform
discussions.
You
don't
see
dims
here.
A
The
yeah,
I'm
not
sure
what
we
wanted
to
talk
about
about
it
on
the
agenda,
because
to
me
we
made
some
comments
and
I
think
it
needs
some
changes
before
it
emerges,
as
I
mentioned
here
and
derek
looks
like
you're
on
the
same
page
there
as
far
as
this
step,
four,
was
this
really
something
that
we
need
to
put
in
here
yeah?
So
my.
C
Concern
on
the
pr
was
step,
one
seemed
burdensome
and
didn't
have
a
clear
tie
to
the
release
process,
which
was
the
bazel
requirement.
C
Step
four
seemed
outside
the
scope
of
needed
success
criteria,
which
was
basically
what
I
thought
you
captured
as
well.
What
was
not
clear
to
man,
I
was
hoping
we
could
get
an
understanding.
This
call
is
like
of
the
existing
architectures,
which
met
the
proposed
rules
of
the
game,
so
I
tried
to
reach
out
to
some
individuals.
I
saw
cindy
commented
around
s390,
but
I
wasn't
sure
for
arm
or
power
if
we
could
get
like
a
clear
ack
on
either
what
the
missing
steps
were
or
or
that
type
of
thing.
A
Okay,
well,
it
doesn't
seem
like
we
have
the
right
folks
on
the
call
either.
So
it
looks
like
recent
comments,
we'll
see
where
that
goes.
I
agree.
I'm
not
sure
that
it's
not
clear
to
me
why
basil
would
be
strictly
necessary,
but
not
knowing
the
build
and
release
process
as
well.
Maybe
I
should
you
know
that
yeah
well,
as
was
a
whole
other
topic,
I
don't
want
to
necessarily
okay,
then
looks
like
you
made
your
comments
and
we'll
just
we'll
just
go.
C
A
A
There
was
there
was
we
want
to
create
this
api
as
a
crd
for
experimentation
purposes,
but
there
was
a
discussion
at
least
that
that
would
that
was
going
to
require
something
in
kk
to
rely
on
that
crd
for
the
scheduler
plug-in,
it
sounds
like
there's
an
option
to
do
that:
scheduler
plug-in
as
an
external
or
do
an
external
scheduler
all
together.
What
where
do
we
stand
on
this
and
I
know
derek
you
had
some
questions
around
whether
the
status
of
the
cap
as
well.
C
Now
that
we're
recording
for
those
who
weren't
here
of
the
process,
because
the
pod
resource
api
kept
merged
and
was,
I
would
say,
70
implemented
in
120-
and
that
was
a
prereq
to
kind
of
do
the
other
items
that
were
discussed
here.
I
wasn't
aware
of
an
actual
cap
that
had
merged
describing
the
api,
and
so
I
thought
requesting
the
repo
might
have
been
getting
ahead
of
the
process
a
bit.
C
But
if
we
want
to
talk
about
the
abstract
on,
should
the
scheduler
support
out
of
tree
plugins,
or
should
these
types
of
optional
things
get
handled
a
certain
way?
I
think
we
can,
but
I
just
want
to
make
sure
that,
like
I
wasn't
missing
something
or
forgetting.
C
D
D
Yes,
okay,
so
we
had
in
the
cap,
we
had
two
gaps
for
topology,
aware
scheduling
in
one
of
the
gaps
we
had
kind
of
explained
that
we
would
have
this
topology
no
resource
body
api
and
initially
we
had
mentioned
that
we
have
this
in
in
nfd.
D
But
then,
when
we
had
conversations
with
entertainment,
they
said
that
it
would
lead
to
kind
of
circular
dependencies
because
nfd
imports,
kubernetes
and
then
the
scheduler
plug-in
would
need
to
import
nfd
and
eventually
entertain
the
circular
dependencies
so
the
process.
So
we
came
to
the
conclusion
that
the
only
viable
option
for
us
is
to
places
place
it
in
staging.
D
So
that's
where
the
process
of
creating
the
staging
repository
started.
Hearing
from
what
you're
saying
it
seems
that
you're
expecting
another
cap
to
describe
the
topology
api
itself.
C
Right,
like
I,
wouldn't
have
expected
code
to
go
into
the
core
kk
tree
or
korg
repo
for
the
api
without
having
a
clear
cap
describing
it-
and
I
think,
maybe
earlier
discussions
had
this
treated
as
a
a
kind
of
x-case
io
like
extended
api
and
had
some
optionality,
but
I
think,
given
what
the
the
natural
course
of
events
you're
describing
around
circular
dependency
and
stuff.
That
means
like
I
would
have
expected
a
at
least
it
kept
describing
the
api,
and
then
we
could
have
the
crd
or
not
crd
discussion.
D
E
On
the
one
hand,
it
sounded
like
this
is
like
experimental,
optional,
we're,
not
sure
if
it's
gonna,
you
know,
proceed
and
graduate
like
we're
just
trying
to
get
initial
proof
of
concept
and
experimental
stuff
in,
but
on
the
other
hand,
it's
wanting
to
merge
like
apis
into
core
repo,
and
so
I,
like,
I
understand
the
circular
dependency
thing.
I
I
think
that
actually
is
sort
of
a
gap
in
the
scheduler.
If
the
only
way
we
can
experiment
with.
E
E
D
I
believe
we
still
do.
We
still
have
the
ability
to
run
it
as
an
out
of
three
scheduler
plugin,
but
the
reason
we
were
trying
to
do
it
as
an
entry
plug-in
is
because
topology
manager
itself
has
introduced
a
few
gaps
that
is
leading
to
topology
on
where
scheduling
and
we
were
trying
to
address
that.
So
that's
the
reason
we
wanted
to
propose
it
as
an
entry
plug-in
if
it
makes
everyone
more
comfortable
with
like
an
out-of-tree
scheduler
plug-in
prior
to
having
it
entry.
D
We
are
we're
okay
to
do
that
as
well.
I
think
I
mentioned
it
as
one
of
the
options
when
we
were
speaking
about
the
possible
options
of
kind
of
moving
ahead
with
this
project.
E
Okay,
I
missed
that
that
was
an
option
I
think.
Just
in
terms
of
velocity,
you
would
certainly
be
able
to
experiment
a
lot
faster
running
it
out
of
tree
like
in
the
time
that
it's
taken
to
sort
of
work
through
the
circular
dependency
stuff,
and
now
that
120
is
frozen,
and
I
mean
just
in
terms
of
velocity
you'll
be
able
to
go
more
quickly.
E
If
you
run
something
out
of
tree
and
say,
run
this
scheduler
and
load
this
x,
kids,
crd
and
play
with
it
and
let
us
know-
and
then
we
can
rev
that
rapidly
once
that's
proven
out
like
once,
there's
it's
clear
that
it's
widely
used
enough
and
proven
out
enough
and
performs
well
enough
and
all
of
those
things
to
sort
of
justify
being
brought
in
as
an
entry
thing
like
that.
E
I
think
that's
a
reasonable
conversation
to
have,
but
I
think
it
would
benefit
you
in
terms
of
velocity
and
it
would
just
make
it
a
lot.
There'd
be
a
lot
fewer
people
involved
in
the
discussion.
If
you
just
ran
it
out
a
tree
and
proofed
it
out.
So
that's.
E
To
do
for
like
auth
and
policy
stuff
like
prove
it
out
as
a
web
hook
like
the
shape
of
the
api.
E
A
I
think
the
the
issue,
though,
that
I'm
hearing
is
that
we've
introduced
with
topology
manager
a
situation
where
no,
where
workloads
are
not
scheduled
or
they're,
scheduled
to.
A
Is
intriguing,
we're
saying
so
we're
not
offering
any
solution
to
a
problem
we
created,
which
I
mean
that
may
be
fine,
because
it's
temporary
right,
but
I
think
it
does
make
sense
that
if
we've
got
something
in
tree,
that's
causing
this
gap,
we
would
eventually
want
to
solve
that
entry
as
well.
E
Yeah
I
know
tim
has
been
more
involved
in
the
topology
stuff.
What
is
is
topology
manager,
alpha
beta,
where.
F
F
B
G
C
So
topology
manager,
the
idea
of
the
cubelet
being
able
to
align
a
device
and
a
cpu,
and
hopefully
in
the
future
memory
to
be
on
a
common
pneuma
node
aka
like
the
intro
node
topology.
C
That
feature
is
beta
now
and
so
to
your
comment,
john
on
there's
a
way
to
configure
the
cubelet
where
the
cubelet
tries
to
align
things
and
the
policy
you
can
assign
to
the
keyboard
to
align
things
that
the
clusterwide
scheduler
may
not
be
aware
of
is
true.
C
The
impact
of
that
is,
you
know,
and
the
ways
to
react
to
that
or
you
know,
there's
a
lot
of
ways
to
make
that
not
a
problem.
I
guess,
but
I
I
for
the
broader
statement
of
like.
Would
we
want
the
scheduler
to
be
aware
of
it
or
not?
C
Like
that's
the
thing
that
I
would
just
expect
to
have
settled
in
the
kep
and
personally,
I
have
no
objection
to
the
entry
scheduler
being
aware
of
what
the
cubit
was
doing
internally
necessarily,
but
we
just
didn't
have
that
clear
cap
to
point
to
that
says
it
was
merged,
but
absent
that
I'd
agree
with
jordan,
that
we
can
continue
to
innovate,
either
out
a
tree
with
a
custom,
scheduler
or
help.
The
scheduler
component
today
support
the
types
of
plug-ins.
A
When
you
talk
about
a
cap
like
do
we
need
a,
I
don't,
I
think,
sweat
swattie
mentioned
a
new
cap.
Do
we
need
a
new
couple?
We
just
need
to
add
to
an
existing.
Is
there
an
existing
cap
that
this
would
fall
under?
That
can
be
enhanced
to
include
this
this
api
and
then,
and
then
I
guess
tim.
If
you
have
some
things
to
say,
you're
welcome
to
jump
in
yeah
but
derek.
Are
you
more
familiar,
you're
more
familiar
with
these
caps?
I
don't
even.
C
Yeah
yeah,
all
I'm
saying
is
I
I
had
tried
to
look
into
prior
to
coming
to
this
meeting
was:
was
there
a
kep
that
clearly
said?
This
is
the
api.
These
are
the
fields
on
it
and
this
is
where
it
should
go,
because
some
of
the
questions
we're
debating
now,
I
thought,
would
have
been
debated
in
a
cap
and
there
I
found
two,
maybe
open
caps
that
we
could
consolidate,
but
neither
of
which
had
been
merged
and
some
of
the
prerequisite
building
blocks
that
this
feature
said
that
they
would
depend
on.
D
Yeah
one
of
the
key
part
of
the
cap,
we're
capturing
in
the
cap,
is
where
we
want
this
topology
api
to
sit
like
at
this
stage.
One
of
the
caps
says
that
it's
going
to
be
in
staging,
but
it
seems
like
we
need
to
have
things
in
staging
for
the
cap
to
get
accepted,
maybe
just
kind
of
lack
of
knowledge
on
my
part
or
our
part
in
general
to
understand
kind
of
the
process.
D
We
had
discussion
in
signored
as
well
explaining
why
we
want
this
in
staging
because,
like
I
explained
that
nfd
would
lead
to
circular
dependencies,
we
also
considered
external
repo,
which
would
have
similar
similar
issues,
and
then
that
left
us
just
the
only
option
of
having
it
staging
when
we
were
just
assuming
that
the
scheduler
plug-in
would
be
entry.
This
the
out
of
tree
discussions,
kind
of
started
after
that.
So.
E
The
the
idea
we
have
a
thing
in
tree
to
I
don't
know
fix
a
fix.
A
problem
or
sort
of
complete
a
solution
for
around
topology
would
be
stronger
if
the
plan
was
for
that
to
be
enabled
by
default,
but
I
thought
that
this
some
of
the
comments
were
saying
this
would
be
an
optional
thing.
Yes,
we
can
hear
you
tim,
I'm
just
talking
over
you.
I'm
sorry.
H
Okay,
I
I
want
to
I
want
to
express
support
for
the
idea
here
now.
I'm
going
to
assume
that,
like
the
research
project,
part
of
this
is
either
been
done
or
is
being
done
to
prove
that
such
a
thing
is
useful
and
and
and
efficacious,
and
given
that
I
feel
like
understanding
topology
at
this
level
is
a
reasonable
thing
for
kubernetes
to
internalize
and
for
the
default
scheduler
to
understand
and
for
on
node
agents,
whether
that's
cubelet
or
something
else,
to
help
populate
information
about
so
in
general.
H
I
I'm
supportive
of
that.
I
don't
know
if
all
that
homework
has
been
done,
and
I
don't
know
if
the
exploratory
part
of
like
are
there
better
options
with
respect
to
where
the
api
should
live?
That's
when
I,
when
I
opened
a
the
discussion
about
topology
api,
I
was
looking
at
it
purely
from
an
api
point
of
view
and
as
somebody
who's
got
some
background
with
the
hardware
side
of
pneuma,
not
from
a
like,
did
you
do
the
research
point
of
view?
Did
you
do
the
research.
D
Well,
I
would
say
from
the
proof
of
concept
point
of
view
like
in
terms
of
how
the
topology
should
be
exposed
and
having
the
end-to-end
solution
work
like
exposing
the
crds
and
then
the
scheduler
plug-in
using
those
crds
to
make
the
scheduling
decision
we
have.
We
have
it
working
and
like.
Is
there
anything
else
that
you're
trying
to
get
to
in
this
question.
C
Maybe
just
make
sure
that
tim,
obviously
the
capability
in
the
cubelet
to
align
devices
with
their
resources
and
their
memory
with
their
cpus
that
that
is
working
well
and
people
are
successful
with
that
today
and
it
had
no
impact
to
the
end
user
api
right.
It
was
a
policy
block
right.
C
The
research
here
that
had
been
presented
was
basically
still
having
no
end
user
impact
to
the
pod
api,
but
having
an
api
to
advertise
back
to
the
scheduler.
What
the
nodes,
concrete,
no
local
scheduling
decisions
were
and
the
feedback
loop
on
where
and
how
to
make
that
known
is
kind
of
the
tension
point
here
and
but
from
like
the
earliest
discussions
that
recall
you
and
I
had
on
this-
like
there
is
no
impact-
the
end
user
pod
api.
C
This
was
all
internal
finding
the
right
communication
vehicle
between
how
the
cubelet
says,
what
its
concrete
resource
assignments
were
and
making
the
scheduler
then
aware
of
that,
and
the
prerequisite
where
that
was
this
pod
resource
api,
that
advertised
from
the
cubelet
from
a
grpc
endpoint.
That
says
these
are
the
pods
running.
These
are
the
cpus
that's
assigned,
and
this
is
the
devices
it's
consuming,
that
got
done
as
a
part
of
the
gpu
enablement
work,
and
that
was
the
building
block
that
was
being
enriched
in
120
injury.
B
B
To
mention
about
another
soft
apology:
api,
if
you
already
took
a
look,
it
looks
too
generic.
B
Initially
it
was
only
about
normal
nodes,
but
now
it
could
support
a
wide
range
of
devices
by
a
range
of
different
types,
for
example
hyper
trading,
siblings
and
so
on
and
internally
we
have
an
extension
for
cpu
manager
which
support
hyper
trading
and
current,
not
resource
topology
api,
which
was
in
the
pr
current,
also
supported.
I
could
support
it
without
any
modification,
so
it
generates
enough
for
any
fuser
modifications.
H
So
the
just
just
typing
the
question
I
have
is:
do
we
have
sufficient
evidence
that
this
level
of
integration
is
actually
a
good
solution
for
whatever
the
important
problem
statements
are.
H
H
C
Sorry
go
ahead.
Yeah.
I
just
wanted
to
focus
the
problem
statement,
so
I
do
not
believe
the
problem
statement
is.
I
want
my
pod
to
be
co-located
with
my
cpu
and
memory
and
device
as
efficiently
as
possible.
I
don't
think
that
problem
statement
is
up
for
debate,
because
that
that
work
has
been
done,
as
is
helping
people
today
in
cube,
as
it
is
today
running
all
sorts
of
workloads.
C
The
the
second
order
problem
statement
is,
I
want
to
ensure
that
the
scheduler
schedules,
my
pod
two
nodes,
whose
policy
will
fit
the
desired
semantics.
I
wanted
of
alignment
the
I
think
from
what
I've
seen
in
saudi
and
alexi's
work
that
it
does
minimize
miss
scheduling
problems.
The
impact
of
that
missed
scheduling
problem,
of
course,
is
how
much
users
pre-plan
their
hardware
deployment
and.
H
I
I
believe
that
I
guess
I'm
looking
for
a
definition
of
like
what
is
how
do
we
know
that
this
was
successful?
Is
there
a
is
there
a
metric
or
some
threshold
of
anecdotes
or
or
something
that
says
like
yeah?
This
is
actually
worth
the
the
effort
and
I
guess
to
go
back
derek
to
the
question
you
asked
before.
Like
is:
is
there
a
cap
that
covers
this
overall.
H
Sorry,
I
was
gonna
say
if
somebody
could
show
me:
look:
we
have
dollar
user.
Who
has
these
special
requirements
and
25
percent
of
the
time
we
schedule
to
a
node
that
isn't
at
all
feasible
and
after
this
change
it's
only
two
percent
of
the
time
that
would
be
wonderful,
like
is
am
I
asking
for
something
unreasonable.
C
C
We
see
in
our
poc
pods
being
scheduled
at
a
rate
of
x
rather
than
y.
That
seems.
A
D
So
I
just
I
just
sent
a
link
to
you
all:
it's
basically,
it
ends
up
in
an
error,
it's
topology
affinity,
error
and
if
that
part
is
part
of
a
deployment
or
a
daemon
set,
it
just
keeps
creating
recreated
on
the
same
note,
because
the
scheduler
essentially
keeps
making
the
same
scheduling
decision
and
the
pod
just
it's
causes
a
series
of
runaway
pods.
H
So,
just
basically
that
that
so
that's
a
problem
that
we've
sort
of
known
about
for
a
long
time
like
is,
is
that
a
problem
worth
solving
on
its
own,
like
being
able
to
thread
two
different
pods
together
through
a
I,
don't
know
a
nonce
or
something
that
the
scheduler
says.
Oh
hey,
this
thing
failed
on
node
x,
I'm
not
going
to
put
it
on
node
x,
again,
like
that
seems
completely
independent
of
pneuma
or
topology,
or
anything
else.
D
D
Yeah,
the
the
reason
that
happens
is
because
the
scheduler
doesn't
have
the
granular
information
of
the
resources
available
at
a
new
node
level,
and
that's
that's
how
we
are
trying
to
look
at
this
problem
and
address
this
by
giving
it
the
visibility
and
that
information
to
make
more
topology
aware
decisions.
C
Yeah
so
tim,
I
think
the
question
is:
do
you
want
the
pod
to
remain
pending,
or
do
you
want
the
pod
to
loop
around
all
nodes
in
your
cluster
in
some
type
of
cycle,
but
that
that's
a
complete
piece
of
fair
feedback
and,
from
my
experience,
plenty
of
users
pre-plan
their
workloads
to
their
hardware,
for
the
scenarios
where
this
is
tackling,
but
not
all?
And
so.
H
Yeah,
that's
that's
fair.
I
I'm
in
the
back
of
my
mind,
there's
a
voice
that
says
there
are
going
to
be
other
reasons
besides
topology,
not
fitting
that
you
might
want
to
say,
don't
run
this
pod
on
this
note
anymore,
but
there's
no
there's
just
no
way
to
express
it
right.
I
don't
mean
to
sidetrack
and
and
take
this
idea
in
a
different
direction
like
like
I
said
before
I
I
am
supportive
of
the
idea
of
the
understanding
of
topology.
I
just
would
like
to
know
how
to
know
that
it
was
successful.
D
Sure
I
think
that
that
is
certainly
a
fair
question.
Maybe
we
need
to
do
a
bit
more
homework
to
have
those
those
metrics
kind
of
laid
out
in
front
of
you
to
show
the
benefit
of
this
feature
like
we.
We
have
the
prototype
working
and
everything
working,
and
we
know
it
works,
but
probably
that's
not
enough
to
kind
of
take
this
forward.
H
Yeah
I
mean
I
would
accept
even
as
a
as
a
result
like
a
model,
we
took
the
scheduler
code,
we
built
it
into
a
program
that,
had
you
know,
5
000,
virtual
nodes
with
different
topologies,
and
we
threw
what
we
think
is
a
representative
workload
at
the
model,
and
this
was
the
infeasible
scheduling
rate
before
the
change
and
here's
the
change.
Here's
the
rate
after
this
change
right
sure.
D
D
A
A
A
It
it
tickles
me
the
wrong
way
that
we
are
having
to
build
in
all
kinds
of
node
policy
like
no
topology
policy
information
into
the
scheduler
as
well,
and
what
next
type
of
use
cases
are
going
to
be
for
controlling
what
goes
on
the
node
and
where
and
then
we
have
to.
We
have
to
build
that
into
the
scheduler
too.
I
guess
we
have
plug-ins
for
that.
You
know,
but
it's
not.
I
don't
think
it's
it's
nothing
that
rises
it.
It's
it.
A
It's
a
level
of
coupling
between
the
two
that
that
sort
of
it
rubs
me
the
wrong
way,
but
I
can
understand
the
need
for
it
and
there's
gonna
be
some
of
it.
So
you
know
not
enough
for
me.
H
A
Yeah,
like
device
manager
to
handle
like
and
custom
resource
types
to
handle.
A
C
Yeah,
it's
a
little
more
complicated,
john,
maybe
so
tim's
right
that
we've
been
discussing
this
since
before
1.0,
and
there
were
a
lot
of
initial
attempts
to
say,
make
the
pod
spec.
Actually
like
no
topology
aware
and
give
preferences
to
a
bunch
of
stuff.
C
I
would
say
that
we've
reached
a
a
a
place,
maybe
a
couple
years
in
the
cube's
life,
where
we
said
that
the
cubelet
was
going
to
be
responsible
for
making
node
local
intranode
scheduling
decisions
and
the
scheduler
opaque
to
it,
and
over
the
last
I
don't
know,
10
releases
or
so
of
cube.
We've
evolved
that
right,
so
the
cube
got
smart
on
picking
cpus
or
the
cubelet
guts
assigned
devices,
and
then
topology
came
up
because
you're
like
well.
C
I
want
my
my
gpu
next
to
my
cpu
and
so
that
we
got
to
that
point
and
I
think
we've
reached
enough
of
a
path
where
both
components
were
able
to
evolve
in
ignorance
of
each
other,
that
this
is
the
last
thing
that
tries
to
bring
it
together.
But
I
think
we've
come
a
long
way
from
not
meaning
to
the
pod
spec,
to
your
comment
on
like
dependencies
between
scheduler
and
cubelet.
C
We
we
actually
have
a
few
that
are
somewhat
frustrating
because
the
the
cubelet
re-runs
the
predicates
before
admitting
the
pod
that
the
scheduler.
C
A
Okay,
yeah,
I
mean
perfect's
the
enemy
of
the
good
or
good
enough
right
or
whatever.
That
is
whatever
the
cliche
is.
Okay,
let's
see
what's
tim
saying
here.
H
A
All
right,
thank
you,
everybody
last
chance
for
comments.
Otherwise
we
get
back
20
minutes
or
so
all
right.
Thanks
so
much.