►
From YouTube: Network Policy API Meeting 20210222
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
And
oh
hold
on
yeah,
so
we
have
three
items
in
the
agenda.
The
first
one
is
layer,
seven
policies
that
wasn't
a
best
issue
from
from
thomas
graf
and
we
have
added
that
again.
I
can't
remember
if
it
was
me
or
jay,
then
we
can
move
forward
to
make
some
issue
triage
in
the
network
policy
issues
and
then
ask
it
some
time
to
to
make
some
other
other
additions
about
cyclonus
but
yeah.
A
B
B
The
best
thing
to
do
is
to
just
start
triaging
these
every
week
in
the
policy
subgroup,
because
I
feel,
like
you
know,
in
addition
to
breaking
things
and
creating
new
ideas
and
apis
stuff,
we
should
be
probably
doing
carrying
our
weight
in
terms
of
making
sure
that
the
broader
sig
does
not
have
any
extra
clerical
work
to
do
with
regard
to
like
stupid
issues
that
we
forgot
to
not
stupid,
but
you
know
like
issues
that
are
like
easy
for
us
to
fix,
but
just
requires
a
little
bit
of
process
right.
B
C
D
A
B
Oh,
that's
a
tricky
one,
because
those
serve
ports
are
what
is
it
there's
like
some
secret
thing
right.
It's
like
a
like
named
ports,
have
a
secret
thing
in
them
where,
if
you
do
serve
80,
then
that
agn
host
container
like
serves
on
port
80
or
something
I
forgot
right.
It's
like
a
special
named
port.
E
A
Okay,
so
the
next
one,
oh
okay,
this
is
these
already
have.
A
a
request
was
one
that
the
team
asked
us
to
improving
the
network
policy
test.
I'm.
B
A
A
B
A
B
B
B
Yeah
yeah,
I
mean
that's,
I'm
I
mean
I've
got
all
that
work
and
I
just
need
to
clean
up
the
pr
okay.
So
we
can
skip
this
one
right,
yeah
that
or
I
know
a
meme
is
here
I
mean:
do
you
want
to
finish
that
97751?
If
not,
I
can
I
it's
totally
optional.
It's
an
easy
pr.
It's
just
cleaning
that
code
up,
but
I
I'm
totally
happy
to
get
another
pr
cleaned
up
today,
because
I
have
another
one
this
week,
but
if
you're
totally
free
I'm
happy
to,
let
you
do
it.
B
B
D
B
A
F
Yeah,
the
only
missing
part
is
this
one
that
j
just
just
raised
the
windows
part.
Oh
great,
so
we.
F
A
B
A
B
A
A
A
B
A
G
A
A
B
B
Are
you
babysitting
that.
A
A
I
Yeah
pro
recorder
can
take
it.
Okay,.
I
A
A
Thank
you,
okay,
so
update
network
policy,
each
we
test
for
v1
api
semantics.
Do
we
have
something
else
here
jay?
This
is
new.
Oh
gosh!
This
is
old,
actually
yeah,
it's
a
four
years
old
and
you
are
assigned
to
this
one.
I
bet
we
can.
A
B
B
F
I
A
A
Yeah
and
support
port
ranges
and
services.
This
is
actually
not
related
to
network
policy,
but
they
they
have.
They
say
that.
Okay,
you
already
supported
on
network
policy,
so
why
not
supporting
these
on
services?
I
was
going
to
take
a
look
into
that,
but
there
is
like
a
bunch
of
discussion
about
this.
B
Yes,
docker
links
thing
and
I
made
a
pr
to
clean
it
up
and
then
and
then
I
think
they
said
that
the
pr
we
shouldn't
do
the
stuff
in
the
pr,
even
though
it
was
kind
of
the
right
thing
to
do
so,
then
I
think
I
had
like
a
long
comment
I
think,
to
explain,
but
I
think
I
don't
think
we
can
do
this
in
the
end
right.
Can
we,
I
don't.
A
Know
I
think
we
we
should
probably
like
raise
this
one
in
the
next
cig
network
meeting
like
five
minutes
folks,
what
what
we
want
to
do
are
we
going
to
move
forward
with
this
one?
Otherwise,
we
should
like
close,
because
we
have
a
lot
of
a
lot
of
things
to
figure
out
about
this
weapon
right
all
right.
This.
A
A
A
I
guess
that
this
filter
is
not
working,
jay,
okay,
we
can.
We
can
do
that
later.
So
the
next
item
in
the
agenda
is
about
this
proposal.
A
This
was
raised
by
by
thomas
graf
from
from
from
isovalent
from
the
the
serium,
because
actually
they
do
support
having
layer,
seven
things
inside
their
natural
policy,
and
I
guess
that
kaliko
nowadays
also
support
these
with
a
crd,
so
the
discussion,
the
main
discussion
about
this
is
if
we
could
have
something
inside
the
network
policy
object
that
could
support
not
only
filtering
by
ips
and
ports
and
and
like
ip
selector,
based
on
on
on
bot
labels,
but
also
something
like
okay.
I
don't
want
to
allow.
A
I
don't
want
to
allow
my
my
users
to
make
a
get
request
against
my
my
services.
Only
a
post
request
or
like
I
don't
want
them
to
post
messages
in
this
kafka
topic,
but
only
on
the
other
one
and
yeah.
So
this
should
probably
have
became
a
a
kept
or
something
like
that.
But
I
guess
there
is
some
some
more
discussion
about
this,
because
thomas
is
proposing
here
like
layer,
seven
part
rules
and,
and
something
like
that
in
the
inside,
the
the
natural
policy.
A
I
A
So
I
I
will
not
pass
through
all
all
of
the
comments.
I
I
recommend
you
folks
to
read
this,
but
the
last
one
that
we
we
got
was
me
asking
about
if
we
should
reopen
these
and
and
make
this
viable
and
antonio
actually
asked
if
this
is
something
most
more
related
to
the
service
api
group
or
with
the
or
within
the
network
policy
or
like
the
policy
api
group
right.
So
I
want
to
listen
to
you
folks
about
your
opinions
about
that.
The
service
api
folks
they
didn't
answer.
A
A
This
wouldn't
this
wouldn't
like
work,
or
this
wouldn't
be
part
of
the
service
api
thing
and
also
I
wanna.
I
wanna
understand
you
about
the
effort
of
this
one.
My
my
thought
is
that
this
needs
to
be
like
a
different,
a
complete
different
object,
separated
from
the
electoral
policy.
B
B
Somebody
brought
him
up,
I
felt
like
so
I
feel,
like
you
know
it's
one
of
those
weird
ones
that
it's
like.
Well,
we
could
you
know
ricardo.
We
could
collect
feedback
all
day,
but
it's
like
does
somebody
care
enough
to
actually
do
the
work
of
actually
solving
this
problem,
because
it's
just
going
to
be
a
lot
of
a
lot
of
work
to
figure
out
some
way
to
do
this
and
there's
a
50
chance
that,
even
if
you
do
all
that
work,
it's
not
going
to
be
accepted.
B
A
I
I
I
I
guess
I
I
have
just
reopened
the
issue
because
thomas
was
complaining
about
this
in
in
twitter
and
like
yeah,
one
was
taking
a
look
into
that,
but
I
don't
think
thomas
came
to
the
last
meeting.
We
asked
yeah.
No,
I
I
I
can't
remember
if
if
it
was
mj
to
be
honest,
that
added
these
to
the
to
the
meeting
notes
or
if
it
was
andrew
or
if
it
was
like
vinai.
You
know
I
know
it's
here,
but
I
don't.
B
A
B
B
I
don't
think
it's
worth
having
an
issue
open
about
it,
but
that's
just
my
opinion
and
I
mean,
but
I'm
I'm
totally
open
to
keeping
it
open
too.
It's
just,
I
think,
we're
just
gonna
keep
getting
sort
of
we're
going
to
keep
getting
new
opinions
that
are
kind
of
the
same
really.
I
J
I
think
when
I
brought
it
up
a
couple
of
weeks
ago,
I
mentioned
that,
if
I
you
know,
I'd
probably
like
to
work
on
this,
but
towards
the
later
half
of
the
year.
So
until
then,
if
somebody
picks
it
up
great
I'll
help
them.
If
not,
then
I'll,
maybe
six
months
down
the
line.
B
A
E
E
So
the
reason
why
I
wanted
to
show
everybody
that
cyclone's
stuff
was
because
I
think,
there's
a
couple
of
ways
that
it
could
be
applied
to.
You
know
the
network
policy
api
stuff
that
we're
looking
at
building.
E
You
know
maybe-
or
maybe
it's
a
really
cheap
way
to
build
something
you
can
actually
like
get
your
hands
on,
and
you
know,
and
and
generate
some
data
with
that
shows
what
network
policy
additions
to
the
api
would
do
you
know
to
help
you
kind
of
like
see
the
effects
of
of
any
any
changes
that
you're
thinking
about
to
see
what
those
would
look
like
without
actually
having
to
have
somebody
go
into
a
cni
and
implement
those
changes
or
something
like
that
so
kind
of
that
modeling
aspect
and
then
also
you
know,
being
able
to
to
put
like
concrete
data
in
front
of
other
people
and
say
you
know
like
this:
is
the
change
that
I'm
proposing
you
know
like
this
is
the
effect
that
we're
going
to
see.
E
So,
if
anybody
is,
you
know,
is
kind
of
interested
in
that
aspect
of
cyclonus,
you
know
I'd
be
happy
to
collaborate
with
anybody
on
that
kind
of
stuff.
You
know
and
see
how
we
can,
how
we
can
make
it
useful
for
you,
but
yeah.
There's.
I
B
J
I
think,
from
what
I
saw
last
week,
psychologist
has
a
few
more
things.
Then
what
we
we
have,
I
think
in
our
tool.
We
have
a
explainer
or
a
career
tool
which
shows
some
policies
appended
to
the
or
applied
onto
the
power
endpoints,
but
I
think
cyclones
does
a
little
more
than
that
and
I,
I
believe,
mac
you're
already
trying
to
do
something
with
it.
J
E
B
B
There's
a
lot
of
ecosystem
and
then
the
question
is:
where
does
it
intersect?
With
what
we're
doing?
I
guess
you
know,
there's
always
been
this
talk
of
building
a
command
line,
client
for
network
policies,
and
I
think
it
became
more
relevant
last
time
in
sig
network,
because
people
were
talking
about
what
were
we
talking
about
that
made
this
come
up.
B
J
So
I
think,
when
we
introduced
cluster
network
policy
on
top
of
kubernetes
network
policies,
the
combination
of
that
a
tool
to
help
explain
the
the
interaction
and
the
overall
policy
that
sort
of
that
those
are
applied
on
the
pod
will
definitely
be.
You
know
helpful.
I
think
that's
how
this
conversation
came
about
in
upstream.
B
Of
the
we
should
work
that
tool
as
one
of
the
potential
things
in
the
kep
when
we
merge
it
as
provisional
right
like
that,
we
would
build
an
upstream
tool
as
part
of
the
cap
that
could
be
used
to
calculate
the
net
policy
and
that
if
that
tool
was
considered
useful,
it
could
be
a
part
of
somehow
integrated
into
kubernetes
itself.
Do
you
think
that
would
work?
You
think
that
would
go
over
well.
J
I
think
it
can
be
independent,
it
can
be.
You
know,
started
off
for
kubernetes
network
policy
which
already
exists
today,
so
that
way
that
particular
cap
doesn't,
you
know,
have
to
wait
for
customer
to
policy
which
might
be
a
lot
of
you
know
back
and
forth
between
people.
So
this
can
be
an
independent
kept
in
itself
and
then
maybe
we
can
find
a
home
for
it
yeah
within
the
kubernetes
repos.
Just
to
you
know,
basically
what
jay
suggested.
J
B
Well,
no,
but
the
question
is:
is
it
something
that
we
want
people
to
be
able
to
vendor
and
use
as
a
library
or
is
it
something
that
should
just
be
a
command
line
tool?
You
know
what
I
mean,
because
the
way
we
pitch
it
as
a
kubernetes
sigs
repo
is
different
right
like
is
it
a
end
user
tool
or
is
it
a
library
or
is
it
both.
B
Yeah,
okay,
so
I
guess
that
sounds
like
a.
It
sounds
like
a
potential
end
point
matt
like
do
you
feel
like
that's
a
good
direction
to
go
in.
E
B
E
B
B
Yeah
I
mean
I
just
want
to
I've,
never
really
proposed.
I've
never
successfully
proposed
a
kubernetes
sigs
project
before
so
I
don't
really
know
what
the
bar
is.
I
just
want
to
make
sure
that
when
we
propose
it,
we
have
a
really
whatever
the
best
possible
story
we
could
possibly
have
or
somewhere
close
to.
That
is
what
we
propose
and
not
hey.
E
B
E
B
B
All
right,
the
the
fundamental
thing
when
I
think
of
cyclonus
in
my
head,
I
think
this
is
something
that
helps
me
reconcile
connectivity
between,
like
between
things
when
there's
more
than
one
network
policy
at
play
right.
This
is
the
thing
that
helps
me
reconcile
that
so.
E
For
it's
just
a
bunch
of
different
applications
of
that,
whether
you're
running
a
bunch
of
tests
against
andrea
and
psyllium,
which
is
what
it's
doing
now
or
you're
explaining
your
network
policies.
It
does
all
come
from
that.
One
idea
that
you
just
mentioned
like
taking
those
network
policies
and
resolving
them
into
something
that
you
can
apply
to
other
stuff.
E
D
B
Cool,
do
you
have
people
working
on
it
with
you?
Do
you
need
help
working
on
it,
or
is
it
still
something
that
you're.
E
Mostly
just
doing
by
yourself
or
what
yeah
doing
it
myself
right
now,
I
don't.
I
don't
need
help
but
like
if
anybody
wants
to
definitely
definitely
open
to
that,
but
yeah
like
what
yeah
like.
I
A
I
B
A
J
So
this
particular
we
have
been
discussing
within
our
cluster
network
policy
team
to
include
this
as
part
of
the
transactional
policy
proposal.
I
think
when
I
and
satish
were
on
the
call.
We're
also
planning
to
you
know,
come
up
with
some
sort
of
a
proposal
around
this
and
see
whether
we
can
include
this
as
part
of
cluster
network
policy.
J
If
not,
if
we
think
that
it
is
becoming
a
big
factor
and
something
that
will
be
distracting
from
the
you
know,
the
original
scope,
then,
maybe
we'll
we'll,
you
know
spin
it
out
as
a
separate
cap
and-
and
I
think
it
makes
more
sense
for
cluster
scope
policies,
because
you
know
we
have
deny
rules
or
we
at
least
plan,
to
bring
up
deny
rules
and
using
logging
policy
for
kubernetes
network
policy
is
probably
not
straightforward,
because
I
think
dan
winston
brings
up
important
use
cases
here
or
important
points
here
why
it
is
not
suitable
for
kubernetes
policy,
but
it
certainly
is,
for
the
administrative
focus
focus
policies.
J
So
it's
something
that
we
plan
to
look
at
yeah.
If
not,
then
I
think
we'll
we'll
open
it
up
as
a
separate
clip.
If
it
becomes
too
you
know
complicated
or
complex
by
itself.
We
don't
want
it
to.
You
know,
take
the
attention
away
from
the
cluster
network
policy.
D
Yeah,
I
think
I
agree
with
what
she
said
that
I
think,
having
I
think.
First
and
foremost,
I
think
it
makes
sense
to
like
combine
the
logging
bits
to
the
network
policy.
If
you
can-
and
I
think
that
will
keep
it
unified
in
one
place
and
then
there's
only
one
controller,
because
if
you
keep
it,
as
the
other
option,
is
to
keep
them
like
a
policy
login
in
a
separate
cr,
and
that
would
make
it
like.
You
know.
D
Now
you've
got
two
places
to
like
an
update:
they
can
watch
your
intent
is
in
terms
of
logging.
So
I
I'm
for,
like
you
know,
adding
a
login
policy
to
network
now
the
issue
about
denies
and
because
there's
no
deny
rule
for
network
policy
right.
So
when
a
connection
gets
rejected,
then
what
do
we
attribute?
So
I
think
what
we
can
do
is.
D
D
J
Yeah
so,
instead
of
looking
at
it,
you
know
from
a
single
from
a
simple
boolean
field.
We
are
exploring
like
a
policy
kind
of
an
option,
a
logging
policy
kind
of
a
field
which
can
be
a
little
more
complex.
So
I
think
that's
the
general
direction.
D
Yeah,
so
for
all
the
allow
rules,
we
can
not
only
capture
the
flow
that
is
being
admitted,
but
we
can
also
attribute
that
to
the
policy
right
like
hey
this
you're
allowed
because
of
this
policy,
but
for
deny,
I
think
that
becomes
a
challenge,
because
you
don't
have
a
deny
policy
anything
that
is
not
part
of
the
allowed
rules.
Guess
tonight.
D
So,
but
at
least
what
we
can
do
is
we
can
we
can
capture
the
five
triples
for
the
connections
so
that,
if
you're
logging
it
that
at
least
gives
us
the
customers,
the
raw
data
that
they
can
parse
through
using
their
own
internal
tools
to
see
who
is
trying
to
access?
This
is
unauthorized.
Why
is
it
coming
from?
And
things
like
that?
A
D
Yeah,
so
I'm
I'm
looking
at
the
comments
that
I
think
danmanship
is
saying,
so
I'm
not
exactly
sure
what
is
maybe
I'm
not
I'm
a
little
slow
today,
I'm
not
understanding
what
his
concerns
are
in
the
next.
The
second.
A
J
I
think
what
then
was
trying
to
say
was
that
most
users
would
want
a
cluster-wide
option
to
either
allow
either
log
all
the
packets
or
do
not
log
all
the
packets,
and
he
did
not
see
a
good
reason
why
it
should
be
done
per
policy
or
per
rule.
I
think
that's
where
you
know
I
differed
from
dan's
viewpoint.
Yeah.
D
Yeah,
I
think
I
agree
with
because
sometimes
when
you
have
lots
of
parts
and
nodes
in
a
cluster,
you
may
not
be
running
privileged
workloads
in
all
the
parts.
So
you
are
interested
only
in
monitoring
some
secure
workload
that
you're
you're
trying
to
monitor,
who
is
accessing
and
who's
if
it's
under
denial
of
service
attack
and
remember,
logging
is
also
going
to
cost.
D
It
has
a
storage
cost,
it
has
a
cpu
cost
it
at
least
an
hour
you've
seen
like
up
to
20
30
additional
cpu
usage
attributable
to
logging
under
sustained
loads,
so
there
is
some
cost
associated
with
it.
So
now,
if
you
use
a
hammer
and
say
it's
across
a
cluster,
it
may
be.
D
When
we
have
that
ability
to
like
you
know,
use
a
very
targeted
logging
across
only
certain
parts
based
on
some
selectors,
then
I
think
it
could
be
advantages
to
customers
so
that
they
don't
have
to
pay
in
terms
of
cpu
memory
and
storage.
I
So,
just
what,
when
I
was
saying,
I
think
so,
like
probably
a
different,
the
tangential
to
what
the
discussion
is
happening
on
right.
So
I
I
think
we
do
want
to
add
a
description
right
rule
description
for
like
in
data
policy,
so
that
might
be
also
related,
because
I
mean
not
just
the
the
policy
that
is
allowing
a
particular
traffic,
but
the
rule
that
is
allowing
this
specific
traffic.
The
traffic
is
also
is
useful
right.
I
So
probably
I
know
that,
like
abhishek
mentioned,
there's
some
work
on
like
adding
unique
identifier
for
a
specific
rule
in
the
policy
so
probably
like.
We
should
take
that
into
consideration
as
well,
because
when
we
provide
the
lots
we
might
as
well
want
to
provide
the
unique
identifier
that
allowed
our
delight
for
cluster
courses.
J
Yeah,
that's
another
one
that
we're
looking
at
two
is
to.
You
know:
have
the
ability
to
uniquely
identify
a
rule
within
a
policy
because
for
you
know
for
as
that
is
mentioned,
for
logging
and
maybe
for
statistics
and
monitoring
and
other
purposes,
you
want
to
attribute
certain
stats
to
a
rule,
and
today
it's
not
possible
within
the
kubernetes
network
policy.
J
So
we
we
would.
We
would
want
to
introduce,
like
rule
identifiers
within
kubernetes
network
policy
and
certainly
for
cluster
network
policy.
So
I
think
that's
another
effort
that
we
will
try
to.
J
A
J
Was
like
in
the
idea,
I
think
we
should
keep
this
open
so
that
we
have
a
because
if
we
want
to
open
up
a
cap,
we
have
this
issue
which
we
can
reference
and
and
then
build
a
cap
on
around
it.
I
Okay,
yeah,
so
just
to
add
one
more
thing,
so
is
it?
Is
it
possible
that
so
there's
this
there's
this
discussion
going
on
right,
whether
we
want
to
enable
cluster
ride
logging
or
per
network
policy
based
logging?
So
would
it
make
sense
to
have
some
kind
of
config
map
that
says
whether
we
want
to
enable
like
throughout
the
cluster
like?
Should
we
say
that
like
decide,
based
on
the
network
policy
options,
those.
J
Those
cluster
those
config
options,
most
cni
providers
do
provide-
or
at
least
they
can
provide,
so
we
don't
need
a
standard
option
within
from
kubernetes.
J
But
certainly
if
we
introduce
the
this
field
and
network
policy
and
trust
network
policy,
then
users
can-
and
I
think
it
should
then
override
whatever
is
the
cluster
config
option,
because
as
a
user
and
if
I'm
specifically
writing
a
policy
with
logging
enabled,
I
would
want
to
see
the
traffic
regardless
of
what
the
cluster
option.
Config
option
specifies.
I
I
So
I
mean
like
if
the
option
is
like
in
the
delegate
mode
like
probably
like
at
that
point
like,
if
you
create
a
policy
that
has
logic
enabled
so
it
will
be
delegated
to
that
particular
one.
Otherwise,
it
will
be
decided
at
the
cluster
level,
whether
we're
gonna
enable
or
like
disagree
yeah.
Maybe
that's
something
for
like
discussing
in
more
detail
but
yeah.
So
that's
just
wanted
to
see
if
that
actually
addresses
like
the
like
different
perspectives
like
we
are
actually
bringing
in
here.
J
Yeah,
I
think
dan
was
kind
of
mentioning
that
you
know
if
you
have
like
calico
or
andrea
or
psyllium
they
they
do
provide
a
config
option.
Wherein
you
know
we
don't
need
any
api
changes.
J
If
the
user
wants
to
enable
logging
at
the
cluster
level,
they
can
just
enable
that
option
in
their
providers
or
in
their
configma,
and
then
you
know,
the
different
cni
providers
will
will
perform
the
logging,
and
I
think
that's
what
dan
was
mentioning,
and
you
know
this
is
what
can
be,
is
being
done.
So
you
don't
need
to
change
the
api
for
that.
But
while
I
think
when
I
also
mention
the
reasons
why
we
need
to
have
individual
policy
level,
logging.
I
A
A
A
A
B
E
A
I
So
I
was
actually
yeah,
so
it's
not
yeah,
but
I
mean
it's
actually
a
field
of
spec,
so
instead
of
egress,
because
we're
going
to
have
like
egress
to
service
or
ingress
to
service.
A
Yeah
english
service
yeah,
that
was
outside
the
spec,
but
I
am
wondering
if
this
is
something
that
we
want
to
change
from
v1
to
v2,
because
I,
my
guess
is
like
this
is
important
at
least
like
for
a
security
from
a
security
perspective.
This
is
this
is
quite
important
so,
but
I
don't
think
we
should
like
be
be
worried
about
like
increasing
the
version
of
the
natural
policy.
A
G
A
A
My
question
is
that
like
how?
How
viable
is
that
we
do
something
like
this
and
say?
Okay
now,
a
network
policy
has
spec,
but
it
also
have
a
policy
spec
and
the
policy
spec
behaves
different
from
the
spec,
because
this
is
something
spec
v2
or
something
like
that
increase
the
the
the
version
inside
this
spec,
instead
of
like
increasing
the
version
of
the
network
policy.
A
B
I
Sorry,
so
if
there
is
no
english
or
egress
defined,
so
we
will,
it
will
fail
close
right.
I
mean.
I
I
Yeah,
if
we
have
both
like
I
mean
that
is
the
expectation
right.
We're
gonna
support
the
backward
compatibility
anyway.
So
so,
if
ingress
is
defined
to
allow
something,
then.
B
I
A
So
I
guess
we
we
are.
We
are
almost
all
of
time
out
of
time,
but
I
I
wish
we
could
like
discuss
more
about
this
one,
probably
in
in
the
next
meeting
like
how
can
we
propose
an
evolution
of
this
spec
from
the
network
policy
without
increasing
the
networking,
the
network
policy
or
like
if
this
is
something
desired,
because
we
we
are
not
going
to
decide
this
this
thing
by
ourselves
other
than
bringing
this
to
a
sig
network
folks,
but
I
guess
this
is
like
we.
A
I
Yeah,
I
agree
like
I
mean
at
least
one
use
case
I
can
I
can
see
here
is
like
so
right
now.
Part
selector
is
a
like
mandatory
field
and
then
like
we
can
only
select
parts
and
pods
but
like
if
we
were
to
support
other
resources,
for
example
service,
selector
and
stuff,
like
that.
So
probably
we
might
need
a
different
spec
yeah.
I
That
way,
like
I
mean
like,
we
don't
have
to
break
the
backup
compatibility
and
make
the
parts
erector
optional,
because
it
was
actually
mandatory
in
the
current
spec
and
we
would
want
to
make
it
optional
because
we
have
both
pod
and
selectors.
A
We
can't
we
can
also
discuss
about
this
like
in
the
next.
The
next
meeting,
I'm
doing
something
like
v2
versus
news
network
respect
sounds
good,
sure,
okay,
so
we
are
out
of
time
folks,
I'm
gonna
hit
the
stop
button
here
and
yeah.
Thank
you,
everybody
for
coming
and
see
you
next
week
next
monday,
bye
folks.