►
Description
[SIG-Network] Ingress NGINX Bi-Weekly Meeting for 20220901
A
Hello,
everyone.
This
is
september,
1st
2022.
This
is
the
cignet
working
ingress
in
genetics
project.
This
is
a
cncf
subproject,
so
that
means
that
it
is
beholden
to
the
cncf
code
of
conduct,
which
essentially
means
be
awesome
to
each
other.
If
you
have
any
issues,
please
report
those
to
ricardo
and
myself
or
to
the
sig
networking
leads
with
that.
I
know
we
had
a
little
bit
of
a
break.
B
I'll
go,
my
name
is
dylan
turnbull.
I
actually
work
for
the
nginx
business
development
and
alliances
group,
and
I
I
primarily
work
in
the
in
the
kate
space
and
our
our
our
ingress
for
the
rest
of
the
company,
the
other
ingress
stuff,
mainly
in
partner
in
partners
in
alliance's
work,
and
I'm
mainly
here
to
find
out
what's
going
on,
see
what's
happening.
That's
that's
pretty
much.
It.
B
C
B
B
D
D
A
A
B
B
A
C
B
A
There
was
a
couple
issues
that
I
pulled
up
on
the
issue
triage
that
are
there
in
the
open
topics
that
we
can
look
at.
I
I
want
to
go
through
those
four
because
they're,
they
seem
kind
of
important
from
what
I
was
looking
at
and
then
we
can
talk
about
project
stabilization
stuff,
where
ricardo
is
going
to
give
an
awesome,
update
on
the
data
plan
and
control,
plane
split
and
we
can
go
from
there.
A
D
A
D
C
C
D
A
D
Are
not
prioritizing
yeah,
we
don't
care
about
features
right
now
for
the
new
releases
right.
It's
not
that
we
don't
care
about
them
at
all.
We
do
and
we
want
to
get
them
in
the
next
releases.
We
are
not
prioritizing
them,
as
as
james
said,
but
for
the
first
one,
so
so
for
the
first
one,
the
cvs
ones.
I
guess
that
just
making
a
new
release
will
even
not
cherry
picking
the
image.
D
Sorry,
we
need
to
share
it,
but
yeah
anyway,
just
cherry
picking
the
image
that
the
final
image,
the
alpine
image
to
the
final
container
will
solve
it
right.
So
we
don't
need
to
do
the
cherry
peak
of
the
whole
things
like
the
test
runner
or
whatever
to
this
branch.
Just
the
final,
just
the
docker
file
in
root
fs,
to
use
the
the
last
image
and
for
the
bug
fixes
we
need
to
cherry
pick
them
as
well.
The
main
problem
that
I
can
see
right
now
is
again.
D
So
I
think
this
is
the
only
the
only
real
problem
that
this
one
and
people
that
relies
on
on
the
manifests
that
are
on
main
right,
so
people
that
just
go
to
maine
and
do
curl
whatever.
So
I
would
just
split
this
into
efforts.
First,
we
need
to
open
an
issue
for
that
saying:
hey
release
a
new
version,
and
in
that
issue
we
need
just
to
clarify
everything
that
we
need
right.
So
sherry
pick
the
image
cherry
pick.
D
The
bug
fixes
then
make
sure
that
the
cloud
build
runs
and
make
sure
that
our
manifests
even
the
main,
even
the
ones
in
main
they
are
pointing
to
the
right
release
and
I
am
not
against
just
changing
the
manifesting
main
to
point
to
that
one.
So
we
we
keep
in
mind.
Just
the
I
mean
version,
131
one,
three
one,
one,
three,
two!
That's
that's
fine
right.
I
think
it's
easier
that
than
again
creating
a
stable
text
file
and
changing
everything
in
kind
or
whatever
kind
of
documentation
or
whatever,
okay.
But
then.
C
D
B
C
C
A
A
B
D
D
D
A
So
about
that
I
was
gonna
ask
and
I
was
gonna,
bring
it
up
when
we
start
talking
about
the
control
plane
split.
Do
we
want
to
do
what
we
did
with
the
v1
update
and
just
have
that
on
a
separate
branch
and
a
separate
release
candidate
like
a
beta
release
like
we
did
so,
do
the
same
thing?
So
then
we
wouldn't
have
this
problem
that
we
think
we're
going
to
have.
D
D
Yeah,
but
this
is
something
that
I
need
to
pay,
so
I
won't
block
you
folks
because
of
my
4k
lines,
pr
right
now,
so
I
will
have
a
separate
branch.
I
will
work
on
that
separate
branch.
I
want
to
merge
in
a
way
that
the
control
that
that
nginx
works
still
works.
I
mean
that's,
not
great,
but
it
still
works
on
both
ways.
B
D
D
I
think
it
would
be
good,
I
mean
right
now
we
can
cut
a
release
from
main.
There
is
no
impact
stuff,
but
this
is
not
sustainable
if
we
want,
if
we
are
gonna,
keep
two
branches
again
right,
so
one
with
the
control,
plane,
split
and
one
without
the
control
plane
split,
I
don't
know
if
you
are
gonna,
do
that.
D
I
was
thinking
about
implementing
the
control
plane
split,
but
keeping
keeping
the
the
the
real
control
plane
still
within
gynex
code,
at
least
for
the
next
release,
but
I
need
to
plan
that
so
right
now
there
is
no
problem
instead
of
cherry-picking
cutting
a
branch,
but
before
I
do
my
merge,
I
think
before
I
do
my
merge.
I
think
that
we
need
to
solve
this
branching
problem.
D
D
A
D
A
A
A
C
A
C
A
C
B
A
A
A
A
A
D
C
A
B
A
We
can
also
make
that,
as
part
of
the
update
when
we
put
out
the
the
beta
for
the
control
plane,
data
plane,
split,
we'll
also
mention
that
we've
deleted
that
we
we're
not
accepting
and
we're
not
supporting
the
legacy
branch,
which
is
pre,
which
is
four
nine.
I
think
or
five
one
was
our
last
one.
Those
won't
be
supported
anymore.
D
A
A
B
D
B
D
One
of
the
things
that
I'm
doing
is
actually
not
right
now,
but
I'm
I'm
splitting
the
code
from
web
hook
as
well.
From
the
ingress
controller,
someone
asked
in
some
meeting
yeah
someone
asked
in
some
meeting
or
some
channel
hey.
Can
we
have
like
a
live
web
hook
whatever
and
yeah?
It
does
make
totally
sense
to
me.
D
The
thing
is
that
we
do
have
the
webhook.
The
webhook
also
tests
the
nginx
configuration
file
right
and
we
won't
be
able
to
test
the
configuration
anymore,
but
this
can
be
sort
of
up
to
the
admin
to
enable
or
disable
so
having
a
more
heavy
web
hook
or
a
more
light
one
just
just
checking
for
the
business
logic,
but
not
the
configuration
from
jynx.
D
C
A
D
A
A
C
D
C
B
C
A
D
Okay,
but
I'm
I'm
putting
on
a
different
way.
Okay,
imagine
that
you
configure
your
ingress
as
myside.com
on
port
80
and
you
don't
state
that
you
have
a
tls
or
whatever
you
don't
put
the
tls
rule,
okay
and
then
I
come
later,
and
I
see
that
you
did
a
mistake
of
not
enabling
not
enabling
tls
and
I
do
exactly
the
same
configuration
as
you
do,
but
I
enable
tls
on
my
side
right.
D
So
you
won't
decide
the
website
without
the
tls,
and
I
will
want
the
website
with
the
tls
right
and
today
and
today
on
the
browsers.
What
usually
they
are
doing
is
they
are
trying
first,
to
connect
to
part
to
port
443
and
then
go
back
and
fall
back
to
part
80..
So
I
just
steal
your
domain.
Your
your
ingress
makes
sense.
C
C
C
C
So
the
so
the
way
I
understand
is,
what
will
happen.
Is
the
lewis
lua
script
or
whatever
we
use
for
synchronization.
It
will
just
go
check
and
if
it
is
the
same
same
specs
for
host
as
well
as
path,
no
difference,
it
will
just
it
will
add,
or
it
will
add
and
add
a
new
annotation
or
whatever
new
directive
engineering
directive,
that's
if
it
is
required.
Otherwise
it
will
just
forget
it
it
just
added
just
no,
not
no.
It's
not.
He
expects
a
web
webhook
rejection
and
that's
not
going
to
happen.
C
Actually,
you
can
see
his
claim.
He
actually
writes
that
if
his
second
yeah
the
second
hammer
that
he's
using,
he
doesn't
have
the
first
rule,
which
is
a
dummy
example
and
something
something
if
he
doesn't
have
that,
then
the
webhook
is
rejecting.
It
he's
actually
writing
that
he's
written
that
somewhere
down
below.
In
a
note,
it
only
doesn't
reject
when
he
has
two
rules.
C
C
C
In
his
first
line,
he's
saying:
there's
a
piece
of
code
somewhere
where
it
only
checks
for
the
first
rule
host
and
the
first
rule
host
is
different.
Then
it
goes
ahead
and
it
doesn't
reject
so
he's
right.
So
it
means
we
have.
We
can't
deep
dive
into
because
in
real
world.
Nobody
will
use
something
like
this,
so
we
can't
go.
Imagine
all
the
permutation
combinations
of
weirdness
that
people
want
to
configure
and
have
the
webhook
check
for
every
single
whimsical.
C
Oh
yeah,
so
if
you
go
in
that
direction,
there
is
actually
several
tls
rated
issues.
People
have
reported,
for
example,
they
want
multiple
client
certificates
right
on
mtls
and
things
like
that.
So
there
is
several
valid
and
good
improvements,
and
just
one
user,
and
just
one
user
or
two
or
anybody
who
seconds
this
kind
of
issues
or
says.
Okay.
I
am
also
facing
this.
There
are
almost
always
a
co-worker
of
that
person
or
somebody
from
the
same
company.
C
C
A
C
D
A
Think
we
should
close
it.
I
think
we
should
like
a
v2
looking
at
improvements.
So
this
I
would
say
this
is
a
feature
because,
yes,
it's
a
separate,
it
is
a
separate
ingress
object
with
two
rules,
even
if
the
rules
do
match.
So
it's
an
improvement
to
check
all
of
the
rules
in
an
ingress
against
all
of
the
existing
right.
So
let's
look
I'll
make
that
comment
I'll.
Leave
it
at
that
and
I'll
make
sure
that
we
put
it
I'll
put
it
on
the
backlog
right.
A
A
D
A
So
I'll
grab
some
stats
from
devstats
and
we
can
close
out
the
survey
and
get
the
results
and
start
looking
at
them.
One,
for
I
mean
62
is
unfortunate
because
you
know
it's
10
000
stars
on
the
repo
and
lots
of
people
use
ingress,
but
yeah
so
I'll
go
ahead
and
I'll
close
that
and
I'll
get
the
data,
and
I
can
share
it
out
to
everyone.
D
Yeah,
so
I
will,
I
will
try
to
be
really
direct
on
that
we.
So
I
have.
I
took
a
lot
of
time
actually
trying
to
figure
out,
which
would
be
the
best
approach
of
doing
that,
instead
of
just
going
into
one
or
the
other
one,
and
I
have
realized
that
the
easier
way
to
do
that
right
now
is
to
the
final
step
of
ingress
is
actually
getting
a
whole
structure
and
generating
getting
that
structure
and
sending
into
engine
extend
plating
to
do
the
template
stuff
and
the
the
cool
thing
on.
D
D
Two
or
three
weeks
ago,
so
we
are
right
now
the
split
the
status
that
we
are
on
the
split
right
now
is
it
is
working.
So
I
have
a
control
plane
and
a
data
plane
running
on
my
kind
cluster
here.
Let
me
see
if
it's
working
or
not
but
hold
on
it
is
working,
so
we
can
see
as
an
example.
Okay,
I
have
it
here.
D
We
can
see
that
whenever
I
let
me
share
my
screen
whenever
we
generate
a
new,
you
need
to
allow
me
james
whenever
we
generate
a
new,
a
new,
a
new
configuration
or
something
like
that.
This
configuration
is
sent
to
to
data
plane
or
to
all
of
the
data
planes
watching
the
the
control
plane,
and
it
will
then
start
reconfiguring
stuff
right.
So,
as
you
can
see
here,
I
have
the
ingress
in
gynx
control,
plane,
data,
plane
and
ingress
in
gynex
and
let's
take
a
look
into
the
logs.
D
So
if
I
come
here
and
do
a
cube,
ctrl
create
ingress,
something.
Where
is
my
ingress?
Okay,
I'm
gonna.
Do
this
really
fast
ingress
my
project
here?
Okay
and
I'm
gonna
just
gonna
change
here
and
create
another
thing
here
we
are
going
to
say
see
that
it
passes
to
the
admission.
Then
it
passes
the
event
and
finally,
it
triggers
a
new
configuration
here
right.
I'm
not
sure
why
the
data
plane
is
not
showing
anything
but
what's
happening
behind
the
scenes.
D
D
D
Okay,
so
if
we
come
here
to
etc
in
chinax,
we
are
gonna
see,
it
should
be
that
this
rule
that
I
have
created
should
be
here.
It's
not
I'm
not
sure
why
this
isn't
working,
maybe
one.
So
we
have
some
problems,
and
one
of
them
is
that
when,
when
communication
ends,
it's
not
reestablishing,
but
this
is
something
that
ingress
x.
This.
B
D
D
Here
it
is
so
it
was
pretty
fast
right.
So
I
have
this
I'm
here
my
login,
because
why
use
debugger
instead
of
printing
messages
with
the
version
right,
so
I
can
see
that
the
version
that
I
had
changed
it
just
applies
the
configuration
and
says:
okay,
I
have
a
back
end
reload
and
just
do
that's
the
reload
of
the
back
end
and
that's
all
and
and
returning
here
we
can
see
that
the
data
plane
posted
back,
that
it
had
a
reload
configuration
here
right.
D
So
it
just
said:
hey
I
had
a
new
configuration
and
because
of
that
I
have
just
triggered
a
reload,
so
this
is
what's
working
right
now
right,
so
we
have
the
control,
plane
and
data
plane.
The
control,
the
control
plane,
have
a
service
that
can
publish
the
events
back
when
it
receives
from
from
the
ingress
controller
right.
D
Instead
of
getting
all
of
the
ingresses
and
doing
all
of
the
calculations,
so
my
my
expectation
next
it's
to
to
finish
this
and
make
it
sorry
folks
it's
to
make
this
properly
work
and
fix
the
end-to-end
tests.
I
mean
just
patiently
saying
that
he
finished
migrating.
The
end-to-end
test
to
the
news
to
the
new
model
without
the
http
expect.
D
So
I
want
to
merge
that
thing
and
then
rebase
this
and
start
doing
the
end-to-end
test
and
checking,
at
least
if
everything
that
we
have
in
end-to-end
test
or,
let's
say
75
percent
of
the
things
they
are
still
working
right.
So
if
I
can
create
an
ingress-
and
I
can
get
this
ingress
if
I
can
create
an
ingress
and
and
have
the
session
affinity
and
other
things,
I
know
that
the
logics
they
are
working
so
the
next
step.
D
So
it's
as
you
can
see,
it's
working,
not
the
final
way,
but
it's
it's
working
and
I
will
just
work
a
bit
more
during
the
weekend
on
this.
One
thing
that
will
help
would
help
me
a
lot
in
the
future
is
as
soon
as
we
get
the
survey
ready,
start
removing
stuff
right.
So
as
an
example,
zipkin
jagger,
open
tracing
call
it
the
way
you
want
it's
not
working
here,
because
it
renders
its
own
template.
D
On
the
other
hand,
one
thing
that
I
we
can
do
right
now
with
this
approach
is
that
we
can
now
split
the
configuration
of
each
of
the
virtual
hosts
right,
because
I
receive
all
of
these
things
as
a
structure
that
then
I
can
just
go
through
all
of
the
virtual
hosts
and
create
separate
configuration
for
each
virtual
host.
As
an
example,
one
thing
that
we've
been
discussing
in
the
past.
B
D
I
don't
know
so
I
will
be
really
honest.
I
have
tried
to
do
the
open,
telemetry
stuff
one
time,
but
I
was
using
debian.
I
guess
instead
of
alpine,
I
have
failed
in
a
lot
of
ways
and
so
many
ways
of
compiling
that
thing
that
I've
said
yeah
whatever
someone
is
going
to
solve
this
for
me,
so
I
couldn't
make
open
telemetry
work.
C
C
End
of
that
scene
has
changed.
That
scene
has
changed.
Okay,
it
comes
that
scene
has
changed,
open,
telemetry
compiles
perfectly
now,
asan
was,
you
know,
did
a
lot
of
work
on
that
it
compiles
perfectly
it
manually.
It
loads
and
hasn't
even
has
got
stats
in
gui
in
grafana.
So
right
now
the
scene
is
individual
components
are
working
and
tested.
A
D
Yeah,
my
my
ask
was
going
to
be
something
like
that.
So
what
I
want
long
is
to
make
sure
that
open
telemetry
can
replace
everything
that
we
have
on
the
telemetry
side
right
now,
even
datadog
we
compile
datadog.
I
have
no
idea
why
we
do
that,
but
I
want
to
get
rid
of
all
of
those
things
and
have
just
opened
telemetry
being
able
to
send
to
datadog
to
jagers
zipkin,
whatever
we
have
as
a
backend
right.
D
So
if
you
folks,
like
you
and
a
son
that
are
working
on
this,
you
can
put
a
paper
a
document,
something
like
that.
Just
showing
hey,
we
have
these
inginax.
It
doesn't
need
to
be
ingress
in
gynex.
Okay,
we
have
this
in
gynex
with
the
open
telemetry
model
and
we
can
send
the
tracings
to
zipkin
datadog.
I
can.
I
can
try
a
license
of
datadog
if
we
need
that,
just
to
prove
it.
What
I
want
is
to
have
less
moving
parts
in
our
code
and
less
moving
parts.
D
B
C
A
D
And
I
guess
this
is
just
how
you
configure
open
telemetry
right.
So
this
is
how
just
how
you
add
configurations
to
nginx
conf
to
open,
because
open
telemetry
is
just
a
model
that
will
take
the
tracings
and
send
you
whatever
backhand
you
you
support
right.
So
I've
seen
the
documents
I've
seen
actually
some
of
the
compilations.
I
just
want
to
make
sure
that
we
can
drop
zipkin
jager,
open
tracing
all
of
those
things
that
we
have
right
now
in
like
a
pr.
D
D
C
C
C
D
B
C
B
Yeah,
so
so
the
module
will
use
otlp,
grpc
protocol
and
then
whatever
backend
is,
can
support
that
they
can
just
received
the
traces
and
normally
people
deploy
a
collector
which
does
the
conversion.
So
if,
for
example,
if
the
zip
king
didn't
support
otnpgr
pc,
you
have
the
collector,
you
talk
to
collector
and
collector
will
convert
it
and
send
it
to
the
zip
king.