►
From YouTube: Network Policy API Bi-Weekly Meeting for 20230314
Description
Network Policy API Bi-Weekly Meeting for 20230314
A
Awesome
glad
that
I
got
that
work
so
welcome
everyone
to
the
Sig
Network
policy,
API
meeting
the
dates
14th
of
March
2023.
Let's
follow
the
kubernetes
community
guidelines
and
be
nice
to
each
other.
Let's
get
started
here.
We
have
a
few
PRS
up
that
Andrew
has
that
are
in
for
review.
A
He
said
he's
gonna
hop
in
a
bit
later,
so
maybe
we
can
push
that
to
the
last
part
of
the
meeting.
So
let's
proceed
with
the
next
item
of
the
agenda,
which
is
from
Nadia,
do
you
want
to
go
ahead.
C
I
I
reviewed
the
API
beat
and
had
some
questions
that
I
hope.
Maybe
you
can
easily
answer
and
I
pasted
them
here.
It's
quite
a
lot
and
we
definitely
don't
need
to
review
all
of
them
today.
But
just
you
know
in
case
we
can
quickly
resolve
them.
So
yeah,
if
you
yes,
it
sounds
good
yeah.
Just
stop
me
if
I
take
too
much
time
at
any
point,
so
yeah,
okay,
the
first
question
I
have
here,
is
around
the
admin.
C
Network
policy
subject
point
right,
so
it
allows
you
to
set
namespaces
with
the
label
selector
or
pods,
with
this
special
struct
that
we
have
and
I
have
a
question.
I
think
when
we
just
use
the
namespace
Pod
subject,
it
allows
you
to
set
namespace
and
pod
selector
and
if
I
got
that
right,
empty
pod,
selector
means
all
pods.
So
is
that
correct
that
if
we
just
said
the
namespace
selector
in
this
namespace
pod
subject
thing
and
we
set
the
Pod
selector
to
empty
that
basically
equals
setting
these
namespaces
field
with
the
same
label?
Selector.
A
So
I'll
try
to
see
if
I
can,
if
I
understood
that
question
correctly
Nadia.
So
in
the
subject,
we
have
two
ways
of
expressing
it
right,
like
the
one
difference
that
I
really
find
with
the
amp
API
is
we've
tried
to
be
very
explicit
and
you
can
see
the
comment
from
Andrew
that
is
linked
on
the
doc
as
well.
The
point
here
to
have
namespaces
and
pods
as
two
different
things
is
to
allow
the
users
ease
of
expression.
A
So
as
a
subject,
you
need
to
either
think
of
a
set
of
namespaces
or
you
have
to
think
of
a
set
of
PODS
right.
So
in
this
case
you
can
express
pods
to
be
a
namespace
selector,
followed
by
you,
know
the
part
selector
in
that
case,
right,
like
like
you
said
so,
it's
it
is
intended
to
behave
that
way
and
an
empty
part.
Selector
indeed
means
select
all
because
that's
the
norm
everywhere
throughout
all
the
apis
that
I've
seen
so
far.
A
Yes,
exactly
so,
you
shouldn't
think
of
it
as
the
same
set
of
Parts.
You
should
think
of
it
as
namespaces
or
pods.
Right,
like
I
know
that
namespace
is
in
the
ends,
are
resolving
to
pods,
but
from
an
API
perspective,
it's
either
a
group
of
namespaces
and
it
involves
all
the
pods
in
that
namespace
at
the
end
of
the
day,
or
it's
in
a
different
way
of
expressing
just
pods
within
namespace,
so
objectives.
D
And
at
the
time,
I
think
Nadia,
sorry,
I'm
late.
Everyone
thanks
Surya
for
getting
everything
going,
really
appreciate
it.
The
you
could
have
definitely
just
had
pods
and
the
namespace
Pod
subject
right
Nadia,
but
we
wanted
to
make
it
really
easy
to
select
all
pods
in
the
namespace.
So
we
didn't
want
a
user
to
have
to
specify
like
a
namespace
with
an
empty
pod
selector
to
select
all
pods
on
namespace.
D
We
wanted
them
to
be
able
to
Simply
use
a
label
selector
to
select
a
namespace,
so
I'd
say
that
was
kind
of
a
design
decision
in
terms
of
the
overlap
and
functionality
there.
C
Yeah
I
just
think
I
read
like
some
guidelines
about
the
API
design
from
kubernetes
right
at
some
point
and
it
said
like
if
you
can
express
the
same
thing
in
two
different
ways.
Maybe
that
is
not
really
but
good.
So
that's
why
I
basically
had
this
question
and
tried
to
figure
out
if
I
understand
the
fields
right,
but
yeah
I
looks
like
that
is
intended.
C
Okay,
so
another
question
I
had
here
is
it's
just
hypothetical,
but
we
can.
There
is
a
possibility
to
use
a
list
of
subjects
to
kinda
optimize.
C
The
network
policy
at
some
point
right
say
if
you
have
the
same
Ingress
rule
for
a
multiple
sets
of
PODS,
so
you
can
create
an
admin.
Network
policy
objects
with
the
same
Ingress
and
egress
rules,
let's
say
but
different
subjects
right
and
then
you
kind
of
can
unify
that
into
one
network
policy.
Admin,
Network
policy,
so
I
just
wanted
to
ask
if
you
like,
consider
that
option,
or
maybe
that's
stupid
for
some
reason.
D
So
you
you're
talking
about
having
an
admin
Network
policy
that
selects
multiple
disc
joint
sets
of
subjects.
Is
that
what
you're
saying
yeah.
D
We
did
talk
about
that
I
think
originally
in
the
cap.
The
subject
field
was
a
list,
but
we
kind
of
determined
that
you
would
want
to
have
just
separate
amps
right,
like
I
think
at
the
time
it
was
kind
of
a
combination
of
sorry
I'm
reaching
back
in
my
memory.
D
It
was
quite
a
long
time
ago.
It
just
made
more
sense
to
us
to
make
multiple
A
and
P
objects.
Rather
than
have
you
know,
a
single
amp,
selecting
multiple
different
groups
of
things
and
I
wish
Yang
was
here
because
he
definitely
was
involved
in
that
conversation.
I
probably
could
remember
it,
but
let
me
go
look
back
at
the
cap
too,
and
see
if
I
can
find
anything
on
that.
A
And
one
thing
that
I
want
to
add
from
a
user
perspective
as
I've
been
testing,
amp
is
I,
don't
know
if
a
list
of
subjects
might
make
a
lot
of
sense
in
the
sense
that
it
might
confuse
the
user
that
in
within
the
same
amp
for
the
same
set
of
Ingress
rules
you're
having
multiple
subjects,
but
in
the
in
the
current
implementation
there
is
a
way
to
say
multiple
subjects
right,
because
it's
a
namespace
selector,
so
you
can
have
multiple
namespaces
match
across
it.
A
E
Yeah
no
worries
I
I
was
gonna,
be
pretty
much.
Second,
that
point,
which
is
I,
think
the
API
becomes
a
substantially
harder
reason
about
once
you
have
these
a
bunch
of
repeated
lists
and
you're
looking
at
the
cross
product
across
all
of
them
and
I,
don't
know
that
it's
more
efficient
in
the
data
plane
like
once
once
you
get
down
to
actually
enforcing
these
rules,
I
think
the
specifics
of
the
implementation
would
matter
more
than
just
having
a
repeated
subject.
That's
that's
my
feeling
on
why
list
of
subjects
would
be
problematic.
C
A
great
Point
yeah
yeah
that
don't
make
sense
and
I
yeah
I
can
try
to
find
some
discussions.
Andrew
mentioned
and
I
think
the
point
the
question
I
asked
about
what
the
nilon
set
means
is
was
actually
about
this
namespace
pod
subject:
thing
which
allows
your
namespace
selector
and
pod,
selector
and
I
think
it
just
it's
not
allowed
to
be
empty
ever
right.
It's
always
need
to
be
empty,
not
kneel,
not.
A
No
I
was
about
to
see
the
Pod
selector
object
is
so
it's
taken
care
of
by
the
libraries
of
the
helpers
and
kubernetes
right.
So
when
you
do
the
ask
label
selector
conversion,
if
it's
an
empty,
empty
thing
like
a
no
thing,
it'll
just
return
labels
dot,
nothing
which
doesn't
match
anything
versus.
If
you
have
nothing
set
but
an
empty
value,
it
will
return
labels,
dot
everything
which
matches
everything.
So
that's
usually
what
I've
seen
in
all
the
other
apis
and
kubernetes.
So
if
you
don't
specify
anything
empty
means,
select
everything.
D
And
nothing's
just
rewinding
a
little
bit
Nadia
I.
Actually
in
the
graduation
criteria
in
the
cap,
we
have
a
bullet
on
evaluate
the
need
for
multiple
subjects
per
amp,
so
I
think
that
was
something
we
hashed
about,
but
we
had
never
like
absolutely
designed
on.
So
we
figured
like
let's,
let's
get
this
view
on
Alpha
One
out
the
door.
Let's
get
some
implementations,
let's
see
if
users
like
this
or
not,
and
then
we
could
come
back
and
visit
it,
so
it
is
still
there
as
a
graduation
criteria.
C
D
A
C
I,
just
like
feels
like
you've,
already
discussed
all
of
them,
so
if
I
knew
where
to
find
the
answers,
I
would
have
done
that.
But
thank
you
for
yeah,
just
replying
to
me.
Okay,
so
and
then
I
have
another
question
about
peers
right,
so
I
see
it's
I
guess
it's
the
same.
The
reasoning
for
having
namespace
pyramid
namespace
podbear
is
like
the
same
right
to
just
like
make
it
easier
to
select
namespaces,
okay,
correct.
A
C
Uh-Huh
yeah
so
then
I
have
some
questions,
but
then
I
found
the
pr
actually
around
that,
but
I
still
didn't
really
understand
the
outcome.
So
do
I
get
that
right
that
these
self
and
not
self
relations
in
the
peer
is
basically
the
same
as
these
label.
Selector.
A
C
Okay,
okay
sounds
good
all
right.
At
least
I
got
that
part
right
yeah.
So
then
I
try
to
just
understand
these
new
relations
and
like
these
new
fields
for
same
labels,
not
some
same
labels,
self,
not
self
a
bit
better
and
I
think
so
for
just
to
make
sure
I
understand
that
right,
it's
kind
of
similar
to
defining
a
variable
value
for
a
label,
I
guess
so,
which
is
based
on
the
subject.
Pod
namespace
labels
right.
C
So
then,
if
just
using
these
terms,
when
we
say
same
labels,
it's
it
means
that
for
every
subject,
pod
will
kind
of
create
a
selector
for
these
label,
based
on
its
namespace.
C
Yeah,
okay,
and
so
then,
that
kind
of
just
a
way
of
me
thinking
about
that
it
kind
of
creates
a
network
policy
generator.
In
a
way,
I
mean
that
when
a
new
pod
or
like
can
use
namespace
with
a
new
value
for
a
label
is
created
that
is
kinda
equivalent
to
creating
and
you
automatically
creating
a
new
network
policy
with
this
label.
In
its
subject
like
in
its
selector
and
the
same
label
in
the
peer
right.
A
I'm
trying
to
read
it
yeah.
C
I
mean
so
sure
yeah,
let's
put
it
that
way,
so,
usually
without
this
tricky
new
fields
for
like
labels
related
to
the
subject
selected
pod,
we
usually
know
so,
every
rule
in
network
policy
or
admin
Network
policy
with
the
simple
selector
will
Define
a
set
of
pods
on
one
side
and
the
set
of
pods
on
the
other
side,
which
is
ingress
regress
whatever
and
then
the
action
between
them,
and
we
know
how
many
relations
like
that
we
have
and
then,
when
we
create
this
new,
like
type
of
label
selector.
C
That
means
we
will
have
like.
Let's
say,
virtual
Network
policies
generated
every
time
and
you
label
value
is
selected
by
that
admin.
Network
policy.
A
E
D
Right
if
your
peer
is
defined
by
a
label-
and
you
create
a
new
set
of
PODS
that
have
that
label
like
you're
ending
up
you,
could
you
could
flood
a
system
right
because
you
could
create
a
million
pods
and
a
Damian
set
that
has
that
label
right
and
and
this
all
distills
down
the
labels
still
like.
Even
with
these
fancy
selectors,
we
end
up
distilling
down
the
labels.
So
I
don't
know
if
I'm
misunderstanding,
the
problem,
I
I,
do
see
what
you're
saying
but
I
think
the
same
thing
exists
already
today.
C
Yeah
I
mean
it's,
maybe
not
even
about
the
any
specific
problem
for
now,
but
about
like
the
new
way
how
it
actually
works.
Because
still
now
you
know
you
have
one
selector
that
is
predefined,
so
it
is
static
and
now
we
kind
of
create
a
new
Dynamic
selectors,
which
will
create
new
sets
of
PODS
that
are
selected
by
it.
C
That
is
based
on
the
existing
values
for
a
label
that
we
marked
here
right.
So
when
we
say
when
I
create
a
simple
selector,
I
say:
label
one
equals
a
and
that
I
know
that
is
the
selector
that
will
be
when
I
just
say,
like
same
labels
label
one,
it
means
I.
The
number
of
actual
selectors
I
will
have
depends
on
how
many
different
values
there
are
in
the
system
for
this
label
right.
C
A
A
So
it's
the
key
and
the
value
combination,
yeah
and
if
they
want
to
say
A
and
B
and
C
in
the
values
right,
that's
a
huge
list
of
parts,
but
that's
it
can
be
expressed
in
the
same
way
using
a
namespace
selector
or
a
pod
selector
that
matches
multiple
deployments
with
label
one
equal
to
ABC
right,
so
I
guess
yeah.
Maybe
it's
also
that
I'm
not
understanding
the
thing,
but
for
me
so
I
can
just
try
to
summarize
what
same
labels
and
not
same
labels
mean
to
me
right.
A
C
Now
that
makes
sense
that
it's
kind
of
the
same
can
be
done
with
just
playable
selectors
that
they
apply
to
pods.
Probably
that's
fine
I'm
yeah
I'm
was
mostly
again.
The
the
emphasis
at
this
point
is
not
on
the
potential
problems,
but
that
how
that
actually
works
and
I
I'm,
probably
not
explaining
that.
Well
enough.
D
So
I
know
I,
think
I
see
where
you're
coming
from
so
like
in
this
case.
If
we
were,
if
we
had
a
namespace
with
the
label,
one
with
a
label
with
a
label,
one
key
right,
so
the
namespace
has
a
label
label
one
equals
fake
label,
one
equals
a
whatever.
You
can't
have
maybe
I'm
wrong,
and
maybe
it's
just
annotations,
but
I
didn't
think
I
could
have
on
that
single
namespace
two
labels
with
both
the
same
key
label.
One
yeah
you
have!
You
cannot
right,
yeah,
that's
where
I
think
we
were
confused
like
Nadia.
D
The
way
this
is
supposed
to
work
is
like
when
we
have
a
namespace
with
the
label,
one
equals
a
and
we
say
we
want
to
select
all
namespaces
with
the
same
labels
label,
one.
That
means
that
those
other
namespaces
need
to
have
label
one
equals
a
as
well.
They
can't
just
have
label
one
with
an
arbitrary
value.
C
Yeah
yeah
exactly
I
again,
I
think
I'm,
just
not
explaining
that
right.
Maybe
I
can
try
to
do
some
pictures
or
something
around
that
cool.
D
C
Yeah
and
well
I
think
I
kind
of
actually
I
understand
what
that
means.
So,
hopefully,
users
will
too
I
was
just
trying
to
yeah
rephrase
that
and
see
if
that's
right
and
if
we
really
create
like
a
new
kind
of
label,
selector
I
would
say
but
yeah.
Let
me
just
try
to
put
that
in
a
to
some
more
easy
to
understand
the
way,
and
then
we
can
keep
that
discussion.
Yeah.
D
And
I
think
that
was
really
that
that
feature
explicitly
was
used.
It
made
building
tenets
a
lot
easier
like
it
was
a
lot
easier
to
express,
like
these
group
of
namespaces
all
have
the
same
value
for
the
label
tenant,
so
they're
one
tenant
like
that
was
where
the
design
came
from,
like
the
tenant
user,
space
user
story.
C
A
No,
so
it's
not
everything
else,
it's
again
same
key
value,
but
a
different.
The
key
is
the
same,
but
the
value
is
different
so
that
we
would
differ
on
the
value
match.
So
let's
say:
I
have
tenant
a
with
labor
one
equal
to
a
and
tenant
B
namespace
with
label
one
equal
to
B,
and
if
I
want
to
express
tenant
a
to
be
not
same
as
labor
one,
then
it
would
be,
it
would
go
and
check
which
name
spaces
have
the
same
key.
A
C
Yeah
exactly
so
I'm
saying,
let's
say
we
have
10
namespaces.
Every
namespace
has
its
own
value
for
the
standard
label
right.
There
is
only
one
namespace
with
that
label.
Exactly
so
then
not
same
labels
will
generate
10
different
sets
of
namespaces
and
every
one
of
them
will
be
all
namespaces
except
one.
D
Yes,
I
I
think
I,
but
that's
a
little
bit
unavoidable.
If,
in
that
cluster,
you
are
modeling
a
namespace
as
a
tenant,
then
each
namespace
is
going
to
be
their
own
tenant,
so
each
namespace
is
going
to
have
to
have
a
rule
that
says:
I
can
talk
to
things.
Everything
inside
me
can
talk
to
each
other,
but
I
can't
talk
to
anything
else.
Right,
yeah.
C
D
C
Yeah
I
mean
so
it's
just
okay
same
labels
and
not
same
labels
with
the
same
value
they
will
for
every
possible
value.
They
will
be
United
as
all
pods
in
the
cluster
right
so
for
every
specific
value,
yeah
I'm,
sorry,
there's.
F
C
A
A
That's
not
our
use
cases
right
like
that's,
not
what
we
defines
the
API
following
them,
so
but
yeah
I
do
see
where
you're,
where
you're
going
with
it,
but
there
is
the
pr
up
which
might
clarify
some
of
the
things
around
what
same
labels
and
what
not
same
labels
mean
because
I'm
today
in
the
master,
it's
not
very
clear.
So
maybe
once
I
push
that
it
might
make
things
a
bit
more
clear
and
we
can
revisit
this
with
diagrams
and.
F
So
so
I
get
a
little
scared
from
the
names,
because
it's
a
very
generous
he
has
work
on
labels.
Today
we
start
talking
about
multi-clusters
and
things
like
that.
Then
because
you
say
it's
pods
right,
but
it's
nowhere
clear
from
the
name
that
we're
just
looking
at
pods,
so
so
I
find
the
operational
name
to
be
very
generic,
which
could
be
good,
but
I
should,
with
these
names,
I
would
expect
to
be
able
to
use
these
operations
on
anything
that
has
labels.
D
You
can
because
its
name,
spaces
or
pods
I
mean
at
the
end
of
the
day.
We
know
like
everything
distills
down
to
pods,
because
that's
the
unit
of
work
in
kubernetes
right
but
like
I,
I,
see
what
you're
saying
I
I
don't
know.
If
that's
a
problem
for
us
to
solve
in
this
API
I
think
that's,
maybe
a
problem
for
you
all
to
solve
in
the
multi-network
API
right,
yeah.
C
D
But
I
think
doc,
I
think
you're
right
like
documentation.
Examples
of
this
stuff
is
really
important
and
that's
why
like
I,
haven't,
had
a
chance
to
do
it,
but
I
am
more
and
more
and
more
than
happy
to
like
take
recommendations
on
the
website.
We
have
for
this
working
group
like,
let's
make
it
better.
If
there's
anything,
we
can
do
to
make
it
better,
I'm
happy
to
hear
it.
So
thanks
Nadia
for
bringing
all
this
up.
This
is.
This
is
really
good.
Yeah.
E
Another
point
I
wanted
to
bring
up.
This
is
in
relation
to
what
Nadia
you
were
mentioning
about,
whether
it
would
be
better
to
replace
the
not
same
with
you
know
a
allow
and
then
a
subsequent,
deny
I
think
this
talks
to
this
speaks
to
what
we
have
discussed
about
better
developer,
tooling,
like
there's,
depending
on
the
shape
of
your
cluster,
a
particular
A
and
B
setup
may
or
may
not
be
an
efficient
way
of
describing
what
you've
done
and
so
it.
E
This
is
probably
a
case
for
good
tooling
to
come
and
tell
you
hey.
Whatever
you've
done
right
now
is
blowing
up
the
data
plane
rules,
you
know
we've
had
to
program,
you
know
millions
of
denies
went,
and
maybe
you
don't
want
that.
So
that's
probably
a
good
place
to
improve
developer
tooling.
C
C
And
it
looks
like
now:
there
are
like
almost
every
field.
There
are
like
many
ways
to
express
the
same
behavior
actually
and
that
yeah.
That
brings
a
bit
more
responsibility
on
the
whoever
creates
the
admin
Network
policy
like
on
the
admin,
basically
right
to
make
sure
it's
configured
in
a
more
or
less
efficient
way.
D
Well,
I,
wonder
so
tell
me
this
Nadia,
if
you,
if
you
write
like
we've
already
determinedated,
that
the
API
has
ways
to
do
the
same
thing
like
to
select
the
same
thing
in
multiple
ways
to
say
you
wanted
to
select
all
pods
in
the
namespace.
You
could
do
it
with
a
the
name:
spaces
admin,
Network
policy
subject
or
the
namespace
or
the
pods
admin
or
policy
subject,
but
that
should
that
same
selection
in
the
API
should
distill
to
the
same
set
of
rules
in
the
implementation
right.
C
E
D
C
Yeah
I
I,
just
also
just
was
trying
to
think
of
which
recommendations
that
could
be
from
the
implementation
side
that,
but
you
know
if
at
some
point
with
seeing
that
most
implementations
we
would
say,
do
not
use
that
thing
use
that
expression
for
the
same
behavior
instead.
Maybe
we
just
should
not
allow
that,
but.
D
C
Okay
yeah,
so
if
you
don't
mind,
I
will
ask
some
more
questions
of
mine.
D
C
C
C
I
mean,
let's
say
if
my
tenants
are
not
based
on
the
namespace,
but
every
namespace
may
have
pods
from
different
tenants
and
actually
I
have
an
example
of
a
customer
that
does
that
so
different
name
spaces
will
have
pods
that
are
like
from
different
tenants.
Let's
say
based
on
the
labels,
then
I
cannot
use
the
namespace
label,
but
I
need
to
rely
on
the
Pod
label
itself.
C
So
yeah
there's,
probably
some
initial
intent.
Why
you
only
have
that
allowed
for
namespaces.
A
Well,
I
think
we
still
have
the
part
selector
in
addition
to
the
namespace
pair.
So
if
you
have
pods
that
are
from
different
tenants
across
different
name
spaces,
you
can
still
add
the
appropriate
labels
to
the
pods
and
use
the
Pod
selector
to
make
sure
they're
all
selected.
So
I
get
you
on
the
same
labels
and
not
same
labels
for
the
pods.
Also,
but
that's
just
an
ease
of
expression
right
like
if
we
have
a
valid
use
case,
I
think
we're
more
than
happy
to
add
it.
In
future,
we.
D
We
I
think
she
hit
the
nail
on
the
head
Nadia
like
in
our
use
cases,
I,
don't
know
if
we
ever
had
one
brought
up
around
collecting
building
tenants
across
namespaces
with
sets
of
pods
like
like
logically,
we
just
never
designed
for
that.
So
if
it's
a
use
case
and
you're
seeing
customers
do
it
like,
it
can
definitely
be
valid
for
the
future
and
something
we
can
think
about.
C
D
Yeah-
and
so
one
thing
I
do
want
to
carry
on
from
all
this
conversation
is
I.
Don't
Shane
is
here.
Maybe
he
can
help
us?
How
do
you
all
in
the
Gateway
API
track
things
that
you
like
discover
in
V1,
Alpha
One
and
want
to
get
into
your
next
version?
Like
I
know
you
have
gaps?
Is
that
like
what
you
do
for
every
little
change,
the
API
do
people.
F
B
It's
like
right
now,
everything
that's
gonna
make
it
into
rv1.
Release
is
on
a
project
board
called
the
road
to
the
road
to
ga.
Okay.
Inside
of
that,
there
are
several
milestones
and
everything
that
comes
in
goes
through
a
triage
process
which
currently
is
actually
on
the
board,
but
we're
going
to
switch
to
using
Upstream
triage,
like
kubernetes
triage.
D
D
All
I
was
trying
to
say:
Nadia
is
like
these
are
all
great
topics
and
the
ones
that
we're
saying
like.
Oh,
we
need
to
figure
out
in
the
next
release
like
we
need
to
have
some
way
to
track
like
the
set
of
issues
we
want
to
reanalyze
before
cutting
of
V1
Alpha,
2
or
V1
beta
one.
So
we
just
need
to
make
sure
we
do
that,
and
I
will
I'll.
Take
a
ish
a
stab
at
like
setting
up
our
project
infrastructure.
To
do
something
like
that.
D
A
A
A
C
Yes,
yeah,
so
what
I
wanted
to
say
here
about
the
past
section
and
I
think
maybe
I
can
try
to
help
with
that.
We
can
improve
the
documentation
in
some
use
cases
with
using
more
than
one
object,
as
we've
just
discussed
now,
or
at
least
a
bit
more
rules
in
the
same
object,
because
with
the
example
we
have
now
right,
there
is
a
pass
section
on
something,
and
the
whole
example
says
apply
this
network
policy
that
has
pass
action
and
it
will
work
like
that.
C
D
I
mean
it
only
I
see
what
you're
saying
really
I
think
I'd
rephrase
it
as
pass
doesn't
have
an
effect
unless
there's
rules
to
fall
to
right,
like
like
yeah,
does
in
the
context
of
of
the
admin
Network
policy,
but
it
doesn't
in
the
context
of
the
actual
traffic
flow
and
when
we
designed
it,
we
wanted
it
to
explicitly
be
that.
So
we
wanted
the
admin
in
the
context
of
that
single
admin.
D
Network
policy
to
be
able
to
express
I
want
to
pass
intent
on
this
traffic
flow
to
the
developers
with
network
policy
I,
don't
care
what
they
do.
I
don't
care
if
they
do
anything
like
I,
just
want
to
explicitly
give
the
developers
the
power
to
control.
What's
going
on,
we
don't
care
what
happens
after
that
I.
C
Mean
yeah,
but
you
so
the
if
I
got
that
right
to
all
admin.
Network
policies
are
kind
of
supposed
to
be
created
by
the
same
person
so
to
say
or
like
the
same
general
entity
right.
So
if
you
want
to
say
I
explicitly,
don't
want
to
do
anything
with
this
namespace.
Well,
don't
select
that
with
any
of
admin,
Network
policies
that
you're
creating
right.
D
D
D
Yeah
I
mean
I
I'm,
just
staring
at
the
user
story
that
we
have
because
in
front
of
me,
but
like
one
that
we
liked
to
throw
around
and
think
about
was
say
you
have
a
tenant
or
a
namespace.
That
has
a
service
and
the
admin
wants
to
open
up
that
service
to
be
used
by
everyone.
So
it
could
be
like
a
metrics
reporting
service
or
from
YouTube
service,
something
along
those
lines.
D
The
admin
wants
to
open
up
and
allow
all
people
in
that
culture
to
talk
about
service.
However,
they
don't
they.
They
also
want
to
give
the
power
to
the
namespace
admins
to
say
no,
my
pods
aren't
allowed
to
talk
that
service.
It
could
break
something,
and
that
was
the
use
case,
one
of
the
use
cases
we
first
saw
for
this.
If
you
didn't
have
pass
Ed,
you
know
what
would
the
admin
do
like
in
that
case
they
would
have
to.
D
They
would
have
to
explicitly
program,
allow
all
cluster
entities
to
talk
to
this
public
service,
except
for
certain
ones.
Right
like
they
would
have
to
express
that
they
couldn't
just
delegate
that
that
expression
to
the
namespace
admin
does
that
make
sense.
C
A
Thing
you
can
think
of
it
is
so
an
admin
would
care
about
it
because
a
lot
of
the
customers
they
offer
this
as
a
service
right,
so
the
developers
might
be
their
customers
per
se,
so
they
want
to
have
a
set
of
practices
that
can
get
the
lives
of
death
easier.
So
they
still
want
to
secure
their
cluster,
but
they
want
to
give
enough
freedom
for
the
users
to
be
also
able
to
wriggle
in
things
that
they
want
to
do
so.
There
might
be
a
set
of
namespaces
that
they
like
predict.
A
C
Yeah,
that's
like
that's
the
same
as
how
to
express
some
exception
right,
so
you
can
say
to
users.
If
you
apply
this
label
to
the
bot,
it
will
be
skipped
from
admin,
Network
policy-
or
you
can
say
if
you
apply,
that
label
admin,
Network
policies
will
be
applied
to
your
pod
and
will
not
otherwise.
F
C
To
yeah,
but
when
you
say
skip
on
a
specific
label.
F
D
I
think
it
depends
a
lot
on
how
you
just
find
your
user
Persona
too.
A
little
bit
like
like
is
a
namespace.
Does
a
namespace
quote:
unquote,
namespace
admin
have
the
ability
to
to
add
and
remove
labels
to
their
namespace
right
or
our
tent
or
or
our
cluster
admins,
giving
out
namespaces
with
labels
Already
Done
Right
like
like.
If,
if
it's
the
latter,
then
you
know
the
admin
would
need
this
explicit
pass
right
because
they
want
to
express
that
intent.
D
If
it's
the
former,
where
namespace
admins
could
could
fudge
with
labels
on
their
namespaces,
then
what
you're
saying
would
work
right
again,
it's
kind
of
a
design
decision,
and
it's
it's
an
important
unfortunate
interaction
with
network
policy
we
just
know
or
from
our
design
discussions
like
we
rolled
back
to
like
explicit,
is
better
right,
like
we
want
to
explicitly
try
to
Define
how
amps
interact
with
Network
policies
rather
than
implicitly
Define
it
with
like
and
accept.
F
C
D
Totally
agree:
I,
don't
think
it
illustrates
it
very
well.
So,
let's,
let's
add
some
more
examples
around
it
and
think
through
some
scenarios
and
I.
Think
as
we
get
these
implementations
kind
of
up
and
running
like
we'll
be
able
to
actually
say
like.
Oh,
this
makes
sense
like
or
oh.
This
makes
no
sense
right.
Well,
let's,
let's
add
more
examples
for
sure.
C
Okay,
yeah
I
think
that's
the
last
thing
and
I'm
not
sure
if
that's
probably
also
something
you
already
know
about,
and
it's
in
progress
of
fixing
or
something
about
that
Ingress
and
egress
watering
or
priority
I
think
that's
yeah.
It's
in
progress,
It's
effective.
There
is
okay,
yeah.
A
C
Okay,
well
I
I
think
then
I
yeah
well.
First
of
all,
thanks
a
lot
for
talking
to
me
about
all
that,
and
I
probably
will
try
to
add
some
pictures,
slash
user
cases,
something
like
that
to
maybe
talk
a
bit
more
about
some
more
complicated
use
cases.
Next
time,
cool.
D
A
D
F
D
Cool
yeah,
so
that
website
PR
from
Nadia
is
the
first
one
like
there
like
if
anyone's
interested.
Please
give
it
a
look
like
this
is
something
this
working
group
has
neglected
for
a
long
time
like
no
one
just
stepped
up
to
the
plate.
To
do
it.
So
thanks
again,
Nadia,
like
our
Network
policy,
docs
have
a
ton
of
holes.
So
I
think
this
is
a
good
start
at
you
know,
trying
to
patch
some
of
them
up
and
really
like.
D
D
D
Cool
and
the
last
one
was
from
me
and
it
was
coming
out
of
a
conversation
we
had
yesterday.
Surya
our
clients,
our
generic
clients
were
kind
of
messed
up.
They
were
namespace,
so
I
added
the
tag
that
we
needed
to
make
them
non-namespace,
because
obviously
BMP,
banps
and
amps
are
non-namespace.
I
then
realized
that
the
generated
stuff
was
not
getting
updated,
and
that
was
simply
because
the
code,
as
it
lived,
was
kind
of
forced
to
where
it
lived
on
disk
was
forced
to
be
like
a
specific
directory.
D
So
what
we
do
now
is
we
just
kind
of
fake
it
with
a
symbolic
link
to
make
sure
that,
regardless
of
where
your
code's
living
on
disk,
your
generated
files
will
get
put
in
the
correct
location,
so
yeah
just
need
some
review
there
and
then
I
updated
all
the
generated
stuff,
but
this
should
fit
fix
your
problem,
sir
yeah.
D
The
root
of
the
issue
with
that.
That's
really
subtle
and
annoying
is
all
those
tools
that
you
run
with
go
run.
D
They
want
to
dump,
they
always
dump
the
code
at
like
your
go
path
like
you're,
head
of
your
gopath.
So
if
you
like
me,
put
your
your
actual
clone
code
at
gopath,
GitHub
kubernetes,
Network
policy
API,
it
doesn't
put
it
there.
It
puts
it
at
gopath,
Network
policy,
API,
Etc
et
cetera,
so.
D
A
The
past,
but
I,
really
appreciate
you
fixing
this
Andrew.
This
is
great
help.
Thank
you,
I'll,
take
a
look
at
it.
I
can
review
it
somewhere
to
do.
D
Yeah
and
I
got
that
symbolic
link
idea
from
the
Gateway
API,
we're
just
doing
it
in
a
make
file
instead
of
with
a
bunch
of
scripts,
because
I
had
this
Grand
Vision
grandiose
vision
of
not
having
hack
scripts
and
instead
of
just
having
like
a
make
file.
But
it's
steadily
getting
more
complicated
to
keep
going
with
that
Vision.
So.
E
B
A
D
You
give
the
one
sentence
overview
for
everyone.
What
you're
you
mean
when
you
say
conformance
profile
like
what
is
that
doing,
yeah.
B
Conformance
profiles
is
a
project
I'm
working
on
right
now
to
provide
some
high
level
tooling
for
running
our
conformance
test,
Suite
against
your
implementation,
and
then
it
at
the
end
emits
a
conformance
report
which
looks
a
little
bit
like
a
custom
resource,
but
it
only
uses
type
meta.
It
doesn't
have
spec
and
all
that,
and
that
conformance
report
is
all
the
data
about
what
happened
during
that
test
that
you
can
actually
submit
back
to
Gateway
API
to
as
part
of
our
certification
process.
B
So
basically
you
submit
those
to
us
and
we
certify
you,
give
you
Badges
and
so
forth,
because
this
is
what
we're
working
on.
It's
been
there's
a
thread
in
Sig
Arch
about
it
as
well,
because
apparently
there's
some
interest
in
Sig,
Arch
and
Sig
testing
is
interested
in
maybe
doing
something
similar.
So
if
you're
interested
just
follow
that
thread,
but
also
subscribe
to
the
API
issues,
I
can
send
them
to.
If
you
PM
me.
D
B
Well,
this
is
the
part
I'm
at
right
now,
as
I'm
trying
to
get
everybody
to
agree
to
use,
go
build
tags
as
a
way
to
produce
prototype
code
that
won't
be
part
of
a
release
so
that
we
can
very
quickly
build
a
prototype
as
part
of
the
get
process,
basically
use
a
prototype
and
experiment
with
it.
I
have
a
couple
of
implementations
that
are
willing
to
try
it
out
and
then
have
that
feedback
into
the
cap,
as,
like
part
of
the
experience
to
inform,
we
want
to
go
before
we
call
it
implementable.
So.
D
Love
to
know,
that's
a
good
one
involved.
That's
a
good
point,
quick
question
for
you
in
line
with
that
Shane
in
in
regards
to
your
releases.
When
you
build
a
release,
you
have
all
your
your
client
code
that
you
maintain
and
your
your
crd.
So
when
you
once
a
user
Gateway
account
API
comes
in
and
wants
to
use,
Gateway
API
they
all
they
really
need
from
that.
Payload
release
are
the
actual
crds
to
apply
to
the
cluster,
the
crd
yaml
and
the
client
code.
Is
that
correct,
but.
B
E
B
Versioned
under
normal
crd,
versioning,
V1,
Alpha
One
V1
beta
Etc,
and
then
we
just
do
semver
for
the
client
code,
but
the
client
code
is
completely
optional,
but
that
includes
the
conformance
test.
So
saying
it's
optional
is
a
little
bit
of
a
lie
except
a
little
bit
of
a
lie,
but
it
you
can
run
it
without
how
you
doing
go
Lang.
So
we
have
two
ways
to
run.
B
D
B
D
A
Yeah,
the
implementations
are
essential
to
do
their
own
thing
right,
like
I,
mean
I
started
off,
for
example,
rendering
in
the
OR
generating
the
yamos
and
installing
that
for
the
OV
and
K
implementation,
and
then
Andrew
pointed
out
that
hey
Gateway
API
does
it
differently.
You
just
need
the
released
version
of
it,
so
we
cut
a
release
and
then
you
can
just
install
that
on
cluster,
and
that
seems
like
a
more
centralized
approach
and
much
more.
D
We
please,
we
don't
want
people
generating
crds
from
our
types
like
we
want
them
to
use
the
crds
we've
generated
right,
or
else
people
could
end
up
with
slightly
different
versions.
Downstream.
We
don't
want
that,
but
the
distribution
question
is
kind
of
tricky,
so
we
need
to
end
up
just
Distributing
those
via
releases,
rather
than
just
like
sitting
at
Main.
A
B
There
has
to
be
conformance
for
whatever
apis
there
has
to
be
conformance
tests
to
a
certain
degree.
That
degree
is
a
little
vague,
but
it's
pretty
well
colloquially
known.
It
basically
has
to
cover
every
status.
Every
bit
of
functionality,
like
the
entire
thing,
has
to
be
covered
by
conformance
tests,
and
then
we
have
to
have
at
least
two
implementations
are
running
those
conformance
tests
and
passing
them
before.
B
We
would
consider
something
V1
beta
one,
and
so
that's
the
state
of
things
so
right
now,
the
only
thing
that's
in
beta
is
Gateway
class
Gateway
in
HTTP
route,
and
those
will
be
the
things
that
will
make
it
to
GA.
Those
have
good
coverage,
I'm
working
actually
with
Andrew,
quite
a
bit
on
TCP
route
and
UDP
route,
with
our
project
leaks,
which
is
getting
moved
into
kubernetes
soon,
and
that
is
actually
driving
for
the
layer,
4
conformance
test.
B
So
once
those
are
in,
which
is
something
that's
on
my
agenda
to
do
really
soon,
we
will
I'm
I'm
going
to
try
to
push
for
at
least
UDP
route
and
then
TCP
route
as
soon
as
we
can
to
get
pushed
up
to
V1
beta
1
after
we
get
at
least
what
one
other
implementation
to
to
do.
The
tests,
but
the
conformance
profiles
project
that
I'm
working
on
adds
the
forever
missing
thing
of
not
having
to
go
to
slack
to
query
who's
actually
running.
B
It
actually
has
reports
that
will
be
sent
back
to
the
repository,
so
we
will
literally
be
able
to
see
not
only
what
people
are
actually
using
the
the
resources,
but
what
features
they're
using
or
what
features
they're
disabling.
We
have
the
idea
of
support
levels
which
has
been
really
helpful
for
us,
probably
one
of
the
best
things
we
did,
which
is
there's
core
support,
which
is
every
implementation,
can
do.
These
features
extended.
B
Some
or
most
of
the
implementations
can
do
these
features
and
implementation
specific,
which
is
kind
of
we
know
it
exists,
but
we're
not
trying
to
really
do
conformance
around
it.
We
just
Ed.
We
acknowledge
that
it's
there
and
those
levels
play
into
the
con,
the
the
conformance
testing,
because
you
can
opt
out
of
all
of
the
extended
features
if
you
want
to
and
still
be
considered
conformant
a
conformant
implementation,
cool.
B
B
The
end
result
will
look
nothing
like
what
you
see
in
the
Gap
today,
but
the
basic
idea
should
be
fairly
similar,
I
figure,
we'll
start
with
just
have
them
put
in
a
PR
and
then
later
we
can
worry
about
better
mechanisms.
Once
you
get
it
into
a
file
format
that
you
can
submit
as
a
PR
into
a
directory,
that's
a
good
Baseline
and
then
from
thereafter
people
can
add
fanciness
on
top
of
that.
If
they
want.
E
B
Know
I
know
because
yeah
first
things:
first,
you
can't
stop
you.
You
potentially
can't
stop
people
that
have
a
proprietary
implementation
from
lying
you'll.
Never
right,
it'll
be
really
hard
to
vet.
That,
like
you,
could
probably
do
it
if
you
went
like
tested
everything
out
yourself
by
using
their
implementation,
but
that's
a
lot
of
work.
So
that's.
B
Implementations
are
always
probably
going
to
be
able
to
lie,
but
I
figured
and
I
put
this
in
the
dock.
Anybody
who
lies
about
this
intentionally
risks
way
way
way
too
much
backlash
and
like
just
like
sullying
their
brand.
By
doing
such
a
thing
that
I
don't
think
anybody
will
do
it
I,
don't
think
anybody
would
lie,
because
the
reputation
damage
would
just
be
so
bad
in
the
community.
Like
everybody
would
look
at
you,
like
you,
lied
about
your
conformance
results,
intentionally
I.
D
Agree
heck
amazing,
amazing,
no
I
had
that,
but
we
are
at
times
was
there
any
last
things
going
twice
cool.
This
is
a
really
great
meeting,
thanks
for
all
y'all
coming
and
thanks
for
the
really
good
conversation
we'll
try
to
take
some
of
this
away
and
keep
kind
of
chugging
away
on
implementations.
Hopefully
Yang
will
be
here
next
time
and
we
can
talk
about
how
it's
going
over
in
Hampshire,
but
that's
all
I
have
for
today,
thanks
Surya
for
co-running
the
meeting
and
we'll
talk
to
you
all
next
time.