►
From YouTube: Envoy Community Meeting - 2019-07-02
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
B
C
Hey
how's,
it
going
awesome,
yeah.
B
D
Right
now
quickly
finish
all
the
plan
for
implantation
and
we
build
all
the
quick
coli
breweries
as
its
external
dependency
like
on
the
pipeline
stream
between
between
army
and
interaction
like
envoy,
or
we
have
a
buffer
to
keep
them
slice
conversion
and
on
the
quick,
quick
lesson
aside,
we
have
received
message.
We
have
system,
alarm
scheduling
and
now
we.
E
F
A
I
think
essentially,
like
part,
a
part
of
the
the
way
to
cope
library
was
built
was
fair
at
this.
You
know
neutral
platform
thing
I
think
not
familiar
with
it
Chios.
Actually,
there
are
a
bunch
of
utils
for
doing
addresses
the
way
they
click
'ok,
speed
of
doing
like
an
address,
wrapper
and
alarms
and
all
that
stuff.
So
that's
basically
done
and
then
some
of
the
basic
utilities
are
done,
and
so
so
dan
is
basically
working
now,
unlike
the
on
the.
A
A
D
A
A
B
D
D
D
B
So
I
guess
just
so
I
understand,
based
on
the
current
status.
Do
we
have
like
a
very
rough
estimate
of
when,
like
when
you're
planning
on
having
a
proof-of-concept
working
I
mean?
Is
that
I
just
don't
like?
Is
that
one
month
away
like
three
months
away?
The
reason
that
I'm
asking
is
that
I'm
starting
to
think
about
the
elf
for
hashing
components,
so
I'm
gonna?
Do
it
I'm
gonna?
B
Do
it
doc,
probably
in
the
next
couple
of
weeks
of
essentially
finishing
the
the
basic
UDP
proxy
and
then
building
a
quick
hashing
component
that
would
hash
on
connection
ID
and
that
would
allow
people
that
don't
have
a
hashing,
elf
or
load
balancer,
to
stand
up
an
elf
or
envoy
that
would
hash
on
quick
connection
ID
and
then
it
would
forward
the
packets
to
the
backends.
That
would
actually
do
the
l7
termination
so
I'm
just
trying
to
get
a
feel.
B
D
D
D
D
A
B
E
G
D
F
A
B
And-
and
that's
that's
where
we
want
to
go
also
because
what
what
we're
gonna
do
is
on
the
Envoy
mobile
side,
we're
gonna
make
that
into
a
production
quality
implementation
that
juice,
that
does
like
TCP,
fallback
and
a
bunch
of
other
stuff,
so
anything
that
we
can
do
on
the
integration
test
side
to
like
get
us
to
a
non
hockey
solution,
so
that
we
can
have
a
proper
client
would
be
good.
Obviously
we
don't.
B
A
A
B
That's
my
that's.
My
thinking
also
is
that
if
we
can
make
this
work
on
the
server
side,
we
should
be
able
to
have
a
codec
client
that
basically
supports
quick
and
I
and
again,
like
I,
admit
I
I,
don't
I,
don't
know
all
the
details,
but
it
seems
like
with
all
the
plumbing
work
that
you're
doing
it
feels
like
it
shouldn't
be
too
bad.
D
A
I
mean
essentially
the
the
way
that
the
abstractions
work
is
you.
You
have
that
the
codec
layer
basically
pulls
in
data
and
spits
out
streams,
and
so
for
server
side.
You
know,
we've
talked
about
pulling
data
in
from
the
socket
and
then
handing
it
in
the
ECM.
You
know
through
into
the
codec,
and
the
code
expects
streams
that
code
again
with
the
minor
differences
for
like
client-side
server-side.
So,
like
you
know,
okay
I
expect
a
URL.
A
A
That
same
code
is
used
an
envoy
to
create
the
envoy
test
clients
so
for
G
of
de
like
we
have
Jetstream
and
we
have
like
a
completely
synthetic
test
client
but
for
Envoy.
The
codec
class
is
used
both
on
the
server
side
and
on
the
client
side.
So,
like
once,
you've
done
that
code,
you're
90%
of
the
way
there
and
and.
D
B
So
right
right
so
I
mean
we
don't
like.
We
don't
is
obviously
figure
that
out
right
now,
but
that's
something
that
we
should
talk
about
and
track
towards,
and
that's
something
to
that
I'm
going
to
be
spending
significant
increasingly
spend
time
on
quick
in
in
this
half
I'll
be
focusing
again
mostly
on
the
l4
portion.
Now,
because
that's
work
that
you
both
obviously
are,
are
not
doing,
and
then
once
the
l4
hashing
component
and
stuff
is
done
and
I
finish,
UDP
proxying
then
I'll
be
available
to
help
with
you
know
like
yeah.
B
Yeah
and-
and
this
actually
comes
back
to
some
of
the
conversations
that
we've
had
where
there
is
some
overlap
here
in
terms
of
how,
on
the
client
side,
we
might
want
to
support
happy
eyeballs
and
like
quick
to
TCP,
fallback
and
stuff,
like
that,
so
yeah,
so
I've
got
some
ideas
on
how
that
might
work
and
again,
like
obviously
the
expectation
is
that
both
of
you
don't
don't
do
that.
But
insofar
as
we
can,
you
know
get
closer
to
that
direction.
That
would.
A
B
Right
and
and
and
again
like
we'll,
be
putting
together
design
Docs
for
all
of
that,
so
you
know
I,
don't
expect
to
do
any
coding
before
we
all
review,
but
but
but
yeah.
So
alright
great
is
there
anything
that
we
can
be
helping
you
both
with
that
would
make
things
go
faster,
or
do
you
feel
like
you're,
mostly
unblocked
at
at
this
point.
B
B
A
B
And
I
think
I
I
think
most
people
are
also
on
that
mailing
list,
the
Envoy,
a
quick
dev,
so
you
can
either
post
in
slack
or
you
can
reply
or
just
send
an
email
to
that
list.
If
there's
particular
issues
that
you
might
want
people
to
pick
up
and
like
I
said,
I
think
my
initial
focus
is
gonna,
be
on
the
elf
for
hashing
component,
mainly
because
everyone
that
isn't
Google
doesn't
have
that
so
I
mean
for
for
anyone
other
than
Google
to
do
a
production,
quick
deployment.
They
will
all
have
to
have
this
thing.
A
Just
calling
out
I
do
think
it's
super
worthwhile
to
do
when,
when
we
had
fraud
initially
and
were
deployed
and
live
I
think
we
made
it
all
the
way
to
chrome,
stable,
just
hashing,
based
on
IP
port,
really
Wow,
okay,
I.
A
C
F
A
A
C
A
G
A
B
A
B
Great
awesome,
thank
you
that
that
fully
answered
my
questions
is
there
anything
that
anyone
else
wanted
to
chat
about
on
the
quick
side?
Oh.
D
B
There
is
one
other
thing
that
I
wanted
to
point
out
just
so
everyone
is
aware:
there's
a
group
of
people
that
are
moving
forward
with
trying
to
get
on
boy
working
with
open,
SSL
versus
boring,
SSL
now
No.
So
before
we
all
freak
out.
Here's
here's
what
I'll
say.
What
we
have
said
is
that
we
are
not
going
to
support
open
a
cell
in
me
main
repo.
We
will
only
support,
boring
SSL.
B
You
know
abstract,
boring,
SSL
and
open
SSL
from
the
underlying
from
from
basically
the
TLS
needs.
My
stand
point
is
that
I
don't
want
any
of
you
to
be
blocked
on
trying
to
get
quick
working
in
any
way
with
OpenSSL
like
we
will
just
assume
that
it's
boring
as
a
cell.
Only
and
essentially
what
we'll
do
is
just
if
it'll
be
up
to
them.
If
they
want
to
try
to
get
it
working
until
then,
we
can
just
completely
disable
quick
on
an
open.
A
I
mean
given
that
boring
SSL
has
this
custom.
Yes,
we
built
and
actually
I
thought
that
they'd
be
having
quick,
disabled
and
I
know
except
stills
or
as
much
as
made.
You
might
be
a
really
good
make
sure
it's
like
we
do
plate
on
the
compile
it
out,
because
you're
boring
if
people
are
gonna
want
to
have
it
yep.
B
Yep
yeah,
so
so
so,
basically
I
just
I
just
wanted
to
warn
you
all
that
this
is
happening
and
just
make
sure
that
you
understand
that.
There's
no
expectation
in
any
way
that
you
support,
open
SSL
so
like
feel
free
just
to
move
forward
or
just
like.
Assuming
that
boring
a
cell
is
the
is
the
only
thing
but
I
just
bring
it
up,
because
you
might
see
PRS
or
you
might
see
people
commenting
in
in
certain
ways
and
feel
free
to
push
back
yeah.
A
B
A
A
B
G
B
C
B
D
B
Good
yeah
and-
and
you
know
on
that
topic,
we
can,
we
can
do
it
in
the
simplest
way
possible,
which
might
just
be
that
if
someone
specifies
that
config
and
it's
not
compiled
in
it,
just
basically
throws
an
error
like
we
don't
we
don't
need
to
do
anything
intelligent
or
something
like
that
yeah
great.
Okay,
thank
you
all
for
coming
and
getting
that
update
right.