►
From YouTube: 2023-03-06 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
I
didn't
have
the
time
to
push
hardening
of
the
maven
open
temperature
extension
for
the
glitches
user
ad,
but
I
have
a
meeting
with
a
Zoom
Cafe,
with
this
person
later
this
week
to
a
discus
of
improvements.
A
Cool
awesome,
it's
great
to
see
interest
in
that
yeah.
Do
you
have
any
sense
of
how
much
that
is
being
used.
B
B
B
We
do
metrics,
who
has
already
solved
by
sorry,
was
already
sold
by
the
Jenkins
Prometheus
integration
on
where
we
differentiate
is
that
we
add
traces,
I.
A
All
right,
we've
got
a
bunch
of
things
to
potentially
chat
about
today.
A
A
It
aligns
now
now
I
I,
think
I
understand
and
is
there?
What
do
other
folks,
I'd
say
in
particular
Riley
would
millet
think
that
we
should
follow
up
on
still
okay
Ted.
D
C
It's
you,
can
you
can
see
the
the
pr
coming,
yeah,
I
I,
think
it's
not
a
very
bottom
and
he
agreed
he's
going
to
add
some
example
and
just
elaborate
that.
A
How
about
you,
Lynn
Miller,
have
you
had
a
chance
to
go
through
the
whole
thing?
Recent
recently,
after
updates.
E
D
A
D
Yeah
one
quick
question
before
I
dive
into
it:
I
guess
the
structure
is,
is
kind
of
like
implicit,
that
semantic
conventions
would
Define
structure.
D
I
I,
see
that
I
guess
we're
leaving
things
like
links
and
stuff
off,
because
they're
not
fully
defined
but
I,
know
there's
some
places
like
in
HTTP
right
where
we
wanted
to
Define
some
structure
right
like
how
redirects
and
retries
should
be
connected
to
each
other,
so
I'm
just
curious.
If
thoughts
about
that
kind
of
stuff
have
gone
into
this.
A
So,
on
the
HTTP
side
we
don't
have.
We
haven't
added
that
link
layer
to
retries
yet
and
I.
Think
since
messaging,
although
Johannes
had
provided
some
feedback,
but
yes
I
I'm,
not
sure
we
have
included.
A
Links
yet,
let's
see
not
enforced
right.
D
A
Yeah
and
I
would
assume
that,
like
messaging
semantic
conventions,
I
mean
that
would
take
precedence
if
they
Market
stable
and
say
that
the
link
you
know
this
is
how
links
will
work.
Okay,.
D
Cool
great
yeah
I
think
it's
always
fine
to
come
back
in
later
and
start
adding
things
that
the
conventions
enforce
it's
reasonable
to
not
enforce
those
things
yet
cool.
A
Okay,
thank
you
very
yeah
at
a
very
high
level
that
this
and
from
a
discussion
on
Friday
there's
a
PR
to.
A
Yes,
this
that
we
basically
are
saying
that
the
semcom
and
because
for
a
while
there
was
some
discussion
of
some
kind
of
applying
to
Consumers
and
what
consumers
can
rely
on,
while
that
would
be
lovely
there's
a
lot
that
happens
in
between
there's
span
processors,
metric
fees
right
there,
things
in
between
and
we're
just
not
ready
to
deal
with
that.
So
we're
being
very
explicit
that
it
only
applies
to
the
instrumentation
that.
A
This
was
the
other
one.
Josh
asked
us
to
take.
A
look
to
cover
today
seems
like
there's
some
good
number
of
reviews
already,
so
maybe
I'll
just
poke
the
spec.
The
broader
group.
A
So
I
had
to
one
thought:
we
discussed
this
on
Friday
and
about
so
adding
new
required
attributes
being
a
breaking
change
and
I
was
thinking
about
it
in
the
context
of
semcom
only
applying
to
the
instrumentation
that
it
kind
of
felt.
Oh
I
see
you
already
commented
on
okay,
so
that
makes
sense
to
you
lindmilla.
A
So
the
idea
is
that
required
now
means
instrumentation,
for
this
specific
specification
version
must
provide
it.
It
doesn't
say
anything
beyond
that
and
then
the
schema
stability
rules
would
govern
how
you
know
that
can
change
or
cannot
change
from
spec
version
to
spec
version.
A
A
Cool
thanks,
Nora,
the
the
what
I
want
to
send
the
the
next
PR
is
to
mark
this
document
as
stable,
which
will
be
I,
mean
need
a
lot
of
more
reviews
and
Pia
and
approvals,
so
I
wanted
to
get
in
the
the
proofreading
first.
A
This
one
also
came
out
of
discussions.
We
were
having
last
week
and
I
just
so
related
to
metrics.
Adding
metric
attributes
is
currently
a
breaking
change
which
would
so
yeah.
So
this
was
from
an
earlier
discussion,
adding
metric
attributes
as
a
breaking
change,
because
it
adds
more
time
series
which
I
guess
some
back
ends
that
causes
problems
for
alerts
and
other
things,
but
it
also
prevents
schema
evolution.
A
So
the
question
is:
can
we
add
a
some
kind
of
schema?
Transform
that
transparently
removes
newer
attributes
for
people
who
want
to
maintain
compatibility
with
a
specific
spec
version
and
it
seems
reasonable,
but
I
wanted
to
get
if
we
could
get
just
kind
of
confirmation
or
clear,
like
a
consensus
that
this
is
doable
in
the
future.
That
would
relieve
some
of
our
concerns
about
HTTP
stability
and
allow
us
to
unblock
a
couple
of
issues,
because
we
know
we
can
address
them
in
the
future.
C
A
C
D
But
also
I
I
think
as
a
general
rule
for
semantic
conventions.
We
should
never
rely
on
the
idea
of
like
optionality
or
configuration
as
like
a
way
of
getting
out
of
anything
related
to
stability,
because
the
reality
is,
you
know
when
people
install
the
new
stuff
they're
going
to
get
the
new
Telemetry
and
it's
not
really
feasible
to
configure
everything
across
a
giant
system.
D
C
That
particular
version
yeah,
so
I
I
feel
mainly.
We
have
some
misunderstanding
here
so
for
Matrix,
I
I
think
the
the
message
is
once
we
ship
the
stable
version
of
Matrix
anything
to
that
metric
stream.
If
we
add
some
new
dimension,
that
Dimension
will
be
up
to
you,
so
you
don't
have
it
by
default
because
we
always
backward
compile.
So
we
have
another
actually
because
you
have
to
take
those
attributes
by
default.
You
won't
have
any
of
this
because
they're
added
later.
A
Yeah
am
I
am
I
understanding
that
correctly
Riley
that
if
there
was
a
schema
translation
that
could
remove
those
new
attributes
and
re-normalize,
you
know
redo
the
distributions.
D
A
A
In
particular,
I
thought
this
section
seems
per
pretty
important
to
Mark
stable
because
it
closes
there's
currently
an
open
issue
sort
of
about
whether
we
should
be
using.
A
The
this
standard,
the
ucum
standard.
A
A
F
The
idea
of
a
guideline
being
stable,
I
thought
I
I.
Guess
it
means
to
like
hey,
like
you
know
this,
it's
not
going
to
change
as
much
there's
still
some
values
to
signal
to
me
that
I
don't
have
to
reread
this
like
every
commit
or
something
I.
Don't
know,
that's
a
good!
That's
a
good
question!
I!
Don't
think
it
formally
matches
the
definition
of
stable
we
have
provided.
However,
the
concept
of
like
hey
this
dock
is
stable
is
still
a
bit
useful
to
me.
F
A
Yeah-
and
maybe
we
just
focus
on
what
we
need
for
http,
which
potentially
would
be
this
and
I
think
this
one
also
is
potentially
important,
whether
that
you
can
choose
either
synchronous
or
asynchronous,
are
considered
equivalent.
G
F
G
A
I
threw
this
in
just
to
in
case
books,
haven't
seen
this
kind
of
late
breaking
update
just
today
that
they
are
elastic,
is
proposing
a
full
sort
of
donation
merger
into
open,
telemetry
and
I
know.
We
have
other
meetings
and
discussions
to
figure
this
out,
I
think
it's
pretty
I
mean
it's
in
kind
of
the
hands
of
the
TC
and
GC,
and
so
I
kind
of
don't
want
to
get
this
I.
Don't
want
this
group
to
get
completely
derailed.
A
We
could
get
completely
derailed
by
this,
and
I
mean
we
will
change
a
lot
of
things
in
response
to
this,
but
trying
to
I'm
still
hoping
we
can
get
all
the
HTTP
stuff
or
all
the
things
that
are
blocking
HTTP
stability
in
this
week,
and
then
we
will
let
ECS
fall
the
ECS
play
out
and
follow
where
it
does.
C
I
have
a
quick
question
regarding
the
ecl
thing,
so
yeah
so
UCS
folks
already
updated
the
old
Tab
and
it
seems
like
they.
They
agree
with
the
overall
direction
of
ecis
and
open
time.
Tracing
schema
will
become
one
and
I
guess
the
old
type
might
take
some
time.
So
how?
How
do
we
want
to
do
this?
Htv
segment?
Do
we
wait
for
the
outside
to
be
merged?
Then
we
just
like
trust
like
you
have
like,
maybe
five,
six
PRS.
Let
me
merge
some
of
those
PRS
or
we're.
C
So
simple
question
is:
do
you
want
to
wait
for
the
old
type
from
ecis
to
be
merged
before
we
start
to
merge
some
of
these
PRS
or
we
think?
As
long
as
ECS
like
an
open
function
lines
in
a
general
direction,
then
we
should
just
go
and
merge
this
because
it
seems
like
aligned
with
the
direction
anyways.
C
A
Without
the
justification
that
is
used
by
this
Otep
yeah
adopted,
yeah
and
but
I
mean
maybe
there's
a
somewhere
in
the
middle,
where
maybe
the
if
we
can
get
the
you
know
like
the
TC
to
basically
say
yes
as
a
whole,
we,
you
know,
we
agree
we're
moving
forward
with
this.
We're
still
working
out
details,
but
it's
okay
to
go
ahead
and
do
this,
but
yeah
I
feel
like
that's
it.
C
Yeah
so
I'm
I'm
almost
opinion
TC
every
other
day
and
I
I
still
feel
like
given.
This
is
not
entirely
controlled
by
open
climate.
Even
open
Telemetry
Community
takes
like
very
long
time
to
agree
on
such
a
big
thing.
So
my
my
water
is
the
the
old
type
might
take
some
time
and
and
I'm
trying
to
explore
a
big
time
like
unblocks
the
HTTP
semantic
Convention
as
much
as
possible.
So
so
trust.
C
Maybe
we
should
go
through
the
the
PRS
that
have
like
some
ECS
related
thing
and
and
make
a
call
which
one
we
can
merge
without
having
to
wait
for
those
and
which
one
we
must
wait
for
the
ultimate
to
be
merged.
First.
C
Like
this
is
something
we're
going
to
make
a
decision
and
whatever
decision
we're
going
to
make,
there's
some
like
critical
consequences,
and
would
you
rather
to
have
the
debate
and
and
have
all
the
issues
concerned
discussed
earlier
than
later.
A
A
C
Yeah,
so
so
what
I'm
thinking?
Maybe
on
tomorrow's
respect,
anything
we
should
tell
people
hey
like
these
are
a
list
of
important
changes
that
will
have
a
lot
of
consequence
and
and
number
one.
We
want
you
to
be
aware
of
this
number
two
is
all
of
this
are,
depending
on
the
eci's
open
time,
systematic
conversion
Direction,
whether
they
merge
or
not,
and
how
they
merge.
G
G
A
A
little
bit
of
like,
but
yes,
I,
I,
totally
agree
with
you.
I
don't
want
this
to
drag
on
for
months.
I
think
you
know
it
needs
to
be
a
week's
kind
of
a.
D
A
D
I
think
we
should
resolve
the
initial
stages
with
ECS
sooner
rather
than
later,
but
my
instinct
is
honestly,
even
if
we
agree
to
merge
the
two
projects,
the
we're
talking
about
like
years
on
both
sides
when
it
comes
to
like
ending
up
in
a
place
where,
literally
all
the
instrumentation
out
there
has
like
converged,
I
I
guess
what
I'm
saying
is
personally
I
feel
like
it's
okay
to
stabilize
to
kind
of
keep
on
our
path
with
HTTP
and
stabilize
it
without
the
ECS
changes,
because
any
kind
of
merger
with
ECS
they
they
are
already
stable
on
this
front.
D
I
guess
is
what
I'm
saying
so
if
we're
going
to
figure
out
how
to
like
actually
live
in
a
future,
where
we've
changed
some
of
this
stuff,
I
think
it
has
to
be
on
the
other
side
of
some
of
our
things
already
being
stable
from
a
practical
perspective
right
we're
already
in
the
place
where
these
kinds
of
changes
would
be
breaking
like
de
facto
stability
like.
A
I
have
a
hard
time
with
that,
though,
like
de
facto
I
have
a
hard
time
with
de
facto
stability
as
like.
If
stability
was
important
enough
to
the
community
that
you
know
it's
not
going
to
allow
breaking
changes,
it
should
have
been
prioritized
and
it
should
have
been
stable.
It
should
have
been
marked
stable
already.
D
Yeah
no
I
I
totally
agree.
We've
been
very
cautious
about
marking
these
things
stable,
but
at
the
same
time
the
fact
that
they
aren't
Mark
stable
doesn't
mean
we
can
be
Cavalier
about
changing
them.
Right
like
the
reality
is,
we
will
like
cause
a
lot
of
pain
and
suffering
if
we
change
these
things.
So,
just
to
me
that
means
like
if
we
want
to
change
something
that
we
know
is
going
to
cause
a
lot
of
pain
and
suffering.
D
A
But
if
we're
going
to
I
mean
wouldn't
wouldn't
the
I
feel
like
this
would
be
the
time
to
make
that
change,
though,
and
be
like
hey,
you
know
now
we're
stable.
Yes,
we
and
we
can
still
do
all
those
things
of
helping.
You
know
that
have
a
better
convergence
path
for
existing
users,
but
at
least
then
we
don't
have
the
issue
of
having
two
stable
things
out.
There.
A
Mean
we've
been
really
also
cautious
on
all
our
instrumentation
is
marked
Alpha
and
we've
gotten
a
lot
of
pushback
from
users
of
like
hey.
When
are
you
gonna
Market?
You
know
stable
and
we're
like
were
not
because
the
semantic
conventions
aren't
stable,
yeah,
so
I
mean
at
least
you
know.
We've
been
responsible
in
the
communication
of
these
things.
D
Yes,
it's
still
I
think
an
open
question
about
whether,
if
we
make
some
kind
of
like
if
we're
gonna
make
a
breaking
change
to
something,
that's
fundamental,
we're
we're
like.
We
know
that
people
are
relying
on
the
way
things
are
today
and
it's
definitely
going
to
break
a
lot
of
people.
If
we
change
this,
even
I,
don't
think
it's
sufficient
to
say
like
well.
Technically,
we
hadn't
marked
it
as
stable
so
too
bad
right
like
we
would
it's
just
like
that.
D
That
just
would
be
a
bad
experience,
so
I
think
we're
one
way
or
the
other
we're
still
stuck
figuring
out.
What
is
the
responsible
way
to
change
these
things?
If
we
want
to
it's,
not
that
we
can't
do
it,
but
it's
like
where
to
me:
there's
a
definitely
a
good
set
of
stuff
where
we
couldn't
change
it.
D
Just
by
having
a
breaking
change
between
two
versions
right,
we
would
have
to
come
up
with
schema
translations
or
some
some
idea
for
how
to
do
it,
so
that
I
guess
that's
what
I'm
saying
like
I
don't
know
if
ECS
is
like
dragging
their
heels
on
merging.
If
it
seems
like
that,
discussion
isn't
going
to
get
sorted
out
like
in
any
kind
of
time
frame,
measured
on
like
a
couple
months.
Oh.
A
D
A
D
A
C
B
While
yes,
so
I
will
not
talk
about
these
years,
because
I
was
a
creator
of
this
Otep
almost
12
months
ago,
because
I
am
no
longer
part
of
elastic.
B
For
some
reasons
on
I
I
feel
that
the
semantic
conventions
are
they
are
today
when
they
are
used
by
Java
an
agent
like
the
Java
hydrant,
which
is
1.23,
which
is
used
in
production
which
has
been
there
for
ages.
B
If
we
break
compatibility
on
this,
it
will
be
a
big
Challenge
on
something
where
why
is
it
hard
to
make
all
these
stable,
I
think
almost
no
vendor
at
the
DTA
effort
to
standardize
all
its
internal
data,
but
a
key
value
of
Hotel
versus
also
proprietary
instrumentation
is
that
the
data
that
you
collected
with
hotels
are
yours,
because
you
can
reuse
them
after
they
have
been
injected
ingested
by
the
open
Telemetry
product
or
your
obserability
backend
or
you
are
your
Kafka
stream
and
you
can
reuse
them
for
your
own
use
case,
and
so,
if
we
change
some
critical
semantic
conventions
like
net
or
like
HTTP
or
even
probably
database
stuff,
it
will
break
some
existing
Integrations
on
with
open
symmetry.
B
We
have
teams,
there
were
teams
who
could
achieve
what
they
have
never
been
able
to
achieve
with
a
vendor
appropriate
stuff.
I.
Remember
some
decommissioning
teams
who
were
trapping
Hotel
tracers
on
the
Kafka
stream
stuff
like
this.
Until
if
we
break
the
attribute
that
were
critical
and
instrumental
instrumental
in
their
use
cases,
even
if
we
say
it's
Alpha
I
think
we
need
some
migration
journales.
F
B
B
I
guess
he
was
your
vendors.
You
derive
your
service
map
from
the
semantic
attributes
of
the
net
boundaries
on
also
you
derive
your
service
map
database
view
connection
to
your
database
from
the
semantic
attributes
on
the
SQL
Server.
F
Well,
okay,
so
it
sounds
like
there's
some
tooling
being
built
upon
semantic
inventions
that
this
isn't
part
of
the
workflow
for
open
Telemetry
right
like
there's,
no
like
ingest
way
to
say,
like
hey,
here's
how
you
were
able
to.
We
don't
provide
like
a
spec
saying
how
you
can
build
on
top
of
genetic
Adventures.
Maybe
I'm
Wrong
I
could
be
ignorant.
Do
we.
D
A
D
Right
like
and
that's
sort
of
why
I'm
saying
it
whether
we
Market,
stable
or
not,
is
kind
of
like
neither
here
nor
there
when
it
comes
to
what
kind
of
changes
we're
allowed
to
make.
If
it's
a
change
that
can
be
mitigated
through
a
schema
translation,
you
know,
then,
like
everybody's
fine
right
and
we
can
also
ship
instrumentation.
That
has
like
both
versions
and
say,
like
you
know,
this
is
like
a
reality,
but
it
would
almost
make
more
sense
to
people
writing
instrumentation.
D
F
I
just
realized
we're
still
talking
about
ECS,
specifically
and
not
this
case,
so
so
all
these
or
we're
not
okay,
we're
talking
about
hotel
now
and
so
the
reason
system
ECS,
is
because
it
we're
thinking
about
maybe
integrating
with
them,
and
so
all
these
concerns
are
shared
between
the
two
but
regardless
of
UCS,
the
concerns
about
changing
semconf
breaking
customers
in
their
alerting
is
it
independent
VCS
is
a
concern?
Okay,
yeah!
Well,
what
do
did
we
ever
land
I?
D
Right
and
so
there
is
a
a
schema
translation
service
built
in
The
Collector
now,
and
we
do
have
like
a
theory
about
using
you,
know,
schema
versioning
and
the
ability
to
have
automatic
translations
to
allow
you
to
install
new
things,
but
still
have
the
old
stuff
work
if
you
want
it
to,
but
it
it's
not
super
tested.
That's
my
only
caveat
with
this
right
like
because
we
haven't
marked
anything
stable
and
we
haven't
tried
to
like
roll
one
of
these
things
out
yet
to
anybody.
D
F
And
we
use
this
we're
doing
it
theoretically
very
solid
plan
in
the
in
this
effort
right
here
right,
because
we're
trying
to
look
like
I
I
hear
the
concerns,
and
this
is
like
it
feels
like
it's
a
very
tight
line
to
walk
here
as
far
as
like
hey,
we
want
to
actually
stabilize
stuff,
but
we
want
to
break
anyone,
so
I
mean,
like
I
I.
Think
we're
like
bouncing
around
the
question
like
like
what
mechanism
does
open
Telemetry
provide
to
make
any
kind
of
change,
as
least
painful
as
possible
to
send
conf?
F
It
sounds
like
that
is
the
mechanism
you
just
mentioned
there.
As
far
as,
like
you
know,
like
this
internal
schema
translator
is
there
any
way
we
could
like
start
broadcasting
or
advertising
to
customers
of
our
system
that,
like
hey,
we
might
be
changing
some
stuff
with
these
non-mark
stable,
cementing
conventions,
and
here
is
the
methodology
we
would
like
you
to
use
if
you,
if
you're
Reliant
upon
any
of
the
existing
shapes,
does
that
make
sense
like.
G
F
It's
just
not
a
use
the
way
I
see
it
is
like,
like
implicitly,
we
kind
of
already
have
some
of
our
customers
perceive
implicitly
that
the
current
state
of
semantic
conventions
are
stable,
regardless
of
our
guidance.
That
is,
it
sounds
like
because
of
the
service
map
and,
like
you
know,
some
other,
like
troubleshooting
workflows
that
you
know
serial
here
had
mentioned
some
vendors
and
some
customers
are
relying
upon
the
current
state
and
trading
as
stable.
Even
if
it's
not
Market
stable
right.
D
Right,
but
that
that
gets
to
just
to
be
clear
that
gets
to
the
Crux
of
it,
like
Trask,
has
done
a
lot
of
work
with
the
HTTP
group
to
like
come
up
with
recommendations,
yeah
and
there's
like
a
set
of
them
for
marking
it
stable
today.
That
aren't
really
don't
really
make
any
breaking
changes
and
we're
fine
with,
and
then
there's
this
like
set
of
things
that
are
essentially
breaking
changes
that
we
would
prefer
that
if
we
merged
with
ECS,
maybe
we
would
do,
but
it
seems
like
no
one
from
that
group
is
recommending.
D
D
We
might
want
to
do
it
so
so
this
is
like
the
first
thing
we
would
run
through
this
system
would
be
something
like
these
HTTP
changes,
but
we're
still
in
this
Camp
of
like
we're,
not
gonna,
bother
with
these
breaking
changes,
unless
you
know
something
like
ECS
shows
up,
so
that
that's
that's
kind
of
why
we're
going
round
and
round
with
each
other.
In
this
conversation
right
now,
gotcha
I
was
just
like
we're.
F
A
D
D
For
me,
even
if
we
even
if
we
decide
we're
doing
this
right
and
we're
saying
like
phew,
we
didn't
mark
this
as
stable,
but
then
we're
gonna
make
these
changes.
We
actually
still
need,
in
my
opinion,
a
way
to
like
describe
this
particular
last
experimental
version
or
whatever
the
heck,
you're
gonna
call
it
frozen.
A
D
D
Like
there's,
because
it
does
feel
to
me
like
it's
a
big
enough
switch
that
we
want
it
to
be
really
like
simple.
For
our
end
users,
we
need
to
be
able
to
communicate
it
clearly
to
like
instrumentation
authors
like
it
seems
to
me
like
we
would
have
like
for
each
semantic
convention
like
two
versions
in
the
spec
for
a
long
time.
If
we
decide
to
do
no.
C
This
is
crazy,
so
put
us
back
on
the
ground
saying
this
is
a
direction
and
it
made
the
reality
that
currently
we're
doing
some
math
and
we'll
be
responsible
for
the
mess
over
the
next,
maybe
a
year
and
two.
But
if
we
start
with
the
the
point
where
we
don't
know
how
to
solve
this
whole
problem
and
let's
wait
and
just
shape
the
stable
of
a
shaped
version
and
wait
for
the
problem
to
be
solved
by
some
alien
after
200
years.
That
will
never
happen
exactly.
F
D
Understand
what
the
instrumentation
they
installed
is
going
to
give
them,
and
if
we
just
like
hide
all
that,
because
when
they
go
look
at
the
spec,
it
shows
a
bunch
of
like
future
ideal
ECS
merge
stuff,
but
that's
not
what
our
instrumentation
actually
produces.
I,
don't
know,
like
that's
all
I'm
saying
like
I'm,
just
thinking
about
taking
on.
F
D
F
A
It
yes,
the
real
surreal
I
think
put
it
the
best
is
this
yeah
reputation
of
Hotel
could
be
damaged
right,
yeah.
B
The
people
who
have
done
these,
who
have
used
our
semantic
conventions-
they
are
the
people
who
have
made
open
Telemetry
successful.
They
are
the
early
adopters
who
have
evangelized,
open,
Telemetry
awesome
and
they
put
their
career
pass
on
it.
Because
people
were
saying
you
should
buy
your
inexpensive
proprietary
tool
until
we
have
to
love
them
or
to
make
their
and.
F
Okay,
so
can
we
just
can
actually
I
didn't
be
like,
let's
test
our
methodology,
I
know,
you're,
saying
like
a
HTTP
here
is
gonna,
be
the
first
run
through,
but
like
let's
just
like
I'm,
not
sure
how
much
more
constructive
this
conversation
will
be
until
we've
actually
tested
our
proposed
methodology
for
making
transitions
seamless.
You
know
I.
F
B
D
D
Like
got
the
adoption
that
that's
the
whole
point,
that's
the
whole
point
it's
like
we
just
have
to.
If
we
decide
we're
gonna
do
this,
it's
actually
a
really
big
deal
and
we
have
to
think
it
through
and
if
we
don't
merge
with
ECS
I'm,
just
noting
that
we
would
not
actually
do
any
of
that
like
we
wouldn't
do
it.
So
that's
that's
my
main
point.
That's.
D
A
No,
no
so
I
threw
more
looking
at
the
HTTP
stuff
of
what
we
need
to
Mark,
stable
or
not
and
wondering
if
we
should
say
anything
about
nested
fans.
A
For
example,
you
know
hdb
service
span,
we
could
say
HTTP
service
bands
should
not
be
nested
under
the
idea
that
they
don't
really
provide
much
value.
The
first
HTTP
service
band
coming
in
is
usually
the
most
interesting
and
downstream
ones
could
be
suppressed.
E
A
So
yeah
so
I
guess
that's
where
I
would
say
should,
instead
of
a
must.
A
A
A
E
E
Required
now
results
to
find
the
solution
for
suppression
problem
right,
but
we
don't
enforce
anything
on
the
instrumentation
because
they
can't
well,
unless
it's
the
case,
where
you,
for
example,
have
a
middleware
and
controller.
And
then
you,
you
get
a
guidance
that
you
don't
instrument.
Both
you
just
instrument
the
outer
one
right.
So
in
the
sense
it
it
can
help.
Even
the
single
instrumentation
foreign.
A
Okay,
but
that's
probably
not
something-
that's
and
I
guess
I
might
have
still
been
thinking
from
a
consumer
perspective
of
what
consumers
can
expect
when
I
wrote
this
and.
D
D
Of
these,
these
nested
span
issues.
They
come
from
a
combination
of
instrumentation
being
installed
right.
That's
that's
kind
of
like
why,
for
me,
it's
a
little
tricky
to
say
something
about
it
in
the
semantic
conventions.
It's
almost
more
like
an
operational
concern
of
the
sdks
in
our
installers
and
stuff,
like
that.
A
Cool
I'm,
going
to
probably
just
close
it
with
I'll,
add
some
feed
the
feedback
here
on
this
one,
how
about
exceptions
so
like
I?
Can
the
Java
instrumentation
today,
for
example
the
HTTP
server
instrumentation,
if
exception
bubbles
up
to
it,
you
know
or
goes
through
error
Handler
exception,
Handler
it'll
record
that
exception
onto
the
server
span
same
on
the
client
span,
but
I'm
actually
not
sure,
that's
very
useful.
We
actually
in
our
distro.
We
suppress
that
because
it's
noisy
and
they
generally
Bubble
Up
and
are
captured
somewhere
else.
A
E
A
So,
but
would
we
be
able
to
release
Java
http
instrumentation
as
stable
or
once
we
release
that
as
stable,
and
we
are
capturing
exceptions
on
the
service
bands?
A
The
okay
and
then
the
other,
maybe
related
to
that
is
there's
the
exceptions.
Oops
I
just
have
it
so
again
back
to
that
example
of
java
instrumentation
producing
exception
telemetry.
Can
we
Mark
the
Java
http
instrumentation
as
stable,
without
marking,
without
this
doc
being
stable.
A
A
A
I
think
this
here
would
attribute
keys.
A
E
So
I
should
make
you
capture
an
exception
right,
so
first
we
don't
require
capture
it
right.
Second,
one
assuming
you
capture
an
exception.
Would
it
be
breaking
this
top
capture
this
or
would
it
be
breaking
to
if
it
changes
the
parent
right
and
goes
from
one
place
to
another
I
think
in
terms
of
what
we
Define
so
far,
neither
would
be
breaking.
A
So
I
I'm
with
you
on
the
the
relationship
between
like
the
event
and
the
span,
the
exception
and
the
span,
the
linking
but.
E
E
A
E
Yeah
I
see
so
assuming
we
have
an
instrumentation
that
stems
database
and
HTTP
attributes
on
the
same
span.
Oh,
we
will
never
release
it
as
table
yet
because
it
realizes
database,
okay,
yeah.
So
practically
we
need
to
stabilize
exceptions.
A
A
Yeah
Ted:
do
you
have
thoughts
on
marking,
HTTP,
semcon,
stable
and
but
not
being
able
to
release
stable,
HTTP
instrumentation
until
we
also
Mark
exception,
some
conf
stable.
D
D
I
mean
like
we're
we're
going
through
and
we're
trying
to.
The
reason
why
we
have
this
working
group
and
not
just
a
bunch
of
individual
conventions,
is
because
HTTP
is,
like
I,
wouldn't
say,
tip
of
the
sphere.
It's
it's
sitting
on
the
hood
of
the
car,
getting
all
the
bugs
in
its
face
right
like
it's,
it's
just
in
front
of
everything
else,
and
so
we're
discovering
some
of
these
other.
Like
fundamentals.
D
Like
oh
look,
exceptions,
you
know
so
my
My
Hope
Is
that
in
part
of
getting
HTTP
out
the
door,
we
will
like
hit
most
of
these
problems,
and
so
the
other
semantic
conventions
will
go
smoother
That's
My
Hope,
but
my
feeling
is
like
yeah.
Why
would
we
like
create
more
pain
and
suffering
for
ourselves
by
having
like.
D
A
Right
I
think
so.
Riley
was
proposing
that
just
to
try
to
keep
the
HTTP
stuff
fast-tracked
yeah
that
I
I
will
yeah.
D
I
think
it
just
maybe
circles
around
to
another
issue
that
they
we
have
to
figure
out
with
HTTP,
which
is
actually
in
practice
updating
all
of
this
instrumentation
right,
because
once
we
do
decide,
we've
got
like
the
stable
versions
of
these
things.
We
don't
really
want
our
instrumentation
all
hanging
out
on
the
like
random,
ass,
various
old
unversioned
things
that
are
out
there,
so
you
know
figuring
out
in
practice.
How
do
we
actually
like
do
the
work
of
getting
them
all
updated?
We
have
to
figure
out,
but
I
I
kind
of
agree
with
Riley.
D
G
A
G
A
And
I'll
put
together
we're
actually
meeting
this
afternoon,
the
HTTP
group,
so
we'll
chat
through
some
more
stuff
and
I'll
put
together
a
list
of
things
to
try
to
get
get
spec
attention
tomorrow.
Awesome.