►
From YouTube: Policies & Telemetry WG Meeting - 2019 02 13
Description
Agenda:
- Networking configuration attributes proposal (https://bit.ly/2GcmSK9)
- Switching off Mixer-policy by default issue 11736
- Small update on WASM / MixerV2 prelim work
A
A
C
A
A
So
a
while
back,
we
had
talked
about
the
fact
that
it's
very
hard
to
know
just
looking
at
the
telemetry.
What
pieces
of
networking
can
fake
led
to
the
baton,
machine
it
was
generated,
and
so
there
was
a
desire
Express
to
have
a
way
to
connect
virtual
service
and
destination
rules
as
a
start
in
the
the
telemetry
that's
gathered.
So
this
is
a
proposal
for
how
we
might
carry
that
information
across
to
reports.
A
A
So
I
think
the
big
thing
is
just
coming
up
with
the
right
attribute,
namespace
and
seeing
if
the
values
make
sense,
the
discussion
in
the
dock
has
been
primarily.
Should
it
be
called
destination
at
virtual
service,
or
should
it
be
config
that
virtual
service
or
networking
that
virtual
service,
and
then
there
was
another
discussion
that
were
questioned,
was
raised
about
whether
or
not
this
stuff
should
be
exposed
to
the
client
in
general
and
who
owns
virtual
service?
A
So
the
argument
was
made
that
virtual
services
and
destination
rules
are
owned
by
the
service
provider
and
so
by
pushing
that
details
out
to
the
clients
we're
exposing
information
that
they
shouldn't
have
access
to.
Although
I'm
not
sure
I
I
fully
buy
into
that,
because
because
it's
a
really
kind
of
a
bootable
Drive
and
those
are
their
clients,
their
client
concerns
but
they're
controlled
by
the
server.
H
A
G
G
A
A
H
A
A
Have
like
it
here's
a
graph
kind
of
thing.
This
came
up
in
previous
working
group
meetings
where
there
was
I
think
the
key
ally
team
in
particular
wanted
to
show
which
pieces
are
config.
You
can
overlay
on
save
fault
injection.
You
know
faults
showing
up
in
the
system.
Things
like
that,
so
there's
a
desire
to
be
able
to
link
either
in
you
eyes
or
just
looking
through
the
logs
or
doing
audits
this.
This
sort
of
networking
conveyed
to
the
observed
results.
Okay,.
H
G
F
E
Do
here,
but
I
didn't
go
exactly
the
question,
but
yes,
we
are
trying
to
show
us,
as
you
already
set
the
default
injection
rules
and
also
we
what
the
better
services
ours
will
be
useful
because
we
don't
know
exactly
how
the
traffic
is
routed
to
to
the
destination.
The
better
we
can
show
now
is
the
that
is
passing
through
our
service,
a
cornet
service,
but
we
all.
H
Know
the
question
the
question
I
have
edgar
is:
do
you
have
a
particular
example
of
a
chart
you'd
like
to
be
able
to
draw
that?
Cannot
you
can't
today,
because
you
don't
have
enough
of
information,
and
if
so,
would
you
mind
sketching
that
literally
sketching
that
into
this
doc
doesn't
have
to
be
high
fidelity
to
show
here's?
The
kind
of
you
know
chart
or
graph
that
we
want
to
be
able
to
draw
I.
Think
to
me
it
always.
H
E
A
And
just
and
for
your
you're
in
favor
of
additional
ethics,
just
came
out
a
couple
of
working
group
meetings
back
so
I
think
we
have
two
notes
and
videos
from
that
we
can
find
some
stuff
there.
We
took
it
to
the
networking
meeting
and
I
got
the
networking
side
of
the
implementation
and
but
I
don't
think
we're
proposing
this
for
one
one,
or
at
least
not
the
initial
one
one
release
so
there's
there's
still
time
to
sort
of
sort
of
figure
out
exactly
what
we
want
to
do
here.
Right.
A
Okay,
well
so
the
documents
there
I
posted
about
it
I
think
on
the
discuss
discussion
site.
So
please
provide
feedback
like
asking
for
charts
and
things
like
that.
Uh-Huh
and
I'll
try
and
keep
working
on
getting
that
into
shape.
I
think
the
next
thing
on
our
agenda
is
issue
one
one:
seven,
three,
six.
G
There
is
an
alternative
already
available
inside
sto,
which
does
some
of
what
they
could
have
been
doing
with
policy
Nomad.
Also
east,
you
are
back,
is
actually
enforced
client
side,
so
it
doesn't
doesn't
suffer
from
the
same
performance
issues.
Mixer
v2
actually
does
address
this
case
anyway,
that
we
are
moving
all
this
enforcement
into
the
client
and
the
other
part
is
if
mix
of
policies
down
and
you
have
you
haven't-
set
up
succeed
on
network
error
of
then
you
will
actually
incur
an
outage.
G
If
mixer
policy
is
down
and
you
would
incur
an
outage,
our
customer
would
incur
an
outage,
even
though
there
is
no
policy
active.
So
even
if
you're
using
you
are
not
using
any
mix
of
policy,
you
would
still
in
curve
outage
here.
So
it's
an
unnecessary
risk
that
that
the
customer
is
made
to
carry
even
though
they're,
not
using
policy
and
then
yeah
for
those
reasons,
we're
considering
switching
it
off
for
1.1,
there's
some
risks
that
that
we
have
documented
there
and
and
then
mitigations
and
some
people
have
already
commented
on
it.
G
Give
like
give
feedback
now
or
I
would
encourage
people
to
actually
add
their
feedback
to
the
proposal
itself,
and
we
are
going
to
send
out
an
email
kind
of
more
broadly
on
announce
tubes
to
get
more
feedback,
but
we
would
like
to
if,
if
we
are
to
move
ahead
with
this,
it
would
be.
Why
won't
our
forum,
which
is
like
within
a
week
or
two
at
most,
the
car
c1,
is
being
cut
today?
So
it
would
be
shortly.
F
Think
from
our
side,
the
only
time
we
really
use
this
is
when
we
integrate
with
our
API
management.
So
we
have
three
scale
being
integrated
through
this
river
mm-hmm.
Is
that
some
optional
installation
for
us
I?
Don't
think
we
would
particularly
mind
this
because
we
can
turn
it
on
when
somebody
installs
three
scale
and
the
adapter
with
that
yeah.
G
G
G
A
G
G
F
G
So
that
that
is
already
there
in
1.1,
so
actually
what
is
already
present?
Okay,
I
need
to
add
this
to
the
Today
Show,
so
we
already
have
a
way
to
switch
on
policy
enforcement
pearl
workload.
You
can
annotate
a
deployment
and
then
policy
enforcement
will
just
be
enabled
for
fall
at
work.
For
so
that
feature
is
already
present.
Oh
so
you're
saying
that
my
fault,
no
one
will
get
it
and
if
you
want
to
turn
it
on,
you
can
turn
it
on
all
of
the
work
or
basis.
F
I
So,
just
to
add
on
to
that,
I
have
been
working
on
a
tiny
project
which
is
similar
to
the
history
of
command
line,
but
which
will
allow
you
to
do
things
much
more
easily.
For
example,
it's
it's
kind
of
our
to
disable
certain
things
at
runtime,
for
example
the
case
with
the
policy
checks.
So
what
if
we
have
like
a
command
line
with
a
better
usability,
so
you
just
mention,
let's
say
command
visible,
let
mixer
or
something
like
that.
I
So
right
now,
I,
don't
think
this
to
control
can
do
that
and
also
a
few
other
things.
So
typically,
we
use
both
QCD
and
sto
control
to
manage
our
cluster,
but
is
there
like
it
would
be
better
to
have
them
grouped
in
a
single
command
so
and
to
you
know,
group
a
bunch
of
steps
into
like
single
commands,
for
example,
if
you
want
to
install
sto,
you
do
you
installing
the
CR
des,
and
then
you
install
a
bunch
of
pods
and
everything.
I
I
F
G
Then
then,
the
other
comment,
the
new
is
that
the
api
that
we
support
currently
for
any
of
this
is
actually
the
values
the
camel
like
helmet
guy
right.
So,
for
example,
this
particular
setting
of
global
dot,
like
disable
policy
check
right.
That
is
part
of
the
mesh
config,
but
even
though
you
can
handle
it,
msconfig
the
real
supported
way
is
actually
in
help.
So
you
actually
make
the
change
in
helm
and
then
you
either
generate
new
template
or
you
or
do
help
install
of
those.
Those
templates
accept
the
operator
peace.
A
I
So
you
mentioned
about
the
health
thing
right,
so
it
is
basically
a
multi-step
process.
You
first
do
some
change
in
the
values,
yeah
middle
and
then
usually
the
new
template
and
so
on.
So
what
my
idea
is
to
basically
try
to
avoid
behaving
like
all
those
steps
using
something
much
simpler.
So
what
if
we
could
do
it
using
just
a
single
command?
I
think
that,
as
you
mentioned,
it
aligns
with
the
operator
thing.
I
need
to
follow
up
on
that
right.
Okay,.
I
And
the
other
thing
is
like
I
want
to
avoid
like
too
much
Hamill
I
think
this
is
more
from
the
link
OD
perspective,
so
they
generally
avoid
all
the
stuff
and
they
have
a
pretty
powerful
command
line
and
I
think
that
is.
That
gives
a
really
good
user
experience
and
I.
Think
Easter
is
not
in
there
honestly.
So.
H
I
think
the
goal
with
the
and
again
I
think
this
really
is
a
discussion
in
the
end
for
the
environment,
but
I
think
the
goal
with
the
operator
is
to
is
to
put
an
operator
employees
that
look
at
the
state
at
least
Rd.
The
Inc
amend
our
call
that
the
API
I,
which
is
currently
representing
that
value
CMO,
but
instead
think
of
that,
as
as
something
that's
in
the
API
server
and
the
operator
will
watch
that
thing
and
keep
the
state
of
the
system
up-to-date,
and
so
when
we
get
that
operator
in
place.
H
If
you
write
a
command
line
tool
that
that
modifies
the
values
of
that
of
that
CRD
in
the
API
server,
then
the
operator
would
do
its
thing
right.
So
if
you
said
we
don't
we
don't
want
a
widow
on
policy.
In
effect,
the
operator
would
make
sure
policy
was
no
longer
text.
We
don't
want
a
mixer
installed,
it
wouldn't
make
sure
mixers.
No,
so
the
moving
to
an
operator
based
model
should
make
it
easier
to
do
things
like
write
a
key.
H
F
H
F
H
Is
the
non-trivial
bit
of
work
is
I
think
we
all
have
agreed
in
principle
we'd
like
to
do
that?
We
don't
yes
Kevin,
you
you're,
absolutely
right.
There
are
details
in
there
that
will
be
difficult.
Some
parts
will
be
easy.
It
will
take
a
bunch
of
thinking
and
I.
Don't
know
how
many
releases
to
make
it
happen.
I
don't
know
if
this
was
it's
a
one,
two
thing
or
not,
but
I'd
like
to
get
started
on
it,
because
it
will
enable
people
like
vanilla
to
write
that
CLI
he's
talking
about
easily.
G
Think
I
think
so.
It
should
be
easy.
This
that's
one,
but
it
should
also
be
interoperable
with
the
bit
like
other
things
right.
We
don't
want
two
different
tools
to
like
step
on
each
other
and
kind
of
one
tool
is
reaching
way
down
into
the
API
and
then
changing
something,
and
then
that
vanishes
when
you
use
the
higher-level
it
castle,
so
that
that's
that's
also.
The
kind
of
thing
that
we
want
to
avoid
so
ease
is
definitely
one
but
making
sure
that
they're
all
built
on
the
same
underlying
API
is
also
important.
Yeah.
I
G
A
G
A
One
thing
I
did
want
to
put
out
there
sort
of
abstractly
is
we
haven't
really
taken
a
good
look
at
the
dashboards
since
the
last
time
they
were
sort
of
updated,
and
now
it's
been
several
months.
There's
been
a
lot
of
changes
for
one
one.
So
if
there's
things
that
people
are
interested
in
or
ways
that
they
want
to
change
the
dashboards
or
streamline
them,
that
would
be
a
good
time
to
start.
G
So
I
had
a
related
comment
of
if
there
was
a
way
to
decouple
the
dashboards
from
releases
so
that
it's
it's
unlikely
that
the
dashboard
is
going
to
destabilize
the
release,
but
sometimes
like
most
of
the
time.
You
don't
want
to
wait
that
long
to
get
it
in
your
dashboard.
So
if
there
is
a
way
to
have
some
other
dashboard
repository
or
something
similar
which
can
move
much
faster
than
the
rest
of
the
release.
But
yes.