►
From YouTube: Network Policy API Meeting 20210614
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
A
So
going
ahead
and
getting
started
on
the
agenda,
I
checked
out
the
issues
didn't
see
any
new
issues
today,
which
involving
network
policy,
which
is
always
good
if
people
are
ever
interested
in
how
I
do
that,
there's
a
link
up
at
the
top
of
the
sheet
titled
issue,
triage
link
and
that's
where
I
essentially
look
for
new
issues.
But
what
I'll
that
shows
you
all
the
issues
with
I'll
share
my
screen.
That
shows
you
all
the
issues
with
the
network
policy
area
network
policy
tag,
but
not.
A
All
of
the
issues
that
haven't
been
triaged
into
that
so
I'll
show
you
what
I'm
talking
about
here.
As
you
can
see,
these
are
all
area
network
policy,
but
a
lot
of
times
they
won't
get
the
correct
label.
So
you'll
need
to
query
all
the
issues
and
just
kind
of
look
through
and
see.
If
there's
any
pertaining
to
network
policy,
which
is
what
I
do
every
week,
the
most
recent
one
was
17
days
ago
and
we've
already
kind
of
been
over
it
we're
just
waiting
for
a
response
from
the
reporter.
A
A
So
I
also
wanted
to
give
a
quick
shout
out
to
tom
tom
if
you
want
to
give
a
quick
intro
he's
another
engineer
from
red
hat
who's
gonna,
hopefully
be
stepping
in
and
helping
out
here
so.
B
A
Just
wanted
to
give
him
a
quick
shout
out
and
get
some
stuff
done
cool
and
if
I
ever
forget
any
week,
if
there's
new
people-
and
I
don't
notice-
it
tell
me
to
stop
the
beginning
and
we
can
give
them
a
shout
out
and
introduce
them
to
the
group
so
moving
right
on
through
I
know.
Last
time
there
was
some
discussion
about
the
api
groups
change
that
start
was
started
on
the
gateway
api
repo.
A
A
A
What
about
sorry,
andrew
the
discussion
around
moving
from
x-kate's
dot,
io
group
to
k-8s
kind
of
blossomed
into
another
discussion
like
it
usually
does
into
creating
an
api
groups
registry
within
sig
network,
or
maybe
not
even
with
instinct
network
but
for
all
of
kubernetes?
A
Yeah,
it's
there's
always
something
there.
This
was
from
antonio
and
tim
is
a
big
fan
of
it.
C
Okay
now
I
was
gonna
say
I
did
take
a
look
at
this
issue
and
tim's
comment
and
I
think
it
makes
sense
because
you
know,
as
as
there
are
more
subgroups
or
more
people
using
the
case
or
io
or
any
other
reserved
api
group
and
wants
to
create
subgroups
out
of
it.
I
think
management
of
these
api
names
across
those
subgroups
is
becomes
becomes
a
challenge
so
having
a
sort
of
a
convention
around
that
and
some
sort
of
group
or
registry
for
this
makes
sense.
C
I
was
a
bit
confused
on
if
you,
if
you
scroll
a
little
down
further
down
under
the
topic
of
sub
scoping
yeah,
you
see
there
is
the.
C
The
second
point
I
think,
he's
basically
or
tim
is
basically
trying
to
provide
some
sort
of
convention
for
such
names,
and
I
think
one
of
the
things
that
he
mentions
that
do
not
embed
the
resource
name
as
part
of
the
group.
So
so
we
were,
we
are
looking
at.
You
know
creating
a
subgroup
under
the
networking
case.
I
o
for
our
crds
anything
network
policy
api.
C
So
I
was
kind
of
like
confused
as
to
whether
network
policy
or
something
like
that
resource
name,
dot
case
or
io
would
make
sense
or
not,
and
I
I
didn't
quite
understand
whether
he
when
he
say
his
counter
example.
Does
that
mean
like
he
is
willing
for
willing
to
do
some
exceptions
or
he's
he's
just
trying
to
you
know,
give
examples
of
what
should
not
be
the
name
of
the
api
group.
So
in
our
case
we
should
not
have
networkpolicy.networking.case.io,
as
the
group
name.
A
C
Yeah,
I
think
you
know
for
like,
for
example,
ingress
they
did.
They
chose
not
to
have
the
ingress
name
in
there
because
they
went
ahead
with
gateway
dot
authority
is
proposing
gateway.networking.com
or
something
on
similar
lines.
So,
if
that's
the
case,
then
maybe
we
would
also
need
to
think
about
some
of
it,
like
a
generic
term
under
network
policy.
Sorry
under
networking
yeah,
that's
the
that's
the
proposal,
I
think,
which
is
gaining
more
momentum
than
other
names,
but.
A
A
It's
something
that
we'll
probably
need
to
follow
as
we
get
further
along
with
the
cmp
stuff,
obviously,
because
that'll
be
following
whatever
we
do.
C
A
Cool
great
so
yeah,
I
just
wanted
to
highlight
that
obviously
go
comment
away
on
any
confusion.
D
D
E
C
Yeah,
I
agree,
and
I
think
that's
one
of
the
reasons
why
the
the
routing
is
not
gaining
any
votes
for,
for
that
particular
yeah.
Yeah.
A
Yeah
pair
go
give
your
go
say
that
on
the
on
the
issue,
I
think
that's
another
really
good
point.
I
totally
agree
with
you.
It's
overloaded.
A
Great
so
yeah,
I
just
wanted
to
bring
that
up
and
document
it
in
the
agenda.
The
next
thing
on
the
list
was
something
I
put
as
a
to
do
from
last
week,
which
was
to
bring
in
legacy
docs.
I
opened
a
pr
that
basically
brings
all
of
jay's
old
tracking
repository
into
network
policy
api.
There
might
be
some
more
stuff,
we
need
to
add
here.
A
So
I
know
avashek,
you
have
an
issue
open
for
something
similar,
so
feel
free
to
comment
and
tell
me
that
we
need
to
add
more
stuff
here.
I'd
like
to
just
get
it
all
done
in
a
single
pr,
so
open
to
comments
on
that.
A
And
obviously,
jay
isn't
here,
but
I'd
love
to
hear
what
you
guys
think
about
it
cool
that
was
just
something
small
so
on
to
the
main
meat
of
the
what
we're
doing
today,
the
user
stories
are
still
up
on
the
repo
now
for
both
v2
apis
thanks
to
prasad
and
nadeem,
and
also
cluster
scope
policy.
A
So
I
don't
know
if
we
wanted
to
highlight
kind
of
where
we
are
with
cluster
scope,
policy,
yang
or
abhishek
really
quickly
or
run
through
anything
with
the
group
as
a
whole,
and
then
we
can
shift
over
to
prasad
and
nadim.
To
give
a
quick
note
on
the
news
stories
they
just
added.
Does
that
sound
good.
F
F
I
think
you
did
make
a
comment
on
how
this
can
serve
as
a
justification
for
the
default
network
policy.
Maybe
do
you
do
want
to
talk
a
little
bit
on
on
that
front.
C
Yeah,
so
I
think
one
of
the
key
things
that
was
missing
in
the
the
kept
was
that
there
was
no
use
case
which
was
justifying
a
new
crd
or
anything
which
would
involve
a
default
network
policy
theory.
C
So
so
I
was
looking
to
add
something,
and
then
you
know
I
was
going
through
the
original
discussion.
Young
has
uploaded
and
one
of
that
story
the
zero
trust
story,
which
is
this
kind
of
resonates
in
terms
of
like
it.
It
sounds
like
you
know.
We
are
talking
about
something
like
a
default
posture
for
your
clusters
and
then
it
also
adds
on
top
of,
like
you
know,
some
certain
allow
rules
should
be
part
of
this
cluster,
because
you
know
you
want
that
critical
traffic
to
flow
through
your
cluster.
C
For
example,
all
your
parts
should
be
able
to
talk
to
core
dns
and
and
that
and
that's
something
that
should
be
a
strict
policy
rather
than
a
weak
policy.
But,
on
the
other
hand,
you
may
want
to
start
with
a
cluster
which
does
not
allow
any
intra
name,
space
or
sorry
any
traffic
to
flow
through,
and
you
need
your
name
space
owners
to
explicitly
open
up
traffic,
so
so
that
is
something
that
justifies
the
default
network
policy
use
case.
C
So
I
think
I
wanted
to
highlight
that
you
know
this
is
the
user
story
that
you
know.
I
I
just
put
the
tldr
at
the
top
that
the
use
case
here
can
be
solved
by
a
default
network
policy
which
default
denies
the
clusters
and
then
a
couple
of
cluster
network
policy
rules
which
allows
the
critical
traffic
and
then-
and
then
you
know,
individual
namespace
owners
can
write
their
own
network
policies
to
allow
their
services
to
communicate
with
each
other.
So
I
think
this
story
gives
like
a
good
good
use
case.
A
Yeah-
and
I
think
you
know
that
was
one
bit
of
feedback
from
the
original
kept
was
we
don't
you
know?
Maybe
there
isn't
a
good
enough
justification
for
dmp,
but
I
I
tend
to
agree
with
you
here.
I'm
gonna
read
through
it
again
this
week
and
add
some
comments.
There
are
there
any
other
thoughts
on
the
xero
trust
cluster
user
story
from
anyone
else?
If
people
have
had
time
to
read
through
these.
G
Well
so
abhishek,
I
have
a
couple
of
questions.
I
didn't
go
through
this,
but
so
is
this:
a
dnp
is
part
of
the.
You
know,
post
evaluation
of
the
network
policy
or
how
does
it
work.
C
C
So
similarly
it
is
also
something
that
will
come
out
after
the
cluster
is
initialized,
because
you
know-
or
I
mean
you
can,
you
can
have
additional
tooling
on
top
of
it,
wherein
whenever
your
clusters
are
created,
you
have
a
dnp
which
performs
this
dnp
sorry
which
performs
this
default
demand
for
your
clusters,
and
that
way
you
know
as
soon
as
your
cluster
is
initialized.
You
have
a
defaulting
eye
posture,
but
you
know
in
in
general,
this
behaves
in
in
similar
ways.
C
G
A
Yeah-
and
I
assume
once
we
get
to
the
point
of
of
conclusion
on
discussion
on
these
user
case
user
stories
like
in
the
cap,
abhishek
did
a
good
job
of
laying
out
the
president
precedence
there
and
it's
a
little
clearer,
like
we're
kind
of
looking
at
it
a
little
backwards
with
this
one.
By
saying
we're
building
this
to
justify
the
default
network
policy,
but
yeah.
C
But
but
that's
not
the
so.
The
the
proposal
has
two
crds,
but
that's
not
the
only
way
to
solve
this
problem.
If
we
can
have
a
hybrid
approach
and
we
have
laid
out
alternative
proposals
in
the
cap,
so
yeah,
so
you
know
whatever
is
best
for
users.
You
know
which
is
more
intuitive.
I
think
we
would
go
with
that,
but
currently
the
proposal
calls
out
for
two
separate
crds,
because
it's
separating
the
intent
one
is
for
stricter
rules.
The
other
is
for
me.
A
Yep,
I
agree
and
I
wasn't
able
to
make
it
on
thursday
to
the
sig
network
meeting.
But
did
you
were
you
two
able
to
go
ahead
and
present
those
three
user
stories?
You
really
were
ready
to
get
review
on
there.
F
Yeah,
I
think
we
did
mention
on
you
know
those
reused
stories
are
ready
for
review
so,
but
we
didn't
get
attempt
time
to
basically
present
it
on
the
signal
per
se,
but
tim
has
a
very
caught.
You
know
regular
comments
on
you
know
if
we
want
this
storage
to
be
reviewed
and
seen
by
the
sig
network.
Guys
we
just
needed
to
you
know,
make
some
noises
on
the
snack
channel
and
you
know
maybe
even
pin
people
to
let
them
know.
Okay.
This
is
ready
for
review.
F
Please,
you
know,
take
a
take,
a
look
at
it
and
stuff,
which
is
what
we're
going
to
do
in
in
this
week.
I
think
yeah
this.
This
is
one
thing
and
I
also
wanted
to
bring
up
two
small
points.
F
One
is
that
in
last
thursday
network
meeting,
I
think
tim
was
originally
preparing
a
topic
to
go
over,
which
is
how
the
the
ip
block,
probably
in
the
current
network
policy,
which
is
closely
related
to
you,
know
our
question
our
policy
proposal
right,
but
unfortunately
I
think
he
didn't
get
time
to
go
through
this
topic
last
in
the
last
meeting.
F
So
he
did
postpone
this
as
a
agenda
item
for
the
next
sig
network
meeting,
which
is
gonna
happen
next
thursday,
we'll
close
still
closely
monitor
this
and
see
how
it
goes
and
we'll
update
the
discussion
with
the
with
this
group
and
the
other,
and
the
other
thing
I
wanted
to
mention
is
that,
in
addition
to
the
user
stories
that
we
are
still
refining
and
gathering
feedback
on
this
repo-
and
we
did
abject-
and
I
did
made
some
updates
on
addressing
the
comments
from
the
original
cluster
network
policy
cap
as
well
as
did
a
little
bit
of
modification
to
the
original
api.
F
So
one
big
change
is,
I
think,
when
a
lot
of
people
review
the
original
pr,
they
think
the
some
people
think
the
three
actions
are
a
little
bit
awkward.
F
The
the
the
action
that's
a
little
bit
awkward
is
the
authorized
action
which
a
lot
of
people
think
didn't
make
sense,
and
tim
also
commented
on
this,
where
he
thinks
that
authorized
action
has
a
big
problem
where,
if
you
authorize
something
like
authorize
traffic
from
your
same
namespace
and
then
deny
everything
else,
we
are
essentially
saying
that
you
know
the
space
cannot
be
segmented
anymore,
because
the
authorize
is
such
a
strong
allow
and
if
you
use
it
to
just,
do
the
name
space
isolation,
then
it
just
doesn't
reflect
our
initial
reflect
our
initial
intention,
intent
in
in
this
regard,
so
taking
his
advice,
I've
basically
redo
the
authorized
to
a
new
action
called
empower.
F
So
now
we
have
three
actions
still,
but
it's
in
power
deny
and
allow,
and
following
up
on
tim's
suggestion
that
what
the
empower
essentially
does
is
that
if
the
rule
is
empowered,
it
basically
skips
the
denial
rule
evaluation.
So
I'm
not
explicitly
saying
that
this
should
be
allowed,
but
it's
basically
providing
an
exception
to
the
denial
rules.
F
Now,
with
those
three
actions,
I
think
we
can
still
express
all
the
intents
that
we
have
in
all
the
user
stories
that
we
put
up,
but
it's
a
little
bit
more
clear
and
it's
a
little
bit
more
flexible.
So
this
is
what
we.
This
is
something
that
we've
done
to
do
some
further
enhancements
to
the
cap.
If
you
guys
wanted
to
also
take
a
look
and
see
if
that
makes
sense
to
you,
it
will
be,
it
will
be
awesome.
A
C
Allow
something
we
rather
would
want
name
space
owners
to
makes
to
make
those
decisions,
so
that
definitely
makes
a
lot
of
sense
and
I
think
that's
something
that
we
missed
out
in
the
beginning.
So
I
respect
him
generally,
you
know
if
he
say
same
thing
that
it's
it's
mostly
very
valid
point.
A
So
yeah
I
mean
it
kind
of
aligns
right.
So
the
only
place
we
had
exceptions
for
people
who
hadn't
thought
about
this
before
I
guess
is
with
ip
blocks
right.
So
if
blocks
were
a
way
to
say,
allow
traffic
from
certain
external
networks
or
two
external
networks
with
exceptions,
so
you
could
have
a
small
subset,
a
small
subset
of
the
network
allowed
and
some
not
and
so
now,
you're
kind
of
bringing
that
powerful
exception
model
to
actions
which
we
didn't
have
before.
A
So
I
think
it
makes
sense
with
the
current
api
in
that
regard,
so
cool
good
job,
yeah.
C
Be
great
if
folks
on
this
call
can
do
one
round
of
review
of
this
offline
and
provide
comments,
because
I
think
that
will
really
help
us
get
this
api
correct.
You
know
there
might
be
some
blind
sides
that
we
are
ignoring,
and
you
know
the
group
here
can
help
us.
You
know
bring
that
out
in
the
open.
A
C
So
the
current
proposal
is
for
default
network
policy
to
be
more
aligned
with
kubernetes
network
policy,
in
a
way
that
it's
quite
loose
right
list
rules
only
which
is
which
has
a
default
isolation.
C
C
C
Also,
you
know,
there's
nothing
below
the
default
network
policy,
so
empower
would
essentially
means,
like
you
know,
it's
a
waterfall
model
where
you
know
after
these
rules,
you
actually
fall
back
to
the
lower
level
rules,
but
since
there's
nothing
below
the
default
network
policy
at
least,
I
can't
think
of
a
reason
why
we
would
need
an
empower
action
there,
but
I
could
be
wrong,
so
maybe
we
can
think
through
some
use
case,
which
requires
some
of
that.
Then
then
we
can.
We
can
think
of
altering
the
crd
for
dnp
totally.
A
Makes
sense
the
only
reason
I
keep
harping
on
it
too
is
I
don't
know
what
ricardo
thinks
or
what
other
people
think,
but
I
think
selling
the
default
network
policy
is
going
to
be
the
one
of
the
harder
parts
like
because
people
just
aren't
they've
never
heard
of
it
in
sig
network
right,
it's
a
whole
new
idea
and
I'm
not
saying
it's
a
bad
idea
at
all,
but
like
they
want
everyone
kind
of
wants
a
cluster
network
policy,
but
then
you're
like
well.
A
C
A
Yeah
exactly
and-
and
you
know-
maybe
it's
something
at
the
end
of
the
day-
better
left
to
v2
instead
of
apis.
Maybe
we
don't
want
to
necessarily
encompass
that
feature
until
then,
but
I
guess
time
will
tell,
but
thanks
for
all
the
great
work
are
there
any
other
questions
for
abhishek
and
yang.
A
Great
awesome,
thank
you
all.
So
let's
keep
some
reviews
there
and
then
I
wanted.
So
I
know
you
got
prasada
nadim
posted
a
bunch
of
v2
user
stories,
so
I
would
like
to
go
over
those
as
a
group.
Maybe
not
today.
Let
me
pull
them
up.
D
Yeah,
so
when
would
you
use
the
stores,
do
we
have
somewhere
listed
sort
of
what
they
call
it?
The
valid
actors
are
for
different
versions,
I
mean
for
for
clusters.
Obviously,
when
we
zoom
out
it's
the
operator
right
and
for
the
old
ones,
I
assume
that
it's
the
person,
that's
that
is
running
the
service,
but
I
mean
when
we
go
to
v2.
Can
we
can
we
start
sort
of
just
looking
at
who
are
the
actors
and
what
are
the
different
cases?
From
that
perspective,
we
want
to
to
cover.
D
So
if
you
look
at
well,
I
used
to
work
at
ericsson,
don't
work
there,
but
someone
that
writes
applications
that
they
don't
run
the
right
applications
or
service
stuff
like
that
that
they
sell.
That
then
gets
that.
That
is
then
run
by
let's
say
a
telco
and
you're
going
to
have
many
of
them
that
be
run
for
different
tenants
on
top
of
a
cluster,
that's
operated
by
someone
right.
Can
we
cover
that
as
well?
What
are
the
vision?
What
are
the
sort
of?
D
How
would
the
and
ericsson
be
able
to
write
network
policies
for
their
application,
but
then
gonna
run
on
the
terminators
cluster
somewhere
and
you're
going
to
have
10
different
instances,
100
different
instances
of
the
same
application
for
different
of
18ts
customers?
How
do
you
write
the
network
policies
that
make
sense
answer?
What
is
the
model
we
want
to
see?
Should
they
more
write
templates
that
get
instantiated
every
time?
That
is
a
sort
of
a
new
network
policy?
That's
created
for
each
of
those
instances,
or
do
we
have
network
policies
that
are
call
it
more
instantiated?
D
A
I
mean
I'm
open
to
seeing
user
stories
right,
so
the
user,
each
individual
user
store.
You
should
start
with
what
the
main
persona
is.
D
Right,
you
know
for
sure
more
should
we
also
sort
of
build
up
some
model
that
describes
which
user
person
our
personas
we
see
and
where
they
fit
as
part
of
this,
so
we
we
can
say
so.
We
have
standard
name
and
try
to
understand
what
what
use
cases
fits
for
the
different
for
different
roles
than
an
attack
them.
D
So
it's
something
so
it
spins
in
my
head
off
and
on
right
now
I
was
looking
at
a
lot
of
call.
It
5d
use
cases
where
you
have
a
lot
of
secondary
networks
and
you
have
a
lot
of
5g
enterprise
customers
running
on.
Let's
say:
18
t's
clusters.
They
might
spin
up
like
500
customers
right
in
one
customer,
then,
and
they
all
run
their
enterprise
5g
or
the
same
service
just
over
different
networks.
So
how
would
you
describe
policies
in
a
way,
so
it
says
manageable.
G
So
so
per
one
of
the
I
mean,
maybe
it
doesn't
address
fully.
The
50
user
story
is
trying
to
cover
what
you're
asking
which
one,
the
fifth
user
story,
which
is
the
policy
that
I
looked
at
some
of
them.
Yeah
policy
repetitions.
D
G
Yeah,
so
so,
as
you
mentioned,
like
you
know,
I
mean
user
might
have.
I
mean
one
example
we
took
is:
let's
say
I
have
a
kubernetes
network
policy.
I
mean,
are
any
policy
right,
we
wanted
to
go
through
a
deployment
phase,
I
mean
development,
phase
deployment
or
maybe
pre-production,
or
it
could
be
repeated
across
custom.
You
know
different
customers,
so
we
try
to
introduce
a
in
a
match
class
here.
G
D
For
sure
so,
for
me,
like
I
said,
I
see,
sort
of
three
different
one
is
the
per
the
organization
writing
the
application
and
sort
of
they
might
want
to
set
up
both
network
policies
and
some
sort
of
way
to
to
me
break
apart
the
network
attachment
definitions.
You
have
one,
that's
a
logical
and
sort
of
maps
into
what
what
is
for
the
for
the
service
and
then
you
have
instantiation
of
the
service
by
an
operator
or
by
a
tenant,
and
then
you
have
the
cluster
itself.
D
I'm
not
sure
if
I
have
all
the
model,
but
I
do
think
that
the
person
that
knows
best
how
to
write
the
policies
for
his
application
is
the
the
organization
that
created
that
application.
That
knows
how
the
dependents
are
inside
and
who
should
be
able
to
talk
to
walked
right
and
so
on,
and
when
someone's
gonna
take
a
run
that
well,
then
you
need
to
instantiate
it.
That's
when
you
feed,
in
probably
things
like
the
namespace,
is
gonna
use,
because
if
you
run
a
hundred
of
them,
obviously
the
namespace
is
not
the
same.
D
D
Yeah
yeah,
so
how
would
we
come
up
with
a
mechanism
so
that
we
don't
so
we
don't
risk
that
people
sit
and
try
to
copy
some
template,
and
then
you
risk
doing
false.
You
risk
copying
the
wrong
way
right.
Then
you
introduce
errors
by
human
errors
or
if
someone
comes
with
it,
with
an
update
of
a
policy
because
they
found
something
wrong
with
it,
and
you
want
to
apply
deploy
it
that
policy.
D
D
That's
why
I'm
sort
of
it's
clearly
v2
and
for
me,
that's
like
two
three
year
goal,
or
something
like
that
to
have
that.
Something
like
that
sorted
out.
If
it's
done
by
saying
that
there
is
a
mechanism
that
that
works
at
the
meta
level,
that
will
create
the
underlying
policies
or
if
the
policy
sort
of
mechanism
itself
allow
for
this
sort
of
injections.
I
have
really
no,
I
don't
know
which
one
makes
sense
or
as
long
as
there
is
a
way
to
cover
all
the
bases
of
the
speak.
D
D
And
trust
me
I'm
pushing
this
I'm
I
talk
to
people
at
erickson
every
other
week,
not
telling
us
like
go
in
sort
of
get
involved
in
all
the
freaking
groups.
If
you
have
these
problems,
I
mean
we
have
one
cnfs,
as
I
see
and
at
the
same
time
we're
selling
systems
to
operators
that
are
kubernetes
based.
I
see
both
ends
of
it,
but
I
do
think
that.
G
G
So
so,
basically,
like
you
know
you
know,
based
on
the
application,
I
would
be
able
to
write
a
full.
You
know
full-blown.
You
know,
firewall
policies,
you
know
across
all
these
services
yeah.
So
that's
that's.
What
is
at
least
like
you
know,
one
of
the
intent
like
you
know
we
wanted
to
address
using
v2.
G
So
it's
like
a
kind
of
application
based.
You
know.
Let's
say
if
it
is
a
hr
app.
You
know,
which
is
three
tier
I
don't
know
could
be
running
across
like
you
know
so
many
geographic
locations
or
so
many
class,
I
mean
so
many.
G
D
G
C
The
mcs
api
is
one
example
now
that
that
kept,
but
it's
still
not
quite
you
know,
hashed
out,
and
so
there
are
going
to
be
a
lot
of
implementations.
So
before
we
talk
about
how
these
service
discoveries
happen
across
clusters
and
how
that's
standardized
and
then
now
you
want
to
think
about
how
to
apply
policies
which
span
across
multiple
clusters.
So
then
there
is,
you
know
how
does
a?
How
do
they
developer
in.
C
I
do
have
a
question
for
the
v2
folks
who
are
you
know,
writing
those
user
stories
I
want
to
understand.
I
mean
I
to
be
honest.
I
have
not
yet
gone
through
every
single
use
case,
so
my
bad,
but
but
if
you
can
give
a
high
level
idea
of
who's
the
persona
that
you're
trying
to
solve
this
use
case.
C
For
because
I
are
you,
are
you
referring
to
multiple
personas,
for
example,
the
cluster
administrator
is
different
versus
a
namespace
administrator
versus
a
developer,
or
are
we
talking
about
cluster
administrator
versus
a
developer
persona
and
we
are?
The
v2
is
aimed
towards
the
developer
persona,
because
I
did
read
clustered
mania,
as
I
think
andrew
is
highlighting.
G
Yes,
so
you
know
nadim,
you
can
also
pitch
in.
Basically
we
were
trying
to
go
after
two.
You
know:
personas
one
is
the
cluster
admin.
You
know,
cluster
admin
be
able
to
define
the
you
know,
application
based
policies
or
the
the
policy
constructs
which
are
you
know,
intent
based,
so
that
that
applies
to
the
whole
cluster.
G
So
that
is
one
persona
and
the
second
is
like
you
know
the
namespace
admin
can
have.
You
know
his
own
network
policies.
So
so
the
way
it
is
is
first,
you
know
custer
network
policies,
you
know
would
be
you
know
higher
precedence
and
the
later
one
is
the
net
network.
Admins
network
policies
are
the
next
precedence.
G
So
that's
how
you
know
we
are
layering
things,
so
actually
we
have
gone
through
one.
You
know
one
video
of
how
the
I
mean
how
our
contrail
policies
I
mean
are
the
juniper
our
implementation,
some
of
the
building
blocks.
You
know
we
lifted
from
there,
so
maybe
going
through.
That
would
give
you
some
more
clarity
or,
if
not
like
you
know,
we
can
go
over
it
again.
That's
not
a
problem
at
all.
G
E
E
The
other
one
which
we
are
calling
name
space
admin
have
a
namespace
admin
term,
maybe
a
misnomer,
but
what
we
are
trying
to
use
that,
for
is
the
persona
who
can
create
policies
within
a
namespace
like
the
current
kubernetes
network
policy,
not
the
cnp,
but
the
existing
kubernetes
network
policy.
So
that
is
what
we
are
calling
is
the
name
space
admin
I
see,
sometimes
in
this
forum
we
refer
to
that
as
a
developer.
A
And
I'd
be
open
to,
I
think,
it'd
be
a
great
idea
to
maybe
a
doc
alongside
the
docs
you
already
have
going
over
and
describing
personas,
I
mean
in
the
docs
slash.
A
G
A
I'm
up
for
anything
whatever
the
community
wants.
I
think
I
don't
think
it
needs
to
be
just
under
v2.
I
think
for
all
of
these
user
stories.
We
can
oh.
A
I
don't
know
what
other
people
think
about
that.
It
might
just
make
it
easier
if
there
are
questions
in
the
future.
C
Yeah
that
sounds
good
and
I
I
was
under
the
impression
I
was
hoping
that
the
name
space
admin
is
the
developer
person
and
we
are
not
talking
about
two
separate
roles
there
within
namespace.
So
so
we
are
on
board
or
sorry.
We
are
on
the
same
page,
at
least
with
that
for
for
the
v2
cluster
admin
related
user
stories.
I
would
hope
that
you
can.
C
You
know,
help
us
write
those
as
part
of
the
cluster
network
policy.
User
stories
are
not
v2,
because
you
know
v2
for
a
cluster
admin
does
not
make
sense,
because
today
we
do
not
have
any
v1
for
cluster
network
policy.
C
So
if,
if
there
is
something
that
is
not
being
addressed
by
the
cluster
network
policy
resource
for
the
cluster
admin
user
stories,
then
you
know
please
bring
that
up
to
the
kept
or
in
our
user
stories
for
cluster
network
policy,
so
that
we
also
make
sure
that
those
use
cases
are
satisfied
and
for
anything
developer
or
namespace
admin
related
use
cases.
I
think
v2
makes
more
sense.
C
So
that's
the
only
feedback
and
I'll
I'll
go
through
the
individual
use
cases
and-
and
I
agree
with
andrew's
point
about
adding
adding
these
personas
document
to
the
user
story.
Section.
G
Okay,
so
so
abhishek,
one
more
point
is:
if
you
look
into
the
intent
based,
you
know,
rules
which
is
the
first
user
story.
I
believe
so
that
gives
you
little
clarity,
why
you
know
we
are
trying
to
add.
You
know
cmpv
and
pv2
kind
of
a
thing
rather
than
you
know,
just
adding
it
to
the
cnp
directly
itself.
G
So
so
one
of
the
thing
we
are
after
is
like,
instead
of
user,
specifying
increase
and
egress.
So
we
are
trying
to
collapse
that
so
that
you
know
user.
Give
this
you
know,
specify
the
intent.
G
You
know
there
is
no
ingress
and
egress
here,
like
you
know,
user
specifies
that,
like
you
know,
let's
say:
user
wants
to
communicate
between
web
tear
to
act.
Air,
and
you
know
he
just
says
that,
like
no
web
to
app
communicate
rather
than
select
at
the
you
know,
part
selector
at
the
web
and
say
you
know
egress
to
app-
and
you
know
reverse,
like
you
know
where
go
to
the
app
selector
and
say
you
know
english
to
english
from
web.
G
So
we
are
trying
to
avoid
that.
You
know,
which
is
in
the
first
user
story
and
the
same
thing.
You
know
we
are
replicating
to
the
network
policy
or
the
network
admins.
You
know,
namespace
based
in
network
policy,.
A
Yeah,
I
think,
there's
room
there
abhishek,
like
there's
some
user
stories
that
just
may
not
be
able
to
be
fully
covered
by
the
current
cmp's
scope,
because
it
would
involve
a
major
break
from
the
existing
api.
So
that
means
maybe
new
selectors
new,
totally
new
actions
like
rule
priorities.
I
think
those
are
all
things
that
would
push
cnp,
as
is
into
this
like
now
cmp
as
it's
all
new
set
of
apis.
C
I
see
I
I
did.
I
took
a
quick
look
at
that
user
story.
Now
I
see
what
you're
what
you're
trying
to
do
yeah
and
I
think
that's
that's
a
that's
the
use
case
for
for
not
just
cnp
but
np
metal
policies,
and
you
know
it's
like
a
totally
radical
new
way
of
defining
policy.
So
I
I
see
I
see
why
you
have
a
separatist
case.
There.
G
Yeah
I
mean
you
know,
I
think
you
know
you
missed
a
couple
of
them
in
the
previous
sessions.
So
when
we
talked
to
andrew
and
others,
you
know
they
proposed.
You
know
why
not
put
that
as
a
v2.
So
hence
you
know
we
start
in
that
direction,
but
you
know
we
are
still.
You
know,
you
know
we
are
still
open.
You
know,
please
let
us
know
how
you
know
and
also
we
will
add.
You
know
we'll
look
into
the
first
comments.
A
C
C
Yeah,
so
in
in
my
experience
with
signature,
typically,
the
kind
of
reaction
that
you
will
get
for
this
radical
approach
is
that
today
you
can
achieve
the
same
using
you
know
two
network
policies.
There
is
one
for
ingress
rules
and
one
for
egress
rules.
So
if
you
do,
if
you
are
able
to
solve
those
use
cases
by
doing
this,
then
you
don't
need
a
new
api
and
that's
that's.
These
are
on
my
work.
I'm
not
just
telling
you
what
what
you
may
hear-
and
this
is
something
that
ricardo
I
think
he's
offline
now.
C
But
this
is
something
that
ricardo
heard
a
lot
about
when
he
was
trying
to
do.
The
port
ranges
kept
so
just
something
that
you
may
hear
in
the
future.
G
Got
it
yeah
good
input?
So
actually,
you
know
see.
Basically
there
are
two
combination.
Things
are
happening
in
this
v2
proposals.
One
is
you
know
from
and
two
are
like
nine
point,
one
and
end
point
two,
and
you
know
the
second
utility
we
are
trying
to
use,
is
the
match
class.
G
So
combination
of
this,
you
know
we
think
you
know
we
can
reduce
a
lot
of
you
know,
network
policy
explosion
so
so
that
that
was
the
main
reason
you
know
going
through
this
little
radical
approach.
Abhishek.
G
C
C
You
know
you
you,
I
think.
Basically,
you
need
to
clearly
define
the
shortcomings
of
the
v1
api
and
then
build
on
top
of
it.
So
I
think
that
will
be
very
helpful
for
for
the
community
question.
G
D
A
G
Should
we
add
it
into
the
notes
section
or
where
should
we
add
you
know,
what's
the
right
way
to
do.
D
Part
of
me
sort
of
believer
that,
overall,
it's
not
just
policy
right,
but
in
networking
what
networking
model
do
we
want
to
have
in
kubernetes
when
we
move
forward,
I
mean:
let's
talk
about
multi-networks
network
policies.
What
is
the
overall
model
sort
of?
How
should
it
work?
I
mean
example
here
right
where
the
network
policy
is
say
is
using
l3
constructs,
but
it's
really
is
really
sort
of
built
as
a
contractor
on
layer
two,
because
otherwise
you
wouldn't
be
able
to
to
run
the
policies
right
just
on
on
a
local
league.
D
When
there's
no
routing
things
like
that,
do
we
want
the
network
policies
to
work
for
multi
networking
in
that
case,
how
does
it
work?
I
see
no
problem
with
it.
It's
an
implementation
process
in
the
cni's
and
so
on
how
how
to
keep
track
of
all
these
addresses,
but
to
describe
the
dependence
in
between
different
objects,
shouldn't
sort
of
there's
no
ipr.
This
is
in
there,
and
so
who
cares?
How
many
networks
and
how
many
addresses
are
involved
right,
but
to
get
through
basis
for
that?
D
What
is
the
overall
ambition
and
then
it's
much
simpler
to
describe
the
technology
and
sort
of
the
pieces
needed
to
reach
that
ambition
or
what
I'm
scared
of
otherwise
I
read
that
we
might
build
something
super
due
to
policies
that
handles
multi-networking
and
then
from
the
networking
side
it
says
no
there's
no
multi-networking
data
single
network
and
so
on
and
so
on.
So
so
I
don't
know,
if
that's
that's,
I,
the
sig.
Networking
meetings
is
really
bad
time
for
me.
D
I
can't
really
do
go
through,
but
I'm
working
on
moving
my
schedules
around,
but
I
think
that
is
the
first
thing
to
do.
If
we
have
a
little
more
time
to
understand
what
are
we
trying
to
do,
what
sort
of
replications
and
use
cases
do
we
want
our
networking
to
be
able
to
support,
and
how
do
we
do
that,
and
then
policy.
G
So,
are
you,
are
you
you
know,
are
you
asking
about
the
nad?
You
know
network
attached
definition
or
the
def.
D
So
I
mean
I
come
from
a
world,
I
mean
you
were
in
the
two
right
where
everything
is
multi-holed
and
I
completely
understand
why
kubernetes
is
trying
to
keep
at
the
same
time.
Anything
that
can
be
single
home
should
be
single
home
right,
but
if
you're
doing
a
a
router
and
now
with
package
router,
it
needs
to
have
many
interfaces
and
so
on
and
most
of
the
especially
with
network
policies,
except
for
the
address
the
ip
blocks
part.
D
It
doesn't
care
which
interface
anything
came
in
or
it
can
be
completely
applied
on
any
data
going
between
two
parts.
It
doesn't
have
to
go
with
the
over
the
cluster
network.
It
can
really
be
over
any
networks,
and
that
could
be
expressed
so
say
that
we
should
be
able
to
work
with
network
policies.
We
should
be
able
to
handle
overloaded
address
spaces,
but
I
think
that
model
needs
to
be
at
least
worked
on
at
the
same
time.
D
So
we
know
what
we're
applying
network
policies
to
and
if
the
assumption
is
so
yeah
we're
still
just
doing
network
policies
for
the
primary
interface
okay,
great,
but
then
sort
of
let's
state
that,
and
if
someone
is
some
crazy,
people
then
wants
to
apply
it
to
many
interfaces.
Fine,
they
can
go
and
do
that
but
sort
of.
Where
are
we
going
with
with
networking
yeah.
A
I
think
it's
a
good
idea
and
and
rewinding
back
to
when
to
where
we
should
put
a
document
like
this
for
prasada
nadim
and
anyone
else
working
on
this.
I
think
it
might
be
good
to
start
a
google
doc
and
we
can
work
on.
You
know
how
we
got
here,
why
we
need
v2
there
and
when
it
gets
to
a
stable
point,
we
can
convert
it
to
a
readme
and
put
it
in
the
repo.
G
No,
I
think,
that's
a
good
idea.
I
mean
it
will
be
easy
for
everybody
to
comment
on
the
google
doc.
I
do
think
that.
D
Do
not
be
shy
right.
The
strength
of
the
kubernetes
networking
policies
is
the
lack
of
eye
paradises
yeah.
That
means
that
they
apply
to
in
reality
anything
it's
about
how
objects
talk
to
each
other
and
then
for
north
south
inbound.
Okay,
we
need
to
have
ip
blocks.
How
should
they
be
expressed
and
managed,
but
that
to
me
is
sort
of
the
really
secondary
part
that
comes.
G
So
andrew
we
are
going
to
take
one
action
item
where
we
create
a
google
doc,
and
you
know
keep
adding
why
you
know
we
are
trying
to
take
a
little
different
approach.
Yep.
A
And
if
you
could
just
add
that
link
to
the
agenda,
I
have
some
other
documents
that
I
had
put
together
internally,
that
I
can
bring
out,
and
you
know,
kind
of
go
over-
why
we
do
why
we're
why
we
need
a
v2
like.
Why
are
we
here
so
some
stuff
that
might
help
out
there
and
we
can
bring
it
up
in
the
next
meeting
and
also
call
to
everyone
like,
let's
start
reviewing
these
full
requests
that
prasad
and
edema
put
out
kind
of
in
tangent?
G
B
A
No,
no,
no
problem,
no
problem!
That's
what
I'm
here
for
to
help
out
with
people
and
foster
the
community
cool
great.
Well
we're
getting
towards
the
end.
Does
anyone
have
anything
else
before
we
wrap
up.
A
Awesome,
so
I
think
we
have
some
good
action
items
for
this
week.
It
was
a
great
meeting,
let's
keep
on
moving
forward,
and
I
really
appreciate
everyone's
time
today
and
please
reach
out
on
slack.
If
there's
anything
else,
you
need
to
know.