►
From YouTube: Multi-Network community sync for 20230607
Description
Multi-Network community sync for 20230607
C
Sure
so
I
do
wonder
about
this,
whether
there's
a
general
principle.
We've
got
some
things
we
need
in
this
area.
Should
we
leave
discussing
them
in
more
detail
until
later
and
come
back
on
this
I
wonder
whether
we're
getting
a
little
bit
derailed
by
this
one,
because
it's
very
interesting
and
there's
a
lot
of
good
technical
stuff
here,
but
yeah.
A
That's
why
I
agree
with
you
give
me
just
like
welcome
everyone.
I
want
to
kind
of
intro
welcome
every
other
multi-network
community.
Sync
today
is
June
7th
on
the
agenda.
I
want
to
touch
something
on
the
cap
that
we
currently
have
posted.
There
was
someone's
a
question
I'm,
not
sure
who
posted
that
one
and
then
finally
keep
talking
about
the
dra
integration
and
and
Pete.
Can
we
back
to
your
question
and
ask
when
we
get
there
yeah.
C
A
Yeah,
okay,
I'm
gonna,
be
quick.
I
got
feedback
about
the
cap
from
Team
and
one
main
recommendation
from
his
point
of
view
for
how
he
manages
the
caps
was.
He
didn't
really
felt
that
approach
where
we
would
have
a
cap
per
phase.
So
what
he's
proposing
is
to
just
convert
the
current
cap,
the
requirements
cap
that
we
posted
as
d-cap,
that
we
are
going
just
to
update
incrementally
so
the
change.
A
What
what
we're
going
to
happen
is
to
kind
of
not
mention
that
we
are
going
to
create
a
separate
cap
per
phase.
It's
just
to
keep
updating
the
cap.
So
basically
the
first
phase
is
just
the
story
and
requirements,
and
then
we
will
pause
the
phase,
one,
the
one
stuff
that
we
are
talking
about,
and
we
will
keep
updating
this
single
cap
about
all
those
things,
and
this
will
make
this
cap
of
course,
unfortunately
long
left,
maybe
fortunately
because
we
would
have
to
handle
like
the
versioning
of
the
apis
anyway.
A
We
cannot
like
go
to
GA
in
probably
next
year,
because
unless
we
will
have
the
full
confidence
around
this,
but
I'm
talking
about
the
apis
themselves
to
go
to
V1
unless
we
will
build
enough
confidence
to
say
yes,
let's,
let's
just
go
V1
and
from
that
point
on,
we
will
just
update
those
add
things
as
the
phases
goes.
So
that
was
one
kind
of
concern
from
his
side
about
the
apis
and
how
they?
A
C
C
Changes
actually
on
the
Node
to
go
and
Implement
these
networks.
I,
don't
know
if
there's
been
any
discussion
of
how
that
would
work,
where
my
assumption
is
that
there'll
be
a
change
equivalent
to
have
a
different
CRI
interface,
I'm
quite
happy
to
to
accept
this
has
been
discussed.
Yet,
let's
push
it
down
the
road
a
little
bit,
but
I
wanted
to
ask
if
it
had
been
covered
that.
A
C
A
A
C
C
A
C
A
Don't
think
we
do,
we
don't
I,
don't
see
any
Usual
Suspects,
so
Pete
you
mentioned
that
we
might,
it
might
slightly
derail
our
thing
it.
This
is
something
that
we
can
decide
today,
because
I
have
some
proposals
and
it
boils
down
right
now
to
to
to
apis
and
how
we're
gonna
use
them,
because
why
I'm
saying
that
the
current
approach
of
the
dra
I
love
the
scheduler
changes
and
the
capabilities?
A
This
is
something
that
we
definitely.
This
is
what
what
Michael
you
touched
on
when
we're
gonna
be
in
phase
two
and
we're
gonna
talk
about
those
Services
I
am
not
planning
it
right
now.
My
proposal
and
probably
we
will
or
agree
on
that,
is
just
to
reuse
the
array
for
the
for
the
scheduler
side
of
the
things
we're
gonna
leverage.
All
that
that's
what
I
would
imagine
we
we're
going
to
design
This.
A
So
what
I'm
thinking
about
for
that
one
and
that's
easy
as
work,
because
we
don't
have
to
mess
around
with
the
core
scheduler
we
already
have
the
apis.
We
just
need
to
write
this
controller.
That
is
going
to
be
not
a
custom
one.
It
will
be
a
kind
of
custom
but
provided
by
the
kubernetes,
and
then
we
will
give
a
capability
for
users
to
if
you
wish
you
can
change
that
and
create
your
own.
This
is
a
reference.
A
A
But
the
array
comes
with
the
API
changes
to
the
Pod
right,
and
they
mentioned
that.
You
know
changing
anything
in
the
core
components
comes
with
a
kind
of
you
have
to
have
a
very
well
defined
arguments
to
do
that
right,
so
my
thinking
is,
should
we
maybe
leverage
that
part
as
well
right
and
then?
Lastly,
there
goes
the
the
the
bottom
side
on
the
cubelet,
where
they
do
have
ability
to
pass
a
string
right
now,
it's
just
a
pass
of
the
string
and
there's
something
for
you
what
you're
referring
to
the
CRI.
A
Maybe
we
can
already
just
leverage
that
that
would
that
see
the
array
already
passing
that
strings
of
what
sort
of
resources
I
am
asking
for,
and
we
can
leverage
that
and
drive
on
that
too.
Okay,
we
already
have
an
implementation.
Why
bother
with
something
completely
new,
so
under
the
hood
I
would
love
to
reuse
most
of
those
things.
A
The
the
thing
here
is
what
we
are
doing
here
up
front.
I
already
said
like
we
definitely
cannot
use
the
claims.
The
resource
claims
objects
that
the
templates
and
the
standard
one
for
us,
because
we
need
to
have
a
a
proper
Network
representation
in
API.
That's
the
core
reason
of
this
whole
effort,
so
that
is
a
no-go
I'm,
not
moving
on
that.
We
need
to
have
a
core
object
which
can
be
referenced
and
can
if
we
have
a
full
representation
of
a
network
in
in
kubernetes.
So
that's
something
that
I
am.
A
On
at
least
from
our
Point,
that's
the
whole
point
for
for
us
to
even
start
this
whole
effort,
so
I'm
not
moving
on
that
one.
So
if
that's
the
case,
then
what
we
are
doing
with
the
rest
of
the
apis
right,
can
we
leverage
some
of
the
parts
stuff,
and
this
is
where
we
can
make
and
I
want
to
hear
your
opinions
on
so
I
managed
to
put
together
something.
Let
me
here
I
share
this
stuff,
so
maybe
to
step
back.
This
is
the
the
dog
that
I
was.
A
We
are
constantly
working
on
right,
attaching
pod
Network
to
Paul
right.
What
I
was
proposing
is
okay,
let's
have
a
field
and
that
field
will
have
some
special
struct,
which
will
introduce
the
Pod
network
name,
so,
basically
the
name
to
which
network
I
am
attaching
to
and
some
additional
parameters
right
to
that
attachment.
So
basically
I
am
providing
some
capability
of
optional
options
for
that
directly
to
that
attachment
right.
A
But
that
will
be
that
that's
something
that
we
that
kind
of
kind
of
was
thinking.
This
was
the
kind
of
example
of
how
that
would
look
like
right.
But
now,
if
we
were
to
look
at
the
dra
and
I
I,
consider
something
like
this,
so
the
array
comes
with
something
called
a
claim:
source
claim
Source
if
I'm
not
mistaken,
is
is
defined.
A
If
what,
if
we
could
expand
this
claim
Source
what
that
they
use
with
pod
network,
don't
look
at
this
one,
yet
I'll
get
there
for
a
second,
but
what
if
we
could
pod
network
name
or
what
do
we
use
here
for
Network
if
we
were
to
introduce
to
their
Alpha
API
a
pod
network
name
and
then
what
it
would
look
like?
It
would
look
like
this
right.
We
have
the
resource
claim
a
name
source
and
all
this
right.
A
This
is
gives
us
a
lot
of
reusability.
We
would
have
to
change
from
their
point
of
view
what
they
do
with
this
field.
Right
initially,
we
could
say
do
nothing
because,
right
now
we
don't
need
any
of
the
scheduler
pieces.
What
the
only
thing
it
could
do
is
just
pass
it
along
to
the
CRI.
So
this
is
where
NEC
Royal
site
implementation
can
handle
it
if
they
want
to.
A
A
D
D
So
what
if
we
expanded
the
API
of
this
parameter
Rev,
so
that
it
could
point
to
different
things
and
one
of
the
types
of
so
let's.
Let's
say
that
we
could
have
parameters
of
different
types.
One
of
the
types
would
be
just
plain:
Network
parameters
that
are
not
associated
to
any
resource
allocation
or
anything.
It's
just
parameters
that
you're
passing
on
to
the
network,
and
then
you
could
have
another
type
of
parameter.
That
would
be
a
resource
specific,
so
parameter
that
is
referencing
a
resource
that
could
be
managed
by
dra.
A
But
then
one
that
make
those
two
kind
of
independent,
that's
so
and
and
bear
with
me
on
this
one.
Why
I'm
asking
this
because
keep
in
mind,
as
I
mentioned
before
I,
would
love
to
reuse
the
scheduler
for
this,
so
I
would
want
to
use
some
of
the
code
that
they
use
for,
let's
say
scheduling
where
we
would
have
the
controller.
A
So
if
you
were
to
do
that,
what
you're
saying
is
you
would
have
two
controllers:
defining
the
let's
say
the
scheduler,
you
see
what
I'm
saying,
because
if,
if,
if,
if
the
scheduler
would
see
okay,
let's
assume
we
are
not
going
with
that
API
right
and
let's
say
we
have
the
spot
Network
attachment.
So
what
what
I
would
in?
What?
What
I
would
think
in
phase
two
and
we're
going
to
talk
about
the
scheduler
right
things
is
their
code
would
see?
A
Oh,
this
is
a
pod
Network
attachment
okay,
so
this
is
I'm
treating
this
as
like
the
array.
So
this
is
that
the
the
generic,
the
core
controller,
is
hard
coded.
It's
this
guy
and
I'm
gonna.
Ask
this
guy
because
I
support
network
attachment,
and
that
will
be
the
one
called
there
to
ask
for
the
availability
and
scheduling.
Are
you
saying
then,
if
if
I
have
who
would
then
parse
and
say?
Oh
okay,
this
network
points
to
another
resource
claim:
hey?
A
A
D
The
only
reason
to
point
to
them
from
the
from
the
network
would
not
be
to
affect
the
scheduling
the
resource
claim
is
able
to
do
that
on
itself.
It
would
be
to
be
able
to
pass
parameters
like
parameters
that
might
be
generated
specifically
from
from
the
allocation
of
the
resource
back
to
the
network,
so
I
might
be
wanting
to
allocate
a
resource
in
a
specific
node.
D
A
Behind
me,
I
am
looking
at
this,
as
is
there
anything
in
in
that
plan.
Is
there
any
engagement
of
the
core
for
you,
because
what
what
I'm
seeing
is
this
is
something
that
you
could
do
right
now
because
keep
in
mind
the
params
ref
is
you
can
point
to
anything
and
it
can
be
the
resource
claim.
Namespace
I'm,
not
only
I,
think
the
resource
claims
I'm
not
sure
whether
the
namespace
or
not,
but
if
they
are
not,
then
namespace
is
optional.
A
D
Anything
yeah
so
I
guess
that
from
what
I
say,
I
I'm
asking
for
something
that
needs
to
happen
in
Cube
later
it's
not
happening
right
now,
and
that's
first
is
the
life
cycle.
How
the
resource
claims
need
to
be
resolved
before
the
body
starts
the
network,
and
the
second
thing
is
something
that
it's
not
there
in
Cuba
today,
which
is
used
to
fetch
parameters
from
the
dra
and
pass
them
on
to
the
network.
A
So
isn't
in
your
plan,
would
you
still
specify
the
claim
inside
the
pod
in
here
in
where
I
had
it?
So
you
would
have
this
network
attachment
signing
to
pointing
to
the
network,
and
then
you
would
have
this
claim
source,
and
here
it
wouldn't
be
pod
Network.
It
will
be
just
resource
claim.
Would
you
still
have
this
piece.
A
So
basically
the
dra
would
deliver
you
all
those
things
down
there,
so
you
would
have
it
in
the
CRI
at
least
right
because
I,
if
I'm
not
mistaken,
dra
provides
them
down
to
the
CRI,
and
you
will
have
it
all
over
there.
Kenny
or
cni
cannot
pick
that
pick
it
up
from
there,
because
you
will
have
it
so
cubelets,
basically
just
passed
them
down
to
CRI
and
now
does
the
CRI
has
to
be
slightly
modified
and
CRA
is
I.
Would
I
would
consider
outside
of
core
where
it
would
okay,
this
is
the
resource
claims.
D
A
So
keep
in
mind
that
cubelet,
so
we
have
a
I'm,
not
sure.
If
you
saw
a
discussion,
there
is
a
discussion
on
slack
Pete
started
it
with
about
exactly
do
we
are
we
thinking
about
any
of
the
CRI
API
changes
right
and
Antonio
is
kind
of
opposing
and
because
the
history
behind
that
part
is
that
cubelet
stopped
handling.
Networking
apis
at
all
right,
Cuba
doesn't
at
all
is
aware
about
networking.
A
It
passes
all
along
the
Pod
stuff
into
the
tri
and
then
CRI
handles
it,
because
the
CRI
is
the
one
that
that
knows
how
to
handle
the
network.
So
that's
why
cubelet
completely
offloaded
all
that
into
CRI.
That's
how
it
is
today
and
from
his
word
and
Antonio's,
not
here
so
I'm
just
going
to
be
paraphrasing
him.
He
would
not
want
Hublot
to
get
back
to
the
networking
business.
A
So
there
is
that
and
I'm
not
sure
how
how
that's
the
kind
of
sentiment,
at
least
that's
what
I'm
trying
to
tell
you.
Does
that
say
something
I'm,
not
sure
how
far
you
would
want,
what
how
much
of
information
from
Cube
that
you
would
expect
right.
That
CRI
would
give
you
right.
So
that's
something
that
you
would
have
to
look
whether
the
dra
capabilities
that
gives
you
today
is
sufficient
right
for
you.
A
What
for
what
you
would
want
to
achieve
and
I
would
consider
if
it's
anything
in
the
CRI
that
will
be
not
out
of
scope
for
this
for
this
cat.
So
what
you're
saying
it
is
possible
to
do?
But,
but
at
that
point,
if,
if
everything
is
on
the
side
right,
you,
you
specify
the
resource
claim
additionally
anywhere
inside
the
Pod,
and
then
you
just
link
those
things
to
together,
which
you
can
do,
because
this
parameter
South
African
reference.
Anything
then
you're,
basically
good
to
go,
did.
D
D
A
So
how
you
pause
them
you,
you
cannot
have
API
there
that
will
gonna
be
support
everything.
So
what
you
would
do
is
probably
just
pass
the
name
of
the
network.
That's
a
specific
pod
or
a
pod
has
wants
to
access.
That
means
the
CRI
now
has
to
reach
out
to
the
kubernetes
API
to
grab
those
parameters,
and
then
it
has
to
understand
what
has
to
do
with
them
or
pass
them
along
or
just
grab
them,
as
is
Marshal
them
and
okay,
pass
them
to
the
cni
right
that
could
happen
right
is.
A
Is
that
something
that
we
expect?
Is
that
something
that's
acceptable?
I'm,
not
sure.
Do
we
have
someone
from
the
CRI
side
here
we
don't
Michael.
Maybe
you
can
give
us.
Is
that
even
possible
if
we
were
to
I,
don't
know,
let's
say
Marshall
the
whole
Network
plus
the
parameters,
the
this
object
into
a
string
and
pass
that
along
and
let's
say
we
will
have
a
list
of
those
and
then
okay
cni,
whatever
you
want
to
do
with
them,
you
do
so.
D
So
so,
just
to
clarify
that's
something
that
I
can
possibly
Envision,
given
that
that's
already
something
that
is
happening
in
the
cni,
how
it
can
just
be
really
open-ended
on
the
number
of
parameters
that
you
can
pass
to
it
right.
So
it's
yeah!
So
that's
something
that
I
can
Envision
as
a
parallelization
between
the
cni
interface
and
the
Syria
interface
I,
don't
know
if
that's
visible
or
wanted,
but
or.
A
A
C
That's
fine,
I
I
had
a
fairly
small
thing
to
say
it's
a
so.
The
model
here
would
be.
You
have
a
resource
claim
that
points
to
something
that
says
attached
to
this
pod
Network
resource
claims
have
got
CRS
that
they
link
to
and
so
on,
and
so
you
can
pretty
much
get
any
parameters
you
like
into
into
such
resource
claims.
C
It
does
feel
like
there's
potential
here
for
us
to
be
able
to
pass
arbitrary
parameters
to
a
network
that
way,
and
so,
if
you're
Network
Revolt,
so
that
could
be
both
standard
parameters
for
a
particular
pod
like
well.
This
particular
pod
wants
to
have
this
network
interface
name
or
whatever,
but
also
it
could
be.
You
know
some
crazy,
SRI
OV
nonsense
that
only
three
people
in
the
world
care
about
but
I
happen
to
be
one
of
them
yeah.
C
C
A
Yeah,
that's
that's
why
we
are
right,
I
think
we
we
committed
some
of
the
time
here
to
kind
of
understand
the
array,
and
now
we
are
discussing
on
because
we
kind
of
were
on
a
verge
of
how
how
we
attached
to
it
right
how
we
specify
that
and
the
array
I
think
that,
as
I
mentioned,
like
most
of
the
dra
capabilities
are
really
useful
and
we
I
I
want
to
kind
of
Leverage
them.
Definitely
the
question
is:
how
do
we
Define
the
apis?
A
What
you
said
it
was
what
I
think
I
I
don't
remember
his
name,
but
basically
that
was
one
of
the
dra
folks
kind
of
his
presentation
from
from
from
the
initial
kind
of
how
we
could
do
what
do.
That
is
what
you
were
saying,
but
my
question
is
then:
do
we
want
to
so
the
alternative
to
this?
What
he
was
proposing
was
having
here,
I
think
that
was
be
so
that
was
just
a
let's.
A
And
this
one
points
to
pod,
Network,
right,
param's
name
and
then
I
have
some
data
plane
here
problem.
My
problem
with
this
approach
is
the
cumbersome
of
API
and
now
imagine
ux
right
for
us.
Okay,
if
we
do
this,
maybe
but
then
we
hide,
there
is
no
pod
Network.
So
how
do
I?
Okay,
we
added
multi-networking
how
we're
doing
the
pods
back.
How
do
I
do
the
resources,
how
not
resources?
How
do
I
add
the
Pod
networks?
How
do
I
Define
them?
A
A
C
B
C
A
A
No,
the
problem
won't
be
any
problem.
We
assume
to
keep
in
mind,
and
this
is
what
Jaime
was
just
asking
about
as
well.
Are
we
passing
those
down
to
the
CRI
right?
So
this
aspect
right?
Let's
assume
we
go
with
the.
We
won't
do
this
in
the
first
phase:
let's
do
it
through
the
kubernetes
apis
right.
So
basically
cni
is
just
a
stab.
It
knows.
Okay,
this
spot
needs
networking
and
I'm
taking
over
from
here,
I.
Don't
care
about
what
CRI
game,
I'm
gonna
look
through
kubernetes
API
right!
A
Let's,
let's
assume
that's
the
approach.
What
I'm
doing
is
I'm
grabbing
the
Pod
I
am
aware.
Mycena
is
aware:
I'm
using
resource
claims,
so
I'm
going
to
go.
Look
at
this,
go
to
the
claim
and
then
go
to
the
parameters
and
the
network
So.
Eventually,
I
am
grabbing
the
the
network.
The
data
plane
Network
to
do
my
stuff
and
I
can
do
it
today,
but
it's
up
to
the
implementation.
Let's
say
Samsung
multi-network
implementation.
We
just
have
to
implement
that
so
that's
possible
even
like
today.
A
If
someone
wants
to
sit
down
and
create
that
and
it
won't
change,
think
speed,
I,
don't
think
it
will
discover
new
things
because
it
will
just
boil
down
to
what
the
API
in
the
Pod
is
right.
So
there
you
have
this
piece
right,
it's
already
existing
and
if
you
enable
the
feature
in
the
apis,
you
you
can
just
reference
this
fields
and
and
just
just
deal
with
that
right.
C
A
C
Think
that
it's
certainly
true
that
having
the
Pod
networks
there
explicitly
is
much
is
much
simpler
and
cleaner
as
a
way
of
doing
things.
It
doesn't
give
you
all
the
flexibility,
and
you
might
want
to
add
that
in,
but
it
gives
you
it
just
gives
you
a
much
nicer,
looking
ux,
but
it's
easy.
It's
easy
to
explain
that
to
somebody
yeah.
A
Any
other
opinions
on
this
on
what
we
should
do
with
the
dra,
because
if
we
were
not
even
we're
doing
to
this
claim
right-
and
we
just
go
with
adding
the
Pod
network
name
here
and
there's
something
that
probably
we
could
ask
them
right-
let's,
let's
re-expand
this
claim
source
where
they
have
the
claim
and
template
defined.
Let's
expand
it
to
other
product
network
name
here
and
then
we
handle
and
take
it
from
here
right.
So
we
keep
the
resource
claims
piece
already
in
and
we
just
add
it
through
pod
Network
right
like
this.
A
My
problem
with
this
one
is
that
where
do
we
pass
the
like
indirect
parameters?
Do
we
do
it
through
the
yeah
I'm,
not
sure,
because
then
we
would
have
to
create
some
claim
anyway,
with
with
parameters
in
it,
pointing
to
some
parameters?
And
let's
say
this
will
be
net
interface,
params
quite
convoluted,
then
right
because
we
I'm
not
sure
and
that
one
would
hold
the
let's
say
whether
the
interface
is
primary
or
what
is
the
name
for
the
interface
it.
B
A
Okay,
so
so
this
guy
right
yeah.
So
if
you
would
look
at
my
kind
of
initial
proposal
that
I
think
posted
back
in
October
last
year
in
it
I
had
a
two
objects:
I
wanted
to
introduce.
First
one
was
pod
Network,
which
we
all
discuss
and
we're
fully
aware.
The
other
thing
that
I
haven't
mentioned
here
in
this
discussion.
A
Yet
recent
discussion
was
the
network
interface
and
basically,
this
is
why
everyone
says
that,
like
at
least
from
some
of
the
folks,
what
I'm
hearing
is
dra
just
fits
exactly
to
what
we
thinking
should
do,
and-
and
this
is
one
of
the
arguments
why,
because
I
was
like
internally
I
was
as
well
kind
of
in
in
my
teams
as
well
posting
this
this
object.
So
let
me
talk
to
you
about
this
object.
This
object
is
to
identify
and
describe
single
attachment,
okay
to
a
pot
right
now.
A
Today
we
don't
have
such
thing
today.
The
only
thing
we
have
as
to
go
to
the
status
of
a
connection
is
the
Pod
IP
status.
You
see,
I
am
trying
to
expand
that.
So
what
I
mean
by
that
is
in
a
postback,
you
have
status,
you
have
pod
eyepiece
right,
and
you
have
this
so
basically,
if
you
just
just
deal
with
core
kubernetes
today,
this
is
your
only
information
today
about
interface
inside
the
pod.
A
This
is
the
only
reason
it's
not
to
kind
of
indicate
what
IP
from
the
networking
or
debuggability
point
of
view
is
just
to
indicate
so
that
they
can
use
it
for
services.
So
there
is
now
an
object
in
kubernetes
today
that
will
tell
you
what
is
the
name
of
the
interface?
What
is
the
MAC
address?
What
are
the
other
blah
parameters
that
you
will
want
to
see?
A
So
I
was
thinking
and
floating
an
idea,
so
maybe
we
should
introduce
a
network
interface
object
that
would
represent
an
interface
and
attachment
inside
the
Pod,
a
single
attachment
into
the
Pod
and
basically
how
it
functions
it
functions
similar
to.
If
you
remember,
from
the
dra
point
of
view,
what
I
think.
Oh,
it
was
Patrick
now
I
reminded
myself
when
Patrick
was
saying
there
is
a
resource
claim,
and
there
is
a
resource
claim.
Template
I'm,
not
sure
how
you
remember
that,
but
basically
as
a
source
in
the
here
as
a
source.
A
The
thing
here
with
the
template
is
they
will,
if
you
point
to
a
template,
they
will
create
a
direct
resource
claim
out
of
this
template,
and
the
other
thing
is
that
they
are
okay
with
using
the
claims,
because
apparently,
multiple
pods
can
reference
the
same
claim
resource.
Keep
in
mind
this.
The
one
of
this
is
a
functionality
that
is
a
no-go
for
us,
because
you
cannot
have
two
parts
pointing
to
the
same
network
attachment
so.
B
B
A
Mean
yeah
and
and
I'm
I'm
I'm
I'm,
throwing
that
into
kind
of
draw
the
analogy
between
the
resource
claims
and
the
resource
claim,
template
and
I
just
draw
it
here.
So
that
kind
of
you,
you
all
here,
have
the
full
story
about
this.
That's
why
I'm
I'm
trying
I
added
it
whether
we're
gonna
have
it
I'm,
not
saying
it
has
to
be
here,
I'm,
just
trying
kind
of
something
that
we
thought
to
have
and
I
I.
A
Have
it
in
my
initial
draft
back
in
last
year
and
I
just
want
to
remind
you
that
that
was
there
and
maybe
we
should
have
it.
Maybe
we
should
consider
it
I,
don't
think!
That's
something
that
I
just
wanna
kinda.
Everyone
has
that
kind
of
context
and
and
a
picture
of
where
some
of
the
kind
of
similarities
for
Dra
comes
from
as
well
all
right.
A
A
The
thing
here
is,
as
we
said,
a
network
attachment
can
only
be
attached
once
so
using
network
attachment
is
a
no-go
for
deployments
or
any
type
of
replica
sets
right,
because
replica
sites
would
mean
I
will
attach
the
same
network
attachment
to
every
pod,
and
that
should
not
be
possible.
So
that's
something
that
that's
the
kind
of
trade-off
of
of
referencing
directly
a
network
attachment
where
you
cannot
or
you
could.
But
when
you
reference
in
any
replica
set,
the
replica
number
has
to
be
only
up
to
one
right,
but.
B
Yeah
so
the
yeah-
maybe
let's,
let's
talk-
let's
discuss
about
the
design
of
the
network
document
generator,
but
for
now
the
network
attachment.
So
the
if
someone
is
reading
this
document
from
top
to
here,
Network
attachment
name
is
pretty
new
support.
Network
name
is
the.
Maybe
the
leader
may
can
imagine
that
Port
network
name
is
pointing
the
port
Network's
name,
but
the
network
document
or
the
network
interface
is
a
pretty
new
terms.
So
maybe
they
used
to
describe
the
sum
of
the
stuff.
Otherwise,
the.
A
We
are,
we
are.
This
is
an
alternative,
don't
take
everything
literally
here
in
this
dark
we
are
working
on.
This
is
all
of
work.
This
is
a
work
in
progress,
this
whole
dog,
so
please
don't
take
it
so
literally
this
dog,
when,
when
it's
going
to
be
posted
in
in
GitHub
as
a
PR,
then
I
agree
with
you,
but
currently
we
are
all
on
the
same
page.
That's
why
I'm
I
am
keep
this
description
and
I'm
describing
and.
B
B
So
I
I-
oh
sorry,
oh
okay,
so
there
I
have
the
the
another
question
is
the
hold
of
it.
So
you
mentioned
that
that
you
want
to
use
the
DRS
this
resource,
they're
scheduling
for
the
yeah
the
scheme.
But
on
the
other
side
you
also
going
to
have
the
schedule
of
Network
right
I
mean
that
the
network
Port
Network
may
have
the
node
selector
or
some
views
to
specifying
so.
A
B
A
What
the
what
the
scheduler
would
say
is:
oh,
you
have
pod
networks.
Okay,
go
call
that
into
the
array,
and
this
is
the
driver,
because
that
will
be
like
a
standardized
driver
or
maybe
we
can
introduce
a
driver
field
into
this
object.
Then,
when
are
we
gonna
talk
about
the
the
when
we're
going
to
talk
about
the
that
scheduler
piece
in
phase
two?
A
Maybe
we
can
expand
the
Pod
Network
object
to
include
the
driver
in
it
and
when
you
not
specify
it,
it
will
just
default
to
the
core
that
we
will
provide,
but
you
can
create
your
own
and
then
you
can
have
your
own
custom,
one.
That
does
something
something
slightly
different
right.
So,
regardless
of
what
API
we
use,
I
definitely
will
will
will
propose
and
withdrive
to
reuse
the
whole
scheduler
or
4D
array.
The
dra
code
would
just
look
at
pod
networks
or
still
the
resource
claims,
even
with
the
resource
claims.
A
B
Resource
schedule
of
the
based
on
the
the
device-
programming
I,
don't
know
the
dras,
the
drivers,
the
the
resource,
identity,
resource
information
and
then
the
port
Network,
the
port,
Network
resource
and
I
mean
that
this.
This
is
about
there.
Not
not
the
device
resource
I
mean
that
Network
resource
okay.
A
B
Is
the
different
the
requirement
right,
I'm
thinking,
so
they
are
maybe
their
the
at
least
the
cubelet
should
when
the
voltage
runs,
then
they
will
the
cube.
The
scheduler
should
get
the
boss
requirements.
I
mean
that
for
their
pod
Network
the
Port
Network
objects
have
the
anode
Factor.
At
that
time
they
know
the
ABC
is
available.
Def
is
not,
and
then
the
dra
case,
and
also
that
this
port
has
a
vrs
resource
frame.
At
that
time.
Also,
the
keyboard
should
check
that
the
the
scheduler
should
check
the
dla
information
at
that
time.
A
B
We
shoot
the
we,
we
don't
have
it
so
that
we
so
that
we
we
should.
We
should
not
reusing
the
DRS.
The
resource
scheduling
I
mean
that
the
resource,
the
idea,
a
result
schedule
is,
of
course
required,
but
on
the
other
side
and
the
pop
Network
site
is
also
needs
to
be.
There
scheduled
schedule
schedule
running
the
schedule
for
the
which
no
no
can
be
available
and
then
the
and
then
the
boss
result,
and
then
we
should
do
the
FM
intersection
or
some
stuff.
So.
A
That's
that
is
going
to
happen.
I
assume,
Tomo,
I,
assume
the
resource
claim,
keep
in
mind.
Resource
claim
is
a
list,
so
they
already
support
that,
because
you
can
specify
multiple
elements
here
so
I
assume
they
they
do
that
right.
They
they
do
for
each
element
in
that
list.
They
will
query
the
appropriate
controller,
get
the
list
of
the
of
the
nodes
filter
things
and
they
go
to
the
next
one
and
and
do
the
same
right.
B
With
this
one,
I'm
I'm,
just
thinking
that
the
the
how
do
I
say
I
mean
I
mean
that
the
the
two
we,
how
does
that
I
suppose
the
the
are
you
using
even
using
the
pop
network?
The
attachment
I
mean
at
the
above
over
the
above,
the
original
implementations,
the
insights,
the
cube,
the
schedule
that
we
can
do
the
the
both
scheduling
and
then
the
finding
the
intersection
with,
and
then
we
get
the
Alcatel
Target
node
I.
C
B
A
I
agree
that
that's
true,
we
don't,
we
don't
have
to
kind
of
have
the
same
those
fields
to
kind
of
Leverage
that
scheduler
piece
right
and
basically
even
later
on
in
the
cubelet
site,
when
we
we
can.
Then,
when
we're
gonna
talk
after
after
this,
when
we
decide
on
that
API,
we
can
talk
about
the
the
cni
IPI
integration
and
then
we
can
talk
on
how
we
are
going
to
pass
some
of
the
information
down
to
the
CRI
right.
A
Are
we
just
leveraging
what
the
array
did
and
and
just
pass
a
string
or
something
I'm,
not
sure
what
how
they
do
it?
I
I'm
I'm,
just
throwing
someone
was
mentioning
about
like
passing
a
string
with
a
name.
So
I
wonder:
is
that
sufficient
for
us
and
just
Leverage
The
dra
path
and
and
be
done
with
it
or
do
we
do
we
do
something
else
right?
So
that's
something
that
we
can
then
discuss,
but
I
I
think.
Are
we
agreeing
all
that?
A
B
D
B
A
B
A
No
because
the
network
is
the
resource
itself,
what
you're
asking
for
is
and
get
if
I'm,
not
understanding.
How
would
I
integrate
this
with
a
let's
say,
srov,
all
right
if
I
were
to
use
or
some
other,
let's
say,
I
would
instead
of
doing
the
device
plugin
stuff
I
would
just
use
the
array
for
my
srov
and
how
now
I
attach
or
link
my
network
to
that
resource
and
I
would
say,
do
it
in
your
parameters,
and
this
is
what
Jaime
was
saying
as
well.
You
could
you
could.
Where
was
it
here?
A
A
That
give
me
let
me
let
me
finish.
Give
me
a
second
if
you
were
to
hear
points
to
the
network,
attachment
definition
and
that
Network
attachment
division
points
to
the
resource
screen.
Won't
that
work
for
you
as
well,
and
that's
then
I,
know
I'm
pushing
that
on
you
on
the
implementation.
You
meaning
your
implementation
rather
here,
and
it's
because
I
don't
see
why
we
would
want
to
have
the
Pod
Network
pointing
to
the
resource
claim
at.
B
B
One
is
the
net
attachative
and
the
second
is
the
resource
frame,
or
some
I
mean
that
the
So
currently
at
the
based
on
that
this
design,
the
problems
that
can
only
have
the
one
object
right,
but
in
so
that
this
means
the
network
of
Staff
should
contains
the
including
the
resource
grabs,
but
also,
in
this
case,
I.
Think
the
this
I
mean
that
this
port
Network
may
have
the
could
have
the
two
objects
are
the
problems
with
one
of
which
one
is
the
network.
That's
different.
Another.
A
Could
be
a
list
I
assume,
that's
I'm,
not
saying
not
I,
think
that's
something
we
can
consider.
Should
this
parameter
be
a
list
right,
because
I
I
think
it
could
right.
It
could
point
to
multiple
elements
and
then
your
implementation
needs
to
understand
that,
because
keep
in
mind
this
parameter
is
for
the
implementations.
It's
not,
for
it
is
not
for.
A
B
A
A
That's
why
I
would
be
on
the
fence
a
bit
to
to
make
this
a
a
list,
but
I
think
we
are
at
the
time
tomolette's
shell.
This
I
will
add
this
this
the
topic
into
a
next
week's
agenda.
To
continue
on
that,
but
yeah
can
we
can
we
end
today's
meeting
with
the
decision
that
we
are
skipping
to
this
and
can
I
have
an
eyes
at
least
so
it's.
B
C
B
C
Anything
very
complicated.
The
final
thing
is
I
think
there
is
a
requirement
that
we
can
have
a
pod
specify
a
bunch
of
parameters
that
are
specific
to
the
type
of
network.
It's
got
but
I
think
resource
claims,
for
that
actually
probably
are
fine.
You
can
have
a
resource
claim,
maybe
have
a
resource
claim
that
links
to
a
resource
that
has
a
link
to
blood
Network
or
something,
and
at
that
point
you're
completely
out
of
this
proposal
you're
into
here's
a
way
you
could
do
it
with
some
customer
resources
and
yeah
yeah.
C
A
Just
because
we're
talking
at
Cross
purposes,
I
hope
you
have
a
Detroit
here
right,
Pete,
please,
if
anything,
just
keep
it
in
one
file.
Let's
keep
it
here.
How
do
I?
Have
you
no
I?
Don't
I
will
add
you
here
so
that
make
sure
you,
edit
in
this
file,
let's
not
create
multiple
files.
Just
add
section
here
and
and
and
and
I
will
try
to
ask
you.
That's
your
right
white
people.
Oh
no
you're,
editor!
Okay,
there
you
go
so
you
should
be
able
to
edit
this
file.
A
A
A
I
said
that
we
have
a
story
behind
it,
but
has
to
be
taught
about
when
we're
going
to
fully
implement
it.
So
it's
not
something
that
we
have
to.
We
will
look
at
it
in
later
phases.
That's
what
I'm
getting
at.
Let's
mention
in
such
a
way
that
dra
is
something
that
we
definitely
want
to
leverage,
but
we're
gonna,
look
at
it
from
this
and
that
perspective
and
we're
gonna
in
detail
talk
about
it
later
or
a
bit
later
on.
Is
that
that's
how
it
I
would
imagine
that
yeah.