►
From YouTube: 2022-02-03 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).
B
C
Hey
always
or
diego
can
one
of
you
drive
the
meeting
today
I
have
to
leave
about
halfway
through.
D
Okay,
well
welcome
ready
to
another
edition
of
the
python
sign.
D
So,
as
always,
please
add
your
name
vietnamese
list.
If
you
have
any
topics,
issues
or
prc,
you
want
to
discuss.
D
C
Oh
yeah,
sorry
I
was
gonna
say
we
to
do
some
introductions.
First,
I
guess
because
we
have
a
couple
of
newer
people.
I
think
sure.
While
I
gather
my
thoughts
for
that
pr.
C
Yeah
sure
hi
everybody
who's
new
to
the
python
stick.
My
name
is
layton.
I'm
one
of
the
maintainers
here
I've
been
working
on
this
project,
pretty
pretty
much
since
inception.
So
if
you
have
any
questions,
you
know
feel
free
to
ask
here,
or
you
can
message
me
through
slack
as
well.
D
E
So
yeah
I
work
at
splunk
and
I'm
also
I've
been
here
on
on
the
project.
I'll
mostly
be
focusing
on
placing
and
instrumentation,
but
hopefully
in
like
one
person
I'll
start
so
yeah
feel
free
to
reach
out.
If
you
have
any
questions
about
anything
or
want
to
contribute
to
some
specific
thoughts,
diagnosis.
A
I
can
go
next,
hey
everyone!
I'm
alex
I've
been
with
the
open,
telemetry
python
project
for
over
two
years
and
I'm
also
a
contributor
to
the
collector.
I
work
for
lightstep.
F
I
go
next
hi.
My
name
is
philip.
It's
my
first
time
in
here
I
currently
work
for
hike
home
and
I've
been
involved
in
hotel.
Now
I
mean
mostly
since,
like
december,
trying
to
approve
docks
across
the
board
and
yeah
that's
about
it.
G
Hi
everyone,
my
name,
is
nina,
I'm
moving
to
only
I'm
from
splunk,
I'm
moving
to
a
way's
team
within
the
next
months,
or
so
so
I'll
be
contributing,
hopefully
into
python
and
about
two
years
ago
also
a
little
bit
helped
with
the
js
sig.
But
wanna
do
python
so
excited
to
be
here
and
you'll.
See
more
of
me
in
the
coming
months.
C
H
So
I
have
started
working
on
hotel
python
few
months
back
around
two
months.
I
work
at
cisco.
H
Working
with
open,
telemetry
python
agent
since
last
two
three
months,
so
I'm
really
excited
to
be
here
and
yeah
going
forward.
You
will
see
more
of
me
hopefully.
E
Guys,
by
the
way,
great
work
on
the
server
span
thing
you
did
across
all
the
server
frameworks.
Thanks
for
that,
thank
you.
D
Right
great
welcome
everybody,
and
well
usually
at
these
meetings.
We
start
with
the
prs
sorry
with
the
topics,
but
I
think
that's.
Those
are
all
the
topics
over
go
straight
to
the
aprs.
I
can.
Can
you
see
these
pr
merchant
synchronous,
synchronous,
home
aggregations,
because
I
have
no
idea
what
I'm
sharing?
D
C
It's
better
okay,
yeah,
sorry,
so
I
just
had
a
one,
quick
clarification
for
this
pr.
What
you
pointed
out
was
the
you
know.
Are
we
really
sorry?
It's
the
it
seems
like
we
associate
synchronous
with
delta
and
asynchronous
with
cumulative,
so
that
was
like
the
like.
C
I
I
learned
this
kind
of
after
I
I
commented
so
it
I
just
wanted
to
like
confirm
if
if
this
was
true
or
not-
and
this
is
what
we
were
using
as
a
indicator,
because
I
think
I
think
you
also
said
this
here
in
that
comment,
I
think
it's
one
of
the
resolved
ones.
C
The
first
one
I
think,
yeah
so
right
at
the
bottom,
it
says
yeah.
You
asked
a
really
good
question
yeah.
So
I
know
like
it
says
briefly
in
the
api
docs,
it
says
you
know
the
the
synchronous
functions
taken,
assume
that
it's
like
a
delta
value
right
and
the
callbacks
produce
a
just
a
value,
but
we
we
just
assume
that
it's
cumulative.
I
guess,
is
this
a
correct
assumption
to
make
or
am
I
is
there
somewhere
else
in
the
specs
where
it
explicitly
says
this
that
we
can
assume
the
temporality
type.
I
I
yeah
I'm
just
gonna
say
that's
the
case.
I
think
a
lot
of
there's
a
lot
of
confusion
around
this.
In
this
fact
at
least
I
know
like
the
old
javascript
implementation
had
this
wrong
because
it
is
kind
of
confusing.
What
are
we
going
to
say?
Do
you
go
and
I'm
going
to
look
for
the
exact
wording?
While
you
talk.
D
Okay,
so
we
are
now
considering
pretty
much
cumulative
to
be
a
an
identifier
of
or
or
something
that
is
associated
with
the
synchronous
instruments
and
vice
versa
with
delta.
But
I
don't
see
any
reason
to
have
a
maybe
an
asynchronous
instrument
that
will
receive
delta.
D
But
what
I
was
concerned
is
the
fact
that
we
are
making
this
association
between
instrument
synchronicity
and
aggregation
temporality,
and
maybe
we
should
instead
use
the
instrument
synchronicity,
which
is
directly
tied
to
the
instrument
instead.
G
I
D
I
Oh
no!
Okay,
if
you
just
search
for
note
colon,
unlike.
I
Yeah,
so
I
think
it
is
kind
of
subtle.
If
you
keep
the
use
cases
in
mind,
it
makes
a
little
more
sense.
So,
if
you
think
about
like
oh,
I
want
to
scrape
a
proc
file
system
for
cpu
time,
and
you
know
like
process
metrics
and
stuff,
like
that.
Those
are
almost
always
reported
as
cumulative,
because
you
all
you
can
do
is
see
the
absolute
value
right.
D
D
Yeah
so
yeah.
I
guess
that
this
this
could
pretty
much
be
a
you
know,
a
requirement
to
something
that
is
actually
very
important.
I
It
is
a
requirement,
but
it's
sort
of
a
thing
where
it's
like
it
doesn't
change
the
shape
of
the
api
right
like
we
might
change.
I
think
we
have
name
the
parameters
to
make
it
clear
so,
like
you
know
like
we
in
the
counter
dot
add
it
says,
I
don't
remember,
says
value
or
amount
but
beyond,
like
they've,
both
taken
an
integer
right.
So
the
best
thing
we
can
do
is
write
good
documentation
and
make
sure
it's
clear
to
users
how
to
use
it.
D
Right,
yeah
right,
but
well
with
finding
aaron
now
I
would
certainly
definitely
not
expect
this
to
be
all
right.
C
So
I
will
I
will.
I
will
make
a
comment
explicitly
stating
that
out
that
we're
going
to
be
using
this,
that
we'll
be
assuming
that
users
will
be
using
it
this
way,
because
we
have
logic
in
our
code.
That
assumes
that
this
is
true,
for
example,
the
temporality
conversion,
pr
that
you
have
up
next
so.
C
D
We
have
another
pr
degradation
to
broad
conversion
algorithm.
I
guess
pr
is
mine,
but
I
did
not
add
these
two.
C
I
I
added
it
all
right,
also
for
the
previous
pr
do
we
have
everything
to
merge
this
or
like
move
this
forward
as
they're
still
kind
of
open.
C
D
I
think
I
remove
this
check,
as
are
indicated
here
right,
so
this
conversation,
I
think,
is-
should
be.
It
should
be
possible
to
solve
the
market
assault.
D
Okay,
I
did
all
right
then
open
conversations.
D
D
I
Right
right,
so
this
was
a
bit
of
an
edge
case
that
the
optional
part
does
basically
well.
I
haven't
had
a
time
had
a
chance
to
look
back
at
your
comments.
Do
you
go
but.
D
Sure,
if
you
want
to
just
be
decent
when
you
have
a
chance,
okay,
okay
yeah
later
so
I
think.
C
Yeah,
so
I
think
back
back
to
the
okay
cool
yeah,
so
yo
aaron,
thanks
for
the
explanation
this
this
makes
sense
to
me
now
just
have
a,
I
guess,
a
follow-up
question
not
related
really
related
to
this
appear.
It's
a
so.
If
does
this
mean
that
whoever,
when
we
do
call
this
convert
aggregation
temporarily,
we
would
have
to
keep
track
of
the
previous
point
and
also
make
sure
that
it's
cumulative.
I
Yeah,
that's
right
so
the
component
above
this,
which
is
like
the
the
thing
that
holds
the
streams,
essentially
we'll
just
save
the
previous
point
as
a
cumulative,
so
essentially
there's
some
optimizations.
We
can
do
there,
but
right
now,
it's
going
to
keep
one
cumulative
point
for
the
previous
collection
interval
to
use
just
for
this
conversion
part.
I
C
I
C
Okay,
yeah,
that
makes
sense
to
me
cool
thanks
that
that's
that
that
was
it
cool,
oh
and
the
pr
looks
good
to
me,
so
I
think
yeah
any
anything
we
can
move
forward
with
it.
Let's
just
try
to
get
this
in.
D
Yeah,
I
think
we
only
need
this
conversation
from
secant.
D
And
this
coming
from
error
to
be
solved,
and
then
you
can
move
forward
you
can
hear.
I
don't
believe
so.
All
right
I'll
send
a
lot
of
comment
here,
just
to
remind
all
right
what
else
we
have
here.
Do
you
want
to
talk
about
this
vr
now.
C
Yep,
okay,
so
I
think
ost
has
already
taken
a
look
at
this
thanks.
Thanks
for
your
comments,
always
so.
Basically,
I
think
I
briefly
talked
about
this
a
couple
of
weeks
ago.
We're
trying
to
the
the
effort
is
trying
to
push
the
http
semantics
conventions
to
the
first
1.0
and
as
part
of
that,
there's
an
otep
that
outlines
the
scope
in
which
we
want
to
cover
pretty
much.
I
think
most
of
the
topics
have
been
addressed
already.
C
C
So
this
is
still
up
the
design
still
up.
Sorry,
the
the
entry
of
this
into
the
spec
is
still
up
for
debate
and
discussion,
primarily
because
they're
not
sure
whether
or
not
this
can
be
done
and
implemented
in
all
languages.
Net
has
already
made
a
prototype
for
this,
and
it's
a
pretty
simple
solution,
because
they
they
all
share
the
same
underlying
hdb
library.
C
Basically,
this
effort
is
to
see
whether
or
not
we
could
do
this
in
python
and
there's
other
representatives
trying
to
do
this
in
other
languages
as
well.
So,
if
we
try
to,
if
we
present
like
a
prototype
or
a
possible
solution
to
be
done
automatically
with
python,
it
will
really
help
drive
the
conversation
as
well
as
the
actual
design,
as
you
can
see,
that
is
occurring
within
the
discussion
always
dennis,
and
I
are
having
so
basically
it'd
be
great.
C
If
people
can
take
a
look
at
this,
I
know
it's
a
pretty
long
description,
so
if
you
have
any
questions,
feel
free
to
feel
free
to
reach
out
but
yeah.
This
is
a.
I
still
have
it
in
draft,
because
it's
still
it's
like
the
implementation
details
are
still
changing.
It's
it's
kind
of
like
driving
the
implementation
specifics
of
this
spec
as
well.
So.
B
D
Right
yeah,
I
I
haven't
had
a
chance
to
take
a
look
into
this
whole.
C
C
C
Yeah,
so,
in
the
conversation
basically
currently
the
how
url
lib3
works
is
the
retries
are
done
using
recursion,
whereas
the
redirects
are
actually
handled
separately
in
a
separate
call,
meaning
that,
for
the
re
retry
case,
all
of
the
spans
generated
will
be
children
of
the
original
request.
So
that's
how
I
was
implemented,
whereas
the
other
one
is
like
two
separate
trace
trees.
C
So
there's
not
an
explicit
there's,
nothing
explicit
in
the
specs
yet
telling
what
the
relationship
between
the
this
the
multiple,
if
multiple
retry
spans,
as
well
as
the
original
request
so
like
the
original
proposal,
was
the
current
design
that
I
had
now,
where
they're
all
like
a
for
all
the
retries.
It's
like
a
giant
trace
all
all
children
of
each
other.
C
I
think
we
decided
upon
the
fact
that
the
the
retry
spans
will
have
no
relation
with
any
of
each
other
or
the
original
request
in
terms
of
parent-child
relationships.
The
only
thing
that
connects
them
together
is
these
these
links.
C
So
I
think
that's
the
result
of
that
discussion
always
did
bring
up
another
point
right
after
this
is.
There
are
some
cases
in
which
there
are
several
retries
and
then,
if
we
do
go
with
the
design,
it
would
be
it'll,
be
several
different
traces
all
with
like
links
with
each
other
right.
That
is
a
that
is
a
good
concern
and
he
proposed
that
we
might
want
to
like
encapsulate
them
within,
like
a
like,
a
like
a
encapsulating
span
or
an
encompassing
span.
That
represents
the
entire
single
original
request.
C
That's
supposed
to
be
that
the
a
single
logical
operation,
but
that
that
was
left
like
we
might
want
to
just
iterate
on
the
the
specs
right
now,
because
the
implementation
for
that
might
be
a
bit
complicated.
So
yeah,
that's
that's
pretty
much
the
discussion
that
we
had.
I
Was
always
concerned
that
all
like
are
all
of
them
linked
together?
So
if
you
have
like
10
retries,
each
of
those
spans
can
have
like
any
number
of
links.
Do
they
link
to
all
of
the
siblings
or
do
they
just
link
to
the
initial
request.
C
No
so
yeah
good
question,
so
each
of
the
retries
links
to
the
previous
retry
attempt
that
was
made.
So
in
terms
of
the
links,
it's
all
like
one
sequential.
C
Path,
I
guess
I
think
the
issue
at
hand
was
the
the
fact
that
the
the
retries
are
like
children's
of
each
other.
If
that
makes
sense,
and
not
the
links
themselves
right.
I
E
Sorry
yeah,
so
the
the
main
point
of
concern
was
that
if
eddie
tri
is
a
child
of
the
previous
director
span,
then
we'll
end
up
with
multiple
blind
spans
and
each
being
like
children
of
each
other
and
be
weird
to
have
a
client
span
not
have
a
server
span
as
a
child.
So
I
think
that
was
the
main
concern.
E
D
All
right
great,
let's
see,
if
we
have,
I
don't
think
we
have
any
more
pr's,
but
we
have
a
couple
of
issues.
Let's
take
a
look
at
this
one,
I
oh
yes,
I
think
I
added
this
one.
This
is
a
request
to
consolidate
other
documentation
in
one
single
place.
D
Shelling
here
mentions
that
we
have
our
getting
started
documentation
in
two
places.
The
canonical
source
should
be
this
one.
So
I
personally
agree
with
that.
I
think
having
the
competition
in
one
single
place
is
the
way
to
go,
and
I
think
shaolin
is
moving.
D
It's
offering
here
to
move
the
pages
to
this
location
wanted
to
know.
If
anyone
else
has,
I
can
speak.
F
A
little
bit
towards
this
there
we
go
yeah.
So
this
comes
from
a
previous
issue
that
I
had
filed
that
comes
from
kind
of
a
comprehensive
scorecarding
effort
of
like
all
of
the
docs
for
the
different
languages,
and
so
one
of
the
things
that
we
basically
determined
on
the
python
side
is
that
the
docs
are
actually
pretty
damn
comprehensive
compared
to
a
lot
of
the
other
languages
which
is
great,
and
so
initially
I
filed
an
issue
that
was
like
hey.
You
know
it's
not
a
lack
of
content
thing.
F
It's
you
know.
Maybe
some
stuff
could
kind
of
be
shuffled
around
and
reorganized
so
that
so
that
things
are
a
little
discoverable
like.
I
got
some
feedback
from
a
couple
customers
on
the
honeycomb
side,
who,
like
didn't
know
that
automatic
instrumentation
be
an
agent
was
possible
and
I'd
have
to
you
know,
be
like
hey:
well,
here's
the
docs
for
it
and
then
they'd
say:
oh,
I
didn't
realize
that
was
there,
and
so
that
kind
of
led
me
to
believe
that.
F
Okay,
maybe
there's
a
discoverability
thing
that
could
be
dealt
with
so
that
was
approved
and
the
suggestion
was
to
make
sure
that,
like
links
don't
break.
So
I
spiked
on
that
a
little
bit
on
the
read
the
docs
site,
but
I
found
that
it
was
kind
of
it
was
taking
more
time
than
I
thought
it
would
I'm
not
as
familiar
with
sphynx,
and
I
knew
that
like.
F
I
would
have
to
install
a
separate
package
into
the
docs
infrastructure
to
enable
redirects
in
the
first
place,
and
then
I
just
brought
this
up
in
the
docs
website.
Sig
basically
say
hey,
this
is
kind
of
what's
happening
and
it's
going
to
take
a
little
time,
but
eventually
we're
going
to
link
to
it
and
then
we
kind
of
talked
about
it.
F
Why
don't
we
just
pull
the
docs
into
the
website,
repo
and
reorganize
at
the
same
time,
instead
of
reorganizing
one
place,
pull
them
in
and
then
likely
have
to
reorganize
a
second
time,
so
that's
sort
of
where
this
this
all
comes
from
so
anyways?
That's
my
spiel
about
the
context
for
this
issue.
D
All
right,
it's
a
great
explanation
is:
is
there
an
an
action
item
for
us,
maintainers
or
provers
to.
D
Yeah
is
there
something
that
do
you
need
us
to
do
for
you.
F
I
don't
I
don't
think
so
we
would,
I
mean
it
would
be
kind
of
a
copy-paste
effort
to
pull
stuff
into
the
dock
site.
I
have
a
pull
request
on
the
dockside
is
just
a
draft
that
shows
like
a
potential
layout
of
the
docs.
F
It
wouldn't
be
the
same
as
the
the
read
the
docs
layout,
because
that
this
is
trying
to
make
it
conform
to
the
the
general
layout
that
we
have
for
every
single
language
on
the
doc
site,
but
the
intention
would
be
that
content
is
all
pretty
much
copied
over
like
there
wouldn't
really
be
a
big
rewrite
or
anything
like
that.
The
main
concern
that
I
have
is
links
in
the
world
that
are
pointing
to
the
read
the
docs
site,
like
they
could
still
point
to
that
reader.
F
That
read
the
doc
site-
I
guess,
but
like
maybe
there'd,
have
to
be
some
kind
of
disclaimer.
That
would
be
like
hey
these.
These
docs
are
still
here,
but
really
they've
moved.
Please
go
here
or
something
like
that
kind
of
I.
I
would
sort
of
leave
that
up
to
you
all,
to
sort
of
figure
out
what
the
best
path
forward.
There
is
just
to
make
sure
that
people
who
may
be
thinking
that
they
need
to
go
to
the
read
the
doc
site,
don't
get
misled.
C
Yeah
you're,
you
are
a
car
temp
right.
Yes,
oh
nice,
okay,.
D
Great,
so
I
I
just
wonder
if
I
see
that
this
issue
is
tracked
here
also
in
this
repo,
I
I'm
okay
with
keeping
this
this
issue
open.
If
it
helps
you
track
your
efforts
just.
D
Maybe
we
should
add
a
comment
here
that
indicates
that
this
particular
issue
will
not
be
fixed
with
a
pr
to
this.
This
reapers,
as
it
usually
is,
but
it
will
be
fixed
with
the
vr
in
some
other
room.
F
Yeah
yeah,
definitely,
I
think
the
the
other
thing
that
would
help
is
sort
of
once
a
draft
of
the
docs
on
the
open,
telemetry
website
repo
are
done.
We
would
definitely
want
to
have
at
least
one
of
you
all
kind
of
give
it
a
look
to
make
sure
that
things
aren't
missing,
or
things
are
organized
in
a
way
that
seems
sensible.
I
don't
know
when
that
would
be,
but
you
know,
probably
in
the
next
couple
of
weeks
I
would
say.
C
C
A
another
issue
that
you
created
related
to
this-
I
think
that
was
the
preliminary
like
hey.
This
is
the
format
that
I
want
to
use
or
something
like
that
right.
F
Yeah
yeah
and
that
one
was
with
respect
to
the
read
the
docs
site
because
the
because
the
open,
telemetry
repo,
there's
kind
of
like
a
fixed
format
for
every
language,
we
would
try
to
make
it
follow
that
format
instead,
so
that
it's
pretty
uniform.
So
honestly,
I
think
that
issue
could
just
get
closed.
I
see.
I
I've
got
a
question
for
phillip.
Also,
sorry,
I
missed
the
introductions
but
welcome
to
the
python
sig,
and
I
was
wondering
like
where
does
the
line
get
drawn
for
non-api
docs?
So
you
probably,
you
probably
saw
that
a
lot
of
our
sphinx
documentation
is
in
the
code
in
doc.
Strings,
including
like
module
level
doc
strings,
so
not
necessarily
api
documentation,
but
more
like
you
know,
like
documentation,
not
getting
started,
but
you
know
it's
sort
of
like.
F
Yeah
I
mean
under
the
docs
folder
there's
the
subfolder
api.
My
understanding
is
all
of
that
is
kind
of
that
module
level
api
dock
stuff.
I
don't
personally
see
any
reason
to
move
that
over
to
the
hotel
side,
especially
if
that's
pieced,
together
with
like
auto-generated
things
from
doc
strings.
But
you
know
yeah.
F
Yeah,
there's
no
currently
there's
no
effort
on
the
hotel
website
repo
side
to
try
to
pull
in
any
api
docs,
largely
because
those
are
those
are
off
times
just
generated
from
the
code
themselves,
and
so
that
would
probably
make
things
way
too
complicated.
I
Yeah,
so,
just
as
like
an
example,
so
the
api
folder
is
like
open,
telemetry
api
package,
docs
generated
from
the
code,
but,
for
example,
like
the
link
I
just
put
in
the
chat,
there's
like
a
little
blurb
about
trace
the
trace
package
and
it's
not
it's
not
exactly
api
documentation
and
some
of
it
is
sort
of
just
like.
Oh
you
know,
here's
how
you
do
it
and
maybe
the
answer
is
we
don't
need
this
at
all,
but
yeah.
I
We
also
have
like
a
lot
of
examples,
and
you
know
exporter,
docs
and
stuff
like
that,
like
how
much
of
that
would
we
want
to
move
over.
F
Yeah,
so
I
I
did
kind
of
like
a
little
audit
pass
over
over
these
things
to
just
sort
of
see
like
if
there's
so.
First
of
all,
there's
there's
a
good
amount
of
like
code
samples
in
this
format
that
are
actually
also
kind
of
duplicated
in
some
of
the
non-api
docs,
and
so
that's
there's
really
no
loss
of
information
there.
I
think,
as
a
part
of
this
effort,
we
might
do
a
pass
over
each
of
these
module
level
things
to
see.
F
If
there's
like
useful
descriptions
that
could
just
be
like
copy
paste
it
over
into
a
relevant
section
somewhere.
I
think,
like
keeping
them
in
this
format.
That
they're
in
today
doesn't
hurt
anybody
at
all.
So
I
wouldn't
see
any
reason
to
like
move
them
or
or
remove
them
in
any
way.
E
One
way
to
think
of
it
would
be
we
keep
the
api
docs
on
three,
the
docks
and
any
docks
for
a
specific
package
like
that
explains
what
this
package
does
there,
but
on
the
open,
telemetry
site,
we
have.
We
document
like
use
cases
how
to
do
context
propagation,
how
to
do
order
instrumentation
that
are
like
cross
package
concerns,
but
explain
how
to
achieve
a
specific
use
case.
F
Yeah
that
that's
exactly
right,
that's
kind
of
what
I
have
in
mind
and
then
like
in
each
of
those
conceptual
like
subsections.
For
example,
if
there's
like
a
relevant
link
to
the
api
docs
or
some
sort
of
thing,
that
gives
a
more
yeah
like
something
like
this
you're
in
the
trace
thing,
and
you
want
to
link
to
a
particular
like
sub
module
in
the
trace
package,
or
something
like
that.
That
would
that
would
probably
be
something
we
would
do.
D
All
right,
great,
that's
fantastic!
If
there
are
no
more
comments,
I
guess
we
can
move
on
to
this
other
issue
that
we
have
here
wait.
This
is
yours.
H
Actually
have
put
the
issue
here,
I
have
put
down
the
issue.
Actually
we
have
some
problem
understanding
the
concept
for
a
I
mean
aci
instrumentation,
so
I
thought
it's
better
to
discuss
with
you
guys.
Maybe
I
mean
you
guys
can
help
me
on
this.
H
So
the
thing
is
that
for
a
fast
api
as
fast
you
guys,
based
into
the
use
the
asdi
middleware.
So
whenever
we
you
know
instrument
so
for
I
was
actually
basically
creating
a
pr
for
test
case
for
asia
and
in
that
pr
I
mean
in
that
test
case.
H
Basically,
I
faced
an
issue
when
I
created
a
parent
stand
and
tried
to
propagate
it
to
the
server
side,
but
unfortunately
the
parent
span
was
not
considered
as
a
proper
span
and
the
instrumentation
instrument
doesn't
create
its
own
server
span,
which
was
not
expected,
so
that
happens
only
for
the
asgi
based
middleware
framework,
but
not
for
the
wsgi
based.
H
So
we
just
wanted
to
understand
how
the
context
is
being
propagated
in
case
of
asgi,
so
we
couldn't
get
the
idea
I
mean
I
couldn't
get
the
idea
how
it
is
being
propagated
because
it
was
not
considering
the
parent
server
span
which
we
created
before
before
we
send
the
request,
and
once
we
signed
the
request
so
in
the
middleware
it
was
creating
its
own
serviceman.
H
So
I'm
not
sure.
Maybe
I
can
share
my
screen
and
explain
the
issue.
Otherwise
I'll
confuse
you
guys.
H
Okay,
so-
and
this
is
this-
is
one
of
the
test
case
that
I
have
created
for
framework
and
in
that,
in
this
case
this
is
working
fine.
So
here
it
is,
it
is
able
to
get
the
parent
span,
which
is
type
of
server
span
and
create
a
child
span
of
inter
type
in
kind,
inter
interval.
But
if
I
make
a
change,
let's
say
just
just
to
give
me
a
minute.
H
So,
in
this
case
I'm
oh,
what
is
this?
H
So
here
in
in
in
this
case,
we
are
just
using
the
app
and
instrument
it.
We
have
instrumenting
using
the
asgi
middleware
and
we
just
try
to
send
the
request
using
send
default
request.
So
in
in
this
case
we
are
creating
this
parent
span
of
type
server
and
send
the
request.
H
But
if
you,
if,
if
we
come
here
so
at
that
time,
I
am
expecting
that
the
the
top
stand
the
so
the
the
outermost
pan
should
be
the
parent's
pen,
but
that
is
not
the
case,
so
the
parent
span
is
not
in
the
same
context
as
the
this
internal
span
of
for
asia
middleware.
H
H
B
D
No,
that's
that's
fine.
I
just
I
was
just
wondering:
do
you
have
an
issue
open
for
this.
H
H
At
this
I
mean
my
instrumented
application
with
the
server
stand
at
the
downstream
side,
rather
than
just
you
know,
create
a
parent's
plan
and
propagate
it.
Use
from
the
client
side.
D
H
D
H
Raised
that
pr,
but
the
thing
is
that
to
we
couldn't
understand
why
this
was
not
working.
I
mean
we
resolve
the
issue
in
this
one
with
the
wrapped
app,
but
we
just
don't
know
why
this
was
not
working.
This
was
supposed
to
work
as
expected.
H
Okay,
so
this
is
parent
span,
it's
basically
should
be
the
the
outermost
fan
and
all
the
internal
span
should
be
the
child
of
that
parents,
man,
but
that
is
not
the
case.
Actually
it
creates
his
own.
So
this
parent's
brand
is
not
being
propagated
to
the
server
side
and
it
creates
its
own
service
plan.
Yeah.
E
I
guess
the
set
default
request
is
maybe
creating
a
different
thread
and
sending
it
sending
the
request
in
that.
I
think
what
you're
expecting
is
that,
since
this
is
the
single
python
process
and
it's
created
before
an
http
request
is
sent,
will
be
also
present
in
the
local
context
when
the
server
span
is
created.
But
maybe
there
is
some
setting
going
on
and
context
is
not
propagated
between
times,
but
either
way.
I
guess,
since
we
have
actually
implemented
the
feature
and
and
it's
not
a
blocker
anymore,
so
maybe
we
should.
D
Yeah,
please
file
an
issue
for
this
problem
that
that
you're
having
and
we
can
take
it
from
there
but.
D
You
for
the
detailed
investigation.
D
Right,
I,
I
guess
the
second
are
you
here
right.
D
D
D
I
I
think
osb
is
going
to
ask
you
to
make
sure
that
any
conversation
that
is
still
open.
C
Hey
diego,
since
they
were
on
this
pr,
I
have
a
another
quick
question:
how
are
we
treating
the
the
new
start
time
for
the
output
if
the
new
new
temporality
is
delta?
D
Okay,
if
the
new
temporality
is
delta,
then
I
guess
this
is
the
case
right
and
the
start
time
will
be
the
one.
The
the
timestamp
of
the
previous
point.
C
Right
conceptually
does
does
that
make
sense
to
do
this
to
store,
as
the
previous
points
start
time,.
C
D
D
So
points
have
two
time
measurements
the
start
time,
which
is
the
the
beginning
of
the
sequence
of
points
the
all
belong
to
and
and
each
one
has
a
timestamp,
which
is
the
instant
where
that
point
is
created.
So
we
were
using
that
second
one,
the
timestamp
for
the
of
the
previous
point
as
the
starting
of
the
field.
B
D
It's
not
the
well
yeah
yeah.
Sorry,
it's
the.
B
I
Is
that
is
the
comment
I
made
open
with
the
little
diagram
still.
I
I
Is
it
open
still?
Oh
there,
it
is
the
icon,
yeah
yeah,
so
that
the
case
we're
looking
at
is
you
have
previous
point
cumulative
and
you
have
current
point
cumulative.
You
want
current
point
delta.
So
the
start
time
of
current
point
delta
is
previous
point.
Cumulatives
timestamp
the
end
time
and
the
end
time
just
stays
the
same
for
current
point
delta.
C
B
D
Fantastic,
I
think
oh.
C
C
I
don't
know
if,
if
you
guys
wanted
to
talk
about
like
this
at
the
bottom
there,
it
said
you
would
bring
it
up
in
the
stick
or
we
could
do
it
next
time.
If
there's
still
a
discussion,
do
you
have.
A
E
A
E
This
instrumentation
has
some
encoded
knowledge
about
the
sdk.
Mainly
it
tries
to
extract
resource
from
a
tracer
provider
which
is
not
part
of
the
api,
so
the
so.
The
question
was
whether
so
now
we
have
fixed
it
in
like
disgraceful
deliberation.
E
If
some
other
sdk
is
used
that
doesn't
provide
it,
it'll
still
work
and
just
not
populate
service
name
or
some
other
fields
that
come
from
resource.
So
it
should
work
with
every
single
sdk,
but
it
still
brings
up
the
question.
Should
it
should
instrumentations?
Do
that
and
then
record
also
brought
up
that
we,
we
didn't,
want
to
think
of
this
feature
as
an
instrumentation
and
wanted
to
move
this
feature
to
the
sdk.
E
If
anyone
has
any
thoughts,
we
should
move
this
to
sdk
or,
if
it's
okay,
to
be
an
instrumentation
and
have
like
peaceful
declaration
when
we
discover
our
sdks
not
being
used.
J
J
I
was
wondering
if
we
could
do
that
from
the
spam
instead
of
on
doing
it
from
the
resource,
since
we
are
already
getting
the
context
from
the
current
span
and
and
then
discussion
into
like
whether
or
not
this
should
be
an
instrumentation
okay
with
these
changes
getting
in,
but
just
wondering.
J
Yeah
sure,
but
like
if
you,
if
you
look
at
the
instrumentations,
we
have
right
the
framework
http
lines
like
this.
This
logging
implementation
is
very
different
from
what
yes
correct
yeah.
B
J
C
Right,
I
think,
for
now
we
can
do.
We
could
just
merge
this
change
in,
since,
even
if
they
don't
depend
on
the
rsdk
as
you
as
always
said,
it
wouldn't
break
anything
and
then
deal
with
the
issue
of
whether
or
not
it's
an
actual
instrumentation.
After.
I
Aaron
go
ahead.
Oh
sorry,
okay,
my
question
was:
it
looks
like
this.
Instrumentation
is
basically
like
a
logging
handler
to
attach
to
the
python
logging
api.
Is
that
right.
E
I
Okay,
maybe
I'll
look
at
it
afterward,
because
it's
not
what
I
thought,
but
I
was
thinking
you
know
like
since
there's
no
logging,
yeah,
okay,
that's
different
than
what
I
thought.
So
let
me
take
a
look
at
it
after
the
call,
maybe.