►
From YouTube: Network Policy API Bi-Weekly Meeting
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).
B
All
right,
so
this
is
the
you
know,
september
21,
sig,
network,
sub
project
for
network
policy,
api
meeting
and
just
to
quickly
summarize,
we
are
going
to
talk
about
starting
caps
to
propose
as
enhancements
in
you
know,
in
the
kubernetes
signature
repo.
We
went
through
the
change
for
the
api
for
port
ranges
and
I
think
an
action
item
is
ricardo,
that
he
will
go
ahead
and
open
an
issue,
and
then
we
can
follow
up.
B
We'll,
probably
look
at
something
similar
to
this,
as
a
proposal
and
andrew
suggested
that
we
use
proper
struct
for
food
ranges,
but
we
can
discuss
these
changes
over
the
over
the
related
issue
and
then
we
can
we
also
now
now
we
are
discussing
the
name
space
as
a
name
which
has
been
actually
actively
discussed
on
the
google
groups,
mailing
thread
raised
by
marketing,
so
so
yeah
ricardo.
You
had
some
comments
about
that.
C
Yeah,
so
just
to
finish
about
that,
so
this
is
a.
This
is
a
discussion
that
that's
that's
under
that's
ongoing
between
tim
hawkins,
then
winship
and
clayton
coleman
and
a
lot
of
other
folks
from
from
sick
architecture,
and
I've
sent
the
link
in
the
chat.
If,
if
you
can
open
that
chat,
so
just
I
think
that
would
be
important
for
the
folks
in
this
so
project
to
follow
this
one.
C
Put
your
thoughts
in
that,
so
we
we
used
to
have
a
noble
about
that,
because
labels
are
a
primitive
in
the
selector
and
this
is
being
rethinked
because
of
you
need
their
back
or
you
don't
need
their
bot
for
labels,
and
you
can
you
can
like
force
a
label
in
your
name
space
and
forge
like
have
a
road
name
space.
C
So
this
is
probably
going
to
be
a
goal,
and
I
think
this
is
also
what
we're
going
to
to
propose
in
the
in
the
sig
network
meeting
is
so
we
can
open
the
issue
and
say:
oh,
we
are
seeing
this
discussion
ongoing.
So
we
think
that
we
can.
We
can
move
forward
with
this
one.
Anyone
have
a
no
goal
for
this.
Otherwise
you're
going
to
open
the
issue
and
write
a
cap.
A
Yeah,
I
thought
that
yeah,
if
anything,
I
agree
with
you
like
this.
This
mailing
thread
that
tim
started
is,
if
anything,
it's
kind
of
validation
for
that
use
case,
because
it
kind
of
highlights
what
are
the
limitations
today
using
label
selected
for
name
spaces,
so
yeah,
plus
one?
A
If
anything,
though,
like
it
highlights
the
fact
that
when
we
do
propose
selecting
namespaces
by
like
a
list
of
names,
we
should
be
very
clear
around
how
that
intersects
with
selectors
right
like
can
it
can
you
can
you
define
both
or
should
the
api
reject?
If
you
try
to
do
both,
and
should
it
only
allow
one
or
the
other
things
like
that,
so
plus
one.
B
Yeah,
so
I
I
also
plus
one
to
the
to
the
user
story,
and
this
is
a
good
validation.
The
the
only
thing
that
I
I
think
I
often
must
mention
this
to
andrew
was
that
you
know
this.
This
is
clearly
a
problem
about
the
network
policy
apis.
B
You
know
it's
not
just
the
network
policy
api
that
needs
to
tackle
this
particular
use
case,
but
I
think-
and
I
I
know
jay
was
also
on
board
with
this-
is
that
maybe
you
know
within
with
the
proposal
of
the
cluster
scope
network
policy?
We
we
try
to
solve
this
problem
and
we
propose
a
solution,
and
then
you
know
we
can
show
that
this.
This
is
working.
B
This
is
how
we,
you
know,
worked
out
the
problem
with
the
thrust
network
policy,
and
now,
let's
see
whether
we
can
solve
this
problem
on
a
larger
scale.
You
know
with
cooperation
with
different
six.
So
so
I
that
that
would
be
my
you
know,
proposal
on
this
for
my
two
cents
on
this.
A
A
If
I
don't
know,
but
I
feel
like
it's
such
a
like,
if
we
were
to
implement
in
the
api
it'd
just
be
like
a
list
of
names
right
like,
is
it
more
complicated
than
that.
B
B
B
So
as
part
of
like
our
network
policy,
api
plus
plus
proposal,
maybe
if
we
can
have
like
that
hashed
out
and
then
bring
this
to,
you
know
broader
table,
maybe
maybe
one
of
the
days
in
the
sig
network
community
meetings.
We
can
propose
this
and
see
if
you
know
folks,
agree
there
and
then
take
it
up
with
with
the
guys
on
admission
controller
side
and
see
whether
whether
we
can
we
have
a.
We
have
a
proposal
that
converges
and
solves
the
use
cases
of
all
the
communities
or
the
six.
A
Yeah,
I
agree
so
ricardo
you
you
mentioned
you
mentioned
that
you
were
going
to
create
an
issue
before
the
proposal
or
what
did
you
say?
You
were.
C
C
To
to
probably
post
this
one
and
say
hey
like
I'm,
going
to
probably
spam
our
meeting
list
and
say
we
have
for
each
of
the
the
the
the
user
stories.
I
don't
know
if
for
each
of
the
user
stories
or
maybe
consolidate
and
consolidate
all
of
them
in
one.
So
we
can
have
like
a
a.
C
To
to
post
in
the
issue
of
the
the
the
enhancements
repo
before.
D
C
A
Yeah,
so
I
think
I
personally
I'd
be
in
favor
of
have
starting
a
single
conversation
around
just
the
yeah,
like
the
four
v1
use
cases,
and
also
maybe
like
on
the
same
day,
there's
sick
meeting.
We
can
also
raise
the
music
meeting,
but
I
think
ideally
we
want
to.
I
think
we
should
present
it
with
like
a
really
like
short,
concise,
google
doc
with
those
four
use
cases.
A
I
think
that
issue
30
is
a
little
it's
lacking
in
a
little
bit
of
details,
so
maybe
like
and
also
like,
like
I
don't
want
to
be,
I
don't
want
to
be
that
person,
but
do
we
do
we
have
consensus
on
on
those
four,
because
I
feel
like
I.
I
agree
with
those
I
know
ricardo
you
do,
but
are
we
as
a
sub
project,
happy
about
those
four
things
to
propose
as
like
the
next
thing,
we
want
to
add
to
you
on.
C
B
Yeah
and
plus
one
for
these
four,
the
only
thing
is
that
the
cluster
network
policy
wouldn't
be.
Would
we
need
up
to
thought
would
need
a
lot
more
thought
processes
to
go
into
it,
but
yeah,
even
the
notes,
I
think,
but
but
in
general
I
am
also
plus
one
for
these,
like
I'm
not
against
any
one
of
them
individually.
A
Yeah,
but
I
I
definitely
think
there
needs
to
be
some
document
that
talks
about
each
use
case
with
a
bit
more
detail,
but
not
too
much
detail
where
you
know
it's
going
into
implementation,
and
that's
probably
the
thing
that
we
want
to
share
with
the
sig
before
we
start
with
caps.
I
don't
know
okay,
so
carl.
What
were
you.
A
D
A
A
So
both
I
think,
but
but
I
think
ideally,
though
I
I'd
really
like
us
to
get
to
a
place
where
we
have
the
four
use
cases
written
in
a
google
doc
and
the
majority
of
us
have
commented
like
a
plus
one
or
like
yeah.
I
agree
with
this
just
so
that
it
it
looks
like
we're
presenting
the
use
cases.
Well,
that
looks
like
we
have
like.
A
We
have
discussed
these
quite
a
bit
but
yeah,
just
just
showing
that
we've
discussed
the
use
cases
in
in
quite
a
lot
of
detail
before
we
present
it.
B
So
andrew
so
here
in
this
particular
proposal
folder,
you
know
this
is
more
like
an
abstract
thing.
You
know
it's
not
really
going
into
any
implementation
and
kind
of
goes
into
the
two,
like
an
administrative
focus
on
our
developer
focus
policies,
and
then,
within
that
you
know,
I
was
intending
to
add
for
the
cluster
scope,
this
kind
of
maps
to
the
to
the
to
the
issue
that
we
have
for
the
cluster
network
policy,
which
is
you
know
which
we
all
agree
on
and
in
the
dev
scope.
B
What
I
was
planning
to
do
was
to
add,
add
twos
to
two
details,
two
sort
of
proposals:
one
is
the
additive
ones,
which
kind
of
includes
the
three
use
cases
that
we
that
are
part
of
the
four
use
cases,
which
is
the
name
space
as
a
name,
the
nodes
and
node
selectors,
and
the
third
one
was
the
port
ranges
and
the
alternative
was
going
to
be
a
new
api.
So
so
do
you
think
we
can
use
these
two?
A
But
what
ricardo's
saying
is
that
we
need
to
kick
off
a
discussion
and
kind
of
just
entertain
the
idea
of
those
use
cases
to
the
sick
before
we
can
propose
the
cap.
So
I
was
looking
like
something
really
brief
and
short
that
highlights
what
it
is,
but
without
going
into
too
much.
I.
C
What
is
it,
what
are
our
objectives
with
that
like
what
what
we
are,
what
we
are
trying
to
achieve,
or
what
what
we
are
trying
to
solve
some
something
of
the
discussion,
but
really
briefly
like
what
you
said
about
the
name:
space
with
names
collector
and
then
like
something
with
five
lines:
maximum
per
user
story.
So
any
anyone
can
okay,
you
read
nice.
You
are
trying
to
solve
this
one.
There
is
the
discussion
in
the
comments.
I
think
that's
better
and
propose
that.
B
Okay,
so
here's
one
question
which
I
just
was
looking
over
and
so
the
node
selector
does
it
make
sense
for
it
to
be
a
part
of
a
developer
api
or
does
it
should
it
be
an
administrator
api?
A
part
of
the
cluster
network
policy.
B
B
B
B
A
Yeah,
I
think
I
think
what
we're
aiming
for
or
what
ricardo
is
proposing
is
that
we'd
have
a
short
dock
with
like
yeah
five
sentences
at
most,
describing
like
what
the
use
case
or
the
user
story
we're
trying
to
solve
for
and
then
once
that
kind
of
you
know
once
we
share
that
with
the
sig,
and
we
start
writing
the
cap,
then
in
the
cap
we
can
then
start
diving
into
like
yeah
like
the
the
personas
and
what
the
api
would
look
like
and
that
probably
deserves
either
like
a
cap
per
each
or
one.
B
C
Yeah
and
and
plus
went
to
one
cat
per
each,
so
we
can
have
like
different
discussions.
Otherwise
it's
it's
going
to
be
like
a
hundred
or
more
comments
trying
to
solve
one
thing
and
not
others.
So
it's
easier.
C
Agree,
okay,
so
so
so
this
is
my
backlog
list.
I'm
probably
going
to
start
writing
this
and
send
to
you
in
slack
or
somewhere
somewhere
else,
just
to
take
a
look
into
that,
and
this
is
what
we
are
and
our
deadline
is
probably
next
wednesday.
So
we
can,
we
can
send
you
the
sick
making
list
and.
A
A
When's
the
kept
deadline
again,
you
said:
no,
not
this
one,
the
next
one.
Okay.
Would
it
be
reasonable
for
you
to
have
that
doc
done
by
the
next
meeting
monday,
and
then
we
can,
as
a
group
like
sign
off
on
it,
and
then
you
can
check.
A
C
C
The
point
that
the
tab
check
has
put
and
also
about
the
cluster
network
policy,
so
we
have
a
plus
one
for
the
port
range-
is
a
plus
one
for
the
namespace
as
a.
D
C
The
node
we
need
to
discuss
better
put
in
the
document.
What
about
the
cluster
network
policy?
What
do
you
think
about
that
and
plus
one
for
this
one
because
of
my
use
days,
but
I
think
that
also
we
have
the
the
the
problem
of
this
being
mostly
a
cluster
admin
related
than
a
developer
related.
B
C
A
A
Yeah
so
and
yeah,
maybe
because
if
if
we
have
no
other
topics
for
the
agenda,
I
yeah
I'd
love
to
just
banter
about
this.
This
topic
so
like
in
my
mind,
cluster
network
policy
would
basically
be
we
fork
network
policy
in
the
existing
api
group
and
on
the
high
level
spec
we
add
network
we
added
either
namespace
by
name
or
a
namespace
selector,
so
that
you
can
select
pods
across
multiple
namespaces
and
then
like
each
to
and
from
selector
and
in
the
rules
are
also
well.
A
C
I
think
we
can
we
can
go.
We
can
dig
deeper
in
this
into
this
one,
I'm
okay
with
that,
maybe
because
the
other
ones
they
seems
pretty
pretty
easy,
because
that's
only
an
additional
few.
Only
I'm
sorry,
it's
not
easy
at
all,
but
that's
a
newer
field,
and
this
one.
I
think
that
we,
we
should
dig
a
little
deeper.
Yes,
and
this.
D
D
B
B
An
administrator
would
be
more
responsible
for
all
the
pods
in
the
cluster,
as
as
opposed
to
individual
services,
or
at
least
like
a
big
group
of
services,
rather
than
your
smaller
subset
of
services
and
then
name
spaces
nodes,
and
you
know
any
interaction
of
traffic
from
from
within
the
cluster
to
outside
of
the
cluster.
B
Do
we
determine
the
precedence
of
you
know,
evaluation
or
enforcement
of
these
policies?
You
know
these.
The
cluster
admins
policy
should
supersede
all
developer
written
policies,
but
in
addition
to
that,
there
might
also
be
a
need
to
outline
the
the
cluster
defaults.
B
You
know
what
happens
if
there
is
no
policy
match,
then,
should
it
be
allowed
or
should
it
be
disallowed
and-
and
I
think
in
the
end,
I
think
you've
also
added
something
like
you
know,
auditing,
whether
the
how
the
logging
policy
for
the
cluster
or
individual
policy,
so
these
are
the
things
that
we
kind
of
like
came
up
with.
So
I
don't
know
whether
this
answers
andrew
some
of
your
questions
are,
like
you
know,
is
it
something
that
you
were
looking.
A
For
yeah,
I
think
so
yeah
so
press
precedence.
Well,
sorry,
I'm
just
reading
like
what's
there
so
are
we
seeing
that
closer
to
normal
policy
does
take
precedence
over
any
namespace
scope
policy.
B
So
this
is,
this
is
not
a
answer.
This
is
more
of
a
question
to
you
know
what
what
are
the
things
that
administrative
focus
policies
or
clusters
of
policy
would
now
one
of
the
things
is
that
you
know
if
you
have
you
know,
these
are
some
of
the
use
cases
that
come
often
that
you
want
to
solve,
or
you
have
like
a
security
policy
for
your
company
that
you
know
you.
B
You
cannot
expose
certain
ports,
you
know
so
those
those
are
the
kind
of
policies
which
need
to
take
precedence
over
the
developer,
written
policies
like
even
if
a
developer,
writes
and
policy
saying
that
you
know
allow
allow
my
port
53
to
be
accessed
from
anywhere.
But
if
an
administrator
does
not
want
that
to
happen,
then
that
should
be
enforced
before
the
developer
policy.
B
On
the
other
hand,
if,
if
there
is
you
know,
a
developer
can
write
some
policies
to
expose
their
services
outside
of
their
namespaces
or
cluster,
and
if
that
doesn't
happen,
then
the
administrator
might
may
have
like
certain
default
or
a
fail-safe
set
of
rules
that
the
cluster
needs
to
adhere
to,
and
those
would
then
be
enforced.
After
the
developer
policies,
so
those
are
the
kind
of
questions
like
how
do
we,
whether
first
of
all
whether
this
makes
sense
and
second?
If
yes,
then,
how
do
we
solve
that?
B
A
Yeah,
that
makes
sense,
so
is
there
ever
a
case
where
we
would
want
the
cluster
scope
of
a
policy
to
override
only
deny
rules,
but
allow
rules
should
be
over
like
it
should
be
allowed.
You
should
be
allowed
to
overwrite
the
allow
rules
or
sorry,
maybe
it's
the
other
way
around.
But
like
is
there
a
use
case
where,
like
we
only
want
either
allow
or
deny
to
be
to
take
precedence
at
the
cluster
script
level,
but
then
on
the
name,
namespace
scope,
level.
A
B
So
yeah,
I
don't
see
goblin
on
the
call,
but
this
was
his
comment
from
last
week
was
that
in
his
opinion,
a
cluster
administrator
is
more
focused
towards
tightening
the
security
of
his
cluster,
like
he
will
be
more
interested
in
denying
things
than
opening
things
up
while
well,
the
developer
would
be
more
responsible
for
you
know
allowing
things
or
opening
up
access
to
his
services.
B
So
I
think
that
that
that's
the
view
that
he
came
from,
like
you
know
the
so
so
there's
like
you
know,
did
not
move
like
a
cluster
network
policy
would
be
more
useful
for
denying
as
a
deny
action
while.
Well,
you
know
the
kubernetes
policies
which
act
as
the
developer
policies
are
more
about,
like
you
know,
allowing
specific
access.
So
so
I
don't
have
an
answer
to
that
to
your
question,
but
this
was
one
of
his
comments,
which
is
kind
of
related.
C
But
we
we
can't
think,
like
I
want
as
a
cluster
admin,
I
want
all
the
namespaces
to
have
a
default
address,
deny
and
being
the
responsible,
the
responsibility
of
the
user,
to
open
to
open
anything
that
he
wants,
but
but
to
to
specific
specific
locations
so
having
a
a
restricted,
namespace
and
being
the
user
responsibility
to
open
the
the
network
policies.
So
I
think
this
is
one.
D
A
Yeah,
the
other
one
I
was
thinking
which
is
the
and
which
is
what
I
think
gobin
was
mentioning,
is
if
I
have
a
rule
that
allows
all
traffic
to
like
yeah
like
let's
say,
like
cube,
dns
or
coordinates
whatever.
But
then
the
developer
or,
like
the
namespace
policy,
says
to
actually
deny
traffic
to
dns.
A
B
Yeah
yeah,
so
that
that's
true
so
though
so
so
that
is
the
thing
that
you
know
feels
safe.
Like
you
know,
maybe
your
coding
s
traffic
or
something
as
a
fail-safe
rule
that
the
cluster
admin
has
put
in,
but
but
the
developer
will
will
have
control
over
adding
more
restrictions
on
those.
B
So
so
I
think
it's
a
clear
pattern
that
we
see
that
you
know
there
will
be
certain
rules
which
have
to
be
executed
or
enforced
before
the
developers
policies,
but
there
will
also
be
certain
set
of
rules
which
will
be
enforced
after
the
developer
policies.
So
we
need
to
be
able
to
handle
or
the
api
needs
to
be
able
to
handle
these
kind
of
requests.
C
C
Do
you
know
what
I
mean
because,
like
you,
you
may
have
a
room
that
denies
everything
every
every
every
every
aggress
traffic
but
allows
you
to
create
anything.
But
you
can
also
have
a
room
that
strictly
forbids
you
to
access
like
the
beta
data
from
from
aws
and
allows
you
to
like
curl
into
the
metadata
and
and
get
some
user
key,
and
you
don't
want
your
pods
to
do
that.
So
I
think
those
are
two
cases.
B
So
yeah,
how
about
like
I
mean-
I
don't
know
whether
this
will
solve
all
of
this,
but
how
about
like,
instead
of
like
an
ingress
and
egress,
just
like
top
level
spec
fields?
How
about
something
like
a
white
list
and
a
black
list
where
the
blacklist
is,
you
know
something
which
is
which
has
higher
precedence,
because
you
know
this
is
where
the
admin
wants
to
deny
for
sure
and
needs
to
be
enforced
before
any
of
the
developer
policies
are
executed.
B
And
then
there
is
a
white
list
which
is,
you
know,
kind
of
like
a
lower
proceedings
than
the
developer
policies,
whereas
whereas
the
admin
is
kind
of
like
allowing
certain
traffic,
but
you
know
as
a
developer,
you
can
deny
or
stream
that
maybe
maybe
this
is
something
that
we
can
think
of
in
this
direction,
or
that
would
be
the
other
way
which
you
know.
I
think
ricardo
was
kind
of
going
towards
like
some
some
rules,
and
then
you
have
like
some
another
section
for
defaults.
B
A
Right,
but
if
we're
saying
it's
a
brand
new
resource
in
the
same
api
group,
you
like,
ideally,
they
should
have
similar,
looking
at
least
in
my
mind
like
in
my
mind,
like
it'd,
be
weird
if
I
was
like
creating
network
policy
apis
and
then,
when
I
switched
to
cluster
network
policy
apis,
it's
like
a
completely
different
semantic
around
like
allow
and
deny
this
like.
I
would
expect
them
to
be
similar,
but
one
is
just
like
expanded
to
all
name
spaces,
while
the
other
is
one.
B
A
If,
if
we
have,
if
you
have
five
more
minutes
and
there's
no
one,
no
one
else
wants
to
talk
about
anything
else.
I'd
love
to
also
talk
about
the
node
selector
one,
particularly,
I
think.
What's
going
to
be
tricky,
there
is
how
to
determine
what
the
node
ips
are,
because
today,
like
the
node
object,
has
some
information
and
status
around?
A
What
are
its
addresses
so
do
like
it
has
like
the
internal
ip
external
ip
fields,
right
or
types
should
an
implementation
of
network
policy
decide
which
address
type
to
use
or
should
the
address
type
information
be
exposed?
Part
of
the
network
policy
api
to
say
like
select
these
nodes
with
this
label
and
only
take
its
internal
eyepiece.
B
B
D
B
C
Yeah,
I
don't
I
don't
know
either.
I
think
that,
like
the
the
the
clown
load
bouncers,
they
use
it
the
external
ip
right,
but
on
the
other
hand,
we
are
trying
to
select
the
internal
one
because
of
the
pods,
but
they
can
also
try
to
reach
the
external
one.
If
this
is
the
case-
and
this
is
going
to
be
a
mess
right.
A
Yeah
pretty
much,
I
think
most
level
balancers
actually
used
in
internal
ip,
but
it's
not
an
so.
The
internal
ip
usage
is
not
an
explicit
definition
like
nothing
is
saying
so
like
internal
ips.
It
just
happens
that,
like,
when
you
add
a
node
into
the
cloud
load,
balancer's
backend.
It
registers
the
internal
ip.
For
for
that
but
yeah.
I
agree
like
it's,
that's
something
that
we
should
like.
A
C
Probably
have
a
default
a
default
behavior,
but
not,
but
also
allow
one
to
select
that
then
like
okay,
the
default
behavior
is
good.
We
are
going
to
select
the
internal
one,
because
the
internal
is
mostly
the
white
white
one.
You
use
it,
you
you
you
always
as
far
as
I
know,
you
always
have
the
internal
ip,
but
the
external
ap
is
up
to
the
cloud
provider
right.
C
A
C
B
So
shall
we
come
back
to
this
node
selected
next
week
a
little?
We
do
a
little
more
homework
and
probably
also
see
if
zane
can
join.
I
think
she
is
the
author
on
this
one.
So
if
we
can
get
a
use
case,
I
mean
if
we
can
clarify
the
use
case.
I
think
we'll
be
able
to
be
in
a
better
position
to
solve
this,
because
we
are
already
at
time
so
yeah
definitely.
A
C
B
Right
yeah,
I
think
so
I
think
there
are
time.
So
maybe
we
can.
You
know
punt
this
discussion
to
next
week.
There
was
one
more
question
that
I
had
was
you
know
to
anish.
I
saw
him
uploading
a
user
story.
I
don't
know
whether
he
wanted
to
discuss
that
in
the
meeting.
If
yes,
then
maybe
we
can
do
that
next
week,
this
was
regarding
vip
named,
say
something
regarding
the
ip.
D
Yeah,
I
think
this
is
what
anand
brought
up
initially
based
on
what
we've
seen
from
users
requesting
at
microsoft,
and
then
I
had
a
chat
with
jay
on
slack
and
we
recommended
I
just
open
a
pr
to
upload
it
so,
but
we
can
discuss
this
next
week.
Okay,.