►
From YouTube: 2022-11-17 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
D
B
Do
we
have
I
think
it
was
Michael
on.
D
E
Right
well,
basically,
I
provided
PR
because
we
are
using
in
quarkus.
We
are
using
open,
Telemetry
driver
and
we
have
problem
in
Native
mode
with
Oracle
driver,
and
we
would
like
to
be
able
to
use
open
Telemetry
driver
even
without
runtime,
into
initialization
or
driving,
registering
it
against
driver
manager,
because
it's,
if
you
registered
against
driver
manager
yourself,
then
well,
you
are
going
somewhere
where
you
don't
want
to,
because
you
just
for
to
having
an
open
television.
E
You
are
registering
other
drivers
and
you
you
don't
know
how
users
are
going
to
use.
Yes,
that's
the
issue,
and
it
will
be
better
if
he
was
able
to
use
just
well,
not
Global
static
registry,
but
just
static
registry
on
open
television
driver.
E
Because
then
you
know
you
are
not
having
impact
outside
of
your
scope
that
you
only
if
well,
you
have
extension
then
deals
with
open
Terminal
3
that
you
already
only
have
impact
on
open
currency
driver
not
to
other
driver
manager.
Well,
other
sources
that
use
driver
manager
like
connection
pools
and
so
on.
E
Well,
usually,
I
don't
know
if
you
will
get
it
all,
but
usually
driver
manager,
drivers
register
themselves
at
start
in
static,
initializer
block
according
to
jdbc
spec,
and
so
it's
fine
and
it
works
JBL
mode.
It's
absolutely
fine
and
most
drivers
I
today
I
tested
with
Derby
postgres
Maria
MySQL
Ms
SQL.
E
They
all
work
out
of
the
box
without
doing
something,
but
well
so
far
it
doesn't
work
with
Oracle
Oracle
driver
and
you
would
have
to
either
initialize
it
at
runtime,
but
it
can
have
if
some
some
other
system
that
you
are
integrating
a
wave
is
or
using
it
in
real
time
or
static
unit.
Then
you
are
having
problem
well,
no
time,
then
you
are
having
problem
because
it's
not
available
if
you
initialize
it
and
at
runtime
and.
E
We
can
also
register
it,
but
that's
what
I
was
talking
about,
that
we
never
use
this
big
Global
static,
Registries,
unless
you
really
have
to
so
it
would
be
easier
if
there
was
an
option
to
use
to
have
be
able
to
register
drivers
just
with
open
telemetry.
That's
that's.
B
About
it,
so
can
you
thanks?
Can
you
talk
through
the
two
different
approaches
that
the
current
jdbc
current
open,
2003
jdbc
instrumentation,
provides
there's
one
that
you
can
wrap
your
driver
programmatically
and
one
where
it
accepts
JVC,
URL
and
sort
of
how?
What
I
don't
understand
is
that
how
those
two
different
things
relate
to
Native
image,
how
they
work
in
Native
images.
E
Well,
it's:
it
is
very
approach
to
wrap
your
data
source.
For
example,
I
will
speak
about
agrawal,
because
that's
what
I'm
saying
then
I
can
wrap
a
data
source
if
this
open
television
wrapper
and
yes,
it
would
work,
but
it
also
means
that
when
something
is
producing
this
data
source,
it
needs
to
have
knowledge
about
about
open
Telemetry.
So
well
it's
against
pattern,
because
then,
if
there
are
others
providers,
not
just
open
territory,
then
they
data
source.
The
connection
pool
will
also
have
to
have
knowledge
about
them.
E
But
it's
very
well.
It's
very
convenient
to
use
this
diver
because
then.
F
E
B
E
It's
it's
it's
possible
to
use
this
data
source,
but
it's
not
as
convenient
for
us
as
well.
Sure
sorry.
E
So
I
added
aesthetic
registry,
because
in
the
way
I
saw
the
connection
Pool
Works,
with
this
data
drivers
or
these
drivers,
it's
I
usually
pass
them
as
just
class
and
or
you
don't
give
them
instance.
So
it's
it
has
to
be
Global
or
it
has
to
be
static
registry
because
you
don't
have
access
to
actual
instance
of
this
driver.
E
Yes,
I
actually
debug
this
today,
but
it's
quite
difficult
to
say
because
it's
marked
as
runtime
initialized.
So
if
when
we
use
it
as
a
build
time
initialized,
we
have
to
do
some
tricks,
like
substitute
Saturn,
certain
methods
that
well
try
to
register
beans,
M
and
MB
means,
and
so
on.
So
well,
there's
some
magic
wrote
it
I'm,
not
sure.
E
Where
is
the
issue
because
to
debug
at
build
time
it's
very
low
level,
it's
it's
very
time
consuming,
so
I
will
do
it
only
if
I
have
to
it's.
B
If
this
is
something
if
this
static
registry
is
something
that
we
only
need
for
Native
images
should
we
can
I
was
thinking
maybe
to
pull
that
out
in
just
a
separate
class
just
so
that
it
doesn't
sort
of
pollute
that
the
normal
jdbc
instrumentation
public
API
surface,
where
people
might
think
that
they
are
supposed
to
use
that.
E
Just
it's!
This
is
also
just
option
for
because
I
don't
know,
if
you
know
exactly
how
open
Telemetry
is
used
well,
well,
I,
don't
certainly
don't
know
it
in
all
cases,
but
this
just
gives
you
a
possibility
to
not
register
driver
against
driver
manager,
if
so
far,
I
suppose,
if
I'm
first
ones
who
complain.
E
So
if
you
want
to
keep
it
just
for
just
for
build
time
for
our
native
images
or
some
alternative
images,
then
we
can
do
it
in
separate
class
or
we
can
somehow
refactor
these
ones,
because
this
way
now
it
is
private,
static
method
that
finds
driver
and
it's
not
possible
to
just
override
it.
So
we
can
also
as
well
just
give
their
well
something
like
protected,
and
then
someone
can
customize
it
according
to
his
needs
right.
B
Run
across
like
a
scriber
minute,
this
pattern
driver
manager,
the
default
driver
manager
being
too
Global,
and
so
you
know
having
a
more
locally
locally
Global
School.
E
Yes,
I
didn't
get
it
completely,
but
driver
manager,
because
if
you
register
something
against
driver
manager,
it
accepts
URL,
then
it
is
going
to
be
used,
probably
by
others
right,
but
it's
possible
that
you
just
want
to
use
it
by
open
Telemetry,
let's
say
a
driver,
so
you
have
no
impact
outside
of
your
scope,
because
if
you
just
want
to
set
up
some.
E
B
Okay
yeah.
Thank
you.
So
much
for
joining
I
think
that
that
really
answers
my
question
about
the
the
two
different
approaches
and
why
we
want,
because
and
yeah
we'll
I
think
we
can
move
that
forward
and
we'll
just
decide
in
the
maybe
discuss
in
the
pr
about
the
API
shape,
whether
we
make
it
more
clear
that
it's
just
prenated
images
or
keep
it
as
a
general.
D
All
right,
thanks
for
that,
moving
on
the
next
item
and
the
agenda
is
semantic
sugar
event
API.
So
this
is
my
PR,
but
I
did
not
add
it
to
the
agenda.
Somebody
wants
to
talk
about
it.
D
Right
all
right:
okay,
semantic
sugar
event,
API.
How
best
to
describe
this.
B
D
D
Okay,
so
the
idea
here
is
that
as
it
stands
today,
there
is
a
the
event:
API
lives
in
the
logs
API
module
and
it
lives
as
an
extension
to
to
what
is
a
to
logger.
And
so
you
know,
if
I
check
out
main
right
here,
we
can
see
this.
D
D
D
So
something
like
this,
you
have
a
logger
instance,
you
obtain
an
event
Builder,
you
add
a
bunch
of
properties
and
then,
finally,
you
omit
the
event,
and
so
there's
been
an
effort
recently
to
decouple
events
from
logs
from
an
API
standpoint
for
a
variety
of
reasons.
But
one
of
the
motivating
factors
is
because
folks
feel
a
lot
more
comfortable
about
the
logs
Concepts
than
they
do
about
the
events
Concepts.
So
by
decoupling
them
we
can
potentially
stabilize
logs
sooner
than
we
would
otherwise
be
able
to.
If
events
were
also
in
the
picture.
D
And
so
if
you
decouple
these
things,
you
know
you
might
be
able
to
do
that,
make
logs
stable
faster
than
you
would
otherwise
and
there's
a
variety
of
other
reasons
as
well.
But
the
proposal
that's
on
the
table
right
now,
or
maybe
not
the
proposal,
but
the
a
change
was
made
to
the
specification
to
actually
do
this
to
to
decouple
logs
from
events.
And
so
if
we
go
to
the
specification
there's
now
a
in
the
logs
directory
there's
now
a
dedicated
event.
D
Api
page-
and
this
describes
that
there's
this
an
interface
or
a
class
called
event
logger
and
you
obtain
event.
Logger
instances
by
you
know
passing
in
a
logger
instance
and
an
event
domain
and
so
an
event.
Logger
essentially
is
going
to
wrap
a
logger
and
emit
events
to
The
Domain
that
you
specify
when
you're
creating
that
thing.
D
Exactly
so,
rather
than
being
something
that
lives
alongside
of
logs,
it's
built
on
top
of
logs,
so
it
delegates
two
logs,
so
it
has
a
dependency
on
logs,
instead
of
them
being
siblings.
What's.
D
Okay,
so
events
are,
our
events
are
as
as
of
now
are
just
a
type
of
log
record
that
conforms
to
this
shape,
so
they
have
an
event
name
and
an
event.
Domain
field
and
event
domain
is
just
a
namespacing
function,
and
so
you
know
event,
names
are
events
with
the
same
name
are
expected
to.
You
know,
have
similar
structure
and
represent
similar
things,
and
you
know
to
avoid
event.
Name
collisions.
D
So
right,
so
you
obtain
your
your
event,
logger
interface
with
by
passing
in
a
logger
into
your
event
domain,
and
then
the
the
API
is
pretty
simple.
You
just
you
emit
events
by
passing
in
the
name
of
the
event
that
you
want
to
wish,
and
then
you
know
the
rest
of
the
fields
of
the
log
record,
and
so
what
I've
proposed
doing
in
the
current
version
of
this
PR
is.
D
Is
so
the
logs
module
has
gets
a
lot
smaller,
so
logger
no
longer
has
this
event
Builder
and
in
fact,
there's
no
event
surface
area
in
this
logs
module
at
all.
You
know:
that's
that's
one
way
we
could
go
with
this.
We
could,
just
you
know,
have
the
event
logger
class
live
in
this
in
this
module
in
this
package
alongside
of
logs,
but
I.
D
Think
it's
actually
my
it's
more
appropriate
to
put
it
over
as
an
extension
and
that's
what
I've
done
currently
so
there's
now
this
new
extension
artifact
called
event,
API
and
event.
Api
is
pretty
simple:
it
just
has
one
class
in
it
called
event
logger
that
does
exactly
what
the
spec
says
so
event.
Logger.
D
Let's
see
you
create
it
with
your
logger
instance
and
with
your
event
domain,
and
it
has
one
API
in
it
which
is
emit
events
and
you
specify
your
event
name
and
then
a
bag
of
attributes
that
are
associated
with
that
event,
and
so
I
guess
the
the
one
of
the
questions
is:
how
do
we
package
this
up
so
I
think
that
an
extension
is
most
appropriate,
because
this
idea
of
it's
not
really
an
API,
the
same
way
that
our
Trace,
metrics
and
logs
apis
are
apis,
those
apis,
Trace,
metrics
and
logs.
D
D
And
so
you
know,
while
you
can
have
an
alternate
implementation
of
logger,
you
can't
have
an
ultimate
alternate
implementation
of
event,
logger,
and
so
it's
kind
of
a
different
thing.
It's
not
really
a
an
API
in
the
traditional
sense
of
open,
Telemetry,
apis,
it's
more
of
a
a
semantic
API.
It
helps
you.
It's
convenient
methods
that
help
you
implement
the
semantic
conventions
and.
H
H
Me
ask:
let
me
ask
a
perhaps
I,
don't
know
not
a
leading
question,
but
I
mean
it's
a
legitimate
thought
experiment.
So
New
Relic
has
an
event
API
built
in
better
agents
at
the
moment.
H
Right
so,
and
it
goes
that
data
goes
to
the
you
know
inside
events,
insights
events,
although
I
don't
know
if
you
call
them
that
anymore,
but
when
you
say
that
you
can't
Implement
your
own
event,
API
implementation,
I,
guess
I,
ask
why
like
why
couldn't
New
Relic
back
this
with
the
existing
insights
events
API
and
skip
the
logging
skip
the
open,
Telemetry
logging
system
all
together
to
get
this
data
in
to
the
back
end.
D
D
I
think
some
of
the
thoughts
are
like
to
yeah
to
to
reduce
repetition.
So,
like
imagine
what
you
would
have
to
do,
if
you
wanted
a
dedicated
event,
API
that
could
be
re-implementable
or
have
alternate
implementations,
you
know
you
would
need
to
have
like
an
event:
logger
provider
event,
logger
Builder.
Basically,
all
this
surface
area
of
the
log
API
would
have
to
be
repeated,
and
similarly
you'd
have
to
figure
out
what
to
do
on
the
SDK
side
of
things,
and
so
you.
H
Know,
I'm
not
sure
you
would
because
by
as
I
said
by
default,
the
API
could
have
an
implementation
that
does
exactly
what
you
have
here
right,
so
it
wouldn't
you
wouldn't
have
to.
In
the
you
know
the
out
of
the
box
open
Telemetry
experience
you
wouldn't
have
to
have
any
of
that.
It
could
just
work
the
way
you've
written
it
here,
but
without
an
interface.
It
makes
it
very
difficult
for
someone
to
provide
an
alternative
path
for
events
to
travel.
D
Well,
I'm,
not
sure
I,
don't
actually
think
it
does.
So
if
you
want
an
alternative
path
for
events
to
travel,
what
you
do
is
you
implement
the
log
SDK
and
you
have
a
filter
that
looks
for
events
that
are
that
looks
for
log
records,
shaped
like
events
that
have
these
these
attributes
on
them.
So
you
detect
that
the
log
record
has
an
event
domain
and
then
an
event
name,
and
then
you
treat
it
specially.
B
I
would
go
one
step
further
and
say
that
the
if
you
wanted
to
Route
those
you
would
just
do
that
in
your
log
exporter.
B
That's
what
we
would
do
I
know
with.
We
have
an
event
concept
in
our
back
ends,
and
we
would
just
update
our
log
exporter
to
look
for
things
that
look
like
events
and
push
them
to
event
records
in
our
back
end.
So.
H
I
find
this
kind
of
hilarious,
so
both
New
Relic
and
it
sounds
like
Microsoft
both
have
an
event
API
that
is
completely
separate
from
their
logging
apis
and
yet
for
some
reason
in
open,
Telemetry,
we've
decided
we
wanted
to
squash
these
things
together
into
one
concept
like
it's
clear
that
this
is
a
thing
that
is
not
a
log.
It's
something
that's
different,
even
if
it
happens
to
be
kind
of
loggy
shaped
like
it's
a
different
thing.
Otherwise,
New,
Relic
and
and
Microsoft
wouldn't
have
separate
backends
and
apis.
For
this
whole
thing.
H
Okay,
this
is
this
is
I,
don't
know
it
drives
me
a
little
crazy,
because
it's
clear
that
we're
kind
of
shoehorning,
logs
or
events
into
a
thing,
because
they
have
a
similar
shape
but
they're
totally
different
meanings
very
frustrating
to
me
because
it
does
feel
like
this
is
a
thing
that
is
different,
and
yet
we
have
decided
to
shove
it
into
something
that
is
that
just
has
the
same
shape,
even
though
it's
semantically
quite
different.
D
I,
don't
think
it's
okay,
so
I
think
you're
gonna
get
some
pushback.
If
you
were
like
dude.
H
D
Well
and
there's:
there's
a
ton
of
you
know
prior
art,
history
around
calling
logs
events
and
vice
versa,
like
using
the
words
interchangeably
and
so
to
kind
of
unwant
like
unwind
those
and
try
to
peel
out
what
exactly
is
the
definition
of
an
event
that
you
know
I
think
it's
a
really
tough
thing
to
do
and
I
think
everybody
has
been
struggling
with
how
to
pin
down
what
the
actual
definition
of
an
event
is
and
how
it
differs
from
a
log.
D
H
D
Yeah,
so
it
came
from
the
spec
itself,
which
came
from
conversations
that
this
group
helped
in
form.
So
it's
kind
of,
like
you,
know,
circular
in
a
way
yeah.
G
H
No
I
mean
Carlos
I've,
been
I've,
been
beating
this
drone
for
well
over
a
year
now,
and
nobody
seems
to
care,
but
I
just
find
this
is.
This
is
where
we
end
up
with
something
that
kind
of
sort
of
makes
sense,
and
yet
it
doesn't
really
I,
don't
know
it.
I
I
think
it
doesn't
end
up
being
satisfying
really
anybody's
teams.
Unfortunately,.
G
C
So
I
think
the
shape
of
this
event,
logger
that
we're
looking
at
is
fine,
I'm
curious
about
users
now
that
if
this
is
to
be
packaged
in
an
extensions
module
that
that's
a
little
bit
more
work
for
users
and
I'm
wondering
if
it's
worth
it
like
I,
think
you've
made
a
strong
case
Jack
that
it
is
kind
of
a
separate
thing.
But
it's
it's
so
minimal
that
my
instinct
is
to
just
plop
it
next
to
the
logs,
but
well.
B
Think
we
should
be,
though
I
I
agree
there,
like
that.
That's
the
only
thing
that
I
don't
love
about
the
API
Jack
is
that
you
have
to
pass
in
a
logger
like
if
you,
if
we
could
make
it
look
if
we
could
build
it
on
top
of
the
logger
provider
or
something
where,
basically
you
don't
it
completely
abstracts
to
the
user,
it
doesn't
see
log
the
word
logger
anywhere
in
the.
A
C
B
B
Like
could
be
an
approach,
I
do
I,
I
think
at
its
root,
though,
for
this
particular
PR.
The
key
is
and
I
think
Jason
to
your
point
about
where
it
lives,
I
think
it's
good
to
split
it
off
for
now,
because
we
want
to
stabilize
the
log
API
independent
and
then
once
we
figure
out
the
whole
event
thing.
You
know
we
can
always
revisit
that
of
where
it
lives.
Okay,.
H
A
A
H
Because
I
think
it
would
be
a
real
I
think
it
would
be
a
real
bummer
long
term
to
have
this
be
a
second-class
citizen,
because
I
think
one
of
the
things
that
we're
that
we're
doing,
at
least
in
my
opinion,
is
we're
adding
we're
adding
this
idea
that
vendors
have
had
for
quite
a
long
time,
but
have
never
made
into
kind
of
the
pillars
of
observability
and
I.
Think
that
this
is
something
we're
adding
to
the
open
source
instrumentation
world
and
if
we
hide
it
off
in
a
it
forever.
H
D
Quick
on
that
note,
so
what-
and
this
is
this
is
suggesting
something
that's
the
opposite
of
what
you
just
said.
But
what
about
you
know
if
the
closest
thing
to
this
concept
is
the
instrumentation
API?
D
A
Yeah
and
it's
the
closest
thing
and
not
the
same
thing
so.
H
A
And
I.
H
Think
the
most
common,
the
most
common
use
case
for
events,
is
a
custom
thing.
It's
not
going
to
be
like
I
know
that
there's
some
cases
for
browser,
maybe
for
Android,
but
the
most
common
use
case
for
events
that
I've
seen
in
my
career
is
generating
business
events
and
we're
not
going
to
have
an
instrumentation
API
for
business
events
that
doesn't
make
any
sense.
H
A
D
Okay,
what's
the
in
terms
of
whether
it
lives
in
extensions
or
in
a
new
module
under
the
API
directory?
What's
the
least,
what's
what's
most
likely
to
align
with
who,
with
the
future,
what.
H
C
D
F
A
The
other
hand,
we
are
being
very
honest
about
it
right
because
it
is
a
very
Alpha
concept.
It's
definitely
going
to
change
in
the
future.
B
And
long
term
Jack,
the
logs
API
would
be
in
brought
into
the
main
open
Telemetry
API
module
right,
yes
yeah,
so
we
don't
split
apis
in
general
across
different
modules.
So
that's
feels
like
the
most
likely
end
result
for
the
event.
Api.
D
Okay,
so
the
so
okay,
so
you're
saying,
okay
logs
comes
and
joins
the
the
API,
and
eventually
events
get
stabilized
too,
and
it
gets
promoted
to
the
API
as
well.
And
are
you
saying
that
the
events
would
live
within
the
logs
package
in
this
module
or.
B
F
D
D
Yeah
and
I
guess
that's
already
the
case
right.
So
if
you
use
the
trace
API
you
bring
in
metrics
and
if
you
bring
in
the
trace
API
you
would
bring
in
logs.
If
I
understand
your
question
correctly.
F
D
Yeah
from
from
an
implementation
standpoint,
there's
only
a
log
implementation,
and
you
know
application
logs
and
events
all
flow
through
the
log
implementation,
and
you
know
it's
up
to
the
configure
the
application
owner
who's
configuring,
the
SDK
to
decide
if
they
want
to
do
anything
different
with
events
versus
logs
or
just
you
know,
pipe
them
all
to
the
same
back
end.
D
D
All
right-
well,
we've
talked
about
this
quite
a
bit.
I'm.
Not
convinced
of
you
know
that
event.
Logger
is
a
good
name,
I'm,
not
convinced
that
extensions
is
a
good
home
for
this.
The
the
thing
that
I
like
most
about
this
is
that
it,
you
know
unblocks
this,
the
the
stabilization
of
logs
from
this,
the
spike
shedding
effort
around
events,
which
I
think
will
be
good
ultimately
for
users
and
in
the
community.
So.
D
D
Well,
there's
some
there's
some
things
that
are
still
experimental
but
for
the
most
part,
everything's
stable,
so
the
things
that
are
still
experimental
are
exemplars
and
exponential.
Histograms.
G
Oh
okay,
I
guess
some
anti-conversions
as
well
right
because
the
metrics
SDK
Beauty
bands
content
right.
D
F
D
All
right,
man,
okay,
we
should
move
on
Carlos.
You
have
a
topic
here
about
including
the
open
tracing
shim
and
the
agent.
G
Yeah
disclaimer,
this
is
just
mostly
a
question.
We
are
curious
about
trying
to
get
some
customers
to
move
on
and
yeah
I
was
just
wondering
I.
Think
somebody
asked
somewhere
in
the
past
like
whether
this
could
be
a
good
idea
or
not.
So
you
just
wanted
to
ask
here
again
what
would
be
the
process
whether
this
is
like
sounds
like
a
good
idea
to
you
or
or
maybe
not-
maybe
just
keep
them
separate.
G
A
Mean
that's
yeah
yeah
yeah
go
ahead.
That's
the
open,
tracing
shim
depend
on
any
SDK
type,
or
is
it
just
API.
A
Okay,
so
it
should
be
I
think
it
should
be
fairly
easy
to
implement
an
instrumentation
that
just
registers
that
our
own
Tracer
with
the
global
Tracer
I
suppose
when,
whenever
that
one
is
loaded.
If
this
is
enough
to
make
it.
G
D
Was
that
is
that
how
you
envisioned
it
working
Carlos
is
so
if,
if
the
open
tracing
shame
were
to
be
included
with
the
agent,
then
the
the
the
shim
would
be
registered
as
the
global.
The
open
tracing,
Global,
Tracer,
correct.
G
Yes,
I
think
that
that
would
be
the
the
core
thing.
Yeah
like
the
global
treasury
is
something
that
is
very
used
in
the
opens
racing
World
I.
Don't
think
we
use
that
a
lot
in
the
open,
Telemetry
necessarily
for
the
interpretation
they
use
that
a
lot,
so
they
could
be
like
an
easy
weight.
G
D
And
what
would
be
the
advantage
of
that?
So
so?
Okay,
you
have
the
open,
Telemetry
Java
agent,
that's
adding
a
bunch
of
instrumentation
to
all
the
the
libraries,
its
attacks
and
then
you're
setting
up
this
Global
Tracer.
That
has
you
know
the
that's
using
the
open
tracing
shim
so
that
open
tracing
calls
delegate
to
the
open,
Telemetry
API,
and
so
this
would
mean
that
anyone
that
has
the
the
otel
Java
agent
installed
and
is
doing
manual
instrumentation,
with
their
with
with
open
tracing,
has
those
calls
delegated
to
open
Telemetry,
correct.
G
Yes,
I
think
that
Bucky
today
we
didn't
have
so
much
coverage
of
java
instrumentation
for
for
libraries,
so
most
of
the
customers
were
using
heavily
like
their
own
custom,
spans
and
traces.
You
know
so
that
would
satisfy
the
thing
we
just
have
to
remove
the
Jagger,
for
example,
dependency
and
just
relying
to
Global
Tracer.
You
know
and
probably
remove
any
open
tracing
instrumentation,
which
was
manual
instrumentation.
You
know
like
where
it's
splitted,
you
know,
but
yeah
that
could
be
the
usage.
D
G
So
basically,
we
are
thinking
about
what
ways
we
could
try
to
move
users
from
from
open
tracing
to
open
Telemetry,
and
this
could
be
like
something
that
could
probably
work
as
an
intermediate
step.
Okay,
to
be
honest,
not
sure
about
whether
this
is
something
that
users
would
love
or
they
would
rather
stick
to
to.
You
know
to
keep
the
manual
instrumentation
and
the
old
instrumentation
from
open
tracing,
but
we
are
we.
We
just
wanted
to
see
whether
this
could
be
like
something
that
could
be
done,
as
I
said
before.
G
C
A
B
Yes,
my
main
concern
would
be
duplicate
telemetry,
because,
presumably
anybody
somebody
is
using
open
tracing
in
a
web,
app
somehow
they're
capturing
requests
and
a
couple
other
basic
things,
and
if
we
just
Auto
throw
this
in
we're
gonna,
that's
all
gonna
be
duplicative
so
I.
Would
it
would
seem
to
me
that
users
would
need
to
remove
the
they're
like
servlet
the
open,
tracing
servlet
instrumentation
anyway,
from
their
app,
at
which
point
they
could
just
add
the
open
tracing
shim
to
their
app.
G
Yeah,
that's
a
big
concern
indeed
yeah,
especially
because
a
lot
of
instrumentation
from
open
tracing
doesn't
automatically
register.
So
it's
not
like
you
just
removed
easily
the
dependency.
You
know,
because
you
have
to
grab
code
so
yeah,
so
I'm
afraid
that
the
customers
or
users
would
end
up
being
too
lazy
to
remove
those
things,
and
you
end
up
in
indeed
with
duplicative
telemetry.
G
Okay,
in
any
case,
I
don't
want
to
yeah,
spend
too
much
time
in
the
discussion,
so
it
sounds
like
it's
technically
possible,
but,
logically
speaking,
probably
it
has
a
few
drawbacks,
so
probably
worth
considering
not
doing
that.
B
D
Felt
the
same
way
about
my
topic,
so
I'll
be
brief
with
this,
so
the
idea
of
complex
types
in
attributes
has
come
up
a
number
of
times
and
it
just
keeps
coming
up
and
the
logsig,
the
folks
that
are
focused
working
on
client,
instrumentation
and
and
in
the
rumsigar
are
really
adamant
that
they
have
events
and
that
they
need
to
map
into
open
Telemetry,
and
these
events
have,
like
you,
know
arbitrary
levels
of
nesting
in
them.
D
So,
and
so
you
know,
this
tigrant
has
reopened
this
PR
to
support
maps
and
heterogeneous
arrays
and
attribute
values,
and
this
is
kind
of
like
an
an
inform
thing,
so
I'm
exploring
just
how
feasible
that
is
with
our
apis
and
how
what
that
might
look
like
just
to
inform
this
discussion?
Is
it
like
a
deal
breaker
or
is
it
reasonable
or
is
it
hard
and
I
just
briefly
wanted
to
collect
input
from
people
does?
D
Does
anyone
in
this
group
have
any
strong
reservations
about
this
and
think
that
attributes
should
be
limited
to
Primitives
and
lists
of
Primitives?
Yes,.
B
C
A
C
A
Even
find
some
of
my
comments
in
one
of
these
issues
and
I
posted
not
probably
not
this
one-
that
one
of
the
older
ones
and
I
I
think
I
commented
here
like
a
year
ago,
or
maybe
even
before
that
at
that
time
there
was
absolutely
no
use
cases
for
nested
objects,
I
mean
every
use
case
and
there
were
two
of
them.
It
wasn't
actually
meeting
these
nested
structures,
so
yeah
I
was
against
it
at
that
point
in
time.
So.
H
We
should
not
do
this
so
I
I
would
also
I
mean
I'm
not
involved
in
the
the
Android
or
the
the
rum
mobile
saying
anymore,
but
anybody
who
is
should
push
really
hard
on
this
assertion
that
it
is
absolutely
mandatory,
because
it
absolutely
is
not
mandatory.
Everyone
has
built
effective
room
systems
for
the
past
decade
or
so
that
do
not
require
this.
So
clearly,
it
should
not
be
mandatory.
A
And
it
also
opens
like
the
whole
Pandora
box
of
link
spacing
like.
Even
if
you
take
a
look
at
current
HTTP
spec,
it's
pretty
much
nice
place.
Every
attribute
starts
with
HTTP
Dot
and
then
something,
and
would
it
mean
that
we
would
have
to
like
switch
to
the
structured
view
of
this?
If
we
introduce
this
change
or
how
would
like
nested
structure
that
attributes
be
converted
to
a
flattened
version,
It's
like
a
kind
of
worms.
D
I
agree:
I
would
like
to
keep
it
simple.
A
couple
of
things
to
call
out
otlp
supports
complex
types
and
attributes.
Today
it's
just
that
our
apis
and
sdks.
Don't
so.
D
If
your
backend
supports
otlp,
then
you
have
to
have
some
solution,
for
you
know
either
rejecting
or
dealing
with
complex
types
that
are
sent
to
you,
because
the
protocol
allows
it
so
that
that's
one
thing
and
then
another
thing
is
that
it's
actually
in
this
spec
today
and
that
that
the
log
data
model,
the
attributes
in
the
log
signals,
support
complex
types,
so
it
hasn't
infiltrated
resource
attributes
or
metric
attributes
or
Trace
attributes.
But
somehow
logs
are
exceptional
as
written
in
the
spec
today,
but.
H
That's
only
in
the
data
model
and
then,
if
I
recall,
that's
only
to
support
some
backward
compatibility
to
other
other
protocols
and
was
not
intended
to
end
up
in
the
API
itself.
It's
just
a
data
model
construct
like
there's
stuff
currently
in
otlp
all
over
the
place
that
isn't
in
the
API
for
these
kind
of
backward
compatibility
reasons.
A
So
last
time
I
looked
at
the
log
API.
It
was
defined
in
a
very
peculiar
way
to
meet
because
it
didn't
actually
Define
the
API,
like
all
the
methods
that
allow
you
or
you
know,
the
Constructor
that
allows
you
to
set
severity
on
stuff.
It
just
references.
The
data
model
we're
just
kind
of
skipping,
a
few
steps.
D
B
H
B
B
D
Well,
if
you
feel
strongly
about
this
specific
issue,
you
know
I
do
suggest
that
you
go
comment
on
the
specification.
D
You
know
it's
been
brought
up
and
struck
down
several
times,
but
maybe
that
would
change
this
time
so
yeah
go.
Go,
engage
with
the
conversation.
D
The
the
the
the
main
use
case
that
they're
talking
about
is
like
hey
you're,
trying
to
you're,
trying
to
Bridge
an
event
that
you
got
from
some
other
system
into
open,
Telemetry
and
or
maybe
it's
a
log,
and
the
log
has
like
an
object,
complex
structure,
an
object-like,
complex
structure,
and
you
want
to
bridge
that
in,
as
is
without
modifying
it
in
place,
without
flattening
it,
and
so
that's
kind
of
the.
D
B
Hey
folks
were
at
time
just
next
week
is
thanks:
U.S
Thanksgiving.
So
let's
plan
to
skip
and
see
everyone
in
two
weeks
stay
warm
Trask
thanks.
Oh
electricity,
just
came
on
like
two
minutes
ago,
so
I'm
too
excited
thank.