►
From YouTube: Network Policy API Bi-Weekly Meeting for 20201012
Description
Network Policy API Bi-Weekly Meeting for 20201012
A
A
B
A
Yet
and
whether
or
not
we
would
justify
it
with
actual
community
user
feedback
inside
of
the
cap
or
not,
and
ricardo
mentioned
that
we
would
do
that
in
the
sort
of
like
the
preamble
section,
which
is
fine,
so
yeah,
that's
all
I
got
on
that
really.
I
think
it's
going
to
be
pretty
straightforward
to
write
the
cup
and
I
think
the
interesting
part
will
be
the
debate
around
whether
we
actually
make
a
decision
on
it
or
not,
but
yeah.
I
can
get
that
done
this
week
for
sure.
B
C
So
I
can
give
a
quick
update
on
the
things
that
we
have
so
far
covered
in
the
very
last
meeting
that
we
met.
We,
we
went
through
the
available
crds
that
currently
offer
cluster
scope
policies,
for
example
the
calico
global
policy,
the
psyllium
cluster,
wide
network
policy
and
yantria
cluster
network
policy
to
contrast
and
compare
of
the
things
that
are
offered
by
existing
open
source
solutions,
and
you
know
that
is
a
good
way
to
figure
out
like
what
how
they
are
tackling
the
this
particular
problem
space.
C
And
you
know
I
think,
in
the
coming
weeks
we
are
going
to,
we
are
going
to
figure
out
how
to
converge
between
these
policies.
You
know
take
the
pros
and
cons
from
from
each
of
them
and
converge
on
like
how
how
the
precedence
and
the
prioritization
between
these
kubernetes
network
policies
and
cluster
scope,
network
policies
should
be
handled.
C
Answer
those
questions
and
and
then
maybe
you
know,
move
on
from
there
and
see
how
we
can
evolve
the
or
start
with
at
least
the
first
sketch
of
the
api
that
would
be
available
other
that
we
can
converge
on
and
and
maybe
as
part
of
next
week's
or
meeting.
Maybe
we
can
hopefully
come
up
with
a
sort
of
a
timeline
for
the
cap
because,
as
you
all
know,
that
this
is
this.
D
C
Large
or
extra
large
effort,
so
so
the
cap
won't
be
like
a
straightforward
thing.
We'll
have
to
you
know
properly
detail
each
and
everything
on
this,
so
it
won't
be
something
that
will
be
achieved
within
a
week
or
a
few
weeks,
but
we
expect
that
we
should
at
least
come
up
with
the
timeline
for
these
gaps.
Let's
get.
C
E
B
C
Okay,
oh
yeah,
anyone
anyone,
you
know,
feel
free
to
see
me
and
you
know
we
can
include
everyone
who
was
was
wants
to
shape
the
cluster
scoped
apis.
So
the
scope
of
that
meeting
would
just
be
just
network
policy
and
not
the
other
use
cases
that
those
are
the
use
cases
we
can
discuss
here
and
then
maybe
form
a
circle.
F
Which
one
is
the
most
focused
on
like
the
dns
side,
I
guess
last
week
we
kind
of
got
to
that
last
10
minutes
and
we're
talking
about
dns
and
that
just
got
my
attention
because
it's
something
I
was
looking
at
independently.
So
are
any
of
these,
in
particular,
more
dns
heavy
that
we
know
of
at
this
point
at
this
juncture,
or
was
that
just
a
r
d
ongoing
conversation.
G
I
spoke
to
tim
hawkins
a
little
bit
as
well
about
this
as
to
how
to
approach
this,
so
I
think
what
we
can
do
is
we
can
try
to
propose
something
as
a
sort
of
a
you
know,
the
sig
network
meeting
as
a
proposal
and
say
this
is
what
we're
hearing
from
customers.
In
fact,
I
had
a
conversation
with
a
customer
on
friday.
G
They
asked
about
this
question
as
well
and
what
they
they
don't
want
to
adopt
like
a
service
mesh
policy
just
so
they
can
do
fudn-based
policies
like
they
just
want
to
be
able
to
do
it
in
kubernetes
if
they
can.
So
I
feel
like
it's
a
legitimate
use
case,
and
I
don't
know
if
you
have
to
like
start
treating
it
as
a
fourth
cap
like
we
like,
you,
have
three
caps
right
now,
like
you
know
the
cluster
scope,
never
policy,
the
namespace
by
name
and
then
the
port
numbers.
G
So
I
think
we
have
three
already
in
flight.
We
could
try
to
do
a
fourth
one
as
well.
Of
course,
I'd
love
to
you
know,
get
some
participation
from
the
community,
so
whoever
wants
to
sort
of
you
know,
help
scope
that
effort.
You
know
where
it's
not
gonna,
be
like
final,
like
immediately
but
like.
If
we
can
collaborate
over
the
next
couple
of
weeks,
I'd
love
to
get
a
proposal
out
and
and
just
do
a
cap
on
it.
If
that
makes
sense,.
F
G
F
Cool
yeah
I'm
interested
because
of
the
I'm
still
seeking
of
the
customer
goals.
I
have
some
ways.
I
think
I
can
like
slice
and
mess
with
dns
right,
but
I
don't
know
what
to
do
with
it.
Yet
I
guess
okay,
but
either
way
I'll
still
follow
up
and
hopefully
can
help
share
some
of
the
knowledge
I've
gotten
that
research
yeah.
G
Yes
yeah,
this
feels
like
it's
just
gonna,
be
an
extension.
So
maybe
this
is
just
gonna
be
a
fourth
cap.
So
what
we
can
do
is
you
know?
Maybe
I
don't
know
if
this
week's,
maybe
we
could
do
it
in
this
week's
cig
network?
I
don't
know
if
there's
already
an
agenda
in
place,
but
maybe
we
could
take
a
five
minutes
towards
the
end
and
just
sort
of
talk
about
it.
G
I
can
put
a
one
pager
together
on
what
the
current
state
of
the
art
is,
and
you
know
what
sort
of
things
are
users
asking
for
and
if
I
can
recall
correctly
like
ever
since
I
started
looking
at
narrow
policy
like
fqdn
has
been
a
very
open
like
very
asked
for
feature,
so
so
I
can
start
putting
that
together.
Oh
it's!
Our
dock,
there,
okay.
G
And
then
sign
network,
oh
okay,
okay,
so
yeah,
okay,
yeah
cool,
perfect!
So
I
can,
I
can
see
if
I
can,
like
you
know,
propose
something
for
october,
15th
and
there's
time,
and
then
you
know
if
there
are
other
folks
who
want
to
join
in
I'll
I'll.
What
I'll
do
is
I'll
start
a
one
pager
and
I'll
just
put
some
suggestions
there
and
I'll
tag
it
in
the
this
meetings
notes
so
that
people
can
actually
latch
onto
it.
Does
that
sound
okay.
A
All
right
yeah,
let's
also
keep
the
let's
keep
our
story
up
to
date,
also
in
the
repo
as
we
transition
it
to
a
kubernetes,
sigs
repo.
Also,
since
that's
kind
of
like
our
system
of
of
record
for
the
things
that
as
a
group
we
want
to
pursue,
so
I
think
gobind
you
did
put
a
pr
into
there.
So
I
think
we
have
it
in
one
of
our
stories
right.
C
D
G
B
D
A
A
You
could
envision
a
crd
with
an
operator
behind
it
which
just
went
and
made
10
kubernetes
network
policies
right
so
for
you,
so
that
would
implement
one
of
the
functions
that
we
want.
Then
there's
of
course
namespace
name,
that's
you
know
like
a
similar
one
like
so
so
a
similar
situation
where
we
could
just
build
a
crd
as
a
group
and
the
crd
could
be
sort
of
orthogonal
to
v1,
but
we
could
build
an
operator
that
literally
created
v1
policies
under
the
hood.
A
A
It
has
nothing
to
do
with
the
fundamental
work.
We
need
to
do
of
writing
these
kept
to
get
the
api
changed,
but
I
think
it
has
some
sort
of
unpredictable
serendipitous
tangential
value
as
a
cool
project
to
hack
around
on
the
side.
It
kind
of
fleshes
out
the
overall
sort
of
concreteness
of
the
of
the
some
of
the
concepts
we're
exploring,
and
I
think
some
people
might
actually
use
it.
A
Oh
james,
let's
see,
doesn't
the
operating
approach
argue
yeah,
it
does
james.
I
mean
that's
that's
the
thing
is
that,
like
I
think,
that's
why
it's
kind
of
interesting
right
is.
It
does
kind
of
demonstrate
that
you
know
you
don't
necessarily
need
to
change
the
core
api
in
order
to
get
some
of
these
benefits.
A
But
that
said,
I
think,
once
you
demonstrate
this
value
with
an
operator,
I
think
then
I
think
it
strengthens
the
in
the
short
term.
It
kind
of
weakens
the
argument
that
you
need
to
change
the
api,
but
I
think
in
the
long
term
it
strengthens
it
because
once
you
val
once
you
demonstrate
that
this
thing
is
useful
and
you
demonstrate
feasibility
and
you
demonstrate
that
there's
actually
a
default
implementation
for
it.
Then
you
could
actually
make
that
operator.
A
Implement
the
v1
api
exactly
so
that
that
api
change
could
go
out
and
then
really
you
wouldn't
even
necessarily
need
a
cni
provider
to
implement
that
api,
because
you
have
the
existing
primitives.
You
have
the
kubernete.
The
network
policy,
api
and
kubernetes
itself
updated
to
support
these
extended
primitives,
and
then
you
could
be
running
an
old
provider
that
implements
you
know
the
old
network
policy
api
and
then
you
you,
don't
you
know,
and
then
all
you
need
to
do
is
just
run.
A
F
A
A
I
think
port
ranges
is
kind
of
far-fetched
because,
like
if
you
have
a
port
range
from
like
90
to
a
you
know,
90
to
like
200.
Now
you
have
to
make
200
you
know
or
110
network
policies.
For
that,
like
I
don't
think
anybody
wants
an
operator
creating
a
hundred
network
policy
objects
for
them,
and
I
think
I've
tried
to
sell
this
to
abhishek.
A
couple
of
times
like
I
feel
like
the
cluster
network
policy,
is
another
place
where
a
policy
operator
probably
has
some
precedent.
A
I
think
I
don't
know
if
dan's
on
the
call,
but
I
think
openshift
kind
of
does
something
like
this
already.
I'm
not
sure,
though,
so
I
think
there's
some
precedent
for
an
operator
at
the
cluster
scope
level.
Like
every
time
you
create
a
new
namespace
automatically.
You
get
a
deny
policy
put
on
that
namespace.
You
know
what
I
mean
so
I'd
say
the
dns
one
and
I'd
say
the
cluster
scoped
one
probably
are
the
most
obvious,
obvious
ones.
C
So
so
what
are
the
things
that
you
probably
might
not
be
able
to
do
this
with?
This?
Is
that
if
you
do
an
automatic
translation
on
a
cluster
scope
level
is
let's
say
you
want
to
you:
don't
want
your
users
or
developers
or
namespace
users
to
delete
policies
created
by
cluster
admin,
and
now,
if
your
operator
is
creating
network
policies,
you
know
each
of
those
name
spaces.
How
do
you,
how
do
you
define
rba
for
certain
set
of
network
policies
as
opposed
to
certain
other
set
of
network
policies?
C
A
Yeah,
it's
tricky
right
so
and
I
always
get
afraid
that
the
cni
people
are
going
to
make
fun
of
me
whenever
I
propose
this
idea
so
because
you
all
know
how
complicated
it
is.
So
I
do
realize
that
there's
a
lot
of
like
sharp
edges
here
right.
So
I
by
no
means
I'm
trying
to
be
like
the
poster
boy
for
it.
I
just
somebody
wants
to
build
it.
B
Know
all
right
there
is.
There
is
like
the
specified
network
policy
to
a
services,
probably
some
some
user
story
as
well.
That
can
be
like
something
that
can
read
the
service
api
and
convert
like
an
object
from
from
us
from
a
service
name
to
the
service
id.
Maybe
I
also
don't
know
if
this
is
something.
A
A
A
B
Yeah,
so
about
the
caps
and
the
r
d,
I
think
that
we
are
done.
Does
anybody
have
anything
else
to
propose
to
the
user
stories?
We?
Actually
we
got
some
short
meeting
today
because
I
was
I'm.
I
was
waiting
for
the
summarize
for
the
summary
of
the
the
user
stories
from
andrew.
So
we
can
start
writing
the
the
the
proposal
of
the
of
the
api
design,
but
I,
as
I
told
you
it
couldn't
be
today
because
it's
it's
holidays
and
he
he
warned
us
about
that.