►
From YouTube: Istio User Experience working group, June 16 2020
Description
Istio User Experience working group meeting held June 16 2020
B
Yes,
so
a
quick
status
on
the
status
status,
we
we
have
some
things
to
discuss
regarding
moving
status
forward
to
beta
whether
it
should
move
forward
to
beta
in
its
current
form
or
whether
there's
another
form
or
another
implementation
that
needs
to
be
considered
before
we
do
that.
The
environments
and
networking
working
groups
are
very
interested
in
this,
and
so
the
TOC
has
asked
that
we
have
a
meeting
to
discuss
it,
just
not
to
kind
of
run
over
anybody
else's
agenda,
because
I
know
that
we
all
have
other
things
to
do
so.
B
A
B
B
A
First,
setting
up
and
making
sure
people
come
to
that
edge.
My
pleasure,
though
the
first
thing
I
wanted
to
talk
about
are
the
user
facing
commands
with
central
this
Tod.
Since
the
last
meeting
I
reworked
the
description,
you
have
to
check
boxes
as
to
what
has
been
done
and
what
hasn't,
and
as
we
can
see,
a
lot
of
pieces
are
missing.
They
don't
have
assignments
over
hoping
networking
would
take
care
of
here's
a
drawing
as
well,
and
this
drawing
was
based
on
my
discussion
with
costs
so
previously
discussed
this.
A
There
had
been
the
hope
that
these
three
is
Tod
instances.
These
three
shards
would
be
exchanging
information
so
that
a
call
to
one
of
them
could
return
all
the
proxy
status
of
all
of
the
clients.
But
custom
was
concerned
that
might
slip
and
proposed
that
we
use
cluster
load
assignment
to
get
the
addresses
of
each
instance
and
plate.
A
I
tried
that
and
it
works,
but
it
only
works
if
you
have
a
flat
network.
So
this
may
put
us
back
to
square
one
for
supporting
this
from
the
point
of
view
of
running
this
behind
some
kind
of
firewall,
where
the
internal
network
is
not
reachable.
I'm
gonna
try
to
get
more
attention.
I
created
a
work
item
for
this
uncharted
view.
Previously
it
had
been
just
tracked
under
some
other
RFC's,
so
that
and
I
think
we
may
need
to
help
networking
out
with
that.
A
A
Instead
of
talking
directly
to
this
via
flat
network,
as
I
show
here
there
had
been
the
talk
of
his
to
cuddle
talking
to
the
ingress
gateway
on
control
plane,
one
or
talking
to
the
sleep
pod
and/or,
the
ingress
gateway
on
control
plane
to
letting
one
of
those
let
us
piggyback
on
its
existing
connection
in
so
that
item
was
thought.
It
is
pointless
if
these
pods
can't
unsharp
so
that
that's
did
never
network
difficulty.
In
terms
of
the
individual
commands
we
have
is
to
cuddle
white,
which
has
mich
Mich
it
has
that
Mitch.
B
A
A
B
A
A
P
are
either
to
support
it
or
to
use
it
will
do
thanks
that
excellent
I'm
I
created
an
issue
for
the
next
feature.
Cuss
has
implemented
it
that's
been
difficult
to
using
that
may
be
operated
her
difficulties
from
eighty
or
a
maybe
that
it's
not
implemented
so
distracting
that
now,
there's
sto
cuddle
version.
A
We
can
get
I
believe
the
version
of
the
sidecar
is
the
version
of
the
data
planning
from
the
same
stuff
that
we're
using
in
proxy
status,
but
the
version
of
the
control
plane
is
not
reported
by
that
and
I
need
to
understand.
If
there's
going
to
be
an
XD
s
event
for
that
as
well
and
finally
describe
which
I
think
I
can
easily
handle
I've
given
the
other
stuff.
A
This
was
Howard's
idea
when
we
go
to
the
next
version
of
sto.
With
the
v3
envoy,
configuration
very
little
was
being
output.
He
and
I
worked
together
on
an
implementation
of
listeners,
which
has
been
checked
in
as
part
of
that
work.
I
thought
that
we
should
improve
proxy
configure
a
lapel.
Currently
it's
quite
useless.
At
the
same
time,
I
had
that
idea.
Rom
venom
from
IBM
also
had
that
idea
and
proposed
that
we
replace
the
current
output.
A
This
is
what
you
see
for
the
ingress
gateway
with
something
more
accepting
that
might
show
the
paths
the
hosts,
and
this
kind
of
thing
so
I
think
I
can
take
care
of
the
implementation
on
that
the
what
I
wanted
to
bring
up
to
everyone
here
is.
First,
the
new
listeners
output
I
kept
the
old
output,
but
I
made
it
non
default.
The
default
output
is
new.
If
anyone
is
trying
to
scrape
the
output
in
a
script,
that's
not
gonna
work,
no
I
didn't
know
if
that
was
really
allowed.
A
F
D
E
You
can
chat
fine,
so
the
this
is
mostly
an
FYI
I
want
people
to
come
review.
This
I
can
walk
through
a
little
bit.
The
general
idea
here
is
that
we
want
to
make
it
a
lot
simpler
to
run
and
operate
VMs
with
this
do
so
right
now
the
instructions
are
pretty
long
for
setting
up
VMs.
The
proposal
leads
to
simplify
that
a
lot
by
having
a
flow
that,
basically,
if
you
scroll
down
to
user
experience,
actually
I
can
walk
through
the
flow.
I.
E
Think
that'll
be
the
most
interesting
for
this
group,
so
the
the
strawman
user
experience
is
basically
that
you
run
a
command
that
registers
a
VM
deployment,
which
is
kind
of
a
new
concept
of
a
group
of
VMs,
rather
than
a
single
VM,
give
it
a
name
give
it
a
name.
Space
label
service
account
basically
the
stuff.
That's
currently
on
service
sort
of
workload.
Entry
today,
but
without
the
actual
end
point
so
you'd
register
that
and
then
you'd
run
a
command
to
create
kind
of
an
install
package
for
that
VM.
E
So
this
has
things
like
the
CA
route,
bootstrap
tokens,
the
proxy
config,
the
mesh
config.
All
that
kind
of
stuff,
so
now
that
has
to
be
sort
of
manually,
popular
image,
copy
that
package
vbm
and
then
just
pass
it
to
history
agent
at
startup.
But
that's
that's.
Basically
the
proposal,
there's
a
bunch
of
other
stuff
in
this
talk
around
improving
some
other
aspects
of
VMs
and
proving
some
the
debugging,
mostly
of
the
agent
that
kind
of
stuff,
but
the
I
think
the
interesting
thing
for
this
group
is
basically
this.
E
A
Some
of
the
central
SEO
D
stuff
had
that
I'm
working
on
I
didn't
discuss
that
when
we
went
through
the
issues,
maybe
I
should
have
had
similar
problems
with
security
when
it's
on
the
security
that
you
need
to
do,
a
proxy
status
might
be
similar
to
the
security.
You
might
need
to
pull
a
configuration
for
a
new
member
of
the
mesh
I'm.
Just
wondering
how
reusable.
E
The
yeah
that's
interesting,
I
hadn't
thought
about
the
centralist,
VOD
parts
to
this,
because
if
we
do
this,
we
would
register
this
not
in
the
main
cluster
that,
if
duty
is
actually
running
in
but
in
the
remote
cluster,
assuming
the
user
doesn't
have
access
to.
You
know
their
names
based
on
that
cluster,
so
they
would
have
to
register
into
the
remote
cluster.
E
E
E
How
about
a
about
a
group
of
VMs
and
we
would
use
it
for
the
service
account
and
for
the
labels
and
the
namespace
labels,
especially
your
useful.
So
then
we
can,
for
example,
make
sidecar
resource.
Actually,
work
for
BM
is
proprietary,
but
pulling
in
details
from
that
and
one
way
I
think
about
this,
like
it's
sort
of
like
doing
a
cube
inject.
So
this
is
kind
of
like
human
jacked
on
a
on
a
deployment
is
kind
of
similar
to
running
that
package
command
on
a
work,
but
in
terms
of
the
information
it
needs
together.
D
A
E
C
Resource
yes,
so
my
primary
concern
was
just
having
someone
not
have
to
write
yeah
mole
to
create
something
with
a
name
and
labels,
okay,
having
to
remember
the
whole
type
URI,
and
things
like
that.
I
find
to
be
problematic.
So
if
it
just
dumps
out
yeah
Moe,
they
can
then
be
piped
in
to
keep
CTL
that'd.
Be
fine
with
me,
but
I,
don't
know
what
what
the
rest
of
the
team
feels.
E
So
there's
there's
prior
art
with
how
kubernetes
has
like
that
service
creation
command,
and
we
have
some
stuff
with
VMs.
Already
around
registering
service
entries
right,
I'll,
probably
just
say,
take
a
cue
from
those
I.
Don't
know
if
those
have
a
spit
out,
yeah
mole
version
or
if
they
just
always
right.
A
Right
with
kubernetes
I'm
used
to
and
look
dry
run
and
some
output
options,
but
so
I'm
sure
we
can
have
this
I
think
it's
a
nice
feature
to
help.
People
see
the
structure
of
the
new
item.
The
next
thing
is
to
package
this
all
into
a
tarball,
and
this
requires
one.
You
couldn't
just
do
two
on
its
own
correct.
E
E
A
A
And
for
is
also
done
using
the
users
own
methods
for
this
yeah
and
Sri
Ram
is
pushing
the
soccer
boot
chef
command,
which
does
a
lot
of
things
using
docker
and
as
responses
to
him
and
I
think
they
make
sense.
But
do
you
think
users
are
going
to
be
confused
if
there's
both
a
pack
which
one
to
use
for
which.
E
Well,
so
I
think
it's
like
our
bootstrap
would
be
written
in
terms
of
ease
commands,
so
it's
it's
a
layer
on
top
and
in
if
it
works
for
the
user,
I
think
we
can
tell
them
they're
welcome
to
use
it.
It's
only
for
a
specific
subset
of
use
cases,
though
where's
the
building
blocks
can
use
for
a
bunch
of
fronts
right,
so
these
can
can
be
used
in
a
CI
CD
system
or
the
user
is
managing
their
own
images
and
copying
them
over
right
does
Hank.
Our
bootstrapping
argues.
A
With
that,
psycho
blue
ship
does
a
lot
of
things
yeah,
so
it
may
be
that
we
want
to
have
a
command
that
groups
together
both
sidecar
bootstrap
and
these
other
things.
So
we
exhibit
being
called
son
car
get
bootstrap.
We
have
like
a
subcommittee
sidecar
with
options,
bootstrap
register
pack.
That
kind
of
thing
you.
A
E
A
E
Not
yet,
but
in
the
future,
probably
that's
one
thing
we're
talking
about:
adding
is
potentially
the
ability
to
have
other
foreign
service
accounts
registered
there.
So
that's
an
active
discussion.
There
might
be
a
couple
other
things,
but
most
of
the
benefit
is
in
having
the
namespace
on
the
labels
emanate.
A
Will
there
be
anything
any
kind
of
annotations
on
this
to
control?
It
I
mean
like
when
we
inject
a
pod,
there's
a
bunch
of
annotations
that
control
how
that
happens.
Will
there
need
to
be
things
here,
I'm
thinking
it,
for
example,
of
afters
multiple
control
plans
like
a
canary
with
the
B
annotations
to
canary
how
this
work
load
deployment
gets
blue,
strat,
yeah,
I.
Think.
E
We
probably
do
want
to
think
about
some
of
that
stuff.
There's
an
active
discussion
to
that.
You
can
see
in
cement
threads
I
think
about
whether
this
should
whether
there
should
be
a
work
load,
deployment
plus
a
workload
entry
as
separate
resources
or
whether
they
should
can
be
combined
into
one
and
multiple
writers
and
a
bunch
of
other
discussions.
Those
will
be
in
the
design
dog,
but
yeah
I
think
we
want
all
of
our
annotations
that
work
on
Todd's
and
deployments
and
other
ordinary
stuff
to
also
work
on
this.
E
So
there,
basically
some
yes,
I
I
was
thinking
specifically
if
you
want
to
be
able
to
annotate
the
workload
entry
versus
the
deployment,
all
right,
the
individual
pod
versus
the
whole
thing.
How
do
you
do
it
so
I
don't
know,
but
yeah
actually
I
mean
one
way.
We
just
spin
up
a
new
deployment
and
deploy
a
new
game.
So
yes
yeah.
Sorry,
there's
not
enough
about
that!
But
yeah.
Absolutely
it's
a
good
idea
cook.
A
E
This
represents
a
group,
so
one
potential
name
would
be
workload
group
actually
because
I'm
I,
don't
I,
don't
like
the
name
deployment,
because
it
makes
people
think
this
is
actually
doing
the
employment,
so
it
this
is
meant
to
be
a
group
of
yemm's.
That
may
be
something
else.
Some
other
controllers
handling
the
auto
scaling
or
not
even
a
controller,
but
you
know
it's
handle
but
we're
in
the
actual
provider,
land
it'd.
A
E
A
E
A
E
E
E
C
E
Yeah
I
think
we
probably
unless
anyone
has
any
major
concerns.
Well,
they
can
start
at
least
proof-of-concept
work,
assuming
you
know
that
the
details
may
change,
but
the
overall
thrust
of
it
is
gonna
stay
the
same
but
yeah.
Let's
give
people
this
week
to
comment,
and
then
we
can
talk
about
it.
Next,
okay,
if
there's
any
major
issues.
A
B
Context
here
this
came
out
of
the
community
meeting
last.
What
are
they
on
Thursday,
Wednesday
and
essentially,
you've
got
a
user
who
expected
that
if
the
namespace
injection
is
disabled,
but
our
pod
annotation
has
is
enabled
that
the
the
pot
injected
it
does
not
because
the
injector
only
listens
to
enabled
namespaces.
B
So
essentially
they
were
thinking
of
these
as
an
either/or
when,
in
fact,
it's
more
of
an
and
relationship
between
the
two
and
Steve
you've
had
some
ideas
on
how
we
might
be
able
to
improve
the
sidecar
injector
to
listen
to
all
namespaces.
It
had
something
to
do
with
recent
developments
in
kubernetes
and
I
lost
the
thread
at
that
point.
Well,
we'll
have.
A
To
wait
for
Steve
Mike,
my
gut
instinct,
is
that
the
annotations
on
a
pop
or
likely
to
represent
a
user's
true
intention
if
they're
inconsistent,
but
that
if
we
listen
to
every
namespace,
it
requires
more
rback
permission.
A
user
might
only
have
access
to
a
few
namespaces
and
we
don't
that
he's
labeled
and
letting
it
listen
to
all
of
them
might
be
a
security
thing.
Yeah.
B
A
A
B
My
thoughts
behind
it
are
just
that
we
went
to.
We
did
bi-weekly
meetings
because
we
often
didn't
have
much
of
an
agenda
and
didn't
use
the
full
hour.
Now
we
tend
to
be
maxing
out
our
time
most
weeks,
as
well
as
adding
additional
meetings
outside
of
the
normal,
the
normal
cadence.
So
I
thought
it
might
be
good,
at
least
for
a
time
until
we
no
longer
need
it
to
meet
more
frequently
I.
A
G
Thank
you
so,
just
to
give
a
little
bit
of
background
on
it
that
then,
you
know
sorry
to
add
an
itch
that
have
already
had
to
listen
to
it
once,
but
very
briefly.
I
did
something
about
some
identifying
causes
for
support
tickets
and
topics
in
discusses
uio
and
internal
support
cases,
and
it
turns
out
that,
apart
from
having
a
gap
in
documentation,
we
also
have
some
some
serious
deficiencies
with
logging
and
the
reason
why
that's
not
easily
solvable
with
other
other
means
like
like
static,
config,
analyzers
or
error.
G
Checking
and
automated
logic
is
because
often
the
gap
is
between
what
the
user
is
intending
and
what
the
correct
configuration
to
meet
that
intent
would
be.
So
you
know,
user
user
ends
up
generating
a
config
which
is
correct
from
a
SEO
perspective,
but
it
doesn't
do
what
they
expect
and
from
that
point
it
becomes
very
hard
to
actually
take
further
steps
to
debug
what
is
going
on
and
figure
out.
G
The
problem
is
that
pretty
much
all
of
our
logs,
or
at
least
the
vast
majority
of
our
logs,
including
warnings
and
errors,
fall
into
that
category.
So
if
we
look
at
the
the
logs
that
that
typically
are
emitted
from
SEO
components
and
Envoy,
a
lot
of
them
are
very
developer
facing,
so
even
even
for
errors
and
warnings
and
critical
info
events,
often
the
the
stuff
that's
coming
through
the
logs
is,
is
not
not
very
comprehensible.
G
It's
often
noisy.
There
are
many
cases
where
warnings
and
errors
Ashley.
Don't
necessarily
indicate
that
there's
a
problem
because
there's
further
logic,
that's
implicit
to
seeing
these
errors
popping
up
that
you
know
some
some
developer
or
whoever
is
wrote.
The
feature
was
familiar
with.
It
would
need
to
run
in
their
head
to
figure
out
whether
that
particular
log
message
indicates
an
error
or
not
so
so,
there's
a
host
of
problems
with
the
current
logging
system
and
in
parallel
with
with
locking
we
have
other
efforts
that
are
going
on.
G
One
of
them
is
the
the
CR
D
status
work
that
that
Mitch
is
driving.
We
also
have
an
event
notification
system
that
Causton
is
working
on,
and
so
so
there
are.
There
are
other
I
suppose
channels
for
for
users
to
receive
information
about
what's
going
on
with
the
system
and
those
metrics
as
well.
But
what
this
RFC
is
is
particularly
focused
on
is
in
improving
the
quality
of
information
that
goes
into
each
of
those
pipelines.
So,
regardless,
whether
users
consuming
information
about
the
system
through
logs,
you
know
some
some
kind
of
event
notification
system
see.
G
G
That
is
then
subsequently
pushed
into
one
or
more
of
these
pipelines
for
it
for
users
to
open
at
PC.
So
so
what
what
this
RFC
is
is
proposing
is
to
define
the
information
that
we
would
like
for
users
to
see,
regardless
of
of
the
actual
transport
or
how
they
consume.
That
information.
It's
to
agree
upon
just
a
set
of
information
that,
by
default,
error
and
warning
conditions,
would
would
capture
and
and
in
it,
meaning
that,
when
a
developer
is
writing
the
code,
they
would
be
expected
to
provide
this
information
as
part
of
handling
the
condition.
G
A
G
So,
ideally,
I
would
like
to
be
able
to
make
available
to
the
developers
some
fairly
minimal
API.
That
would
support
under
the
hood,
I
reckon
your
channels
for
exporting
these.
This
type
of
critical
events,
errors
warnings
to
a
range
of
destinations,
but
regardless
of
where
it
actually
ends
up
the
the
information,
that's
captured
that
the
cosine
would
be
more
complete
and
more
user
facing.
G
How
do
we
get
from
where
we
are
today?
To
you
know
the
promised
land
where,
where
all
the
all
the
places
in
in
the
code,
you
know,
are
well
sort
of
annotated
and
and
contain
all
the
information
that
we
want
and
and
to
that,
to
help
with
that
I
proposed
some
some
some
path
for
sort
of
gradual
retrofitting,
of
what
we
have
with
with
new
package
and
and
sort
of
dividing
up
that
work,
sort
of
semi-automatically
and
tracking
tracking
progress.
G
So
so
you
know
it's
it's
it's
hard
to
know
exactly
what
the
correct
number
is,
but
it's
gonna
be
somewhere
between
those
two
extremes,
because
in
some
cases
format
F
already
contains
all
the
information
that
you
need
and-
and
you
only
have
to
retrofit
the
the
actual
code
that
finally
catches,
the
chain
of
error
returns
and
it
logs
it
at
that
point.
But
in
some
cases
the
information
you
need
actually
needs
to
be.
G
We
we
would
need
to
get
buy-in
from
from
all
the
groups
and
and
divvy
up
the
work,
probably
by
directory
and
and
have
sort
of
work
group
leads
delegate
some
of
the
work
to
the
different
members
of
of
each
group,
but
you
know
at
least
this
gives
us
some
way
of
especially
tracking
progress.
If
we,
if
we
agree
that
this
is
something
we
want.
A
It
from
anybody,
so
I
have
been
extremely
frustrated
by
the
logging
in
this
Tod
I
rarely
do
PRS
against
disunity,
but
when
I
need
to
do
something
deep
in
there,
like
a
validation
web,
look
I
struggle
with
there
being
too
much
of
the
things.
I
don't
want
in
the
log
and
not
enough
of
the
thing.
I
do
want
I.
A
So
I,
although
I,
have
strong
opinions
on
what
an
error
message
should
look
like
what
someone
who's
having
the
logs.
What
that
should
be.
Rarely
am
I
given
the
chance
to
review
PRS
or
write
PRS
that
do
logging
and
when
I
do
get
one
I.
Rarely
look
to
see
what
level
things
are
being
logged
that
because
of
that
lack
of
familiarity,
do
you
think
we
could
really
move
forward
with
this
and
some
kind
of
in
a
way
that
allows
the
groups
to
sort
of
work
together.
A
G
A
Willing
to
work
on
it
and
separating
things
is
how
the
analyzers
work
I
mean
putting
all
of
the
error
messages
in
a
struct
like
this.
It
has
to
be
go.
Gende
is
gonna.
Give
me
the
control
I
want,
but
isn't
it
frustrating
when
I
see
this
line
of
code,
I
can
sort
of
understand
it.
When
I
see
this
one
I
have
to
I
have
to
click
like
function,
12
to
be
taken
to
what
it
means.
G
Yeah
so
I
think
that's
that's
exactly
the
kind
of
feedback
that
that
is
really
good
to
have.
So
so
we
may
need
to
strike
a
balance
between
having
something
that's
locally
meaningful
but
at
the
same
time
sufficient
that
that
it's
gonna
be
it's
gonna
meet
users
needs,
and
you
know
part
of
the
reason
why
I
think
that
that
there's
really
two
parts
to
every
error.
G
So
the
the
part
that's
the
call
site
which
can
contain
some
subset
of
information,
which
makes
it
easier
for
developers
to
understand
the
code
logic
without
having
to
jump
around
a
lot
and
I'm
and
additional
information
where,
where
you
can
we
can,
you
can
just
go
to
town
and
and
that's
basically,
this,
the
the
struct
that
contains
the
user
facing
info
that
the
you
know
should
be
should
be
reviewed.
I
think
by
by
somebody
who
has
a
more
facing
perspective.
F
G
So
there's
two
reasons:
I
think:
there's
there's
two
reasons:
it's
one
is
that
I
think
if
we
attempt
to
put
all
the
information
that
that
we
need
into
into
the
existing
log
statements,
they're
gonna
get
pretty
pretty
large
and
it's
gonna
be
difficult
to
visually
parse.
What's
there
that's
one
reason,
I
think.
F
D
F
F
B
F
Could
have
air
adding
apply
annotation
to
object
in
response
to
attempt
to
modify
a
resource
like
that's
conveys
the
same
information,
it's
more
succinct
for
the
user
and
the
developer
I
mean
I'm
all
for
structure
blocking
of
have
actual
stuff
like
transaction
ID
in
this
example.
Here
it's
that's
different,
though,
than
having
this
like
more
info
type,
stuff,
yeah,.
B
I
think
the
two
concepts
that
we're
touching
on
are
you're
right,
John,
structured
logging
and
then
a
log
diksha
or
an
error
dictionary.
An
error
dictionary
is
something
that
is
pretty
common
practice
in
enterprise
software,
so
that
there's
a
central
place
to
look
up
error
codes
and
get
information
beyond
the
simple
message
in
terms
of
what's
going
on.
G
A
G
It's
not
so
it's
it's
this.
This
relates
to
multi-tenancy.
You
can
one
piece
of
codes
with
multiple
plans,
and
only
one
tenant
would
get
to
see
a
particular
message.
Potentially
an
objet
hash
is
so.
This
is
just
the
unstructured
format
inputs
into
the
fourth
string,
so
it's
refactoring
the
example
above
which
didn't
have
an
object
hash.
It's
just.
It's
basically
just
passed
on
the
error
I
this.
This
new
message,
basically
just
just
includes
the
jessamine
additional
information
about
the
object,
so
maybe
I
serve
a
primary
key,
not
using.
F
User
experience
working
group
actually
one
to
review
every
single
change
to
a
log
message.
Is
that
something
they
you
guys
desire
to
do,
because
that's
pretty
much
in
those
PRS
one,
two
and
and
ought
to
are
probably
two
different
questions.
I
mean
I
mean
like
because
the
name
of
the
group
has
user
experience
doesn't
mean
that
every
other
working
group
is
incompetent
at
writing.
A
log
message
right
like
do.
We
really
need
to
centralize
this
to
user
experience.
B
Wrong
to
me,
I
see
that
and
I,
don't
think
any
of
us
intend
to
imply
that
other
groups
are
not
competent
at
writing
logs
I
think.
What
we
do
want
to
say,
though,
is
that
the
current
state
of
log
messages
leaves
much
to
be
desired,
and
if
we
can
change
that
with
some
organizational
structure,
that
would
be.
F
Great
but
I,
don't
think
I'd
see
I,
just
no
believe
that
the
organizational
structure
will
do
anything
but
make
being
a
developer,
a
huge
pain
in
the
ass
and
that
if
we
stopped
spending
so
much
time
of
a
stock,
we
could
have
gone
and
fixed
every
single
log
message
in
the
entire
code
base
be
done
with
all
those
and
like
things
like
transaction
IDs
or
contacts
that
those
don't
even
apply
to
like
90%
of
the
log
messages.
So
it's
really
like
we
have
this
complex.
You
know
the
more.
G
So
I
think
I
think
this
is
just
the
proposal
John
and
and
I
I
think.
Maybe
we
could
find
some
middle
ground
here,
because
you
know
I
think
we
also
have
to
think
about
developer
experience
as
well,
but
I
I
do
think
there's
value
in
injecting
additional
process
at
this
stage,
because
I
I
think
you
know
you
and
I
could
spend,
say
a
week.
Cleaning
up
all
the
air
logs
and
things
would
be
great,
but
it's
not
gonna.
Last.
G
You
know
like
those
logs
the
next
feature
that
comes
along
or
the
next
contributor
that
changes
something
over
at
symbol.
It's
is
gonna,
start
falling
through
the
cracks
again,
so
so
I
think
we
could.
We
could
leave
the
debug
stuff
completely
alone.
I
think
we
can
all
agree
that
that's
up
to
the
developer
and
they
can
put
whatever
you
know
garbage
they
they
want
in
there
and
it's
nobody's
gonna
touch
it,
but
for
the
stuff
that's
user
facing
I
would
expect
that
at
least
once
we
clean
it
up.
G
It
shouldn't
change
a
whole
lot,
so
I
I,
don't
think
that
it
would
be
a
huge
burden
on
reviewers,
but
for
for
important
cases
where
we
do
need
to
expose
some
event
through
you.
It
would
encourage
the
developers
and
it
will
force
developers
to
spend
more
time
and
and
put
more
thought
into
what
they're.
Actually
you
know
exposing
to
the
user
and
and
having
help
from
I'm,
not
necessarily
UX,
but
somebody
that
that
is
able
to
provide
feedback
on
what
constitutes
a
good
user
facing
error
message.
G
I
think
would
be
valuable,
so
so
maybe
maybe
we're
where
you're
pushing
back
is.
Is
that
I
agree
I,
don't
think
we
should
go
in
and
and
fix
and
impose
this
on
every
single
log
message:
that's
in
the
codebase.
You
know
there's
clearly
a
subset
of
really
important
events
that
we
should
focus
on,
and
maybe
that's
like
300,
something
like
that.
G
A
For
me,
it
would
be
nice
to
get
the
high
important
ones.
The
warnings
I
off
I
really
look
at
my
pilot
logs,
because
it's
logging,
two
or
three
warnings,
a
minute
which
I
don't
understand,
would
love
to
see.
If
we
could
repeat
your
analysis
just
for
the
logs
that
are
commonly
appearing
and
get
them
quiet
enough,
that
it
would
be
meaningful
to
look
at
the
pile
of
logs
I.