►
From YouTube: Envoy Community Meeting 2020-02-25
Description
Envoy Community Meeting 2020-02-25
A
B
D
End
result
was
that
Lisa
and
Mike
and
I
talked
about
his
timeline
forget
expressed
by
17,
because
we
were
able
to
compile
iOS
with
super
specimen
team
with
like
some
flags,
but
it
crashed
at
run
time.
Oh
just
didn't
have
time:
okay,
okay,
let's
lift
that
was
right,
so
I
told
them
that
we
can
prioritize
that
it's
factory
I,
know
stuff
I,
don't
think
it's
not
big
of
a
deal
but
I.
B
C
B
6-4
did
it
on
for
six,
so
this
this
came
up
on
the
last
call
and
I
believe
someone
from
Red
Hat.
So
right
now
we
do
compile
the
source
code,
which
ECC
we
don't
compile
the
tests.
This
came
up
on
the
last
call
or
someone
for
Red
Hat
was
going
to
do
a
PR
to
the
also
with
GCC
I'm
fairly.
Certain
the
GCC
six
is
way
too
old.
So
I
think
that.
E
B
So
it'll
be
seven
or
eight
will
probably
be
required.
I
would
recommend
reaching
out
to
the
folks
at
Red
Hat
and
between
you
and
Red
Hat.
If
someone
could
just
do
the
CI
change
to
make
the
GCC
so
so
right
now,
if
you
look
there's
a
there's,
a
CI
dragon
or
GCC,
but
it
but
only
compile
source,
it
doesn't
compile
test.
So
someone
just
needs
to
go
in
there
and
turn
GCC
on
for
tests
and.
F
C
B
E
E
H
B
Yeah,
that
is
something
that
we
as
a
community
have
to
review.
So
it's
on
my
list
for
today
to
actually
go
through
that
I
would
really
encourage
folks
from
Google
to
also
look
carefully
at
that
I
think
I,
think
snow
had
looked
at
it
and
what
you
know
and
possibly
had
some
concerns
I.
B
My
personal
feeling
for
what
it's
worth
is
that
at
this
time
point
any
time
we
add
a
new
XDS
API
and
we
have
to.
We
have
to
put
it
through
a
lot
of
scrutiny,
because
it's
something
that
we're
gonna
live
with
for
quite
some
time
so,
and
this
code
is
already
so
complicated
that
you
know
I'm
just
weary
of
adding
more
complexity
unless
we're
all
agreed
that
it's
the
right
way
forward.
H
B
E
Only
had
one
topic
and
I
I
don't
know
what
what
might
be
the
resolution
and
it's
the
Nighthawk
and
the
way
we
manage
right
now,
the
relationship
between
Nighthawk
and
envoy,
with
some
large-scale
refactoring
that
we
have
recently
we've
been
running
into
problems
that
Nighthawk
doesn't
build
and
you
put
a
single
repository.
You
know
we
we
imported
in
you
single
repository
and
we
have
issues
so
building.
You
know
both
products
together,
so
I
was
wondering
if
maybe
there
is
potentially
some
solution.
E
I
E
It
seems
like
also
the
repositories
outside
of
envoy
gets
very
little.
Traffic
from
maintainer,
so
I
had
soompi
are
sitting
in
filter
examples
for
quite
a
while,
which
is
actually
fixing
it
built
breakage.
So
I
don't
know.
Maybe
we
need
to
tighten,
maybe
notifications
or
I
I'm,
not
sure
either
like
I
have
some
or
my
automated
way
to
sync
these
repositories
to
my
own
voice
head
or
you
know,.
E
B
We're
just
we're
just
reaching
a
point
at
which
the
number
of
people
that
want
to
contribute
filters,
I
think,
is
outpacing
our
ability
to
actually
review
them,
and
you
know
I
think
we
all
probably
agree
that
webassembly
is
the
future
here,
but
I
mean
if
we're
realistic.
It's
probably
two
years
you
know
before
like
webassembly
becomes
the
de
facto
way
by
which
people
actually
write
extensions.
So
I
just
wanted
to
point
out
that
I.
You
know
I
think
we
have
to
think
through
this,
because
this
problem
will
will
get
worse.
B
I
don't
have
any
answer
here,
but
just
like
brainstorming,
a
couple
of
things.
I
think
that
we
could
do
a
Nighthawk
CI
job
like
we
do
envoy
filter
example,
so
we
do
actually
import
on
both
filter
example.
And
you
look
for
bill
breaks
there.
It
doesn't
fix
all
of
the
belt
breaks,
but
it
fix
some
of
them.
We
can
also
look
into
some
other
things
which
are
more
operational
but
like
we
could
look
into
slack
notifications
or,
like
some
type
of
Status
page.
B
You
know
when
our
ancillary
repos
are
broken
so
that
we're
like
low-priority
emails.
You
know
that
would
go
out
to
some
public
lists
that
tell
us
when
it's
broken,
like
I,
think
there's
some
low-hanging,
just
like
DevOps
fruits
that
we
could
probably
you
that
would
make
it
easier,
maybe
put
it
on
the
maintainer
list.
B
Yeah
I
mean
I
would
rather,
though,
have
some
type
of
notification.
So
it's
like
you're,
whether
that's
you
know
and
and
to
be
honest,
if
we
do
this
thing
around,
you
know,
let's
call
it
filter
sandbox
for
the
lack
of
better
better
phrase.
Until
we
have
a
proposal,
I
would
expect
the
community
to
actually
get
in
there
and
fix
the
filter
sandbox,
because
the
maintainer
zand
primary
PR
owners
are
not
necessarily
going
to
be
doing
that.
So
I
think
we
might
actually
need
a
public
email
list
like
envoy,
build
brakes,
or
something
like
that.
B
You
know
that
anyone
can
subscribe
to
and
will
subscribe
the
maintainer,
and
maybe
the
maintainer
on-call
would
look
at
it
and
fix
it.
If
it's
easy,
but
you
know
the
expectation
would
be
that
the
the
community
would
would
go
and
fix
it,
but
that
would
at
least
raise
awareness.
It's
like
people
would
know
if
it's
broken
I.
J
B
Think
it
would
either
run
nightly
or,
like
maybe
on
every
master,
merge
or
something
like
that.
I
think
we
can
sort
that
out.
You
know
I'm
I'm,
open
to
anything,
really
really.
Okay,
all
right
I
would
I
would
suggest
that
maybe
I
don't
know
how
we
want
to
track
what
one
of
the
things
that
I
have
noticed,
and
maybe
we
want
to
make
a
new
I
hate
to
propose
yet
a
new
repo
in
the
org,
but
we
actually
don't
have
a
place
for
discussing
organization-wide
issues.
It's
like
it.
B
You
know
like
we,
we
kind
of
need
a
place
where
we
can
open
issues
against
things
that
affect
multiple
projects,
so
I
mean
I'm
wondering
if
I
should
make
a
like
community
github
project,
which
will
only
accept
issues,
and
we
could
use
that
for
discussing
like
org-wide
issues,
I'm,
not
sure
if
that
would
be
useful.
That's
just
a
thought.
You
know
that
we
can
use
that
for
these
types
of
things
right,
I,.
E
J
B
And
and
like
these
types
of
things
will
happen,
then
often
so
I
feel
like
if
someone
opens
it
in
a
project
and
some
maintainer
realizes
that
it's
a
community-wide
issue,
we
can
just
move
the
issue
so
I,
don't
my
general
mode
of
operation
is
to
you
know,
try
to
have
as
little
process
as
possible,
and
then
we
can
figure
out
what's
working
and
not,
and
then
we
can
always
fix
it
later,
but
I
I
feel
like
there
is
some
low-hanging
fruit
here
that
we
can
probably
do.
Okay
and
in
on
this
topic.
B
B
B
C
B
I
this,
this
refactor
has
been
extremely
heinous,
but
I'm
I'm,
actually
almost
there.
So
it's
like
I
have
one
more
massive
PR,
which
is
mostly
changing
types
so
like
moving
the
the
right
types
and
then
I
have
one
final
PR,
which
actually
splits
the
interface,
which
means
that,
like
request,
headers
won't
have
status
response,
headers,
won't
have
method,
and
the
nice
thing
about
this
PR
is
I've,
had
to
fix
all
kinds
of
tests
which
had
like
pretty
busted
assumptions
about
using
the
wrong
headers.
B
So
it
actually
has
cleaned
up
quite
a
few
things,
but
I
would
suggest,
though,
that
once
I
land
the
next
to
PRS,
that's
probably
the
time
to
stop
and
then
talk
about
next
next
steps,
because
I
think
that
there's
a
lot
of
things
that
we
could
do
at
that
point,
I
have
a
pretty
clear
idea
of
how
to
implement
static
registration
of
oh
one
headers,
but
then
there's
the
question
of
whether
we
want
to
get
rid
of
that
system
entirely.
So
I
would
love
to
hear
from
all
of
you
on.
B
F
F
B
Okay,
well,
I
think
what
I'll
do
if
this
works
from
you
is
that
I
will
land
the
next
to
PRS,
because
in
my
opinion,
it
can
only
make
performance
better
because
now,
like
request,
trailers,
have
no
one
map
at
all.
Like
response,
trailers
have
like
two
entries
in
the
map
and
the
request
and
response.
Headers
are
now
basically
split
so
they're
using
half
the
memory,
so
it
can.
B
It
can
only
make
perf
better
and
then
at
that
point,
I
can
do
a
small
write-up
on
I
think
what
would
be
involved
in
implementing
static
res
static
registration
of
o1
headers,
but
I'm
not
going
to
implement
it
because
I,
don't
I,
don't
want
to
waste
the
effort.
If
we
collectively
decide
that
that's
not
the
way
that
we
want
to
go
yeah.
H
H
Like
a
benchmark
that
we
feel
is
representative
of
a
few
like
actually,
several
different
benchmarks
is
representative
of
different
scenarios
that
we
might
have
of
like
external,
like
if
on
boyz
and
edge
proxy
or
if
it's
an
internal
proxy
well
common
patterns
that
we
would
see
in
those
environments.
And
I
don't
you
know,
I'm
not
actually
sure
of
all.
A
H
H
B
That
sounds
that
sounds
great,
and
you
know
I'm
I'm
torn
here,
because
from
like
a
pure
programming,
fun
perspective
like
I,
feel
quite
confident
that
we
could
make
the
oh
one
map
fully
extensible
like
I'm,
quite
positive,
that
we
can
make
it
extensible
both
at
compile
time
and
even
probably
a
config
time,
so
that
people
could
basically
configure
all
the
headers
that
they
care
about.
With
that
fully
said,
I
I
agree
that
the
complexity
is
probably
not
worth
it,
so
you
know
I
think
maybe
whether
we
iterate
it
on
the
dock
or
the
github.
B
You
know
I
think
it
is
worth
it
to
explore
from
a
operator
perspective
like
how
you
know
do
we
want
it
to
work
well
in
the
general
case
like
are
we
okay?
If
we
tell
operators
that
they
need
to
specify
like
what
are
the
headers
that
they
care
about?
So
that's.
The
only
thing
that
I
would
suggest
is
that
beyond
benchmarks,
I
think
we
should
look
at
some
look
at
some
user
stories
and
just
try
to
make
sure
that
we
capture
you
know
the
ways
that
people
would
realistically
use
it.
E
Yeah,
that's
a
good
question.
I
think:
we've
we've
tried
to
get
this
information
before
I.
Think
for
us,
it's
challenging
because
it's
considered
PII
yep.
We
can't
just
simply
go
and
scrape
whole
bunch
of
yep
make
sense
a
oh.
This
is
how
people
use
it.
Yeah
yeah
I,
wish
we
could
so
I
think
it
would
be
good
to
get
also
input
from
community
agree.
E
E
B
So
it's
like
that's
all
fixed
now,
so
we
do
actually
have
the
potential
relatively
easily,
because
there's
very
few
places
that
actually
make
header
maps
in
in
the
prod
code
that
we
could
have
different
implementations
so
again,
not
not
proposing
that
we
do
that.
But
I
think
this
is
an
interesting
problem,
because
we
have
a
huge
menu
of
possible
solutions
here.
Right.
E
K
B
J
Have
like
one
more
thing
to
bring
up
like
we're,
similar
to
how
we
ran
hackett,
we're
also
running
like
an
internal
fuzz
it
for
like
two
or
three
days
next
week
and
I
have
a
list
of
like
proposals
and
things
that
we
have
and
like
proposed
tasks
for
fuzzing,
but
I
also
wanted
to
solicit.
If
there's
anything
community
or
in
that
you
know,
people
file
an
issue
or
people
follow
up
with
me
or
whatever.
If
they
want
like
a
specific
area
fussed
or
they
have
an
idea
of
like
something,
that's
important
to
them.
Awesome.
J
J
B
J
B
B
Up
to
you,
I
mean
I,
think
having
the
current
I
mean
it's
hard
to
keep
the
stuff
up
to
date,
but
it's
like
having
some
markdown
page
in
the
repo
that
has
some
status.
I
think
would
be
useful
and
then
I
already
made
a
label
called
fuzzing.
So
no
so
what
I
would
actually
do
is
I
would
just
triage
all
of
the
issues
that
are
marked
fuzzing
currently
in
github
and
then
for
like
future
work
or
ones
where
you
want
to
solicit
people.
I
think
that
would
be
good.
B
Oh,
the
other
thing
that
I
was
gonna
point
out.
Real
quick
is
that
I
am
going
to
this
week.
I'm
gonna
put
some
google
Summer
of
Code
projects
up
for
for
ongoing
one
of
them.
I'm
gonna
do
around
documentation
but
like
I
feel
like
fuzzing
might
actually
be
a
good
Summer
of
Code
project.
So
if
you
have
any
ideas
there,
we
could
put
something
up.
I
have.
J
Something
like
that,
like
I
I,
was
thinking
about
them,
but,
like
I,
don't
have
like
a
good
design
for
how
we
would
do
that,
but
I
think
that's
something
that
we
might
want
to
do
is
to
like
have
a
way
of
kind
of
linking
our
our
buzzing
produced
stuff
with
integration
test
that
we
have,
and
vice
versa.
I
would.
B
I
would
suggest-
maybe
if
you
have
the
time,
just
trying
to
capture
all
of
your
current
thoughts
for
future
issues
in
github,
and
we
can
at
least
use
that
for
some
group
discussion,
yeah
I
would
be
hesitant
for
google
Summer
of
Code
of
doing
anything
it's
too
complicated.
But
if
you
had
just
like
some
low-hanging
fruit
that
has
never
risen
very
high
on
the
priority
list,
but
you
kind
of
want
it
done.
That's
a
perfect
google
Summer
of
Code
project,
okay,.
B
B
H
B
My
personal
opinion
there
is
that
we
should
we
should
probably
make
that
extensible
in
some
way,
so
like
I,
think
it
would
be
really
easy
to
make
some
of
the
core
admin
handers
extensible
so
maybe
like.
If
we
wanted
to
put
you
know
like
some
HTML
handlers
in
there,
we
could
have
that
be
one
of
the
extensions
in
the
build
just
because
I
think
most
operators-
probably
don't
care
about
that,
and
you
know
just
in
the
interest
of
less
attack
surface
it
feels
like
we
should
make
that
separable.
E
I
B
So,
like
I
think
as
long
as
it's
compiled
out
that
that
that
makes
sense,
you
know,
there's
another
entire
class
of
project
here,
which
I've
talked
about
with
Alyssa
off
and
on
and
I
think
it
relates
to
stats
in
relates
to
runtime
part
of
like
stats
and
runtime
right
now,
they're,
basically
freeform
right.
It's
like
in
the
codebase.
We
have
a
bunch
of
strings
and
from
an
operation
standpoint
it
actually
is
kind
of
difficult,
and
you
know
for
a
long
time.
B
We've
talked
about
what
would
it
mean
if
we
actually
had
like
a
proto
schema
for
every
stat,
or
you
know
every
runtime
value
that
actually
in
the
schema,
had
things
like
help
text
and
like
whether
it's
a
gain
in
or
like
what
the
runtime
ranges
are
with
validation.
I
mean
this
is
a
it's,
not
a
small
project
but
like
it's
also
not
impossible
and
I
feel
like.
There
would
be
so
much
benefit
here,
because
now
you
know
like
not
only
could
you
have
better
checking
of
what
run
time.
B
You
know
values
there
are
and
deprecated
features
and
all
of
those
things,
but
you
could
write
tools
like
you
could
have
automated
help
text.
You
know,
so
that's
something
that
if
we
were
looking
towards
like
an
interim
project
or
something
along
those
lines
like
I,
think
that
would
be
really
amazing
and
would
be
along
these
lines
of
like
having
better
debug
ability
like
better,
better
dumping
in
the
admin
port.
B
And
that
would
also
allow
I
mean
if
you
think
about
where
you
can
go
with.
That,
is
that,
if
you
think
about
today,
like
the
runtime
discovery
service
is
basically
like
a
flat
struct,
you
could
move
to
sending
an
actual
proto
like
that
can
be
validated
or
in
the
future.
If
we
fetch
stats
out,
you
know
via
an
API
instead
of
having
like
a
flat
map
with
strings,
you
could
basically
dump
it
like
an
actual
proto,
so
I
think
it's
something
to
think
through.
It
could
be
very
powerful,
yeah.