►
From YouTube: Network Policy API Meeting for 20230328
Description
Network Policy API Meeting for 20230328
A
Awesome
hello:
everyone
today
is
Tuesday
March,
28
2023.
This
is
a
meeting
of
the
Fig
Network
policy,
API
subgroup
to
stick
Network.
This
is
a
cncf
certified
meeting,
so
please
be
nice
to
each
other
and
yeah.
Let's
have
a
good
one.
Today,
hopping
right
in
I
see
some
new
folks
on
the
call
Igor
or
Sarah
Swami.
Do
you
want
to
give
kind
of
a
quick
intro
while
you're
here.
B
Yeah
definitely
interesting
so
yeah.
Thank
you
very
much
for
providing
access
to
this
meeting.
I
get
acquainted
with
this
whole
infrastructure
of
seek
networks,
Google
Nature's
groups.
After
the
latest
scale
conference
you
know
scale
South,
California,
Linens
export,
which
took
place
a
couple
of
weeks
ago.
I
gave
a
talk
on
at
the
conference
on
how
we
migrated
to
kubernetes
at
San
Diego
super
computer
center.
That's
basically
where
I'm
working
and
I'm
in
a
small
group
in
within
the
whole
thing
responsible
for
our
csvpgb.
B
B
This
world
and
as
I
along
the
way
of
Designing
that
platform,
my
Baptist
into
several
issues
and
limitations,
specifically
with
an
Ingress
and
then
I,
met
us
on
whom,
from
Google
on
the
scale
conference
talking
about
the
Gateway,
API
and
I,
said
well.
That
might
be
a
great
opportunity
for
the
scientific
world
to
be
a
part
of
the
kubernetes
community,
and
since
we
have
especially
as
a
scientific
world,
we
have
very
sometimes
very
different
requirements.
For
let's
say
kubernetes
platforms
or,
for
instance,
depend
on.
B
If
you
were
influenced
in
some
kind
of
a
huge
physics
experiments
and
you
would
gets
a
tons
of
data
and
you
want
to
then
somehow
was
protested.
It's
let's
call
it
the
batch
work,
so
we
can
just
drop
it
into
all.
Whatever
cluster
you
have
and
and
just
do
a
lot
of
stuff
with
the
data,
and
then
you
give
you
the
result.
So
it's
a
little
bit
different
from.
Let's
say
you
can
just
run
a
web
server
on
this
sub
style
and
another
aspect
of
my
life
is
control
systems.
B
So
some
software,
which
operates
the
scientific
instruments.
Let's
really
just
a
bunch
of
custom
made
Hardware
that
might
exist
like
where
only
a
single
Exemplar
on
the
planet
and
also
I
see
a
lot
of
possibilities
using
kubernetes
in
that
field,
so
I
hope,
I
might
kind
of
use
or
provide
the
usual
input
from
from
those
fields.
B
A
C
A
Excellent
It's,
a
Love
new
faces
here,
I'll,
go
ahead
and
post
the
agenda
document
our
meeting
chat,
so
you
can
kind
of
see
what
we've
been
doing
find
some
more
useful
links
there.
This
meeting
specifically
is
mostly
around
Network
policy
and
accompanying
apis.
More
specifically,
we've
been
working
on
admin,
Network
policy,
which
is
a
global
version
of
network
policy,
so
that's
kind
of
what
you're
going
to
hear
more
about
today.
A
B
D
The
first
one
is
pretty
straightforward.
We
talked
about
this
in
the
previous
meeting.
We
wanted
to
clarify
how
the
relative
order
of
residence
would
look
like
for
the
rules
within
the
Ingress
in
egress
array.
It's
just
a
dog
change,
I'd
say
the
second
one
which
we
might.
We
might
want
to
talk
a
bit
on
that.
D
We
had
an
issue
around
this
right,
like
I,
think
Dan
Winship
opened
it
initially,
and
then
we
had
a
discussion,
but
what
this
PR
essentially
is
doing
is,
and
maybe
yeah
this
might
be
of
interest
to
you
too.
We
are
removing
the
namespace
relation
all
together
because
we
don't
seem
to
have
use
cases
for
it
at
least
now,
but
that
doesn't
mean
that
we
can't
add
it
back
in
beta1.
D
If
we
want
to
do
some
kind
of
hierarchy,
relations
in
the
future,
like
a
parent
child
which
I
think
was
the
initial
use
case
for
it.
But
just
now
the
way
it
is
it
just
seems
like
we
are
expressing
or
using
it
to
express-
and
it
is
self
and
not
itself
with
namespaces,
but
then
that
can
be
done
using
the
same
labels
and
not
same
labels
anyways,
so
it's
kind
of
redundant.
D
So
this
changes
that
and
then
I've
also
added
more
clarity
to
the
description
of
same
labels
and
not
same
labels,
because
there
seems
to
be
a
lot
of
confusion
on.
Is
it
the
key
batch
or
is
it
the
value
match?
Is
it
a
both
key
and
value
match
and
all
that
so
I've
tried
to
clarify
that
a
bit
so
I
know
it's
feeling
CI,
but
I'll
fix
that
cool.
E
A
A
That
sounds
good
to
me.
Thanks
for
tackling
that
Surya.
Do
you
I'm
wondering
if
there's
somewhere
in
the
website,
we
can
add
a
note
on
like
or
maybe
if
we
could
add
an
example
to
the
website
for
like
a
best
practice.
So
just
in
this
PR
you
can
say
you
know
we're
removing
namespace
relation,
but
if
you
want
to
do
this,
just
use
the
well-defined
namespace
label
just
so
that
it
doesn't
get
lost
in
the
weeds.
A
Awesome
more
more
info
can
be
found
on
the
pr
itself.
Okay,
so
those
are
two
PRS
that
need
some
more
of
you
they're
on
my
list
to
do
it.
I
have
to
get
back
to
absolutely
stuff
this
week,
I
haven't
had
much
time
lately.
I
did
open
a
new
project
which
I'm
still
getting
sorted
out,
which
we
can
use
to
kind
of
track.
The
issues
we
need
to
get
to
Beta
I
know
we're
still
ways
away
right,
but
we've
been
having
a
lot
of
discussions
about.
A
You
know
additional
use
cases,
problems
with
U1,
Alpha,
One
et
cetera,
et
cetera.
So
if
we
could
just
start,
you
know
tracking
any
of
those
issues
that
come
up
here.
That
should
make
our
life
easier.
Again.
Inspiration
was
fully
taken
from
the
Gateway
API
fiction
and
Mike
so
yeah.
If
there's
new
issues,
I'm
pretty
sure
folks
here
can
assign
an
issue
to
a
project,
if
not
just
ping
me
and
I'll,
do
it
happy
to
help
there.
G
A
A
D
A
That'll,
be
it
yeah,
so,
as
you
do
more
work,
Nadia
I
I
can
help
you.
There
eventually
we'll
get
you
as
part
of
a
the
kubernetes
org
as
a
member
of
kubernetes
org,
and
then
we
can
just
open
a
PR
to
add
you
to
kubernetes
six
for
everyone
here.
You
no
longer
have
to
like
make
a
separate
request
issue
that
they're
saying
like
just
become
a
member
of
kubernetes
or
proper
and
then
open
a
PR
to
add
yourself
to
kubernetes.
Six
and
they'll
just
accept
it.
A
A
This
stems
all
the
way
back
to
kind
of
the
design
of
the
IP
blocks,
collector
in
network
policy
and
the
fact
that
we
didn't
really
like
it,
and
there
were
a
lot
of
unclear
semantics.
So
we
really
wanted
to
put
the
time
and
effort
into
designing
something
that
might
be
better
or
at
least
designing
an
API
around
psychic
North
South
traffic.
That
was
very
explicit
in
many
ways,
and
so
we
tossed
this
to
be
kind
of
reopened
after
our
V1
Alpha
One
release.
A
D
D
The
second
one
I'm
track
tattling
is
the
one
we
spoke
about
in
the
previous
meeting,
which
is
we
don't
have
a
clear
way
of
saying
whether
policy
is
applied
to
post-networked,
pods
or
not,
or
if
they
only
apply
to
regular
pods
or
in
we
just
leave
it
as
undefined
I
know,
Nadia
has
some
good
documentation
coming
up,
saying
it's
actually
undefined.
At
least
we
have
it
altharna,
but
I
think
we
should
well
at
least
for
the
new
API,
the
ANP
API
and
any
other
future
API.
D
See
if
this
makes
sense
and
leave
comments
and
reviews
happy
to
help
and
then
I
had
a
question
to
Andrew.
Actually
right
so
I
don't
know
what
the
process
is
here.
So
if
it's
really
like
I
think
we
should
get
this
in
the
V1
Alpha
One,
the
not
the
not
bomb
thing,
because
it
seems
like
a
pretty
required
use
case.
We
shouldn't
go
to
Beta
till
we
have
it,
but
I
don't
want
to
be
a
strong
advocate
of
that
right,
like
I,
can
be
convinced
both
ways.
A
Right
so
I
mean
I
think
we
can't
push
this
into
V1
Alpha
One
I
I
mean
I
would
defer
to
like
Shane
and
Dan,
who
have
a
little
more
experience
with
putting
these
apis
together.
But
this
is
a
fairly
large
like
user
story.
Slash
feature
ad
and
I
I
would
feel
kind
of
bad
I
know,
there's
probably
not
really
anyone
like
digesting
this
yet
but
I,
don't
think
it
belongs
in
review
on
Alpha,
One
I
think.
A
Maybe
we
could
do
a
V1
Alpha
2,
instead
of
jumping
straight
to
Beta
I'm,
all
right
with
that
as
well.
If
we
want
to
kind
of
get
more
feedback
on
north-south
traffic
selection,
because
V,
the
beta
version
is
kind
of
blocked
on
having
two
implementations
I
know,
we
have
two
implementations
in
the
works,
but
they're
not
done
yet
so
I
think,
let's
agree
on
the
use
cases
and
then
kind
of
decide
on
the
mechanism
for
release
I
put
on
to
decide
that
today.
D
A
H
Around
pretty
early,
what
we
do
right
now
is:
we
do
everything
kind
of
autonomously,
with
gaps
up
until
the
point
where
we
put
it
in
for
Sig
Network
review
Upstream,
which
happens.
You
know,
maybe
a
couple
times
a
year,
so
okay,
I
would
I
mean
Dan
can
chime
in
if
he
wants,
but
I
would
feel
very
comfortable
with
you
guys
kind
of
having
your
own
process
until
the
point
where
you
want
it
to
be
kind
of
reviewed,
Upstream.
F
Yeah
I
would
say
whatever
process
works
and
then,
like
only
do
one
new
cap
or
update
to
the
cap,
for
once,
you
decide
we're
ready
for
V1,
Alpha
2
or
you
know
B1
beta
one.
Whatever
then
do
a
cap
update
at
that
point,
with
whatever
the
sake
or
whatever
the
working
group
has
done
since
the
last
skip
update.
D
E
Oh
thanks,
so
I
I
think
I
should
have
I
should
post
this
on
the
on
the
review
comments
on
the
on
the
pr.
But
since
everyone
is
on
the
call
right
now,
I
just
wanted
to
clarify
things.
A
little
bit.
I
was
looking
at
sure
as
PR
on
the
same
and
now
same
labels.
Clarification
by
the
way,
thanks
sure
for
posting.
This
and
I
was
reading.
This
and
I
found
you
know.
What's
added
for
not
same
labels.
E
As
the
subject
of
the
policy,
which
is
a
little
bit
different
than
what
I've
imagined,
because
when
we
started
out
having
you
know
self
and
ourselves
or
same
labels,
not
same
labels,
we're
thinking
about
the
complete
complement
of
what's
being
selected
from
self
or
same
labels,
the
the
not
keyword
is
simply
to
provide
a
compliment
to
what's
being
selected
there.
Now,
if
we
have
two
namespaces
I'm,
just
taking
an
example
right,
so
one
is
say:
region,
U.S,
West
and
epicos
test
right
and
then
another
is
region.
U.S,
West
app
equals
production.
E
It
won't
be
selected
by
the
not
same
labels,
but
in
theory
we
would
want
that
right.
We
wish
we
would
want
the
semantics
to
be.
We,
if
somebody
put
let's
say
three
or
four
keys
for
the
labels.
As
long
as
one
of
the
values
differ,
it
qualifies
as
a
not
same
labels
or
am
I
the
only
one
who's
misunderstanding.
This.
D
That's
a
great
question
young,
so
the
definition
is
not
set
in
stone
per
se,
but
that
was
the
whole
point
of
that
PR,
because
we
still
need
to
clarify
it
and
when
I
read
the
initial
cap
and
the
documentation
I
thought
it
was
this
right
like
the
fact
that
all
the
keys
have
to
be
defined
and
all
the
values
have
to
be
different.
But
then
now
that
you.
H
D
E
Yeah
yeah
yeah,
I
I
can
definitely
but
I
just
wanted
to
bring
it
up
here
in
the
call
first
to
see,
because
since
we're
all
under
the
call,
if
anybody
has
any
opinions
or
who
thinks
that
the
other
way
around
might
work
better,
I
think
I'm
really
happy
to
hear.
But
you
know,
I
was
under
the
impression
this,
the
semantically,
it
would
mean
what
I
have
described
just
now.
D
G
Yeah
can
I
add
that
when
I
first
read
of
that
field,
right
I
was
mostly
thinking
about
that
the
same
as
the
label
selectors
that
exist,
and
there
is
an
operator
called
not
in
right
and
it
has
a
definition.
So
there
is
basically
a
way
to
say
something
similar
in
kubernetes
label,
selector,
so
I
think,
maybe
not
only
me,
but
some
other
kubernetes
users
will
think
in
the
same
term.
So
maybe
we
should
just
review
the
definition
of
that
label
selector
and
see
if
it
fits
our
goals.
G
I
think
yes,
I,
think
that's
what
it
says,
but
I
yeah
I
can
send
the
link
to
the
just
definition
of
not
an
operator
for
label.
Selectors
I
think
it
says
something
like
if
the
label
is
not
set,
then
it's
like
defined
as
not
matching
right.
So
something
about
that.
So
we
have
some
source
to
refer
to.
What
is
what
I'm
saying.
D
D
I
Bringing
this
this
up
basically
into
context
of
egress,
has
been
a
recurring
thing
that
keeps
coming
up
in
the
Gateway
API
gamma
meetings
that
meshes
are
interested
in
finding
a
way
to
support
through
gamma
through
the
gamma,
spec
and
I
would
love
to
hear
if
there
are
or
are
not
intersection
points
between
I'm,
a
network
policy
egress
and
service
special
egress,
and
if
there
might
be
then,
would
love
to
have
y'all
or
you
specifically
sorry.
I'll,
come
to
one
of
the
gaming
meetings
to
chat
about
egress
with
folks.
D
D
A
So
and
I
think
Mike,
like
one
of
the
big
things
with
North
South
traffic
in
network
policy,
that's
undetermined.
It
has
to
do
with
specifically
Ingress,
which
is
why
I
think
Syria
is
focusing
on
South
are
on
northbound
traffic.
Sorry,
because
you
know
in
ninety
percent
of
trait
of
cases
and
kubernetes
clusters
right
like
there's
some
Ingress
mechanism
that
may
be
doing
some
natting,
it
may
not
be
doing
natting
like
it
does
a
lot
of
different
mechanisms.
So
it's
hard
as
a
cni,
where
most
Network
policies
implemented
to
specify
the
behavior.
A
That
was
the
reason
we're
focusing
mainly
on
on
northbound
traffic.
Now
you
know
egress
service
service
mess
mechanisms,
I'm
not
super
familiar
at
all,
I'm
sure
there
might
be
for
some
overlap,
but
we
need
to
think
like
what
happens
in
a
world
where
Network
policy
is
implemented
by
two
different
things
like
no
longer
is
it
just
the
cni,
but
it
also
might
be
the
the
service
mesh
I.
A
Don't
have
an
answer
for
that
yet
and
that's
kind
of
why
we
left
out
focusing
on
Ingress
traffic,
so
I
don't
know
if
anyone
else
here
has
any
ideas
on
how
that
would
work,
but
yeah,
so
that's
kind
of
where
we're
at
I
think
it
does
need
to
be
explored.
It's
just
completely.
Uncharted
Territory
like
having
an
API,
it's
implemented
by
multiple
kubernetes
entities,
so.
F
A
Yeah
I
guess
it
boils
down
to
that.
So
if
there
was
like
a
feature,
we
added
into
the
API
that
specified
applied
policy
before
snap
or
something
before
Nat,
maybe
that
would
have
to
be
implemented
by
the
Ingress
mechanism.
Mesh
Etc,
I,
guess,
you're
right.
So
as
long
as
you
define
really
clear
boundaries,
it
makes
sense
foreign.
B
A
H
I
H
B
I
That
that
definitely
aligns
with,
like
my
thoughts
on
here,
oh
yeah,
like
off
the
policy
between
Services,
feels
like
there's
a
bit
of
overlap
with
admin,
Network
policy
and
this
kind
of
stuff
where
it's
like.
If
there
is
scope
that
this
project
is
intending
to
take
on,
that
would
be
really
good
for
us
to
understand
so
that
we
can
like
build
on
top
of
and
extend
potentially
or
integrate
with
or
defer
to
things
that
are
going
to
be
available
within
Cuban
this
project,
rather
than
having
varying
vendor
implementations
of
something.
I
A
A
Sorry
another
one
from
Syria
on
a
roll
this
week.
So
in
the
cap
we
had
some
bullet
points
on
graduation
criteria
for
outside
of
beta
and
I.
Think
this
issues
just
started
asking
some
more
questions
there.
I
know
it's
on
me
to
kind
of
go
back
and
help
answer
them.
Is
there
anything
you
want
to
try
to
go
over
right
now,
Surya.
A
A
No
worries
cool
yeah,
so
basically
I
think
this
is
just
good
to
kind
of
move.
Our
graduation
criteria
from
the
cap,
where
it
was
originally
created
to
an
issue
and
make
sure
that
this
is
actually
in
our
new
project,
which
it
is
so
just
looking
for
a
view
from
folks
opinions,
I
think
that's.
We
can
actually
look
at
it
right
here,
Alpha
to
Beta.
A
And
then
north
south,
so
so
we're
in
in
flight.
For
most
of
this,
the
one
thing
it
doesn't
have
any
notes
on
is
conformance
testing,
so
I
I'm
fairly
certain.
We
need
at
least
some
basic
conformance
testing
to
go
even
think
about
going
to
Beta,
so
that
should
probably
be
added
here
or
at
least
to
our
new
issue.
So
it's
good
to
think
about,
while
we're
kind
of
talking
about
all
these
new
proposals.
F
A
E
E
My
we
might
be
able
to
even
you
know,
share
some
of
the
test
cases,
but
I
definitely
reckon
that
you
know
test
cases
need
to
be
Rewritten
in
some
sort
of
like
format
so
that
it's
more
Upstream
conformance,
look
like
or
already
but
but
yeah
we
can.
Definitely.
You
know
talk
more
on
that.
It's
just
that.
You
know.
B
E
So
the
traffic
pattern
we
test
is
like
a
three
by
three
Matrix:
sorry,
a
nine
by
nine
Matrix,
where
we
have
three
main
resistance,
repositing
each
and
then
so
so
we
test,
you
know,
81
data
points
to
see.
If
you
know
each
pod
connection
is
what
we
expected.
I
think
a
tricky
part
is
that
because
we
I
was,
you
know,
looking
to
implementing
same
labels
right,
but
for
for
that
test
to
be
even
meaningful,
I
think
we
needed
at
least
a
couple
more
namespaces,
because
you
know
for
the
same
labels
we
want
to
see.
E
Are
these
two
namespaces
correctly
grouped?
Are
these
three
namespace
correctly
groups,
so
we
we
I
had
to
sort
of
like
expand
the
you
know
the
test
space
a
little
bit
to
to
verify
those,
but
in
general,
I
think
most
of
the
amp
amp
test
cases
have
a
pretty
good
idea
on.
You
know
what
you
know.
We
should
include
as
a
basic
set
of
conforms.
I
D
D
A
Well,
no
Yang
just
kind
of
mentioned
chuckled
like
how
do
we
quantify
this
I
think
we
added
scalable
here
due
to
concerns
over
you
know
implementing
something
with
explicit
priorities.
I
feel
like.
If
we
do
set
scale
targets,
it
should
be
somewhat
minimal
for
going
to
Beta
and
then
maybe
more
constrained
for
going
to
GA
as
to
like
how
we
quantify
that
I
don't
know
yet
so
I
think
it's
something
we
need
to
think
about
before
going
to
Beta,
but
it
shouldn't
be
like
a
huge.
E
I
I
I
do
have
a
question
since
we
have.
You
know
experts
from
maybe
other
apis
here
when
we
talk
about
scalable
implementation
or
you
know
as
a
graduation
criteria.
So
as
such,
how
do
we
actually
usually
look
at
you
know
the
the
scale
right.
Does
that
mean
that
the
API
needs
to
be
tested
in
a
environment
with
a
couple
you
know
a
certain
number
of
pause,
let's
say:
10K,
pods
or
namespaces
or
notes
or
or
wouldn't
actually
make
sense
for
the
API.
A
A
H
This
has
some
scalability
problems
for
our
implementation,
and
then
we
have
made
changes
accordingly.
I,
don't
think
we
currently
have
anything
that
isn't
resolved
in
that
category
today
and
we're
on
our
way
to
GA
so
I
that
that's
just
not
been
our
experience.
So
far
I
mean
there
is
always
infra
testing
for
or
whatever
that
can
you
know
you
could
set
up
things
but
I
guess
in
our
case,
one
of
the
problems
is
we.
We
can't
pick
a
favorite
implementation.
H
C
H
The
cluster
under
the
pop
Network
so
like
just
there's,
going
to
be
there's
such
extremely
different
needs
for
any
different
implementation.
That
scalability
has
been
something
we've
just
dealt
with
as
it's
come
up
and,
like
I
said,
I
only
remember
vaguely
like
a
couple
of
issues
where
somebody's
like
hey
this
would
be
a
problem.
H
So
I
guess
my
advice
is
just
make
sure
that
you
are
being
as
loud
as
you
can
and
pulling
in
as
many
people
as
you
can,
because
that's
how
we've
done
it,
we've
just
kept
engaging
with
as
many
people
as
we
can
and
building
up
engagement
so
that
everybody
every
stakeholder
that
needs
to
be
there.
We
have
20,
plus
implementations
and
three
Integrations
gets
the
hears
the
noise
when
we
say
we're
doing
something.
A
Yeah
100
I
think
we
could
do
a
better
job
of
being
noisy
and
in
terms
of
like
feedback
I've
only
gotten
one
person
to
reach
out
and
complain
to
me
about
scale
so
far,
and
that
was
Casey
from
psyllium
explicitly.
He
like
wanted
to
get
rid
of
explicit
priorities
which
was
kind
of
one
of
our
big
selling
points
for
amp,
which
is
one
of
our
biggest
selling
points.
But
since
then
I've
gotten
no
more
feedback
right
so
that
that
doesn't
happen.
A.
H
Lot,
yeah
conformance
testing
is
a
potentially
a
good
way
to
do
this.
Now,
we've
kind
of
done
this
backwards,
I
would
say
we
should
have
done
more
conformance
testing
earlier
and
we
should
probably
already
have
some
like
tests
that
kind
of
touch
on
scalability.
Like
hey.
Can
you
handle
this
many
routes
or
whatnot?
H
We
don't
actually
have
that
today,
but
that
is
something
that
we'd
like
to
have
learn
that
lesson
from
us,
and
maybe
you
know
have
that
earlier
on,
like
this
is
something
this
is
a
scale
that
a
conformant
implementation
should
be
able
to
handle.
Put
that
out
there
as
a
test
and
then,
if
somebody
fails
it,
you
know
figure
out
why
maybe
it's
something
they
have
to
change?
Maybe
it's
something
where
we
have
to
kind
of
be
like
okay.
Well,
we
got
to
dial
it
down
a
bit.
Do
this
during
the
alpha
and
beta
period?
H
A
100
percent
cool,
so
I'd
say
for
Alpha
to
Beta
Yang
like
let's
do
what
we
can
like.
Maybe
some
basic
you
know
scale
to
a
specific
number
of
amps
tests.
I
know
that
doesn't
factor
in
like
number
of
pods
in
a
cluster.
Maybe
we
can
define
that,
but
I
think
it's
important
to
think
about,
because
there
were
some
concerns
like
originally
in
the
API
about
scalability
right,
so
yeah.
A
G
Yeah
do
just
yeah
if
you
just
click
on
slides,
so
I've
asked
some
questions.
Last
time
now,
I'm
prepared
a
bit
better
I
have
some
pictures.
They
are
ugly.
I
didn't
spend
too
much
time
on
them,
but
hopefully
your
eyes
won't
hurt
too
much.
So
here
is
just
A
visual
representation
of
what
at
Network
policy
defines
right.
So
I
have
some
pods
I.
Have
some
letters
like
for
label
one
and
label
two
just
to
make
it
short
right.
So
pod
a
B
has
label
one
equals
a
label,
two
equals
B.
G
H
G
B
G
Okay,
I
hope
we
agree
here.
So
then,
if
you
move
to
the
next
slide,
I
did
a
picture
for
at
least
how
I
understood
the
same
label
selectors
right.
So
we
still
have
a
subject,
which
is
everything
that
Network
policies
selects.
But
then,
when
I
say,
I
want
same
labels
with
Label
2,
which
is
the
second
letter.
G
This
picture
is
what
they're
gonna
get
right,
so
I
have
a
subset,
so
the
subject
set
is
split
into
subject
and
subsets,
based
on
this
second
label
value
and
every
subject
subset
will
have
its
own
non-intersecting
peer
right
with
the
same
label.
Let's
say
so:
that's
what
I
pictured
here.
So
just
please.
Let
me
know
if
that
makes
sense
at
this
point.
E
G
E
I
think
that's
exactly
right
and
and
essentially
what
the
same
label
does
is
that
it
groups
the
subjects
based
on
you
know
the
the
label
value
right.
So
in
this
particular
case,
if
you,
if
you
just
look
at
the
second
label,
then
you
will
have
three
groups
basically,
and-
and
you
know,
the
the
three
actions
on
the
right
should
be
the
same,
because
I
would
imagine
it
will
be
in
the
same
rule.
E
Right
so,
let's
say
we
select
a
b,
a
c
a
a
and
b
b,
and
we
say
we
wanted
to
allow
same
labels,
for
example.
So
what
that
means
is
that
you
know,
as
you
pictured
here,
A
A
will
allow
connection
from
a
a
and
a
b
b
will
allow
connection
from
themselves
and
from
each
other,
and
you
know
the
last
thing
is
for
AC
right.
So
so,
essentially,
we
grouped
the
subjects
into
three
groups
based
on
their
second
label
value
and
I.
I.
Think
what
you
have
pictured
here
is
exactly
right.
G
G
G
So
then,
if
we
just
compare
these
two
pictures,
if
you
still
remember
the
first
one,
what
I'm
saying
is
that
so
what
happens
on
this
same
label
picture?
It's
just
one
peer
rule
that
creates
these
right
and
what
I'm
saying
that
that
that
is
maybe
not
a
peer,
because
if
we
look
at
the
yeah
it's
kind
of
here
so
usually
when
you
have
a
network
policy
or
admin
Network
policy,
it
has
a
subject
and
then
to
all
the
pods
from
the
subject
set.
G
They
all
have
like
the
same
set
of
peer
pods,
and
that
is
not
what
happens
when
you
apply
same
labels
or
not
same
label
selector.
What
happens
is
basically
new
admin.
Network
policies
are
created
with
a
new
subject,
which
is,
as
you
can
see,
the
same
subject
and
a
new
label
match
right
and
every
subject
has
its
own
peers,
which
is
usually
only
one
based
on
how
we
can
do
that
now.
F
F
G
G
G
G
If
it's
okay
to
move
on,
so
that's
what's
going
to
happen
right.
So
if
you
have
the
same
label
selectors,
that
is
what's
going
to
happen
based
on
which
pods
you
have
now.
So,
if
I
create
a
pod
with
label
1D,
there
will
be
a
new
instance
of
that
subject
to
peer
set
of
PODS
right,
which
is
basically
a
new
policy.
G
F
G
G
A
D
F
G
Yeah,
so
what
I'm
trying
to
show
here
with
these
pictures
is
that
if
we
see
the
network,
the
admin
Network
policy
as
just
this
subject,
which
is
one
big
set,
and
then
it
has
peers
which
are
some
other
sets,
then
in
its
sense
it's
the
subsets
that
are
defined
here
are
kind
of
the
same.
They
Define
a
subject
and
the
peers
for
that
right
and
then
also,
if
Andrew,
you
just
move
a
couple.
More
slides.
G
G
G
A
Okay,
so
I
I
s
I,
don't
think
like
I
agree
with
you,
and
what
do
you
think
is
wrong
with
that?
Are
you
worried
about
that
from
an
implementation
standpoint?
Are
you
saying
there's
a
better
way
to
express
this
so
that
you
can't
quote
unquote
to
still
a
single
amp
into
multiple
possible
amps,
because
that
was
kind
of
like
the
goal
here
right
was
to
make
us
that
we
didn't
have
to
have
the
user
writing
like
a
bunch
of
explicit
amps.
G
Yeah
so
I
think
well,
first
of
all
that
appear
with
with
same
or
not
not
appear,
which
kind
of
makes
it
API
wise,
not
really
correct.
Okay
and
then
the
other
thing
is
that
you,
there
are
some
ways
that
you
can
actually
use
that
and
optimize.
That,
and
also
another
point
is
that
we
know
that
tracking
this
status
of
network
policies
is
quite
a
pain,
and
then,
if
you
have
this
special
rule
that
actually
generates
its
sub
policies,
it
can
be
even
more
difficult
to
see
which
labels
are
already
reflected
or
not.
G
G
So
the
subject
is
dynamic
right
and
that
thing
will
generate
Network
policies
for
every
new
label
that
comes
in
then
we
can
have
a
very
simple
interface
for
admin,
Network
policy
itself,
just
with
simple
peer
selectors,
and
then
this
thing
will
actually
maybe
generate
the
real
objects.
And
then
you
will
also
be
able
to
see
for
which
label
in
your
cluster
and
your
network
policy
that
is
automatically
generated
is
already
created,
for
example
right.
G
So
it
may
be
a
bit
easier
to
also
track
it
like
in
the
status
of
it
and
if
it
exists
already
or
not,
and
also
from
the.
If
you
go
to
the
pre,
oh
there's
actually
yeah.
There
is
another
point
to
that
on
the
slide.
Seven
is
I'm,
not
sure
if
subject
like
as
from
the
current
implementation,
if
subject
makes
sense
in
general
right,
because
you
have
a
subject
of
the
network
policy
in
general
and
it
selects
some
pods
and
let's
say
pod
BC
is
not
selected
as
a
subject
of
a
network
policy.
G
G
F
No
because
I
mean
that's
the
thing
like
the
amps
do,
select
the
the
namespace
and
and
so
or
yeah.
They
do
select
a
name
space
right.
I
am
remembering
this
right,
yes,
and-
and
so
like
you
know,
if
you,
if
you
look
at
it
from
the
perspective
of
if
you're,
trying
to
like
get
it
all
down
to
pods,
maybe
it's
confusing
and
complicated.
F
But
if
you
just
think
about
namespace,
it's
like,
if
you
have
the
namespace,
you
know
database
server,
whatever
you
can
look
at
that
namespace
and
say:
okay,
is
it
a
subject
of
of
this
same
labels
using
network
policy?
And
you
can
look
and
you
see
the
subject
matches
and
you
can
say?
Yes,
it
is
a
subject
of
that
policy,
and
then
you
see
okay.
Well,
the
policy
has
a
same
labels
field.
So
the
peers,
therefore,
are
these
other
name
spaces
and
yeah.
Well,.
E
G
G
E
Yes,
Nadia
I
think
for
me
personally,
I
would
say
that
I
completely
get
your
point
right
now.
It's
just
a
matter
of
you
know
which
way
we
think
it
will
be
clearer
or
more
easier
for
the
users
to
digest.
We
were
designing
this
API
thinking
about.
If
we
have
this
one
API
that
can
work,
you
know
maybe
for
the
entire
cluster,
so
that
no
matter
how
name
series
is
come
and
go,
the
user's
intention
is
pretty
simple
right.
It's
just
that.
You
know.
E
E
This
is
what
we
have
been
hoping,
but
what
you're
saying
definitely
also
makes
sense
is
that
if
we
use
a
generator,
we
can
explicitly
generate
the
actual
amps
using
regular
selectors
so
that
people
can
say
hey
in
my
cluster
I
have
a
generator
right,
so
I
have
a
intention
for
the
same
same
labels.
Now
in
terms
of
my
specific
cluster,
what
actual
policies
or
what
number
of
amps
have
been
using
regular
label.
E
F
I
I
was
just
going
to
say
so
you
you
said
like
I,
was
not
trying
to
imply
that
the
data
path
could
do
clever
things
to
make
this
work.
I
was
I,
was
saying
I,
don't
think
you
need
any
cleverness
I
mean
the
code
that
generates.
The
rules
needs
to
be
a
little
bit
cleverer,
but
in
the
end
the
rules
are
are
still
mostly
just
going
to
be
Source.
F
G
A
Think
it's
more
so
from
the
implementation
right
now
like
what
you're
trying
to
say
Nadia
is
that
it
breaks
the
definition
of
a
subject
versus
pure
a
little
bit,
because
now
now
that
boundary
isn't
as
clear
in
these
Corner
cases
right,
it's
like
your
subjects,
are
more
Dynamic
and
not
you
know
exactly
explicit
I
mean
I.
I
is
your
problem
more
with
the
that
it
breaks
API
or
that
I?
Don't
think
it's
really
with
the
implementation
right.
G
G
And
so
there
are
a
couple
things
as
I'm,
showing
here
that
I
don't
think,
are
good
and
well
starting
with
just
the
definition
not
being
correct
right
and
that's
not
being
appear
actually
and
then
another
thing
about
this
BC
red
pod,
which
also
may
not
be
expected
by
everyone
right,
because
at
this
specific
case
object
and
the
peer
subject,
three
and
peer
three
are
different
cells,
and
that
is
not
always
the
case.
So
I'm
not
sure
if
subject
selector
makes
a
lot
of
sense.
G
In
that
case
also,
and
then
another
thing
on
slide,
eight
is
about
a
bit
more
about
scalability,
which
kind
of
if
you
you
can
use,
reuse
that
generated
subject
right,
if
you
have
the
ANP
generator.
Otherwise,
you
will
need
to
do
that
every
time
so,
even
for
if
you
just
have
Ingress
and
egress
policy
with
the
same
label
like
same
label
list
right,
then
you
will
need
to
generate
that
thing,
kinda
twice
more
or
less.
G
If
you're
not
super
smart
and
try
to
you
defy
it
somehow,
and
here
you
can
express
it
this
way
and
then
so.
This
at
NP
generator
only
allows
same
label
and
not
same
label
peers
and
then
actually,
as
we
were
discussing,
if
there
are
some
new
roles
or
something
like
that,
we
can
probably
put
it
here
too
and
not
like
again
make
the
original
object
more
complex
and
then
another
point
is
or
everything
related
to
debugging
and
Status
tracking
and
everything.
A
A
Yeah,
it's
it's
an
intro
super
interesting
way
to
look
at
this
that
definitely
no
one
else
has
thought
of
before.
So
thanks
for
bringing
this
up
Nadia
for
feedback,
I
definitely
want
to
look
at
this
over
again
and
try
to
leave
some
comments.
So
if
folks
also
want
to
do
the
same,
we
can
kind
of
pick
up
on
this
in
the
next
meeting.
If
that
works,
for
you.
E
G
C
G
E
A
A
Amazing:
okay!
Well
thanks
so
much
everyone
sorry
for
running
over
I,
think
that
was
really
productive.
Meeting
and
I
think
we
have
some
stuff
to
do
so.
If
you
get
some
time
review,
some
of
the
PRS
that
we
talked
about
today,
give
your
opinions,
feedbacks
and
yeah,
we'll
just
keep
Soldier
right
on
ahead.
So
thanks
so
much
for
coming
today.
Everyone
and
I
hope
you
have
a
good
rest
of
the
week.