►
From YouTube: Network Policy API Bi-Weekly Meeting for 20201005
Description
Network Policy API Bi-Weekly Meeting for 20201005
B
A
B
B
Three
first
user
stories
accepted
by
sig
network
meeting-
yay,
that's
nice,
so
I
went
to
in
this
first
part
of
the
meeting
to
dedicate
the
accepted
user
stories
and
make
false
owners
of
the
of
the
gaps
I
can.
I
can
be
owner
of
one
of
them
without
any
problem,
so
about
our
first
user
story
that
support
range
or
set.
B
D
B
E
I
I
think
I
was
initially
slated
to
do
that,
but
I'm
happy
if
anyone
else
wants
to
own
that
they
can
absolutely
own
it,
so
I'm
default
but
absolutely
willing
to
give
that
away.
If
anybody
else,
in
fact,
I
would
encourage
someone
else
to
to
own
it,
because
I
think
the
broader
the
ownership
is
the
better
better
off
we'll
be,
but
if
not
I'll
take
it.
E
F
G
That's
really
yeah.
I
can
provide
a
quick
status
update
on
this
so
hi.
This
is
cobin,
so
abhishek
myself,
zhang
also
from
google
and
and
young.
We
we
sat
down
last
week.
We
started
discussing
the
cluster
number
policy,
scope
and
proposal,
and-
and
you
know
what
what
are
the
requirements
going
to
be
and
and
stuff
like
that,
so
so
we're
all
working
on
this
together,
but
I
think
it
makes
sense
to
have
one
one
owner
name
there.
E
G
H
A
Yeah
and
the
reason
why
it's
so
important
is
because,
at
the
close
to
the
enhancement
freeze
of
every
release,
you'll
have
the
release
team,
like
bombardier,
with
notifications,
to
update
the
kept
status,
and
so
whoever
makes
the
issue
is
going
to
be
on
the
hook.
Every
release,
for
you
know
making
sure
that
the
release
team
is
aware
of
the
you
know
the
status
of
whatever
future
you're
delivering.
A
C
A
B
Can
anyway
make
some
some
some
following
like
just
two
minutes
off
to
the
outers,
if
they
are
getting
some
some
sort
of
trouble
with
that,
but
I
think
that
we
can
we
we
don't
need
to
bring
this
in
into
every
meeting.
B
So,
let's
move
forward
the
next
island
that
I
that
I
brought
here
is
to
define
the
scope
of
the
super
project
I've
been
discussing
with
jay
and
andrew
about
the
expectations
of
of
everyone
in
into
this
into
what
we
are
going
to
accomplish
here-
and
I
think
this
this
this
one
is
much
more
like
a
discussion
that
we
need
to
make
here
before
moving
forward,
because
I
think
that
we
have
like
I,
I
I,
as
an
end
user,
want
to
accomplish
something.
B
A
lot
of
use.
Cases
like
been
really
different,
and
I
want
to
make
sure
that
everyone
here
is
is
on
the
same
page
here
before
we
we
move
forward.
So
I
think
that
everyone
can
keep
like
motivated
and
and
like
we
can
put
a
deadline
into
the
user
stories
and
start
making
things
move
forward
after
six
months.
So
the
first
one
that
I
put
here
as
a
as
that
we
need
to
define
as
a
scope
is
that,
if
are
we
going
beyond
traffic
bodies
like
process,
isolation.
C
B
If,
if
you
want
to
move
beyond
traffic
bodies,
there
is
a
user
story
about
that,
and
I
think
was
from
mike
isolating
multiple
process.
We
we
would
need
to
involve
signal
or
like
see
how.
How
is
this
going
to
be
inside
the
the
the
know
by
itself?
Not
only
network
policy,
not
not
only
by.
C
B
B
G
Sorry,
I'm
a
little
confused
by
the
the
prompt.
What
does
beyond
network
traffic
mean.
G
B
C
B
The
traffic,
so
my
my
vote
is
to
to
keep
only
the
threat,
only
keep
the
scope
into
pods
and
don't
go.
Don't
go
inside
the
containers,
because
this
is
going
to
be
really
hard
to
separate
and
we
are
going
to
need
to
involve
also
signal
and
see
how.
How
is
this
going
to
be
deal
with
the
the
container
on
time.
G
Yeah,
I
I'm
in
agreement
with
you
with
what
you
said
ricardo.
I
personally
think
that
it's
hard
enough
to
adopt
number
policy
today
having
it
be
a
a
pod
based
firewall,
so
adding
more
scope
to
it.
Where
now
it
starts
to
do
in
tripod.
Stuff
is
going
to
be
overloading
quite
a
quite
a
bit
of
stuff,
and
I
think
it's
going
to
get
harder.
It's
going
to
make
everybody's
job
harder,
ours,
customers,
users.
G
I
should
say
that's-
that's
my
my
take
on
it,
but
I'm
curious
to
hear
if
there
are
other
opinions
in
the
room.
A
Yeah,
I'm
just
gonna,
say
plus
one.
I
think
we
should
focus
on
apis
and
I
don't
think
the
apis
would
ever
get
to
a
place
where
it
would
select
lower
that
lower
down
the
stack
than
pods.
So
yeah.
B
Great
I'm
gonna
try
to
consolidate
this
also
and
send
to
sig
network
made
in
this
just
to
make
sure
that
everyone
is
on
the
same
page,
because
we
got
like
that
windshield
and
I
think
that
we
got
also
kodi
and
they
aren't
here
just
to
make
sure
that
we
are
not
getting
anyone
frustrated
about
that
like
why
we
are
doing
this.
Okay,
so
the
next,
the
next
one.
The
next
scope
that
I
that
I
wanted
to
to
discuss
with
you.
G
Sorry
before
we
move
on
to
the
next
one,
because
I
think
this
might
be
related.
I
think
this
when
I
first
read
this.
G
I
almost
thought
that
this
smelled,
like
something
I've
seen
otherwise,
which
is
qos,
and
I
thought
that
might
be
an
interesting
scope
for
nerve
policy
to
cover
where
a
customer
or
a
user
might
be
able
to
define
quality
of
service
and
bandwidth
requirements
for
a
certain
pod
and
say
that
oh
yeah,
I
have
this
like
very
critical
resource
that
requires
network
connectivity
at
this
you
know
rate
or
whatever,
and
you
can
take
away
resources
from
other
pods
if
you
have
to,
but
keep
this
one
high.
B
G
Know
calico
cni
provides
it,
but
it's
not
in
the
kubernetes
spec.
As
far
as
I
know,
please
correct
me
if
I'm
wrong,
I
I'm
not
sure
if
I'm
updated
on.
G
B
E
G
Okay,
I'll
I'll
put
a
note
in
the
in
the
dock,
at
least
so
we
have
it
for
posterity
and
then
we
can
come
back
to
later.
B
Yeah,
okay,
okay,
great
so
the
next
one
that
I
put
as
a
scope
that
we
need
to
discuss
here
is
about
how
are
we
going
to
deal
with
above
layer
4
traffic
without
turning
jesus
service
mesh?
So
we
know
that
calico
and
celium
they
they
do
support
the
http
network
policies
using
a
sidecar
with
envoy,
I
think,
and
also
we've.
We
have
discussed
that
there
is
an
item
in
the
agenda.
I
think
that
andrew
has
put
to
to
discuss
about
the
ftp
and
policies.
B
So
my
question
here
is:
are
we?
Are
we
okay
moving
forward
to
proposing?
Also
that
the
api
supports
the
some
layer?
Seven,
because
this
is
this-
is
going
to
be
pretty
complex
like
okay,
we
support
layer,
seven,
but
only
http
and
https,
and
then
someone
is
going
to
appear
wait.
Oh,
why
don't
you
support
irc's
protocols,
because
I
don't
want
my
my
bots
to
connect
to
freeload
servers.
B
C
A
G
B
A
B
A
A
We
should
base
it
off
of
the
feedback
we
get
from
the
community
on
on
the
use
cases
that
we're
trying
to
address
and
if,
if
the
need
comes
up
in
the
future
to
address
you
know,
l7
policies
we
can
discuss
possibly
like
a
new
resource
for
that,
or
maybe
we
can
just
say
like
this-
is
something
that,
like
the
services
api
should
do
or
something
else
I
don't
know,
but
I
wouldn't,
I
think,
it's
a
little
too
early
to
say
that
it
should
be
out
of
scope
at
this
moment.
A
G
B
Yeah,
I
think
it
will
be.
I
had
this
concentration
problem,
so
the
last
one
is
about
external
workloads.
If,
if
we
are
going
also
to
limit
the
boundaries
of
the
of
the
of
network
policy
to
objects
from
kubernetes,
there
was
a
discussion
inside
the
the
last
sig
network
meeting
that
meehan
brought
browsers
about
external
workload.
B
B
This
one
also
was
a
a
proposal
from
mike
and
I
think
would
be
great
like
if
we
could
have
like
kubernetes,
knowing
also
the
external
workloads
and
not
only
things
that
are
internal
to
it
and
having
like
objects
that
can
be
selected
and
those
objects
representing
like
a
mainframe
or
an
oracle
database.
Stuff's
external
from
from
from
the
network
from.
C
D
E
D
Question:
let's
go
ahead.
Sorry,
I
have
a
question
for
this
one.
So
ricardo
are
you
talking
about
the
idea
where
we
can,
probably
you
know,
incorporate
the
external
workloads
in
our
new
network
policy,
spec
like
like
in
the
in
the
in
the
ingress
or
egress.
We
can
use
the
external
entity
workloads
to
to
select
endpoints
rather
than
just
pause,
selector
and
namespace.
B
But
but
but
we
got
some
user
stories
saying
that,
like
I
wanna
to
create
a
network
policy
from
the
node
to
some
external
work
to
some
external
workload
like
I
want,
I
want
my
goal
to
communicate
to
like
my
my
corporate
dns,
but
a
way
to
put
everything
inside
network
policy.
So
the
idea
here
is
that
okay,
we
can
create
external
workloads.
B
A
Anyone,
so
I
think
I
think
today
we
do,
I
mean
by
extension,
it
sounds
like
this
is
something
we
should
support,
because
we
support
external
workloads
today
with
ip
block
in
a
way
so
plus
one
from
me
to
explore
this
more
like.
If
or
when
that
api
becomes.
You
know,
mature
and
ready
to
use.
C
G
B
E
E
B
My
my
concern
here
jay
is
for
the
next
next
item
that
so
now
that
we
can
say
that
we
have
like
a
scope.
We
can
try
to
define
a
deadline
for
user
stories,
because
I
am
worried
about
people
jumping
in
and
saying
like.
Oh,
why
don't
you
support?
I
scope
that
you
like
you,
you
can
put
a
network
policy
limiting
the
I
don't
know
the
disc.
I
o.
If
because.
B
Traffic,
you
know,
you
know
what
I
mean
like
I
don't
I
don't
want.
I
don't
want
the
user
to
write
like
txt
files,
so
that's
I
just.
I
just
want
you
to
limit
what
we
are
really
trying
to
do
to
achieve
here
in
the
in
the
in
what
matters
about
the
api,
but
I
agree
with
you
that
in
in
the
short
term,
this
is
not
like
too
much
relevant,
but
I
think
that
with
this,
these
scopes
define
it.
B
B
B
This
is
my
feeling
about
that
that
we
should
put
like
a
deadline
for
the
proposals,
not
because
we
don't
want
to
accept
everyone's
opinions,
but
because
we've
been
discussing
this
like
from
six
months
now,
so
I
am
like
personally
personally,
I
am
getting
tired
of
discussing
if
this
should
get
into
the
api
or
if
this
should
be
like
a
controller
or
if
this
is
going
to
be
like
a
cube,
ctrl
plugin,
and
I
think
that
we
can
get
like
a
clearer
view
of
what
we
want
to
do
just
when
we
close
what
we
we
accept
as
user
stories
proposals.
B
So
I
think
that
we
should
have
like
two
or
three
more
meetings,
maximum
defining
all
of
those
user
stories
that
we
have
like
in
encodings
sheets
and
also
in
in
our
documents
and
say,
okay.
This
is
this
is
what
we
we
see
as
user
stories,
and
now
we
we
can
start
like
defining
a
timeline
for
the
work
in
progress,
writing
documentation.
C
B
B
Stories
that
we
got
here
like
we
got
this,
this
nice
drawing
from
jay
and
some
user
stars
like
secure
cross,
namespace
communication
through
security
gateway
and
named
cidrs
metal
of
interaction.
So
I
suggest
that
everyone
drops
into
this
document.
Take
a
look
into
every
user
story,
see
if,
if
we
are
missing.
E
We
don't
expect
anybody
to
get
really
passionate
about
network
policies
tomorrow
and
just
join
the
group
and
dump
10
stories
on
us
so
like.
But
if
somebody
has
an
idea
I
mean
we
could
just
have
some
okay.
You
know
if
you
want
to
propose
an
idea
at
the
end
of
every
meeting,
there's
10
minutes,
people
can
propose
a
new
idea
or
whatever,
and
we
can
talk
about
it
as
a
team
right,
but
we
I
mean
as
far
as
I'm
concerned,
we
could
close
that
document.
Now
we
don't
have
anybody
proposing
anything
right.
E
B
E
B
E
B
E
B
E
We
could
say
yeah,
okay,
so
my
proposal
is,
we
say
if
somebody
wants
to
talk
about
something,
including
a
user
story
that
we're
not
actively
working
on
at
the
end
of
every
meeting.
Anybody
has
the
opportunity
to
talk
about
any
crazy
idea
that
they
want
and
we
have
our
priorities
and
the
chances
are
they.
You
know,
there's
a
decreasing
priority,
the
decreasing
probability
that
those
stories
will
align
with
our
priorities
over
time
as
we
get
busier
trying
to
get
real
work
done
right.
A
I
agree
with
jake,
but
I
do
also
think
that
it'd
be
great
to
have
a
list
of
user
stories
that
we've
vetted
out
and
discussed
and
we
feel
are
good
potential
candidates
to
bring
back
to
zig
network
and
you
know,
have
have
the
larger
group
kind
of
review
them
so
so
yeah.
I
do
agree
like
we
should
have
ongoing
discussions
around
news
stories,
but
we
should
have,
like
you
know,
a
refined
list
of
of
user
stories.
We've
discussed
and
agreed
on
as
valid.
A
Yeah
and
if
we
need
someone
to
just
go
through
the
list,
I
can
take
an
action
item
to
try
to
do
that.
B
B
B
I
think
that
we
should
start
like
the
funny
part
of
okay,
making
the
documentation
isn't
funny
at
all,
but
starting
to
define
the
the
data
model
and
defining
the
auxiliary
tools.
So
what?
How
are
we
going
to
build
that
and
propose
that
to
to
the
broader
group?
So
I
I
like,
I,
I
really
like
the
docs
from
the
documentation
from
services
guy,
because
I
think
that
bowie
was
really
the
descriptive
about
the
personas
and
the
objects
and
what
they
are
trying
to
do.
That
and
my
expectation
that
is
that
we
can.
E
I
think
that
dan
kind
of
proposed
that
a
while
ago
I
mean
that
was
dan's
proposal-
was
very
close
to
this
right.
The
idea
that
we
kind
of
define
things
contextually
at
a
high
level
and
then
network
policy
is
some
piece
of
that
puzzle,
and
then
you
drill,
there's
like
a
russian
dolls
thing
right,
where
you
kind
of
drill
down
into
exactly
what
for
the
user
stories
that
we
support,
here's
the
it
seems
like
that
kind
of
would
be
to
me
at
least
the
service
api
stock,
which
I
agree
is
really
good.
E
The
really
really
key
thing
that
was
important
to
understand
was
the
difference
between,
like
the
cloud
provider
and
the
administrator
and
the
developer,
like
those
personas
like
that
was
the
hard
hard
piece
of
the
puzzle
to
like
you,
know,
untwine,
and
then
I
feel
like
for
us.
The
hard
piece
of
the
puzzle
to
entwine
is
what
we
do
and
what
what
network
policy
api
does
versus
what
the
other
external
apis
do.
E
Like
service
mesh
and
all
that
other
stuff
that
we're
saying
we
don't
do
here,
you
know
what
I
mean
like
it's
like.
We
have
to
differentiate
and
I
feel
like
dan's
doc
dan
suggested
kind
of
captured
that
because
he
basically
said
we
should
write
a
doc
that
has
a
you
know
that
that's
independent
of
the
api,
so
that
we
can
actually
figure
out
what
the
api
it's
very
hard
to
define.
Right
like
this
stuff
out
of
context,
yeah.
B
E
It
seems
like
it
could
happen
in
parallel.
Right
I
mean
we.
We
all
know
what
you
know
yeah,
I'm
sure
I
mean
I
think
something
tying
together.
The
user
stories
we
propose
is
important
because
I,
I
think
any
one
of
those
user
stories
just
as
a
random
kept
to
me
intuitively,
isn't
like
it's
it's
more
for
us.
The
overall
goal
is
to
have
a
holistic,
easy
to
use
api
and,
and
so
getting
one
kept
merged,
doesn't
get
us
there
right.
B
B
I
can
try
to
copy
from
the
surface
api
one,
and
at
least
this
schema
to
to
say,
okay,
what
what
we
need
to
fill
in
the
document,
so
we
we
can
have
like
a
guideline
of
what
what
we
should
do
next,
because,
honestly,
I
I
don't
know
what
we
should
do
next.
E
I
mean
I
don't
yeah,
I
mean
I
don't
see
why
not,
unless
anybody
thinks
we
should
gate
that
on
this
user
stories
stuff,
but
I
mean
I
feel,
like
the
user
story.
Stuff
doesn't
have
to
be
gated
on
that
because
we
kind
of.
B
E
B
B
From
from
default
from
service
api,
because
they
were
really
good
about
all
here,
they
were
really
good
about,
like
writing
the
the
user
guide
and
what
they
want
to
do,
the
api
concepts
and
inside
the
api
concepts
they
write
about
roles
and
personas.
So
I
think
that
once
we
have
like
the
user
store
is
closed.
B
E
E
B
Yeah
yeah
this
is
this-
is
this
is
an
issue
that's
opened
and
I
didn't
deal
with
that
either
yet
asking
for
the
ark
to
migrate,
this
repo
to
our
repo
inside
kubernetes
6,
and
also
to
to
create
maybe
a
slight
channel.
So
we
can,
we
don't
need
to
communicate
inside
direct
messages
to
not
follow
this
network
channel.
C
So
one
thing
we
did
in
service
apis
was
create
issues
for
each
user
story.
I'd
probably
say
that
was
that
kind
of
had
a
mixed
amount
of
success,
but
I
don't
know
if
you
want
to
consider.
B
C
Yeah
there
was
a,
I
think
there
was
a
few
documents.
There
was
one
where
bowie
and
some
others
did
a
survey
of
like
a
feedback
survey
of
ingress
v1.
There
was
also,
I
think
that
was
the
main
one
that
tried
to
capture
user
feedback
on
on
the
problems
with
the
existing
api.
Then.
E
C
So
that
was
where
that
it
was
at
that
point
when
the
repo
was
started
and
the
working
group
was
sort
of
kicked
off
or
and
made
it
kind
of
brought
in
the
the
main
community.
So
they
started
with
you
know
a
small
number
of
people
getting
some
feedback
and
having
an
initial
design
proposal.
E
Yeah
we
did
the
opposite.
We
started
with
like
a
million
people,
giving
us
all
sorts
of
crazy
feedback,
and
then
we
pruned
the
list
down
because,
like
half
the
stuff
didn't
wasn't
useful
yeah.
But
if
you
didn't
know,
I'm
kind
of
like
in
two
minds
about
this,
like
I
get
it
that
they
did
a
good
job
with
service
apis.
But
to
me
we're
a
different
group,
and
I
mean
it's
great-
that
we're
borrowing
from
them.
But
I
don't
think
that
that's
for
me,
I'm
like
okay,
like
what's
the
problem
we're
trying
to
solve
here
like.
B
B
The
schema
of
the
document,
so
we
can
like
write
because,
because
usually
I
forgot
things
like,
I
think
that
we
have.
We
need
to
have
like
a
from
a
front
page
that
what's
the
problem
that
that
we
are
trying
to
solve
and
written
like
you
know
either
one
size
you
know,
so
we
don't
we
we
don't
generate.
We
don't
generate
expectations,
but
we
don't
generate
frustration
either.
Jane.
E
No,
I
mean,
I
think,
it's
a
great
way
to
tie
everything
together.
I
just
yeah
I
want
yeah.
I
think
that
I
think
borrowing
from
them
is
a
great
idea,
because
it
ties
together
really
nicely.
B
Yeah,
so
I
think
that's
over
here
we
have
my
my
items
they
are
over.
We
have
some
items
that
need
to
be
assigned
to
people.
I'm
gonna
open
in
in
jade's
repo
before
it
turns
into
an
official
repo
issue,
is
asking
for
folks
to
follow
the
the
caps
to
create
the
caps
and
also
to
to
andrea,
to
go
through
the
dock
and
to
me
to
to
ask
the
ripple.
So
we
just
don't
forget
what
we
have
assigned
it
now,
and
I
think
that
I
can
pass
to
andrew.
A
Yeah
before
we
go
there,
would
it
be
good
to
try
to
get
a
soft
estimate
on
when
we
think
like
what
releases
we
want
to
target
the
caps
for
for
the
for
the
three,
the
three
user
stories
that
we
agreed
on,
maybe
it'd
be
good
to
to
to
agree
on
like
what
what
release
do.
We
want
to
merge
them
as
provisional,
which
means
it
just
has
the
the
summary
and
the
the
problem
statement.
I
guess
in
there
and
then
what
release
do
we
want
to
get
merge
the
caps
as
implementable.
B
I
think
that
two
firsts
they
are
easier
to
get
them
in,
like
v121
having
them
as
a
provisional
and
v122
to
have
them
as
alpha
maybe
and
follow,
follow
the
the
guideline
from
from
jordan.
I
can't
remember
the
the
versions
that
we
need
to
step
before
turning
them
into
be
better,
and
I
don't
know
either
because
network
policies
v1
right.
So
this
is
not
going
to
enter
as
a
now
for
a
beta
but
directly
as
stable.
A
No
so
new
fields,
even
in
v1
apis
new
fields,
need
to
be
obligated
so
that
n
minus
one
api
servers
can
can
round-trip
the
new
fields
and
it
doesn't
break.
You
know,
downgrades
so,
unfortunately,
like
even
the
even
new
fields
on
the
network
pulse
apis
need
to
go
through
alpha
beta,
j,
okay,.
H
Yeah
you
end
up
like
adding
it,
but
then
it's
only
available
for
like
andrew
said
when
you
downgrade.
So
if
you
were
to
go
to
a
newer
version
when
it
is
finally
available
and
then
go
back,
it
would
be
available.
But
by
default
for
that
initial
release
it's
there,
but
you
can
only
use
it
from
upgrade
downgrade
scenarios.
A
B
A
Right
so
I
I
I'm
not
sure
what
the
rule
for
provisional
caps
is,
but
I
think
you're
allowed
to
merge
provisional
caps
whenever
so
yeah
like
maybe
maybe
for
the
first
two
or
actually,
maybe
for
all
of
them.
It
would
be
reasonable
to
do
provisional,
like
some
time
in
the
1.20
release
cycle,
merge
them
as
provisional
with
just
like
the
summary
and
the
the
problem
statement,
and
then
we
can
target
1.21
as
implementable
for
for
the
first
two
and
then
maybe
a
close
scope,
network
policy,
we'd,
say
1.22,
that's
implementable!.
B
A
Yes,
but
in
the
cap,
you'd
have
to
you'd
have
to
specify
like
the
graduation
criterias
and
you
you'd
have
to
specify
like
in
the
cap
what
what
release
you're
targeting
for
for
alpha
but
yeah
you.
You
can't
start
the
alpha
work
until
you
flip
the
status
to
implementation.
A
B
G
I
don't
think
we
discussed
that
actually,
as
a
group,
so
it'd
be
unfair
for
me
to
just
you
know,
put
undue
pressure
on
the
rest
of
the
tape,
but
I
think
if
1.21
is
the
target
for
the
other
ones,
I
would
say
at
least
you
know
an
release
plus
plus
one.
That
would
be
reasonable,
because
the
questionnaire
policy
is
is
pretty
pretty
big.
E
E
And
I'm
wondering
like:
is
that
really
something
that's
gated
on
us?
Or
is
that
really
some
I
mean
if
you
merge
a
v1
alpha
and
knows
you
know
I
mean?
Is
there
some
kind
of
weird
gaiting
thing
that
we're
not
thinking
about
like
if
we
were
changing
an
api
that
was
in
tree
right?
Okay,
that
would
make
sense
because
it
was
a
kubernetes
thing
everybody
in
kubernetes
agreed
on
it,
but
to
mur.
E
I
remember
a
mailing
list
thread.
I
went
and
I
reread
all
the
network
policy
mailing
list
from
like
the
last
two
years,
and
I
remember
I
saw
one
where
dan
winship
had
posted
okay
who's
using
the
new
pod
name,
the
new
namespace
select
the
namespace
pod
or
switch
or
and
switch,
and
what's
the
feedback
like
and
then
you
know,
casey
was
one
of
the
people
that
responded,
he's
like
well,
we've
had
in
calico
for
a
while,
and
you
know
it
seems
to
be.
E
B
Like
I
can
announce
for
the
calico
folks
in
in
slack
at
least,
I
stay
a
lot
of
time
there
and
use
it
to
talk
with
with
sean
grantham,
but
I
think
that
almost
this
cap
is
measured
as
as
at
least
as
provisional.
It
would
be
great
like
that
we
announced
this
in
mailing
list
or
even
in
the
kubernetes
dev
mailing
list.
I
don't
know,
what's
the
better
place,
to
announce
that
so
any
cni
implementing
any
any
any
any
folks
from
from
the
cni
companies.
K
B
F
A
Hold
on
but
but
maybe
there
was
a
miscommunication
here,
because
because
you
implied
that
there
is
a
new
api
group
and
that
these
aren't
intrigued,
but
the
first
three
caps
are
proposals
to
the
current
v1
like
entry
network
yeah,
that's
right,
you
know
I.
E
Mean
like
they're
in
tree,
but
like
all
like
we're,
not
implementing
you
know,
I
mean
all
the
actual
usefulness
of
them
is
that
the
cni
providers
actually
implement
them
properly
right
and
I
feel
like
it
would
be
kind
of
weird
for
us
to
like
merge
like
have
a
plan
to
merge
things
to
the
kubernetes
api
that
wasn't
aligned
with
at
least
having
one
cni
having
a
canonical
implementation
of
it.
B
B
What
happens
if,
like
everyone
had
everyone
implements
the
service
type
load
balancer,
but
on
a
specific
call
provider.
You
know
what
I
mean
it's
going
to
be
pressure
under
that
under
that
clock
provider
to
implement
also
the
service
type
of
balancer,
because
the
others
they
have-
or
this
is
a
part
of
the
api,
so
yeah.
E
E
H
E
H
Someone
from
calico
and
whatnot
I
mean
we
had
a
similar
thing
with.
I
think
I
remember
what
mailing
is
that
you're
referring
to
and
one
of
them
was
on
the
egress
policies
and
red
hat
specifically
had
not
implemented
egress
in
the
way
that
we
had
it.
Currently,
it
had
been
like
one
or
two
releases
or
something
or
it
was
like
in
beta,
but
we
were
trying
to
push
it
to
ga
and
the
decision
was
like.
We
can't
gain
everything
on
the
third
party
kind
of
plug-ins
and
hilariously
enough.
H
E
F
G
G
Okay,
okay,
andrew
first
of
all,
thank
you
for,
for
you
know
putting
this
down.
I
know
I
I
think
we
were
discussing
this
a
little
bit
last
week
and
just
for
anyone
who
wasn't
there
for
that
discussion.
I
just
wanted
to
give
you
a
quick
introduction
to
what
fqdn
policies
are.
G
More
than
anything
else
I
mean
yeah,
they
could
do
the
look
up
and
install
the
ip
addresses
in
there,
but
hey
that
can
change,
and
you
know
it's
cumbersome
and-
and
it's
not
really
scalable
from
a
security
perspective
when
you
do
this
at
large
scale.
So
as
a
matter
of
convenience,
many
customers
have
asked
for
egress
controls
with
fqdn
based
targets,
so
you
could
think
of
it.
G
Just
as
another
sort
of
type
of
you
know
specification
for
for
egress,
so
like
egress
to
ipsider,
egress
to
url
or
fudn,
or
something
something
of
that
sort,
so
it
doesn't
necessarily
require
a
new
crd.
As
far
as
I
can
tell
I
haven't
really
you
know,
sort
of
broken
it
down
to
its
pieces
yet,
but
that
would
be
my
hunch
I'll.
Stop
there
any
any
questions
or
concerns
here.
I
know.
One
thing
that
came
up
last
time
was:
is
this
l7
ish?
G
It
feels
like
it's
l7
ish,
but
to
that
I
mean
you
know
it
almost
feels
like
it's
more
of
a
like
the
analogy
I
used
last
time
was
you
know
this
is
more
like
a
kubernetes
label
being
translated
to
ip
addresses,
rather
than
an
l7
construct.
G
So
that
would
be
my
sort
of
way
of
looking
at
it,
but
you
know
I
kind
of
want
to
just
make
sure
that
everybody
understands
the
ask
here.
First.
B
G
J
To
understand
better,
I
kind
of
missed
what
you
were
saying
the
first
time
I
didn't
want
you
to
repeat
it,
but
if
there
was
like
a
shoe
link
or
something
like
a
preference.
G
Yeah,
I
can
add
some
links
to
this.
This
talk
once
once
we
finish
up
wrap
up
for
today.
We
have
one
minute,
but
just
you
know,
I
I
think
that
to
answer
ricardo's
question
that
he
asked
there
are
probably
gonna
be
many
many
subtleties
here.
G
I
think
the
important
thing
here
is
based
on
tim's
advice,
which
was
sage
advice.
You
know
defining
what
the
semantics
are,
that
we
want
to
support
and
whether
that's
good
enough
for
our
users
use
cases
maybe
solve.
Maybe
we
don't
have
to
solve
the
whole
sort
of
subtlety
of
like
dns
entries,
expiring,
and
you
know
the
type
of
records
and
things
like
that.
Maybe
what
they're
looking
for
is
something
relatively
basic
and
as
long
as
it
works,
you
know
100
of
the
time
we
are
we're
in
the
clear.
G
So
it's
not
a
it's,
not
a
100
dns
adhering
policy.
However,
the
cases
that
it
does
work
for
it
works
100
of
the
time.
I
don't
know
if
that
clarifies
you
know
the
the
way
I'm
thinking
about
this.
E
G
And
whoever
did
that
you
know
sort
of
docs
there.
Thank
you.
You
know.
I
only
see
anonymous
animal
name.
So
so
thank
you
but
yeah.
I
think
those
are
some
good
docs
to
follow
I've
sort
of
poured
over.
You
know
the
psyllium
spec
for
dns
based
policies.
G
I
think
what
they're
doing
is
they're
just
sort
of
snooping
the
traffic
between
cube,
dns
and
other
pods,
and
when
they
make
a
request
to
go
out
to
some
other
url.
That
requires
a
resolution
they
just
kind
of
snoop
on
that
traffic
and
then
they
program
ebpf,
based
sort
of
updates
where
they
can
block
that
that
traffic
based
on
policy
and
things
like
that.
So
so
that's
how
they're
they're
doing
this
today,
I
believe
and
from
what
I've
heard
it's
good
enough.
I
mean
I
have
anecdotal
evidence.
G
I
mean
I
have
by
no
means
have.
I
run
a
survey
on
this,
but
I've
anecdotal
evidence
that
it's
good
enough,
so
perhaps
a
a
good
use
of
time
here
could
be
that
you
know
we
could
just
borrow
or
replicate
some
of
the
good
parts
of
calico
and
psyllium,
and
I
think
openshift
has
a
version
of
this.
But
yeah
andrew
has
a
question.
I
guess
we'll
wrap
up
wrap
up
with
that,
but
would
it
belong
in
a
new
resource
policy
like
dns
policy.
G
Yeah
yeah,
okay,
I'll,
take
a
question
here
I
mean
I'll.
Take
a
note
here
of
the
question.
Sorry
sorry:
apologies
for
going
a
minute
over
I'll
I'll
leave
it
at
that.
You
know
so
for
folks
to
sort
of
think
about
over
the
week.
J
Well,
I'm
just
going
to
say
the
the
quick
stuff
that
I
looked
at
there.
I
guess
my
my
question
is:
why
would
we
not?
Why
would
we
not
want
to
do
that?
Because
if
we
fast
forward
to
once,
we've
made
some
of
these
new
policy
improvements
and
we've
solved
the
single
name,
space
cube
system,
dns
network
policy
situation?
J
You
know
I
just
anticipate
very
quickly
folks
who
said
well,
don't
allow
non-approved
package
repos,
you
know
for
like
their
build
system.
I
don't
know,
I
think
it's
just
gonna
come
very
quickly
afterwards,
so
that
makes
sense.
Yeah.
A
E
Before
you
close,
I
know
this
is
last
second,
but
I
just
if
we're
gonna
make
this
an
official
repository.
Does
anybody
have
a
strong
opinion
about?
I
was
thinking
a
potential
place
for
our
existing
network
policy
tests
to
land.
We
have
this
kept
for
it,
but
I
was
thinking
a
potential
place
it
could
live,
might
be
in
kubernetes
six,
the
network
policy
working
group.
E
E
A
I
mean
I
I
personally
prefer
if
we
kept
the
repo
focused
on
apis,
but
you
know
that's
just
one
person's
opinion,
so
yeah
no
strong
objections,
but
that's
important.