►
From YouTube: Envoy Community Meeting - 2019-03-26
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
C
A
C
C
D
E
F
Yeah
moles
is
a
very
painstaking
to
convert
the
the
configs
because
they're
all
pretty
much
the
other
date
and
then
I
plan
on
starting
on
the
test
code
changes
so
there's
a
fair
bit
that
needs
to
be
done
there
and,
lastly,
the
the
learn
site
which
Chris
posted
the
the
source
for
in
the
chat
is
all
out
of
date
and
that
I
think
that's
driving
a
lot
of
our
so
the
chatter
in
their
black
about
all
configs.
Well,.
B
Yeah
there's
that
and
then
this
will
come
up
in
the
next
thing
and
maybe
maybe
I'll
move
it
and
we
can
talk
about
it
in
parallel,
but
I
think
those
docker
image
changes
that
I
made
are
also
confusing
people.
It's
like
you
can't
win
here,
but
I
think
we're
actually
moving
towards
a
better
place,
but
on
I
guess
on
the
any
vs.
truck
thing.
I
have
one
fundamental
question,
and
maybe
this
is
for
Harvey
I'm,
not
sure.
Is
there
some,
like
I
thought,
there's
some
problem
with
using
any.
A
Yes
problem
is
it
comes
down
to
what
what
we
do
is
we're
hashing
protobufs
and
you
I
see
the
GOP
CT,
maybe
getting
excited
there.
Yeah
hushing,
hushing
protobufs
is
probably
never
a
good
idea.
I
mean
canonical
hash,
staple
hash
value
and
we're
trying
to
actually
make
it
such
that
I
think.
There's
a
bunch
issues
files
here
at
least
me.
Individual
languages
have
stable
hashes.
A
They
would
have
unsampled
hashes,
essentially
in
metal
force,
training
and
high
CPU
utilization
in
this.
Do
so
I
think
some
of
this
has
been
fixed
in
different
ways
like
I
know,
I
think
they've
actually
fixed
this
on
the
go
side,
I
think
they're
on
the
it's
really
switch
back
to
struct
for
their
last
release
because
of
this
issue,
and
they
didn't
want
to
see
the
CPU
spike
and
I
think
it
still
needs
to
be
fixed
it,
the
predator
levels,
so
yeah.
B
C
A
Items
there
I
think
you
can
call
her
yeah,
but
Matt
I.
Think
it's
fine
for
all
the
configs
I
think
the
only
place
at
any
is
a
problem
is
when
we
have
a
dynamic
control,
plane
and
people
are
concerned
about
draining
behavior
specifically,
so
those
are
the
ones
we
shouldn't
convert
over
and
we
should
put
a
big
like
a
big
warning
label
up
there.
The
rest
I
think
are
perfectly
ready
for
primetime
use.
Okay
sounds
good.
F
B
F
B
Our
like
config
gen
examples
and
what
I'm
suggesting
is
that
those
can
fix
today
will
continue
to
run
even
using
deprecated
fields
and
what
I'm
suggesting
is
that
if
we
somehow
make
it
so
that
when
we
run
those
configs
thru
config
tests,
we
make
them
fail
by
default.
And
then,
when
just
sorry,
what's
up
its.
B
It's
it's
it's
own
thing.
It's
a
it's
a
unit
test
so
but.
C
G
B
B
A
B
Just
in
the
interest
of
time,
we
should
probably
move
along
I
did
want
to
mention
that
for
everyone
out
there
I
did
it.
So
there's
been
a
constant
source
of
confusion,
which
is
that
we
have
one
docker
image
rebo
and
we
mix
in
a
tagged
images
and
the
masterbuilt
images,
and
we
constantly
get
questions
about.
You
know
where's
the
version
release
or
where
the
daily
releases,
so
what
I
did
is
I
split
them
so
that
we're
gonna
put
the
tag
releases
in
the
Envoy
docker
hub
repo
and
the
master
releases
and
on
boy
dev.
B
This
has
exposed
a
bunch
of
similar
issues
where
there
are
people
out
there
who
were
just
running
latest,
which
is
probably
not
great
if
you're
out
there.
Please
don't
do
that,
who
I
think
have
gotten
confused
because
now
latest
snap
back
to
version
1.9
point.
Oh
so
I
have
a
PR
up
right
now,
which
actually
fixes
the
docs
try
to
snap
stable,
docks
and
stable,
stable
images
so
that
when
you're?
Looking
at
the
1.9
point,
no
docks
you'll
actually
point
you
at
the
1.9
point,
Oh
image
or
a
point.
B
B
I'll
I'll,
stop
I
think
we
can
do
some
stuff
with
environment
variable
injection
in
the
docker
files
to
make
it
run
from
the
right
place,
but
you
could
track
that
work
on
on
get
up
if
you're
interested,
but
the
goal
from
my
perspective
is
we
should
get
to
a
place
where
people
that
are
running
master
and
are
looking
at
master
docs.
They
seem
Docs
that
are
consistent
with
all
of
the
configs
and
the
image
that
actually
runs
those
docks
and
for
people
that
are
running
tag
releases.
B
F
B
A
B
Would
be
I
think
really
helpful
for
me
and
everyone
else
if
either
you
or
the
G
RPC
team
yeah
could
just
in
a
couple
of
minutes
just
describe
to
everyone.
You
know
what
you're
trying
to
achieve
why
the
current
thing
is
broken
and
then
we
can
start
brainstorming
or
discussing
different
solutions.
Yeah
I
think
especially
Doug
goes
that's
again.
That's
right!
Yeah,
yeah.
H
H
Oh
okay,
oh
cool,
so
I
put
together
a
quick
one
pager
to
sort
of
cover
this,
but
yeah
so
gr
pcs
been
looking
at
moving
to
envoy
XPS
protocol
as
our
load
balancing
and
named
resolving
built-in
solution
to
replace
something
that
we
designed
and
developed
in-house,
and
so,
oh
sorry,
okay,
just
for
rebounding,
okay,
great
and
right.
So
while
we
were
in
the
process
of
developing
this,
at
least
for
go,
we
got
broken
a
couple
times
by
some
changes
that
were
made
in
the
proto
files.
H
These
were
both
I
believe
instances
where
a
field
got
moved
from
outside
of
a
102
inside
of
a
one-of
and
that
that
breaks
the
go
API,
but
not
in
other
languages
or
at
least
not
in
C.
So
so
yeah.
We
started
sort
of
digging
into
the
breaking
change
policy
and
envoy,
and
we
were
a
little
bit
concerned.
I
guess,
by
what
we
read
in
the
form
of
discovering
that
features
could
actually
be
removed
during
a
major
version
of
the
XPS
protocol,
and
this
is
going
to
cause
some
problems
for
us.
So
I
don't
know.
H
B
C
H
Sure
I
can
do
that
and.
A
F
H
H
So
if,
in
the
future,
let's
say
envoy,
looks
at
the
protocol
and
decides
hey,
you
know
this
future.
Sorry,
okay!
So
so
you
know
feature
foo
here
is
you
know
not
really
what
we
needed?
What
we
needed
is
feature
bar,
which
has
you
know
the
same
capabilities
as
foo,
but
it
also
lets
us
do
some
other
things
so,
for
instance,
a
boolean
being
changed
into
like
a
floater,
an
int
to
represent
a
percentage.
Instead
of
on-off
so
so
on,
Boyd
decides
we're
going
to
deprecated
this
old
feature.
H
It's
superseded
by
a
new
feature
that
has
more
functionality
and
so
based
on
our
reading
of
the
breaking
change
policy.
This
is
allowed,
but
this
is
fine
for
now
because
even
though
traffic
director
here
has
updated
to
the
latest
version
of
the
XPS
protocol
and
Envoy,
everything
still
works
because
foo
is
still
declared
and
it's
still
supported
by
traffic
director.
H
So
everything
keeps
working,
everything's,
good
and
now,
let's
so
dr
pc
has
a
decision
to
make
either
we
keep
using
foo
or
we
switch
to
using
bar,
because
we
either
want
to
work
with
the
old
versions
or
the
new
versions,
and
so
here's
here's
where
things
go
wrong,
step
1.
So
g
RPC
in
this
case
we
decide
hey.
We
want
to
keep
up
with
the
latest
and
greatest
envoy
version,
so
we're
going
to
switch
over
to
using
bar
who's
going
away.
H
Let's,
let's
go
to
the
next
picture
so
now,
when
envoy
releases
version
1.1,
actually
the
Foo
field
entirely
will
be
deleted
and
it
would
be
impossible
to
even
do
version
negotiation,
except
maybe
to
negotiate
that
you
can't
work
together
because
that
field
isn't
even
present.
So
you
can't
support
that
old
feature
anymore,
so
essentially,
traffic
director
and
sorry,
the
colors
here,
I
forgot
to
mention
yellow,
was
things
that
work
with
foo
and
purple
are
things
that
work
afar
and
before
we
had
a
gradient
on
traffic
director,
because
it
was
in
that
intermediate
version.
H
But
now
traffic
director
is
updated
to
the
latest
latest
version
that
eliminated
foo
entirely
and
now
you
see
all
of
the
existing
G
RPC
deployments
that
were
working
using.
Who
can
no
longer
talk
to
this
new
version
of
traffic
director.
Meanwhile,
you
know
the
new
version
that
uses
bar
still
can't
talk
to
the
sto
deployment
in
the
customers,
kubernetes
environment,
because
that
hasn't
been
updated
either.
So
so
I
think
the
issue
here
is
when,
when
foo
gets
deleted
from
the
proto
we
have.
B
Ok,
I'm
I'm
a
little
lost,
though
here,
because
I
I
definitely
understand
some
of
the
concerns
around
versioning
I
mean
that
makes
sense
and
I
thought
this
conversation
and
maybe
I
was
incorrect.
I
thought
this
conversation
was
mostly
around
the
fact
that
we
don't
want
like
a
Shaw
or
a
version
based
API.
We
want
something,
that's
tagged,
but
if
I
understand
it
now,
I
mean
you're
you're,
suggesting
that
we
can't
deprecated
fields
like
I
I.
Don't
doesn't
that
doesn't
make
a
lot
of
sense
to
me
right
so.
H
So
deprecated
I
guess
has
different
meanings
to
different
people,
so
so
we're
okay
with
deprecation.
It
just
needs
to
remain
available
and
supported
until
at
least
by
the
protocol,
maybe
not
by
the
latest
versions
of
envoy.
If
that's,
you
know
how
envoy
works,
but
it
needs
to
remain
in
the
protocol
because
you
know-
and
it
could
be
March
deprecated,
but
it
needs
to
stay
there,
because
otherwise
you
can't
even
read
the
fields,
and
so
you
can't
support
legacy
applications
once
it's
been
removed
and
Sue's,
so
there's
actually
lesser.
Okay,.
F
H
Practices
for
managing
proto's
have
widely
been
agreed
upon,
as
if
you
break
backward
compatibility,
then
you
really
should
create
a
new
protocol,
the
same
messages,
but
with
the
things
removed
that
you
were
intending
to
remove
so
once
you've
added
something
to
a
namespace.
You
can
never
remove
it
from
that
namespace,
so
it's
essentially
semantic
versioning
for
proto's
and
you
do
a
major
release
by
changing
the
prototype
version.
So
so.
B
That
part
makes
total
sense
to
me,
and
we
can
talk
about
a
variety
of
different
proposals
by
which
we
can
make
that
better
I
mean
I,
I
think
we'll
end
up
splitting
hairs,
because
I
think
you
can
do
a
lot
of
this
from
a
sha
based
perspective
or
name
space.
But
yes,
I
totally
agree
that
we
can
do
better.
There
I
still
want
to
come
back
to
requirements,
though,
because
that's
where
I
think
I'm
getting
a
little
confused,
which
is
to
me
there's
there's
two
separate
things
here.
Right
previously,
we've
been
talking
about.
B
You
know
essentially
XDS
as
an
API
for
envoy
and
management
servers.
There's
some
deprecation
window
at
which
we
can
move
things
around
you're,
obviously
going
to
use
the
XDS
api
for
a
different
purpose,
but
I
guess
what
I'm
still
trying
to
understand.
Is
that
like?
Let
me
let
me
just
suggest
something
if
we
kept
the
same
deprecation
policy,
but
we
basically
just
kept
incrementing
the
namespaces
so
that
you
could
go
back
in
time
to
a
particular
sha
or
version
that
you
support,
but
we're
still
removing
things
every
three
or
six
months.
Does
that
work?
B
B
H
I
H
I
H
B
One
of
them
is
how
we
version
things
and
again
I
was
saying
before
we
can
split
hairs
about
this,
because
technically
you
could
say
that
the
proto's
are
version
at
a
particular
shot
and
that's
what
they
are
I'm,
not
saying
that's
what
we
should
do,
but
that
would
technically
work,
but
then
there's
the
other
concern
which
I
think
I'm
hearing
and
that's
what
I
really
want
to
understand
that
to
you.
Our
deprecation
policy
is
too
short,
and
it
needs
to
be
longer
like
is
that
is
that
accurate.
H
B
H
So
but
that's
that's
sort
of
like
on
one
end
of
the
spectrum
right
and
and
then,
if
we
move
to
okay,
we
work
with
v2
and
then
meanwhile,
the
envoy
project
has
moved
on
to
b-17
by
then-
and
it's
only
you
know
a
couple
months
later,
then
they're
also
going
to
look
at
us
really
confused
and
upset
because
we're
not
able
to
give
them
something
that
works
with.
You
know
what
they
might
be
running
in
their
environment
plus
it
makes
our
job
a
lot
harder
because
we
have
to
support
the
universal
version.
H
A
F
C
That
we're
changing
this
deprecation
policy,
where
we
have.
We
have
this
a
six
month
window
now
right.
We
plan
at
some
point
TBD
to
go
to
a
year
envoy
cuts
releases
quarterly
so
that
that,
basically,
you
know
I
think
you
could
say
we
support
every
fourth
version
and
you
would
be
able
to
say.
Okay
now
you
migrated
from
the
last
version.
Support
of
this
versioning
you're
you're
upping
your
vs.
once
a
year.
Well,.
B
B
I
still
think
we
need
to
be
a
little
bit
crisper
about
what
the
actual
requirements
are,
because
before
we
even
start
talking
about
solutions
because
again,
I
think
what
I'm
hearing
is
that
the
length
of
our
deprecation
policy
is
not
long
enough,
but
even
there
I'm
still
a
little
confused
because
envoy
the
proxy
as
I
understand.
It
may
actually
not
be
involved
in
this
problem
at
all
right
because
you
have
a
gr,
PC
client.
You.
B
I
I
think
one
of
the
key
points
here
that
it
isn't
sort
of
the
problem
we're
talking
about,
but
is
the
underlying
philosophical
issue,
is
if
we
intend
the
XPS
protocol
to
really
be
an
industry
standard
thing
that
is
not
envoy
specific,
then
tying
its
versioning
to
envoy
doesn't
really
make
sense
right.
There
are
sure,
and
it
needs
to
be
an
independent
thing,
Shh
sure.
B
And
again,
I'm
confident
that
we
can
find
a
proposal
that
that
will
work
for
everyone
like
I,
think
the
solutions
are
pretty
well
understood
and
I.
Think
with
the
right
tooling.
We
can
figure
something
out
here
so
like
I'm,
not
I'm,
not
concerned
about
that
I'm,
mostly
per
my
comment
on
the
issue.
I
just
want
to
make
sure
that
we
make
all
of
you
happy,
but
we
don't
decrease
velocity
and
I'm,
actually
pretty
confident
that
we
can
do
that.
B
But
with
that
said,
I
I
think
that
actually
laying
out
like
what
the
different
scenarios
are,
like
you
did
in
the
doc
and
what
the
requirements
are,
would
be
very
helpful
for
helping
us
build
the
final
solution
and
I
think
that
would
be
just
a
framing
of
the
different
scenarios
of
you
know
using
the
protocol
without
envoy,
using
it
with
envoy.
These
are
the
different
deprecation
dances.
These
are
the
timelines
that
you
would
be
looking
at.
Is
it?
B
I
B
C
B
Yeah
yeah,
because
again,
like
I,
am
actually
quite
confident
that,
with
the
right
to
Ling,
there's
I
can
think
of
four
different
ways
that
we
could
solve
this
problem
and
and
they're.
Probably
all
fine,
but
I'm
still
concerned
that
if
we
still
deprecated
things
too
fast
or
do
things
in
the
wrong
way,
we're
still
gonna
end
up
making
you
angry
so
I
feel
like
we
have
to
look
at
this
a
little
more
holistically.
Okay,.
A
B
Other
thing
that
I
think
that
we
could
do
that
will
likely
come
out
of
this
sorry
I
just
super
quick
is
I
think
that
we
can
enhance
the
existing
deprecated
attributes
on
the
proto's,
say
things
like
deprecated
for
Envoy,
but
not
deprecated,
for
the
protocol,
for
example,
and
like
we
can
do
things
like
that,
so
anyway,
I'm
confident
that
we
can
figure
something
out
here,
but
I
think
that
if
you
could
put
that
initial
talk
together,
that
would
be
really
helpful.
Okay,
we'll
take
a
look
at
thanks.