►
From YouTube: Policies and Telemetry WG 2018-06-06
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
So
so
menorah
and
I
plan
is
hopefully
by
end
of
mid
of
this
month.
We
should
have
a
the
coat-check
din,
which
would
idly
and
have
couple
of
in
the
end-to-end
test,
which
would
which
will
exercise
this
out
of
proper
doctor
back-end
work.
There
are
multiple
peers
that
are
out.
We
there
are
peers
to
auto,
create
CR
DS
for
adapter
developers,
just
create
this
base64
strings
from
file
descriptor,
so
making
it
stuff
a
little
easier
for
the
adapter
developer
and
while
doing
what
else
is
there?
So
Mandel
is
work.
B
B
A
B
I
think
beginning
Piazza
viewed
is
priority
one,
but
I
think
it
has
been
okay,
so
far,
I
mean
the
the
CI
system
is,
is
cooperating
very
well,
so
things
are
going
in,
Osmund
are
Martin,
are
reviewing
stuff
and
reasonable
pain.
So
III
think
that
is
not
a
problem.
Martin
and
I
talked
and
I.
Think
that
is
one
more
piece
of
how
do
we
use
existing
adapters
to
to
work
with
this
out
of
proc
work?
B
So
we
need
a
shame
which
would
translate
this
IB
P
interface
to
a
the
go
interface
and
Martin
would
probably
help
out
next
week
to
to
create
that
shim.
It
will
be
auto
generated
based
on
templates,
so
any
existing
adapters
should
be
able
to
just
say:
I
want
to
create
a
shame,
because
I
want
to
run
it
out
of
process
and
that
shim
gets
compiled
created.
B
One
has
to
compile
it
into
their
into
the
binary
and
run
it
as
a
service
so
how
to
run
it
as
a
service.
That's
a
different
problem,
but
but
first
we
need
to
generate
the
shim.
A
C
A
C
A
D
A
B
We
don't
have,
we
haven't
checked
in
the
CRD
definitions
for
the
new
config
kinds,
CID
kinds,
but
but
we
have
started
consuming
them
as
just
a
string
like
there
isn't,
there's
a
new
there's
going
to
be
a
new
CID
kind,
called
adapter
or
template.
So
those
definitions
needs
to
go
in
and
it's
probably
one
day
of
work.
So
if.
B
C
C
B
C
E
F
B
Completely
joined
right,
yeah,
you're,
right,
I,
think
I
just
need
to
I
mean
no.
No
code
has
been
checked
in
yet
I
need
to
check
if
I
have
joined
them
together
in
this
in,
like
assuming
that
it
is
this,
this
the
new
kind
system
way
we
have,
we
have
separate,
we
don't
have
separate
kinds
for
each
adapters
that
one
is
not
coupled
with
the
outer
proc
work
or
assume
that
it
is
the
dynamic
it
has
to
have
a
dynamic
template.
B
E
E
B
Yes,
so
that
would
be
an
excellent,
separate
piece
to
check
here.
Yeah
yeah-
and
it
is
just
one
block
and
that
way
any
of
the
outer
proper
accidentally
doesn't
doesn't
mix
those
things
together
and
that
should
just
continue
to
work.
It's
probably
a
day
and
a
half
work
so
I
can
I
can
throw
the
focus
on
that
quickly.
So.
E
G
A
A
E
E
E
E
A
C
C
So
maybe
you
guys
can
convince
me
either
way,
so
the
check
cash
I
implemented,
just
needed,
I
think
works,
and
you
just
had
some
comments
about
splitting
up
a
function
into
you.
Two
pieces
and
I
was
about
to
do
that
work.
But
last
week,
Mandar,
Anaya
and
I
talked
about
kind
of
a
different
way
to
compose
mixer
into
in
the
future
and,
and
part
of
that
was
looking.
How
we
do
caching
in
general
and
the
cache
I
implemented,
sits
right
in
the
front
of
mixer
in
front
of
everything
else.
C
When
a
check
call
comes
in
the
first
thing
we
do
is
do
a
cache
look
up
and
then
and
then
return
if
we
find
it
in
the
cache,
so
we
don't
run
the
APS
or
any
of
the
adapter
logic.
The
cache
follows
a
pattern,
that's
very
similar
to
what's
in
the
mixer
client
cache
it's
all
based
on
that.
We
create
cache
keys
based
on
the
set
of
attributes
that
were
used
and
computing.
The
cache
keys
ends
up
being
reasonably
expensive
because
you
need
to
figure
out
which
sets
of
attributes
to
include
serialize.
C
All
these
attributes
calculate
an
md5
on
it
and
so
forth.
It
appears
it
seems
that
it
might
be
more
efficient
to
be
cache
from
a
at
the
cache
level
to
be
more
efficient.
It
might
be
more
efficient
to
be
caching
instances
rather
than
caching
attributes.
So
I've
imagined
we
do
all
the
processing
and
produce
a
set
of
instances
that
are
finally
sent
to
the
adapter.
The
instances
are
fully
denormalized
and
they
tend
to
have
less
state
than
the
attributes.
C
E
C
Now,
if
I
look
at
certain
of
our
adapters
like
the
list,
checker
adapter
or
the
opah
adapter,
they
don't
need
any
caching,
because
they
can
do
all
the
computation
locally
already
yeah,
which
leads
me
to
think
that
maybe
the
caching
should
be
the
responsibility
of
the
adapter
and
mixer
should
just
not
do
anything
and
I
should
just
delete.
My
PR
completely.
E
E
C
C
If
I
wait
until
the
other
proc
stuff
is
in
place,
and
then
we
actually
RC
realizing
the
instances
into
byte
arrays
all
right
and
then
you
can
go,
show
that
easily
and
define
any
parts
are
yes
way
cheaper
than
sha,
and
just
as
good
for
defer
the
study
use,
yeah
yeah.
So
so
so
then
that
would
say:
I
scrapped
my
current
er
wait
a
couple
weeks
and
then
implement
Akash
on
the
other
side
of
things.
So
that
means
for
a
cache
hit.
E
C
E
You
know
what
kind
of
cache
hit
rate
to
be
expect.
I
think
that
that's
that
will
also
dictate,
which
is
better
right.
We
expect
high
cache
it
rate
at
the
client
on
the
server
if
the
cache
hit
rate
is
high,
it's
okay
for
the
lookup
to
be
expensive.
The
hit
rate
is
low.
Then
it's
it's
actually
double
value.
Yeah.
C
C
Maybe
I
should
just
check
it
in,
as
is
cuz,
it
works
and
you
can
easily
turn
it
off
and
you
can
scale
the
size
of
the
cache
and
and
then
we'll
then,
in
a
few
weeks,
I
implement
the
other
end
of
the
cache,
and
then
we
can
actually
run
tests
with
one
enabled
or
the
other
and
see
what
happens.
The
current
this
new
cache
is
self-contained.
If
we
decide
we
don't
like
it,
it's
you
would
delete
the
package
and
remove
a
couple
function
calls
and
it's
gone.
C
E
C
E
C
A
H
H
The
context
reporter
UID
in
context
reporter
local,
it's
just
it's
it's
still
for
server-side
reporting.
So
at
least
we
have
those
attributes
for
client-side
reporting,
and
these
are
issues
of
how
we
model
virtual
service,
so,
like
I,
think
I
just
keep
hitting
some
of
those
discussions
how
to
represent
and
how
to
propagate
virtual
service
information
to
the
plugins.
H
So
I
don't
think
it's
quite
resolved.
Yet
so
I'm
not
sure
what
to
do
about
that
stuff.
I
think
would
way
to
do.
It
would
be
just
to
have
another,
maybe
secondary
mixer,
to
plug
in
that
coexists
with
existing
plugin
that
we
can
optionally
water-type
something
if
before
we
can
make
a
decision.
What
to
do
about
the
PAL
plugins
I
sent
a
dog
to
Sharon
Martin
Ostrovsky.
C
H
H
H
H
E
E
C
H
H
E
So
Martin,
if
you,
if
your
point,
is
that
do
we
plan
to
extend
that
to
all
other
services
that
maybe
I,
don't
I,
don't
think
it's
it's
planned.
Yet
it
doesn't
look
like
it's
planned
yet,
also,
not
that
many
services
like
directly
support
I,
mean
it's
minimal
code
changes.
It's
not
it's
not
that
big
of
a
deal,
but
how
do
the
Box
the.
H
H
A
A
E
E
H
A
G
C
C
H
C
We
use
we
use
the
whole
effectively
the
destination
host
name
to
drive
our
service
selection
or
config
selection,
and
if
a
single
workload
implement
multiple
services,
infective,
Lee,
don't
know
which
service
was
being
used.
When
the
the,
when
the
workload
received
a
request
for
HTTP,
you
could
look
at
the
whole
setter
that
that
is
that
it's
probably
sufficient,
but
TCP
there's
just
nothing.
I.
H
C
Late,
okay,
so
that
so
we're
still
screwed
there.
This
is
just
like
service,
it's
the
opposite
yeah,
so
the
the
one
solution
that
seems
possible
is
to
make
a
requirement
that
each
each
service,
if
you're
gonna,
have
multiple
services
in
a
workload.
Each
service
needs
to
be
exposed
outside
of
the
proxy
by
by
the
sidecar
at
different
ports,
and
then
we
can
apply
policies
accordingly,
based
on
the
which
port
the
traffic
arrives
in
it
doesn't
matter
what
the
physical
services
actual
port
selection
is.
It's
really
what
the
proxy
is
exposing.
C
D
C
C
F
D
If
so,
if
it's
replication
controller,
it
gets
filled
out,
but
if
it's
anything
else
it
doesn't
I'm,
sorry
so
sources.
The
pod
and
source
network
load
is
the
replication
controller
or
a
demon
set
or
that
yeah.
So
what
if
we're
in
a
job?
And
then
so,
if
we
have
a
replication
controller
and
a
demon
set
that
both
have
the
same
name
the
source
at
workload,
isn't
it
is
not
going
to
be
able
to
distinguish
between
those
two.
C
G
A
A
A
A
A
Hopefully
those
will
be
less
contentious
than
everything
everything
else,
but
yeah,
so
I'm
still
trying
to
shoot
for
680
to
have
all
that
wrapped
up
so
we'll
see
it
happens,
dinner
happen
at
the
weekend
during
the
weekend.
Don't
get
shot
on
Monday
yeah
Jeff.
Did
you
want
to
provide
any
update
done
from
the
tracing.
D
D
The
the
tracing
configuration
on
Envoy
is
part
of
the
port,
whereas
on
an
is
two
entity
would
be
like
a
virtual
virtual
server,
although
if
you
make
that
port
change
they
just
talked
about
of,
maybe
that
fixes
the
problem,
but
so
I
think
what
we
can
do
right
now,
which
is
easy,
is
make
a
global,
a
global,
a
global
proto
like
you
were
had
before,
and
just
have
a
global
percentage
of
sampling
and
then
a
and
then
for
a
longer
term.
D
A
Well,
I'm
trying
to
get
my
thought
here.
There
was
another
related
question
that
we
started
to
look
at
an
API
which
is
supporting
other
exporters.
If
you
were
all
so
on
way.
I
get
recently
added
support
for
dynamic
exploit
and
the
light
step
guys
wondered
when
the
CEO
is
going
to
provide
support
for
lights,
up,
I
think
I
roped
you
into
that
conversation
Jeff,
but
just
that's
something
else.
You
want
to
think
about
as
we
design
that
configuration
artifact.
A
A
D
A
D
That
I
recall
the
problem
we
had
with
this
is
that
we
we
need
well.
Maybe
that
would
be
so
that
the
tracing
API
we
would
want
to
be
dynamic
versus
the
Envoy
config
needs
to
be
done
at
a
cluster
set
up
for
the
the
exporter
if
I
recall
correctly,
so
maybe
these
can
fix
go
into
different
places.
I
know
we
have
like
a
cluster
proto
for
ISTE.
Oh.
A
H
C
C
E
C
C
C
A
A
Okay,
that's
all
right,
you're
working
on
Martin
and
you
you're
gonna
get
all
that
through.
G
I
A
C
But
the
broader
context
is
that
we
intend
to
have
data
that
flows
through
mixer
be
editable
right,
so
the
operator
can
write
rules
to
strip
out
PII
or
whatever,
and
and
as
well
as
multiplex.
So
even
though
the
proxy
can
only
send
Jaeger
or
whatever
the
mix,
we
can
rewrite
that
and
send
that
to
different
backends
automatically.
I
C
Yeah
yeah
so
we'll
do
that
for
stuff
in
general
software
for
metrics
as
well,
we'll
just
ingest
standards,
a
a
small
set
of
standard
metrics
protocols,
so
services
can
export
metrics
they'll,
be
captured
by
mixture.
Then
the
operator
can
choose
to
do
whatever
they
want
with
those
metrics
and
move
it
on
that.
Those
really
mixer
is
truly
at
that
point,
a
mixer.
It
takes
inputs
that
sends
it
to
different
outputs
at
will
and.