►
From YouTube: 2022-08-04 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
It's
failing
for
some
reason,
but
I'll
take
a
look
and
fix
that
cool
is
it.
It
looks
like
a
random
failure.
A
B
This
turned
out
nice.
We
got
a
lot
more
content,
length
coverage
and.
B
C
Is
connected
to
check
whether
the
header
is
being
sent
or
not,
and
if
the
header
is
being
sent
it
is.
It
means
that
we
cannot
change
the
continent,
and
in
that
case
we
will
not
inject.
We
will
only
inject
when
we
could
change
continuous
and
we
will
update
the
content
length
after
we
inject.
B
And
it
means
we
may
back
off
in
more
cases
of
injecting
the
snippet
if
the.
If
it's
been
flushed
already,
but
at
least
we
don't
break
the
app.
B
So
I
think
su
is
going
to
push
that
change
today
and
after
that
maybe
we'll
restrict
it
to
in
post
sue
you
because
they
yes.
C
I
guess
did
that
if
we
decide
to
restrict
together
post
because
the
the
coaching
you
will
be
easy,
if
we
make
that
decision.
D
D
C
I
guess
the
other
master
does
not
will
not
return
test.
Html
page.
D
D
A
B
D
B
D
B
So
see
you,
let's,
let's
leave
it,
as
is
then,
and
we
can
always
get
future
feedback
from
the
rum
sig.
B
So
after
this,
I
think
I'll
probably
be
mark
approving
it.
I've
reviewed
it
over
time
and
but
I
did
want
to
check
in
in
particular
around
the
because
it
is
it's.
It's
an
opt-in
feature
right,
but
it's
actually
a
vendor
opt-in,
feature
where
you
have
to.
C
B
B
B
So
I
guess
the
only
kind
of
one
question
is:
I
mean
it's
all
alpha
modules
anyway,
but
would
you
be
more
comfortable
if
this
was
like
experimental,
snippet
holder.
A
A
Well,
on
the
other
hand,
it
might
be
worth
it
to
mention
that
this
is.
This
enables
an
experimental
feature
just
in
the
java
document,
in
a
comment
somewhere.
B
Yeah,
I
think
I
might
lean
towards
renaming
it
just
because
we
know
it
is
extra
alpha,
like
really
use
at
your
own
risk.
At
this
point
until
we
get
some,
you
know,
but
that's
why
I
want
to
merge
it
so
that
we
can
expose
it
as
a
flag
in
our
experimental
in
our
distro
and
start
seeing
you
know
getting
some
real
user
feedback.
A
A
D
Oh
yeah,
I'm
I'm
normally
very
good
at,
like
you,
know,
greeting
new
people
and
being
welcoming
to
our
community.
So
if
you
haven't
been
on
this
call
before
welcome
and
feel
feel
free
to
jump
in
and
say,
hi
yeah
thanks.
This
is
my
first
time
checking
it
out.
I
just
started
doing
some
work
at
datadog
about
a
month
ago.
A
So
working
with
some
hotel
stuff.
E
B
Nice,
so
you
should
be
much
more
at
home
than
most
folks
in
this
repo.
You
know
this
repo
was
originally
now
like
a
couple
of
years.
Oh
not
a
couple
years.
Almost
three
years
ago,
forked
from
the
dd
trace
java.
A
Yeah,
that's
that's
what
I
was
told.
I
haven't.
A
I've
I've
been
there
just
over
a
month
now
so
still
kind
of
figuring
everything
out
welcome,
yeah,
thank
you
and
my
name
is
jerome
deck.
I'm
a
software
development
manager
at
aws.
I
think
you
folks
know
that
algolita
left
aws
for
apple
a
few
months
back,
and
so
I'm
I'm
transitioning.
A
I'm
also
interested,
obviously,
because
abs
is
a
big
java
shop
and
and
we
had
java
maintainer
that
left
the
project
as
well
so
early
involvement,
but
the
the
point
is
indeed
obviously
to
to
get
back
into
a
little
bit
more
java
expertise
here
in
the
open
telemetry
from
from
the
ibs
side
of
things.
B
E
Hello
yeah,
so
we
have
been
losing
some
maintainers
in
the
core
repository
and
we
talked
last
week
at
office
hours
about
potentially
doing
some
some
housekeeping
some
spring
cleaning
to
make
sure
that
you
know
the
the
core
open,
telemetry
java
repository
only
contained.
E
You
know
the
right:
the
right
set
of
artifacts
the
right
set
of
code
to
reduce
the
maintenance
burden
and
kind
of
shift
that
over
to
potentially
contrib
and
assign
individual
code
owners
when
possible
and
yeah.
So
I
I
scoured
the
repository
I
went
through
and
I
came
up
with
a
list
of
artifacts
that
I
thought
would
be
decent
candidates
to
potentially
move.
There's
there's
a
number
here,
so
I
don't
think
we
can
probably
cover
these
all
in
all
in
one
go.
E
It
might
be
good
to
have
some
asynchronous
conversation
about
this
in
the
issue.
If
folks
have
opinions-
but
you
know-
I
I
think
you
know
there's
some
general
questions
that
can
can
help
lead
the
conversation,
one
of
which
is
there's
there's
a
number
of
resource
detectors
in
the
core
repository
there's.
You
know
some
general
purpose
ones
for
detecting.
E
You
know
container
host
that
type
of
stuff
and
then
there's
another
artifact
that
contains
resource
detectors
for
aws
specific
entities,
and
you
know
it
doesn't
feel
like
the
aws.
Specific
entities
belongs
in
the
core
repository,
not
without
you
know,
representation
from
other
major
cloud
providers,
and
that
got
me
thinking.
Okay,
what
is
the
right
home
for
resource
detectors
in
general?
That
feels
like
an
instrumentation
concern.
Actually,
and
so
I
was
curious
on
whether
resource
detectors,
both
aws
and
the
core
ones
should
be
shifted
over
to
instrumentation.
B
Yeah,
no,
you
you
floored
me
that
makes
a
lot
of.
It's
makes
a
lot
of
sense.
The
resources
at
first.
I
was
like
what
move
resource
detectors,
but
it
really
does
feel
more
like
instrumenting,
because
you're
instrumenting,
the
sort
of
platform
you're
sitting
on.
E
A
So
since
you
mentioned
somatic
conventions,
what
about
open
telemetry
center
like
the
semantic
attributes
and
resource
attributes,
they
are
not
strictly
like
api
or
sdk
concern,
probably.
E
Yeah,
you
know
instrumentation
is
the
main
consumer
of
them.
Obviously,
you
know
we're
just
suggesting
the
rule
of
thumb
that
if
it
consumes
the
semantic
inventions,
then
maybe
it
doesn't
belong
in
in
the
core
repository
at
all,
so
exactly
that
that
kind
of
suggests
that
instrumentation
might
be
a
good
home
for
that
as
well.
E
Well,
what's
wrong
with
taking
a
dependency
on
in
the
instrumentation
repository.
E
Or
api:
that's
going
to
be
this
core
thing
that
we're
pushing
on
people
to
to
use,
and
so
I
think
folks
should
get
comfortable
with,
depending
on
on
artifacts
from
instrumentation.
A
E
I
don't
think
we
do
have
coherence
across
the
board
and
there's
a
there's
inconsistencies,
so
some
languages
don't
have
an
instrumentation
repository
at
all,
some
just
like
their
instrumentation
lives
in
contrib
and
that's
kind
of
the
de
facto
instrumentation
home
so
yeah.
I
think
I
think
the
project
as
a
whole
doesn't
have
consistency
about
this
type
of
thing.
A
Java's
kind
of
special
anyway,
because
we
have
three
or
at
least
three
repositories
like
api
sdk,
one,
the
instrumentation
and
the
contract,
one.
D
But
then
again
I
will
I
will.
I
know
trask
but
gonna
keep
beating
this
dead
horse,
because
the
repo
is
too
big.
B
D
E
B
D
A
All
share
like
the
base
gradle
configuration.
B
B
Yeah,
it's
definitely
something
to
think
if
there's
some
solution
in
intellij,
some
workaround
that
we
could
document,
because
I
know
that
the
instrumentation
repo
in
particular
requires
a
fairly
beefy
lat.
You
know
machine.
D
I
mean
you,
you
need
like
a
quantum
computer
or
something.
I
know
that
honorable
was
pretty
adept
at
like
having
like
there's
somewhere,
that
somehow
you
can
like
activate
and
deactivate
like
sets
of
modules,
and
he
was
getting
pretty
good
at
like
doing
that
and
he
was
advocating
for
that
a
couple
of
times,
but
I
never
got.
B
Let
me
make,
maybe
I
can
do
an
another
pass
at
this.
A
D
Well-
and
it
wouldn't
have
to
I
mean
we
did
also
talk
about
like
agent,
instrumentation
split
and
the
argument
against
that
is
well,
then
there's
almost
nothing
in
the
agent,
but
that's
kind
of
not
true,
like
there's
just
stuff
in
there,
but
the
instrumentation
is
clearly
the
bulk
of
the
problem
because
it
syncs
the
internet
but
yeah.
If
we
had
like
categories
of
instrumentation
that
could
be
further
subdivided
into
other
repos.
I
think
that
could
make
a
lot
of
sense
but
yeah.
B
Okay,
yeah
yeah
I'll,
take
a
look
at
the
dependencies
see
if
we
can
trim
those
back
again,
yeah,
I'm
not
sure
unless
we
come
up
with
a
way
to
only
load
and
intellij,
a
single
sub
module,
not
sure
moving
things.
D
Well,
maybe
trust-
maybe
we
have
an
interesting
opportunity
right
now
with
the
two
new
people
on
this
call
have
have
either
of
the
two
new
people
attempted
to
clone
the
java
instrumentation
repository
and
open
it
in
intellij
I've
not
yet.
Okay,.
B
Yeah,
let
us
know
your
experience
if
you
end
up
doing
that.
A
Yeah,
I
will
I'll
probably
play
around
with
it
over
the
next
week
or
so.
B
And
we
cannot
well
sue.
You
is
sue.
You
you
fairly
recently
have
used
have
done
that.
What
was
your
experience.
B
Oh
intellij
loading
the
whole
open,
telemetry
instrumentation
repository
into
intellij
and.
B
And
was
that
a
one-time
issue
or
like
when
you
initially
imported
it
or
have
there
been
continued
issues
beyond
that.
B
A
A
Yeah,
I
attempt
to
do
various
hacks
to
reduce,
like
scanning
synchronization,
all
the
spyware
that
I
got,
but
the
results
vary.
Okay,.
C
Oh
sorry,
I
just
thought
about
a
point
that
I
I
hope
to
mention
about
is
that
the
file
lens
the
file
name
layers,
it's
it's
kind
of
too
long
to
be
put
even
in
the
c
folder,
and
I
have
to
rename
the
project
folder
name
which
which
like
I,
which
I
think
may
could
be
improved.
C
B
Do
you
know,
if
do
you
remember
if
you
tried
that
enabling
long
paths,
long
paths,
I
think
we'd
have
to
do
that
in
the.
A
A
It
it
might
be
specific
to
like
my
machine
or
spline
machines,
more
general,
so
it
might
be
just
you
know
the
combination
of
macos
and
various
different
corporate,
spyware
software
and
that's
the
result.
B
I
do
know
that
I
definitely
disabling
the
virus
scanning
for
me
on
those
through
all
those
related
directories
helped
a
ton.
B
A
D
A
D
E
That's
right!
Well,
one
other
thing
I
wanted
to
talk
about
with
on
the
subject
of
moving
components
out
of
open
telemetry
java.
Is
you
know
some
of
these?
Some
of
these
components,
I
think,
are
decent
candidates
to
move
to
contrib,
but
instrumentation
has
dependencies
on
them
in
some
cases,
and
so
is
there.
This
is
something
that
we've
discussed
in
the
past.
Perhaps
we
should
get
a
bit
more
serious
about
it.
Is
there
a
path
for
instrumentation
to
begin
to
depend
on
contrib,
artifacts.
E
It's
the
so,
for
example,
the
the
aws
x-ray
propagator
open
telemetry
extension
aws.
So
you
know
honorable
actually
left
a
comment
about
this.
I
I
suggested
we
move
this
to
contrib
and
he
he
he
left
a
comment
that
said
that
this
that's
actually
probably
one
of
the
more
more
commonly
used
propagators
in
production.
E
And
yes,
so
it's
it's.
It's
probably
used
quite
a
lot,
but
you
know:
there's
a
there's
some
language
in
the
specification
that
is
pretty
unambiguous,
that
propagators
from
third-party
vendors
don't
belong
in
core
repositories,
and
so
you
know
where
do
we?
Where
do
we
put
a
propagator?
It
doesn't
seem
like
that's
instrumentation
per
se.
It
seems
like
that
makes
more
sense
in
the
contrib
or
in
some
third-party
repository,
and
so
presumably
we
bring
that
in
in
instrumentation
into
the
agent
so
that
you
can
use
that.
B
So
is
in
here
we
have
ot
trace,
which
is
this
one
in
the
specification.
B
E
And
yet
yeah,
that's
that's
like
you
know,
I
I
don't
know
if
I
have
a
fully
fledged
opinion
on
that,
but
it's
interesting
that
you
say
that,
because
there's
there's
an
issue
in
the
specification
about
that.
This
exact
thing
so
I'll
include
a
link
to
it
in
our
doc,
and
so
this
issue
asks
this
exact
question.
Should
third
party
propagators
like
this
aws
x-ray
one
be
hosted
in
open,
telemetry
projects?
E
And
you
know
the
the
consensus
of
the
conversation
seems
to
be
like
yes,
there
are,
there
are
only
a
few
propagators
and
there's
going
to
be
fewer
as
w3c
takes
off
and
begins
to.
You
know
take
over
more
and
you
know
so
that
that
seemed
to
be
the
consensus.
The
conversation
in
their
and
morgan,
you
know,
summarizes
the
discussion
and
the
specification
that
says
as
much,
but
then
the
conclusion
of
this.
E
A
E
So
that
issue
contains
the
text.
That's
like
positive
arguments
like
yes,
keep
the
propagators
in
the
repositories
and
then
on
the
issue
in
open
telemetry
java
to
move
stuff.
I
include
a
link
in
some
like
a
blurb
from
the
specification
that
says.
E
The
aws
x-ray
propagator
is,
you
know,
anurag
points
out
that
it's
probably
not
the
right
name
for
it.
It's
a
propagator
that
uses
amazon's
internal
trace,
propagation
format,
okay,
and
so
it's
not
necessarily
x-ray
specific.
It's
like
it's,
it's
amazon,
specific
and
you
know
the
x-ray
name
just
kind
of
stuck,
and
so
you
know
if
you,
if
you're
consuming
amazon
web
services-
and
you
know
you're
using
client
library
to
call
them,
you
need
to
propagate
trace
contacts
to
them
using
this
format.
So
it's
it's.
It's
pretty
common
to
use.
A
E
B
For
the
headers
that
go
from
service
to
service
that
pass
the
distributed,
trace
context
along
the
wire.
D
B
We
did,
but
we
moved
to
w3c.
D
D
D
A
D
A
D
E
Well,
if
you
scroll
down
in
this
conversation
here
trask,
you
know
you
can
see
the
text
from
the
spec.
I
think
like
we're
pretty
clearly
in
violation
of
it.
If
you
keep
scrolling,
I
left
a
comment
just
like
30
minutes
ago,
yeah,
so
propagators
vendor
specific
protocols
must
not
be
maintained
or
distributed,
and
so
I
don't
really
think
that
leaves
a
lot
of
wiggle
room.
We
either
change
the
spec
or
or
we
remove
it,.
A
E
Yeah
and
then
another
kind
of
you
know
this
isn't.
This
is
just
something
that
we
have
to
consider:
it's
a
stable
artifact.
So
we
have
to
continue
publishing
that
artifact
under
its
current,
coordinates
until
a
2.0.0
release,
and
so
even
if
we
move
it
to
contrib,
it's
going
to
continue
to
maintain
be
published
from
the
core
repository
with
deprecated
annotations
until
2.0.0.
B
Hey,
can
you
leave
leave
that
as
a
comment
here,
yeah.
B
And
jerome
may
is
this
something
that
you
or
somebody
from
aws
would
be
willing
to
drive
at
the
spec
level
of
trying
to,
because
I
mean
jack
is
absolutely
correct-
that
you
know
the
current
wording
in
the
spec
gives
very
little
wiggle
room,
but
based
on
some
you
know,
there
do
seem
to
be
some
good
reasons
to
potentially
change
that.
E
Yeah
and
just
to
further
that
a
bit
if
you
click
on
that
link
where
that
text
came
from
trask,
so
this
text
that
link-
you
know
right
above
that
there's
a
section
that
says
that
it's
a
list
of
additional
optional
propagators
that
may
be
included,
and
so
it
includes
the
ot
trace,
one
that
we
were
discussing,
and
so
that's
a
may
instead
of
like
a
must
where
b3
and
jager
and
w3c
are
musts,
and
so
like.
E
I
think,
a
change
to
the
spec
could
be
pretty
simple
and
just
you
know,
added
this
amazon
specific
trace
format
to
this
may
category.
Like
just
add
another
bullet
point
here,
I
think
it's
a
reasonable
thing
to
do
and
then
we
would
be
in
line
with
specification
and
everybody
is
happy.
B
If
we
did
end
up
moving
it
to
contrib,
one
simple
solution
for
the
java
agent
is
just
to
for
the
java
agent
to
depend
on
the
prior
release
from
contrib
I
mean,
given
that
x-ray
propagator
is
very
stable.
I
don't
see
it
really
changing
over
time.
E
B
No,
what
I
mean
is
the
the
agent
would
pull
in
if
the
agents
on
116
it
would
pull
in
the
116
release,
because
we
make
or
say
117
is
coming
up
next
week.
The
117
release
would
still
use
the
116
from
contrib
the
1016
x-ray
from
contrib.
E
B
E
E
Yeah
so
there's
there's
precedent
for
this
type
of
thing,
with
the
ot
trace
propagator
and
then
the
other
argument
that
I
think
folks
were
making
in
general
about
including
trace
propagators
and
in
core
repositories.
Is
that
there's
relatively
few
of
them?
And
so
it's
not
like,
like
a
number
that
will
continue
to
balloon
as
time
goes
on
it's
small
and
shrinking
over
time,
and
so
you
know,
we
won't
have
to
continuously
make
more
and
more
exceptions.
B
B
Yeah
and
just
definitely,
you
know,
feel
free
to
reach
out
to
chat
more
or
you
know
we
can
follow
up
next
week.
Also,
if
you
want
to,
if
you
have
anybody
else
who
is,
can
help
with
that
and
want
to
talk
through
clarifications.
E
B
Yeah,
I
would
start
with
an
issue
and
then,
if
the
issue
doesn't
get
traction
then
bring
it
up
in
the
tuesday
meeting
to
get
eyeballs
on
it.
B
All
right
anybody
want
to
sneak
any
more
topics
in.
A
A
E
Yeah,
I'm
waiting
for
an
approval
from
from
john
on
that,
I
think
yeah.
So
you
know
we
don't
have
this
documented
anywhere,
but
kind
of
the
way
that
I've
been
operating
for
api
changes
is
that
you
know
we
at
least
two
maintainers
approve
it
before
merging
it,
and
so
that's
unfortunate
that
we're
down
to
two,
and
so
it's
everyone,
but
I
think,
that's
probably
just
part
of
the
reality
of
the
situation
for
now.
E
A
Good
to
ping
him
yeah,
it
can
wait.
I
mean
I
would
like
to
have
it
included
in
the
next
release,
which
is
next
week,
but
yeah,
I'm
not
in
any
hurry.
I
mean
I
don't
need
it
for
tomorrow
or
day
after.
E
E
E
It's
not
completely
clear
what
the
rules
are
around
that,
but
I
guess
either
way.
I
still
need
like
john
to
approve
it.
B
Change
that
to
maybe
not
my
opinion
is
it's
all
exp
when
it's
all
experimental
you
get
to
it's
your
call,
you
get
to
do
what
you
want.
I
like
that.
E
So
maybe
I'll
ping
him
then,
because
that
would
be
like
a
nice
feature
to
include
in
117.,
we've
been
a
little
bit
light
on
the
pr's.
So.
E
I'll
I'll
I'll
I'll
push
john
first
in
the
eyes.
E
Oh
one,
quick
topic
trash,
I'm
sorry,
no
problem,
nothing
like
wait
until
the
last
second.
So
are
we
going
to
do
office
hours
tonight?
I
know
we
had
suggested
that
we're
going
to
cancel
that
now
that
honorary's
gone,
and
so
you
know
john
mentioned
that
he
would
try
to
attend
this
meeting
when
he
can,
and
we
might
just
cancel
that
going
forward.
Should
we
officially
take
that
off
the
calendar
doing
it
all
right.
A
Which
reminds
me
we
still
have
the
special
meetings
on
monday
or
tuesday
in
the
calendar.
B
B
Yeah
so
anurag
told
us
last
week
in
the
office
hours
and
this
week
in
the
special
topics
meetings
that
he,
those
were
his
last
meetings
so
so
yeah
we
lost
our
apac
representation.