►
From YouTube: 2021-08-11 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).
A
Hello,
everyone
just
give
me
a
few
minutes
for
more
folks
to
join.
A
A
B
A
Yeah,
usually
we
give
some
extra
minutes
for
the
folks
to
join,
so
we
keep
just
waiting
a
little
bit
more
for
some
other
folks.
I
just
saw
that
greg
is
not
joining.
A
Okay,
so
I
think
we
still
have.
A
Some
evaluation
should
do
on
the
plc
regarding
iis
is
the
main
gap
that
we
still
have
there.
I
did
some
of
the
stuff
that
I
mentioned
last
week
regarding
applications
that
were,
let's
say,
a
red
built
without
access
to
build
time.
We
have
workarounds
that
we
talked
about
either
changing
the
depth.json
file
for
the
case
of
net
core
or
the
framework
using
binding
redirects,
but
I
would
like
kind
of
I
think,
raj
that
he
reached
or
slack
to
some
information
about
this.
A
So
I'd
like
to
do
a
quick
recap
and
I
think
it's
good
for
everyone
also
to
be
so.
We
are
on
the
same
page
in
regard
to
what
you
are
doing
with
the
plc.
So
on
the
plc
branch,
the
idea
is
to
use
the
hotel
sdk,
the
main
difference
being
that
we
can
consume
the
achieved,
generate
the
activity,
sort
and
the
legacy
and
also
avoid
a
lot
of
code
duplication
if
we
are
implementing
the
tracer
on
the
auto
instrumentation
branch.
A
So,
basically
we
are
leveraging
the
data
dog
code
and
what
we
are
doing
is
we
are
injecting
the
hotel
sdk,
and
for
that
we
also
cover
two
scenarios.
One
scenario
is
that
the
application
already
has
the
hotel
sdk.
They
are
really
just
interest
in
the
auto
instrumentation.
A
So
for
that
case
we
have
an
environment
variable
that
prevents
the
profiler
of
injecting
the
sdk.
We
delegate
that
responsibility
to
the
application,
and
but
the
default
case
we
take
care
of
injecting
the
sdk.
A
A
The
opentelemetry.net
we
can
inject
those
via
calls
in
managed
code.
We
write
that
part
in
managed
code
as
part
of
our
loading
process.
We
check
the
configuration
and
check
what's
going
to
be
loaded
and
also
we
have
a
set
of
byte
code
instrumentations
that
we
can
also
inject
in
the
application.
This
has
the
version
problems
that
we
imagined
kind
of
by
loading,
different
versions
of
the
same
library
being
at
the
hotel
or
a
client
library
that
is
being
used
and
the
way
that
we
are
finally
to
work
around.
A
This
problem
at
build
time,
basically
revolve
around
setting
new
get
package
reference
to
the
versions
required
to
buy
the
sdk
or
by
the
specific
instrumentation
that
you
want
to
use.
That
is
not
as
user
friendly
as
upstream
have
because,
upstream
you
just
tell
instruments
and
it
gets
instrumented
with
what's
capable
and
then
you
can
refine
if
you
want
to
exclude
some
instrumentation.
A
But
let's
say
that's
a
is
experience
that
out
of
the
box
is
much
more
straightforward,
so
the
big
tradeoff
in
being
able
to
reuse
all
the
code
from
the
sdk.
A
Because
of
this
version
conflict
we
have
to
to
kind
of
be
a
little
bit
less
user
friendly
in
the
sense
that,
for
instance,
even
for
a
source
instrumentation,
we
could
do
trial
and
error.
But,
for
instance,
right
now
in
in
the
sdk,
we
are
asking
the
user
to
specify
the
list
of
instrumentations
that
they
want
to
add.
That's
because
if
we
try
to
add
dependence,
source
instrumentation
that
has
a
dependence
that
the
application
doesn't
bring.
It's
gonna
fail.
A
As
I
said,
we
can
do
some
handling
of
that
automatically
to
try
to
load
those
source
instrumentations
automatically.
But
we
are
not
doing
at
this
point
in
the
plc
and
also
this
gets
back
to
other
point.
We
also
have
the
capability
of
adding
this
source
instrumentation,
not
only
source
instrumentation
by
culture,
but
any
instrumentation
in
a
distribution
of
the
open
telemetry.
A
We
can
add
the
instrumentation
nougat
packages
and
those
get
loaded
at
runtime
by
the
code
that
we
have
on
the
plc.
So
we
have
the
capability
of
customizing
distributions.
A
If
that
is
a
scenario
that
anybody
is
interested,
the
the
main
thing
I
I
think
the
the
the
point
that
I
I
really
make,
I
think,
is
that,
as
I
said,
using
the
sdk
saves
us
from
rewriting
a
lot
of
code
but
makes
the
instrumentation
a
bit
harder
to
use.
You
know
a
little
a
little
bit
less
user-friendly.
A
Most
of
the
work
right
now
we
haven't
been
doing
is
actually
happening
on
the
sdk,
because
we
need
to
support.
We
need
the
full
set
of
environment
variables
to
be
supported
by
the
sdk
and
doesn't
make
sense,
as
kind
of
we
could
do
some
of
that
stuff
here.
But
what
makes
sense
is
is
to
implement
that
on
the
sdk
then
pick
up
updated
version
of
the
sdk
and
use
it
rely
on
the
sdk
implementation
of
environment
variable
support
to
configure
things
like
exporters
propagators.
A
They
spend
batching
all
those
things
that
are
already
done
by
the
sdk,
but
they
didn't
expose
it
as
environment
variables
for
us
to
interact
with.
That
makes
much
more
sense
to
be
environment
variables
because
of
the
way
that
the
instrumentation
is
deployed,
the
is
deployed
via
a
clr
profiler,
so
the
most
of
the
work
that's
been
happening
right
now
is
in
that
side
of
the
sdk.
A
I
think
that
a
desirable
target
for
us
is
by
the
time
of
dot
net
six,
that
we
release
alpha
with
a
few
instrumentations,
and
that
is
kind
of
it's
relatively
close,
it's
november,
but
it
seems
doable
to
me
for
us
to
release
alpha
by
the
time
that
dot
net
six
is
releasing
with
a
small
set
of
instrumentations,
not
all
the
experimentation.
A
That
upstream
is
implements,
but
just
a
small
set
for
us
to
prove
the
concept
and
find
any
other
issues
that
perhaps
you
are
missing
in
our
internal
evaluation
of
the
plc.
A
So
I
think
that's
a
summary
of
the
status
and
the
path
that
we
are
taking
are
really
discussions
that
we
have
been
in
the
last
month
or
two.
A
I
I
think
everyone
agrees
that
the
sdk
is
the
path
for
the
open,
telemetry
instrumentation,
so
we
kind
of
making
these
tradeoffs
that
I
mentioned,
and
I
think
that's
the
path
that
we're
going
for.
B
So
currently,
if
you
look
at
it,
like
microsoft,
has
a
similar
implementation
internally
for
application
inside.
So
what
we
do
is
like
for
our
auto
instrumentation,
we
don't
have
a
separate
code.
We
just
take
the
our
auto
instrumentation,
like
instrumentation
code,
is
based
on
bringing
the
application
inside
sdk
into
the
process.
That's
how
we
have
it
done.
So
there
are
a
lot
of
challenges
like
you
said
like,
for
example,
what
happens
if
customer
brings
the
sdk
with
him?
Auto
instrument
rotation
also
will
bring
an
sdk.
So
what
are
we
going
to?
B
In
that
way,
like
instrumentation
will
bring
a
single
library
and
it
will
not
have
a
mismatch
with
mismatch
with
while
loading
it
through
the
process
and
once
we
load
it
instrumentation,
what
it
will
do
is
it
will
do
the
telemetry
collection
only
from
the
sdk
that
is
brought
by
auto
instrument
instrumentation
and
it
will
disable
the
telemetries
from
the
sdk.
That
is
that
customer
brings
in
in
that
way,
we
ensure
that
telemetries
are
collected
only
once
and
also
we
are
not
impacting
the
customer's
performance.
B
This
is
from
the
like
the,
for
example,
the
open
telemetry
api
itself,
duplicated
like
if
customer
brings
it
how
we
can
handle
that
scenario,
and
we
have
another
scenario,
which
is
a
big
worry
like
debug,
the
diagnostic
source
library
customer
might
have
a
lower
version
or
a
higher
version.
B
So
this
is
something
I'm
currently
working
with
the
dot
net
team
to
handle
like
how
to
handle
this
scenario.
So,
but
currently
what
we
are
doing
is
we
are
using
the
least
version
of
the
diagnostic
source,
so
the
net
core
cannot
upgrade
whatever
the
customer
brings.
In
so
the
least
supported
version
is
dotnet.
B
So
that's
what
we
bring
with
the
instrumentation
and
the
the
currently
whatever
we
have
in
as
application
insights
sdk,
but
we
don't
have
that
liberty
with
open
telemetry,
open
telemetry
is
on
the
latest
diagnostic
source
and
it
gets
the
activity
and
everything
based
on
that.
B
So
so
you,
I
thought
if
it's
a
common
issue
that
open
I'm
trying
to
solve
this,
to
have
the
open,
telemetry
sdk
as
a
part
of
the
microsoft
implementation.
Also.
But
I
see
this
is
a
common
problem,
I'm
working
with
dot
net
team.
If
the
community
is
also
facing,
we
can
work
together
with
the
dotnet
team
to
sort
out
that
challenge
for
us
and
again
like
these
are
the
things
I
spoke
from
a
library's
per
perspective
and
again,
how
do
we
bring
an
auto
instrumentation
library
to
a
dot
net
core
project?
B
So
there
are
two
different
concepts
we
tried.
There
is
one
thing
called
this
runtime
store
and
additional
tapes,
so
we
can
just
say
that
these
are
the
additional
dips.json
and
the
runtime
store.
I'm
going
to
give
it
to
you.
Based
on
that.
B
The
second
one
is
dotnet
recently
introduced
dotnet
startup
hook
concept,
which
is
starting.net
core
3.1,
which
is
very
simple.
We
don't
need
so
many
complex
things.
All
we
can
do
is
like
have
a
startup
hook,
library,
written
and
say
that
hey.
These
are
the
things
I
want
to
load,
which
is
super
simple
in
the
other
approach.
So
we
are
moving
to
the
startup
hook
in
the
current
one,
what
we
are
working
so
that
is
going
to
work
for
both
dot
net
core
and
the
dot
net
versions.
B
That's
going
to
come
like
going
forward
and
if
there
is
any
new
version
that
dot
net
release,
we
don't
need
to
change
our
auto
instrumentation
code.
It
should
continue
to
work
with
that
approach.
So
the
problem.
What
we
are
going
to
have
is
I'm
seeing
that
on
the
screen
like
you're,
putting
it
as
framework
for
a
dot
net
framework
application.
So
that
is
where
the
problem
comes
in
dot,
net
framework
application.
How
we
are
injecting
is
like
right
now
we
have
an
http
module
and
we
have
only
azure
based
attach.
B
So
what
we
do
does
it
like,
whenever
the
like,
we
browse
to
and
dotnet
framework
based
application,
the
http
module
will
load
and
which
will
load
the
instrumentation,
our
instrumentation
library,
cooler
tools
and
like
attached
to
the
application
and
same
data,
and
currently,
if
customer
has
sdk
already
a
part
of
that
application.
We
don't
instrument
instrumentation
just
backs
off
in
case
of.net
framework,
so
that's
the
same
problem
that
the
diagnostic
sources
use
difficult
to
like
sort
out
in
the
old
classic.net
framework.
So
we
have
left
out
in
that
way.
B
A
So
so
one
question
do:
do
you
have
that?
Does
the
dot
net
team
has
been
pursuing
these
in
some
of
their
open
source
implementation?
I
mean
kind
of.
Are
we
having
some
discussion
or
some
work
group
with
this?
That
is
this
public
that
we
could
perhaps
join
and
participate
and
kind
of
try
these
things.
B
So
the
only
way
is
to
reach
them
out
through
the
like
dot
net
runtime
like
issues.
B
A
Yes,
yes,
sounds
good,
sounds
good.
I
think
I
think
we
should
kind
of
establish
perhaps
or
we
can
start
using
this
sig
meeting,
but
if
we
have
some
specific
work
on
the
dot
net
run
time
tracking
that,
then
I
think
there
there
are
more
chance.
A
Well,
one
thing
that
crossed
my
mind
is
that
I
think,
at
least
from
my
perspective
and
the
rest
of
the
folks
here
can
manifest
what
they
think
about
that,
but
even
if
we
just
have
a
kind
of
really
really
good
solution
for
future
versions,
I
think
it's
a
path
going
forward.
A
You
know,
I
think
we
are
making
these
trade-offs
right
now
that
we
kind
of
have
workarounds,
but
their
workarounds
are
very,
I
would
say,
intuitive
and
if
perhaps
we
can't
kind
of
be
a
bit
of
kind
of
really
follow
the
microsoft
releases,
I
think,
for
open
telemetry
to
really
take
a
path
forward,
that's
kind
of
more
productive
for
our
sig.
A
We
could
even
declare
something
kind
of
okay.
We
have
this
version,
but
we
don't
support
this
older
stuff
and
because
the
reality
is
that
the
the
vendors
that
participate
here
in
this
space,
they
have
solutions
for
the
older
stuff
and
we
can
tell
the
users
in
some
cases,
kind
of
okay.
If
you
want
to
open
telemetry
and
we
are
moving
also
to
the
open
telemetry,
you
have
the
this.
A
That
is
the
future,
but
if
you
need
to
support
something
old,
then
most
of
the
vendors
have
something
that
they
can
provide
and
works
with
the
older
version.
So
the
main
point
that
I
want
to
make
is
kind
of
a
really
good
solution
for
the
future
is
really
valuable.
Even
if
we
can't
support
the
legacy.
A
It's
it's
a
trade-off
of
course,
but
I
think
it's
a
trade-off,
at
least
from
my
perspective
that
we
should
be
willing
to
take.
You
know
so.
C
Paulo,
I
think
that
one
of
these
trade-offs
could
be
the
solution
which
which
are
rey
or
reggie
register.
I
don't
know
how
to
raj
likes
mentioned-
is
to
use
this
whole
startup
hooks,
because
it
is
it's
a
lot
of
simpler
than
creating.
You
know
this
early
right,
but
then
we'll
get
rid
of
this
bite.
It
will
get
rid
of
this
bytecode
instrumentation,
which
I
don't
know
if
it's
acceptable
or
not,.
A
C
C
A
So
I
think
in
if
we
look
to
diagnose
source
activity,
source
and
activity
going
forward.
I
think,
since
it's
part
of
their
own
time,
that's
really
going
to
become
the
standard,
but
I
think
it's
going
to
take
time
for
this
to
persuade
to
the
ecosystem
right.
So
when
that
happens,
then
the
use
for
il
instrumentation
reduces
a
lot,
because
you
have
all
these
hooks,
at
least
from
the
point
of
view
of
monitoring.
A
You
still
want
to
do
il
for
some
other
special
stuff,
but
for
monitoring
it
kind
of
the
needs
reduce,
but
I
think
it's
going
to
take
time.
You
know
so.
A
So
before
it's
adopted,
yep
yeah-
I
I
know
that
will
be
very.
It
will
make
our
case
much
easier
if.
A
B
So
I
have
a
question
here
like
as
we
are
speaking
about
ielts
right.
So
I
know
java
has
a
like
a
proven
bytecode
instrumentation,
so
they
use
some
like
other
third
party,
which
is
a
proven
component
there.
That's
why
they
could
do
it
very
faster,
their
auto
instrumentation,
so
dotnet
does
not
have
something
like
that
like
I'll
rewrite.
So
are
we
planning
to
write
that
as
a
part
of
this
like
process
in
the
this
poc
like.
A
So,
actually,
the
code
that
we
forked
already
has
the
capability
of
doing
the
irv
right,
and
the
thing
is
that
we
are
planning
for.
We
are
adding
some
of
these
il
rewrite
instrumentations
that
are
added
via
io
rewrite,
so
we
are
going
to
start
to
create
activities
from
code
that
we
use
the
ir
right
to
do
that.
You
know,
I
think
the
main
difference
for
java
is
that
these
are.
A
Let's
say
you
just
need
to
know
how
to
write
normal
java.
They
have
the
proper
hooks
for
you
to
write
java
code
and
the
the
thing
just
works
here.
We
need
kind
of
expertise
in
dotnet
that
actually
is
not
the
typical
expertise
in
dot
net,
an
old
c
plus
class.
A
So
we
need
to
do
the
I
already
write.
We
need
to
have
the
clr
profiler
and
the
code,
even
that
we
write
in
in
c-sharp
needs
to
be
special
to
be
able
to
handle
to
be
injected
that
way
without
the
types
at
build
time,
and
this
kind
of
thing
there
is,
there
is
some
very
cool
stuff
on
the
ripple
that
you
can
look
like
duck
typing
that
implementation
that
avoids
a
bunch
of
reflection
to
get
feuds
and
properties.
A
So
if
I
was
going
to
say
for,
for
instance,
for
the
dot
net
run
time,
one
thing
that
you
make
all
these
things
so
much
easier
would
be
if
we
had
a
way
to
write.
If
a
normal,
typical
c-sharp
developer
could
sit
down,
write
c
sharp
code
and
the
runtime
environment
takes
care
of
wrapping
and
doing
everything.
Basically.
A
Makes
sense
right,
yep
yeah,
so
so
we
do
have
higher
writing
and
we
think
that
is
the
the
key
for
this
project
is
the
capability
right
now.
You
know,
as
I
said,
if
the
plan
goes
as
as
as
dotnet
runtime
wants,
people
are
really
using
activity
source
and
active
that
follows
open
telemetry.
I
would
say
that
in
five
seven
years
all
the
stuff
is
going
to
be
using
that,
but
we
have
this
gap
in
between
that
we
wanted
to
do
via
il
rewrite
to
inject
the
experimentation.
A
D
C
Quickly
just
know
just
mention
one
thing:
how
the
java
auto
instrumentation
handles
this
dependency
conflicts
for
this,
our
like
for
our
what
for
for
us,
it
is
diagnostic
source
for
them.
It
is
simply
reference
to
the
open,
telemetry,
api
or
sdk,
then
simply
instrument
they've
wrapped.
They
have
like
a
wrapper
or
an
adapter
for
hold
the
code
for
the
for
the
sdk
and
they
simply
instrument
all
the
code
that
goes
to
the
sdk
and
then
just
by
just
make
a
breach.
C
So
if
someone
is
calling,
you
know,
version
five,
six
or
whatever
in
rarity,
everything's
go
by
their
own.
Their
code,
which
is
like
vendor.
A
So
I
I'm
not
that
familiar
with
the
they
did
the
implementation.
So,
let's
suppose,
if
somebody
has
library,
that's
instrumented
with
open
telemetry
version
one
and
they
are
using
the
instrumentation
java
version
two
that
has
a
different
indicator.
How
that
bridge
works?
Can
you.
B
C
C
C
C
Only
problem
was
before
the
one
oh
release,
but
right
now
everything
which
is
using
you
know,
java,
auto
instrumentation,
instrumentation,
post
1.0
is
stable,
I'd,
say.
A
So
but
but
on
the
other
hand,
the
dotnet
is
pretty
good
at
not
things
going
forward.
So
if
the
application
is
using
diagnosis.
A
Yeah,
I
I
think
one
other
thing
that
makes
a
bit
harder
for
net
is
actually
that's
part
of
the
runtime,
so
it's
very
good,
that's
part
of
their
own
time.
Don't
get
me
wrong,
but
that
makes
our
challenge
a
bit
different.
B
A
Yeah
yeah,
so
I
I
think
the
the
next
step
here
for
us
will
be,
or
I
my
preference
will
be-
to
try
to
use
this
sig
meeting
to
have
this
discussion,
but
make
perhaps
make
these
conversations
that
you
are
have
with
the
dot
net
one
time
and
or
perhaps
it
started
this
far.
I
know
that
eventually
it
becomes
kind
of
a
spec
thing
for
dotnet
at
one
time,
but
at
least
in
the
beginning.
A
Perhaps
we
can
keep
the
conversations
here
and
then
we
we
jump
or
any
dotnet
runtime
spec
discussion
and
things
there
to
to
fix,
but
to
fix
to
discuss
the
the
implementations
and
tests
and
using
because
in
in
that
case
we
are
kind
of
a
consumer
of
these
apis
and
very
interested
on
those.
A
So,
as
I
said,
I
think,
starting
to
have
this
conversation
with
us
kind
of
I
don't
know
do.
Do
we
already
have
something
that
we
can
read
about
this
startup
hook.
A
Okay
cool,
so
I
I
think
yeah
we.
We
should
start
reading
that
and
perhaps
we
get
back
to
you
and
zlac
asking
questions
and
when
we
have
a
place
to
follow
up.
Perhaps
we
start
here
on
the
sea,
as
I
said,
but
then
we
spend
to
the
doctor
at
runtime.
A
So
actually,
this
is
a
very
welcome,
I
would
say
developing
for
us,
because
we
are
not
aware
of
this
work
and
makes
kind
of
makes
feel
that
we
we
have
support
from
the
broader
community
to
do
something
that
really
works
in
this
case.