►
From YouTube: 2022-05-04 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
A
B
So,
as
usual,
starting
with
the
open
pull
requests,
I
do
have
a
question
about
this
one
raj,
because
this
is
something
that
I
was
thinking
also
to
look
forward
to
add.
Since
now
it's
complete
on
the
sdk
side.
How
far
are
we
kind
of
to
be
able
to
kind
of
export?
Let's
say
runtime,
mattress
and
metrics
for
the
application?
To
be
fair,
I
didn't
look
at
the
rpr,
so
I'm
starting
just
asking
the
the
the
high
level
question.
E
Sorry,
paulo,
I
missed
the
question.
Could
you
please
ask
that
again
actually.
F
Yeah,
because
this
is
something
that,
since
the
metric
is
completed,
the
sdk
will
work
for.
B
I
I
would
like
to
understand
kind
of
how
far
or
close
we
are
kind
of
perhaps
of
adding
these
to
the
auto
instrumentation,
because
this
is
also
something
that
could
be
attractive
to
people
to
try
our
beta.
If
we
can
kind
of
just
light
up
the
metrics
experience,
you
know
with
the
auto
instrumentation.
E
I
I
would
say
in
like
to
three
weeks
is
the
time
where
we
could
add
it.
I
created
this
pr
for
us
to
discuss
here
and
understand
what
are
the
issues
that
we
need
to
create
and
because
I
thought
earlier
I'll
do
and
propose
something
and
later
I
realized
it's
better.
We
do
it
together,
taking
a
look
into
it.
E
There
are
a
few
things
needed
here.
One
is
our
configuration,
so
we
have
a
once
the
settings
just
like
copy
pasted
everything
our
we
need
some
refactor
to
our
configuration
and
we
need
to
rename
like
few
environment
variables.
That's
the
second
part
and
we
have
a
few
classes
environment
reader
class
for
traces.
We
need
a
similar
one
for
the
metrics.
So
whatever
the
changes
I
have
is
a
complete
working
example.
It
does
not
include
the
tests,
but
I
tested
it
with
an
app
even
bringing
the
the
open,
telemetry
runtime
package.
E
I
added
to
that
and
I
validated
the
metrics
as
a
part
of
it,
so
it
worked
with
both
the
custom
metric
created
and
the
metric
created
by
the
runtime,
which
is
from
the
like,
contrib
repo.
So
only
minimal
changes
are
needed.
Maybe,
and
the
challenges
which
we
go
through
are
the
same
as
of
traces
here,
because
it's
using
the
same
system,
dot
diagnostic
source
dll.
So
with
a
very
minimal,
very
minimal
effort.
I
think
in
three
weeks
we
will
be
able
to
get
things
higher
up
based
on
this
pr.
E
B
B
This
is
a
kind
of
signed
question,
but
because
you
mentioned
that
it
reminds
me
that
we
had
to
do
kind
of
a
bit
of
work
to
get
the
exporters
and
the
processors
to
support
the
environment
variables.
So
perhaps
we
should
work
with
the
sdk,
so
in
the
future
kind
of
instrumentations
processors.
Any
of
these
components-
exporters
already
have
the
environment
variables
in
the
state
that
we
can
just
leverage
that
stuff.
You
know
okay,
but
but
this
will
be
future
work
you
know
kind
of,
but
yeah.
B
I
think
it's
the
second
time
that
we
have
this
kind
of
example.
That
kind
of
motivates
me
to
think
about
that.
You
know,
so
I
think
we
as
a
sid
should
perhaps
look
into
that.
E
Now,
if
you
could
open
that
pierre
paulo,
I
just
want
to
show
you
something
like
it
would.
The
changes
will
be
very
simple.
I
wanted
you
to
take
a
look
at
the
environment.
Variable
section
in
the
files
let's
go
to
the
file
is
changed.
Yeah.
E
Yeah
these
ones
are
like
the
one
we
already
have
something
like
line
number
63.
If
you
look
at
it,
we
have
votel.net
meter-enabled
instruments
already
we
have
one
for
tracer,
but
in
that
space
we
will
have
a
tray.
We
don't
have
a
trace
keyword.
It
is
like
auto
underscore
enabled
instruments,
but
the
enabled
instruments
for
metric
and
prices
is
going
to
different.
E
So
we
might
need
to
do
work
on
those
three
names
so
that
it
will
be
easier
for
a
customer
and
also
I
I
feel,
even
though,
if
I
personally,
if
I
need
to
come
to
this
project
and
I'm
on
board,
I
have
a
lot
of
challenges
if
that
reflect
that
got
reflected
in
the
new
issues
that
god
created
also
a
customer
coming
to
us
and
understanding
these
many
environment
variables.
This
should
be
useful.
We
need
to
have
a
very
simple,
simple
approach.
I
don't
have
a
like
proposal
or
a
resolution
for
that.
E
We
need
to
think
about.
All
of
us
should
brainstorm
at
some
point
in
time,
too,
think
how
we
can
make
it
easier
for
our
customers
to
onboard
it,
for
example,
if
they
want
a
basic
template
of
like
http
and
asp.net
with
mongodb,
we
should
have
something
ready
made
for
them
to
pull
it
and
use
it.
So
we
should
also
think
about
it
without
that
it's
going
to
get
very,
very
difficult
for
them
to
use
things
from
our
repo,
because
there
are
many
documentation
available
in
our
reform.
E
They
need
to
go
through
every
one
of
them,
but
that
does
not
stop
any
of
the
things
that
we
are
doing
here
but
holistically
like
we
should
continue
what
we
are
doing
and
have
an
approach
to
do
the
other
things
a
little
later
for
us.
B
Yeah
no,
but
I
I
I
think
this
is
a
very
good
point,
because
I
I
think
the
challenge
right
now
is
really
the
configuration
is
not
trivial
and-
and
we
should
have
some
default-
that
basically
with
minimal
configuration,
this
stuff
just
works,
then
okay,
somebody
needs
to
tweak.
But
how
is
the
the
80
20
right?
We
are
trying
to
achieve
like
out
of
the
box
works
for
80
of
the
cases
you
know
so
yeah.
B
No,
that
that's
a
very
good
point
about
simplify
the
the
the
configuration
so
and
also
I
was
thinking
about
kind
of
the
things
that
perhaps
we
need
on
the
sdk
or
the
the
components
that
come
that
use
the
api
or
sdk.
But
there
is
also
our
side
about
our
environment
variant
right.
So.
B
Okay,
the
other
ones
below
that
are
all,
but
we
should
start
to
address
those
the
this
bunch
of
bumps.
We
perhaps
we
should
look
at
the
these
bumps
and
see
for
tests
whatever
we
kind
of
want
to
keep
old
versions
for
tests,
we
should
just
resolve
and
tell
dependable
to
just
ping
us
after
another
major
upgrade.
You
know,
I
think
we
we
can
start
to
pick
up
on
those,
so
ensure
that
we
do
some
cleanup
on
this.
B
Okay,
so
this
is
just
robert's,
creating
a
pr
to
document
some
other
environment
variables.
Okay,
this
is
simple
enough,
so
you
can
take
a
look
at
the
pr
and
proceed
from
there.
H
D
Yeah,
so
it
sounds
like
some
progress
was
made
there
and
now
they're
running
into
what
I
believe
to
be
some
of
the
new
relic
specific
settings
and
getting
that
to
work
which
spawn
off
the
the
other
pr
that
robert
submitted
regarding
documenting
some
of
the
other
environment
variables
specific.
So
in
this
case
the
header
environment
variables
are
important,
the
otlp
header
ones,
but
then
he's
also
documenting
the
the
otlp
timeout
ones
as
well.
B
I
see
I
see
so
yeah,
so
at
minimum
they
they
got
past
that
first
barrier
that
was
kind
of
blocking.
B
Yeah
yeah
this.
This
also
reminds
me
that
right
now,
the
way
that
we
are
doing
is
very
kind
of
dependent
on
the
the
api,
because
usually
we
call
some
extension
method
that
is
like
add
package,
xyz
instrumentation.
B
You
know
we
need
some
common
way
kind
of
a
common
name
or
attribute
on
some
method
that
we
can
kind
of
hey.
I
have
this
source
instrumentations.
I
just
want
to
load
it.
You
know
the
ones
that
can
be
load
just
with
without
any.
B
We
need
some
common
point.
Otherwise
you
are
going
to
be
writing
a
small
piece
of
code
for
each
one
of
them
right
right
now
we
it's
the
way
it
is.
This
is
something
that
we
also
should
get
back
to
with
the
folks
from
the
sdk
and
kind
of,
as
I
said,
could
be
something
as
an
attribute
could
be
a
api
would
not
design
anything
here,
but
we
should
have
some
common
that
allows
us
to
add
source
instrumentation
easy.
B
D
Yeah,
there
might
still
be
some
gotchas
there
because
of
other
dependencies
that
each
of
those
have.
B
D
B
But
at
least
then
we
we
know
kind
of
okay.
We
are
trying
to
load
automatically.
We
should
get
this
kind
of
file,
not
found
assembly
couldn't
load
assembly.
We
know
what
those
means
the
the
cost
is
that
we're
making
everything
start
slower.
D
Right
so
correct
with
that
being
said,
I
feel
like
there
were
still
some
edge
cases
where
I've
seen
where
so
you
attempt
to
load
these
things.
You
get
an
error,
but
I
don't
think
you
have
the
ability
to
to
really
unload
them,
and
so,
if
they're,
using
some
sort
of
reflection
tool
to
scan
loaded
assemblies,
you
can
start
getting
errors.
B
B
I
B
Yeah
we
we
we
can
follow
up
and
and
and
go
through
through
the
instrument
just
because
and
create
a
design
for
that
you
know
otherwise.
Otherwise
I
mean
we
don't
we
don't
need
to
dig
a
grip
right
now.
We
just
want
to
go
over
the
the
issues.
B
I
I
read
last
week
after
we
finished,
I
read
raj's
issue
about
the
assembly
resolution.
For
me
at
first
it
sounds
good.
It
sounds
workable.
I
I'm
planning
to
kind
of
try
to
do
some
tests
with
it.
B
These
are
next
week
before
the
the
next
meeting,
but
I
think
everyone
that
has
some
cycles
should
take
a
look
there.
B
B
Also
trying
to
minimize
our
carbon
footprint-
and
I
think,
a
lot
of
the
ripples
in
open
telemetry
are
kind
of
doing
stuff
for
avoiding
building,
in
case
of
in
case
of
just
change
that
don't
affect
cold.
So
we
should
do
the
same.
D
B
Yes,
that's
true
just
going
over
very
quickly
here
from
these
ones
that
we
already
looked
at,
perhaps
with
the
exception
of
this
one,
I
think
all
the
other
ones
don't
need
to
be
on
the
next
beta
right.
B
So
what
do
what
do
you
guys
think
about
source
instrumentation
versions?
Should
we
add
these
to
the
next
beta
document
that
or
keep
on
that
for
afterwards.
I
So
you
mean
the
versions
of
what
we
instrument
or
the
packages
that
we
are
using.
B
It's
the
four
is
the
versions
of
the
things
that
we
are
using.
You
know,
because.
B
B
I
think
that
we
can,
I
think
we
can
skip
that,
because
if
you
document
the
top
level
one
can
go
through
nougat.org
and
get
that
information
there.
You
know,
so
we
just
need
to
document
the
top
level
package
that
we
are
using
and
any
user
can
go
and
check
whatever
dependency.
That's
bringing
it's
just
it's
just
more.
I
think
we
want
to
start
to
do
that
eventually,
because
then
becomes
part
of
the
process.
When
you
upgrade
the
package,
I
didn't.
Could
I'm.
B
D
D
B
Yeah,
I
I
I
think
I
think
we
if
we
should
take
on
the
chip.
I
think
if
we
point
to
the
new
get
package
that
we
are
using,
I
think
users
that
care
about
this
kind
of
information
can
go
on
new,
get
organ
and
figure
out
the
versions
that
are
supported,
because
it's
gonna
show
the
package
right.
There
is
a
bit
of
assumption
here.
Perhaps
the
package
doesn't
reference,
whatever
it's
instrumenting.
B
I
C
I
D
I
B
B
This
link
is
the
same.
They.
B
D
C
B
Think
this
one
here
is
kind
of
indirectly
right,
because
this
is
a
type
in
the
runtime
library.
B
B
So
bus1
is
basically
yeah,
so
any
framework
that's
compatible
to
not
standard
2.0
so
and
above
net
462
yeah,
it's
kind
of
a
bit
hard
to
parse.
You
know.
C
And
it
is
a
strange
scenario
because
we
do
not
have
an
external
library.
In
fact,
everything
what
we
instrument
in
this
packet
is
in
dotnet
itself.
The
question
is
how
we
should
define
it
for
mongodb.
So
maybe
this
is
fine
for
everything
what
we
have
directly
in
dotnet.
What
is
supported?
We
can
instrument
it
if
we
have
an
external
dependencies,
we
should
describe
everything
with
details
which
exactly
which
versions
are
supported.
B
Yeah
yeah,
I
think
I
think
we
can
perhaps
delegate
for
that
for
the
time
being,
because
we,
instead
of
us
digging
that
information
you
know,
I
think
it's
not
ideal,
because
the
rhythm
may
be
maybe
not
good
and
maybe
doesn't
have
the
information,
but
at
least
we
are
leaking
there
and
then
we
can
perhaps
go
there
and
contribute
later
some
way
to
specify
the
versions
or
make
that
clear.
You
know.
B
J
Yeah
for
the
networks,
I
think
that's
fine,
I
think
like
longer
term,
we
could
even
do
something
like
a
github
action
to
just
scan
the
that
project
file
and
then
try
to
see
what
dependencies
there
are.
As
like
a
you
know,
long-term
and
hopefully
more
automated
way
of
doing
that.
J
J
Yeah,
we
kind
of
hard.
We
define
what
versions
we
want
to
instrument
since
we're
gonna,
be
inspecting
il.
B
B
This
is
a
nice
to
have
avoiding.
It
should
be
ci,
not
pi,
but
we
should
this.
We
can
leave
after
after
1.1.
I
C
Open
telemetry
sdk
created
kind
of
a
replacement
for
such
scenarios.
I
do
not
dig
exactly
in
the
github
actions,
but
but
they
have
kind
of
windows,
ci
dash
md
steps,
and
it
replaces
the
steps
for
regular
builds.
B
B
B
This
is
just
a
follow-up
to
the
pr,
because
I
had
the
impression
that
we
are
adding
exceptions
for
for
a
specific
case
that
I
think
perhaps
are
rewarding
it's
it's
worth
it
so.
B
C
I
Yeah,
that's!
What's
exactly
what.
H
D
Yeah,
paulo
just
to
catch
you
up
quickly.
The
markdown
rule
that
that
was
added
was
deemed
very
specific
and
doesn't
seem
to
seem
like
it
would
lead
to
bigger
problems
for
us
and
so.
C
D
Ever
have
documentation
and
markdown.
Where
we
have
duplicate
subheaders,
then
we
could
potentially
revisit
this
decision,
but
having
duplicate
subheaders
like
that
might
be
a
separate
smell
in
our
documentation.
B
Yeah,
I
I
I
I
as
long
as
the
the
sig
is
fine
with
that.
Let's
do
that
and
close
one
last
issue.
A
B
Okay,
so
this
behaves
the
way
that
we
expected
and
for
now
we
are
addressing
with
the
path
that
we
chose
right.
So
this
is
a
dotnet
core.
We
are
going
to
end
up
with
the
version
that
application
is
building
unless
we
build
against
some
nougat
package.
That
updates
the
version.
B
Okay,
so
should
we
close
for
now
and
just
say
that
situation
is
understood
or
do
you
wanna?
Do
you
guys
see
the
need
for
any
follow-up.
D
Need
yet,
I
suspect,
if
once
we
start
enabling
instrumentation
libraries
for
grpc,
we
might
have
to
revisit
these
ideas.
D
Yeah,
I
just
don't
know
what
will
happen
if
you
got
a
newer
version
on
the
managed
side
trying
to
load
the
older
version
of
the
native.
K
B
I
didn't
have
a
chance
to
look
at
this
one,
yet
don't
know
if
you
guys
had
a
chance
robert.
What
do
you
say
the
summary
for
us.
I
I
So
so,
basically,
the
user
would
got
this
exception
and
didn't
know
what
to
do,
and
that
was
one
problem,
and
second
problem
was
that
he
was
not
aware
of
using
this
that
he
needs
to
set
this
hotel.that
auto
enabled
instrumentations,
which
was
which
was
already
discussed
before.
So
these
were
the
two
problems
that
he
have
got
into
at
least
that
were
not
obvious.
H
B
I
B
I
Resource
instrumentations
for
source
instrumentation.
B
For
frost
instrumentation,
you
have
to
be
explicit
about
them
right,
yeah.
We
briefly
mentioned
that
we
need
to
make
this
easier
and
perhaps
have
some
way
to
try
to
load.
I
don't
know
if
you
got
that
part,
but.
I
B
I
That
part,
but
I'm
not
sure
if
it's
now
the
correct
moment
to
at
this
functionality,
probably
we
should
first
try
to
try
to
document
it
see
what
will
at
least
reduce
this
problem.
And
then,
if
more
people
complain
about
it,
then
we
maybe
will
enable
every
try
to
load
everything
and
just
handle
exceptions
when
there
is
not
loaded.
But
as
chris
mentioned,
there
could
be
some
loaded
stuff
which
are
not
unloaded
and
yeah.
It
can
bring
other
problems.
B
K
Yeah
the
delayed
one
doesn't
work
currently
sdk.
I
tried
to
build
something
but
or
actually
delaying
the
whole
sdk
building
that
will
work,
but
I
would.
C
B
So
you,
you
are
talking
about
kind
of
waiting
for
the
assembly
load
to
add
such
instrumentations.
K
B
B
You
know
not
sure
I
I
think
definitely
it's
a
good
idea
explore
that
with
the
profiler,
because
then
we
have
the
load
events
and
we
can
do
that
on
demand
and
actually
it
shouldn't
lose
any.
If
we
are
starting
with
the
application,
we
shouldn't
lose
any
event
or
anything,
because
it's
when
the
assembly
is
being.
I
A
K
Yeah,
the
sdk
needs
to
change
a
little
bit
because
you're
not
able
to
add
source
later,
but
I'm
not
sure
how
big
issue
is.
Is
it
for
the
sdk.
B
Yeah,
I
I
I
because
what
I
thought
was
was
kind
of
independent
of
the
sdk,
so
I
actually
would
like
to.
I
have
to
dig
into
the
issue-
I'm
let's
not
do
that
right
now,
but
because
my
what
I
thought
we
are
talking
about
was
okay.
We
have
the
assembly
load
event.
B
I
K
K
B
That's
a
question
here:
it
needs
to
happen
at
that
very
moment
in
the
beginning.
It
can't
happen
afterwards.
I
K
Yeah,
that's
the
current
limitation,
but
subscribing
to
additional
sources
shouldn't
be
hard.
So
the
question
is
what
the
sdk
is
doing.
Additionally,
if
they're
building
some
kind
of
proxies
or
processes
or
something
like
that,
this
might
be
a
problem
but
just
subscribing
to
diagnostic
source.
Isn't
the
big
deal.
B
Yeah,
but
if
the
sdk
requires
that
on
the
startup,
that's
not
an
issue
yeah
exactly
so.
The
question
is:
is
the
sdk
looking
into
having
instrumentations
added
after
the
initial
start?
That's
the.
B
Yeah,
let's
just
because.
B
I
think
this
is
a
a
very
good
thing
for
us
to
look,
I'm
just
questioning
if
we
should
try
to
get
this
to
1.1.
I
I
know.
I
K
I
I
So
what
I
can
suggest
is,
I
would
put
this,
enable
all
instrumentations
just
to
the
project
boards,
not
to
do
my
still
best
choice
to
the
project,
just
to
have
the
conversation
going,
so
you
can
just
go
to
the
right
side
and
add
it
to
the
project.
So
we
can
follow
up
with
the
sdk
team,
with
our
proposals,
etc.
So
it
doesn't.
B
D
So,
paulo
for
these
user
feedback
issues,
I've
just
been
trying
to
keep
them
open,
not
associating
them
to
a
project
or
to
a
milestone
at
this
point.
D
Just
so
that
there's
like
an
open
conversation
and
we
can
refer
to
them-
I
mean
it
does
mean
we
keep
seeing
them
every
week
in
this
list,
but
kind
of
you
using
that
the
conversation.
B
Yeah,
it
sounds
good
sounds
good.
Let
me
just
add
this
item
that
we
already
talked
about
so.
B
Okay,
so
wherever
you
were
jrpc
libraries,
these,
you
already
have
the
dpr
open
right.
We
already
added
the
milestone
project.
D
B
Yeah
yeah,
we
already
talked
about
that
one,
and
this
is
the
one
that
you
created
for
now
regarding
the
the
issue
that
we
just
discussed
it
right.
So,
let's
head
to
the
project
board
and
this
one
we
definitely
want
to
do
see
any
improvement
that
we
can
do
for
1.1
yep,
all
right.
I
The
document
headers
and
timeout
is
already
in
progress.
Okay,
so.
D
All
right,
one
thing
I
want
to
call
out
on
that
project
board.
Thank
you,
robert,
for
taking
a
a
look
at
the
feedback
for
the
blog
post,
but
I
just
want
to
encourage
others
to
take
a
look
at
the
doc
that
I
added
to
the
blog
post
issue,
provide
some
feedback
because
I'd
like
to
get
the
blog
post
out
sooner
rather
than
later.
B
One
okay
cool
so
folks
that
have
a
chance.
Please
take
a
look.
Let's
get
that
out,
so
I
I
think,
as
chris
mentioned,
it's
very
good.
You
have
the
second
feedback,
real
people
trying
at
least
you
know,
so
we
know
that
people
have
the
interest
and,
as
we
add,
more
instrumentations
things
are
going
to
get
interesting.
B
So
with
that
we
completed
our
chipko
rotation
here.
Do
you
guys
want
to
bring
anything
for
discussion.
K
D
No,
I
I
haven't
heard
anything
thing
else
and
then
the
there's
another
user
that
I
had
talked
to
before,
but
I
I
haven't
heard
anything
back
from
them:
either.
D
Oh
another
thing
to
call
out:
I've
mentioned
this
in
our
slack
channel,
but
there's
a
end
user
feedback
working
group
that
has
been
putting
together
surveys
and
I'd
link
to
an
issue
there,
where
they're
tracking
some
of
these
surveys,
and
so,
if
anybody
has
specific
information
you
wanna
see
collected
in
those
surveys,
feel
free
to
comment
within
that
issue.
D
And,
depending
on
the
timing
of
things,
might
add
it
to
our
blog
post,
but
also
eventually
added
to
our
readme
and
so
on.
Once
these
surveys
are
available.
B
Yeah
one
thing
that
iob
should
be
meeting
there
is
the
thing
that
raj
mentioned
is
that
sometimes
the
the
setup
is
not
only
ours
but
the
setup.
I
I
hear
complains
that
the
setup
is
not
sometimes
it's
not
trivial.
You
know
kind
of,
and
people
want
this
kind
of
things
to
be
as
trivial
as
possible,
so
just
anticipate.
I'm
gonna
put
that
in
the
survey.
B
I
I
do
have
a
question
I
put
on
this
lack.
I
remember
some
time
ago,
sometime
presented
event
pipe
stuff
and
there
was
a
after
the
meeting.
Somebody
put
a
link
to
a
prototype
of
something
listing
activities
via
the
event
pipe.
I
was
trying
to
find
that
and
I
couldn't
find
I
don't
remember
who
perhaps
created
that
sample.
I
don't.
I
think
it
was
some
microsoft
person,
I
think
perhaps
no
or
direct.
D
Yes,
I'm
fairly
certain
the
dotnet
monitor
tool,
reads:
activities
from
the
event
pipe.
B
D
B
D
B
D
B
See,
okay,
if
somebody
hears
about
their
funds
finds
that
please
let
me
know
I
I
I
want
you
to
find
that
sample
to
take
a
look
and
are
you
gonna
look
at
dot
net
monitor
to
catch
up,
and
perhaps
I
missed
something
there.
D
Oh
yeah,
otherwise,
if
you're
just
using.net
code,
it's
really
straightforward
to
subscribe
to
the
event
pipe.
You
just
gotta
know
which
event
source
to
subscribe
to
yeah.