►
From YouTube: Envoy Community Meeting - 2018-05-22
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, 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.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
All
right
well,
I
guess
we
can
get
going
so
quick
announcement,
the
CFP
for
both
of
the
coop
cons
for
winter
opened.
So
that's
the
one
in
Seattle
in
December
and
then
there's
one
in
China
in
November,
so
would
be
really
great
to
get
to
get
more
people
speaking.
So
if
you're
out
there
interested
in
in
talking
about
stuff
would
be
great
to
do
it
do
a
proposal.
A
All
right
so
I
guess
I
just
wanted
to
talk
through
the
extension
policy,
so
there's
a
link
in
the
meeting
notes.
Doc.
Oh
sorry,
phone
is
ringing
here
for
some
reason,
so
so
the
idea
behind
the
extension
policy
for
people
that
haven't
actually
read
it
is
that
we
have
kind
of
an
increasing
number
of
organizations
that
would
like
to
add
extensions
to
the
repo
and
it's
eclipsing
I
would
say
our
ability
to
do
quality
code
reviews
and
figure
out
how
to
manage
this
entire
situation.
So
I
put
together
kind
of
a
strong
proposal.
A
There's
no
there's
no
perfect
solution
here,
I'll,
just
briefly
summarize
it.
So
the
idea
behind
the
proposal
is
that
for
the
extensions
that
are
in
the
repo,
we
would
like
to
maintain
the
same
quality
bar
effectively
that
we're
using
for
all
of
the
core
code.
So
that
means
style,
testing
code
reviews.
All
of
that,
so
you
know
the
idea
being
that
the
extensions
in
the
repo,
to
the
extent
that
we
can
guarantee
it
our
production
quality,
release
candidate
quality.
A
You
know
we
would
kind
of
relax
that
component
of
it
and
the
idea
is
then
that
we
can
largely
just
push
through
or
fuse
two
extensions
directly
to
people
that
quote
own
that
extension
and
then
an
existing
maintainer
can
just
rubber-stamp.
You
know
those
reviews
and
basically
merge
them
or
it's
acceptable
if
the
maintainer
is
one
of
those
reviewers
and
is
actually
doing
work.
A
That's
that's
fine
also
so,
but
the
kind
of
the
fundamental
goal
here
is
to
incentivize
people
who
would
like
to
get
extensions
in
the
repo
and
there's
a
growing
number
of
companies
that
would
like
to
do
that
to
actually
be
maintained
errs
if
they
would
like
to
get
extensions
in
the
repo.
So
it's
kind
of
a
pay-to-play,
if
you
will
ELISA
had
the
legitimate
concern
that
that
bar
might
be
too
high
and
like
I,
don't
I,
don't
really
have
a
good
answer
here.
A
So
in
terms
of
you
know
whether
we
should
say:
okay,
like
we'll,
do
the
reviews
and
Shepherd
it
through.
If
you
agree
to
do
these
five
issues
for
us
or
something
like
that,
and
that's
a
totally
reasonable
proposal,
I
I
have
a
feeling
that
we're
just
gonna
have
to
see
how
it
how
it
goes,
but
anyway,
I
just
wanted
to
kind
of
open
it
up
for
discussion
and
just
see
if
anyone
had
any
thoughts
or
concerns
or
wants
to
do
something
different.
A
B
I
just
unmuted
myself,
and
this
is
Stefan
Zurcher
I-
was
wondering
if
you
had
any
thoughts
on
what
might
happen
in
the
future.
If
you
get
a
couple
maintained
errs
for
an
extension
and
then
they,
you
know,
move
on
in
their
careers
and
aren't
you
interested
or
don't
have
the
time
to
continue
to
do
that,
work
for
an
extension,
yeah.
A
So
I
I
put
I
put
a
small
section
in
the
in
the
dock.
Here
about
that
and
like
again,
there's
no
there's
no
perfect
answer
here.
My
assumption
is
that,
once
an
extension
is
in
the
repo,
it's
everyone's
responsibility
to
do
basic
maintenance
so
basically
like,
if
there's
an
API
refactor
like
it's
people's
responsibility,
to
go
through
and
fix
the
extensions
as
part
of
that
refactor,
that's
kind
of
the
benefit
of
the
quote:
mono
repo
approach,
in
this
case
the
the
kind
of
the
way
that
I
wrote.
A
The
proposal,
though,
is
that
obviously
it's
acceptable
that
maintain
errs
of
extensions
move
on.
If
there's
major
known
issues
in
an
extension,
and
we
can't
find
replacement,
maintain
errs
like
if
there's
no
one
that
wants
to
step
up
to
basically
maintain
it,
we
would
have
a
vote
of
the
maintainer
x'
and
then
we
would
basically
delete
it.
C
A
Far
as
I
can
tell,
the
Linux
kernel
is
like
total
chaos.
I
mean
it's
like
they're
there.
There
are
drivers
that,
like
have
literally
one
person
that
ever
wrote
the
code
and
no
one
ever
reviewed
it,
so
the
the
bar
as
far
as
I
can
tell-
and
my
information
might
be
out
of
date
here.
So
if
there's
people
on
the
call
that
kind
of
understand
the
process
better
than
I,
please
speak
up,
but
my
impression
is
that
the
Linux
kernel
has
a
lower
bar
and
I.
A
Think
part
of
that
is
that
they
don't
do
the
same
type
of
CI
that
we
actually
do
like
they.
Don't
they
don't
build
the
whole
code
and
actually
test
it
like
they
build.
You
know
the
one
configuration
that
works
or
couple
configurations
in
DCI
and
like
a
lot
of
the
code,
there's
code
I
believe
in
the
Linux
kernel
tree
that
doesn't
even
build
so
like
it's
just
that's
just
kind
of
there's
a
bit
rot
there.
One.
D
It's
all
extensions
that
I
said
very
other
calls
and,
and
the
sort
of
rule
of
thumb
was
if
a
major
API
change
was
being
made,
which
at
one
point
happened
frequently,
whoever
was
making
that
change
was
responsible
for
getting
it
into
all
the
places
in
the
code
base.
But
then,
beyond
that,
you
know
if
something
was
truly
legitimately
broken
and
nobody
was
interested
in
fixing
it
exactly
what
you
just
described.
It
went
away
yeah.
B
A
C
Which
I
think
are
solvable
and
the
quality
issues
and
that's
kind
of
like
you
know
where
why
we
actually
care
about
the
code
review
bandwidth
here,
write
to
me
because
just
doesn't
build
C
I
could
do
the
job
of
dealing
with
scalability
as
we
get
more
maintainer.
As
we
get
more
extensions,
we
want
to
need
a
scout.
The
maintainer
but
I
feel
like
we.
We
actually
wanna
maintain
the
same
quality
bar
as
the
core
code.
Yeah.
A
A
Some
of
them
have
a
lot
more
production
use
than
others,
so
I,
I
guess
the
other
thing
that
came
to
mind-
and
this
is
something
that
we
don't
have
to
do
initially-
is
that
although
I
still
want
to
do
a
CI
of
all
code,
now
that
we
have
a
very
nice
extensible
build
system,
one
thing
that
did
occur
to
me
is
that
we
could.
We
could
publish
two
separate
docker
images.
One
of
them
is
a
lise
build
which
is
basically
envoy.
A
Everything
right
like
you,
get
all
extensions
that
are
in
the
repo
and
then
one
of
them
is
like
envoy
bless
like
call
it.
What
you
will,
but
like
it's,
the
subset
of
extensions
that
we
as
maintainer
x',
feel
have
very
good
production
coverage
so
like
if,
if
users
are
looking
for,
like
the
quote,
bless
set
of
extensions,
you
know
that
would
be
a
place
to
start
and
then,
if
people
want
to
use
the
giant
bucket,
they
can
use
the
the
other
docker
image
effectively.
Doesn't.
C
Need
with
docker
images,
I
mean
this:
is
this
gets
back
in
now
dangerous?
You
put
off
the
topic
which
the
original
idea
that
we
would
have
the
effectively
the
equivalent
of
config
files
builds,
and
we
would
have
full
minimal
and
yeah.
C
A
Of
course
yeah
and
like
we
can
easily
do
that,
I
was
just
making
the
point
that
most
people
don't
know
how
to
build
on
by
and
they
don't
want
to
do
it
right.
So
it's
like
just
if
if
we're
gonna
do
a
minimal
and
a
and
they
fall
like
I,
see
no
reason
not
to
just
like
do
a
CI
run
for
both
of
those
and
publish
to
docker
images
like
it's
just
it's
just
kind
of
a
nice
convenience
for
people,
I
think.
E
Yeah,
so
my
main
thought
and
I
think
this
is
already
covered
is
that
if
some
extension
code
has
less
scrutiny
than
others,
if
that
is
resident,
you
know
if
that
isn't
built,
then
it
can't
really
do
any
harm.
So
the
docker
images
and
the
kind
of
prescribed
way
of
building
the
minimal
subset
doesn't
even
pull
in
that
stuff
yeah.
Then
it
does
make
sense
to
have
like
a
lower
bar
and
make
it
easier
for
people
to
get
their
stuff.
In
anything.
We.
C
A
So
so
my
my
idea
there,
which
is
not
part
of
this
proposal,
is
basically
we
would
have
an
extension
sandbox
repo.
It
would
look
just
like
envoy
filter
example.
We
would
do
exactly
what
we
do
today.
We
would
do
CI
on
it.
We
would
every
on
my
master
commits
we
would
you
know
we
would
basically
push
the
current
sub
module
up
to
date
and,
like
the
current
maintainer,
x'
won't
track
CI
status
on
that
repo
like
if
it's
broken
its
broken,
like
the
the
larger
community,
will
have
to
come
through
and
basically
fix
it.
A
F
A
Yeah
right
or
you
know,
I
mean
like
there's
even
intermediate
solutions.
There's
like
we
have
a
documentation
section
where
people
link
to
their
like
repos,
which
have
their
extensions
in
it,
or
something
like
that.
Right
I
mean
it's
like.
There's
lots
of
low
friction
ways.
I
just
feel
like
we
can
be
nimble
here
and
kind
of
like
what
we're
doing
today
is
not
working
so
like.
Let's
try
something
different
and
then,
if
that
doesn't
work
we
can.
We
can
try
something
else.
I
guess
can.
A
H
D
A
C
A
Ok,
so
that's
something
that
I
think
the
three
of
us
can
take
offline
and
then,
hopefully
we
can
report
report
back
on
that
ok
cool
on.
So
if
there's
no
major
objections,
what
I'm
gonna
do
is
I'm
gonna
kind
of
clean
this
up
just
a
little
more
and
then
I'm
gonna
do
a
PR
to
the
repo
in,
like
the
government
section,
we're
all
linked
to
this
doc
and
then
we'll
kind
of
make
it
the
quote
official
policy
and
we
can
just
see,
see
how
it
goes.
H
Unfortunately,
I
was
sidetracked
quite
a
bit
last
week,
doing
some
PPP
release
management
stuff,
so
I
have
made
some
progress
and
so
I
hope
to
have
a
patch.
This
we
appear
this
week
that
I
can
can
publish
that
will
let
us
identify
the
areas
that
I'm
run
into
issues,
but
for
now
it's
it's
I'm
still
making
forward
progress.
So,
okay.
A
Well,
idiots,
you
know,
one
thing
to
point
out
is
Brian
Payne
from
Pinterest
just
did
a
PR
to
start
the
work
of
getting
rid
of
ft
from
the
buffer
interface.
Okay,
that
is
part
of
what
you'll
need
to
do,
which
was
very
convenient
that
he
started
to
do
that
now
might
want
to
reach
out
to
him
over
email
or
slack.
I
can
make
that
connection
just
because
he
had
investigated
a
little
more
as
to
like
what
what
was
required
to
actually
make
that
happen.
Yeah,
but
that's
work
that
needs
to
get
done.
H
That
would
be
great
because
yeah
there's
some
areas
that
I
keep
getting
stuck
mentally,
so,
okay,
yeah,
cool
and
and
I've
been
focused,
not
on
you
know,
just
on
the
generic,
let's
get
rid
of
empty
stuff.
I
haven't
been
actually
working
on.
You
know,
extension
stuff
that
might
be
specific
to
VPP,
so
great
cool.
G
A
A
PR
that
you
can
look
at
and
merge
like
in
the
last
day
it
just
it
doesn't
change
the
interface
yet,
but
we
no
longer
call
into
live
event
to
actually
do
the
read.
So
the
read
has
been
lifted
out
and
then
there's
just
some
more
refactoring.
That
needs
to
get
done
to
basically
get
rid
of
the
read
and
the
right
methods
from
from
buffer.
A
D
A
So
if
people
aren't
gonna
flip
out
about
it,
I
I
can
investigate
hey
Chris.
What's
your
impression
bin
of
the
github
project
boards
like
is
that
it's
improved
it
Perl,
probably
work
for
you
I
think
it's
depending
what
you
want
to
do
so,
okay,
all
right!
Let
let
me
go
poke
around
a
little
bit
and
and
see
because
I
kind
of
agree
that
if
we
could
have
it's
like
labels
only
goes
so
far
before
it's
kind
of
a
pain.