►
From YouTube: Network Policy API Meeting 20200720
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
cool:
well,
it's
what
is
it
july?
The
20th-
and
this
is
the
first
official
network
policy
working
group
meeting,
so
we
so
so
we
should
be
following
cncf
guidelines
now,
since
we're
recording
and
we're
all
going
to
be
on
youtube
and
everything
right,
not
that
we
weren't
before
we
would
never
violate
any
of
those
rules,
but
so
everybody
be
cool
and,
and
let's
have
some
fun
and
and
get
into
this.
We.
A
This
is
like
just
want
to
take
a
minute
to
thank
everybody
who
has
gotten
us
this
far
along.
This
is
our,
like.
I
said
it's
our
first
official
meeting
as
an
actual
work
group
as
of
today.
So
thanks
everyone
for
coming
now.
Let
me
share
my
screen
here.
A
There
it
is
firefox,
okay,
all
right,
so
everybody's
my
screen
coming
out.
Okay,
okay,
can.
A
Better
cool,
okay:
we
have
some
new
people
here
today.
So
how
about
everybody
says
hi!
That's!
I
wonder
whether
we
can
do
how
about
since
this
is
our
first
official
thing,
how
about
everybody
just
introduces
themselves
for
like
10
seconds.
Does
that
work
for
you
yeah?
Let
me
see
here:
okay,
we
got
18
people,
so
we
should
probably
go
fast,
but
what
are
you
doing
here
and
and
and
where
do
you
work,
go
ahead?
Start
andrew?
I
guess.
B
Hey
I'm
andrew.
I
work
at
vmware
on
some
career
use,
networking
stuff,
so
I'm
here
to
see
what's
happening
with
network
policies.
E
G
A
Cool
and
I
think
zang's
here,
she's
also
from
google
she's,
been
a
part
of
this
from
the
beginning
as
well.
Abhishek.
H
Hi,
this
is
abhishek,
I'm
also
from
vmware,
and
I
have
done
some
implementations
on
network
policies
for
a
couple
of
cni's
and
most
recently.
I
Hey
hello,
my
niece
I've
been
working
with
zig
network
a
bit
on
dual
stack
and
also
work
and
networking
in
azure
from
microsoft.
A
Cool
chris.
D
Hey
I'm
chris
from
ibm.
I've
worked
on
a
lot
of
api
work
and,
most
recently,
the
ingress
stuff.
But
before
that,
I
added
the
support
for
egress
insider
support
in
the
policy
api.
A
Cool
all
right
and
looks
like
eric.
J
Hey
guys,
I'm
eric
I'm
a
solutions
engineer
at
stackrocks,
it's
a
security
platform
for
kubernetes
environments.
I
used
to
work
with
jay
in
the
previous
life.
He
told
me
about
this
meet
up.
We
have
a
lot
of
customers
who
are
very
curious
about
the
upstream
api
and
what's
happening
in
network
policy,
so
I'm
here
to
help
and
contribute
how
we
can.
A
Cool
bowie
just
joined
as
well.
A
K
We
doing
intro
study
this
movie
work
on
kubernetes
at
google.
A
Yeah,
cool
and
billy's
been
real
helpful
with
all
this
stuff
as
well
getting
our
cap
in
to
get
the
validation
stuff
improved
as
well.
So
who
else
do
we
have.
F
A
And
gobind
gobind.
L
Yeah
hi
this
is
govent,
can
is
my
video
working?
No,
no,
I
don't
know
that's
good
enough.
Is
that
working
out,
hey
hi,
my
name
is
govind,
I'm
a
product
manager
at
google
as
well.
I
look
at
network
policy
and
other
network
security
things
just
curious
to
see
how
this
conversation's
shaping
up
and
what
use
cases
I'm
seeing
versus
what
the
community.
A
A
N
To
try
to
understand
how,
where
network
policies
are
headed,
how
they
interface
sort
of
touch
up
against.
A
A
P
P
My
name
is
michael
joe,
I'm
currently
working
qualcomm
and
I'm
pretty
new
to
the
kubernetes.
Now
I
hope
I
can
learn
about
kubernetes
and
hope
to
contribute
in
the
future.
Yeah.
A
Q
R
Hey
guys,
I'm
yeah,
hey
guys,
I'm
leihan
from
microsoft
as
well,
I'm
working
with
in
container
networking
so
working
in
network
policies
and
curious
about
new
policies,
prosperous
and
contributing
and
background
as
well.
Thank
you.
S
S
S
And
I'm
hoping
to
contribute
more
from
the
90s
community
cool.
A
A
T
Yeah
hey,
this
is
them
so
I'm
also
from
google
kubernetes
networking
team
and
working
on
that
class.
U
Hi,
my
name
is
young.
I
come
from
vmware
and
I
worked
with
app
check
a
little
bit
on.
You
know
the
cluster
network
policy
side
for
andrea,
and
I'm
still,
you
know
currently
contributing
to
that.
F
A
A
We've
just
been
kind
of
hanging
out
and
talking
about
stuff
and
and
coming
up
with
ideas
and
moving
towards
the
more
structured
environment,
but
like
this
is
gonna,
be
the
first
call
where
we
actually
scale
she's,
recording
like
25
30
people,
and
so
I'm
probably
going
to
need
some
feedback
and
in
terms
of
how
we
do
that,
and
so
just
like
you
know,
yell
at
me
anytime.
A
If
anybody
finish
what
we're
doing
is
inefficient
but
like
where
we
were
at
I'll
just
let
everyone
know
where
we're
at
like
we
had
this
kind
of
we
had
like
this
structure.
We
were
following
before
where
we
would
have
an
agenda
and
it
served
as
an
office
hours
for
people
who
were
new
to
policies
to
network
policy
stuff.
A
There
weren't
a
whole
lot
of
introductory
questions,
so
we
kind
of
skipped
over
that
and
then
a
group
of
about
four
or
five
of
us,
or
maybe
six
of
us
that
were
really
engaged,
were
kind
of
debating
hotly
debating
a
few
of
these
policies
and
that
that
sort
of
were
really
interesting.
And
then
we
eventually
got
to
a
point.
Where
can
everybody
see
this
spreadsheet.
A
M
A
We've
got.
You
know,
bowie's
here,
andrew's
here,
a
lot
of
other
people,
so
maybe
we
should
just
maybe
we
should
just
start
off
by
saying.
Let
me
just
open
this
up
and
say
for
those
of
you
that
have
been
coming
and
for
those
of
you
that
are
new.
Are
there
anything
that
you
want
to
see
out
of
this
overall
network
policy?
A
You
know
v2
design,
working
group
meeting
that
that
we
should
talk
about
now,
because
now
is
a
great
chance
to
change
what
we've
been
doing
so
that
it's
more
efficient
or
less
efficient.
If
that's
what
you
want,
I
don't
know.
A
Yeah,
okay,
so
yeah
we
can.
We
can
just
like
start.
We
can
just
literally
go
straight
to
the
use
cases
as
andrew
suggested.
We've.
We've
we've
done
a
lot
of
back
and
forth
on
this,
and
I'm
pretty
sure
we
definitely
will
never
all
be
on
the
same
page
about
it
right,
but
I
think
yeah
I
know
you're
right
like
if
we
can,
if
we
can
like
do
an
overview,
that's
probably
a
good
start.
These
are
tough
to
overview.
A
I
will
say,
though,
because
there's
so
much
history
that's
gone
into
all
of
them,
so
what
we
did
was
we
kind
of
made
these
colors,
because
the
most
important
thing
for
the
charter,
this
group
originally
was
to
figure
out
what
people
wanted
right.
First
of
all,
and
so
we
kind
of
like
triage
them
into
green,
yellow
and
red
things
that
everybody
agrees.
We
really
need
yellow
things
that
people
kind
of
may
agree.
A
We
might
need,
but
not
really
sure
whether
it's
actionable
to
get
there
and
then
red
being
like
out
of
scope
seems
like
maybe
a
cool
idea,
but
really
tricky
to
figure
out
how
we
could
move
forward
with
it.
In
a
tactical
way,
so
that's
the
simplest
way
to
to
triage
them
and
there's
like
one
new
use
case.
So
maybe
the
best
thing
we
can
do
is
start
off
with
the
new
use
case.
A
Was
this
I
think,
there's
two
two
new
use
cases
right:
one
was
for
the
kubernetes
service,
endpoint
egress
rule
and
then
the
other
one
was
for
what
was
the
one
from
the
from
the
bank,
the
guy
the
guy
at
the
bank.
I
forgot
your
name
who's.
I
I
deleted
your
use
case
on
accident
and
then
you
emailed
me.
C
A
C
Gateway,
so
for
me
it's
this.
This
is
basically
how
to
how
we
could
isolate
applications
all
right.
C
A
A
I
always
like
to
pull
up
the
types.go,
so
I'm
gonna
pull
that
up
right
now
and
share
it,
because
I
feel
like
it's
useful
when
we
talk
about
these.
A
A
So,
as
you
know,
you
select
a
pod
initially
right
and
then
you
apply,
you
apply
policies
to
it
and
you
do
have
selectors
for
let's
see,
let's
go,
let's
go
down
and
look
at
so
these
are
the
these.
Are
our
policies
for
namespaces?
A
So
do
you
want
to
maybe
take
a
look
at
that
that
maybe
over
the
next
few
days
and
think
about
it
a
little
bit
in
terms
of
how
it
might
apply
to
your
use
case,
the
specific
the
specifics
of
that
of
whether
you
can
do
what
you
want
to
do
with
the
pod
selector
in
the
namespace
selector?
A
That
might
be
maybe
a
good
start
right,
and
then
we
can
make
it
a
little
more
concrete.
H
Yeah-
and
I
think
you
also
have
a
another
use
case
in
the
document,
which
is
specifically
to
add
policies
which
can
be
created
by
administrators
instead
of
developers.
So
I
think
this
that
can
be
solved
by
this.
You
know
adding
a
new
cluster
policy
resource,
then
you
could
use.
Then
the
administrator
can
allow
namespaces
to
talk
to
each
other
and
disallow
that
I
think
maybe
that
can
also
target
this
uses.
A
C
A
But
one
of
the
suggestions
I
forgot,
who
suggested
it
in
the
in
the
in
here,
was
that
we
allow
people
to
select
directly
in
namespace.
I
don't
remember
why
what
the
motivation
for
that
was,
maybe
just
that
it's
simpler,
but
I
think.
B
C
L
K
I
think
this
is
an
interesting.
This
is
here.
This
is
an
interesting
thing,
because
we
are
seeing
this
in
multiple
places.
We
have
a
draft
to
the
cigars
to
ask
about
what
the
policy
is
here
across
both
would
speak
off,
because
we
were
discussing
in
a
different
context
using
matching
namespaces
by
label
and
which
was
suggested
by
stakeoff,
but
many
people
have
good
points
that
it
may
lead
to
problems.
A
Yeah
so
yeah,
so
this
is
another
one.
A
Yeah,
I
think
it's
come
up.
Yeah
the
whole
default
policy
thing
has
come
up.
I
heard
it
come
up
before
as
well.
Wasn't
there
like
a
kept
around
this
too?
H
Know
yeah
valerie
had
a
kept
for
for
the
default
policies,
but
I
think
it
was
closed
because
a
lot
of
people
wanted
a
lot
of
things.
So
that's
right
here.
A
I
hope
that
doesn't
happen
to
us.
So,
okay,
so
yeah,
that's
that's
our
first,
so,
okay,
so
thanks
for
contributing
that
right.
So
I
think
the
best
thing
to
do
sandor
is
take
a
look
at
the
policy
api
see
if
you
can
come
up
with
something
I
think
a
little
more
concrete
here
in
terms
of
what
you
mean
by
a
secure
gateway
and
whether
or
not
you
think
changing
the
api
explicitly
is
something
you
you're
interested
in
just
reach
out
to
me
offline.
A
If
you
want
to
talk
about
it
more
because
I've
had
to
read
through
those
apis
a
bunch
recently
for
something
else
so
or
other
people
can
help
too,
I'm
sure
so
there's
that
one
are
there
any
other
new
use
cases
we
should
go
through
before
we
review
all
of
them.
B
B
A
Yeah
I
mean
I
think
this
should
be
really
be
the
last
week
that
we
add
more
because
we've
spent
like
so
much
time,
adding
more
so,
please
everybody
now
that
we
have
so
many
people
here.
Please
just
add
a
comment
on
the
doc
that
you
want
to
add
another
one
and
and
we'll
do
it
and
then
next
week
hopefully
will
be
the
end
of
all.
A
The
new
use
cases
is
that
is
that,
okay
with
everybody,
we
were
supposed
to
really
end
the
use
cases
a
week
ago,
but
I
feel
bad
about
doing
it
now
that
we
have
so
many
new
people
here
yeah.
So
let's
keep
going.
Okay,
so
add
a
level
of
indirection
this
one's
orange.
A
I
think
it's
interesting,
I'm
just
going
to
say
something
about
it,
really
quick,
which
is
that
this
is
almost
like
an
r
back
for
policies
right.
I've
talked
to
a
lot
of
people
about
it.
Talk
to
you
know,
and
some
people
are
interested
in
it.
Some
people
aren't
some
people,
think
it's
a
bad
idea.
That's
why
it's
orange.
A
If
anybody
wants
to
get
behind
that
and
champion
it.
Please
just
add
your
name
to
this.
Mike
spritzer
was
behind
it
for
a
while,
but
we
haven't
seen
him
recently
and
but
I
think
it's
a
cool
idea.
I
you
know
we
just
haven't,
found
a
way
to
really
move
it
forward
and
it's
a
heavyweight
change
of
course
right.
So
that's
one
of
the
ones
andrew.
That
would
definitely
be
v2.
I
assume
right
process
restriction.
A
I'll
introduce
if
no
one
outside
this
is
just
the
simple
situation
where
you
got
a
container
floating
around
in
a
cluster.
That's
you've
got
a
process
that
may
have
invaded
a
node
or
invaded
a
container
somehow
or
invaded
you
know,
invaded
a
network
namespace
or
whatever,
and
you
know
you
you
want
specific.
A
You
know
fine-grained
policies
that
are
capable
of
knowing
things
about
processes.
I
don't
know
how
it
says.
I
suggested
this,
but
it
was
really
me
like
writing
down.
Someone
else
suggested
it.
I
forgot
who
it
was
a
lot
of
people
agreed.
That
would
be
interesting,
nobody's
quite
sure
what
what
what
it
would
look
like
if
it
was
fleshed
out
named
cider
box
ip
sets
with
synthesized
labels.
I
think
cody
was
really
driving
this
one.
This
was
all
about
anybody
can
chime
in
on
these.
By
the
way
this
was.
A
I
think
this
was
related
to
this.
Was
people
have
also
talked
about
external
ciders
right
so
like
being
able
to
target
metadata
traffic
to
a
specific
source
or
destination
server.
A
Yeah,
I
think
it
was
to
create,
like
sets
of
ciders,
that
could
be
like
collectively
addressed
as
opposed
to
like
what
we
do
now,
which
is
we
just
you
can
just
you
can
give
it.
You
can
give
an
ip
block
like
manually,
but
you
can't,
like
you
know,
identify
that
ip
block
in
any
kind
of
semantic
way.
So.
A
D
Right,
I
mean
I
I
mean
I
guess
is
this
just
this:
just
for
a
slider
like
unbound
by
ingress
or
egress.
You
just
want
a
way
of
classifying
a
cider.
A
Well,
we
never
got
the
exact
use
case
written
out
for
this,
so
the
user
story
is
actually
an
implementation
detail
of
how
you
would
group
these
ciders
by
labels
right
and
so
yeah
that
always
winds
up
begging
the
question
of
whether
this
is
really
needed,
because
you
might
be
able
to
do
this
in
different
ways,
but
I
think
the
use
case
behind
the
use
case
here.
We
should
ask
cody
I'll
leave
a
note
here.
A
I
think
the
thing
here
was
that
you
want
to
be
able
to
manage
several
different
cider
blocks,
maybe,
as
like
you
know,
like
a
group,
and
that
that
is
not
something
that
you
can
do
right
now
right
by
by
like
managing
them,
managing
the
blocks
themselves
by
names
right
the
data-
that's
not
really
something
in
the
data
model
now,
but
you
could
do
some
kind
of
a
one-to-one
mapping
type
thing
between
cider
blocks
and
policies
and
make
specific
policies
for
them.
A
But
we
need
a
more
probably
clarify
that
use
case.
More
port
ranges
with
exceptions.
Does
anybody
have
anything
else
to
say
about
that
before
I
jump.
A
Yeah,
so
this
is
another
one
of
the
higher
level
use
cases
where
you
know,
like
you
may
have.
You
may
say,
like
this
whole
class
of
applications
wants
to
should
be
able
to
bind
to
any
port
above
or
should
be
able
to.
A
You
know,
access
service
cells
on
any
port
above
8
000
or
something
right
or
you
know,
which
means
you
know
you
may
we,
which
might
just
be
like
a
catch-all,
easy
way
to
manage
some
kind
of
a
legacy
application
which
you
know
you
don't
might
be
connecting
on
multiple
ports
for
for
different
things
right.
So
I
think
we
micro
vms
was
the
main
use
case
for
this.
We
also
had
spark
in
here,
but
I
don't
think
spark
counts
anymore,
because
spark
is
nowadays
it's
it's,
it's
very
kubernetes
native.
A
So
you
don't
need
to
worry
about
that
stuff,
but
micro.
The
idea
of
vms
and
containers
suddenly
becomes
a
really
interesting
use
case
here,
because,
if
you're
running
a
vm
inside
of
a
like,
if
you're,
if
you're
scheduling
a
vm-
and
you
want
to
apply
a
network
policy
to
it-
you
know
it
may
have
a
much
more.
You
may
want
to
give
it
a
lot
more
bandwidth
in
terms
of
what
it
can
do
and
what
it
can't
do
than
you
would.
A
typical
micro
service.
H
A
Yeah
yeah,
okay
cool,
you
know,
abhishek.
If
you
can
add
that
use
case
issue
link
in
here.
That
would
be
awesome.
Remove
hidden
defaults,
oh
yeah.
I
think
this
was
mine
because
so
I'm
not
like
I'm
a
little.
A
I
you
know
I
haven't
been
doing
the
network
policy
thing
for
for
super
long
right,
so
I'm
a
little
bit
new
to
this
whole
world,
and
so
I
started
working
on
this
stuff
about
you
know
six
seven
months
ago,
and
it
was
really
confusing
for
me
to
figure
out
all
the
null
fields
and
everything,
and
I
still
don't
really
remember
them
all.
But
like
there's
little
things
right,
like
you
know,
if
you
have,
if
you
have
like
an
empty
list
versus
a
missing
list,
we
have
completely
different
meaning
behind
those.
A
If
you
don't
have
an
ingress.
If
what
is
it,
if
you
don't
supply
and
if
you
don't
supply
any
policy
type-
and
you
say
then
it's
by
default
ingress,
which
means
that
if
you
have
an
egress
policy,
you
know
that
has
to
be
explicit,
and
so
you
have
a
lack
of
symmetry
in
the
api
there.
We
have
the
corner
cases
outlined
here.
These
are
pretty.
A
I
think
I
don't
think,
there's
a
huge
debate
that
it
would
be
nice
to
get
rid
of
the
defaults.
I'm
not
sure
whether
these
would
be
breaking
or
not
matching
namespace
by
name.
We
already
talked
about
that.
Obviously,
that's
makes
it
a
lot
easier
for
for
people
building
building
policies
zhang
had
this
interesting
thought
about.
A
Well
what
if
you
did
regex's,
because
you
could
imagine
how
easy
it
would
be,
then,
once
you
had
regexes
right,
because
you
could
say
all
the
namespaces
that
are
named
dev
dot
star
or
whatever
have
more
lenient
policies
than
the
ones
that
have
prod
dot
star
and
things
like
that
right.
I
think
a
lot
of
people
really
like
the
idea
of
name
space,
scoped
policies,
as
opposed
to
having
to
having
to
do
everything
with
the
labels,
especially
because
managing
multiple
labels
and
all
that
and
being
able
to
mutate
labels.
A
You
may
not
have
those
our
back
permissions
or
whatever
things
like
that.
I
don't
know
why.
My
was
that
related
to
the
administrative
policies
too.
I
don't
remember
whether
the
namespace
one
was
mixed
in
with
that
or
not.
A
Oh
yeah,
this
is
okay.
I
want
to
know
my
why
my
application's
not
receiving
any
requests
so
there's
a
collection
of
policies
in
here
that
are
more
about
like
meta,
tooling
type
stuff
where
yeah
this
was
ricardo's,
but
he
can't
ricardo.
Unfortunately,
ricardo
and
cody
both
had
like
last
minute
meetings
today,
so
they
both
couldn't
come,
but
they've
they've
both
done
a
lot
of
work
to
really
move
this
stuff
forward.
So
this
was
a
ricardo
policy.
A
I
think-
and
it's
just
a
situation
of
you
know
he's
got
you
know
a
whole
bunch
of
developers
and
they
just
don't
know
why
things
can't
talk
to
each
other
and
he
he
wished.
There
was
more
tooling
around
that
abhishek.
You
have
a
logging
rule,
also
a
logging
policy.
Do
you
want
to
talk
about
that?
Because
you
have
the
actions
and
the
logging
policies
and
that's
all
in
this
sort
of
scope
too
right.
A
Yeah,
so
I
think
we're
making
pretty
good
pace
here.
I
think
in
the
next
five
minutes.
I
think
I
can
get
through
all
these.
Then
we
can
up
level
this,
and
maybe
we
can
add
some
sanity
to
this
around.
What
you
were
mentioning
andrew
in
terms
of
maybe
we
can
address
the
whole
thing
of
like.
Where
should
we
start
and
what
should
we?
What
cutoffs
can
we
do
to
really
really
sort
of
make
make
some
tactical
progress?
I
want
to
define
default
cluster
network
policy.
A
We
already
talked
about
that.
You
know
administrative
policies
so
for
those
of
you
that
are
new,
I
guess
the
history
here
and
I
wasn't
necessarily
here
for
this.
So
anybody
who
knows
this
better
than
me-
please
do
correct
me,
but
these
were
originally
built
for
developers.
That's
what
the
network
policy
api
was
built
for
right.
So
I'm
a
developer.
I'm
writing
something.
A
I
want
my
pod
to
be
able
to
talk
to
certain
things
I'll,
just
I'll
just
like
write
those
policies
right
and
I'll
ship
it
with
my
app
and
I'll
apply
those
policies
to
my
pods.
So
I
know
my
you
know
that
was
kind
of
the
idea.
A
It's
kind
of
now.
People
are
really
a
lot
of
people
want
these
global
policies.
Some
cni
providers
have
global
policies.
You
know
we
know
of
at
least
two
I
know
calico.
Does
it
yeah
brad
has
them
as
well.
A
Exactly
yeah
and
so.
A
So
yeah
like
having
some
default,
you
know
cluster
scoped
ones.
You
know,
I
think
that
goes
without
saying,
because
there's
so
many
of
those
there's
mostly
like
several
cni
support.
Those
and
security
tools
support
those,
as
is
prioritizing
network
policies,
so
how
many
all
have
used
se
linux
before
right.
A
So
you
know
in
sc
linux
you
can
do
like
priorities
and
stuff
of
rules.
I
think
that's
that's
kind
of
where
this
is
coming
from,
like
you
know,
you
may
want
to
have
like
a
like
a
kill,
switch
right
like
where
you
say
you
know
I
I
I've
got
this
policy.
A
This
can't
talk
to
anything
else,
but
everything's
broken,
and
I
did
something
wrong
in
my
policies,
so
I
just
want
to
do
an
administrative
override
so
that
all
the
apps
can
start
working
again.
While
I
fix
this-
and
maybe
you
could
you
know
so-
that's
the
prioritization
thing
right
now,
policies
for
those
of
you
that
don't
know
are
kind
of
once
you
apply
a
policy.
Things
are
locked
and
then
you
layer
the
policies
on
top
of
the
pod
one
at
a
time
right
and
once
you
allow
something
it's
allowed
forever
right.
A
A
The
use
case
again,
I
think
of
is
administrative,
getting
everything
to
work
or
doing
the
opposite,
locking
everything
down,
because
you
have
some
kind
of
an
emergency
situation,
right
actions.
Abhishek,
you
want
to
introduce
this
one.
H
Yeah,
I
think
this
was
like
a
corollary
to
the
cluster
policy,
where,
instead
of
by
having
those
kind
of
defaults
of
you,
know
denying
traffic
and
allowing
certain
traffic
you
might
want
to
just
give
the
freedom
to
the
policy
writer
to
either
allow
traffic
or
deny
traffic
so
right,
particular
traffic
should
be
allowed.
This
particular
traffic
should
be
denied,
so
add
a
new
field
and
explicitly
set
the
action
for
that
rule.
A
Yeah
that
gives
you
some
decoupling
right,
so
you
can
define
things
that
target
target
namespaces
and
target
pods
and
all
that,
but
you
don't
necessarily
have
to
make
the
decision
upfront
about
what
those
do.
A
R
One
question
so
by
defining
an
sorry
to
interject,
so
one
question
with
respect
to
the
previous
user
story
here
is
like
by
defining
an
action
that
means
that
changes
the
current
assumption
of
network
policies.
That
is
always
allow
all
right
now.
If
I
have
an
action,
if
I
have
an
action
specified
against
a
rule,
I
mean
today.
If
I
specify
anything
that
means
everything
else
else
is
denied
only
that
port
is
specified
like
let's
say
if
I
specified
a
port,
only
that
port
is
allowed.
R
Everything
else
is
by
default
denied
now
by
defining
an
action
here.
Does
that
mean
the
similar
thing
like
if
I
specify
an
action
deny
on
a
specific
port?
Does
that
mean
everything
else
is
allowed.
H
No,
so
that
was
more
in
conjunction
with
like
cluster
scope
policies
and
not
the
existing
network
policies
which
would
be
meant
for
administrators
to
write
and
they
would
have
higher
precedence
over
the
kubernetes
network
policies.
So
so
it
won't
affect
the
existing
community
network
policy
defaulting,
and
that
was
the
use
case.
F
A
Yeah,
no
thanks
thanks
for
clarifying
that,
though
yeah,
because
I
I
get
confused
about
almost
every
one
of
these
policies,
so
actually
any
clarify
a
fine
question
that
anybody
wants
to
ask.
Please
do
because
there's
a
lot
of
ways.
A
We
can
interpret
these
service
level
policies
so
bowie's
here
today,
so
bowie
when
we
first
started
this
call
a
while
ago,
you
mentioned
that
this
work
should
co-evolve
with
what's
going
on
in
service
v2,
so
the
reason
that
people
I
think
would
want
to
target
a
service
from
a
policy
is
because
it's
a
more
natural
abstraction,
because
when
you're
running
an
application,
you
generally
think
of
that
application
as
a
service,
and
you
can
think
of
a
use
case
where,
for
example,
maybe
I
have
two
sets
of
pods
one's
a
stateful
set
one's
a
deployment,
and
maybe
those
pods
have
different
labels
on
them,
but
maybe
those
pods
both
subscribe
to
the
same
search.
A
Maybe
those
are
both
load
balanced
from
the
same
service.
That's
a
valid
kubernetes
use
case.
You
could
totally
do
that.
I
I
don't
know
why.
I
I
know
that,
because
I've
done
it
before
and
I
have
no,
I
know
it's
a
horrible
idea,
but
I
did
it
and
but
that's
like
one
one
one
example
of
this
use
case.
So
when
we
talk
about
service
v2,
though
there's
a
whole
another.
A
So
so
that's
one
reason,
but
then
there's
a
whole
service,
v2
angle
to
this,
I'm
not
as
up
on
the
service
v2
stuff,
so
whoever's
here,
that's
working
on
the
service
v2,
especially
when
you
talk
about
external
services
and
things
like
that.
A
A
Okay,
zang,
I
guess
you
were
the
original
author,
I'm
looking
at
this,
so.
F
So
I
I
wanted
to
add
one
more
angle
to
this
is
that
this
service
is
already
a
grouping
concept
right.
You
have
the
label
selectors
on
the
service
already
and
usually
a
service
maps
to
an
application,
or
it
can
have
multiple
deployments
behind
it
and
whatsoever
so
having
another
set
of
label.
Selector
on
network
policy
means
that
there's
must
be
some
kind
of
synchronization
between
one
level
policy
to
its
corresponding
service
configuration
right.
If
you
you
change
the
label,
selector
of
the
service
or
or
whatnot,
your
network
policy
also
needs
to
update.
F
Then
there's
a
synchronization
problem,
so
the
idea
of
using
network
policy
to
to
apply
it
to
a
service
basically
combine
the
two
grouping
mechanism
into
one
that
is
only
one
label.
Selector
would
be
effective,
and
that
is
the
source
of
truth,
and
I
think
I
mean
after
I,
after
the
initial,
like
the
the
current
now
policy
design,
I
think
most
of
the
early
contributors
admit
that
that
was
a
problem
so
yeah.
Hence
this
is
the
ask
of
having
no
policy
directly
applying
to
service.
A
Okay,
cool
yeah,
that's
great!
Now,
if
you
want
to
update
that
with
some
of
those
thoughts
feel
free
to
you
know,
because
so
one
of
the
things
I
was
hoping
was,
people
would
really
champion
a
few
specific
policies
that
they
cared
about
and
figure
out
how
to
organize
them,
because
there's
no
way
from
the
top
down
that
a
small
group
of
people
can
say
which
one
of
these
are
are
more
or
less
valuable.
F
Yeah
that
that's
also
an
angle.
Yes,
because
let's
say
you
have
a
network
policy
protecting
some
parts,
but
then
those
parts
can
be
accessed
through
no
ports
and
things
like
that
right
because
it's
gone
added
and
things
like
that.
So
it
doesn't
work
well
because
the
service
can
bypass
those
network
policies.
T
I
would
say
that
those
are
more
on
implementation:
science,
like
how
are
you
going
to
be
showing
consistency
there,
but
the
user
story
by
itself
is
talking
about
the
gap
which
we
just
couldn't
do
right
now.
For
for
some
cases
you
can
check
the
user
story
for
the
detail,
but
I
agree
that
if
you
think
about
the
implementation
side,
yes,
that.
A
So
so,
there's
the
whole
headless
service
thing
too
right.
I
think
that
was
part
of
the
angle
too.
Right,
like
you,
may
want
to
actually
have
policies
that
target
services
that
aren't
even
pods
right.
T
Right
right
also,
for
example,
you
can
use
a
service
to
direct
it
to
some
external
database.
If
you
only
want
some
parts
to
access
to
that
database
right
now,
you
have
no
way
to
do
it.
You
almost
have
no
way
to
do
it
because,
right
now
you
can
only
use
egress
policy
of
the
path,
which
means
you
have
to
use
a
white
list,
which
means
you
have
to
list
all
the
things
that
pal
allowed
to
talk
right.
T
A
The
irony
of
this
use
case
is
that
you
know
cloud
sql
was
my
first
experience
with
that
use
case
a
few
years
ago.
You
know
so
yeah
providers.
They
really
need
it.
So
I'm
not
surprised
that
the
folks
from
google
came
up
with
this
so
yeah.
A
lot
of
people
need
that
so
network
policy,
egress
rule
for
the
kubernetes
api.
Oh,
who
was
adam,
did.
Did
you
get
to
introduce
yourself?
I
forgot.
A
Oh,
I
don't
know
if
he's
here
so
so
this
is
a
this
is
one
that
maybe
there's
a
solution
to
it.
I
just
don't
know
what
it
is.
So
you
know
you've
got
your
your
kubernetes
service,
which
is
created
on
a
cluster
inception
right,
creating
an
explicit
policy
for
that
service.
A
B
A
Yeah
I
mean
that
this
would
solve
this
would
yeah.
This
would
solve
that
use
case,
but
it's
a
I
mean
it's
a
separate
use
case
and
that
it's
specific
to
the
kubernetes
api,
but
you're
right.
It
could
be
combined
with
that
right.
So
maybe
we
should
just
say.
A
O
A
little
confused,
I'm
not
sure
I
understand
it,
looks
like
so.
The
user
story
starts
by
talking
about
denial,
ingress,
yeah,
yeah,
and
now
I
was
talking
about
egress.
S
B
O
O
O
A
Okay,
so
oh
that
was
you.
That
was
the
person
that
was
also
talking
so
okay.
B
A
A
B
I
think
I
think
I
misspoke
earlier
so.
Api
server
isn't
always
running
in
a
pod,
but
if
you
were
running
in
like
a
static
pod,
maybe
you
can
label
it
and
use
that,
but
I
don't
think
you
can
assume
that
it
is.
You
can't.
O
H
A
O
I
think
my
point
is
simply
that
what's
being
requested
here
is
not
support
for
servers
not
running
in
a
pod.
It's
not
requesting
support
for
service
abstraction,
it's
requesting
being
able
to
implement
that
currently
valid
syntax
in
apparently
some
cases
where
it's
not
correctly
implemented.
Today,.
D
Yeah
for
what's
worth,
I
also
agree
with
mike
this.
The
desired
as
written
is
syntactically
valid
and
would
work,
so
we
need
to
make
sure
the
assumption
is.
Is
he
just
trying
to
cover
the
case
where
you
know,
as
mentioned,
the
host
network
would
not
be
something
that
cni
authors
have
traditionally
covered
and
also
maybe
this
is
something
combined
with
one
of
the
other
previous
things
where
you
want
to
redirect
this,
to
something
that
isn't
necessarily
a
pod.
O
A
O
Have
a
confusion,
another
point
here:
why
are
we
talking
about
egress
at
all?
Why
aren't
we
doing
this
as
ingress.
O
A
O
A
Yeah
we
need
to
okay,
let's
yeah,
so
he
def
okay,
so
we
definitely
need
to
get
that
figured
out.
Basically,
he
needs
to
separate
this
use
case
into
the
two
different
categories
we
talked
about
at
the
very
least.
A
Yeah,
we
probably
should
just
get
his
specific
like.
What's
he
trying
to
do
now,
here's
a
whole
section,
so
we've
got
oh
gosh,
it's
been
so
fast,
okay,
so
this
is
in
one
minute.
There's
all
this
whole
discussion
around
stuff,
that's
tools
that
are
higher
level
policies.
Policy
controllers
me
and
cody
were
batting
around
this
idea
of
building
a
policy
ctl,
something
that
you
could
use
to
generate
policies
at
a
higher
level
without
actually
changing
the
api.
A
So
there's
a
whole
bunch
of
body
of
like
ideas
around
that
that
people
have
proposed-
and
we
put
all
those
into
a
separate
category
just
to
constrain
things
a
little
bit.
So
if
anybody
wants
to
read
over
those
possibly
talk
about
hacking
on
one
of
these
things
on
the
site
or
something
that
could
possibly
be
a
useful
tool
that
we
build,
maybe
that
didn't
even
change
the
network
policy
api
just
as
a
group
of
people
that
want
better
tools.
A
Please
do
look
at
these
and
I
think
these
two
do's
there's
node
policies,
so
these
are
really
important.
Everybody
wants
them
and
I
think
we've
all
discussed.
This
would
be
part
of
v1
right.
Andrew
a
few
people
have
mentioned
that
I
believe
you've
talked
to
some
people
about
that
as
well.
Right.
A
Yeah
but
there's
yeah,
so
there's
a
lot
around
this.
We
don't
have
a
lot
of
time
to
go
through
it.
Now
we
can
look
at
them
again
later,
but
node
policies
and
the
defaults
making
those
monitoring
specific
from,
like
some
policies
for
monitoring
specifically.
B
A
B
Ask
the
ask
from
tim
hopkins
before
we
start
talking
about
like
api
changes,
either
to
the
existing
v1
api
or
either
to
a
new
v2
api.
We
need
to
all
get
agreement,
or
at
least
like
a
majority
consensus
on
the
user
stories,
and
ideally
we
have
them
all
prioritized
on
like
what
we
think
is
the
highest
priority
one
and
what
we
think
it.
You
know
and
stack
linked
them.
A
Yeah
so
we've
got.
I
think
we
have
to
do
this.
Do
this
again
next
week,
though,
because
we
have
a
few
more
to
go
through
right
and
it
sounds
like
we
have
so
many
new
people
here
that
I
think
we're
gonna
have
to
start
over
on
some
of
them
so
probably
next
week
we
should
probably
go
through
these.
Maybe
again
you
think,
or
how
should
we
do
this,
because
we've
kind
of
started
to
stack
our
income?
I
just
feel
like
the
group
we
had,
that
was
doing.
L
Sorry,
can
I
ask
a
clarification
question.
This
is
governed
here
again
from
google.
I
just
wanted
to
understand
this.
The
intent
here
to
do
network
policy
v
1.1.
Is
it
v2
or
is
it
like
doing
crds
to
add
to
the
existing
network
policy
fold
or
everything
all
of
the
above,
like
I'm
just
trying
to
get
a
sense
of
like
what?
What
are
what
is
our
target
for.
L
L
L
A
Thanks
so
I'm
glad
you
asked
that
yeah,
because
hopefully
even
if
we
can't
do
some
of
these
as
part
of
the
official
seg.
B
A
L
See
some
really
interesting
use
cases
like
that
are
marked
in
red,
and
you
know
I
just
wanted
to
understand
like
when
when
and
if
we'll
ever
tackle
them.
A
Yeah
yeah
yeah
yeah,
okay,
yeah
cool,
so
okay,
so
we
got
two
minutes.
I
just
want
to
open
this
up
for
other
people
to
talk
and
I
don't
really
care
if
we
go
over
time,
because
this
is
new
but
whatever
does
anybody
have
anything
else?
They
want
to
talk
about.
B
A
Yeah
I
mean
I
feel
like
the
biggest
thing
we
could
do
to
really
move
this
forward
is
if
people
could
start
putting
their
names
on
some
of
these
stories
and
read
through
them,
because
I
don't
think
everybody's
going
to
be
an
expert
on
all
the
stories
right.
But
if
everybody
who's
really
interested
in
a
policy
could
get
put
their
name
on
one
or
two
or
three
or
four
of
them,
then
you
know
we.
We
could
have
people
to
point
to
to
really
formalize
these
policies
as
we
as
we
try
to
harden
the
story
around
them.
A
That
would
be
my
ask,
so
please
just
pick
a
few
of
these
that
you
care
about
and
read
through
all
of
them.
If
you
can.
A
A
In
the
way
that
would
be
needed
to
to
really
make
a
really
good
story
on
them.
That
would
be
my
ask
and
come
back
and
hang
out
with
us
and
propose
new
ideas,
even
if
they
don't
get
into
this
specific
talk,
because
that's
what
makes
this
fun
for
me
right.
A
A
No,
that's
no
it's
great!
So,
but
here's
what
we
did
since
since,
since
the
last
I
think
time
you're
here
is:
we've
got
these.
That
kind
of
everybody
kind
of
agrees
on,
and
we
kind
of
put
these
all
at
the
top,
and
then
these
are
at
the
bottom.
So
I
think
next
time
we
can
flesh
this
spreadsheet
out
and
revise
it.
A
Does
anybody
have
any
other
questions
about
like
any
of
these
policies?
What
they
mean
that
we
want
to
talk
about,
and
the
other
question
I'll
ask
before
you
end
is:
does
anybody
want
to
get
more
involved
with
this
and
want
to
possibly
meet
again
this
week
to
prepare
for
monday,
since
there's
a
lot
of
new
people
here?
A
V
This
is
aniket
here
from
red
hat.
If
you
go
back
to
that
spreadsheet,
is
there
a
desire
to
add
a
column
for
what
use
cases
would
get
implemented
in
api
v1
versus
in
api
vu
1.1?
Have
you.
A
No
that
we
haven't
figured
that
out
yet
that
was
something
andrew
mentioned-
is
pretty
high
priority
right,
like
figuring
out
now
that
now
that
we've
got
all
these
ideas,
what
can
we
actually
do,
and
when
can
we
do
them
right?.
A
Yeah
last
week,
we
there's
like
differing
opinions
on
that,
but
I
agree
like
having
v1
v2
in
here
would
be
great,
so
this
spreadsheet
is
it
linked
from
the
top.
Let
me
link
this
here.
Please
folks,
add
columns
to
this
add
any
columns
you
want.
You
know,
because
and
especially
that
one
right
user
stories
rankings
so
I'll
add
that
to
this
spreadsheet.
So
if
you
all
want,
you
can
kind
of
add
a
column
there,
anybody
and
start
specking
out
like
what
might
be
v1
and
v1
or
v2.
A
We
may
have
to
go
through
it
all.
As
a
group
anyways,
though
cool
so
go
bend,
yeah,
please,
let's
just
just
reach
out
on
cygnet
and
we'll
talk
more
and
anybody
else
that
wants
to
like
kind
of
do
like
a
do
like
a
turbo,
get
up
to
speed
on
where
everything
at
where
everything's
at
and
maybe
carve
up
some
ownership
here.
That
would
be
cool.
A
L
Awesome
and
just
one
one
final
question:
I'm
seeing
some
comments
here
on
some
user
stories
that
say
that
explicitly
say
not
a
user
story
c
above
from
a
gentleman
named
dan
winship.
I'm
just
trying
to
understand
what
that
means
and
if
there's
a
certain
format
that
needs
to
be
adhered
to
or
something.
A
I
think
yeah
there
is
a
format,
but
I
think
what
happened
was
we
tried
to
reach
that
format,
and
then
we
found
that
it's
very
hard,
yeah,
okay,
so
recently
kind
of
like
got
lazy
about
it.
But
it's
really
everybody
disagrees.
It
seems
like
on
what
a
user
story
is,
and
I
think
the
the
best
way
to
figure
out
whether
something
is
a
user
story
is
if
somebody
says
this
isn't
a
use
user
story
and
then
you
fix
it
one
at
a
time
but
yeah
I
mean,
as
you
read
through
these.
A
If
things
look
too
implementation,
specific
okay,
if
anybody
has
a
chance
to
improve
the
user
story
up
level
it
a
little
bit
so
that
we
don't
just
deep
dive
into
a
bike
shed
about
apis.
That's
great,
I
think
a
lot
of
those
suffer.
From
the
same
from
the
same
comment,
though,
it's
very
very
hard
to
write
a
yoga
story.
A
So
yeah,
but
yeah,
please
anybody
feel
free
to
improve
this
stuff.
These
are
open
documents,
for
the
community
to
work
on
right
and
more
ownership
is,
is,
is
something
we
need
so
thanks.
Everybody
we've
gone
a
little
over
time
and
so
like
that's
it
I'll.
Just
I'll
just
leave
it
at
that,
and
we
can
all
hang
out
again
soon
and
we
can
talk
in
sick
network
about
possibly
having
an
intermediate
meeting
between
now
and
monday
to
get
other
folks
up
to
speed.