►
From YouTube: Bi-Weekly Network Policy API Meeting for 20211011
Description
Bi-Weekly Network Policy API Meeting for 20211011
A
A
B
B
I
would
like
to
would
like
to
see
an
open
process
driven
definition
of
what
the
cid
looks
like
so
in
the
cap
and,
as
you
can
see,
gobind
who
was
working
on
this
thing
is
no
longer
involved
in
security,
so
I've
taken
over
from
him.
Okay-
and
I
was
talking
to
tim
about
it
and
tim
said
what
is
the
status
I
said.
Oh
yeah
we've
been
sitting
on
it,
so
I
decided
like
put
it
up
on
the
I
spoke
with,
so
I
we
attend
the
thursday
meeting
for
the
cluster
network
policy.
B
I
brought
it
up
there,
so
it
doesn't
make
sense
to
just
discuss
it
there
or
here.
So
it
was
suggested
that
I
bring
it
up
here
so
yeah
these
are
pretty
straightforward
caps.
One
is
for
mostly
so
when
I
say
fqdn
we're
just
trying
to
keep
the
scope
only
to
fqd
and
not
l7,
because
l7
opens
up
a
whole
set
of
issues
that
I
didn't
want
to
like
get
into.
B
B
Shared
it
with
me,
yeah,
so
I'll
tell
you
what
I
I
can,
since
this
has
been
sitting
there
for
a
while.
I
did
not
go
through
the
bookkeeping
to
make
these
stocks
all
open.
What
I'll
do
is
I'll
put
it
in
the
I'll
not
use.
My
google
account,
so
it's
easily
accessible
to
everyone.
So
anyone
wants
to
use
it.
Let
me
know,
and
I'm
happy
till
I
can
add
you
as
authors
on
this-
there
are
already
a
bunch
of
people
are
already
working
on
it.
So
here
share.
B
Yeah,
so
service
account
is
something
that
is.
We
use
that
quite
a
bit
on
gcp
and
we're
just
trying
to
extend
that
concept
to
also
in
kubernetes,
because
it
makes
it
easier
for
us
to
define
identity-based
security
instead
of
like
labels,
so
because
there
is
like
so
there
are
some
use
cases
that
I've
defined
there's
two
users.
Actually
I
wrote
it
down,
so
I'm
involved
I've
been
involved
in
this
particular
kept
from
beginning.
So
I
can
I'm
happy
to
incorporate
other
use
cases
if
anyone
has
any
suggestions.
B
The
key
point
of
this
cap
is
to
we
use
namespace
selectors,
we
use
part
selectors,
but
what
we
want
to
do
is
we
want
to
assert
based
on
the
identity,
because
a
lot
of
times
you
can
associate
the
kubernetes
service
account
with,
like
you
know,
underlying
cloud
infra
identity.
So
you
can
do
a
lot
more
things.
For
example,
in
our
use
case,
we
have
kubernetes
workloads
trying
to
reach
out
to
gcp
to
make
certain
calls
for,
like
you
know,
aiml
like
a
spanner
access
and
things
like
that
right.
B
So
this
is
all
tied
to
service
account
and
we
figured
so.
We
need
to
assert
the
identity
right,
so
so
we
want
so
this
we
figured
it
would
be
good
to
have
pods
be
selected
based
on
this.
The
service
service
account.
So
that
is
the
gist
of
this
high
level.
Just
of
this,
that
is
this
cap
yeah
now
I
can,
I
can
add
some
pictures
just
also,
but
this
has
been
sitting
on
my
in
cold
storage
for
a
while,
so
I
just
decided
to
bring
it
up.
B
So
what
I'm
looking
for
number
one
is
the
interest
from
folks
who
want
to
work
with
us
and
then
number
two.
How
do
we
want?
Should
I
use
this
meeting
to
set
it
up
or
should
I
should?
We
have
like
what
the
cluster
network
policy
guys
did
spin
up
a
separate
meeting,
try
to
get
those
things
resolved
there
and
bring
it
back
here.
A
I
think
for
now
it's
it's
fine
to
use
this
meeting.
It's
somewhat
quiet,
we've
been
using
it
as
a
cmp
kind
of
pinging
ground
yeah.
I
say
for
now:
let's
use
this
and
then,
if
the
need
arises
like
further
on
in
the
pipeline,
we
can
spin
up
a
new
one,
pretty
easily
okay
yeah,
and
I
I
think
these
are
both
great
ideas.
I
I
obviously
support
them.
I
think
they're
both
something
that's
gonna
span,
basically
any
resource
so
cmp
or
np.
A
Now
the
question
is
gonna,
be
again,
it's
gonna
come
back
to
how.
How
do
we
integrate
these
changes
into
the
existing
api
right?
Exactly
yep?
So
that's
the
hardest
thing
and
you
know
I
don't
want
to
say
it,
but
I'm
gonna
say
it
is
like.
I
think
the
main.
I
think
that
problem
can
be
solved
a
lot
of
it
if
we
keep
if
we
get
some
people
with
their
hands
on
status
right,
so
network
policy
status
is
something
that
we
could
report
to
the
user.
A
B
For
example,
if
you,
if
you
show
the
fqdn
cap
right,
I
just
wanted
to
show
you
that
so
right
now
there
is
there
are,
I
think,
if
we
see
there
are
one
option
was
to
like
you
know,
use
a
separate
api
and
I
think
we
will
try
so
there's
one
under
the
first
option.
I
think
proposal
is
used
network
policy
itself
right
right
and.
C
B
A
To
be
honest
with
you
like,
we
haven't
really
hashed
all
that
out.
There's
been
a
lot
of
talk
about
of
the
status
field
and
how
that
would
work,
but
nobody's
really
owned
it.
I
would
love
to
but
right
now
I
just
don't
have
the
bandwidth
too.
So
so
let
me
ask
this
question,
so
we
don't
have
status
today
right.
We
do
not.
We.
B
A
A
A
And
there's
been
a
lot
of
discussion
previously
about
status.
I
think
it'd
be
nice
for
someone
to
go
back.
I
might
even
be
able
to
this
week
or
next
week
go
back
and
kind
of
coalesce
all
the
talk
around
status
we've
had
so
dan
winship
was
the
first
one.
He
tried
to
implement
a
kep
for
status
micro
versioning
within
our
api,
the
micro
versioning
thing
kind
of
went
up
in
flames.
It
got
too
complicated
too
quickly
and
the
status.
A
There's
a
couple
corner
cases
like
that
that
I
kind
of
poked
holes
in
in
the
status
cup,
originally,
okay,
so
yeah
just
reach
out
to
jay,
I'm
sorry,
ricardo
and
if
you
have
any
questions
reach
out
to
me
as
well,
I
am
still
poking
around
red
hat
and
and
opens,
and
really
the
kubernetes
community
in
general
to
find
someone
to
take
it
up
and
like
really
own
it.
But
if
not
like,
I
said
eventually
I'll
be
back.
A
Yeah,
no
thank
you
for
bringing
these
back
up.
I
think
they
have
a
lot
of
merit
and
obviously
a
lot
of
cni's
are
supporting
various
iterations
of
them
already,
so
be
super
useful
to
have
upstream
there
any
questions
for
anyone
about
fqdn
or
service
account
selectors
or
service
selector
questions
in
general.
D
D
B
Sienna
independent
way,
so
what
we,
what
it
does
is
it
sits,
it
runs
outside
and
I
think,
if
I'm
not
mistaken,
it
even
runs.
I
need
to
go
back
and
look
at
it
because
it's
open
source
there
is
a
github
where
this
code
is
sitting.
So
what
it
does
is
it
reads:
fpdm
policies
and
then
keeps
a
watch
on
the
dns
and
then
as
and
when
there's
any
change
it
will
go.
Tell
the
community's
cluster
so
hey
update.
B
Exactly
it's
more
of
the
latter,
but
in
our
case
it's
a
little
bit
more
vertically
integrated.
Yes,
basically,
you
send
a
notification
based
and
then
that
way
it
frees
you
up
from
whatever
cni
you
have
you
can
like
if
you're
using
calico
or
psyllium
or
whatever
you
want
to
use,
then
the
behavior
becomes
a
little
different.
B
Yeah
and
I
think
the
the
some
of
the
issues
I
mean
this
was
done
more
as
a
reference
implementation.
One
of
our
strategy,
customer
engineers
went
ahead
and
implemented
that
so
the
main
drawback,
I
guess,
is
like
the.
How
often
do
you
poll
and
what
is
the,
how
long
is
the
window
before
what
the
state
of
the
world
is
and
what
the
intent
is?
B
D
Back
end
of
the
october,
or
maybe
in
two
weeks,
okay,
I
think
he
worked
on
it,
so
he
I
know
he
was
interested
in
also
taking
this
upstream.
So
maybe
I'll
you
know
once
he
comes
back,
I
think
you
can
get
in
touch
with
him
and
I'll
ask
him
to
join
the
monday
meetings
again,
and
maybe
he
can
help
you
right
so
abhishek.
B
What
that
would
be
great
because
we
are
so
so
what
we
wanted?
What
I'm
primarily
looking
for
is
an
agreement
on
the
the
crd,
so
the
api
right
so
like,
I
think,
if
we
can
the
way
I'm
seeing
it
is
based
on
what
andrew
described
like
once,
we
had
figured
out
a
way
to
incorporate
the
status
field
in
the
network
policy.
Then
we
don't
necessarily
need
to
create
a
new
crd
for
this.
We
can
piggyback
on
top
of
network
policy
and
use
the
status
to
like
indicate,
support
or
no
support
for
this
feature.
B
D
A
I
think,
then
it
comes
into
the
talk
of
if
you're
gonna
do
that.
Why
not
build
it,
build
it
into
v2.
If
that
is
a
network
policy.
V2
like
like
status
field
for
network
policy,
v1
is,
is
a
little
less
obtrusive
than
adding
like
new
selectors
right.
It's
it's
changing
semantics
of
how
network
policy
can
work.
B
A
That
it's
been
pretty
stalled
ever
since,
basically,
prasad
and
nadeem
from
juniper
were
working
on
it
and
they
haven't
been
here
in
a
few
weeks,
so
we
have
some
user
stories
and
preliminary
investigation
there,
but
that's
kind
of
it.
It
hasn't.
It's
been
stalled
a
little
bit
after
that.
I
think
they
were
waiting
to
see
what
happened
with
cmp.
In
a
few
regards,
and
now
that
cmp
is
kind
of
unblocked
and
moving
forward,
I
would
assume
it
can
move
forward,
but
I
haven't
heard
from
them
lately:
okay,.
B
D
Yeah,
I
think
that
depends
on
how
we
want
to
do
eventually,
because
if
we
are
thinking
in
an
external,
cr
or
sorry,
a
different
crd
for
fifty
and
might
as
well
do
it
out
of
cnp
as
well.
But
if
we
want,
if
we
want
this
to
be
part
of
network
policy
v2,
I
think
this
is
something
that
we
can
in
try
to
include
with
cnp's.
Because
then
you
know
we
can
take
some
feedback
that
we
get
from
cnp
into
the
v2
structure
and
use
that.
B
Thing
if
we
are
eventually
going
to
make
it
as
a
part
of
v2,
then
I'm
thinking
like
since
cnp
is
still
in
the
like
in
the
early
stages.
Does
it
make
just
in
terms
of
parity?
Does
it
make
sense
to
put
it
in
there
and
then
we
continue
to
push
see.
I
I
don't
think
network
policy
vt
is
going
to
get.
I
will
come
to
a
a
consensus
like
in
or
a
some
final
state
in
the
yeah
in
the
next.
D
D
D
D
Yeah,
that's
why
I
think
a
cap
would
be
like
a
you
know,
to
expand
the
scope
of
the
cnps
into
this,
and
I
think
eventually
we
would
also
need
to
solve
the
north
south
with
cnp,
but
not
of
course,
not
with
this
kept,
but
because
I
still
feel
it's
it's
it's
pretty.
You
know.
We
say
that
cnp
is
like
a
guardrail
on
network
policies,
but
you
have
that
escape
mechanism
with
ip
blocks
and
network
policies
which
we
cannot
block
with
cnp.
A
C
A
I
think
one
of
the
at
least
speaking
with
some
of
the
creators
of
network
policy
they
said
or
when
I
said,
creative
network
policy
when
I
spoke
with
dan
winship
and
dan
williams
about
it.
They
kind
of
pushed
saying
that
the
addition
of
ip
block
to
original
network
policy
was
somewhat
of
a
mistake
like
it's
overloading
that
api
to
try
to
express
too
much
and
they
recommended
in
order
to
move
the
cmp
cap
along
and
get
consensus.
A
Let's
start
with
just
the
east-west
traffic
use
cases
and
then
possibly
look
at
adding
a
resource
to
act
as
a
moat
around
the
cluster
at
a
later
date,
because
when
we
start
talking
ingress,
egress
north-south,
there's
a
bunch
of
other
rules
that
apply
like
it's
not
just
like.
Then
the
question
of
like
pre-snap
post
snap,
different
mechanism
for
ingress
via
services
and
the
gateway
api,
like
that
all
kind
of
comes
into
into
play,
and
and
if
you
leave
it
out,
it
doesn't
makes
a
lot
simpler.
So
that's
where
we're
at.
A
So
yeah
it's
it's
basically
an
example
of
nothing's
been
easy
in
the
development
of
cmp.
There's
been
a
lot
of
hard
choices
to
make,
but
in
order
to
get
the
thing
moving,
we've
had
to
do
some
make
some
of
those
choices.
Yeah
any
other
questions
there
renee
I
shared
what
we
have
for
v2.
I
agree
with
you.
I
think
it's
moving
slow,
very
slowly,
so
it'd
be
harder
to
get
something
done.
A
B
Yeah
exactly
and
I
think
if
we
can,
if
you
think
it
makes
sense
to
go
with
its
own
independent
crd,
we
can
do
that,
but
I
want
to
make
sure
that
the
the
deltas
are
small
enough
that,
once
if
we
incorporate
that
into
network
policy
v2
or
cnp
they're
like
no
issues
right,
it
should
be
smart
right
exactly.
We.
A
C
A
A
while,
because
we've
been
stuck
on
cmp,
but
anyway,
cool
yeah,
I'm
glad
you're
bringing
it
back
up
and
I'll.
I
also
know
some
people
who
have
implemented
openshift's
kind
of
version
of
ftdn
called
egress
firewall
and
I'll.
Ask
them
if
they
wanna,
if
they
wanna,
come
up
and
get
involved
or
if
you
need
any
help.
I
can
definitely
ask
them
as
well
too.
A
Yeah
cool,
no
worries,
okay,
so
we've
kind
of
covered
network
policy
status.
Today
I
won't
harp
on
it
too
much
more.
Basically,
we
still
just
need
kind
of
more
people
to
check
it
out.
I
posted
the
kept
again
ricardo's
more
than
happy
to
help.
If
you
reach
out
to
him
to
slack
he's
usually
around
well
he's
always
around
he's
the
man.
Otherwise
I
don't
have
anything
else
on
the
agenda
for
today.
Abhishek
is
there
anything
you
would
like
to
cover
regarding
cmp
with
the
group
or
are
we
still?
D
Yeah,
I
did
push
a
latest
revision
based
on
the
I
mean
just
to
reflect
the
latest
proposal
and
I
believe
the
remainder
of
things
for
that
cap
is
now
to
add
the
samples
which
I
think
sanji
was
going
to
add
and
then
beyond
that.
I
think
there
are
a
couple
of
to
do's,
like
the
default
rule
handling
and
and
whether
to
add
like
audit
logging
policy
or
as
part
of
this
solution
or
not,
but
I
I
think
we
we
agreed
that
we
probably
have
a
separate
cap
for
it.
D
A
D
A
A
The
only
other
thing
I
wanted
to
talk
about
was:
I
was
going
through
and
closing
some
stale
prs
from
our
sig
network
policy,
api,
repo,
I'd
love
to
still
add
some
more
stuff
here,
open
to
adding.
You
know
examples
around
network
policy,
cool
tools
with
regarding
network
policy
that
people
have
written
like
cyclonus
and
other
things.