►
From YouTube: Policies And Telemetry WG Meeting - 2020-02-26
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
B
A
E
F
D
I'll
echo
that
all
right,
we
should
probably
wait
another
minute
or
two
until.
C
D
D
D
H
D
D
D
All
right-
and
actually
we
might
need
some
of
his
expertise
right
here
too.
So,
okay,.
E
C
All
right,
so
I
can
describe
the
problem
here.
So
basically,
what
we
found
out
yesterday-
or
I
think
jacob
found
out
that
while
he
was
testing
v2
telemetry
destination,
port
now
became
a
default
set
of
labels.
C
C
D
D
H
Is
that
possible
to
set
up
you
know
sorry
owner's
file
yeah,
you
can
eliminate
whatever
files
you
want
in
other
repos
other
studio,
repos.
H
H
C
That
does
work
for
this
scenario.
There
is
the
other
side
of
the
problem,
which
is
networking
continuously
changes
pilot
code
in
a
way
where
policy
is
affected.
Do
you
have
an
example
of
that?
Well,
black
hole,
for
example,
that
was
broken
continuously
between
1
3
and
1
4,
and
the
only
reason
I
was
able
to
surface
it,
because
I
know
the
pilot
code
reasonably
well
and
I
went
and
changed
it.
C
H
Isn't
that
more
just
a
matter
of
having
proper
testing,
you
would
hope
so.
I
I
I
C
C
I
Okay,
so
I
think
should
be
for
any
new
feature:
networking
it
has
to
be
a
test
and
plan
right
and
that
plan
has
to
include
security
and
telemetry.
Okay,
okay,
I'm
fine
with
that.
If
people
agree
but
but
enforcing
that
process
is
not
up
to
us,
it's
a
networking
team.
I
think
I
think
we
need
to
propose
this
to
the
process,
but
we're
not
the
ones
to
enforce
it.
D
J
K
So
so
I
think
I
think
that
that
that's
true
so,
for
example,
if
we
specifically
had
tests
for
black
holes,
then
even
if
they
would,
even
if
it
wasn't
kind
of
fully
consulted,
those
tests
would
have
broken
and
we
would
have
known
right.
I
suppose
we
did
not
have
those
tests.
C
K
So,
yes,
I
I
think
that
that's
that
correct
that
that's
the
next
level
of
detail.
What
but
behaviorally
we
we
didn't,
have
good
coverage
for
black
hole,
telemetry
right!
That's
that's
what
that
is
pointing
to
right.
J
Black
hole,
telemetry
or
black
hole
in
general,
because
I'm
pretty
sure
we
have
a
test
for
fault,
injection
and
and
status
quotes
I'll,
be
shocked.
If
we
don't
not
telemetry
I
mean
we
have
tests
for
port
injection
and,
of
course
the
test
could
check
if
telemetry
is
collected,
I
mean
that's
probably
missing.
I
agree,
but
that's.
C
J
Well,
there
are
things
that
can
catch,
I
mean
we
are
testing
functionality.
If
we
we
verify,
we
have
test
for
filter
for
for
fault
injection
in
networking
and
we
have
tests
for
telemetry.
So
we
don't
have
this
combination.
J
K
J
That's
we
are
not
aware
of
pulling
off
the.
K
Right
so
so
in
in
this
case,
the
reason
why
it
came
out
right
this
way
is
that
we
depended
on
on
certain
implementation
really
of
black
hole
right
and
when
the
way
black
hole
was
implemented,
changed
from
cluster
to
an
inline,
502
or
whatever,
which
is
being
sent
back
right
now,
maybe,
logically,
it
is
still
about
still
a
black
hole,
but
it
wasn't,
and
black
holes
specifically
happen
to
be
very
important,
because
they
give
a
signal
to
people
that
something
is
not
configured
right
and
that's
why
that
telemetry
is
well.
K
It's
also
important
and
and
because
of
that
change
it.
But
but
again
it
still
goes
back
to
the
fact
that
if
we
had
a
if,
if
we
had
good
test
coverage
for
black
hole
telemetry,
it
would
have
failed
in
that
case
and
like
it
would
have
just
stopped
you
submit.
So
I
think
that
I
think
that
was
the
specific
problem
there,
not
so
no
yeah,
the
part
about
notifying
and
all
that.
I
think
that's
that's
always
prone
to
the
problem.
J
Notifying
it's
about
communication
and
I
don't
think
anyone,
because
that's
usually
done
in
pr
sector.
I
mean
it's
not
even
discussed,
because
it's
considered
an
implementation
change
either
an
optimization
or
something
we
should
not.
I
mean
there
are
hundreds
of
peers
that
go
in
and
we
have
no
clue.
What's
that
what's
inside
them,
it's
not
really
obvious
that
pr
like
this
would
affect
other
components
in
general,
it's
not
a
good
idea
to
depend
on
the
internal
implementation
details.
J
That's
another
thing,
because
you
have
other
implementation
of
xds
servers
that
may
be
used
with
with
time
voice
and
they.
K
K
C
K
More
yeah
is
there
something
kind
of
even
more
fundamental,
but
so
so
far
we
just
discussed
right.
We
we
have.
We
have
some
route
annotations,
yeah.
I
C
Happen
right
so
cospin,
I
think
what
we
are
suggesting
is
yes,
having
tests
make
complete
sense
and
the
if
test
break,
it's
a
good
signal
to
the
pr
submitter
that
you
should
go
and
fix
some
things
there
still
will
be
escapes
because
of
the
coverage.
H
C
J
K
K
J
J
C
I
I
I'm
saying
costing
in
general,
there
is
a
problem
when
the
layout
of
how
pilot
creates
the
filter,
chaining
affects
symmetry
and
we
are
not
able
to
catch
it
early
on
right.
So.
D
So
I
think,
there's
a
general
issue
and
I
don't
know
that
we're
going
to
solve
it
where
just
sometimes
like,
when
you're
focused
on
an
area
we're
not
thinking
about
what
the
implication
is
for
other
areas
as
a
project.
I
don't
know
how
to
solve
that,
except
everyone
go
to
every
meeting
which
doesn't
seem
like
a
solution.
D
J
D
So
so
I
think
we're
all
in
agreement
that
we
we
don't
we're
it's
not
it's
not
100
working,
we're
just
trying
to
figure
out.
Is
there
a
way
looking
better?
So
I
think
we
have
some
small
tactical
things.
We
can
do
like
the
owner's
files,
better
test
coverage
of
features
we
know
about.
I
just
don't
know
how
to
I
think.
J
Owners
doesn't
solve
the
problem
either
because
again
the
problem
is,
you
need
to
review
all
prs
and
to
understand
what
they
are
doing.
Only
tests
can
solve
this
problem.
Really
I
mean
you
cannot
communicate.
There
are
optimizations
that
people
do
not
really
understand
what
implications.
I
I
don't
understand
my
implication
of
my
changes.
Either
we.
J
Not
only
retroactive,
I
mean
there
are
many
ways
to
test
it.
Even
if
it's
you
know
it's
a
perf
cluster
and
some
other
stuff,
but
you
it's
not.
No
human
can
understand
all
the
prs
going
into
istio
and
understand
all
the
implications
of
some
subtle
change.
That
is
not
humanly
possible.
I
mean,
I
don't
know.
Maybe
I'm.
I
J
J
I
C
K
Okay,
I
I
think
I
think
we
we're
we're
not
we're
kind
of
where
we
are
it
looks
like,
but
but
the
the
take
home
is
that,
what's
what
I
think
we
lack-
and
I
think
that
that's
that's
what
we
should
recognize
first,
is
that
conformance
test
for
v2
telemetry
right,
so
that
would
have
caught
black
hole
cluster
issue
before
stoner
caught
it.
K
So
so
I
think
I
think
that's
that's
kind
of
that.
That's
one
and
then,
if
we
specifically
want
to
have
some
communication
vehicle
about
changing
the
layout
of
xds
and
how
that
affects
it,
that's
more
of
a
process,
question
and
just
a
communication
question.
K
So
I
think
that
the
only
the
only
thing
we
can
do
is
whoever
is
reviewing
design,
docs
and
or
pr's
can
just
bring
other
people
who
you
think
might
be
affected.
If
you
don't
know
the
know
the
impact
yourself,
but
beyond
that,
I
I
think
we
like.
We
can't
put
any
more
process
around
it
than
that
saying
more
than
the
reviewers
just
be
diligent
and
pull
in
other
people.
I
J
D
I
agree-
let's
I
don't
think
we're
going
to
solve
this
here,
but
maybe
some
thinking
we
can
come
back.
So,
let's
move
on
to
simplifying
prometheus
configuration,
I'm
going
to
resolve
this
comment
I'll,
let
you
john,
I
think
you
and
cost
10
have
a.
H
Yeah,
so
some
of
the
background
is
we're
trying
to
simplify
all
the
add-ons
in
the
environment's
working
group,
and
so
especially
with
regards
to
like
integrating
with
existing
add-ons.
Like
you
know,
most
people
already
have
prometheus
running
whether
it's
the
prometheus
operator,
they
install
it
from
home
or
they
press
some
button
on
their
cloud
provider
and
they
get
prometheus.
H
Those
have
various
ways
of
configuring
them
and
so
we're
looking
into
how
we
can
configure
those
to
support.
H
You
know
the
estro
scraping
config
and
the
tls
settings,
which
I
think
are
the
two
main
things
we
need
to
configure
with
prometheus
and
one
easy
way
is
to
make
it
so
we
we
don't
actually
need
to
configure
anything
special,
like
almost
all
the
setups
for
prometheus
out
of
the
box,
we'll
do
like
the
scraping
of
prometheus.io
scrape
labels,
so
the
thought
was,
we
could
do
add
those
to
istio,
and
then
we
don't
need
custom,
estio,
scraping
config,
because
the
standard
out
of
the
box
prometheus
will
work.
H
So
that's
the
idea
it's
very
early
like
this
is
not
a
design
doc.
This
is
an
idea.
The
main
challenge,
I
think,
is
that
the
user
has
metrics
as
well
and
sidecar
is
metrics
and
prometheus.
Doesn't
support
like
adding
two
ports
to
the
annotation
or
something
easy
like
that
that
we
can
just
have
it
scrape
both
of
them.
H
So
the
idea
was
that
potentially
we
could
do
something
like
have
the
pilot
agent,
be
the
actual
stats,
endpoint
and
it'll
reach
out
to
the
envoy.
The
application
and
itself
get
all
the
metrics
for
all
of
them,
aggregate
it
into
one
response
and
send
it
back
to
prometheus
something
along
this
line.
Like
I
said
this
is
not
a
design,
it
may
not
be
feasible.
Just.
J
And
then,
as
a
side
effect,
this
will
also
solve
the
security
problems,
because
this
will
be
a
port
that
is
not
intercepted
by
the
tables.
So
we
have
full
control
and
we
can
either
say
that
this
port
is
going
to
be
plain
text,
because
there
is
nothing
sensitive
security
sensitive
well,
there
are
some
privacy
related
data,
but
we
can
also
specify
a
port.
J
A
tls
certificate
that
is
configured
in
conjunction
with
from
two,
so
prometheus
can
can
authenticate
and
do
its
own
stuff
without
having
to
do
the
crazy
stuff
we
are
doing
for
spf
and
other
support
in
in
promet
use.
K
K
H
K
J
No,
the
code
is
super
simple.
I
mean
it's
not
really
a
problem.
The
problem
is
we
in
our
in
the
configuration
we
are
generating
for
prometheus.
There
are
all
kind
of
stuff
that
I
don't
think
we
understand,
I
think
doug
probably
understands
them,
but.
I
D
J
Today,
we
are
not
doing
that,
I
mean
today
is
just
basically,
we
just
have
some
stuff
to
select
the
labels
or
whatever
to
do
to
get
the
endpoint
data
and
we
just
connect
to
employee
and
we
get
the
data
because
we
are
not
doing
anything,
fancy
on
and
voice
side.
We
just
expose
directly
to
the
environment,
and
if
we
aggregate
with
some
additional
data,
it
will
not
change
the
situation.
K
Actually
we
we
have
so
like
this
does
give
us
another
way.
I
mean
it
is
it's
sitting
there,
so
we
can
implement
whatever
the
hell
we
want
there,
but
it
actually
does.
I
K
Right-
and
I
I
understand
like
that-
that's
also
the
danger,
but
it's
also
the
opportunity
so,
for
example,
doing
filtering
right
that
doesn't
require
bootstrap
changes.
K
J
M
D
J
Thing
I
want
to
mention
there
is
another
aspect
of
this
is
which
is
health
health
reporting,
which
we
need
for
ingress
and
some
other
use
cases.
So
this
port
will
not
only
expose
slash.
Metrics
will
also
expose
fresh
health
and
will
also
allow
ability
to
to
to
expose
the
health
of
the
application
or
health
of
the
employee
or
or
that's
fine.
H
J
K
J
J
D
Let's
type
up
a
doc
because
I
feel
like
there
are
other
bugs
or
feature
requests
for
someone
to
ask
for
envoy
to
do
this
sort
of
thing
to
act
as
a
an
aggregator
for
application,
telemetry
and
trace
data
being
one
of
the
things
metrics
being
another.
So
there
may
be
something
we
could
do
there
too.
Yeah.
C
H
K
H
Standard
yeah,
so
I
think,
as
I'm
saying
these
like
it's
not
like
prometheus,
inherently
knows
that
right.
I've
never
seen
an
installation
of
prometheus
that
doesn't
scrape
those
labels,
like,
I
think,
every
pretty
much
every
prometheus
setup
does
and
for
the
very
few
that
don't
then
they
can
configure
it
themselves,
but
this
will
help
probably
99.
C
J
To
prometheus
saying,
multiple
ports,
if
I
would
be
prometheus
in
their
shoes,
I
would
say
that
this
doubles
the
load
on
prometheus.
Who
cares.
D
K
I
J
One
thing
is
clear:
we
can
do
this
combination
easily
and
and
we
can
ship
it
in
1
6
without
any
big
problem.
If
we
go
with
the
simple
and
maybe
with
with
open
sensor,
I
don't
think
is
there.
Is
anyone
has
concern
about
the
probability
of
implementing
it.
K
Like
a
bit
so
so,
I
think
I
think
that
if
we,
if
we
put
bounds
on
the
feature
set
and
the
complexity
of
the
code,
so
if
the
entirety
of
the
code
is
get
response
from
x,
get
response
from
y
concatenate
and
send
it
back
and
that's
10
lines
of
code
and
we
kind
of
commit
ourselves
to
not
adding.
You
know.
J
H
Open
census
scraping
it
on
demand,
or
is
it
doing
it?
I
don't
think
it.
J
But
we
should
use
whatever
the
application
scraping.
Is
I
mean
whatever
configuration
is
for
application?
Scraping
is
good
enough
for
employee
as
well.
I
suppose
I
mean
it's
user
control.
That's.
J
D
H
J
And
as
the
design
dock
will
get,
as
usual
out
of
scope
will
become
kind
of
of
rocket
science
for
concatenating
three
three.
I
J
L
The
only
thing
can
I
talk
about
one
suggestion,
rather
than
looking
at
open
sensors,
which
has
never
limited
life,
it'd
be
better
to
look
at
open
telemetry.
It's
not
stable.
D
Is
there
gary,
I
haven't
followed
the
transition
from
our
businesses
to
open
telemetry
very
closely.
Is
there
a
transition
plan
for
the
code
base,
or
is
it
a
completely
fresh
code
base
in
configs.
L
From
what
I've
seen
it's
main
it's
yeah
quite
fresh,
so
I
mean
they
have
ported
some
parts,
but
then
they've
updated
it
to
fit
in
with
a
new
set
of
specifications
so
yeah.
So
it
is
different.
L
K
D
I'll
put
my
name
in
as
a
placeholder
just
because
I'm
gonna
start
looking
at
some
prometheus
stuff
in
the
next
week,
but
welcome
to
other
suggestions
or
people.
Volunteers.
H
J
J
D
Way
back
in
1.1
or
1.2,
I
probably
I
was
publishing
them
to
grafana's
dashboard
location,
but
we
never
got
that
automated
so
that
it
would
happen
at
every
release.
H
B
Yeah,
I
almost
did
it
because
yeah
whatever
back
to
the
beginning
of
this
discussion,
can
can
someone
just
remind
me
what
the
big
win
is,
because
I
must,
I
think
I
missed.
I
missed
kind
of
the
whole
motivation,
yeah.
H
So
the
big
win
would
be
that
you
can
install
istio,
which
is
just
the
control
plane
inside
cars.
You
don't
have
any
of
the
add-on
stuff
and
you
already
have
a
premium
running
in
your
cluster.
It
just
works
out
of
the
box.
H
You
start
scraping
eastwood
things
the
dashboard
once
we
put
it
on
the
rafana
hub,
you
don't
need
to
install
our
istio
grafana
or
try
and,
like
you
know,
get
all
the
config
maps
mounted
all
that
sort
of
stuff
you
just
press
like
the
import
dashboard
or
whatever
the
button
is
called
and
things
just
work,
and
we
don't
need
to
manage
the
installation
of
all
these
add-ons.
H
Yeah,
so
this
would
mean
that
you
don't
have
to
do
stuff
for
observability
and
that
stuff
may
be
configuring,
your
prometheus
or
installing
our
own
prometheus,
which
is
kind
of
like
a
demo
install.
But
people
then
try
and
use
it
in
production.
Then
they
get
mad
at
us
and
then
we
have
to
maintain
it
all
sorts
of
issues
with
that.
H
That's
that's
a
possibility
yeah,
so
we
are
exploring
how
we
can
reduce
the
amount
of
stuff
we
manage
in
the
eu
installation.
Ideally,
from
my
point
of
view,
we
just
install
you
know
the
one
east
2d
control
plane
and
set
up.
You
know
the
gateways
and
side
cars.
H
The
add-on
doesn't
necessarily
need
to
be
bundled
with
that,
because
you
know
all
the
other
vendors
prometheus,
whatever
keoli
have
their
own
way
of
installing
it.
So
we
do.
I
mean
there's
ongoing
work
to
see
how
like
for
the
people
that
are
just
trying
to
demo
things,
and
they
just
want
everything
like
how
we
manage
that,
but
I
think
it's
it's
absolutely
doable.
H
So
that's
what
we're
working
on
environments,
that's
kind
of
the
context
I
mean
it's
obviously
across
working
group
concern
as
well.
J
So
so,
in
a
production
environment
I
don't
expect
anyone
is
for
should
be
running
our
installation
of
prometheus
that
so
we
we
hope
that
anyone
understand
and
unfortunately
many
people
do
not
understand
this.
It's
not
very
clearly
documented
that
ourselves,
so
we
we
want
to
integrate
with
what
people
use
in
production
and
that's
their
main
benefits
that
it
will
benefit
people
who
run
issue
in
production.
D
Yeah
yeah,
so
I
think
this
one
five
we're
gonna,
be
I'm
advising
people
to
run
a
istio
focused
prometheus
as
a
sort
of
aggregation
point
that
federates
into
their
production
prometheus.
I
haven't
finished
the
dots
on
that
or
started
them
really,
but
so
yeah.
We
need
to
make
sure
we're
all
in
sync
on
that,
but.
J
E
J
C
J
You
mean
because
some
posts
do
not
have
annotations.
J
D
C
And
just
so
j
one,
the
one
more
point,
so
the
customers
that
we
deal
with
currently
there's
a
lot
of
angst
around
when
they
get
their
own
prometheus.
They
don't
automatically
get
a
ster
metrics.
So
if
we
do
solve
this,
then,
as
soon
as
they
add,
is
to
your
aspen
mesh,
the
same
prometheus
will
now
have
is
geometrics.
B
Yeah
yeah,
no,
I
mean
I
can
see
that
aspect
of
it.
If
there
was
some
way
to
still
have
some
sort
of
demo
profile,
it
would
be
very
useful.
I
think,
because
you
know
it
can
be
very
good
for
production,
but
maybe
it
just
makes
things
a
little
harder
potentially
for
people
trying
to
test
things
out.
J
For
demo,
you
can,
just
you
know,
have
a
shell
script
that
is
deploying
the
prometheus
operator,
whatever
they
recommend
by
default
and
just
use
it,
but
it
will
be
still
be
simpler
because
you
just
use
whatever
instructions
promise.
You
says
with
a
script
or
whatever,
and
then
we
don't
have
to
customize
or
have
deltas
between
and
have
to
learn
our
way
of
doing
things
versus
the
official.
D
B
Not
on
this
topic,
not
really
I
mean
okay,
I
just
will
wait
and
see
how
it
goes,
but
we
just
want
to
make
sure
that,
obviously,
obviously
being
from
the
kiali
team
we're
curious
about
what's
going
on,
we
just
wanted
to
make.
We
want
to
make
it
still
as
easy
as
possible
for
kiali
to
work
with
with
istio
right.
D
D
The
the
next
thing
I
wanted
to
raise
in
this
working
group
and
we're
sort
of
running
out
of
time,
but
we
have
enough
time-
is,
I
noticed,
a
large
number
of
github
issues
and
things
on
discussion
forums
and
I've
been
asked
directly
on
slack
a
lot
about
policy
related
issues,
so
ip
white
listing
not
working
rate
limiting
concerns
people
having
issues
with
all
the
different
mixer
adapters
for
policy,
and
that
is
not
getting
any
attention
and
I
don't
know
what
we
want
to
recommend
or
do
for
one
five
or
how
we
want
to
change
course
for
one
six,
whether
or
not
it
should
be
prioritized.
D
C
D
Right,
like
the
code,
is
sort
of
languishing.
These
issues
are
staying
open.
It's
not
been
a
high
priority
to
fix
or
address
them
or
even
answer
customer
concerns,
and
so
we're
in
sort
of
a
limbo
state
waiting
for
v2
to
start
working
on
policy
and
v2
like
what
do
we
want
to
do?
D
C
D
K
So
so
we
we
are
deprecating
mixer
in
one
five
right,
which
means
that,
like
bug,
fixes
would
still
are
okay
now
so
for,
for
example,
I
think,
or
someone
just
recently
had
had
a
bug
fix
in
mixer.
I
think
you
you
had
one
very
recently.
D
Yeah
so,
and
it
comes,
there
was
a
pr
changing
docs
on
the
website,
and
you
know
one
of
the
things
I
was
saying
is:
maybe
we
don't
advertise
policy
on
the
website
for
a
while?
Maybe
we
like
how
do
we
reflect
the
reality
that
it
is
a
p2
for
the
large
majority
of
contributors
you
know
is
being
starting
to
pick
up
and
ren
you're,
seeing
usage
ramp
up
by
users
in
the
using
comm
user
community.
I
I
just
feel
uncomfortable
with
the
disparity
between
number
of
incoming
issues
versus
number
of
closed
issues.
C
This
is
open
source
right,
so
we
should
encourage
them
to
submit
prs
if
they
want
to
fix
them
and
maintain
it
right.
I
mean
I'm
just
trying
to
say
that
your
company
needs
it
that
bad
at
some
point,
you
need
to
contribute
right.
D
I
D
Okay,
well,
I
don't
want
to
beat
this
to
death.
I
just
it's
just
something
I
noticed
and
I
wanted
to
get
comments
on
and
the
other
thing
the
last,
which
probably
was
something
we
should
have
spent
the
most
amount
of
time
on.
Is
we
don't?
We
don't
have
any
road
map
items
for
one
six?
D
So
I
link
to
the
extensions
roadmap
doc
and
then
you
know
it's
blank,
so
lucky
you
yeah.
So
I
don't
think
that
that's
gonna
work
on
friday
when
the
toc
goes
to
review
the
road
map.
D
So
I
encourage
everyone
to
sort
of
add
things
that
they
think
are
important
for
one
six
in
the
extensibility
and
telemetry
areas
and
policy
too,
and
I
will
try
and
do
a
pass
thursday
night
to
get
this
in
some
shape
for
sharing
but
yeah
as
you
can
see,
and
we
actually
did
a
pretty
good
job
with
our
1.5
p
zeros.
D
D
K
Yeah,
I
think
the
request
classif
classification
is,
is
one
big
one
I
think
yeah.
We
can
just
just
go
through
the
issues.
We
have
kind
of
filed
issues
whenever.
C
J
K
I
K
That
should
be
the
higher
priority
item
for
one
year,
so
I
think
I
think
telemetry
can
for
conformance
testing.
I
C
How
about
distribution
of
webassembly
from
users
to
extend
envoy.
C
C
Maybe
do
you
know
the
usage
of
auto
mtls,
none
of
our
customers
use
it.
Just
being
very
honest,
wait
you
your.
K
Customers
don't
use
mtls,
auto
mtls,
oh
auto
mtls.
Well,
it's!
It
was
opt-in
right
now,
with
with
one
five
with
with
one
five.
It
is
not
opt-in,
anymore.
K
C
K
C
Customization
I
know
quad
has
been
talking
to
jacob
about
it.
How
do
we
do
that
easily
yeah?
Is
that
part
of
this
group
or
networking?
I
don't
know.
C
K
K
I
would
say
that,
yes,
the
networking
p
people
should
be
involved
and
everyone
else
should
be
involved.
If
we
need
customizations
for
telemetry
to
start
with,
then
we
can
drive
it.
I
mean
it
doesn't,
but
we
just
have
to
make
sure
that
everyone
is
aware
and
like
on
board
with
whatever
is
being
proposed.
C
Okay,
so
basically,
what
we
should
do,
then,
is
for
one
sixth
customizing
v2
telemetry
should
be
the
high
level
objective
and
then,
as
part
of
that,
customizing
bootstrap
has
to
be
done
right.
I
That
is,
you
know:
open,
ended,
yeah
that
yeah,
that's
there's
some.
C
D
I
D
Okay,
I
think
we
thought
that
testing
was
a
p0
as
well
looks
like
it
and
request
path.
Classification
jumped
up
is
there
anything
else
that
we
think
is?
K
So
so
the
so
the
issue
now
is
that
so
so
far
we
have
been
sort
of
shielded
because
our
things
were
not
configurable
and
we
didn't
really
expose
any
configuration
artifacts,
but
as
we
are
exp,
we
are
going
to
expose
configuration
artifacts.
So
so
the
goal
for
1
6
is
that
we
cannot
continue
to
configure
the
extensions
with
onward
filter
api
in
the
way
it
exists.
K
Api
already
has
issues
of
like
not
being
able
to
order
things
properly
like
we
have
had
to
jump
through
hoops
even
now
and-
and
there
is
the
extension
api,
whatever
doc.
That
goes
through
the
details
of
what's
missing
and
all
that.
So
we
need
to
tie
that
and
actually
like
deliberate
in
in
one
six
because
yeah,
because
I
I
don't
think
we
can,
I
don't
think
we
can
continue
just
supporting
onward
filter
in
perpetuity.
It
was
fine
for
now
to
get
started
and
actually
to
deliver
function,
but
anything
more
than
that.
K
K
Yeah
yeah
yeah,
of
course
it
yeah
this.
This
api
will
have
to
go
through
toc
and
and
louis
has
been
involved.
Okay,
I.
C
Know
yeah
there's
just
one
other
request
that
we
have
from
our
customers,
which
again
we
currently
solve
through
envoy
filter,
but
we
will
like
a
high
level
api
in
sdo,
which
is
adding
and
customizing
tracing
headers.
C
Basically,
they
need
to
add
a
tracing
header
which
can
be
quoted
in
the
spans,
based
on
request
incoming
request,
headers,
so
tracing
tags.
I
should
have
said.
C
Need
it
it's
already
part
of
onward
api
now
and
we
can
use
onward,
filter
api
to
add
it,
but
it
will
be
good
to
have
an
istio
api
right.
K
Okay,
so
so
more
more
first
class
api,
okay,
I
I
think
we
should.
We
should
add
that
it
it
it's
going
to
be
an
interesting
discussion
as
to
where
does
it
belong
because
the
I
I
think,
I
think
that
having
it
belong
to
an
extension,
probably
makes
sense.
I
I
see
why
maybe
you
extensions
so
far
have
been
focused
on
filters
and
filter
like
things
so
you
raised
a
very
interesting
question:
yeah.
I
K
Then,
but
the
question
is:
do
we
now?
So
if
we,
if
we
say
that
tracing
is
a
fundamental
part
of
the
whole
thing,
then
we
can
just
stick
it
there.
But
at
some
point
we
have
to
start
saying
that
oh
the
stuff
is
in
extensions
and
we
cannot
just
keep
on
adding
more
stuff.
But
maybe
tracing
is
so
fundamental
that
we
put
it
in
virtual
surveys
and
no
problem.
K
So
but
so
whoever
is
tapping
it
can
we
add
this
also
to
the
to
the
list.
What
would
you
like
me
to
add
to
treating
configurability,
I
mean
we
have
some
api
and
doug.
You
have
you
you
have
that
one
dog,
I
don't
know
how.
D
I
mean
so
the
the
feedback
I
got
back
at
the
time
and
then
gary
was
on
this
effort
as
well
was
that
we
were
explicitly
directed
away
from
doing
anything
new
and
we're
told
to
use
envoy
filters.
We
can
re-raise
that
and
resurface
sort
of
previous
attempts
to
have
a
full-featured
api,
but.
D
K
Stoner
has
some
issues
related
to
this
as
well.
I
would
I
would
say
that
that
ins,
so,
okay,
I
think
a
better
way
to
go
about
that.
That
particular
problem
is
to
add
those
requirements,
and
then
we
can
decide
whether
those
requirements
are
better
satisfied
by
a
more
abstract
extensions
api
or
we
need
the
detailed
xds
patch
api,
which
is
what
what
onward
filter
is,
rather
than
framing
it
as
we
want.
We
want
onboard
filter.
D
Right
so
I
mean
yeah,
that's
fine!
We
can
talk
about
this
another
time,
but
I
mean,
like
part
of
the
issue,
was
that
a
lot
of
the
control
ended
up
looking
exactly
like
the
segments
of
ongoing
config,
so
it
wasn't
really
abstract
in
any
real
sense,
but
we
can.
We
can
talk
about
that
as
we
move
forward.
D
Okay,
well
we're
past
time,
so
I
think
we
should
probably
stop
all
right
I'll.
Take
it
past
this
and
then
add
people
in
friday
morning,
maybe
maybe
thursday
night,
depending
on
my
days
to
get
final
approval
or
edits
on
this.