►
From YouTube: Network Policy API Meeting 20210301
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
Meeting
so
we
expect
everyone
to
follow
the
code
of
conduct
and
and
be
nice
with
each
other.
So
when
we
are
getting
started
today
today
we
have
the
meeting
knows
that
the
meeting
agenda
is
pretty
short
and
we
don't
have
a
lot
of
folks
here,
so
we
can
just
get
started
if
someone
wants
to
enter
any
any
other
item
to
be
discussed.
Please
be,
I
guess,.
A
Okay,
so
the
first
item
of
the
agenda
is
an
issue.
Triage
we've
been
doing
this
since
the
last
meeting,
and
I
guess
this
is
this
is
good.
So
we
can.
We
cannot
actually
take
a
look
into
what's
going
on
if
we
have
any
new
user
story
or
at
least
some
problem
with
with
what
has
been
proposed,
and
we
have
34
open
issues,
but
let
me
put
a
label
here:
it's
triage.
A
B
Yeah,
I
can
take
care
of
this.
We
can
start
with
the
with
the
api
integrations
have
on
one
part
for
the
apis.
Only
and
as
we
get
these
in
calico,
we
test
the
actual
code.
A
A
A
Hey
what's
up
jay,
so
we
are
triaging
issues,
and
this
one
is
is
one
that
you
can
actually
use.
Then
the
node
readiness
and
liveness
probes
to
somehow
attack
the
pod
like
this
one.
They
can
use
the
redness
probe
to
trigger
some
action
into
google
or
aws
mega
data
server,
and
so
it's
not.
It's
not
quite
related
to
our
work
here.
A
But
this
this
falls
again
into
the
node
selector
case,
because
you
could
have
some.
You
could
have
as
an
example
a
a
network
policy
not
allowing
any
traffic
from
from
the
node.
Even
if,
if
this
is
like
a
liveness
or
a
redness
probe
or
you
you
you
just
allowing
liveness
or
redness
probes
from
the
node
to
the
to
the
bot
specific
part
like
8080
and
not
like
an
admin
part
from
from
java.
A
C
A
Yeah,
in
this
case,
they
are
using
like
the
redness
probe,
like
node,
triggering
the
the
metadata
infrastructure,
but
there
is
another
example:
other
possible
targets
are
local
hosts
and
points
etc.
Metrics,
like
you,
can
put
these
in
redness
probe
and
you
can
trigger
something
in
readiness
in
etcd,
metrics.
C
I
think
it's
by
definition,
of
course,
of
the
network
policy
api
right
now
that
this
is
not
something
that
is
enforced
by
network
policy.
So
that's
incorrect
that
it's
bypassing
network
policy
restrictions,
because
if
you
actually
look
in
the
types.go
it'll
say
all
traffic
is
allowed
from
the
node.
You
know
what
I
mean
yeah
so
like
this
is
issue
as
stated
is
wrong,
but
it's
like
a
really
cool
idea
that
we've
talked
about
before.
C
So
I
I
feel
like
we
should
kind
of.
I
don't
know
I
mean
it
seems
like
there's
two
things
happening
in
this
issue.
One
is
they're
saying
that
they're
subverting
network
policy-
that's
not
the
case,
but
they're.
Also
saying
it'd
be
great.
If
network
policy
supported
this
and
that's
valid,
so
I
you
know,
I
would,
I
feel
like
it's
I
feel
like.
We
should
encourage
them
to
who's
working
on
node
policies.
C
The
object,
or
is
that
different,
that's
cluster
scope.
Did
we
just
totally
forget
about
node
policies
like
entirely
like?
I
thought
it
was
a
thing
like.
I
thought
it
was
something
we
were
doing.
C
A
A
F
Also
also
in
general
like
would
it
make
sense
to
have
like
node
based
policies
for
namespace
network
policies?
I
think
we
can.
We
can
use
only.
We
can
use
cluster
flash
metal
policies
only
for
node,
like
for
selecting
nodes
as
such.
F
Because
for
name
space
network
policies,
it
may
be
a
little
bit
confusing
to
have
node
selector,
because
nodes
are
flash
scope
right.
So
probably
we
can
use
cluster
network
policy
for
like
defining
like
node
node
based
network
policies.
F
I
mean,
but
I
think
we
still
have
to
have
node
selector
in
the
in
the
peers,
like
english,
spear
or
egress
peer
for
network
policies,
because
because
the
the
target
can
be
a
part
but
the
destination
can
be
a
node,
so
you
can
still
have
it
in
ingress
or
egress
pl.
But
for
for
selecting
as
a
target,
I
think
only
cluster
network
policy
is
the
candidate.
A
G
There's
just
not
enough
details
in
here,
I
looked
at
it.
It
just
doesn't
make
a
whole
lot
of
sense
like
what
what
do
they
mean
by
kubernetes
api?
I
don't
know,
I
assume
they
mean
some
endpoint
or
something,
and
then
you
can
see
that
like.
If
you
look
at
their
policy
like
they
have
a
super
specific
ip
block
and
then
their
solution
is
to
use
like
a
like
an
anything
ip
block.
You
know
so
like
whatever
problem
they
have,
they
didn't
really
explain
it
and
they
didn't.
I
don't
think
they
really
understood
it
either.
G
A
G
I'm
I'm
happy
to
follow
up
on
this
one
if
nobody
else
wants
to.
I
don't
really
expect
to
that.
There
will
be
anything
that
comes
out
of
it.
I
think
it's
just
like
a
you
know.
They
probably
just
need
to
learn
a
little
bit
about
network
policies
or
something
but
yeah
I
mean
like
feel
free
to
assign
it
to
me.
A
H
A
C
A
A
Okay,
so
this
is
assigned
to
you
jay
and
the
last
one
restrictively
that
knows
not
ready,
because
blah
blah
blah
blah
blah.
A
A
So
so
what
what
do
you
need?
What
do
you
want
to
do
next?
Folks,
because
to
me
I
guess
this
one
is
pretty
hard
to
discuss
and
also
I
am
thinking
about
before
discussing
here,
sending
like
two
sig
network,
mailing
lists
and
saying,
okay.
Why
is
there
a
reason
why
we
shouldn't
do
this
way
or
that
way,
so
they
can
like
throw
everything
on
us
and
we
can
make
some
proper
discussion
better,
and
I
guess
this
one
is
something
that
we
should
probably
discuss.
Right
now
sounds
good.
A
D
D
A
F
So
I
think
the
difference
is
like
so,
like
notes
does
not
have
any
name
spaces
right.
I
mean
network
policy
is
like
protecting
a
particular
namespace,
but
I
think
cluster
names
like
karascope
their
policies,
are
like
more
for
the
entire
cluster,
so,
like
nodes
are
like
cluster
resources,
so
probably
it
would
make
sense
to
include
in
the
cluster
network
flash
networks
itself
and
also,
I
would
feel
like
the
second
item,
like
the
network
policy
like
adding
an
api
to
allow
node
as
appear,
I
think
we
could.
F
We
can
still
achieve
it
using
cluster
scope
network
policy,
but
the
idea
is
like
to
make
it
simplified,
like
I
mean
like,
if
I'm
a
developer
and
if
I'm
writing
net
policies
to
a
particular
namespace,
I
want
all
the
policies
related
to
that
name,
space
in
a
single
object.
So
that's
the
only
use
case
I
see
where
you
want
to
have
node
as
appear,
but
other
than
that.
I
think
clustering
policy
in
itself
would
be
sufficient
to
cover
all
the
node
associated
meta
policies.
In
my
opinion,.
A
A
I
And
he's
here
I
think,
I
think,
for
for
the
cluster
policy
proposal,
we're
doing
right
now
for
the
initial
cap
we
opened.
I
think
we
didn't
put
node
selector
or
those
kind
of
things
into
the
scope
for
for
the
first
iteration
it
would
be
otherwise
it
would
be
too
much
scope
to
include
for
the
for
the
first
cap,
so
we
kind
of
like
decided.
This
could
be
a
like
quota
up
or
or
individual
cap
by
itself.
I
Yeah,
I
think
I
think
I
I
remember
talking
to
abstract
and
he
he
he
said
this
could
be
a
sort
of
like
orthogonal
cap
on
its
own.
I
Yeah
sure
sure
that
makes
sense,
I
think,
because
me
and
the
statistician,
the
and
goldman
who
actually
are
unactive
working
on
the
cluster
in
our
policy
cap
right
now.
We
have,
we
have
a
thursday
meetings,
so
I
think
I
think
we
can
bring
this
up
this
thursday
and
discuss
within
the
group
on
you
know
whether
or
how
we
should
move
forward
with
the
with
this
use
case
and
anyone
else
in
the
in
the
call
who
are
interested
in
this.
Maybe.
C
We
can
I
keep
forgetting.
Satish
is
also
and
and
go
bender.
Also
on
that
I
yeah
that's
great
yeah,
so,
okay,
the
four
of
you
all,
are
like
the
node
people,
cool
okay.
So
does
anybody
else
want
to
help
with
this
node
stuff?
I
don't
want
to
like
discourage
other
people
from
owning
it
if
they
want
to
help.
C
I
So
I
actually
have
a
clarifying
question
on
this
for
on.
Can
you
explain
a
little
bit
more
on
targeting
the
metadata
server
as
in
what
that,
with
that
movement,.
A
J
Is
that
I
mean
so
it's
the
metadata
server
and
I
know
it's
it's
it's
a
link
local
address,
but
is
that
actually,
on
the
note
itself
or
is
there
a
network
call
that
happens
on
the
cloud
provider's
side?
That's
really
an
external
resource,
you're
calling
so
would
this
be
more
defining
external
resources
or
these
definitely
it
runs
on
that
same
same
node
itself.
A
J
So
we
would
look
at
it
then,
like
these
policies
could
be
written,
not
just
against,
because
now
we're
looking
external
from
the
node
itself
again,
if
we're
trying
to
restrict
a
like
a
local
ip
that
is
on
the
node.
But
now
could
it
be
for
any
service
like
that
there
was
another
ticket
earlier
where
somebody
was
asking
about
the
the
api
service.
Ip
address,
that's
external
to
the
nodes
as
well
I
mean.
J
I
I
think
I
think,
from
my
point
of
view,
I
think
I
kind
of
like
agree
with
what
satish
just
said
is
that
you
know
the
the
the
thing
is.
We
are
here
probably
just
trying
to
alter
the
scope
of
what
the
policies
like
so
for
the
cluster
in
our
policy,
even
for
the
cluster
network
policy,
we're
proposing
right
now
the
scope
is
lex.
There's
only
parts
we
can
write
some
policies,
such
as
you
know
we
want
to
allow
on
the
pods
to
egress
to
a
ip
address
from
out
of
the
cluster.
I
Now
with
the
node
policies,
we
wanted
to
sort
of
like
apply
the
entire
policy
to
a
node,
so
that
you
know
we
don't
care
if
it's
paused
on
the
node
or
or
whatnot
you
know
for
for
the
node
itself,
we
wanted
to
allow
egress
to
to
a
certain
external
ip.
So
I
think
that's
the
that's
the
differentiating
point
here.
I
think
so
so
it
is.
It
is
a
little
bit
more.
I
J
Okay,
yeah,
I
think
it
does
so.
Basically
we
know
this.
We
know
the
scope
of
the
source,
but
what
item
it
targets,
then,
is
what
is
obviously
flexible,
but,
like
you're
saying
the
first
use
case
is
going
to
be
this
metadata
server,
which
is
a
well-known
ip
right,
pretty
much
every
cloud
provider.
Has
this
kind
of
system
set
up
so
okay,
that
makes
sense.
Thank
you.
A
Okay,
so
I
left
this
one
to
to
to
be
discussed
in
the
clusters:
copper
network
policy,
meaning
okay,
yeah.
So
it's
like
okay,
we
can
see
what
can
be
done
here
sounds
good.
A
Okay,
the
last
item
in
in
the
agenda,
but
I
will
I
will
trigger
an
email.
I
want
to
first
just
check
with
you
folksy
it's
about
the.
I
guess
we
started
to
discuss
this
in
the
last
meeting,
but
it's
about
if
we
should
now
because
of
like
we
we
are,
we
are
hitting
some
some
some
walls
in
the
proposals
like
the
service
selector
or
the
node
selector,
or
anything
that
that
inserts
a
new
selector
in
the
in
the
network
policy.
A
It
hits
a
a
logo
because
of
the
of
the
the
fall
of
the
of
the
default
behavior
being
the
fall,
allow
instead
of
the
49
right.
So
if,
if
I
I
can't
select
anything,
I
do
follow,
and
this
is
this.
This
has
been
also
a
best
issue
from
from
team,
hawking
and
other
folks
about
about,
like
this
been
a
problem
in
in
network
policy.
But
as
network
policy
has
reached
v1,
we
cannot.
A
This
almost
the
same
object
from
the
viewer,
but
with
the
idea
of
explicit
behavior
as
jay
always
says
that
we
we
need
to
make
those
behavior
explicits
or
if
we
should
propose
as
a
short
path.
Some
something
like
a
network
policy.
Spec
2
inside
the
net
network
policy.
V1
object
like
having
a
network
policy
v1
and.
J
A
But
I
want
to
hear
you
first
folks,
as
we
now
have
a
little
bit
more
time
about
if
we
should
first,
if
we
should
move
forward
to
individual
proposal
and
second,
how
can
we
move
forward
with
the
v2
proposal?
Because
I
guess
cluster
scope
and
network
policy
should
be
a
different
object,
but
we
still
need
to
evolve.
The
network
policy
object
to
something
more
secure
about
it
by
default,
so.
C
I
think
the
best
way
to
move
forward
with
it
would
be
to
build
a
prototype
based
on
crds
that
that
that
translates
in
somehow
that
translates
80
of
the
things
that
we
care
about
into
lower
level
network
policies
and
play
with
it.
That's
what
I
feel
like,
but
I
I
feel
like
this
stuff
to
get
it
right.
We
have
to
play
with
it.
We
have
to
build
something-
and
I
know
matt
has
done
some
work
around
that
he
tried
to
build.
He
did
something
really
ambitious.
C
C
Yeah
I
mean,
and
there
was
that
thing
you
had,
I
think,
with
the
ingress
egress
issue,
where
there
was
that
weird
issue
you
ran
into
where
we
apply
policies
at
the
ingress
level,
and
so,
when
you
say
from
an
egress
perspective,
one
thing
can't
talk
to
another
thing
like
there's
some
kind
of
weird
asymmetry
you
hit
there,
but
that
would
be
fixed
by
these
cluster
nets
that
might
be
fixable
to
some
extent
by
the
cluster
scoped
policies.
I
don't
know
it
seems
like
after
you
have
cluster
scoped
policies,
though
you
could.
C
C
Well,
those
are
the
two
options,
so
that's
one
option,
other
people.
What
other
approaches
are
there?
Because
I
have
a
feeling
you
know
this
whole
thing
of
building
a
thing
that
generates
network
policies
is
not.
That
is
not
the
only
way
to
design
an
api.
So
what
are
the
other
approaches?
People
want
to
take.
I
Before
we
jump
into
that,
I
actually
have
some
questions
about
the
v2
policies
we're
talking
about
here,
because
if
we
wanted
to
do
a
v2
further
for
the
new
netpoll,
what
do
you
think?
What
do
you
guys
think
you
know
the
is
the
problem
I
I
shouldn't
say
problem,
but
what's
something
that
can
be
improved
from
the
current
network
policies?
I
Is
this
something
that
we
cannot
express
by
now
or
it's
just
the
policy
itself
is
confusing
a
lot
of
people
so
that
we
need
an
easier
way
or
more
explicit
way
to
write
a
policy
for
v2.
What
are
the
things
we're
trying
to
solve
here?
I
guess
is
my
question
so
based
on
you
know
the
based
on
the
answer
to
that
question:
we're
probably
going
to
be
more
comfortable
going
from
one
option
to
another.
I
think
it's
unifying.
C
G
Yeah
sorry
go
ahead.
Go
ahead.
I
have
some
pretty
concrete
ideas
about
things
that
I
would
like
to
see
in
a
certain
way,
basically
comes
down
to
like
orthogonality
and
how
like
there's
all
these
features
in
there,
but
they
they
don't
really
work
too
well
with
each
other
and
there's
all
kinds
of
corner
cases
and
stuff
like
that
and
things
that
you
can
use
in
some
context,
but
on
other
contexts,
and
it
makes
it
you
know
really
hard
to
do
things
even
though,
like
the
raw
functionality,
like
kind
of
should
be
there.
G
So
I
don't
know
like
where
is
a
good
place
for
me
to
like
capture
those
specific
things
that
I'm
thinking
about,
but
with
the
stuff
that
I
did
on
cyclones
with,
like
parsing
network
calls,
you
know
like
I
had
to
deal
with
all
these
things
and
it
was
really
hard
and
at
the
end
of
the
day,
you're
just
like
wow.
It
definitely
shouldn't
be
that
hard,
because
there's
not
that
much
stuff
there,
but
because
of
all
of
those
exceptions
and
exceptions
on
exceptions,
it
really
obscures
what
I
think
is
the
core
of.
I
So
so,
from
what
I'm
hearing,
so
there
are
two
two
things
here:
if
first
one
is
that
the
syntax
is
a
bit
obscure
as
a
recorder
is
putting
here
and
as
matt
has
mentioned,
and
the
second
thing
is,
you
know
when
we
were
trying
to
evolve
the
api
around.
You
know
the
new
things
we're
proposing,
such
as
service
lectures
and
no
selectors.
We
wanted
to
have
a
way
to
since
we're
proposing
those
anyways
right.
I
We
didn't
want
to
sort
of
like
disrupt,
disrupt
the
current
struts
or
having
to
deal
with
backward
compatibility,
those
kind
of
things,
so
we
probably
wanted
to
propose
a
new
set
of
api
together.
It
does
that
capture
this
correctly.
C
C
Before
we
like
dig
into
like
one
of
those
weird
like
design
sessions,
where
we're
you
know
what
I
mean
like
yes
think
outside
the
box
as
much
as
possible,
because
right
now
we're
in
this
rut
of
like
trying
to
build
a
better
api
on
top
of
an
api.
That's
fundamentally
not
what
we
want
yeah,
so
I
think
we
should.
We
need
to
take
people
who've
been
around
a
long
time
doing
this
stuff,
and
then
we
need
to
take
some
people.
C
A
C
A
I
I
I
guess
like
leaving
a
little
bit
the
subject
but
but
but
justifying
this
we've
been
doing
this
like
for,
I
guess
one
year
right.
We've
started
this
on
on
the
beginning
of
the
pandemics,
I
remember
when
jay
called
the
the
the
group-
I
guess
was
in
march
or
april,
and
we've
cited
to
to
to
take
a
look
into
the
user
stories
and
what
are
the
top,
the
top
user
stories
that
we
get?
A
How
can
we
improve
more
and
more
the
the
vieble
network
policy-
and
this
was
the
first
proposal
that
that
I
did
with
andrew
and
other
folks
like
okay,
let's
start
running
in
certain
circles
and
and
see,
how
can
we
improve
this
right
with
what
we
have
and
I
guess
we
are
hitting
the
limit
of?
How
can
we
improve
this
without
breaking
anything?
J
A
Guess
that
everything
that
that
everyone
said
here
is
correct,
but
we
we
are
mostly
hitting
the
the
limits
of
the
of
the
extension
of
the
current
api
and,
like
you
know,
about
the
antria,
and
I
know
about
cedium
and
and
and
calico
and
every
every
other
crd
from
those
from
those
providers.
They
have
specific
things
that
we
cannot
add
anymore
in
the
network
policy
if
you
want
object
because
it
doesn't
support
this
kind
of
extension
right.
C
So
maybe
we
should
just
throw
this
up
in
the
air
and
say:
look
nobody's
proposed
anything
yet
the
first
person
to
propose
something
that
covers
80
or
70
of
what
people
do
with
network
policies
will
be
the
person
who
who
gets
the
gold
star
for
the
day
right
ricardo
like
if
somebody
wants
to
propose
something
crazy
and
stupid
that
might
work.
This
is
a
might
be
an
interesting
time,
the
next
few
weeks
to
do
that.
G
C
Anyway,
I
mean
you
know,
just
I
guess
just
show
up
to
one
of
the
one
of
these
and
add
it
to
the
agenda.
Let
me
or
anyone
else
ricardo,
any
anyone
in
here,
just
socialize
it
on
slack-
and
you
know,
that's
like
that's
the
way
to
start
right,
propose
an
api
change
or
a
crd
or
a
prototype,
or
anything
really
because
nobody's
really
proposed
much
yet
right.
Exactly.
A
It's
just
like:
how
can
we
do?
How
can
we
do
this
better
right
now,
as
we
cannot,
we
cannot
move
forward
a
lot
of
a
lot
with
v1
network
policy.
How?
What?
What
can
I
guess,
like
the
the
best
analogy,
is
that
we
wanna
we
wanna
destroy
a
house
to
build
a
building
right,
so
we
are
not.
We
are
just
going
to
use
the
the
land
and
nothing
nothing
else.
So
anything.
J
A
I
A
I
Yeah,
so
on
that
front
I
actually
had
a
question
for
for
satish,
because
I
remember
you
know
a
couple
of
meetings
ago.
We
are
the
design
for
our
proposal
for
the
service
lecture.
So
I
wonder
if
you
know,
because
they
we
we
hit
a
lot
of
like
obstacles
when
trying
to
add
some
new
stuff
into
into
the
v1
api.
I
So
I
wonder
if
you
know,
if
we
sort
of
like
getting
all
those
new
things
that
we
wanted
to
get
together,
can
that
be
like,
like
the
foundation
for
a
new
v2
api?
Or
you
guys?
Don't
you
guys?
Don't
think?
That's
a
that's
a
good
idea.
I
think.
F
Yeah,
I
think
yeah,
I
agree
yeah,
so
part
of
the
reason
is
like
so
we
have
service
selectors
and
I
think
the
service
account
selectors
and
probably
something
like
endpoint
selector.
We
haven't
seen
a
lot
of
use
cases
but
probably
like.
We
will
eventually
end
up
having
something
like
that.
So
I
mean
like
we.
Currently,
the
net
policy
v1
has
got
selected
as
a
mandatory
field,
so
eventually
we're
gonna
move
away
from
that.
I
think
the
only
way
is
like
having
to
move
to
different
api
together.
I
think
so.
F
That's
for
the
targets,
like
I
mean
like
if
you're
trying
to
apply
a
policy
at
a
particular
set
of
policies
like
some
set
of
pods
or
like
endpoints
as
services
in
future.
That's
the
the
thing
that
we're
looking
at
so
other
cases
like.
If
we
are
using
as
a
peer,
then
we
can
actually
get
away
with
v1
itself
like
adding
a
field
and
a
spec.
F
So
now
spack
has
like
port
selector,
ingress
and
egress,
so
you
can
add
ingress
to
service
or
regress
to
service
or
ingress
to
service
account
request
to
service
account
and
not
break
the
like.
I
mean
not
fail
open
with
the
current
api,
but,
like
I
said
it
makes
it
very
easy
to
move
to
a
new
v2
api
where
we
can
actually
solve
everything,
so
it
I
mean
it
definitely
makes
sense
to
drive
v2
agenda
based
on
the
the
new
selectors
that
we
are
actually
trying
to.
You
know
introduce.
H
C
Thing
which
is
a
graphical
representation
of
policies
or
a
node-based
or
a
hierarchical
type,
way
of
defining
policies,
and
then
we've
got
this
other
concept
that
the
people
have
thrown
around
of
status,
which
which
is
kind
of
an
interesting
thing,
I
think
also,
even
though
it's
not
backwards
incompatible
with
v1.
It's
definitely
a
thing
that
isn't
gonna
happen
overnight,
like
we've
got
those
three
kind
of
almost
orthogonal
things
right.
C
F
So
I
guess
the
other
thing
is
like
logging
like
whether
they
enable
logging
for
a
particular
network
or
at
a
cluster
level,
things
like
that.
So
that
could
be
one
thing:
that's
happened.
A
D
C
J
So
I
don't
know
how
they
got
populated
on
the
the
network
docs
page,
but
there
is
a
list
of
that
says
what
you
can't
do
with
never
policies,
at
least
not
yet,
and
a
lot
of
what
we're
talking
about
is
in
this
list.
There's
a
couple
other
items
there
as
well,
so
that
might
also
be
a
place
to
look.
I'm
not
sure
where
all
that
info
was
gathered
from
sourced
together,
but.
C
Yeah
that
was
me
I
I
updated
the
page
to
have
all
those
views,
so
we
collected
a
bunch
of
user
stories
like
like
six
months
ago,
and
so
we
didn't
know
what
the
hell
to
do
with
all
those
stories.
So
I
just
made.
I
made
a
doc's
pr
to
put
them
all
on
the
docs
page,
but
yeah
you're
right
like
that,
would
be
another
like
place
to
start.
I
guess
so
I
mean
I
think.
We've
got
like
a
few
people
here
that
are
volunteering,
some
thoughts
so
matt.
C
If
you
want
to
distill
down
what
you
think
could
be
done
for
like
a
hierarchical
graph
thing
and
satish
and
other
folks
want
to
do
this
stuff
around
statuses
and
logging
and
new
types,
you
know
yeah
sounds
good,
I
feel
like
we
could
probably
start
to
sort
of
starting
from
those
high
level
from
a
high
level.
We
could
sort
of
start
to
think
about
like
what
we
could
do.
C
A
But
the
approach
from
yen
from
me
is
the
the
most
correct
like
what
are
we
trying
to
solve
so
instead
of
getting
all
the
user
stories
and
say:
okay,
we
weren't
now
logging,
we
went
now
blah.
We
want
to
know
even
the
actions
we
are
trying
to
solve
the
problem,
that
we
cannot
expand
any
more
v1
network
policy
at
all
and
it
had
the
problem
of
the
full
deny.
So
this
is
a
good
approach
for
me.