►
From YouTube: Policies and Telemetry WG Meeting - 2020-06-17
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
Okay,
so
I
put
a
bunch
of
stuff
on
the
agenda,
but
I
don't
want
to
dominate
the
discussion.
So
I
wanted
to
start
by
just
opening
the
floor
to
see
if
there
are
anything
that
we
think
we
should
discuss
that
we
aren't
discussing
or
any
items
that
came
up
or
concerns.
We
have
about
the
1-7
release
that
you
should
try
and
talk
about
before
we
dive
into
some
of
the
other.
A
A
C
So
the
TLDR
is
that
for
four
forward
references,
the
the
sidecar
EPA
itself
needs
some
clarifications
because
of
the
because
the
override
semantics
are
somewhat
poorly
defined
because
they
were
never
needed
to
be
more
precisely
defined.
So
we
in
the
inverted
API
we
have
clearer,
override
semantics
right,
you
can
do
canary
and
you
can
specify
configurations
for
specific
filters.
C
If
that
is
move
to
the
side,
car,
then
site
guard
needs
to
have
those
semantics.
So
that's
that
that's
kind
of
one
gateway
attachment
point
actually
works
quite
well.
It
is
straightforward
and
then
virtual
service
is
the
only
other
attachment
point
which
makes
sense
in
a
in
a
limited
sense
of
the.
The
reason
is
so
the
part
that
it
absolutely
makes
sense
is
that
many
times
people
have
a
need
to
attach
behavior
to
certain
paths
right.
C
C
C
So
yes,
so
site
I
mean
all
our
resources
are
kind
of
backwards
in
that
sense,
because
the
sidecar
resource
is
going
to
select
the
workload
that
it
applies
to,
and
in
this
case
the
forward
reference
is
going
to
be
from
the
sidecar
to
the
extension
to
the
extension
manifest
so
I
will
I
will
send
so
I
have
a
I've
kind
of
have
a
rough
thing.
I
was
I,
will
send,
send
it
out,
maybe
tomorrow
and
I.
Think
the
the
other
thing
that
I'm
proposing
is
that
we
have.
C
We
have
a
meeting
of
people
that
are
kind
of
intimately
interested
in
this
as
a
as
a
working
as
a
working
session
and
we'll
make
sure
that
we
we
have
it
at
a
time
that's
convenient
to
to
everyone,
so
I
know
Daniel
and
of
course,
neeraj
and
and
a
few
other
people
are
interested
in
and
then
from
our
side,
Miko
art
and
will
will
be
there.
So
I
think
I
think
that
we
should
book
an
hour.
C
C
C
C
E
A
C
A
C
Up,
actually,
how
about
you,
you
go
to
the
next
one,
while
I
look
at
the
docs
and
okay.
A
C
E
E
F
F
D
A
G
A
A
C
Okay,
so
so
this
so
this,
this
is
this
particular
dock
is
about
like
very
specific,
very
specific
problem,
which
is
what
are
the
different
failure
modes
when
you're
distributing
was
some
extensions
and
more
crucially.
What
does
the
user
do
in
response
to
that
right?
So
this?
So
this
is
somewhat
agnostic
to
what
API
you
used
to
actually
configure
it,
because
it
could
be
on
what
filter
API.
C
It
could
see
the
new
API
that
that
we're
designing
or
it
could
be,
the
telemetry
specific
API,
whichever
whichever
it
is,
but
so
being
able
to
categorize
all
the
modes
of
failure
and
then
giving
the
user
specific
feedback
about
what
is
going
wrong
and
we're
just
enough
so
that
the
user
can
go
back
and
then
look
at
the
logs
and
and
kind
of
do
other
things
right,
so
that
so
it
has.
It
has
a
very
specific
focused
goal,
and
then
we
actually
have
kind
of
catalog
or
different
modes
of
failure.
C
There
are
multiple
ways
that
we're
distributing
the
distributing
bytes
and
actually
now
there
is
a
another
mode
which
at
at
some
point,
quat
will
will
present.
But
and
so
there
are
inline
bytes
where
the
XTS
level
itself
is
pushing
the
whites.
Somehow,
then
there
is
the
URL
fetch
method,
and
then
there
is
the
out-of-band
file
based
delivery,
which
is
like
distributed
file
system
or
a
demon
fetcher,
or
something
like
that,
and
then
the
kinds
of
errors
that
you
can
have
are
I'mme.
Of
course
none
permanently
terror,
so
you
could
not.
C
C
No
I
mean
Tata
timeout
is,
is
the
only
otherwise
it's
the
whole
thing
problem,
but
no
timeout
is
is
the
is
the
only
way
so
I
guess
you
only
know
it
correct.
So
you
only
know
it
after
the
after
timer
saying,
okay,
you
start
with
temporary
error
and
then
after
timeout
you
upgrade
it
to
permanent,
saying,
okay,
I
doesn't
look
like
this
is
going
to
succeed.
C
C
Now
the
interesting
thing
to
note
is
that
with
inline
bytes,
if
you
send
the
bytes
in
line,
then
the
first
two
modes
of
failure-
I,
don't
know
op
because
they
exist
XD.
A
server
itself
is
like
giving
you
the
bytes
and
if
it
doesn't
so
yeah
so
basically
the
first
two
modes
of
failure
are
knobs,
because
just
by
construction,
the
bikes
are
there.
It
could
still
send
you
invalid
bytes
and
the
configuration
could
still
be
wrong.
So
those
are
still
possible.
C
There
so
the
so
I'll
just
kind
of
not
cover
this
part
right
now.
The
and
I'll
just
go
to
URL
fetch.
So
your
fetch,
of
course,
has
the
other
two
moles
of
three
all
right:
you,
you
could
timeout
yeah,
so
you
could
timeout
and
the
error
becomes
permanent
and
file
based
delivery
is
is
somewhat
different.
C
C
It
specifically
does
not
support
eventual
consistency,
so
that's
kind
of
another
part
of
this
proposal,
but
I
don't
actually
well
I'm,
having
second
thoughts
about
that.
So
let's
not
go
there
d.
So
the
main
upshot
of
this
is
providing
a
counter
which
is
dimensioned
by
error,
type
and
filter,
config
name.
C
So
now,
just
by
monitoring
this
metric
right.
So
this
this
will
be
a
Prometheus
MIT
metric.
Let's
say
now
just
by
monitoring
this
metric,
the
user
can
actually
know
so
where
the
error
happened.
So
again,
what
kind
of
error
it
is
and
which
filter
they
need
to
go?
Look
at.
It
won't
give
them
the
error
message
and
all
that,
but
that's
not
the
intent
you,
so
you
should
be
able
to
set
alarms
on
this
thing
right
and
then
with
Prometheus.
C
It
already
tells
you
which
proxy
at
this
error,
so,
for
example,
if
one
of
the
proxies
is
older
version
for
some
reason
and
that's.
Why
that's
why
it
said
API
like
that's
why
it
said
in
the
valid
module,
then
you
would
clearly
know
that
you
will
see
a
counter
that
says:
error
type
invalid
mod
you
going
up
and
it
will
point
to
a
particular
particular
proxy.
C
A
A
C
D
A
C
E
B
C
B
C
C
C
B
E
C
C
F
So
I
spent
all
weekend
trying
to
work
on
something
like
this
and
I
had
a
lot
of
trouble
with
declaring
functions
as
being
external
and
then
wouldn't
read
them
and
I
tried
to
see
if
I
could
come
up
with
some
config
validation.
I
couldn't
I
I,
what's
gonna
be
key,
is
some
kind
of
way
that
a
user
can
tell
what
the
problem
is.
I
I
didn't
realize
that
this
was
going
to
be
presented
today.
C
C
F
So
right
so
I
I
was
using
Waze
me
and
woz
me
sets
up
mounts
and
if
you
screw
it
up,
the
mounts
are
incorrect.
The
push
arrives
it's
rejected
because
the
file
name
is
invalid,
correct
and
what
I
discovered
was
that
Mitch
Conners
distribution
status
was
claiming
that
all
of
the
nodes
had
the
distribution
of
the
filter,
but
it
actually
didn't
have
been
rejected.
So
he's
off
fixing
that
I'm.
F
C
C
F
C
So
I
think
I
think
that
the
the
way
the
wait
way
to
look
at
it,
but
most
definitely
is
that
these
are
all
exceptional
situations
right
and
that's.
Why
metric
as
the
first
line
of
defense
on
that
you
can
set
alerts
and
then
the
alert
will
tell
you
that
there
is
something
going
on
with
this
proxy
or
these
proxies
and
that's
already
specific
enough
for
you
to
go
and
look
at
the
logs
right,
because
this
kind
of
metric
is
telling
you
that
a
particular
proxy
trying
to
load
a
particular
module
and
something
bad
happened.
C
C
F
F
C
Well,
thank
you
actually
I.
Think
that's
I!
Think
that
that's
basically
it
that,
like
that
that
counter,
so
the
proposal
is
that
that
we
implement
that
counter
and
which
is
automatically
scraped
by
Prometheus,
so
we'll
make
sure
that
it's
put
in
the
right
namespace
so
that
it
is
picked
up
by
Prometheus
like
normal
and
then
the
rest
of
the
story
is
we
expose
it
so
CLI
tool
and
or
angriff
on
the
dashboard
yeah.
E
C
C
So
yes,
so
in
so
many
like
many
issues
can
happen
at
at
runtime
and
those
will
show
up
already
in
other
places,
but
but
but
I
but
I,
but
I
agree
that
there
is.
There
is
kind
of
more
runtime
status,
sorry
of
status,
runtime
metrics
as
well
yeah
as
they
pertain
to
the
extension.
So
we
can
actually
have
a
similarly
dimension
thing.
I
can
flick
name
and
that
tracks
tracks.
C
No,
that
should
not
be
possible
simply
because
the
the
Oise
of
VM
actually
abstracts
out
whatever
else
is,
underneath
it
so
yeah,
so
so
that
that
that
should
shouldn't
be
possible
that
there
are.
There
are
certain
other
kinds
of
failures
and
we're
not
very
close
to
getting
them,
but
like
once,
we
have
the
whole
capabilities-based
thing,
whether
you
can
read
from
the
file
system
or
not
right.
So
right
now
there
is
no
ABI
to
read
from
file
system,
but
there
could
be
and.
D
C
May
have
local
policies
that
say
you
cannot
read
from
file
system
and
now
there
is
it.
There
is
an
issue,
but
but
I
think
that
even
in
those
cases
right
again,
these
are
exceptional
circumstances.
So,
in
those
cases
it's
still
important
to
have
an
alert
that
points
user
in
the
approximate
direction
and
then
they
can
then
they
can
pinpoint
using
logs,
ultimately
yeah.
A
C
A
C
B
F
Can
I
ask
about
the
the
runtime
field,
because
I
I
noticed
the
the
the
angry
filters
we
ship
use,
the
run
boy
run
time
envoy,
wasup
run
time
does
null
and
the
ones
made
from
solo,
I/o
or
envoy
Watson
that
run
time.
That
v8
is
that
I
know
that's
not
the
API
version,
but
the
runtime
version
itself.
There
might
be
language
features.
C
The
talk,
v8
is
going
to
be
the
main,
and
the
default
I
mean.
Maybe
the
Volvo
meant
something
like
that,
which
will
come
but
v8
is,
is
the
proper
wasum,
runtime
and
stack
means
like
that
will
be
the
main
thing
no
sandbox
is
used
now,
but
we
will
reduce
the
use
of
it
as
v8
and
then
that
other
pipeline
improves,
so
we
could
potentially
add
the
VM
type
as
a
dimension.
C
A
A
And
I
think
we
have
got
a
lot
of
feedback
now
so
now
I
sort
of
have
to
make
some
tough
deciding
decisions.
So
if
you
take
a
look
at
a
dog,
I
tried
to
capture
all
of
the
parts
in
various
ways
that
we
can
configure
telemetry
in
the
system
today,
and
some
of
the
requests
that
came
in
and
for
issue
is
filed
by
community
users,
and
so
this
is
my
attempt
at
distilling
out
the
set
of
requirements.
A
It's
been
outdated
based
on
some
feedback,
and
so
maybe
we
should
I
just
wanted
to
go
through
them
and
see
if
people
agree.
If
this
is
the
right
set
or
if
they
think
there's
more,
that
should
be
here
or
less
so.
The
first
thing
I
want
to
have
one
way
to
control
telemetry
for
is,
do
I
think
having
to
learn
a
different
way
to
do
tracing
it
differently.
Do
logging
at
point
do
metrics
it's
just
not
the
generally
good
user
experience
and
it
sort
of
leads
to
sort
of
these
fragmented
implementations.
A
A
C
A
A
C
C
A
A
C
F
B
B
C
B
C
C
B
A
A
A
Which
is
just
used
proxy,
config
and
I
think
that
this
invalidates
the
proxy
config,
because
the
feedback
I
get
that
was
getting
was
that
we
want
to
have
it
such
that
you
don't
have
to
restart
the
pods
and
want
this
to
be
dynamic
and
and
go
out,
and
so
I
want
to
make
sure
that
everyone
is
on.
That
thinks
that
that
is
a
worthy
design
goal
on
the
farm.
So
so.
C
B
G
B
B
G
B
C
So
it's
it's
actually
interesting
in
in
in
some
ways.
Yes,
it's
clear
that
the
extensions
the
extension
API
is
an
implementation
of
this,
but
we
should
not
let
the
design
or
the
current
design
of
the
extension
API
influence,
what
we
perceive
as
the
requirements
for
the
telemetry
yeah,
so
so
I
think
that
being
able
to
push
so
Canarian
right.
That's
that's
kind
of
the
bottom
line
you
should
be
able
to.
You
should
be
able
to
canary
changes,
which
also
happens
to
be
a
major
requirement
for
the
extension
API,
but
I
guess
it
also
applies
here.
A
B
D
C
And
the
interesting
thing
is
that
the
way
it
is
set
up
right
now
with
proxy
conflicting
static
at
boot
time
inadvertently
gives
you
that
capability,
because
it
means
that
your
canary
essentially
is
restarting
some
parts
and
that's
your
canary,
but
but
on
water
filter.
Api,
though
the
work,
the
thing
that
we
use
today
to
deliver
telemetry
does
not
have
that
feature
so
to
speak.
It's
like
instant
and
everywhere.
A
C
C
So
if
this
is
implemented
on
top
of
the
extension
API,
then
coexistence
is
solved
just
by
layering.
If
this
is
implemented
directly
in
the
control
plane,
then
we
need
to
make
sure
that
it
coexists
nicely
with
the
extensions
API.
It's
simply
because
the
ways
these
functions
are
actually
delivered
is
still
going
to
be
extensions.
In
many
cases.
A
Yes,
so
yeah
I
was
hoping
that
the
extension
API
would
sort
of
get
to
a
stable
and
approves
station
before
we
try
and
resolve
this,
so
we
could
even
decide
if
this
was
necessary
on
top
of
it
or
how
it
would
fit.
So
maybe
maybe
that's
the
thing,
maybe
we
think
on
this.
While
we
finish
the
extensions
API
so
that
we
can
look
at
how
it
would
layer
or
start
to
design
the
way
right
now-
and
maybe
that's
my
next
dentist
is
to
go
back
and
show
how
this
could
layer
over
the
extensions
again.
Oh.
C
C
So
well,
but
for
mint
from
an
actual
API
perspective.
This
is
what
we
want.
The
users
use
to
configure
telemetry
right,
I
think
that's
that's
kind
of
the
question
so
for
standard
telemetry,
there's
this
API
and
for
anything
else,
that's
more
bespoke.
There's
the
extensions
API
I
think
that
that's
what
we
need
to.
We
need
to
figure
out.
A
A
B
C
A
Okay,
well
thanks
everyone
for
the
feedback
and
please,
if
you
have
more
Adam
to
the
dock,
that'd
be
helpful.
It's
still
a
working
document.
It's
not
a
final
proposal
by
any
stretch
of
the
imagination,
I
just
wanted
to
get
the
conversation
started,
which
we
managed
to
do
and
that's
all
I
really
had.
Is
there
something
else
we
should
talk
about
with
the
last
five
minutes
of
our
time?
So
anything
else,
it's
honest
questions
on
or
is
curious
about
or
wants
to
discuss.