►
Description
[SIG-Network] Ingress NGINX Bi-Weekly Meeting for 20220721
A
Hello,
everyone
today
is
july
21st.
This
is
the
ingress
and
genetics
sub
project
meeting
of
sig
networking,
which
means
that
it
is
subject
to
the
cncf
code
of
conduct,
which
means
be
awesome
to
each
other.
If
you
have
any
issues
with
anyone
in
the
meeting,
please
report
those
to
the
maintainers
or,
if
it's
with
us,
please
report
that
to
the
cncf
and
signed
networking
chairs.
Thank
you
I'll,
go
ahead
and
get
started.
I
see
a
couple
new
names
or
maybe
names
that
haven't
been
in
a
while.
A
So
if
you'd
like
to
introduce
yourself
to
the
group,
go
right
ahead,
if
not,
we
can
just
roll
into
some
of
the
updates.
A
Hi
james
hi
everyone,
so
I'm
harry
so
I
have
joined
the
last
meeting
and
I
have
started
working
on
some
of
the
issues
recently
created
few
pr's
and
hope
to
learn
more
on
this
thing.
A
All
right,
we
can
go
ahead
and
move
on.
Ricardi
said
you
wanted
to
drop
the
line
for
the
issue
triage
and
talk
about
the.
B
A
B
Do
yeah
I
keep
doing
that
because
anyway,
unless
the
issues
that
we
have
they
are,
we.
B
Right
now,
I'm
being
a
jerk,
I
just
care
about
the
the
ones
that
are
related
to
the
stabilization
and
bug
fixes.
So
so
I
wouldn't
just
look
into
the
features
right
now,
at
least
for
my
site
right.
A
B
Yeah,
so
here
it
is
so
I
have
started
working
on
these
and
and
I've
been
I,
I
opened
a
pr
to
move
things
to
the
right
places
and
I
have
a
bunch
more
of
those
actually.
I
I
have
started
working
on
this
in
a
single
branch,
but
I
think
it
would
be
better
if
I
can
just
cherry-pick
and
move
those
the
new,
the
other,
the
other
cleanups,
that
I've
been
doing
two
different
pr's.
B
Otherwise
it's
gonna
be
a
huge,
a
huge
massive
pr
for
just
to
split
control,
plane
and
data
plane.
B
I
have
put
some
document
on
the
architecture
choices
that
we
need
to
make,
and
and
so
there
is
a
a
proposed
solution,
but
there
is
not
final,
not
not
final
conclusion
on
that,
so
I've
sent
on
the
channel,
and
I
really
hope
that
people
can
can
take
a
look
into
the
document
and
discuss
because
there
are
some
important
discussions
like
which
which
approach
should
we
use
like
grpc
or
xds
and
and
and
those
are
gonna.
B
B
Yeah,
sorry,
let
me
let
me
add,
the
link
in
the
zoom
chat
just
just
a
second
and
copy
yeah
sure.
So
here
it
is
yeah.
So
that's
that's
in
zoom
chat.
A
B
So
the
first,
the
first
problem.
So
so
it's
not
it's
not
as
hard
as
I
think
at
least
to
separate
into
two
or
three
programs
right.
So
as
soon
as
we
have
well
define
it.
B
What
what
each
component
should
do
and-
and
I
try
to
be
really
explicit
on
that-
I
know
that
as
an
example,
the
sorry,
the
data
plane
should
never
import
any
kubernetes
library
unless
that
that
that
kubernetes
library
is
some
util
or
something
like
that.
So
no
api
machinery,
no
client,
nothing
right
and
and
with
that
in
mind,
I
know
that
if
we
are
importing
something
on
the
data
plane,
that's
kubernetes
library.
B
We
are
wrong
because
we
shouldn't
be
caring
about
kubernetes
on
the
data
plane
unless,
unless
on
the
apis,
that
the
control
plane
will
provide
to
us.
So
this
is
your
configuration.
Do
whatever
you
need
to
do
with
your
configuration
right.
So
this
is
the
data
model
that
you
understand
and-
and
I
figured
out
that
there
are
some
things
inside
the
the
functions
that
should
be
data
plane
only
but
still
on
the
old
old
ingress
that
they
go
to.
B
Let's
say
to
the
config
map:
to
get
some
config
map
like
hey,
is
like
snippet
allowed
or
not
is
something
allowed
or
not,
and
this
is
gonna
be
the
first.
This
is
gonna,
be
probably
the
first
thing
that
I'm
gonna
affect
as
soon
as
I
can
finish:
cleaning
up
and
splitting
the
code.
So
I
have
a
plan
for
that
and-
and
I
wanna
I
wanna-
add-
probably
the
plan
on
the
implementation
details
in
ingress.
B
So
I
wanna
separate
everything
that
that's
gonna
be
shared
between
control,
plane
and
data
planes,
so
some
util
packages
like
sets
ssl
dealing
whatever
so
things
that
that
are
part
of
that
can
be
shared
with
with
the
with
all
of
the
programs
right.
I
want
to
split
the
api
right
now,
the
api.
What
I
call
api
is
the
is
the
ingress
data
model
so
that
configuration
servers,
tcp
certificates,
whatever
that's
going
to
be
shared
by
by
the
control
plane
in
the
data
plane.
B
And
then,
after
that,
I
will
start
really
working
on
the
on
on
separating
the
the
codes
right
and
the
first
thing
that
I
realized
it
is
that
we
should
decide
which
approach
to
take
and
and
if
we
are
going
to
send
every
time
the
whole
configuration
to
the
whole
data
plane
or
if
we
want
to
define
different,
endpoints
and
and
and
whatever,
and
and
have
like
a
a
full
reconciliation
process.
B
Every
five
minutes
as
an
example,
and
why
I
am
bringing
this
to
you,
because
we
may
end
up
bringing
us
a
different
problem.
B
If
we
do
the
split
between
control,
plane
and
data
plane
like
hey,
we
solve
it.
The
whole
security
problems,
but
right
now,
if
someone
is
fancy
enough
to
keep,
creating
and
removing
like
a
virtual
whole
store
a
pod
in
crash
loopback
or
something
like
that,
we
are
going
to
keep
receiving
full
updates.
B
So
all
of
these
is
actually
explain
it
on
on
this
document,
and
I
just
wanted
to
make
sure
that
everybody
knows
that
I'm
fully
focused
on
this
right
now,
so
I'm
not
taking
care
of
any
other
pr.
I'm
not
thinking,
I'm
not
looking
into
any
other
issue.
B
Just
these
and
it's
going
to
be
a
huge
and
massive
work.
So,
instead
of
doing
the
whole
pr
expect
more
smaller
prs
from
my
side,
like
moving
things
from
other
from
one
side
to
the
other
side,
I
will
try
to
explain
why
I'm
doing
that.
But
I
I
I
wanted
to
move
fast
with
that
right.
B
So,
let's,
let's
try
to
be
really
assertive
on
on,
like
on
the
reviews
like
because
I'm
just
moving
code
right
now,
but
but
I
want
to
make
sure
that
everybody
understands
why
I'm
moving
that
code
and
and
and
later
why
this
is
going
to
be
easy
to
have
like
the
final
pr,
as
just
like
being
the
split
between
control,
plane
and
data,
plane,
okay
and
but
yeah.
A
I,
like
I,
like
the
approach
that
it
makes
sense
from
a
you
know,
just
understanding
the
changes
and
the
differences.
So
when
that
last
one
comes
through,
I
I
like
the
approach
as
far
as
the
scale.
A
Sorry,
as
far
as
the
scalability
is
concerned,
I
think
once
we
get
that
just
to
understand
what
the
actual
impact
is.
We
should
probably
get
that
kasich
stuff
working
so
that
we
can
understand
what
one
three
zero
looks
like
compared
to
all
of
these
changes
that
are
coming
in,
so
that
we
can
have
that
answer
for
folks,
because
yeah
I
agree.
This
is
the
same
problem.
The
endpoints
had.
C
I
was
just
going
to
say
only
jintao
can
understand
the
changes
you're
making
for
now.
So
we
are
whether
it's
good
or
bad
doesn't
matter,
because
I
think
you
should
go
ahead
whatever
and
then
that
when,
after
two
months
of
your
work,
when
when
it
starts
looking
like
a
split
control,
plane
and
data
plane
scenario,
then
testing
will
help
but
yeah.
If
you
are
right
now,
even
before
starting
the
work.
C
If
you
are
saying
that
terms
of
reloading
configuration
and
synchronization
is
going
to
be
a
problem,
I
am
not
a
developer,
so
I
can't
advise
at
all.
But
I
tell
you
right
now:
there
is
one
more
new
issue
already
open
about
scalability.
C
I
can
give
you
a
link
number,
but
we
don't
need
to
visit
that
right
now,
but
they're
talking
about
15
m
15
mb
size
of
just
the
nginx
conf
and
they're
saying
it
looks
like
they're,
a
provider
of
some
kind
or
a
big
or
a
big
like
not
a
cloud,
but
they
do
work
for
some
kind
of
a
very
big
provider
and
they
have
sk.
They
have
this
not
scarability
as
such,
but
they
have
performance
issues
as
in
reloading.
A
Okay,
we've
had
this:
we've
had
this
discussion
problem
before.
I
think
this
might
be
a
good
conversation.
We
have
maybe
we
schedule
a
separate
design
session
and
carol.
We
could
bring
in
some
of
the
engine
x
folks
and
just
talk
about
how
we
can
split
the
nginx
comp
to
make
it
smaller
or
maybe
some
other
ways
of
how
you
guys
have
tackled
large
and
generic
distributions,
like
that
yep
I
had
just
pinged
the
nginx
crew
about
this
discussion
and
damian
will
be
joining
it
shortly.
He
has
a
conflict,
but
he
does
plan
on.
A
C
A
Yeah,
okay,
so
we'll
we'll
put
the
action
item
for
me
to
coordinate
that
with
everybody
ricardo
does
that
does
that
help?
You
ask
with
this
document
and
I'm
sure
everyone
needs
to
review
this
as
well,
because
it's
the
first
time
I've
seen
this.
B
Yeah,
yeah,
and
and
and
just
to
to
be
honest,
sorry
to
be
honest
long,
I
don't
so
I
don't.
I
don't
expect
everybody
to
understand
the
goal
or
whatever
I'm
I'm
I'm
doing
there,
but
I
I
I
expect
that
everybody
understands
why
we
are
doing
that
right.
So
I
think
that
more
important
on
the.
How
is
why
everything
and
the
things
they
are
being
made,
so
it's
more
like
an
architectural
choice
than
the
the
technical
choice
on
on
the
code.
B
B
My
only
my
only
ask
right
now
and-
and
I
understand
that
actually
jintao
is-
is
the
only
one
actually
anyone
in
ingress
in
ginx-
and
this
is
why
I
send
on
the
channel,
because
anyone
that
wants
to
be
a
reviewer
on
goal
can
can
go
ahead
and
review
my
code.
It's
it's!
Fine
and
ask
and
say
hey,
this
looks
good
to
me
or
not.
It's
it's
really
fine
right.
So
my
only
ask
on
that
is
that
we
we
try
to
be
assertive
on
on
the
on
the
on
the
changes.
B
So
not
not
be
like
hey,
being
really
clear,
just
be
careful
with
with
any
need
picking
on
that
right.
So
right.
C
C
Yeah
right
so,
basically
with
the
whole
decision
of
going
into
this
maintenance
mode
and
the
big
change
at
the
end
end
of
the
tunnel
after
six
months,
we
should
be
coming
out
with
an
action
plan
right
now.
We
don't
have
an
action
plan,
so
we
should
have
action
plan
for
that
reload
and
performance
thing,
and
we
should
have
an
action
plan
for
observability
very
easy
observed.
C
So
we
should
offer
the
tooling
or
documentation
for
observability
as
because
people
will
want
to
know
the
the
small
the
my
new
details
as
in
if
they
added
like
2,
000
or
3000.
So
that's
the
big
change
that
is
happening
with
this
whole
exercise
right.
So
one
is
the
performance.
Second
is
observability
and
third,
one
is
the
feature
set
that
you
think
you're
going
to
decide
right.
This
is
what
you're
going
to
remove
what
you're
going
to
keep
on
those
attributes
and.
A
As
I
said,
those
will
all
be
announced
in
the
release
notes
as
we
remove
and
deprecate
things,
so
we're
still
going
to
be
doing
releases
throughout
all
of
this.
I
think
that
it's
just
a
this
is
just
a
focus
of
what
we're
working
on.
So
that's
why
we
wanted
to
keep
track
of
issues
that
come
up
as
as
we're
moving
through
all
this
and
making
these
changes
we're
just
we're
focusing
on
the
things
we
want
to
focus
on
for
the
stabilization
project
and
not
new
features.
A
So
you
know
all
the
things
that
we
talked
about
before.
So,
if
we're
not
making
those
clear,
definitely
make
sure
that
we're
making
those
clear
in
the
release
notes
like,
I
think,
that's
why
we
pointed
out
that
we're
dropping
119
and
adding
124
and
adding
the
new
privileges.
So
things
like
that,
we
want
to
make
sure
it's
very
clear
to
the
end
users
in
the
release,
notes
of
what's
changing.
C
Okay,
yeah
got
it
okay
and
those
releases
will
be
coming
out
of
that
branch
right.
The
130
release
branch
or
not
from
main
right.
A
I
s
the
the
that
again
is
probably
still
not
clear
so
ricardo.
Are
we
going
to
just
release
from
one
three
zero
branch
or
releasing
from
main
still?
I
I
don't
know
why?
What
can't
just
release
new
unless
it's
like
the
major
break,
fixes
like
the
control
plane,
split,
we're
not
going
to
do
until
we're
absolutely
ready
and
that's
going
to
be
a
t-o
really,
but,
like
the
vulnerability
fix
thing,
that's
going
to
be
a
1-3-1!
That's
an
alpine
bump
things
like
that.
A
The
pr
that
I
just
accepted
for
there
was
a
a
data
dog
version
bump.
Those
are
all
regular
releases
that
I
think
can
go
to
like
131
and
above.
B
A
Okay,
yeah
there's
a
that's
something
we
probably
should
talk
about.
Probably
we
probably
want
to
look
at
that
when
we
got
to
do
when
we
think
we're
gonna
do
a
release.
A
Okay
got
it
okay,
so
we
can
just
start
up
like
an
issue
for
like
one
three
one
or
one
for
a
release
and
have
folks
put
in
the
commits
that
we
want
to
cherry
pick.
Okay,
okay!
A
All
right
sounds
good
anything
else
before
we
go
into
doing
issue
triage
we'll
do
some
issue
triage
for
about
10
minutes
and
then
we'll
go
into
the
project.
Stabilization
or.
A
Let's
jump
into
this
the
fun
bit,
I
don't
know
if
anybody's
been
looking
at
any
of
these.
A
So
setting
up
a
redirect
and
it
breaks
health
and
points.
Okay,.
A
Can
you
post
your
your
your
github
handle
yeah,
I
think
going
to
yell
at
me
about.
B
I
think
I
think
harry
you,
you
need
to
go
to
the
issue
and
do
the
slash
assign
for
yourself.
A
Yeah
one
probably
won't
let
me
here,
you
go
yeah,
yes
I'll!
Do
that
yeah
885
tonight,
yep,
yeah
yeah,
because
you're,
not
a
kubernetes
member,
all
right
yeah.
That
sounds
like
an
issue
just
verify
that
it
is
an
issue
and
then
test.
It
looks
like
he's
on
2-1
and
probably
is
going
to
be
in
3-0
as
well.
So
I
would
test
it
with
his
version
and
then
3-0
and
then
just
report
back
in
the
comments,
and
we
can
add
it
for
follow-up
for
next
week.
A
B
A
We've
got
to
be
a
little
bit
more
careful
about
removing
the
kind
bug
until
we
do
triage
accepted.
That's
just
I
want
to
say
that
for
everybody.
A
Don't
know
we
don't
know
it's
a
bug
until
someone
has
done
the
triage
and
has
verified
it.
So
we
want
to
probably
err
on
the
side
of
caution
of
trusting
the
user
that
it's
a
bug,
especially
if
they're
using
newer
versions
and
giving
us
a
lot
of
information.
C
A
C
A
B
Yeah
sign
this
one
to
me,
and
I
will
I
will
take
a
look
as
soon
as
I
just
make
sure
that
so
actually,
this
is
the
one
that
we
should
discuss
with
with
inginx
folks
right
with
the
fl.
A
A
B
A
A
Okay,
the
pathing
issue,
when
I
thought
it
was.
A
A
A
C
A
B
A
B
A
At
it
a
note
at
the
top
of
the
script,
because
I
bet,
if
I
run
this
right
now
I'll
have
this
issue
I
think
I
had
to
install-
I
think
I
installed
gnu
said
so.
It
was
the
same
thing
with
that.
So
I'm
just
saying:
if
we
have
issues
like
this
again,
we
just
start
running
all
the
scripts
inside
our
docker
containers.
C
C
A
A
I
still
think
I
still
think
we
to
solve
the
problem
going
forward
because
someone
else
is
going
to
have
this
issue
that
doesn't
have
gnu
set
installed.
They're
going
to
have
the
the
freebsd
said,
so
we
just
forced
the
script
to
run
inside
of
a
inside
the
docker
container.
It
won't
be
an
issue.
That's
that's
all
I'm
saying.
C
C
This
thing
is
done
when
somebody
is
doing
a
release,
the
script
is
run
only
when
somebody
so
just
for,
and
then
it
means
the
whole
tree
is
on
your
on
your
workspace,
which
is
almost
always
a
laptop
directory
right
and
yeah,
and
it
was
not
happening
until
now.
It's
being
reported
only
now,
so
if
we
can
just
wait
until
it's
proved
that
that's
the
problem,
then
then
we
can,
like
you
know,
do
make
whatever
changes
are
required,
because
it's
not
known
as
to
what
change
for
this
problem
start
happening,
and
I'm
and.
C
A
A
A
What's
what's
up
with
this
one
long.
C
So
bad,
so
back
about
almost
eight
months
or
nine
months
ago
we
had
a
the
user
name,
a
furth
add
this
automation
that
we
start
generating
manifest
for
four
or
five
different
versions.
But
that
was
because,
or
just
two
users
wanted-
we
go,
it
is
v
1.19
manifest,
and
then
there
is
a
feature.
Our
spec
some
field
is
different
for
1.19
versus
above
vpn
1.919.
C
1.19,
I
don't
think
that's
relevant,
so
we
should
just
I
just
put
in
a
thing
saying
we
should
stop
doing
those
multiple
manifests
and
multiple
directories,
and
all
of
that
just
to
one
one.
We
should
start
when
we
run
that
script
and
deploy
and
generate
those
manifest.
We
just
do
just
to
one
per
provider.
A
C
But
that's
where
ishmael
started
looking
at
it
and
we
came
into
the.
A
Okay,
easy
enough
cool
I'll.
Do
everything
I
needed
yeah:
let's
go
ahead
and
pull
up
the
project
boy.
A
Probably
should
put
those
issues
on
there
as
well,
since
we're
working
on
them,
the
ones
that
you
just
designed
out.
Okay,
so
ricardo
already
did
his
bit
for
the
open
issue.
How
how
are
we
at
let's
go
to
the
open
one?
Before
I
talk
about
my
stuff,
where
are
we
at
with
the
open,
telemetry
sidecar?
I
know
we
have
that
as
an
action
item
for
the
last
release.
We
didn't
get
all
those
changes
in.
Did
we.
C
I
didn't
bother
to
bring
you
know.
I
didn't
bother
ricardo
in
mid
midweek
or
during
this
time,
but
even
though
he
said
that
I
could
not
ask
him
for
time,
but
now
I
think
I
should
that
we're
talking
about
it
for
the
second
time,
but
he's
not
going
to
be
working
on
a
control
plane
and
that
so
again,
ricardo.
If
you
think
you
should
wait,
we
can
wait.
B
Yeah,
hey
I
so
I
need
to
pick
up
something
on
the
door
here.
I
will
keep
the
meeting
open,
but
I
will
be
back
in
eight
minutes.
Okay,.
B
A
A
A
A
So
we've
got
yeah,
there's
another
one
in
there
there's
the
other
one
I'll
just
put
them
together
got
a
lot
of
vulnerability
stuff.
What's
a
lot
of
cve
stuff,
I
think
we're
just
gonna
have
to
I've.
So
let's
talk
about
the
cv
stuff
because
I've
added
scanning
now
for
all
of
them,
so
this
will
be
doing
both
trivia
and
grape
scanning,
but
I'm
having
some
issues
because
I'm
using
a
new
I'm
using
a
new
action
from
distrolus.
A
That's
that
also
does
attestations
so
put
them
on
to
the
yoli's
cosine
to
verify
the
attestations.
So
it's
having
some
issues
with
that
right
now,
but
as
soon
as
that's
done,
we'll
have
we'll
just
walk
through
the
action.
A
So
what
it
does
is,
it
does
both
trivia
gripe
and
it
will
do
sneak
if
you
add
a
sneak
token,
but
we
don't
have
one
yet
we.
A
About
that
at
another
time,
and
then
it
will
create
attestations
for
all
of
them,
so
folks
can
verify
that
we
either
have
we've
done
the
ver.
We've
done
the
scans,
and
so
I've
got
it
set
up
to
do
it
on
workflow
request
on
pushes
to
main
and
on
prs
we
can
probably
pull
it
out
of
the
pr's
or
we
can
leave
it
in
prs
and
and
see.
If
folks
are
introducing
new
vulnerabilities.
That's
like
that's.
The
piece
I
wanted
to
discuss
is:
when
do
we
want
to
run
the
scans?
A
So
that's
what
the
workflow
dispatch
can
do,
so
we
can
just
do
a
manual
trigger,
but
I
was
thinking
we
do
them
on
releases,
at
least
on
release
and
push
domain.
The
question
I
have
is
sure,
and
we're
also
going
to
do
them
on
a
schedule
so
that,
as
we
get
new
as
new
changes
happen,
so
I
just
want
to
make
sure
that
we're
always
looking
at
these
and
seeing
if
new
vulnerabilities
are
being
introduced.
That's
why
I
was
thinking
on
pull
requests
to
maine.
A
We
should
also
be
looking
at
those
because
that's
when
folks
are
adding
new
functionality
or
anything
like
that,
if
it
increases
the
count
or
we
see
new
things,
it
just
keeps
us
abreast
of
what's
happening.
So
that's,
that's
really
was
the
main
talking
point
is:
should
we
also
do
this
on
pull
requests.
C
I
think
you
and
ricardo
decide
on
that,
but
there
is
a
different
angle,
but
there
is
some
people
are
posting
scans
on
image,
so
there
are
no
they're,
not
just
talking
about
the
docker
image.
Sorry,
there
are
charters,
I'm
sorry
chart,
so
some
people
are
scanning
the
chart
and
there
is,
I
think,
one
issue
right
now
they
say
the
chart
shows
vulnerability,
the
image
doesn't
or
the
image
shows,
different
set
of
vulnerabilities
and
charts
shows
different
set
of
vulnerabilities.
C
Yeah
sneak
sneakers,
I
also
didn't
know,
but
it
seems
that
guy
did
it
for
using
snake
or
something
on
the
chart.
So
that
is
one
aspect.
The
second
aspect
is,
if
you're
saying
you're
doing
on
pr's.
At
what
time
I
mean,
I
think
it
should
be
a
post
action
only
when
something
merges,
then
we
do
on
on
the
image.
A
Yeah,
so
I
think
right
now
yeah
on
prs.
We
do
build
the
image
on
pr,
but
I
think
the
way
that
I
have
it
written
it
only
does.
The
current
version
so
probably
only
be
helpful
on
releases.
The
way
I
have
it
written
up,
so
I
think
yeah
we're
gonna
have
to
do
wait
for
it
to
do
the
image
build
and
then
do
the
container
scan
good.
A
A
A
That's
a
good
point
that
will
remind
me
what
we're
talking
about.
Okay,
that's
why
I'm
at
with
that
one.
I
think
the
code
ql
stuff
is
completed
and
it
runs.
The
only
issue
I
think
is
it
fails
if
it
finds
issues
and
the
issues
are
only
available
to
maintainers
on
the
project.
So
it's
a.
I
think
we
might
just
want
to
keep
keep
that
one
as
a
scheduled
scan.
I
don't
remember
if
this
does
it
on
pushes
as
well.
A
I
I've
got
to
go.
Look
at
the
yeah
it'll
do
on
pull
requests
and
on
pushes
to
branches.
I
think
we
probably
just
want
to
move
this
one
to
a
scheduled
one,
because
no
one
else
can
because,
because
of
the
way
it
reports
the
scans,
it
reports
it
to
the
security
page
on
github
and
only
project.
Maintainers
can
see
that.
So
I'm
just
going
to
remove
the
schedule
on
this
so
that
we
can
see
it
and
then
open
issues
as
we
see
them.
Okay,
okay,.
A
Code
ql
does
the
vulnerability
scan
it's
a
vulnerability
scanning
static
analysis
from
github,
so
it's
a
security
feature
from
github.
C
A
Okay,
was
there
anything
in
here
that
you
were
working
on
long
that
you
wanted
to
add,
because
I
didn't
see
anything
assigned.
C
Topic
that
chinta
is
following
up
about
adding
the
slash
project,
whatever
command
to
the
bot
yeah,
because
all
those
issues
which
are
supposed
to
be
area
stabilization
are
not
listed
here
right,
so
they
have
to
make
it
here,
one
somehow.
A
C
A
A
C
A
Which
is
weird:
okay,
yeah,
as
you
see
things,
if
you,
if
you
see
them,
and
there
are
things
that
need
to
be
on
the
project
board,
then
just
let
me
know
what
let
me
know
just
ping
me
and
ask
me
to
add
it
to
the
project.
A
A
A
All
right:
well,
that's
all
I
had
to
discuss
and
ricardo's
not
back
yet.
I
just
wanted
to
give
folks
an
update
on
where
I
was
at
with
the
two
things.
The
next
thing
I
was
going
to
work
on
from
a
release
process
perspective
is,
I
was
going
to
add
it.
The
release,
notes
section
to
the
feature,
request,
template
and
then
install
the
release.
A
Notes
bot
from
I
think,
sig
release
has
it
and
so
that
when
we
then
we
can
automate
all
of
our
release
notes
it
will
pull
the
release,
notes
field
from
the
feature
from
the
pull
requests
and
then
put
it
into
release
notes
so
that
we
don't
have
to
do
that
again
during
releases.
That's
the
first
step
at
all
of
the
release.
Stuff
awesome,
awesome!
Okay,
I
don't
know
I.
I
was
also
thinking
about
being
lazy
and
just
adding
a
link
to
our
release.
A
Notes
for
the
controller
add
that
to
the
the
helm
for
the
artifactory
release,
because
I
don't
know
if
it
are
so
artifact
if
it
also
automates
the
auto
factory
release
notes.
So
I
think
that's
another
action
we
could
just
have
where
just
on
the
helm
release,
it
just
adds
a
link
to
the
release,
notes.
C
I
think
artifactory
one
is
special
in
some
ways,
but
we
have
to
go
to
verify
that
not
sure.
A
Yeah
so
yeah
one
problem
at
a
time
right:
okay,
anything
else.
Anyone
wants
to
discuss
before
we
break.
A
Okay,
I
think
I
think
we're
good
carol
I'll
reach
back
out
to
you
on
slack
yep.
I've
already
started
collecting
the
names
on
my
end
or
a
little
slow
on
responding,
so
I'll
continue
to
collect
it.
For
you.
C
How
do
you
pronounce
that
co
rs
in
a
couple
of
tls
issues
that
we're
not
all
talking
about.