►
From YouTube: Envoy Community Meeting 10.24.17
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.
B
C
So,
what's
what's
a
good
way
of
doing
this,
we
just
do
since
we
only
have
a
half
hour.
Do
we
just
do
kind
of
quick
intros
and
then
I
Harvey
yeah
I
had
a
small
thing
that
he
was
gonna,
go
through
yeah
and
then
just
open
it
to
questions
when
when
you
do
QA,
do
you
do
you?
Just
have
people
just
start
talking
or
type.
B
Type,
whatever
they
want
to
talk
about
in
the
actual
agenda,
oh
okay,
cool!
That's
the
best
way
to
do
it,
so
it's
actually
someone
record
at
all.
I'll
essentially
take
notes
this
time
around,
but
in
the
future
it's
good,
if
kind
of,
like
everyone
tries
to
work
together
to
collectively
take
notes.
Sure
okay
got.
B
B
D
B
B
B
C
B
They
hardly
get
it
there's
several
number
yeah
one
of
those
should
work
so
there's
totally
non
toll-free
options.
One
of
those
should
be.
F
E
B
D
B
C
C
So
my
thinking
of
kind
of
this
call
is
we'll
have
Harvey,
do
a
v2
config
status,
update
for
about
five
minutes
and
then,
since
we
only
have
a
half
hour
about
15
minutes,
left
I
was
thinking
that
we
could
do
a
general
Q&A
and
people
can
ask
us
whatever
you
want,
and
then
we
can
have
a
discussion
of
what
would
be
useful
for
for
future
calls.
So
if
people
want
to
see
demos
or
want
to
see
deep
dives
on
particular
subjects,
we
can
get
those
scheduled
but
I
figured.
F
Everyone
knows:
thank
you.
Okay,
I'll
mute
it
now
I'm
as
I
hope
everyone.
The
calls
are
aware:
we've
been
working
on
the
v2
API
for
Envoy
for
quite
some
time
now
and
just
to
provide
some
context
there
in
the
motivation.
You
know
this
was
actually
began
all
the
way
back,
I
think
in
February,
where
we
started.
We
realized
that
we
there
are.
You
know
always
like
super
amazing
that
they
can,
you
know,
discover
lots
of
state
at
runtime,
but
there
are
a
few
things
that
we
needed
to
do
to
get
it.
F
It's
all
been
shaped,
some
of
our
internal
Google
needs,
and
also
just
in
general,
for
the
Envoy
community,
and
these
included
some
taking
me
to
a
PID
service
discovery
api's,
which
has
been
evolving
over
the
previous
year
and
adding
in
support
for
G
RPC
in
addition
to
rest
polling
and
also
being
able
to
ensure
that
all
the
things
that
you
probably
want
social,
definitely
discoverable.
So
at
the
time
I
think
note
list
those
know
how
they
ass
and
so
on.
So
we
really
want
to
essentially
G
RPC
and
Jason
base.
F
V2
API
is
the
data
file
API
repository
these
cover
the
core
services
that
most
folks
are
aware
of.
Today,
things
like
SDA
des
TDS
LDS.
They
also
have
some
advanced
functionality,
things
like
load
reporting
and
distributed
health
checking
and
sort
of
they
basically
take
on
voids,
the
point
of
which
almost
every
state
that
you
would
want
to
discover
at
one
time
is
now
discoverable
and
we've
been
implementing
these
and
most
of
the
implementation
will
be
complete
they're.
Actually,
the
current
status
is
that
the
core
API
is
of
frozen.
F
That
is
like
the
cow
est
est
est
REM
and
they
have
ours,
has
to
at
least
be
one
parity
so
through
the
new
features
that
were
scopes
into
them
haven't
been
implemented
yet,
but
you
should
be
able
to
at
least
you
know
to
express
in
these
api's
and
have
them
be
ingested
into
homeboy
at
v1
apparentiy,
and
we
actually
have
approved
by
construction
for
this
tomboy
itself.
Internally
takes
the
v1
API
that
it
reads
out:
Jason,
transform
them
into
B
two
protos
and
then
actually
confuse
them
internally.
F
So
we're
pretty
confident
that
at
least
as
far
as
b1
parentage,
the
correct
II
eyes
features
in
a
good
place
to
get
working
this
quite
a
bit
of
sort
of
openwork
still
that
remains
that
implied
with
some
great
work
that
Sri
Rams
will
do
right
now
to
ensure
that
filter
config,
the
on
things
like
HTTP
connection,
managing
the
TCP
proxy
filter
are
fertilized
and
Rizzo
and
temporary
solution.
Ravenous.
F
Applying
adjacent
fragments
to
these
pro
knows
the
view
on
Jason
fragments,
opaque
on
favorites,
and
they
just
work
but
hoping
to
get
to
reach
a
point
where
we'll
have
full
presentation
on
the
filters
within
probably
within
this
week.
They
think
that
the
PRG
is
looking
pretty
good
shape
for
our
measure
and
that
there's
also
some
additional
we're
going
on
by
myself
on
adding
documentation.
So
we
have
really
fantastic
Doc's
that
put
together
a
lot
of
their
years
from
other
contributors
from
v1.
F
In
addition
to
that,
we
have
one
last
rough
edge
which
might
be
interested
in,
and
that
is
we
don't
actually
do
full
constraint,
validation
on
their
ingestion
of
the
API,
so
the
v1
API
do
have
Jason's
email,
which
checks
things
like
you
know.
This
tree
must
be
at
least
two
characters,
one
more.
It
must
be
greater
than
zero.
Internally
employer
lies
on
this.
F
We
do
have
a
plan
and
we
have
some
list
based
open
source
truly
now
to
add
in
these
constraints
for
the
v2
API,
but
we're
prioritizing
and
documentation
work
there
when
their
means
for
early
adopters
of
eto
API
is
managed
as
a
company
and
although
we'll
just
crash
in
expected
way
more
than
a
nice
graceful,
hey
here's
an
exception.
Our
rejections
come
the
way,
but
in
a
sec,
faulty
kinda
way.
F
So
that's
the
only
sort
of
camions
for
early
adopters,
otherwise
we're
super
would
definitely
sit
in
there
working
with
folks
who
who'd
like
to
get
balls
and
be
too
impatient
in
place.
So
that's
the
end
of
it
for
me,
if
you
have
any
questions,
I'm
happy
to
answer
them,
yeah.
C
One
one
thing
I
would
point
out
real
real
quick
about
v2
is
we're
still
thinking
about
kind
of
what
the
v1
to
v2
deprecation
plan
is.
Our
current
thinking
is
we're
doing
roughly
quarterly
releases,
so
1.5.0
will
be.
You
know
in
approximately
six
weeks
towards
the
towards
the
end
of
November,
and
our
thinking
is
basically
that
in
the
1.5.0
Rubies
v2
will
be
fully
ready,
they'll
be
docks,
they'll,
be
constraints,
etc.
C
V1
config
is
not
going
to
be
treated
like
our
application
policy,
like
we're,
not
gonna
delete
the
one
config
in
one
point:
six
point:
oh
that's
not
it's
not
reasonable!
There's
lots
of
people
that
are
actually
using
it,
but
our
general
thinking
which
are
open
to
conversations
on
is
that
once
one
point
5.0
actually
ships,
we
will
no
longer
allow
new
features
to
be
added
to
v1.
C
So,
as
new
features
get
added,
basically
people
will
have
to
upgrade
to
v2
to
actually
use
them
and
what
we've
seen
so
far
is
it's
a
little
tedious,
yes,
but
most
of
the
v2
configs,
whether
they
be
gamal
or
JSON.
You
know
it's
a
it's
a
small
iteration
on
the
existing
configs.
It's
not
like
it's
a
total
rewrite
so
most
of
the
concepts
map
very
simply
from
v2
back
to
v1.
But
that's
something
to
keep
in
mind
is
that
you
know
we're.
C
F
C
Yeah,
our
our
goal
is
to
auto-generate
the
v2
Doc's
into
the
existing.
He
wants
things
tree
and
that
will
allow
us
to
cross
link
between
the
existing
view
on
Doc's
and
the
arch
Doc's,
because
obviously
there's
a
ton,
that's
written
in
the
current
v1
Docs
and
instead
of
having
to
rewrite
all
of
it,
you
know
for
90%
of
it.
The
same
concept
still
apply.
So
this
will
allow
us
just
to
cross
link
back
and
forth
and
hopefully
have
a
pretty
good
dog
experience.
C
The
other
thing
that
we're
gonna
do,
which
we
need
to
figure
out
how
to
resource
it'll,
probably
be
partly
Harvey,
Google,
folks
and
partly
lyft
folks
is
we
will
take
the
existing
example
configs
that
are
in
the
repo,
so
there's
kind
of
the
lift
reference
configs,
there's
the
front
the
front
envoy,
the
service
to
service
the
double
proxy
and
then
there's
a
couple
sample.
Docker
containers
will
be
porting
those
to
v2.
So
the
goal
basically,
is
that
in
the
repo
we're
gonna
have
a
bunch
of
examples
that
are
all
v2
configs.
C
F
They
were
interested
in
certain
projects
actually
opening
up
to
have
the
issue
and
taking
ownership
of
that
would
be
great,
but
I
think
it's
actually
a
lot
of
the
work,
really
what
you
review,
the
existing
libraries
and
the
command-line
interface,
and
this
would
provide
the
efficient,
automated
transformation
of
your
convicts
now.
That's
that
would
get
you
at
least
be
to
you
know
the
minimum.
You
need
to
get
one
company
just
to
be
to
in
reality.
What
you
would
go
to
me
to
is.
F
You
want
to
actually
take
advantage
of
either
new
features
or
things
like
ability
to
do
streaming.
Grp
see
this
is
actually
a
much
prettier
way
strip
change,
because
in
each
like
rewrite
your
xdf
server
to
operate
as
a
GF,
PC
endpoints
and
do
a
sub
generation
or
all
that
kind
of
stuff
nuts
yeah
about
that.
That's
a
bit
different.
But
if
you
all,
you
really
want
to
do
is
just
move
it
a
bit
meet
you
Jason
or
proto's
from
the
file
system,
or
you
know
that
kind
of
thing
I
think
that's
pretty
it.
C
There's
actually
there's
a
there's,
a
debug
message
that
actually
prints
went
when
envoy
boots.
If
you
load
a
if
you
load
a
v1
config,
it
actually
spits
out
the
config
in
v2
form,
and
you
know
so
it's
it's
already
being
done
and
actually
did
occur
to
me
this
morning,
because
we
actually
have
to
go
through
and
convert
all
of
our
configs
that
lift
over
to
v2.
So
I
have
a
person
on
my
team
who
I
like
to
say,
drew
the
short
stick.
Who
has
to
go
and
actually
do
that,
but
but
yeah?
C
So
so
we
will
have
to
get
those
converted,
but
it
did.
It
did
actually
occur
to
me
that
we're
doing
that
conversion
internally
and
can
probably
use
that
on
this
does
bring
us
to
our
second
topic
we'll
get
to
in
a
sec,
which
is
the
new
go
control
plane
work.
So
we
can
talk
about
that
soon,
but
yeah
we
can
you
can
let
people
ask
more
more
questions
about
v2,
config.
J
I
I
might
have
missed
it,
but
what's
the
is
there
any
additional
work
or
focus
on
the
like
the
auto,
the
auto
configuration
service
discovery?
You
know
those
sort
of
components
in
v2
or
is
it
just
pretty
much
you're
like
a
mechanical
change,
I.
F
Mean
there's
definitely
some
things
in
there
which
could
be
used
discovery,
like
particular
I,
think
this
we
met
as
an
issue
who
should
have
come
by
earlier
Ryan
about
using
the
health
text
service
reports
to
actually
allow
those
to
register
themselves
and
their
back-end
services.
These
are
all
kind
of
easy.
These
are
not
implemented
yet
but
they're
in
the
API,
and
there
is
some
intention
of
adding
them
as
needed,
step
up
to
take
ownership
you
they
are
common.
I.
J
Noticed
that
that's
like
that's
sort
of
like
the
direction,
I
kind
of
see
it
going
in
and
if
that
that's
something
that
was
kind
of
present,
you
guys
minds
when
you
were
working
on
v2.
You
know
like
sort
of
like
this.
You
know
at
CD,
back-ended
sort
of
you
know
what
I
mean
like
what
a
lot
of
other
things
are
going
in
right
now,
but
that's
kind
of
where
my
my
question
came
from
sorry.
J
Oh,
no
so,
specifically
around
the
the
v2
work,
it
was
kind
of
muffled
in
the
beginning
and
I
heard
some
stuff
about
service
discovery
and
I
was
just
good.
I
was
interested
in
a
service
discovery
aspect,
so
that
particularly,
you
know,
you
know
like
yeah,
like
it
there's
rumblings
about
like
a
see
the
backend
and
things
like
that.
You
know
what
I
mean
we're
nice.
F
C
Did
someone
yeah
so
so
v2
was
designed
as
a
superset
of
e1,
so
all
of
the
concepts
that
you
were
already
using
in
v1,
they
mapped
basically
1
2
1,
2
v2.
There's
features
in
v2
that
were
not
present
in
v1.
So
there's
a
bunch
of
streaming
concept,
there's
load,
load,
reporting
concepts,
there's
aggregation
concepts,
so
you
know
there's
there's
things
that
won't
be
present
back
in
v1
that
are
present
in
v2
in
terms
of
actual
backends
I.
C
Think
right
now,
from
a
project
perspective,
we're
not
really
focusing
on
adding
specific
back-end
support
for
things
like
whether
that
be
at
CD
or
like
marathon
or
console,
or
you
know
whatever,
and
the
thinking
there
is
that
you
know.
There's
this
separation
between
control
plane
and
between
data
plane,
and
the
idea
is
to
try
to
draw
that
separation
via
this.
This
API
and
we're
gonna
rely
on
systems
like
sto
and
pilot
to
provide
backends
for
different
services
and
for
other
people
to
come.
You
know
to
kind
of
come
and
provide
their
their
different
backends.
J
C
So
on
on
this
topic,
just
a
general
announcement
which
people
may
have
seen
so
we
are
starting
a
new
project
and
the
envoy
proxy
or
or
calling
it
go
control
plane
and
what
we
seen
basically
is
that
there's
quite
a
few
people
building
control
planes
and
go
for
envoy.
We
have
the
ISTE
of
people,
building
pilot,
there's
various
people
that
are
investigating
kubernetes
ingress
controllers.
C
C
C
G
C
That
that
that
sounds
great,
so
what
I
was
thinking
for
coop
con
is
there's
gonna,
be
a
lot
of
us
at
coop
con.
We
have
like
an
hour
and
a
half
or
whatever
booked
for
an
envoy
salon.
I
was
thinking
we
would
do
kind
of
like
an
in-person
call.
Basically
and
I
was
also
thinking
that
we
could
do
some
some
lightning
talks
so
for
people
that
are
doing
cool
stuff.
C
You
know
we
could
just
share,
share
the
projector
and
do
like
five
or
ten-minute
lightning
talks,
but
as
we
get
closer
to
cou
con,
we
can
put
it
in
the
doc
in
terms
of
what
talks
people
might
want
to
give
and
I've
talked
to
people,
and
it's
already
put
in
the
doc
here.
But
it
seems
like
there's
general
interest
in
doing
kind
of
a
dinner
or
a
happy
hour,
so
we
will
try
to
get
that
scheduled
for
a
coupon.
Also.
C
B
I
mean
demos
sometimes
well,
if
you
reserved
like
a
one
demo
per
call.
That's
always
sometimes
works
pretty
well
works
well
for
the
kubernetes
community
meeting
at
least.
C
Okay,
yeah
always
yeah
and
then
trim
just
just
said
that
you
know
it'd
be
cool
if
for
people
that
are
using
envoy
at
particular
places,
if
you
even
wanted
to
spend
the
ten
minutes
talking
about
how
you're
using
it,
you
know
that
that
would
also
be
I
think
super
useful.
So
we
can
do
a
little
call
call
lightning
talks.
Also
I.
C
Yeah,
what
we've
been
doing
so
far
for
better
or
worse
probably
worse
is
we
are
using
issue
tracking
and
generally,
what
I've
been
doing
is
we
have
a
milestone
for
the
next
movie
so
right
now,
if
you
look
and
github
there's
a
one
point:
5.0
release
and
generally
everything
in
that
bucket
is
going
to
get
implemented.
You
know
in
probably
the
next
two
or
three
months,
sometimes
things
get
punted
out
and
sometimes
things
get
get
brought
in,
but
that's
kind
of
the
best
roughly
amount
that
that
we
have
so
far.
C
If
there's
general
interest
in
kind
of
like
a
longer
term
roadmap,
you
know
it's
it's
it's
a
bit
hard,
obviously,
because
you
know
we're
we're
all
volunteers,
doing
random
things
for
different
companies,
but
I
think
at
least
from
Google
side
in
terms
of
what's
public
and
from
lift
in
terms
of
what
we
are
definitely
going
to
be
working
on.
I
think
we
can
put
together
kind
of
a
short
term
in
a
in
a
medium
term,
payback
for
sure,
okay,.