►
From YouTube: 2023-01-11 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
D
Okay
but
Carter
had
a
conflict
for
the
first
half
of
this
meeting.
This
will
be
without
him
for
that
give
her
a
couple
more
minutes
to
see
if
anybody
else
shows
up
and
then
we
can
kick
off.
D
A
D
If
there's
anything
you
want
to
discuss
today,
please
add
it
to
the
agenda
I.
Think
as
I
start,
we
should
probably
review
the
agenda
and
the
notes
from
yesterday's
meeting
yesterday
was
the
the
first
meeting
of
this
reconstituted
sig.
D
We
had
pretty
good
attendance
I
think
it
was
11
or
12
people.
There
started
off
by
discussing
the
process
that
Ted
Young
is
initiating
to
work
through
spec
changes,
significant
spec
changes
coming
from
interest
groups
like
this,
and
as
part
of
that.
D
Basically
we
talked
about
what
the
timeline
should
look
like,
so
the
timelines
we've
we've
settled
on
at
least
initially
are
we'll
have
six
weeks
for
this
group
to
figure
out
what
it
wants
to
change
and
to
propose
some
changes
to
the
spec
and
then
a
four
week
period
for
review
and
comments
and
revision
based
on
feedback
from
the
rest
of
the
community,
the
TC
spec
approvers
and
the
like,
and
then
two
weeks
for
getting
those
PR's
merged
after
the
comment
period
and
implementation
or
finalizing
implementation.
D
Hopefully,
implementation
would
have
been
ongoing
in
Prior
10
weeks,
but
finalizing
implementation
of
the
the
new
specifications.
The
project
tracking
issue
is
the
the
same.
That's
been
there.
I
hope
that
everybody
who
is
here
is
aware
of
that.
If
not
it's
in
the
notes,
then
we
moved
on.
D
We
talked
a
little
bit
about
the
the
slack
Channel
partner
is
going
to
try
to
see
if
he
can
get
control
of
the
hotel
land
reflectional
to
rename
it
or
at
least
archive
it,
and
leave
a
tombstone
pointing
at
the
hotel,
fast
Channel,
where
we
will
move
all
work
going
forward,
and
then
we
spent
a
fair
bit
of
time
talking
about
what
sort
of
things
we
want
to
include
in
that
six
week
specification
period,
what
sort
of
things
we
want
to
discuss
and
come
up
with
the
specification
for
as
well
as
talking
about
a
bit
of
what
are
some
of
the
customer
pains
that
we're
seeing
and
things.
D
So
I
think
it
would
be
good
now
for
everyone
to
to
take
a
moment
to
review
the
the
notes
regarding
those
two
things
and
then
I
think
we
can
take
a
little
bit
of
time
to
discuss.
If
there's
anything
we
want
to
add
to
that
or
if
we
want
to
provide
any
additional
clarification
on
any
of
those
items
Tyler
you
were
there
yesterday
is
there
anything
else
that
you
want
to
add
from
the
discussion.
C
I
think
that
was
a
pretty
good
summary
I.
If
we've
got
a
lot
of
extra
time,
I
thought
maybe
we
could
use
it
to
discuss
some
of
the
the
details
that
we
had,
specifically
maybe
the
environment
variable
propagation
question,
but
we
can
save
that
until
the
end.
C
A
I
wanted
to
discuss
I
I,
just
added
to
the
agenda
for
today
regarding
serverless
or
Lambda
demo.
A
D
A
D
I
think
that
maybe
an
area
where
we'll
want
to
try
to
collaborate
with
the
community
demo
group
and
see,
perhaps
we
wouldn't
want
to
make
it
a
required
part
of
that
Community
demo,
but
being
able
to
integrate
with
it
I
think,
would
be
beneficial.
D
A
And
do
you
think
it
can
be
helpful
for
this
walking
group
as
well,
or
should
it
be
like
something
that's
not
related
to
the
working
group.
D
I
think
that
it
would
almost
certainly
be
helpful
in
been
trying
to
build
out
instrumentation
for
Lambda
to
have
something
to
instrument
in
the
in
the
existing
repo.
There
are
very
basic
sample
applications
that
you
know,
make
an
HTTP
request
or
list
them
as
three
buckets.
Something
like
that,
but
don't
really
do
much
of
anything
if
we
have
a
concept
for
a
somewhat
larger,
more
complete
example
of
multi-system
interaction.
A
A
So
how
do
you
propose
we
promote
this
with.
B
D
I
would
say,
probably
open
an
issue
in
the
community
repo
and
reach
out
to
the
folks
on
the
community
demo
seg
and
let
them
know
of
it
describe
what
you
want
to
do.
What
you
intend
to
do
and
seek
participation
there.
Okay,
we
can.
We
can
advertise
that
in
the
the
hotel,
fast
Channel,
as
well
as
the
the
next
meeting
for
North
America
folks
and
try
to
get
some
interest
there.
D
To
those
who
have
joined
since
we
started,
if
you
could,
please
note
your
name
in
the
attendees
list
on
the
the
doc,
and
if
you
have
anything
you
want
to
add
to
the
agenda
to
discuss,
please
do
so
I
think
if
we
could
take
a
moment
and
review
the
the
general
scope
that
was
discussed
in
the
meeting
yesterday
and
see
if
there's
an
agreement
here
with
that
scope
or
if
there's
anything
that
this
group
thinks
was
was
missed
and
needs
to
be.
D
Added
specifically
that
bullet
under
speakers
has
been
the
general
function
requirements
are
there.
Are
there
any
other
things
that
this
group
feels
needs
to
be
addressed
during
the
the
move
to
to
improve
the
spec
around
function
as
a
service
invocation
and
instrumentation.
D
A
So
I
said
there
is
a
section
regarding
the
current
status
of
the
Lambda
layer,
instrumentations
in
different
languages.
Right.
D
Yes,
so
we
need
to
get
an
assessment
of
where
we're
at
what
functionality
the
instrumentation
has
in
each
language
kind
of
create
a
matrix,
decide
what
needs
to
be
included
in
all
languages
and
where
okay
variation
is,
is
acceptable
and
then
try
to
come
up
with
some
sort
of
standardization.
For
that
instrumentation.
A
Okay,
great
so
who,
who
is
currently
working
on
that
and
and
just
wondering
how
or
where
it
will
be.
This
data
will
be
presented
in.
D
D
So
I
think
Tyler.
You
wanted
to
discuss
the
issue
that
you've
created
regarding
extraction
of
context,
information
from
environment
variables.
C
Yes,
sorry
I
just
wanted
to
make
sure
I
was
unmuted.
So
let
me
share
my
screen
seconds.
C
So
it
looks
like
Josh
commented
on
on
here
at
the
end,
but
I
I
think
the.
C
So,
for
the
those
that
aren't
familiar,
what
we're
talking
about
here
is
specifically
in
the
spec
the
current
definition.
The
current
requirement
is
to
prioritize
the
environment
variable
first
for
x-ray,
before
applying
other
propagation
methods,
and
so
I
wrote
this
issue
and
we
were
trying
to
come
up
with
other
options
for
how
to
resolve
this.
C
So
Anthony
and
I
kind
of
went
back
and
forth
a
little
bit
I'm,
not
quite
clear
on
where
we
left
it,
though
Anthony.
What?
What
do
you
think?
What
do
you
think
is
the
current
best
option
for
us
to
consider
going
forward.
D
D
Please
also
go
get
this
environment
variable
and
insert
it
here
as
an
entry
in
that
carrier,
and
then
the
existing
SDK
mechanisms
for
specifying
propagators
and
Order
of
processing
composite
propagators
can
take
over
from
there
and
if
a
propagator
that
can
deal
with
the
Amazon,
Trace
ID
field
and
format
is
present
in
the
propagator.
That's
used
that
will
be
extracted
if
it
isn't,
it
won't.
C
C
So
the
area
where
I
think
that
that's
a
potential
issue
is
cases
like,
for
example,
Auto
instrumentation,
where
the
the
user
isn't
really
able
to
or
expecting
to
provide
any
code
for
setting
in
the
for
for
operating
instrumentation.
C
So
like,
for
example,
in
the
the
Java
agent,
the
only
way
to
really
configure
that
is
primarily
with
system
properties
or
environment
variables.
C
And
that's
what
most
users
do?
There
are
some
kind
of
advanced
methods
for
extending
it
that
allow
for
adding
code,
but
that's
by
no
means
common.
C
Yes,
well,
I
was
under
the
impression
that
the.
C
So
that
propagation
setting
is
kind
of
encapsulated
in
the
in
the
Tracer
a
lot
so
that
that
setting
isn't
necessarily
exposed
to
the
instrumentation
of
which
propagator
to
use.
D
It
is
through
the
global
propagators
right
so
when,
when
you
set
those
environment
variables,
the
auto
instrumentation
bootstrapping
will
set
a
global
propagator
that
is
configured
based
on
that
environment.
Variable
that
you've
set
telling
it
which
propagators
to
use
and
then
instrumentation,
if
not
explicitly,
provided
a
propagator,
will
use
the
global
propagators.
D
I
think
for
the
the
Lambda
events
to
propagation
carrier,
part
of
that
the
same
sort
of
thing
can
be
done,
I
believe
it's
already
done
in
Java,
Auto
instrumentation
and
the
Java
Lambda
layer
to
set
what
sort
of
event
is
expected,
whether
it's
you
know
an
API
Gateway
event
or
an
sqs
event
which
tells
these
rotation
how
to
process
the
The
Blob
of
data
that
Lambda
hands
it
as
an
event,
but
I
think
that's
same
sort
of
mechanism
could
be
applied
there
as
well.
C
Right,
okay,
so,
but
the
problem
I
have,
though,
is
so
say:
the
user
specifies
the
following:
propagators
of
you
know
the
the
w3c
propagation
and
then
x-ray
right.
C
So
then
the
instrumentation
passes
the
the
the
context
of
the
event
to
the
propagator
and
says:
okay,
get
me
the
the
context
where,
in
that
series
of
events,
does
the
instrumentation
have
the
ability
to
insert
itself
and
say?
Okay,
if
there's
not
a
w3c
context,
now
we
need
to
check
the
environment
variable
first
before
we
go
on
to
the
the
regular
exercise.
D
It
doesn't
what
it
does
is
it
injects
the
environment
variable
into
the
carrier,
that's
handed
to
the
propagator
and
the
propagator.
If
it's
a
composite
propagator
that
has
w3c
and
x-ray
configured
in
it
will
evaluate
in
order
w3c
in
that
X-ray
and
if
it
matches
a
W3
or
it's
able
to
extract
a
context
using
the
w3c
propagator,
then
that's
the
context
that
it
uses.
C
So
what
you're
saying
is
in
the
in
the
context?
Sorry,
not
the
context
in
the
the
carrier.
The
carrier
is
the
one
that's
responsible
for
effectively
collecting
that
environment
variable
or
the
carrier
has
that
environment
variable
in
it,
so
the
instrumentation
would
then,
in
effect
before
it
passes.
The
carrier
along
to
the
propagator
would
collect
the
environment
variable
and
put
it
in
there
and
then
pass
that
along.
D
C
Okay,
so,
but
then
the
the
responsibility
for
determining
if
the
x-ray
propagation
from
the
environment
variable
or
from
the
the
original
carrier
is
put
on
the
instrumentation.
D
C
Okay,
so
part
of
the
the
current
spec
says
that
if
the
environment
variable
is
not
propagating
or
it
doesn't
have
an
actual
contact
x-ray
contact
set-
oh
sorry,
x-ray
propagation
set,
then
it
falls
back
to
using
the
the
X-ray
header
from
the
the
event
correct
correct.
So
if
we
just
like.
C
C
I'm
sorry
overwriting
the
propagation
from
the
event,
so
you
effect
have
to
check
that
logic
to
determine
which
which
of
the
X-ray
headers
to
use
has
to
be
put
in
to
the
instrumentation
correct.
D
It
would
have
to
be
put
into
whatever
is
composing
that
carrier
to
be
used,
which
would
likely
be
a
function
of
the
instrumentation
I.
Think
that
if,
if
that
is,
if
that
is
a
concern,
we
can
specify
in
the
specification
of
that
functionality,
though,
that
you
look
to
see
in
the
carrier.
Does
this
field
already
exist?
D
If
so
inject
leave
it,
if
not
inject
it,
but
then
that
gets
to
the
question
of
should
the
context
that
is
in
the
environment
take
precedence
over
a
context
that
is
in
an
event
regardless,
whether
that
is
valid
or
not.
C
I,
don't
understand
what
the
the
motivation
for
that
is
and
I
I
don't
know
why
the
spec
was
written.
The
way
it
was
so
I'm
just
kind
of
taking
it
as
gospel
that
that's
the
way
it
needs
to
be
and
trying
to
figure
out
how
to
to
work
around
it.
D
Yeah
and
I
don't
know
that
we
need
to
take
that
as
gospel,
though
I
really
had
hoped
that
two
members
from
the
the
Lambda
service
team
would
be
able
to
join
us
today
and
hopefully
be
able
to
discuss
that
somewhat,
because
I
think
they
probably
have
a
better
understanding
of
why
some
of
those
decisions
may
have
been
made
or
what
they're
trying
to
accomplish.
By
doing
that,.
C
Yeah
so
anyway,
going
back
to
what
I
was
going
to
say
about
that,
the
the
main
con
so
I,
don't
generally
have
an
issue
with
that.
The
main
issue
I
do
have
with
it
is
in
cases
where
x-ray
propagation
is
is
not
going
to
be
used
or
is
just
not
even
configured.
That's
creating
additional
work
for
the
instrumentation.
That
is
just
going
to
be
ignored.
C
B
C
Don't
have
a
problem
with
that
part,
but
if
there's
additional
logic
about
evaluating,
if
the
header
is
valid
and
if
it's
sampling
Parts.
D
None
of
that,
none
of
that
should
be
done.
The
the
event
to
carry
your
implementation.
If
it's
going
to
inject
the
environment,
variable
should
at
most
I
think
be
if
it's
present
don't
inject
it.
If
it
is
it's
due
because
if
if
there
is
an
x-ray
header
in
the
events
that
has
been
extracted
that
may
take
precedence,
it
should
just
be
a
question,
though,
of
does
the
event
take
precedence
or
does
the
environment
take
precedence?
D
C
Okay
and
I
don't
have
a
problem
with
that,
but
the
spec
currently
states
that
it
has
to
check
to
see
if
the
environment
variable
is
valid,
if
so,
use
that
first
otherwise
fall
back
to
the
the
other
propagation
mechanisms.
D
Yeah
I
have
no
concern
about
changing
the
spec
okay,
I
I.
Think
I
would
like
to
understand
why
it
was
like
that,
but
if
we
can't
get
an
understanding
of
why
it
was
made
that
way
and
if
all
of
us,
after
discussing
the
the
options
that
are
before
us,
think
that
a
different
approach
is
best
great,
let's
change
it.
This
is
not
written
Stone.
C
C
Sounds
good
to
me:
I
think
that
that
resolves
the
the
main
concern
I
had.
B
D
Okay:
well,
if
there
is
nothing
I,
don't
think
we
need
to
keep
people
around
just
to
enjoy
each
other's
company,
give
one
less
chance
for
anybody
to
speak
up
with
anything
they
want
to
talk
about.
Otherwise,
I
think
we
can
break
and
take
27
minutes
of
our
day
back.