►
From YouTube: 2022-06-02 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
D
All
right
cool,
I
guess,
because
it
just
started
yeah
as
usual.
Please
add
your
name
to
the
attendees
list
right
so
this
week
and
I
guess
the
past
week
we've
been
primarily
tackling
a
lot
of
the
bugs
that
came
out
from
the
metrics
rc
release,
which
is
great
the
fact
that
people
are
actually
using
1.12.
D
Chicano
then
diego
and
I
probably
will
have
to
kind
of
have
to
prune
our
backlog
a
little
bit.
They
kind
of
just
been
coming
in
some
of
them.
Don't
have
tags
or
labels
associated
with
them,
so
we're
gonna
have
to
get
a
better
idea
of
like
what
we
need
to
get
done
before
either
our
second
rc
release
or
a
stable
release.
D
A
Yeah
I
mean
the
only
observation
is
that
the
rc1
was
not
really
in
a
usable
state
like
it's
good.
That
people
have,
you
know,
reported
the
issues,
but
it
wasn't
really.
You
know
like
for
them
to
so
some
people
have,
you
know,
commented
that
they
had
work
arounds,
but
it
wasn't
really
like
they
were.
They
weren't
able
to
use
it
properly,
so
they
either
downloaded
it
they
stopped
using
it.
D
B
I
don't
know,
I
don't
know
if
we're
going
to
go
through
it
in
the
issues
or
prs,
but
I
would
I
would
be
interested
to
know
if,
if
we
have
like
compiled
sort
of
like
the
general
feedback
about
stuff
like
it
seems
like,
there
are
a
few
bugs
which
were
like
you
know,
programming
errors
or
kind
of
like
python
programming
errors
like
things
weren't
really
tested.
So
some
import
paths
were
wrong
and
stuff
like
that.
Was
there
any
additional
feedback
that
anybody
saw
and
wanted
to
share.
D
Right,
yeah
there's
we
don't
have
really
a
system
right
now
to
like,
like
have
a
comprehensive
way
to
collect
all
the
feedback
right
now.
It's
like,
as
customers
and
users
are
using
it,
I'm
just
merely
sharing
it
with
the
current
stakeholders
or
implementers
and
see
what
they
think
yeah
there's
not
really
a
and
then
after
that,
like
issues
are
either
created
or
it's
like
the
supposed
behavior
is
is
already
there.
That's
like,
I
think,
creating
issues
is
like
the
best
way
to
do
that.
B
B
A
B
D
A
B
I
didn't
open
the
issues,
but
I
I
did
take
notes.
So
I
think
that
was
too
oh
yeah
because
I
missed
last
week's
thing
so
that
was
like
two
weeks
ago,
but
yeah,
basically
like
the
just.
The
recap
from
those
notes
is
like
the
open
telemetry
I
o
getting
started
stuff
doesn't
have
anything
about
metrics.
B
B
D
I
think
it
would
be
good
to
have
like
a
itemized
list
of
specific
things
that
we
want,
especially
for
getting
started
first
like
make
getting
started
more,
more
robust
as
well,
and
then,
secondly,
cover
some
more
like
advanced
scenarios
as
well,
specifically
like
using
views
or
something
like
that-
maybe
even
some
examples
with
like
musher
system,
metrics,
etc,
because
we
don't
have
any
of
those
I
believe
aaron
did.
You
have
any
more
specific
things
that
we
were
missing.
B
No,
I
think
that
was
basically
it
yeah.
I
agree
with
what
you
said
on
views,
because
that's
sort
of
like
the
right,
the
configuration
part
like
ideally
people,
aren't
going
to
be
doing
too
much
instrumentation
themselves.
If,
once
our
libraries
have
instrumentation,
but
I
feel
like
the
views
are
the
most
important
thing.
B
B
D
D
A
D
E
E
A
A
A
A
Yeah,
so
we
will
will
not
be
hooking
our
handler
on,
like
the
whole
pipeline
default
right
now.
So,
unless
like
this
is
something
most,
people
are
not
aware
that
that
we
we
do
it
so
like
if
they
want
to
take
care,
is
con
like
not.
There
is
that
they
are
sure
that
this
will
not
cause
any
problem
to
their
application
logs.
They
can
enable
it
with
the
env,
otherwise,
it's
disabled
by
default.
D
D
A
A
Yeah,
so
I
wanted
to
talk
about
this
like
open
this
very
long
back.
So
basically
we
we
had
a
bug
fix
for
the
four
four
processes
where
you
know
the
patch
clusters
were
not
working,
but
that
did
not
solve
it
for
the
us
key,
because
its
for
implementation
is
in
c,
so
that
hook
was
never
getting
called
the
at
four
like
after
four,
so
I
looked
at
the
like
you,
whiskey
repo.
A
They
have
like
there's
an
ongoing
discussion
that
you
know
they
want
to
do
like
call
the
python
who
from
the
ubiski
code
itself,
but
it
is
like
they
haven't
reached
any
conclusion
yet
so
it's
still
a
pending
open
issue.
But
meanwhile
I
had
some
thing
in
mind,
so
I
implemented
this.
I
tested
this,
it
was.
It
was
working,
so
I
wanted
to
get
a
reviews.
This
is
something
like.
A
I
don't
mention
that
that
there's
a
project
airflow
they
want
they're,
you
know
trying
to
instrument
natively,
so
it
would
be
great
now,
if
you
can
take
a
review
at
it
and
then
see.
If
this
sounds
good,
we
can
get
it
much,
and
then
we
can
get
rid
of
the
like
the
separate
instructions
that
we
have
for
the
you
know.
This
folk
model.
B
Yeah,
I
remember
the
original
and
the
the
airflow
thing
for
anyone
who
didn't
see.
I
don't
know
if
I
posted
in
the
main.
I
think
I
posted
in
the
main
channel,
but
apache
airflow,
which
is
like
a
batch
processing
framework.
It
uses
python
and
I
guess,
like
a
whiskey
server,
I
believe
g
unicorn,
so
one
they.
B
Basically,
they
tried
out
open
telemetry
for
instrumenting,
like
you
know
the
airflow
traces,
so
you
would
have
like
a
dag
of
sort
of
the
different
jobs
and
dependencies
and
also,
I
think
they
were
trying
to
allow
users
to
add
instrumentation
like
locally
as
well.
This
was
one
of
the
blockers
they
found.
I
think
that
they
were
able
to
make
it
work
with
a
workaround
but
yeah.
I
think,
since
that's
a
pretty
big
project,
it'd
be
awesome.
If
we
could,
you
know
prioritize
any
fixes,
we
can
do
for
them.
A
Yeah,
I
I
think
the
person
who
started
the
proposal
confirmed
that
they're
not
using
anything
related
to
c
that
you
know
they
only
have
like
they
use
the
fork
very
heavily,
but
they
mentioned
that
it's
it's
it's
unix
and
3.7,
plus
only
so
they
shouldn't
be
having
any
issue
already
for
the
project.
But
anyway
this
one
it's
a
long-standing
issue.
It
would
be
great.
We
address
that.
D
E
Yeah,
so
this
is,
I
just
opened
it
as
a
draft
pr,
because
I
wanted
to
get
everyone's
opinion.
This
is
to
fix
the
issue
that
I
brought
up
last
week
that
nathaniel
opened
that
has
the
extra
spam
that
gets
created
with
instrumenting
your
living
requests,
actually
an
update
on
that
issue.
We
tested
it
also
with
manual
instrumentation,
and
it
does
happen
when
you
add
the
url
lib
instrumenter,
it
wasn't
showing
up
initially,
because
that
wasn't
in
the
sample
app.
E
But
once
you
add
the
url
up
three
instrumenter,
you
also
see
the
same
extra
span
show
up.
So
we
investigated
the
issue
and
it
turns
out
that
it's
coming
from
the
create
key
method
in
open,
telemetry
context,
because
that
method
adds
a
uuid
at
the
end
of
each
key,
that's
being
created
in
context.
So
ever
since
every
instrumentation
library
creates
its
own,
suppress,
http
instrumentation
key,
they
all
end
up
being
different
and
the
value
doesn't
carry
over.
D
D
E
D
C
It
seems
like
before
everybody
used
the
same,
suppress
http
instrumentation
key,
like
they
all
use
the
same
one.
But
then
somebody
following
the
spec,
like
rightly
follow
the
spec
and
said
that
the
keys
that
are
generated
on
the
context
should
be
unique,
but
when
they
did
that
across
http
libraries,
everybody
had
different
keys
and
instrumentation
was
no
longer
suppressed.
B
Laden,
I
think
the
thing
here
is
that
when
you
call
create
key,
it
returns,
you
a
context
key
if
you
use
the
same
context,
key
like
the
object
that
you
get
returned
or
if
you
pass
the
same
reference.
It'll
it'll
work
correctly,
but
there's
no
shared
reference
that
all
of
the
instrumentations
are
using.
D
C
D
C
D
C
They
did
it
because
the
key
was
a
key
on
the
context
and
the
specification
changed
to
say
all
keys
on
the
context
should
be
unique
and
locally
scoped
to
the
current
instrumentation
you're
in
such
that
cross-cutting
concerns
I.e.
Requests
to
url
lib
instrumentations
should
never
be
able
to
even
see
the
keys
of
other
instrumentations,
but
by
following
the
spec,
they
broke
this
behavior
okay,
wanting
to
pass
data
across
instrumentations
so
that
duplicate
spans
don't
get
created.
D
C
D
B
There
was
supposed
to
be
like
a
semantic,
and
maybe
this
was
the
fix,
there's
supposed
to
be
like
a
way
that
the
instrumentation
can
tell
if
it
would
be
creating
sort
of
like
a
duplicate
span
for
an
event
if
multiple
levels
of
the
same
caller
instrumented
right.
Does
anybody
remember
anything
about
that.
D
B
C
Yeah,
I
I
think
that
sounds
great,
because
if
you
looked
at
the
page
that
leighton
was
on
just
recently
about
the
context
specification,
it
does
call
out
in
the
specification
libraries
should
use,
provide
direct
apis
on
the
paragraph
under
create
a
key
says.
It
is
recommended
that
concerns
mediate
data
access
via
an
api
rather
than
provide
direct
public
access
to
their
keys.
C
So
the
way
we
understood
that
was
yeah
context
shouldn't
be
used
to
decide
whether
we
create
duplicate
spans
or
not,
but
it
is
what
we
do
right
now
with
suppressed
instrumentation
and
in
the
future.
Once
we
figure
out
that
api,
both
suppress,
instrumentation
and
suppress
http
instrumentation.
All
these
methods
will
use
that
api
instead.
B
B
B
B
This
is
more
like
a
what's
the
word
like
a
conventional
way
to
do
it,
based
on
sort
of
the
structure
of
of
your
trace
like
tree,
so
rather
than
sort
of
the
parents
telling
the
child.
What
to
do
it's
more
like
that,
the
child
can
tell
based
on
what
whatever's
happening,
how
to
how
to
handle
the
situation.
I
don't
know
just
something
to
look
into.
I
think
if,
if
this
is
like
an
existing
mechanism,
we
have,
though,
and
it's
just
broken-
then
we
should
probably
apply
the
fix.