►
From YouTube: 2021-07-22 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
Hello,
everybody
welcome
to
another
edition
of
the
writing.
Stick
meeting.
As
always,
please
add
your
names
to
the
attendees
list,
I'll
paste,
the
link
in
the
chat
for
the
google
looking
at
for
that.
A
A
We
have
some
new
folks.
D
Absolutely
hey
guys,
thanks
for
having
me
and
nathan
here,
so
we
both
are
from
ge
healthcare,
and
we
are
here
in
zanderburn,
california,
and
we
are
starting
to
use
open
telemetry
and
we
have
been
having
some
conversations
with.
You
know
the
aws
team
and
I
believe
they
are
active
in
open,
telemetry
development
and
by
talking
with
them
we
kind
of
we
first
started
using
open
telemetry
for
tracing
purposes.
D
D
And
now
we
are
wondering
and
curious
to
see
if
we
can
use
open
telemetry
anytime
soon,
because,
based
on
that,
we
plan
to
make
some
decisions
so
because
we
are
using
one
single
service
and
rather
a
particular
service
is
going
to
have
both
tracing
and
metrics
implemented.
So
should
we
go
with
open
telemetry
for
tracing
and
our
own
custom
solution
for
metrics?
So
that's
the
question
that
we
are
asking
ourselves.
So
that's.
D
Why
I
kind
of
put
that,
as
a
quick
topic,
to
get
some
feedback
to
make
some
quick
choices
for
us
to
proceed
further,
so
yeah
and
thanks
for
having
us
again.
D
A
Have
you
here
I
don't
know
later
alex?
If
maybe
we
should
answer
your.
B
Okay,
so
aruna
is
this:
is
this
the
only
point
of
contention
that
you
guys
are
having
sorry
go
ahead.
B
Love
to
oh
yeah,
we
dedicated
this
mean
to
talk
about
some
certain
architectural
decisions
that
we
need
to
make.
So
we
we
didn't,
have
a
lot
of
open
topics
today.
So
if
we
could
like
maybe
get
to
your
issue
first
and
then
we're
gonna
be
diving
pretty
deep
into
other,
like
technical
aspects
afterwards,
so
feel
free
to
like
drop
off
afterwards,
but
yeah
we
can.
We
can
talk
about
your
issue
right
now,.
D
A
All
right
perfect,
so
I
guess
I'll
I'll
answer
your
questions,
so
I'm
the
one
who's
developing
the
metrics
prototype
I've
been
doing
so
for
for
a
while,
it's
a
slow
process
and
I
apologize
special
biggest
thing.
In
the
last
few
weeks,
I've
been
focused
on
the
release
and
this
topic
that
we're
concerned
with,
but
okay,
so
the
metrics
specification
is
not
yet
complete
and
people
are
working
on
getting
it
complete
it.
A
The
date
where
it
was
expected
to
be
completed
has
been
moved,
like,
I
think,
like
a
couple
of
weeks
or
a
month,
because
there
are
still
a
bunch
of
topics
to
discuss.
B
A
Now
I
am
working
on
implementing
a
prototype
that
has
relatively
small
goals,
which
are
pretty
much
to
run
a
couple
of
examples
so
that
we
can
have
a
something
to
use
to
drive
our
conversation
right.
There
are
several
prototypes
already
developed
in
other
languages.
I
think
java
has
one
and
go
also
has
one.
A
A
So
it
is
still,
as
you
see
very
unstable
and
very
under
development,
it's
hard
to
make
a
promise
on
when
everything
will
be
as
ready
as
racing
us,
but
as
just
you
can
make
yourself
an
idea
that
the
the
goal
to
have
this
just
in
experimental
this
end
of
august
right.
So
sorry,
this
is
the
the
state
of
things
I
wish
you
had
better
and
useful.
D
Yeah
yeah,
that's
absolutely
fine!
So
when
we
say
august
experimental
prototype
will
we
have
something
to
experiment
with
like
by
early
august
mid-august
any
thoughts.
A
I
think
the
prototype
the
python
prototype,
hopefully,
could
be
a
couple
of
weeks
sooner
than
that.
But
again
the
pyramid
prototype
has
pretty
much
no
weight
when
it
come
when
it
is
compared
to
the
specification
itself
right.
It's
just
a
python
prototype
and
spec
can
decide.
Otherwise,
so
you
could
have
something
in
mid-august
to
experiment
with,
but
the
application
code
that
you
develop
from
it
can
drastically
change
so
yeah.
That's
that's
expected.
Yeah.
D
Yeah
I
mean
we
are
ready
to
take
the
bet,
because
now
the
alternative
is
for
us
to
have
our
own
solution,
which
will
totally
be
different
from
what
ultimately
the
industry
would
be
using
like
few
months
from
now.
So
we
are
leaning
towards
going
with
even
the
prototype
or
experimental
one,
because
it's
going
to
be
more
closer
to
the
specifications,
and
you
know
what
the
industry
would
be
using
soon,
because
we
are
already
anyway
using
open,
telemetry
apis.
D
We
are
thinking
at
least
there'll,
be
some
similarity
in
the
overall
architecture,
and
you
know
some
structure
of
the
code
and
things.
So
that's
a
thought.
So
with
that,
would
you
still
recommend,
if
you
have
to
make
a
decision
say
by
mid-august
or
even
end
of
august,
to
have
a
sample
set
of
services
using
open,
telemetry
api?
Would
you
recommend
that
going
with
this
experimental
or
you
think,
it'll
be
too
unstable?
And
you
say:
hey
no
come
back
in
september
october
or
later
this
year?
What
will
be
the
recommendation.
A
Well,
so
it's
very
hard
to
say
I
considering
the
fact
that
your
only
choices
are
making
the
solution
by
yourself
or
trying
to
go
with
the
metrics
proposal
that
we
have.
I
will
suggest
the
second
one
because
there's
at
least
a
lot
of
discussion
that
has
already
been
done
in
the
metrics,
and
there
is
a
lot
of
work
that
has
already
been
made.
It's.
E
E
Good,
I
just
wanted
to
mention
that
it's
also
worth
pointing
out
that
the
the
apis
for
the
metrics
signal
are
further
along
than
the
sak
implementation.
So,
even
if
you
were
like
betting
on
open
telemetry
like
I,
I
think
I
think
the
apis
themselves
are
further
along
than
where
the
sdk
is.
So,
if
you
were
to,
you,
know,
start
instrumenting
a
service
using
only
the
api
for
metrics
that
are
currently
defined.
E
You
probably
wouldn't
see
as
much
churn
as
if
you
were
trying
to
use
the
sdk
directly,
which
might
might
help
guide
your
decision
decision
as
well,
but
definitely
it
would
be
obligated
if
you
know
if,
if
you
have
engineers
that
are
you
yourself
or
other
engineers
on
your
team,
are
interested
in
participating
and
trying
to
push
forward
the
metric
signal
implementations
that
would
be.
That
would
definitely
be
something
the
community
would
appreciate.
D
Oh,
that's
a
good
idea.
Maybe
I
should
look
for
yet
another
metrics.
I
mean
this
is
our
first
meeting
that
you
know
this
team
from
ge.
Healthcare
is
participating
me
and
nitin,
but
yeah.
Maybe
I
should
look
for
this
metrics
meeting
and
join.
That
is
that
your
suggestion
yeah.
E
The
so
the
metrics
meeting
happens.
Let
me
just
pull
this
up.
It
happens
on
thursday,
I'm
pretty
sure
yeah.
It
is
today.
B
Four
pm
pst
the
metric
six
meetings
gets
pretty
technical.
So
I
would
add
this
like
your
question
as
a
like
what
you
did
for
our
stick
like
as
a
first
point.
Definitely
like
brick,
ass,
like
bring
it
up
like
hey,
we're,
trying
to
use
this
as
a
product.
What
do
you
guys
suggest
and
be.
A
A
slack
hotel,
metrics
channel,
where
you
can
pretty
much
ask
anything.
A
In
slack,
the
cncf
slack
organization
has.
D
D
C
B
Right
cool:
we
have
a
little
under
50
minutes
left
so
today
we're
dedicating
this
to
talk
discussing
about
distros.
B
B
Currently,
our
current
status
nathaniel
is
nathan,
oh
yeah,
yes,
okay,
so
he
has
a.
He
has
a
pr
out,
I'm
starting
to
move
a
lot
of
the
functionality
out
from
distros
into
the
sdk.
B
B
I
believe
diego
has
come
up
with
a
different
solution
and
how
we're
going
to
be
doing
this,
I
think
we
got
to
first
define
like
the
problem
set,
that
we're
trying
to
solve,
which
is
like
extensible
and
robust
way
to
configure
how
we
instrument
with
open
telemetry
right,
whether
it
be
you
know,
environment
variables
specifying
which
exporters
we
use
id
generators
etc.
B
So,
however,
we
do
that
will
be
like
what
we
talked
about
today,
but
that
always
focus
on
that.
This
is
the
problem
that
we're
trying
to
solve.
There's
also
other
nuances,
like
I
can't
think
of
talking
ahead,
but
like
yeah,
that
will
come
up
but
yeah.
This
is
the
the
main,
the
main
issue.
B
So
because
how
do
we
suggest
we
do
this?
We
can
right
now
we
could
probably
start
off
with
nathaniel's
pr.
I
think
that'll
be
a
good
baseline
to
start
off
with,
because
that
seems
to
be
the
thing.
That's
blocking
the
most
progress
right
now,
diego
did
you
want
to
share
your
screen.
A
Sorry
sure
yeah,
let
me
show
you
my
screen
real,
quick,
nathaniel
spear
right,
it's
yes,
it's
this
one!
No!
No!
This
is
something.
This
is
an
issue
this
one
right,
the
four
configurators
two
more
for
this
rows.
Yes,.
B
Okay,
okay,
so
a
little
bit
of
context,
we
we've
brought
up
this
pr
like
a
couple
of
weeks
ago
too,
we
all
had
an
agreement
that,
like
you
know
all
this
pr
does,
is
move
some
of
the
functionality
that
we're
doing
in
the
distros
into
the
sdk
package,
and
I
think
we
all
had
a
consensus
at
that
time
to
do
this,
which
is
why
nathaniel
went
ahead
and
implemented
it.
B
However,
some
of
us,
I
think,
had
a
bit
of
a
disagreement
on
this
on
actually
doing
this
afterwards,
which
is
why
we're
still
being
hung
up
on
it.
I
think
the
main
contender
behind
that
was
tiego,
so
I
think
it
would
be
productive
to,
like
so
diego,
to
make
your
case
on
why
the
main
issues
that
we're
trying
to
not
do
this,
and
then
we
could
talk
about
it
after.
A
Yes,
thank
you,
so
the
reason
why
I
disagree
with
this
pr
is
pretty
much
because
it
moves
this
through
code
into
the
into
the
sdk
I
now
one
of
my
central
points
is
that
this
rose
is
just
a
tool
that
we
created
to
make
things
easy
for
our
users.
A
That
is
not
part
of
the
sdk,
and
that
should
be
completely
separate
from
the
specification
defined
components.
Yes,
okay,
so
yeah,
that's
pretty
much!
Why
I
disagree
with
this
pr.
I
also
think
that
there's
a
technical
issue
here.
The
fact
that
this
is
private-
and
I
forgot
to
mention
this
before-
but
I
think
this
defeats
the
purpose
of
importing
from
it
by
other
packages.
A
Just
and
that's
my
disagreement.
F
F
This
is
kind
of
me
saying
in
the
pr
that
this
shouldn't
be
digital
code.
This
should
be
anyone
who
wants
to
use
this
code
code,
sure
it's
not
sdk
specific
code,
but
that's
why
it's
private!
That's
why
it's
not
any
of
the
implemented
apis.
So
the
whole
point
of
this
pr-
and
maybe
the
title
is
confusing,
but
it
should
be
make
code
that
shouldn't
be
just
open.
Telemetry
district
code
available
to
everyone
in
a
common
place:
okay,.
A
A
Classified
as
private,
that
doesn't
mean
it
should
it
it
can
be
put
in
a
spec-defined
component
and
also
the
definition
of
private,
and
here
I
understand
that
there
is.
There
can
be
some
discussion
about
what
private
means,
but
usually
private
means
do
not
import
from
this
I
mean,
regardless
of
your
and
and
the
end
user
or
or
python
developers,
so
again,.
C
C
I
agree
with
that
with
what
diego
said
about
being
private.
I
think
my
understanding
was
that
this
is
private,
because
we
didn't
want
to
spend
a
lot
of
time
figuring
out
where
to
put
it
now,
we
just
want
to
put
it
somewhere,
so
people,
in
the
sake
can
start
using
it
and
then
slowly
we
can
figure
out
where
the
permanent
place
for
this
school
is.
A
Yeah
just
to
be
clear,
I
do
not
disagree
with
the
code
itself
that
is
introduced
here.
I
just
disagree
with
where
it
is
being
kept
I'll,
be
probably
completely
fine
to
have
it
into
a
separate
package,
name
open
to
limit
be
distro
whatever
or
if
the.
A
I
mentioned
this
because
alex
just
reminded
me
that
the
sdk
says
something
about
configuring.
The
sdk
itself.
C
Yeah-
and
I
think
that
brings
us
to
another
question
that
we
raised
yesterday,
which
was
whether
the
destroyer
is
like
a
general
purpose:
open
telemetry
api
configure
or
it
is
specific
for
open,
telemetry
sdk.
So
if
someone
does
a
third-party
sdk,
maybe
they
need
their
own
mechanism
for
configuration.
C
A
I
do
have
an
opinion
on
what
the
this
phrase-
and
I
think
this
row
is
something
that
is
not
defined
in
the
sdk
and
because
of
that.
It's
something
that
we
just
came
up
with
with
a
practical
idea
in
mind
and
it's
to
make
things
easy
for
our
users.
A
A
A
Yeah
I
mean
the
most
immediate
implication
is
that
it
is
not
part
of
the
sdk
spec.
It
should
just
not
be
there.
B
E
F
Yeah,
this
code
is
only
used
in
auto
instrumentation
and
for
the
purposes
of
automatically
finding
and
initializing
exporters
and
id
generators
and
creating
a
tracer
provider.
That's
that's
its
purpose
right
now,
and
the
idea
right
now
is
that
in
being
an
open,
telemetry
distro,
since
you
cannot
have
more
than
one
discharge
installed,
then
you
can
only
use
the
open,
lonely
district,
which
is
probably
not
what
we
want
distros
to
be
right.
We
want
to
be
able
to
create
other
districts.
A
Does
not
imply
that
but
nathaniel
mentions
a
very
important
point
here:
the
fact
that
this
code
is
used
for
experimentation
and
there's
another
argument,
so
there's
something
else
that
I'm
arguing
against
that.
The
instrumentation
requires
a
distro
to
be
installed
and
that-
and
I
argue
against
that
because
again,
these
throws
are
not
part
of
the
spec,
but
instrumentations
are
so.
We
shouldn't
never
require
a
spec
defined
component
to
re
to
have
a
non-spec
defined
component.
A
B
So
can
all
this
like
is
it?
Is
it
useful
to
auto
instrument
like
based
off
of
the
api?
Can
everything
that
we
want
to
customize
be
able
to
be
done
through
the
api.
A
It
may
solve
the
problem
that
it
won't
be
in
the
sdk,
so
any
sdk
user
may
have
access
to
it.
But
again
has
the
same
problem
that
it
should
not
be
music
in
the
api,
because
it's
not
obvious.
B
A
B
A
I
agree
with
that
goal.
I
think
that's!
That's!
That's
a
great
idea
completely
in
agreement
with
that.
Just
let's
put
it
keep
it
separate
from
the
specifications
if,
if
other
people
have
other
opinions
on
what
a
district
should
be,
please
share
them.
B
E
I
just
want
to
point
out
that
pr
that
she
can't
post
posted
in
the
chat,
open,
telemetry,
desktop
exists
in
order
to
encapsulate
setup
and
can
encapsulate
setup
and
configuration,
and
it
may
include
a
specific
set
of
instrumentation
libraries,
plug-in
samplers
and
other
additional
components.
That's
a
spec
inside
the
pr
to
talk
about
open,
telemetry
distress.
E
E
Is
there
anything?
That's
in
that
pr,
that's
preventing
us
from
moving
forward
from
that
point
on
later,
like?
Is
it
going
to
push
us
in
a
corner
when
it
comes
to
like
the
next
step
of
where
we
want
to
move
forward,
to
try
and
decouple
things
with
destroys
later
or
is
it
at
least
a
step
in
the
right
direction?.
B
B
B
So
right
now
all
the
like:
the
configurator,
the
disk,
drills,
they're,
all
private
right
now
and
we're
importing
the
private-
and
this
is
just
a
like-
a
like-
a
mechanism
that
we're
using
to
make
it
so
that
we
can
break
not
break
the
sdk
if
we
choose
to
move
it
later,
because
we
don't
know
where
to
these
live
right
now
now
the
question
is
like:
is
this
fine
just
to
move
things
along,
or
should
we
actually
decide
on
exactly
what
a
discharge
should
be
and
where
it
should
exist?
B
A
Think
that
if
we
keep
them
private,
we
create
a
then
and
another
problem
and
is
the
fact
that
other
packets
should
not
import
private
things,
regardless
of
if
the
user
is
an
end
user
or
an
open,
telemetry
python
developer.
So
I
don't
think
that's
a
solution
here.
Right.
C
Yeah-
but
I
think
that's
fine
temporarily,
like
for
people
outside
this
sick,
we're
essentially
saying
do
not
use
this
today,
but
for
people
in
the
sig
they
can
make
a
decision
to
use
it
temporarily
and
like
collect
feedback
and,
and
maybe
another
couple
of
sick
calls.
We
can
figure
out
where
they
should
actually
live.
E
Yeah
I
mean
by
putting
something
on
this
in
a
private
method
or
private
package.
You're,
basically
saying
we
don't
support
this
thing
like
use
at
your
own
discretion.
If
you
use
it
and
it
breaks
tough
like
you,
can't
really
do
anything
about
it
and
there's
definitely
a
precedent
because
we
saw
the
same
thing
happen
with.
E
I
think
it
was
like,
maybe
aiopg
or
something
like
that
that
broke
our
contributor
contribute
to
trip
repo,
because
one
of
the
private
methods
that
we
were
using
to
hook
into
into
the
library
like
changed
and
that's
fine
we're
not
going
to
go
and
complain
to
them.
Hey.
You
broke
this
method
because
we
were
using
a
private
method.
Brain.
A
A
Okay,
but
just.
B
A
Good
good
does
this
spec
says
that
this
configuration
should
happen
by
using
a
distro,
no,
no
okay.
So
actually,
what
we
should
do
is
to
make
this
code
that
nathaniel
moved
into
the
sdk
public,
because
it
is
part
of
the
of
the
sdk
spec
and
we
it
should
have
nothing
to
do
with
the
distro
itself.
B
B
I
think
it
says
I
think
I'm
paraphrasing
but
like
there
are
like
the
sdk.
There
are
certain
sdk
environment
variables
right
instead
of
defining
the
spec
as
sdk
environment
variables,
and
these
can
be
configured
okay,
that's
it
it's
very
vague.
A
All
right
now,
what
happens
is
that
we
can
pretty
much
just
make
this
code
nathaniel
put
in
the
sdk
public
so
that
anyone
can
use
it
to
do
this.
Configuration
of
these
sdk
environment
variables,
which
is
perfectly
fine.
That's
why
the
spec
says-
and
I
think
we
should
not
confuse
that
kind
of
configuration-
that
kind
of
sdk
configuration
with
the
purpose.
A
The
other
purpose
that
distros
may
have,
which
is
to
provide
vendor
specific
configuration
like
of
course
having
an
at
distro
for
aws
or
or
whatever
else
that
that
I
think
san
antonio
mentioned
is
something
that
is
necessary
for
all
instrumentation
to
work
right,
nathaniel.
A
Is
that
what
do
you
want
from
this.
F
A
These
separate
distro
have
the
distros
as
a
separate
mechanism
target
for
vendor
specific
configuration,
and
I
I
can't
now
say
that
distrust
is
something
that
we
just
came
up
with,
and
it's
something
that
alex
is
important,
because
frequent
has
rightfully
pointed
to
this
new
component
of
the
spec
which,
where
this
is
mentioned,
I
think
the
definition
here
is
not
yet
specific
enough
to
set
us
in
one
path
or
another.
A
A
Sure
go
ahead;
okay!
Sorry,
I'm
thinking
too
long
I'll
try
to
be
as
quick
as
possible.
Okay
in
this
piece.
A
One
is
a
mechanism
to
separate
the
distros
from
every
other
spec
defying
component
right
now
they
are
not.
The
instrumentation
includes
a
basis
or
class,
and
it
introduces
a
general
purpose
entry
point
that
can
be
used
by
anything
that
wants
to
do
anything
before
the
the
execution
of
the
instrumentation
happens.
So
what
I'm
doing
here
is
adding
this
for
loop.
A
For
this
entry
point
name
open
to
limited
pre-instrument,
then
the
instrumentation
happens
with
the
execution
of
these
other
entry
points
open
to
an
instrumentor.
And
finally,
we
run
this
order.
Entry
point
name
open
to
elementary
post
instrument.
So
what
I'm
suggesting
is
that
this
open
telemetry
post
instrument
and
open
telemetry
pre-instrument
entry
points
are
general
purpose
entry
points
and
that
distrust
use
this
entry
point
to
do
their
own
vendor
configuration
where
the
distros
can
be
called
here
and
executed
with.
A
That
being
said,
this
is
completely
separate
from
how
I
am
suggesting
that
these
truths
should
be
implemented.
In
fact,
the
the
idea
that
away
has
that
to
select
instrumentations
with
priorities
could
work
with
this
solution.
It
just
uses
this
entry
point,
so
I
want
to
make
clear
right
that
this
is
something
the
proposal
that
I
have
for
the
actual
this
implementation
is
something
else.
In
fact,
I
should
separate
this
vr
into
one
that
only
includes
these
hooks
and
one
that
includes
my
actual
suggestion
for
how
distrust
can
be
implemented.
A
In
this
way,
we
can
have
a
complete
separation
of
distrust
from
any
other
component.
It's
specified
component
and
we
can
pretty
much
do
whatever
we
want
with
this
hook
and
vendors
can
have
their
their
distress,
and
I
guess
later
we
can
decide
on
how
do
we
want
these
to
be
implemented?
B
So,
without
going
too
much
into
the
functionality
of
it
under
the
underlying
logic,
is
pretty
much
the
same
as
what
the
other
solution
that
we're
proposing,
I
think
diego's
main
point
is
that
he
just
wants
to
separate
it
in
the
code
and
have
nothing
to
do
with
distro's
in
this,
with
this
configuration
mechanism
have
nothing
to
do
with
distros
the
class.
B
However,
you
still
we're
still
expecting
users
to
create
distros
to
use
these
entry
points
right,
it's
pretty
much
exactly
the
same
as
creating
a
distro
and
using
these
convenience
methods
functions
that
we
define
in
the
sdk.
It's
pretty
much
the
same
right,
so
the
question
is
just
like
like
which,
which
do
we
want
to
go
like
which
looks
better
right,
which
executes
better
and
which
covers
the
most
use
cases
that
we
want
right.
F
I
guess
I
could
look
at
the
pr
too,
but
my
biggest
question
would
be
where,
where
are
you
initializing
the
tracer
provider
in
this
pr?
That's
the
biggest
question
for
me.
A
A
One
is
the
one
that
is
defined
in
the
spec,
that
is
sdk
specific,
and
that
is
related
to
the
apr
that
you
have
opened
already
and
that's
pretty
much
the
code
that
is
right
now
living
in
these
private
methods,
there's
a
separate
kind
of
configuration
that
is
vendor
related
that
we
intend
to
target
by
using
distrust,
and
that
is
related
to
our
instrumentation
and
that
kind
of
configuration
could
use
these
kinds
of
hooks.
A
So
there
are
two
separate
things:
if
you're
thinking,
if
you're
concerned
about
how
the
tracer
providers
are
going
to
be
configurated,
and
if
that
configure
that
specific
configuration
piece
is
specified
in
a
related
suspect,
then
this
is
not
the
place
where
it
will
happen.
It
will
happen,
probably
in
in
the
function
in
the
private
functions
that
you
already
have.
F
Okay,
yeah,
because
then
I
agree
with
leighton
that
this
is
kind
of
just
a
different
way
to
do
distro
hooks,
because
our
solution
already
does
this
right.
It's
just
instead
of
having
well,
I'm
pretty
sure
that
this
exact
file
that
you're
looking
at
said
customize,
it
normally
does
distro
dot
like
start
or
something,
and
then
distros
will
do
it.
Instead
of
that,
you
just
changed
it
to
an
entry
point
right,
so
then
just
chose
could
register
an
entry
point.
So
it's
not.
It's
definitely
a
different
solution,
and
we
can.
We
can
definitely
consider
it.
F
A
Talking
about
your
pr,
I
definitely
need
to
take
a
better
look
at
the
sdk
at
what
the
sorry
at
the
sdk
spec
the
what
the
sdk
specs
says
about
the
then
the
configuration
for
the
sdk
itself,
and
I
I
think
your
pr
is
the
the
right
effort
to
solve
that
sdk
specific
configuration
issue
that
we're
having
now.
A
A
Now
that
being
said,
that,
if
you
make
a
difference
that
does
tracer
provider
configuration,
I
mean
for
the
sdk
and
you
use
this
mechanism
and
you
run
open
telemetry
instrumentation,
then
that
distro
will
do
the
configuration
the
that
is
specified
for
the
sdk
right.
I
mean
I'm
not
saying
that
this
mechanism
can't
do
the
the
sdk
specific
configuration.
I'm
just
saying
that
is
it's
conceptually
intended
to
do
something
something
else
right.
B
Yep:
okay:
let's
open
up
the
floor
of
the
room.
Everyone's
been
really
quiet
about
this,
and
I
think
this
is
a
very
important
topic.
If
you
guys
have
thoughts
on
this,
please
bring
it
up
now
we
want
to
move
this
forward
and
not
just
have
a
discussion
about
it
that
will
go
stale
after
a
while.
So
does
everyone
understand
the
problem
set
and
like
what
our
current
solutions
are?
C
Yeah,
I
think
I
think
I'm
in
line
generally
with
whatever
was
said
for
this
specific
we
are.
I
guess
I
did
not
understand
completely
like
the
problems
it
solves.
I
see
we
replace
one
entry
point
with
two
like.
If
I
imagine
the
new
entry
points
are
just
called
open
element
register
instead
of
configurator,
then
probably
I
need
to
go
through
this
in
detail,
but
I
don't
see
like
what
this
solves.
I
see
one
fundamental
difference
is
here:
we
are
loading
all
the
entry
points
and
in
a
loop
applying
all
of
them.
C
So
essentially,
we
are
supporting
multiple
hooks
while
as
distro
at
least
right
now
supported
only
one
distro
like
we
just
took
the
first
one.
So
that's
the
only
fundamental
difference
I
see
other
than
that.
I
see
just
like
some
reorganization,
I
think
and
and
two
hooks
pre
and
post.
So
I
I
I
guess,
I'm
not
very
sure
like
what
what
problems
this
will
make
easier.
So.
A
A
I
will
separate
this
pr
into
two
so
that
it
will
be
much
easier
to
understand
the
intention
that
one
has
the
other
pr
has
this
pr
that
will
introduce
the
these
two
hooks.
I
considered
much
more
important
than
the
second
pr
that
is
just
another
suggestion
that
I
have
of
how
these
trusts
have
been
implemented,
and
that
ua
and
I
have
been
arguing
in
this
long
discussion
that
we
have
had
before.
B
Wait,
diego
yeah.
C
C
Yeah,
I
think
that
makes
maybe
separating
them
would
clarify
the
intentions.
I
guess
one
question.
You
said
that
it's
sorry,
I
forgot
exactly
what
to
use,
but
you
said
that
it's
important
for
you
that
replacing
the
one
hook
with
two
hooks
is
important
for
you,
like
I'm
trying
to
understand
why
that's
the
case.
A
Okay,
first,
I'm
not
replacing
one
of
cook
with
two
I'm
adding
two
new
hooks.
So
let's
see
we
before
we
had
just
the
open,
telemetry
instrument
hooks,
you
know
open
telemetry
instrument
hooks.
A
What
this
pr
is
just
is
doing
is
keeping
things
just
as
they
were
before,
but
adding
a
hook
before
and
a
hook
after
this
open
telemetry
instrument
group.
The
idea
with
that
is
that
the
distros
can
hook
themselves
into
this
first
telemetry
pre-instrument
hook,
and
in
that
way
these
truss
will
be
completely
separate
from
instrumentations.
A
Not
instrumentations
right
instrumentation
from
the
open
tournament
to
instrumentation
is
because
right
now
the
open
elementary
instrumentation
component
has
the
basis
for
class.
We
can
very.
C
E
Okay,
okay,
so
my
my
takeaway
from
this
discussion
is
that
currently-
and
I
added
notes
around
here
so
currently,
the
distro
is
doing
things
like
provide
configuration
that
should
be
in
the
sdk.
This
is
what
nathaniel's
pr
looks
to
address
provides
methods
that
would
be
beneficial
for
other
distros.
E
That's
something
we
need
to
figure
out
what,
where
exactly
that's
going
to
live,
because
right
now,
based
on
the
10lspr,
that's
being
moved
into
the
sdk,
but
there's
a
discussion
to
be
had
as
to
where
the
right
place
for
that
would
be
for
like
base
distro
or
whatever,
I
think,
there's.
The
concept
of
distro
is
currently
loaded
by
the
instrumentation
package,
like
diego
just
pointed
out
with
this
pr.
E
So
if
you
want
to
split
that
component
out
of
this
pr
and
to
its
own
pr,
so
we
can
have
like
a
clear
this
is
separating
the
instrumentation
from
distro
altogether
pr.
I
think
that
would
be
a
good
step
to
move
forward
and
then
there's
the
last
thing
which
it
provides
like
the
open,
telemetry
recommended
configuration
which
would
be
like
you
know,
the
default
sdk
trace
provider
and
the
like
otlp
exporters
and
the
random
id
generator
and
all
that
stuff.
E
I
feel
like
that
that,
like
that's
in
essence,
all
that
the
open
telemetry
distro
package
should
ever
be
a
anymore.
It's
just
like
here's,
a
couple
of
things
that
it
configures
for
you
and
if
you're
a
vendor
or
you're
a
user,
and
you
want
to
create
your
own
distro.
You
can
take
this
as
a
template.
It's
like
a
very
small
amount
of
work,
a
very
small
amount
of
code
that
exists
and
you
can
just
go
and
implement
it
with
your
own
settings.
E
A
A
I
just
want
to
set
expectations
that,
even
if
we
solve
all
these
problems
that
we
have
discussed
in
this
meeting,
we
still
have
a
pending
problem,
and
that
is
the
actual:
how
to
implement
the
business
right
where
there
are
several
ideas
of
only
enforcing
only
one
distro
or
using
another
environment.
A
B
A
That
it
has
not
actually
that
has
nothing
to
do.
I
don't
have
the
issue
that
I
have
with
nathan's.
Pr
is
just
that
these
methods
are
now
private,
and
that
means
they
just
can't
be
used
by
anyone
all.
B
Right
like
this
is
we
we
don't
know
where
they
should
exist
yet,
do
you
still
have
a
problem
with
the
interim
being.
A
Okay,
I
I
will
always
have
a
problem
with
them
being
private
if
the
intention
is
for
some
someone
else
outside
of
the
sdk
package
to
use
them,
because
that's
just
python
common
usage
right.
So
what
I
mean
is
that
if
I
have
understood
things
correctly,
I
believe
that
the
sdk
specification
says
that
there
is
some
configuration
that
the
sdk
should.
F
A
And
this
code
that
nathaniel
has
added
in
this
pr
introduces
that
sdk
specific
configuration
that
we
want
and
that,
and
that
means
that
if
we
make
these
methods
public,
we
will
be
spec
compliant
and
we
will
be
solving
the
sdk
configuration
problem.
B
A
Okay,
that's,
but
that's
an
excellent
point.
Laden
is
the
fact
that
the
sdk
only
sorry
the
spec
only
says
that
the
sdk
should
be
configured
in
some.
A
How
so
one
solution
will
be
to
just
make
the
the
code
that
senate
has
added
in
this
pr
public
and
the
application
code
needs
to
specifically
call
these
functions
to
before
doing
anything
else,
or
it
could
be
done
in
some
other
way.
It
could
also-
and
this
is
a
kind
of
worms,
of
course
right-
be
part
of
this
role.
I
haven't
yet,
given
that
too
much
thought,
because
so
far
my
ideas
have
been
always
sdk
configurations
separate
from
this
this
for
configuration.
B
The
only
the
only
thing
that
talks
about
sdk
configuration
is
the
link
that
alex
just
posted,
so
maybe
take
a
look
at
that,
and
you
know
you'll
see
why
it's
it's
not
as
explicit
as
you
you
think,
right
like
it
doesn't
have
to
be
like
very,
very
you
got
to
do
this.
A
certain
way
has
to
be
inside
the
sdk.
It
has
to
be
extendable
kind
of
thing.
B
C
I
think
we'll
be
able
to
answer
them
like,
in
another
sake
or
another,
two
things,
but
since
this
is
private,
I
think
we
can
merge.
This
unblock,
titanium
doesn't
harm,
anyone
doesn't
increase
public
api
surface
and
maybe
in
a
couple
of
segments
we
have
a
better
idea
about
what,
where
they
should.
We
can
maybe.
A
Move
us
through
the
description
package:
okay,
if
we
merge
nathaniel's
pr,
we
will
be
going
against
python
common
use,
but
because
we
will
be
pretty
much
exposing
private
functions
with
the
intention
that
we,
the
members
of
the
sig,
use
them
that
will
not
have
any
practical
consequences
right,
because
we
will
just
be
using
a
bunch
of
private
code
here
and
there
and
later
we
can.
A
Change
it
and
if
that's
gonna,
unblock
nathaniel,
I'm
okay
with
it.
If,
because
I
understand
that
this
pr
has
been
sitting
there
for
a
while,
but
I
think
that
if
we
follow
that
solution,
we
must
open
up
an
issue
for
finding
a
final
solution
for
this
problem.
Yes,.
G
B
G
A
The
way
I
see
this
is
that
this
is
just
another.
The
the
documentaries
right
now
in
the
screen
is
just
another
part
of
the
spec
that
we
need
to
implement
and
we
still
haven't
feared
at
all.
A
It's
yeah.
E
I
I
just
want
to
point
out.
I
know
we
only
have
three
minutes
left
on
the
discussion
of
what
of
how
we
should
handle
more
than
one
distro,
and
you
know
whether
two
distro
should
coexist
or
only
one
should
be
selected
or
if
an
environment
variable
should
be
made
available.
I
think
that's
a
discussion.
We
should
probably
have
at
the
s
spec
level,
because
if
a
distro
is
already
part
of
the
spike
we're
becoming
part
of
the
spec,
we
should
have
yeah
that.
E
A
Yeah
definitely
just
something
else.
I
won't
be
I'm
out
of
office
today
and
tomorrow,
I'll
I'll
still
try
to
make
this
separation
of
my
pr
into
two
pr's
today,
probably
at
night.
Just
I
I
I
can't
do
it
right
now,
but
I'll
I'll
try
to
do
it
later,
because
I
understand
this
is
oriented,
but
I
need
this
just.
F
Thanks
guys,
I'm
I'm
pretty
happy
with
the
solution.
I
agree
like
I
want
to
point
out.
I
don't
think
my
pr
is
going
to
solve
all
the
problems
either,
but
I
think
it
it
solves
a
bigger
problem,
one
where
you
can't
use
any
other
distro
and
replaces
it
with
a
smaller
problem
for
now
which
we
definitely
should
fix
and
change
in
the
future.
But
at
the
very
least
like
you
know,
everyone
else
can
start
making
dishes
and
we
can
start
to
see
what
the
experience
is
like
and
change
it
afterwards
as
you
need
it.
A
And
definitely
nathaniel
your
pr
is
the
first
step
in
the
in
the
right
direction.
I
mean
this
is
something
that
we
need
to
solve
and
that's
how
we're
gonna
solve
it
by
following
the
path
that
you
have
started
with
yoga.
B
Okay,
cool
nice,
all
right,
so
we've
got
one
minute
left.
Does
anyone
else
have
any
comments
about
this
topic
or
any
other
thing
any
other
topic?
We
got
our
release
out
this
week,
yeah.
B
E
B
B
People
will
believe
you
yeah
that's
pretty
much
the
path.
Yeah,
that's
pretty
much!
Those
are
the
announcements.
Okay,
so
probably
we'll
have
a
dedicated
flushing
this
stuff
out
and
yeah.
I
think
that's
time
I
will
see
you
guys
next
week
then.