►
From YouTube: Istio User Experience Working Group August 20, 2019
Description
Istio User Experience Working Group meeting held August 20, 2019
A
A
We
also
talked
quite
a
bit
about
the
shuttle
version
and
having
it
check
the
SEO
control
plan
version
and
refusing
to
work
with
back
level
of
control
planes
or
ahead
of
level
control
planes.
No
one
has
commented
on
that
issue
as
well.
So
so
you
do
so.
If
you
want
that,
then
you
horse,
echoing
mute
yourself,
the
so
the
who's
doing
the
demo
of
SCO
cuddle,
analyze,
I.
A
A
B
All
right
so
briefly,
this
is
just
demoing.
An
implementation,
well
odds.
Implementation
of
the
multi
resource
analysis
framework
that
he
proposed
as
a
link
to
the
doc
that
I
put
in
the
agenda.
I,
don't
know
how
many
people
have
seen
that
before
I
know
some
of
you
have
so
we
we
kind
of
highlight
a
couple
of
things
that
are
cool
here,
that
this
does
so
it's
implemented
as
a
common
framework
that
could
be
used
both
from
the
command
line
and
also
live
in
a
cluster.
B
So
one
of
the
things
this
means
is,
we
can
run
it
through
sto
cuddle
analyze,
which
is
what
we
see
here,
and
we
can.
This
is
mobile,
running
it
against
long
pluster
and
we
just
say:
okay
run
the
validators.
It
has
a
library
validator
as
well.
At
the
moment,
the
library
is
very
small,
but
whatever
validations
that
we
would
apply,
we
then
find
where
we
can
get
the
back
things
like
this
with
specific
unique
error
codes.
B
One
of
the
nice
things
jumping
down
to
the
bottom
is
the
version
of
this
library
that
is
also
running
in
gali
means
that
when
you
look
at
the
object
you
can
see
down
here,
bottom
there's
the
status
field
and
that's
populated
with
the
same
error
code.
So
that's
continually
updated
by
Galli
using
the
same
underlying
validation
code.
So
another
neat
thing
that
we
are
able
to
do
right
now
is
we
can
look,
not
just
a
live
cluster.
We
can
also
look
at
files.
B
B
We
look
at
something
like
this.
Where
we're
looking
at
a
particular
file,
it
will
show
us
say:
there's
you've
got
some
bad
gateway
there
and
to
be
clear
what
this
is
looking
at
is
it's
actually
looking
at.
This
is
just
syntax
kinds
of
things
it's
looking
at.
Does
this
gateway
actually
exist
in
the
object
model,
so
the
other
cool
thing
is
not
going
on.
We
look
at
the
live
cluster
in
the
files.
We
can
actually
basically
do
both.
So
we
can
take
starting
from
the
base
of
the
live
cluster.
B
We
can
essentially
simulate
what
would
happen
if
we
apply
a
particular
files
and
see
what
sort
of
validation
stuff
comes
up
there,
so
that
that's
about
it.
For,
for
that
any
other,
each
episode
I
know
that's
a
chapter,
so
just
stick
with
it
right.
So
the
scenarios
that
we've
got
you
can
look
at
live
clusters.
You
can
look
at
a
set
of
static
files.
You
can
look
at
those
files
as
they
as
it
would
work
if
they
were
applied
to
a
live
cluster.
B
You
can
do
all
that
through
is
Co
cuddle
or
whatever
other
interface
you
wanted
to
add,
and
it
also
works
as
something
running
as
part
of
Galle
that
updates
the
status
field.
There's
a
status
field,
data
component.
That
means
the
same
set
of
errors,
can
show
up
in
the
actual
C
RDS
that
you
can
pull.
So
that's
what,
because
not
only
is
it
really
visible
if
he
just
you
know,
do
a
coupe
couple
get
or
something
like
that.
It's
also
available
for
other
applications.
B
A
C
A
Well,
I,
just
instead
of
sending
it
some
text
to
send
at
the
JSON
with
the
CIM
did
that
text
being
a
message
field
so
that
we
can
later
on
at
other
fields
like
has
this?
Has
this
gateways
been
disabled
because
it's
invalid,
which
is
something
we
want
to
add,
or
is
this
gateway
so
new
that
it's
not
yet
been
sent
out
to
the
side
cars?
That
kind
of
thing
just
put
the
text
into
hub
status,
slash
message.
C
Maybe
I'm
confused
so
today
this
is
essentially
in
a
area
of
text.
That's
generated
from
an
area
of
a
big
North
sector.
Diagnostic
messages
right
diagnostic
messages
inside
the
framework
carries
information
about
like
know
where
this
is
coming
from,
like
the
origin
information.
So
if
you
look
at,
for
example,
the
status
here,
you
don't
see
the
origin
information
because
it's
already
tagged
to
the
object.
C
But
if
you
look
up
top
it's
an
error
message
coming
from
the
command
line,
it
tells
you
reach
resources
coming
from
and
we
can
make
it
richer
right
so,
and
this
is
kind
of
the
extent
of
the
diagnostic
information.
So
are
you
suggesting
that
the
extended
diagnostic
model,
so
we
can
attach
more
concretely
type
things
and
we
are
analyzing
and
so
that
they
appear
here
is
that
is
that
intention?
No.
C
B
Yeah
so
one
way
and
muttering
the
kids
kind
of
separate
aspect
to
this,
and
one
of
them
is
we
don't
monopolize
the
status
field.
The
other
one
I
think
is
what
I
was
talking
about
where
we
structure
this
message
a
bit
more,
so
that
if
we
want
to
add
fields
or
just
type
fields,
that
it's
a
bit
more
structured
yeah
and
those
those
both
seem
very
reasonable.
To
me.
A
So
I
would
like
to
see
this
get
in
as
soon
as
possible,
even
if
it's
not
complete,
because
I'd
like
to
get
people
to
try
it
out
and
to
see
if
it
is
doing
what
they
sort
of
want.
Maybe
not
so
there's
two
things.
So
one
is
the
command
line,
which
I
think
is
awesome
and
should
go
in
because
it
involves
no
changes
to
the
server.
Also,
it's
very
low
risk,
a
nice
little
experimental
command,
the
automated
stuff
and
galley.
A
C
D
C
A
C
C
Should
I
be
white,
confident,
yeah?
Okay,
so
let
me
then
go
very
fast
I.
So
I
expect,
first
of
all,
timing
wise.
You
know
in
1.3,
there's
a
gallery
factoring
which
this
depends
on
that's
going
to
be
in
off
by
default.
In
1.4,
that's
going
to
be
on
by
default
and
I
think
we
should
have
the
status
fields
updates
of
by
default
in
1.4,
behind
the
flag
and
in
1.5
we
can
make
it
on
by
default.
C
So
resource
usage,
wise
I,
think
there
are
two
parts
to
this:
there's
a
status
update
controller,
which
is
I,
think
the
most
expensive
thing
that
you
need
to
have,
which
needs
to
keep
track
of
all
the
resources
and
tries
to
update
their
resources
and-
and
you
need
to
see
it
as
a
what
we
need
to
spend
resources
to
make
sure
that
it
is
optimized
right.
So
it
keeps
today
minimal
and
entrepreneur
II,
but
the
actual
analysis
itself
is
based
on
a
on
the
data
model
that
already
that
Yeley
already
cheap.
C
So
the
galley
already
keeps
the
set
of
resources
in
memory
to
create
a
snapshot
of
configuration
to
pass
to
pilots
and
the
analyzers
are
running
simply
on
that
object.
All
right,
so
I
expect
the
I
mean
whatever
analyzers
that
be
right,
which
can
be
expensive.
We
can
actually
have
like
this
may
not
be
written
in
the
most
performed
very
possible
right,
so
they
may
be
a
resource
box.
We
need
to
be
careful
when
writing
the
analyzers
themselves
that
that
we
are
doing
a
good
job.
So
let
me.
A
C
I
think
it's
going
to
be
at
work
in
progress
for
at
least
a
couple
of
releases,
but
you
know
anything
hiding
behind
a
flag
or
you
know,
has
some
variables
making
sure
that
it
is
a
heavily
loaded
system.
For
example,
you
have
the
option
to
run
it.
You
know
much
less
frequently
I
think
we'll
be
okay.
Do.
C
C
So
there's
so
that's
the
thing
they
said.
There's
only
one
rule
at
this
point
right
and
it's
a
showcase
for
there's
nothing
else.
So
and
that's
the
one
that's
firing
I.
So
that's
the
one
that
we
had.
So
you
know
there's
the
infrastructure
part
I
think
it
is
mostly
complete,
but
experimental
and
there's
the
actual
rule
sets
which
don't
exist
today,
which.
A
From
so
I
can
tell
you
that
this
has
nothing
to
do
with
the
SEO
kernel
inspect,
which
is
about
asking
envoy
what
CRD
is
effect
on
that
sidecar
and
then
printing
them
out,
and
so
that
it's
a
good
it's
a
sidecar
and
print
thing,
so
I
have
nothing
to
do
with
everything,
but
we
should
probably
go
on
to
that
survey.
I
think
people
would
like
to
see
that
breakdown.
Can
you
walk
us
through
that
survey.
B
B
E
A
B
B
A
B
Kinds
of
things,
so
kc
ovett
is
a
something
that
somebody
built
specifically
for
this
job
right
of
finding
various
common
bugs
and
being
able
to
report
them.
So
they
run
it
as
their
own
command-line
tool
that
runs
against
a
live
cluster.
There's
a
number
of
specific
vetters
that
look
for
different
issues.
I
listed
cube
man
here
something
I
looked
at
it's.
It's
tells
you
a
lot
about
a
kubernetes
cluster
as
it
turns
out.
It
doesn't
do
much
in
terms
of
highlighting
errors.
That's
less
directly
relevant
here.
B
Jiali
is
really
interesting
because
we
use
it
primarily
as
a
UI
to
inspect
what
a
service
medic
looks
like,
but
it
actually
has
a
pretty
good
library
of
validation
built
into
it.
And
it's
a
it's
actually
a
good
experience
in
a
lot
of
ways,
because
you
it
will
show
you
not
only
where
you've
got
a
mistake.
It'll
it'll
highlight
it
in
the
context
of
the
yellow
file
or
whatever
that
that
it
detected
that
in
so
it's
it's
a
bit
buried.
B
I
had
no
idea,
this
existed
and
I
had
to
go
digging
a
bit
for
it,
but
the
there's
a
pretty
good
library
of
stuff
there
and
I,
really
like
the
user
experience
of
being
able
to
say.
Oh
look
and
I
there's
an
X
next
to
my
virtual
services
and
oh
yes,
I
can
see
that
this
line
of
my
my-y
amel
is
highlighted.
B
So
it's
not
the
kind
of
thing
where
I
can
build
an
adapter
or
something
I
need
to
rewrite
stuff,
just
because
it's
using
slightly
different
object
models
and
and
so
forth,
but
if
those
of
import'
reasonably
well
and
I
think
that
the
real
value
is
in
the
rules
that
have
already
been
kind
of
hammered
out
just
porting.
Those
gives
us
a
good
starting
point.
I
would
really
want
to
talk
to
both
people
behind
this.
Do
vet
and
key
Ollie
in
particular,
these.
F
B
B
There
is
considerable
overlap
in
what
kinds
of
things
are
covered
and
also
the
kind
of
architectural
approach
behind
it,
which
is
the
architectural
approach
overlap,
is
good
because
it
again
it
means
that
porting
them
is
probably
not
going
to
be
too
bad.
Does
a
fair
amount
of
work
involved
just
because
there's
a
lot
of
volume
of
stuff
to
port,
but
I'm
hopeful
that
if
we
read
out
people,
we
could
maybe
get
to
help
with
that.
E
Yeah,
so
on
that
note,
I
wanted
to
propose
that
we
start
having
something
like
a
subcommittee
set
up,
maybe
like
an
hour-long
meeting
next
week.
Each
of
us
can
show
off
what
we've
got
in
terms
of
validation
for,
compare
and
contrast,
and
then
we
can
begin
working
on
kind
of
requirements.
My
concern
is
that
we
come
up
with
a
holistic
approach
to
validation
and
status
within
a
steel,
I
love
all
the
effort
and
all
of
the
initiatives
that's
been
taken
now.
F
Totally
agree
with
that
and
I
think
I
reads
out
or
always
might
have
reached
out
to
me:
I,
don't
know
how
it
started
very
early
on
in
this
process,
and
he
was
just
creating
the
framework.
So
I
would
I
would
be
more
than
happy
now
that
this
framework
is
more
matured
to
move
some
of
this
stuff.
If
I
can
help
or
someone
in
my
team
can
help
and
at
the
same
time
come
up
with
the
consensus
on
what
validations
do
make
sense.
So
that's
great
yeah.
D
B
A
E
A
E
I'll
put
a
invite
in
the
agenda:
I'll
put
it
in
slack
and
I'll,
probably
reach
out
to
the
TOC
members
just
to
see
if
they
know
of
like
I,
don't
think
anybody
from
Cisco's
here
or
VMware
see
if
they've
got
people
who
would
be
interested
in
the
conversation
as
well.
That
way,
we
get
all
of
the
voices
in
place.
I.
C
Okay,
I
think
we
can
make
a
case
for
exposing
something
like
this
through.
The
command
line
is
an
experimental
tool
for
1.3,
but
we
have
a
limited
time
frame
and
this
particular
framework
has
has
just
one
ruler
right.
So
I
think
it
is
current
form.
It
may
not
be
that
great
to
expose,
as
is,
we
may
need
to
add
more
things,
but
I
think
we
might
give
a
shot
that
exposing
this
is
a
nice
to
cuddle
through
in
1.3,
but
otherwise.
B
E
I
think
the
priority
is
getting
it
right
as
we
get
it
out
to
users
so
that
it's
a
nice
consistent
experience
and
something
that
we're
not
going
to
regret
come
one
five,
one
six.
If
we
get
the
ability
to
backboard
it
and
maybe
get
something
out
to
the
community
before
then
in
the
form
of
an
experimentalist,
do
cuddle
command.
That
sounds
great,
but
my
priority
is
making
sure
that
we
we
get
it
right
in
one
for.
F
A
So
that,
if
do
cuddle
inspect
us
a
little
bit
of
validation,
but
it
tries
to
be
more
like,
like
a
if
you're
like
describe
and
telling
you
sort
of
which
rules
are
applied
to
your
pod.
Do
we
think
that
we
should
hold
that
work
and
try
to
roll
into
this,
or
should
we
try
to
put
that
work
out
four
one,
three
and
the
sense
of
it
being
a
synonym
for
described
and
then
try
to
migrate
it
into
that
stuff
later,
so
that
maybe
does
less,
but
still
does
the
describe
type
stuff.
E
C
Yeah
I
think
there's
sufficient
with
different
functionalities
right.
One
of
them
is
looking
at
configuration
and
checking
for
we'll
see
the
other
one
is
looking
at
their
running
posture
and
giving
you
a
quick
diagnostic
information
right.
There
is
some
overlap,
but
I
see
them
as,
like.
You
know
two
relatively
orthogonal.
You
know
UX
scopes,
so
I
could
see
a
new
user
being
shown
the
name
of
this
two
commands
being
unsure
how
they
differ.
That's
a
long-term
concern
yeah
seems
like
kidding.
Oh.
Why.
A
C
Yes,
so
I
don't
have
the
time,
but
one
thing
that
I
would
appreciate.
I
think
we
should
agree
like
this
is
the
common
diagnostic
information
model,
so
you
will
get
the
multi
source
document.
It
describes
a
way
to
like
use
codes
and
naming
for
these
error
messages.
So
I
found
this
very
useful
in
in
a
previous
life
like
90
go
to,
especially
like
some
microphone
products.
You
will
see
that,
like
numbers
having
these
kinds
of
error,
messages
makes
finding
things
online
or
using
tooling
way
way
easier
right.
That's
why
I
nothing
else?
C
A
C
With
it,
yeah
I
think
there's
going
to
be
an
issue
like
give
up.
You
know
the
formulas
and
the
things
but
otherwise,
like
in
bumper
format.
Like
you
know,
we
need
to
locate
some
numbers
spaces
for,
like
you
know
future
like
say,
the
first
hundred
one
is
reserved,
like
you
know,
off
200,
but
after
that
anything
rule
we
have
you
just
just
increment
the
number.
That's
it.
C
A
And
sometimes
an
error
affects
two
things
in
a
framework.
I
wanted
to
understand
that
so,
let's
type
of
virtual
servers
that
refers
to
a
subset,
then
I
have
a
destination
rule
that
defines
that
subset.
Of
course,
the
virtual
service
is
the
one
that
has
a
problem
because
it
might
refer
to
a
substance
doesn't
exist.
Is
there
a
thought
about
if
the
error
message
be
in
more
than
one
place,
so
you're
just
you're,
looking
at
your
destination
rules?
A
B
You
talk
about
that
a
bit
just
so
the
idea
is
the
okay
I
guess
I
print
in
my
head
is:
not
only
can
you
have
your
pointing
at
something
that
doesn't
exist?
You
can
also
have
scenarios
like
you
created
something
that
should
be
referenced
somewhere,
but
isn't
referenced
anywhere
and
really
it's
the
same
error,
probably
but
kind
of
two
sides
I.
C
Also,
don't
want
to
culture
things.
Also,
that's
the
other
side
right,
I.
Think
I
am
personally
a
minimalist
guy.
I
would
say,
like
you
know,
II
most
of
the
time
try
to
pick
one
resource
to
tag
things
with
the
resource
that
you
need
to
edit
to
make
things
work
right,
because
that's
where,
like
you
know
the
most
like
the
error
is,
but
in
the
cases
like
such
as
those
cases
where
things
are
not
reference,
that's
probably
a
different
error
code.
F
A
F
A
F
C
It
makes
you
wonder
this,
be
a
concept
of
more
global
errors
that
are
not
tied
to
any
particular
object.
That
I
can
take
into
account
complex
situations.
I,
don't
know
other
work
with
the
statutes
in
the
ones,
but
conceptually
given
the
need
is
there
I
prefer
if
you
can
push
the
model
all
the
way
up
to
the
point
there,
where
we
can't,
we
have
to
have
the
global
things
like
you
know,
you
can
avoid
the
global
things.
I
think
that
that's
desirable,
mainly
because
you
want
to
have
the
same
constant
experience
with
the
steps
field.
C
Right,
I
totally
believe
that
we
should
have
that
consistent
model.
But
if
you
find
a
case
where
we
simply
can't
well,
okay,
you
know
being
each
other
global
one
give
me
a
come
up
with
a
CR
that
represents
that
and
the
statute
scale,
for
that
CR
is
the
more
complex
rules.
I
think
one
thing
we
are
not
doing
is:
we
are
not.
We
are
not
publishing
communities
of
interest,
so
we
can
actually
also
do
that.
Right.
Now
is
all
of
these
things.
C
C
C
F
A
A
D
D
C
A
Let
me
start
presenting
again,
so
you
know
I'd
ask
for
some
feedback
on
this.
Your
cuddle
inspect
didn't
get
any,
but
we
talked
about
a
lot
this
meeting,
so
this
I
wanted
to
talk
about
multi,
cluster
isolation
and
boundary
in
terms
of
the
user
experience
I,
don't
know
how
many
people
are
sorta,
where
of
it's,
something
that
Vadim
from
IBM
proposed.
A
So
I
started
writing
about
this,
so
the
multi
cluster
that
we
do
this.
You
know
there's
sort
of
three
ways
we
normally
have
been
talking
about
it
and
Vadim
has
been
proposing
a
way
to
do,
isolation
in
which
he
explained,
customers
that
need
and
some
security
features
that
he
wants
to
add.
I
have
a
link
in
to
his
proposal,
which
he
has
shown
briefly
environments
and
more
thoroughly
at
the
networking.
A
A
That
he's
talking
about
so
in
addition
to
those
things,
so
the
short
version
of
what
he's
talking
about
is
that,
in
addition
to
what
you
know,
Jason
has
been
talking
about
for
connecting
a
mesh
and
Jason's
controller
and
command
line
stuff
for
connecting
meshes
and
getting
the
secrets
and
getting
in
to
talk.
Vadim
wants
to
connect
the
services
themselves
and
expose
them
in
a
way
where
they
might
even
have
different
names,
so
you
could
offer
different
aliases.
A
So,
for
example,
you
could
say
my
banking
service
v3,
his
aliases
banking,
public
and
befores,
and
like
releases
banking
data
or
just
totally
renamed
the
services
that
you
offer
he's
got
a
bunch
of
stuff
for
how
to
expose
them.
What
other
clusters
can
see
them
and
he's
got
some
blog
articles
about
that?
A
All
from
hell
he
had
to
do
is
create
this
geo
series
to
do
these
things,
but
it
was
a
lot
of
work,
creating
our
back
and
virtual
services
and
custom
gateways
and
things
so
I
started
drawing
a
picture
of
sort
of
the
kind
of
Federation
we're
doing
in
the
kind
of
operator
work,
that's
being
done
for
it,
and
I
just
wanted
to
get
sort
of
the
communities
consensus
on.
If
this
is
sort
of
the
right
breakdown,
so
jason
has
been
federating.
E
A
Felt
that
they
were
low-level
so
first
it
took
a
lot
of
work
to
sort
of
create
things
properly.
There
were
a
lot
of
cases
where,
if
you
did
another
port
number,
exactly
matching,
you
didn't
know
it
and
things
just
didn't
flow
and
then
once
you
did
have
it
working,
it
was
hard
to
tell
how
the
low
level
is
TOC.
Our
DS
gave
you
the
high
level
stuff
you
wanted.
So
at
a
conceptual
level,
he
was
thinking.
A
I
want
to
I
want
to
expose
my
review
service
on
one
cluster
and
only
the
review
service
I'm
to
be
exposed.
I
want
to
consume
it
by
product
page,
but
I
only
want
to
consume
from
another
disorder
cluster
and
maybe
there's
versioning
differences,
so
I'm
consuming
one
called
public
and
private
and
I
want
to
expose
one
called
b1ad3.
C
E
I
guess
there's
there's
extremis
here:
there's
is
two
provides
very
powerful
low-level
capabilities,
but
that
is
cumbersome
as
you
described
here,
so
we
can
keep
introducing
layers
on
top
of
that
I
guess.
The
thing
that
I
would
be
concerned
about
is,
if
we
add
an
abstraction
on
top
of
that,
is
they
going
to?
Is
it
yourself
a
very
specific
use
case,
or
is
it
common
enough
that
he
could
be
provided
further,
a
building
block,
so
this
probably
some
some
balance
to
strike
there,
which
is
either
find
an
API?
We
have
to
explore.
E
E
I
guess
assigned
in
a
way
that
maybe
it's
more
of
a
comment
on
the
process
of
which
we
arrive
at
whatever
that
API
is.
It
sounds
like
like
you
could
do
this
do
templating
today,
if
you
had
as
part
of
your
deployment
scheme,
you
had
some
templates
that,
given
a
a
leasing,
you'd
wrap
this
do
it.
The
corona
CoAP
is,
and
you
create
your
kind
of
own
de-facto
API
on
top
of
that,
but
it
would
if
I
use
some
capability
to
explore,
how
your?
E
A
A
A
My
team
has
a
blog
post
that
he's
trying
to
get
approval
on
for
the
hidden
low
level,
stuff
and
I
guess
what
I
wanted
to
do
was
to
proposals
for
the
high
level
stuff
in
proposed
API
for
that
and
I'll
bring
them
to
all
the
correct
groups.
I
guess
I'm,
looking
for
people
who,
if
you
want
to
collaborate
on
this
and
think
it's
the
right
things
that
you
need
right
now
in
is
it
part
of
this?
Do?
Is
it
another
tool
that
is
the
core
sto?
E
See
that
the
specific
API
design
might
I
think
the
mall
ready
discussed
this
in
the
context
of
networking
environments
so
for
a
specific
API
discussion
that
might
be
there
soon
appropriate
cliffs
to
talk
about
it.
What
might
be
interesting
or
useful
to
talk
about
the
context
of
the
UX
is
generally
what
the
answer
in
the
problem
is
this.
Is
this
an
sto
problem,
or
is
this
something
that
somebody
else
should
solve?
If
it
is
this
your
problem,
what
are
the
common
mechanisms
that
we
would
provide
similar
to
the
config
working
group?
E
Okay,
if
it
is,
it
need
to
be
an
API
in
the
CR
D.
How
does
it
get
reflected
through
status
and
I'm
in
a
consistent
way
for
things
that
aren't
part
of
the
core
API?
What
our
helper
mechanisms
we
can
provide
like?
You
could
certainly
have
this
as
an
is
to
cuddle
command
that
would
generate
the
respective
underlying
config
I'm,
basically
encoding
a
template
within
a
command
line
tool
that
might
not
be
the
right
model.
E
I've
found
to
be
pretty
difficult
to
get
consensus
on
not
saying
that
we
shouldn't
pursue
that,
but
there's
there's
near-term
things
that
we
can
also
do
to
to
make
users
lights
better
I,
don't
know
like,
but
this
in
this
particular
case,
there's
business
service
defining
an
API
that
everybody's
happy
with
might
be
particularly
difficult
and
I.
Think
there's
some.
Some
people
are
looking
at
how
we
want
it.
We
are
going
to
assist
you
if
there's
any
way
so
I'm,
not
sure
how
that
plays.
Is
it.
A
Currently
the
default
is
NOAA's
geo,
DNS,
but
I'm
told
in
one
feed
the
default
is
going
to
be
as
soon
as
it's
going
to
be
there,
but
they
tried
to
do
some
of
the
mesh
Federation
stuff
and
they
didn't
have
it
I
want
to
get
messages
of
the
kind
of
you
know,
validation,
stuff
out.
This
is
very
different
from
the
kind
of
validation
we've
been
talking
about
with
right
on
the
couple
day.
This
is
I
want
my
control
plane
to
run
this
pod.
E
The
patterns
that
I've
I
can
be
ready
towards
gravitating
towards
interested
to
see
at
other
people
if
it
makes
sense.
Other
people
is
that
you
can
start
in
terms
of
experimenting
and
getting
early
feedback.
We
could
start
with
the
CLI
and
that
was
kind
of
defines
a
defines
an
API,
and
that
could
be
a
set
up
so
install
or
DNS,
but
you
could
also
have
a
kind
of
verify
say:
does
everything
look
correct
based
on
you
know
what
my
intent
was
but
you're
not
running
anything
in
the
cluster?
E
E
Cluster
and
define
a
real
API
for
it,
so
it's
a
path:
kind
of
a
migration
path
from
a
CLI
experience
to
an
operator
CR.
The
experience
I
don't
know
if
starting
with
an
operator
is
the
the
easiest
thing,
because
you've
got
to
define
an
API,
and
then
you
have
this
thing
running
in
the
cluster
with
superuser
privileges
and
you've
got
to
deploy
it
and
upgrade
it
and
there's
just
a
lot
more
work
that
go.
That's
involved
in
and
maintaining
something
like
that.
E
A
Agree
but
then
I've
been
dealing
with
these
small
systems
with
three
clusters
in
my
multi
cluster
mesh
I'm,
if
I
had
a
bigger
system
and
I
was
rolling
stuff
out
dynamically,
more
things
could
happen,
which
is
what
I
was
thinking
along
the
lines
of
eventually
getting
to
an
operator,
but
I
think
you're
right.
A
command
line
is
the
way
to
test
all
this
stuff
and
then
once
we
feel
the
frequency
is
high
enough
that
we
need
to
be
continually
dealing
with
it.
Then
we
need
ya
later
yeah.
C
E
E
Some
so
some
of
the
things
I'm
looking
at
it.
Just
if
you
go
to
the
documentation
today
for
setting
up
some
of
the
different
cluster
scenarios.
Some
of
it
is
just
kind
of
TDM
I
think
so,
if
you
want
to
configure
pilot
to
talk
to
a
remote
cluster,
there's
a
recipe
for
that
it
can
generate
a
secret.
You
label
it
accordingly
and
place
it
in
the
right
clusters.
E
If
you
want
to
do
that
for
more
than
two
or
three
clusters:
you're
you're,
getting
lost
in
environment
variables,
environment,
variables
and
bash,
so
the
one
PR
I
sent
out
yesterday
for
comment
was
making
that
a
little
bit
easier.
So
you
can
just
say:
I
want
to
create
a
secret
for
cluster
n,
and
then
you
can
install
that
in.
A
E
A
E
Right,
so
that's
where
the
bitly
block
nature,
this
comes
I.
Think
constant
is
made
benches,
that
you
can
have
a
single
tool
that
does
everything
or
you
can
kind
of
have
the
Linux
command
line.
Possibly
we
have
a
tool
that
is
one
thing
and
you're
expected
to
compose
it.
So
every
suit
to
get
a
better
understanding
of
the
pain
points
and
see
if
it
makes
life
easier
that
that
is
one
one
consideration.
E
So
we
can
have
you
know
if
the
tool
is
not
going
to
do
everything
when
it's
going
to
drop
you
down
from
fifteen
steps
to
one
step,
but
then
you
could
wrap
that
one
step
in
a
batch
loop,
which
doesn't
seem
very
elegant,
but
most
people
understand.
However,
that
is
that
bash
script
becomes
ten
or
fifteen
lines
long.
It's
probably
a
good
idea
that
we
should
reconsider
the
underlying
commands
or
maybe
create
a
real
API
to
wrap
at
all.