►
From YouTube: 2022-04-27 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).
C
C
C
C
I
have
kept
it
simple.
No,
no!
No,
but
just
getting
the
discussion
and
the
ball
rolling
is
important.
C
I
love
your
proposal,
robert
because
I
just
before
the
meeting
asked
chris
to
do
that
today,
just
to
ensure
rotation,
but
I
think
it's
good
to
make
kind
of
more
formal.
D
Okay,
so
let's
take
a
look
at
our
pull.
Requests
so
looks
like
we've
got
two
one
for
versioning
documentation.
D
And
so
a
couple
of
us
have
reviewed
it
just
asking
for
a
few
more
eyes
on
this
before
we
go
forward.
I
don't
know
if
there's
anything
we
want
to
discuss
about
it
here,.
C
D
E
I'm
waiting
for
confirmation
from
the
list
from
governance
committee
about
this
notice.
He
told
me
briefly
that
it
is
not
so
simple
to
remove
it,
but
there
is
no
exact
exact
recommendation,
so
the
easiest
way
is
to
just
remove
the
third
party
files
and
keep
for
a
while.
You
know
the
notice
file
and
then
handle
it
separately.
E
D
D
Any
thoughts
we
could
mark
this
as
whip
or
we
could
revert
the
notice
change.
B
B
D
D
D
F
F
D
Yeah
so
hopefully
this
will
help
get
you
to
the
next
step
in
trying
things
out,
but
yeah.
If
there's
more
questions
feel
free
to
reach
out
to
us
in
the
issues
or
via
slack,
whatever
you're
most
comfortable
with.
C
D
D
So
this
is
the
issue
that
that
was
submitted
by
brant
and
yeah.
D
B
B
F
F
Can
we
close
that
one
oh
beta
milestone.
B
E
E
E
D
D
Yes,
at
this
point,
I
don't
know
if
it
makes
sense
to
add
this
to
a
milestone
or
anything.
Yet,
we've
started
to
submit
separate
issues
to
track
specific
items
of
work,
but
it's
worth
taking
a
look
at
this
issue
just
to
see
what
questions
are
coming
up.
D
Okay,
so
this
next
one,
this
was
something
that
I'd
come
across.
While
I
was
putting
together
an
example
for
installing
the
this
project
and
setting
up
the
environment
variables-
and
I
just
noticed
that
oh
okay
yeah
this
naming
convention.
D
C
D
Probably
a
good
idea:
there's
going
to
be
a
lot
of
environment
variables
in
the
profiler
that
probably
don't
follow
our
conventions.
C
G
C
G
D
We
have
the
proposal
from
robert.
D
B
C
Yeah,
I
think
this
deserves
kind
of
a
separate
discussion
on
its
own.
So,
as
robert
said,
I
think
the
idea
for
now
is
to
read
think
about
it.
Let's
continue
with
our
beta
and
get
feedback
on
that,
and
then
we,
I
don't
know
by
the
time
of
1.1
beta.
We
kind
of
have
one
discussion
about
this,
so
we
kind
of.
B
Okay
sounds
good,
maybe
you'll,
just
maybe
one
thing
that
maybe
I
have
not
put
it
I'll,
just
update
that
later.
Basically,
I
was
thinking
of
having
these
functionalities
related
to
bootstrapping
the
sdk
more
to
move
it
into
the
sdk
as
kind
of
another
nougat
package
and
have
this
project
here.
Just
like
this
auto
instrumentation
using
the
dotnet,
profiler,
regiting
and
stuff
like
that.
D
Yeah
that
I
mean
it
sounds
a
lot
more
similar
to
what
java
has
for
their
auto
configure
module
and
and
that
distinction.
D
Yeah
so
java
has
this
auto:
configure
module
that
can
look
at
environment
variables
and
other
things.
D
Right
to
automatically
configure
your
things,
even
when
using
the
sdk
and
then.
C
So,
in
a
sense
this
could
be
just
a
separation.
Just
know
just
sounds
like
smaller
that
I
I
mean
it
could
be
seen
as
a
separation
of
the
concerns
regarding
the
sdk
and
the
instrumentations
itself.
So
it's
even
possible
to
see
this
kind
of
having
a
different
package
that
takes
care
of
the
sdk
or
part
of
that
and
separating
that
concern
about
io
instrumentation.
D
Possibly,
I
suspect,
we'll
we
might
still
run
into
some
some
oddities
with
trying
to
truly
support
that
devops
scenario:
yeah
yeah.
D
Yeah,
and
so
it's
kind
of
the
these
sorts
of
discussions
was
one
of
the
reasons
that
that
I
brought
up
that
other
proposal
regarding
versioning,
where
we
might
have
a
longer
path
towards
getting
to
a
1.0.
D
And
so
I
just
yeah
hoping
for
the
version
to
be
easier
to
understand,
instead
of
people
having
to
arbitrarily
assume
that
a
beta,
1
or
beta
2,
which
one's
newer
and
what
changes
are
in
there.
D
And
here
doesn't
look
like
it
and
in
our
project
board,
looks
like
it's
just
the
stuff
that
we've
talked
about.
D
So
as
far
as
the
committed
work
I
haven't
gotten
started
on,
putting
together
a
draft
of
the
blog
post,
I
wanted
to
work
through
end-to-end
installation
guide.
That's
gonna
help
inform
what
I'm
gonna
put
in
the
announcement
blog
so
that
that's
where
I'm
at.
D
And
let's
see
yeah
so
robert
yeah,
I
think
it
makes
sense
for
for
us
to
rotate
through
driving
the
meetings
unless
somebody
really
wants
to
drive
the
meetings
all
the
time.
D
And
yeah
raj
looks
like
you're
up
yep.
H
So
the
proposal
is
going
to
be
very
simple.
I
was,
I
thought
about
many
things,
but
I
kept
it
simple
for
this
one
and
the
first
thing
is:
I'm
keeping
only
the
dot
net,
6
and
dot
net
7
preview
or
7
itself
as
a
scope
here
and
kept
the
other
frameworks
like
core
3.1
5.0
and
the
dotnet
framework
itself,
classic.net
framework
itself
out
of
scope.
H
The
reason
is
like
these
two
are
going
to
get
retired
even
before
we
release
something
and
a
dotnet
framework,
since
it's
classic,
we
have
the
other
ways
like
binding,
redirect
and
all
to
solve
the
issue
in
that
space.
So
I'm
just
considering
dot
net
six
onwards.
How
we
can
move
over
here
so
even
before
we
get
into
an
issue,
let's
like
discuss,
take
a
minute
to
check
how
we
will
how
an
user
will
use
the
diagnostic
source
in
an
application
for
both
dot
net
six
and
dot
net
seven.
H
There
are
two
possible
ways
to
use
a
diagnostic
source
with
six
row.
One
with
like
will
not
have
any
reference
to
the
diagnostic
source.
H
In
these
kind
of
scenarios,
a
diagnostic
source
from
the
framework
will
be
utilized
and
the
app
may
have
a
direct
or
indirect
package
reference
to
diagnostic
source.
It
can
have
a
diagnostic
resource
reference,
greater
than
or
equal
to
six
dot.
Oh
the
same
scenario
for
like
7.0:
it
can
app
without
a
diagnostic
source.
An
app
can
have
a
direct
or
indirect
reference
only
to
7.0
at
this
point
as
it's
in
preview,
so
loading
a
diagnostic
source
version,
less
than
that.net
version
is
not
possible.
H
For
example,
if
a
user
has
a
like
a
dotnet
6.0
app
and
if
they
have
a
package
reference
to
diagnostic
source
5,
it
will
auto
upgrade
them
to
a
6.0
at
the
build,
even
if
they
do
a
publish
or
something
like
they
will
have
a
library
from
the
6.0
and
not
from
the
package
reference.
H
C
Just
one
question
before
that:
your
reference
for
the
diagnostic
source
about
not
going
lower.
This
applies
only
to
the
framework
assemblies
or
does
it
apply
to
known
framework
assemblies.
H
It
applies
only
to
framework
assumptions,
so,
okay,
this
case
is
good
for
both
diagnostic
source
and
the
at
the
extension
start.
Logging
for
us.
G
H
So,
coming
back
to
the
real
issue,
what
we
are
running
into,
if
application
has
a
package
version
like
v1
of
diagnostic
source
and
attempt
to
load
a
v2
version
of
diagnostic
source
only
if
the
version
is
higher
than
the
one
used
by
an
app
like
we
might
crash
that
application.
So
if
the
diagnostic
source,
which
dynamically
that
we
attempt
to
load,
is
same
or
lower
than
the
like
app
version,
there
are,
there
is
no
impact.
H
So
in
case
of
like
auto
instrumentation,
I
kind
of
repeated
the
same
thing
again
here
in
case
of
auto
instrumentation.
If
you
try
to
load
a
diagnostic
source
version
which
is
higher
than
the
diagnostic
source,
that
is
with
an
application,
we
will
run
into
this
issue.
Currently,
we
are
working
on
if
we
haven't
worked
around,
but
we
don't
have
a
complete
solution
for
this.
H
H
This
issue
will
not
happen
for
us,
like,
since
the
like
diagnostic
source
is
used,
is
same
or
higher
version
in
the
app
all
the
time
so,
but
we
could
answer
anticipate
this
issue
if,
for
example,
if
the
open
telemetry
now
has
a
reference
to
diagnostic
source
6,
if
they
release
something
with
by
taking
a
reference
to
diagnostic
source,
seven,
that's,
that
is
when
we
will
break
the
sixth
auto
applications.
H
H
H
The
proposal
is
to
include
the
two
version
of
open,
telemetry
sdk,
the
first
package,
with
the
reference
to
the
lower
supported
version
of
the
diagnostic
source,
for
example
like
if
open
telemetry
has
a
like
open,
telemetry,
sdk,
1.21.2,
3
and
or
not
4,
which,
as
a
reference
to
diagnostic
source
6.0,
we
can
use
the
that
lowest
possible
version
as
open
telemetry,
sdk
1.4
and
the
second
sdk
package
with
the
highest
supported
version
for
in
this
case
they
might
have
something
released
called
as
open,
telemetry,
sdk
1.8,
which
has
a
reference
to
diagnostic
source
7.
H
We
can
have
that
as
a
second
package
in
our
app.
So
in
this
way
we
can
like,
in
the
startup
hook
we
can
identify.
We
can
try
loading,
a
diagnostic
source
and
identify
a
version
which
is
loaded.
So
if
it
is
a
low,
if
it
is
a
lower
version,
we
can
use
the
first
package
if
we
find
it
like.
If
it
is
a
it
can,
we
can
use
the
highest
package.
We
need
to
load
the
other
sdk
in
this
version.
We
in
this
way
we
will
not
leave
out
any
space
in
all
the
environment.
H
H
We
may
have
an
issue,
for
example,
if
a
vulnerability
is
like
identified,
we
don't
have
a
problem
with
the
the
highest
supported
package,
because
any
which
way
open
telemetry,
sdk
maintenance
will
go
and
fix
that
and
release
a
new
version,
but
we
also
need
a
help
from
them
like
to
fix
the
same
issue
with
the
lowest
supported,
open,
telemetry
reference,
which
is
taken
by
auto
instrumentation,
for
example.
H
H
H
So
if
a
similar
issue
is
identified
with
diagnostic
source,
we
auto
instrumentation
should
back
off
when
it
identifies
a
vulnerable
library
and
provide
a
message
in
our
logs
to
update
the
diagnostic
source.
But
there
is
an
option
we
can
use
it
if
we
are
not
in
an
agreement
to
have
a
flag
to
control
this
behavior,
how
we
need
to
go
about
it.
Yeah
in.
H
Our
least
package
version
sdks
will
depend
on
like
diagnostic
source
6.0.1,
whichever
is
the
patched
version.
In
that
case,
I
will
go
to
proposal
2
and
also
take
questions
together.
The
proposal
2
is
not
new.
We
already
have
an
issue
in
our
repo,
where,
like
we
will
create
a
proxy
to
listen
to
the
activities
created
in
the
lower
version
of
the
diagnostic
source,
converted
to
the
highest
version
of
it
and
give
them
to
the
like
open,
telemetry
sdk.
H
But
this
has
a
high
maintenance
cost
and
any
small
changes
in
the
api
will
change
our
implementation
and
it's
very
difficult
to
manage
on
a
longer
run
and
any
new
release.
We
need
to
have
in
your
version
of
the
proxy
over
here,
so
I
have
another
one
for
open,
telemetry
side
by
side,
but
I
I
just
want
to
stop
here
and
take
questions
and.
D
Yeah
so
one
question
I
have
regarding
proposal,
one
it
seems
like
we
would
have
to
get
some
buy-in
from
the
sdk
sig
on
having
a
set
of,
I
would
guess,
to
call
it
long-term,
supported
versions
for
lack
of
a
better
term
and
and
have
buy-in
and
say
that.
Okay,
these
versions
are
the
ones
that
we
will
apply,
bug
fixes
and
security
fixes
too,
but
then
they
also
have
a
a
lifetime
as
well
kind
of
like
how
different.net
versions
have
their
own
lifetime.
H
That
is
correct.
I
had
an
like
casual
conversation
with.
Who
is
the
maintenance
for
that
repo?
He
says
whatever
they
ask
he
he.
He
believes
that
these
two
like
like
auto
instrumentation
and
the
sdk,
should
work
together,
and
this
is
a
valid
ask
for
the
sdk,
but
he
said
like
once
like
if
an
auto
instrumentation,
if
we
are
all
in
agreement,
then
we
can
just
go
and
meet
the
open,
telemetry
sdk
maintenance
to
see
how
we
can
take
this
forward.
C
Okay,
okay,
so
so
just
to
be
sure.
If,
because
from
only
the
sdk
perspective
fix,
a
security
fix
could
be
kind
of
considered,
hey,
let's
upgrade
the
diagnostic
source
and
release
a
new
sdk
for
them.
It's
a
fix.
They
tell
for
people
hey
move
to
this
version,
but
because
of
our
interaction
with
the
framework,
we
may
require
them
to
keep
some
older
version
with
the
fix
right.
That's
the
that's
the
issue
yeah.
I.
C
I
also
had
a
conversation
with
seizure
some
time
ago
and
he
basically
stayed
the
same
like
if
there
is
a
need
they
can
keep
and
go
back
to
the
old
version
and
apply
the
fix.
We
don't
need
to
justify
that.
You
know
kind
of
is
not
something
to
take
lightly,
but
I
think
we
we
have
a
a
good
path.
There.
H
Yeah
and
we
have
the
forks
for
what
is
working
from
here
and
that
we
have
our
presence
in
both
the
places.
So
I
don't
think
like.
We
will
have
a
big
challenge
in
that
way.
Even
we
can
go
and
contribute
and
try
get
that
updated
in
the
area
for
the
lower
versions.
C
C
H
H
For
example,
like
till
the
dotnet
6.0
is
supported
by
the.net
team,
we
need
to
hold
the
diagnostic
six
version.
That
will
be
our
only
least
possible
supported
version.
We
are
going
to
hold
it
and
we
will
have
the
one
version
of
the
highest
version.
It
may
be
seven
dot
the
open,
telemetry
sdk,
which
has
reference
to
7.0
or
8.0,
whichever
is
the
newest,
so
we
will
have
only
two
at
any
point
in
time.
D
Is
that
completely
true,
because
so
right
now
we
have
net
six
available,
then
dot
net
seven
is
coming
out,
but
then
we're
also
gonna
have
dotnet
eight
coming
out
the
following
year,
in
which
case
I
think
that
there'd
be
three
active
versions
of
dot
net
at
a
time
so
which
might
mean
three
diagnostic
source
versions,.
C
D
Okay,
so
so
it
does
sound
like
it's.
It's
really,
two
versions,
yep
and
potentially
a
third.
If
we
need
to
support
like
a
latest
preview
or
something
like
that,.
H
Yeah
dot
net,
at
least
has
confirmed
like
many
of
the
you
know,
r6
also
and
in
the
their
repo
itself
that
when
we
break
any
breaking,
changes
between
two
is
always
backward
compatible.
H
H
So
open
telemetry
side
by
side.
What
I
call
here
as
side
by
side
is,
for
example,
if
hap
has
open
telemetry
sdk
and
we
are
also
bringing
our
open
telemetry
sdk.
I
call
this
scenario
as
the
side
by
side
here,
so
there
are
four
possible
scenarios
where
the
auto
instrumentation
sdk
could
be
loaded
by
an
auto
instrumentation
one
application
without
open
telemetry,
sdk
and
application
with
api
or
sdk,
with
the
same
version
of
auto
instrumentation
or
same
or
higher
version
or
lower
version,
I
don't
need
to
get
into
that
either
yeah.
H
So
there
are
no
problems
with
approach,
one
two
and
three:
if
there
are
no
sdk
or
the
open,
telemetry
sdk
brought
by
the
customer
is
same
or
higher,
we
can
just
load
rsdk
and
there
won't
be
any
issues.
The
framework
will
always
take
the
higher
version
here.
The
problem
comes
with
the
the
fourth
scenario
here:
when
the
user
has
an
app
which
has
a
lower
version
of
open,
telemetry
sdk,
and
we
try
to
load
the
higher
version,
we
could
crash
an
app.
H
So
currently
we
haven't
like
worked
around
to
do
a
binding,
redirect
or
like
we
could
do.
Additional
additional
dips
may
not
work
because
they
have
a
reference
to
the
opentelemetry.dll
in
their
bin
folder
itself,
so
additional
depth
also
want
only
the
what
we
call
it
as
build
time
dependencies.
What
is
going
to
help
in
this
scenario?
H
So
I
am
keeping
the
same
proposal
over
here,
also
like
open,
telemetry,
auto
instrumentation,
to
include
the
two
version,
the
first
sdk
with
lowest
supported,
sdk
version
and
another
with
the
highest
supported,
open,
telemetry
sdk.
We
will
have
two
of
them,
so
whatever
we
are
trying
to
solve
with
the
diagnostic
source
can
be
combined
and
solved
together
for
this
side-by-side.
Also,
I
also
like
explode.
We
use
in
like
a
il
repack
for
application
inside,
so
I
explore
that
option
whether
that
will
be
a
fit
for
this
piece.
H
The
moment
we
il
repack,
it
will
become
an
entirely
a
different
library
and
if
customer
takes
a
dependency
on
open,
telemetry
sdk
and
brings
those
customization
to
hokkien
into
our
auto
instrumentation,
it
won't
work
so
agile,
repack
is
really
not
an
option.
Even
if
we
need
to
go
that
route,
there
is
a
proxy
work
we
need
to
do,
which
is
I
I
felt
it
is
unnecessary,
so
the
proposal
is
same
as
of
the
diagnostic
source.
H
So
in
this
approach,
if
we
go
with
this
approach,
we
will
have
a
tracer
provider
or
a
meter
provider
initiated
from
both
user
application
and
from
an
instrumentation.
So
this
collects
a
duplicate
telemetry,
and
so,
in
order
to
avoid
the
duplication,
duplicate
like
telemetry,
we
need
to
like
kill
one
of
the
tracer
provider
or
even
instead
of
killing.
We
should
avoid
building
one
of
the
tracer
provider,
so
the
better
bet
would
be
at
this
point
is
to
like
provide
an
option
in
sdk
we
set
at
the
moment.
H
We
set
that
flag
using
environment
variable
or
through
a
reflection
like
the
build
process
should
not
happen.
For
example,
I
have
like
sdk
code
here.
Let's
see.
H
So
we
should
have
a
variable
here
to
written
a
like
a
dummy
trace
provider
for
a
user
call
based
on
some
condition
and
like
anyway,
as
like.
We
are
in
in
case
of
if
we,
if
we
go
with
this
approach,
the
instrumented
sdk
will
load
and
in
the
startup
hook
itself
we
create
a
tracer
provider,
so
our
tracer
provider
gets
initialized
first
and
the
user
trails
provider
will
get
initialized
at
a
later
point
through
they
when
they
go
through
their
code
flow.
H
And
then,
at
that
point,
whenever
they
are
doing
a
like
a
build
call
on
the
taser
provider,
we
will
have
that
flag
set
either
using
environment
variable
or
something
which
will
ensure
that
it
does
not
get
loaded
or
like
created
those
tracer
provider,
orbital
provider.
H
C
Yeah,
I
think
I
think
at
first
looks
much
better
than
writing
the
wrappers
and
using
reflection.
The
price
is
the
size,
perhaps
of
water
shipping,
which,
for
me
in
principles,
is
totally
acceptable.
You
know,
so
I
like
very
much
the
proposed
before
we
follow
up
on
the
discussion.
Can
we
can
you
share
the
block
in
a
way
that
people
can
comment
off
whatever
works
better
if
you
could
share
with
the
sig
after
so
I
will
create
a
pr
with
this.
H
B
H
Oh,
that
should
be
some
like
a
back
off
logic
from
our
end,
actually
like
we
won't
be,
for
example,
even
1.2
is
not
our
least
supported
sdk
here.
The
reason
why
we
I'm
saying
that
is
because
they
don't
have
a
flag
here
for
us
to
load
side
by
side.
So
we
should
wait
for
their
next
release
to
take
that.
H
So
in
those
case,
we
should
back
off
and
follow
our
old
logic,
but
on
a
long
run,
I
don't
think
we
will
run
into
that
issue
and
I
don't
think
it
is
like
widely
used.
This
is
the
correct
time
we
take
a
reference
and
do
the
changes
so
that
we
will
be
in
the
place
like
where
most
of
the
user
will
not
have
the
old
version.
H
Does
that
answer
my
your
question?
What.
D
Yeah,
so
so
just
a
thought.
So
if,
if
we're
talking
about
trying
to
handle
the
case
where
they
are
already
using
some
version
of
the
sdk,
would
it
potentially
make
sense
for
us
to
have
a
nougat
package
that
would
make
the
sdk
available
through
through
our
package,
which
ensures
the
alignment
of
of
the
versions.
H
I
never
explored
that
it
I'm
sure
that
is
also
an
option,
but
that
has
a
build
time
dependency.
It
is
not
really
a
runtime.
They
need
to
have
a
package
reference
in
there.
D
H
I
think
we
should
also
consider
that
as
a
another
one
approach
on
added
to
on
top
of
these
ones,
this
is
going
to
like
more
of
all
the
devops
approach.
This
will
cover
if
the
customer
has
the
like
ability
to
change
them
like
their
cs
project
references.
I
think
that
would
be
an
even
better
approach
for
those
customers.
D
Okay,
yeah,
because
I
guess
the
rba
could
be
made
that
so
like
in
the
case
of
the
application
developers.
D
They
may
be
using
a
version
of
the
sdk,
but
then
some
other
team
is
the
one:
maintaining
the
docker
images
and
they're
simply
installing
our
agent
into
a
docker
image
without
involving
the
the
application
developers
and
so
on.
Yeah.
H
So
we
have
a
like
a
case
like
a
special
case,
I'll
explain
in
case
of
azure,
so
we
have
like
a
lot
of
azure
app
service
customers
like
enabled
application
insights
through
auto
instrumentation.
H
So,
for
example
like
for
that
customer
like
what
we
do
is
like,
instead
of
using
an
application
in
size
xdk,
we
replace
them
with
the
open,
telemetry
sdk.
The
auto
instrumentation
will
replace
that.
In
that
case,
we
need
to
ensure
that,
like
all
the
apps
are
already
running
there,
we
changing
the
sdk
should
not
break
any
of
them,
because
all
of
them
are
the
production
apps.
So
this
is
one
of
the
use
case.
F
So
in
the
case
where
they
in
the
same
case
where
they
have
both
a
reference,
the
sdk
and
they
use
it,
and
then
they
also
add
our
automatic
instrumentation,
do
we
expect
them
to
only
care
about
by
code
instrumentation?
Then
I'm
trying
to
think
about
what
the
use
case
would
be
for
that
customer.
H
There
is
a
one
more
thing
we
discussed
in
in
those
cases
like
apollo
once
bought
it.
He
said
we
there
is
an
option
to
enable
the
clr
profiler
based
instrumentation
through
startup
hook.
So
if
we
figure
out
that
way,
then
we
will
have
the
hundred
percent
of
the
coverage
for
us.
If
that
happens
with
us.
F
Okay,
I
guess
I
was
curious,
because
if
we,
if
we
have
the
ability
to
do,
I
guess
I'm
trying
to
understand
if
we
would
be
adding
new
source
instrumentations
on
top
of
what
the
sdk
has
because
then
it
seems,
like
the
only
value
add
to
me
of
adding
the
automatic
instruction
on
top
of
already
having
the
sdk
is
for
bytecode,
and
if
my
code
institution
is
available
that
allows
us
to
do
a
couple
things
like
we
can
tweak.
F
We
could
do
ill
rewriting
to
do
some
things
to
do.
Some
of
these
changes
without
actual
api
source
changes.
H
C
So
I
I
think
the
the
general
answer
is
yes,
we
still
wanna
debate
called
instrumentation
for
the
cases
that
the
api,
or
there
is
no
source,
instrumentation
or
the
api,
doesn't
generate
activities.
We
wanna
do
the
bytecode
instrumentation.
C
Yeah,
I
think
a
lot
of
the
source
code
instrumentations
are
going
to
require
a
minimal
byte
called
help
to
to
get
hooked
properly.
I
don't
think
a
lot
of
things
we
can
do
like
asp.net
core
or
those
kind
of
things
that
we
can
just
call
the
the
method
and
it
hooks
up.
So
we
just
bring
the
basically
we
we
put
that
in
our
initialization
code.
So
we
don't
change.
We
just
inject
the
code
and
everything
happens.
C
I
think
most
of
case
we
are
going
to
need
some
kind
of
interception
like
in
the
among
the
bks
to
be
able
to
hook
up
the
source
instrumentation.
You
know,
I
hope
that
in
the
future,
that's
not
the
case,
but
for
the
time
being,
I
think
we
are
going
to
need
that
a
lot.
H
Also,
as
we
are
discussing
like
I
just
want
to
check
what
is
the
best
way
to
share
this
document
would
be
a
pr
for
some
readme.md
saying,
proposal.md
or
like
creating
an
issue
in
our
repo,
which,
which
would
be
the
best
way.
C
I
I
think
our
issue
on
the
repo
is
fine,
but
perhaps
we
should
do
like
create
the
issue
on
top.
We
are
gonna,
have
discussions
and
do
the
edges.
They
will.
The
only
part
bad
is
kind
of
we
lose
history.
So
it's
good
to
track
like
what
is
being
edited.
You
know
like
api
proposals
in
dot-net,
runtime.
C
Yeah,
so
I
think
I
think
it's
very
good.
I
think
it's
it's
an
interesting
path,
and
just
just
for
me
to
be
sure,
if
we
are
not
using
the
profile,
let's
say
we
just
want
to
go
with
the
startup
hook.
In
that
case,
of
course,
we
missed
the
instrumentations
that
need
il
rewrite,
but
we
are
able
to
hook
up
the
all
the
other
instrumentations
automatically.
C
As
I
said,
the
price
seems
the
size,
but
the
size,
for
me
principle
seems
totally
acceptable,
especially
taking
into
account
that
cloud
providers
usually
for
these
things
that
don't
change.
They
have
a
way
for
you
to
submit
once
and
stay
closer
to
where
it's
going
to
be
running
so
yeah,
I
think
I
think
at
first
looks
great
to
me,
looks
much
better
than
the
rapper
reflection
route
and
I
think,
satisfies
the
the
the
the
kind
of
isolation
that
you
are
trying
to
get.
So
I
think
it's
really
good.
C
I
think
all
of
us
need
to
stop
and
review
it,
but
at
first
sounds
very
good.
E
H
H
So
in
that
way
we
are
if
we
target
only
the
open,
telemetry
sdk,
we
are
covered
in
the
other
space
also,
so
it's
only
three
things
for
us
to
take
a
look
diagnostic
source,
logging,
library
and
the
open,
telemetry
sdk
itself.
C
And
for
the
modules
that
are
the
assemblies
that
are
not
part
of
the
runtimes,
we
still
have
to
do
the
additional
depths
right.
Yes,
so
I
instrumentation
that
pulls
the
span
depends
on.
I
don't
know.
Abstractions
logging
like
we
are
doing
now.
We
still
have
to
pull
the
right
version,
which
brings
related
to
the
question
that
piotr
was
asking
is
if
there
are
different
versions
of
those
you
know.
C
So
I
think
I
think
a
good
step
on
that
you'll
be
kind
of
try
to
build
the
case
with
those
indirect
dependents.
So
we
can
play
with
it
and
try
to
to
see
how
we
could
possibly
handle
that.
A
Yeah,
I
have
a
plan
to
build
a
grpc
examples
where
application
is
bringing
in
grpc
and
we
are
using
a
grpc
exporter.
So
there
should
be
a
conflict
between
grpc
packages.
Yeah,
that's
a
very
good
case.
D
Any
other
topics,
if
not
I've,
got
one
question
for
the
group,
so
we've
talked
about
our
next
beta,
but
I
want
to
talk
about
just
direction
in
general,
so
the
sdk
sig
has
released
metric
support.
C
Else
my
suggestion
I
was
thinking
about
this
today
too.
I
I
think
we
should
talk
attack
then
in
parallel.
I
think,
for
instance,
the
metrics
they
are
relatively
independent.
They
don't
depend
on
the
instrumentation
we
can.
We
are
going
to
have
the
same
issue
about
versioning,
about
the
diagnostic
source
and
and
any
framework
library,
but
I
think
they
are
isolated.
I
think
we
as
a
kind
of
catch
up
to
the
work
that's
happening.
C
Open
telemetry
should
kind
of
pursue
those
in
parallel
and
regarding
splunk
on
that
in
our
planning
we
are
gonna
try
to.
We
can
try
to
put
part
of
our
team
here
dedicated
to
that.
You
know
to
ensure
that
runtime
metrics
are
moving
forward.
H
H
D
H
C
Which
could
be
fine
depending
on
what
features
we
are
capable
of
bringing
you
know
so.
H
But
also
like
to
summarize
like
once
after
I'm
going
to
put
an
issue
today
once
like,
we
all
agree,
we
might
need
to
join
an
sdk
sig
and
get
the
buy-in
for
these
two
things.
If
we
are
in
agreement.
Yes,.
G
C
Yeah
and
if
we
go,
the
the
two
versions
will
be
natural
for
us
to
do
that.
For
the
time
being,
until
we
we
cut
a
version
that
uses
that
strategy.
C
Which
is
great
for
not
nets
but
make
our
way
here
much
harder.
You
know,
I
think
in
I
don't
know
five
years.
This
makes
the
adoption
of
open
telemetry.net
will
be
kind
of
the
the
best
example
for
languages
and
runtimes.
But
meanwhile,
because
of
the
version
you
think
makes
our
work
for
auto
instrumentation
much
harder.
D
At
the
same
going
forward,
there's
probably
going
to
be
less
byte
code
based
instrumentation
libraries.
Yes,
yes,.
C
Bytecode,
this
is
a
thing
that
I
I
always
remember
greg
saying.
Don't
think
that
we
can
just
drop
the
profiler,
because
there
is
a
bunch
of
other
things
that
perhaps
we
need
the
profiler.
Yet
you
know,
but
maybe
in
the
future
we
can
totally
drop
the
profile,
but.
C
C
You
know,
and
that
could
be
very
easy
to
configuration
because
then,
basically,
you
could
have
something
like
install
this
with
the
collector
and
you
can
tell
the
collector,
hey
instrumental.net
applications
or
dotnet
applications
that
satisfy
some
criteria
and
their
way
to
instrument
is
basically
kind
of
okay
at
startup
inject
the
collector
and
they
collection.
I
mean
the
the
profiler.
C
Just
just
some
crazy
idea
for
the
future.
D
D
Probably
gets
more
complicated
or
streamlined
with
the
whole.
What
is
it
the
the
management
protocol
being
discussed
in
a
different
work
group.
C
Yes,
yes,
children
has
been
involved
on
that
and
that
could
be
you
know,
kind
of
you.
Could
you
have
a
control
panel
to
send
the
things
that
you
want
on
your
instrumentation
to
do,
and
then,
with
that
control
panel,
things
really
get
interesting
and
it's
one
path
could
be.
Also,
if
you
don't
really
don't
want
the
profiler,
you
could
just
use
this
fastback
hook,
but
they
start
up
hook
needs
to
be
global
to
the
machine.
In
that
case,
you
know.
D
At
the
same
time,
with
net
with
the
vent
pipe
and
all
of
these
telemetry
signals
funneling
through
there,
you
might
not
even
need
yeah
an
in-process
thing.
Yeah.