►
From YouTube: Kubernetes SIG Node 20230523
Description
SIG Node weekly meeting. Agenda and notes: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.adoto8roitwq
GMT20230523-170602_Recording_1434x1020.mp4
A
Hello:
everybody,
it's
Tuesday,
May,
23
2023.
It's
a
weekly
signal
signal
meeting
welcome
everybody.
A
A
A
You
can
read
more
about
what
changes
are
there?
Okay,
now
Francesca.
B
Yes,
my
fault
yeah,
exactly
this
is
the,
and
this
is
the
the
planet
work
for
128..
So
this
we
want
to
this.
This
we
want
to
make
forward
from
Nvidia
volunteer
to
move
this
forward
to
the
second
one.
Third,
three,
five,
four
five
and
the
sign
himself
on
them.
128
document
and
the
other
one
is
what
I
would
like
to
do
in
28,
which
is
again
to
you
know
avoid
permabetas.
B
A
So
for
this
to
do
you
plan
to
send
the
so
you
want
this
in
Milestone,
but
you
also
will
want
to
send
a
PR
that
changes.
Cap,
yaml
right.
B
B
A
So,
let's
make
sure
that
we
have
metadata
up
to
date
anyway,
absolutely.
D
Yeah,
so
we
discussed
this
item
earlier
this
year
about
no
resource
topology
API.
At
that
time
we
were
posing
this
API
as
part
of
staging
repo,
so
after
API
review
process,
Jordan
recommended
that
it
makes
sense
to
have
this
under
kubernetes
set
as
opposed
to
staging,
and
because
this
is
a
crd
based
API,
it
makes
us
to
have
the
ability
to
you
know,
be
more
flexible
and
not
be
impacted
by
kubernetes
slow
release
clearance.
So
you
recommend
it
to
propose
this
and
have
this
under
kubernetes.
D
So
this
is
me
kind
of
trying
to
see
what
everyone
thinks
about
this.
If
it
makes
sense
or
is
there
any
objections
or
concerns.
D
Sure
yeah,
so
this
back
in
time,
we
were
working
on
topology,
aware
scheduling
and
what
this
API
does
is
it's
just
it's
a
per
node
based
API,
it's
a
crd
base
API
and
it
allows
us
to
expose
granular
information
about
resources
on
a
node.
D
So
the
primary
use
case
for
this
was
that
we
want
to
expose
available
resources,
capacity
of
resources
on
a
poor,
no
one
pneumonode
basis
and
that
could
be
used
by
a
scheduler
plugin
to
make
Numa
where
placement
decision,
as
we've
progressed
with
this
API
and
we've
had
discussions
in
the
community,
we've
realized
that
pneuma,
where
scandaling
or
topology
wire
scheduling,
is
not
the
only
use
case,
and
there
are
other
components
that
could
be
using
this
API
as
well.
D
We
had
discussion
with
the
Intel,
primarily
Sasha,
and
he
discussed
about
using
this,
for
Dra
controllers,
for
example,
as
opposed
to
you
know
scale
up
against
so
so
I
think
in
general
this
could
be
a
nice
API
that
as
a
community,
we
could
collaborate
on
and
that's
why
we
have
this
API
under
a
very
specific
GitHub
organization,
where
mostly
Red
Hat
has
been
contributing
to
it.
So
This
Is
Us
trying
to
bring
it
under
kubernetes
umbrella.
E
A
E
A
D
F
It's
me
sorry
just
wanted
to
give
a
quick
intro.
My
name
is
Andrew
stoikis
I'm,
mostly
active
in
Sig
Network,
so
I've
actually
never
been
here
before,
but
more
recently,
I've
been
along
with
a
group
of
other
folks.
Looking
at
you
know
how
evpf
applies
to
kubernetes
in
an
upstream
sense
and
coming
out
of
that
as
a
project
started
in
Red
Hat
emerging
Tech
and
has
moved
into
its
own
organization,
recently
kind
of
regarding
the
orchestration
and
management
of
evpf
as
a
technology
in
kubernetes.
F
This
Project's
called
bpfd
and
I
just
wanted
to
come
and
kind
of,
introduce
myself
introduce
the
project
and
kind
of
ask
if
you
all
would
be
interested
in
hearing
a
short
demo
of
it.
I
didn't
want
to
just
barge
in
here
and
do
a
demo
analysis
saw
that
there
was
a
bunch
on
the
agenda,
so
it
went
way
faster
than
I
thought.
It
would,
but
essentially
our
plan
has
been
we're
kind
of
presenting
it
to
a
few
sigs,
because
many
of
you
might
be
familiar
with
evpf
as
a
technology.
F
It
kind
of
spans
the
whole
ecosystem
right,
it's
applicable,
to
see
node
Sig
security
and
Sig
Network,
we've
already
presented
to
six
Network
and
we're
just
continuing
kind
of
going
through
the
presentation
cycle.
So
if
there's
no
one
who
disagrees
I'd
like
to
come
back
next
week
and
give
kind
of
a
15
to
20
minute
presentation,
a
demo
on
this
project.
C
Yeah
so
sounds
great
Andrew
yeah.
We
look
forward
to
it
and
I
think.
One
thing
that
may
be
useful
Andrew
is
highlighting
possible
use
cases
for
signode
right.
Okay,
these
are
the
use
cases
where
you
know
we
can
and
integration
points
but
I'm
getting
ahead.
F
No,
no,
no,
that's
really
good
feedback
and
that's
what
we
tried
to
do
with
Signet
right
like
this.
This
is
kind
of
a
a
thing
where
Tim
Hawkins
said
like
we
in
cases
before
we
haven't
and
kubernetes
kind
of
laid
out
how
we
think
technology
should
be
used
in
our
ecosystem,
but
he
at
least
felt
like
for
eapf.
We
should
right,
like
we
today,
deploying
basically
the
sort
of
it
deploying
UPF
and
kubernetes
is
kind
of
not
simple.
F
It's
it's
full
of
pain
points
and
with
the
proliferation
of
the
technology,
it's
led
to
a
lot
of
conflicts
and
troubles.
So
I'll
try
to
to
skew
our
presentation
directly
for
signode
and
I'll,
give
that
next
Tuesday,
if
everyone's
cool
with
it
so
definitely
but
in
the
meantime,
feel
free
to
Ping
us
with
questions.
We
have
two
slack
channels,
we're
really
active
in
evpf
or
bpfd
and
KU
ready
slack.
F
So,
if
you're
looking
before
the
presentation
have
questions,
please
reach
out
we're
happy
to
help
with
questions
all
the
way
from
what
is
evpf
as
a
technology
to.
Why
should
we
care
about
it
in
kubernetes,
so
yeah?
That's
all
I
got.
Thank
you.
A
Thank
you
with
that.
We
get
now
to
the
end
of
the
agenda.
It
was
surprisingly
fast
today,
so
maybe
we
will
get
some
time
back
for
reviews,
I
really
hope
more
people
reviewing
and
approving.
Thank
you.