►
From YouTube: 2022-08-23 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
C
D
Yeah
we
discussed
this
last
week.
The
thinking
was
that
we
will
be
able
to
find
some
use
cases
which
justify
the
change
that
we
did
so
riley
found
some
documents,
some
relevant
documents
from
msdn,
but
it
seems
like
there
is
it's
not
conclusive
in
this
in
this
particular
case,
from
what
I
understand.
D
So
revert
that
particular
pr
that
split
the
metrics
and
then
make
the
release,
and
then
we
have
plenty
of
time
to
think
about
whether
that's
the
right
thing
to
do
so.
We
do
just
revert
it
as
if
it
didn't
happen,
so
it
was
never
released
and
then
we,
after
the
release,
we
can
think
about.
What
did
we
do
about
that?
So
that's
what
I
suggest
I
would
like
to
understand.
If
there
is
any
objection
to
do
that,
if
not
I
then
I
can
submit
a
pr
yeah.
C
I
think
to
jd,
I
think,
jamaica
isn't
a
call
and
he
still
supports
what
we
have
right
now
and
given
that
we
are
one
week
away
from
next
month
from
september,
we
were
thinking
that
maybe
we
can
hold
the
release
anymore
and
try
to
discuss.
C
E
I
did
support
the
what
we
have
now,
because
I
think
it's
consistent
and
it's
it's
based
on
opinions
that
that
you
know
and
backwards
sort
of
precedent,
but
I
also
understand
the
objection
and
I
think
tigre
is
making
the
right
proposal.
E
C
Okay,
perfect,
so
anybody
else
has
something
mentioned
against,
or
in
favor
of
this.
C
C
D
F
Okay,
I
have
only
one
request:
if
we
revert
and
then
we
decide
that
the
split
is
the
right
thing,
please
make
sure
we
update
the
rules
of
when
do
we
do
this
versus?
When
do
we
do
the
split
or
when
do
we
attribute
very
clear
to
make
sure
we
not?
We
don't
have
a
debate
like
this,
so
riley
pointed
that
that
rule
may
be
bad.
Okay,
let's
revisit
that
rule,
I
I
mean
I
just
want
to
make
sure
that
we
it's
not
a
we're,
not
going
to
have
this
long
debate
for
for
every
metric.
C
E
The
reason
why
I
said
that
I
still
supported
our
original
decision
is
that
I
believe
we
are
following
a
rule
that
is
consistently
being
applied,
and
it's
just
that
people
can
disagree
on
the
rule
because
it
uses
very
vague
words
like
meaningful
and
useful,
and
you
know
I
think
our
rules
written
about
the
same
as
what
prometheus
has
and
if
you
look
at
the
prometheus
precedence.
The
prometheus
precedents
are
breaking
this
rule,
which
is
kind
of
why.
E
I
supported
this
that
what
we've
been
doing,
but
that,
but
I'm
again,
let's,
let's
back
this
out
and
and
write
down
a
better
rule
or
have
have
some
debate
in
the
future.
F
F
B
F
C
Perfect,
thank
you
so
much
great
okay.
The
next
one
is
about
boolean
values
for
environment
variables.
This
was
this
came
up
after
the
hotel,
sdk
enabled
disabled
discussion.
C
I
was
mostly
curious
whether
people
where
maintainers
are
here
and
whether
you
support
this
or
don't
support
these,
whether
you
have
actually
supported
values
that
were
not
true
and
false,
like
one
or
two
or
whatever.
G
In
java,
we
don't
support
any
booleans
that
aren't
true
or
false,
and
I
agree
with
daniel's
position
that
we
should
name
the
environment
that
variables
such
that
the
default
is
always
false.
C
C
H
Yeah,
I
think,
there's
two
ways
to
go
about
it
here.
We
can
either
define
very
specific
values
that
could
be
true
or
we
can
find
very
specific
values
that
can
be
false,
but
everything
else
should
be
the
other
and
I
think,
defining
the
case
and
sensitive
string.
True
is
probably
the
easiest
one.
Otherwise
we
define
zero
and
false
as
as
false
and
everything
else
is
true.
C
On
that
front,
anthony
yeah,
you,
you
don't
support
anything
like
other
than
toronto
falls
in
the
gold
side.
Correct
or
maybe
you
don't
remember,
maybe
you
do
don't.
H
Believe
we,
I
don't
believe
we
have
any
boolean
environment
variables
at
this
point.
Okay,.
C
So
you're,
safe,
okay,
okay,
I
don't
see
diego
here
titan
length.
Okay,
so
let's
confirm
that
what
math
do
you
remember
something
from
the
ruby
see
whether
you
support
any
boolean
bar.
B
C
C
Okay,
then,
let's
move
on
aws
propagators
repos
is
an
issue
that
jack
filled.
I
mentioned
that
yesterday,
yeah
jack.
You
want
to
comment
a
little
bit
more
on
that
to
re-summarize.
G
Sure,
let
me
pull
it
up
myself,
so
I
think
the
basics
of
this
is
that
in
the
java
project
we've
been
trying
to
delineate
between
you
know
what
components
live
in
our
core
repository
versus
instrumentation
versus
contrib,
and
you
know
we're
trying
to
trim
down
our
core
repository
because
it
has
a
lot
of
stuff
in
it
that
you
know,
isn't
part
of
the
specification
and
it
probably
doesn't
belong
there,
and
so
you
know
as
part
of
trying
to
define
the
criteria
for
where
stuff
lives.
G
We
came
across
this
the
aws
propagator,
which
lives
in
our
core
repository
and
is
we
we
marked
as
stable,
and
so
we
we
publish
a
stable
version,
but
we
do
so
explicitly
against
the
text
and
the
specs.
So
we
missed
the
mark
on
that.
G
So
we
we
published
a
stable
artifact
where
the
spec
says
hey
you
should
you
must
not
publish,
or
you
know
the
the
open
telemetry
distributions
must
not
include
aws
propagators
and
it
uses
aws
specifica,
specifically
as
an
example,
and
so
you
know
we're
trying
to
figure
out
what
to
do
with
this.
You
know
we
we
we'd
like
to
move
it
or
well.
G
We
thought
about
moving
it
and
decided
that
that
would
be
an
awkward
experience
for
users,
because
you
know
the
fact
that
it's
a
stable
artifact
means
we
need
to
re,
retain
publishing
it
in
our
core
repository
until
a
2.0
version,
and
so
you
know
moving.
It
would
just
mean
that
there
are
two
copies
out
there:
one
deprecated
and
and
one
you
know
the
replacement,
and
so
we're
curious
kind
of
how
to
go
about
this.
G
We,
you
know,
we
we
think
that
it's,
it's
an
important
propagator
users
get
a
lot
of
value
out
of
it.
We
package
it
with
the
java
agent
by
default,
and
so
we're
wondering
whether
we
can
keep
it
in
our
core
repository,
and
maybe
you
know
either.
You
know,
as
dan
suggested,
just
give
a
comment
in
java
that
says
hey.
This
is
an
exception
that
isn't
aligned
with
the
spec
or
adjust
the
spec,
and
you
know
include
aws
as
an
exception.
G
I
know
that
this
specification
has
gone
back
and
forth
on
whether
vendor
propagators
should
live
in
core
repositories
several
times.
So
I
don't
necessarily
think
it's
a
good
idea
to
reopen
that
discussion.
But
that's
the
background.
C
Anthony
may
provide
maybe
some
background
or
context
on
that
one.
I
know
that
android
was
very
vocal
about
supporting
this
one,
because
he
said
that
you
know
this.
Would
this
propagator
helps?
Even
if
you
don't
use
the
aw
tracing.
A
Anarog
approved
the
pr
that
that
made
it
so
that
it
shouldn't
be
included
in
the
default
distribution.
So
that's
really
weird.
I
just
looked
at
the
history
here.
Yeah,
but
yeah
anarag
approved
that
pr,
so
maybe
the
the
the
decision
changed
over
time,
but
that's
it's
just
weird.
I
think.
C
G
G
You
know
the
other
example
of
that
is
the
ot
trace
that
that's
in
may,
whereas
the
others
like
w3c
are
musts.
So.
F
A
A
That
said,
we
don't
want
to
have
a
proprietary
format
going
forward.
You
know,
like
that's
the
thing
we
want
to
move
to
w3c
trace
and
I
think,
like
from
from
the
standpoint
of
hotel,
I
think
that
there's
a
lot
riding
on
that
kind
of
a
decision
you
know
so
meeting
users
where
they
are
is,
is
my
number
one,
but
also
you
know
when
it
comes
to
like
proprietary
versus
open
protocols,
we
should
be
really
pushing
on
open.
H
G
I
I
think
I
think
we
could
definitely
live
with
that
in
the
in
the
java
community.
Like
hey,
we
missed
the
mark
here,
but
let's
not,
let's
not
continue
this
in
other
languages.
G
So
it's
a
stable
artifact,
so
we
have
to
continue
publishing
it
until
a
2.0
version,
which
you
know
is
years
and
years
away.
Do
you
have
to.
I
Is
that
it
will
be
hard
because
it's
a
protocol,
so
even
if
aws
is
deprecated,
if
someone
else
is
using,
let's
see
if
there's
another
vendor,
they
follow
specifically
what
aws
has
been
doing
and
they
don't
want
the
break.
So
I
I
feel
like
if
jack
removed,
that
from
the
the
current
java
package,
it
will
be
a
breaking
change
based
on
the
contract.
I
It
doesn't
matter
if
aws
do
use
that
or
not,
and
I
I
would
suggest
just
treat
it
as
a
specific
bug
in
java
and
maybe
having
a
tracking
issue
so
in
the
java
2.0.
If
there's
a
chance,
you
remove
it
and
there's
no
additional
need
to
call
that
out
in
the
spec.
It's
my
god
finney.
I
It's
similar
like
in
open
telemetry.net
people
made
a
mistake,
there's
something
they
should
put
in
open.
Climatry
dot,
maybe
like
like
trace
name
space,
and
they
did
the
wrong
thing.
They
put
that
under
the
open
time
to
use
namespace
when
I
discovered
that
it
was
too
late.
It's
already
published.
We
decided
okay,
it's
a
known
issue,
let's
just
track
it
and
in
2.0
maybe
like
five
years
later,
we
got
a
chance
to
fix
it.
B
F
But
I'm
curious
about
the
statement
jack
about
continue
to
publish
it.
I
I
thought
that
if
you
deprecate
a
package,
you
can
stop
publishing
it.
At
one
point
I
mean
it's
unmaintained.
G
Our
current
interpretation
of
some
some
conf
is:
is
that
stable,
artifacts
that
we
continue
to
publish
them
so
stopping
publishing
those
those
components
would
be.
You
know
equivalent
with
a
breaking
change
now,
maybe
we
can
revisit
that.
Maybe
we
can
talk
that
over
as
a
group
and
figure
out
what
the
right
thing
is,
because
there
there
are
some
other
components
that
are
stable,
that
you
know
we
have
deprecated
and
we
would.
We
would
like
to
stop
publishing,
but
you
know
for
now.
F
Yeah
here
I'm
thinking,
I'm
not
thinking
about
removing
the
code,
so
if
they
are
part
of
a
bigger
package,
module
or
artifact-
I'm
not
thinking
about
that,
but
I'm
thinking
if
the
whole
artifact
is
deprecated
yeah
stop
publishing.
It
may
feel.
Okay
anyway,
we
should
probably
discuss
that
in
a
separate
topic.
Are
you
I
don't
know.
H
F
H
G
That's
why
we
continue
to
publish
ours
as
well,
but
I
would
be
super
happy
if
we
could.
You
know
if
this
was
like
an
edge
case
of
some
semantic
versioning
and
we
could.
We
could
get
away
with
stopping
publishing
an
artifact
that
we
previously
published
so.
H
Maybe
you
can
certainly
do
it
for
for
go.
It
would
be
difficult
because
of
our
tooling.
We
would
have
to
change
our
tooling
to
enable
that,
and
that
was
a
choice
that
we
made
when
we
built
our
tooling
to
ensure
that
every
every
module
any
given
major
version
has
the
same
miner
and
patch
when
we
release,
but
you
that's
not
required
by
semper.
F
That
that's
my
point,
I
I
don't
think
he's
required
by
december.
We
can
discuss
separately
about
that
topic,
but
I
would
be
interested
to
discuss
that
because
it
sounded
interesting
for
me
and
contrary
to
what
I
expected
like,
I
was
thinking
not
publishing
at
all
an
artifact.
I
mean,
don't
remove
it,
it's
there,
it
was
stable,
it
was
deprecated,
no
longer
published
no
longer
supported.
It's
not
like
I
mean
if
we
don't
have
the
manpower
to
support
this.
I
I
don't
know
how.
F
You
can
even
delete
the
code,
but
because
you
delete
the
entire
artifact,
you
don't
delete
the
the
part.
The
problem
is,
if
you
are
deleting
a
subset
of
a
code
of
the
artifact
that
you
are
continuing
to
publish
so,
which
means
people
are
may
may
go
to
the
next
version.
They
may
not
have
that
code,
but
for
yeah
for
this
artifact
they
they
stick
with
that
version
and
that's
it.
It's.
G
Yeah,
there's
actually
several
instances
of
that
where
we
want
to
deprecate
an
entire
artifact,
but
we're
stuck
at
least
in
our
current
thinking,
into
continuing
to
publish
it
because
of
semver,
so
yeah
I'll
bring
that
up
to
the
the
javasci
and
see
what
they
think,
because
that
would
give
us
more
flexibility,
yeah.
A
So
one
question
I
have
here
so
just
to
note
that
you
are
publishing
the
source
code
with
your
artifact
thanks
to
maven,
so
they
can
always
download
the
source,
regardless
of
whether
or
not
you
have
it
in
your
repo,
but
that
sucks
that's
a
terrible
thing
to
do
to
people.
I've
had
it
done
to
me
anyway.
A
The
the
most
important
thing,
though,
is:
what
are
you
going
to
do
about
say,
security
vulnerabilities
right,
so
the
only
the
only
argument
I
would
have
for
keeping
around
you
are
not
breaking
semcons
by
not
releasing
a
new
version,
they
can
always
use
the
old
version.
It
should
be
compatible
with
the
binary
of
everything
going
on
in
hotel
that
I
get.
I
think
that
that's
an
option,
if
you
don't
think,
there's
a
possibility
of
security
vulnerabilities
or
you
never
plan
to
make
another
release.
A
You
know
I
think
you're
fine
here
too,
if
you
would
like
to
continue
to
provide
support
for
just
security
vulnerabilities.
That's
that's!
The
only
thing
that
I
would
ask
right
is
basically:
are
we
gonna
allow
people
to
continue
to
use
this
until
there's
a
major
vulnerability
and
then
force
them
off,
in
which
case
you
can
just
delete
the
code
and
stop
publishing
it,
and
I
think
that's
okay,
because
it's
still
there
it's
still
out,
people
can
still
leverage
it
or
do
you
want
to
kind
of
keep
it
around
because
of
the
security
vulnerability
question.
F
F
A
F
A
Between
semver
and
then
our
support
contract
and
again,
if
we
look
at
diversity
and
compatibility,
it
talks
about
semver,
but
it
also
talks
about
the
length
of
time.
A
version
is
supported.
That's
why
I'm
specifically
calling
out
these
patch
fix
releases.
If
you
look
at
that
second
bit
right,
we
do
call
out
that
we
will
patch
security
vulnerabilities
and
things.
That's
specifically,
why
I'm
talking
about
that
specific
thing?
I
said
specific
too
much
I'll
stop.
F
A
B
F
Maybe
the
solution,
maybe
the
solution-
is
jack.
You
move
them
into
a
directory
somewhere
the
code
where,
if
we
say
we
maintain
this
deprecated
artifact
for
a
year
and
a
half
or
something
like
that,
you
don't
publish
it
unless,
unless
there
is
a
big
security
thing
that
we
need
to
fix,
otherwise
you
stop
publishing
it
for
for
a
year
and
a
half
and
if
you
ever
publishing
it,
it's
just
a
major,
a
minor
release.
F
So
what
you
can
do
is
essentially,
if
you
have
a
released
branch,
you
can
still
delete
the
code
and
do
patch
releases
to
that
release.
Branch
for
for
this
artifact.
So
so
there
are
ways
to
do
this
with
in
even
deleting
the
code,
because
you
have
a
if
you
have
a
release
branch
you
can
do.
The
cherry
pick
release
things
in
that
branch.
C
Perfect
okay,
so
if
there's
no
other
comment
on
that
front,
let's
move
to
the
next
item,
which
is
just
for
your
information.
We
are
trying
with
alex
who,
from
lightstep
who
went
on
holidays
before
he
left,
he
added
a
user
agent
addition
pr
to
the
other
exporters,
tyrion
and
bottom.
You
have
comments
there,
so
yeah.
So
maybe
you
want
to
review
that
and
we're
waiting
for
your
for
your
feedback,
otherwise
we're
ready
to
go
and
anybody
else
who
wants
to
check
it
out.
Just
please
do
that.
D
C
C
You
thank
you
so
much.
The
last
item
I
just
said
there
just
now
is
about
the
short
name
attribute
discussion.
C
Dashboard
is
not
here,
but
I
think
that
you
were
asking
something
integrant
about
the
name
space
component
and
whether
you
know
you
were
asking
that
which
macd
so
maybe
we
can
spend
a
couple
of
minutes
discussing
that
you
were
asking
whether
a
namespace
could
apply
to
all
the
signals
or
a
metric
specific
item.
D
Yeah,
I
think
josh
had
this.
This
interesting
suggestion
that
essentially
we
have
the
concept
of
the
namespace
and
the
scope
right
instead
of
the
short
name.
I
think
it's
kind
of
an
interesting
alternate
suggestion.
I
I
haven't
had
a
time
to
think
about
it
or
the
or
the
implications
of
it.
To
be
honest,
I
don't
know
if
just
you
have
anything
that
you
would
want
to
maybe
elaborate
on
this.
E
Thank
you.
I
don't
know.
If
I
do.
I
haven't
prepared
any
such
remarks,
but
I
did
as
I
follow
this
issue
sort
of
you
know.
It
basically
is
lifting
a
concept
from
openmetrics
called
namespace
and
doing
exactly
the
same
thing,
but
call
it
something
else,
and
I
like
the
concept
of
a
namespace.
I
think
the
intention
here
is
not
is,
should
be
more
than
just
to
support
prometheus's
implementation
of
the
openmetrics
concept
which
we
are
imitating,
but
instead
we
should
be
making
this
option
to
have
a
namespace
available
to
all
telemetry.
E
That
seems
to
be
a
feature
of
you
know
this,
the
the
environment
we're
in,
and
I
think
we
should
just
follow
the
course
by
naming
it
a
namespace
calling
our
namespace.
A
F
It's
the
uniqueness
requirement,
so
so
the
problem
with
instrumentation
scope
name
is
that
it
requires
to
be
unique.
I
mean
try
to
be
unique
and
because
of
that,
it's
usually
going
to
be
some
kind
of
dns
url
like
pattern.
That
is
very
long
and
people
usually
like
a
shorter
name
for
the
namespace.
They
don't
want
to
type
io
dot,
open
telemetry
that
something
like
a
long
name
for
for
for
the
namespace.
D
Yeah,
that's
my
understanding
as
well.
The
question
I
had
for
josh
is:
what's
the
use
case
of
a
namespace
for
non-metric
data
like
what
does
it
allow
to
to
separate?
Is
it
the
names
of
the
spans?
Is
it?
Is
it
useful,
like?
I
understand
how
it's
useful
for
the
metrics
right,
because
I
can
query
for
a
particular
metric
by
its
name
and
when
that
name
is
used
for
different
purposes,
it's
a
semantically,
very
different
metric
used
in
different
parts
of
the
code.
I
don't
want
those
two
different
metrics
to
come
up.
D
In
my
query,
I
don't
know
of
a
use
case
where
I
would
query
trace
data
by
a
span
name,
but
if
I,
if
there
is
a
use
case,
then
this
this,
this
is
really
that
it
applies
to
the
spans
as
well
right.
Is
there
such
a
use
case?
Does
anybody
know
where
you
would
have
a
ui
where
you
would
enter
the
spam
name
and
you
would
get
all
the
stunts
that
match
the
particular
name.
F
Yeah
go
ahead.
I
can
give
you
a
simple
example
on
that:
the
span
name,
if
you
have
a
metric
that
transforms
the
span
latency
into
a
histogram
and
the
span
name
becomes
a
attribute.
You
you'll
use
that
it's
it's
just
a
very
simple
example
where
you
you
want
to
look
at
the
distribution
of
latency
for
this
span.
E
I
would
I'd
agree,
that's
sort
of
a
basis
of
white
steps,
user
interface
for
spans
and
and
we
we
talk
a
lot
about,
at
least
in
the
future,
about
expanded
metrics.
So
so
creating
a
metric
from
a
span
is
would
have
carry
the
namespace.
But
I
want
to
answer
the
question
a
little
bit
differently
than
bowdoin
did
just
now,
so
we
created
this
concept
of
instrumentation
library,
originally
now
scope
and
the
way
I
recall
we
wanted
to
allow
different
libraries
to
produce
the
same
instrumentation.
E
So
I
have
a
fancy
library,
that's
based
on
the
flight
data
recorder
and
it's
expensive
and
it's
got
all
kinds
of
verbose
detail
or
I
have
a
lesser
expensive
one.
That's
based
on
jmx
or
whatever,
like
that's
complete
computer
computed
in
a
very
different
way.
Those
both
can
produce
the
same
instrumentation
with
different
scope,
names,
different
scope,
attributes
but
they're
the
same
metrics
same
span
same
same
logs,
but
by
some
definition
of
sameness.
A
No,
I
all
I'm
saying
is
what
david's
proposing
is
a
very
low
lightweight
way
of
making
instrumentation
scope
and
namespace
kind
of
be
the
same
thing
and
allow
you
to
swap
your
instrumentation
and
still
provide
the
same
metrics,
because,
again,
if
I'm
providing
the
same
metrics
for
two
different
things
like
a
flight
recorder
versus
a
lightweight
poll
of
jmx
right,
I
would
still
have
the
same
prefix
for
both
of
them.
A
The
question
is:
can
I
instantiate
my
instrumentation
scope
with
that
prefix?
So
what
I
would
say
is
you
know
if
we
want
to
make
it
first
class,
that's
fine,
but
I
still
see
it
as
part
of
instrumentation
scope
as
a
fundamental
concept
of
what
that
thing
means
that
instrumentation
scope
is
here's
a
url
of
my
version
changes.
A
Ideally,
we
should
also
have
that
include
documentation
of
what's
produced
right.
I
think
we
have
some
proposals
on
the
table
around
that,
but
it's
it's
like
here's.
The
bundle
of
stuff
I'm
producing
in
in
within
a
scope
with
some
some
additional
information
to
kind
of
provide
around
it
and
how
it's
exported,
and
this
this
prefix
around
a
name
space
feels
like
it
fits
there
to
me.
But
that's
again
so
bogdan
you
raised
your
hand.
F
F
Yeah,
so
I
have
another
example
in
mind
about
this,
and
that
example
is
the
following.
George
mentioned
that
two
instrumentations
of
let's
say
grpc.
They
may
have
a
different
name,
but
they
should
have
the
same
namespace
and
now
here
I
kind
of
give
you
the
following
example.
One
of
the
reason
why
we
have
this
instrumentation
name
is
to
identify
possible
bugs
or
possible
issues
with
a
specific
instrumentation.
That's
why
we
give
them
a
unique
name
now,
if
that
is
lost
during.
F
I
think
that
should
be
part
of
the
the
the
metric
that
we
emit
anyway,
because
otherwise,
otherwise
we
we
we
lose
this
information
that
hey
this
maybe
exposes
latency
as
a
histogram,
but
this
one
exposes
latency
as
counter
for
arborism
or
what
other
example
that
doesn't
follow
some
some
of
the
things.
So
that
being
said,
I
I
feel
like
we
are
gonna
end
up
with
even
name
space
being
different
for
every
instrumentation,
because
reusing
the
same
name.
Space
may
cause
other
issues.
E
I
somehow
feel
like
you're
you're
changing
what
the
scopes
name
is.
If
it
doesn't
so
so,
there's
two
behaviors
that
users
come
looking
for.
One
is,
I
want
to
put
new
instrumentation
that
produces
the
same
stuff
and
the
other
use
is.
I
want
to
produce
the
same
different
stuff
with
the
same
code
and
that's
the
case
that
we
see
in
openmetrics,
like
I
have
http
duration
and
there's
some
code
that
you
you're
going
to
reuse
your
hdp
server,
but
for
a
totally
different
use
inside
your
code.
You
don't
want
to
use
http
duration.
E
G
E
This
would
be
created
when
the
user
instantiates
the
instrumentation.
They
might
provide
a
a
namespace
as
opposed
to
no
namespace.
I
guess
is
the
way
and-
and
that
is
I
think,
following
the
pattern
in
prometheus
clients,
it's
like
I
want
to
create.
E
I
I
don't
know
they've
not
specified
exactly
consistent
mechanism
across
the
clients,
but
you
can
some
of
them.
Allow
you
to
give
a
namespace
prefix
option
and
it
happens
to
affect
all
the
metrics
that
you
then
create
my
understanding.
F
E
That's
that's
a
detail
that
I
think
doesn't
match
very
well,
so
I
I
don't
think
we
should
go
there,
but
I
think
that
the
straightforward
answer
to
jack's
question
is
something
like
when
I'm
creating
the
instrumentation
package.
I
can
have
a
with
an
optional
somehow
and
go
would
be
a
functional
option
to
say
with
namespace
prefix
and
then
I
would
pass
micro,
http
underscore
or
micro,
and
then
I'd
have
two
http
instrumentations
with
different
prefixes
and
then
I
have
different
span
names,
different
log
names,
different
counts,
different
metrics
and
so
on.
F
Okay,
but
do
we
do
we
still
have
to
publish
the
scope
name
when
we
convert
to
or
to
to
prometheus,
because
I
think
I
think
one
of
the
the
reason
why
david
is
trying
to
solve
this
problem
is
to
not
put
that
scope
name,
because
he
was
too
long
or
ugly
or
whatever
as
part
of
the
metrics.
We
me,
and
I
think
I
think
we
should
clarify
on
that
as
well.
E
Well,
his
his
specification
change
creates
this
new
metric,
potentially
called
target
info,
or
you
know,
there's
been
some
debate
over
whether
it
should
be
split
into
more
than
one
type
of
info,
and
you
just
want
to
add
one
new
attribute
on
that
info
metric,
which
is
essentially
a
we
haven't,
come
up
with
good
naming
here.
It's
like
an
indicator
variable.
You
can
join
with
it.
So
in
prom
ql
you
use
group
left
and
you
say
I've
got
an
instrumentation
scope
name
and
almost
nobody
ever
wants
to
know
that.
E
E
A
Attribute
you,
you
join,
you
join
based
on,
and
so
you,
the
short
name,
is
the
attribute
that
you
use
to
join
with
the
target.
So
the
target
schema
has
multiple
time
series
right,
one
per
every
instrumentation
scope,
again,
I'm
a
little
out
of
date
because
dave
and
I
haven't
had
a
chance
to
sync
in
like
a
week,
but
you
have
multiple
time
series
and
you
join
based
on
your
common
thing,
which
is
the
short
key.
A
So
the
short
key
is
what
what
one
one
of
the
ways
you
could
then
line
up
on
to
the
other
side.
Give
me
this
thing
where
the
short
key
is
this
right.
E
Think
we
need
david
right
now,
because
I
was,
I
had
a
little
bit
of
a
different
understanding
than
than
what
josh
just
said.
I
think
you
I
I
would
imagine
you
create
a
new,
a
new
identifier.
This
is
my
scope,
identifier,
that
I'm
going
to
join
with
in
prometheus.
You
only
need
it
to
establish
that
prometheus
connection,
because
otherwise
it's
nested
in
the
otlp
structure.
E
E
But
I'm
assuming
that
those
name,
those
prefixes
the
short
names,
I
think,
is
the
way
I
understand
it
go
it
actually
become
prefixes
on
the
prometheus
metrics,
whereas
every
other
scope
attribute
would
become
an
attribute
on
the
target
info
or
sorry.
The
scope
info,
open,
telemetry
scope
info
is
what
it's
called.
I
think,
can
you.
E
A
The
short
name
is
especially
what
I'm
saying
is:
it's
still
joinable
just
you
need
pre-knowledge
of
what
you're
joining
it's,
not
joinable
like
abstract.
How
do
I
want
to
phrase
this?
You
can
still
get
out
what
instrumentation
scope
you're
in
you
just
have
to
know
that
prefix
by
looking
at
the
metric
name,
so.
D
F
That's
that's
where
I'm
confusing,
unless
we
keep
the
name
as
an
attribute
and
the
short
name
as
a
prefix,
and
you
always
join
by
the
the
name,
which
is
the
real
identifier-
and
this
is
just
the
prefix,
then
I
would
understand
why
they
are
different,
but
otherwise,
if
they
are
just
used
as
a
key
to
to
join,
it
means
that
they
have
the
uniqueness
guarantees.
It
means
that
it
can
be
the
name
for
me,
like
maybe
I'm
too
narrow.
In
my
my.
D
I
think
you're
right,
but
to
be
able
to
join
using
the
scope
full
name.
You
have
to
record
that
full
name
as
a
label
of
the
metric
right
of
all
the
other
metrics
accepting
for
magic.
But
if
you
do
that,
then
what's
the
purpose
of
the
short
name,
in
that
case
it's
useless
right,
you
don't
need
it
yeah.
I.
A
If
I
recall
correctly,
I'm
trying
to
remember
all
the
specifics
we
talked
about,
but
there
was
something
about
recording
the
whole
name
on
every
metric
was
not
amenable
or
ergonomic.
I'm.
E
Remembering
it
now
so,
the
the
the
scope,
the
scope
info
variable,
also
has
the
the
short
name
prefix
on
it
to
help
you
find
exactly
which
copy
of
it,
but
I'm
realizing.
Now
there
are
some
holes
in
this
situation.
I
think
we
should
go
to
the
issue
and
get
david
to
discuss
this
with
us.
If
you
have
two
libraries
with
the
same
short
name
but
different
instrumentation
names,
they're
going
to
collide
right,
there.
A
Like
that's,
that's
a
different
discussion
then,
but
you
when
we
think
about
ergonomics
and
prometheus
like
we
should
start,
this
discussion
should
start
from
what
does
it
look
like
in
prometheus
and
what
how
do
we
want
to
get
there
from
hotel?
That's
that
and
again,
from
my
standpoint,
prometheus
has
this
notion
of
metric
namespaces.
That's
a
first-class
thing:
a
prometheus
user
coming
to
hotel
that
wants
that
right.
What
what
do
they
do
to
make
this
work?
How
does
that
or
ergonomically
work?
A
That's
why
my
you
know
my
quick
opinion
is,
I
think
namespaces
should
be
first
class.
I
think
scopes
are
namespaces
and
we
just
need
to
figure
out
some
of
the
ergonomics
of
how
that
fits
right.
I
don't
think
we
should
be
complicating
this
or
adding
yet
another
concept
to
hotel
metrics
that
deviates
again
from
how
the
rest
of
the
world
sees
metrics
right.
A
Let's
try
to
keep
it
simple,
like
boxing
suggests,
keeping
the
name
small
might
be
an
option,
but
let's
not
over
complicate
this
and
let's
start
from
what
is
what
do
hotel
metrics
look
like
in
prometheus
and
work
backwards.
You
know,
that's
that's
how
this
this
whole
thing
should
be
starting
and
yeah.
I
agree
we're
probably
not
going
to
come
to
consensus
here.
David
is
back
on
friday.
A
So
if
we
want
to
have
a
discussion,
then
that's
fine.
Maybe
it's
worth
doing
a
one-off.
Maybe
it's
worth
commenting
in
the
bugs,
but
I
don't
think
we're
gonna
resolve
it
right
now.
I.
E
Think
that
we
could
write
down
the
spec,
that's
like,
like
we've
been
describing
and
just
allow
it
to
be
broken
when
it's
broken.
So
if
you
happen
to
use
the
same
short
name
across
more
than
one
instrumentation
libraries,
without
coordinating
you're
going
to
break
the
single
writer
violation
metrics,
and
that
you
better
not
do
that
you,
you
would
break
that
in
prometheus
2.
If
you
did
that,
which
is
what
essentially
the
basis
of
all
this
like
we're,
not
breaking
anything
that
isn't
already
broken
and
we're
adding
stuff
that
that
should
help
users
in
the
future.
E
I
think
my
takeaway
from
this
discussion
is
that
we
shouldn't
be
having
a
short
name
attribute
or
any
new
scope
attribute.
We
really
want
a
first
class
field
in
the
scope
that
says
prefix
and
it
can
be
empty
or
not
and
it
and
when
you
fully
expand
names
like
in
prometheus
you're,
going
to
put
that
prefix
on
all
the
things,
but
you
might
not
need
to
do
that
in
open
telemetry.
However,
we
still
have
that
user
can
put
in
a
namespace
now.
E
D
I
want
to
support
what
josh
surett
said.
I
think
it's
we
should
start
with
deciding
what
open
telemetry
generated
metrics
should
look
like
once
they
are
exported
to
prometheus.
What
do
we
want
them
to
look
like
right
and
then
work
backwards
from
that?
How
do
we
make
it
happen?
This?
The
pr
doesn't
clarify
that
I
really
would
want
that
to
be
clear
right.
C
C
Okay
feel
free
to,
of
course,
add
a
comment
there
based
on
this
discussion
in
case,
you
think
it's
you
know
it
has
any
value
otherwise
yeah,
that's
it
in
the
gender.
Nothing
else
anything
else.
This
cause.