►
From YouTube: Policies and Telemetry WG 2018-07-18
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
Time
this
camera
a
little
bit.
A
Great
well,
thanks
for
coming
I
know
we
have
some
broad
interests
in
this
meeting.
I
think
the
only
thing
on
the
agenda
today
released
to
go
through
some
of
the
changes
for
its
tier
1
battle
and
as
they
apply
to
telemetry,
so
I
put
together
a
little
sort
of
summary
of
some
of
the
issues
that
had
come
up
and
DOX
related
to
those
issues
that
led
to
the
changes
and
I
wanted
to
speak
to
a
little
bit
about.
A
A
Breaking
that
actually
happened
on
the
client-side
proxies
and
not
server
side
proxies,
and
this
was
a
big
hole
in
our
twin
tree
story
prior
to
this
release,
and
so
this
release
will
address
that
bit
of
missing
poetry
and
the
other
big
change
in
telemetry
was
that
we
shifted
away
from
sort
of
search
service,
the
destination
service,
relations
to
focusing
on
source
workload,
the
destination
workload,
communications
and
those
are
the
really
big
changes.
And
there
was
a
lot
of
communication
and
conversations
about
that
which
I
tried
to
link
in
the
background
section
of
the
agenda.
A
So
that's
sort
of
what's
really
new
about
the
one
that
I
was
limitary
and
then
out
of
that
you
know
we
updated
the
dashboards
and
a
bunch
of
different
things,
but
I
think
that's
the
primary.
Those
are
the
two
primary
changes
that
are
worth
mentioning
so
now.
I
know
that
the
Cali
team
had
some
questions
and
I
want
to
turn
the
floor
over
to
them
to
sort
of
ask,
and
we
discussion
about
the
things
that
they
wanted
to
raise.
C
So
the
we're
probably
I
would
say,
probably
a
couple
months
behind
you,
you
guys
had
cuz.
We
both
back
on
all
the
discussions
you
guys
had
about
the
whole
service
versus
workload
stuff.
We
started
having
this
conversation,
we
went
back
and
we
both
if
you
were
docs
and
threads
and
then
of
you
guys
basically
have
the
same
conversations
a
few
months
ago.
So
this
whole
move
from
service
to
workload.
C
A
So,
sort
of,
historically,
we
have
relied
on
the
app
label,
for
you
know
the
example
service
graph
it
ships
with
this
do
and
other
things
I
think
we
are
okay
with
recommending
that
people
use
the
Apple
able
to
identify
sort
of
service
or
application
or
whatever,
whatever
term
use
application.
If
we
want
so
I,
think
that
sounds
okay
from
my
perspective
and
I,
don't
know
if
others
want
to
comment
on
that.
D
A
C
One
of
the
questions
me
and
JJ
is
also
on
the
call
we
just
had.
We
were
just
talking
about
this
before
we
on.
This
call
was
the
way
the
athlete
was
used
in
that
Indian
example.
In
the
booking
photo
example,
it
seems
like
the
act
label
was
more
narrowly
used
in
the
booking.
So
then
we're
not
sure
that's
how
it's
recommended
to
use
it.
For
example,
the
app
level
is
the
same
name
as
the
scripts
name.
C
A
So
yeah
others
made
like
I'll,
give
one
perspective
on
it
right,
so
the
book
info
example
is
sort
of
limited
in
that
we
only
ever
have
one
deployment
for
each
of
the
services,
so
we're
not
rolling
out
well
I
guess
there
are
some
examples
where
we
roll
out
v2
and
v3
reading
yeah
yeah.
So
if
you
want
to
track
readings
across
all
three
of
those
versions
or
used
across
all
those
versions,
the
only
way
to
do
that
is
with
the
a
playable
yeah.
D
D
C
E
C
Yeah
yeah,
so
the
idea,
what
we're
doing
is
we're
using
Apple
equals.
How
we
did
this
and
I'll
say:
I'll,
put
a
link
to
some
of
the
demos
that
we
have
in
case.
You
guys
haven't
seen
a
key
ally
UI,
but
the
idea
is,
we
have
version
worker
lose
think
reviews
one
reduce
you
to
reduce
III.
We
actually
group
them
in
a
version
box,
because
we
know
the
app
the
app
label
is
reviews.
So
you
know
okay,
these
are
related,
but
we
have
free
or
closed
within.
This
related
group
called
reviews.
A
Know
I
will
stop
sharing
and
let
you
take
over.
C
Let
you
see
the
athlete
able
reader
to
be
able
to
repeat
if
we
were
not
looking
at
the
athlete
we're
just
going
with
source
workload
and
destination
work,
we
wouldn't
be
able
to
produce
that
box,
you
see
it
would
use
only
be
able
to
show
you
want
e
to
be
three
circle
nodes
without
any
notional,
then
being
related
to
right.
That
make
sense.
C
G
C
C
But
I
put
a
fault
injection
in
front
of
it,
so
this
just
this
basically
illustrating
the
new
stuff.
You
guys
think
you
might
need
decline
slide.
There
are
metrics.
So
what
this
is
saying
is
product
page
tried
to
make
a
request
to
saw
me
detail
its
service,
but
it
didn't
make
it
because
we've
injected
a
fault
there.
So
there's
no
server
side,
not
sure,
but
very
think
that
cause
I'm
not
sure.
A
C
F
This
does
not
seem
to
distinguish
between
a
404
that
routing
error,
client-side,
routing
error
and
a
404.
That's
legitimate,
server-side
404
it
like,
because
looking
at
that
at
I
could
not
tell
whether
it
was
the
application
that
sent
back
a
404
or
you're
trying
to
say
that
the
attempt
was
an
incorrect
attempt
was
made
to
send
it
to
something
that
doesn't
exist.
C
G
C
F
F
G
C
C
G
A
C
A
C
A
C
We
actually
had
animations
here
to
where
you
would
see
dots
kind
of
like
the
visceral
graphs.
I
know
you're
gonna.
Do
this
what
everyone
says:
yep
yeah,
so
everyone
loves
this
rule,
so
we
actually
do
have
animation,
but
you'll
see
dots
flowing
from
the
edges.
We
start
to
finish
the
the
dots
will
speed
up
the
number
of
dots
change
depending
on
you
know,
throughput
response
times
so
you'll
see
animations
you'll,
see
like
I,
said:
you'll,
see
different
colors
orange
some
errors
red.
G
It's
like
it
I
think
kind
of
see.
A
point,
though,
is
that
you
know
we
understand
in
the
last
few
days,
with
a
back
and
forth
on
the
email
lists
is
that,
even
though
we
are
exploring
what
we
can
do
here
using
app
labels,
we'd
have
to
it,
we
have
to
assume
that
they
might
not
be
there
or
they
might
he's
set
up
in
a
way
that
we
can
leverage
them
very
well.
G
So
we
are
definitely
going
to
have
to
provide
a
graph
that
is
work
load
to
work,
load
based
or
work
load
to
request
in
service
also
needs
to
be
represented
in
the
graph
for
the
for
the
client-side
failures
for
you.
So
that's
that's
key,
but
that's
why
we're
so
interested
in
app
because
we
feel
like,
even
though
it's
optional,
if
everybody's
using
it
and
everybody
uses
it
the
same
way,
we
could
leverage
it
a
lot
right.
So.
H
I
I
really
want
to
ask
the
question
here
clearly
clearly:
there's
a
problem
where
the
people
trying
to
build
UIs
and
experiences
around
this
stuff
need
to
create
a
certain
user
experience
and
they're
struggling
to
do
so
with
what
they
currently
have.
So
we
have
the
Kali
team
working
towards
using
the
app
label
right.
H
My
question
is
so:
if
we're
okay
with
Jiali,
recommending
that
you
should
use
the
app
label
in
this
specific
way
and
pushing
this
usage
throughout
the
community,
the
app
label
is
fundamentally
not
secure.
It
is
not
there's
no
provenance
around.
You
know
that
I
use
ik
and
labeled
upon.
However,
they
want
that
app
is
going
to
be
the
label
selector,
that
this
incoming
service
uses
to
select
those
pots.
H
So
it
kind
of
feels
like
we're.
Taking
a
big
sidestep
to
avoid
a
technical
issue,
but
then
leaving
all
of
the
baggage
there
in
kind
of
a
worse
way,
right
so
I'm
wondering
if
we're
okay
with
using
labels
as
the
means
of
identifying
the
sort
of
business
logic
unit.
That
is
this
with
a
workload
instead
of
standardizing
on
app.
H
D
I
think
the
second
part
the
index
to
service
in
some
ways,
that's
strictly
worse,
because
service
can
be
many
to
many
relationship,
whereas
the
work
we
can
only
have
one
label
of
a
particular
name
and
that
aspects
of
the
property
we're
looking
for
for
grouping
is
that
you
have
a
particular.
You
know
one-to-one
relationship.
So
it's
one
to
many,
not
many
to
many
right.
H
Right
right
totally
so
so
let
me
let
me
backtrack
a
little
bit.
I
think
I
got
last
week,
I
I,
guess
what
I'm
asking
is.
Is
there
a
way
in
which,
rather
than
this
loose
label
selection
mechanic,
if
we
could
actually
say
the
proper
to
do
things
in
the
the
optimized
best
case?
Is
that
you
have
a
one-to-many
as
opposed
to
a
many-to-many
relationship?
You
use
the
app
label
as
your
selector
and
in
that
news,
sto
will
give
you
some
extra
semantics
around
that
particular
use
case
as
opposed
to
I.
F
What
I,
what
I
don't
understand?
It's,
not
such
a
big
departure
from
well
waiting
start
in
a
student,
and
even
if
you
look
at
just
plain
kubernetes
like
given
their
example,
everything
is
exactly
was
so
we
didn't
just
like
me,
I
mean
we
chose
a
playable
because
there
was
some
like
prior
art
and
some
acceptance
offered
before
it
still
came
along
the
only
the
only
thing
thing
I
think
I
see
here
right
to
kind
of
hear.
Your
earlier
point
is
that
a
playable
itself
is
not
names
based.
F
D
I
think
I
think
we
have
to
include
names
or
you
have
to
names,
but
but
more
in
my
word,
meaning
we
need
to
make
the
name
J's
included,
to
make
this
just
assistant
to
not
and
look
there's
career
days
actually
allow
that,
like,
if
you
have
our
sir
I,
think
service
selectors
are
automatically
in
the
in
space
code
yeah,
so
it
still
exists.
Well,
they
do
the
same
thing
right.
You
can't,
even
if
you
label
it
with
the
same
like
front
end
in
a
different
namespaces
right
as
long
but.
F
I
I
think
it's
important
to
think
about
multiple
clusters
as
well,
because
in
the
multiple
cluster
case
you
could
have
two
namespaces
with
different
k.
Kubernetes
are
back,
but
with
the
same
name
that
sto
will
treat
as
the
same
namespace.
So
it
is
that
you
could
have
a
service
that
points
at
a
label
selector
where
someone
else
can
control
the
labels
on
that
right.
D
I
D
A
So
there's
actually
two
issues
here
right,
so
one
is
like
pulling
the
value
for
the
metric
label
from
the
kubernetes
pod
label,
and
one
is
what
we
call
the
metric
label
itself.
So
if
we
think
if
we
build
things
around
using
source
app
as
the
metric
label,
how
we
populate
that
value
can
change
over
time
and
we
can
adjust
that
to
better
understanding.
So
that's
just
something
else
like
the
Cali
folk,
like
you
almost
don't
care
and
that's
how
the
value
is
derived
right.
E
C
F
So
that's
I
think
to
that
point
right.
One
of
the
things
I
mean
labels
are
by
definition,
arbitrary
and
it
is
up
to
the
deployer
to
impart
any
kind
of
meaning
to
it
right
like
whoever
deploys
it,
assigns
labels
imparts,
meaning,
and
then
they
see
the
same
thing
or
in
their
monitoring
so
from
a
whole
subside.
F
I
guess
one
thing
we
could
do
is
have
the
app
label
and
the
version
like
essentially
have
a
book
or
identifying
labels
as
a
configurable
thing
which,
which
I
think
happened,
version
has
shown
to
be
sufficient
so
far,
but
if
someone
comes
along
and
says
that
they
need
app
version
and
I,
don't
know
something
something
third
thing
to
be
included
in.
However,
they
group
their
stuff,
then
I
think
all
our
monitoring
should
be
able
to
pick
that
up
and
say:
okay,
fine,
like
you
group
it
in
these
ways.
So
that's
what
I'm
going
to
follow.
E
C
H
Ahead,
sorry,
there's
there's
one
other
issue
with
with
this
approach:
I
think
so
it
it
works
very
well
to
give
you
grouping
of
your
metrics.
What
it
doesn't
do
is
give
you
a
unit
that
you
can
look
at
all
of
your
observability
information
around
one
concept
right
so
great,
you
created
an
app
label.
How
do
you
look
at
the
policy
associated
with
that
app?
G
It
doesn't
have
to
actually
have
the
great
point
we
were
talking
about
this
earlier
today.
Right
so
let's
say
you
have
that
graph
and
you've
got
and
it's
represents
an
app.
So
then
you
wanna
Dorado
I
mean
you
want
to
look
at
it.
We
want
to
see
what
it
does.
So
how
do
you
get
from
that
node
to
something
with
more
detail?
We're
like
okay,
you
start
with
the
app
on
the
app.
G
We
can
get
the
workload
from
the
workload
we
can
map
it
to
services
and
then,
eventually,
you
can
drill
down
to
the
services
that
you're
interested
in.
So
there
is
like
this
big
indirection
between
getting
from
app
to
what
you
really
want
to
see,
which
is
some
rule
on
your
on
your
service
or
something
like
that
right.
H
And-
and
this
is
kind
of
the
thing
that
I
I
sort
of
feel
like-
were
we're
ignoring
the
elephant
in
the
room,
which
is
that
to
provide
value,
you
ultimately
do
have
to
backtrack
to
the
service
right
so
and
and
and
it's
possible
to
do
that
right,
so
III
would
I
would
just
like
I,
don't
know.
I
I
would
really
like
and
III
understand
the
the
historical
context
and
the
philosophical
context
for
why
this
is
not
the
case,
but
I
would
like
to
see
more
opinion
built
into
SEO.
C
F
G
I
mean
going
back
to
it.
I
think
it
was
Daniel
was
just
saying
right,
you
know
up
until
0.8,
we're
sort
of,
like
ignorance
is
bliss,
because
you're
showing
this
nice
service
service
a
graph
given
the
metrics
that
we
had
back
then,
and
it
made
perfect
sense
right.
So,
when
you're
observing
something
one
thing
you
want
to
you
want
to
have,
is
you
want
to
understand
what
you're
observing
work,
what
workloads
to
workloads
which
are
then
indirect
to
services
in
a
way,
or
maybe
a
little
more
complicated
to
understand?
G
C
C
G
But
what
I'm
trying
to
say
is
right,
I
think
everyone
gets
it's
just
that
there
was
a
simplicity
to
that
which
made
it
easy
to
observe
and
we
can
easily
link
from
a
service
node
back
to
the
service
definition
and
things
like
that.
So
from
an
observability
perspective,
it
actually
was
potentially
easier
and
now
we're
struggling
a
little
bit
trying
to
get
back
to
that
simplicity
and
wondering
hey:
can
we
force
this
app
label?
Can
we
depend
on
it
stuff
like
that.
A
Yeah
no
I
think
that's
out
there
and
I
think
we
all
generally
agree.
I
mean
it's
a
to
Daniel's
point
I,
think
there's
a
larger
thing
that
needs
to
be
solved
across
the
steel,
the
outside
of
just
telemetry,
and
that's
the
link
between
virtual
services
in
the
network
policy
and
how
like
it
like
the
policies
info
entries
that
you
know
this
working
group
is
concerned
itself
with
our
link
right.
C
So
I
can
tell
you
how
we're
thinking
of
doing
it
now-
and
we
do
this
today,
so
I
showed
you
that
graph,
but
we
have
a
whole
half
of
the
UI
that
you
didn't
see.
If
you
solo
demos
you'll
see
this,
but
you
know
you
click
a
node
and
then
we
have
a
link
to
go.
Look
at
the
details
on
that
note,
so
you
can
go
to
the
workload
and
will
actually
show
you
in
the
service
details
page.
Oh,
these
are
the
destination
rules
that
apply
to
this
node.
These
are
the
virtual
services.
C
You
know
we
could
show
all
kinds
of
stuff
like
that.
So
on
that
some
pages
on
those
detail
pages,
that's
when
you
can
start
drilling
around
oh
I
know
the
workload.
Let
me
go
to
the
fronting
services
for
that
and
then
we
can
show.
Then
we
can
show
metrics
based
on
that,
so
we
can
actually
drill
down
to
services.
But
it's
this
graph
thing
is
where
we're
having
difficulty
trying
to
figure
out
how
to
visualize
these
things.
H
B
C
A
So
if
we're
looking
for
action
items,
I
think
we
we
should
take
the
action
item
to
bring
it
up
at
the
next
config
group
meeting
is:
how
are
we
dealing
with
this
and,
what's
the
what's
the
what's
the
roadmap
for
getting
some
sort
of
unification
across
all
of
this
deal?
Are
they
said
to
my
my
suggestion?
I,
don't
know
if
others
have
different
opinions,
I.
F
F
Its
business
affects
all
of
us
too,
so
I
think
now,
where
the
reason
I
think
it
effects
elementary
more
and
more
immediately
is
because
well
in
telemetry,
we're
in
the
business
of
showing
things,
and
it
affects
us
right
away
and
actually
in
in
policy,
especially
with
the
virtual
service
and
that
kind
of
thing.
It
also
creates
some
very
interesting
questions
as
to
are
you
protecting
the
world
code,
or
are
you
protecting
the
gate
and
that's
also
kind
of
another
one
of
those
questions
that
we
really
need
to
answer.
F
A
A
A
G
A
A
A
Anything
else
that
we
should
discuss
otherwise
I
think
and
call
it
a
day,
methylation
yeah.
Actually,
those
I
think
we
decided
to.
We
need
to
raise
an
issue
somewhere
more
pressingly
at
a
higher
level
to
talk
about
the
connection
between
virtual
services
and
policies
and
women
tree
and
how
how
they
unify
the
contest
across
yes
to.
A
Anyone
good
once
or
twice,
okay,
what
think
I
wanted
to
thank
you,
Kelly
team
for
dining
in
I
hope
we
can
continue
close
collaboration
moving
forward.
You
know,
so
we
can
stay
I
think
this
is
really
helpful
about
someone
keeping
us
honest
and
checking
in
on
how
it
all
works.
So
thank
you.
Thanks.
A
little
help,
yeah.