►
From YouTube: 2022-08-09 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
C
All
right,
a
series
of
crises
this
this
year,
it's
it's
like
worse
than
22.,.
C
C
And
yeah.
A
C
In
our
we've
arranged
to
we're
trying
to
build
it
into
our
time
to
have
like
a
week
of
dedicated
outreach,
yeah
yeah
because
not
just
like
this
is
a
problem
that
our
customers
are
having,
but
with
hotel
but
like
no.
Let's
go
be
maintainers
right.
C
A
Cool
well
yeah.
I
think
it's
a
good
policy.
I'm
glad
good
to
see
you
glad.
All's
good
things
are
okay,.
A
C
C
A
Yeah
but
yeah,
that's
good.
Okay
complain.
I
gotta
work
with
these
jerks
andrew
and
sam,
who
are
just
on
just
very
difficult.
E
A
They're
just
a
pain,
they
love
to
take
it
offline
and
sink
or
table
that
and
stuff.
It's
just.
A
Right
yeah,
I
was
killing
time
folks
trickled
in.
C
C
Copy
our
little
agenda
template,
but
I
see
a
bookmark
added
there
is
bookmark.
Is
that
a
permanent?
This
is
the
current
one
or
latest
one.
I
don't
want
to
mess
up,
but.
D
So
I.
F
Like
we
maybe
have
a,
I
figured
out
our
our
hypertext
deep,
linking
woes
and
have
the
usual
group.
Shall
we
jump
into
a
specific
recap.
F
It
does
look
like
we
have
an
unfamiliar
face:
faceless
josephine,
welcome.
G
F
Yeah
welcome
this
is
the
the
ruby
sig
we
generally
kind
of
will
recap
just
a
little
bit
the
spec
sig.
It's
a
meeting
that
happens
before
this.
One
and
kind
of
I
don't
know
has
has
some
relevance
for
for
the
work
that
we
end
up
doing
and
then
we
kind
of
get
on
to
issues
for
our
repo
so
good
to
have
you
here.
There
is
an
agenda,
so
if
you
have
any
burning,
questions
feel
free
to
fill
them
in
there
yeah,
I
think,
ariel,
has
linked
the
dog.
F
All
right,
so
there
is
some
work
being
done
by
the
messaging
sig
on
tracing
individual
messages.
This
looks
quite
interesting
and
like
it
is
definitely
worth
worth
a
read.
I
think
it's
just
an
issue
that
this
is
just
an
issue.
F
It's
just
an
issue
I
think
asking
for
some
feedback
about
how
to
basically
they
are
looking
for
the
way
to
proper
way,
to
trace
multiple
messages
sent
within
a
single
badge.
F
Yes,
I
think
it
is
probably
relevant
and
I
haven't
yeah.
I
think
I
only
skimmed
over
this,
so
I'm
not
totally
sure
exactly
what's
on
the
table,
but
I
think
we
should
probably
all
I'll,
have
a
look
and
participate
in
this
discussion,
especially
if
we
have
opinions
or
if
it
will
help
us
help
us
and
our
message.
F
A
I
wonder
how
it'll
interact
with
disabling
of
like
per
instrumentationy
things
like
so
it
takes
precedence.
F
F
Definitely
think
yeah,
if,
if
anybody
is
thinking
this
through
and
thinking
through,
like
what
the
implementation
actually
looks
like
in
ruby,
if
it
is
looking
questionable,
definitely
feel
free
to
chime
in
that
this
is
a
bad
idea.
I
don't.
I
haven't
been
following
the
discussion,
so
I
don't
know
what
concerns
or
not
concerns
people
may
have
about.
E
This,
I
don't
I
I
might
go
chime
in
on
the
pr,
if
I
can
remember
after
I
finish,
but
the
language
I
just
saw
on
the
screen
was:
there's
a
no
op,
sdk
sort
of
exporter
and
things-
and
I
imagine
like
it
would
just
be
better
to
use
the
api's
sort
of
no
behavior
rather
than
requiring
sdks
to
have
an
additional.
No
thing,
I'm
wondering
so
I'm
going
to
go
comment
that
on
that
part
and
see
what
they
think
about.
That
might
just
be
a
clarification
thing.
F
Just
thinking
this
through,
I
know
part
of
the
reason
for
separation
of
api
and
sdk
is
that
you
can
just
back
the
api
with
a
no
op.
Would
they
know
of
everything?
F
Having
said
that,
I
don't
think
that
I've
actually
kind
of
set
this
up.
So
I
don't
know
how
easy
that
is
or
how
it
is
even
different
from
hotel
sdk
enabled,
but
it
seems
like
the
subtlety
might
be
this
one.
You
actually
have
the
you
actually
have
an
sdk
around
and
you
do
have
it
generally
enabled,
but
for
some
reason
you
want
this
like
quick
switch,
whereas
the.
E
H
I
think
that's
a
decision
that
the
sdk
implementers
can
do.
Yeah
like
it's
just
it
just
so
happens
that
the
way
that
we
do
it
is
using
the
registry
and
the
registry
is
bootstrapped
by
the
configurator.
B
E
Right
yeah,
that's
kind
of
what
I
was
thinking
of
was
that
you
know
in
our
implementation.
We
would
just
check
if
this
is
there
yeah
we
just
don't
set
anything
up
which
is
essentially
jen
just
using
the
api's
tracer,
which
is
a
noaa.
F
Yeah
no
problem,
I
think
good
discussions.
We
end
up
getting
like
these
environment
variables
that
end
up
somehow
competing
and
it
it
can
get
ugly
in
practice
and
depending
on
what
environment
variable
soup
people
have
like.
I
think
unintended
things
often
end
up
happening
so.
F
We
will
work
through
that
and
moving
on.
There
is
a
suggestion,
for,
I
think,
a
a
metric
that
counts
the
number
of
threads
per
thing,
but
I
think
there
has
been
some
bike
shedding
about
where
this
actually
belongs
and
whether
or
not
it
is
process
or
process.
Runtime.
F
C
E
B
H
H
Anytime,
these
come
up
right,
like
the
garbage
collection,
metrics
and
was
another
example
of
this,
where
it's
like
people
just
want
to
have
like
generic
name
spacing
for
these
attributes,
instead
of
just
like
yeah,
it's
all
right,
whatever
the
nsclr
hasn't
changed
in
25
years,
just
call
them.net,
whatever
vendors
will
have
to
build
something
specific
to
rep,
to
visualize
the
clr's
heap
but
differently
from
the
jvm,
because
of
the
seven
different
versions
that
it
manages
memory
with
it's
like
come
on
now.
E
I
was
actually
gonna
just
say.
I
think
that
this
is
actually
a
really
good
use
case
for
the
the
language
specific
semantic
convention
carve
out,
like
that's
actually
where
ruby's
five
scout
should
go
right.
You
know
it
is
language
dependent.
There
is
no
unified
run
time.
I
wish,
but
there's
not
so.
F
F
F
Of
of
the
bounds,
and
it
just
yeah,
it
seems
to
be-
I
guess
it
was
said
that
this
is
a
political
issue,
and
it's
political
in
that.
I
think
the
reason
why
it
keeps
coming
up
is
there's
some
compatibility
issues
with
prometheus
and
I
think
hotel
is
trying
to
be
as
accommodating
as
possible,
but
I
think
there's
some
back
and
forth
happening
to.
B
F
Right,
let's
do
I
have
two
minutes.
Is
this
the
two
minute
warning.
F
Yeah,
let's,
let's
at
least
talk
about
the
user
agent
and
then
we'll
gloss
over
everything
else.
The
user
agent
is
a
proposal
that
exporters
sent
the
user
agent
by
the
famed
code
button
that
we're
always
talking
about.
In
this
thing,.
F
The
collector
already
does
this
and
I
think
you
do
get
a
user
agent
out
of
golang.
I
don't
know
if
it's
actually
something.
C
C
We
added
the
user
to
the
collector,
because
the
ghost
stuff
would
just
say
hey:
this
is
the
version
of
the
goji
or
piece
of
the
library.
That's
talking
to
you
like
I
and
as
a
receiver
of
hotel
on
behalf
of
other
people.
I
don't
want
to
go
digging
around
user
data
to
figure
out
like
what
version
of
hotel
they're
using.
So
I'm
a
huge
fan
of
more
identifiers
in
the
user
agent,
because
that's
helps
receivers
of
telemetry
support.
F
Yeah,
so
I
think
I
think
these
sorts
of
issues
keeps
code
button
up
at
night
and
was
one
of
the
reasons
for
this
pr
was
to
try
to
have
better
kind
of
information
as
a
receiver
of
telemetry,
for
others
like
where,
where
all
this
stuff
is
coming
from,
to
help
them
and
to
help
codeword
and
help
them.
F
Yeah
I
had
one
just
question
about
this
and,
like
javascript
has
like
all
all
the
exporters,
so
they
have
a
proto
http,
they
have
grpc
and
they
have
a
json
or
http.
So
I
thought
maybe
it'd
be
useful
to
have
that
in
the
user
agent,
but
code
bowton
has
said
that
there
should
be
enough
other
headers
around
to
make
sense
of
all
that,
and
I
I
don't
disagree.
F
Read
it
review
it
give
it
many
stars,
and
that
is
the
end
of
the
specific
recap.
F
Alright,
so
let's
hop
over
to
the
agenda
and
see
if
anything
interesting
has
popped
in
no
burning
questions.
Nice
summary
of
the
specific
repair.
F
H
Since
this
is
josephine's
first
meeting
just
wanted
to
give
a
round
of
say,
hello,
I'm
mariana
from
github
and
directly
beneath
me
is
sam.
D
C
A
This
is
reuben
my
son
and
eric
is
me.
I
work
at
shopify
with
all
the
rest
of
the
folks
on
this
call
nice
to
meet
you
and
I'm
gonna
make
him
a
bottle
in
a
second,
I
don't
know
who's
next,
whoever
wants
to
go
next.
Popcorn
robert.
D
Hey
I'm
robert
also
at
shopify.
E
One
of
the
maintainers
on
the
repo-
I
usually
sit
pretty
quietly
on
these
calls,
but
I
try
to
help
as
best
as
I
can,
when
I'm
summoned
and
then
I'll,
I
guess
I'll
shoot
it
to
andrew
hi.
I'm
currently
walking
my
dog,
so
I'm
not
on
video,
but
I
currently
work
at
shopify
with
robert
and
the
gang
previously
worked
at
github
with
ariel
and
I've
been
doing
stuff
for
a
little
bit.
Now
I
don't
know
who's
next
because
I
can't
see
the
screen,
but
I
haven't
heard
matt
go
so
matt.
B
G
Hi
thanks,
thank
you
for
the
introductions
and
it's
my
first
time
here.
Obviously,
I
work
in
a
analytics,
startup
called
mode
and
we
use
honeycomb
and
we
also
use
a
ruby,
so
I'm
in
in
a
few
hotel,
guitar
meetings
just
to
get
myself
up
to
speed
with
all
the
scenes
here.
B
G
H
It's
quite
all
right,
don't
worry
about
it.
It'll
be
a
great
surprise
to
us
next
time.
C
H
Do
you
have
any
so
you
know
we
went
through
the
agenda?
Do
you
have
anything
any
issues
or
pull
requests
that
you're
interested
in
us
reviewing
or
talking
about.
G
G
H
All
right
so
this
so
then
we
look
at
this.
Did
we
look
at
this
vr?
Already?
Oh,
no
just
that
rob!
You
said
you
were
gonna
review
it
today.
I'm.
E
E
F
Yeah
so
question
about
this,
since,
since
it's
up,
this
will
be.
F
Yeah,
what
what
are
the
repercussions
of
this
I
feel
like
there
was
a
couple
of
ways
that
you
could
start
sending
instrumentation
scope.
One
was
a
complete
replacement.
Basically
does
the
back
end
need
to
have.
F
E
Protocols
that
matter
right
now,
instrumentation
library
and
instrument,
instrumentation
scopes
at
this
point
I
believe,
are
wired
compatible.
E
C
So
some
backstory
on
this-
if
I
can
page
it
all
out
of
memory
from
months
ago,
instrumentation
library
got
renamed
instrumentation
scope,
instrumentation
library,
for
a
period
of
time
in
the
protocol
in
the
wire
format,
got
moved
to
a
different
field.
So
it
was.
C
C
For
reasons
largely
related
to
aws's
choices,
about
what
proto
version
they
put
in
their
distribution
of
the
collector
is
using
a
version
of
the
protocol
that
doesn't
know
about
field
1000
sort
of
yeah
it
get.
It
got
complicated.
C
It
is
simplified
when
a
an
sdk
when
you
move
to
a
new
version
of
the
protocol
in
that
same
chain,
or
at
least
in
the
same
release
before
you
do
a
release.
Having
moved
to
the
new
version
of
the
protocol,
where
the
where
the
names
changed
the
fields
changed.
If
you,
if
you
start
using
instrumentation
scope
where
you're
using
instrumentation
library,
you
will
be
putting
the
data
on
the
wire
at
the
same
field,
identifier
as
before,
which
helps
receivers,
who
are
stuck
receiving
old
versions
of
the
proto,
not
throw
data
away.
E
Right
and
from
their
perspective,
then
they'll
just
see
it
as
instrumentation
library,
until
scope
attributes
actually
start
happening
in
a
future
version
of
the
proto,
like
nothing
should
actually
change,
which
is
why
we
put
these
two
together.
I
think
so.
My
understanding
then,
is
like
this
is
kind
of
what
you
were
asking
for
was
to
do
them
simultaneously.
Right,
yeah,
okay,
cool.
C
F
B
C
It's
it's
basically
after
this
merges
instrumentation
library
spans.
I'm
sorry.
C
Spans
will
continue
to
show
up
in
the
same
place
in
the
wire
format
field,
three
or
whatever
it
was
instead
of
field,
one
thousand,
and
so,
if
our
receivers
are
still
on
an
old
proto.
Looking
for
a
thing
named,
instrumentation
library,
instead
of
instrumentation
scope,
it's
still
looking
at
field
three,
it
just
happens
to
be
our
in
our
code,
we're
referring
to
it
by
a
different
name,
but
it's
still
the
same
data
and
same
structure.
E
B
C
E
Oh,
I
was
just
gonna
say:
yeah,
the
the
actual
switch
between
scope
and
library
in
the
protobuf
was
it
was
was
rough
upstream
like
that
was
moving
it
and
yeah.
I
I
don't
know
that
that
was
handled
as
well
as
it
could
have
been,
but
you
know
the
project
learns
and
we
don't
do
the
same
thing
next
time
right,
yeah,.
C
There
are
like
layers
of
compatibility
and,
while
the
right,
the
re,
the
rename
was
fine,
because
any
code
using
this
could
happily
not
change
I'll,
happily
put
data
on
an
instrumentation
library,
and
I
don't
have
to
change
my
code
and
it
will
go
on
the
wire,
but
so
it
was
compatible
in
the
sense
that,
if
you're
using
this
library
in
your
code,
you
didn't
have
to
change
anything.
You
didn't
have
to
rename
everything
to
use
instrumentation
scope.
C
You
could
continue
calling
an
instrumentation
library
and
it
would
show
up
on
the
wire
but
downstream
somebody
receiving
this
if
they
didn't
also
move
to
the
new
protocol.
The
new
protobuf
version.
They
wouldn't
know
about
this
field,
1000
that
the
data
was
showing
up
on.
So
it's
like
it
was
backwards
compatible
at
the
at
the
library
level,
but
it
wasn't
backwards
compatible
at
the
sending
to
multiple
systems,
who
aren't
all
in
sync
on
a
version
of
a
protocol
level.
C
B
C
I
might
be
wrong
on
that
version,
but
at
a
point
where
instrumentation
library
got
moved
and
renamed
to
instrumentation
scope,
anybody
using
that
version
or
later
if
they
update
their
code,
to
call
it
instrumentation
scope
so
that
their
code
references,
the
protobuf
translation
to
the
field,
three
everything's
fine,
which
is,
which
is
why,
like
this
pr
coming
in
with
the
proto
update
and
the
code
change
to
use
the
new
name,
travel
together
and
it's
okay.
F
C
Yeah,
it's
a
library
that
doesn't
change
its
name
from
instrumentation
libra.
The
code
using
the
reference
by
name.
Instrumentation
library,
is
not
going
to
double.
Send
it's
going
it's
going
to.
If
you
use,
if
you
don't
change
the
name,
instrumentation
library,
instrumentation,
scope,
you're,
going
to
publish
it
on
field
1000,
which
not
all
receivers
are
going
to
be
able
to
wouldn't
even
know
about
right,
yeah.
B
Got
it
cool
yeah.
E
C
The
hope
is
that
protocol
goes
1.0
and
obviates
well,
not
addresses,
say,
aws
is
concerned
about
moving
the
protocol
version
of
their
distribution
of
the
collector
and,
like
everybody,
can
move
to
one
and
we
can
start
eclipsing
old
versions
of
the
protocol.
But
if
we
keep
tinkering
with
the
protocol,
we'll
never
get
it
stable.
F
C
C
C
Yes,
we're
trying
to
come
up
with
a
workaround
for
in
a
world
where
we're
breaking
the
protobuf.
Let's
come
up
with
a
way
to
handle
the
breakage
and
it
seems
like
the
preference,
is
well
we'll
not
break
it
again.
E
F
I
know
there's
some
issues
for
bringing
otlp
officially
to
1.0
they're
being
talked
about.
You
know
in
the
past.
F
Well
in
previous
weeks,
but
I
feel,
like
everybody
went
on
summer,
vacation
and
they've
kind
of
been.
I
don't
know,
progress
might
have
stalled
a
little
bit,
but
I
would
like
to
check
back
into
those
and
all
of
us
who
are
interested
in
1.0,
can
maybe
team
up
and
see
if
we
can
somehow
help
pull
this
stuff
over
the
finish
line.
C
I
think
I
I
think
that
is
a
good
idea
to
get
folks
who
know
the
gnarly
details
and
and
care
can
get
together
and
like
try
to
articulate
the
the
remaining
issues
we
see
and
say
and
make
like
a
punch
list
like
here's
a
little
bit.
Here's
what
we
see
it
would
take
to
get
to
1.0
and
try
to
help
push
it
over
the
line.
F
We
can
move
on
now,
as
I
see
ariel
has
added
a
few
more
things
to
the
list.
Http,
client
and
client
hooks
there,
a
problem.
H
Last
time
I
attended
a
meeting,
I
don't
know
if
it
was.
Last
week
we
talked
about
reverting
those.
Did
anybody
send
the
message
out
that
we're
going
to
be
reverting
those.
A
A
But
we
never
have
had
a
release
technically
with
those,
so
I
think
we're
kind
of
flex
there's
some
that
was
pointed
out
last
time
by
someone.
So
I
think
we
have
some
flexibility
yeah.
I
can
ping
the
person
on
the
issue,
but
I
don't
actually
have
a
pr
queued
up
to
revert
or
anything
I
I
can.
You
can
assign
me
that,
though
that's
a
good,
that's
a
good
thing.
I
could
pick
up,
though,
if
no
one
else
has
a
keynote.
F
Were
these
the
hooks,
I
remember
there
was
somebody
advocating
for
hooks
that
also
existed
in
python.
Did
they
are
these?
The
hooks?
Did
they
make
it
in,
and
is
this
what
we're
talking
about
reverting
or
am
I
like
combining
multiple
hooks
in
my
mind,.
D
One
of
them
was
on
the
rack
instrumentation,
which
was
just
like
a
generic
like
do
stuff
around
a
rack
request,
and
then
there
was
also
hooks
on
various
http
clients,
and
they
were.
I
think
they
were
the
same
people,
but
now
that
I
think
about
it.
It
might
have
been
someone
anyway,
but
yeah.
I
think
that
the
general
just
was
like
they're
doing
it
in
other
libraries.
We
can
do
it
in
ours,
but
we
merged
it
in
before
talking
to
the
sig
and
then
the
sig
was
like.
F
D
F
A
Yeah
I
mean
it
was
never
clear.
I
think
that
was
one
of
the
issues.
It
was
never
clear
what
the
use
case
was
like
the
specific
use
case,
and
so
it's
hard
it
yeah
so
because
I
believe
one
of
the
alternatives
we
suggested
was
like.
Well,
if
you
say
the
thing
you
want
to
do,
we
can
just
like
give
you
a
config
option
to
do
that
thing,
but
it
was
a
little
open-ended
and
there
were
some
concerns.
D
A
C
B
H
H
H
A
A
little
bit
heavyweight,
but
it
works,
you
know
and
and
let's
yeah
and
that's
the
way
it
goes.
Sometimes
it
goes.
The
other.
H
B
H
So
hoping
to
get
other
folks
to
chime
in
known
in
this
conversation,
but
you
know
one
of
my
teammates
there
or
I
don't
know
he's
on
on
my
teammates-
I
I
guess
we
get
we're
the
same
employer
henry
was
like
looking
to
contribute
the
torp
instrumentation.
H
Now
twerp
works
is
essentially
it
wraps.
Faraday
right
uses
faraday
for
http
request.
However,
we
have
these
tiered
things
right.
So
if
you've
got
faraday,
you
got
twerp
and
then
you
have
faraday
and
then
on
the
faraday.
You
have
the
the
client
adapter
right
and
that
client
adapter
is
gonna.
Have
a
also
has
an
instrumentation.
H
It
turns
out
that
you
know,
faraday
produces
a
client
spam
and
the
child
adapter
produces
a
client
span
and
twerp
itself
also
will
produce
a
client's
ban,
but
the
spec
is
saying
right:
you
have
one-to-ones
on
the
client
spans
every
other
span,
I
guess,
should
be
represented
as
internal
that's
above
it
and
the
way
that
we've
implemented
this
with
other
libraries
like
koala
is
that
we
do
the
shared
http
attribute
context,
but
what's
missing
from
there
is
kind
of
like
this
notion
of
where
did
these
attributes
come
from?
H
Which
is
like
the
instrumentation
library
attribute,
for
example,
will
show
up
as
faraday,
but
those
attributes
actually
came
from
somewhere
else
right
from
the
koala
instrumentation.
So
you
really
don't
have
a
kind
of
clue
into
where
these
things
appeared
for
twerp.
Also
torque
has
like
this
idiosyncratic
thing
where
it's
a
conceptually
an
rpc
call,
but
it's
hdd
protozoa
over
http.
H
So
the
underlying
transport
is
going
to
be
an
http
request,
but
it
is
conceptually
an
rpc
method
so
that
you
use
rpc
semantics
for
it.
When
trying
to
do
something
and
what
happens
when
you
like?
Should
they
be
a
mixed
mode,
because
there
are
in
fact
interesting
http
attributes
that
you
might
want
to
know
such
as
user
agent?
You
know
so
so.
My
friends,
I
have
presented
you
with
all
a
problem
that
I
have
no
useful
solution
for
at
the
moment,
and
I
was
wondering
how
people,
especially
the
vendors,
felt
about
this.
F
Just
one
question
based
on
that
whole
description
there,
yes,
sir,
it
sounds
like.
Would
it
be
wrong
to
phrase
it
this
way
that
twerp
ends
up
being
an
rpc
framework,
that
is,
that
uses
faraday
as
the
underlying
transport
or
is
it?
F
H
I
don't
know
conceptually,
you
would
think
that
the
whole
twerp
thing,
the
twerp
thing
is
your
client
and
the
fact
that
it
uses
http
under
the
hood
is
an
implementation
detail,
so
conceptually
it's
an
rpc
call,
but
it's
executing
it
over
http.
So
and
then
you
know,
you
also
have
like
the
the
russian
doll
problem,
where
faraday
is
also
wrapping.
C
H
B
C
B
C
H
B
F
F
Yeah,
so
I
don't
know
that
there's
an
answer
I
guess
to
this
question,
but
I
feel
like
it
has
come
up
before.
C
I
would
say
right
now,
if
you
wanted
to
detect
the
handoff
from
a
host,
some
sort
of
compute
thing
to
another
compute
thing:
that's
at
the
http
level,
so
whatever
http
client
faraday's
using
to
whatever
http
receiver,
the
server
is
using.
That
would
be
client
and
that
would
be
server
so
that
you
could
detect
the
host
handoff.
C
So
I
would
call
those
span
kinds,
client
and
server.
If
that's
that's
the
question
about
client
server,
the
span
kind
right.
B
B
H
H
C
Right,
yeah,
the
whole
you
can't
mutate
a
span
after
past
start
is
continues
to
be
a
frustration
for.
B
A
What
do
we
do
with
rack
and
rails.
H
It
rails
depends
on
the
rack,
instrumentation
and
it
amends
attributes
to
the
rack
instrumentation.
As
far
as
I
know,.
H
F
Yeah,
it's
a
little
easier
to
handle
this
thing
on
on
the
way
in
on
the
request.
It's
like
you
never
know,
what's
coming
after
you,
so
you
never
know
if
you
should,
if
you
are
a
potential
clients
fan,
if
you
should
be
internal
or
client,
it's
like
you,
don't
actually
know
until
the
request
leaves
the
system
that
that
is
the
thing
that
should
be
the
client
span
and
everything
else
should
have
been
internal.
C
The
other
option
is
not
settings
mankind
or
it
set
it
to
unknown,
and
we
and
and
then
it's
like
best
effort-
you
you
put
what
you
know
on
the
spans
and
whatever
is
receiving
all
of
this
telemetry.
Your
queries
of
that
data
depend
on
things
other
than
span
time.
A
H
H
B
H
It's
using
and
itself
so
we're
seeing
two
clients
fans
which
is
not
correct
per
the
spec.
H
So
now
you
add
another
library
like
twerp
that
leverages
faraday
and
now
you
end
up
with
three,
if
you're,
conceptually
thinking
of
twerp
as
being
a
client.
But
but
let's
say
we
treat
twerp
as
internal,
but
you
disable
faraday
tracing.
Then
you
lose
the
twerp
client.
B
H
B
C
Well,
there's
there's
the
there's,
detecting
that
a
class
that
a
constant
exists
right
like
a
class
is
a
constant.
So
we
could
check.
Is
the
faraday
instrumentation
constant
class
loaded,
except
that
you
can
load
it
and
disable
it
through
config,
so
you'd
have
to
also
ask:
are
you
enabled.
B
C
A
thing
that
we
do
in
in
using
spanking:
we
really,
I
hope,
that
I'm
right
about
this.
I
think
I'm
right
about
this.
We
really
detect
service
boundaries
by
spanking
server.
B
C
B
C
Well,
in
at
least
in
the
client
server
part
we
we
have
just,
we
have
chosen
to
depend
on
server
and
clients
kind
of
point
of
interest
that
you
know.
For
these
reasons,.
C
F
F
It
always
seems,
like
you,
have
a
situation
where
you
have
multiple
potential
clients,
and
nobody
knows
what
what
the
real
client
is.
C
Well,
well,
it's
what's.
A
client
in
the
server
depends
on
like
peeling
the
onion
layers,
so
that
twerp
uses
some
things
to
get
down
to
put
something
on
the
wire
and
then
the
interpreting
of.
What's
on
the
wire
there's
some
layers
before
it
hits
twerp
again
for
faking
the
rpc
so
like
the
two
twerps
fans
are
client
and
server
from
the
perspective
of
twerp,
but.
F
But
I
feel,
like
part
of
me,
thinks
that
it's
it's
a
hard
problem
and
you
might
just
have
to
have
to
ultimately
deal
with
the
fact
that
you
can
have
nested,
client
and
or
nested
server
spans,
and
really
the
only
thing
people
should
look
at
is
like
where,
where
do
they
change
from
client
to
server
that
that's
the
important
part
if
there
happens
to
be
a
few
nested
clients
ahead
of
that?
That's
interesting,
but
the.
C
It
that
would
be
an
interesting
tweak
to
the
spec
to
consider
that
you
could
have
something
start:
a
trace
and
it's
probably
a
server
span.
And
then
you
have
a
whole
bunch
of
internals
and
then
something
like
twerp
will
initiate
a
chain,
one
or
more
clients
fans
of
trying
to
build
up
a
client
call
out.
A
How
did
you
just
provide
a
config
option
to
users
just
say
like
in
the
twerp
instrumentation
just
say
like
you
choose
whether
you
want
to
mark
this
as
internal
or
same
with
you
know,
faraday
or
aws
sdk.
I
don't
know
I'm
trying
to
think
of
right.
B
H
A
config
option
on
faraday,
because
not
all
of
the
adapters
are
enabled,
and
that
configuration
for
example,
like
we
don't
right.
A
Oh,
I
have
an
idea
what,
if
we
had
like
client
hooks.
B
A
Okay,
I'm
sorry,
I
don't
have
good
solutions
for
your
co-worker.
H
It's
all
good.
I
think
I
think
I
guess
my
my
question
is:
if
we
weren't
spec
compliant,
then
everything
was
a
client.
Would
everyone
would
we
would
we
have
a
problem?
I
don't
know
the
answer
to
that.
F
Like
this
is
yeah,
I
feel
like
this
is
still
one
of
the
unanswered
questions
of
hotel,
and
I
know
we've
had
discussions
about
it,
and
I,
my
gut
feeling
is
that
this
is
like
a
spec,
sig
or
instrumentation
sig.
If
that's
still
happening
question
that
really
still
needs
to
kind
of
have
an
answer.
I
feel
like
it's
just
been
some
it
can.
That
has
been
kicked
down
the
road
repeatedly
and
we
still
have
no
answers.
H
F
I
guess
it's
about
that
time
to
wrap
up
the
meeting.
So
thanks
everybody
for
coming
we'll
see
you
all
next
week.