►
From YouTube: Istio User Experience meeting August 11, 2020
Description
Initial review of Istio 1.8 UX Roadmap
A
A
A
You
know
stephen
had
some
personas,
I
usually
divide
into
three
sort
of
stakeholders,
our
end
users,
the
people
who
are
administering
either
themselves
or
the
cloud
providers
who
are
administering
istio,
and
then
third
party
developers
like
kiali
people
who
are
looking
for
books
to
get
their
work
done.
So
what
I
try
to
do
for
a
lot
of
this
is
to
break
things
up
into
how
we
would
address
sort
of
each
person.
A
B
B
B
Second,
paragraph
begin
to
talk
about
the
working
group
and
the
way
that
we've
worked
previously,
which
I
think
has
been
sort
of
characterized
by
taking
work
from
the
other
working
groups,
features
new
capabilities
and
just
exposing
them
through
a
steel
cuddle,
making
sure
that
they
have
nice
useful,
tooling
around
them,
which
has
value
and
the
istio
control
tool
has
become
really
integral
to
the
pro
the
process
of
using
istio,
which
has
been
great.
But
on
the
downside.
This
is
how
the
effect
that
we
don't.
We
often
aren't
involved
in
feature
creation.
B
We're
often
engaged
very
late
in
the
development
process
where
we're
sort
of
doing
bolt-on
usability.
You
might
you
might
say,
and
then,
in
addition,
the
the
product
istio
has
moved
in
several
directions
that
istio
control
has
not
been
able
to
keep
up
with
I'm
thinking
in
particular
about
multi-cluster
to
some
degree
multi-control
plane,
although
I
think
we've
done
a
better
job
there,
vms
centralist
dod,
because
we're
engaged
late
in
the
process
there's
only
so
much.
B
We
can
contribute
to
these
discussions
so
looking
forward
to
the
next
year
moving
the
needle
on
istio's
user
experience
is
going
to
require
a
different
strategy
than
we've
used
in
the
past.
I
think
we,
as
a
working
group,
are
going
to
need
to
become
more
engaged
in
the
other
working
groups
process
of
innovation.
B
In
addition,
we're
going
to
need
to
begin
becoming
the
source
of
user
in
focused
innovation,
where
we're
not
simply
looking
at
adding
a
feature
to
istio
control
or
covering
a
new
environment
that
istio
is
deployed
to,
but
actually
from
the
ground
up.
Developing
user
first
features
within
the
user
experience
working
group,
and
this
is
sort
of
an
inversion
of
how
it's
worked
before
right.
The
innovation
tended
to
start
in
the
other
working
groups
and
flow
towards
us.
B
There
is
a
cost
to
this.
It's
going
to
cost
us
in
performance.
It's
going
to
cost
us
in
cadence
on
some
of
the
capabilities
that
we're
releasing
in
istio,
but
those
sorts
of
trade-offs
and
costs
need
to
be
evaluated
in
light
of
how
important
it
is
to
improve
the
user
experience
of
istio
over
the
coming
year.
B
A
new
capability,
a
new
environment
that
we
can
run
in,
is
not
likely
to
differentiate
istio
from
its
competitors
substantially
because
we
already
win
on
those
dimensions.
Again,
it's
user
experience
that
really
where
we
are
failing
to
meet
the
expectations
of
our
users,
in
my
opinion,
so
it's
not
only
on
the
ux
working
group
to
achieve
this
over
the
coming
year.
B
We
we
specifically
share
this
goal
with
the
test
and
release
working
group
and
the
documentation
working
groups,
because
if
the
capabilities
of
istio
are
not
usable
or
are
of
low
quality,
that
is
they
break
frequently
or
are
not
well
documented.
Any
of
those
will
keep
even
the
most
awesome
features
from
being
usable
by
our
users.
B
This
has
already
really
begun
in
one
six
and
one
seven.
We've
made
progress
towards
moving
to
apis,
but
that's
going
to
continue
in
1,
8
and
there's
a
number
of
advantages.
You
can
secure
an
api
using
our
back,
which
is
a
very
familiar
way
of
doing
things
which
we
didn't
really
have
before
with
things
like
istio
cuddle,
proxy
status
and
proxy
config.
So
it's
a
better
security
posture.
B
C
A
C
Nothing
concrete
one
thing
that
is
coming
down.
The
line
that
we
want
to
address,
which
is
gonna
be
absolutely
horrible
to
address,
is
when
we're
orchestrating
configuration
changes
in
istio.
We
want
to
be
able
to
trace
all
the
way
from
user
interaction
with
our
system
through
to
it
getting
axed
by
an
envoy.
That's
what
we
want
eventually,
now
that's
going
to
require
upstream
working,
istio
and
envoy,
so
this
like
it's
going
to
need
to
be
a
collaborative
event,
but
that's
like
the
one
thing
we're
super
interested
in
this
area.
B
B
Look
at
him:
okay,
also
we're
working
with
the
envoy
project
on
that
same
topic,
because
we're
using
acts
as
sort
of
a
proxy
for
config
being
actually
data.
It's
the
best
thing
that
we
have
today,
but
it
is
known
to
not
be
100
accurate,
so
we're
working
with
the
envoy
project
on
a
better
signal.
There.
A
Okay,
so
I
have
gone
through
and
tried
to
set
priorities
and
the
1
8
milestone
for
the
ux
items
that
are
in
our
issue
database,
and
this
is
what
I
think
is
the
parties
please
interrupt.
If
you
think
something
is
too
low,
too
high
or
in
the
wrong
section.
I
broke
the
roadmap
into
the
three
stakeholders
that
I
talked
about
earlier,
so
first,
I'm
going
to
talk
about
the
things
affecting
end
users.
I
think
the
for
me.
A
A
A
A
John
howard
did
not
like
them,
so
that
discussion
is
happening
there.
That's
just
a
p2,
some
improvements
on
the
existing
authc
command,
which
no
one
understands
we
want
to
do
that
with
the
security
work
group,
a
little
command
to
get
the
envoy
version
and
a
so.
I
feel
that
our
current
proxy
status
doesn't
give
enough
information
about
tls.
A
A
A
I
think
that's
going
to
be
super
important
for
analyze.
We
already
have
in
progress
some
work
to
get
the
line
numbers
in.
I
want
to
do
the
duplicate
match.
Analyzer
that
greg
hansen
asked
for,
and
john
howard
has
said.
We
shouldn't
do
anything
for
envoy
filters
because
it's
supposed
to
be
a
wild
card,
so
I've
got
nothing
in
plan
for
that,
although
I
still
feel
like
there's
too
many
ways
to
shoot
yourself
in
the
foot
on
that.
A
As
a
stretch,
I
don't
have
an
issue
for
that.
Rom
venom
and
I
have
been
talking
about
some
kind
of
trace
routes
or
ping
or
tls
verifier
tool
that
may
be
just
in
the
isu
ecosystem
or
something
it
would
be
good
to
know.
If
communication
is
really
there
and
I'm
thinking
it
wouldn't
work
like
our
usual
stuff,
it
might,
it
might
use
some
ephemeral
containers
or
some
envoy
filters
to
sort
of
see,
what's
sort
of
really
happening.
A
We
want
to
do
this.
Multiple
control,
plane,
stuff,
that's
slip,
217
that
we
had
promised
to
do
the
sort
of
automatic
revision
checking
if
that's
possible
in
multi-control
plane
a
better
way
to
list
control
planes
which
doesn't
mean
really
listing
them
because,
as
costumes
pointed
out,
there
could
be
an
infinite
number
of
remote
control
planes,
but
to
sort
of
list,
maybe
injectors
or
the
ones
that
are
currently
running
in
your
cluster
I'll
fix
the
bugs
and
wait
do
any
other
team
members
have
anything.
That's
user-facing
that
we
should
do
in
one.
A
A
Okay,
so
I'll
continue
with
the
stuff,
I
think
we
can
give
cloud
providers
so
in
one
seven,
what
slipped
was
this
awkwardly
named,
promote
canary
to
master
with
environments?
We
have
to
figure
out
just
the
best
case
if,
if
it
currently,
you
can
delete
your
canary
and
then
try
to
upgrade
your
master.
A
A
Currently
the
verify
install
just
tells
if
the
pods
are
sort
of
running
in
running
status.
I
think
we
want
to
combine
that
those
checks
that
we've
always
done
for
verify
install
with
something
like
proxy
status
to
see
if
everybody's,
not
stale,
some
real,
simple
things
just
to
combine
stuff
so
that
verify
the
health
really
is
meaningful.
A
D
D
A
So
there
was,
there
was
an
issue.
There
was
a
lot
of
confusion
about
this,
and
a
lot
of
it
is
about
the
the
way,
a
pot
a
way
a
control
plane
is
called,
the
master
is
like
the
master
is
allowed
to
get.
The
istio
injection
equals
true
label
as
and
and
control.
The
other
ones
have
weird
labels
to
control
injection.
D
C
D
A
D
A
A
D
A
D
A
D
So
I
I
don't
have
a
strong
opinion
about
you,
keeping
the
legacy
or
not,
but
my
my
concern
is
that
I
expect
most
users
who
care
about
production
and
and
stability
and
all
this
good
stuff
they
will
want
fine
control.
I
want
this
workload
to
be
one
six,
maybe
one
six
dot
x,
I
mean
basically
and
to
specifically
use
the
division.
I
mean
if
someone
some
beginners
or
some
people
just
want
whatever
it
is,
they
get.
A
D
B
Costing
that
I
I
totally
agree
with
you
that
long
term,
that
should
be
the
direction
that
we
do
for
production,
but
we
have
to
understand
that
there
is
a
mountain
load
of
documentation
on
sdoio
and
blogs
that
have
all
standardized
on
injection
enabled
so
changing.
That
is
not
going
to
be
a
one
or
two
or
even
a
three
release
process.
We're
looking
at
years.
D
All
of
our
users,
and,
as
I
said,
I
have
no
problem
with
maintaining
it.
I
mean,
I
think
it's
probably
a
good
idea
to
just
keep
it
and
to
means
that
it's
kind
of
the
alias
for
the
prod
revision
or
some
some
stable
revision.
But
my
my
point
is
regarding
promoting
something
to
master
is
the
same
problem.
D
You
have,
let's
say:
is
your
latest
or
istio
one
seven
and
you
want
that
namespace
to
have
the
latest
minor
version
in
1.7
branch,
but
not
something
in
1,
6
or
1
on
it.
So
the
primary
use
case
is
people
who
are
in
production,
who
kind
of
explicitly
point
to
a
particular
label,
and
that
label
is
the
one
that
needs
to
be
promoted.
C
D
D
Said
I
mean
there
are
two
questions
here
really
one,
if
not
having
objections,
and
second
is.
If
we
have
a
plan
or
if
someone,
because
we
discussed
several
options,
I
mean
we
discuss
the
proxy
option
where,
where
one
is
actually
doing
some
computation
and
then
forwards
to
the
actual
version,
we
discussed
patching
the
web
hook
with
a
new
version
we
discussed
in
place
upgrade.
There
are
three
main
solutions
for.
A
A
D
D
Yeah
yeah
yeah.
Well,
even
if
you
don't
use
it,
it's
not
harming
you,
but
the
main
question
is
we
probably
need
to
agree.
I
mean
as
soon
as
possible
on
what
we
want
to
pursue
as
a
design
for
how
we
are
doing
this
migration.
I
think
that's
probably
the
most
critical
thing,
because
that's
where
we
hurt
the
most.
A
A
A
A
D
D
A
D
A
A
So
that
things
that
we
want
to
offer
our
third
parties
first
is
what
slipped
in
one
seven,
this
troubleshooting
api.
We
do
not
have
a
approved
document
in
one
seven,
we
had
sort
of
been
working
on
a
document,
and
this
item
is
sort
of
to
put
those
that
work
under
one
eight
and
it's
going
to
be
done
through
these
xds
events,
which
are
going
to
be
federated.
A
B
B
B
B
D
A
Great,
the
last
item
is
something
that
was
created
by
the
telemetry
group.
They
wanted
an
envoy
extension
dashboard
and
I
don't
know
if
they
mean
a
ui
thing
or
is
to
a
cuddle
thing.
I
want
to
envoy
extension
at
least
a
output
command,
an
s2
cuddle,
maybe
api,
and
it's
not
yet
clear
what
it's
supposed
to
look
like.
So
this
item
is
going
to
be
at
least
start
with
being
a
design
item.
Can
we
get
some
cli
commands
to
sort
of
see
this?
A
A
Maybe
those
envoy
filters
are
being
populated
by
something
like
solo,
ios
web
assembly
hub,
maybe
they're,
coming
through
config
maps.
Some
pods
have
these
extensions,
some
don't
users,
I
feel,
are
having
difficulty.
They
see
a
bunch
of
envoy
filters
in
the
s2
system,
name
space
it's
hard
to
and
they
have
the
those
those
filters
in
this
system.
Any
space
and
your
own
filters
have
workload
workload
stuff
in
there,
but
they're
not
in
there
as
labels.
So
you
can't
use
the
cube
codel
label
selectors
to
sort
of
figure
out
what's
happening.
A
I
think
what
needed
are
some
commands
to
sort
of
say
you
know
you're
using
using
this
set
of
webassembly
in
your
system.
These
are
the
pods
that
have
it
you,
maybe
you're
using
this
web
assembly
hub.
I'm
not
sure
how
exactly
this
is
gonna
fly,
but
I
think
we
we're
gonna
need
that,
as
as
people
do
more
and
more
of
webassembly,
I
get
so
many
questions
from
people
who
want
it
leap
into
webassembly
already
and
don't
know
where
to
get
started.
A
C
B
C
C
Not
necessarily
an
istio
one,
maybe
a
third
like
an
external
one,
but
whichever
wherever
we
want
to
send
it
right,
that's
that's
kind
of
what
we're
interested
in,
because
otherwise
you're
monitoring.
Well,
I
guess
actually
it's
not
really
monitoring
your
stock
with
the
sbo
trace
now,
but
yeah
we
can.
We
can
discuss
offline,
but
yeah
cool
spam.
A
E
E
A
A
B
A
Okay,
so
at
four
one
seven,
we
were
only
able
to
get
sort
of
half
of
our
stuff
done.
We
had
promised
more
than
we
were
able
to
do
because
we
spent
a
long
time
understanding
sort
of
what
we
were
allowed
to
do
in
terms
of
adding
our
own
xds
events
and
in
terms
of
environments,
sort
of
we
depended
on
them
for
things
like
deleting
a
control
plane
which
they
ended
up
doing,
but
not
till
the
very
end.
B
B
And
I
think
it's
important
to
call
out
that
on
most
of
these
we
have
co.
We
have
dependencies
on
other
working
groups
and
we
share
responsibility
for
delivering
on
them
so
unilaterally.
No,
we
will
need
our
items
to
be
prioritized
by
other
working
groups.
I've
already
met
with
networking
and
security
to
try
to
encourage
them
to
properly
prioritize
our
requests,
and
I
think
that
was
received
fairly
well,
but
yeah.
This
is
going
to
be
a
very
broad
team
effort.