►
Description
[SIG-Network] Ingress NGINX Bi-Weekly Meeting for 20220609
A
Hello:
everyone,
my
name,
is
james,
strong,
welcome
to
sig
networking,
sub
project,
ingress
and
gen
x,
meeting
for
june
9th
yeah,
it's
june
9th.
So
of
course
this
is
a
cncf
project
which
guidelines
of
the
coc
code
of
conduct,
which
basically
means
be
kind
to
each
other.
If
you
have
any
issues,
please
report
those
to
myself
or
cargo
or
if
there
are
issues
with
us
report
that
to
the
cncf,
hopefully
we'll
not
ricardo
will
be
on
his
best
behavior
unless
you're
mean
to
them
in
your
pr's.
B
A
B
A
Awesome
so
we've
moved
our
meeting
so
now
we
got
long
and
yanto
yeah,
hey
guys
and
carol
thanks
for
joining
so
awesome.
I'm
glad
this
time
works
that
we've
finally
figured
out
to
move
the
time
and
we're
gonna
have
fun
today.
So
we're
gonna
walk
through.
Do
some
issue
triage
and
walk
through
some
of
our
action
items
and,
as
you
all
can
see,
our
lovely
lovely
friend,
our
german
friend
noah,
is
not
joining
us
and
he
hasn't
updated.
He's
been
doing
a
really
great
job
with
that.
A
So
I
think
we've
got
to
pick
up
that
slack
and
for
the
review,
because
we
don't
have
anything
to
review
from
open
issues,
but
we
go
ahead
and
start
working
through
the
triage
conversation.
Is
there
anything
that's
top
of
mind
right
now?
I
already
know
that
long
is
going
to
say
124.
B
A
Gotcha
looks
like
we've
got
a
certain
number
of
them.
Do
we
want
to
start
with
the
124
conversation,
or
we
just
want
to
walk
through
three
hours.
B
I
think
we
can
start
with
this.
One
I've
been
seeing
some
movement
on
there.
Maybe
I
won't
understand
actually
what's
happening
and
not
just
dropping
the
test,
but
maybe
fixing,
because
if
the
test
is
not
working
does
it
means
that
we
don't
support
version
124
or
we
just
need
to
fix
something
in
the
test.
C
D
C
There
is
a
funny
story
of
one
script
calls
the
other
one
make
file,
calls
the
other
and
so
on,
and
this
for,
like
200
minutes,
at
least
it
just
it
just
sits
there
waiting
for
that
waiting
for
api
token
thing.
That
is
basically
a
message
from
the
small
piece
of
code
that
actually
is
trying
to
create
a
service
account
specific
to
a
test
or
specifically.
A
A
C
C
B
This
is
okay,
yeah,
yeah,
yeah
yeah.
This
is
that
this
was
fun
right
because
they
deprecated
something
that
was
really
critical
and
no
one
was
knowing
that
that's
not
generated
a
secret
right.
A
A
B
A
B
Yeah
yeah,
so
we
can
probably
if
we
don't
have
an
issue
on
that.
Probably
we
can
open
it,
and
I
think
this
is
right
now
that
james
actually
raised
this
as
a
problem.
This
is
this
may
be
a
good
first
issue
right,
it's
just
like
fixing
in
gingo
on
the
entry
point
of
gingko,
maybe
our
on
the
make
file
not
waiting
for
the
we
need
to
change
how
the
service
account
is
created
right.
C
A
A
B
A
A
C
C
A
Yeah
but
let's
fix
it,
let's
see
if.
A
B
So
what
we
need
to
do
is
james,
it's
gonna
post,
probably
that
cap-
and
this
is
where
the
things
they
are
broken
right,
because
we
keep
waiting
for
the
secrets
to
be
created,
but
the
secret
doesn't
get
created
anymore,
yeah.
B
B
Doing
the
create
service
account
in
the
line
1558
to
change
and
see
how
it,
how
is
the
right
way
of
doing
if,
like
just
keep
ctrl
create
service
account
right
now,
does
have
a
new
option
to
do
that
or
if
we
need
to
do
something
else,
but
that's
not
going
to
be
just
create,
let
me
see
create,
let's
say,
help
show
safe
config
output
field,
blah
blah
blah
yeah.
It
doesn't
create
the
subject
anymore.
Okay,
amazing
yeah,
so
probably
posting
that
yeah,
probably
posting
is
gonna,
be
enough
to
figure
out.
B
That's
that's
what
we
need
to
do
figure
out
post
and
do
some
rant
on
twitter
as
any
other
person.
D
A
C
B
B
So
this
is
this
is
something
that
actually
why
I
wanted
to
fix
this,
because
we
stayed
in
the
readme
that
we
support
version
124
right.
C
C
B
Okay,
okay,
okay,
okay,
sounds
good,
so
if
we
don't
support
it,
then
okay,
but
I
would
like
this
to
be
fixed
as
soon
as
possible,
and
I
mean
what
james
is
telling.
So
we
have
two
problems.
The
the
first
one
is
that
while
we
do
support
the
version
124,
we
are
gonna
get
the
github
action
in
an
infinite
loop
like
for
three
or
six
hours,
because
it
keeps
it
keeps
waiting.
B
We
don't
exit
that
secret
creation
on
the
javascript,
that's
what
I've
seen
so
this
is
why
they
are
taking
like
three
or
four
hours,
and
we,
if
we
remove.
C
B
A
C
A
You
are
yeah,
okay,
that's
fair!
Then!
Okay,
I
see
now
I
I
did
not
realize
that
there
was
a
break
for
124
for
us.
I
thought
it
was
just
in
testing.
So
that's
fair
to
remove
124
from
testing
till
election
id
is
fixed.
So
even
if
we
do
because
we
know-
even
if
we
fix
the
124
testing,
it's
not
going
to
work
because
we
don't
have
the
election
id
changes
yet.
So,
let's
just
remove
124
from
testing.
A
A
C
A
C
A
Yeah,
let's
pull
yeah
new,
a
new
pr
to
pull
124
from
testing.
That's
fine!
I
just
want
to
make
sure
that
folks
are
aware
that
we're
not
supporting
124
yet
because
of
the
service
token
and
the
election
id
fixes.
That's
what
I
wanted
to
create
a
separate
issue
for
to
track
that
and
then
tag
that
tag
gentiles
election.
I
t
election
id
fix
for
that.
So
I'll
go
ahead
and
do
that,
can
you
open
up
the
the
pr
to
remove
124?
A
No
no
no
directly
commits,
but
this
this
124
discussion
does
we.
We
need
to
have
that
conversation
because
we're
now
at
n
minus
three
about
dropping
120
and
119
support
from
testing
right.
A
So
once
we
go
to
121,
we
in
that
124
pr,
we
probably
should
drop
the
120
and
119
testing
and
also
we
also
need
to
discuss
the
dropping
of
the
legacy
branch
as
well,
because
we're
not
going
to
not
we're
not
going
to
sport
124
on
the
legacy
branch
yeah,
and
I
think
we
said
we
were
going
to
continue
supporting
that,
for
I
don't
remember
how
long
six
months
and
that
ended
in
february.
A
That's
that's
something
that
we
probably
need
to
put
out
there
that
we're
dropping
the
legacy
supports,
so
you
can
craft
that
up
and
get
that
sent
out
to
the
dev
mailing
list.
So
I'll
put
that
as
an
action
item.
So
we've
got
like
three
action
items
now:
oh
somebody's
keeping
track
for
us.
A
And
how
do
you
have
that?
Your
pr
number.
C
A
A
Eight
zero,
nine
one:
okay,
awesome
cool:
we
haven't
even
got
to
the
triaging.
That's
fine.
A
Let's
go
ahead
and
let's
spend
the
15
minutes
on
triaging
some
of
these
issues.
C
C
Some
important
features,
features
or
fixes
people
have
put
in
and
they're
good
to
go,
they're
asking
for
it
so,
but
unless
we're
making
a
release
or
unless
we
have
thought
of
the
release
now
in
the
next
couple
of
weeks,
we
should
talk
about
it.
Otherwise
we
can
just
wait.
B
So
I
I
promise
I
won't.
I
won't
take
too
much
time
before
the
issue
triage,
but
I
wanted
to
before
we
jump
into
it
actually
pass
through
the
open
topics.
First,
because
I
think
those
like
we
can.
We
can
delay
some
non-critical
issues,
but
I
think
that
some
things
we
need
to
align
before
the
next
two
weeks
right.
So
do
you
mind
folks,
if
I
just
go
to
the
open
topics
before
going
to
digitriage.
B
Okay,
so
the
first
one
is
that
me
and
james.
We
opened
a
request
for
the
community
survey
during
uconn.
We
spoke
with
josh,
berkos
and-
and
we
opened
an
issue
for
that-
I'm
not
sure
where
this
is.
But
we
had
a
lot
of
time
to
discuss
about
some
some
something
in
in
the
future
of
of
increasing
giant
x,
and
we
also
got
a
lot
of
people
no
figuring
out.
That
like
was
me
and
james
and
hey,
where
is
gateway
api
on
the
ingress,
china,
x
or
hey?
B
Why
do
you
have
so
many
cves
or
whatever
right
so
and
and
during
those
hallways
conversations
I
I
was
like
a
bit-
I'm
not
gonna
say
annoyed
because
you
know
it
is
not
like
a
a
good
word,
but
I
was
a
bit
concerned
about
people
asking
those
questions
versus
people
actually
contributing
and
all
of
the
books
that
we
had
right
and
I
wanted
to
know
and
to
to
to
to
get
some
feeling
on
what
the
community
is
expecting
from
us.
B
How
can
we
make
ingress
in
ginex
useful
for
like
90
percent
of
the
users,
but
not
accepting
all
of
the
features
that
we
have
right
now,
because,
as
an
example,
maintaining
mod
security
is
pretty
complex
and
and
takes
half
of
the
time
of
the
ci.
And
the
build
process
is
for
mod
security
and
open
tracing,
and
we
don't
know
how
many
people
actually
use
that
right
or
if
we
can
just
follow
a
deprecation
path
from
that
and
focus
on.
B
What's
important,
like
performance
of
of
the
ingress
in
giant
x,
of
the
proxy
doing
adding
some
more
configuration
that
are
part
of
the
core
in
gynex
and
not
like
external
stuff,
like
adding
headers
and
things
that
people
keep
doing
on
custom
snippets,
that
we
can
turn
into
configurations
and
and
removing
and
even
doing
the
cleanup
of
of
the
templates
and
so
on.
So
this
is
after
this
discussion
that
me
and
james
we
had
on
on
kubecon.
B
We
decided
to
open
and
and
take
a
look
into
how
many
people
are
actually
using
mod
security,
and
I'm
not
sure
if
you
saw,
but
my
security
is
going
to
be
maintained
by
the
company,
that
that
created
mod
security.
So
it's
going
to
be
just
like
probably
abandoned,
or
something
like
that,
or
it's
going
to
be
some
developers,
but
the
the
the
release
process,
which
is
already
slow-ish,
because
we
know
that
they
are
also
volunteers.
B
It's
going
to
be
slower
right
and
same
thing
for
open
tracing
versus
open
telemetry,
and
we
have
people
looking
into
open
telemetry
and
maybe
open
tracing
can
be
deprecated
and
other
models
as
well
like
broadly,
which
was
one
thing
that
I
implemented
back
in
time.
But
I'm
not
sure
how
many
people
is
using
broadly
was
like
for
a
really
specific
case
for
myself
that
I
needed
that
I
needed
a
a
for
performance.
B
So
this
is
the
idea
of
the
survey
that
we
can
know
how
how
many
people,
how
how
how
much
people
are,
are
actually
engaged
with
features
right.
So
if
we
do
have
a
lot
of
people
using
each
of
the
features
or
if
we
can
focus
even
when
we
do
gateway
api
stuff,
you
can,
if
you
can
just
focus
on
the
car
stuff.
So
this
is
the
idea
of
the
community
survey
any
addition
on
that
james
that
we
discussed
it
that
I
can't
remember.
A
No,
I
mean
that
was
the
main
talking
points.
It's
just
again
getting
an
idea.
We
we
have
an
idea
of
what
we
need
to
do
from
a
future
plans
perspective.
We
need
to
understand
what
the
community
is
expecting
and
what
they
want
and
how
we
can
align
those.
So
that's
part
of
this
conversation
is:
we
need
to
get
this
out
there.
We
need
to
get
information
from
folks
because
we're
just
not
so
we
need
a
way
to
correlate
all
of
that
information
and
understand.
B
Yeah,
which
takes
us
to
the
second
topic
that
I
had
that
I
have
added
to
the
agenda,
which
is
the
feature
freeze
versus
the
bug,
fixes
and
and
why
I
have
added
this
thing
right.
So
what
happens
right
now
is
that
we
are
accepting
a
lot
of
features
like
someone
needs
some
performance
bucket,
something
in
prometheus.
Someone
needs
a
new
model.
Some
someone
needs
a
new
open,
telemetry,
something
and
people
they
come.
B
B
So
people,
just
they
just
use
and
they
say
hey,
can
we
do
this
in
china?
We
can
do
and
then
implement,
like
we
have
how
many
canary
something
balanced,
that
we
have
in
the
load
bouncer
we
have
like
six
seven,
I
don't
know
every
time
someone
appears
with
a
new
canary
balance
and
they
say
yeah,
that's
just
like
a
new
query,
parameter
now
it's
by
ip.
Now
it's
my
country
now
it's
by
the
weather,
like
I
can
direct
if
it's
sunny
either
directed
to
to
a
back
end.
B
If
it's
raining,
I
can
direct
it
to
another
back
end
right
and-
and
I
think
that
we
are
missing
the
point
of
focusing
right
now
on
the
stabilization.
We
are
spending
too
much
time
reviewing
features
and
we
are
not
spending
that
much
time
actually
fixing
bugs.
B
So
we
had
three
cves
back
in
time
and
probably
there
are
more
more
to
come
on
one
specific
problem
that
could
be
fixed
by
just
like
spending
instead
of
one
hour
spending
three
hours
and
trying
to
figure
out
how
we
could
fix
it,
but
instead
was
like
hey.
I
need
to
fix
this
fast
because
I
have
later
new
features.
I
need
to
make
a
release.
This
is
going
to
like
implement
a
new
feature
to
someone
that's
waiting
as
well,
so
I'm
not
trying
to
be
a
jerk
here.
B
But
what
I'm
trying
to
say
is
that
maybe
we
need
to
establish
after
the
community
survey
and
I'm
really
biased
to
that
saying,
hey,
we
need
a
long
time
support
for
ingress,
which
means
we
are
not
going
to
accept
future
prs
for
the
next
three
or
four
months.
We
can
keep
them
open,
but
we
are
just
going
to
focus
on
the
code
stabilization,
which
means
code
cleanup,
which
means
removing
modules,
which
means
deprecating
stuff,
and
then
we
can
go
back
later
and
be
really
be
really.
B
Cultural
cultures
when
accepting
new
features
are
or
not.
This
was
another
discussion
that
that
that
happen
in
kubecon,
not
only
with
ingress
but
even
with
kubernetes,
that
we
accept
features
and
then
those
features
they
become
bugs,
but
the
people
that
the
person
that
implemented
that
feature
just
just
disappear
right
or
they
don't
have
time
anymore,
because
I
I
don't
think
any
of
us
are
paid
to
maintain
english
in
gynex
or
anything
in
kubernetes.
I
would
love
to
right,
but
that's
my
that's
my
hobby
during
the
weekend.
B
So
this
is
the
point
that
I'm
trying
to
get
here
in
the
future.
Freeze
that,
after
the
community
survey,
we
need
to
sit
down
and
say
to
the
community:
hey.
We
love
you.
We
know
that
you
like
using
us,
but
we
need
to
make
better
for
you,
and
it
is.
This
means
that
we
will
stop
receiving
future
requests
right
now,
so
we
can
understand
what
our
code
is
doing
and
how
we
can
improve
that
for
this
time,
window
make
sense.
C
Yeah,
it
makes
a
whole
lot
of
sense
because
if
you,
if
you
actually
get
statistics
90
over
90
of
the
features
that
we
have
implemented
in
the
last,
let's
say
eight
months-
that
only
used
by
one
or
maximum
two
users.
B
I
I'm
not
like
a
huge
fan
of
the
kubernetes
enhancement
process,
the
caps
I
one
of
the
persons
that
wrote
like
three
or
four
of
them,
and
I
I
m
half
of
my
kubecon-
was
like
making
jokes
about
caps
with
carlos
and
james,
but
I
think
that
we
need
a
design
document
that
doesn't
make
things
too
bureaucratic,
but
at
least
we
get
some
feedback
from
the
community
like
if
this
is
really
desired
or
not
right.
B
So,
instead
of
spending
time
reviewing
another
canary
algorithms
or
something
like
that,
we
can
just
spend
some
time
really
figuring
out
how
to
implement
gateway
api
as
an
example
or
ingress.
A
C
A
I
I
agree,
and
I
think,
to
put
the
expectation
out
there.
Yes,
we
want
to
do
the
code
stabilization.
What
does
that
mean?
I
think
it's
three
things
it's.
We
need
to
actually
do
the
sidecar
container
implementation
split
with
the
controller
in
ingress
engine
x,
but
we
tried
to
replicate
with
the
ch
root.
That's
the
first
one
fix
in
your
ingress
class
object
issues
and
then
start
looking
at
the
gateway
api
in
that
order
from
prioritization.
So,
if
we're
going
to
say,
hey
we're
going
to
stop
accepting
feature
requests
right
now.
A
C
And
just
a
factor
that
at
least
40
of
the
features
coming
that
have
come
in
in
the
last,
let's
say
six
months,
they
are
kind
of
inherent
in
the
gateway,
api
spec.
So,
for
example,
headers
people
want
to
start
routing
using
headers
and
stuff
like
that.
B
Yeah-
and
it
does
make
sense
like
headers
for
me-
is
one
of
the
that
makes
the
most
most
sense
there
like
you,
you
adding
the
headers.
I
got
a
question
on
that,
but
I
don't
think
we
need
to
cover
all
of
the
features
and
all
of
the
things
so
yeah.
Let's,
let's
make
this
james,
we
we
can,
we
can-
and
I
I
mean
we
can
create
a
collaborative
document
and
post
on
the
development
channel
or
something
like
that,
but
we
need
to
be
really.
B
A
B
A
So
we'll
write
up
the
dot,
that's
collaborative
we'll,
send
it
out
to
the
dev
mailing
list,
drop
it
in
the
dev
users,
slack
channel
and
then
for
new
feature
requests.
We
just
have
that
message
like
we're
doing
this
starting
now.
So
the
timeline:
let's
get
the
doc
ready
to
send
out
for
our
next
meeting,
so
we
can
send
it
out
and
start
then,
and
then
the
timer
starts
for
us
and
we
probably
should
put
time
frames
so
for
our
next
meeting.
A
C
A
B
C
A
That's
the
collection
id.
A
B
B
So,
if
someone
wants
to
work
on
this,
it's
gonna
probably
be
a
new
major
release,
but
it's
it's
like.
I
don't
think
it's
gonna
be
that
hard.
It's
gonna
be
just
like
a
move
to
the
new
engine
x
and
check
what
patches
we
need
or
not,
but
yeah.
We
need
to
do
that
as
a
new
major
release
and
not
using
version
119
anymore.
D
B
Okay,
yeah,
so
that's
fine,
and
as
soon
as
we
have
someone
to
work
on
that,
if
anyone
wants
to
work,
I
think
it's
gonna
be
just
it's.
It's
not
gonna,
be
probably
we're
gonna
figure
out
when
we
run
the
end-to-end
tests
right
so
yeah.
B
A
B
So
I
think
that
mod
security
and
open
tracing
open
telemetry.
They
should
be
part
of
the
of
the
email
that
we
send
right.
So
we
we,
we
need
to
ask
josh
the
timeline
for
the
survey
and
then
we
need
to
to
to
figure
out
what
we
do
with
them
like
what
what
we
need
to
do
with
with
those
features
can
we
drop
them?
A
Okay,
I'll
take
that
one.
A
How
long's
got
that
one
I'll
open
that
new
issue
timeline
for
the
survey,
so
I'll
I'll
draft
a
message
and
open
up
a
dock,
for
it
drop
all
this
stuff
in
here
and
I'll
put
drop
it
in
the
the
channel
for
us
to
comment
on,
and
we
can
get
through
that
and
have
that
conversation
next
week
to
be
able
to
send
it
out.
And
we
can
add
the
be
on
the
lookout
for
a.
B
No,
no,
we
we
didn't
took
this
step
yet
right
like
saying
we
are
not
gonna
accept.
This
is
something
that
we
are
gonna
just
send
like.
We
need
to
to
before.
Just
just
doing
that
and
going
to
dpr's
and
saying
hey,
we
don't
accept,
features
anymore.
B
We
need
to
drive
the
document
on
the
rationale
of
why
we
are
doing
that
and
what's
our
timeline
and
etc
so,
right
now,
let's
not
do
anything
on
the
pr's,
let's
just
keep
them,
and
and
if
it's
like
some
bug
fix
or
if
it's
something
that
we
think
that
can
be
acceptable
like
a
documentation,
improvement
or
something
that's
really
simple,
we
can
just
accept.
We
just
need
to
put
like
a
hard
stop
as
soon
as
we
decide
send
the
document
and
say:
okay,
so
right
now
we
are
not
accepting
features
anymore.
B
So
we
are
accepting
features.
We
are
not
just
gonna
gonna
merge
them
for
the
next
three
or
four
months
right.
So
anyone
can
provide
any
contribution
on
that.
But
we
are
we
as
maintainers.
We
are
prioritizing
something
else,
but
makes
sense.
So,
let's
not,
let's
not
state
that
we
are
just
let's
not
say
that
we
are
not
accepting
features
anymore,
because
this
is
not
true
right
now
we
are
gonna
just
propose
to
the
community
that
yep.
A
A
A
A
Wrong
one:
okay,
using
a
new
version.
Good
start
we
need
to
this
is
a
minor
issue
for
me.
I
think
we
need
to
move
up
what
their
issue
is
to
the
top
in
the
template,
because
you've
got
to
wade
through
all
of
this
before
you
get
to
the
actual
issue,
what
happened
and
what's
expected?
So
that's
no
rate
limit
is
found
in
the
endpoint
accessing
it
make
the
ingus
controller
print.
This
message.
B
A
C
B
It's
it's
for
the
global
rate
limit
when
it
shares
like
when
it
shares
the
amount
of
connections
that
are
going
like
it's
a
key
value
right,
so
you
have
the
key,
and
then
you
just
increment
that.
So
this
is
the
key.
C
C
B
What
what
they
want
is
actually
the
lua
is
is
dropping
that
saying
that
this,
this
access
key
is
limited
to
to
200
characters
and
they
want
something
like
a
thousand
and
five
five
five
hundred
characters
because
they
use
something
like
a
gwt
token
for
as
the
key.
So
here
is
my
rent
opinion
on
oidc
token
being
used
for
for
those
things
right.
B
You
can't
so
the
oedc
token
the
header
can
have
like
4
4k,
which
means
like
for
4,
000,
characters,
right
and
and
it
it
depends
on
how
what
the
authentication
side,
what
what
the
authentication
side
returns
to
you
and
then
sometimes
that's
bigger
than
the
4k.
So
what
what?
What
the
the
outside
they
do
is
like
they
split
that
right.
So
they
start
splitting
that
header
so
doing
this
here,
it's
not
gonna.
B
It's
gonna
solve
their
problem,
but
it's
not
gonna
solve
other
person
problem
right
because
because
the
jwc
token
is
gonna
have
like
a
4k
or
6k
or
something
like
that,
and
we
are
just
gonna
again
wrap
them
into
a
thousand
and
five
hundred
characters.
So
I'm
I'm
I'm
really.
Not
I'm
really.
Not!
B
I'm
really
not
not
not
willing
to
do
this
to
make
this
change,
or
at
least
it's
not
it's
for
me,
it's
something
like
it
can
be
verified
in
a
really
long
term
right,
so
because
it's
some
really
specific
case
for
jwt
tokens
to
limit
the
to
do
some
global
raid
over
an
authenticated
user
so
yeah.
I
think
that,
maybe
that
it
should
be
some
somehow
some
other
way
like
extracting
from
from
the
ydc
just
the
username
and
using
the
username
as
a
key
as
an
example.
Instead
of
the
whole
token.
A
B
Yes-
and
this
is
something
that
we
don't
support
right
now,
but
there
was
some
discussion
about
using
njs
like
they're,
ready
in
javascript.
You
know
sense
that
okay,
I
have
this
gw
token
and
I
want
to
extract
the
information
for
that
for
something
else.
So
someone
raised
an
issue
on
that
and
I
say
yeah.
Okay,
I
think
it's
fine,
but
before
doing
that,
you
need
to
support
an
njs.
It's
going
to
be
a
new
feature.
I
have
some
other
things
that
I
want
to
prioritize
other
persons.
A
B
A
Yeah
thumbs
up
would
be
a
good
selection.
We
need
to
figure
out
a
way
of
how
we're
going
to
prioritize
feature
requests.
That's
that's
a
future
discussion,
but
yeah
I'll.
I'm
gonna
sign
this
one
to
you.
Ricardo.
A
B
Yeah,
that's
I've
added
future
requests,
but
I
mean
it's:
it's
questionable
right.
B
A
B
C
No,
no,
no
so
so
what
happened
is
someone
did
a
pr
and
files
that
are
supposed
to
be
character?
Devices
came
across
as
files
regular
files,
so
the
pr
is
put
in
now
what's
happening
is
permission.
Denied
error
is
being
returned
when
they
try
to
actually
use
it.
So
they
have
tried
to
use
different
deficit
as
before,
but
now
they're
trying
to
they.
C
They
just
demonstrated
that
they
use
dd
to
against
the
do
a
character
device
random
as
input
and
they
get
a
permission
denied
error,
but
they
don't
they
get
it
only
on
the
ch
root.
We
random
not
on
the
main
containers
you
random.
B
Okay,
so
I
sorry
folks,
I
have
to
drop
here
and.
A
B
Need
to
drop
let
let's
can
we
just
move
this
to
slack
I'm
going
to
answer
on
slack,
okay,.