►
From YouTube: Network Policy API Bi-Weekly Meeting for 20210427
Description
Network Policy API Bi-Weekly Meeting for 20210427
A
A
This
is
a
kubernetes
community
meeting,
so
we
have
a
code
of
conduct
being
applied
here
and
we
ask
you
how
to
comply
with
the
code
of
conduct,
which
is
basically
be
accident
with
each
other,
don't
be
a
jerk
with
no
one,
and
any
violation
should
be
reported
to
any
of
these
signature
chairs,
which
you
can
find
in
the
sig
network
charter
at
github,
or
you
can
report
directly
to
me
if
your
complaint
is
not
about
me,
okay
yeah,
so
this
meeting
is
actually
a
kickoff
about
about
ingress
and
ginex
and
what
we
should
do
with
it
right.
A
So
I
guess
everyone
knows
that
increasing
gynex
is
one
of
the
most
or
probably
the
most
used
ingress
controller
project
around
there
and
last
year
alejandro
stepped
down
from
the
maintenance
of
this
this
project
right.
So
he
did
a
really
amazing
work
during
that
time,
but
because
of
of
some
other
reasons
he
asked
me
to
step
down
and
as
a
main,
the
main
maintainer
from
from
ingressing
jynx.
A
He
was
looking
for
someone
to
keep
the
project
ongoing.
This
was
discussed
in
in
some
of
other
sig
network
meetings,
and
actually
this
is
being
discussed,
I
guess,
by
by
the
the
technical
oversea
commitment
from
from
kubernetes,
but
on
this
I
guess
the
steering
committee,
but
anyway
I
was
talking
with
other
folks
like
elvin
and
bowie.
How
can
we
at
least
keep
the
maintenance
of
this
project
by
its
importance,
and
then
I
have
scheduled
this
meeting
so
we
can
discuss
who
wants
to
help
owning
this?
A
So,
first
of
all,
instead
of
going
directly
to
the
to
the
meeting
items,
I
would
like
to
to
ask
you
to
invite
you
to
present
yourself
and
if
you
want,
if
you
don't
want
it's,
it's
okay
as
well
and
say:
who
are
you
what
what
are
your
expectations
with
english
in
gynex?
If
you
are
a
user,
if
you
are
a
developer
of,
if,
if
you
work
for
a
cloud
provider
that
uses
it,
what
are
your
expectation
about
that?
A
B
Let
me
go
ahead
and
get
started,
so
my
name
is
james,
strong,
I'm
a
cloud
native
director
at
cantino.
We
are
aws,
managed
services,
partner,
actually
major
cloud
services
provider.
I've
used
nginx,
ingress
controller
at
multiple
clients,
I'm
also
a
community
maintainer
from
a
meetups
perspective
for
louisville
kentucky.
C
Well,
so
my
name
is
pere
anderson,
I'm
chief
architect
at
the
company
called
kaloon.
We
develop
networking
solutions,
I
mean
hardware-based
network
solutions
for
data
centers
and
then
including
kubernetes.
So
we
program
everything
in
p4.
We
also
do
solutions
on
smart
mix.
I
have
a
long
past
in
building
load
balancers
like
24
years
of
doing
that
at
ericsson
I
haven't
participated
at
all
in
ndx.
We
always
did
our
own
little
balancers.
C
Now
I
don't
know
if
we're
gonna
do
our
own
ingress
controller
bottom
up,
because
we
really
want
to
have
a
quick
and
http
2
support
or
if
we
would
use
ngkx
for
what,
where
we're
going.
So
I'm
probably
not
a
good
participant
right
right
now
to
do
maintenance
on
it.
I
don't
know
the
code
base
at
all,
but
it's
an
area
that's
dear
to
to
me.
A
Okay,
I
think
we
can
later
maybe
try
to
do
some
some
deep
dive
into
the
code.
I've
been
developing,
increasing
gynex,
like
on
the
I
I
was
a
a
contributor
like
in
2017
2018
from
there
to
now.
It
changed
it
a
lot,
but
I
guess
I
can.
I
can
try
to
at
least
show
some
some
inner
parts
of
it.
Otherwise
you
can
schedule
it
with
lv
and
maybe
try
alejandro
but
yeah.
A
D
Yeah,
I
will
introduce
myself
shortly
I'm
a
contributor
of
the
indexing
grass
control
project,
I'm
also
a
contributor
of
opera,
st,
so
I'm
familiar
with
ngx
and
lula.
So
I
think
I
can
help
you
to
maintain
the
injics
and
the
lula
part
of
this
project.
A
Yourself,
yeah,
you
are
probably
muted,
okay,
folks,
so
yeah
so
welcome
everyone.
I
am
ricardo.
As
I
say
I
I
am
nowadays
I
am
sweetie.
I
am
in
the
middle
of
switching
jobs,
so
I
I've
used
it
to
contribute
with
with
increasing
gynex
in
2017
2018
18
because
of
my
former
company.
I
have
a
lot
of
a
lot
of
love
to
this
project
because
it
was
my
first
project
contributing
with
to
be
kubernetes
but
yeah.
A
B
B
The
the
big
thing
for
me
would
just
be
understanding
how
we
would
do
this
in
the
case
community,
because
I've
not
maintained
an
actual
open
source
project,
but
I
would
definitely
like
to
be
able
to
help
you
know
run
the
meetings,
do
the
code,
reviews
and
just
put
structure
to
this,
but
other
than
that
I
mean
I
would
need
some.
A
Yeah
sure
I
think
we
can
as
we
we
have
find
this
first
meeting.
We
can
go
through
the
open
items
of
the
meeting
and
and
and
maybe
do
do
this
like
yeah
I
want
to
be-
I
want
to
start
reviewing.
I
need
some
some
knowledge
about
this
about
that,
so
we
can
discuss
about
that
james
yeah.
So
boy,
are
you
with
the
right
microphone
now.
E
Yeah,
can
you
hear
me
yeah,
okay,
yeah,
sorry
I
joined
in
late,
so
I
was
trying
to
catch
up,
I
think
generally,
and
what
it
sounds
like
is
since
alejandro
left,
like
the
first.
E
I
I
think,
like
the
the
stuff
on
the
email
makes
sense,
one
of
the
first
things
that
we
should
probably
do
as
a
group
is
just
to
get
the
state
of
the
world,
because
it's
been
like
ongoing,
like
how
many
issues
outstanding
and
where
the,
where
we
see
bugs
and
like
just
like,
and
then
how,
where
we
want
to,
go
and
then
and
then
and
then
based
on
that
it
would
be
then
like.
I
think
it
naturally
comes
like
okay,
the
group
meets
x
times
a
week,
triage
and
so
forth.
E
A
E
I
don't
so,
I
think,
as
a
group
that
might
be
one
of
our
first
items
is
to
basically
just
get
the
current
status
of
the
project.
You
know
where,
where
investment
needs
to
be
made,
yeah
like
where
and
then,
and
then
we
can
come
up
with
the
triage
process.
I
think
like.
If
we
jump
to
the
triage
process
we
might
be
missing
out
on
stuff
like
it
are
all
components
in
the
in
the
hierarchy.
C
I
have
one
question
so,
like
I
said
it's
a
long,
I
haven't
looked
at
endings
for
years,
but
is
the
open
source
properly
supported
now
after
endings
been,
I
mean,
basically
left
open
source
track
and
went
all
commercial?
C
Properly
the
ending
itself
sort
of
the
stuff-
that's
there
in
the
bottom
right,
then
we
have
hp
3
coming.
Do
we
expect
to
see
an
update
of
engines
to
support
that
and
all
these
things
it's
not
first,
of
course,
needs
to
be
maintained
and
supported
right
now,
but
sort
of
is
there
also
a
problem
with
sort
of
finding
a
a
new?
C
Do
we
sort
of
doesn't
need?
Do
we
need
to
work
also
on
the
base
part,
the
the
web
server
itself
for
the
http
proxy.
A
Yeah,
in
my
opinion,
I
I
don't
think
nowadays
we
need
to
do
that.
I've
seen
some
folks
like
elvin
doing
some
some
changes
into
the
the
ingress
in
ginex
to
to
have
some
features
that
in
ginex,
open
source
doesn't
have
like
the
hot,
the
hot
wheels
right.
So
yeah
we
have
those
two
flavors
of
inginx.
We
have
the
enterprise
one
and
the
community
one
and
the
community
one
is
to
maintain
it
because
it's
a
a
mainly
used
web
server
as
well.
Well,.
C
C
A
E
Yeah
my
suggestion
is
one
is
to
and
we
can
solicit
volunteers
for
this,
like
it
would
be
good
to
put
together
a
a
presentation
or
something
where
people
can
look
at.
Maybe
a
web
page
like
that,
can
look
at
the
architecture
of
the
software
and
how
it
maps
to
the
repo,
even
just
for
new
contributors,
because
I
don't
know
if
it's
very
obvious,
just
building
it
and
looking
at
it
like
how
the
pieces
work.
I
know
that
there's
like
a
significant
luau
component.
E
There
is
a
controller
that
generates
the
configuration
so
like
that
is
one
task,
the
another
one
I'm
recommending
doing
this
offline
because
I
don't
know
if
we
can
fly
through
it
in
10
minutes,
but
maybe
come
back
like
next
week
with
the
summary
is
to
go
through
all
the
issues.
Like
that's
an
obvious
one,
and
then
from
there
we
can
kind
of
figure
out.
E
Okay,
there
is
probably
some
set
of
things
that
needs
to
happen
now
in
terms
of
like
fixing
the
current
issues,
and
then
we
can
look
at
sort
of
what
we
want.
That's
not
there
and
that
would
be
like
the
future
development
kind
of
stuff
that'd
be
like
new,
like
roadmap.
Basically,
that's
my
take
on
it
having
not
actually
looked
significantly.
A
E
That
to
just
like
categorize,
like
bugs
that
need
to
be
fixed,
now
feature
requests,
and
you
know
internal
infrastructure.
I
guess
like
reorganization
and
then
based
on
that,
like
how
big
those
buckets
are,
then
we
can
figure
out,
I'm
assuming
that
bugs
is
going
to
be
pretty
big
just
because
it
usually
is
some
kind
of
road
map
for
like
six
months
and
then
based
on
that
six
and
twelve
months.
I
guess,
if
you
are
ambitious,
then
based
on
that
we
can.
E
Then
then
it's
like
easier
to
set
up
a
structure
where
we
can
ask
the
group
to
volunteer
to
take
up
pieces
of
it
and
what
at
the
same
time,
have
it
sort
of
be
more
cohesive
like
if,
if
we
look
at
bugs
one
by
one,
I
think
like
there
are
certain
bugs
where
we'll
get
a
lot
of
traction
and
then
there
are
a
lot
of
bugs
where,
like
he'll,
get
like
no
traction
and
then
it
just
becomes
very
uneven
in
terms
of
the
investment
on
that
project.
Overall,.
C
E
Having
that
overall
map
is
kind
of
what
my
concern
is,
and
if
we
generate
that,
then
it
then
it
will
be
like
the
investments
will
be
directed
to
basically
benefit
the
whole
project
versus
if
people
are
individual.
I
think
that's
what's
happening
today.
Is
that
there's
just
individual
people
coming
in
and
doing
one
or
you
know,
and
then
maybe
there's
a
few
people
who
are
just
handling
the
bulk
of
the
the
like
core
maintenance
and
that
that
needs
to
be
kind
of
spread
out
to
make
it
viable.
A
Okay,
yeah
I
can
I
can.
I
can
jump
in
to
the
mapping
the
architecture
of
the
the
repo
I
can
reach
alvin,
and
and
do
this
with
him.
I
I've
sent
to
you
on
the
zoom
shed
bookmark
from
the
google
docs,
where
elvin
already
mapped
a
lot
of
the
parts
of
the
code.
Like
the
the
course
in
logic,
the
data
plane
the
nginx
image.
So
I
think
it's
a
good
start,
but
I
can
I
can
put
those
together
in
a
doc
or
something
like
that.
Like
start
contributing
to,
so
we
can
have
like
how.
A
How
can
I,
how
can
someone
contribute
with
the
project
right?
A
contributor
guy
yeah
sounds
good
to
me
so
about
mapping
the
categorizing,
the
the
books
that
need
to
be
fixed,
feature,
requests,
etc.
A
E
So
my
recommendation
is
that
I
think,
like
one
of
the
other
sigs
has
some
triage
tool
or
something
we
can
see.
E
We
just
need
a
list
of
all
of
the
issues
right
now
and
then
a
set
of
categories
that
we
want
to
categorize
it
into,
and
then
then
it
can
be
farmed
out
like
we
can
say
everyone
in
the
group
go
and
look
at
like
10
issues
or
something
right
and-
and
you
know,
come
back,
but
first
we
need
some
way
to
collect
that
data,
or
maybe
we
can
use
labels.
A
A
A
format
and
then
just
proceed.
I
think
I
think,
labels
they
are
already
used.
We
have
like
the
kind
bugs
and
the
kind,
the
kind
design
kind
of
features
so,
but
but
like
the
the
triage
label,
it's
not
used
yet,
which
we're
already
triaged
or
not
the
the
the
which
were
accepted
or
not.
So
we
we
some
some
of
the
issues.
They
don't
have
the
kind
bug
or
the
kind
features
so
yeah.
We
did
that
for
q
proxy.
I
guess
it's
it's.
What
you
are.
E
E
250
open
issues,
so
it's
not
it's
not
like
an
insurmountable
number,
like
thousands,
which
was
like
stick
network
on
kubernetes,
so
we
can
definitely
just
walk
through.
These
looks
like
there's
a
bunch
of
triage.
Actually,
it
started
happening,
I'm
looking.
C
E
B
E
B
A
E
Yeah
I
think,
like
next
week,
let's
review
the
results
of
both
the
10-minute
summary
of
like
how
to
become
a
contributor
than
the
the
bug
categories
and
then
from
there
we
can
construct
a
roadmap
of
like
six
months.
What
we
want
to
happen
and
then
the
call
for
contributors
is
more
structured
because
we
can
be
like
okay,
these
bugs
like
who
wants
a
volunteer
here.
Who
wants
funkier.
B
A
E
Yeah,
that's
true
like
the
idea
is
that
also,
if
you
can
create
search,
maybe
by
date
or
something
I
don't
know
like,
there's
a
way
to
just
chop
up
chunks
of
it,
then
we
can
kind
of
distribute
them
in
some
ways,
so
that
people
aren't
just
looking
at
the
same
issues.
B
A
A
A
So
I
will
give
this
to
like
to
the
next
meeting
or
so,
and
the
the
next
thing
that
I
I
wanted
to
discuss
with
you
is
about
how
actually
we
we
want
to
start
not
not
not
not
just
start
doing
the
issue
triage.
But
what
should
we
do,
as
we
are
a
small
group
with
the
support
issues
right?
So
this
is
something
that
we've
been
trying.
A
C
A
C
A
I'll
see
what
happens
yeah
so
about
about
about
the
support
issues.
I
I
know
that
this
might
be
a
a
bit
aggressive
for
the
perspective
of
the
user,
but
I
wanted
to
discuss
with
you
if
we
should
at
least
try
to
direct
users
to
get
some
help
from
the
community
other
than
issues
and
leaving
the
the
github
issues
to
report
like
features
and
books.
So
I
want
to.
I
want
to
listen
to
you
about
that,
because
this
is
my
opinion.
Yeah.
E
A
So
you
mean
you
mean
about
like
if,
if
the,
if
it's
a
support
that
we
think
might
be
about,
we
should
keep.
But
if
it's,
if
this
is
something
like
yeah,
I
am
trying
to
to
create
an
allow
list
and
I
can't
use
the
annotation
for
the
allow
list.
What's
the
annotation
for
the
allow
list,
we
can
direct
them
to
other
yeah.
E
E
A
Okay,
so
I
guess
we
can
do
that
as
well
this
week,
james
like
seeing,
which
of
them
are
like
support
someone
trying
to
make
something
and
directly
directing
them
to
the
right
channels,
right,
yeah,
okay,
okay,
sounds
good
to
me,
yeah.
So,
okay
about
the
the
issue
triage,
we
are
going
to
discuss
this
later
as
well,
yeah
about
pr
reviewers,
so
I've
seen
bowie
marking
me
on,
like
some
helm,
charts,
triage,
elvin
and
and
other
folks
that
are
already
assigned
to
that.
A
E
E
A
C
A
A
Yeah
and
I
I
will
bring
you
in
slack
and
ask
you
to
approve
me
as
as
a
number
as
well:
yeah,
okay,
okay,
great
yeah
and
the
last.
The
last
thing,
the
two
last
things
that
I
wanted
to
that
I
left
in
as
the
open
items,
the
first
one
is
about
the
meeting
times
and
future
moderators.
I
know
that,
for
me,
this
time
is
pretty
bad
because
he's
in
china,
but
I
wanted
to
know
if
this
time
is
okay
to
you.
A
E
Lunchtime,
usually,
we
send
out
an
email
because
that's
easiest
for
people
to
respond
with
and
for
you
to
collect
the
results
and
then
based
on
that.
It's
also
that's
a
broader
community,
because
the
people
who
it's
like
the
if
they
couldn't
make
this
meeting,
then
this
meeting
was
a
bad
time.
But
they
have
like
no
way
to
tell
you
yeah.
A
I
I've
said
I've
said
that
judo
for
this
one,
but
I
will
I
will
send
it.
I
will
send
an
email
confirming
and
seeing
if
you
can,
if
we
can
at
least
start
doing
this
by
weekly
and
sinking
a
synchronous
in
slack,
I
don't
think
we
are
having
like
the
state
of
the
world
in
the
next
week.
It's
at
least
by
my
side.
It's
gonna
be
pretty
hard
but
yeah.
I
I
will
send
this
to
to
to
civ
network
meetings.
Yeah.
B
A
A
B
A
Great
okay,
so
yeah
and
the
the
last
item
that
I
will
leave
open
as
soon
as
we
know
about
like
this
state
is
about
increasing
ginex
plus
gateway
api.
I
I
I
already
added
that,
because
I
know
that
probably
no
one
is
looking
at
this,
but
this
is
something
that
has
been
worked
by
sig
network
bowie
is
one
of
the
main
architects
of
this
one
with
rob
and
other
folks,
and
I
don't
think
no
one
is
taking
a
look
into
this
in
ingress
in
ginex.
We
will
be
really.
A
I
think
it
will
be
really
strange
if,
like
every
other
ingress
controller,
supports
already
gateway
api
and
ingredient
gynex,
which
is
in
the
main,
repo
yeah.
E
One
of
the
things
that
we
do
need
to
clarify
as
a
specific
thing
is
that
right
now
I
think
the
ingress
engine
x
has
support
for
like
an
incredible
number
of
versions
of
kubernetes
or
it's
like
it
supports
very
old
versions
of
kubernetes,
and
that
was
one
of
the
reasons
why
it
was
fairly
widely
adopted.
E
But
on
the
other
hand,
it's
like
it
makes
it
harder
for
it
to
like.
We
need
to
define
that.
I
guess
as
part
of
this
road
map
and
scoping
is
to
like
what
is
the
compatibility
issue,
because
I
remember
there
was
a
discussion
I
had
with
alejandro
a
couple
years
ago,
where
we
couldn't
add.
He
couldn't
add
something
because
it
was,
it
would
break
like
some
really
old
version
of
kubernetes,
and
I
was
like
well,
you
know
like
get
the
kind
of
balance
that
yeah.
E
E
A
No
that's
right.
We
have
actually
two
two
scenarios
why
the
first
one
is
to
investigate
the
the
the
versions
that
that
increase
in
china
that
the
kubernetes
version
that
you
raised
in
giant
x,
the
pure
ingress
in
gen
x,
is
going
to
support
and
the
the
later
one
is.
How
can
we
add
support
for
the
gateway
api,
because
this,
like
this,
this
this
this,
this
number
of
of
versions
supported-
might
be
a
problem
right
like
if
we
still
support
like
kubernetes
114.
A
So
it
might
be
a
problem
because
actually
ingress
ingress
api
is
on
v1
and
we
we
need
to
see
if,
like
if
ingressing
gynex
is
still
supporting,
like
extensions,
slash,
ingress
or
like
v1b,
better
one,
and
this
might
bring
some
comparability
issues-
okay,
okay,
folks,
so
yeah.
So
we
got
three
action
items
and
I'm
gonna
sync
with
james
to
to
categorize
those
things
and
and
try
to
try
it
not.
E
Hi
everyone,
unfortunately,
I
have
to
drop
off,
but
it's
great
to
see
this
kick
off.
I
think
yeah,
let's
build
a
community
around
this
yeah.
A
Boy,
thank
you
very
much
for
your
help
here
really
appreciate
that.
Thank
you.
Okay.
Everyone
see,
okay,
folks,
so
I
guess
for
now
it's
it's
all.
I
I
just
need
someone
to
yeah
to
investigate
to
investigate
the
kubernetes
version
versus
ingress.
Nginx
version
skew,
but
I
will
leave
this
action
item
open.
If
no
one
jumps
here-
and
we
can
add
this
to
the
queue
okay.