►
From YouTube: 2022-11-23 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
A
A
I
guess
we
can
start
Alan
and
Siege
or
out
this
week.
So
I
put
this
one
item
on
the
agenda.
I,
don't
think
it'll
take
much
time
so
just
wanted
to
discuss
it
before
we
get
into
the
config
di
changes
discussion.
A
So
in
the
contract
repo
there's
this
package
for
in
mass
transit
instrumentation
and
starting
the
the
latest
version,
which
is
eight.
We
don't
really
need
this
instrumentation
package
anymore.
The
users
just
have
to
add
a
source
and
the
activities
will
just
start
flowing
so
like
summer.
A
We
are
to
just
deprecate
to
just
remove
this,
the
entire
code
from
the
repo
and
just
wanted
to
like
get
people's
opinion
on
like
how
should
we
have
ever
removed
the
package
from
200
people
like
that
like
do
we
want
people
to
reference
the
code
or
like?
Is
it
just
or
do
we
just
like
go
forward
and
remove
it?.
C
Are
we
happy
that
there's
no
propagation
and
stuff
like
that
in
there
that's
still
required,
is
this
from
the
mass
transit
people.
A
Yeah
I
guess
originally
this
package
probably
was
written
from
someone
written
by
someone
from
the
mass
transit
team.
I,
don't
know
the
history
of
this
package,
but.
A
A
A
Yeah,
so
just
wanted
to
like
know,
if,
like
anyone,
has
any
opinion
on
like
keeping
this
or
because
with
this,
what
this
PR
does
right
now
is
it
deletes
all
the
project
files
it
retains
that
folder
and
that
folder
will
just
have
the
change
log
and
the
readme
file.
C
B
C
So,
essentially
remove
all
the
implementation
from
all
the
apis
leave
all
the
rest
of
it.
There
update
the
readme,
put
an
obsolete
on
stuff
and
then
because
otherwise
people
are
just
going
to
be
still
using
that
library
and
not
realizing.
D
A
A
Okay,
then
I
think
yeah,
we'll
just
have
the
changelog
and
read
me
and
we
can
get
rid
of
everything
else.
F
I
also
kind
of
think
it
would
be
nice
if
they
like,
directed
to
the
new
way
to
consume
the
data
like
if
they
have
I,
don't
know
like
the
mass
transit
docs.
That
show
how
to
do
that,
because,
like
there's
some
there's
some
stuff
in
the
readme
here
about
you
know,
like
example,
asp.net
core
information
instrumentation,
how
you
would
like
configure
things.
F
A
I
think
like
from
this
on
this
repo,
like
in
this
PR
this
they
have
added
a
note
saying
this
only
works
with
V7
and
earlier
with
V8
I
guess
we
can.
They
just
have
to
put
an
ad
source,
so
we
could
mention
that
and
I
haven't
checked
Mass
transit's
actual
repo.
So
maybe
they
mentioned
things
there
about
how
to
add
instrumentation.
G
F
They're
then
they're,
like
oh
I
gotta,
go
find
the
mass
transit
docs
and
then
they're
like
they
don't
know
where
to
look
to
find
that,
and
maybe
that's
a
lot
of
business,
be
in
the
business
of
maintaining.
You
know
like
that
relationship,
but
I
almost
feel
like,
because
this
was
here
at
one
point:
it
yeah.
It
makes
sense,
at
least
for,
like
the
V1
version
of
their
docs,
to
link
to
it.
A
Yeah
I
think
I
can
ask
the
the
mass
transit
maintainer
to
like
point
us
to
a
link
of
the
docs
and
then
DPR
author
can
just
add
them.
So.
A
A
B
C
H
So
if
an
instrumentation
package
wanted
to
utilize
the
dependency
injection
API
surface,
there's
different
things
in
there.
You
know
you
can
register
Services,
you
can
do
the
detach
style.
Probably
the
biggest
is
the
options
support
like
if
you
needed
an
options
class
for
your
instrumentation,
it's
nice
to
be
able
to
do
that
stuff.
H
So
we
were
investigating
was
what
else
could
we
do?
Could
we
move
some
of
it
to
a
different
Library,
so
the
instrumentation
could
depend
on
something
a
little
bit
less
than
the
full
SDK.
So
that's
sort
of
what
this
PR
is.
It
was
a
experiment
to
what
would
it
look
like
if
we
just
moved
the
fundamental
stuff,
so
this
moves
configure
services
and
configure
Builder,
and
then
it
also
adds
some
overloads
for
instrumentation
specifically,
so
this
new
package
depends
on
API
and
then
the
SDK
depends
on
this
new
package.
C
I,
don't
know
whether
I've
reached
my
limit
of
I
just
want
to
get
this
in
now
and
get
the
release
out.
C
It
feels
like
a
lot
of
moving
around
for
ideals,
sake.
A
Yeah,
like
I
since
I,
don't
think
the
EPA
is
going
to
be
changing
with
this.
It's
just
about
moving
around
things
and
since
most
of
the
work
is
already
done
in
this
PR
right,
Branch
I,
don't
think
this.
A
If
we
do
decide
to
go
forward
with
this
like
would
it
is
there's
still
a
lot
of
work
to
do
on
this
PR
lens.
C
Well,
shouldn't
we
I
mean
we're
gonna
have
to
RC
the
package.
Aren't
we.
C
H
I
think
the
plan
was
always
to
do
an
RC,
so
this
would
be
a
1.4.0
like
rc1.
That
would
sit
out
there
for
a
couple
weeks
and
then
1.4.0
would
go
stable.
That
would
be
SDK,
API,
there's
a
new
package
and
then
probably
shortly
thereafter
we
could
do
a
stable,
hosting
there's,
no
reason
we
couldn't
do
hosting
at
the
same
time.
I
just
don't
know
if
that
is
the
current
plan.
C
A
Yeah
I,
don't
think
we
would
need
to.
We
don't
have
to
spend
as
much
time
in
on
the
on
deciding
what
apis
you
want
to
offer,
because
I
think
that
discussion
is.
A
H
B
C
Oh
well,
I've
I've
got
a
week
at
home
this
week,
so
I
have
varying
amounts
of
time.
So,
if
you'd
like
some
usage
on
it,
if
it's
ready
enough,
I
can
have
a
bit
of
a
play.
H
Definitely
it's
it's
hard.
It's
it's!
A
cheat
just
to
kind
of
read
an
API
I
think
you
really
have
to
kind
of
code
against
it
to
really
get
an
idea
if
it
works.
So
some
of
this
I
asked
Anna
and
people
have
been
kind
of
playing
with
it
and
writing
tests
and
stuff,
but
the
more
the
merrier
some
of
the
stuff
I
put
in
specifically
for
you
Martin.
So
if
you
want
to
go
make
sure
it
meets
your
needs,
that
would
be
great.
G
A
We
removed
the
add
exporter
apis
because
he
didn't
think
it
was
ready.
I
mean
we
still
have
the
ad
processor,
so
you
can
still
achieve
the
same
out
same
navigating
through
the
ad
processor
API,
but
the
ad
exporter
ones
have
been
removed
now.
I
think
we
discussed
this
after
you
left
the
meeting
last
time.
C
I
mean
there's
still
the
old
style
way
of
building
it.
Isn't
that
so
we
can
still
build
it
using
a
adding
a
simple
processor
and
doing
it
that
way.
B
H
C
C
H
Yeah
pretty
much
that
the
ad
exporter
extensions
are
just
kind
of
helpers
anyway,
so
it's
we
didn't
really
lose
a
whole
lot
taking
them
out.
But
I
do
like
the
idea
of
what
you
just
said
like
having
all
the
built-in
exporters.
They
all
have
that
code
duplicated
everywhere,
I'd
like
to
bring
it
back,
maybe
it'll
be
internal.
E
C
Yeah
as
long
as
it's
it's
not
then
using
we'd
have
to
break
the
external
apis
again
for
the
any
of
our
our
own
internal
exporters.
We
can
just
refactor
into
our
exporter
later,
and
people
just
won't
notice
the
difference
and
the
same
for
vendors
and
Library
authors.
C
Yeah,
it's
just
you
know,
try
and
get
it
shipped
as
soon
as
we
can
stop.
People
keep
pinging
me
on
Mastodon
and
Twitter.
Asking
me
why
everything's
RC.
A
A
We
also
need
to
do
the
public
API
review
for
everything
else
that
we're
going
to
be
shipping
foreign.
So
we
could
do
that
if
anyone-
if
nobody
has
any
other
item
to
discuss.
C
I
honestly
need
to
drop
because
it's
half
past
midnight
here
so
I
just
wanted
to
catch
up
on
the
the
stuff
that
been
moved
around
and
stuff
I
was
going
to
ask
if
we
want
to
do
that.
I'm
happy
to
be
involved,
but
I
might
need
to
move
the
Sig
next
week
again.
A
We
have
done
a
few
things
of
the
SDK
we've
already
reviewed,
but
let's
just
start
with
every
project
now.
A
H
A
Yeah
I,
don't
think
there's
any
like
conditional
changes.
So
foreign.
A
H
A
H
A
The
oh
I
guess
it
was
probably
not
had
not
overridden
the
dispose
method
before
it
is
yeah
I
think
that
was
because
of
some
log
console
log
exporter
bug.
If
there
is
like
a
if
the
log
of
factory
or
something
is
already
disposed,
we
didn't
want
to
export
laws.
I
think
I.
Remember
that
PR's
and
being
sent
long
ago
yeah.
It's
probably.
A
A
Metric
reader
options,
okay,
I
think
I-
remember
this
one.
This
is
adding
Matrix
snapshot
for
for
the
Deep
copy,
shallow
copy
issue.
A
A
H
A
A
A
E
A
Okay,
let
me
take
a
look
at
this
one,
so
this
is
for
1.3
stable
when.
A
A
A
A
B
A
B
E
A
Oh,
this
is
the
new
project.
Do
we
expect
this
to
be
shipped
as
as
part
of
OneNote
phone,
or
is
this
for
later.
E
B
A
H
H
H
A
B
E
F
E
H
A
A
H
H
A
H
H
A
B
B
B
A
I
think
that's
my
default
I
type
goof
first
before
typing,
but
okay,
let
me
test
CSP
net
core.
B
The
Matrix
spec
is
that
stable
earlier
we
didn't
do
that
because
it
was
not
stable.
The
spec
was
not
stable,
Matrix
yeah,
yeah
I
I'm,
just
looking
at
the
link,
it's
experimental
okay,
maybe
I'm.
Looking
at
like
some
wrong
link
or
something
let
me
send
that.
A
E
B
A
Yeah
good
point:
this
is
still
experimental,
but
are
we
okay
to
ship
the
metrics.
F
D
F
A
A
F
F
Yeah
I
thought,
maybe
maybe
the
way
I
read
this-
is
that,
like
these
environment
variables
are
supported.
F
That's
what
I'm
saying
there's
like
there's
like
quite
a
few
that
that
are
not
supported
so
I'm
guessing.
We
marked
it
as
stable,
because
what
we
shipped
was
stable,
but
we
didn't
include
things
that
were
experimental.
A
A
A
And
do
you
do
you
know
if.
A
Like
this
is
something
we
should
take
into
account
before,
making
those
I
mean
we've
already
shipped
metric,
stable,
add
metric
exporter
for
DLP
apis.
H
B
A
H
A
A
A
A
F
B
H
Yeah
so
I
guess
the
answer
is
we
can
put
out
RCs
for
those,
but
we
wouldn't
do
the
stable.
E
H
H
A
F
D
F
F
G
Yeah
I
was
looking
at
the
package
and
the
Contra
probe
repo,
the
runtime
instrumentation
package
and
I
know
the
releases
stable,
but
I
checked
the
spec,
it's
on
experimental
as
well,
so
I'm,
not
sure
whether
we
should
follow
closely
that
if
the
spec
is
not
stable
yet
then
we
should
not
have
a
stable
release.
A
I
I
think
run.
Time
was
like
more
of
an
exception
because
it
was
more
dot
net.
We
had
the
reasons
we
had
to
do
was
we
made
for
making
stabilities
it
had
more
to
do
with
like
dot
net
being
different
from
the
other
platforms,
and
like
this
I
mean
it
had
something
very
specific
to
do
with
DOT
net
and
not
just
respect.
G
A
But
like
we
have
never
released
Prometheus
before
so,
I
mean
I.
Think
it's
probably
you
can
ask
Alan
when
he's
back.
If
he
remembers,
if
he
knows
the
reason,
I
remember
like.
A
G
A
H
E
A
A
Questions
you
mean
this
comment:
should
we
do
an
RC
for
this
or
like
this.
A
A
Okay,
yeah
extensions
hosting
extensions
propagators
is
not
released.
Instrumentation
instrumentation.
A
E
A
A
So
we
only
left
with
the
shims
open
tracing
as
following
the
non-core
packages,
never
released
we're
left
with
SDK,
which
I
think
we
can
do
in
the
next
meeting.
Since
we
are
already
over
time-
and
a
lot
of
this
would
most
likely
be
moved
to
the
new
package,
then
we'll
be
left
with
just
SDK
core
SDK
related
apis.
H
Move
but
we'll
stay,
what
we'll
stay
is
like
add,
processor
stays
set,
sampler
the
stuff,
that's
very
like
there's
no
concept
of
a
sampler
or
a
processor,
an
API.
Those
are
just
like
SDK
Concepts,
but
ad
instrumentation
is
moving,
configure
Builder,
configure
services
I
think
in
metrics,
like
add
reader,
that
will
stay
in
SDK.
A
E
A
Looks
like
a
lot
of
things
will
just
stay
in
SDK,
then
the
sampler
processor,
leader
and
resources,
okay,
instrumentation,
would
move
yeah
cool.
Let's
come
back
to
the
public
eBay
review
of
SDK.
Once
we
decide
on
like
where
we
are
moving.
If
we
are
moving
most
likely,
we
would
soon
cool
sounds
good.
Thank
you
so
much
everyone.