►
From YouTube: 2021-05-26 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
B
C
Hey
this
was
the
first
time
I
was
prompted
with
a
voice
about
the
meeting
is.
A
Recorded
yeah,
it's
my
second
time
now,
I'm
starting
to
get
used,
but
the
first
time
was
what
what
what
what
some.
C
D
D
Okay,
let's
have
that
1x
or
two
extra
minutes,
but
I
don't
think
any
anyone
else
will
be
joining
right,
maybe
greg.
I
don't
know.
F
He's
still
under
the
the
weather.
E
No
he's
taking
time
off,
but
I'm
not
sure
how
long
I
see
not
sure
if
it's
like
two
weeks
or
yeah,
I
think
yeah.
I
think
it's
variable.
D
Yeah,
I
should
do
that
too,
but
nothing
planet
so.
E
Yeah
I've
got
one
week
planned
off
at
the
end
of
june,
so
I'm
looking
forward
to
that.
A
G
G
D
Okay,
so
rosmus
hasn't
been
doing
a
bunch
of
experiments
and
we
actually
not
on
the
plc
branch
but
in
his
own
private,
and
it
seems
that
we
can
work
around
the
virgin
issues
of
the
assembly
on
the
framework
with
assembly
redirects
that
they
have
a
easy
way
to
do
on
the
old
cs:
project
styles,
that
is,
for
the
dot
net
framework.
D
But
even
if
that's
not
possible
to
do
on
a
kind
of
easy,
clean
style
there,
we
still
have
the
app
config
that
we
could
set
up
the
the
by
this
json
to
the
json
file
to
to
correctly
load
only
the
version
that
we
need
and
for
net
core
3.1
and
5
and
after
it
seems
that
we
can
resolve
this.
The
any
issues
by
applying
the
rules
of
new
get
package
resolution.
D
So,
for
instance,
if
your
application
doesn't
have
a
reference
to
one
of
the
the
system
diagnostics,
then
you
have
two
libraries
that
have
in
their
own.
If
you
just
add
a
reference
to
the
top
level,
it
will
pull
the
the
reference
that
we
need.
That
said,
this
is
preliminary.
D
We
want
to
kind
of
bring
this
experimentation
to
the
poc
branch,
so
everyone
can
try
and
do
their
own
stuff,
so
should
be
simple
stuff.
Should
the
idea
is
that
the
poc
branch
is
really
lee
and
we
can
run
very
easily.
You
know,
so
we
are
going
to
keep
bringing
stuff
from
the
poc
branch,
so
we
can
confirm
our
so
far
solutions
to
this
case.
D
There
are
some
limitations
in
the
sense
that
a
pure
base
that
the
solution
on
the
profiler
doesn't
require
anything
at
all
related
to
build
steps.
You
can
just
have
the
executable
and
bring
the
profiler,
but
I
think
that
for
most
usages
of
open
telemetry,
what
we
have
most
people
are
are
actively
building
their
their
code.
You
know,
I
think
the
scenario
nowadays
is
is
much
less
common
to
have
people
just
getting
the
code
for
a
third
party
and
not
building
and
packing
their
own
application,
but
it's
true.
D
It
doesn't
cover
those
scenarios,
one
of
the
biggest
things
that
I
note
also
is
that
there
is
nothing
for
net
core
2.1
and
that
I
don't
know
how
impactful
that
version
is
in
for
for
usage.
In
general,
you
know
what
I
know
is
that
it's
coming
next
to
the
end
of
life,
but
currently
the
the
the
instrumentation
works
for
dotnet,
core
2.1
and
in
the
poc.
We
can't
make
that
work,
because
the
sdk
doesn't
support
net
core
2.1
so
that
that
will
be
something
that
can't
be
support.
D
I
think
just
for
us
to
kind
of
go
through
some
of
the
questions
so
rasmus
you,
you
confirm
in
the
scenarios
with
the
redirect
bindings
that
it
was
seeing
the
parent
child
relationships
even
between
different
versions.
That's
correct!.
D
Different
version
of
the
system-
diagnostic
diagnostic
source,
dll.
H
So
the
main
application
must
use
only
the
501
that
is
coming
from
the
sdk.
If
it's
different,
then
it's
not
working.
H
D
Yes,
we
didn't
do
the
the
tests
with
the
strong
name
yet,
but
we
plan
to
do
this
on
the
plc
branch
and
bring
that
to
do
the
tests
with
the
strong
name
on
the
the
plc
branch
you
know,
and
we
we
had.
I
think
we
planned
it
for
the
strong
name
and
also
net
core
app
doesn't
have
a
strong
name
so
yeah.
Basically,
we
plan
that,
for
the
framework.
D
And
the
scenario
that
we
are
planning
to
test
is
mailing
around
activity.
So
zac
had
this
question
about
other
types,
perhaps
zach.
If
later
you
can
just.
Let
us
know
what
types
you
have
in
mind.
Perhaps
if
something
is
we
can
add,
but
initially
we
are
planning
just
focusing
on
the
activity
because
is
what's
used
by
the
sdk.
D
Yeah
so
chris,
the
the
experimentation
that
we've
been
doing,
you
have
to
bundle
the
sdk
with
the
tracer.
D
So
basically,
and
one
interesting
question
that
we
have
down
the
line
is,
is
regarding
instrumentations
that
work
with
the
sdk
and
actually
one
of
the
things
then
you'll
be,
and
then
we
can
work
with
the
sdk
folks
to
have
consistent
version,
because
one
case
that
we
find
is
like,
for
instance,
that
is
asp.net
instrumentation,
but
it
doesn't
support,
let's
say,
framework
461,
but
the
sdk
supports
you
know.
So
we
have
some
strange
case
or
we
work
with
them
to
have
consistent
version
down
the
line.
D
If
we
really
go
this
path
or
do
we
have
some
limitations
in
what
can
be
loaded
depending
on
the
application,
but
I'm
kind
of
pointing
that
question
for
the
time
being,
you
know,
but
there
is
this
issue
about
this
packages
and
sdk
version.
C
Yeah
and
then,
of
course,
there's
along
with
the
instrumentation,
I
believe
most
of
those
will
likely
have
some
hard
dependencies
on
types
in
those
different
libraries
that
are
being
instrumented,
and
so
that's
yet
another
surface
area.
To
be
aware
of
that,
you
can't
just
try
to
load
these
assemblies
into
memory
and
try
to
register
that
instrumentation,
because
it
can
lead
to
type
resolution
errors
down
the
line.
C
E
D
Yeah
one
thing
that's
worth
mentioning,
because
the
model
about
these
extensions,
these
added
instrumentations,
is
that
we
felt
the
need
to
have
an
option
to
not
load
the
sdk
to
let
the
application
itself
load.
The
sdk
think
like
this.
We
are
going
to
have
a
set
of
ad
instrumentations
and
they
may
have
something
that
is
actually
not
even
public.
D
You
know
that
could
be
some
instrumentation
of
their
own
libraries
and
then
the
way
to
kind
of
put
this
out
of
this
together
is
basically
to
say:
hey,
okay,
you
have
our
option
that
you
were
in
charge
of
injecting
the
sdk
we
inject
instrumentation,
you
know,
so.
This
is
something
that
we
we
plan
to
put
on
the
plc.
C
Yeah
branch
could
also
be
an
interesting
use
case
for
handling
a
lot
of
the
type
our
assembly
dependencies
that
we
have
as
well.
C
So,
if
there's
some
nougat
package
that
they
could
just
use
and
it
would
enforce
a
bare
minimum
version
of
our
dependencies,
that
could
help.
D
Yeah
yeah,
that's
true,
and
regarding
dreaming
and
how
self-contained
publish
I
I
didn't
look
at
that
and
initially
we
we
are
not
planning
to
to
look
at
those.
You
know
I
think
there
there
was
a
disclaimer
that
I
read
somewhere
in
microsoft.
Website
about
saying
kind
of
certain
stuff
doesn't
work
with
the
current
for
treatment
publishing
for
3.1
and
in
the
sense
that
I
have
to
dig
the
link.
D
This
was
a
some
time
ago,
but
I
had
somebody
trying
to
instrument
with
the
trimming
and
clearly
by
the
the
linking
that
I
found
in
microsoft
that
didn't
work
so
initially
you're
not
planning
to
look
at
that.
Much
on
the
treatment,
publish
code,
I
think,
perhaps,
is
a
requirement
from
our
side.
If
we
go
this
route
that
you
can't
use
that.
D
Yeah
you'll
be
interested
to
know
if,
if
just
disabling
it
just
disabled,
if
the
customer
have
a
real
need
to
use
that
or
if
they
are
willing
to
kind
of
disable
it
to
get
the
the
instrumentation,
you
know
that's
the
hard
question
and
I
don't
know
I
I
also
the
one
that
I
had
to
deal
with.
I
I
told
that
and
they
disabled,
but
I
I'm
not
sure
if
everyone
is
going
to
be
on
the
same
boat.
You
know.
D
C
Yes,
another
thing
with
the
sdk-
and
this
is
specifically
for
if
you
got
an
application
using
asp.net
core
and
redis,
and
that
there's
a
little
bit
more
complexity
to
bootstrapping
the
the
redis
instrumentation,
because
I
believe
you
need
to
have
a
a
reference
to.
C
C
And
so
the
trick
there
is
you
actually
do
the
instrumentation
registration
in
one
of
your
configuration
methods
for
asp.net
core,
where
you
can
then
get
a
reference
to
the
to
the
redis
connection.
E
Wait
so
does
it
basically
require,
like
it
leaks
out
a
redis
assembly
reference,
then
in
the
sdk
yep.
E
D
D
Anyone
else
we
have
questions
in
this.
C
E
C
Track
traction
here
have
how
far
have
you
gotten
with
the
auto
bootstrapping
the
sdk?
I
Only
not
working
on
the
mac
os,
but
but
I'm
not
sure
if
it's
not
even
a
problem
in
in
current
code
base,
because
we,
our
script,
uses,
dot
net
run
and
maybe
there's
some
other
problem.
I
don't
know
if
the
bar
script,
maybe
the
bash
behaves
differently
or
mac
or
maybe
the
child
processes
doesn't
get
the
environmental
virus.
I
don't
know.
I
haven't,
got
enough
time
to
dig
into
the
issue,
but
I
saw
the
same
problem
without
the
sdk
because
I
tried
it.
I
don't
know
if
you
want
to.
D
D
Oh
this,
this
actually
reminds
I,
I
think
one
question
that,
but
let's
finish
your
demo,
I
I
have
a
question
actually
for
that.
I
A
Okay,
if,
if
you
don't
mind,
rebooting
yeah.
I
J
All
right,
the
demo
gods
manifested
themselves.
F
Once
again,
but
zac,
the
question
was.
D
They're
falling
because
the
option
in
the
profiler
is
to
inject
the
tracer
when
it
needs
it
detects
that
it
has
something
to
instrument.
D
I
was
thinking
just
because
if
I
was
writing
something
like
that
from
zero,
I
will
probably
inject
something
on
the
first
jit
compilation
just
because
it
becomes
more
predictable.
You
know
kind
of
oh
asp.net.
If
this
is
gonna
load
on
that
moment,
you
know
so
it
gets
more
predictable.
So
I
was
thinking
if
there
is
any
historical
reason
that
the
option
was
to
wait
for
the
first
instrumentation
of
if
there
was
some
technical
reason
for
that.
You
know.
C
E
Yeah,
okay,
we-
that
is
the
behavior
today,
so
what
happens
is
in
some
of
that
profiler
code.
We
since
we're
doing
monitoring
all
the
j
compilations
the
first
time
we
sort
of
have
a
flag
to
run
some
il
that
we've
embedded,
which
we'll
then
call
that
instrumentation
instrumentation
cs
like
initialize
yeah.
E
The
first
jit
yeah
so
that
way
in
that,
in
that
code
we're
initializing
the
tracer
setting
like
the
tracer
instance
and
then
that's
where
we
actually
set
up
our
first
bit
of
the
asp.net
core
diagnostic
observer
stuff.
D
Yeah
but,
but
just
to
be
sure,
I
noticed
that
because
I
tried
to
to
kind
of
minimize
the
the
integration
json.
If
you
don't
match
anything
there,
the
tracer
is
never
injected.
E
D
Yeah,
I
I
was
just
thinking
in
experiment
with
that
because
in
my
mind,
the
the
the
benefit
in
the
sense
that
it's
more
predictable.
You
know
you
know,
because,
let's
suppose,
if
it's
some
application,
that
a
web
server
actually
in
some
scenarios
is
going
to
be
load
because
of
one
instrumentation
was
loaded
and
depending
on
the
code
path,
perhaps
another
one
is
going
to
trigger
the
load.
So
in
that
sense
it's
not
reproductible.
You
know.
So
I
was
thinking
that
perhaps
making
reproductible
makes
our
debugging
life
easier.
You
know.
D
D
D
What
I'm
saying
is
kind
of
hey
inject
the
tracer
at
the
first
jute
compilation.
That
way
is
always
reproductible.
You
know
what's
happening.
E
D
First,
one
globally,
the
the
first
one
globally
like
we
could
look
for
maine
or
or
globally.
I
I
actually
didn't
put
thought
on
that,
but,
let's
say
main
or
globally,
one
of
the
two
anyway,
with
the
goal
of
making
more
predictable,
more
projectile,
making
predictable
what
happened
with
a
specific
runtime
and
type
of
application.
You
know.
E
Got
it
yeah
we
we
do
already
try
to
do
it
globally
on
the
first
jet.
E
So
I
guess,
if
that's
not
working
as
it's
better,
then
maybe
you
can
show
me
like
an
example
of
what
you're
expecting
to
happen.
Okay,.
D
I
I
hoping
you
via
slack
afterwards,
then
I
show
what
I
mean
by
that
you
know
and
we
can
go
further
from
there
all
right.
I
Just
rebooted
the
machine,
and
basically
starting
from
this
point,
we
see
not
docker
run
here.
We
see
that
we
have
run
two
instrumented
app,
so
so
one
of
them
is
basically
just
an
asp.net
core
mvc31
application
which
which
just
it
was
just
having
some
dummy,
endpoint
and
second
one
which
is
instrumented
here.
I
So
it's
an
http
client
with
which
calls
this,
which
basically
makes
a
call
to
this
to
this,
to
the
s
core
server
and
also
to
one
non-existing
to
non-existing
end
point
so
give
me
so
the
code
will
be
here
and
also
it
has
an
additional
activity
just
to
check
if
it
will
be
also
compatible
with
the
with
the
with
the
diagnostics
or
diagnostic
library.
I
G
D
Just
one
thing,
because
before
I
forgot,
can
you
go
back
to
the
clients
program?
I
guess
yeah.
Of
course
I
I
did
a
very
cool,
quick
review
now
before
I
forget,
so
I
I
want
to
point
out
that
you
are
creating
a
new
client
and
still
using
the
old,
regular
client
from
the
top.
B
D
27,
could
you
repeat,
I
didn't
get
so
line
26
25,
you
create
a
new
client
yep,
but
then
you
use
it
was
the
intention
to
keep.
B
I
B
E
So
that
the
sailor
profiler
managed
that
one
is
right
now
referencing,
the
sdk
is
that
correct
and
then
you're
just
calling
it
initializing
it
from
the
instrumentation
code
exactly.
G
E
E
I
Because
otherwise,
it
is
using
because,
as
far
as
I
understand
erasmus,
correct
me,
if
I'm
wrong
the
out
of
the
box
diagnostic
source
reference
which
is
used
is
not
the
same
which
is
used
by
the
sdk
is
an
older
one.
So,
in.
H
E
D
Cool
yeah,
so
it
seems
that
we
have
a
a
path
forward,
as
I
mentioned
before,
we
we
want
on
the
plc
to
be
easily
available,
so
people
can
test.
We
still
the
tests
that
erasmus
did
actually
are
not
fully
available
there
yet
on
the
plc,
but
we
are
gonna
start
to
upstream
the
rest
of
the
stuff,
and
we
can
further
test
this.
You
know
and
perhaps
is
a
path
that
allows
us
to
use
the
the
code
instead
of
duplicating
exporters
and
all
that
stuff
in
the
ripple.
D
Yeah,
I
I
think
one
interesting
question
you'll
be
down
down
the
line.
If
we
really
go
this
path
about,
we
have
the
ad
instrumentation,
let's
say
for
asp.net:
do
you
do
some
auto
instrumentation
or
use
the
sdk?
You
know
kind
of
choice,
and
this
can
be
even
configurable.
You
know,
but
there
is
a
bunch
of
things
for
which
there
is
no.
D
There
is
not
even
the
programmatic
groups
to
add
the
instrumentation.
We
still
need
il.
We
write
to
do
that.
Instrumentation,
you
know,
maybe
in
the
future,
if
activity
and
activity
source
are
really
successful
and
people
follow
open
element
conventions,
we
can
reduce
the
set.
But
as
far
as
I
see
kind
of
for
at
least
a
few
years
like
three
or
four
we
are
still
gonna
need,
io,
instrumentation
and
I've.
I
say
three
or
four.
I
think,
I'm
being
optimistic.
You
know.
D
C
Yeah,
so
one
thing
I'm
curious
about:
how
are
you
currently
bundling
the
sdk
with
with
the
tracer?
Are
you
just
using
the
pre-built
dlls
directly
or
are
you
effectively
vendorizing
it
so
far.
A
C
Yeah
so
one
interesting
thing
related
to
using
the
these
packages
directly
like
this
is
so
the
sdk
has
a
contrib
repo
and
so
there's
a
bunch
of
other
instrumentations
out
there,
and
I
don't
know
if
this
is
something
we
want
to
consider
at
all.
C
D
Maybe
it
could
be
what
what
do
I
think,
but
I
think
initially
that's
one
of
the
reasons
that
we
want
to
have
the
option
of
just
using
the
api
and
let
the
user
do.
The
injection
of
the
sdk.
C
D
It's
not
going
to
be
a
zero
touch
in
this
case,
but
I
think
it's
a
good
compromise
for
at
least
initially
you
know
and
later
we
can
look
at
possible
solutions
like
you're,
saying
kind
of
hey
load
the
dependencies
from
this
folder
here
and
call
this
method
via
reflection.
That's
when
I
had
some
instrumentation
yeah.
I
think
I
think.
I
D
I
I
was
asking
one
thing
on
the
on
slack,
but
for
the.net,
not
the
instrumentation.
I
was
asking
if
they
want
to
have
something
like
you
know:
load
the
tracer
from
environmental
variables.
You
know
like
an
extension
method
that
basically
does
this
stuff
and
basically
one
guy
said
no
there's
nothing
like
in
the
upstream,
but
we
have
created
it
by
our
own
because
we
we
want
it.
I
So
I
think
that,
basically,
if
we
do
this
stuff
here-
and
we
will
have
you
know
just
kind
of
ready
code-
we
can
just
make
a
nougat
package
of
it.
And
basically
we
can
you
know
so.
Someone
can
use
just
an
extension
method
like
you
know,
autoload
whatever,
and
then
they
can.
They
can
add
to
additional
stuff,
and
I
think
it
will
be
the
safest
approach
and
then
it
would
also
force
to
load
the
same
versions
of
the
dlls.
D
Yeah,
but
I
I
think
increase
can
correct
me
if
I,
if
I
misunderstood,
that
I
think
chris
was
thinking
the
case
like
let's
say
there
is
a
version
of
some
instrumentation
that
depends
on
the
sdk,
that
let's
say
we
don't
have
access,
so
we
could
somehow
provide
a
way
for
that.
You.
C
D
D
D
All
right,
I
think
one
other
thing
that
I
put
to
talk
about
was
the
nuke
build.
I
look
at
the
pr,
but
I
I'm
really
ignorance
about
nuke
stuff.
I
try
to
learn
it.
It
looks
good
to
me.
I
like
the
thing
that
we
stay
kind
of
on
the
same
mind
model
you
know,
and
I
think
I
think
it's
an
improvement.
I
I
would
invite
the
folks
to
look
more
if
they
have
a
chance,
because
I
think
it's,
it's
really
a
good
improvement.
E
Yeah,
it
basically
tries
and,
as
you
guys
already
have
experienced,
there's
a
lot
of
different
build
scripts
that
we
have,
and
so
that
basically
provides
an
entry
point
so
that
there's
just
one
build
sh
or
build
cmd
and
that'll
launch
nuke
and
basically
each
target
that
we
had
there's
still
a
lot
of
them,
which
can
use
some
consolidation.
But
each
target
that
we
had
so
like.
E
Building
the
like
windows,
integration
tests,
building
the
msi
building
like
the
zip
file,
they're
all
just
individual
targets
within
there,
and
so
it
basically
it's
still
pretty
large.
But
it's
like
one
common
entry
point
and
so
we'll.
I
E
I
don't
know
I've
ran
it
on
windows.
I
have
not
tested
on
other
systems.
I
expect
it
to
because
I
think
it's
also
actually
running
in
ci
as
well.
So
it's
using
using
that
entry
point
to
run
our
linux
integration
tests,
cool.
D
Yeah
yeah,
so
so
I
I
I
like
the
stuff
there.
As
I
said,
I
didn't
comment
because
I
need
to
learn
more
about
nuke,
but
I
I
like
the
the
idea
in
the
model
you
know,
so
I,
if
folks
have
a
chance
just
to
do
a
quick
check
on
that
bi.
I
think
it's
worth
you
know
and
then
I
I
think
we
we
can
also
prepare
ourselves
when
we
do
some
pool
and
get
that
technology
on
our
side
to.
C
C
So
apollo
you
mentioned
earlier
that
you
wasn't
that
you
weren't
quite
sure
what
the
net
core
2.1
usage
was
for
people,
and
so
I
took
a
quick
look
at
some
of
the
dashboards
that
that
we
have,
and
it
looks
like
our
usage
of
greater
than
core
3.0
and
less
than
core
3.0
are
fairly
similar.
C
D
Yeah
that
that
that
that's
kind
of
a
bummer,
but
we
we
can
do
what
we
can
do
right
so.
D
A
D
Yeah
and
and
actually,
if
I'm
not
mistaking
the
very
first
system,
diagnosed
diagnostic
source,
no
I'm
probably
wrong
on
that.
But
2.1
had
one
of
the
first
diagnostic
related
stuff.
That
kind
of
is
really
old,
but
we
also
have
the
no
get
packages
stuff
for
that.
So,
but
we
don't
have
the
sdk
so.
I
C
C
Yeah,
I
just
see
the
code
coverage
badge
story.
D
Oh,
I
saw
this
a
few
days
ago
and
completely
forgot
about
I'll.
Take
a
look
at
that.
I
didn't.
I
didn't
look
it
so
it's
somebody
from
the
hotel.
D
I
I'm
not
sure
if
the
person
is
member,
but
he
created
a
pr
to
to
do
some
to
satisfy
some
requirements
regarding
what
open
telemetry
requires.
That's
correct,
more.
I
I
I
I
True
also,
I
don't
know
zach
any
update
from
your
site
from
from
the
issues
that
you're
assigned
to
or
greg
is
assigned
to.
I
don't
remember
there
were
quite
a
few
of
them.
E
Repo,
oh
sorry,
I
apologize.
I
was
made
to
have
something
else
that
one
is
still
in
pr,
so
we
expect
that
to
be
merged
soon.
As
far
as
so
greg
has
one
about
stun
activities,
I
don't
know
the
status
of
that
and
I
have
not
made
any
progress
on
the
design.
I
need
to
prioritize
that.
E
To
yeah
I'll
need
to
talk
with
tony
about
that
and
the
other
one
which
one
was
the
other
one.
E
Hey
87,
okay,
hardcoded,
name,
output,
file;
okay,.
E
Okay,
I
don't
have
any
updates
yeah
this
one
I'll
need
to
again
sync
with
tony,
because
he
has
the
most
knowledge
here
so
yeah,
no,
no
many
philip
days
for.
A
D
So
I
I
actually
thanks
for
reminding
that
so
I
bet
we
should
always
put
in
in
the
end
of
the
meeting
or
in
the
beginning
to
do
a
quick
review
on
that.
I
I
was
completely
focused
on
the
poc
stuff
and
didn't
usual.
D
To
be
honest,
all
right,
I
guess
I
see
you
guys
next
week
then.