►
From YouTube: Maintainer Q&A - Matt Klein, Lyft
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Maintainer Q&A - Matt Klein, Lyft
Open Q&A with Envoy maintainers. Come and ask questions and we will answer them live!
A
Hey
everyone,
I
think
I'm
live
thanks
for
having
me
for
this
maintainer
q,
a
my
name
is
matt
klein
a
software
engineer
at
lyft
still
trying
to
figure
out
this
meeting
platform.
I
don't
think
I
can
actually
interact
with
any
of
you
directly,
but
there's
a
live
q,
a
tab
on
your
screen
and
if
you
would
like
to
start
asking
questions,
I
can
go
ahead
and
answer
them
for
you
or
I
will
also
join
the
slack
room
if
we
want
to
ask
questions
that
way.
A
A
A
Scripting
has
worked
out
very
well,
but
again,
not
everyone
likes
to
program
in
lua,
and
you
know
we
don't
have
extension
points
for
all
of
the
different
ways
that
you
can
currently
extend
envoy
and
cpus
plus.
So
we
really
view
webassembly
as
the
future
of
envoy
extensibility,
and
you
know
we
view
that
for
again
a
couple
of
different
reasons.
A
One
of
them
is
that
we'll
allow
people
to
write
extensions
in
different
languages,
they're
comfortable
in
so
if
people
want
to
write
in
tiny
go,
they
could
do
that
if
they
want
to
write
in
russ,
they
can
do
that
if
they
want
to
write
and
save
c
plus
they
can
do
that
and
then
over
time.
I
would
expect
us
to
allow
webassembly
to
offer
extensions
in
all
of
the
places
today
that
c-plus
plus
can
be
used
to
extend
envoy,
which
is
you
know
again
at
this
point,
probably
10
or
15
or
20
different
extension
points.
A
So
I
think
it's
gonna
take
us
two
or
three
years
before
we
get
there,
but
I
am
really
extremely
excited
for
webassembly
as
a
technology
that
will
allow
people
to
dynamically
extend
envoy
and
also
when
associated
with
other
things.
We've
been
working
on
around
dynamic
configuration
of
filters
and
extensions.
A
So
the
use
case
that
comes
to
mind
is
think
of
something
like
a
web
application,
firewall
or
wav
filter,
or
maybe
we
want
to
you
know,
send
rules
dynamically
down
to
the
proxy,
and
maybe
those
rules
are
written
in
webassembly
and
they're
compiled
in
a
server
off
host,
and
then
they
are
dynamically
sent
down
to
envoy.
So
hopefully
that
answers
your
question,
but
I
you
know,
I
think
it's
a
very,
very
exciting
technology.
A
All
right,
it's
looking,
let's
see
next
question,
is
I'd,
be
interested
in
an
update
on
ud,
udp
support
and
envoy.
So
udp
support
is
I
I
would
say
it's
fairly
robust
at
this
point.
We
offer
obviously
udp
listeners
we
offer
udp
proxy
and
within
the
udp
proxy
we
offer
various
different
hashing
mechanisms.
A
So
I
you
know
I
I
would
definitely
encourage
people
to
go
through
and
look
at
that
support
and
if
it
doesn't
meet
your
what
I
would
call
raw
udp
use
cases.
Definitely
let
us
know.
Obviously,
udp
itself
is
also
used
for
quick
in
http
3..
So
there's
an
increasing
amount
of
effort
going
into
udp
robustness
and
I
actually
expect
us
to
have
a
public
alpha
support
of
quick,
http,
3d
support
and
envoy,
probably
in
the
next
couple
of
days.
So
that
is
quite
quite
exciting.
A
Okay,
let's
see
next
question,
do
you
think
we
will
see
oidc
support
directly
in
envoy
at
some
point
for
using
an
external,
oidc
idp
and
configure
that
directly
in
envoy?
To
be
perfectly
honest
with
all
of
you,
I
am
not
an
authentication
and
authorization
expert.
I
do
know
you
know
that
we
have
an
increasing
number
of
filters
that
are
operating
in
this
space
around
things
like
oauth
and
then
obviously,
we've
had
the
external
authorization
filter
for
quite
some
time.
A
A
A
I
think
when
envoy
was
starting
out,
I
I
definitely
viewed
it
as
very
important
to
you
know:
help
educate
people
on
envoy
internals,
and
so
I
I
think
doing
talks
and
writing
blog
posts
and
obviously
answering
questions
talking
to
folks
within
the
community
has
been
a
really.
You
know
important
thing
that
has
allowed
envoy
to
become
what
it
is
today.
A
Sadly,
I
I
I
don't
have
as
much
time
as
I
used
to
so
between
responsibilities
for
the
project
and
having
two
young
kids.
Frankly,
I
just
I
just
don't
personally
have
as
much
time
so
I
would
obviously
love
to
be
giving
more
deep
dive
internal
talks,
and
I
would
encourage
more
folks
to
give
those
talks
or
write
blog
posts
or
do
whatever
makes
the
most
sense
for
them,
but
I
I
just
don't
have
the
time
right
now.
A
What's
really
hard
is
to
find
people
who
care
about
documentation
and
education
and
examples,
and
all
these
kinds
of
things,
so
my
pitch
to
all
of
you
is
that
from
a
contributor
standpoint,
we
really
don't
actually
need
more
people
to
write
c,
plus
plus
code.
We
need
more
people
to
help
with
you
know
these
types
of
deep
dives
and
giving
talks
and
writing
blog
posts
and
working
on
documentation.
A
A
I
am
not
in
the
day-to-day
of
windows
and
I
actually
tried
to
have
one
of
the
maintainers
of
windows
join
this
chat,
but
unfortunately
the
platform
was
locked
and
we
could
not
add
him,
but
I
believe
we
are
very
close
to
offering
a
windows.
Ga-
and
you
know
that
won't
be
a
hundred
percent
feature
parity
with
linux,
but
it
will
be
close
and
it
should
be
usable
for
windows,
production
workloads,
and
I
know
that
there's
various
organizations
that
are
wanting
to
use
it
in
in
prod.
A
A
A
I
fully
expect
that
we
will.
You
know
that
we
will
see
russ
with
an
envoy.
You
know,
I
think
it's
a
very
exciting
path
that
that
language
has
taken,
and
you
know
I
I'm
no,
I'm
no
huge
supporter
of
seepless
plus
myself.
So,
if
there's
a
better
alternative,
I
think
that
would
be
great.
But
like
all
these
other
projects,
we
have
hundreds
of
thousands
of
complicated
lines
of
code
and
it's
not
reasonably
possible
to
rewrite
everything.
A
A
A
A
A
Okay,
let's
see
next
question:
what
is
the
biggest
thing
you
would
want
to
improve
in
envoy
right
now?
If
you
had
all
the
time
you
wanted.
Oh
that's
a
tough
one.
I
I
I
think
for
me
it
it
would
probably
still
be
around
documentation
and
onboarding.
You
know
I.
I
think
we
still
do
a
great
job.
You
know
around
the
code
and
the
features
the
feature
velocity
continues
to
be
huge.
A
You
know,
there's
always
small
improvements
that
we
can
do
in
code
quality
or
you
know
in
testing
coverage
or
in
performance
or
all
of
those
things.
But
you
know
we
have
so
many
extremely
talented
contributors
that
work
on
that
stuff,
that
it's
not
a
huge
concern
of
mine,
but
I
you
know,
I
think,
in
terms
of
things
that
we
can
improve.
It
really
is
that
onboarding
experience
and
what
I
do
mention
to
people,
which
I
find
very
interesting,
is
that
I'm
very
frequently
told
with
envoy.
You
know
two
different
things.
A
A
So
for
those
that
don't
know,
xds
is
the
name
of
our
generic
configuration
api,
and
you
know
we
started
a
long
time
ago
with
just
a
few
different
xds
apis
things
like
eds
or
endpoint
discovery,
service,
cds,
cluster
discovery,
service,
lds,
listener
discovery
service
and
over
time
you
know,
we've
developed.
I
don't
even
know
now,
probably
between
you
know,
10
or
so
10
or
so
different
apis
and
the
main
thing
that
xds
provides,
and
I
actually
think
that
xds
has
been
the
main
contribution
of
envoy
versus
the
code.
A
A
I
think
there's
internal
systems
and
tools
at
various
companies
that
speak
xds.
So
you
know
we've
effectively
developed
a
network
configuration
api.
You
know
for
for
these
types
of
systems,
so
I
think
the
real
benefit
you
know
is
not
really
one
of
performance.
I
think
the
real
benefit
of
xts
is
it's
giving
us
a
common
language
that
we
can
use.
You
know
that
will
allow
us
to
actually
configure
these
types
of
systems
across
the
industry
and
that
has
spawned
a
huge
vertical
ecosystem
of
products
and
services
based
on
envoy
and
eventually
grpc
and
other
systems.
A
Okay
next
question:
based
on
your
experience
in
growing
and
building
a
community
around
envoy,
what
advice
would
you
give
to
newly
founded
oss
projects?
Besides
the
onboarding
experience,
I've
given
several
talks
on
this
and
it's
something
that
I
think
about
a
lot,
and
I
don't
think
there's
I
don't
think,
there's
one
one
answer
here.
I
do
think
that
the
onboarding
experience
is
very
important,
as
has
been
noted,
so
you
know
things
like
a
slick
ui
and
making
sure
that
there's
examples
ready
to
go
and
things
like
docker
and
docker
compose.
A
A
Building
community
is
hard
work
and
it
really
requires
a
lot
of
effort
and
a
lot
of
patience
and
a
lot
of
time
and
the
biggest
piece
of
advice
that
I
actually
give
people
which
sounds
really
really
simple
and
probably
obvious,
is
just
to
be
really
nice.
You
know
when
you,
when
you
start
a
new
project,
you,
don't
you
don't
have
a
community,
you
don't
have
anyone
to
actually
help
and
encouraging
new
contributors
and
new
maintainers
and
new
people
to
join
up
is,
is
the
most
important
thing
so
being
very
welcoming
to
everyone
that
comes.
A
You
know,
making
sure
that
communication
is
just
welcoming
and
nice
and
you
know
taking
the
time
to
answer
people's
questions
and
get
them
onboarded
and
facilitate
helping
them
with
the
code
and
all
of
those
things.
I
think
you
know
that
that
is
probably
the
most
important
thing
I
think
there's
smaller
items
like
trying
to
have
good
issues
for
new
contributors
and
again
good
documentation
and
all
of
the
ancillary
non-code
things
that
you
know
people
tend
to
think
about
after
the
code.
A
But
in
my
opinion,
in
my
experience
they
tend
to
be
more
important
than
the
code
itself.
So
I
would,
I
would
definitely
definitely
encourage
focusing
on
those
things,
and
I
don't
have
the
link
handy
right
now,
but
I
gave
a
talk
at
oscon
a
couple
of
years
ago.
I
think
the
tight
it's
on
youtube
and
I
think
the
title
is
you
know
something
around
the
the
you
know
amazing
success
of
envoy,
so
I
definitely
searched
for
that
talk
and
I
gave
an
entire
talk
on
this.
A
Topic-
let's
see
next
question:
do
you
think
some
part
of
the
envoy
magic
could
be
rewritten
using
ebpf?
Would
it
make
sense
on
the
performance
side?
I
I'm
also
not
an
ebpf
expert.
I.
I
definitely
believe
that
there
are
probably
large
parts
of
envoy
that
could
be
written
using
using
ebpf,
it's
theoretically
possible,
that
all
of
envoy
could
be
written
using
ebpf.
You
know
whether
that's
practical
or
not-
I
don't
know,
but
I
I
do
think
that
over
time
we
will
definitely
see
more
functionality
move
into
the
kernel.
A
Just
from
our
just
from
a
performance
standpoint.
We
already
see
projects
such
as
psyllium
that
rely
both
on
ebpf
as
well
as
envoy,
where
they
have
a
split
of
doing.
You
know
a
bunch
of
functionality
in
the
kernel
in
terms
of
things
like
tls
offload
and
more
efficient
routing
of
packets.
You
know
between
processes,
and
then
they
also
route
up
to
envoy
to
do
various
policy
aspects.
A
So
you
know
they
would
certainly
be
the
best
people
to
ask
in
terms
of
why
they've
chosen
to
split
things
where
they
have
and
whether
over
time
they
expect
more
functionality
to
move
within
evpf.
I
would
imagine
the
the
biggest
issue
on
the
ebpf
side.
Is
that
and
again
I'm
not
an
expert
here
is:
I
think
there
are
restrictions
on
the
type
of
code
that
can
run
within
abpf,
for
example.
A
My
understanding
is
that
I
don't,
I
don't
think
you
can
have
things
like
loops
and
various
other
things
you
know,
so
I
think
it
would
be
difficult
to
rewrite
all
of
envoy
as
an
eppf
program,
but
you
know
between
some
combination
of
ebpf
and
kernel
offload,
and
you
know
running
in
you
know
user
space
projects
like
envoy.
I
I
have
no
doubt
that
things
will
shift
around
over
time.
A
Okay,
let's
see
next
question
since
documentation
is
the
main
improvement
part,
what's
the
main
thing
in
envoy
lacking
documentation
for
now.
In
your
opinion,
besides
generic
newcomer
stuff,
I
think
the
main
thing
that
we're
lacking
right
now
in
envoy
around
documentation
actually
comes
back
to
extensions.
I
think
so.
For
those
who
don't
know
enboy
uses
protobuf
as
our
configuration
language
and
I'm
a
huge
proponent
of
protobuf.
I
think
it's
an
amazing
project
and
I
think
in
proto3
they've
done
a
really
incredible
job
of
allowing
conversion
between
yaml
and
json
and
proto.
A
A
So
there's
a
protobuf
type
called
an
any
and
it
allows
you
to
specify
a
generic
type
and
then
have
configuration
within
that,
and
it's
done
for
a
very
good
reason,
which
is
that
envoy
allows
extensions
to
be
compiled
into
the
binary
that
enboy
doesn't
know
about
ahead
of
time.
So
we
need
this
generic
mechanism,
where
we
can
offer
extensions
that
envoy
core
doesn't
know
about,
and
then
users
can
actually
configure
them.
So
you
know
we
use
this
product
off
any
and
type
url
configuration
mechanism.
A
A
I
think
that
it's
not
a
big
deal,
but
for
new
users
it
can
be
very
daunting,
and
so
that's
what
I
was
talking
about
before,
where
we're
starting
to
put
in
a
lot
of
effort
into
cross-linking
between
various
aspects
of
the
documentation,
so
that
it's
automated.
So
you
go
to
an
extension
point
and
you
can
you
know,
click
through
all
of
the
different
extensions
that
are
available.
We
want
to
provide
example,
snippets
for
every
extension
so
that
the
user
can
just
see
what
they
have
to
put
into
their
config.
A
Again,
I'd
like
to
do
a
vs
code,
plugin,
where
you
know
it
actually
has
auto
completion,
so
I
think
there's
some
things
that
we
can
do
there.
That
will
really
help
the
99
use
case.
So
I
I
think,
that's
the
main
thing
and
I
think
the
work
is
ongoing,
but
if
you're
passionate
about
it,
definitely
please
please
reach
out
and
help
us
all
right.
A
A
We
are
retaining
the
the
opportunity
to
do
a
v4,
but
there
are
no
plans
to
do
it
and
realistically,
I
think
we
are
many
years
to
never
out
from
it
and
instead
of
doing
a
v4,
we
are
working
now
on
a
minor
version
proposal
which
will
try
to
actually
have
it'll,
be
a
compromise
between
doing
a
clean
new
version
where
we
can
actually
delete
fields
and
allowing
us
to
have
clients
that
will
remove
deprecated
functionality
that
may
have
been
deprecated
for
several
years
so
yeah.
I
would
definitely
watch
this
space.
A
I
think
it's
something
that
we
will
continue
to
improve
and
learn
about.
But
at
this
point
I
think
the
the
amount
of
effort
around
the
industry
that
went
into
v3
was
not
worth
the
benefit,
and
part
of
that
is
actually
just
hindsight
on
on
time
and
growth
of
the
project.
We
started
talking
about
v3
at
this
point.
It
was
probably
a
year
and
a
half
ago,
and
just
with
the
meteoric
rise
of
the
project,
we
didn't
have
as
many
users
as
we
have
now.
A
So
you
know,
I
think,
when
we
started
talking
about
it,
we
really
underestimated
the
you
know
the
burden
that
it
would
cause
people.
We
didn't
understand
it,
and
I
think
we
have
a
better
understanding
now,
coupled
with
just
the
large
usage.
So
I
think
you
know
I
I
think
we've
learned
a
lot.
I
think
we're
going
to
continue
to
improve
in
this
area
and
I
would
expect
us
to
do
better
in
the
future
and
no,
I
don't
expect
to
see
a
v4
anytime.
Soon.
A
A
All
right,
let's
see,
since
this
is
a
maintainer
q.
A
could
you
share
with
us
how
things
went
regarding
your
work
as
an
envoy,
maintainer
and
as
an
engineer
at
lyft.
At
the
same
time,
even
if
both
are
linked
like
what
balance
did
you
find
between
work
on
envoy
that
was
related
to
lift
needs
and
work
on
envoy
that
was
unrelated?
A
Was
there
any
real
discussion
about
this,
or
did
things
just
happen?
Naturally,
this
is
a
complicated
topic
and
I've.
I've
done
a
few
podcasts
on
this,
and
I
would
definitely
encourage
folks
to
you
know
to
listen
to
some
of
the
podcasts
that
I've
done
in
this
area,
but
very
quickly.
I
would
say
it's
complicated.
I
I
think.
As
an
industry,
we
don't
do
a
very
good
job
of
being
honest
with
people
about
the
needs
of
open
source
in
terms
of
just
what
it
means
to
do.
A
A
I
also
encourage
people,
like
the
poster
mentioned
in
their
question,
to
try
to
find
common
ground
of
working
on
open
source.
You
know
for
things
that
the
company
actually
cares
about,
and
I
think
that's
that's
the
way
that
it
tends
to
go
the
best.
So
I
will
stop
there.
I
will
be
in
slack
if
people
want
to
continue
this
conversation
and
anyway.
Thank
you
very
much
for
having
me
and
thank
you
for
coming
to
this
maintainer
q,
a.