►
From YouTube: Ingress-Nginx Subproject Bi-Weekly Meeting for 20220915
Description
Ingress-Nginx Subproject Bi-Weekly Meeting for 20220915
B
A
Hello:
everyone
it's
jen
strong
today
is
september
15th.
This
is
the
ingress
engine
x
meeting,
which
means
it
is
subject
to
the
cncf
code.
Conduct
means
be
kind
to
everyone.
If
you
have
any
issues,
please
report
those
to
me
or
ricardo
or
someone
in
the
sigma
said
networking
team.
Thank
you
with
that.
Do
we
have
any
new
joiners
today
who
want
to
introduce
themselves.
A
C
A
And
I
unfortunately
didn't
give
a
chan
get
a
chance
to
brief
him
on
the
issue,
but
so
we're
getting
ready
to
do
a
really
big
release.
A
We're
ready
to
do
the
data
plan,
control,
plane,
split,
which
is
a
complete
re-architecture
of
how
we're
running
ingress
engine
x,
and
we
have
some
questions
on
how
we
want
how
we
should
go
forward
with
releasing
branch
management
and
things
like
that,
because
we're
probably
going
to
run
both
the
data
plan,
control,
plane,
split
and
and
non
for
a
little
while
so
we'll
want
a
beta
like
we
did
with
the
v1
split.
So
we
just
wanted
to
discuss
what
your
thoughts
were
on
that
did.
I
cover
the
ask
ricardo.
B
A
So,
carlos,
if
we
wanted
to
run
two
two
simultaneously,
I
think
with
v1
the
v1.
We
ran
two
separate
branches
and
just
released
from
both
of
them,
but
I
think
when
we
removed
the
v1
branch
and
went
into
main
that
caused
a
huge
like
merge
conflict
that
we
had
that
we
ricardo
had
to
fix.
B
Okay,
but
the
when,
if
we
split
in
two
branches,
the
second
one
the
like
doesn't
matter
which
one
but
we're
gonna
merge
to
main
afterwards
or
that's
gonna,
be
our
like
a
separate
live
branch
for
some
time
and
then
just
to
stop
doing
maintaining
that.
A
B
B
A
That
that's
really
what
we
should
be
discussing
should
we
have
cve
fixes
in
a
separate
branch
like
new
130
releases
in
a
separate
branch
and
then
just
keep
dp
of
the
data
plane,
control,
plane,
split.
In
main
that
way,
we
don't
have
that
issue
and
then,
when
we
need
to
release
from
maine
move
everything
over
to
maine,
then
we
just
cherry
picks.
The
cbe
fixes.
B
Like
we
do
like
similar
things
on
the
cluster
api
that
when
like,
for
example,
we
have
an
release
1.1,
we
create
a
release
break
for
that
one
and
things
that
is
in
my
in
the
main
branch
we
cherry
pick
to
the
other
one
as
needed,
and
we
release
both
branches
independently.
B
A
A
C
D
A
Sig
release
engineer
lead
here,
who
can
help
us
fix
that
right?
Carlos.
B
Yeah,
no,
I
I
think
like
if
the
cloud
build
is
only
work
on
the
main
like
we
can
fix
that
like
it
should
work
independently
of
the
the
branch
we
just
need
to
set
up
correctly.
The
the
pro
job
to
point
into
the
correct
break
that
triggers
network
yeah.
B
Just
one
question:
when
we
should
start
working
on
that,
like
we.
A
Haven't
we
have
not
merged
ricardo's
data,
plane,
control,
plane
split
into
main,
yet
I
think
we
probably
should
do
one
more
release.
So
do
like
one
three
three
do
that
release
and
then
that
that
will
we
can
cut
the
branch
and
then
then
we
can
merge
in
data
plane,
control,
plane
and
get
an
alpha
there
are
we.
A
C
Yeah
yeah,
I
I
so
all
of
the
tests
they
are
working
now,
but
without
the
control
play
data
plane.
My
next
step
is
to
start
writing
the
tests.
Exactly
for
the
scenario
where
the
data
plane
is
is
enabled,
so
I've
spent
some
time
actually
fixing
the
tests
to
kind
of
pretend
that
I
was
enabling
the
the
data
plane
and
and
checking
if
when
they
heard,
of
course,
because
yeah
should
occur
because
I
was
enabling
the
data
plane,
but
as
they
weren't
ready
for
the
data
plane.
C
C
I
need
to
write
everything
that
bootstraps
the
environment
as
well,
so,
but
that's
the
next
step
and
and
and
to
be
honest-
I
am
I
am-
I
am
like
kind
of
like
which
share
share
with
like
speech,
feelings
on
merging
and
then
writing
the
tests
on
a
separate
measure,
quest
versus
waiting
for
the
interest,
the
entering
test,
because
it's
gonna
be
a
really
big
pr.
But
I'm
gonna
wait
and
do
everything
at
once
and
we
are
gonna,
have
some
hard
work.
C
B
C
Yeah,
but
I
I
will
have
to
fix
that
anyway,
because
some
commits
they
are
like.
I
am
a,
I
am
an
idiot.
Let
me
fix
this
typo
fixing
the
typo
again,
oh
crap,
another
typo,
but
I
will
fix
the
commits
and
and
at
least
split
in
the
control
plane.
They
are
playing
commit
the
main
one
and
the
end-to-end
test.
A
So
if
you
just
squash
those
into
one
commit,
we
can
tag
that
at
main
and
let
that
be,
we
just
tag
it
something.
So
we
know
where
it's
at
in
maine.
If
we
ever
needed
to
just
go
back
or
is
that
at
that
point,
should
we
before
we
merge
that,
should
we
just
accept,
should
we
just
create
the
130
branch
and
that's
the
split
and
we
don't
need
a
separate
tag
on
main.
C
Yeah
I
mean
I,
I
don't
have
problem
with
the
mesh
conflicts
right
now,
because
we
are
really
slow,
accepting
new
features
right
and
bug
fixes,
so
any
conflict
that
may
happen.
It's
not
gonna
be
some
huge
conflict
and
I
just
ask
you
folks
to
be
careful.
If
you
see
some
bug
fix
that
needs
to
be
merged,
just
just
at
least
being
me
approved,
but
at
least
being
me,
so
you
know
whatever
I
am
conflicting.
C
A
C
A
C
Yeah,
so
I
was
gonna
do
everything
on
this
weekend,
but
I
won't
be
at
home
for
the
whole
weekend,
so
I
will
probably
just
have
some
time
next
week
to
start
at
least
doing
some
end-to-end
tests
and
checking
if
I
can
do
the
end-to-end
tests.
But
how
can
I
say
it
like
on
on
a
really
small
changes?
Just
like
saying
hey,
this
is
data
plane.
So,
instead
of
calling
like
the
local
host,
you
should
call
another
service
or
something
like
that.
C
A
Okay,
that's
fine
well
we'll
just
follow
up
sometime
next
week
and
see
how
you're
doing
and
then
maybe,
if
we
need
to
do
it,
we
can
discuss
at
the
next
community
meeting
if
you're
ready.
So
we'll
just
wait
for
the
next
community
meeting
to
discuss
that
at
merge.
In
the
meantime,
we'll
just
I'll
work
with
carlos
on
cutting
the
the
release
branch
for
one
three
x
and
go
from
there.
A
A
Awesome,
thank
you
carlos
you're,
free
to
hang
out.
If
you
want,
we
go
to
our
next
point.
I
think
the
stale
bot
should
be
our
next
discussion.
A
I
didn't
say
I
really
pushed
back.
I
just
said
that
the
stale,
but
I
think
it
pings
me
when
things
are
stale.
I
get
those
notifications
in
github
and
I
look
at
them.
So
I
think
it's
a
nice
reminder,
but
if
there's
a
different,
I
I
think
he
said
in
slack
ricardo
there's
a
different
bot
that
just
lets
us
know.
Instead
of
actively
closing
it.
C
Yeah
yeah,
so
so
I
I
have
also
split
split
feelings
on
this
on
one
hand,
sometimes
we
just
page
people
and
they
just
abandon
the
issues
or
something
like
that,
and
the
bot
helps
us
on
that.
C
On
the
other
hand,
as
a
contributor
and
as
a
user
of
kubernetes
and
other
projects,
I
get
really
upset
when
I
make
a
contribution
and
no
one
just
cares
and
the
bot
keeps
closing
my
issues
right
so
trying
to
to
have
the
same
empathy
and
bringing
the
same
empathy
and
and
ben
benjamin
elder
also
added
some
some
comments
on
on
on
dpr.
C
I
don't
know
if
you
folks
saw
that,
but
he
was
saying
their
experience
on
unkind
and
and
and
what
he
felt
on
kind
and
what
what
we
should
be
taking
a
look
on
on
on
that
right.
C
So
I
think
we
can
try
to
make
this
as
an
experience
and
and
being
really
having
really
empathy
with
people
opening
issues,
but
also
we
will
probably
need
to
to
to
get
some
time
on
a
weekly
basis
or
on
a
bi-weekly
basis
or
even
me,
on
a
daily
basis
to
close
things
that
need
to
be
closer
than
answering
things
that
need
to
be
like
hey.
We
acknowledge
your
ask,
but
we
don't
have
time
to
work
on
that,
so
feel
free
to
work.
C
Otherwise,
you're
gonna
accept
and
it's
gonna
be
on
our
kiwi,
with
priorities
right,
but
at
least
giving
some
answer
for
people
saying
we
are
not
gonna
leave
this
to
close
and
and
I
die,
because
we
don't
care
but
be
aware
that
we
don't
have
time
to
fix
all
of
the
issues
and
all
of
the
feature
requests
and
so
on.
So
I
think
it's
a
good.
C
I
think
it's
a
good
movement
for
us
and
also
based
on
on
the
survey
that
we
are
still
gonna,
take
a
look
into
that.
But
that
was
one
of
the
complaints
and
I
have
received
this
complaint.
C
Modern
owns
not
only
on
ingress
in
china,
like
I
am
one
of
the
approvers
of
sick
dogs
for
portuguese
as
well
and
people
said:
hey
can't
you
have
more
approvers,
because
we
are
translating
things
and
it's
kind
of
annoying
waiting.
You
and
two
other
folks
just
review
for
us,
and
we
know
that
you
don't
have
time
on
that.
So
I
think
it's
a
good
movement.
I
think
that
for
kubernetes
kubernetes
it's
not
sustainable
to
not
have
stayobot,
because
a
lot
of
things
they
are
just
like.
C
They
have
like
a
hundred
issues
or
so
a
thousand
issues
or
so
right
more.
But
I
think
it's
a
good,
maybe
a
good
approach
to
having,
in
our
that's
a
good
experience
to
make.
In
my
opinion,.
A
I
think
it's
been
closed
twice
and
someone
said
they
were
gonna
pick
up
the
pr
and
I
don't
think
a
pr
was
ever
put
in
place.
So
it's
like
we
do.
We
need
to
have
just
new
rules
that
we
abide
by
that
you
know
it
gets
in
the
queue
or
you
can
put
in
a
pr
yourself
and
we
just
gotta
get
better
at
cueing
and
prioritizing
issues.
C
Yeah,
I
think
so
one
of
the
things
that
we
did
when
we
started
to
do
the
other
roles
was
like
adding
more
approval,
approvers
on
dogs
and
home
shards
and
other
things,
so
the
things
they
they
weren't,
just
like
decisions
from
you
me
or
gentile,
or
like
the
root
approvers
for
foreign
ex
right
and-
and
I
think
that
the
first
I
think
it's
fine
having
more
approvers
and
I
think
that
the
approvers
they
need
to
be
to
have
their
independence
on
approving
and
fixing
and
triaging
issues
just
remind
to
be
fine
with
people
because
they
are
actually
when
someone
comes
to
our
repo
and
opens
an
issue
or
open
aprs,
they
are
actually
thinking
they
can
improve
our
software
right.
C
So
we
need
to
understand
that
thing
like
hey.
We
understand
that
this
is
an
improvement
or
hey.
Thank
you
for
your
pr,
but
we
we
think
this
is
going
to
break
more
than
fixed
things.
So
can
we
do
something
better
on
that
right?
So
I
think
that
we
need
to
to
this
is
my
thinking.
Okay,
I
think
it's
going
to
be
like
good
for
the
community
if
we
stop
closing,
but
still
we
can
add
labels
on
stale
issues
and
stereo
prs,
and
we
can
do
that
using
the
label
common.
C
Any
contributor
can
do
that
right,
like
say
hey,
if
you
see
something
is
stale,
just
add
a
stale
label,
it's
fine
right
and
we
can
add
some
github
action
that
marks
like
hey.
This
didn't
get
traction
for
a
long
time,
so
this
is
still
but
that's
not
close.
C
I
mean
if,
if
you
go
to
this
pr,
you
are
going
to
see
that
I
have
added
in
a
bunch
of
jobs
right.
So
there
is
the
job
for
the
real
thing.
There
is
the
job
for
the
stereo
and
there
is
the
job
for
the
active
or
something
like
that
we
can
remove
from
the
like
from
the
label
rolfin
and
say
we
are
not
going
to
add
the
rotten
and
we
are
not
going
to
close
anymore.
We
are
just
going
to
make
it
stale
right.
C
The
biggest
problem
is
it's
that
the
message
is
the
same
right,
so
the
message
says:
hey.
This
is
going
to
be
closer
than
90
days,
which
is
not
true.
We
are
not
going
to
close
anymore,
so
we
should
define
a
different
pro
job.
Just
for
our
case,
like
saying
this
is
a
different
message.
We
understand
we
are
not
going
to
close,
but
this
is
marking
for
the
contributors
that
this
is
still
right.
B
Two
approaches
you
can
work
on
that.
That
is
not
a
hard
one.
That's
easy
to
achieve.
Okay
sounds
good,
so
just
one
comment
in
I
I
like
this:
not
no,
not
closing
things,
but
do
don't
you
think.
That's
gonna
increase
the
number
of
issues
forever
and
like
we
have
some
issues
that
is,
is
in
a
real
stale
for
like
more
than
three
six
months
and
never
got
to
be
closer.
B
B
C
I
think
that
this
is
a
contract
between
us
and
the
community
like
we
are
not
going
to
automatically
close,
but
if
we
decide
that
we
are
not
going
to
implement
that
we
are
not
going
to
implement
that
because
we
don't
have
time
or
we
don't
agree.
So
please
don't
keep
reopening
that
right
and
I
think
we
can
even
lock
the
issue.
Sometimes
I
think
there
is
a
plugin
to
do
that.
So
we
can
say:
hey
we
we
discuss
it.
C
Then
we
it's
not
going
to
be
like
a
single
dictator
of
like
open
source,
saying
I
don't
agree
with
this.
I'm
gonna
close
and
I
don't
care
so
we
are
gonna,
discuss
between
us
and
say:
okay,
we
are
not
gonna
fix
this
or
we
are
gonna
fix
this
because
we
don't
agree
with
this
issue.
Thank
you
for
the
contribution.
C
Just
don't
keep
reopening
this
because
we
have
our
reasons
and
and
so
on,
and
the
maintainers
decided
on
that.
But,
on
the
other
hand,
we
are
gonna,
take
care
of
the
issues
that
we
agree,
even
if
you're
not
gonna,
think
if
even
if
you're
not
gonna
implement
that
in,
like
short
term
or
medium
term,
but
we
we
are
gonna.
Let
the
users
know
that
that
thing
isn't
our
radar.
So
we
are
not
gonna.
Allow
the
theme
to
close
a
lot
of
those
issues
they
are
just
like.
C
I
have
a
lot
of
pr's
on
my
q,
a
that
I
need
to
review
and
because
I
am
in
this
control
plane
data
plane,
the
aprs
they
keep
getting
marked
as
a
stale
and
then
they
keep
getting
closed
because
I
didn't
review
it
and
that's
not
because
I
don't
care,
that's
because
I
don't
have
time
right
now.
So
right.
B
Yeah,
I
understand
this
point
where
I'm
questioning
the
other
side
like
it's
some
issues
like
we're,
not
not
never
gonna
deal
with
that
as
a
maintainers
or
the
community,
there's
no
one
that
wants
to
pick
it
up.
That
and
like
we
don't
have
time
fixed
committee,
doesn't
is
not
interested
in
fixing
that
and
then
the
issue
like
stays
forever
right
and
just
growing
yeah.
A
A
All
right
I
will
carlos,
is
there
anything
that
we
need
to
do.
A
A
Okay?
Thank
you
gentile's,
not
on.
I
wanted
to
discuss
the
the
121
update
with
open
rusty
and
this
conversation
that's
been
ongoing
for
a
little
while.
A
I
was
looking
through
because
I
was
trying
to
understand
it.
We
don't
just
use
open
rusty.
We
use
specific
different
repos
that
we
pull
in,
because
I
was
looking
at
the
build
script
and
we
pull
in
a
bunch
of
different
repos
from
open
rusty.
So
updating
that's
not
as
simple
as
I
thought
is
that
accurate
ricardo.
C
But
then
we
got
into
that
core
dump
situation
where
people
they
say
hey.
You
need
to
be
with
the
open,
rusty
version
right,
so
yeah
and
it's
not
easy
to
update
so
jintao,
has
a
lot
of
background
with
lua
and
openresty
and
he's
the
one
that
can
answer.
What's
the
effort
on
that.
A
All
right,
I'll
I'll,
follow
up
with
him,
then,
and
just
make
sure
that
he's
got
his
priority,
because
I
mean
that's
one
of
the
things
we
need
to
make
sure
that
we're
doing
is
just
removing
the
cvs
and
making
sure
things
keep
continuously
get
updated.
A
A
I
guess
that,
right
last
but
not
least,
on
the
open
topics
we
wanted
ricardo.
You
wanted
to
discuss
this
one.
C
Yeah
so
f5
announced
a
lot
of
improvements
on
chinax.
I
was
talking
with
carol
last
week
as
well
and
she
asked
me
what
specifically
things
we
want
to
know
or
we
want
to.
We
want
to
do
with
that
right
and
one
of
the
complaints
that
we
have
since
a
long
time,
and
also
one
of
the
reasons
that
we
realized
so
much
on
dua
and
other
things.
C
It's
the
hot
reloads
and
the
the
dynamic
configuration
of
inginx
and
one
of
the
announcements
on
this
is
something
they
call
it
in
gianx,
asians
right
so
carol
told
me
that
carol
is
here,
so
she
can't
speak
by
herself,
but
she
told
me
that
there
is
not
yet
much.
There
is
not
yet
yet
much
on
on
on
the
nginx
agent
to
say
other
than
this
is
being,
I
guess,
developed
or
opened,
or
something
like
that.
C
E
No,
no,
I
I'm
from
I'm
from
f5
engineering.
That's
not
the
reason!
I'm
that's
not
the
only
reason.
I'm
here.
That's
all.
I
just
wanted
to
say
I'm
glad
yeah,
eventually
I'll
I'll
jump
into
contribution
right
now,
I'm
just
in
the
getting
the
lay
of
the
land
kind
of
phase
just
just
to
see.
What's
what
I
can
help
with
and
what
I
what
I
where
I
could
be
useful.
E
And
you're
correct
on
on
the
agent
right
now
there
it's
a
lot
of
they're
trying
to
clean
things
up
and
get
the
user
experience
in
a
positive
spot
before
they
release
it
to
the
to
the
known
universe.
So.
A
C
No,
it's
yeah,
maybe
in
in
in
in
it's
going
to
be
on
the
middle
of
the
path
right
like
the
control,
plane,
programs,
the
inginax
agent
and
some
somehow
the
inginx
data
planes.
They
come
and
reconfigure
that
I
don't
know
how
the
inginax
agent
works.
C
Actually
I
just
know
that's
like
some
rest
api,
I'm
not
sure
if,
if
it's
in
a
pool
model
or
in
a
push
model
or
something
like
that,
but
I
think
the
the
main
idea
is
like
the
end
points
and
the
certificates
and
the
other
things
they
are
not
going
to
be
configured
anymore.
Push
it
to
engine
x,
the
data
plane
right,
so
they
are
going
to
be
dynamic.
C
C
But
I
understand
that
actually,
as
someone
that
works
for
a
big
company,
that
makes
a
lot
of
announcements
and
then
we
have
a
lot
of
engineering
efforts
after
the
announcements.
I
understand
that
they
need
some
time
to
figure
out,
what's
going
to
be
provided
for
the
community,
so
I'm
fine
with
that.
So
as
soon
as
you
folks
have
some
more
information
for
us
like
hey
here
are
the
documentations.
We
can
do
some
proof
of
concept
just
showing
how
this
works.
I
would
like
to
listen
more
about
that.
E
Okay,
yeah,
I
mean
that
that
that
that
sounds
reasonable.
I
think
the
separate
the
separation
of
management
and
control
is
is
in
the
same
vein
of
wha
you're.
Thinking,
I
think,
is,
is
mostly
accurate,
I
would
say,
but
I
think
it's
not
really
worth
discussing
until
you
have
some
code
to
look
at
in
my
opinion.
That
way
you
can.
You
can
give
us
your
opinion
on
whether
or
not
you
see
useful
you
see,
use
in
it
or
not,
and
then
we
can
move.
E
A
E
Yeah
we
met
with
the
pms
for
that
last
week.
I
think
to
kind
of
get
this
get
the
skinny
on
it
and
they
were.
They
gave
us
the
you
know
we're
they're,
we're
it's
it's
actively
being
worked
on,
so
I
can
say
that
it
wasn't
just
like
a
nebulous
promise
and
then
we're
gonna
get
around
to
it
when
we
feel
like
it
it's
actively.
So
that's
a
that's.
A
positive
note
is
that
it
is
actively
being
worked
out.
E
A
E
E
No
marisol
was
on
that
call
yeah.
That's
right!
That's
right!
I
have
the
transcript
I
I
was
reviewing
it
this
morning
and
there
wasn't
a
lot
of
me
on
the
bone
there.
So.
A
That's
that's
fine
quarters
are
good
too
we'll.
Just
we
can
open
up
an
issue
and
watch
it.
Go
stale.
A
D
Dylan
a
curiosity
question:
does
the
nginx
team
clearly
recognize
the
problem
that
when
the
config
is
too
much
like
at
least
the
controller
users,
they
have
talked
about?
There's
one
issue
right
now:
it's
in
thousands,
so
they
have
like
2,
000
or
3000
ingress
rules
to
be
reloaded.
E
I
don't
know
the
answer
to
that
question.
I
I
would
poke
jason
to
see
if
he
has
any
feedback
on
that,
but
I
actually
don't
know
if
we
recogni
what
the
what
the
engine
next,
because
I
work
for
the
business
development
or
not
the
business
of
the
community
team
and
not
on
that
actual
dev
team.
But
I
can,
let
me
take
a
look
at.
A
Thanks
for
bringing
up
one,
I
know
I
saw
another,
I
saw
an
issue
earlier
in
the
week
where
somebody
said
they
had
a
thousand
ingress
objects
and
they
just
kept
getting
500s
during
the
reload.
So
I
know
it's
a.
I
know
it's
an
issue
awesome.
Well,
we've
been
through
all
the
open
up,
open
topics.
Should
we
go
into
the
stabilization?
D
D
D
C
Yeah
the
thing
that
I've
kept
so
the
thing
that
I
keep
seeing
is
and
your
boss,
james
made
a
great
discussion
on
that-
is
that
people
they
are
relying
on
different
scholars
right,
like
disconnect
from
the
cloud
provider
to
say,
hey.
This
is
vulnerable
when
they
are
just
like
checking.
C
If
there
is
some
library
that
exists
because
of
like
transitive
libraries,
but
they
are
not
being
used
right,
I
I
think
that
all
the
cvs
they
matter,
I'm
just
worried
that
we
are
getting
buried
by
a
lot
of
like
cve
reports,
that
they
are
not
real
cd
reports.
They
are
just
like
hey.
I
have
passed
this
gunner
than
this
scanner
and
it's
reporting
me
the
cve.
C
So
go
ahead
and
fix
it
right,
and
this
is
why
I
got
really
excited
by
the
announcement
of
the
gold
team
on
the
gold
film
stuff,
because
that
that
scanner,
I
would
actually
rely
on
because
they
cannot
say
hey,
you
use
the
vulnerable
part
of
the
code
or
you
don't
use
the
vulnerable
part
of
the
code.
So
don't
you
don't
need
to
take
care
of
that
right.
A
C
It
doesn't
do
for
us,
it's
it's
a
new
product
that
it's
a
new
program
that
the
goal
and
team
they
are
announcing
and
it
will
do
that
it
will
just
check
hey
your
code
touches
a
part
of
the
code
which
is
vulnerable
or
not
right.
So
the
same
thing
happened
with
some
kubernetes
library.
I
guess
on
the
next
meeting
we
discussed
about
that
like
we
are
using
kubernetes
1.24
and
it
reports.
C
I,
like
us,
really
severe
vulnerability,
but
it
ended
being
like
kubernetes
didn't
touch
that
part
of
the
code,
so
jordan,
legit
and
teams,
they
had
to
say
hey.
We
are
not
going
to
release
a
new
version
right
now,
because
our
code
doesn't
touch
this
right.
So
I
think
that
what
go
vulnerability
program
does
it
something
like
that?
I
and
I
would
love
to
rely
on
that
thing.
C
At
least
so
we
don't
get
worried
because
I
keep
seeing
like
on
a
daily
basis,
reports
on
on
cves
on
our
packages
right
because
some
scanners,
some
cloud
scanner,
something
like
that
reported
that
thing
and
it
ends
up
being
just
like.
Okay,
we
are
always
gonna
have
libraries
vulnerability.
They
appear
all
of
the
time.
Right
we
need
actually
to
know
go
for
me
is
just
becoming
some
node.js
or
like
java.
C
You
just
have
a
lot
of
libraries
and
you
just
need
to
decide
if
you
want
to
live
with
that
cv
or
not
right
so
yeah
I
would
like
I
I.
I
would
like
to
be
really
sure
that
whenever
we
receive
some
cv
report,
it's
a
cv
report
of
a
call
that
we
use
like
we
are
receiving
things
from
end
to
end
tests
like
hey.
We
don't
produce
end-to-end
tests
so
yeah,
but
your
code
compiles
using
that
library.
I
mean
it
doesn't
touch
that
part
of
the
code
right.
D
A
D
C
But
this
is
this
is
the
discussion
here
that
I
that
I
saw
from
from
dan-
and
I
think
it's
fine,
so
each
vulnerability
scanner
reports
different
vulnerabilities
right
and,
if
we
just
like
and
and
they
do
like
some
of
them,
they
report
debian
vulnerabilities,
where
there
is
no
debian
in
in
the
image
as
an
example.
But
they
do
are
like
old
gold
grpc,
something
protobuffer,
because
the
protobuffer
contains
something
old.
So
I
think
it's
fine,
but
I
think
that
we
need
to
be
just
really
careful
on
what
matters
for
us
on
the
vulnerability
right.
C
So
on
the
go
code,
it
just
matters
for
me
the
the
vulnerability,
the
vulnerability
of
parts
of
the
code
that
we
touch
and
in
china
x.
It
does
matter
for
me.
I
think
ginax
releases
a
vulnerability
off
in
ginex,
because
it's
not
something
that
we
control
right.
So
it
may
be
a
future
future
that
we
use
for
the
libraries
on
on
on
on
the
image
that
we
use
and
I
really
want
to
be
distributed
in
the
future.
C
A
C
C
A
A
Yeah,
because
that
can
also
be
the
other
thing
we
can
just
have
them-
attach
an
ephemeral
container
and
do
their
testing
from
there.
So
when
we
do
move
the
move
to
distrelis
that
also
solves
that
problem,
so
I
wouldn't
consider
it
a
breaking
change.
I
would
just
consider
it
some.
It
changes
how
you
do.
Testing
yeah.
C
A
Oh,
I
was
idle
in
the
zoom.
Sorry
that
was
a
zoom
message,
not
not
a
a
meeting
anyway.
I
don't
think
we
have
enough
time
to
start
triaging
issues.
Unfortunately,
we
already
know
where
we're
all
at
with
the
stabilization
projects.
I'm
gonna
go
ahead
and
yeah
I'll
open
that
issue
to
that
recovery.
Thank
you
for
posting.
A
It
I'll
go
post
those
issues,
I'll
I'll,
do
the
wrap
up,
and
maybe
we
do
like
you
said
once
we
get
the
stamp
the
new
sailbot
in
place,
that
that
should
be
one
of
the
first
things
we
start
checking
instead
of
skipping
it
because
we
we
have
been
in
the
habit
with
the
project,
stabilization
stuff
in
the
dp
and
all
of
the
things
we're
doing
of
skipping
the
triaging
of
issues.
A
C
One
one
last
thing
we
are
having
in
cubeconde
falk
and
me
and
james
like
I.
I
still
need
to
start
preparing
my
talk
with
carlos
and
I
need
to
prepare
my
talk
with
james
as
well,
but
I
think
if
we
can
put
something
together
already
james
and
provide
the
slides
the
preview
of
the
slide.
C
So
if
someone
wants
to
add
something,
because
this
is
a
community,
a
a
community
presentation,
we
would
like
to
invite
you
folks
to
to
contribute
on
on
those
slides
as
well,
because
they
are
going
to
be
actually
how
we
present
the
the
project
health
for
the
community.
C
I
think
that's
gonna
be
fine
as
well
james.
If
we
can
consolidate
the
data
that
we
receive
it
from
josh
yesterday
up
front
and
and
sent
to
folks
on
the
ingredients
next
dev.
So
we
can
also
discuss
the
roadmap
that
we
want
to
present
on
on
cubecon.
A
B
A
E
Gents
a
couple
of
things
I
I
actually
will
be
at
kubecon.
I
just
found
out
last
week
that
I'm
they're
gonna
send
me
to
detroit.
So
that's
just
as
an
fyi.
The
other
thing
is,
is
I'm
looking
through
the
community
group
stuff
and
I'm
trying
to
find
the
the
the
sig
meeting
stuff
and
I'm
for
some
reason
not
able
to
locate
it.
I
mean
what
should
I
be
looking
for
here.
E
Yeah
I'm
on
the
kubernetes
contributor
site
and
I
was
just
trying
to
find
it
because
I'm
trying
to
figure
out
where
can
I
request
the
slack,
invite
and
get
access
to
documents?
I
mean
I,
I
see
all
the
stuff
on
github.
The
other
thing
too,
is
you
mentioned
that
there's
an
issue
around
the
reload
or
I
don't
know
if
it's
a
reload
issue
or
if
it
was
the
reference
to
a
recent
issue
about
the
failure,
that's
happening
with
large
numbers
of
instances.
It's
in
the
slack,
oh,
is
it
okay?
A
What's
that
I'll
show
the
doc
with
you
post
all
of
the
meeting
notes
and
then
I'll
get
you
a
slack
invite.
A
All
right
but
yeah,
I
don't
know
the
invites
just
that.
Is
it
just
slack
that
kubernetes
that
I
o?
I
don't
remember.
E
It
should
be
dylan.turnbull,
I
think
at
gmail.com
is
what
well
actually
let
me
look
at
it
and
see
which
one
I
have
up
there.
A
Okay,
yeah,
I
think
that's
you.
A
A
Okay,
awesome:
well,
we
appreciate
the
help
and
we're
time
folks
thanks
everyone
for
joining
and
discussing
the
issues.