►
From YouTube: Multi-Network community sync for 20230802
Description
Multi-Network community sync for 20230802
C
D
Definitely
so
I
typed
up
a
very
draft
document
yesterday
about
breaking
down
some
of
this
work
into
various
tracks
to
help
support
multi-network
in
a
very
iterative
fashion,
and
last
week
we
talked
about
you
know.
If
we
have
multiple
networks,
you
know
on
a
on
a
pod
that
we
need
a
method
to
return
IP
addresses.
Thus
that
pointed
to
the
Pod
sandbox
status,
CRI
message
type,
which
doesn't
really
include
what
we
need.
D
So
in
the
case
that
we
actually
need
interface,
name,
the
network
name
and
IP
addresses
and
I
made
a
very
simplistic
proposal.
What
we
have
as
the
current
and
then
I
have
a
proposal
that
obviously
can
be
changed.
This
was
about
five
minutes
of
thought
to
provide
some
incremental
progress
here
and
effectively.
I
took
a
multis
approach
which
obviously
the
annotations
could
be
multisere,
and
how
do
we
add
value
to
the
Pod
and
that
was
effectively
expanding
the
Pod
sandbox
status
message
to
include
some
additional
information
with
a
future
track.
D
That
would
also
make
the
Pod
aware,
which
involves
kubelet
changes.
On
a
second
vein,
we
have
track
B,
which
is
the
multi-network
cap
which
effectively
most
likely
be
modifying
the
Run
pod
sandbox
request
to
add
some.
You
know
potential
fields
that
will
invalidate
or
negate
the
need
for
annotations,
and
that
seemed
like
those
two
items.
Those
two
tracks
could
move
in
parallel
and
that
we
could
actually
cover
more
ground
and
they
need
to
happen
regardless,
so
they
can
be
broken
out
in
two
separate
caps.
D
D
That
will
give
us
the
most
value
and
that's
where
I
just
came
up
with
those
three
Fields
in
my
proposal,
the
name
interface
name
and
like
pod
IPS
could
add
a
significant
value
and
then
the
track
b
or
current
one
would
obviously
make
a
proposal
for
the
Run
pod
sandbox
request
that,
with
the
goal
to
get
rid
of
you
know
the
annotations
and
be
able
to
link
eventually
our
pod
Network
resource
kubernetes
object.
All
together.
D
Or
those
are
like
calls
from
those
are
all
the
CRI
calls
that
go
into
the
Container
runtime
and
this
one
it's
container
D,
but
the
you
know
cryo
Falls,
a
very
similar
approach.
They
may
have
different.
You
know
status,
maybe
different,
I
think
it
follows
a
similar
route,
though
so
the
areas
that
we're
looking
at
is
run
pod
sandbox
and
run
sandbox
pods
sandbox
status,
which
will
give
us
our
IP
addresses
and
then
something
on
the
Run
pod
sandbox
would
need
to
change
to
support
a
more
thorough
approach.
D
B
D
B
D
All
share
the
cry
API
so
in
this
case,
say
like
sync:
pod
is
actually
passing
in
the
Run
pod
sandbox
request.
The
container
runtime
in
this
case
is
coming
back
with
run
pod
sandbox
response,
which
only
said
re
Returns,
the
uid
of
the
pod,
which
that
was
my
action
item
to
put
the
requests
in
responses
in
this
to
make
it
a
little
bit
easier
to
consume
and
I
haven't
gotten
to
that.
Unfortunately,
it's
just
well
a
little
too
busy.
B
D
E
B
B
That
will
then
give
us
ability
and
then
thinkpot
would
have
to
understand
and
are
you
trying
to
then
then
as
well,
including
your
cap,
the
ability
to
update
the
API,
the
one
that
we
would
add,
because
that's
where
the
Gap
would
be
right
now,
right,
I,
think
this
is
yeah,
you
still
don't
have,
so
we
would
be
the
part
of
it.
Yeah.
D
That
would
the
the
scope
would
be
to
update
the
cry
API
to
include
the
necessary
fields,
and
then
we
would
probably
I'm
not
certain
if
it
requires
a
second
cap
to
go
into
the
cubelet
and
say
hey
instead
of
just
handling
one
IP,
it's
one
address
family
per
Jesus.
Whatever
it
is,
we
will
Implement
that
under
a
feature
gate.
So
then
right,
you
know
it's
either
enabled
or
it's
not,
and
it
goes
into
the
staging
cry:
API
code,
until
it's
fully
promoted
out.
B
All
right
so
that's,
and
so
that
that's
a
good
plan.
If
we
have
that,
but
then
from
our
side
I
wonder
what
I'm
getting
at
is.
We
can
probably
just
change
the
sync
port
to
include
the
whatever
we
want
to
do
to
to
be
passed
into
runpod
sandbox
right,
but
then
it
will
be
up
to
the
Cris
to
adapt
that
new
parameters
that
are
passed
right.
Yes,.
D
That'll
be
up
in
this
case.
Yes,
it
could
be
the
container
run
times
and
I'll,
even
I'll,
even
Implement,
that
just
for
funsies
so
but
yeah
it
has.
Someone
has
to
know
about
it
on
that
side,
so
that
will
cover
these
are
pod
setup,
pod
network
setup
and
our
pod
teardown.
So
we've
satisfied
kind
of
the
scope
because
we
said
that
updates
and
more
are
you
know
future
state
right
and.
D
That
was
that
was
effectively
it
so
and
the
nice
piece
of
this
is
it's
highly
iterative
in
small
changes.
So
we
can,
you
know,
measure
our
success
for
each
change
here
by
adding
a
little
bit.
You
know
some
tactical
gains
and
it
doesn't
paint
us
into
a
corner
either,
and
these
small
changes
May
identify
like
hey.
This
approach
isn't
going
to
work
any
longer.
We
need.
We
need
to
look
at
our
future.
Work
like
you
know,
number
four
for
some
reason
to
highlight
it.
Right.
D
I
have
no
idea
but
like
we
like
or
approved
the
shape,
the
API
or
it's
a
new
API
all
together.
So
this
isn't
saying
that
this
must
be
the
way,
but
it's
iterative
enough
that
it's
not
a
lot
of
investment.
The
hardest
investment
is
just
writing
the
cap,
and
you
know
sitting
down
and
doing
the
you
know
all
of
that.
So
that's
just
my
like
proposal
and
if
we
agreed
upon
the
small
little
what
a
pod
Network
resource
looks
in
a
CRI
API.
B
B
Yep
all
right
so
I
think
what
we
can
do
next
is
now
discuss
on
what
we
would
consider
passing
to
that
simple
when
we
create
the
Pod
right.
So
what
sort
of
information,
and
let's
just
kind
of
list
them
only
and
then
we
I
I,
will
I
will
try
to
look
at
the
sync
pod
and
run
pod,
where
exactly
we
can
propose
a
change
in
such
a
way
that
we
are
not
breaking
anyone
right
so
but
let's
maybe
discuss
I
will
get
back
to
instead.
B
Let
me
just
zoom
this
in
a
bit.
What
we
are
thinking
of,
like
wattpod
network,
has
right
what
parameters
we
have
some
ipam
information
and
then
the
provider
and
the
name
of
the
Pod
Network
itself
right.
What
can
we
pass
into
the
into
the
that
API
call
to
the
CRI
right
now
from
pod
Network
attachment?
What
we
have
is
interface
name
and
one
of
the
two
I
would
imagine
that
the
first
thing.
Definitely
we
want
to
pass.
B
Is
the
network
name
right
and
that
will
be
in
a
in
a
ways
where
I
just
straightforward
pass
the
name
of
this
guy
or
if
I,
have
a
pod
enter
pod
network
interface
in
place.
I
just
grab
I
would
have
to
grab
the
object
and
then
get
the
podnet
Pod
name
from
that
guy,
and
if
you
see
once
you're
going
to
remind
what
support
network
interface,
it
has
a
field
called
pod
name.
So,
basically
I
only
passed
the
name
of
the
network
that
I
want
to
connect.
B
A
B
Network,
what
will
that
look
like
right
and
bear
with
me
just
some
pseudo
code
doesn't
matter,
but
we
know
it
will
have
to
have
a
pod
Network
in
it.
That
would
be
just
a
string.
What
else
we
we
think
we,
because
right
now,
if
I'm,
not
mistaken,
Michael
correct
me
if
I'm
wrong,
I
assume
today
we
don't
pass
anything
in
terms
of
like
what
network
I
want
to
configure
right.
No,
we
just
create
me
a
namespace,
create
me
a
namespace
use
the
default
cni
and
and
be
done
with
it
right
yeah.
B
But
then
I
was
thinking
on
this.
How
we
would
differentiate
the
basic
use
case
right.
Let's
say:
I
want
to
just
use
the
basic
use
case
where
my
pod
network
is
just
a
name
for
the
cni
config
right
or
the
cni
conf
name,
whatever
this,
whichever
it
has
to
match
to
right
to
all
from
all
the
cnis
that
I
have
configured
in
my
cni
path.
Right
so
or
maybe
some
other
means
right.
However,
some
of
the
Cris
would
implement
it.
B
So
basically,
what
I
was
thinking
is
we
would
have
to
pass
as
well
a
provider,
because
that
way
we
can
identify
okay,
what
who's
handling
the
spot
network
from
the
CRI
point
of
view
right?
Is
it
multis
and
basically
maybe
for
multus.
They
just
want
the
way
it
is
today
where
just
call
me
and
I
met
a
plugin
and
I'm
handling
the
whole
thing
by
myself,
so
don't
cut
in
or
is
it
just
fully
container
D,
for
example,
where
they
would
grab
the
name
and
find
a
matching
cni?
B
B
Yes,
here,
I
can
provide
it's
like
it's
either.
The
maltus
is
using
this
or
it's
the
container
d,
because
otherwise,
if
we
won't
specify
that
CRI
would
not
know
how
to
differentiate
between
this
use
case
that
they
want
to
implement
versus.
Oh
don't
do
anything
just
do
whatever
and
just
pass
all
the
lists
to
the
cni
right,
so
one
of
the
two
would
have
to
be
implemented,
and
basically
this
is
Michael
where
your
implementation
goes
into
play
as
well
to
ensure
that
Cris
can
support
such
case
right.
B
D
Yeah
and
so
just
to
break
it
down,
we
have
like
you
know.
The
use
case
here
is
that
you
know
I'm
a
regular
I'm
80
of
kubernetes
I.
Don't
care
about
I
wanted
to
do
the
default
route
in
that
case,
like
this
request,
this
field
that
we're
proposing
to
change
probably
should
just
be
nil
and
empty.
It
should
just
do
the
default
Behavior
and
then
you're.
C
B
So
so
let
me
tell
you
so
basically
what
I'm
referring
to
here
is
whether
this
name,
because
what
we
can,
how
we,
how
does
CRI
can
can
take
this
right,
so
it
can,
if,
if
it's
a
some
provider
that
I
don't
care,
it's
it's
a
list
of
networks
that
I
pass
to
the
CRI,
which
should
be
then
passed
into
the
cni
all
right.
So
basically,
CNL
gets
that
whole
list
that
we
are
currently
thinking
of
what
it's
going
to
be
in
it
right.
B
So
basically,
the
cni
gets
all
that
list
right
and
right
now
it's
going
to
be
just
a
net
name
of
the
Pod
Network
and
at
this
provider
right
so
basically
from
straightforward
from
the
provider.
Motors
will
see.
Do
I
worry
about
this
network
or
not
right.
Do
I
do
I,
provide
it
and,
of
course
it's
based
on
how
the
implementation
is
done
right
because
that's
as
well
kind
of
important
on
that
and
then
based
on
pod
network
maltose.
B
Can
okay
I
need
to
grab
the
spot
network
from
API
and
and
do
because
I
need
all
the
extra
parameter
reference
to
do
my
owl
billing
right?
So
it
will
do
that
and
whatever
it
has
to
do,
it
will
do,
but
in
the
CRI
side,
if
I
want
to
kind
of
Leverage
the
multi
multinix
CRI
that
you're
trying
to
propose
it
shouldn't
be
overriding
every
other
ones.
That's
what
I'm
trying
to
get
because
CRI
is
the
first
is
the
is
the
only
thing
in
the
path
between
cubelet
and
cni,
and
we
cannot
have
the
CRI.
B
B
You
see
that
because
if
you
say
what
what,
if
you
just
do,
what
track
a
proposes
every
time
right
that
will
be
the
only
available
implementation,
then
because
nobody
else
can
do
anything
else,
because
if
I
have
a
full
and
bar
networks
listed
CRI
expects
there
is
a
foo
and
bar
Networks
configured
in
CRI,
or
what's
that
so
basically,
if
I
use
container
D,
that
is
the
only
thing
I
can
use.
I
then
cannot
use
motors
at
all
in.
B
How
would
I
use
because
then
I
had
to
create
a
network
called
mult?
Let's
say
we
go
just.
Let's
say
this
right:
implementation
will
go
by
a
straightforward
just
by
the
name
right.
So
basically,
pod
networks
equals
the
the
cni
conf
right,
but
so
then
I
have
to
have
a
pod
Network
called
multus
inside
of
it.
That
will
have
some
additional
parameters,
but
that
kind
of
Beats
the
purpose,
because
now
I
have
to
control
CRI.
B
Additionally,
on
top
of
my
Motors
and
that's
not
the
point
of
the
Pod
Network,
so
I
have
to
have
a
dual
way
on
how
Syria
is
going
to
behave.
It
should
behave
the
way
where
it
just
passes
along
the
list
and
then
but
then
to
to
kind
of
to
your
to
your
cycle.
Let
me
share
this
tab
again
to
your
kind
of
main
point
right.
So
basically,
what
would
happen
is
I
run
the
runpod
sandbox
I
pass
down
the
list
of
the
networks
right
and
then
you
do,
and
let's
say
this
is.
B
This
is
the
case
where
I
want
to
support
Motors
that
the
old
way.
So
what
will
happen
is
now
CRI
sees
that.
Okay,
I
don't
have
to
do
anything
about
this
because
the
provider
is
not
container
D.
So
that
means
the
cni
handles
this
by
itself.
So
basically
I
pass
the
whole
list
into
the
cni.
Maltus
gets
a
set
of
parameters
into
the
cni
call,
which
is
expanded
by
the
list
of
those
networks.
That
I
want
right.
We'll
just
look
takes
that,
instead
of
grabbing
it
from
the
Pod
and
grabbing
the
Pod
object.
B
Now
it
already
has
all
the
names
it
has
to
handle
in
an
order,
and
then
it
will
just
grab
the
Pod
networks.
Then
it
grabs
the
port
reference,
the
the
parameters
reference
and
it
has
the
node
and
then
based
on
that
it
will
do
its
own
stuff
right
and
then
what
we
have
to
ensure
that
cni
can
return
back
to
the
Pod
sandbox
status
right.
It
can
return
back
the
list
of
the
IPS
that
has
been
configured
all
right
so
and
that's
up
to
the
cni
to
do
that
right.
B
So,
basically,
cni
can
return
you
same
as
you
can
pass
up
the
list
of
networks.
Now
a
cni
can
return
back
to
you,
a
list
of
ips
that
it
configured
right
instead
of
you
retrieving
that
right,
because
if
you
retrieve
it
that
that's
kind
of
straightforward
because
you
completely
configured
it,
so
you
know
what's
what.
But
if
you
didn't
configure
it,
you
might
not
really
know.
What's
what
and
the
cni
has
to
tell
you
what's
what
you
see
the
difference,
Michael.
G
C
C
B
Of
those
right
for
network
name,
one
two
and
provider-
let's
say
provider-
is
one
one
right
so
the
same
provider
for
those
two
networks
right.
So
this
is
what
I
this
is.
The
message:
I
am
receiving
and
I'm
passing
to
the
CRI
right
and
now,
based
on
this,
let's
assume
provider
is
what
CRI
supports.
I
have
a
CRI
called
provide
one
and
then
what
it
happens,
what
it
will
do
it
will.
B
A
D
D
C
B
And
name
equals
pod
and
network
and
Network
name
one
right.
So
we
have
a
cni
call
like
this
right,
and
this
is
a
basically
cni
conflict
right
cni.com
and
the
name
is
like
this
right,
and
this
is
understandable
right
what
the
cons,
what
the
cni
is
right
and
then
what
I
do
is,
and
this
is
the
case
where
I
said
that
the
CRI
supports
multi-networking
right
fully.
B
D
B
Right,
so
this
is
the
case
where,
where
this
is
that
right,
but
in
this
world,
how
do
I
run
multis
in
this
world?
In
this
case,
let's,
let's,
let's
kind
of
entertain
example
here
and
let's
say
multiple
right:
what
do
I
do
here
with
motors,
because,
right
now
you
called
a
pod
network
name
one.
Basically,
this
is
my
Mac
VLAN
interface,
how
I,
how
we
kind
of
presented
it.
This
is
my
maybe
not
Mac
villain,
it's
my
Subnet
a
right.
B
G
C
G
B
So
now,
but
with
this
approach
that
breaks
it,
because
how
do
I
ensure
I
being
moltus
is
being
called
right
now.
Motors
is
not
being
called
at
all,
because
what
I'm
calling
is
POD
network
name
one
and
the
Pod
networking
two
and
with
if
the
CRI
handles
it
right
fully,
so
that
completely
breaks
Motors,
because
you're
gonna
a
do
two
calls
to
the
C9
and
B.
They
are
not
multiples
right.
So
that's
the
problem
right.
So
this
is
where
what
I'm
saying
to
support
something
like
not
only
Motors
but
other
implementers
of
the
multi-networking.
H
D
Remember
what
I
said
earlier
about
the
Run
pod
sandbox
request,
this
object
will
be
nil
and
maltes
will
continue
on
Happily
completely
fine.
With
this
annotation
approach
on
the
Pod
spec.
The
only
added
benefit
now
is
that
it
can
return
additional
information
via
the
Pod
sandbox
status.
So
in
that
case
we
don't
do
anything
different.
We
we
happily
go
along,
though.
B
D
D
B
B
D
B
That
we
support
that
right.
So
basically,
what
has
to
happen.
This
then,
has
to
be
passed
into
the
cni.
We
cannot,
because
you
say:
oh
this
field
will
be
no
nil.
I
cannot.
How
do
I
define
whether
it's
nil
or
not?
The
Pod
Network
field
in
a
pod
is
not
exclusive
for
the
CRI.
Only
okay,
it
is
used
by
multiple.
It
can
be
used
by
multiple
implementations.
B
Okay,
so
my
pod
will
have
this
field
set
same
way,
so
I'm
gonna
pass
those
to
the
CRI,
but
in
this
case
CRI
should
not
make
this
calls,
but
should
make
this
because
now
I
want
to
support.
I
want
to
be
Backward,
Compatible
and
I
want
to
support
Motors.
So
what
I
would
imagine
CRI
with
Co
provider
is
not
equal
provider.
X
is
not
equal
to
me
provider.
One.
So
I
do
nothing
with
this
one.
B
It's
not
I'm
not
handling
those
spot
networks,
because
it's
not
mine
and
then
I
go
to
and
I
will
just
pass
those
guys
into
the
cni
and
we
will
expand
the
cni
API
to
include
those
guys
in
the
list
and
then
multis,
as
you
said,
would
have
to
change.
Oh
those
are
the
list.
That's
that
is
the
list
of
the
networks
that
I
got
so
I,
don't
have
to
go
to
the
Pod
to
get
them
crap.
B
A
C
A
B
A
comma,
IP
or
multiple
same
like
you
have
right
so
basically,
I
can
I,
can
return
back,
see
and
I
can
return
back
to
now
a
list
not
of
a
single
IP
but
of
multiple,
and
you
can
just
do
the
same
thing.
What
you
were
doing
for
your
approach,
but
then
you
would
support
this
one
as
well,
where
okay
cni
now
it
can
return
me
all
the
data
it
gathered
right
because
multis
now
run
out
the
CNS
internally.
B
It
covers
all
the
apis,
and
now
it
will
through
the
cni
call,
it
will
return
the
list
that
you
would
otherwise
know
about
it
about
yourself
right
now.
It's
provided
provided
by
dc9,
because
now
the
provider
is
X
and
now
the
X
provider
handles
the
whole
thing,
but
the
CRA
has
to
allow
us
to
support
this.
This
is
what
I'm
kind
of
trying
to
make
sure
that
we
ensure
that
CRI
will
not
take
over
the
whole
field.
B
A
A
D
That
case
you're
passing
it
something
like
is
the
provider
saying,
hey,
don't
do
anything
and
I'm
gonna
handle
it
elsewhere,
because
in
that
case
you
don't
want
adding
the
Pod
Network
resource
stuff
may
not
makes
a
lot
of
sense,
because
that's
where
I'm
getting
confused
and
I'm
I
think
the
the
diagram
you're
drawing
is
a
little
confusing.
So
if
we
add
something
else,
something
else
needs
to
tell
hey.
D
I
know
like
something
obvious:
you
need
to
say:
hey
container
runtime,
don't
do
what
I'm
telling
you
to
do,
but
right
now
the
Pod
networks
is
the
setup
setup
and
tear
down
is
handled
by
the
container
run
times.
However,
what
you're
proposing
say
if
we
have
our
default
Network
that's
going
to
go
through
the
cni.
However,
we
have
a
b
and
c
Networks
and
you
want
to
tell
the
kubelet
or
something
to
say:
hey,
don't
do
you're
gonna
set
up
this.
This
is
your
role
in
responsibility.
D
B
Out
yeah
yeah,
that's
exactly
because
we
cannot,
because
otherwise,
what
you're
thinking
of
doing
is
completely
you
you
would
you
would
there
will
be
only
one
implementation
of
multi-networking
and
that
is
through
the
Cris,
and
we
are
on
the
mercy
of
containerd
or
cryo
and
all
the
other
ones.
That's
not,
and
that's
the
purpose
of
what
we
want
to
achieve,
because
it
cannot
be
like
just
one
guy
one
implementer
just
handles
the
whole
thing
for
us.
B
A
B
I
perfectly
can
and
that's
why
we
had
the
provider
field.
It
perfectly
can
imply,
provide
that
capability,
and
if
someone
wants
to
use
the
very
simple
stuff,
yes,
then
they
use
oh
I'm,
using
container
d,
a
container
D
expects
to
provide
their
value
to
be
container
containerd.io
whatever
and
then
I
set.
That.
B
I'll
just
want
to
do
your
container
D
and
my
nodes
have
all
the
conflicts
created
for
us
and
then
that's
how
I
want
to
deal
with
it,
and
that's
perfectly
fine
for
me
and
that's
good
right,
but
there
are
cases
where
it
shouldn't
it
shouldn't
care
about
it
right
and
like
multis.
Multus
is
the
one
that
takes
over
and
that
relies
on
the
conflicts
right.
It
relies
on
not
objects,
Network
attachment
definition
objects.
So
that's
why
we
need
to
allow
it
to
be,
and
even
our
Google
implementation
has
a
well.
B
It
has
its
own
objects,
some
other
stuff.
So
we
don't
want
to
rely
cnis
for
us,
it's
just
a
stab.
Basically,
we
just
want
you
yeah.
Just
make
sure
you
call
my
my
agent
on
the
Note.
That's
it
and
I'll
take
over
and
I
will
do
the
whole
thing
and
that's
what
I
want.
So
basically,
a
CRI
is
not
I.
Don't
want
CRI
to
be
one
and
all
implementation.
So
that's
something
that
we
must
ensure,
and
do
you
see
that
now
well.
D
Yeah
I
see
I,
see
oh
sorry,
dagger.
Oh
he
hot
miked
himself,
I
totally
see
what
you're
trying
to
do
so
like
if
just
allowing
provider
field
puts
passes
this.
You
know
past
this.
You
know
discussion
because,
like
I,
don't
care
if
the
provider
field
is
there
like?
That's
that's
a
completely
fine.
I
was
just
saying
that,
like
I
was
trying
to
figure
out
the
reasoning
I'm
not
contesting
the.
E
D
The
providers
I
didn't
understand
what
you're
doing
with
that
and
like
yeah.
So
if
we
can
like
agree
to
what
the
Run
pod
sandbox
request
would
look
like,
and
if
that
includes,
like
the
whatever
I
put
in
my
my
status
proposal,
or
something
shaped
like
that,
that
works
perfectly.
However,
now
I
want
to
like
kind
of
understand
the
flow
one
I
I
I
really
want
to
iron
out
the
details
of
what
the
that
new
message
type
would
look
like,
but
the
second
part
here
is
like.
D
Can
you
discuss
the
flow
of
the
non-cri
approach
for
multiple
networks,
because
that's
a
larger
effort
in
itself,
like
the
one
that
we
have
right
in
front
of
us
very
simple
to
do,
but
I
want
to
understand
the
the
details
of
the
non-cri
approach,
because
there's
my
I
put
in
The
Proposal
there's
like
a
future
work
like
a
new
API
and
more
I'm,
trying
to
figure
out
that
piece.
That
would
be
helpful.
B
D
Yeah
well
in
this,
in
the
current
diagram
sets
the
the
iterative
approach,
and
so,
let's
just
talk
about
say
we
have
here's
the
scenario
we
have
pod.
Now
we
have
our
default
Network.
Obviously
we'll
just
call
it
Calico
for
funsies,
and
then
we
have
pod
network
name,
one
and
name
two.
We
have
provider
X
and
provider
y.
Can
you
shed
some
details
on
that?
That's
I
think
will
help
clarify
your
thought
process
for
us.
E
Possible
to
to
kind
of
separate
the
interfaces
and
the
kind
of
implementations,
I
think
CRI
is
just
the
interface
and
then
there
is
the
container
runtime
right
and
then
there's
cni
and
the
kind
of
cni
Plug-In
or
agent
or
whatever
implementation.
It
is
right,
at
least
it
would
help
me
to
understand
the
call
Flow
better.
B
B
H
The
bit
that's
confusing
me
now,
maybe
other
people
have
been
fighting
the
same
as
I
was
assuming
that
the
provider
would
be
cni.
That
means
call
cni
with
some
parameters,
I
think
what
you're
saying
is
it's
a
much
more
grandular
thing
than
that
that
there
has
to
be
some
configuration
somewhere
that
understands
that
the
provider
for
Calico
is
called
cni
with
a
bunch
of
or
whatever
you're,
using
with
a
bunch
of
parameters
for
Calico
and
a
bunch
of
configuration
for
that
yeah.
B
B
That's
what
we
are
kind
of
I'm
trying
to
call
out
it's
not
just
a
standardized
piece:
it's
not
part
of
cubelet.
No,
it's
one
of
the
providers,
because
it's
in
the
path
and
it
can
take
over
the
whole
thing-
that's
why
it
cannot
be
just
a
transparent
thingy
that
that
I
think.
Currently,
the
plan
is
up.
What
the
top
picture
would
would
show
right.
H
So
the
current
networking
model
is
that
you
kublic
calls
CRI
and
CRI
then
calls
the
networking
implementation.
Yes
are
you?
Are
you
proposing
that
yeah?
So,
yes,
cro
whatever,
but
normally
cni,
yeah
and
I?
Think
what
you're
proposing
is
that
the
kiblet
would
only
sometimes
call
the
CRI
CRI
with
networking
information.
Sometimes
it
would
call
something
else:
do
they
all
go
through
the
CRI
or
not?
They.
B
Always
go:
no.
They
always
go
through
this
here.
Right,
I,
don't
want
to
change
that
path
right.
So
basically,
what
what?
What
to
to
what
Michael
was
trying
to
to
ask
for
right
top
case
is
where
CRI
is
handling
the
multi-networking
and
I'm
just
proposing
here
one
of
the
ways
it
could
be
implemented.
B
Jaws
basically
calls
the
first
cni
conflict
right,
that's
what
is
being
happening
today
and
basically
I
want.
Some
of
the
implementers
like
multus,
relies
on
that
implementation.
Maybe
in
a
future
multis
would
integrate
in
some
ways
with
the
top
approach
in
some
ways,
but
that
I
don't
know
whether
that's
even
possible,
but
maybe
they
can
right.
Then
they
don't
have
to
rely
on
this,
but
we
must
ensure
that
we
can
support
the
data
approach
where
the
today's
implementers
are
reliant
on
on.
B
B
We
have
such
message
right.
We
have
so
default
provider
and
what
I
would
see
in
this
case,
and
it
will
be
a
bit
of
a
messy,
but
but
this
could
be
supported
as
well
right,
so
I
would
have.
My
default
is
called
by
by
provider
Calico
and
the
other.
So
how
would
I
see?
Is
this
with
get
right
and
of
course
that's
up
to
how
CRI
would
handle
that
in
the
ordering
and
all
that
that
would
have
to
happen?
That's
one
right:
I
don't
have
space.
C
H
B
B
So
basically,
all
the
other
networks
that
I
don't
own
I
just
do
the
default
stuff,
as
I
did
today
right
it's
a
bit
of
a
bit
of
a
mess
because
then
I
I
provide
those
networks
to
the
first
cni
conflist,
and
maybe
it's
maltus
or
something
else
right,
and
then
it
handles
the
whole
thing.
But
then
I
have
one
of
the
networks.
Is
a
provider
CRI
right
so
that
will
make
another
cni
call.
F
B
Has
to
and
because
it
has
too
much
to
its
own
to
its
own
provider
right
because
so
yes,
that's
what
I'm
gaining
of
right
so
because
and
what
I'm
trying
to
tell
as
well
like
container
D
versus
cryio.
They
both
can
Implement
their
multi-networking
in
completely
different
ways.
I,
don't
know
what
that
can
be,
but
that
might
be
the
case
right
why
we
are
forcing
them
to
standardize
on
how
they're
gonna
do
the
networking
this
approach
on
the
top
right.
It
might
be
just.
B
B
Exactly
so
and
I
I,
don't
think
we
would
want
you
for
this
right.
So
basically,
what
do
we
do?
So
we
have
to
pass
all
the
data
we
could
to
the
CRI,
so
it
knows
what
to
do
next
right.
So
in
this
case,
I
was
thinking.
Okay,
let's
pass
that
provider
as
well
to
the
CRI
so
that
it
then
can
determine
based
on
the
provider.
What
you
do
do
I
handle
that
Network
or
not.
B
F
F
B
B
D
As
is,
and
we
moved
the
effort
forward
from
a
CRI
perspective,
we
probably
need
to
decouple
provider
and
say
the
workflow,
because
right
now
we're
telling
we're
adding
provider
and
if
we're
going
to
go
super
iterative.
I'm
I
want
to
know
like
what
we're
doing
with
that,
because
in
this
pod
Network's
default
net
a
net
B
effectively
the
provider
is
cni.
We
shouldn't
be
calling
out
the
specific
implementation
like
Calico
and
more
that's
where
I
think
a
few
people
are
also
getting
wrapped
up
is
like
tell
me
the
path
where
we
don't
use.
B
When
the
provider
is
not
equals
provider
right
see
right
and
it's
just
a
pass
through
yeah,
then
those
guys
below
those
two
guys
don't
exist
right
and
basically
then
I,
then,
basically,
what
happens
is
I
have
only
this
I
had
the
default
Behavior,
so
the
provider
is
completely
different.
Cri
is
just
a
pass-through
and
you
do
nothing,
because
how
do
I
Michael
tell
me
so
you
need
to
support.
Let's
say
when
you
need
to
support
multus
as
it
is
today,
if,
if
you
are
going.
B
F
H
F
F
A
B
Then
no,
no
folks
see
a
CRI
only
knows
about
its
own
provider.
Doesn't
care
about
the
other
ones,
so,
basically,
CRI
is
container
D,
so
I
care
only
about
container
D
and
I
do
my
stuff
only
for
container
G
I,
don't
care
about
the
other
ones.
Anything
that
doesn't
is
something
a
provider
that
is
not
called
container
D
I
just
do
the
default
piece.
B
You
see
that
so,
basically,
if
I
have
here
the
provider,
that's
why
that's?
That
field
is
slightly
explicitly
stating
that
what
provider,
what
the
key
of
a
provider
do
I
support
based
on
the
CRI-
and
let's
say
this
is
container
d
and
basically
the
provider
key
that
I
hard
coded
into
my
implementation,
is
container
D
I,
don't
care
about
what
are
the
other
ones,
whether
it's
Calico
motors
for
those
I
just
do
the
default
stuff?
If
it's
not
container
D
I
do
this.
B
If
it's
container
D,
then
I
do
this
additional
call
or,
however,
the
CRI
is
once
you're
supporting
it
all
right.
So
that's
what
I
was
counting
up
up
here
right
provider-
it's
called
provider
here
and
when
the
when
the
networks
that
are
passed
to
me
are
called
provider.
Okay
I
will
do
it
means
someone
wants
me
to
handle
those
networks.
So
I
will
do
that.
I
just
want
to
ensure
we
do
this.
Otherwise,
if
we
don't
have
the
provider,
Sierra
is
the
only
way
to
do
it.
Oh.
B
D
And
much
I
understand
your
concern.
What
I
mentioned
earlier
too,
is
that
if
you're
passing
it
via
the
CRI,
the
container
runtime
is
going
to
receive
this
and
where
you're
putting
provider
effectively
says
you're
going
to
The,
Container,
runtime
and
you're
going
to
go,
do
something.
So
what
I
mentioned
earlier
is
that
this
field
is
in
the
wrong
location.
That's
all
I'm
saying
that
the
kublet
either
is
going
to
The
Container
runtime,
or
it's
going
somewhere
else.
D
What
you
just
said,
because
it
can't
you
can't
be
telling
the
container
runtime
hey
here's
all
this
stuff,
because
it's
already
at
the
container
runtime
but
you're
saying
it
and
I
understand
you're
you're
trying
to
say
it's
not
the
run
time
here
and
I'm
just
saying
you're,
just
this
decision.
Logic
is
in
the
wrong
place
it,
but.
D
That's
the
whole
container
run
time,
so
the
only
alternative,
if
you
want
to
if
you
want
to
propose
moving
away
from
the
CR
like
the
CRI
for
the
network
setup.
If
you
go
down
scroll
to
my
document,
there's
a
place
where
you
can
do
just
what
you
said
and
that
field
once
again
provider
is
still
in
the
wrong
location
if
it's
in
the
Run
pod
sandbox.
So
if
you
want
to
say
like
we
have
provider,
CRI
container,
D
cryo
and
now
you
have
provider
mache's
implementation.
D
So
right
now
the
roles
and
responsibilities
of
run,
pod,
sandboxes
and
the
currency
is
create
the
network
name.
Space
set
up
the
network.
Now,
if
you
want
to
have
a
provider
come
in
here,
it's
right
where
your
cursor
is
run
pod,
sandbox
and
between
create
containers.
So
at
that
point
you
can
actually
have
an
entire
new
API
right
between
there.
B
B
Then
you
ask
Hublot
to
include
oh,
for
this
is
a
container
deep
provider,
or
this
is
a
this
guy,
so
do
I
so
now
I
have
to
implement
what
Cris
there
are
inside
cubelet
and
hard
code.
Those
values
there.
So
that's
that's
that
won't
fly
either
because
then
yeah,
because
I
have
to
decide
whether
I
leave
that
at
least
empty
or
not
in
Cuba,
and
to
do
that.
I
have
to
know
what
is
the
CRI
and
then
compare
that
Cris
provider
with
whatever
is
in
the
Pod
name.
B
D
I
have
literally
it
all
in
like
links
that
I
can
share
and
walk
you
through,
because
I
I
I
understand
what
you're
trying
to
do
and
I
think
where
I'm
pushing
back
is
that
there's
we
already
have
the
CRI
we're
we're
not
going
to
go
and
you're.
You
can't
do
it
outside
the
CRI.
You
have
to
do
it
elsewhere
and
that's
what
I
was
saying
earlier
is
like.
D
So
is
I
like
the
the
proposals
that
I
think
you're
trying
to
get
to
is
what
I
mentioned
in
the
future
state
that
we're
going
to
come
to
the
conclusion
that
the
cry
API
doesn't
work
for
a
lot
of
our
use
cases
and
that's
where
we
need
to
go
and
that's
where
we
probably
should
look
at
the
the
current
behavior
from
kubelet
all
the
way
to
the
container
runtime,
exactly
what
it's
doing
and
then
identify
like
hey.
What
could
we?
D
How
can
we
move
this
effort
forward
in
an
iterative
way,
but
also
say,
like
hey
future
work
bullet
point
number
four
in
the
parentheses,
is
that
you
know
we're
going
to
start
saying
that
this
just
simply
no
longer
works
for
networking
and
Cisco.
Juniper
and
Arista
all
have
come
to
this
conclusion,
but
we
also
have
to
like
build
the
case.