►
From YouTube: 2022-08-18 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
Hey
just
wanted
to
take
a
quick
second
to
introduce
myself.
It's
vive
here
from
aws.
I
joined
aws
recently
as
their
engineering
manager
and
happy
to
be
here
along
with
rafael
who's
part
of
my
team.
B
C
Ish
and
okay,
no
lori
anything
that
we
want
in
there
this
one.
Oh,
yes,
I
think
lori
mentioned
a
comment.
Okay,
I'll
push
that
comment
and
merge
that
anything
else.
Oh
yes,
this
one
mateusz,
do
you
think
any
reason
not
to
merge
this
for
the
release.
C
C
Cool-
and
I
had
put
those
two
already
in
here
so
I
will
push
that
comment-
merge
that
pr
and
merge
the
change
log
update
and
kick
off
a
release
today,.
C
Oh
yeah
and
then
in
the
contrib
we'll
make
contrib
release
after
that.
There's
one
pr
that
if
you
have
a
chance.
C
Somebody
who
has
a
on
a
official
approver
approval,
I
can't
merge
the
two
component
owners
approved
it.
So
you
know
somebody.
A
I
could
approve
it,
but
honestly
I
didn't
understand
it,
so
it
will
be
just
a
lack
of
approval.
C
I
think
that's
okay,
okay,
given
the
component
owners
have
approved
it.
Maybe
just
take
a
look
at
the
public
api
surface.
There's
some
public
api
surface
changes.
A
Okay,
I'll
take
a
look
at
it
tomorrow,.
C
C
No
now
I
mean
I'm
not
terribly
against
giving
right
access,
because
it's
not
like
you
can.
We
can
still
restrict.
C
We
can
still
restrict
people
from
being
able
to
push
directly
to
maine
and
we
can
restrict
who
can
hit
the
merge
button
so
not
really
sure
what
else
the
right
access
does
now.
This
is
sort
of
how
the
other
repos
have
been
managing
it
through
this
component
owner's
github
action
that
daniel
daila
wrote
to
sort
of
automatically
assign
people
and
work
around
this
issue.
C
C
Okay,
if
you
have
right
access
some,
but
don't
want
to
grant
those
component
right
access
to
the
repo
yeah,
I
think
that's
worth
revisiting.
C
B
C
C
Let's
see,
did
we
get
jason
here?
Yes,
jason.
E
I
was
only
a
minute
late,
we're
on
time
today,
yeah.
I
think
I
think
jack
already
chimed
in
on
this
one.
It
sounds
like
it
sounds
like
we
want
to
do
that,
so
it's
probably
not
a
lot
to
discuss.
I
think
I
put
this
on
here
like
a
week
ago.
E
C
F
And
one
of
the
reasons
I
feel
comfortable
making
this
change
or
I
don't
love
it
first
of
all,
but
I
don't,
I
can't
think
of
a
graceful
way
to
to
make
this
change.
But
one
thing
we
can
do
is
the
view
file
based
configuration.
A
lot
accepts
arguments
now
for
aggregations,
and
so
you
can,
we
can,
in
the
change
log,
describe
what
the
yaml
would
look
like
in
order
for
you
to
change.
That
would
allow
you
to
revert
the
bucket
boundaries
to
their
their
previous.
If
you
were
depending
on
those.
D
We
I'm
just
brainstorming,
but
could
we
detect?
So
you
know
as
a
way
to
mitigate
the
fact
that
this
will
almost
certainly
break
people?
Could
we
have
like
in
the
next
release,
have
a
warning
if
they
we
detect
that
they're
using
the
defaults
and
they're
the
wrong
defaults,
and
with
in
that
warning,
include
like
the
correct
way.
D
F
So
I
I
think,
if
we
detect
that
they're
using
the
wrong
defaults
it'll,
basically
that
that
warning
will
be
logged
for
everyone,
but
it's
you
know,
maybe
there's
still
some
some
merit
there
to
just
say:
hey.
This
change
is
coming
be
aware.
D
It
does
mean
that
we're
a
month
and
a
half
away
from
actually
getting
it
fixed
in
that
case
yeah
anyway,
just
a
thought.
E
E
B
Yeah
also,
the
current
defaults
are
in,
let's
say,
creating
problems
for
people.
Let's
say
if
they're
measuring
latency
with
they
have
let's
say,
very
low
latency,
it's
kind
of
masquerading
right,
the
result
of
let's
say
if
they
want
to
calculate
the
p99
or
something
like
that
right,
because
the
buckets
they
will
not
fall
directly
correctly
in
the
buckets
right
since
we
are,
is
keeping
the
first
bucket
right.
F
I
don't
think
we're
going
to
break
anything
on
the
front
end
so
on
the
low
latencies,
because
the
existing
buckets
have
a
bucket
from
negative
infinity
to
five,
and
you
know
all
latencies
are
going
to
be
positive,
so
you're
only
going
to
have
you
know,
even
though
the
buckets
from
negative
infinity
to
five
that
pretty
much
is
just
zero
to
five
for
all
practical
purposes
and
then
in
the
new
buckets
you
have
a
bucket
from
zero
to
five.
So
I
don't
think
we
have
any
change
there.
D
E
B
F
We,
we
could
add
a
temporary
property
that
you
know
is
a
shorthand
way
to
revert
to
the
the
previous,
the
previous
buckets.
So
you
know
we
can.
You
can
do
so
today
with
the
view
file
based
configuration,
but
if
you
don't
use
file
based
configuration
today,
that
may
be
like
extra
work,
that's
challenging
to
do
versus
you
know.
If
we
just
had
an
environment
variable
or
system
property
that
you
could
flip.
That
would
reduce
the
burden
we
could.
F
F
I
don't
like
that.
We
have
extra
extra
code.
That
does
the
same
thing.
I
do
like
how
it
stands
less
for
our
users.
C
Because
the
views
do
you
have
to
pull
in,
you
have
to
pull
in
a
separate
artifact
to
use
those
views
right.
The
view
configuration.
C
Well,
my
my
personal
take
would
be
the
delaying
doing
the
logging
in
one
release
and
then
breaking.
I
would
probably
not
go
that
far,
but
I
probably
would
I
like
the
idea
of
the
the
system
property
just
making
it
super
simple
for
somebody,
you
know
if
they
do
see
that
they
were
broken.
F
D
C
I'm
all
for
breaking
the
breaking
it
sooner
than
later.
I
do
think
not
upgrading
is
a
pretty
easy
option
for
people
who
are
just
depending
on
the
sdk,
because
the
sdk
has
been
pretty
stable.
So
there's
not
like
a
whole,
a
big
reason
why
they
would
need
to
upgrade.
F
A
D
E
Yeah,
it
sounds
like
we're,
leaning
in
the
direction
of
having
a
config
flag,
which
reverts
back
to
the
old
behavior.
Do
you
want
that
as
part
of
that
same
that
same
change
set,
or
you
want
to
follow
up
one.
F
B
E
G
So
that
that
was
me
so
micrometer
tracing
is
basically
like
a
sprinkler
suit
moved
over
to
the
micrometer
organization,
because,
like
that
way,
sloop
doesn't
need
to
be
like
dependent
of
of
spring,
and
we
had
this
discussion
earlier.
I
believe
it's
on
rock
to
to
create
a
bridge
in
the
micrometer
organize
sorry
in
the
auto
organization.
G
Like
a
throne
right
because
so
this
is,
this-
is,
I
guess
the
other
way?
So
this
is
like
users
are
using
the
micrometer
tracing
api
and
those
api
calls
are
translated
into
open
telemetry
codes.
C
C
So
I
so
these
bridges
are
fairly,
I
mean
they're
complex
and
they
have
been
specked
because
I
think
probably
the
one
key
thing
that
I
would
call
out.
C
So
open
tracing
and
carlos
since
you're
here,
why
don't
I
defer
and
let
you
talk
just
briefly
about
the
process
of
specking
and
building
out
such
a
bridge.
B
Yeah,
so
basically
the
way
for
do
that
was
just
starting
with
the
draft,
the
usual
stuff,
but
it
was
very
easy
because
we
are
well.
We
already
have
something
like
this
in
open
racing
between
open
tracing
and
yeah.
I
just
created
the
drafts.
You
start
looking
with
yuri
and
he
was
just
hitting
me
on
iterating.
G
I
have
two
questions,
so
such
a
such
a
like
a
bridge,
already
exists,
so
if
this
is
basically
total,
it
is
very,
very
similar
we
will
just
like
if,
if
it
is
okay,
we
want
to
like
move
that
into
the
duty
hotel
code
base
and
like
also
like
the
other
modules
of
micrometer
support
like
the
micrometer
shim.
Does
that
have
a
spec.
F
No,
so
that
that's
what
I
was
going
to
bring
up
so
there's
kind
of
an
exception
for
micrometer,
because
it's
a
really
important
piece
of
the
java
ecosystem,
but
it's
not
language
agnostic
micrometer
doesn't
exist
for
these
other
languages,
and
so
you
know
it
doesn't
necessarily
make
sense
for
a
spec
to
exist
that
all
the
languages
implement.
C
Yeah-
and
I
think
that
we
kind
of
put
that
here,
given
I
mean
how
pervasive
the
how
everywhere
micrometer
metrics
is
and
how
all
of
our
users
are
using,
that,
I
think
for
my
initial
thought
would
be
for
the
micrometer
tracing
shim.
C
I
don't
see
any
reason
we
wouldn't
accept
it
in
the
contrib
repo.
As
long
as
there
are
two
well
at
least
one
component
owner,
so
it
would,
you
know
it
would
need
to
come
with
a
component.
The
contribution
would
need
to
come
with
somebody
saying
that
they
would
be
a
component
owner.
Ideally,
we
try
to
get
two
component
owners
from
different
companies,
but
the
min
bar
is
one
component
owner.
A
This
is
a
straight
copy
of
spring
split
photo.
I
think
it
might
even
need
to
go
to
contract
because
if
I
remember
remember
correctly,
it
uses
instrumentation
api,
so
we
would
have
like
a
cycle
reference
reference
cycle
back
to
instrumentation
from
sdk,
which
is
probably
something
we
want
to
avoid.
G
So
this
is
basically
like
the
open,
telemetry.
Sorry,
the
micrometer
tracing
api
is
basically
like
smooth,
it's
an
abstraction
layer
over
tracing
libraries,
and
we
will
have
like
two
supported
tracing
library.
One
will
be
brave
and
one
will
be
hotel
and
for
the
implementation
for
these
kpis
or
these
species.
We
want
to
move
this
into
the
into
the
respective
like
organization,
so
the
grave
bridge
should
go
to
brave
and
the
the
octo
bridge
should
go
to
hotel.
G
G
That's
the
current,
like
the
dimetrix
bridge,
does
that
live
in
the
country,
people
or
is
it
a
kin
another.
B
F
There's
obviously
an
argument
that
they
should
be.
I
need
to
learn
more
about
the
micrometer
tracing
library
previously
spring
sleuth,
because
the
an
exception
was
made
for
micrometer
metrics,
because
it's
so
pervasive
in
the
java
ecosystem
need
to
revisit
why
we
why
we
thought
that
the
the
core
repository
was
a
good
home
for
this
and
whether
that
same
criteria
applies
to
micrometer
tracing.
G
So
just
take
a
look
at
the
the
ringkai
sand
and
yeah,
just
let
us
know
like
next
week
and
we
can
get
back
to
this
topic.
C
So,
just
the
core
repo
kind
of
the
line
that
we've
been
learning
and
and
re
calibrating
as
we
go,
the
line,
we've
kind
of
tried,
I
think,
makes
the
most
sense
from
the
core
repo
to
instrumentation.
Repo
is
spect,
components
live
in
the
core,
repo
and
non-spec
components,
don't
live
in
the
core,
repo
or
and
also
oh.
No,
we
also
said
anything
semantic
convention
related
would
live
outside
of
the
core
repo,
so
was
it
spect
or
semantic
conventions.
What
was
I.
C
And
then
so
does
that
mean
the
core
repo
can
have
things
that
aren't
spec'd,
but
I
don't
have
summit,
don't
use
semantic
conventions.
F
Well,
it's
a
tricky
question
because
the
shims
in
here
you
know,
could
be
thought
of
as
instrumentation
in
a
way
but
they're
kind
of
different.
They
have
some
some
characteristics,
but
they
don't.
A
F
Well,
it
was
until
the
micrometer
shim
landed
in
there,
so
that
kind
of
threw
a
wrench
in
that
in
that
criteria.
C
So
another
wrinkle
is,
if
anything
that
we're
using
in
the
a
in
the
java
agent
today
is
either
we
don't
put.
We
don't
pull
anything
from
contrib
into
the
java
agent
today
that
could
certainly
change.
We've
got
some
cycle
release
cycle
potentially
to
iron
out.
C
The
easy
solution
to
that
is
instrumentation,
like
1.17,
would
only
pull
in
the
1.16
release
of
the
contrib
components.
Since
we
release
in
that
order.
A
F
D
Did
does
the
I
guess
thought
that
we
were
going
to
bring
this
up
with
the
the
technical
committee
if
they
had
opinions?
I
don't
know
if
anyone's
had
the
chance
to
do
that,
carlos
since
you're
here.
B
Yeah,
so
I
think
that
yeah
I
mean
I
can
ask
to
see
directly.
I
think
that
in
the
past
we
have
considered
that
it's
up
to
the
maintainers.
What
they
feel
is
the
best
and
the
best
case
that
is,
it
could
issue
a
recommendation,
but
in
the
end
it
could
be
about
most
likely
will
fall
on
you
to
make
the
final
decision.
D
I
think
if
we
could
restrict
it
to
things
that
are
specified,
it
will
make
the
core
maintainers
lives
a
little
more
sane
and
push
other
things
that
are
instrumentation
in
the
instrumentation
repo
to
push
things
that
are
not
instrumentation
into
the
contrib
repo
with
owners
for
them.
D
F
And
you
know,
even
if
our,
even
if
our
head
count
changes
if
we
get
more
help,
the
core
repo
isn't
set
up
like
contrib
in
the
sense
of
you
know,
sharing
ownership.
So
the
contributor
repository
has
that
nice
code
owner's
infrastructure
to
you
know
assign
sub
sub
modules
to
individual
people.
F
C
F
C
All
right,
yeah,
let's
sit
on
this
for
a
week,
digest
it
see.
If
anybody
has,
I
mean,
feel
free
to
comment
more
on
this
issue
and
then
maybe
next
week
we
can
make
a
decision.
D
F
Yeah,
I
suggest
so
there's
two
parts
of
it.
There's
the
the
propagator,
the
x-ray
propagator,
which
you
know,
I
think
we're
kind
of
coalescing
on
the
idea
that
we
add
that
to
the
stack
and
then
so
that
would
live
in
here.
But
then
there's
also
the
aws
resource
detectors.
F
And
so
you
know
those
deal
with
the
semantic
inventions
resources
of
semantic
inventions.
And
you
know
one
idea
that
we
threw
out.
I
think
last
week
or
maybe
two
weeks
ago,
a
couple
weeks
ago
was
to
move
resource
detection
to
instrumentation,
and
that
would
involve
not
just
the
aws
resource
detectors,
but
the
I
don't
know
how
to
describe
them.
The
core
ones
as
well
process
and.
F
C
No,
our
all
of
our
maven
central
permissions,
are
at
the
I
o
dot
open,
telemetry
level.
D
So
this
might
be
a
case
since
we
would
want
to
just
move
them
over
there,
without
essentially
without
changes.
Maybe
it
would
make
sense
to
publish
the
same
coordinates,
whereas
the
annotations,
I
think
we
were
starting
to
build
new
annotations,
and
I
don't
remember
if
there's
another
good
reason
why
we
didn't
want
the
same
coordinates.
F
Well,
so,
let's,
let's
play
that
out
a
bit
so
right
now
we
have
the
let's
call
them
the
the
core
resource
detectors
and
then
the
aws
resource
detectors
in
the
future.
We
could
imagine
other
cloud
specific
resource
detectors,
azure
gcp
things
like
that
when
we
were
to
add
those
would
we
would
those
coordinates
not
be
symmetric
with
the
aws
resource
detection,
because
the
aws
ones
got
grandfathered
into
the
old
coordinates.
D
So
I
mean
it
wouldn't
bother
me,
I
mean
publish
those
under
open,
telemetry,
sdk,
extensions,
azure
or
gcp,
or
something
like
that.
I
don't
know
that.
Wouldn't
that
wouldn't
necessarily
be
a
terrible
thing.
It's
a
little
bit
it's
a
little
bit
strange,
but
I
guess
the
question
is:
if
we
mark
those
things
stable,
the
other
option
is
to
continue
to
publish
both
versions,
and
I
think
that
might
end
up
being
more
confusing.
F
That's
not
great,
and
you
know,
depending
on
how
far
we
go
with
this,
we
can
have
a
we
might
end
up
with
a
decent
number
of
artifacts
that
we
continue
to
publish
under
two
sets
of
coordinates
like
right.
Now
we
have
the
annotations,
but
if
we
play
this
out,
we
can
have
resource
detection
and
potentially
some
others,
because
you
know
those
are
all
artifacts
that
are
already
stable
from
the
core
repository.
A
Yeah
but
the
difference,
the
research
detectors
are
kind
of
different
from
annotation
because
they
probably
require
some
actual
maintenance
right
in
case
there's
anything
any
bug
or
any
change
that
we
have
to
do.
You
would
pretty
much
have
to
change
it
twice,
both
in
the
corridor
and
in
the
instrumentation
repo
and
then
annotations
are
like.
Who
cares?
It's
just
an
annotation.
B
What's
the
problem
with,
let's
say
just
keeping
the
the
coordinates
until
we
have
a
new
measure
version,
so
let's
say
move
the
code
to
a
new
repo
but
keep
the
package
namespace
the
package
names
and
the
maven
coordinates
so
that
users
that
importing
the
those
class
directly
don't
are
not
impacted
and
also
people,
depending
on
the
on
the
let's
say,
they're,
gradle
or
maven
palm
xmls
are
not
impacted
as
well.
So
what's
the
problem
just
let's
say.
D
C
Yeah,
they
would
be
the
only
artifacts
in
the
instrumentation
repo
that
are
not
published
under
the
I
o
open,
telemetry,
instrumentation
or
io
open
telemetry
java
agent
group
ids,
but.
C
And
I
think
you
know
we
can
definitely
make
the
decision
to
not
have
consistency
in
favor
of
you
know
not
causing
user
pain,
but
would
be
good
to
understand
what
our.
What
would
we
do
for
future.
A
I
think
keeping
the
I
o
and
telemetry
and
sticking
extension,
meaning
it
kind
of
makes
sense,
because
you
can
use
resource
detectors
even
without
like
any
instrumentation.
You
can
just
plug
them
into
sdk
and
since
they're
they
just
contain
spi's
they're,
just
like
plug
and
play.
You
put
them
on
a
class
five
and
they
just
work
so
they're
kind
of
different
from
most
of
our
instrumentations
and
honestly.
C
What
about
the
contrib
repo.
F
Well,
that
might
make
sense
for
the
aws
resource
detector.
Definitely
not
the
core
one
or
probably
not
the
core.
One.
A
C
F
What
would
it
change
your
opinion
if,
or
does
this
influence
the
discussion
at
all?
Having
some
sort
of
you
know
date
in
mind
for
a
2.0
where
you'd
be
allowed
to
change
the
group
id
and
artifact
2.0
is
like.
D
E
F
So
let's
say
we
put
a
new:
we
have
a
new
category
of
things
in
instrumentation,
which
are
these
is
where
these
resource
providers
go.
Where
the
resource
providers
go,
how
much
sleep
would
we
lose
over?
You
know
having
these
things
called
sdk
extensions,
and
what
would
make
sense
is
the
criteria
for
other
extensions
that
would
go
in
that
directory.
C
Sorry,
sorry,
jason,
the
mono
repo
is
continuing
to
grow.
A
C
F
Yeah,
let's
narrow
the
conversation
to
try
to
just
think
about
these
resource
detectors
in
in
particular,
you
know
maybe
ignore
some
of
the
other
things
I
wasn't
sure
what
the
best
way
to
approach
this
question
was
so
there's
like
one
issue
that
tracks
many
things:
maybe
that
conflates
issues
but
yeah.
Let's
try
to
settle
the
resource
detector
thing
first
and
we'll
go
from
there.
D
C
Why
is
this
hard
all
right,
any
oh
ice.
Did
we
do
this
auto.
B
B
I
found
that
during
the
call
okay
yeah
by
the
way
since
we
are
in
there.
If
I
ask
something
I'm
wondering
about
the
upper
bounds
change
for
the
xbox
histogram,
I
saw
that
you
are
planning
to
post
a
pr,
maybe
today
or
something
like
that.
Yeah
like
release
wise,
do
you
think
that
will
appear
in
the
next
release
next
month.
F
I
think
it's,
I
think
it's
pretty
much
certain
that
it
will.
It
shouldn't
affect
any
users,
because
you
know
the
whole
idea
of
these
histogram
boundaries
is
that
it's
impossible
to
be
precise,
anyways
and
so
yeah.
It's
just
an
implementation
change
and
the
implementation
is
probably
like
90
on.
C
All
right
any
final
thoughts.
Oh
I
know
on
this
one
I
was
going
to
mention
to
viv
and
rafael
that,
since
we
were
interested
in
keeping
the,
I
think
we're
also
interested
in
keeping
the
aws
propagator.
B
C
The
core
repo,
but
that
is
not
expect
today,
so
we
would
really
love
if
somebody
could
drive
that
a
spec
for
that,
so
that
we
can
justify
keeping
it
in
the
core
repo.
F
And
there's
here
let
me
include
a
link
down
here,
so
I'm
not
sure
I'm
just
included
in
the
bottom
of
this
document,
but
there's
a
very
obvious
play
yeah
right
there,
you
got
it
or
no,
that's
not
the
right
place.
B
F
It
is,
it
is
specked,
okay
and
the
place
where
it's
spec
is
in
the
context.
Directories
the
specification
context,
yeah
api
propagators.
B
F
F
We're
just
trying
to
add
a
bullet
point
just
like
this
ot
trace
bullet
point
right
here.
So
you
know,
ot
trace
is
not
part
of
the
set
of
propagators
that
must
be
supported,
but
it's
allowed.
So
it's
a
may,
and
so
you
know
we'd
like
to
get
the
aws
propagation
included
in
this
in
this
may
category.
So.
B
C
F
Because
right
now
we're
kind
of
we're
kind
of
out
of
spec
compliance,
because
the
example
that
we're
talking
about
is
explicitly
used
as
an
example
for
something
that
shouldn't
be
in
the
core
repositories.
C
And
yeah,
and
so
the
kind
of
the
reasoning
in
general,
nothing
sort
of
vendor
specific,
like
a
splunk,
something
splunk,
specific
or
new,
relic
specific
should
be
in
the
core
repo.
But
this
is
a
case
where
the
awx
aws
propagator
is
useful
for
splunk
customers,
new,
relic
customers,
every
all
customers,
not
only
x-ray
customers.
B
F
I
think
you
should
the
the
spec
workflow
requires
that
you
open
an
issue
before
pr.
So
if
you
could
open
an
issue
and
and
reference
this
conversation
that
we're
having
in
the
in
there's
an
issue
in
the
java
core
repository,
you
know
and
then
describe
essentially
what
we're
talking
about
here
and
then
you
can
have
a
pr
that
follows.
If
you
do
open
that
issue,
I'll,
go
and
comment
on
it
and
you
know
express
support
so.
B
D
People
want
to
contribute,
do
pr
views
in
the
core
repo.
Please
please,
please,
there's
a
great
opportunity
right
now:
jack
put
in
a
pr
do
some
stuff
with
the
logging,
like
kind
of
recording
information
on
the
logs
in
the
sdk
great
opportunity
for
someone
to
get
involved
and
review
that
piece
of
code.