►
From YouTube: Envoy Community Meeting - 2019-05-07
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
B
A
A
C
Yeah
basically
I
feel
like
unless
there's
any
strong
pushback
on
the
versioning
proposal.
It's
just
we'll
start
rolling
there
with
it
I
mean
I'm
right
now,
I'm
working
on
the
next
TDS
PR
and
once
that's
done,
yeah
I'll
start
actually
working.
That's
when
the
machinery
and
things
that
we
need
to
actually
make
this
all
for
are.
B
There
I
I
guess
my
question
is:
are
there
any
remaining
open
issues
because
I
know
we
had
some
concerns
about
either
the
timelines
of
things
and
then
I
know
there
are
some
concerns
around
the
like
how
people
set
deprecated,
which
is
part
of
the
CD
s
proposal,
so
I
just
I'm
having
a
hard
time
wrapping
my
head
around
like?
Are
we
good
or
are
there
still
open?
You
have
a
list
of
open
questions
in
the
doc
and
they're
very.
C
C
B
Yeah
I
guess
my
my
sense
is
that
it's
going
to
become
clear
once
you
build
the
tooling
like
there's,
probably
I
mean
there's
some
I
guess
conceptually.
This
all
makes
sense
to
me,
but
but
I
feel
like
until
we
can
play
with
the
developer
flow.
It's
not
it's
not
quite
as
clear
what
the
implications
are.
C
Yeah
I
I
agree.
So
that's
why
I
wasn't
sure
him
set
up
a
tool
playground.
So
we
have
two
separate
things
we
need
to
do
by
the
end
of
q2.
The
first
is
get
to
b3.
Api
is
ready
and
I.
Think
a
lot
of
that's
going
to
be
pretty
mechanical
is
already
play
that
up
by
swinging
clean
up
stuff
like
using
a
unify
head
amount
formats
and
yeah.
A
C
These
places
where
we
know
we've
replicated
things
and
it
allows
you
just
be
a
refactoring
I,
don't
imagine
any
significant
real
change,
yeah
it'll
clean
up
one
offs
and
all
this
kind
of
stuff,
and
then
there
will
be
the
National
tool
and
just
support.
All
of
that,
and
that's
that's
probably
the
most
of.
A
D
C
A
B
One
of
the
things
that
I
was
I
was
thinking
about
is
I,
almost
wonder
you
know
we
don't
we
don't
use
the
Envoy
announce
list
very
much
or
very
consistently
and
I.
Guess
one
of
the
things
that
I'm
wondering
and
again
this
is
me
just
brainstorming
out
loud
is:
should
we
have
something
similar
to
the
Security
distributors
list
for
like
deprecation
clock,
tick
right
so
that
people
that
care?
You
know
they're
gonna,
get
like
a
cadence
of
announcements
on
a
particular
email
list
for
distributors,
which
basically
says
you
know
this
is
when
the
clock
starts.
B
This
is
when
it's.
When
it's
going
to
be
going
to
be
done
and
and
to
be
honest,
I,
don't
see
it
as
any
different
than
when
a
bon
dieu
does
long
long
term
stable
releases,
and
they
say
you
know
it
lives
until
X
date
and
here's
what
we're
doing
patches
and
then
we're
no
longer
supporting
it.
These
these
calendars
are,
you
know,
they're,
they're,
written
down
and
they're
well
understood
so
I'm
wondering
if
we
just
need
to
get
more
prescriptive
about
actually
having
a
calendar
that
people
can
look
at
yeah.
A
A
B
A
A
A
A
E
B
A
C
C
Okay,
so
getting
back
suppose
I
guess:
we've
had
a
few
people
join
us
so
kind
of
curious
from
the
folks
who've
George
already
read.
The
proposal
have
read
it.
What
you
do
be
interested
in
having
me
cover
here
and
just
for
context.
This
is
the
API
versioning
and
the
stable
envoy
API
versioning
policy,
which
is
linked
in
the
minutes
as.
C
Like
a
five
minute
summary,
you
know
so
you
know
they're
beating
some
concerns
that
the
v2
API
is
have
not
had
the
stability
properties
that
are
necessary
for
cloud
operators
or
folks
who
are
adopting
homeboys
API
is
outside
of
the
envoy
code
base.
The
most
prominent
example
of
this
is
G
RPC
lb,
who
committed
to
replacing
that
proprietary
client
so
because
I
load-balancing
control,
plane
protocol
with
that
of
envoy
is
they're
using
an
XDS.
Essentially,
and
so
you
know,
you
can
kind
of
see
how
this
how
I
got
here.
C
We
we
moved
from
the
view
and
API
servers
of
restful
and
JSON
schema
based,
so
they
were
just
proto
base
which
in
theory
had
the
promise
of
you
know
real
backwards
compatibility,
but
we
were
playing
a
bit
loose
and
fast.
Even
though
we
had
an
official
policy
for
breaking
changes,
and
we
learned
we
would
know
if
you
know
carolien
randomly
turning
things
down.
C
So
in
response
to
that,
I
essentially
have
a
proposal
which
I've
shared
there's
both
the
long
form,
which
is
like
20,
odd
pages
in
the
short
film
version
of
its
now,
which
is
like
has
a
couple
of
pages
and
the
residues
describe
how
we
can
take
what
we
have
to
bear
with
the
v2
API
and
turn
this
insurance
from
an
ongoing
evolution
of
the
api's.
And
never
you
know
we
were
simply
going
from
a
world
of
the
v2
FCS
api's
to
v3
LDS
v
for
bootstrap
v6.
C
You
know
leaf
header
map,
helper
v7
data
formats,
so
basically
a
family
of
api's
which
really,
in
reality
the
home,
where
a
POS
were
all
along
each
with
their
own
independent
sort
of
major
versions
and
release.
Kayden's
they're
basically,
will
all
follow
a
single
clock,
but
beyond
that
they
will
involve
somewhere
independently.
The
main
thing
that
we
can
we're
reaping
win
that
we
get
from
it.
C
There
are
more
communities,
we
got
a
clearance
for
our
technical
down
in
the
api's,
be
able
to
make
our
breaking
changes
without
the
fear
of
actually
having
any
existing
users
affected.
Only
users
of
the
new
API
versions
that
we
make
these
breaking
changes
in
the
alpha
api's
are
affected
by
changes
and
we're
essentially
in
this
position
where
existing
API
is,
will
have
no
breaking
changes,
and
so
that's
pretty
great.
C
There's
a
lot
of
technicalities
over
how
we're
going
to
deal
with
things
like
tooling
and
minor
versions
and
version
discovery
and
feature
discovery
and
quirks
around
how
to
deal
with
clients
which
may
not
support
the
full
feature
sets
pretty
donor
to
go
into
too
much
detail
here.
I'm
more
interested
in
sort
of
hearing
from
folks.
C
If
they
have
questions
about
any
of
these
specific
items,
the
goal
is
to
maintain
a
release
cycle
for
envoy,
which
will
still
be
causally
and
just
as
it
is
today-
and
we
were
on
top
of
that,
we
will
also
do
API
major
version
releases
and
spinouts
once
per
year.
Initial
target,
for
that
is
end
of
q2,
so
yeah
likely
not
to
have
any
questions
in
this
part.
D
Some
concern
mainly
about
like
how
much
room
we
will
have
when
we
improve
when
we
bumped,
like
a
version
of
the
API
like
we
did
like
index
Dossett
bump
from
V
to
alpha
2,
V,
2
and
there's
a
lot
turn
to
having
like
2
version
of
API
registered
in
server
side
and
in
my
side
in
control,
plane,
side
and
data
plane
side
and
that
go
back
and
force
a
couple
times.
Do
we
have
like
two
or
change
to
support
that
in
both
side,
so.
C
I
mean
homeboy.
Sorry,
the
plan
is
definitely
to
make
that
as
painless
as
possible
by
writing
lots
of
tooling
to
automate
things
like
you
know.
If
you
need
to
copy
proto's
across
with
only
a
single
feel
difference
and
build
all
the
code
to
ingest
that
that
will
be
largely
the
plan
is
to
automate
that
away
with
reflection,
tooling
and
so
on
you
now
you
are
right
that
any
management,
server,
Easter
and
rollouts,
and
so
on,
is
going
to
need
a
roof.
C
Probably
support
two
major
versions
realistically,
at
least-
and
that
is
I,
understand
and
go-
is
very
verbose
and
cumbersome.
I
personally,
don't
plans
to
build
outs.
You
know:
go
control
playing
or
management
server
sort
of
tooling.
For
that
I
feel
that
problems
should
be
solved.
I
think,
once
we
establish
some
good
patterns
for
doing
this
in
C++
for
Envoy,
it
should
be
relatively
easy
to
say.
Well,
Hollywood
works
that
way
and
they
managed
to
reduce
that
culture
and
by
using
reflection
and
cogeneration.
Let's
just
do
the
same
thing
go
and
actually
a
relatively
straightforward
exercise.
C
C
I
I
mean
I
personally,
I
didn't
think
I
can
commit.
I
can
commit
to
doing
a
lot
of
the
work
either
myself
or
my
team
for
stuff,
which
is
necessary
to
enable
the
home
or
side
of
this
and
for
the
AAPI
photos,
but
the
actual.
Oh,
let's
go
what
I
mean
just
I
mean
frankly,
like
I'm,
not
qualified
you
to
go
work,
I'm
I'm,
not
a
girly
valleca.
This
is
a
it's.
B
A
it's
a
reasonable
point,
though,
that
most
of
our
consumers
for
these
proto's
are
go
so
I
I
would
say
that
we
need
to
be
cognizant
of
the
pain
that
we
might
cause.
People
also
maybe
like,
as
we
start
doing
some
technical
discovery.
We
can
loop
in
some
folks
and
just
try
to
get
a
feel
for
what
it
would
mean
on
the
go
side
and,
to
be
honest,
it
might
be
enough
to
loop
in
the
GRP
see
people,
because
they
have
a
vested
interest
in
making
it
work.
C
C
If
you
want
to
hit
our
original
calls,
but
then
we
have
like
a
whole
year
after
that,
where
v2
is
still
a
fully
supported,
API
and
we'll
have
v3
as
well
as
that's
like
an
entire
year
in
which
we
can
look
at
the
server
side
of
this
I'll
start
supporting
roll
over
roll
out
yeah.
Definitely
anything
we're
going
to
touch
anything
the
management
side
by
the
end
of
q2,
and
there
will
probably
use
some
combination
of
yeah
well
reach
out
to
folks
we'll
hear
from
the
community.
C
What
that
pain
points
are,
and
ideally
prioritize,
stuff
I
mean.
Obviously
we
all
have
a
vested
interested
in
making
the
API
is
work,
and
so
we
have
found
at
the
end
of
that
saying
a
year
and
a
quarter
that
it's
just
so
difficult
for
people
rollouts
that
it's
a
completely
block
for
that.
That
would
be
our
failure
situation.
So
we
need
to
avoid
that's
happening
by
you
know,
basically
just
watching
what
goes
on
as
people
in
this
role.
Ask
then
probably
refocusing
our
efforts
on
perhaps
even
on
the
control
plan
side
as
as
needed.
C
C
C
We
keep
it
reasonably
small
focus,
but
we
will
be
relaying
information
back
to
our
community
and
provide
opportunities
for
other
parties
who
have
legitimate
need
to
be
members
of
this
committee
to
join
like
it's
a
generally.
Basically
it's
you
know
it's
I
guess
a
semi
public
forum
is
what
I
would
describe
it.
I.
B
Think
that,
though
there
there's
gonna
be
a
learning
curve
where
I
don't
think
we
know
how
engaged
people
well
will
want
to
be
so
I
think
we'll
need
to
see
but
I
think
right
now
we
have
commitments
from
all
of
them
all
the
major
clouds
and
and
effectively
from
the
load
balancer
side
on
ROI
and
gr
PC,
so
I
think.
Initially
it's
still
going
to
be
envoy
focus,
but
even
there
there's
value
in
making
sure
that
the
API
is
evolved
in
a
way
that
meet
the
needs
of
all
of
the
cloud
providers.
C
C
B
D
These
CI
stability,
so
I
have
a
couple
of
the
evaluation.
Pr
goes
out
with
trying
to
speed
up
CI
for
a
couple
items.
One
is
the
RBE
which
I
expect
to
do
the
full,
build
and
test
within
around
ten
minutes
for
the
whole
CI
and
the
one
is
the
coverage
safe,
speed
up
to
switch
from
G
cough
or
to
lvl
p.m.
coverage
and
I
think
we
can
trigger
the
GCC
to
can
search
for
the
release
period.
Well,
that
was
been
my
spirit
appeal
much
as
well.
D
B
One
of
the
things
that
we
need
to
do,
which
maybe
you
and
I
we
zon
can
take
offline,
is
I
know
that
ETA
got
a
new
job,
which
you
know
probably
means
he
doesn't
have
as
much
time
to
work
on
rainbow
kitty
and
like
I,
do
want
to
know.
Specifically,
you
know
what
api's
does,
as
your
pipelines
have
and
like
like.
B
D
B
A
B
B
B
F
D
F
D
Configuration
is
kind
of
a
bit
hard
for
me,
since
we
need
to
generate
free
generator,
costume
files
for
the
darker
image
you're,
using
for
B
and
I.
Think
six
or
three
months
ago
we
still
have
the
repository
rules
that
beauty
dependencies
in
shell
script
and
there's
a
lot
of
stuff
that
works
well
with
Harvey.
We
already
deprecated
and
move
those
repositories.
We
have
external
if
you
see
mixed
up
and
that
helped
a
lot
to
for
the
migration
to
our
beat.