►
From YouTube: 2022-11-01 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
So,
of
course,
maybe
you
can
start
sharing
your
screen
before
I
leave
it
for
and
I
think
I'll
mentioned.
He
would
join
through
okay.
E
D
That
I
think
has
stemmed
from
this
notion
that,
like
oh,
you
know,
we
don't
we
should
we
should
avoid
incomplete
traces
and
so
on,
but
I
don't
think
that's
really
the
the
way
things
are
designed.
I
think
that
incomplete
traces
are
just
kind
of
a
fact
of
life,
depending
on
how
you
have
things
configured
like
sampling
and
so
on.
So
in
a
nutshell,
I
think
that.
D
B
Like
thing
is
like,
maybe
like
this
from
like
1.0,
so
this
might
be
a
like
perf
affecting
change
for
people
who
were
lying
on
this
Behavior.
So
we
could
easily
create
this
as
a
like
bug,
which
we
are
now
addressing.
A
But
this
do
have
the
impact
on
people
who
are
relying
on
such
samples.
They
know
that
only
if
it's
a
root
they
end
up
creating
the
activity
on
the
Heap,
otherwise
it
will
be
null
would
know.
So
that's
the
only
concern,
but.
A
B
Standpoint,
and
also
from
the
the
only
the
incorrectness
or
incompleteness
of
the
trace
is.
A
Not
really
a
something
which
we
can
help
with,
because
if
they
have
a
sampler
which
makes
different
decision
for
different
traits
a
difference
plan
in
the
same
Trace,
then
it's
yeah
I,
said
I
said
it's
just
a
reality
like.
If
they
do
a
something
like
that,
then
they
will
have
trouble
sleep.
You
cannot
do
anything
about
it.
Passing
the
EOG
Thunder
would
be
the
rendered
to
waistband,
which
is
nowhere
to
be
found.
It's
equally
there
issue,
I,
don't
think
we
can
do
anything
about
the
data.
A
So
the
only
question
is
like:
how
do
we
message
this
so
that
we
want
to
surprise
a
lot
of
people
with
the
increased
amount
of
activities
which
they
are
allocating
so
which
we
are
going
to
allocate?
But
if
we
must
display.
A
E
D
D
C
B
Hey,
can
you
hear
now.
B
So
I
need
to
figure
out
like
what's
wrong,
with
zoom
I,
just
updated
in
my
desktop
like
earlier
today,
yeah
but
yeah,
now
I'm
from
phone
again
so
yeah.
So
what
I
was
saying
is
I
generally
agree
with
the
change
we
we
may
be
like
taking
some
people
by
surprise,
with
the
amount
of
increased
activity
allocation
on
the
Heap.
People
might
have
used
to
the
idea
that
we
won't
be
creating
activity
unless
it's
a
route.
B
D
Yeah
and
speaking
with
Mike
about
this
a
little
bit,
you
know
one
suggestion
he
brought
up
was
I.
Think
you
kind
of
alluded
to
it.
A
feature
flag
that
enabled
this,
but
I
think
that
if
we
did
have
any
notion
of
that
that
it
should
be
a
feature
that
is
off
by
default,
that
is
default
should
be
follow
the
spec,
and
then
you
know
for
the
individuals
who
we
may
surprise
we
can
say
well,
you
can
turn
this
on
and
get
the
old
Behavior
or
something
but
I
don't
know.
B
Only
reason
is
like
if
you
are
going
to
merge
this
now,
like
we
only
have
like
very
few
days
before
we
call
it
stable,
so
we
may
not
have
enough
time
to
gather
feedback
so
that
or
alternately
we
can
just
delete
for
like
one
dot
post
1.4
then
ship
it
in
the
betas
and
if
no
one
objects
will
just
make
it
part
of
the
stable
and
if
people
complaints
then
we'll
introduce
a
flag
as
the
same
time
as
we
make
it
stable
in
1.5,
the
like
we
are
able
to
like
go
like
from
release
candidate
beta
and
stable
by
end
of
this
month.
B
So
we
may
not
get
enough
feedback.
It's
not
like
I,
don't
have
a
strong
pushback
against
it,
because
it's
something
we
suspect
very
clearly
called
out.
I
was
part
of
the
discussion
as
well.
Now,
I
did
not
regret
like
why
we
decided
to
do
it.
The
other
way
yeah,
but
we
did
discuss
this
I.
Think
Paulo
is
the
one
who
implemented
from
that
instrumentation.
We
did
discuss
this
in
one
of
the
PRS,
but
maybe
like
we
decided
we'll
come
back
to
it
and
we
never
came
back.
B
So
yeah
I
was
involved
with
Christian
when
he
made
that
the
spec
proposal
to
do
what
we
say,
but
the
the
technical
committee
decided
against
it
and
decided
to
create
the
span
always
so
yeah
I
think
Christian
already
mentioned
that
in
his
when
he
opened
the
issue
in
our
report.
So
I
generally
think
it's
okay,
given
that
the
species
asking
for
it
and
every
other
language
is
implementing
it.
That
way.
D
B
D
Yeah
I
think
that
sounds
like
a
plan,
so
I'll
probably
close
the
pr
for
now
I'll.
You
know
it
needs
some
work
anyways,
you
know
tests
need
to
be
fixed
up
and
so
on
so
I'll
shelve
it
for
now,
but
we'll
bring
it
back
after.
A
E
G
G
How
we
could
fix
our
API
so
that
we
avoid
the
weird
scenarios
we've
kind
of
created,
so
what
this
PR
does
is
just
make
everything
part
of
the
public.
Api
puts
it
on
the
users
to
owed
to
the
right
things.
So
we'll
I'll
update
the
documentation.
I
have
comments.
You
know
in
the
code
itself
to
kind
of
tell
you
what's
firing,
but
it's
kind
of
pushing
it
on
to
the
users.
That's
the
kind
of
downside
of
this.
B
Yeah
I
think
I
generally
agree.
I,
don't
have
any
concerns
moving
forward
with
this
one.
So
is
there
any
other
instrumentation
which
we
own
in
the
main
triple
which
has
the
same
challenge?
B
G
B
There
are
like
few
subtle
things
already
in
the
secret
instrumentation,
even
though
it's
applicable
I
mean
even
though
it's
available
like
compiler
wise
you'll,
see
it
in
the
API.
It
won't
just
fire
in
the
so
I'm
trying
to
find
like
what
exactly.
That
was
because,
when,
like
a
person
who
contributed
this,
he
says
it's
very
complex.
B
There
is
no
way
you
can
like
make
it
very
consistent
because
of
the
way
system.data
and
Microsoft
data
varies,
and
also
the
variation
between.net
framework
and
net
core.
So
there
were
like
other
issues,
but
at
least
let's
do
the
thing
make
it
to
make
it
consistent
with
HTTP
client.
Have
all
the
apis
uniform
and
like
document
that
this
particular
thing
won't
be
fired
for
XYZ
Frameworks.
A
G
Sure,
from
what
I
remember
it's
basically
on
that
framework,
when
The
Listener
or
the
source
fires
it
doesn't
give
you
like
the
raw
SQL
command.
It
just
gives
you
like
the
text,
so
you
don't
know
if
it
was
a
start
procedure.
If
it
was
a
text
command,
it
just
doesn't,
doesn't
give
you
enough
to
do
all
the
useful
things
that
we
want
to
do.
B
Okay,
things
like
yeah,
please,
we
will
be
consistent
in
terms
of
what
we
expose
to
the
public.
So
let's
at
least
get
that
part
going
cool,
okay,
yeah
I
think
we
I
think
the
there
were
like
other
one,
more
PR,
which
was
doing
subsimilar
breaking
change.
I,
don't
think
we
added
it
to
the
agenda.
So
maybe
can
you
go
to
the
open
PR
one
where
we
considered
the
return
type
for
filter
being
changed.
F
B
Like
while
we
are
like
at
it
like,
please
comment
on
this
one
as
well,
I
think
it.
My
only
concern
is
like
what
do
we
name
it
like
I,
didn't
have
a
good
naming
suggestion,
foreign.
B
But
yeah,
so
we
don't
need
to
discuss
it
right
now.
I
just
meant
like
please
review
this
one
as
well,
along
with
the
other
one,
so
we
can
include
all
of
them
in
one
release
which
we
we
should
try
to
do
it
like
this
week,
so
that
we'll
have
enough
time
to
gather
feedback
in
the
next
two
weeks.
B
Would
create
their
own
options,
so
if
they
want
to
do
like
something
more
than
the
the
collect
versus
probe,
then
they
can.
C
B
Referred
to
yeah,
so
the
question
was
like:
should
we
keep
the
enum
for
return
type?
Should
we
keep
it
in
a
common
place
and
have
all
of
them
copy
or
prefer
it
or
like
everyone,
creates
their
own
thing
like
call
it
like
yeah?
What
what
we
should
see
in
this
PR,
it
very
specific
to
asp.net,
core
instrumentation
filter
result
type
are
supposed
to
click
Sim.
D
F
D
You
know
to
conform
to
our
patterns
versus
having
to
basically
reinvent
everything.
G
D
Related
to
that
one
thing:
that's
been
kind
of
running
in
the
back
of
my
mind
that
we
haven't
really
talked
about
I,
don't
think
Java
has
an
API
specifically
for
instrumentation
authors.
It's
it's
basically
an
instrumentation
API
that
allows
for
easy.
G
D
Can
stay
inconsistent
with
other
types
of
instrumentation
so
like
in
this
case?
Asp.Net
core
is
a
web
framework.
Their
instrumentation
API
has
the
ability
to
create,
like
you
know,
a
server
side,
HTTP
span
and
it
takes.
You
know
all
the
it's
Java.
So
there's
probably
a
builder
pattern
or
something
for
building
up
one
of
these
things
and
it
it's.
It
makes
it
so
that
it's
really
easy
to
follow
the
semantic
conventions
you
know
as
it
might
intersect
with.
You
know
what
we've
got
here
with
like
filter
and
Rich.
D
B
F
B
That's
different,
the
sumatic
conventions
being
publicly
say
separating
the
instrumental
API
which
python
has
is
just
to
enable
attaching
to
the
provider
like
easily
so.
H
On
the
same
thing
on
the
same
theme
and
that
what
we're
trying
to
do
is
standardize
the
way
that
people
create
stuff
and
until
recently
we
didn't
look
at
the
the
punch,
pushing
the
semantic
conventions
out,
but
we're
starting
to
do
that.
There's
a
whole
theme
there
around
standardization
of
spam
names
and
the
structure
of
spans
and
that
kind
of
stuff.
So
I
think
you
followed
on
the
same
thing.
Yeah.
D
Absolutely
it's
definitely
all
part
of
like
the
same
kind
of
theme,
the
the
semantic
conventions
public
package
is
kind
of
like
the
base
Foundation.
It
doesn't
necessarily
Drive
the
consistency,
but
it's
an
important
foundational
piece
to
you
know
the
concept
of
like
an
API
that
would
then
use
that
Drive.
The
consistency.
B
D
B
Can
we
keep
this
in
API
then
like?
Can
we
keep
this
enum
as
part
of
the
API.
C
B
E
G
B
I
mean
eventually
like.
If
you
want
to
add
more
things,
then
it
makes
sense.
But
as
of
today,
it's
yeah,
it's
just
the
CNM,
so
maybe
we'll
start
with
letting
each
instrumentation
Library
Define
it
themselves.
G
Because,
like
imagine,
it
was
a
shared
thing
and
then
somebody
wanted
to
do
like
a
third.
Would
we
force
a
breaking
change
into
their
instrumentation?
Make
them
Define
their
own
with
the
third
thing,
or
we
would
allow
the
third
to
go
into
the
shared,
even
though
that
option
might
not
make
sense
across
the
board
everywhere
that
shared
thing
is
used.
C
D
The
third
option
might
be
I
mean
this
filter
is
very
similar
to
sampling,
so
it's
kind
of
like
a
yes
or
no,
but
are
there
other
circumstances
where
you
think
a
third
option
might
be
a
thing.
G
G
D
Well,
I
agree
that
it's
probably
a
a
premature
generalization
to
just
shove
one
enum
into
a
package:
I,
don't
I,
don't
think
that
makes
sense
either
and
it
also
I
guess
one
of
the
reasons
why
I
I
don't
really
know
what
an
instrumentation
API
would
look
like
for
us
is
one
of
the
things
we
talked
about.
I.
Think
last
week
was
I.
F
D
It
was
in
relationship
to
your
PR,
the
unify
the
HTTP
client.
You
know
one
one
idea
that
we
tossed
out
was
like.
If
we
had
a
wrapper,
you
know
like
a
common
rapper
that
all
HTTP
and
we
were
concerned
about
like
allocations
of
that,
but
I
think
that
that's
a
con.
They
have,
you
know,
increased
allocations
and
so
on,
but
a
pro
would
be.
It
would
be
something
that
would
work
well
with
like
one
of
these
instrumentation
apis
like
any
any
HTTP
client
kind
of
Library
out.
D
There
could
use
an
API
to
generate
those
spans,
but
if
we're
concerned
about
allocations,
Then
I,
then
I
think
something
maybe
API
like
that
might
be
not
feasible
in
the
future,
meaning
that
our
API
would
always
just
be
like
pretty
anemic,
with
like
these
enums
and
so
on.
So
like
I
I,
don't
know
if
an
instrumentation
API
is
in
our
future
or
not
I
think
it
definitely
warrants
some
some
deeper
thinking
before
we
jump
in
there
and
do.
D
C
C
Like
these
kind
of
files,
just
the
Handler
and
all
of
these,
like
so
multiple
libraries
just
linked
to
them.
So
if
you
just
had
an
enum
file
here
and
we
could
have
people
linked
to
it,
but
I
think
it's
probably
fine,
like
maybe
instrumentation
Library
can
just
have
their
own
email,
because
when
they
have
to
extend,
if
at
all,
they
do
I
don't
know
in
which
cases
they
would
have
to.
G
G
So
when
you
try
to
code
it
you're
going
to
get
ambiguous
warnings
and
errors.
Saying
I,
don't
know
which
one
you're
trying
to
use
you'll
have
to
fully
qualify
everything
but
they're
all
in
the
same
namespace.
So
you
actually
have
to
like
qualify
it
by
assembly
where
you
have
to
Alias
things.
It's
super
nasty,
so
I
wouldn't
wouldn't
recommend
going
that
route.
G
G
B
B
H
C
C
F
G
G
Auto
configuration
open
real,
quick,
then
that
relates
to
PR.
G
So
we
got
this
one
a
while
back
from
like
the
auto
instrumentation
team
and
I
basically
asked
them
to
wait
until
I
was
done
with,
like
the
eye
configuration
environment
variable
stuff,
so
that
happened,
they've
kind
of
worked
on
it
since
then,
and
they're
asking
like
okay.
What
should
we
do?
If
you
open
the
files
changed
it's
adding
a
lot
of
API
in
SDK.
It's
creating
this
kind
of
architecture
for
sampler
detectors
which
work
a
lot
like
the
resource
detectors.
G
I,
don't
think!
That's
a
spec
fan
I,
don't
think
in
the
spec
there's
anything
called
like
a
sampler
detector.
It's
just
kind
of
new.
There
are
the
environment
variables
that
Define
like
what
sample
or
the
SDK
is
going
to
use.
They're
all
are
also
variables
that
control
what
exporter
is
going
to
be
used.
So
if
we
do
this,
there
will
probably
also
be
export
or
detectors.
There's
this
whole
kind
of
black
hole
of
features
that
we
need
to
add.
So
Cedar
has
a
comment
on
here,
I
kind
of
agree
with
like
do.
G
We
really
need
all
of
this
stuff
in
SDK.
It's
a
lot
of
artifacts.
It's
a
lot
of
API
service.
One
of
the
things
Alan
and
I
have
been
talking
about
on
and
off
is
Java
has
some
kind
of
Auto
configuration
package.
There
is
also
stuff
going
on
in
the
spec
where
we
might
get
like
a
yaml
file.
That's
a
standard
way
of
representing,
like
open
Telemetry
configuration
that,
presumably
all
languages
would
be
able
to
consume
and
like
configure
themselves
so
we've
kind
of
been
talking
about
like.
G
Could
we
create
an
auto
configuration
package
that
owns
that
world,
that
side
of
things
so
I
kind
of
looked
at
this
PR
and
then
I
created
that
draft
of
what
that
might
look
like
so
I
created
an
auto
configuration
assembly
and
then
in
there
it
exposes
the
sampler
detectors.
It
exposes
exporter
detector,
it
consumes
those
environment
variables,
it's
kind
of
laying
the
groundwork.
For
some
of
these
things.
G
H
G
I
would
expect
Auto
instrumentation
to
always
use
Auto
configuration
they
would
just
today
they
pushed
the
SDK
reference.
I
would
expect
them
just
to
push
this
reference
along
with
that,
and
then
they
would
use
this
to
configure
themselves
in
the
same
way.
They'd
use
this
like
detector
API,
so
they
would
just
use
this
package
in
addition,
or
with
the
SDK,
to
configure
everything,
but
you
wouldn't
necessarily
strictly
need
to
use
Autumn
instrumentation,
you
could
just
consume
Auto
configuration,
you
know
in
your
hosting
application
and
it
would
work
just
as
well
it
just
wouldn't.
G
One
of
the
concerns
that
this
doesn't
tackle
that
auto
instrumentation
must
tackle
is
how
do
you
acquire
binaries
and
inject
them?
So
this
wouldn't
do
that.
So,
if
you
look
go
back
to
the
description,
so
if
you
want
to
use
like
the
Jaeger
detector
with
this
package,
you
would
have
to
add
a
reference
to
the
Jaeger
Auto
configuration
and
that
would
give
you
the
detect,
Jaeger
exporter
extension.
G
So
in
this
world,
in
the
repo
world,
the
SDK
world,
you
still
have
to
manually
reference
everything
and
make
sure
that
if
you
want
to
use
Jaeger,
if
you
want
to
use
otlp,
if
you
want
to
use
Zipkin,
those
dlls
must
be
present
and
you
have
to
hook
up
their
detectors.
Auto
instrumentation
would
take
it
a
step
further
and
say
none
of
that's
present
at
all
and
we're
going
to
go,
download
or
somehow
retrieve
it
all
and
hook
it
up
at
runtime,
so
that
it
calls
everything
and
it
just
works.
You
know
Auto.
H
Magically
I
suppose
we
want
to
be
making
sure
we
have
a
chat
with
the
the
auto
instrumentation
guys
about
what
the
shape
of
this
looks
like,
because
we'd
be
expecting
them
to
use
it
as
a
primary
candidate
for
what
they're
doing
so,
all
the
all
the
variables
all
the
name
naming
conventions.
Everything
would
need
to
map.
H
I
mean
one
of
the
things
is
I
I
would
I
would
probably
take
this
as
a
all
of
the
open,
Telemetry
dot.
Libraries
should
expose
something
with
the
same
sort
of
configuration
which
would
allow
you
to
say
yes
do
auto
configuration
go,
do
some
kind
of
reflection
over
all
of
the
libraries
find
something
that
is
a
type
that
implements
the
particular
interface
and
then
you
don't
need
to
go
in
and
say,
add
Jaeger,
providing
you've
added
the
Jaeger
package
and
said:
do
auto
instrumentation.
G
It's
definitely
possible
I,
don't
know
if
it's
something
we
want
to
get
into,
because
I
think
it's
also
an
attack
surface.
If
you're
just
combing
through
assemblies.
Looking
for
interfaces,
you
have
to
load
those
things
so
I'm
not
sure
we'd
have
to
do
some
research
on
the
safety
in
that
world,
but.
H
G
If
you
look
at
the,
if
you
go,
the
files
changed,
I
am
defining
those
interfaces,
so
it
would
be
possible
to
do
such
a
thing
like
there's,
I,
sampler
detector,
there's
I
trace
explorator
detector.
Those
are
what
the
libraries
are
implementing.
So
there's
like
a
Jaeger
Trace
export
detector.
So
you
could
do
that.
You
could
look
through
the
assemblies
that
are
present
and
find
any
type.
You
know
that
is
assignable
from
the
interfaces
and
do
it
all
completely
dynamically.
It
is
possible.
H
Yeah
I
mean
that's
as
a
as
a
person
using
it.
That's
what
I
would
expect
rather
than
having
to
say,
add
the
library
and
then
add
the
line
of
code.
That
says,
use
the
library
just
being
able
to
say
right,
add
the
package
great
and
it
should
Auto
configure
itself.
I
mean
that's
kind
of
Holy,
Grail,
I
suppose,
from
an
implementer
perspective,.
G
G
I
have
I
haven't
been
too
involved
in
it.
I'm
just
talking
to
Alan
I
think
Alan's,
a
bit
more
involved
in
in
Jack
at
New
Relic.
B
Yes,
there
was,
there
was
like
a
specific
comment.
I
found
like
a
few
days
back.
It
says
there
is
an
overall
effort
to
figure
out
the
configuration
as
a
whole
and
because
of
that,
any
new
environmental
variables
are
like
prohibited,
like
whatever
is
there
in
this
packet
remains,
but
they
are
prohibiting
adding
anything
new
to
the
environment
variable
configuration
because
they
are
overall
figuring
out
what
to
do
with
the
configuration
tutorial.
B
So
I
mean
it's
possible
that
the
spec
would
come
out
and
say
you
should
do
this
and
this
so
we
may
get
like
some
input
from
there.
I
mean,
or
we
could
work
closely
with
the
spec
and
be
one
of
the
languages
which
prototypes
this
I'm.
Okay,
either
way
like.
Since
this
is
a
separate
package,
we
don't
need
to.
Like
I
mean
we
can,
we
can
have
much
more
flexibility
because
we
can
add
more
things
more
dependencies
and
like
still
call
it
like
experimental,
because
it's
not
the
or
SDK,
probably.
B
I
will
paste
the
issue
from
the
spec
to
the
chat.
Let
me
just
do
it
right
now,
yeah,
if
you
refresh
the
meeting
notes,
you
can
find
the
link
which
I
added
it's
spec,
issue2891.
G
So
what
I'm
imagining
is,
if
we
go
back
to
the
pr
that
all
those
codes
where
it
says
like
use,
Auto
configuration
so
basically
the
entry
point
into
that
world
would
understand
the
specs
configuration
file.
So
one
of
the
things
that
would
do
is
when
you
light
up
Auto
configuration,
it
would
go
and
look
for
that
file.
Maybe
it
has
an
option.
You
tell
it
where
to
get
it
or
there's
an
environment
variable
reads:
the
file
consumes
it
and
then
it
says:
okay,
I
need
some
processors.
G
I
need
some
exporters,
then
what
it
will
do
is
it
will
just
call
these
extension
points
to
sort
of
orchestrate
the
Builder
as
if
you
coded
it.
So
it's
just
sort
of
telling
the
deal
of
what
you
know
to
add
to
the
pipeline
and
it
can
use
the
auto
configuration
detectors
and
artifacts.
So
to
me,
it
all
fits
in
nicely
to
what
we've
built,
but
I,
don't
know
until
we
go
and
actually
build
it.
It'll
be
it'll,
be
hard
to
say.
B
So,
what's
the
immediate
thing
which
is
blocking
the
auto
instrumentation
sick
I
am
trying
to
figure
out
what
was
the
motivation
for
adding
the
sampler
detectors
themselves,
like
what
part
is
missing
like
because
in
the
spec
for
environmental
variable,
there
is
a
spec
which
says
what
is
the
sampler
to
be
used?
So
can
we
just
use
the
environment
variable
and
configure
the
sampler
accordingly,
so
I'm
still
failing
to
understand
like
what?
What
was
the
motivation
behind
adding
a
new
detector
thing.
G
B
Yeah,
but
that
part
won't
be
anywhere
configurable
from
environmental
variable
anyway,
because
there
is
no
spec
written
or
written
on
how
how
to
configure
a
custom
sampler
using
environment.
That
part
is
not
there
in
the
spec.
It
only
explicitly
allows
like
four
or
five
values,
which
are
all
the
built-in
sub
same
with,
like
anything
like
xmlr,
also
or
the
exporter.
B
B
Because
the
primary
motivation
is
to
unblock
the
auto
instrumentation
efforts
right,
so
if
we
can
like
unblock
them
without
adding
a
new
configuration
story,
I
think
I
I
would
prefer
to
do
that,
but
I
think
oh
yeah
I
just
forgot
that
this
is
not
going
into
this
ticket.
This
is
a
separate
package,
so
no
harm
doing
that
as
well.
Okay,.
G
Yeah,
it
also
was
kind
of
a
nice
exercise
just
to
prove
out
the
the
dependency
injection
surface
works
and.
E
F
D
About
this,
a
note
about
the
stuff
that's
happening
at
the
spec.
It's
it's
super
super.
In
the
beginnings
of
of
things,
Jack
kind
of
kicked
off
the
conversations
and
I
missed
the
first
meeting,
but
he
he
had
a
meeting
with
a
small
group
of
folks
I
think
last
week
and
I'd.
Imagine
it's
probably
going
to
turn
into
a
more
formalized
working
group.
D
He
talked
with
me
about
it,
a
fair
amount
beforehand
as
well,
and
we
kind
of
bounced
around
ideas
and
he
met
with
these
other
folks,
and
they
too
want
to
kind
of
go
through
the
same
exercise,
kind
of
alone
kind
of
maybe
brainstorm,
some
different
structures
to
the
config
anyways.
So
there's
there's
a
lot
of
preliminary
conversations
going
on
and
I
think
that
the
need
for
dynamically
and.
D
An
SDK
based
off
of
like
a
file
or
something
is,
is
definitely
in
our
future,
so
I
think
it's
great
to
get.
B
So
one
question
like:
do
we
either
of
you
know
if
the
auto
instrumentation
is
waiting
for
us
to
ship
this
in
the
stable
or
they
are
okay
to
wait
or
they
are
okay?
To
take
this
temporary
or
like
extra
package,
do
we
know
like
plants,
maybe
like,
since
you
got
pink
by
them?
Do
you
know
what
what
they
are
waiting
for?
I.
G
Don't
know
exactly
I'll
reach
out
to
them.
If
you
look
at
the
little
thumbs
up,
I
think
that's
from
someone
on
auto
instrumentation,
so.
G
Did
ask
them
to
look
at
it
because
it's
sort
of
an
alternate
proposal
to
their
things
but
yeah
and
we'll
get
their
feedback
and
see
if
a
be
released
would
work
if
they're
hard,
blah
I'll
get
more
information.
We
can
talk
about
this
more.
D
F
E
G
G
It
wouldn't
be
that
useful
right,
there's
a
lot
of
stuff
in
contrib.
There's
a
lot
of
stuff
out
on
nougat.
You
kind
of
want
the
flexibility,
at
least
for
exporters.
I,
don't
know
if
anybody's
really
doing
custom
Samplers
but
day
one
but
I
feel
like
that
will
need
to
be
there
at
least
at
some
point.
Absolutely.
D
It's
very
similar
to
the
architecture
of
the
collector.
In
that
you
know
you
can
create
your
own
custom
receivers,
processors
exporters
and
refer
to
them
in
the
collector's,
the
animal
configuration
and
it
just
automatically.
You
know
if
it's
on
disk
it
instantiates
one
and
configures
it,
and
to
my
knowledge,
I
think
that
Alex
was
his
last
name.
Botan
Alex,
Bowden,
I,
think
from
The
Collector
group
is
involved
with
those
preliminary
discussions
and
he's
suggested
something
like
that.
D
Like
hey,
can
we
can
we
imagine
a
file
based
configuration,
that's
very
similar
to
the
collectors
and
is
very
dynamic
in
that
in
that
way
enable
to
consume
any
any
custom
components.
I.
C
F
C
So
for
the
traces
and
metrics
part
we
already
have
introduced
the
number
of
public
apis
to
get
the
TI
and
config
work
going,
and
we
should
review
them
before
one
dot
forward.
So
if
that's
not
going
to
be
possible
today,
maybe
in
the
next
meeting
we
should
do
it
and
I
think
plant
you're
already
working
on
writing
the
docs
to
use
those
apis.
C
B
Yeah
I
also
want
to
ask
like
we
should
try
to
do
a
release
the
beta
this
week,
so
that
we'll
have
an
opportunity
to
do
at
least
one
or
two
release
candidate
in
the
next
two
weeks.
B
Yeah
I
just
want
to
know
like
if
everyone
has
any
concern
with
doing
a
stable
by
number
30.
There
is
no
pressure
on
us
to
do
it.
We
can
do
it
in
December
or
we
can
even
do
it
on
January
but
like
it's,
it
would
be
nice
if
you
do
it
on
number
30
before
people
go
on
vacation.
B
The
most
important
thing
which
I
I
am
particularly
looking
for
is
the
dot
Net
7
support
like
we
need
to
have
tested
with
asp.net
core
7
that
we
continue
to
work
and
then
the
couple
of
new
things
which
we
added
for
metrics,
which
is
up
down
downtrend
Max,
which
should
have
been
there
in
the
very
first
release,
but
due
to
things
we
we
could
not
add
it
in
dot
net
six,
so
we
just
waited
so
so
that's
my
only
motivation
to
have
it
by
end
of
number,
but
if
there
are
things
which
we
are
not
confident,
we
can
consider
delaying
the
release
or
moving
things
or
like
whatever
else.
B
Everyone
agrees
to
for.
Let's
make
that
call
next
week
when
we
review
the
public
API,
hopefully
we'll
have
the
dogs
like
plants.
Are
you
you'll
have
some
top
here
right,
so
we
can
look
the
new
API
side
by
side
with
the
new
Dock
and
then
decide
if
this
looks
good,
let's
just
like
call
it
release
candidate
and
give
it
another
week
for
people
to
comment
and
then
call
it
stable
or
if
we
think
it's
too
early,
then
we
can
delay
it
for
a
few
more
weeks
as
well.
D
This
is
a
relatively
minor
point
in
my
opinion,
but
it
has
come
up
for
people
have
asked:
hey
you
know.net
core
3.1
doesn't
end
of
life
until
I
think
like
mid
November,
mid
December
and
we're
dropping
support
before
that
effectively.
D
B
Yeah
we
did
that
before
also
like.
We
did
stop
support
for
dotnet
461
in
November
2021,
but
the
actual
support
ended
only
in
like
February
2022,
so
we
ended
like
two
and
a
half
months
earlier,
so
we
do
have
like
some
history,
but
we
are
not
explicitly
blocking
anyone
from
using
it.
In.Net
core
3.1
right,
like
they'll,
get
the
warning.
They
can
suppress
it
and
move
on
right.
B
Yeah
I
think
it
should
be
like
a
very
less
concerning
thing
than
because
if
they
want
they
can
use
it
and
they
they
should
understand
that
they
are
already
online
supported
or
able
to
be
unsupported,
so
open,
Telemetry
is
just
not
tested
explicitly
in
that
framework.
So
I
think
it's
it's
a
very
reasonable
thing
for
us
to
do
as
well.
B
B
Yeah,
probably
like
we
should
be
given
a
lot
of
credit
for
supporting,
like
everything
which
dotnet
officially
supported
from
day
one
because
I
remember
like
when,
like
we
were
supporting
net
four
five,
two
onwards
and
netcore
2.1
onwards,
like
in
the
very
first
release.
But
if
you
look
at
other
popular
libraries
like
even
Azure
Zone
libraries
don't
support
like
didn't
support.net4614.9452,
we
looked
at
like
Prometheus
client.
They
only
had
an
extended
two
or
Target,
so
it
didn't
work
on
net
452..
B
So
we
were
like
much
more
liberal
in
supporting
everything
dot
net
officially
covered
so
I
think
we
have
some
good
reputation
already.
B
I
All
up
on
the
previous
discussion
with
auto
configuration
so
right
now
with
the
environment
variables
like
I,
want
to
say,
there's
like
lack
of
support,
for
instance,
for
like
Hotel
exporter
or
otlp
traces
endpoint,
as
opposed
to
excuse
me,
like
the
non-data
type
specific.
Do
we
envision
supporting
those
things
in
addition
to
whatever
is
on
the
horizon,
with
auto
configuration
or
like?
Does
that
question
make
sense.
B
Yeah,
whatever
is
already
the
spec
for
configuring
things
using
Android
variables,
we
should
be
supporting
it,
it's
just
that
we
did
it
as
a
low
priority
thing
until
Auto
instrumentation
folks
jumped
in
and
contributed
so
yeah
I
expect
like
everything
which
we
have
a
stable,
spec
or
but
at
least
a
Speculator.
We
should
cover
just
by
the
regular
environment.
Variable
we
already
supported
for
like
few
things.
B
Sampler
is
something
which
we
haven't
done,
so
we
should
be
doing
that
and
then
temporality
is
another
thing
we
haven't
done,
but
the
thing
is
we
won't
be
able
to
support
without
this
new
approach
is
the
ability
to
pick
the
exporter
itself
like
there
is
a
environment
variable
which
decides
what
exporter
you
want,
that
we
won't
be
able
to
do
right
now,
because
we
need
to
have
the
dependency
on
that
package
anyway.
B
So
that's
the
thing
which
will
be
unblocked
when
we
have
the
configuration
Mega
package,
but
anything
which
requires
like
plain
reading
in
ground,
variable,
passing
it
out
and
feeding
it
to
the
SDK
that
should
be
covered
even
without
this
extra
package
it
it
should
be
the
functionality
in
the
offered
by
the
core
SDK
itself.
Okay,.
I
B
A
B
Stay
heads
up
like
I'm,
adding
all
the
extra
stuff
to
the
repo,
but
none
of
them
would
be
exposed
to
public,
so
it
would
just
remain
in
internal
I'm,
just
working
to
implement
it
and
help
the
spec
get
stable
before
we
can
incorporate
it
in
our
like
1.5
really
so
you
can
look
at
it,
but
none
of
this
will
make
it
to
the
1.4
release
and.
G
D
Question
about
this
quick
question
about
that.
The
is
that
really
the
last
thing
to
your
knowledge
remaining
at
the
spec
level
is
just
more
more
languages.
Implementing.
B
It
I
think
that's
one
reason
because
I
believe
only
go
or
you
I
don't
even
know
whether
go
implemented
it,
but
only
Java
is
the
language
I
know
which
has
implemented
it.
So
I'll
have
to
reattend
The,
Matrix
or
spec
meeting
to
see
what
is
the
status,
but
this
is
something
which
we
pondered
from
like
last
year,
initially
already
so
we'll
anyway
have
to
get
to
it
yeah.
At
that
time
it
was
mentioned
that
at
least
two
or
three
languages
must
implement
it.
B
Before
we
can
mark
the
xmlr
feature
as
a
stable
thing,
yeah
and
I
I'll
be
going
very
slow.
I
I
will
do
the
initial
work
by
this
year,
but
I
don't
think
it
will
be
like
good
enough
from
a
puff
standpoint
until
next
year.
B
So
this
is
just
to
like
iron
out
issues,
because
we
need
to
figure
out
like
where
to
attach
it,
and
there
are
like
few
things
in
the
spec
itself,
which
I
expect
to
send
some
PRS
to
fixing
the
spec
itself
so
yeah.
It
won't
happen
like
in
this
month.
B
Okay,
I
would
only
be
working
like
for
another
three
weeks
and
then
I'm
taking
vacation,
so
I'll
be
back
on
January,
so
I'll
do
the
basic
groundwork,
keep
it
internal
and
then
come
back
on
Jan
and
continue
so
and
also
the
other
thing
which
Alan
you
might
also
work
like.
We
do
not
have
actual
customers
who
can
help
us
validate
because
most
back-ends
do
not
support
xmlrs
yet
so
we
may
need
like
more
time
to
violate
it.
D
B
Yeah,
so
Microsoft
also
has
the
same
trouble,
but
we
do
support
Prometheus
and
grafina,
which
has
this
feature,
but
it's
to
be
seen
like
how
it
lures
and
out,
but
anyway,
the
foundation
is
like
SDK
has
to
First
support
it,
so
people
how
to
implement
it
anyway,
yeah
yeah,
just
a
heads
up
like
I,
just
wanted
to.
Let
you
know
that
it's
not
for
like
1.4
consideration.
It's
only
for
post
1.4
release.