►
From YouTube: Istio UX Working Group Meeting July 28, 2020
Description
Review UX items still scheduled for completion in 1.7
UX-owned Istio documentation automated test status
Hongyi on Unifying Istioctl Command Output
Should istioctl command like dashboard support “type/name” notation like kubectl ?
A
A
B
A
A
B
A
A
Frank
from
documentation
has
taken
every
page
in
the
istio
io
doc
and
assigned
it
to
a
working
group.
So
security
got
17..
We
got
33
of
these
documents
and
I
went
through
them
and
labeled
each
one
with
its
title
and
then
tried
to
figure
out
what
its
sort
of
priority
would
be.
So
what
frank
thinks
that
we
should
do
is
write
is
review
all
those
and
write
automated
tests
for
the
ones
that
we
can.
A
So
I
worked
on
automated
tests
for
analyze.
I
did
this
test
and
if
you
look
it
now
has
a
check
mark
on
it.
It
took
me
several
days
to
learn
the
framework
and
get
it
all
done,
but
all
of
these
commands
are
sort
of
run
automatically
when
the
documentation
is
built,
and
so,
if,
when
that
happens,
it's
great
for
us
because
there's
a
spreadsheet
that
we
normally
do
for
every
release
testing
day
and
we
are
trying
to
do
those
tests.
A
A
A
A
A
If
anyone
has
somebody
and
their
team
was
trying
to
learn
this
to
you
or
something
maybe
having
them
try,
some
of
these
tasks
would
be
a
good
way
to
get
them
on
board
and
get
this
stuff
going.
Okay,
hong
yi
has
prepared
a
document
for
us
about
the
output
of
istio
cuddle
ani.
Can
you
walk
us
through
this
document
that
you
want
to
review.
C
One
is
log
format
which
is
intended
to
be
human,
readable
and
the
other
two
are
json
format
and
yaml
format,
and
so
we
would
like
to
implement
these
output
for
pre-check
and
verify
install
to
be
as
close
to
as
close
to
easter
color
analyze
as
possible.
So
basically
the
output
might
look
like
may.
Would
you
mind
scrolling
down
to
the
section
on
proposed
output.
C
So
for
proposed
output,
maybe
a
little
bit
a
little
bit
more
scroll
a
little
bit
so
basically
yeah
right
here.
So
we
would
imagine
that
the
output
might
take
four
parameters
which
will
basically
show
the
level
of
an
output
message,
the
code
of
a
message,
the
origin,
which
is
where
the
message
origin
is
from,
and
also
the
detailed
message
of
why
this
message
is
emitted.
C
So
this
is,
I
also
put
an
example
here
like
in
istio
analyze.
You
would
have
error,
followed
by
the
code
like
isd,
0,
101,
0101,
that
kind
of
stuff
and
a
followed
by
origin
of
that
message.
So,
basically,
in
this
meeting
we
would
like
to
discuss
the
message
code
thing
because
for
pre-check
and
verify
install,
we
would
also
like
to
add
some
message:
codes
for
them
and
we're
we're
proposing
some
of
the
message
codes
for
these
two
commands
and
json.
Do
you
want
to
take
over
from
here.
D
Yeah
sure,
do
you
mind
scrolling
down
a
little
bit.
I
believe
it's
on
right
here.
Yep
there
you
go
yeah.
I
think
we
would
like
to
propose
that
yeah.
If
you
look
at
the
comment
on
the
right,
so
currently
we
have
0
to
100
for
internal
usage
and
100
to
200
for
config
analysis
which
we're
currently
using,
and
we
would
like
to
propose
that
200
to
300
for
control,
plane
resource
analysis.
D
D
A
D
A
A
D
Right
so
I
think
that's
that's
the
main
like
why
we're
proposing
the
range,
so
I
guess
yes,
they
are,
they
might
be
different,
like
the
the
ranges
are
are
for
different
user
targets.
I
think
I
guess
0
to
100,
probably
right
now
it's,
although
we
don't.
I
don't
believe
we
have
error
messages
right
now
for
for
those,
but
those
are
mostly
for
like
easter
internal
stuff
and
targeted
for
easter
developers
and
then
100
to
200.
A
A
The
current
tests
for
valid
or
analyze
a
bunch
of
incorrect
crs
that
they
check
over
one
reason
we
haven't
done
a
lot
of
integration
tests
for
pre-check
and
verify
install
is
that
they
we
don't
have
a
good
mocked
up
situation
of
a
cluster
say
that
doesn't
have
support
for
web
hooks
and
things
like
that.
Do
you
think
we
need
mocking
of
the
sort
of
unusual,
problematic
clusters,
or
do
you
think
it's
fine
just
to
have
tests
for
correctness.
D
So,
like
I'm,
not
specif,
not
specific
to
user
scenario
like
we
test
out
if
the
json
output
is
valid,
if
if
the
command
line
can
output
correctly
in
certain
ways,
but
we
don't
test
specific
on
user
scenarios,
so
I
think
we
can
also
stick
to
that
kind
of
separation.
I
haven't
looked
at
the
unit
tests
we
have
for
and
for
for
pre-track
and
verify
install,
but
I
I
believe
here
what
honey
is
talking
about.
A
Using
istio
cuddle
last
week
and
the
week
before
to
troubleshoot
some
things,
and
I
was
thinking
that
a
lot
of
the
kubernetes
commands,
let
you
use
deployment
or
service
slash
and
in
the
name
of
the
deployment
or
service,
and
it
picks
a
random
pod.
I'm
wondering
if
we
think
that
istio
cuddle
should
do
the
same
thing.
A
A
And
is
there
anything
we
need
to
see
for
next
week?
One
thing
I
really
want
to
do
next
week
is
either
do
or
prepare
for
the
plan.
The
roadmap
for
one
eight,
which
means
we
need
to
identify
candidate
issues
for
one
eight
and
sort
of
prioritize
them.
So
if
you
have
features
that
you
want
for
one
eight,
please
make
an
issue
if
you
think
it
is,
should
be
p,
zero
or
p
one.
A
Definitely
for
one,
eight,
let
me
know,
and
I
will
triage
it
as
such
and
then
next
week
I
can
prepare
a
meeting
with
all
of
the
highly
rated
one
eight
items
and
try
to
see
if
there's
a
sort
of
agreement
on
them.
Everyone
knows
how
zenhub
works
right
with
the
all
right.
Have
people
use,
design
hub
or
people
mostly
using
the
github
stuff.
A
Mix
match
yeah,
so
just
if
you've,
never
if
you're
not
familiar
with
how
we
do
it
in
istio.
There's
these
priorities,
new
issues
and
things
that
our
release
blockers
are
marked,
p0,
etc,
or
release,
blocker
or
or
p
zero.
If
I
don't
know
who
has
access
to
zen
hub
or
whatever
so
I
mean
I
can
move
stuff
around
to
set
priorities,
I
don't
know
who's
allowed
to
do
that.