►
From YouTube: Closing Remarks - Matt Klein, Lyft
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Closing Remarks - Matt Klein, Lyft
Join us for KubeCon + CloudNativeCon in Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
Yeah,
so
thank
you,
everyone
so
much
for
for
coming.
This
was
absolutely
fantastic.
I
thought
everyone's
talks
were
awesome,
I'm,
typically
very
bored
at
most
conferences,
but
this
was
this
was
awesome.
It
was
great,
but
you
know
thank
you,
everyone
for
coming
out,
and
it
was
great
to
hear
from
just
a
different
variety
of
use
cases
and,
as
I
was
saying
in
the
opening
to
see
everyone
here
and
super
excited
and
just
to
see
what
everyone
is
building
in
such
a
short
period
of
time,
only
two
years
of
open
source
has
been
super
fantastic.
A
So
what
I
think
we're
gonna
do
just
for
this
short
closing
session,
because
I
know
that
people
are
eager
to
go
out
and
mingle
is
we'll.
Do
just
a
little
quick
rundown
of
some
of
the
bigger
roadmap
items
that
we
know
that
people
are
going
to
be
working
on
in
2019,
I'm
gonna
introduce
all
of
the
maintainer
are
who
are
here?
A
I
think
there's
a
there's
a
couple
of
main
things
that
we
know
that
people
are
gonna
work
on
in
2019,
as
was
already
talked
about
before,
there's
a
bunch
of
ongoing
scalability
work.
So
that's
not
only
robustness
protection
but
also
decrease
memory.
Usage,
decrease,
CPU
usage,
there's
already
been
quite
a
lot
of
optimization
dumb,
but
there's
definitely
more
that
we
can
do
so.
I
would
expect
in
2019,
particularly
as
more
and
more
people
run
on
boy
as
a
directly
internet-connected
proxy
or
we're
gonna
see
more
robustness,
security,
fuzzing
scalability
stuff,
which
is
all
fantastic.
A
A
For
those
of
you
that
don't
know,
quic
is
a
next-generation
protocol
that
will
hopefully
give
better
networking
performance
in
lossy
networking
conditions.
There's
plans
around
Kafka,
so
I
think
this
is
a
very
highly
requested
feature.
So
we
actually
have
some
work.
That's
already
been
started
here.
The
goal
here
is
gonna,
be
to
start
with.
You
know
a
basic
observability
filter,
much
like
we
have
for
MongoDB
and
then
hopefully,
actually
move
into
more
active
l7,
proxying
and
load
balancing,
which
I
think
could
be
pretty
amazing.
A
A
You
can
think
of
this
as
like
TCP
dump
at
l7
in
Envoy
I
think
there
are
some
pretty
incredible
things
that
we
can
build
here,
both
from
a
CLI
tooling
perspective,
but
also
from
an
API
perspective,
so
think
of
an
XTS
API
that
can
not
only
send
tapping
configurations
to
envoy
but
then
actually
get
tap
data
back
from
envoy
over
an
API,
and
you
can
imagine
how
this
might
be
built.
You
know
you
could
do
DDoS
detection
tooling,
where
we're
automatically
sampling
requests,
building
building
profiles
then
actually
sending
blocking
rolls
back
to
envoys.
A
So
there
are
some
pretty
awesome
things
that
we
can
do
there,
both
from
security
debugging
I'm
pretty
excited
about
this
another
one
is
generic
outbound
proxy.
This
has
been
one
of
the
most
highly
requested
envoy
features,
so
allowing
envoy
to
be
used
to
talk
to
a
whole
variety
of
different
domains
and
have
that
work
in
a
scalable
way.
A
A
A
If
that
interests
you
please
come
and
talk
to
me,
this
is
going
to
be
a
major
open
source
effort
that
we'll
be
doing
with
with
all
of
you-
and
you
know
like
I
said
before,
since
we
are
not
a
paid
product,
you
know
we
don't
have
an
official
roadmap.
So
what
what
often
happens
is
we
are
community
driven?
So
you
know
what
all
of
you
either
ask
to
build
or
want
to
build.
You
know,
I,
think,
that's
what
we'll
end
up
getting
built
so
I
think
it's.
A
It
always
interests
me,
because
people
are
always
saying
hey.
You
know
we
need
a
road
map
like
where's
your
road
map
and
sure
there's.
You
know,
there's
some
big
things
that
we
know
that
we're
gonna
end
up
working
on,
but
ultimately
the
the
road
map
is
built
by
all
of
you.
So
you
know,
I
would
continue
to
encourage
you
to
send
us
emails
and
open
issues
and
and
talk
to
us
and
slack,
and
you
know,
talk
here
and
tell
us
what
what
you're
looking
for
so
people
are.
A
You
know
also
often
asking
like
how
can
people
help
and
you
know
it
doesn't
always
have
to
be
code
changes
and
C++
is
not
what
many
people
want
want
to
be
working
on
and
that's
fine
as
it
turns
out,
there's
lots
of
non-coding
things
that
need
to
be
done
that
are
hugely
hugely
important
and
if
anything
are
more
important
than
actual
code
changes.
So
those
are
things
like
documentation,
we're
always
looking
for
people
to
help
make
our
documentation
better.
A
That's
not
only
fixes
to
the
reference
documentation,
it's
to
make
fact
entries
better
or
to
have
examples.
It's
it's
as
small
as
if
you
read
the
documentation
and
you
were
confused,
please
do
a
PR
and
help
the
next
person
not
be
confused
by
the
same
thing
that
you
were
confused
by
that's
hugely
impactful,
and
it's
it's
just
a
great
thing
to
do.
A
Would
love
blogs
we're
happy
to
post
them
on
the
Envoy
proxy
blog
or
to
cross
link
to
your
company's
blog,
but
blogging
is
a
great
way
to
get
the
word
out
and
to
help
the
larger
community,
as
I
was
saying
before,
to
go
along
with
documentation.
There's
examples
that
that's
always
great
and
you
know
just
open
issues,
we're
very
active
in
github.
A
So
you
know
please
email
our
user
lists
or
dev
lists,
or
you
know
open
issues
or
talk
to
us
on
slack
a
lot
love
to
talk
different
people,
and
we
are
always
looking
for
new
maintainer,
the
the
rate
of
incoming
code
changes
that
we
have
continues
to
go
up.
I
think
now
we're
typically
have
30
or
40
or
50
PRS
open
at
once
and
we're
merging
10
or
15
changes
a
day.
You
know
we
have
people
that
work
on
a
full-time,
but
we
we
need
more,
more
people.
A
So
if
your
organization
supports
you
being
a
maintainer
and
you're
interested
would
love
to
chat
with
you
to
see
if
that's
a
possibility,
so
that
brings
us
to
our
maintainer
z'.
So
for
those
of
you
that
don't
know
from
a
governance
perspective,
we
have
a
dual
maintainer
status,
it's
kind
of
loose,
but
we
have
what
are
known
as
senior
maintainer
z',
and
then
we
have
regular
maintainer.
A
So
currently
we
have
five
senior
maintainer
and
if
people
could
just
come
on
up,
that
would
be
great.
Obviously
we
have
myself
from
lift
ELISA
from
Google
who
you
heard
from
before.
We
have
Harvey
from
Google.
We
have
Stefan
who's
not
present
today
and
we
have
Greg
from
Apple
and
then
additional
maintainer.
So
we
have
a
D
from
touch
I
haven't
seen
him
today.
Is
he
here?
Oh
there,
you
are
okay,
great
Nissan,
also
from
Tut
trade.
A
A
A
A
general,
Q&A
and
I
can
bring
this
around
and
you
know
we
have
Mike
that
can
be
passed
around,
but
just
a
you
know
a
couple
of
different
things:
you're
welcome
to
ask
whatever
questions
you
want
of
all
of
us,
but
just
some
general
questions
are,
you
know:
are
there
things
that
the
project
can
be
doing
today
to
help
you
to
succeed,
that
that
were
not
right?
I
mean
that
would
be
great
to
talk
about.
A
You
know:
are
there
particular
high
level
missing
features
that
that
would
help
you,
but
that
we
don't
have
currently
and
really
anything
else,
so
I
think
what
we
can
do
is
we
have
this
thing
so
I'll
leave
this
up
here
and
then,
since
it's
being
recorded,
we
can
pass
this
mic
around,
but
would
just
like
to
open
it
up
for
questions.
So
does
anyone
want
to
start
I
guess?
Maybe
it
would
be
easier
if
I
just
repeated
the
question
so
go
ahead.
A
B
So
I
can
say
essentially
having
done
a
lot
of
the
hardening
work.
An
envoy
we've
had
this
problem
already
in
Google,
when
we
switched
to
quick
right,
so
Google
tends
to
use
quick
rtcp
replacement
for
majority
of
our
traffic,
or
rather
roughly
a
third,
depending
on
where
it's
supported
and
we've
been
able
to
do
the
same
hardening
for
kind
of
this
in
user
space.
Udp,
so
I
assume
that
that
would
translate
fairly
well
to
you
just
face
TCP.
A
The
question
is
on:
Bowie
has
prom
support
built-in,
but
we
don't
have
histogram
output
today.
I
could
just
answer
that
super
quick,
it's
not
through,
not
wanting
it.
It's
just
that
no
one
has
come
forward
to
actually
do
that.
Work
I,
don't
actually
think
it's
very
difficult,
so
someone
one
of
you
may
be
you
know
it
just
just
needs
to
finish
it.
It's
honestly,
probably
a
couple
days
of
work,
but
we
just
need
I
think
none
of
the
existing
organizations
use
it.
So
no
one
has
done
it.
A
C
D
Would
add
to
that
that
over
time
there
has
been
an
up
streaming
of
some
of
the
filters
that
have
existed
in
the
sto
repository
to
the
main
on
boy
repository
and
that's
been
beneficial,
because
these
are
more
general
than
just
yeah.
Being
history
are
specific
and
pots
of
mixture
I've
ever
moved
in
and
then
that
kind
of
thing
I,
don't
know
like
listen.
You
want
to
talk
a
bit
about
this
year,
you're
our
resident
SEO.
E
A
Yeah
I
mean
that
the
one
thing
that
I
would
add
there
is
I
I,
think
to
your
point
like
there's
one
direction
in
which
we
could
make
a
control
plane
that
is
part
of
envoy,
proper
I.
Think
we
probably
it's
unlikely
that
we'll
do
that,
because
it's
a
decision
that
we've
made
to
clearly
separate
the
data
plan
from
the
control
plane
and
to
allow
like
I,
was
singing
in
the
intro
talk
to
allow
lots
of
different
projects
to
be
successful
and
to
differentiate
on
top
and
I.
A
Think
that's
one
of
the
things
that's
made
envoy
so
popular
is
that
we
don't
stipulate
that
people
have
to
do
it
in
a
particular
way,
so
I
think
we're
really
committed
to
making
sure
that
we
have
a
stable
API
that
works
for
sto
or
for
other
control
planes,
but
I
don't
know
that
we
would
want
to
compete
or
subsume
with
this
do.
Does
that
answer
your
question.
A
F
So
so,
as
you
saw
today,
control
plane
servers
have
basically
what
I
think
three
parts
there's
a
data
monitoring
part
that
actually
you
know,
does
the
transformations
that
transform
your
your
company's
topology
into
you
know
the
Envoy
API,
then
there's
a
caching
layer
and
then
there's
a
server
layer,
I
think
the
go
control
plane
and
similarly,
the
Java
control
plane
projects
try
to
abstract
the
parts
that
can
be
shared
between
different
control,
plane,
solutions
being
the
server
and
the
cache.
And
on
top
of
that
you
can
build.
F
You
know
the
control
plane
that
your
organization
needs
or
if
you're,
a
cloud
provider
or
an
infrastructure
provider.
You
can
provide
something
that
you
know
can
be
used
by
different
organizations
in
terms
of
continued
maintainer
ship,
as
you
saw
today,
and,
for
example,
at
least
from
this
perspective,
we
we
use
go
control
plane.
So
we
have
vested
interest
in.
You
know
continue
to
maintain
that
project.
I,
don't
know.
A
Yeah
and
and
what
one
thing
that
I
would
add
to
just
about
control
planes
in
general,
and
it's
related
to
the
last
question
is
you
know,
I
think
a
couple
of
years
ago,
sto
started
and
unvoiced
started.
There's
a
there's,
a
dream
that
they'll
be.
You
know
one
control
plane
right
that
and
and
that's
a
that's,
a
great
dream.
A
So
you
know
I
I,
think
like
as
we
can
abstract
common
functionality
into
the
base
envoy
project,
whether
that
be
control,
plane,
Stubbs
or
features
or
API
is
like
will
obviously
do
that.
But
I
am
I.
Don't
know
that
right
now,
it's
in
the
projects
best
interest
to
try
to
build
a
control
plane
that
would
end
up
aged
is
competing
with
a
bunch
of
other
control
planes
and
probably
not
satisfy
their
concerns
or
not
satisfying
everyone's
concerns.
I.
D
It's
largely
probably
gonna
be
a
hugely
breaking
change,
but
the
idea
is
to
make
homeboy
more
scalable
on
its
control
plane
and
to
allow
you
know,
resources
to
be
lazily
fetched
and
so
on,
and
there's
a
bunch
of
work
going
on
right
now
by
various
Googlers
and
folks
from
Red
Hat,
who
some
of
who
are
here
today
and
I,
think
a
lot
of
that's
going
to
start
landing
in
q1.
So
that
should
be
pretty
interesting
and
that
will
probably
arrive
in
go
control
plane
as
it
as
that
work
continues.
F
And
just
quickly
similar
to
Matt's
plug,
for
you
know,
continued
community
efforts
and
maintainer
ship
for
the
you
know,
main
envoy,
proxy
project
same
goes
for
the
control
plane
solution.
So
if
there's
any
missing
features
or
bugs-
or
you
know
something
that
you'd
want
to
see
same
rules
apply.
We'd
love
the
community
I.
A
Okay,
you're
putting
me
on
the
spot
here.
The
the
general
plan
right
now
and
like
I
said,
is
that
we'll
have
a
bunch
more
information,
hopefully
in
the
March
issue,
I'm
frame.
But
the
goal
is
we're.
Gonna
run
envoy
on,
like
I
said
both
Android
and
iOS,
so
iOS
will
be
Swift,
Android
I
think
will
end
up
being
Kotlin,
and
this
is
going
to
be
an
integrated
solution
where
we'll
run
envoy
as
part
of
a
higher
layer
library
which
will
open
source
and
there's
going
to
be
deep.
A
Protobuf
integration
around
certain
common
features
around
API
annotations,
and
we
think
that
we
can
do
some
very
interesting
things
at
the
API
layer,
so
it'll
be
both
about
low
low
low
layer
networking.
So
around
commonalities
like
TLS
1.3,
quick,
like
a
you,
know,
load
balancing
mobile
XDS,
but
now
at
the
API
layer
we
can
do
some
very
interesting
things
around
annotations
around
things
like
caching
and
offline
API
is
and
deferred.
A
Api
is
and
a
bunch
of
other
stuff,
but
we
can
implement
all
that
logic
in
Envoy
and
have
that
be
similar
across
all
platforms,
so
basically
bring
at
least
some
of
the
goals
of
the
out
of
process,
architecture
to
the
mobile
clients
or
to
the
edge
clients
so
from
scale
I
mean
you
know,
we're
talking
millions
of
devices.
Oh.
A
Sorry
you're
talking
like
code
size,
yeah,
that's
that's
a
tougher
one.
I
I
think
that
there
are
going
to
be
efforts
and
the
envoy
layer
to
continue
to
strip
code
out
that
we
don't
need.
So
we
may
see
more
changes
next
year
around
further
build
flags
moving
more
code
into
extensions,
which
I
know
that
the
Google
folks
would
love
anyway,
because
it's
less
less
code
that
needs
to
be
security
vetted
so
I
mean
you
know,
there's
probably
winds
from
some
of
this
work
in
and
a
bunch
of
different
bunch
of
different
avenues.
A
The
question
is:
what
is
the
plan
around
my
sequel
and
Kafka
I
I?
Think
that's
ongoing.
I
can't
speak
for
my
sequel,
because
that's
being
driven
for
by
VMware
is
anyone
here
from
VMware?
Who
can
speak
is
oh,
do
you?
Can
you
come
on?
Okay,
come
on
come
on,
come
on,
you
can
talk
about
Kafka,
while
you
walk
up
here
so
so
sure
and
we'll
talk
about
my
sequel,
but
in
terms
of
Kafka
I.
A
Think
it's
less
clear
right
now,
I
think
even
the
folks
at
confluent
are
pretty
excited
about
a
bunch
of
the
stuff
that
we
can
do
at
the
proxy
lair.
Honestly
I
think
it's
a
problem
of
having
too
many
things
that
we
can
do
with
this
and
having
to
scope
it
down.
So
I
think
we're
gonna
start
with
just
metrics
and
then
we'll
see
where
we
can
go
from
there,
but
there's
so
many
things
in
terms
of
converting
like
HTTP
traffic
to
Kafka
or
back
and
forth
or
load-balancing,
there's,
there's
all
kinds
of
stuff.
H
My
name
is
freedom,
I
work
on
the
East,
your
project,
and
so
the
plan
for
my
sequel
is
like
the
planet
turned
that
into
a
generic
sequel,
pass
a
library
that
will
end
up
in
my
core
such
that
we
can
actually
develop
wire
protocols
for
my
sequel,
post,
crass
and
what
else
that's
possible,
and
today
the
the
sequel
parser
is
actually
gonna.
Give
you
information
in
terms
of
the
tables
accessed,
and
you
know
the
rows
and
what
kind
of
tables
are
actually
accessed
in
a
given
query.
What
was
written
and
what
was
like?
H
You
know,
right
from
plus,
you
can
do
some,
our
back
stuff
on
those
things
in
terms
of
like
saying,
you're
not
allowed
to
access
this
table,
no
you're
not
allowed
to
write,
write
to
this
table,
and
so
on
and
over
time
we
plant
like
just
enhanced
such
that
you
can
actually
do
more.
Intelligent
sharding,
like
reads:
go
to
some
replicas
as
well
writes
code
or
something
else,
and
so
yeah.
You
can
do
a
whole
bunch
of
things
in
terms
of
once.
H
A
E
D
So
I
think
there's
like
a
couple
of
things
there.
So
there's
a
number
of
efforts
to
try
and
you
know,
move
things
out
revolver
and
make
things
more
extensible.
So
there's
deciding
that
that's
we
would
one
day
essentially
have
a
side
call
RG
RPC
filter,
where
you
can
essentially
move
anything
that
would
be
an
envoy
off
to
a
you
know,
a
generic
G
RPC
service
and
that
and
already
lots
of
filters
sort
of
work
that
way
or
have
that
feature,
but
this
would
be
a
sort
of
generalization
of
that.
D
The
second
thing
is
this:
increased
move
towards
like
dynamic
language
support
like
which
is
like
loadable.
You
know
over
LDS
such
as
legit
or
I,
assume
that's
the
way,
the
JavaScript
extension
works
and
certainly
web
assemblers,
something
that's
coming
up
and
that
we
have
an
open
issue
to
track
and
I
think
you
know
eventually
we'll
be
able
to
it.
You
know
you
weren't
urine
actually
need
to
necessarily
have
these
things
built
since
the
Envoy
binary
you'll
just
be
able
to
deliver
these
things
dynamically
and,
yes,
maybe
yeah
I'm.
B
Just
a
little
further
thought
here,
I
think
I
think
we
basically
haven't
gotten
to
the
point
where
we
have
to
worry
about
that,
because
so
far
everything
that's
been
suggested
over
the
last
year
or
two,
and
that
I
see
upcoming
is
something
that,
like
dozens
of
companies,
are
really
excited
to
have
an
envoy,
but
just
add
kind
of
one
more
note
of.
Where
does
it
end?
B
I
remember
about
ten
years
ago,
when
I
was
working
on
the
trains
from
our
proxy
to
a
v1
to
v2
my
tech
lead
was
completely
convinced
in
like
two
years
we
would
spin
down
in
a
maintenance
mode
and
11
years
later
were
now
like.
My
Creator
team
is
like
a
40-person
team.
We're
still
finding
ways
to
you
know,
make
proxying
faster.
You
know
we
did
h2.
We
did
quick
and
I
feel
like
there's
always
going
to
be
new
and
interesting
ways
to
make
proxying
faster
and
better
and
add
extensions
and
add
new
options.
B
C
I'm
only
now
looking
at
other
proxies
that
or
other
server
architectures
that
exist,
the
Apache
hbd
has
been
around
for
decades.
Its
core
is
incredibly
stable
and
slow-moving,
but
people
make
extensions
to
it
all
the
time
and
still
do
and
I
think
if
we
move
into
that
kind
of
ecosystem,
where
there's
a
really
robust
at
some
point,
maybe
we'll
have
an
ABI,
but
probably
we're
not
ready
for
that.
Yet
that
that's
but
I
mean
I.
C
A
Yeah
I
mean
there's
I
I
think
as
was
said,
there's
things
that
we
know
that
we
need
to
do
that
are
going
to
make
this
better
so
moving
last
year
to
the
the
extension
model
has
worked
out
very
well,
so
we'll
continue
to
add,
hook,
points
and
continue
to
evolve
to
a
core
and
extensions
model.
We
will
likely
eventually
support
loadable
modules.
A
It
wouldn't
actually
be
that
hard
again,
just
someone
needs
to
do
the
work
and-
and
then,
as
was
just
said,
I
mean
we
know
that
we
need
to
move
to
a
more
stable
API
so
that
we
guarantee
that
we
won't
break
extensions.
We
have
not
done
that
yet
because
we
don't
want
to
decrease
velocity,
but
we're
probably
reaching
the
point
soon
in
which
we're
gonna
have
to
do
that,
so
that
that
might
be
a
2019
thing.
It's
it's
unclear.
A
D
I
A
C
I
A
Like
we're
obviously
trying
to
build
the
api's
in
a
way
such
that
that
can
happen
to
be
honest
from
a
practical
perspective
like
once,
the
data
plane
reaches
a
certain
number
of
like
physical
users.
It
becomes
frankly
a
larger
cell
I
think
for
someone
to
swap
in
some
other
proxy,
because
sure
you
can
implement
the
API,
but
I
mean,
as
we
all
know,
like
api's,
have
a
lot
of
intention
in
them.
That
might
not
be
clearly
specified
and
someone
can
implement
XDS.
It's
gonna.
Take
them
a
long
time
to
make
it
work
like
envoy.
A
B
In
line
with
that,
I
can
speak
to
that
a
bit
because
we
spent
a
lot
of
time
in
Google
kind
of
debating
about
whether
or
not
we
wanted
to
implement.
You
know
something
common
that
we're
to
the
Envoy
and
then
try
to
be
bug
for
bug
and
feature
feature
compatible,
and,
as
you
see,
we
decided
what
we
wanted
to
do.
B
You
know
we
invested
in
envoy
because
it's
just
really
hard
to
keep
up
with
any
proxy
that
has
the
sort
of
community
that'll
boy
does
right
and
then,
as
we
had
quick
integration
and
as
we
add
you
know,
school
and
as
we
add
all
these
extra
functionalities,
you
may
support
the
XDS
API.
But
actually
trying
to
be,
you
know,
feature
compatible
and
bug
compatible
is
just
is,
is
going
to
be
really
tough
but
again,
for
you
know
simpler,
you
skate.
So
this
is
where
people
just
want
to
proxy
their
data
into
you,
load-balancing,
totally
fine.
B
A
A
Sure
mm
yeah,
so
the
question
is,
as
we
add,
more
and
more
features.
We
are
shipping.
Basically,
this
docker
container
today,
which
is
like
the
super
fat
image.
Will
we
ever
do
streamline
things
I'll?
Let
other
people
weigh
in
I
think
the
answer
is
definitely
yes.
I
think
we
already
have
a
problem
in
which
we
may
not
be
setting
up
things
with
exactly
the
defaults
that
people
expect.
I.
Think
Harvey
message
me
about
this
today.
A
The
the
problem
is
that,
as
we
were
just
saying
before
it's
hard
to
make
it's
impossible
to
make
everyone
happy
so
so
then
it's
like:
where
did
where
do
you
end?
I
mean
it's
like
we
do
the
light
image,
but
then
someone
wants
the
light
image
plus
X
and
then
is
now.
We
have
like
17
images
with
different
settings,
so
I
guess
my
answer
and
I
would
like
everyone
else
to
weigh
in
is
I.
A
Do
think
that
we
are
going
to
have
to
revisit
what
is
in
the
stock
image,
and
maybe
what
some
of
the
defaults
are.
Personally
I,
don't
want
to
end
up
offering
you
know
like
the
7,
the
70
Windows
versions.
No
no
offense,
but
you
know
I,
don't
want
to
have
like
envoy
enterprise
and
or
something
like
that
or
you
know,
because
that's
just
not
it's
not
super
sustainable.
So
we'll
have
to
find
some
happy
middle
ground.
Does
anyone
have
any.
D
Yeah
I
get
everything
will
be
interesting
to
revisit
and
just
like
the
scenes
in
the
talks
today,
the
default
configuration
settings
for
various
things,
whether
they're
circuit
breakers
or
statistics,
and
so
on
I
mean.
Ideally
we
make.
We
have
defaults
which
are
both
safe
but
also
make
sense
if
you're
doing
performance,
benchmarking,
I've
sort
of
been
a
number
of
conversations
with
folks,
who've
done
performance
benchmarking
and
take
a
well
on
voice
is
not
really
good.
It
doesn't
really
compare
to
this
other
proxy
and
I
want.
D
Did
you
try
changing
this
feature
of
that
feature
and
turning?
This
is
a
flag
on
and-
and
you
know,
that
the
set
of
best
practices
for
performance
benchmarking,
for
example,
and
as
a
consequence
using
it
in
a
high
performance
production
scenario-
are
not
obvious
and
I
think
we
definitely
should
try
to
average
over
it's.
Why
documenting
best
practices
or
just
flipping
these
on
his
defaults,
where
they're
safe
to
do
so.
C
Yeah,
echoing
that
I
also
wanted
to
point
out
that
if
the
goal
and
I
think
it's
a
really
goal
that
I'm
really
aligned
with
is
getting
a
handle
and
understanding
performance
and
scalability
etc.
The
essential
piece
that's
missing.
There
is
not
necessarily
more
prepackaged
things,
although
that
probably
helps
it's
a
good
set
of
metrics
that
are
really
easy
to
reproduce
that
tell
you
what
performance
you're
getting
with
a
certain
configuration
and
that's
something
that
we're
working
for
and
hope
to
deliver
something
this
year.
F
And
I
think,
echoing
that
in
in
general,
were
you
know
the
the
maintainer
is
can
help
and
the
community
can
help
is
actually
enabling
you
to
do
what
what
you
need
to
do
for
you?
You
know
particular
flavor
of
Android
so
similar
to
an
earlier
talk
today.
We're
talking
about
you
know:
how
can
we,
as
infrastructure
engineers
build
products
that
are
easily
operated
on
by
product
engineers?
F
How
can
we,
as
the
I'm
women
tenors
in
the
MMO
community,
do
that
for
the
data
plan
itself,
so
you
know
an
example
of
that
is
the
extensions
you
know,
divisions
between
core
and
extensions.
Were
we
have
open
up
the
possibility
for
you
to
compile
in
whatever
you
you
need
for
your
flavor
of
envoy,
yeah
I.
G
Think
one
of
the
original
parts
that
question
was
really
about
the
the
what
binary
images
and
things
like
that
we
might
have
and
I
think
if
I
just
look
left
and
right
amongst
the
people
that
I
see
up
here
in
the
maintainer
z--.
Most
of
us
are
not
people
who
are
using
prefilled
binary
images,
we're
actually
just
building
things
from
source,
with
exactly
the
individual
extensions
that
we
need
so
many
ways.
The
extensions
is
already
the
mechanism
to
get
that
level
of
flexibility.
G
To
give
you
the
meat,
the
lean
binary
that
you
want-
and
you
know
I
think
we
should
have
a
community
conversation
about
what
you
know
what
people
want
from
people,
pre-built
binaries,
because
I
think
a
lot
of
the
people
from
you
know,
lifts
in
Google
and
probably
Apple
and
so
on
are
not
operating
with
pre-built
binaries
we're
building
things.
You
know
when
we
deploy
them
so
so
yeah.
So
that's
that's
a
differ
and
I
think
we
should
understand
what
what
the
community
really
wants
from
pre-built
binaries.
C
A
But
but
but
yeah
I
think
on
this
topic,
particularly
around
I.
Think
someone
asked
me
before
around,
like
docker
images
around
will
we
do
point
releases,
like
you
know,
deal
with
cherry-picking
and
stuff
like
that?
It's
not
that
any
of
us
are
opposed
to
any
of
these
things.
It's
just
that,
like
was
just
said.
None
of
the
companies
that
are
maintained
errs
honestly.
They
don't
use
any
of
those
things.
So
that's
why
it
hasn't
been
a
a
development
priority,
so
I
don't
think
anyone's
opposed
to
any
of
that
stuff.
We
just
need
help.
A
A
G
J
Depending
on,
if
you
seem
like
Matt's
earlier
talk,
that
was
also
kind
of
the
point
of
it,
too,
is
to
be
able
to
handle
those
functionalities
equally
right,
because
then
you
don't
have
to
maintain
two
different
proxies
and
that's
where
then,
you
have
to
set
of
ten
marking
teens
and
you
have
to
set
of
application
libraries
and
so
may
can't
uniform
across
your
entire
stack.
It's
a
plane
and
the
client
makes
everyone's
life
happier
and
I
can't
see
where
who's
doing
a
happy
developers.
But
then
you
actually
have
a
lot
happier
developers
cuz.