►
From YouTube: Policies and Telemetry WG Meeting - 2020-07-29
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Everyone
thanks
for
coming.
There
wasn't
a
lot
on
the
agenda
today,
so
thought
I'd
start
by
once
again
asking
if
there's
anything
that
anyone
thinks
we
should
discuss
or
want
to
discuss,
or
we
should
use
this
meeting,
for
I
can
add
it
to
the
agenda
or
you
can
just
mention
it
now
and
I'll
update.
A
Notes:
okay!
Well,
I'm
sorry
to
put
you
on
the
spot,
but
I
thought
that
maybe
you
could
provide
some
updates
on
the
work
you've
been
doing
for
extensions
config
and
how
we
might
be
using
that
moving
forward.
B
B
That
means,
if
you
want
to
change
some
configuration
in
telemetry,
for
example,
the
update
will
be
localized
to
the
extension
that
implements
telemetry
and
that
and
it
will
not
cause
any
drainage
or
disruption
to
the
networking
it
also
it's
it's
basically
not
the
xds
specifically
for
extensions.
So
that's
the
general
and
our
plan
of
it
is
to
use
it
to
ship
awesome
plugins.
So
we
can
load
modules
dynamically
using
this
service,
and
that
means
you
can
also
ship
code
as
an
option
using
the
service.
C
And-
and
the
other
thing
to
note,
is
that
the
way
to
ship
wasm
bits
is
still
orthogonal
to
this
particular
process.
So
so
we
can
still
choose
the
three
different
options
that
we
have
to
write
three
different
options
that
we
have
orthogonally
to
how
the
extension
config
is
shipped,
which
which
gives
us
a
lot
of
flexibility
in
in
deciding
under
what
circumstances.
B
C
B
So
I
think
it
depends
what
kind
of
model
you
want
to
ship
if
it's
substantial
module,
then
this
probably
shouldn't
be
shipped
via
this
service.
But
if
it's
a
small
like
script,
10
lines,
it
makes
a
lot
of
sense
to
use
this
service
and
there's
also
like
a
provisions
to
deal
with
the
warming.
So
when
you,
when
it
takes
time
to
load
the
module,
it
will
await
until
things
are
ready.
So
that's
the
benefit
of
minimizing
disruption.
B
A
Okay
and
just
in
case
people
were
looking
to
try
this
out.
Do
we
have
a
reference,
implementation
or
framework
that
we
could
use
for
that,
or
is
that
still
in
development.
B
B
Every
time
you
change
any
information
config,
which
is
not
always
what
you
want
for
http
traffic,
and
so
it
could
be
used
there,
but
we
need
a
good
design
because
it
I
mean,
if,
once
you
come
to
shipping
binaries,
it
changes
the
workload
and
pilot
and
we
have
to
make
sure
it's
done
right.
B
B
C
Envoy,
and-
and
so
so
I
guess
the
the
related
question
is
that
the
lookup
is
by
name
correct.
The
lookup
is
by
a
config
name,
yes,
which,
which
means
that
that
name
differs
slightly
from
the
semantic
names
that
we
have
been
using.
So,
for
example,
we
use
steroid
stats
to
mean
like
an
abstract
notion
of
stats,
but
we
actually
apply
different
configurations
to
stats
based
on
whether
we
deliver
it
to
ingress
or
a
site
car.
So
I
think
that
that
that
will
also
have
to
be
taken
into
account.
B
I
mean
you
can
always
scope
it
by
proxies
right,
so
it
could
be
same
name
resource
that
is
not
the
same
across
different
proxies.
A
So
the
related
question
is,
I
know
that
I
saw
that
config
dump
was
not
yet
implemented
or
coming.
How
do
we
debug
extensions
and
find
out
which
versions
of
these
configs
they
have
when
they're
running.
B
There's
a
result
of
stats
implemented,
so
it's
it's
it's
just
another
xds,
so
the
standard
xcs
metrics
apply
and
it's
the
config
reload
set
stat
that
allows
you
to
monitor,
updates
the
config
dom
is
was
not
never
always
reliable
in
any
way.
It's
not
never
actual
truth.
So
you
should
always
kind
of
assume
some
kind
of
approximation,
but
we
should.
B
B
C
C
It
will
it
will
be
sent
out
shortly,
though,
within
within
the
next
couple
of
days,
I'll
send
out
the
supportable
onward
filter.
C
E
F
Yeah,
I
have
an
update
on
one
of
the
issues.
Let
me
think
there,
so
it's
about
exposing
more
our
stats,
so
I
think
there
will
be
like
so.
Basically
the
easiest
track,
some
experiment.
F
I
did
and
see
whether
if
it
is
possible
to
expose
more
and
with
that
currently
we
are
omitting
the
listener
and
cluster
related
stats
due
to
the
performance
easier
that
we
run
into
back
to
one
zero
one
one,
and
this
issue
is
to
see
how
much
improvement
that
performance
wide
and
what
has
made
on
stats
and
see
whether
we
can
enable
them
enable
other
stats
or
more
stats
by
default
and
the
experiment.
F
I
did
shows
that
like
for
for
a
gateway
kind
of
proxy,
if
we
install
like
200
clusters,
there,
cpu
and
memory
usage
is
still
not
looking
good,
it
could
be
out
of
it
for
like
two
twenty
or
thirty
percent
sa
car,
like
we're
like
not
not
that
many
cluster
sizes,
not
cpu
usage,
are
looks
a
bit
better
than
gateway
is
less
than
10,
but
the
memory
like
a
part
of
it
might
because
we
are
sending
less
requests
per.
F
F
So
I
think,
like
the
conclusion
I
have
is
that
it's
still
not
very,
very
good
or
very
appropriate
to
turn
on
all
the
stats.
So
we
still
need
to
use
whitelist-based
approach
to
expose
stats
that
we
just.
We
think
that
would
be
useful
or
very
important
for
debugging.
F
I'm
not
sure
whether
there
are
some
other
opinions
from
this
group,
or
should
we
cast
out
away
folks
whether
this
result
is
expected
or
do
we
need
to
generate
some
profiling?
I.
D
C
C
Yeah,
so
we
we
need
right,
so
I
think
I
think
that
clearly
envoy
has
made
progress,
but
from
your
experiment,
it's
not
enough,
but
if
someone
wants
more
metrics
across
the
mesh,
then
we
just
don't
give
them
enough.
Give
them
an
easy
way
to
do
it
at
all
today.
So
so
I
think
that
that
would
at
least
enable
experimentation
and
put
the
control
back
in
terms
of
users,
but
in
terms
of
which
other
metrics
we
want.
I
think
we
should
be
able
to
come
up.
C
We
should
be
able
to
come
up
with
a
budget
and
say
we
have
room
for
like
whatever
five
ten
more
metrics
and
then
and
then
just
get
those
important
ones
in.
F
C
I
think
I
think
per
cluster
metrics,
but
just
a
few,
not
all
right
like
you.
If
you
turn
on
cluster,
you
get
like
all
whatever
30
50,
some
large
number.
So
if
we,
if
we
can
just
say
that
hey
in
in
a
cluster
we
just
are,
we
just
think
that
these
two
are
the
top
most
important.
Then
that
could
be.
I
think,
that's
a
good
starting
point.
Yes,.
G
Have
you
also
looked
at
prometheus
memory,
cpu.
F
Yeah
yeah,
if
I
turn
on
us,
that's
promises.
It's
not
looking
good,
so
so,
okay
yeah,
I
mean
like
if,
if
eventually
we're
going
to
turn
our
stats,
that
then
we
need
to
make
it
very
clear
that
promises
need
to
ignore
those
some
metrics
during
scripting.
So.
F
Yeah
I
mean
at
sidecar,
we
exposed
xds
stats.
Already,
it's
not
expensive,
but
the
expensive
part
is
the
asset
only
available
at
sidecar,
like
the
cluster
etc.
Yeah.
G
C
F
Yeah,
that
is
the
update
for
this.
I
like
I,
can
definitely
pin
android
for
more
to
get
more
insight
into
this.
I'm
gonna
follow
up
in
the
next
working
group
meeting
yeah.
E
Just
out
of
curiosity
and
sorry
to
bargain,
but
what
is
the
primary
driver
for
cost
outside
of
volume?
I
I
so
yes,
there's
there's
a
certain
amount
of
volume
for
logs
and
assuming
that
they're
going
to
go
and
log
everything
they
can
log.
What
is
the
primary
factor
that
drives
cost.
F
C
No,
so
so
yeah
so
cost
on
the
proxy
is
is
kind
of
the
most
important
part
because
it
gets
multiplied
by
the
size
of
the
mesh
and
then
cost
that
is
imposed
on
the
telemetry
system,
which
is
prometheus
or
like
stackdriver
or
whatever
else
is
the
it's
like.
The
second
consideration.
E
C
H
I
mean
there
is
downstream
cost
right
once
you've
collected
it,
there's,
storage
and
and
if
you're,
aggregating
and
number
you
know
that
that
all
falls
out
the
more
stuff
that
you
collect,
obviously
the
more
stuff
more
space.
It's
going
to
take
the
more
time
series
you
have
the
slower
quarries
are
going
to
be,
I
mean,
there's
a
huge
amount
of
cost.
Actually
you
know
resource
wise,
especially
if
you're
collecting
things
that
aren't
used
in
any
way.
E
Is
there?
Is
there
an
upper
upper
bound
to
that
cost?
If,
if
I
am
logging,
everything
that
I
can
log,
is
there
an
upper
bound
for
that
resource
consumption
and
do
we
know
what
that
upper
bound
is?
Is
it
is
it
something
like
millicourse
or
so
and
so
gigabytes
of
ram,
or
is
that.
H
D
You
can
keep
on
adding
workers
and
I've
seen
envoy
up
to
like
six
gigabytes
of
ram.
If
you
really
want
to
throw
a
lot
of
stuff
at
it.
So.
A
A
Okay,
peter
did
you,
do
you
want
to
mention
anything
else
or
do
you
think
we've
covered.
H
That
the
only
other
comment
I'd
make
is
instead
of
upper
bound.
I
think
it's
lower
bound.
That's
a
little
more
interesting.
You
know
how
much,
how
many
resources
are
you
using
just
to
do
minimal
amounts
of
things,
and
I
don't
know
what
the
answer
is
there,
but
you
obviously
want
it
to
be
as
low
as
it
can
be.
G
I'm
just
curious,
I
know,
link
rd
uses
like
a
very
low
amount
of
memory
in
the
side
cars
do
they
do
that
because
they
have
less
stats
or
they
just
have
a
more
efficient
stats.
Implementation.
C
C
Okay,
so
the
stats
is
kind
of
the
secondary
part,
and
the
other
thing
is
the
cardinality
of
on-voice.
Stats
is
actually
somewhat
bounded.
It
is
actually
bounded
because
it's
not
it
doesn't
have
the
configurability
that
is
geostats
have
which
can
lead
to
cardinality
explosion.
So
so
we
so
there.
So
it's
quite
predictable
and
well
known,
like
once,
you
add
a
cluster,
you
get
these
20
things
and
that's
it.
You
just
get
those
20
things.
I
A
quick
question
here
so
the
onward
level
stats.
I
mean,
I
see
the
issue
filed
by
peter,
I
think,
are
they
actually
being
asked
by
customers
or
is
it
something
that
istio
devs,
who
are
very
familiar
with
proxycrave.
C
And
some
of
them
have
equivalent
in
istio
stacks
and
some
of
them
don't,
but
like
that,
that's
the
only
time
that
I
have
turned
them
on
just
because
they're
debugging.
Now
there
are
certain
like
downstream
stats
and
like
some,
some
other
stats,
which
we
just
don't
have
exact
equivalence
and
people
do
turn
them
on
using
the
annotations.
A
As
if,
if
we're
only
using
it
for
debugging,
it
would
be
interesting
if
we
could
have
just
sort
of
a
like
debug
mode
right
or
some
way
I
mean
that's
you're,
getting
an
easy
way
to
turn
on
additional
metrics
mesh
y.
But
it
sounds
like
we
don't
want
to
do
this
on
a
consistent
basis
all
the
time,
but
we
want
to
turn
it
on
for
the
30
minutes
that
we're
looking
at
right
and
then
be
able
to
easily
switch
it
back
off.
I
Yeah
and
additionally,
I
was
thinking,
can
steer
ctl
do
something
here
I
mean
if
you
have
to
look
at
time
series
data
over
a
long
time,
there's
limited
value.
That
is
maybe
these
limited
values
qctl
can
provide,
but
if
it
is
just
for
interim
debugging
for
like
30
40
minutes,
I'm
just
throwing
ideas
out
there
so
that
we
can
avoid
the
impact
globally
but
still
provide
these
metrics
when
the
time
it
comes
right.
F
So
that
requires
a
proxy
restart
right.
If
you
want
to
expose
one
stats
that
the
stats
configuration
is
input
strap
right
now
right,
so
I
think
restart
will
make
it
not
very
useful
to
provide
debugging
signals
in
some
cases
it
will
make
it
pause.
Debug
signal.
C
So
so
that
so
I
think
the
the
work
that
actually
peter
and
then
someone
else
is
doing
to
get
to
connect
the
sandbox
stack
system
to
an
alternate
stat
system
like
open,
sensors
right,
but
once
once
we
have
that
fully
baked
in,
we
should
be
able
to
go
back
with
some
more
data
and
conviction
to
the
envoy
community
and
say:
okay,
can
you
can
you
add
this
and
not
have
everything
in
the
bootstrap
yeah
like
that?
That
will
that
will
be
the
first
step
so.
C
Open
sensors
is
definitely
efficient.
I
I
don't
know
about
more
or
less
so,
if
you,
if
you
look
at
so,
we
use
open
sensors
for
stackdriver
and
in
in
like
measurements.
If
you
see
the
stackdriver
measurement,
which
directly
uses
open
sensors
and
sends
it
out,
is
basically
the
same
cost
as
stat
system
which
well,
which
uses
onwards
native
pipeline.
C
C
Okay,
so
there
is,
there
is
one
I
I'm
just
looking
for.
So
there
is
an
issue
that
doug
has
opened
for
for
some
time
about
updating
the
grafana
dashboard
with
some
some
of
the
newly
created
wasm
stats,
and
I'm
just
looking
for
someone
who
is
able
and
willing
to
do
that.
C
A
Okay,
I
did
have
some
other
updates.
I
mean
like
we
should
probably
just
talk
about
for
a
second
here,
the
big
one
being
the
mixer
is
now
gone
from
the
code
base.
A
And
there's
a
shim,
the
the
grpc
shim
is
sort
of
a
bad
name,
for
it
is
being
developed
against
the
one
seven
code
base.
A
And
I
think
right
now,
the
biggest
thing
left
is
developing
an
integration
test
around
the
functionality.
So
I
think
it's
almost
ready
to
go.
A
So
if
anyone
is
still,
you
know
interested
in
the
grpc
adapters
for
mixer
and
testing
them
with
envoy
x,
off
or
access
log
service,
you
should
have
something
in
a
week
or
two
that
will
allow
a
lot
doing
that
with
one
seven
and
then
we'll
need
to
develop
the
docs
for
how
to
use
that
in
one
eight,
if
you
still
don't
want
to
transition,
you
you're
out
of
process
adapters.
A
So
I
just
wanted
to
share
that
that
update.
If
you
see
anything
I
mean
this
relates
to
the
dashboard
updates
and
other
stuff,
there's
still
probably
small
vestiges
of
mixer
left
in
the
1
8
code
base.
So
if
you
see
anything
anywhere
that
still
references,
it
it'd
be
a
good
time
to
go
ahead
and
just
clean
that
up
as
you're
working
through.
A
So
I
did
want
to
mention
that,
and
that
also
thanks,
ed
and
others
who
added
the
deprecation
and
detection
tools
for
one
seven.
I
think
that's
gonna
be
super
useful
as
well.
That's
a
big
part
of
being
able
to
remove
mixers.
So
thank
you
for
that
work.
A
A
There's
been
a
number
of
open
issues
where
metadata
exchange
has
failed
for
some
some
reason,
maybe
maybe
errors
you
know,
maybe
calls
coming
from
out
of
metric
going
out
of
mesh,
and
so
I
didn't
know
if
anyone
had
done
any
concrete
thinking
about
that
or
advanced
it.
I
know
niraj
and
jacob.
You
guys
have
looked
at
that
a
little
bit.
I
don't
know
if
we
have
any
good
thoughts
there
or
are
thinking
has
advanced
on
how
to
do
meditative
discovery.
C
So
so
I
think
the
the
prioritization
like
deciding
the
priority
is
is
one
of
the
it's
not
exactly
the
same,
but
I
think
we
have
to
agree
on
on
the
priority.
What
I
think
what
happened
last
time
was,
even
though
we
did
agree
it.
It
wasn't
really
a
form
agreement
right
because
we
weren't
willing
to
put
any
effort
into
it
like
we
as
in
we
as
google
did
not,
and
neither
did
nirich
and
and
his
his
team.
So
we
we
really
need
a
consensus
on
priority
like
that
and
yeah.
C
So
so
I'm
I'm
not
I'm
not
commenting
on
like
design
or
technology,
or
anything
like
that
here.
I
think,
but
I'm
just
saying.
C
A
That's
a
good
point,
I
guess
maybe
it's
just
like
sort
of
the
bias
on
the
issues
I've
seen,
but
it
does
seem
like
it
keeps
coming
up
in
more
and
more
scenarios
like
there's,
you
know
different
conditions
under
which
this
you
know
the
exchange
fails
more
than
just
being
out
of
mesh,
so
seems
to
me
that
we're
finding
more
and
more
edge
cases
now
in
which
something
like
this
would
be
useful.
A
Right,
I
mean,
I
think,
that's
fair.
This
is
coming
in
cases
where
things
fail,
but
the
number
of
reports
of
those
seem
to
have
gone
up.
A
C
If
we
had,
if
we
had
a
solution,
that
was
already
ready,
would,
and
so
would
it
be
a
better
solution
that
so
at
which
point
we
can
just
switch
off
metadata
exchange
right,
we
can
say:
okay,
fine,
we
don't.
We
don't
need
it,
because
this
service
is
so
reliable
and
so
good
that,
like
we
just
don't
need
it
it.
C
C
If
it
does
turn
out
to
be
strictly
better,
then,
like,
I
would
say,
we
would
be
able
to
put
more
resources
behind
it
right.
It's
not.
A
C
C
C
B
A
Okay-
okay,
I
just
wanted
to
raise
this
and
and
have
it
reach
sort
of
the
group
consciousness
is
something
we
should
look
at.
I
think
for
one
eight
figure
out
what
we
want
to
do
there.
A
Are
there
other
topics,
other
things
that
we
should
discuss
this
week?
I
don't,
I
don't
know
a
lot
of
other
updates
from
just
been
ongoing.