►
From YouTube: 2020-11-03 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
C
A
Yeah
they
do
a
good
job.
I
heard
actually
people
because
they
do
some
like
automatic
muting
to
like
make
conversation
flows
easier.
They
like
dynamically
sort
of
like
do
some
work
there,
and
I
heard
it's
like
changing
people's
like
speech
patterns,
because
they're
now
like
relying
on
this
sort
of,
like
assistance
of
that,
doesn't
exist
in
real
life,
real
life.
So
it's
interesting.
C
A
B
Reality
well.
Well,
I
don't
know
it's
it's
seven
after
so,
and
this
looks
like
the
the
usual
group
of
people
and
plus
one.
I
don't
think
I've
seen
angela
here
before
welcome
thanks
matt.
B
Yeah,
so
I
guess
we
can
do
the
usual.
I
can
run
through
kind
of
summary
of
the
spec
sig
and
then
we
can
kind
of
jump
into
ruby
related
issues
unless
anybody
has
any
other
plans.
Ideas.
B
B
All
right,
so
I
think
we
talked
about
this
a
little
bit
last
week,
but
there
is
kind
of
this
user
research,
dog,
fooding
business,
and
this
was
kind
of
it
came
up
at
the
maintainers
meeting.
B
It
was
kind
of
like
an
invitation
for
people
from
various
sigs
to
try
out
other
language
sex
implementations,
so
this
is
kind
of
like
the
official,
the
official
way
to
do
this.
So
if
you
want
to
do
this,
you
can
kind
of
go
through
this
document.
I
think
you're
supposed
to
like
I
mean
there's
instructions
here,
but
you
create
a
copy
of
the
document
go
through
it
and
then.
C
B
Cool
yeah-
and
I
guess
I
don't
know
what
will
happen
after
that,
but
I
assume
somehow
they
will.
People
will
start
surfacing
this
information
back
to
the
to
the
sega
so
that
we
can
help
help
and
improve
things.
C
B
As
always
like
yeah,
I
think
having
having
more
information
is
always
better
than
having
it
not
enough.
So,
okay,
great
somebody,
is
taking
notes.
This
is
awesome.
B
Yeah
so
then
the
meeting
did
not
really
follow
the
outline
here.
We
kind
of
jumped
in
to
we
jumped
in
to
this
rename
labels
discussion
and
this
kind
of
ended
up
actually
taking
quite
a
while.
B
So
I
think
we
brought
this
up
here
a
little
bit
before,
but
right
now
the
this
terminology
kind
of
refers
to
the
key
value
pairs,
so
attributes
kind
of
refer
to
the
key
value
pairs
that
you
are
adding
to
a
span.
B
There
are
also
resource
attributes
which
might
be
slightly
different,
I'm
a
little
unclear
how
they
differ,
but
maybe
they
differ
in
maybe
not
being
able
to
have
collection
values,
I'm
not
exactly
sure,
but
there's
a
distinction
there
too,
and
then
there's
yet
a
third
distinction
which
is
on
metrics.
B
These
key
value
pairs
are
called
labels
and
for
those
there's
a
little
bit
more
or
there's
at
least
a
reason
that
I
understand-
and
the
reasoning
is
that
these
are
meant
to
be
string,
string,
key
value
pairs
as
opposed
to
our
our
span,
attributes,
which
can
be
you
know,
strings
numbers,
booleans
arrays
thereof
as
long
as
they're,
homogeneous
and
someday,
possibly
maps.
So
in
general,
it's
like
there's
kind
of
reasoning
behind
this,
but
there's
like
confusion
as
well.
B
I
guess,
and
as
for
us,
it
hasn't
been
like
a
huge
deal,
because
our
metrics,
our
metrics
sdk
anyways,
is
not
quite
there
and
our
metrics
api
as
a
result
is
not
really
used.
So
this
is
kind
of
a
problem
for
future
us
and
maybe
a
problem
that
will
be
solved
for
us.
Hopefully,
by
the
time
we
start
on
it.
B
So
I
feel,
like
I
feel
like
we
are
saving
us
ourselves,
a
lot
of
pain
by
waiting
for
the
dust
to
settle
in
this
area,
which
I
still
keep
thinking
it's
just
like
a
week
or
two
away,
and
I've
been
thinking
that
now
for,
like
I
don't
know
at
least
six
months
and
probably
even
longer
so
but
again
kind
of
this
conversation
yeah.
B
I
think
there
are
two
sides
to
this
argument,
and
one
is
that
the
different
name
is
here
for
a
reason,
and
it
makes
sense-
and
we
just
need
to
explain
it
better
and
the
other
perspective
is.
This
is
confusing,
and
sometimes
people
actually
want
to
use
like
that
same
collection
of
stuff
for
like
a
span
and
a
metric
and
like
they
can't
because
they're
they
are
different
types
like
any
type
of
language,
they're,
definitely
different
types
and
in
a
non-type
language.
B
It's
like
the
values
could
possibly
not
match
expectations
so
to
solve
that,
like
the
the
proposed
solution,
is
that
the
apis
would
accept
attributes
so
values
that
are
things
other
than
strings.
But
everything
would
be
converted
to
a
string
for
the
purposes
of
export,
and
that
would
be
the
way
to
kind
of
smooth
this
over,
where
you
are
able
to
reuse
attributes
between
tracing
and
metrics,
but
still
get
the
correct
desired
result
kind
of
in
the
end.
B
One
other
side
conversation
that
showed
up
here
was
ted
was
describing
an
experience
he
was
having
using
baggage
because
I
guess
baggage
somehow
gets
looped
in,
because
the
key
value
pairs
we
have
in
baggage-
I
don't
know
if
we
even
really
have
a
name
for
them,
but
they
are
technically
supposed
to
be
string.
String
as
well
and
ted
was
mentioning
how
he
was
using
an
api
and
added
a
numeric
value,
and
it
was
just
like
silently
dropped
and
he
didn't
know
what
was
happening.
B
I
wanted
to
kind
of
at
least
this
conversation
was
pretty
pretty
active,
so
I
didn't,
but
I
I
wanted
to
kind
of
say
this
is
kind
of
like
the
error.
Handling
guidance
we
were
given
a
while
ago
for
a
lot
of
things
is
to
definitely
not
raise
an
exception,
but
you
know
try
to
just
kind
of
move
on
in
a
way.
That's
reasonable.
I
think
for
baggage
like
it
could
make
sense
to
just
like
coerce
the
thing
to
a
string.
B
If
you
can
and
then
drop
it,
if
you
can't,
but
still
it's
kind
of
like
a
side
effect
of
the
no
exception
shall
be
raised
by
your
tracing
system,
even
if
it
is
like
improper
api
usage.
So
there's
that.
D
E
So
I
think
it
doesn't
really
impact
processing
that
much.
It
really
just
affects
the
the
api
and
how
we
describe
the
api.
E
B
Yeah
yeah,
my
impression
is
it's:
it's
like
a
it's
a
usability
thing,
it's
really
kind
of
has
a
user
in
mind,
and
I
see
both
sides
of
the
argument.
To
be
honest,
like
part
of
me
is
just
like
you
know,
users
will
get
used
to
this
and
you
know
if
labels
need
to
be
string.
String
and
metrics
like
there
are
some,
like
probably
some
advantage,
I
think,
to
writing
the
code.
B
That
does
the
processing,
if,
if
you
can
rely
on
them,
but
at
the
same
time
as
a
user
like
I
see
wanting
to
be
able
to
use
like
this
same,
like
hash
of
stuff
for
like
attributes
on
a
span
as
on
a
metric
and
like
being
a
little
frustrated
that
there
isn't
a
way
to
do
that,
and
even
just
as
like
a
programmer
knowing
that
okay.
Well,
I
could
write
this
thing.
B
That's
like
you
know
two
labels
or
something
I
just
would
like
feel
frustrated
that
I
have
to
write
that
in
the
first
place
and
a
little
bit
sad
about
probably
the
performance
trade-offs
of
whenever
you
have
to
use
it
kind
of
thing.
E
Yeah,
there's
also
a
reasonable
argument
that
you
know
we're
restricting
metric
label
values
to
strings
right
now,
because
that's
what
our
metric
stores
and
that's
a
limitation
that
our
metric
stores
have.
You
know
the
dominant
ones
being
statsy
and
prometheus
that
doesn't
like.
Should
we
constrain
our
api
to
what
the
existing
systems
are
capable
of,
or
should
we
give
the
api
the
flexibility
to
support
new
systems
that
become
available
later
on
right?
B
Yeah
and
I
think
that
that
does
make
sense,
so
so
yeah.
If,
if
you
have
opinions
on
this,
I
think
people
are
looking
for
them
so
feel
free
to
join
the
conversation.
B
B
The
question
came
up
in
the
rails,
instrumentation
review
about
like
can
we
add
framework,
specific
attributes,
we're
kind
of
tossing.
B
Are
you
know
throwing
on
the
idea
of
adding
controller
in
action
to
as
attributes
on
the
span,
and
I
think
this
all
ultimately
became
moot,
because
I
think
we're
going
to
name
the
span
after
the
controller
in
the
action,
but
for
a
minute
we
were
debating
whether
or
not
we
could
have
these
attributes
if,
if
we
wanted,
because
they're
not
technically
part
of
the
semantic
conventions,
so
I
was
just
trying
to
get
other
opinions
on
this
and
really
just
want
to
see
if
other
people
were
doing
this,
if
it's
a
waste
of
time
to
add
these
to
the
semantic
conventions,
when
they're
really
kind
of
a
rails
very
rails.
B
Flavored
way
to
talk
about
these
things-
and
I
think
in
general,
like
armin's
opinion,
was
the
opinion
that
a
lot
of
people
had
like
you
know.
If,
if
there's
any
chance,
these
are
valuable
to
any
other
language
settings.
Definitely
add
them
to
semantic
conventions
and
even
if
they're,
not
maybe
add
them
anyways
or
at
least
open
a
pr
to
add
them
and
see
where
that
goes.
E
It
seems
fairly
heavyweight
to
take
that
approach
for
very
framework-specific
attributes.
You
know
if
you're
building
instrumentation
for
something
that
is
very
specific
to
the
way
rails,
operates
and
uses
concepts
or
uses
terminology
from
rails.
A
So
is
that
the
convention,
now
that
any
non-standard
attribute
like
I
know
we
got
into
it
a
little
with
whatever
it
was
maybe
it
needs
to
like
was
like.
Let's
say
it
wasn't,
but
some
more
obscure
database.
We
were
making
integration
with
that.
Didn't
have
a
special
section
in
the
spec
like.
Could
we
do?
We
need
to
add
that
section,
then,
to
add
some
tribute.
E
That's
a
good
question
I
mean
I
think,
ultimately,
if
it's
a
data
store
that
is
accessible
from
multiple
languages,
then,
and
the
sorts
of
attributes
that
you
want
to
add
are
not
language
specific,
then
I
think
it
makes
sense
to
go
ahead
and
add
something
to
the
spec
about
it.
You
know
if
we
have
additional
attributes
that
we
want
to
add
for
the
mongodb
instrumentation.
A
A
I
don't
know,
I
don't
know
if
awsome
section,
but
it's
like-
I
guess
maybe
I
guess
yeah,
but
it's
it's
language,
agnostic,
really,
there's
every
every
language
has
a
client
for
ws.
It
would
be
something
where
there's
probably
a
lot
of
details
around
the
you
know
details
straight
to
the
service
you're
connecting
to
and
then
you're
you
want
to
use
their
crazy.
A
You
know
thing
that
whatever
quantum
their
quantum
mechanics
api
and
you
some
metadata
for
that,
so
it's
like
it.
It
feels
like
it'll,
slow
down
the
pace
of
development
to
have
to
get
everything
into
spec
to
prove
it,
but
I
think
it's
maybe
better.
I
guess
that
makes
sense
if
we're,
since
other
languages
will
want
to
abide
by
it
too.
Yeah.
E
I
think
generally,
we
provide
you
know
the
first
person
in
to
provide
instrumentation
for
one
of
these
things
can
go
ahead
and
add
the
attributes
that
seem
to
make
sense
try
to
follow
a
similar
pattern
to
other
semantic
conventions.
E
So
you
know
database
if
it's
for
a
database,
then
you'd
like
use
db
dot
database
name
dot
whatever,
as
your
attribute
name-
and
you
know
the
first
person
into
to
do
that-
gets
to
kind
of
define
stuff
and
then
once
they've
got
it
working,
they
can
throw
up
a
spec
pr
to
say
hey,
let's
add
some
anti-conventions
for
this
thing.
This
is
what
we're
doing,
and
then
you
know
if
people
want
to
bike
on
that.
At
that
point
sure.
B
Yeah-
and
you
know-
I
think
I
don't
know-
I
do
think-
the
armin
comment
is
is
fairly
good
guidance.
If
it
is
applicable
across
multiple
language,
it
would
make
sense
to
add
them
to
the
spec.
I
do
think
if
we
as
we
review
instrumentation,
if
it
really
is
truly
like
a
rails
thing,
I
think
we
should.
B
I
think
we
can
agree
to
add,
add
these
attributes
if
they
make
sense,
I
think
for
me
probably
the
harder
thing
is
just
to
like
figure
out
like
where's
the
line
like
how
many
attributes
are
too
many
and
like
are
all
these
things
actually
useful,
but
that's
probably
just
another
debate
that
will
happen
on
a
per
attribute
basis,
but
yeah,
it's
always
kind
of
like
the
the
tightrope
walk
of
getting
enough
visibility
with
just
not
like
overdoing
it
kind
of
thing
that
we
generally
have
to
do.
B
So
really,
that's
all
that
we
got
to
so
there's
like
quite
a
few
things
that
are
carryover
that
are
probably
gonna
carry
over
to
the
next
spec
meeting.
So.
B
Apparently,
an
issue
of
having
extra
propagators
live
outside
of
the
main
sig
repos.
I
don't
know
if
this
would
have
like
there
are
a
few
like
blessed
propagators,
b3
and
jaeger
tend
to
be
there.
But,
oh,
I
think
I
approve
this
one.
I
think
this
one
is
talking
about
aside
from
b3
and
jaeger.
This
would
be
like
amazon
x-ray
or
maybe
like
a
data
dog
propagator
or
something
should
probably
you
know,
live
somewhere
else.
B
B
So
yeah
on
the
topic
of
the
maintainers
meeting,
the
other
thing
that
I
brought
up
and
discussed
there
was
we
talked
about
this
issue
briefly
towards
the
end
of
the
last
ruby
sig
meeting.
It
was
like
basically
like
how
to
handle
this
situation,
where
you
have
potentially.
B
Potentially,
multiple
spans
created
for
the
outgoing
http
request
and
how
to
kind
of
flow
data
from
one
of
these
higher
rapping
stands
to
your
ultimate,
probably
in
that
https
van.
B
And
so
francis,
throughout
a
proposal
of
having
basically
a
a
specific
http
client
context
that
you
can
like
write
into
from
say
like
in
this
example,
is
koala,
but
faraday
would
be
like
another
example,
so
from
faraday
instrumentation,
you
can
add
some
of
these
attributes
here
and
then
the
net
http
instrumentation
would
pick
this
up
ultimately
and
attach
that
metadata
to
its
span,
which
I
think
is
a
pretty
decent
approach.
B
It.
It
spawned
a
couple
of
other
conversations,
though
just
in
general
like
we
were
talking
about
like
there
are
situations
where
you
can
kind
of
technically.
B
If
you're,
not
careful,
you
can
end
up
with
nested
client
spans
or
maybe
a
that's
a
situation
that
you
have
to
work
through,
and
the
other
ones
that
we
brought
up
were
like
elasticsearch,
where
you
kind
of
generally
think
about
elasticsearch
as
being
like
a
client
span.
But
since
it's
http
underneath
you're
really
gonna
have
a
net
http
spam,
that's
gonna,
be
the
client's
fan.
So
what
what
do
you
actually
do
there?
B
What's
the
right
thing
to
do
there
and
grpc
was
another
example,
so
this
is
actually
a
pretty
interesting
conversation
because,
as
it
turns
out,
everybody
is
doing
something
a
little
bit
different
and
some
people
seem
to
be
oblivious
to
this
problem
to
begin
with,
but
this
particular
one
for
http
instrumentation
nikita
from
the
java
auto
instrumentation
sig,
said
they
kind
of
went
the
opposite
approach
where
they
found
ways
to
like
just
keep
like
decorating
the
higher
level
http
span,
pushing
stuff
up.
B
Generally,
I
feel
like
stuff
does
not
flow
upwards
really
well
in
tracing,
so
I
think
you
know
nobody
was
saying
that
you
had
to
go
that
way.
So.
B
In
terms
of
elasticsearch
we've,
I
found
that
there
were
multiple
approaches
there
as
well,
but
one
approach
that
people
were
taking
was
saying
that
you
know
that
the
approach
I
really
liked
was
that
for
something
like
elasticsearch,
it's
not
a
client's
fan,
it's
a
dbs
fan,
but
the
clients
fan
will
actually
be
your
net
http
fan
and
the
reasoning
why
this
might
be
a
good
design
is
that
you
know
anything
built
over
http.
You
need
to
have
some
kind
of
error
handling
it
might
have
retries.
B
You
know
you
might
end
up
with
multiple
http
stands
for
retries,
for
example
in
a
in
inelastic
search,
query
and
that's
valuable
information
for
your
trace,
and
if
you,
if
you
didn't,
have
this
information
somewhere
that
would
be
lost.
A
B
And
I
think
that's
probably
fine
to
you
to
use
this
kind
of
like
push
down
methodology
to
get
stuff
to
your
hdp
spans.
A
Yeah
I
mean,
I
think
the
proposal
is
fine
and
has
value.
I
don't.
I
think
we
and
at
datadog
we
handle
this
inconsistently
depending
on
language.
In
some
places
we
swallow
the
http
span
completely
or
or
just
make
it
invisible
and
make
everything
part
of.
Like
a
you
know,
a
client,
it's
like
elasticsearch
or
aws
called
abs
clients.
Another
big
example,
I
think
in
ruby.
We
don't,
if
you
would
think
I
would
know
offhand
but
yeah.
I
could
see
cases
where
it's.
A
I
think
it's
broader
to
be
honest
than
a
client.
I
think
it
happens
in
controller
in
frameworks.
You
have
middleware
that
has
some
information,
and
but
you
know
you
want
it
all
to
kind
of
live
in
your
controller
span
or
like
graphql.
Sometimes
you
have
information
and
resolver,
but
yeah
I
mean
I
think
the
proposal
is
good.
B
Well,
this
particular
proposal
or
situation,
I
think,
is
for
this
https
fan
situation.
It's
like
you
kind
of
need.
B
You
need
to
gather
information
at
point
a
and
attach
it
at
point
b,
because
the
thing
in
point
b
hasn't
doesn't
not
exist
yet
right,
whereas
in
the
kind
of
the
http
or
the
kind
of
like
the
request
ban
like
the
rails
span,
the
server's
van
situation,
it's
like
that
server
span
has
been
created
when
the
request
has
been
started.
So
it's
a
lot
easier
to
kind
of
like
add
stuff
to
it.
B
A
Right,
I'm
lost,
but
okay,
it's.
A
B
I
think
that's
fine,
I
guess
the
only
thing
I
was
going
to
mention
about
this
was
you
know
we
did
get
into
like
discussions
about
like
for
like
a
elastic
search,
for
example,
if
you
didn't
want
to
model
the
requests
as
a
underlying
http
request
as
a
span,
you
should
still
keep
that
information
somewhere.
An
event
is
like
a
possibility,
but
I
feel
like
that
kind
of
goes
into
some
slightly
weird
territory
where
there's
there's
not
technically
an
http
event.
B
It's
an
approach
that
could
be
considered,
but
in
my
mind
it
seems
like
it
will
require,
like
some
kind
of
gymnastics
to
like
turn
off
your
http
instrumentation
a
and
like
be
kind
of
gather.
Some
gather
the
data
in
some
ad
hoc
way
to
add
them
as
events.
So,
while
I
recognize
it
from
like
a
in
theory,
this
would
work
kind
of
situation.
B
A
B
B
B
Yeah
and
it's
it's
usually
always
pretty
clearly
the
customer's
fault.
We
rarely
release
vlogs.
B
B
Yeah,
so
I
think
I
think
I
brought
us
up
to
speed
on
a
lot
of
these
things.
Questions
comments.
E
I
haven't
really
seen
much
in
the
way
of
changes
to
the
spec
for
tracing.
I
think
we're
pretty
stable
at
this
point
I
know
we
were
declared
stable
and
you
know
we
had
a
release.
Candidate
declared.
Have
you
seen
or
are
you
aware
of
any
tracing
related
things
that
are
still
open?
Do
you?
E
Are
you
aware
of
things
that
we
haven't
implemented
yet
in
in
the
tracing
api?
I
think
trace.
State
is
probably
the
one
remaining
issue.
Mostly
I'm
I'm
asking
whether
you
feel
we're
at
a
point
where
we
could
actually
do
an
rc
for
open
telemetry,
ruby,
at
least
for
the
tracing
portion.
B
I
think
I
think
we
need
to
do
a
pass
through
the
compliance
matrix
and
the
spec.
I
do
feel
like
there
are
a
handful
of
things
that
are
missing
from
our
apis
and
also
from
from
our
issue
backlog.
B
So,
just
like
offhand,
maybe
take
a
quick
look
at
the
compliance
matrix.
B
B
Yeah,
so
technically
there
are
things
like
jaeger
propagator.
We
don't
have
b3
we
need
to
fill
in.
There
are
like
fields,
there's
this
fields
and
keys,
kind
of
notion
and
context
propagation
or
your
your.
I
guess
the
getter
should
return
keys
so
and
the
propagator
should
return.
B
E
C
C
E
Yes,
we
have
is
recording,
becomes
false
after
and
I
think
we
have
an
issue
open
for
that,
maybe
not
sure,
certainly
easy
to
do
set
status
with
status
code.
We
have
that.
B
E
E
B
B
Yeah
so
tldr
like
I
feel
like
we
probably
should
make
a
pass
through.
I
feel
like
there's,
maybe
like
three
or
four
issues
that
we
identified
here,
that
we
need
tickets
for
it's
kind
of
been
yeah.
It's
been
on
my
radar
to
actually
come
through
and
make
those
issues
finding.
The
time
has
always
been
the
core
problem.
E
B
Yeah
that
sounds
good.
If
I,
when
I
revisit
this,
if
there's
anything
that
hasn't
gotten
an
issue
I'll
I'll
make
sure
to
get
one
so
that
we
can
kind
of
track
that
and
get
things
towards
start
preparing
for
an
rc.
But
I
think
we're
we're
little
ways
out.
I
guess
at
the
maintainers
meeting
before
last
they
were
asking
sigs
for
how
long
they
thought
it
would
take
before
they
would
be
rc
ready.
B
And
luckily
I
was
gone
so
I
didn't
give
an
estimate
for
ruby.
So
so
nobody
knows,
but
everybody
else
is
saying
like
two
to
three
weeks:
it's
like
a
week
later
and
everybody
was
like
yeah,
it's
like
two
to
three
weeks,
so
I
feel,
like
it's
probably
gonna,
be
two
to
three
weeks
for
most
cigs
for
the
next
month
or
two
as
their
estimate.
E
B
Yeah
so
yeah,
I
don't
know
I
feel
like.
B
I
saw
one
thing
that
made
me
flinch
in
an
issue
somewhere,
but
I
don't
know
that
it's
actually
been
been,
but
had
it,
but
it
was
called
open
census,
compatibility.
E
But
that's
a
giant
tbd
in
the
matrix.
D
B
Well,
yeah:
let's,
let's
move
on,
let
me
just
really
double
check.
Yeah,
let's
go
ahead.
D
Yeah,
that's
okay!
There's
one
point
that
I
just
really
worked.
I
guess
two
that
I'd
like
to
go
a
few.
We
few
of
us
here
present
the
first
one
was
just
repurposing
it
to
use
the
existing
rack
instrumentation
instead
of
re-implementing
it
just
for
rails,
which
I
think
is
the
right
choice.
D
The
question
becomes
around
how?
How
does
that
dependency?
Look?
How
how
do
we,
how
the
two
interact
is
the
rap
instrumentation,
a
dependency
of
the
rails
jam
itself,
or
does
it
have
this
explicit
dependency
where,
if
you
want
the
middleware
to
be,
if
you
want
that
tracing
to
be
like
done
by
the
middleware
rack,
you
have
to
add
it.
So
you
the
two
interact
kind
of
like
we
were
talking
about
with,
like
the
http
context,
propagation,
where
you
pass
some
information
along
and
it's
up
to
the
http
library
to
make
use
of
it.
D
If
we
implement
it.
So
in
the
rack
middleware,
you
would
set
some
information
like
on
a
thread
local
sink.
This
is
the
rackspan
and
then,
let's
say
in
rails
metal.
We
have
a
patch
looks
for
that
rackspan
and
we'll
append
some
information
to
the
attributes.
For
the
for
the
long
and
the
request
so
like
that,
it's
like
how's,
the
interaction
but
like
I
guess
we're
saying
is
like
is:
should
rack
be
a
dependency
of
the
rails
gem
or
should
you
require
someone
that
wants
this
functionality
to
say?
B
Yeah,
I
think
my
two
cents
is
that
rails
should
probably
depend
on
the
rack,
instrumentation
and
like
right
now
the
rack
instrumentation
like
if
you,
if
you
just
wanted
to
instrument
a
rack
app,
you
could
you're
kind
of
responsible
for
wiring
up
the
the
the
rack
instrumentation
you're
responsible
for
inserting
that
in
your
middleware
chain
somewhere.
B
D
I
think
I'm
leaning
towards
that
as
well
like
it.
It
requires
some
changes
to
rack,
like
not
doing
that.
I
think,
is
like
easier
because
you're
pushing
the
responsibility
on
whoever's
using
this
to
like
set
it
up
properly,
but
for
in
terms
of
like,
if
you
want
to
make
adoption
easier,
I
think,
having
rack
be
a
dependency
of
the
rails.
Instrumentation
is
the
right
way
to
go
so
like
I
am
leaning
towards
that.
But
then
questions
like
when
we
create
a
span.
We
set
the
instrumentation
library,
so
you
set
up
the
rails
instrumentation.
D
It
brings
in
rack
for
you
that
span
gets
generated
by
the
rack
middleware,
but
through
the
rails
instrumentation.
That
setup
is
like
what
what
does
that
span
have
its
attributes
set
to?
Is
it
rack
or
rails
that
instrumented
it
like
little
things
like
that
and
the
rack?
The
rack
middleware
requires
an
instance
of
the
tracer
right
now
it
looks
for
rack
instrumentation.instance
tracer
right,
so
that
doesn't
that
would
not
exist.
D
E
B
It's
like
you
could
modify
rack
to
be
able
to
kind
of
specify
the
named
tracer.
You
know
and
you
could
pass
in
like
rails
as
you
as
your
name
tracer,
and
that
would
work
fine
for
your
for
the
rails,
part
of
your
application,
but
you
can
mount
any
kind
of
rack
app
in
your
rails
app
or
you
know,
through
the
use
of
of
routing
just
available
to
you
from
rack.
B
You
know,
aside
from
rails
like
you
can
have
multiple
can
have
multiple
rack
apps
in
process,
some
of
which
may
be
rail.
Some
of
them
might
be
just
plain
rack
apps.
Some
of
them
could
be
sinatra
apps
and
they
don't
necessarily
have
to
like
nest.
I
guess
what
I'm
saying
so.
You
will
end
up
in
a
situation
where
you
do
not
have
like
a
single
instrumentation
library
that
you
would
want
to
tie
a
tracer
to
for
the
rack
instrumentation.
B
B
Like
part
of
our
problem
is
wanting
to
use
the
rax
fan
and
continually
decorate
it
from
stuff
further
downstream.
B
E
B
I
think
that's
normal
and
I
definitely
see
it
as
as
an
approach.
I
think
an
alternative
approach
that
could
be
considered
is
making
a
span
for
for
your
framework,
if
you
wanted
to,
if
you
wanted
to
have
it
attributed
to
the
right,
instrumentation
library
and
consider
decorating
that
one
I
feel
like
the
the
downside
to
that
is
like,
for
example,
I
think
for
the
the
racks
fan
the
racks
fan
becomes
unwieldy
and
hard
to
name.
B
To
be
honest,
I
think
that's
one
of
the
biggest
problems
with
it
is
that
you
have
a
request
path
that
if
you
just
use
outright,
it's
probably
gonna
be
pretty
high
cardinality
and
if
you
want
to
make
it
something
a
little
bit
more
reasonable
you're
going
to
have
to
do
a
lot
of
processing
and
gymnastics
there,
and
it
would
be
nice
if
you
could
just
update
the
name
from
rails
once
you
kind
of
get
to
like
a
controller
in
action,
a
pretty
stable
name.
B
A
Yeah,
that's
what
datadog
does,
but
they
do
both.
They
update
the
name
and
something
called
a
resource
which
is
totally
different.
It's
like
the
I
never
mind.
They
update
a
couple
things
in
rack
to
be
more
rails,
friendly
or
just
more
user-friendly,
and
then
we
also
create
a
rail
span
representing
the
controller
action,
but
a
lot
of
that
is
due
to
the
constraints
of
our
ui
in
our
system,
where
the
top
level
span
has
lots
of
extra
significance
in
first-class
citizenship
within
the
ui
that
probably
aren't
standards,
we
need
to.
E
The
client
and
service
bands
really
are
special
and
they're
used
for
building
things
like
service
graphs,
build.
You
know
automatically
deriving
slis
from
from
spans
and
being
able
to
decorate
them
with
a
bunch.
More
information
is
actually
super
useful,
even
from
an
analytics
perspective
like
if
you
don't
actually
care
about
the
the
duration
of
your
controller
versus
middleware
from
an
analytics
perspective,
it's
much
easier
to
look
at
a
single
span
than
to
try
to
combine
multiple
spans
here.
I'm
talking
about
things
like
you
know,
we
use
bigquery
heavily.
E
A
Yeah,
we
don't
have
that
a
bit,
it's
something
I
complain
constantly
about,
so
I
yeah
I
just
was
gonna
say
I
worry
about
the
naming
thing
that
matt
brought
up,
which
is
like,
if
there's
a
rock
span
and
then
okay
see
angela,
no
worries
thanks
for
coming
and
then
yeah
how
the
naming
of
the
span
up
name
would
work
versus
like
if
it's
rack
with
sinatra,
although
I
guess
we
would
just,
would
we
then
have
to
go
to
our
sinatra
instrumentation
and
also
make
sure
we're
updating
rack
scans
in
there
or
do
we
already
do
that.
E
Yeah,
we
don't
do
that
at
the
moment
and
I
think
we
should.
I
think
the
sinatra
should
like
sinatra:
instrumentation
should
play
nice
with
the
rack
instrumentation.
A
B
Like
maybe
a
possible
hybrid
approach
just
to
have
an
option,
it
might
be
terrible
caveat
with
all
my
ideas,
but
you
could
consider
having
both
with
the
rackspan
in
your
framework
span,
but
the
rax
fan
still
could
be
a
little
bit
special
and
it
is
something
that
you
could
pass
down
either
through
the
end
or
in
the
context
somehow,
and
it
is
something
that
you
could
give
a
better
name
to
further
on.
You
know
your
rails.
B
Instrumentation
might
call
something
like
controller
action,
but
if
you
had
access
to
like
a
route
or
something
that
made
more
sense
to
update
the
rax
fan,
2
you
could,
and
that
would
probably
be
okay,
and
then
you
could
put
the
really
railsy
controller
stuff
on
the
rails,
fan
and
choose
to
decorate
the
rackspan
with
some
things.
If
it
made
sense,
I
don't
know
if
this
just
is
a
terrible
idea
that
you
know
entangles
too
many
concerns.
It
sounds
like
that
might
be
the
case
a
little
bit
as
I
talk
it
through.
D
Another
point:
I
know
we
got
like
no,
no
time
left,
but
I
just
wanted
to
get
the
temperature
on
this
one.
So
we'll
have
to
comment
on
the
pr
suggesting
that
the
rails
instrumentation
would
be
broken
apart
to
each
kind
of
respective
gem.
That
rails
is
made
up
of
so
you,
instead
of
having
like
your
rails,
instrumentation
you'd
have
like
action
pack,
you
might
have
whatever
other
ones
that
are
there
and
it
would
be
gem
like
rails
gem,
specific
instrumentation.
D
I
don't
like
that
just
because
it
seems
like
package
out
kind
of
thing
and
how
those
all
play
together.
I
was
thinking
more
that
we
just
keep
it
a
single
rails,
instrumentation
gym,
but
I'm
open
to
having
people
say
I'm
wrong,
or
maybe
we
should
break
it
apart.
E
Once
we
have
more
there,
we
can
break
it
apart.
At
that
point,.
D
A
A
I
think
his
comment
was
more
just
to
say
that
some
of
the
other
ones
when
we
do
approach
them,
don't
worry
about
it
but
like
when
we
do
might
we
might
need
to
rely
on
our
alternative
patching
method
instead
of
patching
the
you
know,
it's
like
you
need
active
support,
notifications
for
the
view
or
whatever,
but
whatever
it's
tomorrow's
problem.
D
So
then,
I
think
it
sounds
like
overall,
just
like
we'll
keep
it
as
one
and
we
can
carve
it
off
if
needed
later,
like
that's
a
further
down
the
road
concern
and
then
making
rack
a
dependency
of
the
rails,
instrumentation
gem
seems
to
be
the
way
to
go.
I
think
everybody's
kind
of
landing
on
that
one,
even
if
it
comes
with
a
little
bit
more.
D
A
B
D
E
Okay,
wherever
time
I
did
want
to
flag
a
few
things
quickly.
One
is
there's
a
few
slightly
contentious
prs
in
flight
right
now.
It
would
be
good
to
get
some
opinions
on
those
there's,
a
general
thing
around
should
should
we
try
to
stick
as
closely
as
possible
to
semantic
conventions,
or
should
we
be
trying
to
align
with
what
other
languages
are
doing?
E
My
preference
is
that,
whenever
possible,
we
should
be
sticking
to
sticking
closely
to
semantic
conventions,
simply
because
like
where,
in
the
long
term
that
drives
us
towards
consistency,
whereas
the
other
way
everybody's
going
to
gradually
diverge
but
again
like.
If,
if
there's
alternative
opinions
there,
it
would
be
useful
to
add
those,
and
the
third
thing
is
around
error
handling.
We
have
had
several
cracks
of
this,
so
this
is
the
top
pr
here
there
was
a
request
for
better
handling
in
the
configurator.
E
A
I
can
quickly
comment
on
the
this
file
in
the
spec
thing,
with
regards
to
whatever
it
was
mongodb
yeah.
Definitely
in
favor
of
following
spec,
I
just
wasn't
paying
I
just
like
kind
of
was
rushing.
I
think
the
guy
updated
the
pr
and
then
yeah
I
gave
I
tried
to
I
kind
of
got
yelled
at
so
yeah.
Definitely
if
other
people
can
chime
in
on
the
batch
span
thing
with
four
working
scared
of
the
computer
and.
A
Datadog
recently
had
some
error
handling
stuff,
where
what
we've
ended
up
doing
is
passing
in
defau.
There's
an
argument
you
can
pass
into,
like
whatever
I
forget
what
it's
called
here
like
tracer.trace,
like
your
core,
like
trace
thing
that
you
wrap
like
a
block
of
code
in
you,
can
pass
a
default
like
as
an
option.
A
You
can
pass
an
error
handler
like
a
proc
that
has
like
a
reasonable
default,
but
we
noticed
with
key
like
people
with
certain,
so
basically
on
a
per
configuration
basis,
you
can
pass
in
custom
error
handlers
per
integration
basis
that
people
have
found
value
from
so
yeah.
I'm
in
favor
of
I
can
look
at
this.
I
think
it's
any
reasonable
step
in
that
direction
helps
a
lot
rather
than
some
sort
of
like
crazy
spam
processor
or
something.
E
Yeah,
all
we
have
is
logger
right
now
like
and
that
doesn't
really
have
any
knowledge
about
the
existence
of
an
exception.
So
there's
not
really
much
you
can
do
with
the
logger
other
than
just
you
know,
control
the
level
of
logging,
I
suppose,
but
yeah
I
mean
we
took,
I
think
the
linked
issue,
or
actually
it's
not
linked
here,
there's
another
issue
where
we
have
attempted
to
deal
with
this
multiple
times:
okay,.
E
You
know
strict
mode
was
an
early
proposal.
B
B
And
then
any
component
can
just
call
this
global
error
handler
instead
of
a
logger,
and
you
can
by
default
it
logs,
but
you
could
do
something
more
special.
If
you
wanted
to
is
this.
This
is
what
I'm,
what
we're
looking
at.
E
Yeah,
okay,
so
I
think
the
the
one
thing
we
would
want
to
do
to
make
that
more
usable
is
actually
have
some
kind
of
exception
hierarchy
in
the
api
or
the
sdk
or
something
just
so
that
we
can.
You
know
people
can
choose
whether
they
want
to
raise
configuration
errors
or
whatever
right.
It's
like
you
might
want
to
plug
in
an
error
handler
that
raises
that
is
strict
about
configuration,
failures
in
production,
but
does
not
raise
errors
for
any.
You
know
misuse
of
the
api.
B
Yeah,
I
think
we
need
to
talk
about
this
a
little
bit
more,
but
the
one
that
I
was
talking
about.
It's
mainly
it's
a
replacement,
it's
a
kind
of
replacement
for
logger.error,
and
it's
really
meant
to
be
used
by
sdk
components.
So
it's
like.
Typically,
you
won't
find
this
thing
in
your
exporter
like
when
an
export
failed,
it's
really
not
meant
to
be
used.
I
think,
by
like
the
you
know,
like
the
tracer,
for
example,
at
least
I
have
not
seen
any
of
these
being
used
in
that
way.
E
Cool
I
mean
we
can
discuss
this
in
the
issue,
but,
like
the
the
error
handling
seems
to
talk
about
invalid
uses
of
the
api
as
well
as
malformed
configs,
which
kind
of-
and
you
know,
talks
about
strict
error
handling
right.
So
it's
similar
to
the
strict
mode
that
we
were
discussing
a
long
long
time
ago.
B
Yeah
reading
this
through
it,
it
does
say
that
I'm
just
yeah,
I
was
just
recalling
the
uses.
I
know
of
this
like
js,
has
this,
for
example,
and
it's
pretty
much
exclusively
in
the
domain
of
exporters
but
we're
using
typescript
over
there.
So
I
think
we
rely
on
that
a
lot
to
make
sure
that
the
apis
are
used
properly
but
yeah.
B
B
So
I
think
we're
at
that
stage
where
we
need
to
make
a
decision
about
how
this
stuff
works
and
make
sure
that
things
are
tenable
and
reasonable
for
users
to
too
you
know
you
want
that
right,
balance
of
definitely
not
crashing
an
app,
but
also
giving
users
feedback
that
something
didn't
work
as
expected.
So.
E
Yeah,
the
other
consideration
here
is
configuring,
the
error
handler
for
the
configuration
block
inside
the
configuration
block.
So
I
just
want
to
raise
that
as
a
minor
complexity.
B
Yeah,
I
see
the
complexity
there
all
right
we've
gone
over.
We
should
probably
call
it
yeah
next
time
if
we
have
a
little
bit
more
of
an
agenda,
make
sure
to
time
box,
maybe
the
spec
stuff,
so
that
we
just
have
time
to
make
it
through
everything.
So
yeah
we'll
we'll
kind
of
check
in
at
the
end
of
the
meeting
and
see
the
bus
the
best
way
to
kind
of
maybe
try
to
set
up
some
time
boxes.