►
From YouTube: 2022-05-12 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
D
It's
it's
very
haphazard
organization
system.
Some
of
them
have
been
there
for
a
while.
C
D
D
Oh
so
there's
there's
been
a
slot
conversation
with
not
sure
his
name
he's
a
contributor
to
the
java.
From
time
to
time.
Let
me
pull
it
up,
justin,
spindler
and
so
his
his
problem
is
this.
So
he
uses
spring
with
micrometer
and
spring
boot
actuator
and
he
is
interested
in
getting
some
of
the
metrics
about
span
processor.
D
The
batch
span
processor
records
metrics
about
how
its
processing
spans
and
he's
interested
in
in
using
those
in
his
his
ecosystem,
which
is
his
setup,
is
micrometer
and
spring
boot
actuator,
and
so
the
problem
is,
is
that
so
spring
boot
actuator
provides
this
kind
of
proprietary
metrics
format?
I
don't
I
don't
know
where
it
came
from
but
like.
D
D
I'm
not
sure
what
it
is
exactly.
It's
just.
A
A
troubleshooting
endpoint,
it
is
not
meant
to
be
used
in
production.
It
is
meant
to
be
used
in
cases
when
you
are
pushing
metrics.
So,
for
example,
you
are
not
using
prometheus,
but
anything
other
than
that,
and
you
want
to
see
what
matrix
do
you
have.
D
A
Yeah
never
ever
use
it
in
production,
don't
like
scrape
the
ten
point,
use
a
real
netflix
backend,
that's
not
meant
for
for
production
use.
That
is
only
meant
for
debugging
purposes.
That's
why
it
is
like
basically
part
of
the
like
the
actuator
endpoints
yeah.
D
A
I
believe
it
should
be
documented
in
the
like.
There
is
a
big
documentation
section
for
for
spring
boot
actuator.
It
should
be
there.
C
A
C
But
using
using
metrics
on
that
page
to
determine
healthiness
for
the
purposes
of
load,
balancing
or
whatever
you're
discouraging
that
you
think
no.
A
So
you
can,
but
in
that,
so
those
are
two
two
different
things
that
you
are
talking
about.
They
are
so
if,
if
you
are,
if
you
want
to
use
matrix
for
the
half
check,
just
register
and
a
half
indicator
into.
D
Yeah,
so
what
I
think
like
that
the
matrix
endpoint
does-
and
you
can
correct
me
if
I'm
wrong
jonathan,
but
I
think
it's
it's
in
some
way
implemented
as
a
micrometer
metrics
registry,
and
so
it
reads
out
metrics
from
micrometer
and
displays
them
in
this
format.
It.
A
Is
it
is
an
in-memory
registry,
and
it
is
the
only
one
that
is
like
shipped
with
micrometer
out
of
the
box.
D
Okay
and
so
kind
of
the
the
so
that
that
answers
part
of
my
question.
So
if
if
this
person
has
is
scraping,
this
metrics
endpoint
and
you
know-
wants
to
bridge
open
telemetry
metrics
into
there.
That's
not
really
part
of
the
use
case
of
this
metrics
endpoint.
It's
just
for
debugging
purposes,
yeah,
but
there's
kind
of
a
question
that
still
remains,
which
is
that,
like
suppose,
you
suppose
you
expose
those
micrometer
and
spring
boot
metrics
via
the
prometheus
format.
D
So
and
then
you
also
want
to
have
open,
telemetry
metrics
exposed
in
prometheus.
So
right
now.
The
way
that
you
would
do
that
is.
You
would
use
open
telemetry
with
with
either
the
well
with
just
the
prometheus
exporter
the
prometheus
metric
reader,
and
I
think
you
would
have
to
have
two
prometheus
endpoints,
because
you
can't
bridge
those
together.
You
just
have
you'd
have
like
micrometer,
plus
prometheus
and
then
open
telemetry
plus
prometheus
on
two
different
ports,
and
so.
A
Yes
right
and
yeah
in
that
case
that
you
can
just
like
register,
you
have
to
end
points
and
that
that
should
be.
That
should
be
all,
but
I'm
not
I'm
not
saying.
Why
would
you
do
that
like?
Why
would
you,
like
I
mean
like
this-
is
not
breaching
one
to
the
other?
It
is
like
using
both
at
the
same
time,
right.
D
E
That
around
justin's
pr
draft
pr
and
contrib-
oh
it's
not
that
anymore,
yeah.
E
D
Well,
he's
proposing
it
in
case
other
people
are
interested.
I
haven't
heard
other
people
mention
this
use
case
and
I
guess
this
is
kind
of
asking
a
like
a
broader
question
of
you
know:
what's
our
stance
on
pintrib
contributions,
so
do
we
only
accept
contrib
contributions?
If
there's
a
certain
level
of
demand,
do
we
accept
any
and
everything.
E
But
it's
like
yeah,
does
it
just
literally
anybody
can
put
in
anything
I
mean
this
seems
I
don't
know
jonathan.
Do
you
have
thoughts
on
the
the
use
case
or
the
usefulness
for
this
bridging
the
other
direction.
A
I
think
so
so
I
I'm
not
I'm
still
not
sure
I
completely
understand
is
his
like
use
case
or
what
what
is
he
like
doing?
Maybe
he
has
like
some
code
that
he's
not
able
to
change,
and
there
were
like
other,
like
discussions
around
like
using
open,
telemetry
tracing
in
the
micrometer
sectional,
but
I
believe
this
could
be
useful
in
other
use
cases
as
well.
A
For
example,
let's
say
that,
like
a
library
is
instrumental
open,
telemetry
audio
user
is
using
the
open,
telemetry
api,
but
you
want
to
push
your
metrics
into
a
registry
or
like
into
a
back
end.
Open
dynamic,
doesn't
support,
I
don't
know
elasticsearch
or
whatever,
which
is
not
otlp
or
prometheus
anything
else.
D
Yeah,
so
so
a
couple
things
so
one
I
think
if
I
were
to
bat-
and
I
would
have
to
clarify
this
with
justin,
but
I
I
I
bet
that
his
use
case
is
that
he
has
some
sort
of
proprietary
software.
That's
scraping
the
spring
boot
actuator
metrics
endpoints,
which
is
probably
like
outside
of
what
they're
supposed
to
do.
But
you
know,
assuming
he
he's
doing
that
we
can.
D
We
can
like
ask
him
to
do
the
right
thing,
but
I
think
jonathan's
point
remains
that
there
there's
probably
other
use
cases
like
other
valid
use
cases
for
people
that
want
to
see
open,
telemetry
metrics
bridged
into
micrometer.
The
argument
against
doing
that.
So
you
know,
let's
say:
micrometer
has
an
elastic
search
exporter
and
open
telemetry
doesn't
so
I
mean
on
one
hand
that's
what
the
collector
is
supposed
to
be
used
for.
D
The
collector
does
have
a
elastic
search
exporter,
and
so
you
could
export
from
your
application
to
the
collector
in
otlp
format
and
then
from
the
collector
to
elasticsearch
using
that
proprietary
protocol.
So
not
saying
I
agree
with
that,
but
that's
like
an
argument
against
you
know
just
supporting
the
project.
C
Yes,
yeah
jack,
I
mean,
I
think,
you're
right,
because
micrometer
supports
so
many
different
backends
or
you
know,
data
platforms
that,
if
they're,
if
they're,
coupled
to
any
of
those,
that's
probably
what
it
is
like
getting.
Specifics,
would
be
good
to
know,
though,
because
there's
bound
to
be
a
bunch
that
are
not
supported
by
the
collector.
D
Yeah
yeah,
so
I
guess
my
I
I
don't
mind
having
this
as
a
part
of
kendrip
if,
if
he's
committed
to
being
the
code
owner
for
it.
E
E
D
D
D
Yeah
that
sounds
good
I'll,
I'll
I'll,
follow
up
in
the
slack
thread
and
just
try
to
better
understand
his
specific
use
case
and
and
if
he's
interested,
invite
him
to
the
thursday
night
meeting,
maybe
next
week,
if
it's
too
short
of
notice
for
this
week,
awesome.
F
Hi,
I'm
a
very
infrequent
visitor,
but
I
have
been
using
the
instrumental
api
in
my
own
manually,
instrumented
applications
and
I
really
like
how
it
is
because
I
know
it
was
a
big
change.
I
think
from
there's
a
previous
api
prior
to
that.
F
One
thing
I
found,
though,
is
that
you
have
the
ability
to
add
your
custom
attribute
extractors
and
what
I
would
like
to
do
is
to
be
able
to
extract
attributes
from
the
metadata
that
is
passed
with
the
grpc
request,
but
that
metadata
is
not
available
until
after
the
instrumenta.start
has
been
called
face.
First
problem,
and
it
also
seems
that
the
grpc
request
object,
which
encapsulates
the
request
and
metadata
is
never
modified,
and
so
it
it
never
actually
updates.
E
I
wanted
to
start
and
ask
if
you
have,
if
you're
using
or
have
looked
at
the
grpc
instrumentation
here,
yes.
F
E
Oh,
it's
amazing
that
that
linking
works.
F
So
metadata
and
remote
address
right,
so
we
construct
it
with
null
and
null
which
is
okay.
I
guess
because
we
don't
know
what
the
metadata
is,
the
reason
being
that
we
don't
know
what
the
metadata
is.
If
we
jump
back
to
the
prior
thing,
we
don't
really
know
what
the
metadata
is
going
to
be.
That
goes
with
the
call
until
we
get
down
to
scroll
down
to
the
tracing
client
call
here
down
here,
keep
going
here.
F
Yes,
let's
start
okay,
so
here
is
where
you
get
the
metadata
passed
in
the
headers
that
are
actually
going
to
go
with
the
call,
but
there's
no
provision
in
the
instrument.
Well,
first
of
all
the
instrument
api.
We
could
do
this,
probably
at
the
end
of
the
request,
because
I
know
you
have
the
ability
to
extract
attributes
there,
but
you
still
only
pass
that
encapsulating
grpc
request
object
and
that
is
never
updated
with
any
headers.
F
What
I
was
wondering
like,
maybe
there's
some
you
know,
method
on
the
grpc
request.
Where
you
can
say
here
are
the
actual
headers
that
went
out
based
on
what
I
know
from
my
client
interceptor
and
then
you'd
have
availability
avail
have
them
available
at
the
end
right
when
that
cause
instrument
to
end
you'll,
be
able
to
run
through
your
attribute
extractor
and
see
what
those
were.
E
Yeah,
it
makes
sense
to
me
to
add
a
set
metadata
in
here
to
be
able
to
update
and
then
from
over
here
once
it's
available
update.
It
call
it
set
it
in
the
request.
F
Yes,
I'm
adding
my
own
attribute
extractor.
The
reason
is
we
have
other
grpc
client
interceptors,
that
will
add
particular
information
into
the
metadata,
essentially
basically
putting
in
headers
that
came
in
from
an
http
core,
that's
then
being
put
into
the
outgoing
grpc
core,
but
I'm
unable,
whereas
we
can
extract
the
http
headers
very
easily
right
and
put
the
span
attributes.
B
F
B
F
On
until
that,
grpc
interceptor
runs
and
that's
well,
yes,
and
then
it's
put
into
the
metadata.
E
That's
what
this
yeah
that's
definitely
a
use
case
I
know
was
in
mind
when
adding
these
allowing
users
to
add
their
own
attribute
extractors
to
the
pub
to
the
standard,
instrumentation
libraries
right,
so
yeah
yeah,
I
mean.
F
Do
you
want
to
open
the
open
an
issue
in?
Is
that
the
easiest
way.
E
Yeah,
either,
if
you,
if
you
want
to
do
a
pr,
just
send
the
pr.
If
you
want
to
do
an
issue,
you
know
if
you
have
trouble
with
the
pr
feel
free
to
do
an
issue
and
or
or
both
we're
real
flexible.
F
F
F
So
I
know
in
the
in
the
java
agent
there
are
settings
or
an
environment
variable
to
essentially
disable
the
java
agent
completely,
and
I'm
wondering
whether
there
should
be
something
similar,
maybe
that
you
can,
in
the
order,
configure
sdk
that
if
you
set
that,
like
otel
dot,
sdk
dot
enabled
equals
false,
for
example,
that
it
doesn't
try
to
do
any
of
this
thing.
It
just
returns.
You
an
open,
telemetry
dot,
know
what
I
know
that
seems
like
maybe
putting
too
much
into
the
auto
configure
sdk.
F
I
could
just,
for
example,
check
that
before
I
get
there,
but
I
have
a
general
thing
where
I'm
pulling
in
properties
from
a
configuration
file.
Similarly,
to
how
the
java
agent
does
it
might
be
environment,
variables,
etc,
and
then
just
have
that
able
to
basically
turn
off
or
open
telemetry
completely.
D
There's
there's
something
similar
to
that.
So
all
of
the
exporter
options
have
the
ability
have
like
a
none
option,
so
you
can
set
the
spanx
border
to
non-metric
exporter,
to
none
log
exporter
to
none
and
that
the
sdk
internally,
when
the
when
there's
no
exporters
present,
has
like
a
variety
of
optimizations
to
act
somewhat
similar
to
a
no
op
sdk.
But
it's
not
quite
the
same.
So
have
you
tried
those
and
yeah.
F
So
I
have
triggers
so
I
have
put
in
my
code.
Basically
let
me
start
before
auto
configure
existed.
I
wrote
my
own
sort
of
configuration
thing
and
one
of
those
things
had
a
basically
hotel
enabled
equals
false.
So
what
I've
done
is
whenever
I
see
that
from
my
own
configuration
I
have
to
manually
set
these
properties
before
I
call
the
order.
Configure
sdk
to
say
yes,
matrix
is
support,
equals
none
logs
export
equals
none
and
trace
is
exported
equals,
none
which
I
can
do
and
that's
all
on
my
site.
F
I
just
wonder
whether
it
might
be
might
be
an
idea,
basically
at
a
line
to
something
where
you
say:
hotel
sdk
enabled
equals
false
and
that's
immediately
returns
to
a
open,
telemetry.no
op
instance.
D
It's
possible,
you
know,
I
think
I
think
we'd
have
to
discuss
it
with
the
other
maintainers.
So
the
the
idea
behind
that
auto
configuration
module
is
that
all
the
properties
that
are
specified
reflect
the
properties
that
are
declared
in
the
specification,
so
with
the
exception
of
a
handful
that
have
like
experimental
somewhere
in
the
name
of
the
property.
D
So
you
know
if
there
was
kind
of
demand
for
this
and
and
we
wanted
to
introduce
it,
it
would
have
to
include
like
experimental
somewhere
in
there
or
else
the
specification
would
have
to
get
adjusted
to
to
support
this.
All.
F
F
E
Is
a
very
interesting
thought,
though,
like
like
almost
from
a
like
a
debugging
perspective
like
if
you
wanted
to
you
know,
if
you're
having
issues
in
your
app
and
you
just
want
to
shut
down
everything
related
to
open
telemetry.
F
But
the
way
I
the
reason
I
mentioned
is
I
do
use
the
auto
instrumentation,
as
I
said,
and
some
other
apps
and
some
I've
got
manually
instrumented
and
the
auto
instrumentation
definitely
has
an
equivalent
like
hotel,
java
agent
enabled
and
that
can
be
the
true
or
false
and
when
it's
false
it
doesn't
do
anything
except
just
return.
The
no
op
open
to
the
material.
So
I
know
what
hotel
auto
configure
enabled
equals
false
right.
C
If
it's
okay
for
us
to
go
back
in
time
a
little
bit
evan,
I
wanted
to
ask
about
your
grpc
attributes.
Is
it
possible
to
give
us
an
idea
about
the
nature
of
those,
because
I
mean
obviously
the
the
most
common
use
case
is
for
trace
context
propagation,
which
you
shouldn't
have
to
manually?
Do
a
bunch
of
extra
work
for.
But
what
can
you
describe
like
what
the
nature
of
those
attributes
is.
F
Yes,
so,
for
example,
we
have
incoming
http
calls
which
we
then
pull
down,
or
upstream
grpc
services
and
in
the
incoming
http
call.
We
have
user
agent
right
from
the
user
agent
header
and
you
actually
do
want
to
propagate
that
down
or
propagate
that
to
the
grpc
services,
because
it
does
make
a
difference.
For
example,
if
it's
a
robot,
we
may
do
something
different
in
the
grpc
service.
F
So
the
way
we
currently
do,
that
is
we
put
that
as
a
metadata
entry,
essentially
metadata
user
agent
equals
copy
across
from
what
the
http
incoming
header
was.
F
E
Yeah
yeah,
if
it
was,
I
mean
if
it
turned
out
to
be
a
common,
and
you
just
want
to
capture
it
one
to
one.
F
E
E
E
Thank
you,
lori
for
the
the
performance
numbers
that
life
ray,
isn't
enormous.
It's
like
the
one
that
loads
the
most
classes.
I
E
Mathias
did
you
oh.
I.
B
It's
not
that
I
think
it
can
probably
wait
a
bit.
We
don't
have
to
be
included
in
this
release,
it's
something
that
will
become
useful,
especially
to
us
once
we
start
like
rewriting
all
our
micrometer
metric
system,
notations
to
all
the
stack
once
again.
E
Oh
okay,
that
was
one
question
I
had
was.
If
you
already
had
a
need
for
it
or
you
know
you
you're
going
to
need
it.
B
We
sort
of
already
have
one
I
mean
we,
we
are
setting
some
configuration
properties
based
on
others,
but
we've
like
hacked
around
it.
So
yeah.
B
E
I
like
it,
it
made
sense
to
me.
I
think
the
only
question
I
had
was
it
kind
it
felt
like.
Maybe
there
was
a
combined
because
this
is
kind
of
where
yeah
I
think
I
was
doing
something
similar
and
using
this
essentially
to
read
system
properties
and
provide
new
ones
yeah.
I
think
we're
doing
the
same
thing
right.
B
Now
but
yeah
it's
like
drawing
the
command.
It
would
probably
make
sense
to
that.
The
default
properties
method
where
you
can
provide
the
defaults
and
just
remove
the
config
property
source.
B
E
E
Related
to
the
really?
Oh,
yes,
so,
the
stability,
the
rc,
whether
we
call
experimenter
api,
rc.
B
H
E
C
B
Yeah,
so
the
spam
status
extractor
is,
is
probably
a
spam
thing.
I
was
hesitant
about
the
time
extractors
because
there
was
one
use
case
where
we
used
to
set
and
time
in
their
mirror
instrumentation,
but
it
got
kind
of
lost
when
we
migrated
over
the
instrument
api-
and
maybe
it's
just
you
know
me
being
picky,
but
it
looks
kind
of
strange
when
you
get
the
start
and
timestamps
from
different
time
sources.
E
Yeah,
what
do
you
think
about
another
asada
had
was
because
they're
all
basically
like
if
we
exposed
a
timer
and
somehow
allowed
that
to
be
attached
directly.
E
E
Because
I
was
also
trying
to
think
of
how
this
would
work
with
the
like,
we've
talked
about
exponentially,
exposing
the
clock
in
the
sdk
side.
Yeah,
though,
actually
I
think
this
the
current
time
extractor
works
well
with
that,
because
we
would
just
you
would
just
use
that
to
supply
the
time.
B
E
H
B
It
is
especially
the
response
and
the
error
is
kind
of
it's
never
used
and
it's
there
for
it's
neatly,
no
reason
so.
Yeah
I'll
try
out
the
context
version
of
puja
pr
tomorrow,
so
we
can
decide
based
on
that.
E
E
Jonathan,
since
you
are
have
a
are
a
potential
user
of
you
know,
stability
of
the
instrumentation
api,
and
I
know
we've
pulled
out
the
semantic
conventions
from
it,
which
is
part
of
what
you
needed,
but
to
you.
What
does
what
does
rc
mean?
Would
you
like?
Would
you
recommend
us
if
we're
not
sure,
on
a
couple
of
things
still
to
hold
on
marking
the
rc
or
to
go
ahead
with
our
market
rc,
to
kind
of
indicate
that
we're
pretty
close
and
we're?
A
Usually
are
seeing
to
me
that
it
is
like
very,
very
close
to
a
service,
so
ideally
should
be
exactly
the
same.
A
That
is
that
is
going
out
in
the
indigenous,
but
usually
that's
not
the
case
because,
like
between
the
two
like
r,
like
you
did
and
so
on,
but
from
like
suits
side,
we
will
basically
handle
rc
as
just
another
mystery
version,
so
we
will
move
on
to
the
onto
it,
but
we
will
not
like
release
smooth
out
or
stable
until
we
can
depend
on
a
stable
version.
A
So
basically
it's
up
to
you.
Well,
we
will
not
be
really
impacted
by
this.
If
you
are
making
like
still
like
breaking
changes
in
in
an
rc
like
after
an
rc
period
for
us,
it
will
be
fine,
we
will
handle
it
as
my
stories.
E
Yeah,
if
we,
if
we
don't
market
rc,
we
should
definitely
make
that,
like
our
in
every
meeting,
we
in
all
every
weekly
meeting
kind
of
review
make
sure
that
the
next
one
is
rc.
G
E
All
right,
I
will
I'll
try
to
ping
folks
on
slack,
because
yeah
definitely
owe
him
a
review.
C
We
could
talk
about
this
if
we're
looking
for
topics,
we
could
talk
about
this
hikari
upstream
possibility.
I
made
a
comment
to
matasha's
pr
about
us,
potentially
contributing
this,
this
implementation,
because
they
have
a
bunch.
I
don't
know
what
to
call
them
they're
like
adapters.
I
guess
they
have
a
bunch
of
existing
adapters
and
I
just
threw
it
out
there
like,
maybe
that
part
of
it
could
live
in
the
in
their
project
and
then
we
would
just
use
it.
B
He
definitely
agree
with
you.
I
mean
it
would
make
sense
to
include
that
in
hikari,
since,
like
all
the
other
patrick
libraries,
are
there
yeah,
the
only
thing
that
I'm
worried
about
are
the
somatic
conventions
so
like
these
are
still
not
stable
and
yeah.
I
suppose
it
is
a
broader
question,
perhaps
to
the
instrumentation
sick.
B
If
we
contribute
to
a
third
party
library,
how
can
we
make
sure
that
the
changes
to
somatic
conventions
are
propagated
there
correctly
or
if
it
was
somewhat
stable?
If
you
had
a
schema
file,
then
I
suppose
it
would
kind
of
work
because
you
can
translate
or
you
should
be
able
to
translate
between
schema
versions,
but
it's
not
stable
right,
there's
no
schema.
I
I
E
E
Already
more
strongly
pushing
people
to
upstream
native
to
write
native
instrumentation.
E
Laurie
wanted
a
question
to
one
of
your
points
about,
because
I
do
think
it's
in
it's
very
useful
for
the
java
agent,
the
fact
that
everything
is
bundled
together
and
so
all
the
versions
align
and
the
there's,
but
I'm
guessing
in
in
some
of
the
cases
like
as
long
as
the
native
instrumentation
isn't
really
baked
in,
but
is
like
an
opt-in
kind
of
a
like
a
registry
or
something
that
users
still
register.
E
I
C
I
I
And
obviously
like
we
want
to
like,
provide
the
easiest
way
for
the
users
to
get
something
running.
E
Which,
I
think
you
know,
is
sort
of
a
long-term
goal,
but
will
probably
take
longer
for
to
have
that
level
of
trust
in
open
telemetry
breaking
changes
to
make
that
a
core
dependency.
E
I
think
it
would
be,
maybe
maybe
we
should
start
a
issue
to
sort
of,
or
at
least
I
like
the
idea
of
having
a
ongoing
discussion
topic
of.
E
I,
like
it
yeah,
but
maybe
picking
one
you
know
pick
one
basically,
maybe
like
twilio,
something
that
is
not
very
used
and
explore.
You
know
what
that
means.
We
kind
of
have
to
get
a
feel
for
do
we,
how
are
how
receptive
our
libraries
if
we
came
into
their
ecosystem-
and
you
know,
open
an
issue
and
proposed
upstreaming
that.
E
But
I
think
for
now
I
mean
I
think
it
makes
sense
to
continue
with
you
know.
Yeah.
E
Cool
but
yeah,
I
think
it
is,
it
has
I've,
seen
it
come
up
with
this
and
other
languages.
E
I
I
think,
for
example,
in
gold
they
were
pretty
strict,
that
they
didn't
want
to
add
new
instrumentations
into
the
core,
wanted
people
to
maintain
their
their
own
instrumentations.
C
Well,
I
brought
up
this
topic
ad
hoc
and
emily.
I'm
sorry
if
you
had
typed
in
there,
I
didn't
see
it.
So
sorry,
if
you
jumped
in
the
list-
and
I
just
stomped
on
it-
I
don't
think
I
did,
but
if
I
did
I'm
sorry.
E
Yes,
so
we
just
have
a
few
minutes
left.
So,
let's,
let's
get
to
your
topic,.
J
So
it's
we're
having
a
discussion
like
somebody
like
asking,
I
mean:
what's
the
potential
consequences
they
give
for
like
a
one
application,
use
both
open,
changing
and
open
telemetry,
I'm
wondering,
since
these
economies
is
a
major
the
main
place.
Do
you
foresee
any
kind
of
scenario
this
is.
Is
this
valid
like
for
the
application?
J
So
it's
a
producer
double
trees,
one
biker
from
open
chasing
the
other
one
from
open,
telemetry.
Oh
this!
This
is
just
like
account
once
you
had
a
bad
time,
not
to
turn
both
at
the
same
time,.
E
Jack,
do
you
want
to
take
that
or
I'm
happy
to
take
it
also.
E
Cool,
so
there
is
in
the
open,
telemetry
java,
sdk
repo,
a
open
tracing
shim,
which
allows
users
to
use
the
open
tracing
ap
like
if
they
already
are
using
open
tracing
they
can
plug
that
in
and
that
will
then
emit
everything
through
shim
all
the
calls
into
open
telemetry,
and
that
is
a
an
official
specked
component
by
open
telemetry.
E
I
don't
believe
it
is,
has
been
marked
stable.
Quite
yet.
J
E
J
Okay,
so
this
is
a
kind
of
just
like
you
support
support
the
basically
the
older,
open,
choicing
thing.
My
question
is
in
the
same
app,
or
can
you
use
both
the
open
telemetry
api
together
with
older,
open
training
api
and
actually
to
make
it
more
evil?
On
the
one
method,
your
annotation,
you
use
both
open,
changing
and
open
telemetry.
J
E
I
see
so,
for
example,
if
you
pulled
in
the
open
tracing
grpc
instrumentation
and
the
open,
telemetry
grpc
instrumentation.
Yes,.
E
That
is
not
tested,
or
necessarily,
I
would
say
you
might
end
up
with
double
spans.
In
that
case,.
J
E
Reducing
yeah,
so
reducing
effort
to
migrate
is
what
the
open
tracing
shim
is
all
about
right.
So
the
open
telemetry
project
is
officially
the
successor
to
open
tracing,
and
so
as
part
of
the
sort
of
foundational
charter
of
open
telemetry
was
that
it
would
provide
a
backward
compatibility
story
with
open
tracing
to
help
people
users
move,
so
that
part
is
supported.
E
There-
and
we
did
john
watson
just
mentioned
in
slack
yesterday-
that
he
tested
he
was
using
the
open
tracing
shim
in
real
life,
and
it
worked
so
it
worked
first
time
for
him
like
everything
worked
smoothly.
E
That's
not
you
know
a
promise
that
there's
not
edge.
Cases
like
you
said
like
if
you're
calling
start
span
on
both
open
tracing
and
open
telemetry.
J
You're
shooting
yeah
so
well,
no,
I'm
just
trying
to
say
for
the
scenario
of
both
the
open,
telemetry
open,
choosing
doing
their
own
thing.
This
could
be
quite
a
problem
programmatic,
so
you
for
both
the
creators,
bands
and
etc.
E
Yeah,
maybe
if
you
can-
and
I'm
sorry
we're
over
time
so
but
maybe
if
you
could
bring
a
a
specific
example
next
week,
we
could
talk
through
in
more
detail.
J
Yeah,
that's
fine.
I
think
he
is
a
yeah.
I
will
yeah
try
to
join.
If
I
can
next
week,
yeah
or
or
feel
free
to.
E
Open
it
open
an
issue
also.