►
From YouTube: 2020-11-24 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
Hey
hey
nice,
to
see
you
as
well
as
usual.
Let's
please
add
yourselves
to
the
agenda.
Indeed,
in
this
section
feel
an
important.
A
A
I
think
that
some
of
us
well
yeah,
mostly
part
of
the
team
base
in
united
states,
is
out
this
week.
Well,
let's
see
what
we
can
do.
A
A
B
I
think,
for
me
at
least
the
the
big
issue
is:
how
should
things
behave
if
there
is
no
service
name
since
so
many
exporters
require
it
to
be
there
and
should
we
fail
early?
Should
we
fail
at
sdk
startup,
or
should
we
fail
at
export
time
like
these?
Are
the
questions
that
I
don't
really
have
a
good
handle
on
unless
we're
going
to
say,
as
you
know,
as
I
think
ted
was,
is
pushing
for
that
we
require
the
service
name,
be
in
the
resource
at
sdk
startup
time
and
then
just
refuse
to
start
up.
B
D
I
mean
the
service
can
still
start
up
depending
on
how
you
implement
the
sdk,
not
starting
up.
For
example,
you
could
fall
back
to
no
up
mode.
That's
true!
That's
fair!
That
that's
a
good
one!
Yes,
and
there
is
might
defeat
the
purpose
again,
because
if
you
want
to
fail
early
to
make
the
error
more
noticeable.
E
E
F
I
agree
yeah,
I
would
say
the
same.
There
might
be
some
beckons
that
that
have
some
other
other
means
of
reasoning,
about
the
name
or
or
don't
need
it
for
whatever
reason,
and
that
the
demand
for
a
required
service
name
is
not
coming
from
anything
other
than
those
two
exporters
right,
because
they
they
are
built
on
a
either
a
data
model
or
processors
in
foreign
that
rely
on
that,
and
it's
rather
for
backwards.
Compatibility
in
that
case.
B
Yeah,
I
agree.
I
think
that
the
this
does
boil
down
to
what
are
those
two
exporters?
What
do
they
should?
What
should
they
do,
because
I
actually
I
don't
know,
if
does,
can
we
can
we
guarantee
that
the
collector
will
be
able
to
infer
or
does
otlp
need
a
fallback
like
what
should
happen
with
the
otop
exporter
in
the
absence
of
a
service
name?
A
Yeah,
I
think
that
we
can
agree
for
a
start,
that
we
don't
want
to
report
any
error
at
export
time.
There
could
be
a
disaster
in
my
opinion,
so
basically
we
have
two
options.
We
either
fail
fast
as
at
startup
time,
or
we
provide
a
fallback
plan
which
would
be
either
provide
providing
a
default
service
name
or
go
no
op
go
knob
is
probably
safe,
but
I
can
imagine
some
people
feeling
weird
about
that.
Like
we
wouldn't
entirely
know,
although
he
could
be
safe
yeah.
A
I
think
chad
is
not
going
to
join
the
call.
I
poked
him
in
the
internal
communication
channel
and
no
probably
he
his
sleep
who
knows
okay,
but
so
trying
to
think
about
who
are
the
important
stakeholders
in
this?
I
would
say
that,
first
of
all,
probably
we
need
to
gather
the
the
feedback
from
people
from
from
jager
and
seeking,
I
would
say,
like
people
who
know
those
exporters
for
start
and
then
somebody
who
is
working
in
the
collector
so
tigran
or
box
them
probably.
D
And
one
one
problem
I
also
see
is,
I
don't
think
there
is
definitive
step
where
you
start
up
the
sdk.
D
It
might
be
a
more
gradual
process,
for
example:
first
you
initialize
the
tracer
provider
and
then
you
add
a
spam
processor
with
an
exporter,
and
I
mean
it
depends
on
in
which
order
you
initialize
this
stuff.
But,
for
example,
if
you
say
resources
are
always
initialized
before
exporters.
You
could
also
fail
at
that
step
where
exporters
are
added.
So
if
exporters
could
have
access
to
resources
already
when
they
are
initialized,
they
could
fail
themselves
if
they
want
to.
D
A
little
bit
more
on
that
yeah
I
mean,
for
example,
let's
say
I
add
the
eager
exporter
to
the
tracer
provider
in
java.
I
think
that
you
add
it
after
you
initialized
all
the
resources
and
then
the
jager
exporter
could
check
in
the
constructor
or
is
the
service.name
resource
available,
if
not
I'll,
draw
an
exception.
B
A
Okay,
since
there's
not
here,
let
me
at
least
write
what
are
the
options
that
we
have
so
personally,
I
would
like
us
to
at
least
hear
what
you
guys,
if
you
have
a
strong
opinion
between
the
main
options,
please,
so
we
can
more
or
less
have
an
idea
of
which
one
is
a
favorite,
so
to
speak.
So,
as
I
was
saying,
the
first
one
is
we
failed
to
start
without
service
name.
B
Yeah,
but
that's
actually
explicitly
the
point
of
this,
because
the
exporter
specs
says
doesn't
say
anything
about
that.
We
put
that
in
there
just
to
make
sure
that
we
could
continue.
Okay,
that
that's
actually
the
the
main
impetus
for
this
entire
issue
is:
what
do
we
do
with
that,
and
then
what
do
we
do
if
that
ver,
that
thing
collides
or
is
it
different
than
the
service
name
that
comes
in
on
the
resource
like
none?
That
is.
C
B
B
A
By
the
way,
in
the
case
of
lightstep,
we
are
playing
with
this
idea
of
distros
and
we
are
failing
at
the
start
of
time.
If
there's
no
service
name.
G
Somewhat,
I
think
it's
it's
a
little
more
nuanced
than
that
because
of
the
fact
that
yeah
like
in
our
distro,
we
require
a
service
name
like
if
it
comes
in
through
the
resource.
You
don't
actually
know
what
startup
that's,
I
think
that's
the
biggest
problem
because
they
are
async
and
they
may.
H
C
C
G
D
D
We
can
add
an
attach
callback
or
something
to
the
export
when
it's
attached
to
a
spam
processor
that
would
work,
although
the
spam
processor
itself
may
be
attached
to
multiple
different
resources
again
and
one
pro
idea.
I
have
one
issue
I
have
if
an
export
is
attached
to
multiple
tracers
providers
want
that
result
in
multiple
calls
to
shut
down
on
the
exporter.
G
While
we're
on
this
topic,
like,
I
think
it's
useful
to
point
out
that
there
might
be
problems
with
the
way
our
resource
system
actually
works
and
then
generally
kind
of
around
startup
and
around
when
different
detectors
fail.
G
I
know
this
is
something
that
we've
struggled
with
a
lot
in
javascript
to
come
up
with
a
clean
way
to
to
resolve
async
resources
and
have
them
ready
in
time
for
export
and
also
just
what
do
you
do
if
some
of
your
async
resource
detection
fails
along
the
way
like
what
is
what
is
the
right,
behavior,
so
yeah?
I
think
this
is
kind
of
like
just
one.
One.
Symptom
of
of
this
whole
problem
is
that
resource
name.
G
G
G
G
If
we,
if
we
made
something
like
default
service,
name
part
of
the
default
resource
that
you're
supposed
to
supposed
to
create
that
might
help,
it
could
have
like
its
own
environment,
variable
and
basically
yeah,
like
its
own
environment
variable,
it
could
have
a
first
class
kind
of
configuration
option
for,
for
whatever
your
sdk
start
method
looks
like,
and
it
could
always
have
some
sort
of
like
default,
that
it
would
fall
back
to
if
it
wasn't
set.
A
To
me,
it
makes
sense.
I
think,
that
yeah,
it's
this
specific
parts
of
the
resources
support,
seems
important
enough
to
decouple
it
from
the
rest
of
the
resources.
A
A
Okay,
in
any
case,
probably
we
should,
I
don't
know,
there's
already
a
discussion
there.
A
We
can
probably
at
least
comment
what
we
have
been
talking
here
in
this
issue
and
that's
it.
Sadly,
we
don't
have
enough
people
here
enough
stakeholders
and
I
don't
feel
there's
any
strong.
E
A
Yeah
yeah
sounds
right,
so
john
described
that
we
provide
default
for
java.
Only
the
only
it's
the.
E
Yeah,
so
for
for
doughnuts,
based
on
what
I
I've
seen
in
the
code,
the
jager
and
zip
keynes
caller
will
check
if
the
resource
that
service
name
is
there
and
if
it's
not
there
or
if
it's
there,
but
it's
an
invalid
value.
It
will
use
the
like.
The
fallback
behavior
try
to
get
the
the
name
space
to
try
to
use
the
process
or
the
machine
information
just
to
give
a
name.
F
A
Math,
how
is
that
in
ruby
by
the
way
and
in
javascript?
Maybe
you
are
familiar
with
both.
G
So
ruby
our
sdk,
our
sdk
configure
method.
This
is
the
thing
you
call
kind
of
before
you
start.
The
sdk
has
a
actually
has
a
service
name
and
service
version,
like
first
class
configuration
option
and
we'll
we
will
kind
of
merge
that
with
the
telemetry
sdk
resource
in
the
beginning,
so
there's
something
there's
a
way
to
get
a
synchronous
name,
but
I
also
believe
in
addition
to
that,
the
jaeger
exporter.
G
No,
I
take
this
back.
It
used
to
have
a
service
name
option
itself,
but
I
think
we
removed
that
when
we
added
this
first
class
one
to
the
sdk,
so
I
think
I
think
it
is
expected
that
at
sdk
startup
time
there
will
be
an
option
like
due
to
the
way
that
resources
can
merge
like
it
can
get
overwritten
later,
but
for
javascript.
G
A
After
listening
to
these,
my
feeling
is
that
we
should
probably
consolidate
the
the
fallback
value
you
mentioned
that
the
problem
is
that,
probably
you
end
up
with
you
know,
with
with
many
services
reporting
the
same
name.
A
A
So
if
we
want
to
take
that
approach
and
of
course,
wait
for
the
feedback
from
people
for
the
feedback
that
we
need
from
from
people
like
julia
and
antigura,
we
could
probably
cook
some
proposal
this
this
week
and
it
could
be
about
basically
yeah
providing
a
fallback.
F
A
A
F
And
I
have
one
general
question:
do
we
in
general
agree
that
this
only
applies
to
certain
exporters,
namely
jaeger,
zipkin
and
maybe
the
collector?
But
it's
not
a
general
sdk
issue,
because
if
there
are
exporters
that
don't
need
that
particular
service
dot
name,
then
this
should
be
fine,
because
I
could
imagine
a
account
having
some
rule
engine
where
you
would
say
yeah.
It
takes
the
span
name
for
some
or
it
takes
the
http
uri
for
for
other
stuff.
F
That's
something
that
would
make
sense
to
me
and
in
in
those
cases
you
wouldn't
need
any
any
service
dot
name
that
is
predefined,
or
maybe
you
add
something
to
the
collector.
You
hook
up
a
module
there
that
looks
into
attributes
and
and
sets
the
service
name
based
on
that
for
the
first
span,
let's
say
so.
I
think
it's
not
always
always
required.
A
I
I
just
want
to
throw
out
one
thing
that
I
think
backs
up.
Having
a
fallback
is
the
design
of
open,
telemetry
kind
of
not
getting
in
the
way
of
an
application,
so
you
can
instrument
it
no
matter
what
and
it
like
kind
of
falls
out
basically
makes
error
messages
really
really
really
freaking
hard.
So
I
am
really
in
favor
of
having
a
terrible
service
name
that
says:
hey,
there's
a
problem,
but
doesn't
stop
things
from
working
like.
I
I
think
that
just
really
fits
with
the
philosophy
that
I've
seen
so
far
in
the
ecosystem.
So
I
just
want
to
put
support
behind
that
and
I
think
the
whole
idea
of
how
to
get
error
messages
out
in
general
from
open,
telemetry
setup
is
going
to
be
a
big
topic
of
discussion
and
something
to
really
think
through,
as
we
find
bad
scenarios
like
this.
But
that
said,
I
think
the
the
principle
here
is
don't
get
in
the
way
of
things
working
like.
We
should
never
actually
fail.
F
Yeah,
that's
something
we
have
in
our
general
error,
handling
guidelines
that
say
tracing
can
go
bad
and-
and
we
do
our
best
so
that
people
are
aware
of
it
by.
I
don't
know,
marking
things
as
logos
or
logging
stuff,
but
we
don't
crash
the
application
just
just
because
tracing
wouldn't
work.
That's
not
what
we.
F
A
Yeah,
that
makes
sense
okay,
so
it
sounds
like
we
should
try
to
take
that
approach.
For
now.
I'm
gonna
add
this
to
the
issue
itself.
Any
any
non-american
person
could
take
would
like
to
take
this
based
on
what
we
this
calls,
which
is
basically
that
we
will
be
providing
a
a
fallback
proposal.
A
B
A
Okay,
perfect,
so
it's
it's
me
and
yeah.
I
will
create
a
pr
for
this.
I
will
yeah
okay,
I
will
probably
create
a
draft
prior
for
now.
So
at
least
we
we
can
discuss
not
the
details,
what
at
least
the
proposal-
and
hopefully
people
like
tigran
and
well-
not
hopefully,
but
maybe
people
like
tigran
and
judy
or
ted
will
be
able
to
see
this
this
week.
If
not
well,
we
can
continue
next
week.
F
A
Yeah,
as
far
as
I
know,
he's
working
today,
so
he
should
be
around.
I
will
sing
up
with
him,
but
otherwise
I
will
present
a
pro.
I
will
write
a
proposal.
Myself
sounds
good
thanks,
great
okay,
sweet
okay
that
took
a
little
while,
but
I
think
it
was
a
good
discussion.
The
next
one
is
paschemic.
Could
we
store
information
on
you?
Something
great?
Please.
J
Yeah,
so
this
is
like
a
really
a
quick
question.
I
would
say
like
what's
the
feeling
about
this,
because
I'm
thinking
that
there
are
many
use
cases
where
you
would
like
to
know
what
was
the
sampling
rate
when
given
span
was
received,
especially
when
a
dynamic
sampling
rate
which
we
don't,
I
think
fully
support
yet
or
a
sampling
rate
is
being
used.
J
That
could
give
some
indication
like,
for
example,
if
you
want
to
understand
how
many
times
given
service
was
hit,
you
need
to
divide
this
by
the
sampling
rate
number
of
spans
to
a
given
service
and
so
forth.
So
there
might
be
several
use
cases
where
this
could
be
helpful
and
I'm
wondering
if,
if
there
was
some
discussion
on
that,
I
I
was
trying
to
search
for
it,
but
I
couldn't
find
anything
and
what's
the
general
sentiment
of
this
idea,.
J
So
so,
to
give
you
an
example,
we
if
we
have
let's
say
sampling
rate
of
0.001,
we
could
have
an
attribute-
let's
say
sampling,
dot
rate
with
this
value
and
if
the
sampling
rate
is
being
used-
and
maybe
we
could
have
some
other
information
as
a
separate
field,
starting
with
with
something.
So
this
could
be
like
a
more
generic
solution
that
could
cover
more
use.
Cases
related
to
sampling.
A
D
D
A
F
J
Yeah,
but
I
think
that
sampling
priority
was
something
something
not
exactly.
It
wasn't
exactly
the
same
thing
because
okay
and
then
it
was
close
well
anyway,
we
can
take
it
offline.
I
will
need
to
research
it
a
bit
more
and
maybe
just
propose
an
issue
with
another
solution.
If
that,
if
I
would
not
find
anything
that
suits
me
right
now
and
then
eventually.
A
There
is
a
link
in
the
specification,
and
this
is
where
the
sampler
there's
a
subsection
in
the
return
value,
and
it
says
a
set
of
passband
attributes
that
also
will
be
added
to
the
span
so
check
it
out
see
that
works
for
you.
D
Sweet
as
far
as
I
can
see
the
in
general,
the
sampler
definitely
does
this
setting
this
attribute,
but
I
can't
find
the
spec
on
how
this
attribute
should
be.
J
J
A
Okay,
shall
we
go
to
the
next
item?
Well,
andrew
is
not
here,
but
basically
it's
about
the
status
of
the
p1
issues
and
then
I
see
oh,
somebody's
writing.
A
A
Sorry,
what's
happening,
something
happened,
but
anyway
there
we
are.
So
this
is
the
worm.
The
word
down
what's
happening.
This
is
usually
presented
by
andrew
yeah.
This
is
the
one
that
we
have
today
that
we
just
mentioned.
This
is
also
related.
If
I
remember
correctly
yeah.
Those
two
are
basically
one
of
the
same
yeah
and.
B
A
The
rest
are,
if
I
remember
correctly,
all
protocol,
I
was
going
to
say
that
they
are
mostly
metrics
well.
Justin
is
not
here.
Allow
port
an
update
on
this
one
is
that
we
requested
a
port.
A
A
Oh,
this
is
results,
it's
fine,
so
we're
in
a
good
state,
and
so
that
part,
I
remember
that
there
was
mention.
I
don't
know
whether
it
was
sanji,
or
that
mentioned
that.
Probably
we
should
be
starting
very
soon,
since
tracing
is
basically
done
to
start
using
part
of
the
time
of
this
call
to
discuss
metrics.
B
A
B
Well,
sweet,
I
think
if
we,
if
we
don't
do
that,
I
think
we'll
be
in
a
situation
like
we
are
today
where
a
good
fraction
of
the
folks
don't
have
a
good
handle
on
what's
going
on
in
the
metric
side,
and
we,
I
think
we
really
need
to
get
everyone
who's,
a
spec
in
the
in
the
spec
world,
on
board
with
the
metrics
specification
and
setup
so
that
we
have
a
really
good
common
understanding.
A
Yeah
worst
case,
we
can
use
at
least
half
an
hour.
Let's
say
you
know
for
metrics.
So
do
something
like
that:
okay,
so
yeah!
So,
let's
see
next
week,
then
we
will
probably
try
to
do
that:
metrics
compliance,
traces
and
context
propagation.
This
is
a
basically
a
call
out
for
for
maintainers,
I
think
in
java
we
are
up
to
date,
but
javascript
python
go
etc.
Please
check
that
out.
A
Based
on
the
comment
here
by
andrew
I'm
gonna.
I
am
going
to
guess
that
still
like
there
are
a
few
sections
like
baggage
resources
and
environment
variables
are
still
missing.
So
yeah.
Please
check
that
out
and
then
add
new
provider
specific,
restores
fields
to
the
spec.
K
Yeah,
that's
me.
This
is
my
first
meeting
for
the
spec
sig,
but
I
made
these
pull
requests
about
a
month
ago
and
was
hoping
to
get
them
merged
in
as
a
way
to
add
future
attributes
that
are
not
necessarily
generic,
like
generic
function
as
a
service
attributes
or
host
attributes,
but
that
are
actually
more
specific
to
the
service
that
they're
running
on
that.
K
There
was
some
discussion
about
how
we
want
to
whether
or
not
this
will
be
maintainable
inter
like
whether
or
not
it
will
explode
into
having
like
a
billion
different
attributes.
K
But
I
I
think
that,
like
we
decided
to
limit
it
to
only
the
current
cloud
providers
that
are
defined
in
the
spec
as
a
way
of
limiting
the
amount
of
attributes
there
would
be
so
yeah.
I
just
wanted
to.
K
Specifically,
this
poll
request
is
related
to
adding
attributes
for
aws
elastic
container
service
resource
attributes.
A
Yeah
theorem
is
over
here.
I
still
he
commented
a
few
things.
Giovanni
also
commented
a
few
things,
but
I
don't
think
he's
in
this
goal.
F
F
Okay,
I
see
that
sorry
for
the
for
the
bad
experience
with
the
lack
of
reviews.
I
just
think
that
that
most
of
the
reviewers
are
not
so
familiar
with
with
the
details
in
ews,
and
so
it's
a
bit
hard
to
to
decide
on
on.
What's
right
and
what's
what
should
be
improved,
but
I
see
that
you
pull
in
a
couple
of
your
folks
to
review.
I
review
it
right.
H
A
I
think
we
were
waiting
for
one
more
approval,
moralizing,
that
but
okay,
I
will
review
that
and
if
nobody
else
comments
anything
against
this,
I
will
merge
this
by
the
end.
A
A
C
A
Yeah
yeah
yeah,
please
review
as
well,
but
yeah
yeah
totally.
Let's
go,
let's
go
so
yeah,
it
makes
sense.
I
think
it
just
said
and
relax
pr
review
is
done.
Is
there
so
yeah,
I'm
more
confident
about
that
and
you
got
a
second
one.
Correct.
K
Yeah,
so
the
second
one's
a
little
more
controversial.
Thank
you
for
taking
up
that
that
first
one
carlos,
I
appreciate
it.
The
second
one
is
defining
like
a
generic
attribute,
whereas
the
other
ones
were
would
be
within
like
an
aws,
namespace
or
whatever
provider.
A
Yeah,
I
was
thinking
like
probably
my
connection
has
died:
okay,
okay,
but
I
see
trying
to
follow
up.
I
think
that
william
probably
needs
to
address.
F
Yeah
that
one
was
challenged
by
yuri
and
I
had
a
look
at
the
at
the
alternative
that
we
proposed
and
I
actually
find
that
one
reason
ever
yeah,
so
I
I
think
I
even
improved
it.
I
know
there
was
something
that
I
was
not
so
sure
about,
but
would
be
nice
if
we
could
get
yuri
to
to
have
a
look
at
that
one
again.
F
Yeah-
and
I
think
that
we
will
have
that
situation
more
often
that
that
there
are
certain
things
where
people
that
are
usually
reviewing
stuff
are
not
so
familiar
with
with
the
domain.
For
example,
we
have
one
for
cassandra
specific
attributes
that
has
been
around
for
a
while
now,
and
I
don't
really
know
cassandra,
I
had
a
look
at
it
and
it
links
to
the
documentation
and
it
looks
legitimate
to
me
so
I
approved
it,
but
it
would
be
good
if
someone
who
is
more
familiar
with
cassandra
could
look.
A
B
A
F
A
F
Really,
it's
not
really
fair
to
the
people
who
who
made
an
effort
in
in
creating
a
pr
yeah.
I
think
the
people
reviewing
it.
Don't
necessarily
have
to
be
the
approvals
that
have
the
power
of
check
marks
green.
But
if
we
have,
I
don't
know
one
or
two
people
who
have
a
cassandra
background
that
we
can
rely
on
and
they
say
it
looks
good.
A
Yeah,
let's
take
that
offline.
I
I
have
a
few
ideas
that
could
help
but
yeah.
Let's
follow
up
on
the
discussion.
A
A
suggestion
yeah
exactly
yeah
yeah.
That
was
my
initial
proposal.
Yes,
okay,
and
for
the
second
time
since
the
last
issue
seems
very
interesting.
I
would
like
to
just
jump
into
that
directly.
C
J
Because
for
manual
instrumentation
we
can
prepare
some
guidelines
so,
for
example,
if
you
have
an
api,
then
don't
take
the
context
from
the
request,
but
start
always
a
new
one.
Things
like
that
and
and
similar
for
for
client
codes.
We
may
describe
that
if
this
is
going
outside
of
your
organization,
then
make
sure
you
are
not
like
propagating
the
context,
but
for
automatic
instrumentation.
This
just
happens.
So
probably
we
need
some
sort
of
switch
or
other
method
to
prevent
this
from
happening,
especially.
C
J
Yeah
I
want
to
because
I
think
that
this
is
this
might
be
a
common
problem
and
out
in
the
wild.
So
maybe
there
are
some
solutions
to
this
problem.
I'm
thinking
that
maybe
someone
can
provide
some
sort
of-
I
don't
know
token
or
property
that
may
make
sure
that
if
it's
not
present,
then
that
context
is
not
being
included.
Things
like
that
or
maybe
it
can
be
simply
based
on
the
host
name
or
like
the
domain
name
in
the
hostname.
J
B
C
B
The
spec
also
supports
this
there's
a
whole
there's
a
tenant,
there's
a
tenant
id
in
that
you
can
include
as
a
part
of
the
propagation.
G
Yeah,
like
I
was
gonna
say
this
is
a
tricky
situation
and
I
think
in
a
lot
in
a
lot
of
scenarios,
you
do
still
want
to
send
this
tracing
data
if,
if
it
is
the
situation
that
these
may
be
different,
tenants
with
the
same
vendor
or
they
might
just
be
completely
separate
organizations
in
general
like
there
are
ways
if,
if
you
yourself
are
a
vendor,
for
example,
an
organization
one,
an
organization
two
are
both
your
customers
but
they're
like
completely
different
accounts
like
you
could
handle
the
situation,
it
would
require
you
using
trace
date
and
it
would
require
you
writing
some
custom
logic
with
your
propagator
to
say,
okay,
you
know
I
don't
want
to
link
these
up
on
my
back
end
because
they're
they're
not
compatible,
but
I
do
want
to
continue
to
propagate
this.
G
So
if
this
trace
does
go
back
to
organization
one
at
some
point,
if
service
acts
for
some
reason
called
service,
a
you
would
be
able
to
make
that
link
that
this
trace
has
left
your
service,
be
it
went
somewhere
into
a
black
box,
but
it
has
now
returned
to
service
a
and
you
can
kind
of
continue
the
trace.
If
that
makes
sense,.
J
I
think
that
there
are
like
two
consequences
of
what's
happening.
Currently,
the
first
one
is
that
you
know
on
the
organization
two.
The
first
span
will
have
a
pattern
span,
id
set
which
is
not
expected,
because
there
is
it's
a
new
trace
for
organization,
two
and
another
continuation
of
another
trace,
which
is
maybe
a
smaller
problem,
and
the
second
thing
that
could
happen-
and
please
correct
me
if
I'm
wrong
here,
but
if
organization
one
is
putting
something
into
the
baggage,
then
it
will
be
present
in
organization
two,
and
this
could
be
well
unwelcome.
G
As
far
as
baggage
goes,
I
think
that's
also.
The
intention
is
that
you
will
potentially
receive
packages
from
many
sources,
but
you
are
expected
to
propagate
it
on
behalf
of
these
other
services.
Just
because
they
ask
you
to
and
failing
to
do
so
could
could
break
break
an
application
if
it
returns.
I
guess
back
to
their
services,
because
you
don't
always
know
where
the
trace
terminates.
I
guess,
but
at
the
same
time
I
do
understand
that
there
are
probably
some
scenarios
where
you
absolutely
probably
do
not
want
to
pass
context.
G
So,
like
I
think
I
don't
know,
I
don't
know
what
the
solutions
are,
but
I
do
think
that
there
are
a
couple
of
options
so
like
one
of
them
for
the
solution,
where
you
definitely
don't
want
to
send
something
to
a
third-party
api,
I
could
see
having
some
sort
of
deny
list
for
for
a
client,
as
as
a
stop
gap
for
situations
where
you
don't
explicitly
are
there's
no
reason
to
not
explicitly
not
past
pro
past
context.
G
You
should
probably
just
pass
it
and
let
the
receiving
service
make
the
decision
what
it
wants
to
do
there,
but,
like
the
the
whole
kind
of
purpose
of
of
w3c
trace
context,
is
to
allow
like
a
trace
to
go
through
at
least
multiple
tracing
vendors
for
the
same
for
the
same
customer.
G
Ultimately,
so
the
idea
is,
a
client
could
well
even
more
than
that
that
a
trace
could
go
through
multiple
trace
tracing
providers
and
possibly
multiple
multiple
customers,
and
you
would
at
least
be
able
to
know
this,
and
there
is
kind
of
a
future
goal
for
that
group
to
ultimately
have
trace
exchange
trace
exchange
is
part
of
this
group's
charter.
G
They
aren't
there
yet,
but
ultimately,
if
you,
if
you
can
detect
that
a
trace
has
been
somewhere
else,
then
you
can
potentially
find
out
where
this
is
and
based
on
a
trace
id
query
for
it
and
have
kind
of
like
integrations
between
providers.
J
G
Yeah
it
I
mean
it
does.
It
also
adds
like
some
complications,
or
at
least
things
that
you
need
to
be
aware
of.
As
a
trace
comes
in
and
like
the
the
situation
is
like
you
know,
you
might
not
have
the
others
fans
for
the
the
incoming
trace.
They
may
be
going
to
another
provider,
but
there
are
ways
too
to
work
with
us.
I
think.
G
G
E
E
A
Okay,
well
at
least
we
have
trace
context
more
or
less
done,
but
mostly
though
okay.
I
think
that
was
the
last
item,
so
I
will
give
you
guys
two
minutes
back.
Thank
you
so
much.
Thank
you
for
the
discussion.
We
were
missing
some
important
people,
but
still
we
managed
to
discuss
a
few
very
important
items.
A
Yeah
please
follow
up
for
for
those
ones.
Taking
days
of
this
week,
enjoy
them
for
the
rest,
see
you
see
you
around
have
a
good
day.
Thank
you.
Bye.