►
From YouTube: Envoy Community Meeting - 2019-08-27
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
A
Okay,
well
I'll
just
get
side
with
to
be
three
stuff,
so
there's
a
few
things
going
on
there.
First
of
all,
the
regular
UDP
a
stuff
needs
in
the
background
and
working
with
the
working
group
there
to
try
and
hash
out
different
aspects
previously
was
the
transport
protocol
right
now
we're
looking
at
things
like
the
data
model
and
I
mean
how
al
seven
routing
can
be
handled
in
this
context.
The
goal
here
is
actually
to
do
two
things
to
universalize
or
generalize
on
voice.
A
It's
always
possible
to
write
recover
an
optimizer
against
what
we
had
today
for
Envoy,
but
that's
not
the
direction
we
want
to
go.
We
want
to
actually
structure
improve
things.
The
next
generation
rousing
API,
and
so
that's
currently
what
we're
hashing
out
there.
In
the
guise
of
the
UDP,
a
efforts
other
stuff
happening.
There
is
we've
actually
split
out
the
UDP,
a
boaters,
including
Orca,
into
a
separate
repository
which
now
lives
under
CN,
CF,
/gd
PA
an
envoy
brings
that
into
its
build
as
an
external
dependency.
A
And
that's
then
it's
it's
the
direction
where
we
want
to
go
with
the
v3
XTS
API.
So
moving
away
from
this,
this
long-term
PDP
effort
I
want
at
the
end
of
this
quarter,
cuts
the
B
3
major
version
of
the
XDS
api's
and
given
we
don't
even
have
v3
alphas
today
there
there's
no
not
going
to
be
a
lot.
That's
very
revolutionary
here,
they'll
be
very
evolutionary
what
we've
essentially
taking
the
v3,
the
v2
XDS
ap,
is
and
removing
anything
that's
marked.
A
A
You'll
have
a
about
a
year
to
start
turning
down
your
use
of
v2
and
moving
over
or
your
service
to
b3
and
switching
over
to
basically
yeah
two
new
endpoints
new
code
path,
new
generated
code,
all
this
kind
of
stuff
and
I
think
the
way
to
see
this
really
is
is
a
canary
of
voice.
Api
version
policy,
as
well
as
way
of
for
us
to
actually
safely
turn
down
some
a
technical
debt
that
would
built
up
the
v4
API.
B
Well,
I
was
gonna,
say
and
I
think
the
goal,
though
I
just
want
to
make
sure
that
from
our
side,
we're
on
the
same
page
is
that
I
mean
we're
still
focusing
on
making
sure
that
the
developer
experience
is
decent
right.
So
you
know
I
mean
that
includes
like
not
sacrificing
documentation,
making
sure
that
we
have
those
I
think
I,
don't
want
to
speak
for
Harvey
explicitly,
but
I
think
our
plan.
There
is
to
have
translation
tools,
since
we
have
to
do
it
internally
to
envoy
anyway.
B
So
it's
like
we're
gonna
convert,
probably
the
old
v2
api's
to
the
new
v3
API,
so
we
can
very
likely
have
a
a
config
dump
tool
that
will
spit
out
what
the
new
config
would
actually
look
like
to
help
developers
transition,
but
I
think
just
as
we
go
through
this
process
for
those
that
are
a
little
more
bleeding
edge
out
there.
Feedback
on
the
developer.
Experience
is
useful
because
we
want
to
make
sure
that
that
you
know
we're
not
making
things
yeah.
A
I
mean
the
idea
really
is
by
shooting
for
very
low,
both
the
API
changes
for
v3
or
allow
us
to
focus
on
tooling
and
infrastructure
and
process,
and
all
this
other
good
goodness,
and
particularly
given
that
there's
very
little
change
between
the
two
API
is
really
it
would
allow
us
to
it
make
sense
to
not
have
to.
For
example,
we
implement
twice
everything,
that's
in
v2
for
e3,
and
what
do
you
think
very
carefully
about
how
we
do
this
translation
automate
as
much
as
possible,
because
there'll
be
a
huge
payoff
from
that
yeah.
B
And
then
there
are
a
few
other
things
that
I
would
like
to
fix
in
this
minor
Rev,
which
I
think
I've
mentioned
to
a
couple
people.
So
on
the
listener
and
the
cluster
side
right
now
we
have
a
bunch
of
embedded
fields
that
are
protocol
specific.
That
really
either
should
be
opaque
extensions
or
one
of
so
you
know
things
like.
Is
it
a
UDP
listener
or
a
TCP
listener,
or
for
some
of
the
upstream
cluster
stuff?
You
know?
B
B
A
Your
clock,
essentially
it's
pushing
back
even
further.
Basically,
where
there's
point
well,
we
can
no
longer
the
applicate
anything
and
remove
it
from
the
API,
and
this
is
you
know
it's
moving
things
which
I
wouldn't
know.
We
wanted
this
essentially
the
clock
to
correspond
with
envoy
releases
which
are
in
the
right
and
make
it
switch
towards
the
end
of
the
year.
That's
an
additional
quarter.
Anything
would
just
be
marked
deprecated
yeah,
so
you
know
anything
marked
deprecated.
It's
gonna
live
at
least
from
this
point
onwards
for
at
least
a
year
plus.
B
A
B
I'm
just
brainstorming
right
now.
It
feels
like
a
useful
compromise.
I
guess
all
I'm
saying
is.
If
we
let's
to
me,
let's
see
where
we
get
you
know
by
the
second
or
third
week
of
September,
and
it
feels
like
we're
done
with
the
low-hanging
fruit,
and
we
feel
good
about
how
things
are.
Then
that's
fine,
but
if
we
get
there-
and
you
know
we're
thinking
I
wish-
we
had
one
more
week
like
we
could
do
a
bunch
more
stuff
here.
That
feels
like
a
that
feels
like
a
good
use
of
time.
Yeah.
A
A
To
do
is
get
the
right,
API
cuts
and
then
the
actual,
tooling
and
automation
beds.
Some
of
these
things
can
you
know,
for
example,
you
know
stuff
like
to
keep
the
true
API
in
sync
or
to
make
sure
we're
not
violating
any
constraints
on
what
single
definite,
what
your
ody
are
and
this
kind
of
stuff
this
could
some
of
this
stuff
can
be
pushed
back
on
with
a
/
hands
up
the
first
time
around
sure.
B
B
A
A
B
On
I
yeah,
it's
lots
of
lots
of
words:
I'm,
just
I'm,
just
I'm,
just
thinking
like
tactically,
whether
it's
github
issues
in
the
in
the
UDP,
a
repo
or
whatever
and
I
can
help.
With
this.
Can
we
just
open
issues
on
on
like
the
things
that
we
want
to
actually
fix
right
right,
like
we're,
gonna
pick
a
small
number
of
things
that
we
think
that
we
want
to
fix
before
we
caught
c3,
whether
that's
that's
the
scalable
routing
or
the
listener
polymorphism
or
the
cluster
extensions.
The
named
filters
I'm
just
thinking.
A
D
B
Fine
I
mean,
however,
however,
you
want
to
track
is
fine
like
whether
it's
a
spreadsheet
or
issues
or
it
doesn't
really
matter,
but
I
just
think
that
will
give
us
a
better
way
of
collaborating
on
like
these
are
the
things
that
we
want
to.
These
are
the
small
fixes
or
small
additions
that
we
would
like
to
opt
meal,
and
in
v3
and
to
your
point
we
can
look
at
one
of
those
things
and
say:
oh
it's
incremental.
We
can
add
it
later.
B
That's
fine,
but
some
of
the
things
that
I'm
thinking
of
are
not
gonna
be
a
pro
mental
like
right.
So,
for
example,
like
named
filter
configs
is
not
incremental
over
the
current
situation.
We
actually
have
to
fix
that
proactively,
so
so
so
like,
let's
just
make
sure
that
we're
getting
on
top
of
those
things.
That's.
A
Correct
okay,
so
let's
let's
try!
So
if,
at
your
end,
you
can
make
sure
everything's
filed
and
label
to
correct.
Yes,
we
played
it
this
week
and
make
sure
everything
in
Mayans
in
and
other
folks
in
the
community
can
hopefully
look
at
that
label
and
either
look
at
the
issues
that
are
out
their
own
yeah.
That
sounds
good,
but.
B
My
my
general
comment,
though,
is
that
two
people
who
are
either
on
the
call
now
or
we're
gonna
listen
to
this
later
is
you
know
we
have
four
to
six
weeks,
basically
to
make
some
incremental
not
revolutionary
changes
to
the
API.
So
you
know
if
there's
things
that
you
want
to
see-
and
you
know
now-
is
the
time
to
speak
up
so
just
keep.
Keep
that
in
mind.
B
And
I
mean
and
again
I'm
just
being
realistic,
because
it's
one
thing
for
us
to
do
this
with
an
envoy,
but
then
trying
to
reconcile
this
with
theoretically
making
the
other
data
plants
happy
I'm,
less
convinced
that
the
timeline
is
going
to
work
unless
we
take
a
harder
line
on
just
this
is
what
we're
doing.
What's.
A
A
B
B
A
B
A
B
A
D
D
I'd,
rather
not
have
3
years
worth
of
deprecated
features
like
okay
and
plus
I
think
it's
worthwhile
getting
a
feel
for
the
tooling
of
having
two
versions
in
progress
like
sooner
rather
than
later,
just
like
feature
flags
or
whatever
else
like
there
was
a
bunch
of
work
that
we
didn't
anticipate
that
just
got
piled
on.
So
having
like
a
minimal
change,
that's
not
going
to
be
super
painful
learning
how
to
support
two
in
parallel
and
then
doing
like
the
big
one
makes
a
lot
of
sense
to
me.
Okay,
once
you
marry
so
sounds
good.
E
There's
a
group
of
researchers,
a
duo
who
are
looking
into
sto
a
lot
which
uses
envoy
everywhere
is
the
communications
backbone
and
we've
been
investigating
so
su
currently
for
auth
currently
uses
jots
as
a
issue.
The
authorization
header
to
authenticate
users
as
they
make
connections
into
their
applications
within
sto
and
the
Envoy
proxy
supports
pulling
jots
out
of
an
HTTP
authorization
header,
but
doesn't
currently
support,
pulling
it
out
of
a
cookie
and
there's
a
number
of
github
issues.
E
On
like
the
sto
issue,
page
that
people
are
asking
for
this
feature,
we
were
looking
into
this
feature.
Just
last
week
we
discovered
the
the
sto
group
is
working
on
an
OID
C
off
proposal
that
might
sort
of
supplant
the
idea
of
using
jots
in
cookies
directly.
But
it's
something
that
we
were
looking
into
and
so
I
was
hoping
to
sort
of
just
say,
hi
and
hold
the
room
and
see
if
anybody
had
thoughts
on
on
that.
F
F
I
didn't
follow
what
have
done
in
in
still
proxy
right
now,
so
it
might
be
already
usable
with
the
legs
upstream
on
just
filtering
boy,
but
not
supportive
in
in
still
proxy,
yet
so
that
one
once
in
the
texture
that
how
we
have
in
still
site
and
also
the
IDC
group
is
like
mom,
is
trying
to
do
more
comprehensive
story
of
supporting
o
NDC
research
or
education.
So
that's
the
current
status.
E
Yeah
I've
been
looking
into
the
OID
BC
proposal
and
that's
looking
really
good.
We're
gonna
join
the
meet
up
on
that
proposal
tomorrow,
yeah
find
out
more
about
that,
but
I
guess
so.
Just
just
to
clarify
you
mentioned
that
upstream
envoy
has
shot
support
in
the
authorization
header.
Were
you
saying
that
it
also
already
has
support
in
where
I
can
pull
jaws
out
of
cookies?
Yes,
I
think
so
we
are.
F
Essentially,
added
up
there
so
recently
OPRS
for
supporting
extracting
charts
from
other
header
and
matching
from
part
of
the
like
header,
like
semicolon
Ecore
based
elective,
which
field
to
extract
I,
think
you
might
be
able
to
make
use
of
that.
But
I'm
not
super
confident
that
is
usable
to
extract
from
cookie.
F
G
Hello
I'll
bill
row
here
so
yet
yeah,
cool
and
I
are
here
just
to
kind
of
check
in
that
appreciating
all
of
your
help
over
on
envoy
dev,
of
course,
trying
to
get
the
Windows
port
build
largely
interested
in
your
awareness
of
any
any
other
groups,
working
toward
or
interested
in
consuming
envoy
on
Windows,
first
off
and
just
to
kind
of
give
a
little
bit
of
an
update.
We
basically
have
all
the
sources
building,
there's
a
whole
bunch
of
work
around
I/o
handle
and
this
Iowa
socket
handle
info
that
we
have
to
finish
cleaning
up.
G
Of
course,
we
did
a
bunch
of
work.
Steven
did
a
bunch
of
work
way
back
into
last
year
and
so
now
we're
finally
getting
caught
up
to
to
current
origin/master
trying
to
get
back
in
sync,
so
you
guys
can
accept
some
patches
but
biggest
biggest
problems.
We're
having
are
around
the
extensions
API
so
and
I,
don't
know
how
to
I.
Don't
know
the
level
of
detail.
We
want
in
terms
of
the
PR
on
that,
but
basically
we're
finding
that
a
lot
of
the
extensions
weren't
actually
built
with
the
Envoy
extensions
CC.
G
Library
and
other
stubs
that
were
made
to
tune
whether
or
not
those
extensions
are,
in
fact
in
the
list.
I've
seen
human
interesting
proposals
on
dev
to
kind
of
move
that
over
to
assemble
our
list
of
enabled
extensions
right
off
the
bat,
even
even
as
the
build
system,
even
as
basil
kicks
in
so
we
would
actually
know
from
end
and
which
pieces
of
the
in
the
extensions
tree
are
just
fallin
which
pieces
are
not
sorry
I'm
not,
but
so
we
are
you
I'm
not
following
what
what's
the
broke
a
well.
G
B
F
F
How
we're
actually
building,
because
the
basil
is
smart
enough
to
detect
what
raw
is
not
required
by
specific
target.
So
if
we
do
like
stress
or
slash
dot
dot
dot,
you
will
be
basically
including
any
everything.
But
if
you
do
like
stress
or
stress,
exercise
avoid
static,
then
those
not
enable
the
extensions
are
not
being
compiled
anyway.
Right.
A
G
C
F
G
B
Cool
did
anyone
else?
Have
any
quick,
I
think
we're
out
of
time
any
real,
quick
things.