►
From YouTube: Kubernetes SIG Network meeting 20210617
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
All
right
thanks
everybody
for
joining
this
is
the
network
plumbing
working
group
meeting
for
june
17th
and,
let's
get
it
started
with
some
of
our
regular
business,
feel
free
to
add
your
name
to
the
attendees
list
on
the
agenda.
If
you
haven't
or
if
you
care
to
it,
can
always
be
used
later
to
declare
your
candidacy
as
a
member
or
a
maintainer.
B
A
On
to
the
rest
of
the
agenda,
the
first
topic
is
one
that
was
carried
over
from
last
week.
I
was
hoping
that
we'd
have
adrian
c
on
the
call
who
added
hit
to
the
agenda
for
the
last
meeting.
However,
we
don't
have
them.
Is
there
anyone
on
the
call
that
would
like
to
comment
on
this.
It's
regarding
the
api
group
that
we
used.
A
A
Yeah,
absolutely
yeah,
if
you
want
to
just
give
an
overview
of
what
you
provided
on
the
agenda,
would
be
awesome.
C
Okay,
so,
let's
start
with
a
little
introduction,
slash
background
because
yeah
I'm
not
a
regular
participant
on
this
forum,
even
though
some
of
you
might
know
me
so
I'm
laventa
kali,
I
also
known
as
lavovar
from
github.
I
have
a
couple
of
projects
related
to
mostly
related
to.
I
don't
know
how
to
call
it
improving
resource
management
in
various
aspects
of
kubernetes,
namely
I'm
altering
denom
and
cpu
pooler.
C
C
Commodity
to
itself
and
went
a
little
bit
of
a
different
way
of
how
to
approach
certain
various
network
management
aspects,
and
we
see
that
it
kind
of
creates
a
friction
sometimes
so
we
have
multiple
cnfs
inside
the
company
and
also
outside
of
the
company
coming
from
third
party,
and
this
let's
say,
disparity
in
supported,
feature
set
or
just
the
disparity
in
through
what
apis.
These
features
are
available
through.
C
It
is
basically
a
recurring
topic,
so
I
was
thinking
about
how
we
could
address
this,
and
I
did
a
poc
recently,
which
kinda,
let's
say
validated
my
idea,
because
I
have
an
idea-
and
I
basically
came
here
today
to
present
this
idea
to
you
and
see
whether
you
are
receptive
to
it
or
you
are
interested
in
it
or
not.
So
you
know
just
to
have
a
discussion
about
what
I
have
in
mind
that
that's
it
as
far
as
introduction
goes
and
feel
free
to
interrupt
me
at
any
time.
A
I
you
know
you
might
as
well
jump
into
the
idea.
No
yeah
thanks
a
bunch
yeah
by
the
way,
it's
pretty
cool
that
you
guys
were
able
to
implement
a
network
attachment
definition,
and
then
that's
really
neat
and
yeah,
as
we
you
know,
can
find
some
common
ground
here
like
I.
A
I
know
that
we
can
have
some
synergy
between
the
work
that
you've
done
on
dan
m
and
what
we've
done
in
the
network
falling
working
group-
and
I
mean
personally,
I
know
that
there's
a
lot
of
rough
edges
that
you've
cleaned
off,
that
you
know
I've
seen
deficiencies
with
in
some
of
my
own
work,
so
yeah.
A
To
see
you
know
how
we
can
find
some
common
ground
and
you
know
collaborate
so
yeah,
that's
awesome.
We
wanted
thanks.
C
Yeah,
if
it
wasn't
clear
from
the
introduction
that
that's
what
the
idea
is
so
some
collaboration
and
finding
the
common
ground
between
the
two
ecosystems,
I
I
I
would
like
to
use
the
word
ecosystem
because
I
kind
of
feel
like
this
is
what
we
have
today.
So
it's
one
thing
that
we
have
multiple
meta,
plugins
and
yeah.
It's
it's
not
a
secret
that,
let's
say
my
idea
about
how
meta
plugin
should
work
is
different
of
motus's
basic
design
principles.
C
I
kind
of
stating
cni
is
not
really
the
best
api
for
network
management
motors
clarified
it.
I
I
I
hid
it.
Basically,
that's
the
basic
difference
and
I
don't
necessarily
see
the
changing.
However,
there
is
a
lot
of
commonalities
or
similarities.
I
think
in
the
in
the
ecosystem,
which
was
created
around
these
meta
plugins.
So
from
my
perspective,
our
project
or
my
project-
I
I
wouldn't
say
it's
nokia's
project-
is
really
my
pet
project,
mostly
so,
let's
not
associate
it
with
my
company.
C
What's
the
fancy
name,
I
guess
I
should
use
the
word
operator
since
there
are
some
people
from
redhead,
so
let's
call
them
operators
and
the
good
thing
in
this
approach
that
any
functionality
which
is
implemented
in
in
this
way,
so
by
an
operator
while
it
currently
only
speaks
the
language
of
the
dynamic
apis.
C
They
are
already
somewhat
obstructed
away
from
these
specific
apis,
and
the
idea
would
be
that
if
we
would
simply
teach
these
operators
to
how
to
speak
other
apis,
namely
network
attachment
definition
and
whatever
api
definitions
we
are
having
or
you
are
having
under
the
network,
plumbing
workgroup
any
functionality
which
is
implemented
this
way
could
be
easily
reused
in
other
ecosystems
as
well.
For
example,
if
matus
happens
to
be
the
the
configured
meta
cni
in
a
given
cluster
and
the
poc
I
did,
that
was
with
one
of
these,
let's
say:
operators
or
controllers.
C
So
this
was
the
initial
idea.
I
wanted
to
validate
it
really
in
practice.
How
easy
it
is
to
do
it
in
code
and
stuff.
So
I
went
out
and
I
did
a
pr
which
I
also
linked
in
the
in
the
agenda
to
to
validate
this
concept,
that
pr
is
basically
an
addition
to
one
of
these
controllers.
C
I
have
four
which
I
think
there
might
be
some
re-user
opportunities,
so
I
basically
took
the
simplest
one
and
you
know
just
checked
how
easy
it
is
to
to
teach
it
to
talk
another
language
and
it's
like
basically
200
lines
of
code.
So
really
not
the
third,
and
what
I
achieved
with
this
is
that
I
really
just
needed
to
let's
say,
modify
or
or
expand
the
event,
vendors
or
the
api
handlers
at
the
top
level
of
the
operator,
and
I
I
didn't
need
to
touch
any
of
the
underlying
functionality.
C
So
the
code,
which
does
some
network
automation
tasks
and
we
can
deep
dive
later.
But
what
are
these
tasks
exactly
which
we
could
do
for
now?
What
I'm
trying
to
highlight
is
that,
by
doing
a
simple
api
enhancement,
I
think
it
would
be
feasible
to
port
some
of
these
functionalities
again
depending
on
interest
level
to
to
other
ecosystems
as
well,
namely
move
to
the
ecosystem.
C
Now,
if
this
is
something
which
this
community
would
be
interested
in
from
our
side
or
from
my
side,
garbo
appears
fear
free
to
interrupt
me
if,
if
I'm
saying
something
stupid
which
is
not
valid
or
legit
from.
C
C
If
we
would
go
ahead
with
this
project,
it
might
need
a
little
bit
of
modification
in
these
projects,
nothing
major.
We
can
discuss
how
much
it
would
be
and
if
it's
something
which
we
would
like
to
go
ahead
with,
then
we
could
also
donate
these
projects
and
work
on
them
together.
C
C
A
All
right,
no
yeah,
that
sounds
very
interesting
as
a
next
step
levante.
Would
you
be
willing
to
put
together
just
a
short
presentation
or
demo
I
mean
I
would
be
happy
with
whatever
format
you're
into
just
to
you
know
whatever
give
some
demonstration,
so
we
can
get
like
I
mean.
A
Your
description,
of
course,
is
very
good,
but
so
we
could
just
have
like
a
like
more
like
a
hands-on,
so
everyone
can
kind
of
like
see
in
action
whether
in
action
is
via
slide,
deck
or
via
terminal
demo
or
whatever
you
like,
and
hopefully
you
know,
generate
some
more
interest
and
then
educate
people
about
it.
A
And
then
we
can
put
it
to
a
vote
for
a
project
to
accept
as
part
of
network
following
working
group
and
I'm
more
than
happy
to
help
on
whatever
bits
and
pieces
to
you
know
get
it
moved
over
et
cetera,
and
I
guess
I
would
also
say
is:
we've
never
in
this
group
had
anything
other
than
a
unanimous
vote
and
usually
it's
because
people
are
pretty
good
at
like
sharing
idea
or
whatever
and
usually
get
people
get
the
sense
of
if
it's
gonna
fly
or
not
after
a
little
bit
of
of
discussion.
A
But
I
I
personally
see
a
lot
of
synergy
with
problems
that
we're
trying
to
solve
problems
you're
trying
to
solve
and
it
totally
fits
the
you
know,
mission
of
the
group
which
is
essentially
let's
you
know,
goal
number
one
of
the
group
is:
what
can
we
do
about
the
multi-networking
problem
in
kubernetes?
A
This
is
certainly
100
relevant
to
that
and
then
also
to
have
a
home
base
for
vendor
neutral
projects.
So
yeah
I
mean
yeah
I'd,
be
psyched
to
see
some
of
this
work
in
action.
Learn
it
a
little
bit
more
but
yeah.
That
sounds
good.
C
Okay,
so
how
about
how
about
this?
In
the
past
I
already
made,
or
have
a
couple
of
recordings
which
are
kind
of
like
handsome
demos.
So
if
you
are
fine
with
that,
I
think
I
can
go
ahead
and
check
these
now
in
these
demos,
it's
kind
of
a
mixed
bag.
C
So
in
some
of
these
demos
I
I
present
how
denim
works
itself,
but
I
also
present
some
of
these
features
implemented
as
controllers,
so
I
I
need
to
go
back
and
see
what
do
I
have
exactly,
but,
generally
speaking,
absolutely
not
an
issue
for
me
to
okay
together.
A
All
right,
yeah,
no,
that
sounds
awesome
and
yeah,
totally
fair
to
reuse
material
and
especially
if
that
makes
it
more
efficient,
and
I
guess
a
couple
of
ways
to
go
about
that
is
one.
You
could
send
some
pointers
to
those
presentations
on
the
mailing
list
and
you
know
point
out.
You
know
which
sections
would
be
used
like
relevant
for
the
like
common
ground
type
of
work
and
the
other
thing
is,
I
you
come
back
in
a
subsequent
meeting
and
and
show
them
in
real
time
too.
C
C
Stuff,
okay,
so
maybe
high
level
so
or
a
little
bit
lower
level.
So
we
are
talking
some
specifics:
functionality
wise.
We
have
four
operators
what
I
think
are
kind
of,
or
might
be
somewhat
interesting
to
you,
the
problems.
What
we
have
faced-
and
I
thought
with
these
projects
well
to
a
lesser
or
more
extent,
are
basically
four.
C
So
we
face
issues
with
automating
host
interface
management
with
some
kind
of
special
networks,
so
whenever
somebody
is
using
ipv
or
mac,
villain,
cni's
or
basically
any
other
cni,
which
includes
or
relies
on
some
host
interfaces
or
a
bit
being
created
on
the
node
with
them,
you
know
like
vlan
interfaces,
excel
interfaces
or
whatnot.
So
that's
a
recurring
issue:
how
to
automate
the
creation
of
these
host
interfaces
on
the
right
hosts
on
a
basically
api
driven
automated
manner,
so
we
have
an
operator
for
that.
I
think
that
could
be
one
of
the
interesting
stuff.
C
The
second
is
ip
management,
so
ipam.
Here
we
have
a
little
bit
of
a
difference,
because
I
strongly
believe
that
ip
address
allocation
should
be
an
integral
part
of
the
network
management
api.
I
think
your
ecosystem
also
a
little
bit
moved
towards
this
idea,
but
still,
basically
what
you
have
in
there
about.
I
have
it
integrated,
but
it's
kind
of
the
same
so
like
an
api
driven,
centralized
network
or
ipam
plugin
the
problem
with
centralized
api
driven,
ipam
plugins.
I
think
what
you
are
also
experiencing
nowadays
that
kubernetes
have
a
lot
of
failure.
C
C
C
But
more
often
than
that
we
have
experienced
that
ip
is
just
getting
lost
and
if
we
only
rely
on
releasing
ip
addresses
during
the
cni
that
operation
right
on
that
specific
node,
there
is
basically
you
can
never
be
sure
whether
you
need
to
release
something
or
not.
C
So
what
we
did
is
we
created
a
centralized
operator
which
is
running
on
the
manager
nodes,
so
it's
kind
of
independent,
a
little
bit
from
the
cni
life
cycle
and
it
kind
of
oversees
these
dangling
locations
or
like
policies,
these
dangling
locations
in
a
centralized
manner.
So
that's
what
I
call
cleaner
and
I
think
that
could
be
something
interesting
as
well
and
the
last
two
operators.
C
I
have
I'm
fairly
sure,
and
I
know
for
sure
that
you
also
have
some
work
in
the
area,
because
these
are
very
horse
topics
and
for
these
two
maybe
some
kind
of
a
merge
or
merging
of
functionalities
is
better
than
just
a
donation.
I
don't
know
we
can
definitely
discuss
it
once
we
are
through
these
demo
sessions.
C
One
topic
is
extending
the
kubernetes
services
concept
to
cover
multiple
interfaces
as
well.
I
know
that
we
have
a
little
bit
of
a
different
approach
to
this.
I
always
thought
that
the
service,
so
the
service
discovery
aspect
of
the
services
feature,
is
definitely
something
what
we
can
extend,
and
I
did
just
that.
I
don't
really
think
that
the
routing
aspect
of
the
kubernetes
services
should
be
universally
extended,
but
nevertheless
that's
something
we
can
discuss
later,
which
is
highlighting
what
this
operator
does.
C
But
that's
what
it
does
it's.
Basically,
you
can
create
secondary
interface
of
aircube
and
the
services
kinda.
C
The
first
and
last
is
same,
but
with
network
policies
that
that
could
be
the
short
summary,
so
some
kind
of
an
operator
which
universally
implements
software
based
micro,
segmentations,
firewalling,
absolutely
independent
of
what
is
the
underlying
cni
used
to
create
that
specific
interface
and
that's
a
huge
gap
which
we
see
for
a
long
long
time,
and
it's
always
coming
back
from
customers.
So,
and
I
know
that
for
the
last
two
years
I
have
some
projects,
although
I'm
not,
I
would
be
lying.
C
If
I
say
to
you
that
I
am
fully
familiar
with
the
full
extent
of
what
you
have
done
in
this
space.
I
know
that
you
have
done
something
there.
I
also
have
some
working
solutions
there,
so
these
these
two
could
be
aligned
in
my
opinion,
but
these
four
operators-
what
I
have
at
the
moment
and
I
think
which
could
odd
value
generic
use,
value
yeah
no.
A
This
is
really
cool,
there's.
Definitely
we
definitely
have
some
overlap
and
it
would
be
cool
to
see
where
this
kind
of
stuff
could
come
together,
and
you
know
we
do.
We
have
some
forward
progress
on
services
and
also
we
have
a
project
for
network
policy
and
on
secondary
interfaces
which
is
extensible
and
it's
covering
a
growing
number
of
situations,
but
still,
you
know
still
growing
so
yeah.
B
A
B
A
Quote-Unquote
interactive,
get
rebase
of
these
ideas.
Results
in
you
know
which
could
be
interesting
but
yeah.
This
is
really
great
stuff,
definitely
very
cool
to
hear
about
the
post
networking
operator.
I
that's
a
particularly
sticky
problem.
That's
really
cool
that
you
have
some
work
on
that
as
well.
So.
C
Yeah,
I
also
don't
want
to
give
off
the
vibe
like.
Oh,
we
have
done
and
solved
everything
which
is
out
there
not
really
the
first
three
operators.
They
are
kind
of
deployed
in
production
and
used
for,
let's
say
a
long
time
when
it
comes
to
the
boot
interface
firewalling
yeah,
it's
kind
of
the
same.
So
that's
more
of
an
offer
version
for
me
as
well,
and
it
implements
some
core
level
of
use
cases,
but
there
are
definitely
challenges
which
I
myself
also
haven't
sold.
D
So
may
I
ask
us
some
stupid
question.
D
Okay,
can
you
hear
me?
Yes,
please,
okay,
okay,
so
let
me
ask
so
so
the
yeah
I'm
looking
via
some
of
the
stuff
like
that
I
am
greener
for
ipam
stuff
and
then
I'm
also
think
feeling
that
this,
the
the
controller
is
pretty
depends
on
the
implementation
of
the
eye
pump.
D
I
mean
that
the
diamond,
cleaner
is
pretty
depends
on
the
iphone
or
the
diem
side,
so
yeah,
maybe
if
you
so
the
I'm
just
wondering
that
the
what
you
are
going
to
make
it
more
generalized
or
they
are
you
just
putting
this
stuff,
as
they
are
part
of
the
network
prompting
working
group
only.
C
So
if
you
are
specifically
talking
about
the
cleaner
to
some
extent,
you
are
right,
but
not
really
so
it
doesn't
really
depend
on
denim's
ipon
itself.
The
thing
is
that
it's
we
kind
of
made
it
plugable
already,
so
we
can
divide
it
into
two.
D
Yeah,
so
at
that
time
of
the
year,
I'm
just
wondering
that
the
implement,
so
they
are.
How
does
that
the
programmable
one
big
operator
or
the
two
small
operator
for
specific
implementation,
so
the
so
sometimes
the
the
big
programmable
application
it
seems
to
be
hard
to
maintain
right
yeah,
maybe
if
you're
good
at
the
some,
the
new
linker
or
the
llbm
link
of
the
compiler,
we
there
there's
lots
of
the
lessons
from
this
stuff,
so
maybe
yeah.
D
If
you
have
time
they,
maybe
you
you,
I
recommend
to
you
to
look
into
it
anyway.
They
so
so
there
may
be
that
this
is
the
design
thread
off
and
then
they
are
and
then
also
the
yeah
that
that's.
They
are
a
little
bit
concerned
so
for
now,
and
also
the.
D
I'm
looking
at
the
service
watch
as
well
and
then
there
seems
to
be
a
little
bit
different
from
the
the
current,
the
our
prototyping
from
the
design
or
the
networking
perspective,
so
so
the
yeah
I.
C
However
speaking,
what
I
had
in
mind
is
is,
first
of
all,
I
don't.
I
I'm
not
looking
to
remove
features
which
are
already
in
there.
What
I'm
looking
for
is
first
of
all
donating
and
then
extending
so
it
covers
more
use
cases.
D
Yeah
yeah,
I
yeah,
I
understood
but
sodium.
How
do
I
say
so
they're
extending
the
lots
of
stuff,
then
the
controller
needs
to
be
looking
to
the
various
cld,
and
then
this
makes
the
chaos
so
so
this
this
is
also
a
trade-off,
so
so
the
so.
As
far
as
I'm
from
implementing
the
barriers,
the
kubernetes
operator,
the
simple
operator
is
pretty
good
to
maintain,
so
they
are
and
then
they
are
so
there.
D
When
I,
when
I
be
implementing
the
sum
operator,
I
try
to
how
do
I
say:
try
to
reduce
the
kubernetes
objects
to
watch
as
I
could
that
that's
the
keeping
the
software
quality
and
then
the
rest
bugs,
and
then
they
are
making
the
user
happy
and
they're.
D
Also
me
happy
as
well,
so
so
that
that
that
that's
in
my
experience,
so
so
the
yeah
a
little
bit
there,
I'm
I'm
I'm
wondering
that
the
make
it
generalize
making
the
operator
complicated
so
that
that
that
that
is
acceptable
or
not,
that
that
is
the
not
the
how
to
say
just
for
software
architecture
was
a
just
a
performance
point
of
view
that
concern
not
not
the
community.
D
The
stuff
I
mean
so
they
are
yeah,
I'm
pretty
welcome
about
the
you
bringing
the
id
stuff
and
then
they
are
of
course
the
week
I'm
pretty
open
to
discuss
about
that,
but
that
that
is
still
my
concern.
So
yeah.
C
So
I
completely
understand
where
you're
coming
from
from
from
effort
perspective,
maybe
what
I
can
tell
you
that
I'm
basically
a
one
or
two
man
army
at
this
point
and
I'm
maintaining
all
these
four
operators,
plus
the
denim
core
alone
with
or
with
one
other
guy
or
maybe
stops
three
of
us.
C
So
it's
not
that
big
of
an
effort
when
it
comes
to
plugability
yeah,
it's
true
that
it
would
mean
that
the
crd
library
code
or
the
cid
generation
code,
multiple
of
those,
would
be
included
in
this
project,
but
the
whole
idea
behind
this
concept-
and
this
is
what
I
set
out
to
prove
in
the
poc-
that
this
is
the
only
code
part
which
we
need
to
branch
and
by
the
way
this
is
the
code
part
which
is
generated
anyway.
So
there
isn't
really
much
to
maintain.
C
D
Yeah,
but
so
they
are
reconciliation,
the
routine.
We
need
to
add
this
rivalry,
and
then
we
do
lots
of
the
processing
in
the
early
conservation
right.
C
Trying
to
say
that
be
behind
the
cid
code
are
the
functional
code
that
need
not
be
branched
regardless,
which
api
triggered
the
event,
so
that
that's
high,
imagine
it,
and
if,
if
we
look
at
it
from
this
perspective,
then
we
only
maintain
one
functionality.
C
C
But
again,
so,
let's,
let's
go
ahead
with
the
with
the
show
and
if
later
on,
we
see
that
something
is
more
complex
or
you
have
an
idea
how
it
could
be
done
better
or
more
simplified.
I'm
totally
open
of
you
know,
reworking
and
refactoring
and
cutting
up
into
multiple
pieces.
That's
not
an
issue
at.
D
All
yeah
and
then
also
that
I
I
don't
look
into
the
code
yet
I'm
I'm
just
looking
at
your
the
mentions
the
url
about
that
so
yeah.
Maybe
maybe
we
should
understanding
for
each
other
and
then
try
to
make
the
common
ground
for
that.
C
We,
if
we
have
the
the-
u
and
you
say
that
you
know
what
we
are
really
not
interested
in-
I
don't
know
operator
three
or
four.
Maybe
we
could
use
two
sure
it's
it's
open
buffet.
Let's
say
I'm
really
not
bothered
if
you
feel
that
something
is
is
not
possible
to
meet
common.
It's
just.
I
had
this
idea.
I
brought
it
in
here
and
let's
see
how
it
goes.
A
Cool
I
I
appreciate
that
and
of
course
you
know,
as
we
dig
into
the
into
the
details,
we'll
we'll
learn
more
about
you
know
which
things
merge
cleanly
or
don't,
etc,
but
yeah.
B
A
We
can
move
forward
on
that
and
we
can
start
to
hash
out
those
details
and
yeah
see
where
yeah,
where
we
can
merge
so
yeah.
I
appreciate
that
big
time
and
tomo
thanks
for
jumping
into
the
discussion.
That's
yeah,
there's.
You
know
important
considerations
to
make
with
all
of
this
and
you
know,
depending
on
the
projects
that
we've
had
and
the
efforts
we've
had
in
the
groups
too.
A
Sometimes
we
need
to
like
have
some
design
discussions
and
breakout
groups
and
documents
and
all
of
that,
but
we
can
figure
out
all
of
those
details.
I
think
that
yeah,
the
important
thing
is
thank
you
for
all
the
links,
the
context
and
yeah
as
we
move.
A
Steps
we'll
get
into
the
details,
so
sweet
any
other
commentary
on
this
topic
before
we
move.
A
A
All
right
excellent.
That
being
said,
the
agenda
is
complete
for
today,
so
it's
an
open
floor
for
any
other
topics.
E
Hello
guys
so
apologies
if
if
this
music
is
not
right
for
him
to
discuss,
but
I
have
raised
a
full
request
to
change
basically
mad
crd,
so
let
me
quickly
share
my
screen.
A
E
Yeah
so
a
while
back,
I
used
pr
to
basically
add
a
status
field
to
the
network,
attachment
definition
crd.
So
I
got
response
in
the
pi
itself
that
we
should
should
attend
the
meeting
and
propose
so
basically
here
we
just
trying
to
add
a
status
field
to
the
network.
Attachment
definition
object,
so
this
status
field
actually
allows
to
programmatically
access
the
status
information
so
which
is
a
more
in
a
cube
api
and
it
doesn't
break
the
functionality
and
it
is
an
optional
field.
E
So,
and
so
basically,
this
status
field
contains
two
things
so
state
which
can
be
successfully
pending
and
observation.
Any
message
can
be
there,
so
this
status
field
actually
can
be
used
by
any
controller
implementation
which
is
trying
to
whoever
is
trying
to
write
a
controller
for
the
mad.
Actually,
so
we
we
saw
this
in
our
use
case.
We
saw
this
as
a
value,
so
I
just
wanted
to
make
a
proposal
to
that
one.
So
yeah.
D
So
thank
you
for
your
the
proposing
that
this
stuff
so
yeah.
Clearly
you
are
right
way.
I
mean
that
the
the
so
currently
this
working
group
is
maintained
of
the
specification
of
the
network.
That's
the
definition,
not
not
only
the
the
client
library
also,
the
its
specification
is
maintained,
as
I
mean
that
the
different
google
doc
have.
The
network
has
definitions
specification,
so
maybe
the
you.
You
also
need
to
be.
Writing
the
specification.
D
Is
the
amendment
or
update
that
stuff
to
proceed
this
stuff,
so
so
that
that's
the
great
stuff
and
then
to
me
from
the
design
perspective,
I'm
a
how
do
I
say
I
have
a
little
bit
the
comments
on
that.
The
first
is
the
they
are
named
of
the
status,
so
the
maybe
that
this
so
the.
D
As
far
as
looking
the
pull
request,
this
is
so
this
status
contains
the
you
may
have
the
operator
for
the
managing
the
network
definition
and
then
the
to
reconsiderate
status
is
putting
in
their
status
right.
D
D
I
don't
know
what
what
does
it
mean
and
the
ipv9
is
fader.
I
don't
know.
Is
there
a
bit
bending?
Why?
Maybe,
even
though
the
srb
device
is
ready
and
then
the
device
blocking
working
for
that,
but
if
the
the
controller
putting
the
pending
stat,
then
the
user
is
misunderstanding
that
hey
the
we
we
create
the
port
with
srb,
and
this
works
fine,
but
why
this
status
is
pending.
D
So
maybe
the
you
may,
I'm
I'm
recommend
to
use
the
another
term.
I
mean
that
the
network
definition
operator
status.
What
is
the
that's,
the
one
stuff
and
also
the
I'm,
still
wondering
that
they
are
from
the
kubernetes
native
way
from
the
our
working
group,
as
well
as
the
other
working
groups
such
as
the
cube,
open,
kubernetes
or
obs.
D
We
we
are
using
the
annotation
field
of
the
cld
to
adding
the
various
information.
I
mean
that
the
malthus
use
motors
at
the
network
and
notation
in
the
port
object
and
they
also
the
qovn
added
the
network
information
into
the
annotation.
D
So
at
that
time
there
you
do
not
need
the
change
in
the
cld
and
then
you
can
easily
adding
the
your
your
information
as
you
want
to
so
so
the
so
so
that
that
is
the
also
the
how
to
say
so
that
once
we
changing
the
network,
that's
definition,
then
we
also
changing
the
version
and
then
also
version
conversion
needs
to
be
considered
to
all
other
components
which
looking
the
network
attachment
definition
so
that
that's
the
also
the
consideration,
so
there
may
be
a
yeah,
maybe
maybe
we
could
consider
for
next
version.
D
So
so
currently
we
do
not
have
any
plan
yet,
but
of
course,
once
we
get
the
various
concept,
of
course
we
need
to
thinking
about
the
next
version.
At
that
time
we
could
introduce
the
various
fields,
such
as
the
your
their
status
or
other
stuff,
but
also
the
before
that.
Maybe
it
takes
a
little
bit
time,
so
they
I'm
recommend
to
utilizing
the
annotation
field
for
first
and
then
the
then
you
can
achieve
your
your
things.
D
You
want
to
do
so
and
then
the
and
then
the
for
our
next
version
there.
We
could
thinking
about
to
introduce
that
this
concept
in
somehow
so
that
is
the
one.
D
F
Any
chance
you
could
tell
how?
How
would
you
use
this,
because
I
I
look
just
look
through
the
pr
and
basically,
that's
not
kind
of
obvious
you're,
just
adding
the
fields,
but
the
thing
is
with
the
with
those
states.
Those
are
cluster-wide
who
would
update
those
and
what
will
be
there
if
something's
wrong?
F
What
means
the
network
attachment
attachment
is
wrong.
What
does
that
mean?
Because
today
it's
it
is
used
by
every
pod?
If
one
pod
fails,
that
means
you
update
that
state
which
is
basically
not
correct
or
or
could
you
explain?
How
would
you
use
that?
I'm
not
sure
whether
you
can
exit
disclose
or
how
you
would
plan
to
use
this.
E
Yeah,
so,
basically,
in
our
use
case,
we
are
creating
some
object
depending
on
the
after
the
creation
of
the
ad,
so
we
have
written
a
controller
which,
which
basically
watches
the
mad
creations
and
application
all
the
events
and
it
in
in
the
reconciliation
logic.
We
create
some
other
objects
which
we
need.
So
if
those
objects
are
like,
we
cannot
create
those
objects.
E
So,
depending
on
that
result,
if
you
have
the
object
could
not
be
created,
we
will
just
obtain
the
state
like
success,
failure
or
something
like
that
pending
to
create.
So
this
is
our
basic
use.
Research.
D
And
then
also
they
how
so
they
are.
Maybe
you
also
could
implementing
the
somehow,
in
the
admission
controller
side,
to
prevent
the
error
state
right.
E
Yeah
as
a
book
using.
D
Yeah,
so
so
the
I'm
just
one
also
wondering
that
the.
Why
that
you
create
the
you
need
to
filling
the
error
state
in
the
network.
That's
the
definition,
so
so
the
in
so
the
our
working
group
is
also
serving
the
network,
attachment
definition,
admission
controller,
which
is
the
kind
of
the
validation
web
utilized
to
verify
the
cni,
so
so
that
this
means
the.
If
you
don't
want
to
add
the
invalid
cni
at
that
time,
the
user
cannot
add
invalid
cni,
because
the
admission
controller
is
reject.
D
So
so
there
may
be
a
utilizing
the
admission
controller
you
may
not
to
the
status
field,
which
is
error,
but
they
are
yeah,
so
the,
but
still
now
the
maybe
the
the
your
error
case
is
the
euro
operator
have
the
recognized
something
in
the
error,
but
also
their
network.
That
means
this
doesn't
recognize
that
the
network
attachment
definition
itself
is
in
error
right
exactly.
E
Yes,
basically
yeah,
so
it
is
not
as
a
as
such
as
a
validation,
so
we
wanted
to
create
some
objects
depending
on
the
you
know,
creation
of
the
network
attachment
definition.
So
if
those
objects
we
could
not
create
in
the
sense,
then
we
want
to
throw
the
error.
So
it
is
not
a
validation
is
kind
of
a
after
the
reconciliation.
G
Oh
okay
thanks,
but
but
I
think
this
is
not.
This
is
not
the
right
way
to
actually
return
an
error,
because
the
error
or
the
status
in
the
network,
attachment
definition
means
that
when
you
create
the
network
attachment
definition,
something
is
happening
underneath,
but
nothing
is
happening
underneath,
so
you
can
actually
return
an
error.
So
I
it's
it's.
It's
nice
to
return
some
status
of
when
you
create
those
objects.
Those
extra
objects
that
you
would
like
to
do,
but
I
don't
think
that
status
should
go
inside
the
network.
F
Yeah,
I
see
it
the
same
way.
That's
a
good
point
in
which
exactly
what,
because
you're
trying
to
in
in
what
you're
trying
to
do
is
impose
error
of
your
object
onto
an
ad.
That's
how
well
you
see
it.
So
you
have
some
problems
with
creating
your
your
own
object
and
you
want
to
put
error
about
that
inside
the
not
that's
not,
and
that's
not
related
right,
because
the
state
inside
a
network
attachment
definition
should
be
about
the
network,
attachment
definition
and
what
tomfool
just
mentioned.
F
H
B
H
F
F
Does
that
for
you
and
basically
it
will
reject,
apply
or
creation
of
that
object
directly
via
cube
api,
so
when
even
eventually
it
will,
it
will
reject
that
object
on
a
cube
cattle
level
or
if
you
have
a
go
client
and
then
it
will
or
some
other
kubernetes
client.
It
will
reject
at
that
point.
So
even
before
you
even
create
that
object.
So
that's
what
the
admission
controller
does
right.
B
So
basically,
what
we
do
is
we
create
a
virtual
network.
We
use
nad
to
create
a
virtual
network
and
associate
like
multiple
and
the
second
or
third
interface
of
the
pod
to
that
virtual
network.
So
we
want
a
state
wherein
to
know
the
status
of
that
virtual
network.
Otherwise
we
end
up
using
exposing
our
custom
crds
of
the
virtual
network
out.
So
so
we
thought
nad
would
be
a
already
existing
object
where
people
are
comfortable
with
and
propagate
the
status
up.
D
So
so
so
to
me
so
currently
the
euro,
the
concept
status
seemed
to
seem,
seems
to
be
the
of
only
for
your
solution.
So
currently
they
are
inside
the
in
the
community
as
as
a
hearing.
So
currently
we
do
not
have
the
status
and
then
yeah.
This
is
because
there
may
be
that
the
network
that
your
requirement
is
not
for
status
of
the
network
definition,
so
so
there's
so
currently
the
kubernetes
also
supporting.
As
I
mentioned
again.
D
Let
me
mention
again
so
the
kubernetes
have
the
annotation
field,
which
is
free
to
use
from
the
other
components.
So
you
can
easily
add
the
your
additional
views
in
the
annotation
and
then
there
that's
the
way
the
wii
motors
uses
the
annotation
and
then
the
open
kubernetes
uses,
and
also
the
lots
of
the
other
kubernetes
related
component,
utilizing
the
notation
field
to
keeping
the
application
original
information
to
the
kubernetes
object,
neuromedia
port,
also
the
crd,
so
so
the
and
also
the
in
our
community.
D
The
march
network
policy
also
utilizing
the
annotation
field
to
additional
information.
So
I
recommend
to
using
the
notation
field
to
putting
the
application
specific
information
to
the.
A
Object
yeah,
the
annotation
to
me
seems
intuitive
because
it's
not
governed
by
the
specification
that
we
maintain
in
this
group.
So
if
it's
possible
to
use,
I
think
that
that
might
be
a
good,
a
good
first
step
for
you
and
so
seeing
that
we're
starting
to
run
a
little
bit
lower
on
on
time.
I
think
maybe
we
could
start
to
look
at
some
next
steps
here
and,
from
my
perspective,
two
possible
next
steps.
A
The
use
of
the
admission
controller,
which
I
think
I
threw
a
link
into
chat
and
see
if
that's
a
possibility
to
use
or
extend
or
contribute
to
and
then
secondarily,
I
think
that
to
further
the
discussion,
what
we
typically
do
when
we
go
to
modify
the
specification
is
that
we
take
a
proposal
that
shows
which
sections
of
the
specification
would
be
changed
and
then
giving
the
reasoning
behind
those
and
I'm
gonna
paste
into
chat.
But
it's
also
in
the
agenda
in
case
you
didn't
get
it.
A
Let
me
paste
a
couple
links
into
the
agenda
here
or
into
the
chat.
So
this
is
the
agenda
and
then
secondarily,
this
is
example
spec
change
proposal
and
if
you
move
forward
with
a
spec
change
proposal,
if
you're
not
seeing
that
the
annotations
or
admission
controller
solves
your
case,
maybe
to
communicate
better
with
the
group,
you
could
start
on
a
proposal,
and
I
I
think
that
one
of
the
first
things
to
address
is
why
annotations
or
ignition
controllers
isn't
sufficient.
A
How
nashon?
How
does
that
sound?
Also
thanks
for
your
willingness
to
come
to
the
group
with
this
after
the
pull
request,
I
appreciate
that.
E
Yeah
thanks.
I
think
this
sounds
clear,
so
yeah
you
can
work
on
that
suggestions.
E
A
Yeah
no
problem
whatsoever.
A
That
being
said,
happy
to
continue
this
conversation,
if
there's
more
input,
but
we
are
down
to
five
minutes,
so
any
other
commentary
there.
Otherwise,
the
floor
is
open
for
other
topics.
A
All
right
sounds
like
we're
talked
through
for
today,
thanks
everybody
for
taking
the
time
to
today.
I
appreciate
it
and
yeah
thanks
for
all
the
collaborative
conversation
here,
it's
good
stuff,
we'll
catch
you
all
in
two
weeks,
which
will
be
july
first
and
we'll
catch
you
soon.
All
right!
Thanks
everybody,
bye-bye
thanks.