►
From YouTube: Envoy Community Meeting 2019 09 24
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
Envoy Community Meeting for September 24, 2019
A
A
B
A
A
Done
that
I
feel
we
need
to
I
think
once
we
cut
b3,
we
need
to
have
this
discussion
I
feel
for
a
short
period
of
time.
At
least
we
would
have
to
allow
me
to
because
there's
still
people
actively
working
on
v2,
who
was
sort
of
blindsided
by
v3
and
they're
not
going
to
want
to
upgrade
to
v3
just
yeah.
C
A
B
Yeah,
that's
my
feeling
too,
is
that,
whether
it's
like
3
or
6
months
or
something
but
but
we
have
to
have
a
policy
so
that
people
know
my
my
gut
is
that
basically
halfway
through
the
cycle,
we
should
freeze
it.
So
if
it's
a
12-month
cycle,
we
should
basically
tell
people
you
know
after
six
months.
You
know
if
you
want
new
features
like
you
must
start
moving
to
the
the
new
version.
That's
my
that's
my
personal
feeling,
yeah.
C
I
would
leave
earlier
because
we
can
always
relax
it
and
also
again,
like
we've,
had
problems
before
where
people
don't
move
early
enough
and
then
find
problems.
And
so,
if
we
wait
six
months,
I
suspect
there's
gonna
be
a
bunch
of
stuff
that
people
like
if
there's
behavioral
changes
and
they
think,
like
I'm
plan,
saying
six
months
for
the
first
cycle,
we'll
see
how
it
goes,
but
like
a
bunch
of
big
things
like
the
websocket
change
or
something
like.
C
B
We
can
try
whatever
we
may
have
to
be
flexible,
that
this
first
time,
I
think
I'm
just
trying
to
balance.
It's
like.
We
need
to
get
people
to
move
forward,
but
I
also
can
realize
to
some
people
how
incredibly
irritating
it
would
be
like
if
we
told
them
that
you
know
they
added
one
field
that
they
want,
and
now
they
have
to
move
like
everything
over
I
mean
that
you
know
so
I
so
I,
just
you
like
giving
them
enough
notice
so
that
and
having
the
policy
clearly
written
down
that
we
can
reference.
A
I
kinda
feel
like
what
we're
gonna
do
with
the
v3
will
show
how
we
can
reduce
the
toil
by
example,
and
on
the
envoy
side
and
focus.
Well,
then,
let's
say
we
can
go
control
play
and
they're
gonna
have
to
adopt
the
patterns
that
we've
used
without
the
code
and
necessarily
in
envoy
to
actually
reduce
their
pain
in
moving
forward
through
these
major
versions.
For
what
is
remaining
six.
B
C
B
C
Essentially
again,
what
I,
what
I
want
is
something
that's
gonna
be
generalizable
and
it's
possible
that
I
should
do
like
the
one
API
have
to
change,
and
then
a
bunch
of
coding
changes
you
know,
but
essentially
for
anything.
That's
political
I
would
like
to
know
again
the
last
successful
load
for
an
instance
of
of
a
thing
and.
C
There
were
fail
modes,
so
if
they
are
named
things,
I
would
want
to
know
that
you
know
listener
food,
you
know
had
a
successful
load
five
minutes
ago
and
it
had
a
failed
load
one
minute
ago.
But
if
it's
the
first
time
we
loaded
foo
I
do
want
to
track
the
fact
that,
like
we
never
successfully,
billeted
foo
for
in
turn,
yeah.
A
C
B
So
I
I
haven't
had
a
chance
to
type
into
the
get
up
as
you,
but
that
was
going
to
be.
My
suggestion
also
is
to
like
essentially
move
it
over
where
now
it's
just
a
map
of
basically
name
to
a
thing
and
in
there
I
think
we
can
structure
it
so
that
you
know
if
it's
active,
like
here's,
the
active
conveying
and
like
here's
when
it
was
last
loaded
like.
B
If
there's
a
failure,
there
could
be
like
a
failure
section
with
the
config
that
failed
to
load
and
that
you
know
if
it's
warming
or
draining
you
could
optionally.
Have
you
know
what
the
warming
or
or
the
training
config
was,
does
not
work
like
I,
think
that
would
be
flexible,
and
then
that
would
work
for
clusters
also.
C
B
B
The
object
basically
contains
the
config,
the
running
status,
the
last
low
time,
like
all
of
the
things
that
you
had
said
in
the
case
that
there
was
a
failure
since
last
load,
you
would
have
like
an
optional
part
of
that
object,
which
is
like
last
failure,
and
then
you
know
if
it
was
draining
or
something
else
you
could
even
have
and
then
an
optional
section
of,
like
you
know,
draining
convey
drained
at
time.
You
know
draining
configuration
right,
but
that
wouldn't
show
up
unless
those
things
are
actually
happening.
C
B
Fine,
so
then
basically
be
yeah,
so
it's
like
we
can.
We
can
figure
out
the
object,
I
think.
In
that
case
you
would
have
a
last
failure.
Data
right,
which
contains
the
last
failure
and
then
they're
just
there
would
be
no
active
configuration.
So
it's
like
the
only
thing
in
the
name
would
be
like
a
last
failure.
Basically
well.
B
C
Preferences
on
what
we
want
to
do
for,
if
there's
only
a
felt
like
if
there's
a
listener,
it's
pretty
easy
to
say
we're
gonna,
remove
it
when
it's
removed
right,
I,
don't
I,
don't
think
we
need
to
have
it
processed
that
if
it
fails
on
startup,
then
there's
a
question
of
when
we
are
with
it.
They
want
to
have
that
they
can
figure
ball
or
just
kind
of
hard
coded
for
now
and
yeah
right.
B
A
Works
for
resources
delivered
by
Audie
sdds
we're
on
boys
knows
what
it
wants:
the
state
of
the
world's
updates,
the
things
coming
from
LDS
and
CTS-
that's
not
the
case,
and
so,
unless
you're
saying
we
since
you're
going
to
deletes
the
failure
now,
that's
full
yet
something
which
might
be
reasonable.
Actually,
because
you
know,
when
you
have
a
successful
audience
updates
and
everything.
That's
all.
A
C
B
B
Think
that's
I.
Think
that's
fine
because,
like
what
one
of
the
work
items-
and
this
came
up,
I
mean-
is
something
that
I
know
that
we've
talked
about
and
it
came
up
when
I
tried
to
remove
the
experimental
flag
from
config
dump
is
that
we
definitely
still
need
to
invest
more
and
config
dumb
in
terms
of
like
making
it
available
for
filtering
and,
like
various
other
feature,
so
you
could
imagine
based
on
either
a
protorpc
or
just
like.
You
know,
query
params,
that
you
could
change
the
behavior
and
actually
make
it
display
different
things.
C
B
B
Yeah
sounds
sounds
great
and
I
mean,
if
you
don't
mind
since
you're
gonna
do
that?
Could
you
do
clusters
also
because
I
think
I
think
I
think
we're
gonna
wind
up
with
the
same
situation,
basically
cool,
because
that
way
we
can
just
agree
on
the
overall
structure
and
make
sure
that
it
looks
similar
for
both
clusters
and
listeners,
because.