►
From YouTube: Policies and Telemetry WG Meeting: 2020-04-22
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
So
I
had
a
PR
that
is
still
out
improve
multi
cluster
telemetry,
with
the
idea
of
being
I
think
this
came
up
in
a
previous
discussion.
We
didn't
have
cluster
IDs
captured
enemy
of
the
toiletry,
and
so
this
was
there's
a
PR
out.
It
has
the
potential
to
add,
cost
their
label
source
and
destination
to
the
default,
telemetry
and
I.
Think
the
question
is:
do
you
want
to
do
that
if
you
want
to
make
it
configurable,
so
I'm
sort
of
interested
in
I
go
on
spots
on
that
and.
B
C
B
We
we
would
like
to
and
we
so
a
couple
of
versions
back.
We
took
a
look
at
what
we
could
do
with
multi
cluster
traffic,
and
the
answer
was
that
if
it
was
a
shared
control
plane,
you
know
basically
a
different
instance
per
cluster.
We
could
do
something,
and
we
did
we
put
a
little
bit
of
code
in
to
help
people
track
requests
going
between
the
different
clusters,
but
I
think
we
talked
about
in
the
last
call.
You
know
it's
sort
of
like
you
can
see
something
leave.
B
You
can
see
something
come
in,
but
you
couldn't
connect
the
dots.
So
we
don't
do
a
lot
of
Multi
cluster
representation
in
the
in
the
topology
yet,
but
but
that
we
could
potentially
add
it
here.
I
agree
that
it
would
be
useless,
but
if
it's
all
within
the
same
cluster,
then
there's
really
no
need
to
supply
the
labels.
For
one
thing
you
know,
so
you
could
potentially
just
supply
them.
B
C
See
I
agree
with
you,
people
do
want
to
do
or
try
multi
cluster
and
basically
telemetry
is
the
best
hope
to
understand.
What's
happening
there.
So
the
downsides.
Are
you
see
one
label
that
is
being
added
by
default,
which
will
mostly
not
change?
If
you
just
drink
single
cluster
Doug
is
that
can
we
maybe
in
the
docs,
if
somebody
is
managing
their
own
Prometheus,
we
can
say
hey.
This
is
how
you
drop
this
label.
If
you
don't,
if
you
want
to
preserve
vole
behavior,
yes,.
A
A
B
C
So
here
is
another
basically
on
these
lines.
What
we
can
do
is
in
the
multi
cluster
documentation
section
explain
you
can
turn
how
you
can
turn
this
label
on
and
get
more
telemetry
and
also
keep
it
under
the
telemetry
section
of
the
sto
Docs,
and
for
this
release
go
with
the
safer
gesture
of
safer
posture
of
not
turning
it
on
by
default,
adding
the
docs
in
the
next
release.
We
can
make
it
on
by
default
if
we
find
that
most
of
the
people
actually
use
it.
B
That
so
with,
how
would
this
ID?
How
do
you
identify
what
what
the
cluster
is
like?
So
could
this
ID
be
used?
Is
it
just
for
display
or
is
it
or
is
it
gonna
be
a
way
for
us
to
actually
potentially
contact
the
other
cluster?
So
like
say,
we
wanted
to
get
service
information
from
cluster
B,
so
say
you
had
something
going
from
cluster
ad
cluster
B
right
and.
B
B
If
we
want
to
show
the
details
of
that
particular
thing
by
having
cluster
IDs?
That
could
actually
help
us
look
in
a
certain
place,
for
a
definition
could
be,
you
know
useful,
but
if
it's
just
some
label,
that's
not
gonna
be
able
to
be
used
as
some
sort
of
identifying
ID
that
we
could
use
in
querying
or
access
there
were
API.
It
would
be
less
useful
and.
A
C
Think
that
that's
totally
correct
J
your
use
case
is
interesting
with
shared
control,
plane,
I,
don't
I
I,
don't
know
if
it
will
just
straightaway
work
for
a
shared
control
plane.
To
be
honest
because,
like
the
resources
that
live
in
different
clusters,
I
don't
think
you
will
be
able
to
query
it.
Based
on
this
identifier,.
B
B
A
B
A
The
second
topic
is
basically
the
same
thing.
This
was
a
a
different,
a
different
label.
There's
been
a
work
on
the
request,
classification
piece,
and
so
the
question
was:
we
want
to
go
ahead
and
make
request
operation
a
default
label,
that's
exposed,
or
do
we
want
to
make
it
configurable?
What
do
we
want
to
do?
There
I
think
there
are
some
big
concerns
about
adding
this,
especially
for
traffic
that
comes
through
the
gateways,
so
I
just
want
to
put
this.
C
A
A
A
C
A
I
guess
before
I
am
manthara
be
hesitant.
Yeah
I
was
trying
to
avoid
any
unnecessary
configuration
because
it
just
doesn't
seem
like
it's
totally
ironed
out,
especially
with
the
other
proposals
around
hiding
the
config
and
things
of
that,
but
maybe
I
mean
what's
on.
Maybe
you
can
speak
like
I,
don't
know
how
are
you
thinking
about
that
configuration
today
and
whether
or
not
we
think
that's
good
enough
state
that
it's
not
a
big
deal
for
users.
D
B
D
C
A
D
C
D
C
C
A
D
C
B
Yeah
I
mean
that
that
might
be
the
case,
so
you
know
it's.
The
question
is:
what's
actually
doable
or
is
anything
actually
doable
now
that
we
look
under
the
cover,
so
I
I
don't
mind
if
this
I
just
like
to
see
this
discussion
continue,
it
doesn't
have
to
continue
in
this
meeting,
but
I
mean.
If
we
can't
really
do
anything
here,
then
maybe,
let's
figure
that
out
or
or
if
there's
something
we
can
do,
let's
figure
that
out
so.
C
I
think
J
the
requirement
so
I
I
think
here
you
are
the
product
owner.
In
no
way
for
this
feature
you
need
to
give
requirements
and
then
Peter
can
come
back
with
design.
So
are
your
requirements
that
whatever
client
requested,
irrespective
whether
there
is
an
actual
service
for
it
or
do
you
want
actually
a
service
behind
this
label?
I.
B
Guess
I
think
maybe
you
know
my
initial
understanding
a
while
back
was
perhaps
I
think
you
know
incomplete
because
you
know
I
was
thinking
are
a
service.
A
record,
you
know,
makes
a
request
for
service
B,
but
given
the
fact
that
there's
virtual
services
in
play,
it
doesn't
actually
go
to
service
B,
it
goes
servus
see
right,
it
gets
rerouted
or
maybe
it
goes
to
service,
B
and
C
because
of
mirroring
or
something
like
that
right.
B
So
I
always
had
this
idea
that
a
request
comes
in
and
then
what
we
end
up
with
in
today's
telemetry
are
the
destination
service
service
name,
namespace
right
those
those
are
the
resulting
fields
for
where
this
thing
gets
routed.
That's
what
happened
and
I
always
thought
that
well,
but
what
happened
to
that?
The
original
request
was
for
something
potentially
different.
So
how
do
we?
You
know
if
you're
talking
about
a
visualization
if
you're
talking
about
like
a
key
ally
graph
or
something
you're
thinking?
B
That
was
kind
of
what
this
was
all
about,
but
now
that
Peter
went
to
look
into
it.
You
know
you
really
have
like
this
incoming
header
right,
but
at
some
point
that
host
requested
host
gets
processed
and
turns
into
the
actual
destinations.
I
just
don't
know
whether
or
not
it's
feasible
or
not
feasible.
To.
B
Understand
or
to
get
any
sort
of
information
that
will
help
us
understand
what
was
actually
requested
past.
You
know
compared
with
what
actually
resulted
basically
and
I
actually
thought
it
wasn't
that
big
a
deal
but
I
think
it's
starting
to
read
this
now
that
he
looks
at
it,
it
seems
like
maybe
it's
a
bigger
deal
and.
D
C
B
Potentially,
that's
I
mean
that's
the
intent,
but
I
understand
that
you
know
in
reality
it's
maybe
not
that
it's
easy
to
figure
it
out.
I'm,
not
I,
wouldn't
say
I
want
to
see
like
virtual
service
names,
you
know
in
the
telemetry
and
you
could
have
multiple
virtual
services
involved
even
in
doing
one
request,
so
you
don't
want
that.
But
you
know,
maybe
even
through
the
original
requested
host
is
a
good
thing,
this
host
header.
But
then
you
know
you
have
the
issues
that
are
that
he's
bringing
up
right
here.
B
B
D
C
B
B
A
Due
to
our
designs
and
always
honor,
is
it
the
bug
tool
right?
Because
this
is
the
bug
tool
you
could
turn
on
as
the
virtual
service
name
appear
and
metrics
real,
quick
and
then
turn
it
right
back
off
once
you
validated
your
your
rules
already
so
then
you
know
what
the
snapchat
is
and
it's
a
controlled
time
frame.
B
Yeah
I
mean
I,
don't
know,
I'm
I
think
most
of
the
time
people
are
interested
in
looking
at
pretty
much
a
very
recent
view
what's
been
going
on,
and
so
that
in
general,
the
definitions
that
are
currently
there
are
fairly
relevant
to
the
traffic
that
they're
looking
at
I
agree
that
sometimes
they'll
look
in
the
past.
They
may
want
to
go
back
and
do
comparisons
with
the
past
or
whatever,
but
a
lot
of
the
time
it
seems
to
be
more
recent,
and
so
so
far
we
haven't
gotten
a
lot
of
complaints
about.
B
You
know
these
these
issues
about
the
config
not
matching
what
they're
looking
at,
but
that
then
that's
why
I
was
kind
of
trying
to
steer
this
particular
issue
as
literally
just
trying
to
figure
out
if
there's
any
clues
that
we
could
give
to
the
consumer
of
telemetry
that
that's
what
they
requested
was
maybe
not
what
they
ended
up
with
because
of
because
of
destiny
because
of
virtual
services.
You
know
because
it
does
happen.
A
C
C
C
That's
where
I
was
going
quite
so
I
think
the
authoritative
source
here
is
basically
all
the
matching
that
happen,
because
we
already
have
the
first.
What
client
intended
clients
intent
was
and
we
have
the
destination.
What
is
missing
is
just
the
things
in
the
middle
and
the
things
in
the
middle
are
either
based
on
matchers
or
based
on
some
actions
like
mirroring
right.
C
C
A
C
How
it
gets
lowered
right,
so
look
look
at
the
route
configuration
for
envoy.
What
will
happen
is
you
will
have
a
list
of
routes
with
a
list
of
hosts
in
them,
so
one
of
them
will
match
or
series
of
them
will
match
and
I.
Don't
think
we
should
try
to
pick
out
a
metadata
there.
We
should
try
to
pick
out
what
exactly
matched
I'm
saying
and
then
store
that
that
will
be
always
consistent.
Irrespective
revisions
of
the
configuration.
E
Is
that
important,
though
I
mean
it
I'm,
just
from
like
a
user
perspective?
What
would
be
important
to
me
is
to
see
what
was
the
service
routing
right.
Where
did
I
go?
Where
did
I
want
to
go
and
where
was
I
sent,
and
you
know
how
things
actually
mapped
or
matched
out
is
sort
of
more
like
a
debugging
exercise.
I
would
also
be
concerned
that
if
you
took
that
approach
that
that
could
be,
you
know
expensive
in
terms
of
generating
the
telemetry
details
right.
E
So
if
so
the
first
is
find
me
is
looking
at
this
from
user.
Here's
how
the
service
routing
occurred,
and
then,
after
that
you
know,
I
guess
the
next
problem
is.
Why
did
that
happen?
But
I?
You
know,
I,
think
that
just
comes
into
play.
If
stuff
isn't
working
right
so
and
that's
so
I
think
it's
you
know,
have
it
I
I
think
we
should
get
away
from
not
from
having
like
configuration
details
tied
in
with
the
telemetry
right.
The
telemetry
is
there,
you
can
visualize
it
if
the
telemetry
is
not
there.
E
You
can't
do
anything
so
I.
Think
the
question
to
what
you
were
talking
about
Niraj
is:
is
it
important
to
have
those
details
in
the
telemetry
so
that
we
can
look
at
it
historically
or
is
it
enough
to
just
say
this?
Was
you
know,
version
X
of
or
revision
X
of
the
you
know,
pilot
config
for
that,
but
I
mean
that's
even
kind
of
useless
to,
because
if
the
configuration
has
changed,
you
know
it.
It's
really
just
I,
don't
know
sorry
I'm
starting
to
ramble.
So
stop.
C
C
B
E
A
So
the
way
I've
been
internalizing-
this
is
that
we
want
to
be.
There
is
a
desire
to
understand
how
changes
to
config
impact
telemetry
and
to
do
that
in
a
direct
way
or
to
make
it
observable
when
he
changes
it,
config
in
which
which
pieces
have
configure
contributing
and
so
I
mean
others
may
have
a
different
understanding
of
this
problem,
but
so.
A
B
Think
it's
fair
and
you
know
I
think
that's
what
the
original
request
here
was
that
you
take
that
host
header
and
you
break
it
down
to
that
requested
service,
and
you
put
that
default
telemetry,
and
then
you
let
something
like
key
Olli
try
to
figure
out
whether
there
was
a
virtual
service.
There
involved,
for
example,
by
by
potentially
doing
its
own
work
against
the
current
definitions
on
the
virtual
services
and
the
current
to
to
a
degree,
some
of
the
same
matching
that
goes
on
so.
D
I,
don't
think
we
need
to
look
up
every
single
virtual
service
attached
a
quest
right
because
most
of
them
don't
really
actually
know
much
like
if
it's
just
a
default
routing
pattern,
and
why
don't
you
know
what
Saurus
config
was
suppose
out
there.
So
maybe
we
need
to
look
at
the
kinds
of
things
that
we
are
looking.
B
D
B
B
C
C
Then
there
is
a
person
who
might
whose
job
might
be
to
just
understand
how
everything
works
in
his
quest
in
their
twister
with
Sto.
Maybe
they
are
the
only
person
who
needs
to
see
this
information
all
the
time,
I
think
in
the
beginning
days
of
history
or
when
most
of
the
time
the
clusters
were
broken
because
nobody
understood
is
steal.
This
request
this
feature
would
have
been
extremely
useful.
I,
don't
know
if
we
still
need
to
even
expose
this
to
everyone.
C
B
A
A
A
A
A
C
B
B
G
A
B
D
C
C
A
Ran
through
a
test
where
I
was
able
to
get
metrics
from
multiple
clusters
pulled
into
the
same
place,
but
I
didn't
do
anything
beyond
that
in
terms
of
usability
studies,
I
just
remember
being
told
that
the
cluster,
the
missing
cluster
idea,
was
going
to
be
the
biggest
thing
and
so
I.
That's.
Why
I
focus
on
that
first,
but
there
could
be
other
gaps.
I
just
haven't
spent
any
time
with
it
does
anyone
else
know
of
gaps
or
things,
and
then
we
could
add
that
certainly
to
list.
C
A
D
Well,
I
mean
this
is
going
to
be
up
streaming.
Work,
I
know
what
it's
going
to
be
done,
but
it's
certain
name
I,
don't
think
it's
an
hour
plate,
it's
more
just.
We
need
to
adjust
ourselves
to
the
world
where
it's
based
off
box.
You
awesome
paradigm
is
Joe.
Biased
sort
of
we
need
to
make
sure
the
general
was.
Some
extensions
are
part
of
this
Joe.
Not
just
these
two
extensions,
okay,
I,
don't
know
quite
how
to.
A
D
D
A
F
Love
me:
does
that
include
kind
of
you
know
the
ability
to
separate
gateways
and
that's
like
curse
like
would
that
be
part
of
the
API
for
us
to
call
out
like
whether
it's
tracing
or
you
know
other
things
well,
they're
telemetry.
C
A
C
A
C
D
It
turns
out
it's
very
hard
to
tell
whether
each
choice,
handling
connections
or
not,
because
not
always
connections
go
for
the
same
standard
telemetry
pipeline
and
what
all
these
connections
are
correct
so
like.
If
you
have
an
issue
protocol
handling,
then
we
don't
actually
meet
the
events,
so
when
you
improve
there
so
that
we
can
understand
and
for
every
connection
made
to
proxy,
not
just
ones
for
that
successful.
C
C
A
Yes,
so
the
Charter
is
unclear
with
the
transition
away
from
this.
Oh
man,
maybe
what
the
idea
is
to
just
be
clarifying
the
Charter
I
think
we
had
one
to
provide
documentation
within
a
transition
plan
for
all
of
the
former
functionality,
so
not
just
closing
the
feature
gap
for
telemetry
v2,
but
for
p2
in
general.
A
A
C
C
A
C
A
I
think,
eventually,
we
want
to
provide
the
ability
for
them
to
run
in
the
epoxy
right,
but
I
was
just
thinking
if
you,
if
you
were
transitioning
across
and
you
only
had
a
pilot,
proxy
and
I'm
out
of
the
mixer,
you
know
how
to
process
adapter
running.
Wouldn't
it
be
nice
that
you
could
just
push
config
and
we
would
sense
to
send
you
the
same
data.
A
F
D
C
D
For
policy,
we
don't
really
have
examples
of
contentions
that
call
out
and
we
only
have
to
limit
extensions
to
collab.
So
things
like
rate
limiting,
we
don't
have
experience
implementing
it,
so
we
need
to
gain
some
experience
and
make
sure
it
works.
I,
don't
know
if
we're
gonna
make
it
that
so
they
can
port
existing
stuff,
but
at
least
we
need
to
make
sure
the
foundation
is
there.
First.
C
D
D
So
some
things
are
more
complicated,
for
example,
have
a
group
working
on
the
DLP
data
like
prevention,
so
the
the
one
I'd
be
able
to
observe
and
then
modify
data,
so
that
requires
call-outs
during
processing
and
then
also
modifying
at
the
same
time.
So
that's
a
case
for
an
extension
that
is
not
existing
in
any
way.
D
C
D
A
C
A
A
Okay,
well
we're
basically
out
of
time.
So
the
document
is
linked.
Please
contribute
ideas
there
and
help
shape
them
into
something
I'm
more
useful
than
this
list.
That'd
be
much
appreciated,
and
if
there
any
questions
or
agenda
items
for
next
week,
please
don't
hesitate
to
add
them
or
to
Eastern
I
guess
I
mean
the
last
thing.
I
want
to
say
is
I.
Think,
there's
some
internal
testing
days
coming
up.
So
please
take
a
look
at
the
swing,
maturity
and
the
policy
items
over
there
and
see.
If
you
get
about
the
testing.
B
B
B
A
Had
not
verified
this
I
was
under
the
impression
that
the
upgrade
scripts
had
been
modified.
To
look
forward,
make
sir
a
message
of
the
the
mixer
CRS
and
then
would
maintain
if
there
any
customization
and
if
there
hadn't
would
go
ahead
and
convert
everything
over
to
be
to
okay,
but
I
have
not
tried
it
and
I,
don't
know
if
that
is
actually
what
ended
up
happening.
What
do
you
have
any
recollection
of
no.
A
I
think
the
further
and
further
we
get
away
from
mixer
the
details
are
gonna,
get
vaguer
and
vaguer
on
what
happens
if
you're
still
trying
to
use
it
heck,
Lee,
yeah
I
hope
would
hope
that
the
tests
are
still
running
for
it,
but
that's
as
much
as
much
as
I
would
know
right.