►
From YouTube: Network Policy API Meeting 20210621
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).
B
A
Thanks
everyone
for
coming
today,
it's
june
21st
2021.
This
is
a
meeting
of
the
sig
network
policy,
api
subgroup
of
sig
network.
Remember
this
is
a
recorded
meeting,
so
please
be
nice
to
each
other
and
let's
have
a
good
productive
day
today.
So
I
don't
really
have
anything
on
the
agenda
to
to
really
talk
about
today,
so
feel
free
to
add,
as
we
kind
of
run
through
this.
This
first
new
item
I
did
want
to
get
a
shout
out,
looks
like
we
have
a
new
attendee
today.
Josh
bell.
C
Sure
yeah
no
worries
yeah.
I've
actually
been
to
a
couple
other
of
the
other
network,
sig
groups
of
subgroups,
and
so
I
I'm
a
network
engineer
myself
working
for
an
oil
and
gas
company
and,
as
we've
been
adopting
more
and
more
kubernetes
strategies
around
here,
I've
had
the
opportunity
to
go
to
kubecon
stuff
like
that
and
get
to
know
more
and
more
folks
in
the
community.
C
So
I'm
just
you,
know
kind
of
plugging
in
trying
to
trying
to
get
caught
up
on
some
of
these
newer
things
that
are
coming
in
and
looking
at
issues
that
are
in
the
bucket.
That
may
be
easier
to
pick
up
that
I
can
jump
in
and
do
some
do
some
triage
on.
If
there's
anything
so
I
figured
I'd,
give
it
a
shot
today
hop
in
here
and
see
what
see
what's
happening.
A
Great
awesome:
well
thanks
for
stopping
by
and
there's
definitely
places
for
you
to
get
involved
already.
If
you
want
to
check
some
stuff
out,
so
that's
awesome
cool.
So
I
want
to
rewind.
A
You
know
last
week
the
in
the
agenda
there's
the
link
for
the
network
policy,
v2
user
stories,
part
of
the
network
policy,
api
repo-
and
we
kind
of
were
discussing
that
last
week
and
wanted
to
iron
out
some
more
information
about
the
sorry
construction,
going
on
more
information
about
the
personas
for
each
user
story
for
network
policy
v2.
So
prasad
has
made
a
document.
You
know
revolving
around
this
and
around
some
of
the
other
v2
concepts.
So
it'd
be
great.
A
So
yeah,
I
don't
know
if
you
want
to
say
anything
else
about
that.
Prasad.
D
Yeah,
I
think,
andrew
that's
a
good
summary.
I
give
all
all
of
us
edit
permissions.
You
know,
please
go
ahead
and
you
know
edit
it
and
you
know
and
feel
free
to
comment,
and
you
know
I
will.
You
know,
try
to
coordinate
with
you
and
you
know,
try
to
get
answers
and
I
already
talked
to
you
know
pair
and
some
some
time
back,
and
you
know
you
know
with
you
andrew
yeah.
So
let's
you
know
keep
it
going
as
a
live
document.
D
A
B
Document,
that's
on
the
agenda
today.
A
A
Cool
that'd
be
awesome
and
and
for
newer
people
to
the
group
too,
just
a
little
background
I'll
share
my
screen
really
quick.
A
What
we're
doing
in
our
new
repo,
which
is
network
policy
api
under
kubernetes
6,
is
trying
to
document
user
stories
for
v2
and
also
cmp
cluster
network
policy,
so
open
to
you,
know,
review
on
those
cluster
network
policy
have
been
around
for
a
while,
so
we're
just
hopefully
finishing
up
review
and
getting
review
from
some
main
sig
network
players
soon
and
for
v2.
That's
brand
new,
so
just
starting
our
first
round
of
review
there
so
on
cmp
abash.
A
Is
there
anything
you
want
to
bring
up
this
week
around
cmp?
I
know
we're
kind
of
just
waiting
on
review
from
other
members
of
sig
network
still.
E
Yeah,
I
think
I
dm'd
a
few
folks
today
regarding
additional
reviews
and-
and
we
also
look
forward
to
the
external
network
discussion-
that
de
makin
has
put
on
agenda
for
this
week's
sig
network
and
that's
something
that
also
affects
cnp.
And
hopefully
we
can
get
some
conclusions,
at
least
on
from
that
aspect.
And
then
we
can
include
that
in
the
cnp
talk.
But
beyond
that,
there's
not
been
much
because
we
haven't
yet
gotten
any
new
feedback.
A
A
A
There
was
well,
I
guess,
they're
not
here.
There
was
some
effort
we
discussed
a
few
weeks
ago
to
bring.
A
The
network
policy
recipes
repo
over
to
let
me
pull
it
up,
so
you
actually
know
what
I'm
talking
about.
A
Yeah
another
member
of
google
said
or
suggested
that,
and
I
thought
it
would
be
a
good
idea.
So
I
don't
know
what
happened
there,
I'm
going
to
put
it
on
the
agenda
again.
So
if
someone
looks
yeah.
F
In
the
past,
I
haven't
put
on
twitter
that
he
wanted
to
donate
this
so
me
and
jay.
We
tried
to
reach
him,
but
we
got
no
answer.
It
was
like
I
guess.
Five
months
ago
we
can
probably
ping
him
on
slack
in
our
channel
because
usually
he's
he's
there
as
well
and
say:
hey,
we
we
want
to
to
to
to
fake
the
ownership
of
this.
If,
if
you
want
to
donate,
you
say
that
on
peso,
do
you
wanna
do?
Do
you
wanna
steal
to
the
eighties,
and
we
have
this
kubernetes
dash
seeds
and
we
can.
G
So
cool
one
thing,
though,
is
that
do
we
have
specific
ideas
for
enhancing
it
because
you
might
say
it's
already
complete
and
it's
you
can
just
put
a
pointer
in
the
network
policy
api
repo
to
saying
there.
F
F
C
F
B
E
Yep
yeah,
I
would
propose
to
all
headers
yeah.
I
would
propose
to
add
a
new
directory
like
samples
here
here,
where
we
have
like
sub
directories
for
each
different
apis
that
we're
trying
to
propose
and
the
one
which
is
already
present,
which
is
the
vm
network
policy
and
then
most
of
amit's
samples
when
recipes
can
be
merged
into
the
view
and
network
policy
and.
B
A
Yeah
cool,
so
that's
a
small
thing,
but
I
think,
as
we
contribute
more
to
this
repo,
we
should
also
figure
out
what
we
want
to
show
on
the
main
page
and
kind
of
spice
up
the
readme
and
just
make
it
a
little
prettier
since
we're
the
owners
of
this.
So
it's
kind
of
on
our
in
our
hands
and
as
we
keep
moving
forward
like
if
there's
any
other
network
policy
tools
that
want
to
be
hosted
upstream,
that
could
be
a
cool
place
for
it.
So.
G
On
that
note,
since
josh
mentioned
that
he's
a
practitioner
I
mean
josh,
do
you
have
some
real
world
implementation
examples
to
share
about
how
you
might
be
using
network
policy
in
your
real
world
deployments?
Or
are
you
not
at
that
stage
yet
so
we're
not.
C
C
At
that
stage-
and
that's
that's
why
I'm
I'm
trying
to
engage
a
little
bit
here-
is
to
bring
that
knowledge
in
so
actually
I've
just
pulled
up
the
site
while
we're
talking
here-
and
I
love
it-
I
haven't
seen
this-
I
haven't
seen
this
recipes
repo
before
so
I
just
can't
wait
to
show
my
team,
because
there's
stuff
in
here
that
we
could
we
could
use
so
as
we
go
through
it.
C
A
Cool
yeah,
that's
exactly
what
we
want.
I
mean
I
think,
having
that's
something
people
are
constantly
asking
for
is
like
recipes
and
examples,
and
this
is
the
only
the
best
one
I've
seen
and
if
we
could
start
you
know
collecting
those
in
an
upstream
centric
manner.
I
think
that'd
be
awesome
like
real,
real
use
cases.
So
great
thanks
for
commenting.
So
that's
all
I
have
for
today.
A
Does
anyone
have
some
other
stuff
they
want
to
talk
about,
or
do
we
want
to
give
the
time
back,
so
we
can
get
to
maybe
poking
around
at
the
v2
user
stories
or
poking
other
people
for
review
on
cluster
network
policy
or
checking
out
the
new
doc
prasad
nadeem
have
put
up
for
us.
A
H
H
I
mean
it
was
pretty
good
discussion
for
a
while
in
the
history
and
the
thinking
here
I
guess
is,
and
I'm
I'm
a
little
new
in
this
group
like
about
a
week,
is
that,
with
all
the
different
cni
implementers,
it's
kind
of
hard
to
be
able
to
tell
if
you
just
like,
for
example,
log
into
a
cluster
who
implements
what
version
of
the
network
policy
so
to
get
some
kind
of
upstream
and
andrew.
You
can
correct
me
if
I'm
wrong
here
to
get
some
kind
of
upstream
commonality.
H
The
idea
is
to
have
a
versioning
status,
which
would
so
you
could.
You
would
know
you
know
who
which,
which
cni
was
implementing
what
what
in
in
a
particular
cluster
and
there
could
potentially
be
two
cni's.
But
let's
even
assume
one.
A
So
it's
a
muddy.
This
is
a
muddled
cap.
First
of
all,
there's
two
problems
here:
there's
there's
network
policy
versioning,
which
is
one
and
then
there's
a
status
field,
which
is
two
at
its
simplest
form.
A
status
field
for
network
policy
would
set
would
signal.
Does
the
cni
have
the
correct
flows
programmed
for
this
network
policy?
D
H
Well,
they're
in
the
same
cap
and
the
thing,
but
the
problem
with
the
versioning
is
spelled
out
in
the
cap,
is
that
since
it's
third-party
cni
is
implementing
network
policy,
there's
no
real
way
to
version
it,
but
what
I'm
trying
to
figure
out
then,
is
exactly
what
does
the
status
refer
to?
If
there's
that's
the
harm,
let's
say
the
sternus
say:
startus's
status
is
yes,
I
implement
it,
but
what's
it
v2
v1.
A
Oh
for
this,
it
would
just
be
existed.
The
existing
network
policy
so
v1
this
would
be
an
augmentation
to
network
policy
v1.
Now
the
hard
question
is:
what
does
enforced
mean?
Does
that
mean
like
across?
How
can
you
generalize
that
across
cni's,
some
cni's,
it
may
mean
the
iv
tables
rules?
Are
there
other
cni's?
It
may
mean
the
the
ovs
flows
are
programmed
correctly
now,
there's
some
some
conversation
on
that
kept
around
like.
A
H
Ahead,
yes,
but
the
question
is:
if
it's
the
cni's
responsibility
to
implement
the
network
policy,
the
responsibility
here
is
just
to
say
whether
they
claim
to
have
implemented
or
not,
and
there
could
be
some
messiness
around
exactly
what
that
means
yeah.
But
we
can't
if
this
at
this
point,
we
can't
dig
into
what
the
mechanism
of
implementation
is,
because
that's
specific
to
the
cni
right
right.
A
So
we
have
to
somehow
if
this
was
ever
going
to
work,
so
the
reason
we
brought
status
back
up
in
this
meeting
was
there
were
some
calls
for
it
in
a
couple
different
places.
But
you
know
there's
also
a
lot
of
argument
against
having
it.
So
really.
I
would
one
just
wanted
someone
to
kind
of
look
dig
into
it
and
say:
is
the
status
field
possible
as
an
upstream
feature.
H
H
F
Is
the
discussion
that
that
should
be
made
on
it's?
It's
actually
what
what
is
a
network
policy
status
like
a
node
status
is
like
if
the
node
is
ready,
if
the
cubelet
is
ready
and
if
like,
if
it's
under
pressure.
B
F
Not
right
so
the
network
policy,
it's
it's
the
same
thing
of
of
I
will.
I
will
use
ingress
as
an
example.
Okay,
I
don't
know
if
ingress
got
its
status,
I
guess
it
does
and
the
only
status
that
ingress
gets.
F
I
might
be
wrong,
but
that's
the
external
ip
of
that
inverse,
but
some
somehow
what
adds
what
adds
that
status
is
the
ingress
controller.
So
if
you
create
an
ingress
controller
that
doesn't
provide
that
doesn't
fit
back
the
api
with
that
information,
that
information
is
going
to
be
empty
blank.
So,
in
my
opinion,
I
think
that
status
is
important.
F
It
was
asked
in
a
cat
for
me
like
yeah,
so
how
can
you
say
that
that
that
network
policy
was
programmed
correctly
or
not,
or
that
the
the
the
cni
understood
that
correctly
or
not?
So
one
thing
that
we
should
probably
bake
with
that
cap
is
split
that
in
two
and
say:
okay:
hey
now
we
need
to
add
the
status
field,
the
network
policy,
but
we
need
to
figure
out
the
cni
providers
what
what
they
understand
as
a
as
a
status,
because
this
was
an
ask
from
the
production
readiness
review.
F
E
Yeah,
I
agree,
and
I
think
and
in
inquiry
we
already
have
a
status
field
to
the
extended
under
policy
objects.
I'm
sure
the
other
cni
providers
probably
also
have
something
on
similar
lines
from
what
I
see
you
know
in
a
network
policy.
What
do
you
want?
You
want
certain
rules
to
be
realized.
You
have
a
set
of
rules
and
the
status
could
be
whether
those
rules
were
realized
correctly
or
not.
E
Now,
one
of
the
things
that
is
makes
it
harder
for
us
to
kind
of
give
a
status
at
that
granularity
is
because
you
cannot
uniquely
identify
a
rule
within
a
network
policy,
so
there
is
no
rule
identifier
for
it.
So
so
the
best
bet
is
you
know
if,
if
you
look
at
the
policy
object,
as
is
you
tell
them,
you
tell
the
user
that
the
network
policy
was
on
a
whole
was
not
realized
correctly
and
you
can.
E
You
can
give
some
sort
of
feedback,
like
you
know,
in
a
message
format,
but
then
you
know
if
we,
if
we
are
able
to
add
unique
identifiers
to
network
policy
rules,
which
I
think
should
not
be
that
difficult.
If
we
are
able
to
do
that,
then
we
can
give
a
more
granular
answer
to
the
user,
query
and
and
and
yeah,
and
then
you
know
we
can
build
on
top
of
that.
And
then
there
are
other
things
also
that
you
can
give
like,
for
example,
a
bit
bit
of
stats
and
metrics.
E
You
know
what
kind
of
packets
were
dropped
because
of
this
rule.
What
kind
of
packets
are
allowed
because
of
this
rule
and
that
that's
a
bit
more
advanced
use
cases
for
network
policy
and
that's
something
that
we
can
also
do,
but
you
know
provided
that
we
can
give
some
sort
of
ide
to
a
rule.
So
I
think
I
think
we
can
certainly
do
that
and
it's
not
something
that
would
break
anything
and
it
will
be
valuable
to
users.
At
least
we
find
that
it's
valuable
for
our
users.
E
So
I
I
think
it's
something
that
we
should
think
about
and
and
then
you
know
kind
of
decouple
it
from
versioning,
because
I
think
versioning
itself
has
a
lot
of
pushback.
Maybe
then-
and
it's
probably
not
as
clear
as
you
know
what
dan
wants
to
convey.
So
maybe
if
we
can
split
those
two
into
separate
caps
and.
H
Maybe
it
was
yours,
I
saw
a
comment
in
the
history
to
that
effect.
To
me,
it's
hard
to
understand
how
you
would
I
mean
this.
I'm
I'm
just
gonna
try
to
be
the
like
a
objective
broker
here,
because
I
understand
there's
many
can
be
many
people
who
are
connected
with
organizations
that
are
actively
creating
competing
cni's
for
kubernetes,
but
is
there
something
is
is,
would
it
be
easier
to
get
it
get
some
at
least
the
concept
accepted
if
it
was
just?
H
I
don't
know
if
at
what
point,
in
other
words,
there's
a
lot
of
detail
in
what
you
said
and
it
could
go
on
forever
before
we
got
agreement
if
they
kept
well.
Maybe
that's
what
we
want,
though.
H
Maybe
we
do
want
to
specify
exactly
what
that
status
entails
and
and
elaborate
the
policy
or
do
we
just
want
to
say
people
agree
that
there
should
be
a
status,
even
though
we
don't
really
exactly
know
what
component
of
the
policy
the
status
is
and
what
whether
the
status
means
it's
completely
implemented
all
nodes
supported
or
what.
E
I
think
I
think,
on
a
high
level,
I
probably
think
that
everyone
would
agree
that
status
would
be
something
very
helpful
to
at
least
give
the
user
some
sort
of
feedback.
Now
what
what
the
status
would
look
like.
That's
something
that
maybe
we
can
iterate
over
the
cap
and
see
yeah,
and
that's
something
that
I
can
also
provide
some
inputs,
because
we
have
some.
We
have
some
experience
with
it
and
you
know
anyone
on
this
call
who
also
has
some
experience,
can
also
provide
that
input.
E
A
Yeah
and
I
think
we
should
start
with
some
user
stories
tom,
I
know
like
dan.
I
talked
to
dan
briefly
about
it
the
other
day,
and
he
said
he
dropped
this
because
the
main
user
story
he
started
with
was
being
basically,
you
know.
He
wanted
a
network
policy
status
so
that
e2e
tests
could
know
for
sure
when
a
particular.
H
A
Too
right,
but
that's
that
proved
to
be
a
hard
use
case
to
fully
answer
with
a
status
field
because
of
those
weird
scenarios
so
say
there
are
each
week
test
cases
where
you
do
something
like
create
pod
and
then
create
network
policy.
It
doesn't
match
your
pod
and
then
you
modify
the
pods
labels
to
match
and
network
policy.
So
there
like,
there's
some
weird
hair
pins
or
like
word
corner
cases
that
are
hard
to
cover
with
the
status
field.
A
But
my
point
was
like
there's
more
user
stories
than
just
being
able
to
fix
the
uv
tests
like
the
cluster
admin
wants
to
be
able
to
see
that
the
cni
has
implemented
the
status.
So
maybe
we
start
there
see
if
we
can
like
kind
of
like
what
we're
doing
with
all
these
new
objects
is
like
start
with,
some
user
stories
get
the
community
to
agree
and
then
from
those
user
stories
you
can
like
determine
the
best
way
forward.
H
A
I
might
start
by
doing
what
we
were
we've
been
doing
for
cmp,
which
is
why
don't
you
just
go
ahead
and
get
some
user
stories
created
in
network
policy
api
and
then
from
we'll
get
some
feedback
there
and
you
can
move
forward
with.
You
know
a
v2
of
the
cap
from
the
response
there,
rather
than
like
jumping
straight
to
the
cap
and
having
to
go
back
and
analyze
the
user
stories.
I
don't
know
that
just
seems
like
the
workflow
we're
doing
now
across
objects.
It
might
be
easier
to
maintain,
but.
E
The
tom
I
pasted
a
issue
from
andrea
which
was
related
to
the
status
for
our
policies.
It
has
some
description
on
how
we
have
enforced
it
or
how
we
have
solved
that
so
you
know,
maybe
you
can
just
take
a
look
at
it
and
see
if,
if
that
helps,
you
version
out
your
your
status.
D
Yes,
sir
tom
and
andrew
and
abhishek,
I
I
think
you
know,
status
field
is
important,
so
you
know
each
cni
might
have
their
own
way
of
you
know
realizing
the
network
policy.
You
know
some
might
use.
You
know
rules,
and
you
know
whatever
abhishek
mentioned.
Some
might
use
the
other
things
right.
D
So
do
you
see
a
case
that,
like
you
know,
maybe
we
give
it
opaque.
You
know
one
is
the
transparent
right.
I
mean
I
agree,
then
it
has
to
be
crisp
and
you
know
what
each
status
error-
women,
let's
say
status
field
means,
but
you
could
also
have
opaque
information.
Where
cni's
can
you
know
inject
their?
H
Yeah,
no
vendor
specific
field
in
the
status
and
so
like.
Well,
you
and
one
would
think
that
if
they
had
say,
for
example,
silium
running
here
they
and
their
pod,
they
would
no,
they
would
know
it's
running
and
maybe
go
check
additional
status
or
if
it's
someone
else's
cni,
but
it
might
be,
we
may
never
get
done
if
we
try
to
incorporate
all
the
different
kinds
of
things
that
can
come
from
every
cni,
exactly
yeah.
H
A
I
think
you're
totally
on
the
right
track.
I
would
go
investigate
deep
deeper
into
like
existing
status
fields
around
kubernetes
and
maybe
yeah
if
you
can
find
some
prior
work
and
then
start
thinking
about
user
stories
and
then
from
there
be
able
to
take
what
you've
learned
and
maybe
rework
the
cap,
but
I
think
you're
on
the
right
track
and
obviously
thanks
for
working
on
this.
This
is
awesome.
I.
A
A
No,
but
it's
good
someone's
picking
this
up
so
as
you
keep
going
feel
free
to
ping
us
in
the
channel,
and
you
know
we'll
keep
talking
about
it.
A
H
A
It
was
a
little
bit
of
time.
It
was
a
little
bit
of
I
think
dan
was
just
kind
of
over
the
bantering
on
it,
which
happens
sometimes
with
caps.
So
anyway,
cool
well
thanks
tom
again,
and
does
anyone
have
anything
else?
They
want
to
bring
up.
A
And
on
that
note,
awesome
well
short
meeting
today,
we'll
give
everyone
30
minutes
back.
Remember
those
three
things
we
want
to
start
processing
now
we
have
even
more
stuff
to
talk
about
every
week,
which
is
awesome.
So
thanks
for
joining
today
and
feel
free
to
add
stuff
the
agenda
for
next
week
and
otherwise
have
a
good
week.
Everybody
I'll
talk
to
you
later.