►
From YouTube: 2021-08-25 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
C
B
C
Is
an
issue
that
came
up
in
the
specs
egg
yesterday
there
are
some
changes
to
the
1.6
seminar
conventions,
values
where
the
the
values
could
not
be
generated
into
proper
identifiers
in
some
languages,
because
they
start
with
numbers
or
have
spaces
in
them,
and
so
they're
they're
going
to
be
changed.
The
values
themselves
will
be
changed
and
they
expect
there
will
be
a
schema
for
either
one
six
one
or
one
seven.
It
wasn't
clear
which
direction
that
was
going
to
go.
That
will
contain
that
translation
information.
C
So
this
is
a
point
at
which
we
we
talked
about.
It
could
be
useful
to
have
a
processor
in
the
collector
that
can
perform
schema
migration,
where
you
tell
it
I
want.
You
know
the
end
result
to
be
in
schema
version
x
and
it
uses
these
schemas
to
translate
either
up
or
down
versions
based
on
the
attributes
that
come
in.
C
C
Okay,
I
can
create
an
issue
describing
at
a
high
level.
What's
required.
I
don't
know
if
there's
anyone
on
the
call
who's
interested
in
taking
on
this
effort,
but
once
I
have
an
issue,
I
will
get
it
added
to
these
notes
and
mention
it
in
the
slack
channel
so
that
anyone
who
is
interested
in
the
work
can
give
it
a
try.
B
Yeah,
the
only
problem
is,
we
need
to
to
make
sure
everyone
understand
that
we
are
in
the
middle
of
the
transition
to
contribute.
So
probably
maybe
some
delay
here
and
there.
C
Sure
yeah,
my
expectation,
was
that
it
would
take
a
little
bit
to
craft
this,
so
it
would
probably
fall
after
we're
done
with
that.
But
that
is
a
fair
point
to
call
out.
B
B
Yeah
so,
as
you
know,
we
are
doing
a
lot
of
other
work,
so
we
expect
some
delays
and
I'm
sorry
about
that.
But
we
have
the
priority
to
unlock
all
the
prs,
because
for
we
we
had
a
lock
on
the
freeze
on
the
pr
scene,
collector
and
stuff.
So
I
would
prefer
to
to
prioritize
that
against
any
other
work.
E
Yeah
till
next
monday,
okay
yeah-
I
mean
until
until
the
move
is
stable.
Unfortunately,
we'll
go
slow
on
merging
anything
or
not
merge
anything.
D
Yeah
makes
sense,
I
understood
thanks.
C
So
I
think
I
can
probably
summarize
this,
though
we
were
having
the
conversation
on
slack
it.
So
the
the
we
when
we
were
moving
the
components
out
of
corn
and
dick
and
trib.
One
of
the
steps
we
wanted
to
take
was
to
create
a
manifest
for
the
collector
builder.
That
would
produce
a
binary
that
had
the
same
components
as
the
core
prior
to
any
of
the
changes,
and
the
question
was:
where
should
that
manifest
live?
C
So
I
think
we've
discussed
in
the
past,
should
there
be
releases
or
manifest
repo,
or
should
that
all
be
bundled
together
in
the
builder
repo,
and
I
think
he
and
I
are
both
in
favor
of
having
a
separate
repository
for
those
manifests
or
or
releases
enabling
the
builder
to
to
stay
as
a
library
or
utility
and
others
can
come
along
and
have
their
own
instances
of
releases
if
desired,
to
effectuate
distributions
yeah.
I
think
his
concern
here
is.
We
haven't
recorded
that
decision
anywhere.
B
I'm
fine
with
that,
but
I
would
challenge
the
other.
One
should
builder
be
its
own
package,
or
should
we
put
them
into
the
go
builder
tools-
repo,
not
its
own,.
C
E
C
B
C
So
contrib
currently
just
builds
itself
with
its
set
of
default
components
for
testbed
right.
That's
how
it
functions
or
does
it
get
a
binary
from
somewhere
else.
B
G
B
So
so
we
just
discussed-
and
we
said:
okay,
it
seems
fine
to
have
a
release
repo,
but
there
is
a
circular
dependency
here,
which
is
the
test
bed.
The
test
bed
after
the
move
leaves
in
contribute
and
needs
an
image
to
test
against,
and
it
seems
like
a
circular
dependency
that
the
components
leave
in
a
contrib.
G
Right
so
the
builder
itself
is
a
command
line,
interface
tool
right,
so
you
can
download
the
builder
and
generate
a
a
binary.
The
way
that
you
want
in
the
contrib
repo
itself,
so
you
can
generate
a
binary
with
only
the
the
contrib
components
that
you
want
to
test
or
all
of
them.
You
want
to
test
all
of
them.
G
Of
course
it
is
a
duplication
of
efforts,
because
the
releases
repository
is
going
to
contain
a
manifest
that
looks
very
much
the
same
as
potentially
as
the
one
that
you
have
in
contrib,
but
it's
not
a
direct.
You
know
dependency
between
them.
The
releases
repository
would
be
the
releases
that
we
as
a
community
would
make
a
stamp
and
say
you
know
this
is
what
we
support.
B
Okay
for
for
the
release
last
question
for
the
release
and
it's
important
right
now:
where
would
you
publish
the
images
we
already
have?
Two
docker
hub
accounts,
one
for
for
collector
and
one
for
for
contrib,
probably
for
the
foreseeable
feature,
it's
better
to
reproduce
the
same
images
that
we
were
doing,
I
know
I
know
anthony-
has
a
manifest
for
the
previous
hotel
collector.
G
Yeah,
absolutely
I
mean
I
just
pasted
a
link
here
in
the
agenda
with
a
release
that
I
did
this
morning
and
if
you
open
the
release
itself,
it
lists
two
docker
locations
for
two
images,
so
one
for
the
collector
core,
which
contains
all
the
the
the
components
from
the
manifest
that
I
used
this
morning
based
on
the
select
trend
and
the
second
image
is
a
load
balancer
just
for
fun.
You
know
just
to
to
prove
a
concept
that
multiple
binaries
are
possible.
G
It's
a
configuration
option
in
in
go
wizard
to
set
what
is
the
namespace?
What
is
the
registry
to
use?
So
we
just
need
to
agree
on
a
name,
a
location,
and
if
it
is
under
open,
telemetry
realm
on
docker
hub,
then
I
need
one
of
the
maintainers
to
go
into
this
repository
here
and
add
a
secret
with
the
credentials.
A
B
We
will
do
that
last
last
question
about
this.
We
do
did
produce
msi.
G
Right
that
one
is
missing
yeah,
so
that's
the
only
thing
that
I
think
is
missing,
so
I
need
you
all
to
take
a
look
and
see
what
else
you
think
is
missing,
but
msi
certainly
is
something
that
I
I
first
I
I
have
no
idea
how
how
it
works.
I
think
alolita
last
time
mentioned
that
it
requires
a
a
windows
image
or
in
windows.
E
B
So
so
we
we
do
produce
an
msi
image
from
from
collector
jurassic.
So
take
a
look
at
our
rules
and
yeah.
If
we
can
plug
that
in,
at
least
in
the
in
the
yeah.
G
So
I
did
take
a
look
at
that
one
and
it
is
using
circle
ci
windows
builder,
for
that.
G
Is
it
if
there's
someone
that
knows
what
they're
doing
to
do
this
part
here,
I
can
show
which
parts
needs
to
be
adapted,
which
you
know
which
files
is
changing.
I
think
it
would
be
faster
than
I
figuring
out
windows,
stuff.
B
Yeah
look
look
at
this
action,
so
I
have.
We
have
an
action,
a
github
action
that
produces
msi
in
the
collector,
so
it's
still
using
windows
image,
but
but
we
have
the
the
script
and
everything
so
maybe
maybe
you
can
use
that.
I
will
connect
you
with
somebody
also
to
to
give
you
some
hints
the
the
person
who
wrote
that
script.
G
All
right
sounds
good
all
right,
so
how
do
we
do
with
the
repositories,
then?
Do
you
create
them
under
open,
telemetry
or.
B
G
E
B
Okay,
I
will.
I
will
take
a
step,
look
at
that
issue
and
if
it
has
enough
of
the
world,
I
will
create
it.
G
B
Okay,
we'll
do
that
perfect.
B
Okay,
next
one,
I
think
we
we
agreed
on
this,
I
will
follow
up
on
making
the
repo
thank
you
alolita.
E
Yeah,
I
just
wanted
to
bring
up
a
couple
of
points
that
just
folks
need
to
be
aware
of,
and
these
were
just
that
just
call
out
that
people
will
have
to
resubmit
their
prs
on
contrib,
given
our
prometheus
components
and
as
well
as
zipkin
and
jager
pipelines
have
moved
to
contrib.
E
A
I
have
a
question
on
process
related
to
that.
Actually,
if
that's
okay,
so
our
prs
to
the
contrib
repository
frozen
at
the
moment
is
that
is
that,
what's
going
on.
A
Okay,
if
there,
if
there's
anything,
I
can
do
to
help
also
feel
free
to
message
me
on
cnc,
app
slack.
Okay,.
I
B
Yeah,
so
you
can
see
there
a
bunch
of
pr's
that
we're
doing
a
bunch
of
discussions.
E
B
Thank
you:
okay,
alolita
github
actions
yeah.
This
is
related
yep.
B
So
anyone
from
amazon
can
help
us.
We
saw
a
demo
last
week
or
two
weeks
ago
about
this,
and
it
would
be
good
to
to
enable
that
tool
that
you
made,
or
one
of
the
interns
made
yeah.
E
B
Other
releases
and
setting
up
the
correct
versions,
so
one
of
the
biggest
problem
right
now
is
because
we
have
multiple
repo.
When
we
do
a
release,
we
need
to
upgrade
all
the
versions.
So
consumers
of
these
don't
have
to
use
replace
statements,
and
I
heard
that
the
tool
fixes
that
maybe
I'm
wrong
anthony
do
you
know.
C
B
C
B
Perfect,
how
how
hard
is
to
enable
that,
for
contrib
and.
E
Well
then,
we'll
we'll
take
a
look.
It
shouldn't
be
very
hard,
but
we
can
work
on
it
next
on
monday,
if
that's
okay,.
E
B
E
Okay,
let's,
let's
I'll
I'll
sync
up,
maybe
alex
and
anthony,
we
can
chat
figure
that
out.
C
G
So
anthony
the
manifest
that
you
added
to
the
channel
is
the
one
that
I
used
for
the
v002
there,
so
it's
working
and
released.
If
that's.
C
Yeah,
so
no
we're
we're
talking
about
a
slightly
different
manifest.
This
would
be
for
the
multi-module
version
management.
C
That
eddie
had
created
for
the
go
sdk
earlier
to
help
us
deal
with
having
modules
in
the
contrib
repo
that
are
going
to
be
at
different
versions.
So,
right
now
we're
just
going
to
try
to
establish
a
baseline
everything
at
the
same
version,
but
still
list
out
all
the
modules.
Then
we
can
start
breaking
them
out
in
groups.
C
B
E
B
I
think
I
think
we
are
done
for
the
release
jurassic,
quick
thing
for
the
release.
Can
you
help
us
by
next
tuesday?
I
will
help
you
with
the
repo
today,
but
can
you
help
us
by
next
tuesday
to
have
the
manifest
in
place
and
be
able
to
even
without
msi
but
be
able
to
build
a
hotel
collector
and
push
it
to
the
docker
hub?
Because
I
don't
want
to
downgrade
the
the
experience
for
our
collector
users
right
now,
yeah.
B
Core
contrib
contrib
doesn't
change
at
all.
We
can
still
build
from
there
because
all
the
components,
even
though
they're
moved
they're
still
there
we
still
build
and
then
in
two
weeks
we'll
do
the
country
the
next
one
will
be
contrib
as
well.
But
let's
focus
on
core
because
sure
I
cannot
build
anymore
after
the
remote
yeah.
G
So
I
think
I
think
the
manifest
that
anthony
provided
is
already
containing
all
the
components
and
it's
there
already
it's
there
on
that
repository.
So
as
soon
as
the
repository
is
created
under
open
telemetry,
I
can
push
the
code
there
and
I
can
do
a
release
like
very
quickly
on
that
new
repository
just
make
sure
to
add
the
secret.
The
secrets
for
pushing
the
the
images
to
docker
hub
yeah.
B
Because
those
are
more
secure
than
circle
ci,
I
heard
perfect.
I
will.
I
will
take
that
as
an
action
item
to
unblock
this.
So
then
we
can
have
it.
It's
not
needed
right
now,
a
new
release.
We
need
the
tuesday
when
we
release
the
core.
We
need
to
build
the
binaries,
because
yeah
yeah.
A
G
So
what
I
would
do
by
let's
say
I
don't
know
this
friday,
let's
say,
is
to
run
a
build
and
a
release
published
under
my
namespace
on
clay
io,
and
then
we
can
verify
if
that
works.
And
if
that's
good,
then
I
change
the
releases
and
we
can
publish
on
tuesday
yeah.
B
B
K
I
just
have
a
quick
notification
for
jurassi
to
inform
that
pr.
354
is
ready
for
review
in
the
operator.
B
I
think
we're
done
yes.
Indeed.
Thank
you.
Everyone,
oh
jurassic
last
thing
for
you.
I
know
you
define
the
interfaces
for
p
data
authentication
data.
That's
one
thing.
The
second
one
is
the
interfaces
that
the
extension
should
implement
right.
I
want
to
put
something
in
your
mind
before
I
I
leave
should
that
be
in
config
out,
or
should
that
be
out
out
extension
package
in
the
extension
just
those
interfaces.
G
Let's
involve
tigran
in
in
this
discussion
as
well,
because
I
think
he
prefers
to
have
it
in
configures.
I
would
say
that
whatever
is
not
strictly
config
should
be
in
the
auth
package.
I
think
I
did
have
a
auth
context
or
something
like
that,
but
let's
involve
him.
I
think
he
has
a
strong
opinion
on
that.
B
Okay,
okay,
the
other
thing
I
was
surprised.
I
know
the
interfaces
have
different
things
for
http
for
grpc.
I
was
thinking.
I
think
we
can
work
on
map
string,
string
for
all
the
things
and
don't
involve
the
don't
make
the
interface
literally
knowing
about
grpc
http,
even
tcp
or
anything,
but
we
can
discuss
that
separately.
L
L
All
right
so
first
thing
we
measured
the
the
rename.
So
now
it's
open,
telemetry,
clr
profiler
there
will
be
no
other
clr
profiler.
We
can
drop
that
big,
auto
instrumentation
word
thing.
L
That
that's
alright
there
just
kind
of
to
notify
people.
I
put
out
also
kind
of
very
high
level
architectural
overview.
I
would
appreciate
stack
if
you
can
take
a
quick
look.
I'm
trying
to
describe
things
at
very
high
level.
You
know
so
it
should
be
just
about
100
lines
of
text
is
very
short.
L
It's
just
to
capture
in
attempt
to
give
people
a
chance
if
they
arrive
at
the
repo
to
kind
of
have
an
overview
about
how
to
navigate
the
project
and
stuff
like
that,
then
I
think
the
the
next
big
thing
that
we
have
to
do
is
to
make
the
plc
branch
the
main
branch
of
the
ripple
and
kind
of
I
was
thinking
also
in
cleaning
up
a
bunch
of
things
that
give
the
impression
that
we
are
still
working
on
on
the
main
branch.
L
So
things
like,
I
want
to
review
all
the
open
issues,
because
I
think
there
is
a
bunch
of
things
that
we
should
probably
be
closing
kind
of.
We
had
things
for
just
on
the
top
of
my
mind.
L
We
had
things
like
about
making
the
tracer
how
we
are
going
to
work
with
the
multiple
versions,
and
since
we
are
going
for
this
path
with
the
sdk
we
we
should
close
a
bunch
of
those
related
stuff
and
kind
of
make
the
repo
and
the
github
kind
of
clean
for
people
that
arrive
at
the
project.
At
this
moment,
I'm
not
sure
if
we
should
do
at
the
meeting.
L
Let's
see
how
we
go
with
the
discussions,
but
perhaps
it
kind
of
takes
a
little
bit
of
time
and
I
can
go
later
over
the
issues
and
close
open
and
if
I
close,
something
that
should
stay
open
can
discuss
the
real
there's,
no
big
deal
there.
So
I'm
not
sure
if
should
go
over
then
in
the
meeting.
Just
for
a
matter
of
expedience.
L
Same
thing
applies
to
the
dashboard,
the
dashboard
we
we
set
up
at
the
time
that
we
are
thinking
about
doing
the
release
with
the
tracer
with
the
original
data
dog
tracer.
So
I
think
we
should
look
at
the
dashboard,
establish
the
the
new
target
and
kind
of
do
a
clean
up
there
and
see
what
we
need,
and
on
top
of
that,
I
think
the
the
thing
that
we
we
already
mentioned
before
is
that
we
are
gonna
would
like
to
have
alpha
or
beta.
L
I'm
I'm
not
worried
about
the
terminology
right
now,
but
some
release
together
or
right
after
dot
net
six
few
instrumentations,
probably
just
more,
with
a
b
and
graphql
for
bytecode
instrumentations,
asp.net,
core
http
client,
this
kind
of
really
common
use
it.
What
I'm
calling
source
instrumentations
coming
via
the
the
sdk
and
basically
have
a
release
that
we
can
do,
can
give
some
people
to
try
and
start
to
use.
L
So
that's,
basically
the
the
plan
and
updating
this
changing.
Also,
as
I
said,
the
plc
branch
to
become
the
main
branch.
We
have
questions
that
I
mentioned
last
week
that
we
didn't
address,
but
I
think
the
forcing
factor
about
making
the
branch
will
force
us
kind
of
to
go
to
these
questions.
The
main
ones
that
I
have
in
my
mind
are
kind
of.
L
We
need
to
be
sure
that
we
don't
miss
bug,
fixes
and
changes
regarding
the
the
native
part,
so
I
think
that
we
wanna
regularly
to
be
at
least
following
upstream
to
be
sure
that
we
don't
need
especially
bug
fixes.
You
know,
but,
as
I
said,
let's
make
that
the
main
branch
and
and
then
we
address
and
start
to
have
a
procedure
for
that.
L
I
think
doing
as
we
are
doing
before
the
pull
for
upstream
becomes
really
hard
because
it,
the
the
ripple,
is
very
different,
but
in
another
sense
we
we
should
not
lose
the
the
bug
fixes.
That's
why
the
this
kind
of
concern,
so
I
I
went
over
these
things
relatively
quickly,
but
basically,
these
are
are
the
things
that
I
had
in
my
mind
for
this
meeting.
L
There
was
a
release
of
the
sdk
another
alpha
that
they
are
doing.
I'm
gonna
update
the
branch
and
try
to
bring
the
changes,
relate
to
environment
variables
that
were
done
on
on
the
sdk.
So
I'll
do
that
during
this
week,
and
I
think
that's
it
that
I
had
in
my
mind.
J
L
Yeah
I
I
think
that
may
be
a
good
idea.
You
know,
because
if
you
keep
the
branch
we
have
the
test,
we
have
each
step
in
bringing
the
the
stuff
from
that
branch,
so
some
stuff
that
we
can
change
it
makes
make
easier
than
instead
of
trying
to
pick
up
from
upstream
straight.
You
know,
so
I
think
I
think
that's
a
good
point.
We
should.
We
should
consider.
L
Yeah,
I
I
really
didn't
put
much
thought
in
about
that,
but
I
think
I
think
this
idea.
Perhaps
it
facilitates
the
whole
process,
one
of
the
things
that
a
small
thing
that
crosses
my
mind-
and
this
is
based
on
something
that
rasmus
mentioned
to
me.
L
We
had
some
kind
of
breaks
in
the
solution,
but
basically
because
I
think,
for
instance,
I've
been
using
visual
studio
code
with
nuke
and
command
line
stuff,
so
I
didn't
see
anything
break
on
the
solution
because
I'm
not
used
so
perhaps
we
we
should
look
at
building
the
solution
on
the
ci,
but
I
I
also
didn't
look
that
this
is
something
that
you
do
upstream
zach.
J
I
mean
I
usually
use
visual
studio.
I
don't
ever
use
command
lines,
so
I'm
like
the
complete
opposite
yeah.
So
so
in
your.
L
A
L
Was
something
missing
on
the
bug
that
I
never
noticed?
You
know
erasmus
was
the
one
that
found
you
know
so
in
our.
In
our
case,
I
think,
since
the
modus
operandi
is
not
all
the
time
on
the
solution,
I
think
you'll
be
good
if
we
had
a
ci
cd
for
the
solution.
J
I
think
so
I
think
the
ci
that
we
have,
I'm
not
sure
if
this
is
mirrored
in
your
ci,
is
so
basically
everything's
with
command
line.
Nuke
accepts
the
one
of
the
first
things
it
does.
Is
it
just?
Does
a
nuget
restore
based
on
the
solution,
and
so
I
think
that
alone
is
a
good
check
to
make
sure
that's
in
sync,
because
if
there's
inconsistencies
or
if
it
can't
load
projects,
then
the
actually
yeah
yeah.
J
Okay,
sorry,
let
me
let
me
explain
that
so
everything
that
nuke
does
like
buildings
certain
projects.
It
uses
the
solution
file
as
the
source
of
truth.
So
basically
it
loads
the
solution
file
and
then,
if
we
want
to
build
like
the
main
tracing
projects,
when
we
specify
that
like
to
build,
we
query
the
solution
for
that
project
like
by
the
project.
By
like
the
I
guess,
project
name,
and
then
it
gives
that
back
to
us.
J
So
when
we're
building
each
of
those,
if
there's
something
wrong
with
a
project
not
being
there
or
unable
to
load,
I
think
it
should
error
out
and
make
it
obvious
already.
At
least
I
think
that's
how
it's
operating
right.
Now,
in
our
datadog
ci.
L
Yeah,
I
I
think
perhaps
the
case
that
we
have
is
some
very
specific
library
for
native
that
is
part
of
the
source
and
I
think
when
we
started
the
the
plc
branch
when
they
we
clean
up
when
we
make
kind
of
minimum,
we
cut
that-
and
I
never
know
you
know
only
when
erasmus
tries
to
build
the
debug.
So
that
explains
why
it's
not
caught
by
the
nougat
restore
on
the
solution.
L
But
anyway
my
my
my
main
concern
was
kind
of.
Oh,
the
solution
was
broken.
I
never
know
you
know,
so
that's
the
the
thing
that's
kind
of
make
immediately
kind
of.
Oh,
I
need
to
build
the
solution
somehow,
every
time
you
know
so
cicd
comes
to
mind,
but
but
I
think
I
think,
you're
right
kind
of,
because
we
use
the
project,
but
we
probably
are
building
just
release
that
that
will
be
interesting
for
just
building
the
leads
on
the
ci
cd.
L
L
L
L
L
All
right,
as
I
said,
that's
what
I
had
do
you
guys
want
to
bring
anything
up.
M
Yes
follow,
so
it's
a
very
good
document.
I
did
not
go
through
like
completely
step
by
step,
but
the
few
of
the
challenges
like
whatever
is
mentioned
in
this
document.
I
had
a
discussion
with
the
dotnet
team
in
the
past
two
weeks,
even
I
discussed
with
them
a
pro
about
the
approach
that
the
auto
instrumentation
added
for,
like
the
vendored
diagnostic
source
approach
and
all
so.
M
The
runtime
team
has
agreed
to
help
the
instrumentation
space,
but
they
really
wanted
to
know
what
are
the
challenges
that
we
have
it
in
this
space,
especially,
it
is
being
called
out
the
under
the
assembly
conflict
resolution.
You
have
called
out
that's
the
same
similar
thing
I
like,
I
also
notified
them,
and
there
is
no
good
ways
at
this
point
without
making
the
dotnet
runtime
host
to
resolve
this
issue,
because
dotnet
core
has
like
kind
of
two
publishing
models.
One
is
framework
dependent
and
the
contained.
H
M
Whatever
the
approach
we
come
up
with,
it
will
scale
very
well
with
the
framework
deployment
model,
because
we
have
additional
dates
or
we
can
even
modify
the
file
attribute
portion
of
a
diagnostic
source
and
and
we
can
load
and
get
it
working.
But
in
case
of
like
self
contained
application,
it
does
not
honor
any
of
those,
and
currently
there
are
no
ways
even
to
take
a
look
at
the
library
which
is
outside
that
space.
M
So
if,
as
an
auto
instrumentation,
if
we
need
to
instrument
that
app,
there
is
no
way
that
we
can
get
the
the
diagnostic
source.
What
is
comes
with
the
sdk
to
be
a
part
of
that
app?
If
we
even
try
an
attempt
to
do
that,
we
are
going
to
crash
that.
M
So
these
are
the
kind
of
challenges
I
discussed
with
them
and,
apart
from
diagnostic
source,
at
least
our
team
for
the
current
application
insights,
we
have
a
solutions
within
us,
even
if
we
don't
have
a
depth.json
or
something
there
are
several
other
ways
we
use
something
like
iel
merge.
We
change
the
library
to
different
library
or
we
can
change
the
file
attribute
version
to
a
lower
version.
So
in
in
that
way,
so
we
have
a
lot
of
hacks
to
do
that,
either
with
self-contained
or
framework
deployment,
but
not
for
the
diagnostic
source.
M
So
the
model
which
you
have
like
proposed
here
is
going
to
have
a
big
challenge
for
us
in
a
self-contained
scenario,
especially
the
challenge.
That
is
the
same
challenge
I
initially
joined
to
discuss
and
that's
have
been
called
here
out.
We
might
miss
a
like
a
lot
of
like
apps
or
not
auto
instrumented
with
this
approach,
so
it's
a
good
documentation.
M
So
I'm
going
to
take
this
and
speak
with
the
runtime
team
again
and
saying
that
this
is
a
broader
issue
and
we
need
something
in
the
the
runtime
itself
and,
if
need
be,
I'm
just
going
to
get
them
to
this
meeting.
Also
so
that
we
can
have
a
discussion
here.
L
Yeah,
no
very
good
thanks
for
bringing
that
up.
It's
really
true
that
we
have
focused
on
very
kind
of
specific
scenarios.
We
do
have
concerns
about
these
other
kind
of
because
nowadays
there
are
more
and
more
ways
to
deploy
the
net
apps
in
general.
So
it's
very
good
that
you
bring
those
up
and
feel
free
to
add
the
comments
and
links
on
the
review
or
via
issues.
So
we
can
start
to
make
those
cases
kind
of
concrete
in
concreting
our
road
map.
L
You
know
so
at
first,
because
we
are
trying
to
to
get
a
release
out
by
the
time
of
dot
net
six,
I'm
sure
we
are
not
going
to
be
able
to
address
all
of
them,
but
we
we
should
be
kind
of
at
least
half
down
on
the
radar
so
down
the
line
we
can
really
handle.
All
of
those
you
know
yes,.
M
So
what
is
the
plan
here
like
when
dotnet
gets
released
in
november?
So
I
don't
think
we
have
like
a
lot
of
time
also
here.
So
it's
a
plan
to
get
the
kind
of
beta
done
by
that
time,
or
is
the
plan
to
get
the
complete
implementation.
L
No,
the
plan
is
to
have
a
beta
by
the
time
of
net
six
and
that
beta
in
a
sense.
What
we
are
trimming
for
this
release
is
actually
the
number
of
instrumentations
themselves
and
try
to
focus
on
the
infrastructure
that
we
need.
So
we
basically
want
to
be
able
to
handle
the
the
main
a
few
deployment
scenarios
and
have
the
auto
instrumentation
be
able
to
inject
the
sdk
inject
bytecode
instrumentation
inject.
What
I'm
calling
calling
source
instrumentations
and
prove
that
that
is
working.
That's
our
goal
for
this
release.
L
You
know,
then
we
we
need
to
expand
the
deployment
cases
and
also
add
a
bunch
of
instrumentations,
because
that
there
is
a
bunch
of
libraries
that
don't
offer
activity
to
our
achieved
source
that
we
could
do
via
source
instrumentation
and
for
those
libraries
we
have
to
bring
upstream
already
has
a
large
set
of
that.
But
probably
we
need
to
bring
what
upstream
has
and
also
implement
some
stuff
that,
for
instance,
some
other
vendors
also
implemented.
L
So
you
want
to
bring
all
of
that
to
finally
eventually
claim
claim
our
official
release
got
it.
L
Yeah,
so
please,
if,
if
you
can
I
I
we
have
the
recording,
I
can
revisit
that.
But
if
you
already
have
the
case,
you
can
put
those
in
the
in
the
review
of
the
pr
or
open
an
issue
on
the
repo
and
we
organize
on
that
to
to
put
on
the
road
map
those
cases
you
know
and
how
we
are
going
to
work
to
to
solve
them.
M
Definitely
paulo
I'm
going
to
get
that
done
and
also.
I
have
a
question
next
question:
it's
not
related
to
this
year.
I
just
looked
at
a
few
of
the
samples
in
the
repo,
so
all
of
them
has
most
of
the
examples.
Has
the
open,
telemetry
sdk
like
referenced
as
a
package
in
them
so
by
november.
I
expect
that
we
don't.
We
will
not
have
a
package
reference
in
the
sample
app
and
expect
auto,
like
this
instrumentation,
to
cover
that
space
right.
That's
what
we
are
heading
towards.
L
But
that's
kind
of
the
only
part
of
the
work
around
that
we
are
proposing
right
now
to
deal
with
that
just
work
for
applications
at
build
time,
even
if
they
don't
use
directly,
we
are
asking
them
to
add
a
reference.
You
know.
A
L
To
the
package,
which
gets
me
to
another
thing
that
we
should
be
doing-
and
I
think
actually
zac
did
this
for
upstream-
is
to
add
new
get
package
to
as
a
deployment
mechanism
for
the
the
clr
profiler
itself.
We
are
not
concerned
about
having
a
new
get
package
for
people
to
use
in
the
apis,
okay,
but
have
a
new
get
package
to
deploy
the
profiler
itself,
because
I
I'm
thinking
with
that.
We
can
solve
both
problems,
both
problems.
We
can
solve
two
problems.
M
Okay,
the
reason
why
I'm
asking
is
when
we
say
like
normally
when
we
come
to
a
concept
of
auto
instrumentation,
all
we
say
is
a
customer.
You
bring
an
app
and
just
click
a
button
and
we
will
start
collecting
telemetry
and
sending
it
to
the
service.
So
in
our
case
the
services
are
going
to
be
different.
M
Like
that,
that's
the
experience
we
need
to
give.
So
if
we
are
going
to
ask
like
a
customer
to
include
a
new
gate
or
any
other
reference,
I
kind
of
feel
that
we
are
breaking
that
auto
instrumentation.
So
we
are
asking
an
additional
work
for
the
customer
asking
him
to
have
a
built-in
dependency.
I
completely
agree
that
we
are
not
asking
him
to
change
the
code,
but
still
there
is
a
build
dependency.
M
We
are
putting
on
it
saying
that
hey
you
bring
the
package
with
your
app
that
we
will
take
care
of
enabling
it
internally
with
through
reflection
or
whatever
it
means,
but
this
like
this
is
something
we
need
to
think
on
a
longer
run
we
could
avoid
it.
All
customer
need
to
do
is
just
click
on
like
some
button
stay
on
and
then
we
should
have
it.
So
that's
a
kind
of
one
implementation
we
did
recently
through
startup
hook,
for
example
like
what
I
do
is
I
do.
M
M
That's
it
when
the
moment
they
accept
that
environment
variable
the
telemetrics
will
start
flowing
if
they
re-run
that
app,
the
telemetries
will
start
flowing
from
that
app,
so
it
seamlessly
works
with
both
windows
like
and
linux.
So
I
feel
like
we.
We
should
try
and
achieve
something
like
that.
I
understand
it
cannot
be
done
on
the
day
one
we
can
go
by
one
step
at
a
time.
This
is
one
of
the
proposal
I'm
going
to
propose
it.
M
Even
if
I'm
going
to
write
an
issue
that
I
have
a
plan
to
propose
that
here.
L
Yeah,
no,
we
are
aware
we
really
wanted
to
have
as
you
describe
it,
really
zero
thoughts,
because
zero
touch
projects
and
zero
touch
source.
L
We
really
wanna
have
that,
but
what
is
being
struggling
with
is
kind
of.
If
you
wait
to
have
that,
we
don't
get
started
on
the
project,
we
don't
release
the
project,
so
we
are
trying
to
kind
of
lower
the
requirements
that
we
are
subjecting
us
to.
L
So
we
can
have
a
release
that
okay,
it
doesn't
work.
What
we
are
calling
devops
scenario,
people
that
don't
have
access
at
build
time
chains.
You
know
we
are
aware
of
that,
but
we
do
agree.
Ideally,
we
wanna
kind
of
minimize
any
changes
and
we
wanna
people
to
be
able
kind
of.
Oh,
they
don't
have
access
to
the
build.
They
have
access
only
to
the
application
itself.
We
do
wanna
cover
that,
so
we
are
really
really
interested
in
seeing
the
solution
that
we
are.
L
You
are
working
with,
but
we
at
the
same
time
we
don't
want
to
wait
kind
of.
Let's
have
that,
so
we
can
work
on
the
instrumentation,
so
we
can
work
on
the
other
parts
you
know.
So
I
think
actually
we
can
move
this
in
in
these
two
fronts.
L
We
can
have
a
kind
of
a
group
working
with
you
on
this
goal
of
really
being
zero
touch
and
not
depending
on
any
build
time,
changes
or
anything
and
also
the
other
part
working
on
the
instrumentations
on
getting
the
semantic
conventions
from
open
limit,
telemetry
and
everything
you
know
so,
but
just
should
be
a
hundred
percent
clear
yeah.
That's
the
the
end
game
that
we
see
for
us
down.
The
road
is
kind
of
trying
to
get
to
that
point
that
we
really
don't
even
need
change
to
the
project.
L
You
know
so
I
got
it
yeah,
so
we'll
be
very,
very
interested
if
you
could
do
eventually
down
the
road
two
weeks
three
weeks,
one
week
whenever
you
can,
if
you
can
show
to
us
or
or
send
link
to
us
that
we
can
look
at
this
yes
100.
M
I'll
try
to
build
some
like
a
simple
demos.
Next
week,
like
whatever
I
explained,
like
probably
just
a
command
line,
I
won't
be
able
to
show
the
real
code
that
is
present
now,
but
I
need
to.
I
can
write
some
demos
and
I
can
demonstrate
next
time
or
when
I
join.
L
M
Sure
this
is
what
I'm
going.
I
don't
know
whether
I'll
be
able
to
make
it
next
week.
Next
week
I
have
a
conflict,
maybe.
L
M
A
week
after
that,
I
will
be
able
to
join
yeah.
This
is
what
I'm
planning
just
show
the
demo
on
the
startup
hook
and
additional
lives.
M
Okay,
that's
what
I'm
going
to
do
then
yeah,
so
I
will
ensure
that,
like
everyone,
whoever
is
like
contributing
to
it
is
a
part
of
it
in
that
meeting,
then
only
it
makes
sense
to
show
it
in
that
meeting,
if
not
like,
taking
a
look
at
the
demo
also
like
recording.
Also,
if
you
have
a
question,
it's
going
to
be
difficult
to
get
that
sorted
out,
so
we
will
ensure
that
every
one
of
us
present
when
doing
that,
but.
L
All
right,
then
I
I
I
think
this
sounds
very
promising
so
and
I
I'm
really
with
that
in
the
back
of
my
mind,
but
I.
M
M
L
Sounds
very
good
sounds
very
good
all
right
on
those
exciting
notes.
Does
anyone
want
to
add
something.
N
Yeah,
I
was
looking
at
the
start
of
hope
that
it's
like
supported
from
dot
net
core
3
plus,
but
I
guess
that
you
can
still
deploy
net
core
2
and
2.1
to
the
azure.
So
how
to
manage
for
these
applications.
M
So
like
doctorate
code,
2.01
will
go
out
of
support
and
yeah.
It
already
went
out
of
support
by
the
time
like
21st
of
august
statement
of
support,
ipv,
so
no
dotnet
core
to
any
2.2,
0,
2.1
or
2.2.
Nothing
is
supported
as
of
now,
so
we
can.
We
need
to
like,
at
this
point
safely
ignore
and
move
on
to
the
latest
one.
M
So
that's
the
approach
we
have
taken,
but
in
case,
if
we
want
to
support
that
there
is
a
reserve
way
like
additional
tips,
which
I
spoke
about,
that
and
the
runtime
store
additional
tips
and
runtime
stories
which
we
could
utilize
to
support
those
space
and
even
though,
like
the
article
says
it
has
started
supporting
from
3.1
2.2
is
was
supported.
So
I
just
realized
that
when
working
on
it,
it's
not
documented.
I
asked
them
to
update
that
so
yeah,
but
we
can
rely
on
that.
M
But
the
only
thing
is
that
we
are
going
to
leave
out
the
self-contained
space.
I
think
that
is
fine
dot
net
core
2.
N
Okay,
I
was
thinking
like
that.
If
a
customer
is
like
using
2.1,
do
you
restrict
to
deploy
to
azure
no.
M
For
example,
like
in
azure
like
we
don't
allow
them
to
create
2.1
apps,
but
they
can
create
a
3.1
app
and
deploy
2.1,
so
we
cannot
stop
them
doing
that
so
that
that's
what
happens
in
like
azure
and
again,
there
are
a
lot
of
apps
already
deployed,
which
is
of
version
2.1.
We
cannot
like
go
and
say
all
of
a
sudden
immediately
just
move
on,
if
not
I'm
going
to
shut
down
your
apps,
so
that
will
never
happen.
So
we
need
to
support
that
space
yeah.
N
L
Yeah
one
thing
that
I'll
say
is
that
for
for
better
for
worst,
typically,
the
vendors
have
solutions
for
these
download
versions
is
old
versions
in
that
same
idea
of
kind
of
trying
to
limp
the
scope,
and
also
because
the
sdk
are
red
kind
of
restricts.
What
it
supports
in
the
first
in
the
first
in
this
target
release
that
we're
gonna
do
for
the
same
time
of
dot
net
six,
I
think,
basically,
whatever
the
sdk
takes
as
the
minimum
requirements
we
have
to
follow.
You
know.
L
Yes,
yes-
and
this
is
a
let's
say,
a
limitation
that
we
are
willing
to
take
in
in
light
of
reusing
all
the
code
that
goes
with
the
sdk
and
the
exporters
and
the
processors
our
stats.
You
know
we
are
aware
of
that,
but
is
a
is
a
limitation
that
we
are
willing
to
take.
L
All
right,
very
good
conversation.
Let's
give
that
silence
so
we'll
be
sure
that
nobody
had
any
ideas
or
questions.