►
From YouTube: 2022-07-21 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
B
A
Cool,
as
usual,
everyone,
I
please
add
your
names
to
the
attendees
list.
You
can
as
well
as
any
other
topics,
issues
prs
that
you
want
to
bring
up
during
the
sig.
Usually
the
prs
that
are
mentioned
here
would
be
expedited,
as
more
eyes
will
be
on
them.
A
All
right
cool
welcome
everyone
to
another
python.
Sig
this
week
looks
like
we
have
a
couple
topics
today.
Anyone
know
who
put
this
there
is
there.
Are
they
in
the
call.
A
C
I
know
there
was
someone
who
pinged
in
the
python
channel
that
they
want
to,
because
there's
no
component
owner
yet
so
one
of
the
one
of
them
wanted
to
volunteer
so
that
you
know
they
can
take.
They
can
take
care
of
the
maintaining
of
the
aws
specific
components.
A
Right,
I
was
talking
about
the
like,
like
boto
and.
C
A
C
A
Let's
see
okay
yeah
well,
if
they're
not
there's,
also
a
relevant
slack
thread
here.
I'm
sure
this
links
to
the
thing
you're
talking
about
but
yeah.
If
the
relevant
person
is
not
here,
yeah,
it's
exactly
the
one
that
you're
referring
to
trueville
chrome
but
yeah.
If
they're
not
here,
then
we'll
probably
just
push
this
discussion
on
to
next
week,
then
cool.
A
So
there's
this
we
can
take
a
look
at
the
doesn't
look
like
there's
any
other
topics
related
to
for
today
we
could
take
a
look
at
the
the
metrics
project
board,
real
quick
for
the
metric
stable.
Let
me
take
the
open
up
my
screen,
real
quick.
A
So
it
does
look
like
a
lot
of
these.
Things
are
assigned
already,
a
bunch
of
them
are
in
review.
I
believe
a
lot
of
the
metric
examples.
One
has
been
merged
and
the
other
ones
are
assigned
so
kant.
I
believe
you
have
a
pr
out
for
this
one
right.
C
Yeah,
I
got
a
reviews
from
eco.
There
is
some
disagreement
there,
but
yeah
we
will
never.
Can
I
see.
C
So
he
was
suggesting
that
we
introduce
a
new
histogram
type
like
so
there's
already
histogram
kind
right
so
he's
suggesting
for
the
time
we
we
should
introduce
a
new
histogram
type
altogether.
So
I'm
saying
that's
we
do
not.
We
probably
don't
want
to
do
that,
because
api
has
only
one
method
like
create
histogram,
so
they
should.
We
won't
be
able
to
add
a
new
method
to
create
a
time
instagram.
C
So
I
am
suggesting
that
we
will
have
only
one
instagram
type,
but
there
will
be
convenience
method
for
the
context
manager
yeah.
This
one
is
suggesting
that
we
add
a
new
class
timing
histogram,
which
is
which
I
don't
think
we
don't
want
to
do,
because
if
you
want
to
obtain
the
timing
instagrams,
there
must
be
a
new
api
method
which
we
probably
don't
want
to
add.
A
C
So
he
he
pointed
out
that,
like
I'm
not,
but
he
find
out
that
adding
a
new
time
definition
on
the
histogram,
it
would
be
a
anti-pattern
and
then
you
want
to
introduce.
A
It'll
be
easier
if
diego
would
be
here,
but
maybe
we
could
bring
this
up
like
next
week.
A
Okay,
that's
fine,
can
you
can
you
just
like
put
it
for
next
week?
If
we
don't
haven't
closed
yet.
C
A
I
think
we
also
agreed
on
this
one
where
it's
we
still
don't
want
to
instantiate
metrics.
Similarly,
to
like
how
we
don't
do
spans
right.
C
C
A
Alright
sounds
good
nice.
A
I'm
going
to
be
I'll,
probably
take
this
one
on
if
no
one
else
is
working
on
this,
I
believe
the
metric
reader
is
using
the
otlp
environment
variable
right
now.
There
isn't
a
way
to
tell
whether
or
not
from
the
metric
reader's
side
what
exporter
is
being
used.
A
C
Yeah,
so
what
I
remember
is
that
the
reader
should
call
the
exporter,
what
is
its
preferred,
temporality
and
then
configure
it
like
right
right
now.
There
is
no
such
thing
on
the
exporter
right,
let's
say:
if
exporter
has
an
interface
prefer
like
that
it
returns
the
preferred
temporality
and.
C
Reader,
can
you
know,
invoke
that
and
then
configure
it
on
site,
but
there
is
no
such
thing
as
of
now.
We
can
either
add
that
capability
and
the
exported
interface
and
then
implement
it,
so
the
reader
can
do
that.
Work
yeah
if
you
want
to
like
get
this
read
of
the
metric
reader
like
the
base
class,
will
probably
have
to
you
know,
go
that
off.
C
A
C
Exporter
is
already
configured
with
the
cumulative
temporality,
so
there
is
nothing
like
you
know:
environment
variable
setup.
You
can
do
it
and
that
itself
that's
like.
If
it
were.
If
it
were
to
be
implementation
of
the
exported
interface,
we
we
would
have
to
do
that
like
adding
additional
functionality.
A
C
Okay,
so
there
is
this,
so
we
do
not
have
any
that
configuration
on
the
exporter.
They
can
only
do
it
on
the
metric
creator.
A
Right
so
like
the
right
now,
the
only
way
that
I
can
see
to
make
it
so
that
we
can
have
a
temporarily
preference
like
knowledge
in
the
base
from
in
the
metric
reader
based
off
of
exporter
is
if
we
in
the
metric
reader,
we
determine
what
kind
of
exporter
it
is,
or
we
set
a
temporality
preference
specifically
for
like
exporters
themselves.
A
C
C
But
the
issue
itself
is
that
this
difference
should
not
like
the
exporter.
Difference
like
the
environment.
Variable
difference
should
not
be
in
the
base
class
right
like
I,
I
understand
the
the
hacky
solution
that
you
propose
like
we
look
at
the
what
lp
exporter
type
and
then
configure
it.
But
if
the
issue
is
to
remove
this
from
the
base
class,
I
think
we
will.
We
don't
have
any
other
option
than
adding
the
configuration
to
the
exporter.
A
I
see
well,
I
think
the
issue
is
not
that
it's
in
the
base
class-
it's
it's.
The
issue
is
using
that
it's
using
the
environment
variable
for
every
single
exporter.
If
it
exists,
not
only
if
it's
otlp.
C
A
C
Main
point
here:
I
think
we
are
fine
implementing
that
hacky
solution
again
once
then
we
can
maybe
revisit
I'm
not
sure
yeah.
I
think
we
can
do
that.
Sure.
A
Awesome,
let
me
just
let
me
sign
this
to
myself.
A
What
oh?
Okay,
all
right,
nice,
let's
go
back
to
the
sig
notes
cool!
Are
there
any
other
issues
and
pr's
that
people
want
to
talk
about?
A
I
remember
there's
a
lot
of
new
prs
in
the
contrib
repo
related
to
metric
instrumentation.
Anyone
have
any
questions
for
those
seems
pretty
straightforward
to
me.
A
Asking
integration
cool,
does
anyone
know
who
put
this
in
the
sukkah?
Did
you
put
this
in.
B
About
this
yeah,
yes,
so
we
had
proposed
an
approach.
Could
you
scroll
to
the
top.
B
Yes,
so
say
like
in
a
flash
cap,
if
you
are
into
integrating
using
sql,
alchemy
or
cycle
pg2
for
our
db
connection,
and
if
we
require
matrix,
I
mean
matrix
from
flask
like
a
controller
name
or
a
url
should
be
added
to
the
sql
query,
which
needs
to
be
added
by
a
sql,
alchemy
or
psycho.
Pg2.
B
And
then
can
you
go
to
the
files
changed.
B
Yes,
so
in
in
flask,
in
in
dot
pi,
we
would
be
appending
the
matrix
to
the
context
when
the
flag
is
enabled.
B
And
in
sequel,
alchemy
or
psycho
pg2,
if
the
context
has
the
key
sql
commander
values,
we
will
be
appending
it
to
the
query.
Yes,.
C
So
I
will
try
to
give
you
some
more
context.
So
let
me
what
I
I
believe
you
remember
that
we
added
the
sql
commenter
into
jungle
and,
like
there
are
some
ways
like
we
added,
so
we
want
to
enable
this
to
like
everywhere.
C
The
original
proposal
was
that
you
pass
around
the
reference
to
instrumentations,
but
that
wouldn't
work
with
the
auto
instrumentation,
which
people
usually
prefer.
So
what
I
suggested
is
so
inject
this
so
like
different
frameworks,
different
have
different
ways
of
extracting
the
information.
Like
the
you
know,
http
we're
out
or
like
whatever
it
is
there
so
passing
around
the
references,
those
and
then
extracting,
wouldn't
be
really
neat
way
to
do
it.
C
So
what
I
suggested
is
that
a
framework
each
framework
that
it
like,
if
it's
enabled
if
it
wants
to
like
let's
say,
there's
a
there's,
a
higher
level,
http
request
and
then
there's
somewhere,
like
you,
enable
the
sql
commenter
and
the
sql
commentary
is
involved
like
it's
like
that.
It's
adding
the
the
trace
context
to
that
query.
C
But
if
you
want
to
add
extra
information
such
as
http
route-
and
you
know,
method
something
like
that,
you
can
inject
those,
so
we
we're
going
to
create
a
context
screen
for
this
purpose
like
just
now.
You
know
we're
using
context.
You
know
in
in
other
places
where
for
the
surprising
instrumentation
right.
C
So
what
I
suggested
is
create
a
new
context,
key
for
the
sql
commenter
and
then
the
frameworks
can,
you
know,
add
the
the
additional
you
know
tags
that
they
want
to
append
it
to
the
commenter
and
then
the
commenter
will
at
the
at
the
time
of
adding
the
trace
context.
It
will
also
look
at
the
context,
key
value,
and
then
it
will
add
tags
to
the
query.
So
that's
what
I
suggested
my
so
we
like
what
the
question
now
is
like
does
this
approach
seem?
C
Okay,
like
do
you
have
anything
like
any
others
have
any
other?
You
know
comments
from
this
part.
A
So
if
I
were
to
understand
it,
besides
from
the
trace
context,
information
you
just
want
to
enrich
their
sql
commenter
I
mean,
or
whatever
you
know,
sql
database
instrumentations
with
other
like
tag
values
right
that
is,
could
possibly
be
called
from
their
flask
instrumentation
right,
like
what
like
endpoint
like
url.
C
C
C
B
A
B
Experience
yes,.
A
Sir,
can
you
can
you
repeat
what
you
just
said
originally,
this
wasn't
the
the
mechanism,
and
this
is
something
new
that
you
proposed.
A
So
I
guess
until
he
comes
back,
hey
thiago,
I
remember
you
created
the
sequel,
commenter
integration
for
django
correct.
Yes,
I
remember
that
one
had
like
a
much
more
elegant
solution
was
it
like
did
django
have
like
native
support
or
something
for
sequel.
B
A
I
see,
and
so
that's
why
we
didn't
have
to
use
this
kind
of
like
context
variable
passing
mechanism
right,
yes,
got
it
got
it.
So
if
we
go
with
this
route,
the
recommended
kind
of
mechanism
we'll
be
using
for
any
future
in
the
instrumentations
that
we
want
to
integrate
with
sql
we'll
be
using
this
context
variable
passing
okay,
I
I
currently
can't
I
haven't
taken
a
look
at
this
very
clearly
yet,
but
this
seems
okay
to
me.
A
A
Worries,
yeah
no
worries.
I
was
just
saying.
I
was
just
asking
thiago
that
like
if
we
were
using
the
same
thing
for
django,
but
it
turns
out.
Django
has
like
what,
like
native
support
to
add
sql
com
like
enrich
with
sql
commenter.
C
A
Yeah,
so
I
was
just
saying
like
just
looking
at
this
like
briefly,
it
doesn't
look
like
there's
any
issues
with
it,
so
it
makes
sense
to
me
we're
already
using
you
know,
instrumentation
specific
values
in
the
context
anyways
for
the
http
suppression.
That's.
C
C
Yeah,
this
is
something
like
the
it's
not
just
this
in
your
instrumentation,
like
any
instrumentation.
That
wants
to
add
this.
B
A
So,
does
that
mean
that,
like
now
that
you
mention
it,
does
that
mean
that
all
all
instrumentations
that
support
sql
commenter
will
use
the
same
key,
so
they
will
all
be
enriched
with
any
kind
of
sql
statements
if
we're
instrumented
with
them.
C
A
Right
so
I'm
thinking
like
let's
say
you're
like
does
that
mean
that
since
we
have
this
as
automatic
behavior
now,
usually
our
our
follow-up
to
that
is
like
adding
some
way
to
configure
this
right,
meaning
that
if,
for
example,
if
user's
using
flask
and
django
sorry
not
django
django's,
not
the
like
flask
and
some
other,
you
know
web
framework
right
or
some
whiskey
face
framework
that
also
supports
sql
commenter,
but
they
don't
want
certain
values
for
one
of
them
like
they
would
all
pick
this
up
right
if
it
exists.
C
A
And
then
whiskey
also
like
in
the
future,
we
also
support
enriching
their
sorry
for
sql
alchemy.
We
also
support
like
enriching
the
their
their
statements
with
whiskey
stuff
right,
but
they
don't
want
that
right.
They
only
want
the
stuff
from
flask
right.
C
Yeah,
so
we
can
like
they
each
instrumentation
where
they,
if
the
instrument
is
invoked
right
like
that
instrument,
is
called
right
yeah,
we
will
add
the
capability
there
that
they
can
so.
A
Right
right
is
there
a
way
to
there's
there's
configuration
on
sql,
alchemy
and
cycle
pg
itself.
A
B
A
Also,
the
word
metrics
kind
of
confused
me:
it's
just
a
semantics.
B
Yes,
I
will
change
it.
A
Cool
yeah
looks
good
yeah
if
you,
if
you
want
to
take
a
look
at
it,
please
change
it
from
draft.
So,
okay,
awesome
any
other
comments
on
this.