►
From YouTube: [SIG-Network] Ingress NGINX meeting 20210525
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
Hello:
everyone-
this
is
a
sig
network,
ingress
nginx
sub
project
meeting
today
is
the
25th
of
may
2021.
This
is
a
kubernetes
community
meeting
and
we
ask
you
to
comply
with
the
code
of
conduct,
which
would
basically
be
excellent
with
each
other.
If
there's
any
violations,
please
report
those
to
the
sig
chair
or
the
person
running
this
meeting,
aka
me
or
ricardo.
A
If
it's,
if
you
have
an
issue
with
me
anyway,
we've
got
to
we've
got
a
couple
of
big
things
that
we
need
to
talk
about,
but
let's
go
ahead
and
welcome
some
of
our
newer
members.
So
anyone
who
is
on
the
call
that
would
like
to
introduce
themselves
and
talk
about
their
experience
and
what
they're
looking
to
help
with
go
ahead
and
go
on
unmute
and
we'll
start
there.
C
D
D
A
E
E
So
since
last
1.5
years
I
mostly
contributed
in
ingress
engineering,
either
its
dog
pr
or
small
bug,
fixes
and
analyzes
issues
and
all-
and
I
am
also
I
started
working
in
q
proxy
also
so
there
also,
I
am
contributing
and
my
main
motive
is
to
contribute
as
much
as
possible.
It
means
even
I'm
not.
I
tried
in
last
series
also
to
contribute
few
features
in
ingress
engine
x,
but
unfortunately,
after
doing
some
work
and
after
discussion
it
was
not
metallized,
so
it
hadn't
got
submitted
yeah,
but
my
motive
will
be
some
quality
fixes.
A
Well,
thank
you
for
that.
We
appreciate
your
help
from
that
perspective,
so
hopefully
we
can
get
some
of
those
features
pushed
through
after
we've
talked
through
some
of
the
other
issues.
I
know
that
are
facing
us
right
now,
so
right
about
time.
From
that
perspective,
ricardo,
do
you
want
to
should
we
go
ahead
and
skip
issue
triage
and
really
go
into
the
the
big
concern
that
we
have
right
now?
From
that
perspective,.
B
D
B
I
don't
know
if
everybody
knows
but
ingress
ingress,
lingerie's
object
was
created
as
an
extension
as
an
extension
into
the
api
group
extensions
and
that
then
later
it
was
migrated
from
to
a
specific
api
group
inside
inside
kubernetes,
which
is
networking,
kubernetes,
io,
slash,
v1,
beta1
and
most
recently
I
think,
wasn't
120
or
119.
It
was
graduated
to
ga.
So
it's
on
viewer,
but
during
this
migration
some
some
fields
have
some
fields
from
from
from
the
specs
they
they
have
changed
and
and
also
some
behavior
have
changed.
B
So
we
got
the
ingress
class.
We've
got
the
the
path
type
and
also
the
the
the
service
field,
which
is
not
anymore
servicing
name
and
service
support.
But
now
it's
a
cersei
field
where
you
put
the
name
and
the
part
or
the
port
name
and
those
are
breaking
changes
and
those
are
breaking
changes
from
the
from
the
cuban
behavior
or
they
are
like
pretty
hard
to
maintain
two
code
bases
inside
inside
ingress
controller
or
even
having
like
a
conversion.
B
B
He
asked
me,
but
he
asked
other
folks
about
if
we
are
not
going
to
move
the
support
from
ingress
in
ginex
from
v1
bit
better
one
two
v1,
because
on
the
next
release
of
kubernetes,
which
is
v122
v1,
better
one
is
going
to
be
deprecated
and
the
api
is
not
going
to
serve
it
anymore.
So
the
only
api
that's
going
to
be
served
about
the
ingress
object
is
going
to
be
the
v1
which
has
these
these
changes.
Okay,
so
so
I
I
brought
this
here
because
I
wanted
to
discuss
with
you.
B
I
think
we
have
we.
We
have
some
some
issues
and
some
pr's
to
deal
with,
but
on
the
same
time,
yeah.
This
is
the
issue
and
then,
at
the
same
time,
I
guess
it
it's
required
that
we
start
supporting
the
v1
api.
Otherwise
we
are
going
to
be
the
official
project
and
probably
the
only
one
from
the
ingress
controllers
that
does
not
support
the
v1
api
right.
B
But
to
do
that,
we
will
need
to
deprecate
the
support
for
kubernetes
versions,
which
are
less
than
1
19,
and
we
have
to
make
some
deprecation
plan
and
some
communication
plan
and
probably
other
things
that
I
forgot
to
say
so
I
have
opened
a
pr
to
migrate
from
v1
beta1
to
v1,
which
is
not
not
finished
yet.
I
still
have
to
change
the
main
part
of
the
controller
and
the
e2e
tests.
B
It's
on
the
few
requests.
It's
a
huge
one.
I
spent
my
weekend
doing
that
and
yeah
this
one,
so
this
is
gonna
be
fun
to
review,
who
wants
to
review
this
one?
It's
gonna
be
pretty
pretty
fun
but
yeah.
So
so
mostly,
I
wanted
to
bring
this
discussion
to
you
folks
to
see
what
what
is
our
timeline
about
these.
We
need
to
be
sure
that
we
are
going
to
communicate
folks
about
this,
because
it's
going
to
bring
some
impact
for
folks
using
kubernetes
using
kubernetes.
B
Probably
we
are
going
to
have
to
cherry
peek
into
that.
So
maybe
I
was
carlos
is
not
here,
but
maybe
I
was
wondering
if
a
good
strategy
would
be
that
we
have
like
version
zero
dot,
something
which
uses
v1
better
one
and
version
one
dot,
something
which
uses
the
the
api
version
one
and
bugs
and
cds
and
other
things
we
share
it
big
to
older
versions.
Otherwise,
you're
gonna
follow
this
new
version
and
yeah.
There
is
a
lot
of
things
to
discuss,
so
I
wanna
hear
you
folks
as
well.
What
do
you
think
about
that?
A
This
I
mean
this
is
a.
This
is
one
of
them,
one
of
the
things
since
I
think
the
past
month,
since
I've
been
trying
to
help
get
an
understanding
of
where
we're
at.
But
we
definitely
there
are
lots
of
older
issues
from
that
perspective
and
there's
lots
of
older
versions
of
kubernetes
that
they're
using.
So
this
will
help
from
that
perspective,
pushing
that
forward.
A
C
B
Yeah,
mostly
mostly
critical
books-
and
I
I
guess
we
could
establish
also
a
a
window
for
that
like
we
are
gonna
support
these
for
the
next
six
months.
So
please
migrate,
folks
to
newer
newer
cluster
versions,
just
because,
if,
if
we
find
some
security
issue
or
something
else
we
can,
we
can
import
these
two
to
previous
versions.
Instead
of
saying
to
people
hey.
C
B
B
All
of
those
things
also,
the
automated
cherry
peak
tool
that
that
kubernetes
have
so
probably
it's
gonna,
be
it's
not
gonna,
be
easy
to
use
it,
but
it's
gonna
be
the
same
process
that
we
already
have
in
in
kubernetes,
maybe
mean
ripo,
which
is
like
someone
makes
a
path
and
points
to
a
specific
branch,
and
we
say:
okay,
this
branch
is
gonna.
Now
have
this
path,
so
you
can
put
a
release
into
both
of
those
those
paths
both
of
those.
B
B
B
B
I've
asked
wayne
to
take
a
look
into
that,
but
probably
this
is
going
to
be
reversive,
so
I
I
was
wondering
if
we
in
at
this
moment,
if
we
want
to
keep
accepting
future
requests
right
now
or
if
we
should
focus
on
squashing
the
bugs
and
saying
hey.
Okay,
we
have
a
stable,
we
have
a
stable,
a
stable
version,
so
we
can
cut
the
release
and
say
this
is
the
this
is
the
this
is.
B
A
It
doesn't
yeah,
I
mean
I
think
that
goes
in
line
with
our
previous
comments
around
just
having
a
if
we're
doing
a
separate
branch
and
we're
only
doing
bug
fixes
we
shouldn't
be
implementing
new
features
into
a
an
older
version.
So
I
I
agree
that
we
shouldn't
be
putting
new
features
into
the.
I
think
one
d46
right
now.
A
Yeah
there
I
I
agree,
a
lot
of
the
older
ones
have
been,
I
think,
in
like
v30
versions
and
misconfigurations.
From
that
perspective,
even
from
the
last
meeting
that
we
had,
there
was
a
lot
from
that
perspective,
so
we
still
got
a
lot
of
follow
up
on.
I
think
we
covered
maybe
a
10
or
12
of
the
older
ones,
and
I
say
old-
we're
talking
a
year
plus.
A
So
I
think
if
we
go
into
that
communication
plan
and
talking
about
deprecations
of
just
being
able
to
support
119
and
following
other
projects,
I
you
know
I
I
understand
that
that's
going
to
be
an
issue
for
folks
using
older
versions
and
can't
upgrade
their
clusters,
but
we
from
the
scale
that
we
have
and
the
folks
that
we
have
helping.
We
can't
continue
to
support
all
diversions
from
that
perspective.
C
B
G
So
I
think
it's
fine
for
the
group
to
basically
say
hey,
there's
going
to
be
a
stabilization
release.
Is
there
probably
hasn't
been
one
in
the
life
of
this
project
and
the
other
one?
Is
that
a
big
fan
of
this
idea
like
if
you
want
to
put
something
in
you,
have
to
take
something
out
so
like
you
can
fix
a
bug
before
you
put
a
new
feature
in
kind
of
making
that
at
least
for
the
for
the
current,
like
one
cycle,
so
that
it's
just
not
people
landing
features
and
then
kind
of
leaving?
G
Yeah,
I
think
like
just
given
where
the
project
is.
It
is
worth
saying,
like
hey,
we
are
at
a
point
where
we
would
like
to
just
stabilize
the
existing
stuff
to
get
rid
of
the
queue
and
then
take
new
features,
and
if
you
are
really
into
it,
interested
in
adding
a
new
feature.
Like
you
know,
this
is
the
opportunity
to
sign
up
for
taking
care
of
some
of
the
existing
bugs.
F
Yeah
again
just
my
two
cents,
people
argue
a
lot
and
talk
and
describe
a
lot
of
stuff
so
why
they
require
things.
So
I
think,
if
we
are
very
explicit
in
saying
here's,
the
heart
dependency,
that
if
we
start
the
things
that
are
absolute
priority
right
now,
will
impact
any
pre
1.19
users.
So
that's
the
reason
we
are
taking
this
approach
because
that's
helpful
and
if
somebody
and
then
we
can
also
will
be
very
explicitly
saying
it
on
either
documentation,
page
or
somewhere
saying.
F
F
F
So
some
kind
of
communication,
because
what
ricardo
said
really
made
a
very,
very
big
difference
now,
because
earlier
people
were
talking
about
backboarding
fixes
and
all
that,
but
now
that
we
have
to,
we
have
to
go
into
this
message
where
pre
119
is
going
to
be
a
problem
either.
That
is
our
current
thought.
That
is
our
current
solution.
That's
the
current
known
best
approach.
Somebody
else
can
come
up
with
a
better
approach.
G
F
There
seems
to
be
a
small
section
that
say
they
are
stuck
on
a
certain
version
of
kubernetes
because
of
the
provider,
and
then
they
are
stuck
on
a
certain
version
of
the
controller
itself
and
they
don't
want
to
upgrade,
and
yet
they
want
a
feature
or
a
bug
fix
for.
So
I
think
for
that
community,
explicit
communication-
I
just
thought
it
would
be
nice
yeah
survey-
would
be
good.
G
G
B
But
it's
not
clear.
Yes,
sorry
so
this
was.
This
was
something
that
we
were
discussing.
If
it's
worth
to
put
this
into
a
different
branch
and
say
hey,
we
are
going
to
support
this
for
more
six
months,
but
only
for
bug
fixes
security
bug
fixes.
So
you
have
six
months
to
migrate
from
your
old
cluster
to
needle
right,
because
kubernetes
kubernetes
supports
only
three
releases
behind,
but
we
know
that
cloud
providers
they
support
a
bit
more.
So
I
know
that
I
think
google
is
on
117
or
118.
B
Amazon
also
have
some
some
older
versions,
so
I
am
pretty
sure
that
probably
there
are
some
folks
using
increasing
ginx
inside
those
manager
kubernetes
instead
of
using
the
ingress
from
the
call
provider
and
for
those
users
this
might
be
a
problem
right.
So
I
I
I
was
wondering
if
maybe
we
should
do
the
the
same
thing,
that's
done
in
kubernetes
and
saying:
hey:
okay,
we
are
gonna.
We
are
gonna,
keep
this
for
the
next
six
months,
but
only
for
only
for
like
cves
or
bug
fixes.
G
F
I
can
probably
search
and
come
up
with
some
issue
urls
to
issues
numbers.
Somebody,
I
think,
is
right
now
with
the
open
issue
on
33
somebody
else
on
35,
but
I
think
the
objective
of
this
conversation,
I
think
we
are
saying,
is
at
least
the
way
I
am
saying
it
is
that
there
is
no
place
on
the
documentation
or
anywhere
else
where
we
are
explicit
about
this
and
now
because
of
this,
this
requirement
that
we
need
to
start
working
with
v1
by
time.
122
is
out.
G
G
F
Right
and
on
a
side
note
that
will
also
be
useful
that
we
are
all
aware.
We
all
just
become
aware
of
it
like
consciously
aware
of
it
and
when,
when
somebody's
submitting
issues
that
comes
under
that
scope,
that
either
the
controller
version
is
old
or
the
feature
the
requesting
or
the
pr
submitting
is
hitting
this
kind
of
scope,
then
we
just
point
them
to
that
explicit
communication
on
documentation
or
wherever
we
tell
them.
We
have
to
be
very
clear
about
it
and
it's
not
right.
F
Now:
it's
not
clear,
it's
not
explicit,
so
we
just
tell
we
just
as
a
as
a
group
people
in
this
meeting,
I'm
a
big
fan
of
all
you
guys
so,
but
we
we
are
not.
I
mean
I'm
seeing
jintao
and
everybody
addresses
issues,
so
I
think
we
should
just
be
conscious
and
communicate
that
to
people
who
create
issues.
G
H
G
G
F
I'm
willing
to
do
whatever
possible.
I
like
what
I
said:
I'm
not
a
developer,
so
I
think
I
think
somebody
kicks
off
the
pr
which
is
modification
of
the
home
page
of
the
documentation,
and
I
think
over
the
course.
The
whole
pr
process
itself
should
keep
getting
refined
and
I
think
the
words
will
come
up
from
there.
D
G
A
So,
let's
start
let's
say
since
I'm
typing,
let
me
make
sure
I
understand
so
our
direction
that
we
want
to
go
forward
with
is
that
we
will
support.
We
continue
to
support
n
minus
three,
like
the
kubernetes
project,
new
features
into
n
minus
three
versions
for
ingress
and
anything
older
than
that
only
gets
bug
fixes
for
six
months.
So
if
issues
get
open
for
new
features
on.
F
F
Ricardo
actually,
the
essence
of
that
communication.
I
think
I
really
liked
from
what
ricardo
put
out
both
in
the
pr
and
in
the
messages
in
slack,
so
just
a
wording
about
bug,
fixes.
Let's
and
today
ricardo
said
one
more
thing
very
clearly
cve.
So,
let's
not
say
bug
fixes,
let's
just
say
cve,
so
only
only
only
cv
cvs
will
come
in,
but
no
nothing
else.
So
I
think
just
let's
get
explicit
on
that
cve.
Only
okay.
F
I
like
to
see
I'm
very
new
to
this,
so
I'm
very
sorry
if
I
can't
be
too
efficient
at
this,
but
my
thought
the
thought
is
coming
from
at
least
one
or
two
issues
that
are
open
right
now
and
the
root
cause
of
the
issue
is
that
they
have
really
huge
implementation,
like
they
have
over
a
thousand
ingress
objects
and
they're
using
they're
talking
about
thousands
of
hosts
and
so
on.
Just
there's
a
size
of
the
config
engine
engine
is
gone,
reloading,
taking
minutes
and
all
that
so
we're
talking
about
that.
F
Those
are
the
only
two
use
cases
of
only
two
circumstances
where
we
should
try
to
work
on
an
older
version,
at
least
say
in
the
communication.
That
is
what
I
was
hinting
at.
I'm
sorry.
My
thoughts
are
not
very
clear,
but
the
worry
is
just
that
that
that
part,
I
said
you
know
old
version
complicated
and
one
only
one
user
or
maximum
two
users,
three
users,
and
and
for
that
the
effort
is
not
going
to
be
worth
it.
D
G
Yeah
at
least
the
definition
of
cv
is
fairly
precise
in
that
it
goes
into
the
cv
database.
So
that
one
is,
I
think,
well
known,
I
mean
in
the
end,
it's
like
a
human
triage
process,
but
we
should
definitely
say
that
cpus,
probably
for
sure,
unless
it's
extremely
old
and
then
we
will
bias
towards
not
just
taking
all
the
bug,
fixes
and
backboarding
and
just
that's
not
realistic
for
a
project.
F
B
So
I
I
I've
added
some
suggestion
that
that
james
is
reproducing
that
might
be
we
with
those
two
development
branches,
the
view
and
better
one.
We,
we
said:
hey,
okay,
we
are
gonna,
keep
this
one
only
for
I
don't
know
the
the
right
wording
right
now
with
the
cves
and
critical
bug
fixes
with
the
human
triage
and
the
currently
the
current
branch
that
we
use
for
v1,
we
can
say:
hey
we,
we
only,
we
only
answer
for
issues
with
versions
less
than
two
or
three
releases.
B
B
The
the
only
thing
that
we
need
to
be
be
careful
about
this
approach
is
about
the
the
how
many
releases
we
make
during
a
month
or
a
year
right
how
many
major
releases
we
we
make,
because
kubernetes
have
have
a
specific
time,
time
time
time
releasing
timing
like
we
make.
We
are
always
going
to
make
three
major
releases
per
year
in
kubernetes
right,
but
if
we
decide
like
to
keep
cutting
release
before
we
release
release
after
release
after
release
and
then
say,
hey,
we
only
support
three
three.
This
is
back
from
this
one.
F
G
Yeah
my
my
feeling
is
like
we
should
just
not
be
very
aggressive
for
now
in
terms
of
getting
the
project
settled,
because
you
can
only
have
a
really
aggressive
one.
If
there's
a
lot
of
active
development
and
the
release
process
is
very
smooth
and
well
known,
and
you
know,
the
whole
community
is
kind
of
locked
in
yeah
that
that
would
be
my
suggestion,
but
we
do
need
to
give
probably
a
more
stable
kind
of
interval.
G
F
G
B
Yeah
yeah,
I
guess
it's
gonna,
it's
gonna,
we
are
gonna,
put
some
some
breaks
into
until
future
release,
but
at
least
we
we
are
going
to
have
more
time
to
work
on
bug
fixes
and
we
can
revisit
that
later.
Like
say:
hey
yeah,
we
we
are
now
having
like
a
good
time.
Nothing
new
happens,
so
we
can
probably
accelerate
the
release
again.
I
G
A
A
B
A
A
G
G
B
We
can
we
can
at
least
into
the
body
cpr
we
can
get
some
some
feedback
like
make
the
same
thing
as
tim
is
doing
with
the
with
the
all
part
caps
and
ask
for
c
contributor
experience
and
the
cncf
impartial
ambassadors
to
say:
hey,
we're,
gonna
change
the
policy
release
for
ingress
university
nx.
Please
be
aware
and
comment
into
this
pr.
A
Okay
and
then
yeah
the
real
cycle.
I
like
the
idea
of
just
after
we
get
through
the
stabilization
period
just
working
through
and
getting
on
the
same
release
cycle
as
the
kubernetes
project.
Just
to
make
it
easier
on
us
from
that
perspective,
and
if
we
don't
have
anything
new
to
release,
then
we
don't
need
to
do
a
release,
but
that's
my
opinion
and
we
can
work
through
that,
probably
the
later
half
of
the
year
once
we
get
through
this.
A
Okay,
so
carlos
you're
going
to
keep
working
on
122
the
the
v1
fix
I'll,
follow
up
with
carlos
on
slack
and
we'll
have
that
conversation
in
the
dev
channel,
so
everyone
can
see
it
and
I'll
put
out
a
pr
this
week
that
puts
the
the
phase
the
phrasing
in
there
for
the
stabilization
release
and
we'll
just
cycle
through
that
and
I'll
follow
up
with.
Who
did
you
say
we?
I
should
follow
up
with
it
wasn't
sick
contribute,
it
was.
Was
it
sick,
documentation.