►
From YouTube: 2020-08-27 Python SIG
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
B
A
B
B
B
Yeah
sure
so
yeah
we
didn't
have
a
meeting
last
week,
some
something
messed
up
about
the
with
the
public
calendar,
but
that's
fine
right
now.
I
think
the
main
issues
to
talk
about
are
like
the
the
tracing
spec
alignment
with
sorry,
the
tracing
tasks
to
align
with
the
current
spec
right
now,
I've
been
following
the
spec
really
closely
these
past
couple
of
days
and
just
looking
at
it
like
the
the
primary
focus
is
just
to
get
tracing.
B
The
ga
really
metrics
is
slowly
trudging
along
josh
is
putting
up
like
a
few
metrics
sdk
related
stuff
and
like
some
discussion,
but
the
velocity
is
not
nearly
as
fast
as
like
tracing
right
now,
like
everyone
is
rushing
to
get
their
prs
in.
So
I
saw
a
couple.
People
pick
up
some
tasks
and
like
put
up
some
pr's,
I'm
focused
primarily
on
like
the
sampling
stuff
right
now,
so
I've
been
following
that
pretty
closely.
B
There
is
still
like
a
bunch
of
issues
that
open
issues
that
alex
created
a
couple
weeks
ago.
It'd
be
great.
If
people
started
picking
those
up,
oh,
I
should
be
sharing
my
screen,
but
yeah,
I
guess
yeah.
Those
are
like
the
the
main
things
that
we
gotta
do:
the
which
moves
on
to
the
next
topic,
pretty
quickly,
this
feature
matrix
for
ga.
B
So
if
you,
if
you
guys
follow
that
link,
this
is
a
kind
of
like
a
matrix
for
every
single
language
and
all
of
the
features
that
was
required
for
ga.
I
think
alex,
and
I
will
go
through
this
afterwards
to
see
how
python
is
doing
so
like,
as
you
can
see
like
only
like.
Some
of
it
is
filled
out
most
of
the
trading
and
exporters
part,
mostly
because
we
have
actual
specs
for
those.
Oh
well,
not
the
exporters
but
yeah.
B
So
this
is
pretty
much
a
comprehensive
list
of
what
we
need
by
ga.
So
what
we're
probably
gonna
do
is
go
through
this
and
if
there's
any
like
major
things
that
we're
missing
we're,
probably
gonna
focus
on
those
first
before
you
know
tackling
some
of
the
smaller
issues,
especially
the
the
ones
that
are
like
either
language
specific
or
like
would
be
nice
to
have
so
we're
just
a
little
treat
triaging
needs
to
be
done
yeah,
but
you
know,
if
you
guys
ever
need
to
see.
B
Yeah
and
it
seems
like
we
have
less
and
less
people
joining
the
the
the
sigs,
especially
the
it's
not
concerning
for
me
that
there's
less
people
it's
more
like
the
the
people
who
put
up
prs
in
in
the
the
repo
that
don't
join
the
don't
join
the
meeting.
I
feel
like
their
their
pr's
or
the
issues
that
they
want
to
talk
about,
will
kind
of
not
be
talked
about.
B
Yeah,
I'm
okay
right
now
with
this,
because
we're
focused
only
on
mostly
on
the
ga
tasks,
but
it
does
have
the
problem
of
like
having
stale
pr's
and
issues
open
so
might
want
to.
You
know,
discuss
about
maybe
having
like
a
like
strict
rule
about
like
if
there's
no
activity
about
it.
B
A
B
It's
just
we
have
to
the
best
thing
I
feel
right
now
is
to
say
strictly,
like
okay,
we're
gonna
be
doing
this
like
to
maintain
the
integrity
of
like
and
the
quality
of,
our
our
issues
and
prs,
and
if
we
say
that
we're
going
to
do
it
strictly
today,
then
we
have
to
start
enforcing
that
from
now
on
so
yeah
yeah.
A
B
Yeah
yeah
and
the
pull
requests
like
like
I'm
not
like
this,
there's
not
that
many,
but
we
have
102
issues
open
so
like
some
of
them
are
related
to
stuff.
B
That,
like
is
like,
after
ga
or
you
know,
just
just
opened
by
people
that,
like
aren't
even
part
of
the
community
or
like
who
don't
join
the
sig
at
all
so
and
it
could
be
parade
in
page
three
or
four,
and
it's
not
likely
that
we're
ever
gonna
get
to
it
unless
if
they
come
here
and
like
say
that,
oh
this
is
an
urgent
issue
or
something
like
that.
So.
A
Yeah,
I
wonder
if
yeah
one
of
the
things
that
I've
seen
be
pretty
successful
with
the
spec
anyways
is
to
have
someone
actively
doing
the
triaging.
A
B
Oh
definitely
yeah
yeah,
so
yeah
right
now,
the
pretty
much
the
only
active
reviewers
are
the
people
in
the
sig
in
diego
and
that's
not
nearly
enough
like
we
don't
have
the
the
bandwidth
to
also
triage
everything.
Iteratively,
that's
just
the
reality,
so
I
think
for
the
specs,
like
riley,
took
it
upon
himself
to
like
help
with
the
triaging
and
everything.
B
So
that's
like
out
of
someone's
personal
time.
You
know
so
and
that's
the
specs
repo.
So
you
know
that
must
have
took
like
days
so
yeah
and
that
that's
like
a
high
need
to
because
a
lot
of
people
are
blocking
on
that,
but
for
python.
It's
like
honestly.
Besides
from
the
ga
and
the
tasks,
it's
not
like
show
stoppers
they're,
not
blockers,
so
I
don't
know
how
high
of
a
priority.
This
is.
A
A
Right,
that's
an
example:
yeah
yeah,
that's
just
one
of
them,
but
yeah,
okay,
so
maybe
like
maybe
as
a
as
a
takeaway
item
is
we
should,
at
the
very
least
like
mark
all
of
the
stuff,
that's
to
not
the
api
or
sdk
as
like
lower
priority,
or
something
like
that
and.
A
B
Stuff-
and
I
think,
as
a
general
rule
to
like
people
here
and
also
like
you
know,
the
more
active
members
of
the
sake
like
we
should
try
to
focus
on
the
ga
tasks.
And
you
know
I
will
be
certainly
taking
more
priority
on
like
reviewing
stuff
that
we
need
for
the
release.
B
C
C
A
C
B
Yeah,
a
good
question,
usually
like
the
person
who
created
it
with,
which
is
what
we
had
before
like
address
the
issues.
It's
just
that,
like
the
people
who
made
them
are
like
not
part
of
our
part
of
the
team
anymore,
so
or
sorry,
part
of
part
of
this
python,
repo
anymore
or
not
just
just
not
actively
developing
on
it
currently.
A
Yeah,
I
think
I
think
at
some
point
like
at
a
sig
meeting
months
ago
now,
uk
has
suggested
that
you
know
for
instrumentations.
A
Maybe
the
easiest
thing
to
do
is
like
ensure
there's
nothing
crazy
and
then
be
a
little
bit
more
lenient
on
approving
them,
and
that
was
that
was
kind
of
the
part
of
why
I
was
really
wanting
to
get
all
of
the
instrumentations
into
a
separate
repo
just
to
get
the
like
the
flow
of
approvals
a
little
bit
a
little
bit
more
flexible
than
what
we're
doing
for
the
core
repo,
but
we're
not
we're
not
there
and
we're
not
gonna
have
time
to
focus
on
moving
those
out
but
like
maybe
we
can
still
follow
the
same
kind
of
you
know
review
it.
B
If
we
do
move
it
to,
like
I
mean
like
hypothetically,
if
last
time
we
did
move
it
to
like
a
separate
repo
like
who
would
who
would
own
that
right?
I
feel
like
right.
We
would
still
have
to
have
cycles
to
do
all
that
maintenance
and
stuff.
So
absolutely.
C
B
I
didn't
get
to
fill
up
this
pr
section,
but
I
feel
like
we
can
from
the
top.
I
guess
sorry,
let
me
let
me
let
me
link
one
actually
wait.
I
can't
copy
and
paste
what
the
you
go
to
10
34,
the
sampling
one
yup
sure
all
right,
so
I
moved
previously.
I
moved
the
samplings
api
into
the
sdk
package
so
because
the
sampler
is
an
sdk
concept,
this
this
change
is
it
fixes
a
lot
of
our
sampling
stuff,
because
it's
a
lot
of
it
is
outdated.
B
B
Yeah
but
yeah
just
just
need
reviewers.
B
This
is
actually
blocking
me
from
moving
on
for
other
sampling
stuff,
because
the
changes
are
pretty
pretty
evident,
like
it's
completely
different
than
what
the
specs
are
doing
right
now.
So.
D
D
I
I
was
your,
I
think,
maybe
I
don't
know
a
couple
of
months
months
ago
before
the
beta.
I
was
here
once
but
nice.
Not
since
then.
A
Previously,
oh
okay,
we
know
each
other
through
github
nice
yeah,
so
I
guess
yeah.
I
I
can
take
a
look
at
this
one
laden-
I
don't
know.
I
guess
the
only
other
person
that's
on
the
call
is
yeah.
B
Yeah
pretty
straightforward,
it's
literally
just
reading
through
the
specs,
so
yeah
cool,
although
if
you
are,
if
you
do
get
confused
by
the
wording
of
the
spec
like
be
sure
to
like
either
comment
on
the
pr
bring
it
up,
because
that
is
important.
There
was
a
few
things
that
were
kind
of
confusing.
B
Was
this
one
of
them?
Yeah,
parent
or
else
sampler,
parent
or
else.
A
Yeah
yeah,
you
gotta,
do
it
or
else
yes,
authoritative,
yeah,
it's
it's
really.
It's
an
intense
statement,
yeah
cool
yeah,
I
think
there's
I
I
only
have
one
pr
in
here.
I
think.
B
A
So
no
way,
I
know
that's
crazy.
I
know
it's
like
the
like
the
superstar
from
from
yesterday's.
A
A
A
A
A
B
That
was
easy
anyway,
it's
no
big
deal
yeah,
oh
yeah,
daniel.
For
some
context,
the
correlation
context
is
being
renamed
back
to
baggage.
D
No,
no,
not
really,
actually
I'm,
basically,
I'm
mostly
here
for
learning.
So
I'm
just
nice
we're
waiting
to
get
some
feedback
and
see
how
useful
what
I
did
was
and
then
maybe
pick
up
something
else.
So.
B
Oh,
there
is
one
that
I
kind
of
want
the
the
refactor
is
valid
to
be
an
instance
attribute.
This
is
related
to
the
the
one
that
aurevin
opened
right,
but
I
think
he
closed
it
led
it
to.
B
I
don't
know
like
having
a
wait.
Maybe
it's
not
related,
but
it
was
like
the
attribute
one
as
part
of
the
span.
C
I
think
it
was
there's
an
issue
right
or
there
was
a
pr2.
B
Adding
spam
getter
method-
maybe
this
yeah,
so
it's
not
exactly
related
to
daniel's
vr.
I
think,
but
it's
an
issue
that
was
open.
This
is
not
necessarily
needed
for
ga,
but
we
didn't
come
to
a
consensus
for
this.
If
you
open
the
issue,
7
16.
B
15,
oh
15,
yeah
right.
So
this
is
the
one
where
it's
like.
If
we
use
like
a
default
span
or
something
like
that
and
the
user
tries
to
access
the
attributes
and
stuff
right.
A
B
It
would
actually
throw
an
exception
because
we
have
this
whole
design
of
like
using
a
default
span
instead
and
then
we're
trying
to
like
make
it
so
that
it's
like
foolproof,
so
it
will
never
crash,
even
if,
like
users,
try
to
access
an
attribute
that
doesn't
exist,
there
are
some
issues
with
that
that
I
wanted
to
bring
up.
B
That
is
related
to.
If
you
go
to
the
sig
notes
to
the
the
issue
that
I
want
to
talk
about
the
first
issue.
Sorry,
the
this
third
issue.
B
Yeah
remove
default
span
mechanism
so
basically,
oh,
I
hope,
like
we're
all
done
with
the
pr's
and
stuff
because,
like
this
is
kind
of
a
debate,
kind
of
thing.
A
Just
hold
on
just
before
we
get
there
so
yeah
sure.
What
was
your
suggestion
for
this
pr?
Are
you
saying
that
this
shouldn't
be
implemented?
The
way
it
is
or
no.
B
I
think
I
think
it's
this
this
one's
fine.
This
doesn't
have
to
do
with
the
attribute.
So,
okay,
yeah.
C
The
the
one
about
the
span
attributes
is
the
spec
allowing
like
users
to
access
the
attributes
on
the
spam
like
that,
or
is
it
disallowed
in
the
spec.
B
It
does
that's
the
thing
like
it
doesn't
say
like
right
now.
The
attribute
thing
is
kind
of
like
a
it
feels
like
a
python
specific
thing
like
I
don't
think
you
know
java
has
this
problem
and
also
like
a
lot
of,
I
think
some
languages
aren't
using
this
default
span
concept.
Do.
A
The
other
languages
not
have
a
no
op
like
a
noaa.
B
Span
that
they
can
use,
I
don't
know
exactly
but
like
it
seems
like
this
accessing
this
attribute,
like
all
the
other
like
at
least
java,
is
using
like
a
getter
for
to
access
these
attributes
so
like
it
seems
like
we
have
to
in
order
to
make
this
foolproof
like
we
have
to
make
getter
methods
for
every
single
attribute
on
the
span.
B
C
B
C
B
A
C
C
B
A
B
Yeah
kind
of
shooting
in
the
dark
here
yeah,
but
I
think
I
think
it'd
be
useful
if,
like
we
could
talk
to
aravind
directly
about
this,
maybe.
B
B
Yeah
like,
if
he's
not,
if
he's
not
part
of
this
project
anymore,
I
think
it's
fine
just
to
get
his
understanding
of
what
was
in
the
sig
and
then
have
someone
else
work
on
this.
So
I
think
I
think
that'd
be
the
move.
C
Okay,
I
think
he's.
Actually
I
think
this
is
his
last
week.
So,
oh
okay,
I
can
I
mean
I'm
not
sure
if
I
completely
understand
so,
I
don't
know
if
it's
like
a
voice
of
time.
If
I
was
to
talk
to
him,
do
you
want
to?
I
could
tell
him
to
like
message
you
on
twitter
or
something
does
that
sound
good.
B
Yeah
yeah
no
go
for
it.
I
just
I
just
wanna,
know
what
he
learned
from
the
sig
like.
I
don't
really.
C
C
The
attributes
should
be
right
only
so
I
don't
know
if
you
could
imagine
like
set
attribute
only
so
that
you
can't
like
iterate
over
attributes
or
you
can't
read
their
values
like
arbitrarily
so
internal
to
the
sdk
or
internal
to
the
api.
We
can
do
that,
but
I
guess
it
should
be
like
it
should
be
like
an
underscore
method.
So
we
know
it's
private.
Does
that
make
sense.
B
C
A
B
Sorry,
yo
alex
what
was
that?
What
was
that
issue
number
again
that
that
was
was
aravinds.
B
C
Oh
sorry,
I
was
just
gonna
ask
in
terms
of
like
the
the
ga
stuff
that
we
talked
about.
Is
there
anything
that
you
guys
want
me
to
work
on,
for
I
don't
know
like.
I
haven't
worked
too
much
on
on
the
tray
side
of
thing,
but
if
there's
anything
that
I
could
do
to
help
move
it
to
ga
feel
free
like
assign
me
those
tasks.
A
B
A
I
I
think,
we'll
have
probably
a
better
and
like
a
clear
picture
of
what's
still
needed
once
we
go
through
that
matrix.
But
any
of
the
issues
that
are
marked
as
required
for
ga
is
probably
all
fair
game.
Cool.
B
All
right
cool
off
the
top
of
my
head.
I
think
you
and
I
were
tasked
with
the
metric
stuff
there's
I
posted
like
some
links
in
there
like
there
was
some
activity
for
the
metric
spec
that
josh
created
this
week
over
my
my
opinion
is.
B
We
should
wait
on
the
stuff
to
go
out
to
be
final,
because
there
is
a
lot
of
stuff
that
he's
overwriting,
that
it's
a
lot
of
like
you
know,
name,
changes
and
stuff
like
that
that
this
this
doesn't
seem
to
be
so
firm
right
now
and
there's
a
comment
in
the
spec,
where
it's
saying
how
like
there's
a
guy
who's
from
like
the
java
sig
he's
all.
A
B
Like
yo
like
in
his
his
his
opinion,
his
point
was
basically
like.
Oh
this,
this
seems
to
be
like
forcing
us
to
do
this
a
certain
way
and,
like
we've,
already
implemented
another
way
or
something
that
which
is
which
just
happens
because,
like
this,
there
is
no
spec
for
the
sdk,
and
people
couldn't
just
be
waiting
around.
But
his
point
is
valid,
so
I
would,
I
would
wait
for
any
metrics
implementations
really
in
case
our
work
is
like
wasted.
C
C
Yeah
I
agree
yeah
also
on
that
john
was
like.
I
think
I
think
that
josh
agrees
with
what
john
said.
He
was
just
trying
to
outline
sort
of
like
the
yeah,
exactly
he's
just
trying
to
document
how
go
works,
which,
which
is
definitely
valuable
if
you're.
If
you're
like
looking
to
do
a
certain
part
of
it,
you
haven't
done
yet
or
don't
do
one
when
it's
time
for
reviews
or
something.
But
I
was
going
to
say
yeah.
C
I
feel
like
kind
of
like,
like
the
ap,
the
metrics
api,
that
we
have
there
and
the
spec
it's
sort
of
vague,
like
it
doesn't
like.
That's
the
real
user
contract
that
that
I
feel
like
we
need
to
make
sure
it
matches
with
whatever,
like
that's
the
part
that
we
need
for
ga,
like
the
actual
internal
implementation.
Doesn't
matter
so
much,
but.
B
I'm
not
too
knowledgeable
about
like
how
the
waiting
works
exactly,
but
this
isn't,
I
think,
oh
I
put
this
under
an
issue.
It
should
be
just
under
the
tracing
spec
thing,
but
it
does
bring
up
the
fact
that,
like
like
this
behavior
is
not
defined
in
the
spec
like
there's
nothing
to
tell
us
like
you
got
to
do
it
a
certain
way
but,
like
I
think
our
code
is
just
wrong
and
it
just
doesn't
cover
some
of
these
use.
Cases
like
christian
outlined
for
his
comment.
C
Okay,
do
you
guys
remember
who
worked
on
this?
Was
it
mauricio,
yeah
was
mauricio
or
or
was
it
christian
originally
apparently,.
C
B
B
Yeah,
just
just
I'm
just
bringing
it
on
the
radar.
It's
not
it's,
not
something
that
to
talk
to
talk
about
how
to
do
today.
So
yep.
B
Yeah
I,
like
I
added
this
like
all
yesterday
and
stuff
yeah.
We
kind
of
already
talked
about
this,
so
we
could
just
move
on
to
the
next
one.
Yes,.
A
B
Okay,
so
wait
actually
before
we
move
on
to
that.
If
we
go
to
the
actual
open
issues
for
ga,
are
we
able
to
like
kind
of
like
do
a
little
triaging
here,
because
I
don't
want
to
just
be
like
okay?
We
just
gotta
get
this
done,
but
like
not
have
any
action
items,
so
it
looks
like
a
lot
of
them
are
assigned
already,
which
is
really
good.
B
A
A
B
C
A
B
Yeah,
I
can
just
say
from
microsoft's
side
we're
not
going
to
be
investing
in
a
open
census
bridge
because
we're
just
manually
migrating
our
open
census,
customers
to
open
telemetry.
So
personally
like
from
azure.
We
don't
really
have
a
need
for
this,
but
it
could
be.
I
don't
know
when
they're
required
for
ga
thing
it
could
be
in
the
feature
matrix
for
for
all
we
know,
so
we
should
probably
verify
that.
C
Yeah,
as
I
was
gonna
say,
like
google
cloud
customers
are
also,
I
think
it's
like.
I
don't
know
like
most
of
our
custom.
Metrics
are
coming
from
open
senses
right
now,
so
I
know
at
least
for
java.
We
have
a
new
google
who's
working
on
opencensus
bridge
for
java.
I
know
we
have
like
an
open
tracing
one
for
python
right.
A
C
And
yeah
I
mean
maybe
so
once
that
new
new
googler
is
working
on
the
the
java
one.
Maybe
I
can
like
sync
up,
but
I
was
wondering
because
it
seems
like
most
of
the
activity
in
the
open
census.
Repo
right
now
is
actually
azure.
Customers.
A
B
B
Yeah,
it's
the
to
the
to
the
collector
yeah
yeah,
but
that
is
required
for
jp.
I
don't
see
an
open
census
bridge
in
the
feature
matrix.
A
C
B
C
B
Right
yeah
so,
like
our
customers
aren't
taking
advantage
of
the
views
at
all,
like
you
know,
they're
just,
which
is
why,
like
a
part
of
the
reason,
why,
like
I'm,
not
really
contributing
to
the
metric
sticks
because,
like
the
use
cases
for
our
customers,
are
very
very
easy,
you
know
pretty
straightforward
for
metrics
and
not
and
once
again
not
many
people
are
using
metrics
so
like
as
long
as
they're
able
to
use
the
default
aggregations
right
now.
B
It's
fine,
but
maybe
they
have
the
need
for
the
in
the
future,
but
hopefully
like
the
metrics.
Sdk
is
in
a
good
shape
and
we
have
an
implementation
by
then
so.
C
B
Yeah,
however,
we
won't
be
starting
migration
until,
like
the
open,
telemetry
goes
g
anyways
so
like
that
would
be
assuming
that
the
metrics
is
already
there,
so
it
would
be
f
like
and
that
that
would
mean
like
the
views
would
be
already
implemented.
So.
B
Yes,
exactly
yeah
yeah,
so
that
would
be
sufficient
enough
to
do
that
yeah,
actually,
even
even
with
like
the
complicated
use
cases,
I
feel
like
good
documentation
could
achieve
that
too.
It's
actually
not
that
hard.
So.
B
B
B
B
Yeah,
I
think
you
could
just
just
put
a
just
put
a
comment
there.
I
don't
want
to
take
up
too
much
of
the
meeting
time
and
just
put
a
comment
there
saying
like
oh
try
to
find
a
spec
issue
for
this
and
see
if
it's
needed
for
for
ga,
which
I
think
it
is
like
for.
A
A
That's
good
this
one.
A
B
Is
it
only
the
flush
call
like?
Would
there
be
any
other
way
for
the
exporter
to
hang
really.
B
Right
yeah,
that's
that's!
That
was
the
one
case
I
actually
ran
into
too
for
one
of
our
azure
exporters
and
I'll.
I
added
like
a
manual
timeout
yeah,
but
any
exporter
so.
A
Yeah
yeah,
so
I
guess
you
could
implement
this
on
in
each
one,
but
it
seemed
like
we
should
just
have
a
general
mechanism
for
it.
Instead,
but
yeah.
A
B
The
like
the
concurrent
batch
batch
span
processor
problem,
like
I
don't
think.
Unless,
if
you
run
into
it
or
someone
looks
at
the
code,
no
one
will
really
realize
that
it's
a
problem,
yeah.
A
C
B
We
have
like
a
actual
mechanism
that,
like
detects
this
or
we
just
like,
do
this
change
for
all
of
the
exporters
manually,
and
if
anyone
wants
to
create
a
new
exporter,
we
just
have
to
be
mindful
about
this
right.
I
think
those
are
the
two
ways
that
we
could
do
about
this
yeah
yeah.
I
guess.
C
I
was
going
to
say,
I
think
the
resource
detection,
at
least
the
otap,
definitely
specified
that
there
should
be
a
timeout.
So
it
would
be
nice
like
if
it
was
part
of
the
the
exporter
interface,
that
the
constructor
has
to
accept
the
timeout
or
something
it'd
be.
A
A
B
Yeah,
it's
three
sorts
of
truth
now,
so
I
don't
know.
A
There's
too
many,
maybe
I'll-
maybe
I'll
actually
open
a
pr
to
that
matrix.
To
add
these
things
in
there
and
natural
dandrusing.
B
I
think,
as
part
of
our
our
matrix
triage
thing,
anything
that
we
is
marked
ga
for
our
issues
but
isn't
doesn't
appear
there
or
we
should
probably
follow
up
with
someone
from
like
a
tc
member
or
something
like
that
yeah.
I
agree.
A
All
right,
so
this
one,
I
guess
yeah,
we
just
need
something,
but
we
don't
have
anything
yeah.
I
guess.
C
B
Yeah,
it's
not
related
to
anything
it's
from
a
different
repo
yeah.
What
is
yeah
so
this
thing
actually
make
it
in
yet
I
don't
know
it's
yeah.
All
of
these
are
still
open,
but
it
could
be
possible.
Big
changes.
B
A
B
All
right
so,
basically
going
through
the
when
I
was
going
through,
like
the
sampling,
specs
and
stuff,
I
you
know
obviously
there's
like
a
decision
that
is
coming
from,
like
the
sampling
result
and
I
was
seeing
how
different
sigs
implemented
like
what
they're
doing,
if
it's
sampled
and
not
sampled,
so
right
now.
Currently,
if
our
span
is
sampled,
we
actually
created
like
a
real
span.
If
it's
not
sampled,
we
create
a
default
span
and
each
of
them
there
is
recording
court
like
will
return
true
or
false,
like
all
the
time.
B
So
right
now
like
we're,
actually
not
taking
advantage
of,
like
the
you
know,
performance
improvements
that
could
possibly
result
from
like
not
recording
it
at
all.
So,
basically,
for
all
of
our
instrumentations,
we
don't
have
any
check
to
see
whether
or
not
the
span
is
recording.
B
We
basically
just
call
all
of
the
set
attributes
you
know
like
and
sending
it
over
the
wire
if
it
is
propagated,
and
even
if
it
is
a
no-op
span,
we're
still
calling
these
functions,
but
it
just
doesn't
do
anything
that
that
is
pretty
much
our
mechanism
for
not
not
sampling
a
span
which
is
like.
So
what
what
all
other
all
the
other
sigs
are
doing.
I'm
seeing
is
like
they
have
a
is
recording
check
for
every
single
instrumentation.
B
I
don't
think
they
use
the
mechanism
of
like
a
default
span,
so
I
I'm
not
saying
remove
the.
I
should
reword
this,
I'm
not
saying
to
remove
the
default
span
completely.
We
just
need
to
utilize
this
this
flag
for
what
it's
supposed
to
be,
because,
right
now
we're
not
using,
is
recording
for
anything
so.
A
C
B
And
there's
like
pretty
pretty
big
perf
problems
with
that
because,
like
some
of
the
like
set
attributes
like
you
know,
sometimes
I
I
I
saw
for
one
of
them
like
it.
It
makes
them
all
like
a
capital
or
something
like
that,
like
all
these
functions
are
still
called
so.
B
So,
yes,
I
put
this
here
in
the
issues
because
it's
it's
not
a
complicated
change.
It's
just
that!
It's
it's!
It's
a
lot
to
do
so.
Yeah.
B
Yeah,
I'm
always
an
advocate
for
smaller
prs.
So
I
wouldn't
mind
if
someone
did
like.
Oh
just
the
database
ones
or
like
just
the
http
ones,
or
something
like
that.
B
Yep
cool
yeah-
this
actually
kind
of
leads
me
to
the
next
issue.
Oh,
but
for
this
yeah
you
could
just
I
think
an
action
night
for
me
is
just
create
an
issue
for
it.
So
yeah.
Does
anyone
have
any
questions
about
this
or
comments.
B
Okay,
cool
right,
so
for
the
next
thing
I
have
a
collecting
metrics
via
instrumentations.
So
this
has
been
brought
up
before
I
think
by
conor
when
he
was
implementing
some
stuff
for
the
grpc
instrumentation,
and
it
is
a
very
like
it's
talked
about
in
the
metric
six
and
the
the
tracing
and,
oh
sorry,
the
sampling,
sig
and
there's
a
pretty
big
need
for
like
deriving
metrics
from
like
either
tracing
data
or
like
from
instrumentations
themselves.
B
For
example,
like
you
know,
request,
counts
and,
like
request
durations,
there's
no
mechanism
to
do
this
right
now.
What
grpc
instrumentation
is
doing
or
like
what
we
instructed
conor
to
do
is
like
make
a
instrumentation
specific
thing
for
now,
because
there's
no
like
specs,
defining
how
we
can
collect
metrics
from
either
span
data
or
like
the
instrumentations
themselves.
B
So
the
issue
for
here
is
from
for
at
least
from
microsoft,
for
azure's
needs.
We
actually
can't
rely
on
anything,
that's
related
to
tracing.
B
We
want
to
keep
the
pillars
of
observability
orthogonal
to
each
other,
meaning
like
if
I,
if
a
user
just
wants
metrics
data
right
and
they
didn't
instrument
it
with
tracing,
they
still
should
be
able
to
get
this
requests
per
second
requests
count,
so
that
means
we
can't
rely
on
things
like
spam
or
spam
processor.
B
B
There
also
is
a
problem
of
like
how
we
consolidate
those
at
the
end
like
if
we
want
account
for
like
flask
for
django,
for
like
requests
and
stuff
like
that
right.
If
we
make
metrics
for
each
of
them
like,
I
would
have
to
create
a
counter
for
each
instrumentation,
but
these
would
be
like
specific.
These
would
aggregate
specifically
for
only
those
instrumentations.
B
How
would
we,
how
would
we
either
consolidate
them
at
the
end
or
like?
Do
we
care
about
that?
So
this
is
just
like
an
open
problem
that,
like
we
have
right
now,
especially
because
it's
no
mechanism
to
do
this
yet.
C
Yeah,
so
to
your
last
point,
there's
a
I
know,
there's
at
least
one
semantic
convention.
That's
supposed
to
be
about
like
time,
conventions
like
metric
names
for.
B
B
Yeah,
that's
like
that's
a
good
point,
so
I
was
thinking
about
that
too
right
now
we
don't
have
the
the
concept
of
like
returning
the
same
metric
by
name,
though.
C
So
they
go
sdk,
which
I
think
I
was
just
saying.
I
was
thinking
about
it
as
part
of
josh's
right.
B
Right
yeah,
so,
if,
if
that's
the
strategy
like
that's
fastest,
strat
we'd
have
to
change
the
metrics
sdk
first.
I
think
that
would
be
a
good
idea,
though,
like
I
wouldn't
mind
doing
that.
B
B
I
wish
diego
was
here
because
he's
pretty
like
he's
like
an
advocate
for
all
this,
but,
like
we've
been
saying
for
time,
we
need
some
configuration
api,
so
maybe
we
can,
like
I
don't
know,
I
think
environment
variables
might
be,
might
be
the
way
to
go
or
like
yeah
some
sort
of
configuration
file,
but
I
actually
don't
really
know
how
to
do
it
or
like
what's
the
best
practice
for
this.
A
Anyways
yeah
there's
we're
running
out
of
time,
but
there
was
a
pr
that
was
opened
by
oa,
oh
yeah,
which
is
which
kind
of
tries
to
address
some
more
configurability
of
auto
instrumentation.
That
might
be
worth
taking
a
look
at
because
I
think
this
kind
of
ties
in
with
a
little
bit
with
the
config
file
with
the
global
configuration
object
that
diego
always
talks
about
yeah.
But
I
I
do
agree
that
it.