►
From YouTube: Network Plumbing WG Meeting 2018-04-12
Description
Kubernetes Network Plumbing Working Group meeting 2018-04-12
A
A
On
that
note,
I'll
move
on
to
the
first
item
here
in
the
list
which
I
added,
which
is
a
couple
meetings
ago.
Since
then,
I
had
updated
the
specification
for
multiple
attachments
and
for
the
default
Network
functionality
and
I
was
wondering.
If
anyone
had
any
input
on
those
items,
they
tend
to
gloss
over.
B
A
Know
that
there's
a
possibility
to
make
some
changes
upstream
in
C
and
I
at
gloss
over
that,
but
it
kind
of
allows
to
say
that
you
know
the
meta
plug-in
may
create
a
unique
interface
names
in
the
case
where
you
would
use
an
interface.
You
know
I'm,
allowing
also
for
the
fact
that
there
may
be
user
space
networking
plugins
that
don't
use
a
at
all.
We
want
to
have
any
feedback
on
those
sections.
A
So
that
was
that
hey
Mike,
so
it
it
really
basically
allows
for
a
kind
of
May
clause,
saying
that
the
that
the
meta
plugin
may
allow
the
creation
of
unique
interface
names
as
it
creates
basically
duplicates
of
the
attachments.
So
you
know
if
you
say
that
a
comma,
a
as
a
user,
you
may
expect
it
to
creates
a
net
one.
A
So
it's
that's
right.
So,
for
example,
I
know
Carol
had
an
exact
a
swear,
maybe
with
I'm
forgetting
which
plug-in,
but
he
just
had
to
create
the
name
anyways
and
then
ignore
it
essentially,
but
yeah.
You
sure
that
if
you
use
the
delegate,
add
method
from
Scout
that
it
says:
hey,
gimme,
a
interface
name
right.
D
A
I
kind
of
think
that
what
Suresh
suggested
is
a
good
I'm,
pragmatic
workaround
for
the
shorter
time,
and
that
we
may
want
to
add
that
to
the
specification
and
maybe
with
the
plan
that
later
on,
he
would
try
to
form
maybe
team
of
people
from
this
group
that
might
go
upstream
to
CNI
and
try
to
make
a
proposal
later
and
add
an
invention
that
the
maintainer
x'
were
at
least
warm
to
the
idea.
That's
not
necessarily
a.
C
C
A
C
C
C
A
C
Like
to
do
one
question
sure,
there's
people
are
when
they
want
to
refer
the
implementation
of
this
they'd
say
the
metaphor:
nyan,
but
I
have
a
problem
with
that
right.
For
the
reasons
we've
discussed,
a
plug-in
is
involved.
Only
a
pod
set
up
time
and
I
want
to
be
able
to
track
changes
dynamically
here,
so
you're
right,
I'm
a
prototype,
an
initial
implementation
with
a
plug-in
but
I
think
I
want
to
you.
I'd
rather
hear
words.
You
know
like
look
the
implementation,
will
it
without
a
presumption?
E
C
I
mean
I'm
motivated
by
I'm,
coming
from
the
angle
of
people
who
are
trying
to
implement
virtual
machines
in
pods
and
so
virtual
machines,
it's
kind
of
common
to
be
able
to
dynamically
change
their
network
attachments.
So
it's
you
know
consequence
you'd
be
desirable
to
be
able
to
do
that
with
a
pod.
A
Yeah
I'm
I'm
with
you
there
and
I
think
that
this
is
definitely
important,
and
my
current
focus
in
the
context
of
the
agenda
is
to
ensure
that
the
specification
allows
for
this
idea
of
the
fifth
audiences.
Something
we've
kind
of
discussed
before
is
fin
plug
in
thick
plug
in
and
I
believe
that
there
is
I'm
looking
for
in
the
spec,
but
I
believe
that
there's
some
language
in
here
that
at
least
hints
at
this
idea.
Yes,.
C
D
C
My
concern
is
not
thick
plug-in
versus
thin
plug-in.
My
problem
is
that
a
the
idea
that
the
existing
interface
between
couplet,
CRI
and
CNI
a
plug-in.
It's
only
invokes
the
whatever
plug-in,
whether
it's
thick
or
thin
early
invokes
at
its
startup
time
and
that
rules
out
being
able
to
dynamically
track
changes.
So
that's
my
objection.
I
want
to
see
you
know
the
discussion,
so
the
implementation,
noting
that
we
may
start
with
a
limited
imitation
that
doesn't
track
the
changes
dynamically,
but
we
aim
for
an
implementation.
We
allow
for
an
implementation
that
does
track
changes.
E
I
mean
there
are
other
ways
of
thinking
about
this
problem
that
sort
of
intrinsically
start
from
a
dynamic
viewpoint.
You
know
part
of
the
problem,
the
C&I
in
couplet,
and
what
they're
doing
very
definitionally
sets
up
networking
at
startup
time
and
that's
it.
There
were
some
ideas
that
were
bouncing
around
on
us
a
couple
of
weeks
ago.
That
would
look
at
the
problem
from
a
slightly
different
angle
and
allow
you,
and
just
naturally,
as
a
side
effect
of
the
different
viewpoint
on
the
problem.
Involve
dynamic
attachments.
Can.
E
E
It
probably
clocks
in
closer
to
twenty
boo,
just
because
there's
contexts
involved
right
because
part
of
it
thinking
about
the
problem
differently
than
the
way
that
we
thought
about
it
in
sort
of
the
the
traditional
VM
world
and
thinking
about
it
more
in
terms
of
the
way
that
the
cloud
native
world
thinks
about
these
things.
But
it
still
allows
us
to
get
this
thing
that
we
actually
need
at
the
end
of
the
day,
make
sense.
C
A
How
about
this?
Let's
put
it
at
the
end
of
the
agenda
here
to
let
people
who
needed
to
get
a
few
items
on
here
in
advance.
Give
him
the
chance,
and
we
can
make
a
judgment,
call
based
on
the
time.
Does
that
sound
good
sure,
that's
good,
all
right,
great,
so
anyways,
something
that
I
wanted
to
bring
up.
A
Briefly
at
least
was
a
thought
that
I
had
regarding
a
item
in
the
spec
that
reads:
should
a
cluster
or
namespace
administrator
or
someone
else
be
able
to
prevent
certain
pods
from
attaching
to
certain
networks,
and
it
was
brought
up
at
one
point
that
maybe
the
CR
DS
may
be
able
to
do
this.
However,
the
thought
that
I
had
was
that,
since
this
is
a
free-form
field
that
allows
the
user
who's
creating
a
pod
to
enter
into
it,
and
then
it
is
read
by
a.
A
In
the
for
the
sake
of
not
saying
a
metaphor
again
for
saying
a
resident,
daemon
or
fin
implementation,
it
will
refer
to
its
credentials
when
it
reads
that
so
I
wanted
to
bring
that
up
as
food
for
thought
or
to
hear
anyone's
particular
use
cases.
That
might
make
this
more
of
a
primary
consideration
that
it
may
need
more
wording
in
the
specification.
C
Yeah
I
mean
I,
think
it's
a
legitimate
question.
I
think
I
can
think
of
some
ways
to
maybe
abuse
some
of
the
concepts
we
have
I'm,
not
sure
if
we
should
start
with
that
abuse
or
nothing
at
all.
But
for
example,
we
could
say
I
think
that
the
implementation,
whatever
style
it
be
in,
can
check
whether
the
service
account
that
the
pod
is
running
under
is
authorized
to
read
this
attachment
definition
and
allow
access
or
not
based
on
that,
it's
a
bit
of
an
abuse,
but
it's
a
way
to
get
some
control
using
existing
mechanisms.
A
I'm
making
a
note
of
this,
because
I
I
feel,
like
that's
a
fairly
good
start
and
how
to
address
this
issue.
I
think
that
that's
probably
at
least
if
I
was
thinking
about
it.
Like
here's,
just
a
use
case
to
throw
out
there,
you
have
whatever
senior
admin
and
junior
admin
and
junior
admin
is
only
allowed
to
attach
to
this
subset
of
networks.
Right
you'd,
probably
look
at
what's
what's
the
service
account
for
this,
so
yeah
I
like
that
under
my
made-up
use
case,.
A
F
So
I
don't
have
funds
for
us.
I
I
mean
the
question
is:
how
do
we
handle
for
heterogeneous
networks?
We
might
have
a
resource
pair
network,
but
what?
How
do
we
want
to
handle
a
logical
network?
So
let's
say
we
have
over
like
with
thousand
networks
and
we
are
going
to
create
one
resource
per
each
logical
interpreter.
So
I
wonder
if
anyone
has
any
ideas
on
that
and
how
we
should
handle
it.
Yeah.
C
I
think
you're
presuming
making
a
mistaken
assumption,
which
is
that
each
network
needs
to
be
a
separate
resource.
I
think
if
you've
got
a
thousand
networks,
probably
nine
hundred
and
some
of
them
are
all
consuming
s,
RR
io
V
channels,
so
you've
really
only
got
one
resource
of
concern
here,
which
is
the
SR
Iove
channels.
Yes,.
F
C
F
F
C
F
Yeah
so
I
the
idea
to
select
the
specific
Network.
When
would
some
attribute
it
was
bring
up
and
the
last
main
thing
I
think
so
the
death
could
solve
this
right.
So
that
would
be
their
rule.
The
only
one
resource
for
all
those
networks-
and
we
don't
need
a
schedule
involved
because
of
them-
are
available
on
each
node
right.
So
in.
C
B
C
B
So
I
think
still
if
we
try
to
fit
that
into
the
present,
if
we
say
you
know
we
we
want
to
expose
Obion
as
a
resource.
Then
I
still
the
question
is
you
know?
How
could
we
say
to
what
to
what
network
of
that
resource?
Do
we
want
to
get
attached
and
then
I
groove
better
than
everything,
something
like
an
attribute
to
that
resource
makes
sense,
and
then
also
we
don't
burn
put
the
burden
on
the
scheduler,
because
we
effectively
just
have
one
resource,
which
is
you
know
the
availability
or
connectivity
to
to
ovn
I.
C
B
Yeah
today,
I
think
today,
it's
not
possible
to
today.
The
problem
really
is
that
for
every
network
we
want
to
represent,
we
would
have
to
expose
a
separate
resource,
because
the
value
or
the
request
you
can
do
to
a
device
plug-in
is
just
you
know,
an
integer.
You
can
just
request
the
number
of
restriction.
Oh
the
count
of
that
resource.
You
want
to
sign
your
pod
so
and
how
the
difference
between
the
two
proposals
is
actually
just
that
the
one
proposal
has
an
admission
controller
which
is
taking
care
of
the
the
de
facto
standard
annotation.
B
B
E
D
So
not
the
basic
difference,
I
seen
in
the
proposal
we
do
caps
I
could
say
is
like
you
considering
the
network
resources
which
is
like
bonding
to
the
pot
containers.
So
if
you
take
a
network
or
it's
bounded
to
the
port,
it's
not
your
container
at
the
end
of
the
day.
So
both
the
proposal
considered
the
network
has
a
kind
of
resources
for
the
containers.
If
you
device
plug
in
is
basically
does
the
resource
allocation
for
the
containers,
it's
not
doing
for
the
port.
D
If
you
have
two
Network
containers,
currently,
the
none
of
the
div
a
device
plug-in
proposes
is
addressing
that
issue
so
for
which
container
is
going
to
invoke
that
network.
Currently,
like
I
I,
think
that's
a
major
gap
I
seen
in
the
booth
proposal.
They
are
considering
the
network,
resources
or
logical
network
or
overlay
network
as
a
container
thing,
and
not
a
support
thing
or
shared
with
resources
between
the
containers.
B
D
It's
bring
back
to
me
the
same
thing,
which
my
guest
posted
like
this
week
about
the
unification
of
I,
just
added
in
the
last
argent
Artic.
What
is
the
idea
on
unification
of
device
and
network
plugins,
whether
we
want
to
go
for
some
kind
of
network
manager,
so
that
will
take
care
of
doing
the
networking
or
we
are
rattling
on
some
mother's
wrong
model
of
doing
the
networking.
D
The
in
debates
plug-in
cases,
that's
a
huge
gap,
I'm
thinking,
because
if
you
go
for,
if
you
consider
network
as
a
resource
right,
if,
for
example,
if
you
take
s
or
IV
right
in
case
of
D,
pre-k
or
user
space
things
there
s,
our
AV
network
is
considered
as
a
resource
per
container.
It's
not
per
pod.
So
I
think
that
the
that's
where
this
confusion
comes
in,
whether
the
network
is
a
pod
resource
or
the
container
resource
or
which
model
we
are
going
to
take
that
one.
C
It
does
seem
a
little
bit
odd,
I
think
it's
actually
a
proper
issue
to
bring
to
a
whole
device
plug
in
anywhere
right.
The
question
of
whether
is
something
is
specific
to
the
container
or
the
pod
I
doubt
that
that's
unique
to
networks
right
there
might
be
devices
that
are
like
storage
volumes,
I
think.
F
F
Full
priority,
but
surely
but
further
I
mean
in
the
whole
solution
for
the
multiple
networks.
What
we
can
do
is
that,
when
a
pot
as
the
annotation
that
requests
a
network,
what
we
do
in
an
animation
control
could
be
that
we
create
a
site
card
that
will
request
this
resource,
so
the
resource
will
be
requested
by
any
container.
It
will
be,
and
just
an
annotation
of
the
boat
and
some
ammunition
position
controller
would
create
the
site
container.
Let's
go
ask
for
ask
for
the
resource
and
to
be
bring
into
the
network.
F
Namespace
and
I
was
thinking
about,
like
for
the
logical
and
towards
the
scheduler,
might
be
beneficial
as
well,
because
if
we
have
run
the
resource,
floral
ovn,
then
let's
say
temporarily,
because
they
are
not
unlimited
resources.
We
have
thousands
possible
connections
to
this
overlay,
and
so,
if
there
are
100
what
requesting
this,
this
access
to
a
network
that
is
in
this
overlay,
it
can
be
scheduled
on
multiple
nodes.
So
it's
balanced
across
them
right
because
there
is
the
total
bandwidth
on
each
node
for
the
overall
is
limited.
C
C
F
Yeah
right
and
saying
that
I
mean,
if
so,
the
Oviatt
use
just
wind
our
face
for
all
for
the
over
light.
So
all
those
networks
will
share
this
one
interface
and
by
using
using
one
resource
for
all
those
networks,
it
would
balance
a
moment
or
what
network
it
is.
It
would
still
runs
the
whole
overlay,
not
individual
networks
and.
C
I'm
just
saying
that
that
same
effect
obtains
in
kubernetes
today,
even
without
any
virtualization
or
overlays.
Typically,
there
is
one
network
interface
that
is
used
for
I/o
for
all
the
pods,
and
so
there
is
still
a
question
of
potentially
managing
the
bandwidth
on
that
one
network
interface,
even
without
anything
we're
discussing
it's
a
separate
question.
All.
F
B
By
the
way,
getting
back
to
your
initial
question,
better
I
think
one
option
is
actually
to
represent
the
ovn
connectivity
as
a
single
resource
and
then
providing
the
details
for
the
Obion
as
a
pod
annotation.
But
this
actually
depends
on
the
open
question.
If
we
can
provide
the
pod
details
to
to
the
device
plugin,
that's.
F
B
Honest
I
hope
that
we
can
that
this
issue
will
be
addressed
by
looking
at
the
device
plug-in
API
like
we
have
seen
request
from
for
multi
use
cases
about
providing
some
kind
of
generic
key
value,
pairs
attached
to
resources
or
resource
requests
and
I.
Think
that
this
point
about
you
know:
infinite
resources
or
an
infinite
number
of
networks
for
a
given
resource,
I
mean
I,
don't
want
to
say,
could
be
resolved,
but
there's
at
least
the
opportunity
to
see
that
we
could
use
such
generic
mechanism
to.
F
Maybe
I
mean
many
people
ask
further
like
so
the
what
idea
is
pass
to
allocate
call
and
that
would
give
us
a
tool
to
obtain
a
name
attribute
that
around
the
pot
asking
for
or
in
the
network
object
that
specific.
If
the
attribute
that
specifies
the
logical
network
is
in
the
network
object,
we
can
look
it
up
if
we
get
the
odd
ID,
so
the
device
plug-in.
F
And
I
was
just
saying
that
if
we
let's
say
we
have
the
miss
Burke
object
and
it
asks
for
the
resource
ovn
and
it
specifies
the
network
name
right.
So
if
we
get
and
allocate
call
it
body,
we
can
look
up
the
network
that
both
asks
for
and
then
in
the
network.
We
will
obtain
the
note,
the
resource
and
the
specific
network
that
it
asks
for.
So
it's
just
some
hack
and
it
would
allow
us
to
have
this
key
value
pairs.
F
C
B
I
just
want
to
say
think
as
far
as
I
understand,
while
Peter
is
saying
that
should
also
work
for
multiple
networks,
because
effectively
we
would
have
an
annotation
which
is
either
listing
a
single
network
or
multiple
networks.
I
mean
that
the
de
facto
standard
which
is
being
discussed
and
if
the
device
plugin
has
the
ability
to
read
the
pod
details.
However,
through
what
mechanism,
then
we
can
either
read
a
single
or
multiple
networks,
I'm,
not
seeing
difference
there.
C
Everybody,
the
issue
is
now
we're
calling
the
device
manager
to
allocate
to
choose
by
individual
devices
before
it's
going
to
be
called
multiple
times
for
the
same
pod.
To
choose
individual
devices
right,
someone
needs
to
the
most
natural
approach
would
be,
someone
has
to
remember
which
device
they
cut
in
at
and
allocate
combini
was
for
which
network
attachment.
C
D
C
B
And
yeah
India
today,
that's
true
and
that
the
question
that
can
be
changed,
because
we
could
also
say
that
if
there
was
something
like
no
parameters
or
attributes
to
resources-
and
it
would
be
a
single
call
where
the
attribute
then
would
contain
the
list
of
networks
to
connect
to
so
we
would
say
take
that
SR
I
will
be
resource
and
passes.
It
permeated
the
networks
to
use
and
then
would
be
singled
out.
Okay,
cool.
C
E
E
A
C
D
I
think
it
yeah
I
think
the
network
plumbing
group
could
be
the
right
choice
for
you.
I
am
sing
through
your
presentation.
I,
like
the
idea,
I
think
by
next
plumbing
working
group.
I
think
most
of
them
could
be
familiar
with
your
area.
I
think
I,
don't
think
the
network
cig
group
could
be
the
correct
group
for
this
particular
idea.
That's
my
opinion,
so
you
can.
We
should
present
this
funny
in
this
group.
Actually
yeah.
A
Nice
yeah
thank
you
for
doing
that.
That's
excellent!
Alright.
That
being
said
that
we
still
have
a
few
more
items
on
the
agenda.
Do
you
guys
mind
if
I
move
on
here
from
putters
topic?
You
know
a
lot
of
good
conversation.
There
I
just
want
to
make
sure
that
everybody's
got
the
voice.
This
meeting,
all
right
great.
That
being
the
case
Carl.
Would
you
like
to
speak
to
the
training
mechanism.
D
Yeah
I
think
we
kept
a
lot
of
the
mechanism,
but
I,
don't
know
whether
we
missed
out
or
meet
at
the
chaining
mechanism
in
the
meta
plugin.
How
what
will
happen
if
you
want
to
do
some
chaining
mechanisms?
Currently
we
have
some
few
chaining
mechanism,
see
anyplace,
so
I
think
we
missed
out
that
one.
If
you
put
the
chaining
mechanism
plug-in,
has
configuration
in
the
network
Sierra
T's.
So
currently
it
will
support
a
contact
list,
but
it
won't
support
network
theories.
A
C
A
D
A
D
A
Think
it
might
be
one
of
those
things
that
we
intentionally
didn't
specify
to
leave
it
up
to
the
implementation
itself
to
decide
how
it
would
use
that.
But
there
is
a
hint
about
it.
It's
like
the
top
of
the
document
and
it
has
to
do
with
the
default
network.
So
there's
a
stanza
that
we
added
a
few
weeks
ago.
That
basically
says.
A
Well,
you
know
the
spec
is
set
for
a
while,
like
it
expects
that
we're
gonna
attach
to
the
default
network.
That's
used,
quote/unquote
default
Network
and
then
we'll
attach
to
the
other
side
car
networks
as
found
in
C
or
DS,
and
it
basically
says
that
default
configuration
can
be
specified
in
any
way
that
the
implementation
chooses,
and
so
it
could
be
in
its
own
configuration
which
I
would
assume
to
be.
You
know
at
CCI,
net
D,
config
file,
right
or
by
another
method,
but
yeah.
Maybe.
A
C
So
we
did
discuss
this
a
few
weeks
ago,
right
and
I.
Think
what's
going
on
here,
is
that
we're
trying
to
write
a
spec
and
that
has
a
little
broader
or
lifetime
and
scope
than
the
couplet
and
CRI
will
support
today,
because
today
the
couplet
and
C
are
I,
do
not
support
a
demon
model
that
does
have
to
run.
You
know
the
existing
C
and
I
plugin
mechanism.
It's
going
to
pick
one.
So
we
know
that
the
initial
conditions
are
going
to
be
a
better
plugin
and
they're
going
to
be
found
by
the
usual
mechanism.
C
A
C
Have
not
chosen
to
write
that
in
this
spec,
because
we
want
this
spec
to
have
a
longer
life
than
that
fact.
So
maybe
it
belongs
to
some
kind
of
appendix
or
addendum.
That
is
like
a
current
implementation,
consideration
or
a
roadmap
issue,
or
something
like
that
saying,
we'll
start
out
with
and
then
plug
in
it's
found
in
the
usually
and
yeah.
If
that
better
plugin
is
going
to
read
its
own
config
file,
that
will
specify
the
default,
and
you
know
later
something
else
can
happen.
A
A
A
A
D
So
I
want
to
talk
about
the
network
first
test
documentation.
He
captured
in
the
kubernetes
note
Signia
proposal.
So
there
is
a
proposal
called
kubernetes
node
performance
benchmarking,
so
they
trying
to
analyze
some
of
the
benchmarking
for
a
node
taking
to
the
consideration
of
the
CPUs
and
other
details.
So
in
that
is
the
interesting
part.
I
was
looking
it's
an
input,
performance
testing,
so
I
was
wondering,
like
whatever
we're
doing
in
the
network.
Plumbing
group
work
for
the
meta
meta
plugins
right.
D
This
particular
use
case
won't
be
capturing
our
network
performance
right
or
because
it's
in
kubernetes
for
Koopman.
It
is
just
a
single
interface
right,
so
it's
never
going
to
be
affecting
with
other
meta
plugins.
That
forum,
just
asking
like
there
were
a
group,
has
to
look
into
this
one
or
is
just
like
for
kubernetes
just
a
network.
D
D
C
A
D
Think
you
captured
that
one
I
think
I
was
thinking
about
this
Mike
five
points.
What
is
mentioned
in
the
sig
group,
so
I
was
thinking
about
that
one.
So
I
also
wondering
the
same
thing
with
the
database
plug
in
one
it's
unifying
or
it's
because
for
the
device
plug
in
it's
mostly
containers,
it's
not
pod
and
also
in
most
of
the
cases.
D
In
some
cases,
if
you
take
s
or
vbf,
if
you
go
for
some
pneuma
managers,
proposals
which
has
me
already
discussed
in
the
resource
management
working
group
in
this
case,
the
srvv
of
that
particular
network
is
bounded
to
the
content
is
not
bounded
to
ports
anymore,
because
the
pod
will
be
bounded
to
one
CPUs.
If
what
happens
if
the
network
card
is
bounded
to
another
node,
in
this
case,
your
performance
will
be
less
so
I.
D
D
Yeah
because,
but
if
you
take
in
not
not
I,
don't
think
that
I
am
keep
on
poking
this
eyesore
we
use
case,
but
the
thing
is
that
if
you
look
into
there
sorry
we
use
cases
where
you
represent
them
as
a
network,
but
in
some
way
they
are
not
only
Network
for
you
in
some
case
they
are
like
a
resource
for
the
container.
So
that's
one
of
the
cases
which
we
can't
fit
in
both
two
containers
or
in
the
pod
I.
C
Certainly
agree
that
you
know
the
network
stuff
is
at
the
pod
level,
not
the
container
level
I
again,
I,
not
convinced
that
it's
really
unique
to
networking
right.
The
storage
volumes
are
also
really
at
the
pod
level
and
in
general
multiplicity,
a
general
subset
of
the
containers
in
a
pod
have
access
to
a
given
storage
volume.
So,
yes,
it's
a
important
to
get
the
pod
versus
container
distinction
right
and
no,
it's
not
unique
to
networks.
C
F
C
C
So
I
noticed
in
the
release
notes
for
1.10
that
there
was
an
advance
on
this
topic.
There
is
now
such
prevention
for
a
couple
of
cases
involving
PVCs
I,
skimmed,
the
discussion
of
it
I
haven't
had
time
to
truly
understand
how
it
works,
so
I'm
not
sure
what
general
lesson
can
be
drawn
from
that.
But
if
someone
is
aware
of,
you
know
a
high-level
description
of
the
how
this
technique
works.
I'd
love
to
see
it
I.
C
Mean
there's
a
basic
principle
problem
here,
which
is
in
kubernetes
api.
You
can
only
do
an
atomic
transaction
on
one
object.
You
can't
have
a
multi
object,
atomic
transaction,
but
we've
now
got
some
things
that
prevent
that
they
preserve
referential
integrity,
more
or
less,
which
is
involve
some
multiple
objects.
So
is
there
you
know
kind
of
a
high
level
principles
based
this
description
of
how
that's
done
and
if
not,
I'll,
try
and
dig
it
out
of
the
discussion.
F
A
A
C
A
It
in
this
particular
case
to
summarize
basically
the
gist
was
it
was.
It
wasn't
necessarily
because
somebody
wanted
to
manually
assign
the
names
like
they
wanted
to
exactly
know.
The
name
was
going
to
be
because
in
by
one
viewpoint
you
could
go
to
the
results
object
and
you
could
pull
it
from
the
results.
If
you
needed
to
know
what
what
it
was.
However,
this
was
to
solve
the
unique
to
both
at
CNI
itself
uses.