►
From YouTube: Policies and Telemetry WG Meeting - 2020-04-08
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
Basically
to
go
through
where
we
are
are
the
things
that
we
do
because
I
think
we're
wavy,
how
I've
done
a
lot
of
things,
so
I
wanna
do
a
recalibration
and
see
what
we're
actually
gonna
get
done.
But
if
there's
anything
else,
anyone
wants
to
talk
about
first,
maybe
we
should
do
that.
Is
there
anyone
anyone
out
there
that
wants
to
talk
about
something
before
we
start
going
through
our
work
items
I.
B
B
E
B
C
A
B
F
A
B
So
what
was
them?
Okay,
so
was
distribution.
B
So
was,
distribution
is
a
is
a
p0,
and
actually
there
is
a
cache,
so
gassing
remote
fetcher
will
be
implemented,
and
that's
that
is
expected
for
1.6,
and
once
we
have
a
caching,
remote
fetcher,
we
can
for
any
sort
of
reasonable
distributed
any
sort
of
reasonable
installation.
We
can
just
use
the
caching
remote
fetcher,
along
with
putting
extensions
in
putting
extensions
inside
the
container,
so
we'll
have
we'll
have
both
sides
reasonably
covered
right.
B
E
B
So
the
API
is
already
there.
In
fact,
we
can
already
use
it.
The
issue
is
that
it's
not
reliable
because
it
doesn't
do.
Caching-
and
the
work
item
here
is
to
add
a
cache
in
front
of
that.
So
not
every
listener
fetches
its
own
extension,
it
just
treach's
it
once
and
and
stuff.
Oh
we
so
we
need
to
document
them.
That's
so
so
I
guess
all
your
questions
were
regarding
that.
So
we
will
beam
into
document
on
document
how
to
use
it.
B
F
E
F
A
A
When
we
had
when
we
were
using
mixer,
we
added
some
stuff
to
the
Prometheus
adapter,
that
after
10
minutes,
if
there
was
a
particular
combination
of
like
say
service,
say
attacking
a
service
B
and
that
hadn't
happened
for
10
minutes,
we
dropped
that
we
removed
those
metrics
from
the
mixer,
so
they
weren't
continuing
to
get
reported.
That
functionality
does
not
exist
in
the
Envoy
based
extensions.
So
once
you
once
you
record
an
event
it
you
continue
to
report
it,
albeit
at
a
0-0
Delta
for
for
forever.
A
G
B
G
B
Right
right
so
do
we
do
we
want
to
keep
it
be
zero
or
not
or
not?
And
okay,
so
the
same
thing
for
stackdriver
is
completely
different,
though
okay,
that's
right,
because
that
goes
to
open
senses.
So
the
so
the
question
is:
do
is
to
keep
it
as
be
zero.
I
think
there
is
plenty
of
other
piece,
eros
I
agree,
so.
E
Guess
we're
back
so
swag
driver
goes
through
open
senses,
which
means
there
is
an
open
sensors
collector,
which
can
do
these
type
of
things
in
that
model,
is
the
open
census
collected
and
not
considered
equivalent
of
a
mixer
as
an
is
it,
that
is
that
not
going
to
be
the
same
resource
resource
hog
or
people
are
okay
with
that
kind
of
deployments?
So.
G
E
G
A
D
Good
Jacob,
yeah
well
kind
of
based
on
the
email
that
was
going
around
it
being
a
first
class
API
I
guess
is,
is
or
you
know,
part
of
the
extensions
API
or
telemetry
API.
D
If
you
know,
if
it's
not
gonna
fit
the
extensions,
that's
gonna
be
a
work
in
progress,
so
so
kind
of
the
support
that
is
intended
that
I'm
working
on
right
now
actually
is
to
add
an
annotation
probably
to
this
sidecar
API
I'm,
guessing
I
still
need
to
kind
of
figure
out
where
it
is
I'm
gonna,
be
kind
of
adding
this
support
for
an
annotation
and
then
putting
it
in,
but
I
believe
it's
on
track.
Yes,.
E
D
E
G
Think
is
completely
separate,
like
I'm,
not
sure
whether
Kyary
folks
only
cause
I
CJ
but
I.
Think
it's
about
like
worship,
service
and
destiny
or
like
how
can
we
get
that
piece
of
information
into
matrix?
I
haven't
looked
more
deep
into
the
requirements,
but
yeah
we
can
think.
Maybe
I
can
see,
see
you
on
bug
on
the
issue
and
we
can
discuss
there
if
you
interested
okay,
yeah.
I
I
So
if
workload,
a
requests,
workload,
B
or
sorry
service,
B,
but
then
a
virtual
service
steps
in
and
redirects
it
somewhere
else.
Today
we
get
that
redirect
right,
we
at
the
final
destination,
but
we
don't
know
what
the
original
request
was,
and
so
that's
what
we're
looking
for,
so
that
we
can
try
to
visualize
where
that
rerouting
takes
place.
I.
A
E
E
I
G
E
E
Yeah
they
were
trying
to
so
because
of
the
time
zone
issues
they
weren't
able
to
attend
our
meetings,
but
they
were.
They
told
me
that
they
were
going
to
submit
a
PR
in
Sto
because
they
had
fixed
this
for
their
operator.
They
were
passing
the
trust
information
down.
We
should
see
if
any
one
of
them
are
willing
to
contribute
there,
but
again
that
might
be
for
v1
I.
Don't
think
they
have
anything
for
me
to
at
least
yeah.
A
E
B
D
B
E
From
networking
working
group,
I
can
say
four
one:
six
our
priority
for
better
transports,
the
Better,
Transport,
Security
or
better
transport
is
getting
a
demo
done
for
one
six,
so
I
think
it
looks
like
once
after
the
demo
is
done,
and
we
have
reasonable
confidence
that
we
can
make
it
work.
Networking
and
policy
should
sync
up
so
you're
correct
after
one
six.
Only
oh.
F
G
G
E
D
E
E
A
C
A
A
E
A
B
You
know
so:
okay,
networking
doesn't
so
networking
does
use
downstream
protocol,
but
we
don't
put
what
we
don't
collect,
collect
the
stats
there
and
and
I
think
there
was
some
work
item
in
networking
which
was
going
to
make
this
automatic.
As
far
as
I.
Remember
so
I
said:
okay.
Well,
we
don't
need
to
do
anything
here,
but
as
it
stands
today,
if
use
downstream
protocol
is
enabled-
and
we
don't.
B
E
A
C
B
E
A
A
E
A
With
VIX
everyone
right,
we
had
this
human
adapter.
So
then,
if
traffic
came
in
from
a
source,
it
wasn't
reporting
attributes
or
something
right.
We
could
look
up
the
pod
information
and
label
the
traffic
according
to
the
workload
that
it
came
from
and
same
thing
for
outgoing
right.
If
it
went
to
some
place
that
wasn't
proper,
you
know
there
wasn't
a
proxy
there.
We
can
still
tell
you
a
little
bit
about
it
and
now,
with
the
v2
architecture,
we
don't
have
any
way
to
look
up
information
about
sources
that
we
don't
have
information
on.
E
A
E
E
F
I
This
gap
may
explain
a
recent
crash
that
we
had
reported
in
Keala
I'm,
not
sure
actually,
but
what
we
ended
up
having
we
saw
a
time
series
where
the
source,
the
source
workload
namespace
was
set,
but
no
other
source
information
was
set
in
their
industry
requests
total.
So
we
got
this
source
namespace
and
then
we,
it
in
in
key
ally,
had
assumed
that
there
would
also
be
a
source
workload
set.
Yet
it
wasn't.
There
was
no
canonical
service,
I
mean
that
was
unknown.
I
I
woulda
thought
it
would
I
agree.
It's
very
strange.
We're
gonna
treat
it
like
bad
telemetry
and
discard
it
until
until
we
know
what's
going
on
there
yeah,
then
that's
really
strange
in
the
past
we've
seen
you
know
straight
unknown
right,
we're
just
everything
the
source
is
unknown.
That's
fine!
We
expect
that
coming
in
from
the
from
the
wild,
but
I've
never
see,
I've,
never
seen
that
where
you
have
a
namespace
set
and
nothing
else,
I
think
it's
just.
It
might
just
be
a
corner
case,
some
kind
of
bad
scraping
or
something
I,
don't
know.
B
E
F
B
A
F
E
B
B
B
We
need
to
adjust
in
the
in
the
extensions
we
need
to
play
catch-up
with
all
those
different
methods
of
denoting
a
black
hole,
so
what
we
are
going
to
do
or
what
the
proposal
is,
is
that
we
use
response
flag
NR,
which
was
the
original
Envoy
response
flag,
which
denotes
that
there
is
no
route
right,
which
is
which
is
actually
exactly
what
about
a
black
hole?
Is
there
is
no
route
and
there
is
no
route
because
of
lack
of
configuration.
That
is
exactly
what
it
means.
B
So
we
are
we're
proposing
that
we
use
that
in
our
flag
uniformly
in
sto
to
denote
black
holes
and
that
way
the
the
filters
and
the
data
plane.
All
they
need
to
do
is
check
for
the
presence
of
the
NR
flag.
It
also
means
that
any
of
our
metrics
that
actually
record
response
flags
will
have
a
not
as
the
correct
response
flag,
which
means
you
can
filter
it
in
with
just
just
that
as
well.
So
it
just
simplifies
it.
D
B
The
we
will
have
to
do
I
mean
we
will
maintain
backwards
compatibility
if
people
still
rely
on
the
black
hole
name.
We
can
still
stick
it
in
there
or
something
like
that.
But
what
what
I
really
feel
is
that
once
you
have
once
you
have
NR
as
the
response
flag
that
you
can
just
use
that
on
the
dashboard
as
well,
I.
E
Think
this
makes
complete
sense.
The
only
question
that
you
might
get
from
some
of
the
other
networking
folks
will
be.
Is
there
a
downside
to
add
that
terminating
network
filter,
apart
from
onward
directly
just
doing
it
without
an
additional
filter,
as
in
they
performance
implications?
I,
don't
think
so,
but
yeah.
B
B
D
F
I
think
a
better
way
do
not
put
a
filter
to
begin
with,
just
have
a
empty
table
in
the
no
filter
chain,
matching
particular
destination
that
we
better
them
having
a
filter
between,
but
between
running
a
filter
and
sending
traffic
to
some
empty
cluster
out
before
any
filter
because
running
a
class
safe.
It
has
a
lot
more
performance
implications.
E
E
B
So,
if,
if
there
is
a
way
to
do
it
without
the
terminating
filter-
that's
okay
too,
but
what
we
have
it
and
we
can
just
make
it
uniform
or
that
way,
but
but
I
mean
so.
If
Envoy
itself
encounters
and
in
our
situation
where
there
is
legitimately
no
route
envoy
just
sets
the
flag
itself
now.
The
issue
there
is
that
there
won't
be
like
our
filters
will
completely
be
missing
from
that
in
our
flat
like
we
won't
see
that
right
if,
in
that
little
chain
stats
filter,
for
example,
is
not
present
at
all.
H
F
E
B
F
F
F
I
E
B
B
Yeah
so
I
think
I
think
they're
well,
okay,
I!
Think,
that's
a
that's
a
good
point.
We
do
need
to
think
about
that
a
little
bit
because
the
region
destination
so
I
suppose
there
can
be
other
clusters
that
are
also
passed
through
sorry
original
destination
and
the
question
is:
is
original:
whenever
you
hit
original
destination,
is
that
the
same
as
passed
through
like
are?
We
did
we
just
create
a
new
name
for
it,
just
like
black
hole
or
is?
Is
it
more
specific.
E
That's
interesting:
they
can
be
service
entries
or
explicit
destination
rules.
I,
don't
think
we
allow
destination
rules
to
have
passed
through
or
I'm
forgetting
I
think
there
is
a
queue
API
in
which
users
can
explicitly
configure
pass
through
if
they
want
I
was
for
original
desk.
Sorry,
so
I
don't
know.
That's
a
good
question.
Are
his
original
desk
equivalent
to
pass
through,
in
all
cases
right.
B
B
Okay,
any
anything
else
I
think
we're
down
over
the
end
of
it
anyway,
so
yeah.
So
we
will
present
this
tomorrow,
like
the
networking
group.