►
From YouTube: Istio User Experience Working Group August 6, 2019
Description
The Istio User Experience Working Group meeting held August 6, 2019
A
Hello,
everyone,
so
we
have
a
short
agenda,
but
some
interesting
stuff.
Today
we
want
to
discuss
what
we're
calling
the
ISTE
of
coddled
structural
idiom,
meaning
what
order
do
the
commands
work?
We
want
to
talk
about
version
compatibility
between
the
CLI
and
the
control
plane.
We
want
to
talk
about
the
operator
yeah.
If
we
have
the
operator
folks
here,
I
know,
Stephen
couldn't
make
it
and
I
have
a
demo
of
a
steel
cuddle
inspect,
which
I
hope
to
get
into
1/3
and
want
to
get
everyone's
feedback
on
to
everything.
A
A
A
Policy,
so
the
operator
is
proposing
sto
cuddle
and
in
this
category
manifest
and
then
sort
of
possibly
this
is
a
noun,
maybe
its
category
I'm
sure
manifest
versions
manifest
generate
my
my
grade
and
then
profile
list
profile,
dump
and
profile.
Diff,
then
jason
has
a
proposal
for
the
multi
cluster
operator,
which
has
these
commands,
and
these
are
our
scarily
close
to
the
operator
commands
so
that
it
is
a
mess
generate
similar
to
the
manifest
generate,
and
then
there's
only
this
profile
generates
motor,
then
there's
the
mesh
generate.
A
A
A
C
A
A
So
the
idea
was
she
proposed
that
if
you
try
to
operate
an
experimental
command
and
you're,
not
using
experimental,
that
would
sort
of
say:
do
you
want
to
reenter
this
with
experimental
to
sort
of
give
you
a
hint
that
you're
almost
there,
you
almost
got
it,
but
you
forgot
the
words
pheromone,
so
maybe
we
need
a
license
for
a
few
of
the
commands,
especially
during
this
transition
to
a
more
rigorous
way
of
organizing
things.
Yeah
great
I
think
the
Elliots
is
without
good.
A
A
Why
is
it
not
opening
who
Google
Docs
encountered
in
error?
Okay,
well
reloading
helped,
okay,
so
the
motivating
example
is
that
some
of
the
commands
like
proxy
config,
fail
if
invoked
on
newer,
sidecars
and
newer
on
web
versions
than
they
were
meant
for.
We
also
had
a
problem
with
the
sto
cuttle
version
with
the
remote
option,
because
we,
the
control
plane,
switched
to
doing
JSON
instead
of
the
format
it
had
been
doing
and
the
older
command
lines
didn't
work.
So
the
idea
was
instead
of
failing
with
the
mysterious
message.
A
We
should
have
some
rules
to
check
what
the
version
is
and
I
just
threw
out
some
rules,
sort
of
the
top
of
my
hat
approximate
rules.
You
know
if
you're
so
far
ahead
or
behind,
warn
the
user
and
if
you're
on
a
completely
different
version
like
ariel,
is
do
0.7
just
using
halt.
So
this
is
the
proposal.
A
A
Try
to
get
the
control
plane
version
from
the
sidecar
injector
new
Clingman,
the
sod
current
effect
injector
config
map
has
sort
of
kept
some
stuff
about
the
install.
It
has
a
global
tag
that
could
be
used.
If
you
have
our
official
release.
There's
some
talk
in
the
comments
about
what
should
happen
for
daily
builds
as
part
of
this
work.
I
went
through
all
of
the
existing
sto
cuddle
sub
commands
and
reported
their
connection
to
either
kubernetes
or
the
sto
control
plane.
So
often
talks
to
pilots,
authentication,
deregister
talks
to
kubernetes,
etc.
A
A
A
No
well,
since
the
last
call
everyone
has
approved
this
document,
and
this
is
the
command
line
for
the
operator.
At
least.
We
think
it's
supposed
to
be,
and
there
had
been
some
talk
about
making
a
standalone
binary,
but
probably
we're
going
to
roll
it
into
sto
cuddle.
The
commands
themselves
seem
somewhat
strange
to
me,
or
at
least
they
seem
strange
when
I
first
read
through
it,
so
to
figure
out
what
you
can
install.
What
versions
of
it
Co
are
possible.
A
There's
this
idea
of
manifest
versions
that
it's
fetching
from
some
server
on
the
internet,
to
figure
out
which
versions
are
available.
There's
this
manifest
generate
which
generates
kubernetes,
manifests
to
install
this
deal
with,
and
the
whole
thing
on.
First
reading
troubled
me
from
a
user
interface
point
of
view,
so
typically
I
user
installs
this
deal
once
and
then
they
upgrade
it
maybe
forever.
At
least
in
my
model
they
have
a
long-lived
cluster
and
they're
upgrading
it
sort
of
the
way
I
do
so
I.
A
Imagine
that
there
would
be
commands
like
sto
cuddle
install
is
to
cuddle
this
deal
upgrade,
but
these
are
sort
of
more
building
blocks
and
it
looks
like
this
is
what's
going
into
1
3.
If
we
need
higher
level
commands
that
do
this
work,
we
are
going
to
have
to
squeeze
it
in
later.
So
something
like
manifest
apply
is
supposed
to
go
out
and
generate
this
manifest
and
then
apply
it.
So
essentially,
this
is
your
upgrade,
but
it's
it's
unclear.
A
D
So
the
semantics
is
the
desired
semantics
for
this
command
or
that
it
is
both
install
and
upgrade
that
we
wanted
a
model
we
didn't
want
to
treat
them
differently.
It's
kind
of
analogous
to
keep
it
all
apply.
You
don't
necessarily
care
whether
the
the
resources
that
have
resources
exists
before
or
after,
but
that
the
the
tool
or
the
controller
would
do
the
right
thing
and
kind
of
handle
both
did
you
so
with
that
in
mind,
we
picked
apply.
D
A
Actually,
after
reading
this,
a
bunch
of
times
before
improving
it
and
I
was
hesitant,
like
these
commands.
I
think
these
commands
are
logical
for
sort
of
us
and
sort
of
for
advanced
users
that
the
feedback
that
I
kept
giving
was
that
there
should
be
a
sort
of
a
syntactic
sugar,
alias
where
sto
cuddle
install
was
maybe
just
this
manifest
apply
for
the
latest
version
and
steal
cuddle
upgrade
was
just
check
if
there
isn't
existing
a
control
plan,
resource
and
fall
out.
A
If
it
is
intend,
if
there
is
reinstall
a
new
version
using
that
old
control,
signed
resource
or
something
I
mean
I
I
feel
like
it
shouldn't
be
hard
to
make
some
aliases
for
common,
install
and
upgrade.
But
if
it
is
hard
for
some
technical
reasons,
we
can
put
it
off
until
the
next
version.
This
is
still,
but
we
have
now.
A
Right
I
mean
time's
a-wasting
we
I
got
a.
There
was
a
note
on
discussed
that
we
have
to
sign
up
for
1/3
testing,
so
we
can't
really
blue
sky
it
for
any
more
time
and
approved.
We
gotta
make
it
go
but
think
about.
If
there's
any
ways
that
we
can
create.
Aliases
that
look
more
like
something
a
newbie
tire
kicker
would
use.
E
This
is
been
here,
I
think,
that's
actually
a
great
idea.
We
should
consider
it
in
the
context
of
when
we
have
the
controller
as
well.
Sort
of
is
it
installed.
Is
the
default
install
run
with
the
controller?
Is
it
just
the
CLI
mode,
letting
the
CLI
mode
was
originally
kind
of
envisioned
more
as
an
advanced
user
thing
anyway,
but
we
should
figure
out
how
we
want
that
to
fit
in
in.
A
E
Know
I
I
meant
like
if
we
had
his
new
controller
installed,
what
would
it
do
right?
Would
it
would
it
install
the
controller
or
would
it
just
install
the
the
manifest
I
think
we
love
that
we
attach
that
out
that
something
I
don't
know
which
is
which
is
considered
the
easier
option
right
having
that
sounds
some
useful
and
some
sort
of
just
upgraded
to
latest?
Maybe
it
would
give
you.
Hopefully
we
give
you
some
feedback
on
what
it
would
actually
do
and
then
ask
you
if
it's
okay,
but
did
nothing
to
do
that
right.
A
A
E
A
E
A
So
I've
I
proposed
at
several
meetings
ago.
This
is,
do
cuddle
inspect
and
the
feedback
was
that
I
should
make
sure
that
it
used
on
voice
configuration
and
there
was
people
weren't
sure
if
they
wanted
to
sign
off
on
it
or
not
so
I
just
went
ahead
and
implemented
it
because
it's
going
to
be
useful
for
me
whether
or
not
it
goes
into
steel
or
known
and
I,
have
it
as
a
PR
which
is
yet
to
be
reviewed,
but
if
it
was
reviewed,
I
might
go
in
so
don't
review
them
positively,
unless
you
like
it.
A
So
this
is
a
tool
that
I
designed
because
I
was
people
who
were
confused
about
why
they're
sto
didn't
work
and
often
it
had
to
do
with.
They
had
left
this.
The
old
rules
left
around
from
previous
sto
versions,
or
they
had
typos
or
mistakes,
and
there
is
deal
stuff
and
I
thought
about
how
I
might
sort
of
solve
that
and
make
it
more
visible.
A
I
wanted
to
make
something
sort
of
like
Cube
control
described,
but
for
the
sto
rules,
hopefully
where
it
will
have
to
control
describe
for
the
sto
rules
based
on
some
of
the
custom
CRD
open
API
stuff.
But
this
is
more
of
a
peek
into
envoy
and
really
tell
you
if
which,
which
rules
are
connected
to
your
pod
before
sort
of
going
so
for
this
tutorial,
which
will
become
the
blog
article.
A
A
B
This
is
needed
here,
so
I
was
the
one
who
had
suggested
if
you
can
use
the
breadcrumbs
from
on
what
configuration
could
be
really
useful
for
this
tool.
This
information
is
great.
I
was
just
curious.
If
you
were
able
to
use
the
bedrooms,
or
did
you
have
to
go
to
some
other
source
to
get
all
this
great
data
yeah,
so
I'm
using
the
breadcrumbs
for
the
destination
rule
I'm,
not.
B
A
So,
when
I
print
out,
so
this
information
here
is
coming
from
kubernetes
just
by
doing
a
get,
and
this
information
is
coming
from
our
or
this
part
is
coming
from
kubernetes
by
doing
a
get
on
the
service
and
we
match
it.
So
the
service
itself
I'm
not
given
from
the
breadcrumbs
I'm
calling
match
on
that
explicitly
and
recreating
it
so
I.
Couldn't
the
service
comes
from
ad-hoc
logic
of
mine.
I
wish
I
I
thought.
B
So
I
think
maybe
inspecting
the
kubernetes.
Configuration
is
okay
for
this.
But
if
you
are
going
to
inspect
sto
configuration
outside
of
envoy,
then
you
will
have
to
places
with
its
logic
to
figure
out
what
is
to
your
configuration
maps
to
a
particular
workload
that
could
be
dangerous,
so
you're
you're
right.
A
But
it
turns
out
that
actually
the
so
because
we're
following
the
breadcrumbs
we're
getting
a
pretty
correct
information
about
which
destination
rules
are
connected,
and
you
actually,
though,
have
some
comments
on
this
later,
because
the
user
is
not
only
interested
in
which
rules
are
being
used.
They're
also
interested
in
which
rules
aren't
being
used
but
feel
like
they
should
be,
and
I
have
a
demo
of
that.
That
you'll
see
on
this
on
this
demo,
explaining
that
problem
so
hold
that
thought,
because
it's
completely
right
so.
A
A
A
So
we
get
the
same
we
saw
before,
but
we
get
one
additional
piece
which
says:
there's
one
HTTP
route:
we've
got
a
virtual
service
as
part
of
talking
to
this
pod
and
we
have
a
one
HTTP
route
on
that
service.
So
that's
pretty
nice,
that's
not
useful
at
all,
but
at
least
things
are
rocking,
but
now,
let's
take
a
look
at
it
for
the
v2
pod.
A
B
A
D
Us
has
PRV
North
London
for
was
a
cross
resource
analysis
or
multi
resource
analysis,
which
I
think
does.
Some
of
this
has
not
focused
on
the
BOD,
but
it
would
point
out
if
you
had
a
gateway,
a
virtual
service
that
was
bound
to
a
gateway,
but
the
Gateway
didn't
exist
or
virtual
servers
at
reference
to
destination
rope.
The
destination
role
didn't
exist
that
does
get
analyzed
in
galle
and
then
possibly
you're
it
back
into
the
sea
rd
status,
yes,
which
might
be
compatible
with
this
in
some
way,
I.
A
A
B
So
IDI,
if
we
think
about
the
scope
of
this
command,
is
the
school
setting
is
the
idea
that
this
command
tells
you
for
a
workload.
What
SPO
configuration
is
getting
applied
and
also,
which
is
to
configuration
which
you
think
should
get
applied
where
it
is
not
because
the
second
one
is
useful,
but
it's
kind
of
a
big
thing
to
do
so.
You're
right.
A
A
Has
this
great
function
to
match
if
a
host
name
matches
a
service,
I
could
just
call
that
and
then
I
could
subtract
the
things
that
envoy
has
versus
the
things
that
match,
but
aren't
there
so
things
like
wild
cards
or
if
there's
two
destination
rules
or
virtual
services
for
the
same
host
obvious
thing
will
detect
that
if
it
gets
merged,
but
let's
say
there
are
two
destination
rules
for
the
same
host.
I
think
the
user
wants
to
see
this
destination
rule
took
it.
A
D
You
differentiate
the
with
the
experiences
from
the
implementation,
to
my
tell
because
I
think
there's
fewer
people
that
would
object
to
the
experience.
I
think
everybody
said
this
is
really
useful.
What
I've
heard
so
far
is
more
on
the
implementation
side.
Then
either
maybe
some
common
code
or
common
logic
that
can
be
shared
between
this
and
Galilee
or
you
could
use
parts
of
Galilee
and
that
may
change
over
time.
As
these
features
are
emerged
in
this.
A
A
So
suppose
there
were
two
destination
rules
for
the
same
house.
Hopefully
others
work
we'll
put
in
status
field.
Some
warning
like
by
the
way.
This
is
in
conflict
with
this
other
one,
and
one
is
the
accepted
by
pilot
and
one
has
an
but
anyway
I
want
to
show
you
some
more
features
this
and
then
we
can
discuss
sort
of
how
I
did
it
and
if
I
did
it
wrong.
So
anyway,
I
I,
just
I,
just
showed
how
no
no
pods
match
this
subset.
So
suppose.
A
Reviews
v2,
which
had
showed
me
that
nothing
was
going
to
happen
and
now
it's
giving
me
a
very
different
warning
route
to
unknown
subset
and,
as
you
can
see,
there's
no
destination
rule
here,
naming
the
subsets
and
that's
because
while
we
were
talking
I
deleted,
video
configuration
I
had
meant
to
delete
the
virtual
service.
I
accidentally
deleted
the
destination
rules.
So
this
tool
is
supposed
to
tell
you
that.
A
So
you
sort
of
have
run
the
companions
or
figure
out
that
you
did
that
and
then
you
just
sort
of
maybe
know
now
enough
to
fix
it
and
then
becomes
easy.
Things
are
working
again.
So
the
other
features
that
I
put
in
this
tool
was
some
empty.
A
lot
of
stuff,
so
I'm
going
to
apply
strictness
for
this
and
after
I
apply
strictness,
I'm
going
to
show
that
it's
strict
so
right
away.
It
says
clients
are
going
to
speak
in
TLS
and
the
pot
is
going
to
enforce
them.
A
A
When
I
inspect
that
ratings
pod,
instead
of
it
saying
client
uses
TLS
and
the
other
is
giving
me
this
warning
again,
it's
the
same
debug
authentications
that
you
see
mr.
Loftin,
but
it's
just
on
a
single
pod
which
made
it
easier,
but
it
also
resorted
reports,
the
destination
rule
and
the
authentication
policy
that
are
in
conflict
to
sort
of
help
you-
and
this
is
where
I'm
going
to
ask
for
sort
of
user
facing
advice
from
Rahman
others,
I'm
reporting
something
very
tiny
here
or
a
destination
rule
rating
/
default.
A
D
D
A
Would
maybe,
with
an
output
of
JSON
like
optional
JSON
output,
what
would
just
list
the
destination
rules
and
virtual
services
that
are
being
evolved
and
you
could
use
it
that
way?
I
felt
that
the
common
use
case
that
I
get
are
people
who
just
don't
know
what
to
do.
Don't
know
why
the
pods
aren't
working,
so
I
thought
the
default.
A
C
A
It
will
actually
go
through
sort
of
every
pod
and
report.
The
things
that
it
finds
on
the
whole
mesh
so
is
tío
required
if
you're
recommends
or
demands
that
any
ports
on
a
service
be
exposed
by
the
container.
Here's
a
flaw:
it
isn't
my
echo
service,
didn't
expose
anything
on
its
container,
the
tailless
conflict
we
saw
so
this
thing
works
nice.
It's
also
really
good
at
finding
and
I.
Think
I'll
show
I.
Think
I
show
that
later
like.
A
A
A
C
D
Said
a
few
times,
it
is
kind
of
analogous
to
cue
cuddle
describe
that
where
people
might
parse
the
outputted
Cupid
will
describe
to
figure
something
out
about
their
workloads.
One
thing
I've
heard
from
the
kubernetes
team
is
that
that
is
a
problem
because
essentially
output,
a
cue
cuddle
describe
becomes
an
API
and
they
have
to
deal
with
backwards.
Compatibility
agree.
So
when
I
think.
A
About
when
I
script,
I
use,
you
know
cube
cuddle,
inspect
animal
I
would
want
something
like
that
for
this,
that
this,
the
version
I'm
showing
here-
is
the
sort
of
initial
version
or
for
checking
your
configuration,
but
they
couldn't
wanted
something
machine
readable
because
remember
what
in
a
sense,
what
this
is
doing
is
summarizing.
What
you're
on
what
configuration
is
I've
tried
several
times
to
summarize
on
what
configuration
which
is
hard
and
then
it
just
prints
out
the
CRTs.
So.
D
Something
to
think
about
in
terms
of
if
you
had
to
deal
with
backwards
compatibility,
it
would
just
take
a
lot
longer
to
prototype
a
lot
of
the
stuff
I
think.
Whereas
if
you
said,
we
just
limit
the
scope
to
quick
summary
and
then
you
need
to
go
look
further,
someplace
else,
then
at
least
for
a
while,
you
don't
forget,
with
backwards
compatibility.
A
B
A
B
A
A
A
Okay,
so
start
out
default
or
two
entries
for
the
same
hostname.
It's
going
to
put
the
most
specific
one
in
and
your
other
ones
aren't
going
to
be
there
and
you're
never
going
to
know
why,
unless
a
tool
like
this
looked
all
of
the
destination
rules
or
pilot
puts
into
envoy
additional
metadata
about
rejected
runners-up
to
be
a
destination
role
and
virtual
service.
The
other
thing
I
wanted
to
put
into
this
was
output
of
your
sidecar.
So
many
people,
including
me,
get
confused
about
side,
cars
and
there's
no
sidecar.
A
Examples
in
the
sample
of
directories
are
tests
for
it
and
I
wrote
my
own
book
info.
Sidecar
tape
put
product
page
in
a
little
sandbox,
so
it
couldn't
talk
to
anybody,
but
who
it
was
supposed
to
and
I
think
I
made
it
work
out
them
for
that.
We
I
don't
want
to
put
any
stuff
in
this
tool
to
show
you
what
Assad
crowd
looks
like
until
I've
seen
some
good
side
cars,
the
only
side,
cars
I've
seen
have
been
testing
ones,
no
samples,
no
best
practices.
So
that's
for
the
future.
A
I
want
to
put
policy
and
I
mean
the
policy
authentication,
CRD
output,
but
I
wasn't
sure.
If
it'd
be
late,
we
don't
put
a
breadcrumb
forward
into
the
Envoy
config
I
wasn't
sure
if
I
should
try
to
get
it
out
of
pilots,
debug
authentications
and
then
try
to
read
it,
but
maybe
maybe
in
the
future,
I
want
to
show
that
I.
A
There
should
be
some
way
to
sort
of
say,
look,
here's,
here's
a
destination
rule
nobody's
using
it,
and
also
all
these
commands
seemed
like
they
would
be
nice
if
applied
to
a
service
entry
or
a
kubernetes
service
without
the
pod
stuff.
So
none
of
the
stuff
about
subsets
would
be
involved,
but
just
sort
of
showing
what
what
the
kubernetes
service
can
expect
and,
of
course,
that
means
I
couldn't
use
the
technique
of
asking
an
envoy
what
it's
got,
but
pilot
can
generate
the
configuration
for
a
pod.
A
C
A
But
to
do
that
I,
don't
I
had
a
work
out,
I'm
open
for
a
long
duration,
open
for
a
long
time
requesting
a
what
I
called
command
line
pilot
that
would
just
read
in
yellow
files
instead
of
live,
kubernetes
resources
and
just
sort
of
produce
handy
things
like
give
me
an
give
me
an
XD
s
for
a
pod
name
foo.
If
I
had
DZ
animals
in
my
cache
that
that
item
didn't
get
any
attentions,
people
I
think
put
a
thumbs-up
on
it.
B
D
And
looking
at
what's
happening
in
the
chat
right
now,
this
looks
awesome
and
it
seems
like
there's
broad
consensus
that
we
must
have
very
soon
sort
of
the
sort
of
functionality
that
you're
demonstrating
here.
My
concern
is
that
we
seem
to
be
have
implemented
that
functionality.
Some
people
have
put
a
little
bit
of
it
in
key
ally.
Some
of
it
lives
in
is
tio
vet
from
the
aspen
mesh
team
and
Niraj
there's
inspect
here.
Oz
has
a
slightly
different.
Take
on
it.
D
I'm
worried
that
if
we
come
up
with
five
different
systems,
you'll
have
five
different
sets
of
rules.
They
give
you
five
inconsistent
results
when
inspecting
a
given
cluster
I'm
wondering,
if
maybe
it
wouldn't
be
worthwhile
to
look
at
each
of
these
and
see
how
we
can
maybe
unite
around
a
common
shared
library
code
base
or
something
along
those
lines
for
consistency,
sake.
So.
A
B
So
I
can
speak
for
the
stupid
piece.
I
think
I
was
waiting
for
all
the
framework
puddin,
where
we
can
do
things
like
cross
resource
validation
as
part
of
a
spiritual
there
that
lives.
I,
don't
know
currently,
like
all
plan,
is
to
reflect
those
as
part
of
status
of
see
are
these.
It
might
also
be
part
of
st
of
CTL,
which
is
fine,
and
then
we
can
move
the
logic
of
some
of
the
logic
of
st
of
it
and
find
out
what
you
want
if.
C
A
I
don't
want
to
introduce
a
lot
of
technical
debt
like
if
people
demand
a
certain
Wow
use
to
it,
but
it
would
be
great
if
one
three
had
something
in
it,
whether
it's
this
or
ratio
that
or
yeah
I,
think
I
creative.
We
should
you
know,
definitely
interested
in
delivering
this
on
one
three:
throw
the
ring
get
feedback
from
user.
A
We
could
try
to
scope
this
down
to
see
if
that
helps
get
it
out
the
door.
It
sounded
like
when
you
talked
about
just
doing
what
is
applied
to
a
particular
pod
and
that
itself
is
useful,
and
but
there
was
no
major
issues
with
that.
It's
when
the
tool
was
trying
to
determine
what
you
intended
to
apply.
That's
when
I
saw
a
lot
of
concerns
from
users,
but
what
if
we
just
did
what
is
applied
and
then
released
that
as
an
experimental
feature
in
one
happen,
so
the
current
code
only
shows
what's
applied
it.
A
It
doesn't
by
scraping
the
envoy
configuration
and
the
results
of
pilot
debug
on
ten
occasions,
and
it
just
prints
out
my
summary
of
stuff
I'm.
The
only
thing
that
it
does
that's
at
all
complicated
is
printing
up
the
subsets
which
could
be
removed
if
there
was
objection
to
it,
yeah
I.
Think
from
like
the
debugging
user
experience.
I
think
we
need
the
underlying
implementation
detail
on
the
overlap
between
the
all
the
other
stuff
that
we
have
groups,
doing,
config,
validation
and
and
config
statuses.
A
I
think
those
could
be
re
are
connected
to
build
on
one
another,
but
as
a
debug
toward
I
think
we
we
do
need
this.
So
the
reason
I
did
a
lot
of
work
on
those
subsets
was
because
the
unmatched
subset
problem
I
expect
how
this
tool
is
going
to
pick
up.
If
you
you
refer
to
a
subsidy
exist,
it
should
tell
you
on
the
CR
D
for
the
virtual
service,
but
if
your
pod
isn't
a
member
of
one
of
the
subsets,
it's
in
the
virtual
service
there's
nothing
wrong
with
that.
A
It's
nothing
wrong
with
having
a
pod
that
no
one
talks
to
so
I
thought
that
it
would
it's
so
it's
worth
considering.
You
know
keeping
this
sort
of
ad
hoc
subset
stuff
in
because
it
just
makes
it
super
easy
to
see
the
subset
stuff
which
so
many
people
get
wrong
and
not
understanding
that
they
need
to
define
them
all.
A
D
In
that
sense,
then,
maybe
it
makes
sense
to
push
this
in
in
1
3.
This
will
generate
it'll,
be
useful
to
people
who
don't
have
a
tool
currently
or
who
haven't
discovered
the
additional
tools
that
they
could
install
to
do.
This
it'll
generate
a
lot
of
conversation
around
how
these
things
should
work
and
buy
us
a
full
quarter
to
really
talk
about
long
term,
how
we
bring
these
tools
together
and
make
sure
that
we're
covering
all
of
the
desired
use,
cases
and
architectural
constraints,
etc.
D
That's
consistent
with
what
we've
done
on
the
operator
as
well.
So
all
the
new
operator
type
commands
that
were
integrating
into
SEO
cuddle
are
under
experimental.
We
know
they
will
exist
in
some
form,
but
this
is
based
on
tax
is
not
locked
down.
Maybe
we
can
do
a
better
job
of
making
that
clear
to
users
when
they
use
experimental,
because
I
think
there's
some
experimental
commands
have
been
around
for
a
year.
C
D
D
When
exam
point
is
I,
think
it's
experimental
should
be
clear
that
this
is
subject
to
change
we've
just
kind
of
overloaded
that
over
to
overtime
and
if
we
can
take
it
back
to
its
original
intent,
then
maybe
just
something
in
the
release.
Notes
that
says:
no
really
we
mean
it
experimental.
We
really
intervals.
C
C
C
C
A
So
what
I'm
hearing
is
that
I
should
try
to
get
this
into
one
three
as
experimental
promises
get
feedback
and
see
if
I
can
make
it
use
more
of
a
chorus
to
your
features
in
the
future,
so
that
it
does
as
little
as
possible
on
its
own
I'm
going
to
try
to
make
that
happen.
If,
if
it
turns
out
that
this
does
not
merged,
then
I
will
throw
it
in
these
two
ecosystem
and
let
people
experiment
with
it.
There
well.