►
From YouTube: Policies and Telemetry WG Meeting - 2020-09-09
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
All
crowd
today
I
put
some
some
things
on
the
agenda.
I
wanted
to
share
the
feedback
we
got
at.
The
working
group
leads
meeting
from
the
tfc
members
on
the
proposed
roadmap
for
one
eight
everything
seemed
to
pass
without
comment,
except
for
the
critical
but
uncommitted
work
which
was
dealing
with
metadata
for
inbound
and
outbound.
Calls
that
don't
belong
to
to
the
mesh
so
coming
from
proxy
lists
places
are
going
to
practice
those
places
and
also
about
metrics
expiry.
A
For
the
metadata,
the
feedback
was
that
we
should
pursue
imbalance
in
in-point
annotation
for
outbound
calls.
So
this
is
something
we
talked
about.
I
think
on
the
slack
channel-
maybe
some
other
forums
but
quickly
using
the
endpoint
existing
endpoint
annotation
to
add
some
labels
with
metadata
about
the
endpoints
and
send
them,
and
if
we
could
do
it
efficiently
by
doing
it
for
endpoints
that
we
know
don't
have
proxies,
I
guess
was
the
optimization
proposed,
but
that
sounds
like
some
work
that
we
should
pursue
and
then
for
metrics
expiry.
A
They
ask
that
we
prioritize
documenting
the
work
arounds
and
developing
the
plans
for
how
we're
going
to
address
that
work
in
1.1.9
and
beyond.
So
that
was
the
that
was
the
major
feedback
from.
B
No,
I
think
doug,
that's
good.
I
was
gonna
just
ask:
are
these
reflected
in
the
updated
extensions
roadmap?
The
changes
that
you
just
mentioned.
A
B
B
Yes,
yes,
for
the
metadata
support
for
outbound
I'll.
Take
a
look
at
the
code
today.
Well,
I
shouldn't
say
today
I'll
take
a
look
at
the
code
this
week.
Okay,
and
if
it's
straightforward,
I'll
collaborate
with
you
on
slack.
A
B
Think
so
too
yeah
I'll,
let
you
know
is,
are
you
gonna
be
working
on
that?
Is
that
fair
to
assume.
A
I
am
happy
to
work
on
it.
I
think
that's
the
safest
thing
I
can
say
so.
I
I
will
try
and
find
time
to
work
on
it.
Yes
did
we
want?
Is
there
anything
else
we
wanted
to
say
about
that
or
the
other
thing
that
came
up
afterwards
was
sven,
pointed
out
that
we
didn't
have
anything
on
our
roadmap
for
multi-cluster.
A
So
I
added
a
line
item
here
to
say
we
should
add
multi-cluster
support
to
the
dashboards,
but
I
think
there's
probably
more
work
there.
I
just
don't
have
a
good
idea
of
what
that
work
is
per
se,
because
we
sort
of
documented
how
you
monitor
in
multi-cluster
scenarios
and
the
metrics
themselves
should
already
do
the
right
thing.
A
So
I
think
that
there's
some
there's
a
need
to
focus
on
multi-cluster
support,
but
I
don't
know
what
specifically
that
work
is.
So
if
anyone
out
there
is
looking
at
this
or
thinking
about
it
or
wants
to
to
own
that
that
would
be
great.
I
don't.
I
don't
have
a
lot
of
guidance
to
provide
in
that
regard.
However,
let
me
add.
B
That
so
doug
two
things.
C
B
Is
if
we
are
unclear
on
what
it
means,
I
would
suggest
not
to
add
it
until
soon
helps
you
get
clarity
on
it
because
we
have
items
on
the
roadmap
which
never
gets
done
because
we
don't
know
what
it
is.
B
Second
is:
what's
the
state
of
telemetry
in
multicluster
right
now,
I
know
there
is
a
cluster
label
that
can
be
optionally
added
in
all
the
metrics.
Is
that
the
extent
of
it
or
does
it
go
beyond
it?.
A
So
there's
that
label
the
the
labels
to
get
added
for
prometheus
metrics
those
get
auto
added,
and
then
there
is
a
document
I
think
carolyn
put
together
on
the
website
about
how
to
monitor
across
clusters,
and
so
those
are
the
two
things
that
would
have
been
done
for
multi-cluster.
A
As
far
as
telemetry
goes
so
sort
of.
B
C
A
C
A
Added
was
the
dashboard
because
at
least
there
I
can
see
having
a
drop
down
and
say
it
should
only
show
me
traffic
going
to
or
from
this
cluster,
but
I
think
that
there's
probably
more
that
we
could
do
but
you're
right.
I
don't
have
a
good
handle
on
what
that
is.
A
A
E
I
was
just
going
to
say
niraj
on
the
kiali
side
for
multi-cluster.
We
we
put
a
little
bit
of
I
mean
the
support
is
very
minimal.
We've
tried
to
clean
up
a
little
bit
of
being
able
to
connect
requests
that
are
either
going
out
of
one
cluster
or
coming
into
another
cluster,
but
there's
nothing
that
actually
will
show
you
that
as
one
edge
you
know
going
from
one
cluster
to
another.
We've
we're
actively
looking
at
multi-cluster
and
better
support
for
that
too
going
forward.
E
A
Aj
one
of
the
things
about
multi-cluster
support
is
that
those
labels
are
sort
of
dynamically
right,
so
they
sort
of
detect
when
the
cluster.
You
know,
when
you're
doing
the
install
that
it's
a
multi-cluster
scenario
and
then
adds
the
labels
and
we've
talked
about,
maybe
turning
those
into
always
on.
Would
that
make
it
easier
for
kylie
to
to
adopt
some
features.
The
ability
to
rely
on
those
labels
always.
E
E
B
Okay,
doug,
if
we
do
go
this
route
as
long
as
there
is
an
option
to
turn
it
off
for
people
who
don't
need
multicluster,
I
don't
think
there's
much
loss
there,
so
you
can
turn
it
on
like
folks
like
us
for
our
customers,
we
might
turn
it
off
because,
like
jay
was
saying,
I
think
trying
to
visualize
multicluster
is
a
much
bigger
story
than
metrics.
A
Sure-
and
I
think
with
the
the
customization
work-
that's
in
should
be
straightforward
to
turn
off
but
documenting
that,
I
think,
would
be
the
big
the
big
thing:
okay.
A
Okay,
anything
else
that
anyone
is
thinking
about
one
eight
before
we
move
on
okay
on
the
slack
channel.
There
was
this
issue
about
response
codes,
in
particular
when
downstream
connection
failures
happen,
and
so
we
were
returning
zero
and
the
question
came
up
as
to
whether
or
not
that
was
appropriate,
and
so
I
think
I
said
on
the
slack
channel.
I
would
raise
this
in
the
working
group,
so
I
just
wanted
to
sort
of
open
the
floor
to
hear
thoughts
on
what
should
we
do
when
there
are
no
response
codes?
A
Should
we
make
it?
Something
else
is
zero.
Okay,
there
seems
to
be
sort
of
a
split
thinking,
at
least
on
the
slide
channel.
So
I
just
wanted
to
see
what
what
the
thoughts
were.
E
E
I
guess
that
carl
stoney
I
can't-
or
his
name
had
had
also
brought
up
in
the
past,
but
what
happened
for
me
was
I
I
didn't
know
if
I
was
looking
at
a
bug
or
not
right,
because
I
would
all
of
a
sudden
there
were
http
response
codes
of
zero,
which
threw
us
for
a
little
bit
of
a
loop
in
kiali,
because
we
were
expecting
always
an
http
response.
Code
of
you
know
x,
three
x
x,
four,
whatever
three
three
digits,
and
so
I
think
the
zeros
we're
we're,
not
anticipating
that.
E
But
we
didn't
know
what
I
mean
we
could
deal
with
it.
I
mean
so.
The
question
is:
what's
really
appropriate
and
the
other
problem
being
that
if
we
go
with
zeros,
what
do
you
do
with
grpc
which,
where
zero
is
success?
E
B
So
jay
is
the
there
are.
It
looks
like
there
might
be
two
problems
here.
One
is,
we
are
overloading
zero
here,
where
zero
might
mean
different
things
depending
on
different
context,
and
then
the
second
problem
is:
what's
the
right
metric,
I
guess
to
emit
when
you
get
errors,
where
a
response
is
not
even
emitted.
E
I
I
guess
it's
really
both
I
mean
in
this
case
right,
so
you
get
you
get
the
response
flags
which
are
telling
you
that
there
was
a
downstream
connection
problem
and
so
there's
really
no
response
right.
So
if
there's
no
response,
can
you
even.
E
I
guess
there
really
shouldn't
be
a
response
code
because
it
would
seem
logical
that
way.
I
don't
know
if
that
makes
it
easier
or
not,
but
it
seems
logical.
It's
still
an
error.
You
know
the
request
fails.
So
in
general,
you
know
when
we're
when
we're
trying
to
show
that
say
in
a
graph
or
wherever
else,
it's
a
traffic
failure.
E
Usually
we
feel
like
there
should
be
a
response
code
that
that
goes
with
that.
So
I
don't
know
what's
best
yeah,
I
really
don't.
B
A
A
We'd
have
to
figure
out
what
the
right
thing
to
do.
There
is
yeah,
certainly
when
it
gets
translated
into
the
the
metric.
We
could
change
it
to
like
a
dash
or
or
something
right,
but
it
had
been
zero,
there's
less
of
a
concern
at
the
moment
with
overlap
with
grpc,
if
only
because
we
have
the
separate
grpc
response
status
field.
A
B
E
It
doesn't
really
necessarily
make
it
better,
I
mean
so.
The
question
is,
then:
how
do
you
if
the
right
thing
is
to
not
have
a
response
code?
That's
to
not
have
a
proper
http
response
code,
then
you
have
to
at
least
be
able
to
know
that
the
request
something
has
to
be
the
flag.
That
says
this.
You
know
this
failed
to
launch
or
whatever
you
know
we
never
got
a
response
because
of
a
timeout
or
whatever
else.
E
B
I
think
currently
it
has
to
be
a
combination
of
both
right
or
as
far
as
I
know,
because
they
might
be
in
case.
Well.
Let's
see
so
maybe
some
some
telemetry
expert
can
tell
me.
So
if
you
do
proceed
and
you
can
get
a
response
code,
but
the
request
still
terminates
what
happens
then?
Do
you
get
an
actual
response
code
with
a
response
flag.
A
So
you
you
get
a
partial
response,
I'm
trying
to
figure
out
yeah.
I
think
that
you
would
get
the
why
I
don't
actually
know.
I
imagine
you
get
the
response
code.
I
don't
know
about
the
response
flag.
Maybe
what
do
you
know
or
newper
or
anyone
on
the
call.
D
B
Yeah-
and
I
do
agree
with
ed
what
he
was
saying
around
having
a
having
one
indication
if
we
can
make
it
uniform
is
better,
but
I
I
just
don't
think
it
is
possible
because
if
you
set
the
response
code
to
something
else
other
than
what
the
server
send,
then
you
are
kind
of
masking
the
real
behavior
right.
So.
B
I
don't
know
it
feels
like
we're
doing
the
right
thing
in
both
the
cases
unless
somebody
and
unless
you
all
think
that
we
have
to
consolidate
this
and
have
yet
another
flag
which
always
says
that
this
is
the
error.
E
E
A
E
What
would
it
be?
Zero
zero
is
a
success
for
grpc,
so
you'd
have
to
base
it
off
of
the
you
said
you
I
thought
I
heard
you
say
doug
that
the
http
response
code
would
be
200
yeah
in
the
case
of
a
success.
So
if,
if
we
can
always
assume
that
response
code,
0
means
there
was
no
response,
then
at
least
that's
something
consistent.
C
E
Yeah,
so
I
think
it's
just
a
matter
of
for
the
consumer
side
for
kiali
or
anyone
else
just
to
be
able
to
understand
that
when
we
query
the
metrics
that
we
have
to
assume
that
a
zero
is
something
that
we
have
to
handle,
because
I
can
tell
you
right
now.
We
actually
do
some
things
with
you
know,
regex
and
so
forth,
where
we're
looking
for
three
digit
response
code,
which
is
a
problem
right
now.
A
Okay,
I
I,
I
think
for
sure
the
action
coming
out
of
all
this
is:
we
need
better
documentation
about
the
possibility
of
response
code
being
zero
and
making
that
clear
and
sort
of
providing
information
about
what
that
means.
C
B
A
A
Or
anyone
else
remember
if
it's
only
on
I'd
like
to
really
answer
that.
A
A
Okay,
so
here's
the
interesting
thing
about
it:
grpc
response
status
is
always
on,
but
if
the
request
protocol
was
not
grpc,
we
set
it
to
the
empty
string,
and
so
it
will
disappear.
I
think
from
the
metrics
it'll
show
up
as
an
unset
label
and
be
dropped.
E
A
A
That
would
probably
be
good.
Is
that
better
I
mean,
then
you
would
have
no.
E
Response
good
at
all,
I
mean
that
makes
me
wonder
only
now
whether
the
zero
is
right
or
whether
that
should
be
an
empty
string,
but
that
seems
like
it
could
really
cause
more
special
case
code
than
right.
The
problem
with
things
not
showing
up
at
all
is
that
it's
sometimes
special
case
code,
as
opposed
to
just
being
able
to
do
a
query.
A
E
A
Okay
and
all
this,
of
course,
we
had
talked
about
consolidating
these
down
to
a
single,
a
single
field.
At
some
point,
I
don't
know
what
the
thoughts
are
there
and
how
that
would
impact
this
conversation
right.
If,
if
response
code
wasn't
just
http,
but
it
was
also
grpc,
then
I
think
there
is
overlap
and
we'd
have
to
figure
out
yeah.
B
Yeah,
I
I
think
we
discussed
that
in
details
when
the
grpc
response
status
was
being
discussed.
I
feel
like
what
we
have
is
reasonable.
Instead
of
trying
to
consult
it.
B
B
E
A
A
I
feel
like
a
month
ago,
or
so
there
was
some
there
were
some
issues
coming
up
or
at
least
on
one
of
the
channels,
either
slack
or
discuss
about
how
to
support
mtls
to
add-ons
and
how
to
do
authentication
and
authorization
for
add-ons,
and
so
I
was
sort
of
wondering
if
there's
more,
that
we
as
a
working
group
should
do
to
help
provide
guidance
around
setting
up
add-ons
or
whether
or
not
that's
something
we
want
to
sort
of
leave
as
an
exercise
for
the
for
the
community,
because
you
know
in
the
same
spirit
of
we're
sort
of
not
supporting
customized
installations.
A
So,
john,
that's
why
I
tagged
you.
I
was
just
sort
of
curious
what
your
your
thoughts
were
and
or-
and
I'm
also
interested
in
others,.
G
It
seems
like
yes,
we
should
provide
some
guidance,
probably
because
I
think
if
users,
if
we
ask
users
to
do
this,
they'll
just
end
up
getting
stuck
and
asking
us
on
slack
or
github
or
whatever,
because
you
know
it's,
I
don't
think
it's
obvious.
I
think
there's
a
lot
of
different
ways.
You
can
do
it
as
well.
G
So
I
like
right
now,
I
don't
even
know
exactly
what
we
want
to
do
and
I
think
it's
different
for
different
add-ons
like
prometheus
is
certainly
different
than
like
jager,
for
example.
So
it
would
probably
be
useful.
Okay,.
A
Ed,
do
you
think
this
is
something
that
we
could
work
on
across
working
groups
is
sort
of
a
user
experience
issue,
or
do
you
think
this
belongs
in
some
other
form
or
prop
maybe
shared
between
user
experience
environments
in
telemetry
or
like?
What's
the
what's
the
right
way
to
drive
this
work.
F
A
Okay,
I'll
follow
up
with
the
niche
then
and
maybe
start
throwing
together
an
rfc
related
to
what
we
want
to
do
in
document
in
terms
of
documentation.
F
Yeah,
I
find
it
hard
to
tell
what
the
settings
are
for
like
mtls
and
certificates
and
stuff,
so
it
would
be
good
to
get
ux
involved
with
this,
but
I'm
not
sure
how,
for
one
eight,
just
maybe
a
one
nine
time
frame.
A
A
Agenda
based
on
things
I
remember
coming
up
on
the
channels,
is
there
anything
else
that
anyone
wants
to
talk
about
or
bring
up
or
ask
questions
about,
or
show
demos
off
about
or
anything
like.
A
A
Okay,
well,
if
not
thanks
everyone
and
enjoy
your
days,
hopefully
blue
skies
will
return
wherever
you
are
at
some
point
soon
and
I'll
talk
talk.