►
From YouTube: Istio User Experience working group, August 18, 2020
Description
- Wiki instructions for using experimental XDS based istioctl command variants
- unsharded view of XDS
- nventory/Analysis of istioctl commands
A
So,
thank
you,
everyone.
This
is
the
user
experience
meeting.
Last
friday
we
presented
our
roadmap
to
the
toc,
but
we
sort
of
went
over
time
because
there
was
not
enough
time
to
do
the
whole
thing.
The
feedback
that
I
got
from
this
roadmap
is
that
what
we
agreed
on
last
week
was
not
everything
they
wanted.
They
liked
mitch's
user
story
and
we
gave
them
a
full
list
of
the
work
items
we
wanted
to
do
with
rankings,
but
they
didn't
feel
that
we
were
telling
them
why
we
wanted
to
do
them.
A
So
I
started
putting
single
words
or
phrases
in
each
item,
such
as
correctness
for
the
federated
view
or
learnability
in
front
of
these
items,
and
I
think,
on
friday,
we're
going
to
have
to
go
back
with
something
better
than
that.
So
I'm
trying
to
finish
up
and
come
up
with
the
right
words
to
to
get
people
to
understand.
Why
we're
doing
these
things.
A
So
I
I
think
we
all
agree.
I
mean
we
all
agreed
on
these
items
last
week
and
what
I
think
is
new
is
just
how
are
we
going
to
tell
the
tlc
about
them
all
right?
So
all
I
wrote
here
was
federated
view
of
xds
events.
I
even
forgot
to
link
this
one.
I
made
it
to
p0,
it
didn't
know
what
that
was.
It's
you
know
for
the
correctness
of
the
proxy
status
command.
A
We
just
need
to
sort
of
be
able
to
put
all
that
into
this
chart.
Do
we
want
to
go
through
this
line
by
line
or
do
we
just
trust
me
to
do
this
before
friday?
I'm
going
to
do
a
good
job?
I
just
want
to
make
sure
I'm
not
trying
to
make
everyone
do
this.
In
my
using
my
terminology,
or
maybe
mitch,
you
and
I
can
do
this-
I.
B
B
Think
we
can
group
a
lot
of
things
under
the
federated
view
of
xds
events.
This
idea
of
getting
all
of
our
troubleshooting
commands
working
across
all
supported
topologies
that
covers
the
troubleshooting
api
that
covers
this
security
credentials
stuff
here,
I
think
about
half
of
what
we're
doing
can
probably
be
grouped
under
that
use
case.
D
A
A
A
A
B
Well,
I
think
a
lot
like
I
said
I
think,
there's
value
in
grouping
a
lot
of
them
together,
rather
than
you
know.
We've
got
maybe
30
issues
linked
here
rather
than
telling
30
different
stories
in
terms
of
usability
telling
the
higher
level
stories,
such
as
the
the
all
commands
work
across
all
environments.
I
think,
like
I
said
I
think
we
could
group
about
half
of
them
under
that
particular
heading.
B
A
D
A
D
A
So
I
don't,
I
think
I
I
think
mitch
and
I
can
handle
that
on
her
own.
I
think
the
items
that
we
agreed
to
do
can
all
be
easily
grouped
into
three
or
four
items
of
these
higher
level
stories,
and
I
can
make
issues
or
epics
for
them
in
github
and
link
them
all
up
to
the
items
with
the
priorities
that
we
set
here
I
can
make
the
high
level
story
priorities
the
same
as
the
highest
priority
of
each
item
in
its
individual
work
items.
A
So
the
next
thing
I
wanted
to
talk
about
was
the
instructions
that
I
wrote
last
weekend
for
using
the
experimental
istio
cuddle
command
variants.
So
not
everyone
is
aware
of
this,
but
in
the
wiki
I
wrote
these
instructions
wrote
them
here,
rather
than
trying
to
get
them
through
docs
and
release
notes,
because
I
feel
there's
stuff
here
that
we
should
be
sort
of
trying
out
before
we
expect
everyone
to
read
it.
A
A
A
If
you
have
central
s2d,
you
expose
it
using
a
gateway
and
a
virtual
service
on
a
particular
port
with
pass
through,
so
that
you
can
expose
to
the
outside
world.
The
https
that
is
2d
already
does,
and
then
you
using
your
new
certificates,
you
use
the
experimental
steel
cutter
x
commands
with
all
of
these
options.
Xds
address
authority
inserter,
and
then
you
use
the
new
configuration
file
feature
that
we
dark
launched
to
make
those
features.
A
E
A
E
A
A
The
makefile
puts
the
certificate
chain
and
the
certificate
in
different
files,
and
we
just
have
to
combine
them
together
and
that's
really
clunky.
We
either
need
to
create
targets,
like
you
said,
for
the
jwt
token,
or
a
target
that
combines
the
certificate
chain
and
the
certificate
or
we
need
to
get
the
dsc
library
to
handle.
What
the
make
file
makes-
and
I
just
want
to
talk
about
that
networking
meeting.
D
I
have
a
question
so
yeah,
I'm
sorry.
I
didn't
keep
track
this
closely.
I
I
couldn't
get
the
token
working
and
then
I
sidetracked
work
on
some
other
stuff.
So
the
the
issue
with
the
key
and
search
to
bootstrap
the
vm
was
when
you
generate
the
key
and
search
you
can't
be
like
a
namespace
admin
of
any
namespace.
D
D
Right
so
john,
that
was
my
concern
with
this.
If
we
are
using
falling
back
to
key
and
search
approach,
we're
saying,
in
order
for
user
to
onboarding,
still
kind
of
commands
for
the
data
plane
within
central
studio
environment,
the
user
would
somehow
be
able
to
retrieve
the
key
and
search
which
is
only
accessible
to
the
mesh
admin.
A
A
C
D
D
A
A
A
C
I
don't
know
if
it's
going
to
be
sufficient.
There
are
additional
things
we
probably
want
to
do.
I
mean
it's
it's
kind
of
a
full
back
worst
case
and
scenario,
because
it
relies
on
on
on
events
from
from
ap
server,
which
are
not
very
reliable,
not
not
not
not
f,
zero,
fml,
that's
correct,
so
so
the
api
server
may
hold
them
as
long
as
they
need
the
most
important
reason
I
added
this
is
that
it
allows
us
to
report
events
back
to
the
to
the
pod.
C
C
So
we
still
want
to
do
direct
connections.
Yes,
the
problem
is
that
for
the
reconnection
also,
we
have
corner
cases.
So
I
believe
that
the
combination
of
the
of
the
events
plus
direct
connections
is
sufficient.
For
most
users
I
mean
the
debug
tool
is
not
supposed
to
be.
You
know:
100
percent
accurate,
understandable
we,
the
system
is
recovering,
so
every
15
minutes
I
mean,
even
if,
if
the
eventing
doesn't
is,
is
dropped
because
we
we
reconnect
every
15
minutes
or
20
minutes
or
30
minutes.
C
C
C
Okay,
so
you
there
are
two
ways
to
to
get
the
the
status
and
basically
so
one
is
to
watch
the
events,
and
then
you
should
see
you
know
in
real
time
when
endpoints
connect
disconnect
and
then
keep
track
of
them.
The
other
one
is
to
actually
get
this
information
initially
in
edit
code
for
study
towards
the
event
itself
and
to
build
the
database.
That's
not
yet
completed
right
now.
The
purpose
of
the
pr
is
to
you
know
test
it.
So
we
see
if
how
bad
it
is
in
terms
of
you
know,
performance
scalability.
C
C
A
C
C
So
ed,
if
we
had
a
way
to
to
query
all
these
ud
pods,
we
would
do
it
would
not
have
this
problem.
So
the
problem
is
that
we
do
not
have
a
very
good
way
to
find
all
because
you
have
multi
cluster.
Have
too
many
scenarios.
It
is
if
you,
if
you,
if
you,
if
you
are
willing
to
have
something
that
some
code
that
is
connecting
to
all
these
two
of
these
just
put
it
in
in
in
package
util
and
each
id
itself
can
do
it
can
connect.
C
C
B
So
we've
we've
bumped
into
this
problem
before
and
it
seems
like
whether
we're
talking
about
a
pub
sub
system
that
they
all
use
or
we're
talking
about
connecting
directly
to
all
of
them
or
eventing.
I
I
think
the
same
problem
comes
into
play.
The
question
that
we're
asking
is
which
sdod
instances
are
in
scope
for
this
aggregation
right
like
if
you're
aggregating,
let's
say
status
data?
Do
you
take
absolutely
every
instance
of
sdod
that's
running
in
the
cluster?
Is
that
enough,
or
are
there
other
clusters?
F
C
A
You
you
saw
my
you
saw
my
wiki
instructions
to
expose
this
virtual
service
for
sdod.
You
could
imagine
that
this
destination
is
a
subset
of
an
s2d
that
is
unique
to
my
particular
setup.
So
I'm
sort
of
saying
I'm
going
to
expose
a
subset
for
coca-cola
I'm
exposed
to
subset
for
pepsi
yeah.
That
kind
of
thing.
So
I
see
that
as
being
sort
of
fine.
If
I
can
come
up
with
a
way
to
do
that.
C
For
example,
if
a
knack
happens,
we
want
all
the
students
to
know
that
that
particular
config
is
bad,
so
they
don't
push.
We
want
all
these
students
to
know
what
other
issue
this
existing
system
and
what
loads
they
have,
how
many
endpoints
they
have
so
they
can
rebalance.
We
want
when
an
endpoint
connect
to
any
study.
The
other
issue
is
to
find
out
immediately,
so
we
don't
have
latency.
So
there
are
many
networking
related
features
that
depend
on
study
or
can
be
improved
if
this
study
can
connect
to
all
the
other
studies.
C
The
question
is,
in
the
simple
case:
it's
why
I
think
your
your
code
will
work
perfectly
and
if
you,
if
you're,
only
concerned
with
with
solving
the
problem
for
one
centralist,
ud
cluster,
then
it's
it's
fine
and
it's
a
perfect
start
as
long
as
it's
in
study
itself.
But
if
you
have
to
have
multi-region,
for
example,
have
a
cluster
pair
region,
then
you
have
friends.
How
do
you
discover?
I
mean
all
the
studies
from
the
other
clusters,
so
you
have.
The
scenarios
where
you
run
eastwood
is
on
prem,
because
you
have
some
for
fallback.
C
A
A
We
pass
that
in
as
an
argument,
maybe
through
a
header-
and
we
use
some
header
routing-
to
get
it
to
the
right
instance.
If
it
were
on
a
single
cluster
or
the
right
data
center,
or
we
have
a
data
center
flag
and
once
status,
I'm
willing
to
if
it's
too
hard
to
if
it's
a
general
multi
cluster
computing
problem
that
we
haven't
haven't
solved,
we
can
make
ps,
do
less.
A
C
No,
no,
no,
the
way
it
is
implemented.
You
get
events
from
the
cluster
where
the
port
is
running,
because
you
need
to
associate
the
event
with
the
pod.
So
in
reality,
if
you,
if
you,
if
you
are
in
a
lane
space,
if
you
just
do
cattle
describe
on
each
pods,
you
will
see
where
they
are
connected
each
port
individually,
and
that
is
very
reliable.
So
if
you,
if
you
have
a
port,
if
you
actually
know
a
pod
or
the
list
of
ports,
you
can
find
exactly
where
they
are
connected.
C
Or
report
yes,
yeah
the
application
workload.
Yes
exactly
because
that's
a
part
where,
where
where
where
there
is
no
problem,
you
do
keep
cut,
will
describe
on
on
on
the
pod.
Kubernetes
retains
the
events
associated
support,
so
you
can
see
that
the
pod,
you
know
pulled
an
image
did
start.
The
readiness
check.
You'll
also
see
that
connected
to
a
particular
study,
and
you
can
get
actually
study
where
it's
connected.
C
It's
very
useful
because
again
for
a
user,
you
just
need
to
do
cube
cattle
described
on
support
and
it
can
get
also
probably
will
be
able
to
get
knocked
so
that
that
particular
port
received
so,
and
I
think
that's
the
most
important
use
case.
You
carry
in
your
namespace
how
all
the
pods
are
connected
and
where.
C
And,
and
what
that
was
saying
about
wrestling
renault
ps
is
giving
you
all
the
supports
all
across
the
mesh
that
has
some
security
and
privacy
implication.
I
mean,
if
you
are
a
namespace
admin
because
centralized
studios,
that's
kind
of
the
premise
that
you
are.
You
are
splitting,
so
I
think
restricting
the
semantic
of
ps
to
mean
in
one
namespace
and
for
the
ports
that
are
currently
running.
B
C
Yes,
but
it's
it's
it's
getting
a
bit
more
complicated
and-
and
you
know
complex
and
let's
I
mean
if
we
can,
if
we,
if
we
are
going
to
to
change
the
semantics,
let's
change
it
to
something
that
it's
you
know
easy
to
support
because
per
name
space,
that's
a
unit
of
granularity.
I
mean
we
can
extend
it
to
namespace,
multiple
namespace
as
a
talented
unit
when
coverity
says
it
and
we
have
it.
C
C
C
E
C
I
I
think
we
also
need
to
be
very
careful
about
not
overwhelming
the
system,
so
we
definitely
can
send
the
knacks
to
the
port.
So
you
will
see
that
that
port
got
a
knack.
The
question
is:
how
do
we
revert
it?
How
do
we
we
delete
that
event
and-
and
there
is
a
delete
operation
and
we
can
also
send
arc?
I
mean
hey.
Everything
is
okay
for
this
port
when
it
is
resolved,
but
we
cannot
send
all
acts
all
the
time
so.
B
C
Yeah,
probably
we
don't
want
to
delete
yeah,
I
probably
don't
we
want
to
send
an
arc,
but
only
if
it
we
previously,
so
we
want
to
send
arcs,
but
only
if
we
previously
send
a
knack.
That's
easy.
If
you
are
within
a
connection,
because
you
know
that
you
sent
a
knack,
you
got
a
knock,
but
if
you,
if
you
reconnect,
then
we
don't
have
this
information.
However,
if
you
reconnect,
if
the
issue
cattle
is
able
to
interpret
the
stream
to
say,
hey,
knock,
connect
and
no
additional
knock.
It
means
it's
okay.
C
It's
not
very
straightforward,
but
I
think
it
the
logic
works.
I
mean
it's.
Basically,
we
send
a
knack
and
within
the
same
connection,
if
we
we
keep
track
that
we
send
a
knock
and
we
when
it
is
resolved,
we
we
we
revert
it
basically,
but
john
is
right,
it's
probably
per
resource
and
probably
need
to
include
additional
information
in
the
next.
So
the
user
knows
what
to
do
with
it.
A
Okay,
great
and
thanks
for
coming
to
the
meeting
by
the
way
carson.
I
think
this
really
helps
so
I
have
a
no
one
has
no
one
has
reviewed
my
pr
for
verify,
install
I'd.
I
think
it
may
be
too
late
for
one
seven,
but
maybe
one
seven
one
it's
totally
needed,
especially
on
kubernetes
118.
So
I'm
hoping
someone
can
review
that.
A
The
commands
that
I
think
either
I
never
the
commands
that
I
never
use.
I
marked
an
orange
and
I
indicated
whether
it
had
documentation
and
I
wanted
to
see
sort
of
what
the
people
on
this
call
think
are
the
bad
commands
and
what
are
the
popular
commands
so
that
we
can
sort
of
focus
our
effort
on
improving
the
good
ones
and
getting
rid
of
the
ones
that
no
one
is
using.
Currently
so.
A
C
C
A
C
Yes,
we
we
can
definitely
return
the
file
over
xds.
So
since
we
have
connection
to
each
ud,
we
can
get
them,
but
we
cannot
use
basically
cubes
to
api
to
connect
with
your
system
and
get
them
that's
my
point.
So
we
need
fixes
basically
over
xds.
We
can
return
them.
You
know
we
use
only
files,
whatever.
A
C
And-
and
there
is
also
the
larger
item
of
do-
we
want
to
actually
let
users
specify
an
injection
template
in
their
own
namespace,
in
which
case
we
need
to
modify
the
injector
to
actually
inject
the
files
with
config.
So
then
give
back
the
user,
the
control,
basically,
which
is
they
already
have
with
cube
injector.
They
can
use
local
files.
C
A
You're
right
I'll
move
all
these
discussion.
I
just
typed
into
the
other
document.
So
right
now
I
just
thought
I
would
go
through
and
ask
people
first.
So
yeah,
let's
go
through
your
list,
so
everyone
loves
analyze.
So
people
been
asking
for
this
authentic
check,
so
I'm
bringing
it
back
can
convert
ingress.
I
haven't
used
since.
A
C
E
E
D
C
C
D
E
That's
what
I
mean
has
been
supported
for
quite
a
while.
I
just
made
some
improvements
to
it
and
yeah.
It's
supported.
Well,
so
there's
two
different
things:
there's
ingress
which
has
been
around
for
a
while
and
then
there's
the
new
kubernetes
gateway
stuff,
the
new
kubernetes
gateway
stuff.
Yes,
it
works
on
all
kubernetes
versions,
but
you
have
to
like
install
a
separate
project
crd
and
it's
like
alpha
like
no
one's
using
that
we
should
basically
ignore
it.
For
this
conversation,
okay,
but
but
also.
E
C
C
D
B
A
D
A
C
D
No,
no,
I
think
dashboard
is
useful,
because
people,
so
the
the
whole
purpose
of
dashboard
is
for
people
who
can't
remember
the
portfolio
command.
I
know
you're
gonna
laugh,
but
I
always
have
to
look
up
the
doc
to
remember
those
commands
for
the
dashboard.
It's
really
helpful
for
people
to
you
know
launch
this
for
testing
purpose,
but.
A
A
C
C
C
B
I
do
like
the
idea
of
making
them
a
little
bit
more
intelligent,
though,
like
perhaps
replacing
prometheus
with
a
single
telemetry
command.
That
will
do
some
logic
around
detecting,
where
our
our
mixer
list
config
is
sending
its
telemetry
data
and
attempting
to
port
forward
to
that
for
supporting
things
beyond
just
the
production.
E
E
C
It's
not
mean
command,
it's
not
a
user
command
and
I'm,
I
think
we
need
to
focus
mostly
on
users
and
users
will
not
have
access
to
the
promise.
Namespace
will
not
have
access
to
zipkin
and
we
are
encouraging
a
very
bad
practice
of
actually
requiring
tools,
debug
tools
to
to
do
high
privilege
operation.
C
A
Custom,
but
what
I
want
is
dashboard
prometheus
to
still
work.
So
what
I'm
proposing
is
that
when
the
cloud
provider
sets
up
your
environment
with
prometheus
and
they
create
some
way
to
get
to
that,
be
it
a
virtual
gateway
or
something
that
they
put,
that
in
a
config
map
that
the
user
can
see
in
the
user's
own
cluster.
C
A
A
C
B
It
could
be
helpful
to
think
of
this,
not
as
a
command
that
is
designed
for
troubleshooting.
This
is
not
the
way
that
we
would
recommend
that
anyone
continuously
access
their
prometheus
system
in
a
production
environment.
Instead,
it's
a
helper
command
that
is
useful
when
starting
off
with
this
deal,
it's
good
so
far
as
it
goes,
but
it's
not
designed
to
be
used
permanently
or
for
troubleshooting,
or
anything
like
that.
C
B
B
Those
are
both
valid
users
of
our
system,
constant.
We,
we
definitely
need
to
increase
the
focus
on
the
user
of
a
like
the
application
name
space
owner
that
sort
of
thing
increased
focus
there
is
good,
but
removing
existing
functionality
for
other
users
is
not
the
way
that
we
go
about
doing
that.
Right,
just
add
new
commands
for
that
particular
user
type.
C
A
Our
demo
used
to
be
you
know
it's
all
book
info
now.
Now
you
can
bring
up
prometheus
and
grafana
sure
you're
installing
the
demo
profile
you've
installed
the
item
they're
all
there
now
we're
going
to
say,
but
we're
not
going
to
tell
you
how
to
find
that
stuff
you're
going
to
find
it
on
your
own,
with
cube
cuddle.
C
Sure,
but
it
doesn't
have
to
be
your
cattle
command.
I
mean
we
can
it's
a
demo
of
of
how
to
not
do
things.
Basically,
so
if
you
want
to
have
a
demo,
you
should
you
know,
have
a
big
phone
saying.
This
is
not
something
you
would
do
in
production
and
run
us
root,
and
and
and
so
again
we
are
focused
on
them
or
not
on
production
and
and
and.
B
A
I
think
I'm
adding
we're
promoting
some
functionality,
so
remember
we
have
that
new
dark
launched
is
to
cuddle
defaults.
It
could
be
that
the
prometheus
thing
just
sets
up
a
port
forward,
something
that's
in
that
default
file,
so
it
literally
just
looks
up
something
on
your
local
file
system
and
does
something
but.
C
How
you,
how
it's
even
implemented?
How
do
you
even
know
which
promises
it
is-
I
mean
it
can
be
in
any
namespace?
It
can
be
running
as
our
other
user.
It
may
be
in
a
remote
cluster,
because
that's
also
possible.
I'm
suggesting
that
your
cloud
provider,
when
you
install
istio,
gives
you
a
configuration.
E
That's
I
I
don't
I'd
like
I'm.
I
want
I'm
pretty
fine
with
keeping
this
command,
but
I
think
what
you're
proposing
is
far
and
not
accurate,
because
first
of
all,
a
cloud
provider
may
not
even
provide
prometheus.
They
may
provide
15
different
prometheuses
that
are
doing
all
sorts
of
federation
and
other
things
or
any
anything
in
between
like
we
we
eat
prometheus
is
not
part
of
ustio
and
we
do
not
dictate
how
a
user
connects
to
prometheus.
E
C
How
about
how
about
having
an
istio
demo
command,
which
is,
as
you
said,
useful
for
people
who
do
demos,
and
then
you
can
have
dashboards
there?
We
keep
the
code,
we
keep
everything
that
is
your
demo
and
then
for
production
users
and
what
we
want
to
actually
support
and
and
and
tell
users
of
centralist
ud.
We
we,
we
have
a
clean
steel
cattle
that
is,
or
is
your
user
whatever
you
want
to
call
it
that
is
focused
on
on
on
things.
We
can
do
for
central
history
and
manage
these.
Your
cases.