►
From YouTube: 2022-11-15 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
C
I
guess
we
could
start,
but
Martin
said
he
would
be
joining
right.
We
could
I
could
message
him
on
Slack.
Just
to
remind
him,
if
he's
forgotten
about
it,.
D
E
He
said
he
was
going
to
be
late,
he
had
a
conflict
last.
E
Okay,
then
I
guess
I've
only
got
about
half
an
hour
three
quarters
of
an
hour.
Just
it's
Bake,
Off
final
in
the
UK
and
I
can't
miss
it
because
yeah
you
want
to
find
out
on
Facebook
yeah.
C
Okay,
I
guess
we
can
get
started
then
share
my
screen.
C
Yeah,
so
we're
going
to
continue
doing
the
public
API
review,
I.
Think
from
the
last
six
meeting
we
had
these
two
apis
that
we
would
we
thought,
were
good
candidates
to
be
made
internal
and
I
think
this
has
already
been
made
internal
by
Michael
spear
yesterday.
C
Yeah
so
let's
take
a
look
at
this
one
then
so.
C
We'll
start
with
the
di
ones,
I
think
just
to
go
over
it
again
because
I
think
last
we
have
the
meeting
that
we
had
on
Friday.
We
kind
of
got
a
better
idea
of
what
these
apis.
What
purpose
they
saw
so.
C
C
Okay,
so
this
one
takes
an
Meetup
provider
Builder
as
well,
and
it's,
which
is
probably
the
next
one,
an
action
of
Provider
Builder,
my
Blanche,
have
we
documented
the
use
of
this
one.
This
API.
C
Okay,
so
what
would
that
do
like
if,
if
the
overload,
which
does
not
take
in
an
action
of
a
media
provider,
Builder.
F
You
could
I
mean
this
is
kind
of
the
pattern.
If
you
look
at
like
the
options
API,
you
can
just
call
add
options
and
pass
nothing,
and
what
that
will
do
is
just
register
like
the
underlying
dependencies
of
the
options
sort
of
framework.
So
it
gives
you
the
ability
to
then
use
like
eye
options
and
stuff
like
that.
So
if
you
called
this
method
without
passing
a
builder,
basically,
what
it's
going
to
do
is
it's
going
to
set
up
all
the
SDK
artifacts,
so
you
can
get
a
meter
Provider
from
the
container.
F
F
Yeah.
It's
just
sort
of
the
standard
pattern
is
you
can
always
call
the
ad
thing
just
to
register
the
components
and
then,
if
you
you
want
to
configure
it
there,
you
have
another
thing
you
can
pass
in
this
case:
it's
an
options
class,
so
you
can
also
configure
it
by
just
registering
configuration
actions.
Ours
is
a
builder,
it's
not
an
option.
So
it's
a
little
bit
different.
C
B
C
Is
this
one,
it
will
add
a
meter
like
add
like
whatever
action,
whatever
the
action
is
supposed
to
do,
it
will
do
it
but
like
in
case
of
a
when,
like
when
we
are
using
an
overload,
which
does
not
take
any
argument
if
it's
just
configure
open,
Telemetry
Matrix
with
no
action.
That's
not
the
one
setting
up
the
meter
provider
right.
C
The
laptops
are
not
that
I
mean
they're
decent,
but
if
I
open,
Visual,
Studio
and
teams
and
like
if
I
have
a
video
call
going
on
then
yeah.
It's
probably
not
going
to
be
the
best
experience.
Oh.
F
E
B
F
So
the
key
bit
is
you
call
this
one,
it's
going
to
jump
in
here
and
then
it's
going
to
new
up
a
builder.
Do
nothing
because
it's
passing
in
basically
a
no
op
and
then
return
the
service
collection.
So
it
looks
like
it's
doing
nothing,
but
this
guy
actually
has
some
work
to
do
so.
What
it's
going
to
do
is
register
into
the
service
collection,
some
stuff,
the
stuff
right
now
is
the
Tracer
provider
itself,
and
then
it's
going
to
register
some
things
that
it
needs.
F
So
it
sets
up
options,
make
sure
options
are
available,
it
makes
sure
I
configuration
is
available.
It
sets
up
some
options,
factories
and
then
the
state.
So
these
things
have
some
side
effects
so
if
they
weren't
there
and
your
library
try
to
like
get
in
options
or
something
conceivably
could
blow
up
in
weird
ways.
So
the
the
reason
you
would
call
this
guy
is
just
to
make
sure
that
in
your
library
the
SDK
is
like
there
and
it
will
work.
C
B
F
C
Okay,
so
another
question:
so
if
you
have
like
two
instrumentation
libraries,
both
calling
configure
open
Elementary
tracing,
so
they
both
come
and
create
a
new
Tracer
provider.
Builder
SDK.
F
F
So
this
state
right
here
this
is
basically
a
class
that
just
holds
the
actions
that
need
to
run
once
the
provider
is
accessed,
which
is
this
guy,
so
it
is
safe
and
sort
of
by
design
that
this
will
be
called
many
times.
I
think
I
have
a
note
up
here.
That
says
that
so
it
should
say
like
this
is
safe
to
be
called
yeah.
This
is
safe
to
be
called
multiple
times
by
Library
authors,
okay,
built
in
that
it
works,
and
that's
all
safe
to
do.
F
Basically,
like
each
time
you
fire
this
stuff
will
all
run
it's
all
just
sitting
in
the
service
collection
and
then
once
the
final
Tracer
provider
is
accessed,
which
can
happen
manually
or
the
hosting
package
will
do
this.
Then
this
Constructor
runs
it
grabs
that
state
object,
so
the
Singleton
sitting
there
in
the
service
provider
and
then
it
basically
executes
all
that
stuff
and
applies
it
so
that
the
end
of
the
day,
the
Tracer
provider
that
you
get
had
all
that
configuration
okay.
C
Okay,
yeah
makes
sense
so
yeah,
going
back
to
the
configure
API
I
think.
E
Last
time,
though,
that
we
shouldn't
do
that,
because
it's
not
the
convention
that
that
works
with.net,
because
everything
is
there's
a
whole
reflection
problem
that
could
happen
like
down
the
lines
and
it's
just
not
idiomatic
of
the
sdks.
F
This
is
what
we'd
want
in
a
perfect
world,
just
one
method
where
this
is
a
default
thing,
but
there's
traps
to
doing
this
and
it
kind
of
locks
you
in
makes
it
hard
to
ship
changes.
So
when
you
want
this,
what
you
should
do
is
this:
you
just
have
two
methods:
one
of
them
doesn't
accept
it
and
knows
how
to
like
shim
it
make
it
safe.
So
this
is
really
kind
of
the
pattern
we
have
now
across
the
board.
Where
really?
What
we're
doing
is
this?
F
E
Realistically,
we
want
people
to
be
the
code
to
be
clean
enough,
that
it
doesn't
say,
configure
open
tracing
null
in
people's
code.
E
But
what
we're
saying
is
we're,
keeping
in
the
same
sort
of
style
as
the
rest
of
the
sdks,
not
just
the
open,
Telemetry
sdks
we're
talking
generally
in
sdks.
That's
the
way
you
should
do
things
so
I.
Don't
think
that
should
really
be
a
debate.
C
Okay,
yeah
sure,
then
I
think
that
seems
good
I
was
thinking.
We
should
just
write
here
a
list
of
the
things
which
we
feel
that
we
are
good
with
so
I'm
going
to
write
these
two
apis
here.
C
F
Which?
These
two,
which
will
work.
C
A
C
C
So
let's
go
back
to
the
next
one
I
think
line
21
of
this
file.
A
C
C
C
It's
just
one:
yeah
overload.
B
A
F
F
A
F
Yes,
before
I
touch
on
that,
let
me
also
quickly
say
that
most
of
these
that
we
just
looked
at.
F
So
most
of
this
stuff
exists
today,
it's
just
part
of
the
hosting
package,
so
all
I'm
really
doing
is
I
moved
it
all
into
the
SDK.
So
now
you
can
do
those
things
without
needing
the
hosting
package.
So
it's
more
of
more
of
a
convenience
thing
than
like
a
new
complete
edition.
If
that
makes
sense,
and
the
real
benefit
to
that
is
previously,
that
stuff
only
worked.
F
If
you
were
calling
those
extensions,
so
you
were
doing
what
do
I
have
here
app
builder
services
that
are
open
to
monitoring
Trace
along
with
over
so
today
you
can
do
this
and
that
will
work,
but
you
can't
do
it
in
the
kind
of
manual
style
or
the.net
framework
style.
This
wouldn't
work.
So
you
have
these
two
different
kind
of
paths
through
the
code.
F
C
Okay,
so
this,
like
the
set
sampler
thing
that
you
newly
added
in
in
the
SDK
that
has
the
same
signature
as
the
one
that
extensions
hosting
or.
F
F
C
F
These
ones
right
here
get
services
and
configure
these
became
in
the
new
API
they're
now
configure
Builder
configure
services,
so
the
names
changed
and
configure
Services
used
to
used
to
be
a
get.
So
it
would
return
you
the
service
collection,
where
now
it
just
executes
against
its
internal
instance.
It's
a
delegate
thing.
F
C
F
C
D
You
think
it
would
be
Our
intention
to
remove
those
methods
before
this
package
went
stable.
D
I
think
if
we
just
had
a
small
I,
remember
talking
to
you
about
these
methods
a
little
bit,
I
I
think
it
given
that
I
think
our
discussion
was
that
this
package
has
been
out
there
for
a
while.
So
people
might
be
using
this
pretty
extensively
so
I
yeah
I
think
that
there's
some
value
in
a
small
transition
window
I
hope
that
people
will
jump
on.
C
So
do
we
need
to
update
the
readme
of
extension
sourcing
I
think
we
can
do
that.
Let
me
look
just
later
on
to
use
the
new
configure,
Builder
and
configure
so
yeah
this
one.
F
I
haven't
touched
it.
You
could
probably
just
remove
a
lot
of
this,
because
it's
now
in
the
other
Docs.
C
Okay
and
yeah
configure
services
and
configure
Builder.
That's
something
we
need
for
sure.
So.
I'm
gonna
add
that
as
well
to
the
things
that
look
apis,
that
look
good.
F
F
F
E
F
E
I
think
the
question
I've
got
is:
is
that
a
decision
that
we
need
to
make
as
part
of
the
1-4
release?
Could
it
be
putting
it
to
one
five
or
to
two
just
in
the
efforts
to
not
like
shed
too
much
on
naming
and
locations.
D
E
D
F
C
E
Well,
yeah
to
me,
the
biggest
thing
in
this
release
is
the
extensions
hosting
removing
of
that
collapsing,
whatever
you
want
to
call
it,
but
essentially
making
it
so
that
people
can
host
with
a
fully
non-pre-release.
E
A
D
If
this
were
part
of
a
separate
Library,
would
it
be
possible
to
do
that
anyways
and
maybe
provide
all
the
same
functionality,
maybe
in
a
different
namespace
like
open,
telemetry.config
or
something
along
those
lines
and
not
have
there
be
a
future
clashes
and
still
provide
the
same
benefits
to
you
know
instrumentation
or
extension
authors
that
would
prefer
to
avoid
an
SDK
dependency,
any
obvious
gotchas
you
can
think
of
that
would
make
that
a
non-starter.
F
D
A
D
Sdk
package
right-
and
we
don't
even
worry
about
this,
like
move
it
to
a
different
class
and
and
so
on,
have
we
if
we
entertained
a
new
package
in
the
future,
it
had
all
the
same
functionality.
D
Well,
could
one
could
we
do
that
and
not
have
painted
ourselves
into
a
corner?
You
know.
A
F
I
think,
as
long
as
we
move
this
whole
type,
including
its
namespace.
So
if
we
moved
all
of
this
to
open,
Telemetry,
dot
configuration
or
open
telemetry.d
dependency,
injection
we'd
be
fine,
there'll
be
no
issues.
I'd
have
to
move
some
other
stuff
that
it's
relying
on
like
the
state
class,
but
this
stuff's
all
internal,
no
big
deal
there.
F
D
D
Just
trying
to
Envision
a
world
where,
like
we
tried
to,
we
tried
to
hedge
our
bets
and
and
put
things
in
a
different
class
with
the
intent
to
maybe
take
advantage
of
this
type
forward
thing,
but
then
oops,
you
know
something
was
left,
unaccounted
for
or
something
and
now
you
know,
Reg
has
been
thrown
into
our
plans.
Would
we
still
have
a
a
path
forward
if
we
shipped
to
a
separate
library,
but
just
with
all
the
same
functionality
and
an
entirely
different
namespace
again?
This
is
not
a
fully
big
thought.
Yeah.
F
I,
don't
know:
do
you
think
we
would
be
okay
like
if
we
needed
to
keep
this
stuff,
so
how
this
stuff
is
implemented?
Is
it's
looking
for
like
a
certain
type,
so
we
could
preserve,
like
let's
say
this
class
with
this
API.
If
we
moved
this
type
or
we
had
some
new
type
and
some
other
package
as
long
as
we
could
fulfill
the
contract,
then
we
could
just
mark
this
as
obviously
call
into
the
new
API
and
just
redesign
it
as
we
need.
F
F
F
F
D
Well,
anyways
yeah
some
things
to
think
about
again:
I
I
mean
I'm,
I'm
kind
of
with
Martin,
like
I.
Don't
think
that
I'm
personally
super
concerned
I
think
it's
worth
a
little
bit
of
thought,
but.
C
I
think
the
instrumentation
libraries
would
need
to
take
a
take
an
SDK
ref
dependency
only
if
they
want
to
use
these
Advanced
config
features
right.
Otherwise,.
C
Like
if
it's
a
very
simple
setup,
then
they
could
be
well
of
using
the
just
the
API
reference
and
I.
Don't
know
if
that's
like
something
like
do
we?
How
much
do
we
want
to
comply
with
like
an
instrumentation?
Library
should
not
take
a
dependency
on
SDK
at
all,
like
even
for
advanced
for
whatever,
regardless
of
what
configuration
we're
talking
about.
F
So
I
take
like
this
stack
the
stage
redis
case
so
I
don't
think
it's
going
to
take
an
SDK
dependencies.
I
also,
don't
think
it's
going
to
take
an
API
dependency,
because
I
think
it
would
just
be
super
surprising
to
many
users
that
want
to
use
stack
exchange.
They
don't
know
or
care
about
open
Telemetry.
They
don't
want
to
see
it
show
up
so
I
Envision
it
if
it
ever
happens.
Being
foreign.
F
F
Which
one
they're
using
like?
Why
not
just
do
the
SDK
I,
don't
think
anyone
would
complain
like
I,
don't
totally
understand
the
value
of
the
API
libraries
adding
to
the
mix,
because
most
of
our
API
has
done
that
itself.
The
only
thing
really
in
API
is
like
the
Builder
or
baggage
context,
propagation.
C
I
think
like
we
didn't
want
to
take
an
SDK
reference
like
we
don't
recommend
our
friends
to
intentional
library,
because
someone
might
do
a
custom
implementation
of
the
API
and
then,
if
the
instrumentation
library
is
depending
on
a
different
implementation
of
SDK,
then
what
the
consuming
application
would
use.
I
guess,
I
think
that
was
the
reason
for
it.
But
I
don't
I,
hardly
know
of
anyone
who
would
have
implemented
I.
E
E
E
That's
why
I
think.net
is
very
different,
which
is
why
I
don't
think
it
works
as
well,
because
what
you'd
normally
have
in
API
is
a
span
type
and
a
tracer,
a
tracer
provider
that
allows
you
to
get
a
a
tracer
which
we
don't
have
because
that's
supplied
by.net.
B
C
Like
if
the
let's
say
in
this
case,
if
this
red
is
open,
Telemetry,
Library,
instrumentation
libraries,
depending
on
SDK
on
the
SDK,
that
we
ship
and
the
actual
consuming
application,
is
using
their
own
implementation
of
API,
which
is
a
different
SDK.
So
I
like
I,
mean
I,
don't
know
like
if
it
will.
C
Get
hooked
to
the
right
things
in
that
case.
E
C
So
everything
like
about
like
exporters
in
processors
and
all
of
that
stuff
and
the
logic
that
we
follow
for
that.
E
So
what
would
be
the
customer
implementation,
because
that
is
also
that's.
That's
the
customer
implementation.
If
somebody
wanted
to
do
something
different,
they
would
have
to
do
all
of
their
exporters
and
all
of
their
instrumentations
and
processes
and
all
of
that
kind
of
stuff.
So
what
would
they
be
pulling
from
us.
C
F
C
Yeah
but
like
if
someone
was
to
implement
a
custom
implementation,
would
they
still
have
to
comply
with
the
hotel
spec
for
SDK
like
when
they
are
making
their
own
SDK?
Because
then
it's
essentially
they're
working
towards
what
we
are
building.
A
D
Life
use
cases
of
people
implementing
their
own
SDK,
but
you
know
so
it's
just
kind
of
going
out
on
a
limb
and
trying
to
imagine
that
scenario.
You.
D
Attempt
to
implement
say
they
implemented
all
of
the
SDK,
and
it
was
you
know
they
they
had
their
own.
Notions
of
you
know
like
a
batch
span,
processor
and
and
things
like
that,
all
in
their
own
namespaces,
then
you
know
I
the
instrumentation.
The
stack
exchange,
instrumentation
example
right
that
takes
a
dependency
on
our
SDK.
That
provides,
you
know,
maybe
some
defaults
for
some
processors
and
so
on.
Just
would
not
work.
F
F
F
F
So
if
we
look
at
its
extensions,
it's
just
newing
up
on
options
and
invoking
the
delegate,
so
this
won't
work
with
the
greater
world
of
options
that
we
know
and
love,
but
it
looks
like
it
does,
so
this
is
going
to
be
very
confusing,
probably
for
users
using
the
other
libraries
which
now
all
work
in
that
world.
This
is
kind
of
an
outlier.
E
Unfortunately,
I've
got
a
drop
I'm,
hoping
that
we've
got
at
least
somewhere
with
the
public
API
surface
area.
Stuff
I
will
I'll
be
available
next
week,
Parts
other
than
that
I'm
happy
to
converse
over
slack.
And
what
have
you.
B
F
C
So
if
we
extract
the
configure,
Services
API
and
basically
the
service
collection
related
stuff
into
a
different
package,
then
the
instrumentation
Library
would
depend
on
API
and
that
new
package
and
not
on
SDK
right.
A
A
F
C
C
G
C
C
Okay,
I
think
we're
also
out
of
time
now,
let's
ask
sijo
as
well
I
think
he
didn't
join
what
he
thinks
like
I
think
we
should
just
make
that
decision
of
where
these
public
apis
would
reside,
and
then
we
can
go
on
with
the
next
ones.
The
remaining
apis.
C
F
F
There's
four
or
five
currently
there's
a
bunch
of
them,
one,
two:
three:
four:
five:
six
and
they're:
basically,
that
same
pattern
of
sort
of
expanding
out
the
methods
for
each
thing
you
might
want
to
pass,
so
this
is
sort
of
the
one
that
does
them
all.
This
doesn't
have
the
name.
This
doesn't
have
the
configure
delegates.
F
F
Yeah.
If
you
do
decide
to
pass
a
delegate,
they
all
take
this
class
export
activity,
processor
options
which
doesn't
have
a
whole
lot
at
the
moment
it
has
type
and
then
the
batch
options,
so
I've
gotten
a
few
questions
on
this
design
like.
F
Why
do
we
need
this
class?
Could
we
just
say
batch
options
here?
Why
do
we
specify
the
type
or,
conversely,
why
is
there
a
type
on
here
different
reasons
for
all
of
those
things?
So
there's
already
six
extensions.
F
F
C
I
think
yeah.
We
are
not
unblocking
him
we're
not
blocking
him
by
not
providing
this
like.
He
there's
still
ways
to
add
an
exporter
which
is
because,
if
you
require
the
person
to
understand
what's
simple
and
batch,
it
means
then
I
think
they
are
like
knowledgeable
enough
to
use
our
processor
for
it.
I
would
say.
F
F
F
C
C
F
For
sure
I
would
expect
only
people
to
call
AD
exporter
are
other
extensions
like
I
would
expect
Jaeger
to
call
it
Zipkin
to
call
it
Geneva
to
call
it
or
if
you
happen
to
be
building
your
own
exporter,
that
you
want
to
use
in
your
application,
and
you
know.
A
F
It's
a
batch
or
a
simple
I
would
say
it's
safe
to
use
there,
but
it
it
was
never
my
intention
that
you
would
call
AD
exporter
and
then
use
Like,
Jaeger
yeah.
So
a
couple
people
ask
me
that
that's
not
good
like
if
the
API
is
allowing
you
to
do
that.
It's
probably
not
a
good
API,
because
the
extensions
have
a
lot
of
other
logic
that,
like
ad
exporter,
doesn't
know
how
to
do
this.
F
B
C
A
F
C
F
B
F
B
C
Cool
then
I
think
we
are
11
minutes
past
our
meetings
and
time
I'll
update
the
meeting
notes
with
whatever
we've
decided
on
like
configure
The
Source.
Can
we
want
to
see
configure
Services
if
that's
something
we
want
to
make
it
easily
movable
and
that
you
would
be
marking
ad
exporter
methods,
internal
and
yeah.