►
From YouTube: 2022-08-25 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
C
B
A
A
Start
here
so
jack,
this
was
kind
of
what
I
was
trying
to
get
at
in
that
slack
comment,
but
clearly
didn't
explain.
Well,
so
what
well-
and
also
I
don't
think
I
understood
what
the
user
was
asking
about
anyway.
But
so,
let's
just
call
this
a
related
issue.
We
have
the
temporary
metrics
view
in
the
instrumentation,
which
is
basically
right.
A
We
have
a
single
api
for
spans
and
metrics
sort
of
where
we
pass
all
the
span
attributes
into
the
metric
builder,
and
then
we
apply
our
temporary
metrics
view
to
basically
filter
out
which
of
those
span
attributes
we
want
to
stamp
on
to
the
metrics
and
so
wondering
I
know
I
think
our
hope
was
that
long
term.
We
could
use
real
metrics
views
for
that
and
which
would
maybe
allow
users
say
a
user
wanted.
A
C
So,
if
you
want
to
include
all
of
those
attributes
today
and
then
filter
down
to
a
narrower
set
based
on
what
the
user
needs
today,
you
would
have
to
like
you'd,
have
to
include
all
the
attributes
by
default
and
you
and
every
user
that
uses
the
agent
that
wants
the
default
set
would
have
to
like
manually
configure
the
views
to
define
the
narrower
set,
and
so
I
think
it's
like
a
bad
experience
for
users,
because
they
would
basically
all
have
to
do
this
manual
configuration
to
their
views
to
get
the
more
limited
set.
C
So
that's
that's
kind
of
I
think
part
of
the
thinking
behind
what
has
been
called
like
the
hint
api
that
doesn't
exist.
You
know
the
hint
api
is
many
things
and
maybe
that's
something
that
is
is
proposed
as
part
of
its
scope.
It's
many
things,
but
it's
nothing
today.
E
And
there
are
so
library
instrumentations
and
even
if
we
did
provide
like
a
default
matrix
view
in
the
agent
library,
instrumentation
users
would
still
get
all
the
attributes,
both
the
high
and
low
cardinality
ones.
So
the
hand
api
is
probably
a
must
team.
C
There
there
might
be
some
some
interesting
mechanism
to
do
this,
where
you
know.
Maybe
we
have
an
spi
for
view
configuration
and
maybe
the
java
agent,
you
know,
registers
and
as
an
spi
that
is
enabled
by
default,
and
this
spi
says:
hey
all
http
server
duration
metrics
have
this
default
set
of
attributes
that
they
retain,
and
so
that's
enabled
by
default,
but
maybe
a
user
could
opt
out
of
that
and
redefine
their
own.
A
A
E
A
Get
gets
very
hacky,
so
it
sounds
like
the
way
forward
is
the
hint
api?
Is
there
any
spec
issue
open
jack
that
you
know
of
that's
sort
of
talking
about
this.
C
C
C
It,
but
you
know,
I
guess
one
more
comment
on
this.
This
issue
in
general
is
that
I
think
the
temporary
metrics
view
is
defining
the
wrong
attributes
for
now,
like
the
attributes
that
it
defines
are
not
the
ones
that
are
current
and
the
spec,
and
I
think
you
mentioned
that.
There's
a
reason
behind
that
and
I
think
it's
a
good
one,
but
I
forget.
E
What
do
you
mean
by
wrong
attributes?
Okay,
I
think
I
understand
yeah.
B
A
C
E
B
A
This
was
well
from
josh
sarath,
I
feel
like
we
had
discussed
this
with
him
yeah
and
he
was
in
favor
of
this
proposal.
A
So
that's
the
reason
why
we,
the
discrepancy,
so
I
can
try
to
push
forward
with
this
change
to
get
us
out
of
non-compliance.
C
Is
does
ludmilla's
pr
that
got
merged
to
clarify
the
http
attributes?
Does
that
change
move
the
needle
on
this
at
all?
I
don't.
A
Think
so
because
it's
not
changing
the
definition
of
http
target
or
http
route,
I
believe.
A
Oh
sorry,
so
it
doesn't
move
the
needle
on
http
route,
but
it
may
move
the
needle
on
the
this
part.
I'll
have
to
think
about.
E
I
mean
definitely
because
http
host
and
http
server
name
were
removed
so
like
at
least
half
of
these
sets-
and
this
issue
attribute
sets
are
out.
A
E
Oh
and
I
found
the
in
the
hind
api
full
request,
it
turns
out
it
wasn't
an
issue.
There
was
a
pull
request
which,
but
there
was
a
lot
of
discussion
there,
but
it
was
closed.
Unfortunately,.
A
The
biggie
do
we
have
jonathan.
Yes,
we
have
jonathan
hello,
jonathan.
B
A
We've
we've
got
some
good,
we
talked
about
this
last
week
and
I
think
we've
had
some
good
async
discussion
since
then.
So
I
think
that
we're.
A
Landing
on
this
proposal,
which
would
be
to
start
publishing
so
kind
of
using
this
serious
heuristic,
which
is
not
the
most
awesome
thing,
but
I
it's
just
not
clear
to
me-
we'll
come
up
with
anything
better,
so
I
think
it's
good
in
that
sense
that
for
the
core
and
instrumentation
repos
the
criteria
for
inclusion,
there
would
be
well.
I
guess,
for
core
repo,
it's
more
clear.
It's
it's
whether
it's
a
spec
non,
a
spec
component,
that's
not
related
to
semantic
conventions.
C
And-
and
I
guess
the
one
outstanding
question
on
the
core
repo
is
whether
the
shims
are
involved
there,
the
spec
shims,
whether
those
are
included
there,
because
we've
discussed
moving
them,
and
I
haven't
quite
fully
formed
an
opinion
on
that.
I
could
go
either
way
at
that
point.
Whether
spect
shims
belong
in
the
court
repo
or
not.
C
B
A
B
D
D
Just
because
they're
supposed
to
be
a
core
part
of
this
project
was
the
proposal
to
move
them
to
instrumentation,
because
that
feels
even
weirder.
E
C
So
I'm
not
opposed
to
that,
but
I
think
the
reason
just
for
some
context.
The
reason
why
we're
proposing
moving
them
to
either
contrib
or
instrumentation
was
because
there's
other
shim
like
things
that
are
arising,
that
aren't
spec'd,
and
so
you
know,
there's
an
argument
for
consistency
in
terms
of
where
all
shims
live.
But
you
know
that's
just
one
data
point.
D
I
don't
think
we
would
consider
that
to
be
the
case
for
micrometer
okay,
so
it
does
feel
like
there
is
a
difference
there
between
those
two
shims
and
that
oc
and
ot.
They
really
like
that.
That
should
be
a
temporary
measure
for
people
while
they
convert
their
stuff
over
to
use
a
open
toronto
tree.
I
think.
D
What
about
the
the
semantic
convention
module
itself.
E
D
I
think
they
we
can't
move
that,
though,
because
the
core
repo
depends
on
it
like
we
actually
have
instrumentation
of
our
own
stuff
in
the
core
repo,
and
I
don't
think
we'd
want
to
depend
on
the
instrumentation
repo
in
order
to
have
our
core
components.
I
mean
that
would
end
up
with
a
circular
reference,
so
I
think
semantic
dimensions
have
to
be
in
the
core
repo
because
we
use
them
ourselves.
D
E
A
D
D
F
Yeah,
so
that
one
that
you're
clicking
on
I
flung
into
contrib
and
created
a
new
module
and
contrib
for
it,
because
I
didn't
know
where
else.
To
put
it
so
I
mean
it,
the
location
is
a
little
bit
squishy,
because
things
are
in
flux
and
I'm
perfectly
happy
to
move
this
somewhere
else.
F
But
the
idea
is,
we
want
to
be
able
to
make
it
easier
for
people
to
spin
up
an
agent
without
having
to
specify
environment,
variable
or
system
properties
for
things
like
service
name.
So
if
they
can
be
gleaned
from
the
runtime
which,
if
it's
spring
boot,
for
example,
there's
a
dozen
different
places
that
you
can
go.
Look
for
these
things
and
sort
of
get
the
application
name
and
in
the
event
that
they
haven't
specified
a
service
name.
We
can
spackle
that
application
name
into
the
service
name
in
the.
F
So
I
think
this
one
has
had
no
eyes
on
it
yet,
which
is
not
super
surprising,
given
that
it's
in
a
new,
a
new
module
and
can
trip-
and
people
probably
are
not.
You
know,
scrutinizing
config
that
much
so
be
cool
to
get
eyes
on
this
again,
with
the
full
understanding
that
we
may
be
moving
it
yeah.
Those
are
the
places
that
it
currently.
C
Checks
so
let's
talk
about
the
correct
home
for
recess
resource
providers
in
general,
so
you
know,
I
don't
think
they
belong
in
the
core
repo
and
so
at
least
two
spots
can
and
instrumentation.
C
The
advantage
of
including
them
in
contrib
is
always
that
you
can
get
assigned
like
outside
users
as
code
owners.
So
you
can
encourage
contribution
from
the
people
that
are
experts
in
that.
But
the
advantage
of
instrumentation
is
it
can
be
easy.
They
can
be
easily
included
in
the
agent
distribution,
and
so
you
know
lots
of
folks
can
take
advantage
of
them
without
having
to
package
up
their
own
agent.
A
So
do
you
think
this
my
thought
was
this
could
mitigate
that
if
we
publish
a
kind
of
like
the
collector
publishes
a
collector
and
then
a
collector
contrib.
C
E
C
That's
a
pretty
good
argument
that
instrumentation
should
only
contain
spect
resource
providers.
C
E
Yeah
I
took
a
look
at
that
pws
one
and
well,
it
might
be
spec,
but
the
implementation
of
it
is
highly
obvious
to
me,
and
I
think
that
probably,
if
you
don't
have
some
amount
of
internal
knowledge
about
aws,
you
probably
won't
understand
if
how
to
fix
it
or
how
to
change
something.
There.
G
G
C
Yeah,
so
I
mean
I'm
by
vendor
agnostic
in
this.
In
this
context
I
mean,
like
the
resources
themselves:
don't
pertain
to
vendored
things
like
we're,
not
talking
about
aws
elastic
bean
stock
or
aws
ec2.
We're
talking
about,
like
you
know,
generic
things
like
service
name
host
id
things
that
transcend
any
vendors.
B
B
C
Well,
we
recently
added
an
ordered
element
to
resource
provider,
so
there's
a
there's,
a
prioritization
and.
F
C
But
you
know,
jason
also
did
just
recently
propose
an
extension
to
the
resource
provider
interface
that
allows
the
resource
provider
to
conditionally
apply
itself,
and
so
it
can
take
into
into
consideration
other
contexts.
I
think
you
made
config
properties
accessible,
but
maybe
the
existing
resource
is
also
accessible
too.
I'm
not
sure
exactly
yeah.
F
Because
the
resources
yeah
the
resources
built
up
sort
of
incrementally
with
a
series
of
merges
and
so
that
that
state
of
the
resource
as
it's
being
built,
is
passed
into
that
should
apply.
It's
that
second
link
for
that
47-18
yeah.
F
Yep
I
mean
yeah
go
ahead,
I
mean
pretty
small,
pretty
small
change
but,
like
maybe
I
mean
a
reasonably
important
impact
in
in
the
development
of
future
resource
detectors,
but
delores
thing
I
mean
what
that
allows
you
to
do
is
to
to
say
nope.
Somebody
already
said
the
resource
name,
I'm
not
going
to
do
that.
F
E
Yeah
and
I'm
not
sure
if
the
ordering
solves
the
problem
completely
here,
because
why
yeah
why
we
will
probably
provide
some
some
of
the
roderig
and
say
that
I
know
this
spring
boot
service
name
runs
after
all,
the
built-in
or
default
resource
providers.
E
F
It
does
bring
up
this
interesting
concept,
though,
of
when
that
given
given
this
like,
assuming
that
we
went
with
this
when,
if
you're
building
this
this
new
functionality,
when
do
you
decide
to
make
it
a
resource,
detector,
a
resource
provider?
And
when
do
you
decide
to
build
it
as
a
customizer
right
because,
like
in
our
distribution,
we
also
have
a
customizer,
then
that
runs
after
everything.
E
I
think
the
difference
here
is
that
the
customizer
runs
after
the
entire
resource
is
built,
including
the
environment,
the
resources
that
you've
used
past
from
the
environment
and
the
resource
providers.
They
all
run
before
that.
C
F
C
F
B
D
C
So
I
think
we
should
think
about
this.
You
know
one
design
principle
I
think
we
should
adhere
to.
Is
there
there
shouldn't
be
many
ways
to
accomplish
the
same
thing.
If
there's
a
specific
use
case,
we
want
to
support.
We
should
have
a
a
specific
way
that
we
recommend
due
date,
users
accomplish
that
and
so
like
whatever
the
use
cases
we're
trying
to
accomplish
with
this
with
this,
you
know
this
new
concept
that
jason
should
apply.
Let's
just
see,
if
there's
we
can
accommodate
that
with
existing
tools.
First,.
A
So
back
to
where
these
things
should
live
so
vendor.
A
Agnostic-
I
just
keep
coming
back
to
sort
of
this,
but
I
feel
like
every
time
we
try
to
say
like
try
to
narrow
down
what
it
is.
We
come
up
with
exceptions.
A
I
don't
know
I
haven't,
looked
it
through
so
well,
okay,
so,
like
the
spring
boot,
this
seems
like
a
pretty
useful
thing
to,
for
I
mean
spring
users
are
a
big
part
of
our
user
base.
Java
agent
user
base
seems,
and
also
for
the
we
have
the
whole
spring
boot
starter
like
this
seems
like
it
would
be
perfect
in
the
spring
boot
starter,
which
we
have
in
the
instrumentation
repo.
C
A
Like
an
aws,
one
would
specifically
be
put
in
contrib.
C
Yeah-
and
you
know,
I
feel
I
feel
a
little
bit
better
about
that
approach
now
that
mateusz
has
mentioned
that
you
can
just
include
those
resource
detectors
as
command
line
arguments,
and
so
they
don't
need
to
be
packaged
up
with
the
agent
for
them
to
be
easy
to
use
for
customers.
F
F
F
Yeah
yeah
for
sure
I
didn't
I
didn't
make
that
connection,
so
it
wouldn't
be
its
own
thing.
It
would
still
be
part
of
one
of
the
spring
library
instrumentations.
F
There's
nothing
transitively
risky
about
that
approach.
F
G
C
I
think
I
think
they're
all
enabled
by
default
and
there's
a
system
property
where
you
can
disable
resource
providers
by
including
their
fully
qualified
class
name.
G
G
A
C
A
Okay,
that
makes
sense
so
then
we
will
go
through
and
move
the
resource
detectors
out
of
core
and
either
and
make
up,
maybe
just
make
a
proposed
list
of
where
each
one
is
going
to
go.
A
A
I
kind
of
like
this,
I
kind
of
like
this
idea.
I
would
be
willing
to
try
that
out.
If
people
want
it,
it
would
allow
we
could
start
moving
some
of
the
lesser
like
the
the
rocket
mq
or
the
the.
I
forgets,
there's
a
few
instrumentations
in
the
instrumentation
repo
that
the
maintainers
really
don't
understand.
Well
because
they
were
contributed
externally.
So
they
really
are
ideal
candidates
for
contrib.
C
C
You
know
before
embarking
on
it,
and-
and
this
is
just
just
like
a
comment
because
you
mentioned
the
the
collector
contrib,
so
one
thing
collector
contrib
has
done
because
they,
while
they
publish
a
collector
contrib
artifact,
they
actively
discourage
using
it
in
production,
use
cases
because
it
contains
everything
and
that's
just
like
a
lot
of
security,
vulnerability,
surface
area
and
so
to
you
know
they
still
publish
that
they
recommend
not
to
use
it
and
to
in
order
to,
I
guess,
accommodate
users.
C
They
have
a
collector
builder
project
or
tool
that
allows
you
to
really
easily.
I
guess
compose
your
own
collector
distribution
that
contains
exactly
the
components
you
need.
So
I'm
not
sure
how
much
that's
transferable
to
to
to
the
java
agent,
but
yeah.
That's
just
an
idea
that
they
do
they
have
they
make
it
easy
to
compose
your
own.
E
B
E
A
I
tend
to
agree
that
it's
less
of
a
problem
for
us,
at
least
at
this
point,
but
certainly
if
it
becomes
an
issue
I
know
nick.
This
was
the
java
agent
builder
was
one
of
nikita's
like
favorite
ideas,
or
I
think
he
was
yeah.
Yes,
yes,
just
like
the
spring
boot
start
spring
io.
B
I
I
personally
think
that
this
this
could
cause
more
problems
than
it's
worth
because,
like
users
might
not
be
like,
they
might
not
always
be
aware,
like
which
instrumentations
they
actually
need.
B
F
C
Is
that
for
the
builder
or
for
the
the
contrib
version
of
the
agent
in
general?
Sorry.
E
A
Oh,
I
was
thinking
of
like
the
builder
could,
like
start
with
the
java
agent,
because
we'll
still
publish
a
java
agent
from
the
instrumentation
repo
that
would
have
sort
of
the
most
important
instrumentations.
G
Yeah
on
this
topic,
I
was
thinking
about
the
lean
agent,
where
you
can
just
download
what
you
want
to
cherry
pick.
Whatever
modules
you
want,
and
then
you
click
you,
you
pass
this
parameter
when
you
load
the
agent,
so
the
agent
would
just
have
the
bare
minimum
to
run,
and
then
you
load
everything
else
in
runtime
you
don't
pack
everything
together
in
the
same
jar.
A
Which,
which
project
is
that.
G
No,
no.
This
was
just
one
idea
that
came
up.
Why?
Because
this
is
how
python
the
python
one
works,
they
just
they
just
cherry
peak
in
the
environment.
What
are
the
instrumentation
that
you're
going
to
use
and
then
the
auto
instrumentation
is
able
to
load
that
auto
automatically
load
the
modules
based
on
that.
A
A
And
for
this
one
jack
can,
will
you
create
a
list
for
the
core
repo
resource
detectors
or
I
guess
we
have
an
issue
there,
but
maybe
make
a
list
of
the
detectors
in
core
and
where
each
would
go.
C
Yeah,
all
the
I'll,
you
know
we,
we
have
an
issue
for
this
and
I'll
just
comment
on
the
there's:
a
specific
issue
for
resource
providers
where
those
should
live
so
I'll
include
the
details
of
this
conversation
and
where
we
kind
of
concluded
that
each
would
go
and
potentially
to
resolve
that
conversation,
you
know,
maybe
we
should
update
the
readme
or
contribution
guides
on
these
respective
projects
so
that
we
don't
constantly
revisit
this
conversation.
A
Yeah,
so
we
actually
have
a
such
a
document
in
the
instrumentation
repo.
A
I
I
it
was
in
the
road
map,
oh
okay,
that
I
remove
the
road
map
to
1.0,
which
I
finally
deleted.
But
yes,
I
also
have,
as
far
as
making
this
list
of
which
instrumentations
to
go
to
contrib.
A
B
A
F
A
Okay,
so
there
was
one
the
other.
The
last
thing,
then,
is
to
circle
back
with
jonathan
about
micrometer
sue.
A
B
I
I
am
fine
with
the
tweet,
whatever
you
you
think
it's
fine
with
it.
So,
okay,
just
tell
me
like
actually
leave
and
I'm
okay.
Thank
you.
A
Awesome
so
I
think
we're
good
to
to
go
ahead
and
send
you
know
any
time
send
micrometer
tracing
bridge
into
the
contrib
repo.
B
So
I
guess
the
next
steps.
We
need
to
sit
down
with
the
with
this
spring
project
and
we
need
to
like
decide
about
like
how
do
we
want
to
orchestrate
it
like
release
wise
and
so
on,
because
this
will
actually
like
make
it
more
complicated
to
for
us
to
like
release
changes,
because
the
changes
should
go
to
to
the
micrometer
repo,
then
to
point
elementary
and
also
springboot.
If
you
want
autoconfiguration
for
that,
so
we
will
sit
down
and
talk
about
this,
and
I
will
get
back
to
you.
A
A
C
My
agenda
item
is
kind
of
like
loosely
related,
and
so
let's
see
we
were
talking
about
in
the
spec
meeting
this
week
we
were
talking
about
the
aws
propagator
and
you
know,
as
some
folks
know,
but
just
update
others.
It
lives
in
the
core
repeal
right
now
and
the
spec
says
that
the
aws
propagators
or
vendor-specific
propagators
like
the
aws,
must
not
live
in.
C
You
know
core
distributions,
and
so
we
are
explicitly
in
violation
of
the
spec
and
so
we're
trying
to
figure
out
what
to
do
about
that,
and
I
think
the
consensus
was
is
that
we
should
call
out
in
the
readme
somewhere
that
you
know
this
is
this
is
exceptional,
and
you
know
this.
This
was
made
kind
of,
I
guess
an
error,
but
we're
going
to
maintain
it
and
but,
like
you
know,
we
shouldn't
expect
future
vendor-specific
propagators
to
be
included
in
the
in
the
core
repository.
C
C
We
published
that
today,
and
so
you
know
if
we
were
to
move
it
to
contrib,
we
would
have
to
continue
publishing
a
stable
artifact
at
a
core
and
there'd
also
be
you
know,
an
a
duplicate,
artifact
and
contrib,
and
so
we
need
to
update
both
places
and
so
on
and
so
forth,
and
I
was
getting
a
lot
of
feedback
that
we
do
not
have
to
continue
to
publish
stable
artifacts
to
be
compliant
with
semantic
versioning.
C
And
so
that's
kind
of
the
interesting
piece
of
this
puzzle
here
and
it
influences
kind
of
this
repository
reorg
in
a
couple
of
ways,
because
we
have
a
number
of
artifacts
that
have
been
marked
as
stable,
that
we
don't
want
to
publish
anymore.
There
is
the
jaeger
protobuf
artifact,
which
contains
the
protobuf
definitions
for
for
jaeger.
There
is
there's
this
aws
propagator
that
we're
talking
about.
There
are
the
this
stable
resource
providers,
so
the
sdk
resource
providers
artifact
that's
stable
and
we're
considering
moving
that
and
so
kind
of.
G
C
Well,
we're
not
breaking
we're,
not
we're,
not
changing
the
existing
code.
You
can
continue
to
use,
let's
say
we're
on
1.17
today,
so
the
thinking
was
that
we
stopped
publishing
the
aws
propagator
as
of
1.17
or
whenever
we
do
and
we're
not
going
to
publish
any
breaking
changes
to
that
code.
You
can
always
depend
on
that
and
because
our
api,
we
have
backwards
compatibility
guarantees
forever.
An
old
version
of
a
propagator
will
always
use
work
with
like
a
newer
version
of
the
api
and
sdk.
C
And
you
know
the
question
is
like
kind
of
what
do
you
do
about
patches
like
if
you
have
security
patches,
that
you
need
to
deploy
and
well?
We
don't
have
a
lot
of
dependencies
in
in
these
things.
So
there's
not
a
ton
of
external
surface
area
for
that
could
need
security
patches,
but
we
might
have
errors
in
our
own
code
that
require
patching
in
like
if
those
come
up.
C
Definitely
so
you
know
the
what
that
would
look
like
in
practice
is
maybe
they're
using
1.17
of
the
maybe,
let's
say
1.20
of
the
bomb,
and
they
have
to
explicitly
have
a
dependency
on
1.17
of
the
of
the
aws
propagator,
or
something
like
that
yeah
exactly.
D
I
mean
there's,
there's
a
I
I
was
going
to
say:
there's
a
there's,
a
possibility
that
we
could
publish
a
separate
bomb
like
a
legacy
or
a
deprecated
bomb
which
would
have
all
the
versions
of
the
deprecated
stuff,
pointing
at
those
deprecated
versions
of
things.
People
wanted
to
pull
that
in
just
as
a
thought
and
then
our
main
bomb
could
depend
on
the
could
include
the
deprecated
bomb
in
some
way
or
another.
C
F
E
E
C
C
A
Yeah,
I
don't
remember,
I
feel,
like
we
discussed
this
at
one
point
with
honorag
and
he
had
a
preference
to
continue
publishing
them.
But
I
don't
recall
the
details.