►
From YouTube: Policies and Telemetry WG Meeting - 2020-07-15
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
Yeah,
so
I
I
want
to
bring
up
something
from
from
the
extensions
api
and
yeah
and
specifically
regarding
on
the
word
filter.
So
let
let's
discuss
that
when.
B
B
Okay,
I'll
find
it
so
the
so
what
one
of
the
options
that
like
that
now,
I'm
again
seriously
considering
and
sriram
who
is
not
on
this
call,
is
strongly
supporting.
It
is
that
we
just
fix
the
parts
of
the
onboard
filter
api
that
need
to
be
fixed
so
so
for,
for
example,
there
are
three
main
things:
one
is
relying
on
name.
So
if
you
scroll
down-
and
there
is
like
one
section
that
that
goes
through
what
are
the
issues
with
onward
filter
api.
B
Tell
me
when
I
yep
scroll
down
further
okay,
so
examination
that
that
has
some
details,
but
but
you
can
you
can
scroll
down,
that's
that
has
the
details
which
I
think
we
will
have
already
read.
But
now,
if
you
go
down
a
little
bit
further,
yes,
okay,
so
that
that's
okay,
so
essentially
augmenting
the
unwanted
gps.
So
the
issues
today
with
onward
filter,
which
does
a
whole
bunch
of
things,
xds,
patching
and
stuff,
are
difficulty
in
upgrades
because
it
relies
on
unstable
names.
B
There
is
a
lot
of
boilerplate
config
and
code
and
it
it
seems
normally
like
a
very
low
level
api,
and
then
there
is
some
difficulty
in
connecting
changes
right.
So
the
these
are.
These
are
the
top
three
issues
that
we
have
with
onward
filter
api
and
the
other
proposals
were
trying
to
address
this
and
then
also
do
some
some
other
things.
B
So
on
one
side
there
is
a
specific
telemetry
api
proposal,
and
then
we
we
have
also
discussed
or
have
the
desire
to
have
a
wasm
specific
proposal,
then
creating
yet
another
api
in
the
middle
is
so
that's
like
that's
the
part
that
at
least
I'm
I'm
reconsidering
now,
because
if
we
can
get
onward
filter
api
to
a
shape
where
it's
upgrade
safe,
like
does
these
three
things
in
my
mind
right,
you
begin
canary
things,
remove
some
of
the
boilerplate
and
doesn't
rely
on
names
unless
it's
like
absolutely
necessary,
or
there
is
no
other
way.
B
We
then
we
don't
introduce
a
new
api
for
forward
or
backward
reference,
but
just
fix
in
place
and
only
concentrate
on
the
higher
level.
Apis
in
terms
of
new
api
introduction
and
what
it
essentially
does
is,
if
you,
if
you
look
at
the
other
proposal,
that
that
quad
had
right,
so
this
essentially
adds
aspects
of
that
to
onward
filter.
So,
basically,
all
the
filters
will
now
have
associated
functions
right
so
telemetry
pre-processing,
art
and
post-processing.
B
B
And
we
don't,
we
don't
need
those
to
be
that
small
either.
So
these
are
the
fours
that
were
proposed
in
the
in
the
other
api,
but
actually
we
can
have.
We
can
have
them
slightly
more
granular
than
that.
So,
specifically,
what
I'm
proposing
is
that
we
also
have.
We
also
have
functions
that
are
for
built-in
filters
that
are
injected
by
the
control
plane
directly
right,
so
aussie
filters
are,
are
a
clear
example
of
that
that
are
just
inserted
by
control
plane.
B
Now,
if
we
add
that
as
an
enum,
then
that's
part
of
the
api,
and
now
you
can
clearly
say
that
insert
my
filter
right,
so
we
we
will
specify
the
order
of
our
enums,
and
now
you
can.
You
can
specify
where
you
want
your
filter
to
be
in
in
what
what
function
within
a
function,
the
the
the
order
is
unspecified
because
they're
they're
considered
independent
filters.
B
So
the
idea
is
that
now
you
can
rely
on
enums
and
you
need
to
go
back
to
specific
patching
behavior
only
in
very
very
specialized
cases,
and
as
long
as
you
rely
on
enums,
you
should
be
upgradable
because
a
filter
doesn't
change
its
function
from
one
version
to
another.
If
it
was
a
pre-author
before
it
will
remain
so
it
will
remain
so
later.
B
The
the
boilerplate
code
are
actually
like
much
simpler
changes,
especially
for
http
filters.
If
you
look
at
http
filters,
it
has
this.
We
specif,
we
say,
apply
to
http
filters,
but
then
we
still
ask
people
to
write,
http
connection
manager
and
sometimes
even
ask
them
to
to
write
like
onboard
router
right.
So
all
these,
so
this
can
actually
just
be
solved
by
adding
some
more
smart
defaulting
behavior.
B
So,
if
you're
applying
to
http
filter,
you
don't
need
to
specify
http
connection
manager
like
there
is
no.
There
is
no
need
to
go
to
to
that
level
and
then
canarying
changes
which
is
which
is
semi-supported
today,
but
not
not
quite
right
to
canary
changes.
B
You
need
several
levels
of
replace
semantics
right
which
which
which
are
missing
from
onboard
filter
today,
so
you
can
have
replace
semantics
of
three
different
levels.
B
B
If
you
have
the
requirement
to
completely
specify
your
own
filter
chain,
you
should
be
able
to
do
that
and
then
you
just
say
I
don't
care.
What
else
applies
to
me
if
I
have
specified
so
if
I've
specified
the
most
specific
match,
which
is
like,
let's
say
my
canonical
service
mat
or
my
workload
match,
then
just
replace
up
essentially
you're,
fully
specifying
the
filter
generator
like
doesn't
matter
what
other
things
are,
and
then
there
is
the
replace
by
name.
But
this
time
the
name
is,
is
specified
in
the
root
name,
space
itself
right.
B
B
So
in
that
case,
what
what
we
would
do
is
we
would
have
in
the
root
name
space
we
will
have
an.
We
will
have
an
attribute,
gen
filter
defined
with
whatever
name
the
administrator
chooses
now
right.
They
can
call
it
open
apr
whatever
else
they
did,
they
want
to
call
it
and
then
every
workload
scoped
envoy
filter
can
just
provide
an
implementation
of
that
attribute
gen
filter.
B
B
So
if
you
look,
if
you
look
at
the
requirements
that
we
had
specified
before,
this
is
able
to
model
canarying
behavior
of
connecting
new
versions
of
filters.
New
versions
of
extensions
while
maintaining
like,
while
still
making
it
possible
within
the
api
and
not
just
entirely
pushing
it
down
to
ci
cd.
B
So
so
what
I
so
I
think
what
I'm
looking
for
here
is
some
some
serious
discussion
about
where
we,
what
like
so
essentially
the
the
first
important
point,
is
that
do
we
want
to
continue
with
with
the
new
kind
of
api
or
do
we
want
to
fix
envoy
filter
api
where
it
is
and
then
just
concentrate
on
the
much
kind
of
much
higher
level
apis,
so
that
so
that's
the
like.
That's
the
first
opinion
point
that
that
I'm
really
looking.
C
C
So
mandar
from
my
point
of
view,
if
you
can
fix
an
existing
api
to
make
it
more
extensive
and
usable,
we
should
do
that.
That's
just
makes
common
sense.
I
thought
onward.
Filter
was
unfixable
but
looks
like
you,
and
some
other
folks
have
done
some
research
to
make
it
so
that
that's
not
the
case.
I
think
that's
a
great
idea
why?
Why
make
another
api,
when
you
can
make
this
more
usable.
B
Right
so
so,
so
I
think
the
I
haven't
added
add
enough
enough
cons
here.
The
api
service
of
onward
filter
api
itself
grows
right
because
pretty
much
everything
listed
here
is
a
new
facet
to
the
api.
B
But
yes,
as
a
as
a
whole
api,
we
haven't
added
like
a
whole
new
whole
new
top-level
api,
so
so
yeah
I'm
what
I
mean.
What
do
so?
Okay,
that's
that's
good
to
know.
I
I
I
will.
I
will
actually
like
have
a
draft
api
apr
where,
where
we
can
discuss
the
the
details
of
of
this,
but
any
anyone
else.
D
C
B
So
so
what
so,
which
so,
okay,
what
we
could
do
is
which,
which
specific
part
in
the
in
the
requirements
do,
you
think,
is
unfixable
with
what
we
have.
D
When
we
move
from
one
representation
to
another
representation
like
it
happened
to
filter
chains
in
listeners,
virtual
service
survived
that
transition,
because
it
did
not
reference
those
things
but-
and
I
feel
that
it
just
by
necessity,
has
to
reference
one
of
those
things
so.
B
Okay,
I
I
mean
I,
I
understand
what
what
you're
saying,
but
using
using
functions
and
using
other
primary
attributes
right
so
pore
and
other
things
which
are
which
are
kind
of
more
fundamental
to
decide
the
placement
of
filter
and
then
using
filter
functions.
D
Oh
so
yeah
yeah,
I
filter
functions,
actually
try
to
classify
existing
native
extensions
in
way
and
they
simply
don't
fall
into
that
categorization
because
they
just
do
everything
at
once.
Many
of
them,
if
you
take
any
single
filter
they
it
tends
to
do
off
and
telemetry,
for
example,
together
and
it's
very
difficult
to
insert
functions
in
between
those
two
steps.
B
D
C
And
and
there's
another
interesting
point
here,
which
is
even
if
you
add
these
functions
based
placements,
you
will
have
some
pieces
of
this
api
which
can
be
promoted
to
beta
and
then
some
pieces
of
the
onward
filter.
Api
can
never
be
promoted
to
beta.
So
as
a
whole.
This
api
will
never
get
to
a
production
usage
quality,
because
the
reason
what
quartz
is
mentioning,
if
you
still
allow
arbitrary
patching
of
xts
fields
by
definition,
you
cannot
make
them
upgrade
stable
right.
C
There's
no
way
to
do
that,
because
the
same
resource
will
just
not
work.
B
Right
but
but
but
all
the
new
parts
of
the
api
that
we're
proposing
here
right,
we're
not
act
like
we're
explicitly,
not
letting
you
patch
anything
we're
just
so
you
can
just
replace
things.
I
agree,
you're.
Actually
we're
actually
saying
that
there
won't
be
any
merge.
So
so
I
guess
the
the
the
mapping
of
what
god
just
mentioned
of
mapping
of
existing
extensions
or
existing
filters
into
one
of
these
functions.
A
What
what's
the
recommendation
going
to
be,
though
right?
Are
we
going
to
recommend
that
people
touch
angular
filter
at
all,
or
is
it
always
going
to
be
hey
use
the
higher
level
apis,
which
we
can?
We
will
have
some
controller,
that's
generating
downward
the
right
envelope,
filter
for
the
right
version
of
everything.
Yes,
so
so.
B
Okay,
that's
a
that's
a
that's
a
great
point.
Yes,
I
mean
in
my
mind
and
which
is
what
pushed
me
towards
this
is
that
the
higher
level
telemetry
api
and
the
and
the
the
wasm
based
api,
which
abstracts
some
of
the
like
the
wasm
areas
out,
is
what
we
would
expect.
We
would
push
people
towards
using
directly.
B
So
so
there,
so
there
is
a
so.
There
is
a
difference
between
like
runtime
support.
What
api
does
the
runtime
support
and
what
api
does
like
just
tooling
support
right.
So,
if
runtime
supports
online
filter
api,
then
they
can
build
as
much
tooling
as
we
want
around
other
apis.
That
finally,
finally
makes
it
only
compiles
it
down
to
all
workflow
api.
F
I
would
love
some
insight
into
how
I
might
write
an
analyzer
to
tell
people
if
they're,
using
like
names
like
like
http
filter,
that
they're
changing
or
how
I
can
tell
people
if
they
have
an
old
envoy
filter,
what
the
new
replacement
is.
B
That's
a
that's
a
great
point
and-
and
I
think
those
things
are
are
most
definitely
possible
like
we
yeah,
we
haven't
done
it
yet,
but
but
those
things
are
are
absolutely
possible
so
essentially
also
calling
out,
like
a
onward
filter,
linter
right,
which
calls
out
the
safe
usage
and
unsafe
usage
of
onward
filter.
F
C
I
I
think
so
ed,
that's
an
existing
issue
already
so
yeah.
If
we
change
onward
filter,
we
should
make
sure
we
fix
the
usability
and
the
analyzer
piece
collectively,
but
if
the
stable
interface
is
a
higher
level
api,
then
why
not
just
augment
the
control
plane
to
create
the
xds?
You
want.
What's
the
value
we
are
adding
by
changing
onward
filter
at
this
point,
then.
B
Right:
okay,
that's.
C
B
A
So
if
we
so
we
need
something
that
is
better
for
distributing
and
managing
extensions
right.
We
need
that
in
a
nearer
term
than
another
release
cycle
of
design.
So
to
me
it
seems
like
patch
or
fixing
envoy
filter.
Api
is
worthy
goal
in
and
of
itself,
and
then
maybe
we
reassess
at
the
end
of
that
process
where
we
stand
and
whether
or
not
we
need
another
layer
or
another
extension,
is
that
that
the
thinking
you're
having
raj
as
well.
C
I
totally
agree,
I'm
just
making
sure
mandar
realizes
that
if
he
comes
on
one
eight
and
says
hey,
let's
promote
this,
he's
gonna
get
a
lot
of
pushback
from
other
tlc
members.
That's
the
only
thing
I'm
trying
to
say
here
but
yeah
as
an
incremental
step.
This
totally
makes
sense.
B
B
We
can
have
discussion
about
it
early
and
then
later.
B
So
so
yeah
so
the
so.
The
related
thing,
then
here
is
that
in
order
to
complete
a
usable
extension
story
right
off
so
so
right
now,
extensions
have
to
be
fetched
over
a
url
right,
awesome,
extensions
that
have
to
be
faced
over
url
and
it
has
a
few
modes
of
of
failure,
but
it
is
still,
it
is
still
possible.
B
Quad
is
working
on
the
filter,
config
discovery
service
and
once
that
gets
into
like
proper
use
right,
I
think
that's
when
the
whole
story
will
be
usable
even
from
a
low
level
api
standpoint,
so
so
convergence
of
this-
and
that
is
the
is
the
next
or
actually
a
concurrent
step.
B
So
the
so
the
next
step
here,
then,
is
oh
I've
already
taken
half
an
hour
next
step
here
is,
I
will
have
an
api
pr
and
of
course
I
mean
I'll
work
with
quad
on
all
the
specific
things
and
of
inability
to
classify
and
and
whatnot,
and
then
see
what
what
the
pr
looks
like.
C
Just
one
thing
for
this
mandar
I
would
say
I
don't
know
how
much
you
want
to
put
it
in
one
seven
versus
like
a
follow
on
in
one
eight,
as
in
trying
to
get
new
fields
and
canary
I
mean
we,
we
have
only
like
what
two
weeks
left,
so
that
might
be
too
much
to
bite.
Even
if
you
get
the
new
fields
in
the
api
without
canary,
I
don't
think
it's
a
feature
loss,
so
it
might
be
acceptable.
C
A
Okay,
so
I
was
the
next
thing
I
put
on
the
jindos.
I
I
think
we
need
to
go
over
where
we
stand
on
our
1-7
items,
because
I
was
trying
to
populate
the
the
status
for
the
working
group
leads
meeting
yesterday
and
I'm
concerned
that
we
haven't
made
enough
progress
anywhere.
A
So
maybe
I'm
just
not
thinking
correctly,
so
I
wanted
to
go
through
it,
so
I've
linked
the
ones
that
sort
of
the
high
level
things
from
our
road
map
and
let
me
share
the
tab
so
like
for
enable
extensions
ecosystem.
There's
these
these
are
all
the
open
items.
Do
we
feel
that
we've
provided
a
good
extension
distribution
mechanism,
design
and
implementation
at
this
point?
B
A
Okay,
do
we
have
documentation
for
any
of
the
work?
That's
been
done
available.
B
B
Okay
and
that's
that
that
doesn't
have
to
be
done
by
the
code.
Freeze,
though,
right
that
the
documentation
I
mean
that
part
can
follow
next
week
or
whatever.
A
A
Okay,
the
next
thing
was
designed
to
long-term
telemetry
apis,
so
I
think
we
just
spent
a
while
talking
about
the
extensions
api.
A
These
latter
two,
I
mean
we
have
the
proposal,
the
rfc
sort
of
in
a
funny
state-
and
I
know
that's
on
me
to
push
more
on
that
and
I
know
there's
some
people
here
who
have
added
some
some
good
comments
recently.
So
is
there
anything
else
that
we
think
we
should
do
other
than
keep
pushing
on
that
or
you
know
a
renewed
push
on
the
telemetry
api?
A
So
I
think
the
goal
for
one
seven
for
this
was
to
have
a
plan
like
to
have
the
finalized
design
right.
So
we
could
start
the
one-eighth
cycle
with
implementation
or
the
last
vestiges
of
approvals
and
implementation,
and
so
some
of
that
can
like
it's
unaffected
by
code
trees,
but
it's
still
work.
That
has
to
be
done
and-
and
I
know
we
were
supposed
to
have
side,
design
meetings
and
things
and
those
slipped
and
we
didn't
have
them.
A
D
I
think
it
would
help
to
have
a
list
of
blockers
that
allow
us
that
we
need
to
start
first
in
terms
of
run
time
and
anyway
or
things
like
you
know
whether
you
can
change
things
at
one
time
versus
at
startup
versus
at
the
installation.
Time,
for
example,
tracing
diver
being
applied
dynamically
rather
than
hard
coded.
A
A
Sorry,
I
was
muted.
The
next
big
item
was
improve
operational
excellence
and
I
have
started
adding
some
of
these
tests
for
both
of
the
p0s.
Has
anyone
looked
at
cni
or
negative
tests.
G
G
I
know
that
I
think
j
j,
j
shaughnessy
was
reporting
some
issues
that
I
know
other
people
are
looking
into
kind
of
around.
I
know
they
do.
I
think
it's
related
to
openshift,
but
I'm
not
quite
sure.
I
don't
know
if
he's
on
that
call.
H
Yeah,
I'm
on
the
call
so
right
now,
I'm
not
aware
of
anything
that's
affecting
telemetry,
specifically
due
to
cni.
So
I
think
that
was
cleaned
up.
I
think
so,
but
yeah
so
cni
is
is
enabled
by
default
on
with
openshift,
which
is
where
I
do
all
pretty
much
all
my
stuff.
H
A
Okay,
so
it
sounds
like
you
know:
we've
got
at
least
some
manual
testing.
That's
been
ongoing,
it's
doing
validation
there.
Okay,
all
right.
Let's
see
the
next
thing
was
v2
transition
enable
full
v2
transition.
You
know
we
have
a
report
or
sorry
request.
Classification
did
we
do
anything
regarding
non-mesh
destinations
and
lookups
is
any
work
proceeded
proceeded
there?
C
Is
this
the
one
that
I
think
I
was
supposed
to
work
on
right?
Yes,.
F
C
B
C
B
C
Okay,
all
the
pieces
are
available.
Okay,
so
I
would
just
say
it
won't
be
done
for
one
seven.
The
best
I
can
do
is
we'll
start
I'll
start
an
rfc
and
I'll
get
comments
from
you
and
other
folks
in
the
group,
but
I
mean
our
dashboard
is
right
now
not
working
with
v2.
So
for
me
to
spend
time
to
get
you
know.
Non-Mesh
pieces
is
a
little
difficult.
A
Okay,
I
think
similarly
there's
work
on
their
way
to
to
write
the
shim,
the
oop
attack
or
right
for
off
and
and
actually
even
telemetry
adapters
using
x,
xl
and
access
logs.
But
I
don't
know
if
that's
gonna
be
done.
Peter
yeah,
I
I
yeah.
I
doubt.
I
A
Well,
yeah,
I
mean
what
I
what
I'm
thinking
is
now
looking
over
this
and
the
work
that
hasn't
been
done.
I
got.
I
don't
know
that
we've
met
the
bar
to
delete
mixer
and
one
eight,
which
is
what
I'm
I
wanted
to
raise
here,
because
I
I'm
fairly
concerned
about
that.
D
I
Is
not
tooling
it's
a
mixer
server
change,
so
we
decided
not
to
do
it.
Do
it
without
tool
but
instead
just
add
the
support
for
externality
and
the
access
log
api
support
into
the
mixer
server
yeah.
That's
fine.
A
I
I
start
to
prototype
support
for
those
two
I'd
like
solution
for
those
two
issues,
but
it's
just
inherently
hard
with,
like
the
web
assembly,
api,
the
nature
of
five
assembly
ap
api
and
like
where's,
that
system
the
complication
there
so
yeah.
But
I
mean
I'm
I'm
starting
to
make
progress.
But
I
don't
I
don't
and
I
I
don't
think
we
will
make
one
seven
as
well.
B
C
So
the
bucket
customization,
in
my
opinion,
I
don't
think
there
were
many
usage
of
it.
That
is
one
of
the
things
that
we
are
changing
on
our
side
to
be
compatible.
That's
why
our
dashboard
is
failing.
I
don't
know
if
anyone
else
relies
on
it.
Maybe
we
can
live
with
the
that
whatever
you
get
is
default
and
maybe
in
one
eight
will
add
back
customization,
but
if
it's
too
hard
like
peter
is
saying,
I
don't
know
how
much
complexity
you
want
to
add
because
of
that
functionality.
C
A
A
B
What
are
we
not
achieving
by
kind
of
keeping
mixer
there
for
another
release
right
in
in
terms
of
well
in
terms
of
build
and
tests
that
run
and
and
whatnot,
and
then
on
the
on
the
other
side?
If
we
do
remove
it,
what
is
the
we
do?
Remove
it
with
these
caveats,
then,
what's
the
like?
What's
the
cost
that
some
of
our
users
will
have
to
pay.
A
Right
about
I
mean
the
only
thing
we
know
is
there
have
been
requests
to
find
out
when
it's
fully
going
away,
but
I
don't
know
if
that's
a
good
proxy
or
not
for
a
number
of
people
actually
using
it.
I
So
the
other
point
is
that
there
there
are
definitely
people
that
are
using
mixer,
like
the
hydro,
autopsy
adapter
or
like
other
functionality,
and
the
problem
for
them
is
how
to
make
the
transition
into
the
new
model,
and
we
don't
have
the
extension
api
yet,
and
I
mean
so.
We
don't
have
a
like
a
very
good
story
for
people
who
are
looking
for
transition.
I
I
mean
not
only
the
p0s
released
it
there,
but
people
will
need
a
need.
Some
guide
on
how
they
migrate
to
the
muslim
world,
either
the
api
or
more
document
that
they
want.
Some
programming
which
we
are
currently
we
currently
don't
have
so.
G
This
at
least
like
my
thoughts
on
this
right
now,
if
you're
trying
to
transition
over
you,
don't
know
what
the
the
kind
of
the
missing
gaps
are.
You
have
to
look
through
github
issues,
or
you
know
various
pages
on
istio
io
to
kind
of
like
figure
like
what
are
the
things
that
I
could
do
that
I
can't
do
you
know.
I
think
one
thing
that
we
need
is
at
least
documentation.
G
Like
you
know:
here's
mixer
v2,
you
know
here's
the
benefits
you
know
here
are
the
missing
gaps,
I'm
kind
of
coalesced
into
one
single,
you
know
page
and
then
you
know
at
least
kind
of
have
it
more.
As
a
user
guide
of
like
you
know,
here's
how
you
can
transition
because,
right
now
you
know
the
documentation
is
very,
not
user
focused.
I
guess
it's.
It's
very
implementation
focused,
and
so
I
think
it's
it's
difficult
for
people
to
make
that
like.
How
do
I
make
that
leap?
G
You
know
and
kind
of
trust
that
this
is
going
to
work.
The
way
that
I
have
and
kind
of
know
the
associated
trade-offs.
C
A
Okay,
so
that
might
be
something
I
need
to
raise
at
the
tocc.
A
A
A
I
Yeah
for
at
least
for
the
exposing
away
generous
stats,
I'm
conducting
some
experiment
on
it.
I
mean,
but
I
haven't
got
the
final
result
yet,
but
like
the
preliminary
result
doesn't
seems
like
not
very
good.
I
mean
I
don't
see
much
improvement,
especially
for
finding
fan
out
proxy
but
yeah.
I
I
I
need
to
do
more
testing
on
it
which,
which
one
is.
Is
this
feature?
I
Sorry,
so
the
consider
exposing
all
and
what
generators
that's
bad
before
yeah
yeah
and
it
especially
at
ingress
yeah.
So
this
one's
like
very
bad
yeah,
so
yeah,
maybe
like
there's
our
other
considerations
that
maybe
we
should
not
avoid
on
gateway
but
invoice
for
other
proxies,
which
doesn't
have
as
much
as
a
clock
cluster
as
ingress,
but
yeah
the
measurement
hasn't
been
down.
So
that's
the
current
progress
there.
I
A
The
final
thing
I
think
we
were
talking
about
adding
a
tool
and
ed.
I
know
you've
looked
at
this,
do
we
feel
like
we're
in
a
good
place
here,
or
we
need
a
lot
more
work
on
detecting
and
warning
about
mixed
uses
just
related
to
the
earlier
conversation.
F
I
am
happy
to
help
anybody
with
detecting
mixer
resources.
I
don't
know
which
ones
are
removed
or
what
I
should
be
doing
to
check
them.
F
A
A
Okay,
well,
sorry
for
dragging
through
all
that,
but
I
was
just
growing
concerned
about
where
we
stood.
So
I
wanted
to
make
sure
I
was
in
sync
with
the
work.
I
don't
have
anything
else
and
I
know
we're
coming
up
against
the
timeline.
Is
there
something
else
that
anyone
wants
to
raise.
H
J
J
H
Yes,
if
I,
if
I
can
share
I
let
me
try.
H
Okay,
so
this
is
a
little
demo
that
we
have
it
simulates
some
travel
applications,
so
you
can
kind
of
see
that
you've
got
these
travel
portals
and
it
makes
requests
for
travel
reservations
and
it
goes
through
and
it
gets
hotels
and
flights
and
cars
and
things
like
that,
and
so,
if
you're
unfamiliar
with
kiali,
the
triangles
are
like
services
and
the
squares
or
apps
app
or
application
versions.
So
this
is
like
you
know,
hotels
version
one.
So
you
get
a
request
from
travel's
version.
H
One
workload
goes
to
the
asking
for
the
hotel
service
and
it
gets
routed
to
the
v1
of
the
hotel's
workload
and
so
forth.
So
request
classification
is
experimental
in
one
six,
but
we
wanted
to
jump
on
that
because
it's
a
pretty
neat
feature,
and
so
now
there's
this
option
that
if
you
were
to
go
ahead
and
actually
have
configured
in
sdo
by
adding
the
request
operation
attribute
to
the
metrics,
you
are
now
able
to
turn
on
operation
nodes
in
kiali
or
you
will
be
in
our
next
release.
H
And
you
can
see
things
like
this,
so
let's
say
you're
making
a
car
reservation
in
as
a
request
header.
You
know
whether
or
not
it's
actually
vip
request,
handling
or
standard
request
handling,
and
so
you've
got
these
two
different
buckets,
basically
classifiers
right.
So
that's
using
that
new
attribute
that
was
injected
for
request
operations
and
then
bucketizing
the
requests
into
those
two
things.
For
example,
and
then
you
know
you
can
do
the
usual
things
like
get
the
traffic.
That's
going
specifically
through
that
operation.
H
You
can
get
response
times
specifically
for
that
operation
and
so
forth.
You
can.
You
can
notice
that
there's
a
vip
and
standard
classification
for
both
the
car
service
and.
H
Then
you're
going
to
get
the
total
aggregations
for
vip
requests
going
to
either
cars
or
hotels
or
so
forth.
Things
like
that
and
a
couple
more
of
these
classifiers,
this
one's
more
about
what
service
you're
actually
asking
for,
like
you
asking
for
a
travel
quote
or
a
listing
of
cities
handled
by
this
workload.
H
So
you
know,
I
think
this.
I
think
the
request
classification
stuff
adds
quite
a
lot
of
ability
for
people
to
examine
what's
going
on
in
their
mesh,
and
you
know
perhaps
figure
out
where
there's
bottlenecks
figure
out
if
you
need
to
break
up
a
service
into
multiple
services
and
so
forth.
So
just
wanted
to
show
you
guys
that.
B
H
B
H
Any
of
these
things,
let
me
see
so
we
have
a
little
script
that
deploys
this
and
you
can
see
if
I
have
it
and
see
if
I
can
open
it
quickly,
if
I
can
find
it
so
yeah
in
this.
This
is
this:
can
you
guys
see
the
script?
You
can
right,
yep,
yeah
so
down
here
you
can
see.
Here's
the
when
I
run
this
installer
for
the
whole
demo.
If
I
choose
to
install
the
request
operation
stuff,
here's
the
section
where
we
are
patching-
the
fill
stats
filter,
160
ammo,
with
the
it's
straight
out.
F
B
H
H
Start
to
see
some
of
the
matching
that
we're
doing,
there's
the
travel
quote
and
the
list
cities.
Let
me
show
you
the
one
I
here's
like
vip
and
standard
right,
so
you've
got
the
workload
selector
for
hotels
here
and
then
you're
gonna
take
a
look
and
we're
matching
on
the
request
header.
So
we
can
say
hey
if
you've
got
a
user
request,
header
and
the
value
is
vip,
then
you're
going
to
bucketize
it
into
the
vip
aggregate
or
operation
and
pretty
much
if
it's
not
vip,
we're
just
throwing
it
into
the
standard
bucket.
B
J
H
G
G
H
B
H
H
H
This
was
I
hate
to
leave
on
a
downer
which
will
be
the
downer.
So
I'm
going
back
to
this
view
that
I
had
initially
with
everything.
H
So
this
is
what
we
want
to
see
for
the
travel
app,
but
given
the
bug,
that's
been
in
one
six
since
it's
since
the
beginning-
and
it's
still
there
in
165
with
regards
to
telemetry
being
generated
incorrectly,
giving
you
unknown
and
pass-through.
So
I've
been
filtering
that
out
up
here,
you
might
have
noticed
this.
Is
our
graph
hide
feature
in
kiali,
where
you
can
get
rid
of
stuff
that
you
don't
want
to
see?
H
Did
it
come
through?
Okay,
sorry,
so
so
this
is
what
I
was
showing
before.
This
is
what
we
would
like
to
see
for
the
travel
demo
and
what
you
should
see,
but
up
here,
I'm
actually
filtering
by
the
cali
graphite
feature
the
bad
telemetry
that
has
to
do
with
unknown
and
pass-through
cluster
traffic
being.
H
Being
generated
when
you
don't
want
it
and
if
I
take
away
the
filter,
this
is
what
you
get
so
out
of
the
box
because
of
this
bug.
This
is
the
telemetry
that
we
see
using
one
six.
So
if
I
don't
hide
it,
it
looks
like
a
mess.
H
I
Yeah,
at
least
when
I
try
to
try
to
install
this
travel
app
after
I
increase
it
to
an
hour,
I'm
no
longer
able
to
see
the
junk
edges.
H
I
Yeah
the
basically,
the
thing
is
like
the
proto
sniffing,
like
the
proxy,
doesn't
know
whether
it's
a
http
and
make
a
forced
judgment
on
the
types
of
the
traffic,
and
thus
the
the
exchange
doesn't
happen
that
metadata
exchange
doesn't
happen
correctly
and
the
cost
is
this
pass-through
and
hormone.
B
I
B
I
Even
even
after
we
changed
it
to
a
very
high
value,
we
still
you
know
1.65.
We
change
it
to
five
seconds,
okay,
which
seems
already
pretty
high
for
me,
but
yeah.
I
tried
one
five
one,
six,
five
with
this
travel
app
and
I'm
still
seeing
several
junk
edge
in
my
installation.
I
Oh
even
I
mean
yeah,
even
even
with
even
with
five
seconds
yeah
after
increasing
to
an
hour
yeah
like
it,
at
least
it
solves.
For
me.
It's
also
easy
for
me.
I
What
we
need
to
do
like
really
yeah,
so
just
increase
it
to
infinity,
but
I
I
don't
know
whether
what
jj
is
saying
is
the
same
issue
as
what
I
thought
about
like
the
pro
sniffing.
So
I'm
asking
jay
to
try.
D
I
Okay,
yeah
jay.
If
you
have
some
time,
please
use
the
use
that
option
and
see
whether
that
helps
to
solve
this.
Okay.
A
H
E
I
haven't
really
talked
much.
This
is
my
first
time
showing
up
for
this
meeting,
but
my
name
is
brian
wolfe.
I
work
at
airbnb
and
I
just
wanted
to
provide
some
feedback
on
the
mixer
stuff,
like
we've,
never
even
attempted
with
mixer
because
of
the
performance
issues.
E
So
from
our
perspective,
if
it
goes
away,
it
just
simplifies
docs
for
us.
So
I
know
that's
not
a
very
broad
perspective,
but
that's
our
perspective
so
far.
B
No,
that's
I
mean
your
perspective
is
welcome
and
and
welcome
brian
to.
E
A
Okay,
well
now
that
we
said
hello,
probably
time
to
say
goodbye,
see
you
guys
in
see
everyone
in
two
weeks,
yep
thank.