►
From YouTube: Open Telemetry's Personal Meeting Room
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).
A
A
A
A
So
I
will
definitely
start
joining.
Is
sharing
that
then
right
now,
so
before
maybe
I
start.
Are
there
any
particular
topics
which
we
want
to
add
here
at
the
end
after
we
review
quickly
everything.
A
All
right,
then,
let's
begin,
let's
check
the
pull
requests
so
there's
one
created
by
Rasmus
to
basically
Rasmus
started
working
on
making
the
things
like
lazy
loaded,
the
thing
which
was
reported
by
Paulo
that
once
to
make
sure
that
the
modules
are
not
loaded
until
necessary.
The
exporters
instrumentation
libraries
Etc.
So
this
is
some
peers
were
already
merged.
So
this
is
the
next
one.
Personally,
I
have
reviewed
and
I
have
no
comments,
any
resumes.
Anything
from
your
site
or
just
you
ask
for
take
a
look.
C
It's
not
to
the
pr
itself,
but
one
thing
that
I
keep
going
back
to
my
mind
in
this
regard:
it's
because
we
did
this
for
some
instrumentation
already
that
I
forgot,
which
one
we
use
internals
and
I
mentioned
in
a
comment.
Perhaps
we
should
update
the
recommendations
for
people
writing
in
the
contribute
to
make
this
stuff
public.
Besides
the
extension
method,
you
know
the
extension
map
they
need
to
do
anyway,
but
perhaps
we
should
update
that
you
know.
E
There
is
another
option
to
make
our
Library
like
internally
visible
for
the.
C
That
that
makes
a
very
complicated
to
coordinate.
You
know,
I
think
I
think
make
requiring
to
make
that
as
an
API
not
required
but
guiding
people
to
making
that
as
a
public,
API
I
think
it's
a
bad
approach.
A
C
C
C
A
A
F
Maybe
just
either
dumb
question
what
was
what
was
that
for,
like
the
SDK
theme
or
should
I
take
that
question.
Ask
that
question
at
the
end.
A
No,
it's
okay
to
ask
kids
now,
so
you
get
so
in
the
dot
net.
Sdk
repository
here,
I'm,
not
sure.
If
I
find
it
very
quickly.
There
are
some
docs
regarding
creating
instrumentation
libraries
I.
A
Think
it's
I'm,
not
sure
if
it's
here
yeah
it's
here
so
here
are
the
docs
for
the
and
Paulo
wants
to
add
more
recommendations
to
make
make
life
easier
for
us,
because
the
right
now
the
recommendations
which
are
like
explained
here
like
Works
in
a
scenario
when
you
inject
the
stuff
in
the
bootstrapping
right
when
you're
creating
your
own
application.
But
for
our
use
case
for
our
for
auto
instrumentation,
we
are
not
sure
what
Auto
instrumentation
libraries
will
be
needed
when
the
Tracer
is
created.
So
we
are
using
like
internal
code.
A
F
C
Yeah,
basically,
there
is
the
extension
method
that
goes
on
the
trace
Builder
and
makes
a
lot
of
sense
for
people
that
are
writing
the
instrumentation
code.
But
in
our
case
what
happens
is
we
wait?
The
assembly
that
should
be
instrumented
to
be
loaded
when
data
has
since
loaded
right?
Now
we
have
a
turbo
I
think
we
had
to
kind
of
go
to
the
internals
and
basically
do
the
same
thing
that
the
extension
method
is
doing.
So
my
my
point
is
that
actually
the
instrumentation
Library
should
be
should
be
written
with
that
part
public.
C
So
we
can
just
call
and
establish
a
contract
with
them
about
the
instrumentation.
You
know
if
they
plan
to
break
that,
then
we
are
not
going
to
be
are
caught
by
surprise.
It's
part
of
the
API.
C
Yeah,
usually
the
code
inside
the
extension
method
for
getting
the
configure,
but
inside
the
the
code
for
the
extension
method,
the
add
WCF,
add
X
instrumentation.
Usually
it's
pretty
simple,
but
usually
it's
not
exposing
questions.
A
A
A
A
Think
yes,
but
it
looks
awkward
that
there's
a
new
nuget
without
a
release
on
GitHub
nor
tag,
and
here
we
have
some
new
bumps
regarding
the
new
as
dotnet
7
release
and
I
think
that
some
of
them
needs
to
wait
until
we
add
some
support
for
for
the
new
diagnostic
Source,
but
some
like
login
as
login
abstractions
configuration
I,
think
they're
only
failing
because
of
the
additional
depth.
That's
my
guess:
additional
dependency
structure
and
probably
they
should
be
bumped
and
merged.
E
A
And
I
think
that
some
time
ago,
Raj
suggested
to
have
the
latest
for
some
reasons
if
for
some
reason
we
load
it
faster
before
the
application
to
make
sure
that
there
are
no.
You
know
there
are
no
missing
features.
A
G
Yeah
I
just
want
to
make
sure
that
we're
still
able
to
support
uh.net6
smoothly
foreign,
just
because
I
suspect.net6
will
have
a
larger
user
base
than
net
7.
since
dot
net
6
is
long-term
support.
C
Yeah,
we
will
have
the
issue
when
we
upgrade
the
package
from
the
SDK
that
use
seven.
So
so
far
we
didn't
do
it
yeah,
but
I
I,
I,
I,
perhaps
I'm
misunderstood
I
I
thought
that
Robert
was
suggesting
to
hold
this
seven
zero
upgrade
until
we
do
the
packages
right.
C
Yeah
I
think
I
think
we
want
to
confront
the
problem
you
know,
but
we
need
to
be
very
conscious
about
that's
that's
the
thing
you
know
so
I
think
we
have
trapezed
the
packages
that
is
stuff
that
we
wanted
from
from
from
those
updates.
C
But
we
we
need
to
be
very
careful
that
hey
from
now
on
this
happens,
you
know
so
yeah,
so
I
I'm,
I'm
I'm,
just
saying
I'm,
fine
with
postponing
those
except
for
the
test
integration
test
integration
we
can
up
at
ratio.
Seven,
that's
not
gonna
make
a
a
difference,
but
the
other
ones
we
we
should
postpone
until
we
upgrade
the
the
the
packages
yep.
A
C
A
Some
of
the
issues
that
are
just
here
because
you
want
to
revisit
them,
there
was
an
issue
created
by
me,
sometimes
go
to
attempt
to
dispose
spending
activities
when
application
exists
and
because,
right
now
we
have
a
possibility
to
like
push
to
add
some
I
think
environment
available
to
like
flash
the
the
traces
and
metrics
to
the
exporters.
A
Next,
one
I
think
I
had
trouble
finding
who
created
this
like
who
was
proposing
this
one,
but
I
think
it
was
I
think
it
was
Zach
to
add
support
for
getting
the
latest
version.
So
right
now
the
dogs
just
each
time.
We
make
a
release.
We
have
an
information
to
basically
right
now.
A
We
could
right
now
because
we
have
in
the
artifacts
proposed
to
use
the
latest
here
to
get
the
latest
version.
However,
I'm
not
sure
if
it's
something
that
we
should
propose
for
because
we
might,
we
still
will
be
introducing
breaking
changes
from
the
users
and
they
may,
if
they
will
use
this
approach.
A
They
may
say
at
some
point
that
we
we
broke
the
installation
and
one
change
that
could
be
could
be
like
breaking
the
users
if
they
will
use
such
approach
is
that
right
now
we
are
in
prayer
release,
so
we
are
making
just
breaking
changes
in
configuration,
but
second,
which
I
expect
will
happen
even
after
stable
release
will
be.
That
will
be
dropping
support
for
legacy.net
versions.
B
A
B
B
A
A
A
F
A
C
Just
a
quick
comment
about
this,
because
I
I
look
at
related
stuff
recently
the
way
that
we
Mark
the
instrumentations
is
kind
of
because
came
from
Upstream
at
the
time
that
they
have
that
calcite
instrumentation
it's
kind
of
a
bit
backwards
in
the
sense
that
we,
if
you
think
from
the
point
of
view
of
the
profiler,
not
the
writing
the
code
from
instrumentation.
C
What
you
want
to
have
as
the
top
level
thing
is
the
assembly
itself
right
and
even
that
we
should
having
even
the
framework
that
we
are
running
as
actually
the
toughest
level
of
all.
So,
if
you
don't
have
the
instrumentation
for
a
framework,
we
are
not
going
to
even
look
at
the
module
because
right
now
we
end
up
looking
at
the
module
is
not
a
a
big
deal.
But
then
we
are
looking
through
the
module
just
to
kind
of
hey
I'm
not
going
to
find
anything.
C
And
if
we
reorganize
that
data
in
a
in
a
better
shape,
we
can
avoid
kind
of
that
inspection
because
we
already
know
that
the
receipts
targets
are
going
to
be
zero.
So
we
can
do
that.
So
it's
optimization,
but
it's
also
kind
of
to
make
to
make
the
process
straightforward.
You
know
the
way
that
the
Json
is
organized
right.
Now
is
not
the
ideal
for
the
native
part
of
the
code
that
does.
A
C
But
but
oh
yes,
yeah
that
that
one
point
the
award
is
also
that
we
can
do
a
lot
of
that
pre-processing
when
we
generate
the
file
right.
Yes,
yes,
so
we
we
can
do
that
at
build
time,
not
build
time.
But
when
we
update
the
Integrations
Json
or
whatever.
F
A
Json
or
what
what
is
this
integrate?
I
will
just
show
you,
so
we
have
a
file
called
Integrations
Json,
so
the
integration
is
Json
is
a
file
which
our,
which
is
analyzed
by
the
CLR
profiler,
to
make
bytecode
instrumentation,
which
means
which
is
used
for
registering
the
methods
so
once
so,
for
instance,
here's
a
graphql
in
bytecode
instrumentation
and
when
a
type
from
assembly
graphql
method
execute,
is
called
with
these
signatures.
Then
it
uses
this
wrapper
assembly
to
register
to
register
this
code.
So
it's
making
a
wrapper
for
for
this
stuff.
D
C
F
F
F
Sorry
sorry
yeah
yeah,
so
in
that
issue,
maybe
we
can
I,
don't
know
how
we
should
approach,
but
like
can
can
someone
like
best
the
Json
like
so
that
we
all
can
see?
Okay,
this
is
how
we
are
going
to
do
it
and
so
that
everyone
is
onboarded
with
it.
Like
understanding
perspective
right,
then
we
will
before
implementing,
like
everyone
understand
yeah.
This
is
the
this
is
the
right
way.
Then
we
cannot
remember.
D
C
We
have
some
documentation
of
the
internals,
but
I
actually
think
they
perhaps
deserve
a
update
and
review
if
I
have
a
chance.
I'll
take
a
stab
at
that.
Okay,.
A
Next
one,
we
got
an
internal
request
at
Splunk
to
distribute
our
our
Auto
instrumentation
in
similar
way,
like
data
dog
does,
which
is
something
which
we're
talking
I
think
months
months
ago,
to
distribute
the
Tracer
as
a
nuget
package.
G
So
one
thing
that
I
just
want
to
clarify
in
regards
to
the
nuget
package,
because
we've
talked
about
having
a
nuget
package
for
a
while,
but
we've
talked
about
the
nuget
package:
solving
to
distinct
problems,
one
is
for
getting
dependencies
aligned
and
then
the
other
is
actually
packaging.
G
A
Or
the
artifacts
so
that
when
someone
uses
this
nougat,
he
just
needs
to
put
the
environmental
variables
and
it
will
work
so
the
so
the
auto,
so
our
Auto
instrumentation
is
put
alongside
with
the
application.
Just
you
know,
as
a
inside
the
folder.
G
So
so
are
we
looking
to
solve
both
the
artifact
packaging
and
the
dependency
resolution?
I.
A
Think
this
one
should
be
put
earlier,
as
the
artifacts
just
to
have
I
propose
to
separate
these
two
issues:
okay,.
G
G
Sense
to
separate
I
think
ultimately
will
want
both.
Yes,.
C
C
We
have
a
pretty
good
idea
how
to
do
it,
but
the
version
of
part
is
where
we
are
gonna
learn
this
stuff
right
so
makes
a
lot
of
sense
to
me
to
separate,
but
in
the
end
the
end
goal
is
to
solve
the
two
things
we've
nougat
I
would
say
that
right
now,
I
don't
have
a
clear
picture
if
we
end
up
with
kind
of
a
uber
nougat
package
that
solves
both
problems
or
you
have
packets
separate
for
that,
I
I.
G
Yeah
and
I
know
that
Raj
has
talked
about
potentially
having
two
nougat
packages,
but
they
were
for
handling
different
versions
of
of.net
package.
A
G
Okay,
yeah
because
I
remember
Raj,
talking
about
his
vision
being
that
when
we
support
two
versions
of
the
SDK
which
handles
different
versions
of
of.net,
that
a
customer
would
need
to
choose
one
nuget
package
over
the
other
and
so
I
I
I'm,
just
trying
to
understand
which
concerns
we're
trying
to
handle
at
a
given
time.
C
Yeah
so
I
think
a
good
way
just
to
describe
what
I
think
the
the
case
that
Robert
was
just
created.
The
usual
is
about
the
distribution
case.
Is
we
encountered
a
few
users
that
have
the
following
scenario?
The
person
write
the
application
doesn't
control
much
the
image
so
for
them
kind
of
to
say:
hey,
I'm,
gonna
ship.
This
with
my
application
via
the
new
get
package,
is
very
good
for
them.
They
can
just
ask
whatever
is
deploying
to
set
environment
variables.
C
A
C
If
content
files
is
correct
already
there,
this
should
be
just
a
matter
of
validating
right.
F
I
just
wanted
to
understand
once
again,
so
is
it
something
like?
Are
we
thinking
in
terms
of
like
CLA
type
of
thing
or
like?
We
want
users
to
add
this
as
a
part
of
their
project
dependency.
C
Yeah
just
add
as
part
of
the
dependence
project,
because
at
least
the
case
is
that
we
got
users
asking
for
it
is
the
case
that
who
is
building
the
application
kind
of
doesn't
control
that
part
of
the
deployment.
So
it's
easier
for
them
to
say:
hey
I'm,
not
gonna,
use
anything
of
this
in
my
application.
But
if
I
have
a
new
get
package
I'm
shipping
with
my
application,
so
they
can
ask
deployment
just
to
set
environment
variables.
Usually
they
have
ux
experience
that
allows
them
just
to
set
environment
variables.
F
Yeah
and-
and
in
case
it's
it's
from
a
devops
Persona
right,
let's
say
developer-
doesn't
handle
instrumentation,
it's
all
handled
by
devops,
then
then,
how
we
are
proposing
like
because
developer
is
just
writing
the
logic,
so
in
that
case,
so
do
we
is
there
a
CLI
which
they
can
just
you
know
say
that
he
has
a
part
of
my
deployment.
This
is
the
command
to
run
into
dot
or
instrument.
It
yeah.
C
We
have
the
scripts
that
Rasmus
and
Robert
did
some
work.
We
have
the
Powershell
module
and
for
we
have
some
scripts
for
Shell
to
do
that,
so
they.
This
is
another
alternative
to
be
fair,
I
kind
of
from
my
developers.
Perspective
I
was
like.
Oh,
the
script
is
all
that
everyone
needs,
but
we
did
get
the
feedback
that
people
were
like.
No,
they
don't
get
packages
much
easier.
So.
G
Honestly
I've
seen
people
request
a
new
get
package
for
when
they
want
to
instrument
their
application
in
a
cloud
service,
especially
azure.
I
Yeah,
this
is
one
of
the
that's
one
of
the
bigger
reasons
if
they
don't
have
control
of
the
underlying
system.
I
think
service
fabric
was
one
of
those
as
well,
so.
C
Yeah
I
I
think
perhaps
Azure
allows
custom
images,
but
the
problem
is
that
then
they
have
to
create
the
Custom
Image.
If
you
have
the
new
get
packages
much
easier
so.
A
C
A
C
Question
right
now
so
just
to
confirm
they
have
how
to
test
this
from
the
build
kind
of.
If,
if
we
have
a
fix
and
it's
merged,
I
know
that
we
produce
some
of
the
artifacts.
But
for
this
specific
case,
do
they
have
a
way
to
test
that
the
fix
is
good
or
not.
C
A
A
Okay,
so
we
get
a
new
security
advisory
for
independable
critical
one,
but
it's
for
the
test.
Application
and
I
created
this
issue
to
have
a
common
agreement.
What
we
do
regarding
such
such
basically
alerts
for
the
test
applications
I
see
three
proposals.
A
One
is
to
bump
these
ones,
because
then
we'll
get
rid
of
the
issues,
if
they'll
happen
again
or
I,
don't
know
for
Forks
or
whatever,
and
in
that
that
way,
we
also
say
that
we
are
not
supporting
nosql
libraries.
The
second
is
to
ignore.
There
is
the
reason
is
that
we
should
basically
work
whatever
the
client
is
using,
so
it
may.
A
They
may
be
reasons
that
our
that
that
the
users
are
using
some
old
version-
or
maybe
they
didn't
get
even
a
chance
to
update
it
and
yeah
and
also
the
other
reason,
is
that
it
may
be
a
breaking
change
for
the
users.
If
we
start
supporting
some
older
version,
if
we're
not
testing
it,
then
we
are
not
sure
if
it's
still
working
first
solution
is
to
make
some
hack
just
to
get
all
rid
of
these
others
or
on
GitHub.
A
However,
this
hack
may
only
work
for
on
GitHub
and
and
I
yeah,
but
it
will
solve
the
issue
that
that
will
get
not
reports
but
still
other
other
static.
Analysis
may
find
it
initially.
I
C
Yeah
I
I
was
gonna
say
that
we
we
should
look
at
the
case
by
case
we
we
lost
the
capability
that
Upstream
has
of
testing
range
right.
Now
we
don't
have
that
capability,
but
I
would
say
in
line
with
what
Zach
was
saying
kind
of,
let's
Bob
the
version,
the
range
we
already
test
with
one
tree
in
the
past.
Let's
go
to
one
four
we
made.
Sometimes
that's
the
part
that
could
be
harder.
C
We
may
need
to
update
the
instrumentation
in
this
case
doesn't
seem
to
be
the
the
case
here.
But
if
the
bumper
requires
update
the
instrumentation,
then
we
force
it
to
have
a
bug
to
release
fix
the
issue.
Right
so
I
would
say:
let's
try
to
bump
these
applications
that
come
with
the
security
issues.
E
It's
basically
shipped
from
second
version,
but
the
seven
is
already
out
there.
C
F
B
B
C
A
E
E
E
A
A
C
E
E
D
E
B
A
E
I
Yeah,
the
only
maybe
only
issue
with
running
on
Main
is,
if
maybe
like
a
release,
needs
to
be
time
bound.
Definitely
scheduled
could
work
as
well.
D
A
Not
really
because
we
are
using
also
reflection
in
sourceful.
A
C
I
F
F
And
just
just
a
quick
question,
so
Paul
I
wanted
to
understand
when
you
were
telling
like
that's
why
we
should
go
for
just
type
of
API.
So
are
you?
Are
you
referring
like
okay?
If
a
package
has
an
API
which
is
auto
instrumented,
then
we
should
Target
that,
rather
than
targeting
everything
is
that
what
you
mean.
A
We
I
think
we
mean
that
if
there's
a
new
release
of
an
instrumented
Library,
we
should
still
support
the
previous
ones,
so
that
we
make
sure
that
our
outer
instrumentation
is
still
working
with
the
previous
versions
of
the
library.
Even
though
there
were
breaking
changes
in
the
API.
G
C
Right
now
we
are
doing
it
yeah,
sometimes,
especially
if
byte
code.
If
it
depends
on
the
internals,
we
may
have
to
write
a
new
version
to
support
the
new
release.
Hopefully
that
doesn't
happen
frequently
or
something
like
this.
Another
reason
why
we
prefer
other
this.
What
we
call
Source
instrumentation,
that
we
just
use
the
package
that
somebody
wrote
for
that
instrumentation.
We
just
do
the
hookup
of
that
package
yeah.
So
we
try
to
avoid
avoid
bytecode
instrumentation
as
much
as
we
can,
but
there
are
times
that
there
are
no
other
Alternatives.
B
B
Instrumentation
and
you
can
check
how
the
internal
API
changed
and
it
is
breaking
change
from
our
perspective,
but
it
is
not
breaking
change
if
we're
speaking
about
the
public
API.
A
A
A
Okay,
I,
keep
on
slack
or
just
get
disconnected.
I
have
to
drop
okay.
A
Appeared
you
want
to
tell
something
about
this.
One
you're.
D
A
And
okay,
I'm,
not
I,
think
Paulo
hasn't
got
a
chance
exactly
any
any
chances
or
not
at
all.
For
this
one,
no
progress
any
chances
for
progress
or
not
really.
I
I
think
I
can
spend
some
time
at
the
end
of
this
week.
On
that
awesome.
A
A
G
F
I
think,
once
again,
I
I
am
starting
to
look
into
it,
so
I
I
might
be
for
few
of
you
guys
when
I'm
getting
stuck
and
I'll
see
if
I
can
schedule
some
time
with
any
of
you
just
to
do.
You
know
bring
me
up
to
this
page
or,
if
I
need
to
so
yeah
yeah
other
than
that
I.
Don't
have
any
anything.