►
From YouTube: 2023-02-16 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
C
D
A
A
Is
not
going
to
make
it
she's
joining
the
messaging
Sig
it's
at
the
same
time.
A
So
yeah
we
may
as
well
start
yeah
I
wanted
to
touch
base
and
on
these
three
that
are
General
in
the
general
semantic
convention,
but
we
have
marked
as
blocking
HTTP
stability.
A
Maybe
we
can
start
with
this.
One
is
probably
the
easiest.
A
B
Oh,
that
one
is
not
even
stable,
yet:
okay,
I
I,
guess
we
should
because
otherwise,
what
does
it
mean
if,
if
we
Mark
anything
that
depends
on
it
stable
right.
A
A
A
So
yeah
so
for
this
one
in
particular,
what
I'm
imagining
is
and
I
can
send
a
PR
for
that
would
be
if
I
wanted
to
run
by
you
know.
First
is
basically
something
similar
metric
instrument,
requirement,
level
and
I.
Think
at
this
point
we
would
just
have
work
required
well
on
the
HTTP
I
think
we
only
need
required
and
optional.
E
I
feel
like
there's
not
going
to
be
a
huge
difference
between
them,
but
I'm.
Okay,
if
we,
you
know,
if
you
only
add
required
and
optional,
but
we
tacitly
agree
and
kind
of
put
in
the
pr
that
we're
doing
that,
because
those
are
the
only
two
we
need,
but
if
we
add
more,
they
will
have
the
exact
same
meaning
as
what
exists
for
attributes.
I
just
want
us
to
explicitly
call
that
out
like
we
are
not
trying
to
diverge
right,
yeah.
B
B
One
thing
to
point
out
is
that
optional
might
be
misleading
because
it
it's
more
it
it's
more
saying
opt-in
rather
than
than
being
optional,
because
the
definition
says
any
like
open,
Telemetry
provided
instrumentation
should
not
collect
this
Telemetry
unless
the
user
explicitly
opts
into
it.
B
I
think
we
have
that
for
things
that
are
considered
sensitive
and
either
high
cardinality
or
or
sensitive,
where
you
maybe
don't
want
that
in
your
in
your
showing
up
in
your
backend,
if
it's
not
capable
of
having
access,
control
and
such
so,
maybe
when
we
think
about
stabilizing
it,
we
might
also
want
to
consider
the
the
naming,
if
it
shouldn't
say
opt-in,
because
I
I
think
the
optional
already
got
the
few
folks
that
it's
actually
saying
something
like
a
soft
discouraged
to
use,
and
only
only
if
you
explicitly
opt
in
then
then
it
should
be
connected.
E
Well,
I
think
what
that
means.
Trask
is
you
want
recommended,
and
maybe
we
should
probably
rename
optional
to
opt-in,
but
I
I
think
it's
fine
to
leave
it
as
optional
as
well
as
long
as
we
understand
what
the
meaning
here
is
right.
B
A
E
I
think
it
does,
but
I
don't
know
if
we
have
any
in
HTTP
where
it
does
right.
B
Great
but
it
could
say
something
like
if
whatever
your
your
measuring
is
readily
available,
then
go
ahead
and
measure
it,
but
if
you
would
have
to
calculate
it
first
or
use
some
some
expensive
means
of
of
getting
a
hold
of
the
value,
then
you
would
not
need
to
to
collect
it.
That's
one
example
that
we
could
put
as
conditionally
required,
for
example,.
E
It's
it's
kind
of
like
HTTP,
latency,
conditionally
required
is
the
HTTP
route
right.
If
you're
able
to
calculate
it,
it's
really
valuable.
It's
conditionally
required
it's
not
optional.
It's
not!
It's
not
just
recommended.
It's
like
I
think
it
should
be
conditionally
required,
for
example,
that
attribute
what
you
could
say
possibly
is
the
whole
latency
metric
is
conditionally
required
on
HTTP
routes.
E
So
so
you
could
say
for
HTTP,
like
you
know,
we
should
have
a
metric
that
calculates
you
know
queue
sizes
or
something
right
unless
you're
using
HP
instrumentation
that
doesn't
have
cues,
in
which
case
you
know,
this
is
only
conditionally
required
for
those
that
would
or
retries
right.
Maybe
the
there
there's
a
retry
metric
that
only
exists
if
your
implementation
does
abides
by
retries
or
something
I,
don't
know
you
get
what
I'm
saying
right
like
that's
that's.
What
initially
required
would
be.
A
Okay,
I
think
I
got
enough
to
send
a
PR
and
get
more
feedback
on
that.
E
Oh
I
was
gonna,
say
the
because
I've
been
waiting
to
talk
about
it,
since
you
put
it
in
the
agenda.
The
one
around
metric
stability
in
December.
We
had
tons
and
tons
of
discussions
around
what
metric
stability
is
and
I
have
a
pending
PR
to
update
the
spec
with
metric
stability,
things
that
I'm
going
to
send
out
effectively.
You
know
the
tldr
here
is
like
we're
not
including
histogram
buckets
and
stability.
E
There's
a
set
of
things
we're
going
to
allow
that
to
change
and
that
sort
of
thing
we
have
that
document
that
we
walked
through
and
had
the
discussions
with
talked
with
the
spec
committee
I'm
going
to
make
a
PR
there.
So
you
can
put
an
A
on
me
that
should
be
out
and
I've
been
kind
of
overloaded,
so
I
apologize
it
didn't
hit
earlier,
but
that
I
feel
like
we
have
agreement
from
this
group
how
to
resolve
that.
We
just
need
to
get
it
passed
back.
Approval.
A
E
E
If
I
recall
correctly,
there
there's
a
few
things
that
either
aren't
accounted
for
in
the
well.
We
had
this
discussion
specifically
on
spand
name,
right,
I
do
think
changing
span.
Name
is
breaking
me.
A
E
Have
no
way
to
really
interact
with
spending
with
the
Telemetry
schema
thing
to
make
it
not
breaking
right,
so
I
think
we
probably
want
to
just
directly
outline
that
that's
breaking
and
such
for
Trace.
E
Is
adding
an
attribute
breaking,
don't
think
so
for
Trace?
Generally,
that's
kind
of
okay
for
metrics.
You
know
we
have
all
those
caveats
with
metrics
of
like
if
you're
changing
the
number
of
Time
series,
it's
a
breaking
change.
E
Yes,
so
this
is
again
one
reason
I've
been
slow
here
is
I'm
trying
to
make
this
change.
How
the
spec
looks
when
it
specifies
this
stuff,
but
if
you
look
under
where
is
it
Telemetry
stability?
E
E
Semantic
convention
stability
is
outlined
under
versioning
instability.md,
and
this
one
talks
about
changes
to
semantic
conventions.
Specification
are
allowed,
provided
the
changes
can
be
described
by
schema
files.
The
following
changes
can
currently
be
described
as
schema
files
and
are
allowed,
and
it
says,
renaming
span
metric
log
resource
attributes,
renaming
of
metrics
renaming
of
span
events
as
far
as
I
know,
though,
events
don't
have
a
name
of
attributes
so
that
last
one
is
kind
of
funny,
because
the
name
is
I.
Think
event.name
is
the
attribute
for
the
name.
E
So
anyway
whatever
and
then
it
says
all
such
changes
must
be
described
by
open
Telemetry
schema
format.
So
I
I
want
to
fix
this
because
again
right
now,
this
would
not
allow
span
name
changes
right,
but
one
thing
we're
not
enforcing
we're,
not
enforcing
histogram
bucket
boundaries
right
we're
allowing
those
to
change.
Specifically,
we
made
that
decision
and
so
like
I,
think
there's
a
set
of
things
that
are
outside
of.
E
E
E
Doesn't
it
right
so
this
is
why
I've
been
having
trouble
making
this
PR
to
the
spec
is
because
I
feel
like
we
need
a
place
that
outlines
what
does
semantic
conventions
enforce
and
what
don't
they
enforce
right
and
to
some
extent
our
stability
is
like
whatever
we
Express
in
that
yaml.
Here's
the
rules
around
what
can
change
and
what
can't
change
and
that's
what
this
section
here
should
be
right
now.
E
Do
we
want
to
include
what
the
hint
API
should
have
for
histogram
bucket
boundary
in
it
I
think
Yes
actually
I
think
that's
a
useful
thing
to
add.
Once
the
hint
API
exists
is
default
set
of
bucket
boundaries.
E
However,
I
also
think
changing
that
default
set
doesn't
break
instrumentation.
E
So
that's
anyway,
that's
why
I've
been
having
trouble
with
my
PR,
so
recommendations
are
very
welcome
for
how
we
can
address
this.
But
my
plan
is
to
address
those
two
sections
and
kind
of
add
more
verbage
about
like,
what's
included
in
semantic
inventions,
what's
outside
the
scope
of
semantic
inventions
and
then
address
what's
allowed
to
change
right.
E
B
E
I
can
I
wish
we
hadn't
done
that,
but
I
kind
of
understand,
because,
if
you
think
about
it
right,
there's
a
different
sampler
between
behind
the
two
and
and
those
use.
Cases
are
fundamentally
important
when
I
have
events
on
a
span.
They're
guaranteed
to
be
sampled
with
this
band,
regardless
of,
if
they're,
like
info
debug
error.
If
I
have
events
on
logs
I'm,
probably
filtering
info,
debug
error
and
globally
right
so
I
get
that
they're
different
because
of
the
sampling
decisions.
But
man
doesn't
hurt
my
brain.
A
So
Josh
do
you
think
it
makes
sense
to
wait,
wait
for
this
to
try
to
do
this
work
until
you
send
this
PR.
C
A
You
think
there's
overlap
there,
or
do
you
think
they're
independent
enough
that
it
makes
sense
to
try
to
move
forward
on
this
in
parallel.
E
I
think
there
will
be
a
lot
of
overlap.
I,
don't
think
you're
going
to
be
able
to
send
a
PR,
well,
I!
Think
if
we
okay,
if
we
both
send
PRS
they're,
going
to
conflict
a
lot
with
each
other
in
this
duplicate
work.
But
if
you
independently,
want
to
go
through
the
trace,
Proto
and
say
here
are
the
aspects
that
will
be
enforced
by
semcon.
But
here
are
the
aspects
that
won't
be
I,
think
that's
still
a
valuable
exercise.
E
A
E
Yeah,
so
I
I
think
that
if
you
can
make
progress
on
that,
I'll
try
to
finish
the
metric
side
and
get
that
PR
out
with
all
the
spec
kind
of
updates
for
giving
us
a
section
to
kind
of
describe
this.
And
then
hopefully,
when
that
lands
you'll
be
able
to
just
put
Trace
in
there
right
away.
E
D
D
A
This
issue,
about
other
things
in
general,
that
we
need
to
mark
people.
A
These
I
think
were
aware
and
sort
of
prepared.
Now
these
are
we
still
thinking
yaml
a
yaml
attribute
or
to
Mark
something
as
stable.
B
E
So
we
went
through
I
think
we
talked
about
this
in
the
thing.
Basically,
the
Otep
that
you
see
from
Daniel
I
think
is
the
one
that's
likely
to
work,
but
also
it
doesn't
solve
the
issue.
We
had
a
previous
Otep
that
we
think
solves
the
issue,
but
it
won't
work
in
practice.
A
E
The
instrumental
that
was
the
notion
of
having
experimental
tags,
yeah
and
and
defining
them
as
experimental,
don't
think.
That's
actually
going
to
work
because
in
practice,
if
you
take
a
take
a
name
and
start
using
it
and
anyone
sees
it,
it
needs
to
kind
of
retain
that
going
forward
or,
like
you
have
breaking
changes.
Really
weird.
You
can't
recycle
names,
you
can't,
you
know
we
can't
change
the
meaning
of
a
name
once
it's
taken
when
we're
a
full
standard
committee.
E
So
what
I
would
suggest
here
is
we
probably
want
to
take
span
General
and
stabilize
the
pieces
of
it?
You
need
and
we
can
move
everything
else
out
of
it
into
a
like
up-and-coming
recommendations
for
span
General
right,
so
I
do
think
we
should.
We
can
reserve
the
names
effectively
and
say
this
name
would
mean
this,
but
we
haven't
stabilized
it
yet.
So,
whatever
you
need
for
http
cemconf
we'd
get
in
Span,
General
we'd
get
it
marked,
we
get
it
marked
stable.
E
We
make
an
experimental
file,
and
this
is
again
because
we
don't
have
an
Otep
proposed,
so
we're
just
kind
of
making
this
up
as
we
go.
We
make
another
thing
called
span,
General
experimental
and
we
put
all
the
experimental
attributes
in.
There
would
be
my
suggestion
and
so
the
idea
being
things
in
Span
General.
You
can't
change
the
meaning
of
the
name,
even
if
it's
an
experimental,
but
we
aren't
sure.
A
A
So
the
like,
we
could
leave,
say
sections
that
are
and
stay
experimental
here,
but
in
like
a
whole
sec,
I
guess
that's
I'm,
not
clear
on
when
a
document
is
mixed.
Do
we
don't
mix
it
within
a
given
section
like
this.
E
And
then
that
way
like
when
I
do
Cogen,
it's
very
apparent
to
me
if
I'm
picking
up
the
stable
or
the
or
the
experimental,
in
fact,
maybe
we
wanna
make
a
pass
and
just
make
all
the
ammo
files
Dash
experimental
initially
and
then
when
we
stabilize,
we
move
them
to
be,
but
that
would
break
so
many
people.
B
I
see
one
one
larger
problem,
even
that
we
have
I
think
just
a
rough
guess,
but
probably
less
than
half
of
the
instrumentation
we
have
out.
B
There
is
actually
like
supplying
the
schema
version
that
they
that
they
adhered
to,
and
so
you
can't
really
tell
when,
on
the
back
end,
you
receive
some
data
and
then
it
has
some
HTTP
attributes
on
it,
if
it,
if
those
were
the
old
ones
or
the
new
ones,
if
they
were
stable
at
the
time
or
if
or
if
they
were
experimental,
but
the
fact
was
still
used,
that's
something
we
will
also
have
to
push
for
it
that
we
are
good
citizens
and
role
models
and
Supply
the
schema
version
everywhere,
because
if
we
don't
do
it
then
or
say
end
users
wouldn't
want
to
it.
E
A
So
one
the
third
phase,
the
the
stability
working
groups,
pertense
document,
the
third
aft
is
after
stability
is
going
around
and
updating
all
of
the
hotel
instrumentation
to
conform
with
the
stable
spec,
so
supplying
Supply
in
a
schema
version
at
that
point
is
something
that
the
stability
working
group
could
tackle.
A
Do
you
think
Armin
that
that's
enough
and
that
then
backend
could
infer
that?
Oh,
if
you
didn't
Supply
the
schema
version
you're
not
on
the
stable
version.
B
I
think
we
even
called
it
out
in
the
Telemetry
stability.md
that
you
had
earlier.
It
said
it
said
that
by
definition,
if
there
is
no
schema
version
in
there,
it's
experimental,
it's
unstable,
I
think
if
I
recall
correctly,
because
also,
if
you
don't
have
any
any
version
in
there,
you
you
don't
know
how
to
transform
things.
A
B
E
I
feel
like
we
can
Market
stable,
though
like
I,
don't
see
any
I.
Don't
know
yeah
like
this.
Is
the
guidelines
we're
using
for
how
we
Define
attributes,
so
we
should
I
feel
like
we
should
just
Market
a
stable
and
I'm
willing
to
just
literally
make
a
PR
that
slaps
at
this
table
and
I
think
we
showed.
B
That
the
first
go
ahead,
oh,
go
ahead.
I
think
we
should
first
think
about
the
or
finish
the
proposal
on
how
to
come
up
with
experimental
conventions.
If
we
would
I
don't
know
in
the
end,
still
come
up
with
x,
dot,
something
and
I
think
at
some
point.
B
Someone
mentioned
that
the
that
the
application
itself
should
use
its
own
namespace
to
show
it's
not
an
an
auto-defined
semantic
convention,
but
something
that
the
the
organization
or
the
developer
came
up
with
in
their
own
app
that
it
should
start
with
app
dot
something
or
custom
dot,
something
there
are
still
a
few
things
to
to
think
about.
Well,.
E
Okay,
so
I
think
you
know
Daniel
really
convinced
me
not
to
go
with
experimental
attributes.
E
Sorry,
with
an
experimental
attribute,
namespace
like
we,
we
have.
We
have
evidence
from
the
the
HTTP
spec
of
of
that
like
that,
doesn't
work
in
practice
effectively.
What
happens
is
those
experimental
attributes
remain
forever
and
they're
set
in
stone?
So
it's
better
to
have
this
like
I
can
go
request
an
attribute
with
a
particular
naming
convention.
If
no
one
else
has
grabbed
it,
I
own
it
and
I
own
the
semantics
and
to
basically
have
maybe
maybe
that
ends
up
with
some
things
having
poorer
names
than
they
could
otherwise
have.
E
But
you
end
up
with
the
stability
that
you
actually
need
for
specification,
so
I
think
like
given
what
we
learned
from
that
I
just
I,
don't
think
we
will
ever
have
an
experimental
namespace
if
we
were
going
to
have
one.
We
could
probably
add
it
to
that
document
without
breaking
it
as
a
thing
that
we
add
right
so
I,
don't
think
that
needs
to
be
defined
in
attribute
naming
an
application
name
space,
though
that
absolutely
is
a
good
point.
E
I
still
think
we
can
add
that
to
attribute
naming
later,
like
I,
don't
think
it
changes
the
stability
of
it
unless
we
think
we're
going
to
require
an
Hotel
namespace
on
all
Hotel
things
like
that's.
That
would
be
my
only
concern.
I,
don't
I
feel
like
that.
Would
we
shouldn't
do
that
either
like
require
Hotel
dot
on
anything
from
semconf?
That
just
seems
wrong,
but
opening
up
an
application
namespace
where
applications
can
make
their
own
conventions
that
feels
okay,
I,
don't
know
what
do
you
think.
B
Yeah
I
think
we
can
really
restrict
developers
to
say
that
whatever
you
do
in
hotel,
you
always
have
to
prepend
an
app
dot
to
it,
because
it
would
be
like
why
why
should
I
I
I
feel?
This
is
something
that
this
schema
should
take
care
of,
that
you
that
you,
you
say:
okay,
I
have
these
these
attributes.
They
are
coming
from
the
official
IO,
open,
Telemetry,
something
schema
and
then
I
I
derived
from
that
with
my
own
conventions
like
com,
dot,
Armin.
B
What
not
and
there
I
add
my
own
attributes
to
it,
but
still
we
we
would
like
the
mapping
of
is
the
net
peer
name
coming
from
this
one
or
the
other
one.
That
could
still
be
a
tricky,
so
I
think
it
would
all
be
solvable
in
in
theory,
but
for
now
it's
like
just
science
fiction,
I
think
yeah.
E
I
think
there's
still
time
for
us
to
figure
out
what
happens
in
practice,
but
theoretically
schema
URL
does
solve
all
this
and
that's
one
reason
we
require
it.
When
you
get
a
meter
or
a
tracer
I
should
say
we
don't
require
it,
because
we
can't,
because
that
would
have
break
in
broken
compatibility,
but
we
have
it
there.
E
When
you
get
one
I
still
feel
that
that
is
a
change
we
can
make
without
breaking
compatibility,
though
so
I
still
think
like
I
I'm
more
than
happy
to
just
open
a
PR
that
marks
attribute,
naming,
is
stable
and
just
see
what
happens
because
I
I
don't
see
it
changing.
E
B
I
think
I
mostly
agree.
I
would
need
to
to
read
it
again
because
I
haven't
read
that
part
in
a
long
long
time,
but
it
also
says
you
shouldn't
reuse
names
and
I.
Think
the
experimental
one
says
once
you
register
a
name.
If
you
want
to
have
a
like
different
semantics
to
it,
you
will
need
to
find
a
new
name
and
such
I
think
it.
It
fits
fits
together
quite
well.
B
And
I'm
really
glad
that
Mia
collected
all
of
these
dependencies,
because
I
think
we
were
not
aware
of
how
many
things
will
be
or
need
to
be
marked
stable
for
our
very
first
and
comfort
to
be
Market
Stable
online.
E
E
E
I
mean
I
I,
guess
I
didn't
miss
it,
because
I
opened
the
the
bug
about.
We
should
outline
what
stability
means.
I
just
forgot
that,
because
it
I
did
all
that
in
what
November.
A
Okay
I
see
so
this
one
is
stable,
though,
that
one
is
stable.
It's
stable.
E
In
schema,
transformation
still
experimental,
partly
because
I
think
like
just
overall
so
we're
all
aware,
you
know
schema
convention,
we
think
solves
a
lot
of
issues,
but
is
a
huge
investment
right.
It
is
a
directional
shift
that
requires
vendor
buy-in
requires.
You
know
us
to
do
a
lot
of
work.
E
One
of
the
questions
with
schemas
was:
it
enables
us
to
do
a
lot
of
good
stuff
with
Telemetry,
where
we
feel
like
we
can
Mark
things
stable
and
not
break
users,
but
it
depends
on
the
adoption
of
the
schema
and
whether
or
not
people
use
it.
So
the
reason
it's
not
stable
is
partly
because
we're
not
sure
that
we
have
all
the
things
we
need
in
it,
but
also
partly
because
we
wanted
to
see
if
there's
industry
momentum
around
the
adoption
of
schema.
E
B
That
makes
sense
yeah
it's
a
bit
of
a
chicken
and
egg
problem,
though,
because
as
long
as
it's
not
stable,
then
then
vendors
might
be
hesitant
to
invest
in
implementing
it
yeah,
but
yeah.
That's
that's
something
that
we
are
always
facing.
Are
you
aware
of
any
beckons
that
do
transformation
based
on
schema
already
today,
because
there
is
no
reference
implementation
either
right?
No.
E
And
that's
why
my
opinion
is
we?
We
would
need
to
do
that.
Investment
first
in
The
Collector,
with
this
experimental
schema
translation
thing
with
that
PR
I
put
together
for
sdks
to
do
it
on
resource,
where
exporters
can
actually
ask
for
a
particular
semantic
invention
version
of
resource
attributes.
E
So
they
that
you
don't
have
this
mismatched
version
hell
between
exporter
and
resource
detector,
right,
like
I,
think,
there's
I
I
feel
like
schemas
are
not
implemented
in
open
Telemetry.
Yet
we
put
enough
in
the
spec
that
we
can
Implement
them,
but
we're
missing
a
whole
bunch
of
stuff
around
them,
I'm.
E
The
risk
is-
and
this
is
why
we
never
Market
stable
I.
Think
in
practice
is
there's
that
back
of
the
Mind
here
that
this
won't
be
adopted
and
will
do
all
this
work
for
nothing.
And
then
we
still
can't
actually
use
schema
Transformations
for
versioning
stability,
because
no
one
uses
them
in
practice.
E
I
think
that's
the
like
back
of
the
Mind
fear
behind
why
this
isn't
stable
I
feel
like
it's
we're
at
the
point
now,
where
we
have
enough
stuff
in
we
have
enough
stuff
moving
that
we
should
just
proceed
as
if
it's
going
to
be
viable
and
if
it
turns
out
the
schema.
Transformations
are
not
viable,
we're
not
in
any
worse
spot
by
having
locked
down
names
for
things,
I
think
we're
still
in
better
position
than
we
were
previously
so
I'm.
Okay.
E
Personally,
let's
also
see
if
we
can
mark
that
document
as
stable
going
forward.
I
think
we
might
want
to
take
a
second
look
at
where
it
sits
and
maybe
Mark
some
of
the
specific
schema
Transformations
as
experimental.
But
overall
the
document
itself
of
there
will
be
schema.
Transformations
I
think
is
fine.
B
B
I
mean
even
if
vendors
don't
support
it,
if
we
can
show
with
the
collector
process
so
that
that
it's
possible
and
and
you
can
just
use
it
with
a
collector
and
it
even
works
without
without
Windows
support
for
those
who
who
do
music
collector
and
if
I
don't
know.
E
Yeah
yeah
I
think
so
I
guess
what
I
want
to
do
is
proceed
like
we
should,
when
we're
nervous
about
something
like
that.
The
worst
thing
we
can
do
is
hedge
our
bets.
Because
then
what
happens
is
we
have
to
implement
something?
That's
guaranteed
to
fail
right
instead,
I
say
we
we
go
all
in
and
say
we
think
this
is
going
to
work,
we're
going
to
continue
to
specify
as
if
it
works,
we're
going
to
build
the
components
to
make
it
work
and
we're
going
to
get
vendors
to
back
it.
E
That's
the
only
way
it
can
succeed
if
we
like
the
hedging
the
bets
of
like,
let's
keep
it
experimental
and
like
keep
seeing
if
people
will
adopt
it
effectively
that
guarantees
its
death.
E
In
my
opinion,
right
so
I'd
rather
say,
let's
Market
stable
and
let's
invest
in
all
those
tools.
Let's,
let's
get
some
work
behind
it.
My
plan
for
those
tools
was
actually
going
to
be
code.
Gen
client-side,
not
collector
side
of
what
I
would
invest
in
myself,
but
we're
not
ready
for
that.
Yet
we
have
a
lot
of
things
to
do,
which
is
why
I
haven't
done
anything
yet
on
mine,
but
I
do
think
I
I
personally
think
we
need
to
invest
there,
yeah
I,
don't
know
what
would
it?
What
do?
E
What
do
both
of
you
think?
What
do
you
think
we
should
do
going
forward
here?
Like
I,
said,
I
can
talk
to
tigrin
and
then
try
to
put
a
PR
that
marks.
This
is
stable
with
specific
Transformations
as
experimental,
because
we're
basically
saying
we
won't
make
transforms
that
work.
We
know
that
this
is
a
viable
thing
to
do.
We
just
don't
have
implementations
of
the
transforms
yet.
B
I
think
the
the
definition
of
the
Transformations
is
simple
enough
to
assume
with
enough
confidence
that
it
will
be
doable.
I
mean
the
the
renaming
of
attributes.
That
sounds
like
a
simple
thing,
something
you
a
human
can
do
today
by
reading
a
schema
file
and
then
and
then
writing
a
file,
a
configuration
for
the
transform
processor,
but
the
split
metrics
I,
don't
know,
but
the
the
attribute
part,
the
one.
That's
that
we
are
interested
in
for
HTTP.
That
on
sounds
like
a
no-brainer
to
me.
E
Okay,
Trask
I
sent
you
a
link
to
the
actual
schema
processor.
It's
in
contrib
right
now,.
E
Yeah,
like
they're
still
working
on
it,
it's
still
not
stable.
It
still
doesn't
necessarily
do
everything
they
want.
I
think
it's
just
like
the
first
setup
of
it.
If
you
look
at
what
it
does,
you
know
it,
you
can
pre-cache
certain.
E
Pull
in
the
latest
convention
and
then
it
can
do
that
transformation,
so
I
think
according
to
Tigger
and
it's
not
stable
enough
to
be
launched.
So
the
question
is,
you
know:
should
we
wait
to
mark
the
entire
Transformations
document
is
stable
until
that
pit
of
code
is
ready
and
we
are
comfortable
with
it.
Or
can
we
Mark
part
of
the
schema
transformation
documents
to
stable,
because
enough
has
been
proven
in
that
code
that
we're
sure
we
can
stabilize
components
of
the
document
later.
A
This
this
particular
doc
doesn't
describe
the
actual
translations
right.
A
E
Yeah
I
I
think
we
should
Mark
rename
attribute
stable.
Specifically,
we
don't
have
to
mark
the
rest
of
them,
but
I
think
rename
attributes
we
should
Mark
stable
because
of
how
much
we
rely
on
it
in
other
pieces
of
the
spec.
B
And
we
already
introduced
like
a
lot
of
pain
to
everyone
consuming
HTTP
instrumentation
today,
because
we
we
break
quite
a
few
things
on
on
somebody.
Late
notice,.
B
One
thing
I'm,
not
sure
about
is
I
think
we
said
hey,
there
is
the
specific
attribute
and
from
now
on
use
the
generic
attribute
instead
and
I,
don't
know
if
we
already
did
that
or
if
we
were
just
discussing
it,
but
there
were
discussions
whether
that
could
be
done
with
a
rename
transformation,
but
that
one
would
be
irreversible,
because
you,
you
can
only
apply
it
in
One
Direction,
not
in
the
other,
so
I
I
don't
know
if
that's
if
that
would
deter
us
from
from
stabilizing
it
or
if
we
need
a
an
extra
transformation.
D
B
B
Rename
it
right
so
maybe
it's
even
even
fine
I
need
to
think
about
it.
If,
if
someone
sent
that
one
in
the
past,
then
it
was
not
from
from
our
schema,
probably
it's
out
of
scope
for
what
we
need
to
worry
about.
A
I'm
curious,
though,
to
like
say
our
scheme
is
supposed
to
be
reversible
like
because
our
plan
is
to
use
useragent.original
for,
like
there's
an
open
PR
for
Cosmos
to
use
this,
and
at
that
point,
once
we
have
two
people
using
that
your
point
about
it
not
being
reversible,
holds
I.
Think.
D
E
About
it,
this
way
drask
it's
like
a
Java
interface,
if
I'm
using
version
one
of
the
interface
I,
don't
know
about
new
attributes,
so
I
need
to
be
able
to
take
the
the
new
attributes
and
convert
them
to
the
old
ones
that
I
would
have
used.
E
E
A
So
if
somebody
is
using
new
instrumentation,
say
they're
using
1.20
instrumentation
and
that
instrumentation
is
emitting
user
agent
original
The
Collector.
Can
people
ask
the
collector
to
back
Port
that
schema
because
they
want
to
let
they
want
schema
119.?
Yes,
so
how
would
the?
How
would
it
know
whether
to
map
user
agent
original
back
to
http
user
agent
or
to
Cosmos
user
agent.
A
E
It
will
create
HTTP
user
agent
for
customers
from
user
agent.original
and
if
Cosmo
also
has
a
thing
that
said,
user
agent
original
is
Cosmo
user
agent.
It
would
also
create
Cosmo
user
agent
to
user
agent
original
right,
because
the
idea
would
be
anything
that
the
previous
any
any
key
that
the
previous
version
expected
you
have
to
synthesize,
and
this
is
your
mapping
for
what
to
take
to
get
back
to
that
previous
thing
right.
So
all
of
the
keys
that
were
expected
will
show
up.
E
B
All
right
so
I
think
it's
actually
different.
So
if,
if
if
we
merge,
what
do
you
have
here
and
then
in
1.20
we
introduce
hey
with
Cosmo
now
also
please
record
usage
and
original
and
you
are,
it
would
not
go
into
the
schema
because
it's
not
a
introducing
the
new
attribute
is
not
something
that
we
we
would
reflect
in
the
schema
and
if
on
The
Collector,
you
would
convert
from
1.20
to
1.18,
because
your
consumer
expects
1.18.
B
Then
it
would
indeed
use
the
cosmo
user
agent
and
convert
it
to
http
user
agent,
but
your
1.18
consumer
doesn't
know
or
care
about
Cosmos,
so
it
it
wouldn't
break.
Because
of
that.
B
B
You
yeah
it's
a
tricky
topic.
If,
if
you
have
a
I,
don't
know
some
analyzer
that
that
presents
your
Cosmo
data,
then
it
would
just
not
expect
any
usage
in
any
way
anyways
it
just
wouldn't
be
there.
A
I'm
glad
yes,
I'm
glad
to
have
you
on
this
stability
working
group.
E
E
This
is
also
Java's
notion
of
stability
when
you
think
of
interfaces
and
like
how
it
does
linking
and
stuff
so.
The
key
here
is.
We
should
allow
as
many
changes
that
people
don't
notice
as
possible,
because
that's
how
you
evolve
and
make
things
better
and
there's,
there's
there's
a
concern
of
with
stability
right.
E
The
bug
bug
fixing
stability
right
if
I
change,
the
behavior
of
something
to
fix
a
bug,
I
could
break
user
expectations
in
a
way
that
really
upsets
them,
because
I'm
actually
changing
the
behavior
of
how
things
work
and
that's
where
things
get
really
really
fuzzy
with
stability
and
with
this
scheme
of
things
so
we're
enforcing
this.
You
know
if
you
only
look
at
the
attributes
that
we've
declared
we're
keeping
that
stable,
but
there
could
be
other
attributes
that
were
generated
or
synthesized
on
the
span
and
we're
not
enforcing
anything
about
them.
C
B
Yeah
we
we
all
know
that
I
think
that
you
that
there
is
undefined
behavior
and-
and
you
should
not
rely
on
it.
But
of
course,
if
it
comes
in
Hindi,
then
people
do
and
they
will
be
upset.
If
you
break
them
and
you
can
then
go
there
and
see
them,
we
told
you
you,
you
shouldn't
rely
on
it,
but
still
they
will
be
mad
at
you
and
not
themselves.
I
think.
A
So
far
this
one
then
Josh
I
liked
the
proposal
of
just
sending
a
PR
to
mark
it
stable
and
the
specific
file
format
ones
as
mixed
with
the
rename
as
stable.
E
Yeah
I'm
a
little
bit
nervous
because
we
don't
have
rename
implemented
in
that
collector
module.
E
So
what
I
do
like
the
idea
of
making
it
PR,
because
I
think
we
all
kind
of
understand
that
we
could
implement
it.
We
just
haven't
yet
what
I'm
nervous
about
is
whether
or
not
we
get
pushback,
because.
E
Yeah
anyway,
worst
case
scenario,
I'll
open
the
pr.
If
we
get
pushback
I,
might
take
some
time
to
implement,
attribute
renaming
and
only
attribute
renaming
in
in
The
Collector,
or
we
can
see
if
somebody
else
is
already
doing
so
and
where
it
sits
with
tigrin
like
we'll
have
to
figure
that
out,
because
I
know
someone
has
been
working
on
this
and
someone
has
been
contributing
here.
But
you
know
it's,
it's.
It's
open
source
volunteer
work,
so
you
know
we
don't
know
deadlines.
We
don't
know
timelines.
E
That
sort
of
thing,
so,
if
necessary,
to
make
sure
that
the
pr
goes
through
I'm
willing
to
implement
the
attribute
renaming
part
with
just
the
attribute
renaming
part,
because
I
think
that's
what
we
need
for
our
initial
release.
E
B
I
have
a
topic,
a
general
one,
to
discuss
if,
if
time
permits,
yeah
and
I
wanted
to
get
your
your
feeling
about
it,
so
we
we
want
to
Mark
HTTP
semantic
conventions
as
stable
and
I.
Think,
given
that
there
is
instrumentation
out
there
that
has
shown
that
it,
it
works.
I
think
that's,
that's
fine
and
one
could
say:
okay,
it's
stable
now,
but
as
we
are
stabilizing
it,
we
are
actually
breaking
a
lot
of
things.
We
are
changing.
B
A
lot
of
things
is
the
intention
still
that,
just
after,
for
example,
we
introduced
the
hint
API
and
changed
milliseconds
to
seconds
there
or
the
other
way
around
I
think.
Would
we
still
two
weeks
later
declare
it
as
Stabler
would
be
again
wait
for
it
to
to
settle
for
instrumentations,
to
adapt
and
for
for
users
to
give
us
feedback
that
it
works.
E
Okay,
specifically,
that
change
milliseconds
to
seconds
risk
super
freaking
low,
it's
pedantics
at
this
point,
freaking
metric
systems
work
I
yeah.
How
do
I
want
to
phrase
this
I?
That
whole
debate
has
been
super
silly,
in
my
opinion,
like
incredibly
silly,
we
chose
milliseconds
because
we
feel,
like
you
know,
if
you
think
of
modern
microservice
architecture
right.
What's
the
is
it
more
common
for
a
request
to
take
seconds
or
milliseconds
right,
I
think
milliseconds
at
that
point.
So
that's
why
we
picked
it
because
of
that
graph.
E
Prometheus
uses
seconds,
okay,
great,
like
I
I,
don't
think,
there's
a
high
risk
using
milliseconds
versus
seconds
personally,
like
I,
just
I
I,
don't
see
it
when
we
look
at
the
technical
details,
how
we're
collecting
the
data
we're
not
using
integers.
So
there's
no
like
performance
reason
why
it
mattered.
E
Moving
the
seconds
is
literally
just
multiplying
by
n,
so
I
I
think
that
particular
change
is
so
low
risk
that
it
should
not
really
affect
HP
send
conf
outside.
If
we
should
make
that
decision
update,
you
know,
update
things
and
get
that
out
the
door
that.
B
E
B
A
Okay,
we're
gonna
run
into
I.
Think
somebody
at
the
nine
o'clock,
probably
there's
like.
E
In
all
right,
we
can
take
it
offline.
A
Yeah,
let's
jump,
let's
put
it
in
slack
all
open,
because
I
have
I
can
share
my
thoughts.
Also.