►
From YouTube: Understanding the Future of Ingress-nginx - James Strong, Chainguard & Ricardo Katz, VMware
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Understanding the Future of Ingress-nginx - James Strong, Chainguard & Ricardo Katz, VMware
Speakers: Ricardo Katz, James Strong
In this talk, we will present the survey results from our Ingress-nginx community survey. The survey's goal was to know what we should be doing for future releases and how to prioritize features, bugs, or other issues important to the community. The ingress-nginx project is undergoing a stabilization project as well. This stabilization project has worked to increase the security, review and deprecate older features, and fix long-standing issues with the project. We will examine the current status of the stabilization project and invite community members and users to join us to discuss the future of the ingress-nginx project.
A
A
Welcome
to
our
comedy
session,
thank
you.
Open
mic,
no
I
make
jokes
when
I'm
nervous
so
be
prepared,
hello,
everyone.
My
name
is
James
strong,
I'm,
a
Solutions
architect
at
changuard,
and
what
that
means
is
I
help
people
secure
their
software
Supply
chains,
look
at
gaps
of
those
and
and
I
also
help
maintain
Ingress
in
genetics
and
I
wrote
a
book
about
networking
kubernetes.
But
please
don't
ask
me
about
your
IP
tables.
B
A
A
Thank
you
very
much
we're
going
to
talk
about
the
stabilization
project
that
we've
been
working
on
and
we're
going
to
do
a
little
discussion
about
the
road
map,
some
of
this
stuff,
some
of
the
bugs
that
Ricardo's
introducing
and
a
little
bit
of
q
a
if
you
have
questions
so
this
time
is
the
community
time.
So,
if
you
have
questions
for
us,
just
go
ahead
and
yell
at
us
throw
things
Ricardo
will
catch
them.
A
So
I'm
going
to
talk
about
the
community
survey
results.
One
of
the
first
things
we
asked
I
thought
was
pretty
obvious,
but
I
wanted
to.
We
wanted
to
understand
what
people
were
using
and
what
they
thought
was
most
critical
in
Ingress
engine
X,
and
that
makes
pretty
that
makes
sense,
right,
load,
balancing
and
the
fact
that
it
was
open
source
so
good
to
know
that
everyone's
using
it
for
what
we
intended
to
use
it
for.
But
we
need
to
talk
about
that.
A
A
A
They
take
about
45
minutes
to
run
each
time
we
have
a
PR,
so
we
want
to
make
sure
that
those
are
supported
so
we're
also
following
the
N
minus
three
and,
as
some
of
you
are
probably
aware,
I
think
122
is
being
deprecated
soon.
I'm,
looking
at
our
Sig
release
here
at
Carlos,
I
always
have
questions
for
him,
so
we're
moving
as
kubernetes
is
moving
and
looking
at
understanding
what
we
should
be
supporting.
A
So
if
you
have
any
feedback
on
that,
please
let
us
know
what
versions
of
Ingress
are
currently
running
in
production.
So,
of
course
we
have
Ingress
versus
versions
of
kubernetes,
really
good.
So
back
when
we
put
the
survey
out,
we
were
on
one
two.
One
I
think
we're
getting
ready
to
at
least
one
five
with
a
couple
new
features
and
deprecating
some
things.
A
This
is
really
a
good
thing.
We
do.
We
try
to
make
sure
that
we're
keeping
the
documentation
up
to
date
as
new
annotations,
config
Maps
features,
get
added.
We
want
to
make
sure
that
we're
answering
those
questions
there,
because
it's
not
fun
answering
the
same
question
over
and
over
again
and
I
eventually
will
get
the
client
IP
thing
documented,
because
I
think
in
the
year
and
a
half
I've
been
working
on
this
we've
been
asked
that
about
five
or
six
times.
A
This
is
also
fun.
I
would
like
to
talk
to
the
never
person,
but
this
is
always
exciting
that
people
like
Ingress
in
genetics.
They
continue
to
use
it
and
they
would
recommend
it.
So
again,
that's
all
part
of
what
you
guys
are
doing
the
feedback
that
you're
giving
us
and
the
work
that
we
continue
to
do.
So.
Thank
you
for
that.
I.
A
This
also
makes
sense.
We
get
a
lot
of
questions
about
home.
We
get
a
lot
of
as
you'll
see
further
on
in
some
of
the
surveys,
some
of
the
open-ended
questions.
We
get
a
lot
of
questions
about
Helm,
support,
Helm
documentation
and
Helm
changelog.
So
again
the
multiple
instances
per
cluster,
that's
going
to
be
something
I,
think
that
we
need
to
discuss
and
probably
document
a
little
bit
more.
There
are
some
hidden
gems
on
trying
to
run
multiple
instances
on
one
cluster.
A
We
see
a
lot
of
things
in
here
again
the
nginx
version.
We
know
we're
running
a
little
old
behind
that
it'll
become
apparent
when
we
talk
about
some
of
the
complexities
with
managing
this
project
time
and
issues,
we
know
that,
with
a
stability
project,
we've
probably
been
neglecting
some
issues
and
we're
working
on
making
that
a
little
easier.
Some
of
the
things
we're
looking
to
implement
right
are
using
a
GitHub
project
to
triage
issues
and
work
on
that.
A
You
guys
know
what
we've
been
working
on,
that
who
reads
the
kubernetes
dev
emails
that
they
get
all
the
time.
No,
okay,
that's
all
good.
Also.
It
helps
the
attend
the
community
meetings,
because
we
talked
about
that
there
and
we
sent
out
the
kubernetes
dev
if
there
are
other
forms
of
communication
that
we,
that
might
be
more
helpful,
I
know
I'm
looking
to
investigate
getting
a
Twitter
handle
for
Ingress,
nginx
I.
Think
that
might
be
helpful.
A
What,
if
anything,
stops
you
from
updating
Ingress
nginx
as
I,
was
talking
about
some
of
the
instability
issues
that
we've
had
lately
in
the
past
you
know
eight
or
so
months,
I'm
working
on
the
V1,
the
leader,
the
election,
the
lease
API
all
of
the
upgrades
trying
to
maintain
those
things.
So
we
know
that
there's
been
some
issues.
A
A
A
A
It
did
give
us
an
indication
that
I
think
we're
on
the
right
track
on
the
things
that
we're
trying
to
accomplish
from
the
stabilization
project
and
what's
going
to
be
on
the
roadmap,
and
it
gave
us
a
little
bit
of
direction
of
things
that
you
know
will
work
in
the
project
day
in
day
out
that
we
don't
see
and
yeah,
can
you
work
out
so
again.
Thank
you
for
that.
A
A
So
we've
accomplished
in
I
think
we
put
this
out
in
July
and
we've
accomplished
these
these
three
things,
so
the
N
minus
three
we
put
out
there
I
think
we've
talked
about
it.
We
put
a
blog
post
out
there,
but
again
a
lot
of
people
aren't
seeing
that.
So
we
want
to
make
that
a
little
bit
more
explicit.
So
we
put
that
out.
There
we've
also
looked
at
implementing
some
of
the
open,
ssf
recommendations
and
trying
to
make
sure
that
the
project
is
secure.
A
A
We
don't
we're
not
blocking
on
those
yet
but
I'm,
starting
to
think
that
we
probably
should
we're
looking
at
introducing
the
go
vulnerability.
Checker
that
just
came
out
so
working
on
trying
to
make
it
a
little
bit
more
secure
and
then
from
a
features.
Acceptance
criteria,
perspective,
release,
notes,
we're
using
the
Sig
release
tool
to
generate
those
automatically
for
us,
so
we
don't
have
to
do
this
by
hand
and
forcing
that
they're
in
there
in
the
PRS
that
you're
putting
together
and
that
it's
documented
and
that
you
have
an
end-to-end
test.
A
B
Let
us
know
that
there
are
other
ways
of
doing
those
information
extraction,
that
they
cause
problems
right
and
if
you
look
into
Ingress
at
our
Ingress
controllers,
there
are.
They
are
probably
the
most
risky
component
that
you
may
have
in
your
cluster
right,
because
you
don't
expose
your
API
server
to
the
internet.
You
don't
expose
the
cubeletal
parts
or
whatever
to
your
network,
but
you
expose
Ingress
controller
in
gynex
because
that's
the
proxy
to
your
application
right.
So
we
are
aware
of
that
and
then
then
we
started
thinking.
B
How
can
we
improve
this
bar
looking
how
the
other
projects
of
the
community
they
are
doing?
So
we
have
this
Amazing
Project,
that's
ongoing,
which
is
called
copying.
That's
the
new
Q
proxy
that
have
some
sort
of
similar
problem.
We
know
that
Contour
folks
and
why
folks
they
do
the
same
thing,
which
is
we
should
split
privileges
right
now.
This
is
the
way
that
we
should
deal
with
this.
So
that's
what
displayed
in
control,
plane
and
data
plane
is
so
effectively
what
we
are
doing
is.
B
We
are
re-architecting
English
in
China
X
to
have
just
a
control
plane
that
is
responsible
to
connect
to
kubernetes
API,
and
it
will
just
do
all
of
the
calculations
and
create
the
right
data
model
for
the
data
play.
So
the
data
plane
will
consume
just
front-end
back-end
certificates,
whatever
gets
updated,
but
won't
have
access
anymore
directly
to
the
kubernetes
API
server.
And
this
we
should
I
hope,
probably
also
help
getting
some
better
performance
in
your
cluster,
because
you
won't
have
more
like
50
or
100
Ingress
controllers
instances
consuming
the
the
kubernetes
API.
B
You
have
probably
three
control
planes
doing
that,
maybe
one
just
in
a
leader
election
sort
of
working.
We
didn't
decided
that
yet
and
then
you
you
have
the
data
planes
just
consuming
via
grpc
or
XDS.
We
are
just
figuring
out
how
the
data
plane
they
wire
is
going
to
work,
but
the
control
plane
and
the
control
plane.
If
something
got
compromised
in
your
data,
plane,
you'll
just
be
able
to
consume
whatever
you
are
supposed
to
consume
anyway,
which
is
the
front
end,
then
the
back
ends
and
the
data
model
right.
B
We
are
also
discussing
starting
to
discuss
with
the
kaping
folks
If.
Instead
of
doing
all
of
those.
This
work,
which
is
almost
done
in
Ingress
controller
I'm,
just
trying
to
fix
the
end-to-end
tests.
Otherwise,
James
is
not
going
to
allow
me
to
match,
but
if
we
can
use
what
they
are
doing
for
copying
in
the
layer,
7
fashion
and
how
this
can
be
helpful
for
other
increase
implementations
as
well.
B
So
we
are
going
to
discuss
about
the
Gateway
API,
but
can
I
use
the
same
approach
to
have
a
control
plane
for
Gateway
API,
generating
the
data
model
and
back-end
implementators
just
need
to
implement
like
angina
xha
proxy,
whatever
consuming
that
control
plane
and
not
like
having
to
consume
the
whole
Gateway
API
model?
So
that's
what
we've
been
looking
for
and
I'll
be
kind
of
looking
forward
to
work
next
week
with
decaping
folks
as
well.
A
Yeah
and
then
on
the
nginx
side,
so
there
are
a
couple
things
that
stop
us
from
going
directly
to
like
123
and
things
like
that.
A
lot
of
the
functionality
that
you'll
see
probably
from
like
the
Enterprise
nginx
version,
We
Implement,
that
with
Lua
and
open
Rusty.
So
we
can't
support
the
nginx
versions
until
all
of
the
I
think
43
dependencies
that
we
pull
in
support
that
version.
A
So
it
takes
a
lot
of
time
and
effort
to
make
sure
that
all
of
those
dependencies
we're
using
support
that
nginx
version
and
pass
all
of
our
nginx
tests.
I
think
as
of
last
week,
that
was
completed
and
I
think
it's
just
sitting
in
our
queue
to
actually
accept
it,
but
we're
waiting
till
Tuesday
and
for
those
who
are
paying
attention
probably
know
why
we'll
have
another
vulnerability
we'll
have
to
patch
and
then,
as
part
of
streamlining,
the
release
process
that
goes
along
with
automating
the
release
notes
automating
the
build
process.
A
One
of
the
specs
that
we
talk
about
is
that
it
takes
about
four
hours.
If
we
do
everything
properly
the
first
time
to
get
a
release
out
and
I,
don't
know
about
you
recorder,
but
I've
not
got
it
right
once
there's
always
one
little
thing
that
we
miss
changelog
doesn't
get
updated,
there's
a
version
that
didn't
get
updated
so
we're
working
on
trying
to
automate
that
entire
process
yeah
and
looking
at
additionalist
build
more
to
come
on
that
one.
A
We
know
that
there
are
issues
with
the
Ingress
class
logic
that
we've
implemented,
so
that
is
on
the
backlog.
From
after
we
get
the
data
plan.
Cp
split
working
through
there
are
lots
of
modules
that
we
use,
there's
lots
of
dependencies
and
looking
at
an
understanding
what
we
need
to
remove
again
for
the
stability
of
the
project.
A
There
are
lots
of
other
containers
and
tools
that
we
use
that
haven't
been
touched
in
two
or
three
years,
so
we're
actually
actively
removing
those
from
the
project
and
using
newer
versions
of
things
for
that
respect.
So
trying
to
do
that,
and
we
also
still
have
the
Legacy
Branch
out
there.
So
anything
that's
pre-119,
so
we're
looking
at
removing
that
availability.
So
we
haven't
done
that
yet,
but
they've
been
in
discussions.
So
that's
why
we
asked
the
question
of:
why
are
people
using
still
using
five.
A
B
A
A
A
Two
monitoring
Frameworks,
so
we
support
Prometheus
and
grafana
dashboards.
We
actually
produce
our
own
grappana
dashboards.
We
get
a
lot
of
questions
on
those
as
well.
Three
third-party
plugins,
so
mod
security
is
one
of
those
plugins.
We
have
to
figure
out
how
we're
going
to
replicate
that
functionality
I'm
sure
there
are
other
people
in
the
community
who
have
that
same
exact
issue,
so
we
have
not
engaged
anyone
from
that
conversation.
Matt
Nat
Geo
is
one
of
them,
so
goip
and
I
forget
what
the
third
one
is.
A
Open
tracing
yeah,
so
we
do
have
the
open,
Telemetry,
PR,
completed
and
in
test
is
passing
and
that's
also
probably
going
to
be
part
of
the
one
five
release
like
I
said
it
takes
four
hours
to
build
this.
If
we
do
things
properly,
we
have
seven
static
configurations.
So
not
only
do
we
produce
a
Helm
chart
for
this.
We
also
support
specific
implementations
for
like
AWS.
Do
things
like
that,
so
we
have
to
help
maintain
those
as
well
12
other
container
images,
so
we
build
two
container
images
right,
Ingress,
controller
and
nginx.
A
B
A
A
68
Ingress,
nginx
command
line,
Flags
so
being
able
to
configure
it
what
port
it
runs
on
where
your
search
is
coming
from,
where
your
logs
go
100,
plus
e
to
e
test,
and
if
anybody
else
is
looking
at
that
math.
Some
of
the
things
that
we
are
talking
about
the
configuration
options
we
don't
have
all
of
our
tests
covered.
So
it's
not
a
full
end-to-end
test,
Suite
118
annotations.
So
that's
how
you
customize
nginx,
there's
a
couple
different
ways:
right,
there's
annotations
in
this
config
Maps
and
there's
166
of
those
configuration
options.
A
I
didn't
do
the
math
on
that.
What
that
permutation
is,
but
that's
a
lot
to
make
sure
that
continues
to
save
running.
So
when
we
talk
about
when
we
haven't
seen
your
PR
or
we
haven't
accepted
your
feature
request
or
you
know,
there's
an
issue:
there's
a
cve
out
there.
We
just
wanted
people
to
understand
what
the
complexity
is
to
manage
this
project.
A
So
please
be
kind,
but
also
if
you
have
an
issue
or
if
something's
wrong,
and
we
have
a
slack
Channel,
we
have
our
community
meetings
and
you
know
just
come
and
engage
with
us
and
help
us
and
help.
I
was
going
to
wait
to
ask
that
later.
Okay,
so
from
a
roadmap
perspective,
I
think
we
talked
a
little
bit
already
about
the
data
plan.
Control
plane
split
once
Ricardo
gets
all
of
those
100
plus
in
the
end-to-end
tests.
Passing
we're
gonna
do
the
same
thing
that
we
did
with
the
V1
we'll
put
out
Alpha.
B
Please
please
please
test,
because
when
we
did
the
V1
and
released
the
Alpha
and
the
beta
and
we
got
a
lot
of
bugs
when
it
was
released
for
GA
I
only
said
like
hey
folks,
because
we
didn't
get
any
feedback.
Yeah
yeah,
yeah,
yeah
and
like
we
didn't,
have
like
some
clusters
to
test
that.
So
if
you
have
some
cluster
that
you
can
test
it
like,
I
can
run
a
canary
with
this
Ingress
doing
like
not
directing
my
traffic,
but
at
least
applying
my
own
annotations.
A
Once
we
get
that
out,
we
didn't
really
talk
about.
So
when
we
first
had
that
CV
come
out,
we
added
the
CH
root
environment.
So
that's
so
we
produced
two
containers
right:
the
CH
root,
which
helps
with
that
cve
vulnerability
that
we've
talked
about
we'll
go
ahead
and
remove
that
once
we
get
the
cpdp
split
to
ga,
adding
the
digitalis
bill
as
well
I'm
about
90
there
I
can
I've
got
the
build
time
down
from
four
hours
to
about
10
minutes
now.
A
Open
Telemetry,
like
I,
said
that
that
pull
request
is
there
it's
waiting
for
us
to
hit
the
lgtm
button,
explicit
duplication
policy
again
continuing
to
make
that
apparent
to
people
when
we
say
what's
deprecated
we're
saying
that
it
runs
in
the
end-to-end
test
suite
and
we
know
as
well
as
we
can,
that
it's
working
and
then
reviewing
those
third-party
dependencies
like
mod
security
and
then
I'll.
Let
I
think
we
already
talked
and
hit
on
the
Gateway
API
with
the
kaping.
Unless
there's
anything
else,
we
wanted
to
add.
B
A
Familiar
with
mtls
and
grpc
calls
I
was
asking
questions
and
then
one
of
the
feedbacks
that
we
got
was
you
know
you
guys
I.
Think
I
made
it
pretty
clear
about
the
complexity
of
the
project.
People
get
upset
about
the
stalebot
and
life
cycle,
rotten
we're
going
to
remove
that
bot
and
we're
going
to
move
to
the
project.
A
A
Oh
yeah,
two
other
things:
I
went
to
the
tax
security
meeting
yesterday,
we're
gonna
go
work
through
the
threat
modeling
and
get
that
evaluated
working
through
the
project
and
understanding
what
else
we
can
do
to
help
secure
Ingress,
nginx
and
then
engaging
Sig
contributor
X
to
understand
how
we
can
continue
to
work
evolving
the
community
and
then
this
one
might
be
a
little
bit
controversial
but
trying
to
understand
Lua.
We
we
have
difficulty
getting
lure
developers
so
either
more
lure
developers
or
looking
at
migrating
to
engine
engine
X
and
JS
yeah.
Here.
B
I
want
to
use
this
moment
actually
to
give
a
big
shout
out.
I'm,
not
sure
if
Alvin
is
here,
he
was
talking
with
me
yesterday,
but
Alvin
from
Shopify
is
the
one
that
actually
implemented
the
all
of
the
Lua
stuff,
because
in
China
X
didn't
support
it
hot
reloads
right.
So
he
solved
a
bunch
of
people
problem
with
that,
because
we
are
the
the
original
reason
that
we
move
it
to
AJ
proxy
in
my
previous
company
was
because
of
the
hot
reloads
as
well
right.
B
They
have
moved
forward
doing
their
stuff.
Alvin
I
hope
that
he
can
keep
contributing
with
us
as
well.
I
will
speak
with
him
because
he
he
is
our
Lua
maintainer
right.
So
he
is
the
person
that
did
all
of
those
things,
but
it's
hard
for
us
like
I.
Do
this
on
my
Sunday
really
and
I
I
do
mostly
of
the
gold
stuff
and
enjoy
next
stuff
and
and
maintaining
all
of
this
Lua
burden.
B
It's
it's
kind
of
hard
for
us,
so
Jin
Tao,
which
is
the
other
maintainer
that's
in
in
China.
He
does
a
lot
of
things
as
well,
but
the
thing
is
that
if
we
don't
have
more
people
actually
willing
to
maintain
the
lower
part
of
code,
we
cannot
keep
accepting
features.
So
people
ask
us
like
hey:
can
you
have
Canary
by
callers
like
I,
put
the
color,
blue
or
color
red
in
the
query
and
it
like
I,
don't
know
the
impact
of
adding
that
thing.
B
So
if
I
don't
know,
I
cannot
say
hey
I'm,
going
to
maintain
that
or
not
or
if
there's
going
to
be
a
CV
or
not
right.
So
this
is
a
call
for
people.
Actually,
we
need
help
on
this
part
of
the
code.
We
need
help
in
any
part
of
the
code
actually,
but
the
lower
part
is
something
that
for
me
right
now:
it's
a
risk
on
the
project,
because
we
don't
have
enough
people
maintaining
that
and
it's
the
core
of
the
project
right.
So
that's
where
the
load
balancing
actually
happens.
A
And
with
that,
like
I,
said,
call
Action,
we
discuss
all
of
these
things
in
our
Dev
slack
Channel.
We
have
the
user
support
channel
for
folks
asking
questions,
and
then
we
have
the
new
contributor
docs,
where
we're
working
on
trying
to
understand
putting
together,
like
all
of
those
architectures
understanding
how
the
build
works,
and
things
like
that.
So
we've
been
trying
to
put
new
contributor
docs
together.
A
C
Only
one
thing
that
I've
tried
to
use-
and
it
wasn't
supportive,
was
the
amq
support
because
we
have
wrapped
mq
and
we
wanted
to
Route
red
from
queue
stuff
through
ngx
and
that
wasn't
supported
so
I
had
to
do
some
some
stuff
to
handle
it
other
than
that
everything
was
great.
One
question
that
I
have
is:
there
is
some
sort
of
interpolation
with
the
Gateway
API
and
I
know
that
there
is
a
project
right
now
called
Gateway
API?
Can
you
guys
talk
about
this
like?
What
is?
Is
it
going
to
be
a
blend?
B
B
So
you
have
an
Envoy
control
plane
that
deals
with
all
of
the
Gateway
API
objects
and
and
generates
a
data
model
for
a
configuration
model
for
Envoy
Beckett
controllers
right.
So
in
our
case,
what
we
are
looking
for
is
actually
supporting
this
new
brand
API
from
kubernetes
that
Rob
Scott
and
all
of
the
other
folks
from
Sig
Network.
They
are
drawing
and
architecting
I
guess
it
was
in
the
same
room
yesterday
and
it
was
packet
right.
So
we
know
that
we
need
to
to
figure
out
about
that.
We
have
a
bunch
of
questions
of
that.
B
The
problem
is
just
about
a
time
and
prioritization
right,
so
I
was
planning
to
support
a
Gateway
API
and
to
all
of
those
CVS
appeared.
So
my
question
now
is:
do
you
prefer
Gateway
API
or
a
vulnerable
Ingress
right?
So
that's
I
I
do
prefer
right
now
fixing
those
CVS
and
again.
If
someone
wants
to
help
me
and
implementing
the
Gateway
API
help
me
when
I
say
that's
helping
the
community
but
like
mostly
I'm
finishing
the
split,
so
we
need
more
people
willing
to
do
that,
but
we
have
plans.
A
You
you,
like
I,
said
July.
We
said
we
were
going
to
complete
all
those
things
from
the
stabilization
project,
but
yeah
we're
all
you
know
working
on
this
on
our
separate
times
and
I
get
some
time
from
shangard,
because
six
door
does
use
Ingress
nginx,
so
I
get
helpful
from
that
perspective,
but
yeah
I
think
our
prioritization
right
now
has
been
just
the
security
instability
versus
features,
because
that
you
know
nobody
likes
their
certificate,
Keys
being
stolen.
B
It
wasn't
a
popular
decision,
but
someone
had
to
take
that
and
we
decided
like
in
the
community
meeting,
to
take
the
decision
of
freezing
features
and
having
something
stay,
able,
even
if
people
say
yeah,
I'm
gonna
use
another
Ingress,
because
the
support
Gateway
API.
That's
that's
fine
again,
that's
totally
fine
and
we
understand
that.
But
we
need
to
clean
our
house
first,
any
anyone.
D
All
right
just
want
to
say
first
thank
you
for
maintaining
the
project
we've
been
using
it
for
I,
don't
know
five
years,
so
it
I'm
not
sure.
Is
there?
Is
it
an
official
like
cncf,
whatever
the
status
of
the
project
is
incubating
or
something
and
the
other
idea
of
the
how
many
users
the
project
has
like
what
is
the
adoption
rate,
and
maybe
that
can
lead
towards
like
does
this?
Can
the
cncf
help
this
project
become
more
organized?
So
it's
not
just
on
a
few
that.
A
Containers,
yeah,
I,
would
say
and
I
don't
think
it's
a
controversial
topic
when
we
say
that
you
know
all
of
the
projects
need
help
maintainership,
but
you
know
we
got
13.7
000
stars.
There
are
some
other
Dev
stats
that
I
tried
to
pull,
but
we
are
a
sub
project
in
the
Sig
networking.
So
it's
not
a
top
level
project
like
you're.
You
know
like
Envoy
and
other
things
like
that.
So
there's
a
differentiator
from
that
perspective.
A
But
that's
why
we've
you
know
working
with
the
contributor
X
working
with
Sig
release,
understanding
how
we
can
make
things
better.
From
that
perspective,
you
know
working
with
six
security.
Every
time
you
know,
they're,
very
responsive
on
helping
us
figure
out
how
we
triage
these
issues
and
how
do
we
coordinate
the
communication?
So
we
do
get
support
from
the
cncf
projects
and
nginx
is
working
with
us.
We've
been
talking
with
their
product
man,
they
had
a
product
marketing.
There.
D
A
Know
plus
is
different,
but
nginx.
That
was
actually
the
first
topic
that
we
broached
with
nginx.
We
have
an
open
issue:
they
have
a
blog
post
and
we've
been
trying
to
work
through
and
understand
that
so
Ingress
nginx
is
how
we've
been
identifying
the
project
and
then
they
have
the
nginx
Ingress
controller.
A
E
E
Hey?
You
know
we
we
use
this
product.
We
should
dedicate
some
of
our
development
time
towards
contributing
to
open
source,
rather
than
each
person
trying
to
make
that
case
on
their
own,
like
maybe
if
there
was
some
kind
of
template
or
some
kind
of
guide
or
help
to
kind
of
take
that
to
upper
management,
and
you
know,
maybe
just
an
idea
to
get
more
contributors.
A
That
is
a
very
good
suggestion
and
I
will
take
that
I
know
that
Paris
has
been
talking
about
I
think
she
was
in
contributor
X.
She
was
talking
about
that
like
how
do
we
make
the
case
that
it
helps
Advance
the
career
helps.
People
in
you
know
helps
organizations,
you
know
supporting
open
source,
so
we've
got
to
continue
to
have
that
message,
but
having
a
a
solidified
message,
a
template
that
I
think
that
would
be
really
helpful.
A
That's
something
I
think
I'm
going
to
take
the
contributor
X
and
see
what
we
can
do
to
get
that
added.
But
as
far
as
helping
the
project
like
I
said,
we
have
the
new
contributor
docs.
The
community
meetings
are
open
and
available
the
notes
all
there
from
all
of
our
meetings.
So
if
you
have
any
questions
about
doing
that,
I'm
going
to
be
here,
I'm
going
to
be
available,
I'll
be
at
the
chain
guard
booth
at
1
30..
So
if
you
have
any
questions,
just
let
me
know.
A
That's
not
that's
good
enough.
The
if
you
purchase
a
support
contract
from
nginx,
it's
for
the
nginx,
Ingress
controller,
yeah
yeah,
so
not
the
not
not
the
open
source,
yeah.
Okay,
no
problem!
We
get
that
question
a
lot,
so
I
I
know
from
versions
when
someone
asks
a
question.
They
drop
the
version
in
there
I'm,
like
that's,
that's
F5,
that's
not
kubernetes!
So
yeah.