►
From YouTube: 2022-09-22 meeting
Description
Instrumentation: Messaging
A
C
A
A
A
A
A
B
Let's
see
other
folks
join
okay,
so
I
I
this
week
was
really
busy,
so
I
I
didn't
have
much
time
to
to
address
some
of
the
things
but
I
last
week
what
I
did
do
is
I,
follow
up
on
the
on
the
topic
of
trying
to
get
more
people
on
board
if
they're,
approving
the
PRS
or
the
close
to
us.
B
So
I
I'm,
not
sure
if
you
saw
what
I
post
posted
a
message
on
our
our
chat
there
in
on
the
cncf
slack
and
two
other
of
the
colleagues,
the
guys
there
reviewing
rpr's
commonly
so
Paulo
and
Bruno,
they
seem
both
to
be
on
board
I
asked
if
I
it
would
be.
Okay
to
add
their
names.
B
Only
Paulo
came
back
to
me,
so
I
will
give
you
a
follow-up
to
see
if
also
Bruno,
it's
okay
in
doing
it,
and
so
and
I
also
have
one
comment
from
from
you
Johannes
to
to
address
their.
That
should
be
easy,
but
I
I
probably
will
get
on
it
tomorrow.
B
To
add
the
to
add,
the
description
for
the
intermediator
foreign
like
I,
did
for
the
other
things,
so
that
should
be
easy
to
do.
Apart
from
this
I
think
the
pr
is
ready.
There's
only
one
thing:
there
is
this
through
this
comment
open
here
where
there
was
some
discussions
on
on
the
green
text
not
being
completely
clear
about,
for
example,
where
the
or
where
the
the
the
cortex
should
be
edited
and
because
of
the
beta
was
concerned
or
she
she
had
a
point
which
I
think
makes
sense.
B
That
does
she
says
it's
more
like
rocus
should
not
change
the
contract
because
we
say
it
cannot
change
something
like
that
yeah,
so
we
say
it's
to
attach
in
a
way
such
it's
not
possible
to
be
changed,
but
it
is
possible
to
to
be
changed
right
so
because
there's
no
enforcement
in
some
places.
So
she
had
this
point
and
there
was
this
strategy
and
at
some
point
we
I
arrived
to
this
next
year,
which
I
think
addresses
everything
and
she
reacted
here.
So
I
think
she
agrees
with
this.
Oh
hey,
Bruno,
Mars,
here.
D
Welcome
hey,
how
are
you
guys.
B
Decide
so
that
the
only
thing
that's
left
of
this
is
there's.
This
message
is
so,
if
you
agree,
if
you
just
try
to
pick
a
book,
if
you
can
and
if
you
think
this
is
better
than
the
correct
that
correct-
let's
just
react
to
here,
either
thumbs
up
their
thumbs
down
or
whatever
leave
your
comment.
If
not,
then
I
will
just
close
this
and
and
keep
the
text,
as
is.
A
B
E
A
B
C
Yeah
I
mean
I
will
think
about
that
I
mean
I've,
found
quick
thought
here
and
I
I
think
you
understand
also
not
Miller's
concern,
but
I
also
understand
remark,
because
I
think
we
should
be
careful
of
making
just
requirements
here
for
intermediaries
and
what
intermediaries
should
do.
I
think
that's
actually
not
really.
When
we
talk
about
like
instrumentation
here,
that's
not
really
our
business
to
kind
of
what
we
call
put
requirements
on
intermediaries
and
yeah
I
will
think
about
that
and
write
some
comment.
C
Maybe
we
can
find
a
formulation
that
that
just
focuses
on
consumer
requirements
but
still
kind
of
addresses
with
mailers
requirements.
C
Because
when
we
say
what
the
intermediate
we
should
do
here
and
should
not
do
it
feels
to
maybe
kind
of
Step
a
bit
too
far,
because
I
think
just
intermediaries
will
not
like
most
likely.
We
just
assume.
Currently
the
intermediaries
don't
know
anything
about
about
the
context,
propagation
and
the
semantic
conventions
at
all.
So
it's
a
bit
strange
to
just
put
requirements
on
demons
during
this
document.
A
B
All
right
so
yeah
so
I
think
this
is
the
major
thing
that
is
left
here.
There
was
this
other
one
here
from
Dwayne,
but
I,
don't
remember
what
it
was
yeah
if
I
think
I
replied
to
some
time
ago.
If
you
have
time
to
read
I'm,
not
sure
if
I
answered
your
questions,
but
apart
from
this
I,
think
it's
good
to
go.
There's
the
the
addition
for
the
intermediary
definition
that
I
will
end.
Probably
tomorrow.
B
And
then
we
we
should
be
good
to
go
yeah
and
then
I
will
add
follows
to
the
description
here
and
see
that
is.
Okay,
we
did
so
I'll.
Add
I
think
we
already
do
this
in
all
tabs
right
that
we
had
some
something
like
I
think
I
saw
in
some
more
depth
that
we
had
like
some
supporters
or
some
people
they're
on
board
with
this
or
that
in
the
description.
So
I'll
try
to
do
something
similar
so
but
I'm
not
sure.
If
anybody
else
feels.
B
C
Guess
I
can
try
to
explain
yeah
we
we
are
basically
working
as
a
more
or
less
if
you
see
like
the
reviewers
here,
just
like
technically
commit
these
specs
approvers
black
trace
approvers
and
for
trained
for
changes
like
this,
like
the
technical
committee
needs
to
approve
and
they
all
stretched
pretty
thin.
C
So
they
are
currently
working
on
on
how
to
say
a
guideline:
how
to
get
semantic
convention
stable,
which
also
means
that
independent
groups
of
experts
are
working
on
different
areas
of
semantic
conventions
and
there's
no
process
currently
how
those
groups
should
best
work
because
they
operate
those
groups
like
us,
our
group,
he
would
operate
a
bit
independently
of
the
overall
open,
Telemetry
spec
group,
just
because
we
need
the
sub
subject
matter.
Experts
having
involved
here,
who
often
are
not
really
deeply
involved
into
open
Telemetry.
C
So
there's
no
process
yet
so
yet
of
how
those
groups
are
working
and
working
together
with
open
Telemetry
that
processes
in
the
making
there
is
this
issue
and
Trust
from
Google
is
working
on
flashing
this
process
out.
In
the
meantime,
we
are
a
bit
of
kind
of
like
how
to
say
hanging
free
in
the
air
here.
So
it's
not
here
how
we
best
collaborate
with
the
with
the
bodies
like
the
technical
committee
who
need
to
approve
our
work.
C
They
also
often
don't
have
the
time
to
kind
of
look
into
all
the
technical
details
and
approve
our
work
based
on
that.
So
what
they
were
asking
about,
Josh
was
asking
is
kind
of
this
intermediate
resolution
for
us
to
continue
productively
working
and
for
them
kind
of
avoiding
being
threat
to
sin
by
giving
detailed
reviews
is
just
that
we
put
like
a
list
of
people
there
who
were
involved
in
this
work
and
the
list
of
credentials
basically
saying
yeah.
C
This
person
is
working,
I,
don't
know
at
AWS
on
messaging
systems
so
that
we
have
this
list
of
people
who
approved
who
are
involved
in
the
work
and
who
are
agreeing
with
this
work,
and
then
basically,
this
gives
the
necessary
credibility
to
the
work
or
to
the
PRS
for
the
technical
committee
to
approve
them
and
merge
the
work
without
looking
into
order
technical
details.
C
So
it's
just
basically
a
matter
of
creating
credibility
and
Trust
and
basically
for
them
trusting
that
this
work
or
these
PRS
are
okay
without
getting
into
order
tactical
details
and
reviewing
everything.
So
that
is
kind
of
the
background.
Why
we
why
it
would
be
great
to
have
kind
of
an
as
comprehensive
as
possible
list
of
people
there
who
are
working
in
the
business
who
are
working
with
messaging
systems?
And
you
know
thus
this
list
can
kind
of
give
credibility
to
our
work
and
make
it
much
easier
for
us
to
get
things
merged.
C
This
is
more
like
often
as
I
said
intermediate
resolution.
I
mean
there
will
be
some
kind
of
workstop
process
that
is
for
this.
Instrumentation
stability
working
group
is
about,
but
yeah
in
the
meantime,
that's
the
advice.
We
got
how
to
best
operate
foreign.
B
To
collect
some
some
folks
like
this
that
are
willing
to
to
lean
into
this
participated
with
this,
and
then
we
would,
for
example,
add
add
their
names
to
the
description
here,
just
to
give
some
more
because
yeah
they
can
see
that
they
approved,
of
course,
that
also
counts,
but
also
the
credentials
and
like,
for
example,
I
worked
on
like
he
said.
I
work
on
this
specific
company
worked
on
the
specific
messages
yeah.
So
that's
why
I
posted
that
message?
B
There
and
I
thanked
you
and
Paulo,
because
you
you
both
reviewed,
thankfully
reviewed
some
of.
A
B
Already
and
since
you
you
are
working
on
on
this
space,
as
also
would
be
great,
if
we
could
yeah
use
your
credential
there,
but
yeah,
but
of
course
feel
free
to
not
not
be
persuaded
or
don't
feel
pressured
to
to
do
anything.
But
they
will
be
great.
D
In
my
in
my
particular
case,
I,
don't
work
directly
with
the
messaging
systems
like
GMS
Artemis,
or
something
like
that.
That
is,
that
I've
been
using
to
to
Showcase
some
of
these
open,
Telemetry
messaging
propagation
work,
let's
say,
but
I
can
try
to
to
see
if
someone
over
there
has
interest
on
this,
but
I
will
continue
to
to
follow
this
work,
because
right
now
so
I
I
I'm
trying
to
do
a
POC
and
what
I
am
able
to
do
with
the
the
current
state
of
open
telemetry.
D
Well,
it
doesn't
allow
me
to
to
create
this
span
that
encompasses
the
whole
messages
spun
from
beginning
to
the
end.
That
goes
through
well
more
than
one
service.
D
What
I
get
is
just
the
initial
span
from
sending
the
message
and
the
receiving
end
and
from
what
I
understood
for
what's
in
there.
The
purpose
is
to
have
just
one
spent
for
the
message
from
the
beginning
until
this
process
right
foreign.
B
Yes,
so
the
idea
is
to
the
producer
would
create
this
context.
We
didn't
Define
it.
What
is
going
to
be
I
saw
your
comment
in
the
Otep
saying
that
we
should.
That
was
interesting,
but
we
still
didn't
decide
what
it
will
be.
That
is
going
to
go
inside
the
message,
but
it
will
be
at
least
the
the
the
trace,
IDs
and
so
on,
so
so
you're
able
to
to
continue
the
trace
so
then
yeah.
So
the
producer
will
do
this.
Put
this
whatever
we
decide,
we
will
be.
B
B
Okay,
the
customer
will
create
a
link
to
this
to
the
to
the
trace.
That
is
inside
the
message,
and
then
this
will
be
able
to
to
correlate
like
this,
but
that
is
a
roughly
like
a
roughly
overview.
C
Bruno
I
think
you
were
talking
about
the
span.
One
span
encompassing
order,
work
for
message,
processing,
I,
think
it
would
not
be
a
single
span,
it
will
might
it
in.
In
our
case
it
will
be
multiple
spans
that
are
somehow
correlated
with
each
other
I
look,
apparented
or
they're
linked,
but
I
think
it's
not
really
possible
to
have
a
single
span
that
encompasses
all
the
work
for
products.
Okay,
so
there
will
be
several
spans
that
are
correlated
and
to
your
other
points
that
you
think
you
don't
have
the
necessary
like
expertise
or
credentials.
C
I'm
pretty
sure
that
you
have
I
mean
when
you
work
on
a
POC
for
instrumenting
messaging
systems
and
when
you
kind
of
feel
comfortable
reviewing
PRS
like
this
I,
definitely
think
you
have
the
credentials
to
be
on
board
and
you
should
be.
You
should
be
on
the
list,
because
people
who
instrument
messaging
systems
and
to
who
are
kind
of
who
know
who
see
who
experience
the
problems
there
think
those
are
actually
experts
that
we're
seeking
for
because
they
have
both
messaging
knowledge
and
also
instrumentation
knowledge
and
I.
C
Think
those
are
exactly
the
people
that
we
want
to
have
on
board
here.
So
I
definitely
think
you
have
I
mean
if
you
can
involve
anybody
else
from
your
site.
That's
great,
but
definitely
you
have
the
necessary
kind
of
expertise
and
credentials
to
be
part
of
this
list
that
we
are
trying
to
put
together.
D
Okay,
thanks
you're,
very
kind.
B
Yeah
I
also
yeah.
There
might
be
some
some
people
coming
to
the
to
our
CSF
slack,
because
just
this
week,
I
I
was
kind
of
very
busy
best
days,
but
I
I
I
hosted
this
Meetup
yesterday
about
hotel
and.net,
and
there
was
quite
a
few
folks
that
came
in
and
they
were
asking
all
this
sort
of
questions
about
messaging
and
so
on,
and
they
actually
like.
B
There
was
three
three
folks
I
think
three
all
of
them
were
using
Kafka
and
they
were
having
these
problems
that
they
don't
know
how
to
correlate
things
that
we
have
a
batch
batch
of
messages.
You
know
like
how
do
they
do
it?
How
is
it
going
to
work
and
so
on?
It
was
quite
cool
and-
and
they
were
doing
all
this
workarounds
and
so
on
and
I
I
basically
told
them
to
join.
B
B
So
if
you
see
some
people
there
might
be
some
of
these
folks,
but
yeah
it
was.
It
was
interesting
to
to
actually
find
users
that
are
trying
to
get
work
done
and
their
trying
to
work.
Trying
to
use
hotel
for
doing
things.
Kind
of
get
them
are
a
bit
stuck
or.
D
Yes,
because
well,
the
the
HTTP
tracing
is
kind
of
a
some
problem,
more
or
less,
but
the
messaging
is
I,
think
it's
more
challenging
and
is
equally
important.
So
in
past
companies,
I
worked
with
messaging
systems
and
most
of
the
work
was
dispatched
through
these
messages,
so
jobs
would
send
messages
that
would
be
completed
elsewhere
and
without
this
type
of
tracing
is
actually
not
possible
to
to
understand
if
jobs
jobs
are
being
completed
correctly,
and
if
we
could
put
something
that
allows
this
traceability
on
message
workloads.
D
It
would
be
great
because
this
is
why
they
use
not
just
for
Kafka,
but
all
kinds
of
messaging
I
was
using
rabbit
mq
at
the
time.
Actually,
but
it's
it's
the
same
problem.
D
B
E
Joe
I
have
a
very
small
question:
remark
about
your
pull
request
on
the
context
propagation,
so
I
checked,
I
randomly
looked
into
the
specification
recently
in
the
API
stack
and
what
I
found
there
in
open,
Telemetry
API
that
there
is
a
sentence
there
that
individual
messages
requires.
The
new
producers
spend
per
message
to
be
paid.
E
E
A
Here
this
yeah.
E
B
E
B
B
Oh,
that's,
nice,
yeah,
I'll,
think
about
it.
Maybe
I
there's
some
place
to
add
on
the
complex
propagation
we
are
now,
but
otherwise
it's
good
to
know
that
there
is
something
and
if
there's
something
here
already,
then
maybe
we
don't
even
need
to
discuss
what
to
add
anymore
what
the
traces
will
be
where
the
context
will
be
because
it
won't
be
a
span
anyway.
B
Yeah
I
still
need
to
read
what
you
added
there.
Bruno
I
know
about
that.
Pr,
the
the
con,
the
context
very
scope
thing,
because
it
was
brought
up
by
a
colleague
from
from
here
and
yeah,
but
I
guess.
Maybe
we
need
to
think
because
I
Spain
can't
contain
a
lot
of
stuff,
but.
D
Yeah
yeah
I
think
there's
kind
of
of
very
different
ways
and
definitions
about
context
and,
while
there's
instrumentation
context,
yet
the
scope,
the
well
I
I,
come
to
three
of
them
on
my
notes
and
they
have
very
specific
definitions
and
I.
Don't
know
if
any
of
them
can
be
used
effectively
to
to
do
what
we
want
here
unless
I
I'm,
not
understanding,
well,
that
the
problem.
B
I
think
the
easy,
the
easy
thing
that
we
can
use,
which
we
don't
have
to
create
anything
new,
is
just
to
create
a
span
and
put
the
span,
as
is
inside
the
message
right:
oh
yeah,
yeah,
but
but
folks
already
created
a
there's.
Some
concerns
about
this
I
think
the
main
one
is
that
probably
probably
most
of
the
time,
if
you
do
this,
the
span
will
be
like
a
zero
duration
spin.
So
this
one
thing
that
it
tend
to
be
not
well
received.
B
Yeah
and
but
there's
no
other
concept
like
we
talk
about,
we
entertain
the
idea
of
having
a
new
thing.
That
is
a
stainless
context,
more
or
less.
That
is
just
the
IDS,
for
example,
but
there's
no
such
thing
today
expect
so.
C
Think
the
the
wording
here
is
actually
pretty
good
because
it
says
in
messaging,
scenariosis,
batching
tracing
individual
message
requires
a
new
producer
span
per
message
to
be
created,
so
it's
kind
of
just
a
trade-off
that
you
have
so
if
you
want
to
create,
if
you
want
to
trace
individual
messages,
you
have
to
create
a
span
and
you
pay
the
overhead.
If
you
don't
want
to
pay
the
overhead-
and
you
don't
want
to
have
a
spam
for
each
individual
message,
you
can
basically
just
Trace
batteries
more
or
less,
and
you
cannot
raise
their
individual
message.
C
I
think
this
is,
it
doesn't
require
here
to
create
this.
This
wording
here
doesn't
require
you
to
create
a
span
for
each
individual
individual
message.
It's
just.
If
you
want
to
trace
each
individual
message,
then
you
should
create
a
span
for
it
and
attach
this
context.
I
think
that's
pretty
pretty
good
wording
actually,
and
that
also
shows
the
trade-off
that
basically
instrumentation
writers,
trust
the
need
to
consider.
C
B
So
this
kind
of
songs,
a
large
large
portion
of
things
for
us,
no
because
I
think
we
discussed
this
a
lot
during
your
vacation.
I
think
this
was
some
of
the
main
things
that
we
spent
some
time
discussing.
What
would
be
and
seeing
that
we
can
just
go
with
the
spend
it
yeah.
A
D
So
so
imagine
that
we
do
we
send
the
the
this
this
Span
in
the
message
we
need
to
serialize
it
and
how
would
we
do
that.
E
E
But
your
your
point
is
to
add,
like
start
the
spend
on
one
service
right
and
propagate
it
all
the
way
through
and
end
it
on
the
somewhere
else
to
trace
the
whole
thing.
B
I
think
it
was
more
and
more
a
way
to
encapsulate
everything
right,
so
you
just
sterilize
it
and
then
just
realize
it
back
to
have
access
to
and
everything.
Yes,.
D
Well,
it's
it's
right
now.
It's
I
think
it's
open,
so.
D
Ludmila's
question
I
don't
mind
to
have
multiple
spans
and
just
having
a
context
being
propagated.
It
doesn't.
A
D
If
this
is
by
serializing
the
context
or
creating
multiple
spans,
because
right
now
we
have
kind
of
a
context
propagation.
If
we
instrument
the
the
message
that
we
send
them
in
a
particular
way.
The
the
trace
IDs
sent
on
can
be
sent
as
a
header
on
the
message,
and
we
see
we
can.
We
can
create
a
span
in
the
when
we
are
sending
that's
a
unique
span.
Are
there
and
then
it's
correlated
with
the
the
consumer
spend
that
is
well
created
on
the
receiving
end.
D
But
it's
not
like
under
the
same
umbrella.
It's
like
this
happens
here
that
happens
there
and
in
the
middle
we
don't
really
know
the
timing
of
right
now,
because
the
Brokers
are
not
instrumented,
because
there's
no
spec
for
this,
but
in
the
future
it
would
be
super
interesting
to
have
the
timings
between
the
sending
and
receiving
of
the
message
to
to
understand
what
happens
on
the
infrastructure
side.
E
Yeah
and
possible
solution-
and
we
didn't
approach
it
yet,
but
the
possible
solution
could
be
that
there
are
actually
two
contexts
that
flow.
There
is
a
message
context
right
and
there
is
a
transferred
context.
They
could
be
related,
but
not
necessarily
so
you
create
the
message
right.
The
context
flows
unchanged
to
the
next
hope.
Right
and
also
you
have
a
span
that
describes
call
to
the
broker.
What
broker
can
do?
They
can
just
continue
this
transfer
context.
E
They
can
also
link
to
the
message
context.
They
can
say:
okay,
I'm
related
I'm,
doing
something
related
to
this
message
right
and
we
don't
know
how
it
can
be
like
how
it
will
be
done.
It's
just
with
context
embedded
the
message.
It
does
not
prevent
us
from
any
of
the
broker
instrumentation.
A
B
A
B
And
for
for
this,
for
this
part
for
the
broker
instrumentation,
we
have.
We
have
a
column
here,
V2
which
we
discussed
a
bit,
but
we
decided
to
because
it's
not
too
much
anyway.
So
we
decide
this.
The
the
intermediary
part
is
is
important,
but
we
kind
of
postponed
it
to
let's
say
V2
and
what
we
discussed
here
like
in
a
sense.
So
once
we
have
this
context
propagation
for
the
message
in
place,
it
will
be
put
in
the
message
under
some
you.
B
Maybe
header
named
a
key
name
whatever
it
is,
and
that
will
be
specific
for
the
message
for
the
application
layer,
let's
say
instrumentation
and
then
the
usual,
the
usual
transparent
and
you
can
still
exist
and
then
that
will
be
used
for
instrumenting
the
whole
like
the
whole
part.
So
that
would
be,
for
example,
I.
My
app
sends
the
message
and
then
the
broker
the
processes
that
the
trace
ID
and
creates
a
new
one
and
replace
the
header
and
sense
again
and
then
the
other
things
again.
B
B
Okay,
yes,
but
for
the
for
what
things
were
looking
into
this
a
little
bit,
because
this
is
really
I
guess
this
is
good
news
for
us,
but
there
is
already
this
I
think
this
specification
and
I
guess
we
could
use
it
as
an
argument
that
is
already
there
and
and
depending
how
we
phrase
it.
We
we
can
say,
like
also
like
Johanna,
said
that
this
is
there
it's
possible.
If
you
don't
want
it,
then
you
don't
have
this
level
of
insights.
But
if
you
want,
then
you
can
do
this.
C
Yeah,
it's
currently
open
for
context.
Propagation
I
mean
I
think
we
should
also
make
here
that
we
we
don't
really
answer.
We
don't
really
aim
at
answering
this
question
yet
there,
because
this
context,
propagation
card
is
just
about
how
propagate
context,
but
we
don't
actually
say
what
context
you're
propagating
here.
I
think
that
we
can
really
clarify
with
future
additions
to
the
spec,
because
now
we
just
say:
okay,
how
do
we
propagate
context?
C
B
Yeah
yeah:
do
you
think
I
think
it's
I
mean
it's
not
explicit,
but
I
could
I
could
maybe
make
it
more
explicit
on
the
description
here.
The
the
goal
is
not
yes,
but
yeah.
E
I
think
we
have
a
initial
OS
where
we
are
trying
to
choose
between
span
and
spend
context,
and
also
we
have
a
document.
Maybe
if,
if
I
share
a
link
and
if
you
can
take
a
look
and
then
if
you
believe
something
is
not
addressed,
you
can
comment
on
the
issue
and
we
can
I,
don't
know,
expand
it
or
do
something
about
it.
How
would
you
feel
about
this?
Oh.
B
Right
so,
okay,
yeah,
the
next
thing
that
I
put
here,
was
just
about
your
comments
in
the
big
order
now,
but
it's
I
think
it's
basically
what
we
just
discussed
now
about
the
because
there's
this
other
PR
about
this
other
approach
for
context
or
context
attributes.
So
you
start
a
span,
you
start
a
span
and
then
all
the
attributes
that
you
start
that
is
under
that
are
kind
of
passed
on
to
all
the
things
that
happens.
B
B
C
C
B
C
B
For
the
baggage
data
in
the
message
that
is
propagating
right,
so
all
these
things
but
I
guess
it's
the
whole
point
of
package
anyway
to
have
it
propagated,
but
through
other
other
to
outside
boundaries
like
this.
Do
you
know
if
this
w3c
expected?
They
are
start
working
on
the
drive?
I
didn't
I,
didn't
look
in,
but.
B
E
Yeah,
thank
you.
So
was
the
mqp
Practical.
They
used
the
same
header
Trace
current
so
far.
That
I
think
it
will
change
if
it
gets
in
your
update
at
some
point,
but
they
use
binary
format,
so
they
have
binary
tracing
the
binaries
1080,
which
means
that
there
is
no
straightforward
way
to
use
it
because
binary
format
is
again
another
draft
PR
and
there
is
no
supports
written
up
in
telemetry.
E
B
Yeah,
but
this
thing
may
be
used,
binary
may
be
used.
E
C
I
think
Factory
need
to
think
about
whether
how
we
deal
with
package
across
links
I
mean
that
it's,
that
is
anyway,
that
is
anyway
like
a
not
just
a
messaging
problem,
but
a
general
problem
when
you
expands
together
like
when
you,
basically
when
your
parents,
bands
together,
you
get
the
parent
context,
and
maybe
there
comes
baggage
with
it.
I
think
there's
some
basically
find
how
you
deal
with
baggage,
but
with
links,
it's
not
really
clear.
C
Furthermore,
even
when
you
have
like
a
consumer
span,
you
can
like
consume,
maybe
several
messages
in
one
span
and
then
each
of
those
several
messages
on
Spain
and
each
each
with
this.
Each
of
this
message
comes
then,
with
their
baggage,
and
it's
not
I
think
it's
not
that
clear
at
all,
but
to
do
this,
what
to
do
with
this
baggage,
but
I
think
this
is
not
just
a
messaging
problem.
That's
a
more
General
problem.
C
Because
remember
that
was
also
a
point
that
Bogdan
brought
up
with
the
with
the
baggage
and
yeah,
but
I
think
it's
not
messaging
dependent,
but
it's
a
more
General
problem.
C
Because
I
mean
for
propagation,
it's
not
really
a
problem
like
to
propagate
baggage.
It's
just
another
header
that
you
that
you
add
it's
just
a
third
header,
Trace
parent,
then
Trace
State,
and
then
you
have
this
package
header,
but
the
what
you
do
with
it
on
the
receiving
side.
I
think
that
is
currently
the
more
undefined
the
more
undefined
thing.
What
you
do
with
it
in
scenarios
where
you
just
link
and
don't
parent.
A
C
B
C
C
I
I
think
once
it's
table
there,
then
I
guess
open
Telemetry
will
figure
out
how
to
actually
exactly
deal
with
spirit
with
baggage,
also
in
like
transparent
child
relationships
and
then
I
think
in
in
and
then
in
this
discussion.
It
might
then
be
good
to
also
bring
up
the
link
problem.
B
Yeah,
that's
good
to
know
yes
right
so
yeah
from
the
comments
here
and
there
was
this
one
about
about
the
links
and
the
baggage
about
this
one
here
this
this
portion
of
the
text
here
is
is
what
we
I'm
gonna,
try
to
what
the
other
PR
is
trying
to
put
so
the
API
is
trying
to
to
grab
some
of
these
here
and
and
already
make
incremental
changes
so
yeah.
B
So
this
is
what
the
other,
the
other
PR
pretty
much
the
same
thing
yeah
and
then
they
must
not
be
altered,
but
we
I'll
try
if
you
were
here
in
the
beginning,
but
we
discussed
this
that
yeah,
who
probably
should
try
to
avoid
any
disk
requirement,
the
the
other
PR
words
of
mine
in
the
lbr.
There
is
this
discussion
here
about
the
same
thing
that
you
commented
out
there,
Bruno
and
and
about
the
this
requirement
for
for
not
changing
the
context
as
well
and
there's
some
discussions.
B
If
you,
you
can
take
a
look,
but
the
latest
I
propose
this
to
reward
a
bit,
but
we
discussed
again
today,
and
maybe
we
should
even
not
talk
about
like
what
the
intermitters
should
do
in
this
case
here.
So.
A
B
So
maybe
more
more
discussions
a
bit
on
this
and
maybe
another
iteration
too,
to
try
to
get
the
text
a
bit
better
right.
Yes,
indeed,
I
think
the
other
thing
that
you
comment
on
is
yeah
the
last
thing.
The
other
thing
is
yeah,
as
you
know,
probably
now
it's
it's
a
Spam,
but
we're
trying
to
push
to
use,
and
now
we
just
learned
that
there's
already
this
pack
so
which
is
great.
B
All
right,
okay,
I,
think
that's
what
I
put
what
I
had
in
the
agenda
for
today.
Does
anybody
have
anything
else?
I
may
ask
in
the
beginning,
I'm,
not
sure
if
you
were
already
here
about
the
pr
that
you
had
for.
C
E
It's
a
good
question
whether
we
are
ready
to
undrafted
I
guess
by
look
and
that's
another
question.
I
wanted
to
ask
you
guys,
because
I
was
looking
at
our
project
board
and
also
at
the
autop,
and
my
feeling
is
the
attribute
part
is
good
enough
to
start
trying
to
incorporate
it
in
their
current
stack.
E
E
So
if
it's
the
case,
we
can
just
bundle
the
things
up
yeah
because
there
are
other
breaking
changes,
for
example,
The
Source
name
on
the
consumer
side
right,
so
it
will
be
breaking
for
an
existing
spot
and
if
we
feel
we
are
ready
to
start
working
on
the
attributes
making
them
to
the
stack,
then
let
me
continue
adding
them
to
this
draft.
And
then
we
will
have
all
the
breaking
changes
in
one
place.
A
That's
right,
I
think
our
original
intent
was
to
have
like
a
PR
that
is
very
small
and
easy
to
review
and
approve
and
not
have
something
big
that
can
take
a
long
time,
but
the
really
supported
in
all
these
biking
changes
I,
just
I'm
afraid
they
might
take
a
lot
of
time
until
it
will
get
merged.
We
think
it's
something
we
can
do
quickly.
E
E
I
guess
it
would
not
include
the
source
name,
but
I
will
go
through
the
list
and
understand
it
better.
Then
this
PR
will
be
bigger
anyway
and
I.
Don't
think
we
can
do
it
quickly
because
nothing
happens
quickly
in
the
spec
repo
right,
so
I
can
incorporate
all
those
changes
or
I
can
undraft
the
pr
we
can
try
to.
We
need
to
form
this
group
right.
It
was
Bruno.
Thank
you
for
helping
us
with
this
really
appreciate
your
journey.
E
A
E
A
B
I
just
want
to
add
one
question,
I
think
from
last
time.
The
the
thing
that
is
breaking
in
the
pr
here
is
that
we
move
the
message:
ID
right.
E
Can
you
open
the
change
lock,
it's
listed
there,
everything
yeah.
All
of
this
great
thing
is
great.
E
A
But
we
don't
feel
comfortable
with
adding
a
few
breaking
changes
in
multiple
steps
like
Because.
B
Unless
the
PRS
already
like
already
running
and
we
open
one
but
but
the
the
emerging
times,
yeah
I
mean
having
having
all
of
them
in
the
same
PR.
I
wouldn't
think
it's
it
would
be
too
big.
I
mean
it
would
not
be
a
lot
of
changes.
I
would
say
right:
I
was
messing
with
the
table.
I
guess,
but
mdpr
would
be
big
because
of
the
discussions.
A
To
discuss
about
so,
if
we're
limiting
it
to
a
narrow
like
subject,
then
it's
easier
to
to
get
it
through.
Yes,.
E
B
E
B
Thinking
is
like
because
what
I'm
thinking
is
like
it's,
it's
not
stable
yet
right!
So
should
we
understandable
that
we
are
trying
to
make
this
stable
right?
B
So
we
try
to
clean,
clean
up
the
house,
so
it
would,
it
would
be
I
guess
expected
that
we'll
be
breaking
changes
because
it's
not
stable,
but
so
so
like
what
I
wanted
to
the
point
where
I
want
to
make
is
they
were
just
just
want
to
make
sure
that
we
that
this
problem,
like
not
having
several
break
changes,
is
really
something
that
should
be
avoided
or
is
something
that
we
have
in
our
minds,
but
not
sure
it's
really
true
right.
D
So
from
from
the
Javas
pack,
there's
breaking
changes
from
time
to
time,
wow
almost
every
release.
D
D
E
E
So
there
is
a
new
spec
version
is
okay,
so
once
the
new
stack
version
is
released,
the
CML
file
that
we
see
here
messaging.yahoo
it's
used
to
originate
code
in
at
least
a
few
languages,
definitely
in
gold
for
sure
in
Java
and
probably
other
languages.
So
from
this
yaml
file
they
have
a
specific
package,
called
Sam
cons,
it's
gender
being
generated,
and
somebody
on
the
like
language.
They
could
have
to
go
and
update
this.
E
What
they
have
currently
to
this
new
version
of
using
this
automated
process
of
some
kind
of
generation,
at
least
in
Java
instrumentation
work
group.
This
PRS
are
hard
like
it's
difficult
to
review
them.
There
are
a
lot
of
changes.
It
affects
them,
20
different
instrumentations
right,
then
they
just
starting
to
produce
newspaper
and
it
like.
The
new
data
goes
to
the
backends
right
and
on
the
back
ends.
First,
the
backends
may
depend
on
this
current
conventions
right.
E
They
need
to
do
the
work
to
apply
this
mapping,
or
maybe
users
have
their
queries
ready
in
future
COC
agar.
They
just
get
this.
This
attributes
raw
and
nothing
processes
them
to
unify
The
Experience,
so
existing
user
queries
can
break,
and,
yes,
it's
all
experimental
everywhere.
We
know
that
it
can
break
it's
just
the
point
that
it
we
should
probably
care
about.
Instrumentation
seek
maintainers
that
have
to
support
this
stuff.
Oh
every
time
we
break
things
and
also
the
users,
and
the
backends
also
need
to
do
more
work
to
support
it.
B
B
Audience
or
something
maybe
even
to
the
to
the
spec
meeting
on
Tuesday,
because
because
like
what?
What
do
we
do
right
so
because
it
will
be
breaking
right
so
either
we
go
along
blob
of
PR
gigantic
PR
or
we
could
I
think.
B
We
also
discussed
this
that
we
keep
the
current
keys
and
I
know
somehow
mark
them
as
deprecated
and
the
new
ones,
and
then
at
least
people
have
time
to
move
on
to
the
new
thing:
I'm,
not
sure
how
how
much
that
is
better
because,
for
example,
backhand
them
has
to
support
these
two
for
for
some
time,
it's
cumbersome
as
well.
So,
but
that's
why
we
also
have
this
schema
right.
That
has
a
conversion,
conversions,.
E
E
Sorry,
yes,
it's
just
the
one
right
that
when
I
work
in
HTTP
changes
that
were
breaking
I
got
a
little
bit
of
pushback
on
this,
but
I
was
able
to
get
through,
but
I
had
to
explain
multiple
times
this
part
about
breaking
messaging
creates
less
mature
than
HTTP,
so
it
would
be
easier.
Just
the
question
is
once
we
can
do
it
maybe
twice,
but
if
it
will
happen
every
version,
it
will
be
difficult
to
explain
and
we'll
get
more
and
more
pushback.
B
What
about
this?
What
about,
if
we
put
all
the
attributes
that
we
have
in
the
Otep
in
the
yellow
file,
maybe
not
in
this
PR,
maybe
in
a
separate
one
just
so,
we
see
everything
I'm,
sorry
that
would
help.
They
can't
look,
for
example,
what
everything
that
will
will
be
part
of,
for
example,
the
changes
is
going
to
be
huge
or
not,
or
maybe
just
having
all
of
them
there.
B
So
we
can
at
least
because
of
not
sure
if
we
decide
on
all
of
them,
if
all
them
are
okay
at
this
point,
remember
that
that
beer,
something
that
I
put
your
IDs,
the
one
that
those
are
I
think
still
left,
but.
E
E
B
Right
and
then
after
this
is
merged
these
attributes,
then
it's
like
what
Amir
said
it
kind
of
unblocks
to
move
on,
for
example,
defining
the
the
clearly
defining
what
to
do
the
for
for
single
message.
If
we
have
a
link,
if
we
don't
have
a
link
and
so
on
and
then
later
on,.
E
I
guess,
without
glorifying
each
particular
attribute,
we
can
stack
out
the
link
Behavior
right.
B
Yeah
there's
just
this
attribute
that
we
discussed
about
the
battery
if
it's
batch
or
not
right,
I
think
this
is
also
something
that
will
be
bundle
here.
B
Yes,
thanks
for
coming
all
right,
then
I,
guess
if
you
need
anything,
help
on
on
doing
this
to
the
chat.
If
you
need
something
else,
just
reach
out
to
the
on
the
slack
and
then
we
can
plane
things
offline
and
and
continue
working
offline.