►
From YouTube: Envoy Community Meeting - 2018-03-13
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.
C
Oh,
can
you
hear
me?
Okay,
yes
excellent,
so
many
of
you
will
have
seen
the
pull
request
that
I
submitted
I
want
to
say
a
couple
of
weeks
ago
about
folding
ambassadors
authentication
mechanism
into
envoy.
There
was
a
lot
that
tiara
since
means
closed
after
a
lot
of
discussion,
a
lot
of
back-and-forth,
the
long
and
short
of
it
could
be
summarized
as
there
was
a
lot
of
interest
in
having
a
more
flexible
off
mechanism
as
part
of
envoy
score.
C
There
was
a
lot
of
discussion
about
how
best
we
could
do
that
in
light
of
both
the
ambassador
PR
and
the
earlier
Tiger
work
and
the
end
route
forward.
There
is
going
to
be
that
will
be
talking
later
today
between
myself
and
Integra
folks
about
how
to
get
the
work
done
of
folding
ambassador's
functionality
and
use
cases
into
the
existing
filter
from
the
tiger
folks,
which
I
am
very
happy
with,
and
thanks
to
all
involved.
C
D
E
B
E
And
so,
as
most
folks
know,
we
have
the
v2.
Api
is
now
that
bean
production
ready
since
over
1.5,
which
was
last
December.
The
plan
is
to
turn
down
the
v1
api's.
We
do
understand
that
there
is
quite
a
lot
of
dependence
that
folks
have
on
the
v1.
Api
is
that
there
are
various
and
management
stacks
integrations
that
are
based
around
the
one.
What
API
so
we're
not
deprecated
need
as
aggressively
as
we
are
other
features
in
envoy.
E
The
plan
of
record
I
believe,
and
please
correct
me
if
I'm
wrong
folks,
is
to
not
deprecated
them
in
the
1.6
release
cycle,
so
it'll
be
1.7
in
which
we
announce
that
they're
in
deprecated
in
three
months
time,
and
the
way
we
have
things
working
without
breaking
change
policy
is
that
we
then
have
another
three
months,
essentially
of
them
being
enabled
at
the
beginning
of
the
1.8
release
cycle.
We
will
actually
remove
that
functionality,
so
that
essentially
gives
us
nine
months
but
yeah.
B
Story
I
think
months,
yeah
it'll
be
it'll,
be
nine
months
until
there
is
a
release
in
which
the
v1
code
is
completely
removed,
but
it
will
be
removed
at
the
beginning
of
the
1.9
cycle,
which
was
approximately
six
months
one
one.
Other
piece
is
so
we
will
document
this
entire
policy
and
we'll
get
this
sent
out
and
they'll
be
on
the
website
and
we'll
send
it
to
envoy
announced.
The
other
thing
that
we're
likely
to
do
is
that
in
envoy
1.8.
So
that
means
the
beginning
of
the
1.7
release
cycle.
B
B
So
in
about
three
months,
we're
going
to
switch
that
flag
to
default
to
true
so
basically
by
default
envoy,
will
attempt
to
parse
v2
only
so
people
will
have
so
people
will
have
to
explicitly
put
in
false
for
that
and
we'll
probably
put
in
some
type
of
learning,
also
which
basically
says
that
in
three
months
time
you
know
this
code
is
basically
going
to
be
removed.
So
that
will
hopefully
help
people
understand
that
they
that
they
basically
need
to
upgrade.
E
Now
we
we
strongly
recommend
that
folks
don't
write
any
new
v1
integrations
and
start
moving
to
be
I
mean
there
are
other
advantages
than
just
having
a
not
you
know
your
API
disappear
from
underneath
you
specifically
like
most
new
features,
are
going
into
the
v2
API
is
already,
and
probably
after
the
next
release
cycle
will
start
pushing
back
pretty
hard
on
any
additions
to
v1.
So
it
really
is,
it
feature.
Freeze
state,
then
yeah.
B
So,
starting
basically,
next
week
we
will
be
pushing
back
very
hard
as
once
Envoy
one
point
seven
is
released
in
about
three
months.
We
will.
We
will
not
allow
any
any
further
v1
features,
so
it
will
be
completely
frozen.
So
again,
the
kind
of
TL
DR
of
this
is
that
you
know
if
you're
running,
if
you're
running
actual
version
releases,
you
have
nine
months
if
you're
running
master,
you
have
about
six
months
now.
A
B
Cool:
what's
next?
Oh
sorry,
I'm
looking
what's
next
on
the
agenda:
repo
B
org!
Oh
okay!
Let
me
cover
this
one
really
briefly.
So
there's
a
github
issue
that
I
opened
before
I
went
on
paternity
leave
and
the
kind
of
idea
behind
this
issue
is
that
you
know
at
this
point:
we
have
a
whole
bunch
of
different
extension
possibilities
and
Envoy.
We
have
different
kinds
of
filters.
B
We
have
network
HTTP,
we
have
listener
filters,
we
have
stat
sinks,
we
have
tracers,
we'll
probably
have
health
checkers
in
the
future
and
right
now
the
extensions
are
kind
of
sprinkled
all
over
the
repo,
and
that
has
a
couple
of
different
downsides.
The
first
downside
is
that
it's
hard
for
people
to
actually
look
at
the
extensions
understand
what
there
is
and
actually
learn
from
them.
The
second
problem
is
as
we're
growing
this
project.
B
You
know
you
have
an
increasing
number
of
pr's
there's
an
increasing
burden
on
maintainer,
x'
and
we'd
like
to
get
to
a
world
in
which
we
can
have.
You
know
specific
code
owner's
files
for
specific
extensions,
so
actually
start
extending.
You
know
that
the
fact
that
there
may
be
people
that
own
certain
proportions
of
the
code
that
are
not
core
actual
maintainer
x',
so
we
proposing
a
repo
reorg
and,
what's
in
that
PR
is
not
completely
up
up
to
date,
but
the
idea
is
to
kind
of
move
to
a
model.
B
That's
a
little
more
like
Linux
kernel,
in
the
sense
that
Linux
kernel
has
like
the
core
code
and
then
there's
a
set
of
drivers.
So
what
we'll
essentially
do
is
we'll
try
to
move
all
the
extensions
over
to
a
specific
directory
structure,
called
extensions
and
then
we'll
break
those
down
very
clearly
in
terms
of
what
extension
types
they
are
and
again
that
will
allow
us
to
more
easily
understand.
B
What's
there,
it'll
have
code
owners
and
also
it's
gonna,
allow
us,
in
the
future
to
actually
again
kind
of
like
Linux
kernel,
we'll
be
able
to
have
compile
Flags,
probably
for
basil,
to
compile
in
and
out
different
filters
so
that
people
that
want
to
either
from
a
security
footprint
perspective,
don't
want
to
install
certain
filters
or
low
low
like
low
memory
footprint
devices.
They
don't
want
to
install
lure
or
something
like
that.
We
can
basically
compile
that
out.
B
So
I'm
gonna
go
and
update
that
issue
from
a
final
proposal
based
on
in
person
discussions
with
with
Harvey
that
happened
about
a
month
ago,
so
watch
that
issue
if
you're
interested
and
then
assuming
that
there's
no
major
objections.
Once
we
release
one
point,
six
I'm
probably
going
to
start
doing
the
work
to
kind
of
slowly
move
different
filters
over
and
you
know,
there's
gonna
be
a
learning
process
during
this.
B
In
terms
of
you
know
what
code
is
still
kind
of
shared
and
like
do
we
need
other
extension
points,
for
example,
to
get
all
of
the
code
out
of
common.
So,
like
one
example
is
right
now
we
support
Redis
health
checking.
So
until
health
checking
itself
is
pluggable,
we
can't
take
the
Redis
code
entirely
out
of
core.
So
you
know,
there's
gonna
be
some
to
dues
that
actually
come
from
this
from
things
that
you
know
that
we'll
need
to
make
extensible
to
actually
get
that
code
out
but
yeah.
B
E
There's
one
related
thing
to
that,
then
that's
I
know
the
user.
Dod
IO
was
looking
at
extending
envoy
filter
example
with
some
different
types
of
filters
and
the
idea
there
was
how
that
reflect.
The
new
organization
I'm
actually
wondering
whether
we
actually
want
to
think
about
reorganizing
envoy
filter
example
and
actually
moving
in
maybe
into
the
main
repost
from
these
educational
pieces
and.
E
B
B
Yeah,
you
know
one
one
is
that
we
probably
won't
have
time
for
this
week,
but
we
should
put
on
the
agenda
for
two
weeks
from
now
and
I
will
open
an
issue
on
this
is
I.
Think
at
this
point
we
have
a
general
need
for
github
bots
that
do
like
17
different
things
and,
like
you
can
imagine
that,
like
we
should
be
having
a
bot
that
whenever,
on
my
master
changes,
it
automatically
commits
the
SHA
update
into
aqua
filter
example,
and
then
basically
tells
us
if
it
actually
breaks.
B
So
you
know,
there's
things
that
I
think
that
we
can
do
to
help
us
with
that
bit
rock
that's
true
yep,
but
yeah.
So
why
don't
we?
Why
don't
we
go
ahead
and
I
will
take
the
action
to
at
least
open
an
issue,
unlike
what
we
want
from
BOTS
and
bots
are
actually
a
great
thing
for
people
out
there
who
don't
necessarily
want
to
write
C++
but
like
want
to
help
that
that
we
could
get
them
to
help
with
with
with
BOTS.
E
Okay,
next
agenda
item
is
just
increment
XTS,
so
this
is
actually
just
public
service
announcement.
Also
a
request
for
sort
of
interest
from
folks,
so
Nicola,
who
is
a
Googler
and
myself,
are
working
on
a
proposal
for
incremental
XDS
right
now.
We
would
like
to
speak
to
anyone
who's
interested,
we'll
have
a
public
dock
most
likely
later
this
week
or
early
next
week,
and
but
we
were
definitely
open
to
the
conversation
early
rather
than
later.
Everyone
who's
interested
in
this
topic.
E
So
the
idea
is
already
Nicola
has
a
sort
of
work-in-progress
PR
for
lazy
loading,
where
you
can
fetch
additional
resources,
such
as
clusters,
dynamically
based
on
incoming
requests.
The
idea
here
would
be
to
see
if
we
can
actually
unify
that
with
the
core
sort
of
XTS
protocol
and
supports
incremental
updates
along
the
way,
which
were
something
which
were
also
on
the
road
map
for
XDS
later
down
the
track,
but
there's
an
interesting
confluence.
There
might
be
possible
here.
F
B
E
B
G
C
G
C
To
mind,
while
you
guys
were
talking
about
the
deprecation
of
the
v1
api's,
we
just
filed
an
issue
where
we're
seeing
connections
dropping
when
we
do
hot
restarting
and
on
the
one
hand
it
would
be
kind
of
interesting
if
anybody
has
a
cycle
or
two
to
take
a
look
at
that.
But
on
the
other
hand,
it
occurred
to
me
to
wonder
as
the
v12
zigged
Goods
way,
then
it's
hot
restart
also
going
away.
B
B
Guess
one
one
other
question
from
me
for
the
group
as
we're
starting
to
talk
about
releases:
do
people
think
that
we
need
to
start
doing
early
candidates
or
is?
Is
the
is
this
the
procedure
that
we're
doing
now?
Is
it
okay,
like
from
my
perspective,
I'd,
rather
not
do
these
unless
there's
a
very
good
reason
for
it?
You
know
we've
kind
of
taken
the
general
approach
that
were
always
at
for
these
candidate
quality
on
a
master,
so
is
that.
D
A
E
D
H
H
H
H
B
D
B
So
for
for
any
for
any
config,
you
know
that
people
would
like
to
be
dynamic,
I
I
think
that's
totally
reasonable.
It
just
has
to
get
resourced
and
someone
has
to
work
on
it.
So
I
mean
my
general
feeling
is
that
you
know
there's
certain
config
options
that
really
don't
realistically
change
like
once.
Bootstrap
is
actually
written
out
and
making
them
fully
dynamic.
It's
probably
going
to
be
a
substantial
amount
of
work,
it's
not
that
it
can't
be
done,
but
what
I
recommend
is
just
for
things
that
you
know
people
would
like
to
see
dynamic.