►
From YouTube: Envoy Community Meeting - 2018-01-16
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://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
B
C
C
A
D
E
D
D
D
B
B
D
I
mean
I
I
think
most
of
the
time
people
use.
These
calls,
for
you
know
for
people
in
the
in
the
general
community
to
hop
on
and
ask
questions
so
I
guess
part
of
it
is
maybe
that
we
haven't
done
enough
to
actually
publicize
that
these
meetings
take
place,
so
I
guess
I
could,
because
we
can
send
reminders.
D
You
know
a
couple
days
before
with
the
agenda
doc
to
see
if
people
want
want
to
add
something
it
I
mean
it
does
seem
in
general,
like
most
people
are
comfortable
with
the
with
the
mailing
lists
and
with
em,
with
pr's
and
with
github
and
stuff
like
that,
which
is
honestly
better
for
me
too.
So
I,
don't
I,
don't
know
that
I
personally
cared
that
much.
If
like
no
one
hops
on
and
asks
a
bunch
of
questions,
but
but
you
know
I'm
also
totally
happy
to
answer
them.
Yeah.
B
One
thing
that
I
actually
sort
of
realized
today
would
be
useful
would
be
to
have
a
more
public
notion
of
what
the
on
board
roadmap
is
like.
We
tag
things
for
you
know
the
next
release
and
that's
I
think
that's
that's.
You
do
pretty
conscientiously,
but
I
feel
that
it's
unclear
to
some
people
when
certain
features
will
arrive
with
the
to
do
I
think
we
put
the
API
but
not
actually
SDS
being
from
today.
D
E
D
I
mean
it
like.
That's,
that's!
That's
the
problem
with
this
type
of
work.
You
know
it's
I
can
I
I,
do
try
to
pretty
aggressively
go
through
and
prune.
What's
what's
in
the
next
milestone,
at
least
with
what
I
think
people
are
working
on,
but
I
mean
given
that
at
least
for
me
you
know,
I
mean
I.
I,
do
control
some
resources
here,
but
but
they're
only
a
fraction
of
what
is
what
is
applied
and
then
you
know
I
don't
have
any
control
over
what
anyone
else
works
on.
So
it's
it's!
D
The
other,
the
other
problem,
too,
is-
and
this
is
just
my
personal
experience-
is
I
I,
don't
feel
that
in
general-
and
this
is
not
an
on
book
problem-
this
is
an
industry
problem
that
people
are
very
good
at
estimating
of
when
things
will
actually
arrive.
So
I
mean
saying
that
something
is
going
to
happen
in
cute.
One,
in
my
opinion,
is
almost
meaningless,
so
it's
I.
B
They
make
clear
that
on
their
1.0
before
they
come
over
there,
though
I'm
gonna
have
C++
code
coverage,
I
think
that
unless
they
slip
off
badly
on
that
and
that
do
you
something
no
it's
I'm
not
going
to
expect
anytime
soon,
but
I
should
expected
my
time.
We
hate
that
sort
of
juvenile
suitable
for
no
no
I.
Think
I
can
ask
the
yesterday
maybe
will
only
arrive
in
a
minute
envoy
5.0.
You
know
yeah.
D
The
moment
the
only
pushback
that
I
would
give
to
that-
and
this
is
my
personal
opinion,
so
you
can
take
it
with
a
with
a
grain
of
salt-
is
I
feel
that
there
are
basically
two
types
of
open-source
there's
corporate
driven
open-source
and
then
there's
basically
community
driven
open-source
and
even
though
envoy
has
a
ton
of
money
being
thrown
into
it.
I
would
actually
put
it
in
the
community
driven
open-source
model
like
there's.
D
Not
a
corporate
backer
basil
is
corporate
open-source
and
and
in
the
sense
that
it's
being
driven
by
by
Google,
primarily
and
there's
plenty
of
other
examples
like
that,
so
the
only
the
only
the
only
reason
that
I
bring
that
up
is
that
I
feel
like
in
corporate
up
and
source,
like
versions
have
much
more
meaning
like
people
are
saying,
you
know
it's
like
we're,
gonna
have
a
1.0,
and
then
it's
gonna
do
this
and
it's
gonna
be
a
product
or
something
like
that
and
I.
Don't
know
I,
just
don't
I.
E
D
I'm
I'm
not
really
pushing
back
in
the
sense
that,
like
I,
think
having
a
roadmap
is
great
part
of
the
problem,
and
this
is
something
that
I
that
I
struggle
with
is
github
is
not
great
for
road
mapping.
Right
I
mean
it's
like
you.
Have
it
I
mean
it
is
title
like
you
have
milestones,
but
it's
it's
it's
very
hard
to
have
a
clear
thing
of.
What's
going
on.
You
know.
B
D
Sdos
corpora
open
source,
so
III
mean
I
I,
just
like
it's
sto
has
program
managers.
It's
do
has
like
product
managers
right,
I
mean
I,
just
like
we
don't
have
those
resources
so
I'm
not
saying
that
this
is
not
a
good
idea
like
we
can
have
a
doc
and
I
would
be
more
than
happy
to
have
a
place
where
you
know.
Maybe
it's
Google
Doc,
maybe
spreadsheet.
We
can
talk
about
what
makes
sense
and
for
high-level
features.
We
can
drag
and
drop
them
into.
You
know
different
releases
depending
on
you
know.
D
If
we
assume
that
releases
are
every
three
months
and
the
people
find
that
interesting.
That's
totally
fine,
like
that
sounds
great
to
me.
I'm
just
worried
that
people
are
gonna.
Look
at
that
and
then
it's
not
gonna
get
implemented.
Then
people
are
gonna,
be
like
what
well
you
said
it
was
on
the
road
back,
so
I
I,
don't
know
it
just
it
just
feels
like
it
feels
like
it
might
a
if
you
like
it's
useful,
but
it
also
might
come
back
to
bite
us.
That's
all.
B
D
B
We
lot
of
things
have
gone
into
the
api's
and
then
being
tagged,
not
implemented
high
grades
or
draft
status,
and
it's
unclear
really
when
they're
actually
gonna
happen.
Mm-Hmm
that's
I
mean
the
actual
docks
that
people
see
you.
We
do
a
good
job
of
hiding
that
stuff,
which
isn't
really
you
know
firmly.
B
D
I
mean
there's
we've
in
in
the
beginning
of
the
proto's
I
I
think
it
was
a
little
I,
don't
want
to
say
out
of
control,
but
people
were
just
adding
things
that
we
might
one
day
want
to
implement.
Hey
I
think
we've
actually
done
a
pretty
good
job
at
this
point
of
either
telling
people
like
you
can
add
it
when
you're
gonna
implement
it,
so
don't
don't
want
it
and
we've
got
not
implemented
hi
tag
now,
so
it
actually
is
a
lot
more
clear
when
things
are
not
implemented.
D
D
So
I
you
know,
I
I
tend
to
agree
that
like
we
could
but
but
here's
the
problem
is
that
you
know
if
we
go
and
we
make
a
spreadsheet
like
let's
say:
let's
say
we
do
a
spreadsheet.
That
seems
like
the
most
cheap
way
of
doing
the
road
map
and
let's
say
that
we
arbitrarily
say
that
releases
or
every
three
months
we
could
go
to
the
not
implemented
high
things
and
say
you
know
it's
gonna
get
implemented
in
version,
one
point
acts,
but
then
when
no
one
does
that,
then
we
have
to
go
through
and.
D
So
okay
I
mean
one
one
way
of
doing
it
might
be,
it
might
be.
Scalable
is
how
about
this.
This
sounds
like
potentially
a
good
idea.
What,
if,
when
someone
adds
something
to
proto
and
they
put
a
not
implemented
hide
in
what
if
we
make
them
put
a
github
issue
ID
in
there,
so
basically
everything
that
is
not
implement.
It
must
have
an
issue,
that's
tracking
it,
so
that
when
we're
looking
through
the
proto's,
they
can
just
see
like
it's
either
in
a
milestone.
It's
not
in
a
milestone.
D
E
F
D
F
We
it
actually
asks
for
your
github
ID
and
I
don't
pass
word.
It
can
read
your
github
history,
but
we've
been
using
it.
So
it's
a
bit
tricky
I,
don't
want
to
recommend
it
in
particular,
okay,
but
what
I
do
want
to
recommend
is
having
like
tracking
the
features
in
github,
so
people
can
comment
and
add
to
them.
Sometimes
it's
they're
hard
to
find
in
a
spreadsheet.
You
know
yeah.
D
I
mean
that's,
that's
my
that's
my
feeling
also,
which
is
why
I've
pushed
back
before,
unlike
spreadsheets
or
Docs,
so
I
I
think
we
can
be
better
about
going
through
and
doing
milestones
and
historically,
you
know
that's
just
something
that
I
have
done
because
I'm
kind
of
OCD
and
I
like
things
to
be
organized.
So
that's
something
that
you
know
we
can
spread
around
more
if
other
passionate
OCD
people
like
to
keep
things
clean.
If
that
is
you,
you
can
talk
to
me
and
put
up
that
work.
D
D
Okay,
cool
yeah,
that
sounds
great
I,
mean
I,
think
I
think
there's
a
there's.
A
meta
conversation
here,
kind
of
about
about
releases
and
I-
get
asked
this
quite
a
bit
by
people
so
historically
for
envoy,
you
know:
most
people
I
think
that
are
running
envoy
are
kind
of
stereotypical,
larger
internet
companies
that
tend
to
be
used
to
doing
continuous
deployment.
Roughly
so
people
are
mostly
running
master.
A
lot
of
people
are
not
comfortable
with
that.
So
I
I
get
a
lot
of
questions
around.
D
You
know,
gonna
be
in
a
numbered
release
or
you
know.
If
bugs
are
found,
are
you
gonna
do
dahm
releases
and
so
far,
mostly
because
we
just
don't
have
resources
and
and
at
lift
we
don't
care
at
Google
I
doubt
you
care
I
mean
it's
like
most
most
larger
companies
don't
care,
we
all
tend
to
run
master.
There
hasn't
been
resources,
for
you
know
like
maintaining
dot
releases
and
like
doing
doing
those
types
of
releases.
D
So,
there's
a
larger,
long-term
question
as
to
whether
you
know
we
need
to
do
kind
of
more
official
release,
Cadence's
where
we
do
like
with
these
candidates,
and
then
you
know:
if
a
bug
is
of
sufficient
badness,
we
would
do
a
dot
release
or
something
like
that,
and
it's
not
that
we
couldn't
do
that
today.
It's
just
that.
You
know
that
just
requires
yet
more
resources
which
which
we
don't
have
so
I'm
just
curious.
B
D
I
mean
I
think
we
could
well
I
I.
Think
so.
I
think
there's
two
things:
I
I
think
the
best
practices
are
pretty
well
known,
it's
more
of
a
resourcing
problem,
just
in
the
sense
that
you
know
I
think
we
can
build
a
policy
like
we
could
actually
go
through
and
we
can
do
release
candidate
drops
for
some
period
of
time
and
ask
people
to
test,
and
then
we
can
do
dot
releases
if
there's
bugs
found,
but.
E
D
Ya
know:
I
think
there
isn't
it
I
think
there
is
an
issue
actually
for
doing
for
doing
like
da
burly.
He
says
and
stuff
like
that,
but
I
can
I
can
look
and
then
track
it.
So
I
just
want
to
throw
it
out
there.
I,
don't
think
it's
something
that
we
have
to
decide
right
now,
but
that
that
is
a
that
is
a
thing.
I've
heard
is
that
people
are
not
necessarily
comfortable
running
master
and
they
want
more
official
releases,
but
that's
just
not
something
that
I
personally
have
resources
for
I
I.
F
There
is
significant
amount
of
work
in
supporting
multiple
versions,
especially
when
it
comes
to
test
infrastructure
and
all
the
rest.
So
even
in
East
yo
wid,
we
have
like
a
monthly
release.
Now
we
switch
for
quarterly
release
to
a
monthly,
but
we
do
not
plan
to
support
all
the
intermediate
versions
right
because
if
it
keeps
like
forking
and
diverging
they're
either
there
is,
there
is
a
toll
on
the
team,
so
we're
gonna
support,
mostly
like
the
latest
or
the
two
previous
released
versions.
F
Not
everything
right,
and
this
also
like
it
becomes
an
issue
with
who's
using
the
version
right
and
how
critical
is
the
bug
that
needs
to
be
double
committed
in
a
particular
version.
So
it's
a
whole
machinery
that
becomes
necessary
when
you
move
from
using
the
master
to
having
like
supporting
different
versions.
Don't
take
it
lightly.
It's
just
you
know
and
advice,
yeah.
D
D
Yeah
I
mean
I,
I,
guess
the
the
difference
is
that
you
know
like
when
we,
when
we
ship
1.5,
we
found
that
there
is
a,
but
so
this
is
actually
a
great
example.
We
found
that
there
was
a
few
bugs
in
terms
of
we
weren't.
You
know
we
weren't
parsing
the
proto
schema
correctly
or
there
was
a
few
cases
of
configs
that
basically
weren't
being
cached
and
I.
D
Think
in
historical
kind
of
software
practices,
someone
that
was
doing
a
shrink,
wrap
software
would
have
done
a
1.5
dot
one,
basically,
what
those
couple
of
fixes
and-
and
we
didn't-
because
we
don't
have
the
resources
to
to
do
that
so
I-
bring
that
up.
Just
because
I
think
there's
there's
a
difference
between
like
like
a
severe
security
bug,
which
I
do
think
that
we'd
have
to
go
back
and
basically
patch,
but
you
know
and
kind
of
like
a
random
bug,
or
you
can
just
say.
Well,
it's
been
fixed
to
master.
D
Yes,
yeah
I
think
that's
I,
think
that's
totally
reasonable
and
I
I
think
that's
in
general.
The
stance
that
I've
taken
so
far,
which
is
you
know
we
we
are
community
driven
like
in
in
as
much
as
I,
would
love
to
provide
everything.
You
know
that
people
want
we're,
not
running
a
business,
so
it's
like
can't
really
justify
that.
D
So
I
think
if
people
want
these
things,
I
think
someone's
gonna
have
to
step
up
and,
as
was
said
before,
doing
doing,
release
management
like
if
you
look
at
what
you
know
GRP
see
and
what
like
protobuf
does
just
as
an
example
of
like
cutting
our
seas
and
like
those
kinds
of
things
it's
a
very
non
non-trivial
cost.
So
we
would
need
someone
to
step
up
like
an
actual
release
manager
to
to
go
and
do
that.
D
D
All
right
so
I
think
the
concrete
actions
are
going
to
be
so
we'll
we'll
do
something
in
a
data
point
API,
where
features
are
not
implemented,
will
force
people
to
put
in
a
github
issue
for
tracking
I.
Think
that's
great
I
will
set
up
some
type
of
calendar
reminder
so
that
maybe
like
the
Friday
before
the
community
meeting,
we
send
out
a
reminder,
email
and
ask
people
to
reply
back
with
things
that
they
might
want
to
put
on
on
the
agenda
just
so
that
we
make
sure
that
people
are.