►
From YouTube: 2023-02-14 meeting
Description
Instrumentation: Messaging
A
A
A
A
And
give
people
a
couple
more
minutes:
I
need
to
get
started,
Happy,
Valentine's,
Day
to
everyone.
Now
it's
important.
A
Okay,
I
think
we
can
go
ahead
and
get
started.
Let's
probably
Quorum
for
today
there's
some
just
quick
notes.
We
do
have
an
EU
meeting
tomorrow,
but
I
think
that's
going
to
be
canceled.
Some
of
those
Cisco
guys
are
going
through
a
rework,
so
it's
kind
of
unclear
what
their
involvement
will
be
going
forward.
So
tpd
on
that
and
I'll
try
and
provide
an
update
when
they,
when
they
know
more
as
well
so
for
the
first
issue,
Tyler
I
think
he
brought
this
up.
Is
there
any?
A
B
I'm
trying
to
remember
I,
don't
think
that
I
have
created
anything
specific
off.
The
top
of
my
head.
I
wanted
to
discuss
it
first,
because
there
was
argument
that
maybe
this
sig
shouldn't
be
responsible
for
it,
because
it's
technically
not
in
the
the
fast
spec
but
I
think
that
that
we
should
take
ownership
of
it
and
and
push
it
Forward
on
this
sig,
because
I
don't
think
there
is
a
a
generic
Cloud
Sig.
Is
there.
A
C
A
B
Sure
so
I
mean
Anthony
and
I
already
talked
about
it
the
other
day.
The
main
gist
is
that
in
the
fast
spec
there
is
expectation
that
the
sqs
and
SNS
Lambda
handlers
do
propagation
via
x-ray,
but
there
isn't
a
a
corresponding
there
isn't
a
corresponding
requirement
for
this
on
the
AWS
SDK
side
of
things.
So
right
now
the
the
Javas
SDK
has
sorry
the
Java
instrumentation
for
SDK.
B
Has
it
hard-coded
to
use
x-ray
propagation
when
making
calls
using
the
AWS
SDK
that
instrumentation
is
not
done
in
other
languages
like
node
or
python.
This
means
that
propagation,
when
going
through
things
like
sqs,
sorry
SNS
to
sqs
the
propagation
gets
broken
because
AWS
only
supports
propagating
x-ray
through
those
systems.
B
So
I
I
think
that
there's
instrumentation
that
needs
to
be
added
to
the
auto
instrumentation
for
node
and
python
to
support
hard-coding
x-ray
propagation
for
those
for
AWS
SDK.
A
C
I
think
that's
one
component
of
it.
One
component
of
it
is
standards
in
some
of
the
instrumentation
groups.
May
differ
from
this
like
in
go
contribute.
We
require
that
all
instrumentation
except
a
propagator,
and
that
it
used
the
global
if
it's
not
provided
by
the
user,
that's
an
expectation
that
all
of
our
instrumentation
has
and
breaking.
That
is
something
that
would
have
to
be
discussed
with
that
Sig
and
probably
driven
by
a
spec
requirements,
I
I
think
more
generally.
Yes,
this
is
something
that
probably
needs
a
resolution.
C
D
E
B
The
part
that's
in
the
spec
is
specific
to
the
the
sqs
and
SNS
handlers,
Lambda
handlers.
It
doesn't
address
anything
relating
to
the
AWS
SDK.
E
C
I
think
for
the
Lambda
use
case,
we've
already
got
all
the
configurable
context
extraction.
We
need
with
the
events
to
carrier
implementations.
So
if
someone
wants
to
extract
something
other
than
x-ray
from
an
event,
they
have
the
ability
to
do
so
for
the
outbound.
What
what
gets
injected
into
requests
made
by
the
X-ray
SDK
is
a
question
for
the
or
sorry
for
the
AWS.
Sdk
is
a
question
for
the
AWS
SDK
instrumentation,
which
is
you
know,
kind
of
the
fragmented
responsibility
of
all
of
the
groups
that
have
implementations
of
that
I.
C
B
D
C
F
How
do
is
it
any
different
between
the
synchronous
versus
like
the
ones
that
go
off
worker,
cues
and
whatnot?
As
far
as
our
specification
should
be
concerned,.
F
So
many
sense
because
you
have
like
the
event
pipe
right
that
goes
into
like,
if
you
like,
rolling
it
off
sqs
and
whatnot
versus,
like
the
immediately
invoked
function
for
a
function
as
a
service,
but
we're
just
talking
about
the
ones
that
are
event
driven
right
and
not
like
immediately
invoke
functions.
F
B
Okay,
I
will
see
if
I
can
get
the
attention
for
anyone
in
a
different
Sig
or
maybe
just
drive
this
directly
through
a
PR
or
something.
E
E
B
Mean
I
would
say,
go
forward
with
it,
because
Java
already
has
an
implemented.
That
way,
I
mean
we.
We
could
see
potentially
wait
until
the
spec
gets
merged
before
actually
merging
this
PR,
but
I
think
it's
valuable
work.
B
E
Yeah
tests
are
failing,
I
haven't
figured
that
out
yet,
but
it's
basically
done.
A
Okay,
cool
so
yeah
we
gotta
stock,
PR,
updated
for
that
and
and
start
that
conversation,
so
I
think
we
did
already
have
and
Tyler
someone
could
provide
the
link
for
the
merged
PR
that
was
was
done.
I
think
we
potentially
have
some
improvements
to
make
on
the
current
layers
to
make
them
align
with
any
Behavior
I'm,
not
sure
exactly
where
that
work
is
needed.
A
Up
yeah
I
appreciate
it.
We
also
have
Mike
Whalen
from
our
field
team
here
today.
He
has
a
wealth
of
experience
on
the
user
side
from
from
the
land
of
perspective
and
like
asynchronous
tracing.
So
at
some
point,
I
would
like
him
to
kind
of
share
his
perspective
and
feedback.
So
I
think
that
might
be
helpful
for
the
broader
Sig.
A
Welcome
to
the
fastest
we're
very
happy
to
have
you
here.
Don't
want
to
put
you
too
much
on
the
spot,
but
if
there's
like
a
couple
really
painful
points
around
Lam
does
which
I
know
there
are
I,
think
you
call
out
or
maybe
maybe
share
any
feedback.
I'd
be
appreciated.
We'd
love
to
hear
it.
G
Yeah
sure
so
I've
primarily
been
working
with
node
and
then
also
some
python
in
there
and
then
working
with
Tyler
now
in
the
on
the
Java
side
and
I
apologize.
G
If
some
of
this
is
repeated
information,
because
again,
they're
just
disjoining
here,
but
some
of
the
main
things
I've
seen
are
so
with
the
the
propagation
I
believe
we
were
just
talking
about,
was
in
regards
to
sqs
there's
a
couple
things
that
I've
seen
there:
it's
not
just
the
you
know
that
it
should
be
pulling
up
the
it
should
be
pulling
the
AWS
Trace
header
value
in
there,
but
I
also
see
that
the
instrumentation
and
I
haven't
I
haven't
dug
into
this
to
know.
It's
explicitly
why?
G
But
the
producer
that's
putting
in
context
in
there
is
writing
context
values
into
the
message
attributes
as
well.
As
the
you
know,
the
trace
headers
getting
written
into
the
attributes
section
and
those
don't
those
values
don't
always
match.
They
have
different
Trace
IDs.
Sometimes
they
have
the
same
Trace
IDs
with
different
parents.
G
I
haven't
dug
into
that.
Yet
that's
one
thing:
I'm,
seeing
there
with
API
Gateway,
so
I
know
that
that's
handled
but
the
disabled,
AWS
context
propagation
in
a
couple
different
areas.
So,
let's
see
I,
think
there's
a
spec.
There's
a
PR
out
there
to
be
able
to
control
this
via
an
environment
variable,
but
that
doesn't
work
or
the
environment.
G
Variable
I
think
we'll
solve
this,
but
the
the
node
Library
wouldn't
do
that
unless
you
had
your
own,
you
know
unless
you
told
it
to
reconfigure
the
the
AWS
Lambda
instrumentation,
the
python
Library
I
believe
Alex
Bowden
when
he
looked
into
it,
found
that
it
that
it
just
ignored
that
all
together
it
was
always
set
to
true
and
you
couldn't
you
couldn't
even
set
it
to
I'm.
Sorry,
it
was
already
set
to
false.
You
couldn't
have
said
to
true
I'm,
not
sure
if
that's
been
addressed
or
not
yet,
but
I
know.
G
That
was
one
thing
one
one
problem
I
was
facing
in
that
regard
and
let
me
see
what
was
the
I
just
had
one
yesterday.
Oh
one
of
the
things
I
did
want
to
point
out
too.
Actually,
no
I'm.
Sorry,
that's
an
internal
product
question!
Polite
step.
G
Sorry
I
wasn't
prepared
for
this.
That's
everything
that
comes
to
top
of
mind
right
now,
as
I
know,
there's
a
lot
of
different
things
here,
I've
been
having
the
internal,
so
my
role
here
is
a
solution.
G
Architect,
device
up,
I
work
with
our
customers,
I'm
helping
them
instrument,
their
Lambda
functions,
using
open,
telemetry
and
so
I
I'm
digging
into
this
and
reproducing
those
use
cases
testing
it
out
myself
running
my
own
playgrounds,
taking
the
feedback
from
the
customers,
I
really
that
to
our
internal
teams
here
to
Carter
and
Tyler,
and
some
of
the
others,
and
you
know
bridge
that
knowledge
of
me
out
in
the
field
with
those
that
are
working
more
closely
here
with
the
Sagan,
with
the
open,
Telemetry
community.
G
I've
documented
quite
a
bit
of
this
internally
but
I
know
because
of
these
efforts,
there's
a
lot
of
different
things
that
are
in
different
stages
of
of
being
either.
You
know
the
work's
already
out
there,
but
we're
waiting
on
to
be
merged
or
there's
pull
requests
already
out
there.
G
So
I
I
don't
know
exactly
where
everything
is
at
today,
but
those
are
the
those
are
a
few
of
the
main
things
that
I
as
as
of
this
morning,
still
exist
in
the
the
latest
versions
of
and
I'm
testing,
both
with
the
AWS
distribution
of
open,
Telemetry
layers,
as
well
as
just
the
open
Telemetry.
The
open,
telegraphy
Lambda
layers,
so
I've
done
with
both
and
I've
noticed
a
little
bit
of
differences,
it's
probably
to
be
expected
in
there.
But
there
are
slight
differences
between
those
two
as
well.
A
Yeah,
thanks
for
sharing
all
that
info,
Mike
and
sorry
for
kind
of
putting
you
on
the
spot
there
so
I
think
we
we
did
get
a
PR
merged
around
updating
the
land
of
Stack
to
remove
the
X-ray
environmental
propagation.
So
I
think
that
would
potentially
address
this
last
issue,
but
we
I
think
need
to
do
the
implementation
of
the
spec
change.
Is
that
correct,
Tyler.
B
Yeah,
so
Tristan
is
already
I.
Think
you've
already
got
a
PR
open
for
this
on
the
python
side,
right,
yep
and
I.
Think
Martin
was
going
to
do
it
on
the
node
side.
Yeah.
That's.
B
A
B
A
There
you
go
and
has
any
work
needed
in
the
net
layer.
I
know
that's
not
using
like
Auto
instrumentation
or
anything
like
that
so
unsure.
If
it
would
be
affected
here.
C
It's
not
using
automation,
but
it
should
still
have
a
wrapper
similar
to
go
and
I.
Think
both
of
those
will
need
adjustments.
Go
doesn't
do
that.
It
doesn't
have
the
behavior
that
the
other
implementations
did
in
the
first
place
yeah.
So
it's
just
simply
not
adding
the
link,
but
it
will
use
whatever
propagation
is
configured
so
adding
the
link
if
configured
would
be
the
the
change
needed
for
go.
A
Makes
sense
great
I
know
no
Python
and
node
are
the
priority.
Is
there
anyone
interested
in
picking
up
the
dotnet
and
go
changes?
It
seems,
like
the
other
three
are
accounted
for.
You
can
also
create
project
tracking
issues
if
needed.
D
E
I
can
probably
grad.
Go.Net
is
yeah,
probably
yeah.
A
Awesome,
okay,
I
think
we
can
move
on
so
the
next
one
is
around
kind
of
this
open,
spec
PR,
and
we
have
a
ton
of
comments
coming
in
and
I
think
this
is
kind
of
related
to
David's
question
around
resource
ID
or
fast
ID,
or
something
like
that.
So
I
don't
think
I'll
be
able
to
show
like
the
entire
thread,
but
please
open
it
up
on.
Like
you,
all's
personal
machines,
I'm
David.
A
H
Sure
I
think
I
would
summarize
it
as
fast.id
is
useful,
at
least
to
some
people
using
it.
H
It's
like
the
RN
on
AWS
or
the
gcp
resource,
URI
or
I
forget
what
it
is
on
Azure,
but
One
reviewer
in
particular
uses
it
a
lot
we
had
talked
to
potentially
at
the
last
sake,
meeting
about
moving
it
to
the
cloud
conventions
and
I
I
would
I
was
less
interested
in
starting
a
discussion
about
it
and
more
I
wonder
if
it's
actually
a
good
idea
for
us
to
split
the
fast.id
change
out
of
this
PR
or
include
the
new
Cloud
attribute
in
the
pr
as
a
way
to
move
it
forward.
A
D
H
H
B
H
Either
way
I'm
happy
with
with
either
of
those,
but
just
it
doesn't
seem
like
there's
any
contention
around
the
other
ones
and
I
I
do
actually
think
it
would
be
better
to
if,
if
we're
pretty
sure
we're
going
to
introduce
the
cloud
one
to
do
that
at
the
same
time
that
we
remove
the
fast
one.
A
Yeah,
it
sounds
sounds
like
a
great
idea,
David,
so
yeah
Tyler.
If
you
could
update
this
PR,
let's
just
open
a
separate
one
for
these
two
attributes,
and
then
we
can
update
the
cloud
ID
or
add
a
cloud
resource
ID
and
remove
the
fast
dot
ID
in
this
PR
and
at
least
like
make
that
change
to
say
we're
not
taking
something
away
from
you
necessarily
just
just
move
in
where
it's
coming
from,
but
yeah
David.
That's
an
excellent
idea.
A
I've
noticed
these
threads
have
gotten
seemed
like
it's
going
to
be
kind
of
a
Rat
Hole
to
a
degree.
D
A
So
at
some
point
we
do
any
Google
and
Azure
best
practices,
documentation
or
at
least
a
single
source
of
Truth
I.
Guess
we
need
those
for
lambdas
as
well,
but
yeah
I'm,
not
sure
David.
What
level
of
Interest
like
the
Google
team
has,
or
what
kind
of
timeline
you
all
potentially
have
in
mind?
Why
do
you
think
it'd
be
great
to
centralize
this
stuff
on
the
Octo
website?
What.
A
I'm
not
as
familiar
enough
with
Google
to
comment.
I
know,
for
example,
for
my
time
at
Microsoft,
Azure
functions
had
a
lot
of
kind
of
really
weird
behavior
and
also
a
kind
of
best
ways
to
set
up
the
instrumentation
to
actually
get
it
to
work.
So
it'd
be
something
along
those
lines.
You
know,
some
sort
of
examples
would
be
great
to
have
I,
think
and
just
giving
customers
like
a
really.
A
You
know
simple
way
to
to
get
onboarded
and
not
have
to
like,
maybe
go
around
and
try
and
find
what
it
is
exactly
and
it
could
even
just
be
a
link
to
the
public.
Sdk
is
insane.
This
is
how
we
recommend
you
know
you
recommend
we
use
those,
and
then
you
can
instrument
them
using
this
way,
or
here
are
some
bespoke
giggle
Behavior,
to
be
aware
of,
instead
of
something
like
that.
D
A
I
think
we'll
probably
have
to
produce
the
Lambda
docs
first,
but
we
can
do
that
as
part
of
I.
Guess
we
do
it
in
parallel.
We
should
probably
close
some
of
these
spec
PRS.
First
and.
A
Awesome
I
think
we
covered
most
of
our
agenda
topics
today,
but
we
have
a
pretty
good
audience.
So
are
there
any?
You
know
top
of
Mind
items
for
people
who
are
on
the
call
right
now.
A
Unfortunately,
no
I
keep
the
my
harassing
one
of
our
internal
Austin
Parker,
who
has
access
to
the
cncf
account
I,
keep
harassing
him
to
give
me
updates.
I
messaged
him.
Yesterday
nothing
responded
post
us
giving
the
cost
estimate
and
then
he
pinged
them
again
to
say:
hey.
Can
we
get
an
answer
here
so
still
in
progress?
I'm
still
amazing,
fairly
slowly,
but
trying
to
follow
up
on
it.
I
have
a
reminder.
It's
kind
of
ongoing
in
my
phone
just
to
get
this
closed.
A
C
A
Absolutely
so
we
already
have
one
spec
PR
open.
We
have
the
subsequent
one
that
will
be.
You
know,
segmented,
based
on
the
cloud
resource,
ID,
so
I
think
the
cloud
resource
ID
would
be
the
final
spec
PR
we're
trying
to
make,
and
we
could
even
you
know,
start
a
lot
of
our
work
without
that
PR
being
merged.
So
the
goal
was
to
have
all
spec
PRS
open
by
the
beginning
of
March
and
I.
A
Think
we're
we're
more
than
on
track
for
that
today
and
then
the
goal
is
to
have
the
reviews
done
by
the
end
of
March,
which
it
also
seems
like
we're
getting.
You
know
a
fairly
good
amount
of
Engagement,
and
things
like
that,
so
I
feel
fairly
good,
but
if
anyone
has
concerns
feel
free
to
voice
them
or
yeah,
whatever.
Okay.
B
So
this
is
I
think
where
you
know
in
terms
of
finalizing
the
the
spec
I
I
think
this
is
where
getting
Google
or
Azure
to
engage
in.
You
know
making
sure
that
the
the
semantic
conventions
that
were
just
going
forward
going
forward
with
will
work
also
for
those
platforms.
A
Yeah
I
think
we're
we're
seeing
a
good
amount
of
Engagement.
So,
of
course,
David.
Thank
you
for
being
here
and
participating
in
the
pr
Lou
Milla
is
commenting
on
the
the
fast
changes
as
well,
so
I
think
we
should
have
that
engagement
and,
of
course,
Anthony.
Thank
you
for
being
here
too
and
for
other
AWS
folks,
but
it
seems
like
we
have
that
level
of
Engagement
but
yeah
to
ensure
they
get
their
reviews
and
things
like
that.
I'll
kind
of
keep
poking
them
on
these
PRS.
D
A
Okay,
silence
is
golden
I'll.
Take
that
as
another
topics
I
will
see
y'all
next
week
or
on
the
slack
Channel
just.
A
Yes,
yeah
Carlos
I'll
need
your
help
on
that.
We
need
to
remove
the
EU
meeting
if
you
weren't
here
earlier,
some
of
the
EU
contributors
you're
going
through
our
rework
so
something
to
account
for
yeah.
A
Cisco
is
going
through
a
reorg
and
they're,
not
sure
if
they'll
they'll
still
be.
You
know,
Hotel
contributors.
Fats
will
be
a
priority,
all
that
good
stuff.
So
some
organizational
uncertainty.
A
It's
kind
of
permanent
going
forward.
We
may
do
the
Monday
instance.
If
they
come
back
to
us
and
say
we
will
continue
actively
working
on
this.
They
reached
out
to
Tyler
and
I
and
f
that
we
just
put
it
on
hold
for
now
until
until
they
follow
up
so
going
forward.
It's
intended
to
be
just
the
Tuesday
meeting.
That's
a
single
meeting
a
week.
It
may
may
switch
to
the
bi-weekly
rotation
for
Mondays
if
we
can
get
some
more
contributors
back,
but
TBD.