►
From YouTube: 2020-10-01 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
A
A
A
C
Yeah
all
right,
it's
1204
already,
so
I
guess
we
can.
Oh
sorry
904,
for
you
guys.
C
Yeah
actually
so
yeah,
I
guess
we
can
get
started.
Let
me.
A
C
Okay,
cool
nice
so
got
a
couple
topics
to
talk
about
before
we
get
into
like
pr's
and
stuff
alex
alex
and
I've
been
saying,
like
a
bunch
of
you
have
been
very
active
recently
in
the
you
know
in
our
repo,
and
we
always
welcome
more.
You
know
trying
to
get
more
approvers
and
maintainers
for
our
for
a
sig,
especially
approvers
right
now
we're
kind
of
like
in
in
need
of
people
who
can
like
activate
that
green
check
mark.
You
know.
C
I
also
feel
like
it's
kind
of
a
barrier
for
people
to
review.
If,
like
you
know,
they're,
not
an
actual
approver
or
something
so
I
believe
there
was
like
a
couple
of
guidelines
in
our
contributing
doc
that
that
is
kind
of
like
what
you
need
to
do
before
you
can
become
an
approver.
C
C
You
know
we're
more
than
happy
to
try
to
talk
with
that.
With
you,
so
especially
right
now
as
we're
trying
to
get
into
ga
improving
the
velocity
of
our,
although
it's
we've
been
doing
very
well
it'll,
be
much
easier
on
the
current
approvers
and
alex,
and
I,
if
we
get
more
people
on
board,
so
yep
yeah,
so
just
feel
free
to
ping,
one
of
us,
if
you're,
if
you're
interested
in
that
cool.
C
Okay.
Second
thing:
this
is
kind
of
extending
from
daniel's
sdk
extensions.
Pr
alex-
and
I
were
talking
this
morning
that
we
we
really
need
to
start
moving
our
instrumentation
packages
into
the
python
contrib
repo.
C
All
of
the
other
languages
already
have
this
and,
as
time
goes
on,
as
more
people
add
instrumentations
into
our
main
repo.
Obviously
this
task
will
get
bigger
and
bigger
and
the
longer
we
delay
this
you
know
longer
it'll
take
to
actually
you
know
pull
it
off,
so
we
we
thought
this
is.
This
would
actually
be
a
pretty
good
project
if,
if
one
of
the
like
the
interns
would
want
to
take
this
on
now,
we
are
already
designing
like
pretty
comprehensive
requirements
list
for
this.
C
So
you
know
if,
if
one
of
you
and
this
the
the
main
thing
is,
this
will
benefit
us
very
greatly
like
we
are
in
dire
need
of
this
and
we
kind
of
been
pushing
it
off
for
a
while,
so
yeah.
So
let
us
know
if
you
want
to
take
any
action
on
this,
we'll
be
happy
to
talk
to
your
mentors
or
stuff
if
this
doesn't
really
align
with
your.
C
You
know
path
to
success
at
your
company,
but
you
know
we'll
definitely
make
a
good
case
for
it.
Cool.
B
C
To
make
the
python
one
called
exactly
yeah,
originally
we
had
a
bunch
of
stuff
like
contribution,
but
we
just
kept
like
moving
back
and
forth
because
you
know
main
pain
point
being
like
every
time
we
released
in
the
main
repo.
We
would
have
to
update
it
in
the
contributor
with
a
lot
of
breaking
changes.
So
definitely
like.
C
Yeah,
our
our
solution
would
have
to
address
that
so,
but
we
can
talk
about
it
more
after.
I
think
sorry,
nathaniel
is
your.
Are
you
working
with
a
lolita
or
anna
rug?
More.
B
C
Cool
cool,
awesome,
nice.
Anyone
have
any
questions
about
this.
C
All
right
cool-
I
guess
this
leads
pretty
pretty
well
into
your
the
first
pr
topic.
Nathaniel
wanna
talk
about
that
a
little
bit.
B
B
I
I
definitely
thought
about
it.
A
lot
when
I
started
looking
and
comparing
it
to
contrib
repo.
I
think,
as
like,
wherever
the
instrumentation
package
lives
is
the
best
place
to
live
the
sdk
extensions
and,
like
you
guys
mentioned,
you
were
speaking
this
morning
to
even
move
the
instrumentation
outside
into
the
contrib
so
yeah.
I
I
just
wanted
to
discuss
and
talk
about.
B
You
know
if
it
could
stay
in
it,
because
it
is
so
closely
tied
to
the
sck
and
it's
not
very
heavy
in
terms
of
code
or
even
dependencies,
but
like
it's
a
good
discussion
to
have
phone
as
other
other
vendors
try
to
extend
from
the
sdk
in
a
way
that
allows
people
to
plug
into
the
normal
sdk
easily.
C
Right,
okay,
it's
actually
funny
that
you
mentioned
this
because,
like
azure
is
doing
the
exact
same
thing
like
we
have
a
lot
of
configurations
and,
like
you
know,
just
a
lot
of
azure
specific
logic
that
is
not
represented
just
from
the
core
sdk
and,
more
importantly,
it's
it's
a
lot
of
logic
that
doesn't
necessarily
belong
in
our
exporters.
C
You
know
like
it's
not
anything
related
to
exporting
logic,
but
the
solution
that
we're
doing
for
this
is
like
we're
actually
making
an
external
repo
for
this,
like
a
like
an
azure
sdk
that
extends
from
open
telemetry,
and
I
think
the
main
reasoning
behind
that
is
like
we
didn't
want
to
pollute
the
the
core
sdk
with
like
any
vendor
specific
logic.
Besides
the
ones
that
are
listed
as
like
pretty
vendor
neutral,
like
zipkin
exporter,
you
know
jager
stuff
like
that,
so
I'm
not
sure.
B
B
B
Like
aws
is
doing
the
same
thing,
we're
also
having
like
our
people
there,
it's
just
with
with
my
managers
and
everything
we've
been
talking
about,
also
trying
to
get
it
into
the
open
telemetry,
but
just
so
people
have
it
like
easy
plug-in
player
from
there
right.
Just
saying,
oh,
I
want.
F
C
I
don't
know
what
java's
reasoning
is
to
put
it
to
include
like
vendor-specific
stuff
in
the
community
repo,
but
maybe
that's
something
that
you
want
to
talk
to
them
about
like
what
was
the
reasoning
behind
this.
If
they
have
a
strong
argument
in
why
in
like,
why
they're
doing
that-
and
maybe
it
applies
to
us
then
then
maybe
we
can
explore
this.
C
But
as
of
now
like,
I
think
this
was
even
outlined
in
like
the
specs,
where
it's
like,
we
shouldn't
have
anything
related
to
outside
stuff
in
a
repo,
so
might
be
something
we
have
to
discuss.
B
Yeah,
I
definitely
benefit
from
asking
the
java
people
why
they
did
it
it.
It's
just
something
that
I
just
finished
recently.
I
don't
know
I
think,
like
the
java
review
was
just
so
huge
at
this
point
like
has
so
many
things
that
maybe
just
kind
of
slipped
in
there,
but
right
yeah.
I
can
definitely
ask
them
and
get
a
follow-up
on
to
why
they
have
it
or
maybe
they're
just
have
it
backlogged
to
move
it
to
some
contrib
repo
later
on
too
right
yeah,
maybe.
A
Yeah
I
feel
like
there
was
a
there
was
a
discussion,
at
least
at
the
one
of
the
maintainers
meetings
a
while
ago
around
having
the
like
the
concept
of
distros,
and
I
think
this
is
kind
of
where
this
would
this
would
fit
into.
I
don't
know
where
that
discussion
ended
up.
I
yeah,
I
know,
there's
there's
obviously
interest
in
having
like
vendor-specific
propagators,
and
you
know
like
we
have.
We
have
vendor-specific
exporters
in
our
repo
today
and
that's
that's.
A
Why
we're
trying
to
move
it
into
the
contrib
contributor,
and
I
think
I
think
that
would
be
a
like
a
fine
place
to
have
even
extensions
like
this,
so
long
as
it's
in
line
with
what
the
specs
decision
is
on,
where
these
things
should
live,
yeah,
which
I
like,
I
think,
was
to
put
it
in
the
contributor,
but
I'm
not
sure
what
what
the
java
folks
are
doing
here.
G
Yeah
yeah
real,
quick
daniel.
I
just
looked
at
the
pr
I
mean
I'm
not
I'm
not
sure.
I
understand
why
why
it
should
be
in
like
the
sdk,
because,
like
what
layton
mentioned
about
sort
of
custom
logic,
this
one
just
seems
to
be
like
the
ivs
generator.
I
mean
like
what
else.
What
other
things
are
you
guys
hoping
to
override?
Besides,
like
the
resource,
detector
and
id
generator
exporter,
stuff.
B
So
this
is
just
a
first
step
to
getting
to
where
we
want
to
be
right.
Now
it
is
just
the
ids
generator
like
you
mentioned.
Next
is
resources,
then
we're
going
to
have
a
custom,
propagator,
a
custom,
sampler
and
then
leading
from
that.
B
I
think
there's
definitely
plans
to
add
more
things
to
it,
but
it's
like
every
part
that
especially
doesn't
work
with
our
back
end
right
now,
which
we
know
isn't
going
to
be
able
to
be
updated
in
the
next
like
year
or
two
years
from
now
that
we
want
to
be
able
to
give
people
something
easy
that
they
can
say.
Oh
you
know,
hotel
does
all
these
great
things
already
instruments,
so
many
modules
and
mongodb
and
things
that
we
don't
do.
B
We
just
need
to
give
them
something
that
they
can
plug
in
and
add
in
the
customizable
parts
so
that
they
can
run
hotel
in
a
way
that
they
can
send
things
aws
and
to
other
places
right
have
an
aws
extension
for
the
stuff.
They
want
to
send
aws
and
like
an
azure
extension
for
things
they
want
to
send
to
azure
and
other
places
too.
G
Yeah,
so
what
we
have
for
google
is
we
have
a
like
open,
telemetry,
google
tools
package
that
has
all
these
things,
but
I
guess
I
just
don't
you
like.
What's
the
argument
for
having
it
in
the
sdk
repo.
B
Well,
there's
nothing
really
going
on
in
the
contrib
repo
for
many
days
now
and
just
trying
to
get
the
conversation
going
on
like
how
would
we
have
some
sdk
extensions
if
we
wanted
to
have
them?
Is
this
the
right
way
for
it
to
look
if
it
lives
in
the
contribute?
I
don't
think
that's
a
problem
to
anyone.
G
C
Yeah
cool,
I
think,
yeah,
so
I
thought
we
just
have
to
kind
of
explore
this
idea
a
bit
more.
An
action
item
would
probably
be
for
nintendo
to
like
reach
out
to
the
java
guys
see
why
they
have
their
packages
set
up
the
way
they
do.
Another
note
is
like
the
java
guys
like
they
actually
have
a
lot
of
stuff
that
a
lot
of
other
cigs
aren't
doing.
C
H
C
Of
us
have
that,
so
you
know
they
they
do
certain
stuff
because
of
the
language.
So
it's
definitely
good
to
not
always
like
just
ask
questions
yeah.
I
feel
like
it's
good
to
question
yeah.
B
C
Yeah,
I
can
just
like
briefly
kind
of
talk
about
that,
like
at
least
for
what
azure's
doing
we
have
already
like
made.
The
decision
to
like
have
the
the
azure
sdk
plus
the
explorers
exist
in
microsoft,
specific
repo,
because
all
of
our
infrastructure,
like
it's,
it's
not
only
like
telemetry
right,
like
we
have
a
lot
of
like
other
resources
and
services
that
we
use,
and
they
all
will
exist
eventually
in
that
repo.
So
it
would
be
very
beneficial
for
customers
to
like
find
everything
in
one
place.
C
So
if
you
do
invest
in
like
if
we
do
eventually
get
the
sdk
extensions
to
be
a
concept,
I
don't
think
we
would
go
with
it.
You
know,
because
not
only
is
it
like
has
to
be
open,
telemetry
related
things
we
also
have,
like
you
know,
various
like
storage
services
and,
like
you
know,
you
know,
data
pipelines
and
everything
will
exist
in
another
place,
and
so,
if
and
telemetry
is
just
one
kind
of
service
that
will
also
live
in
that
other
place.
So
I
don't
think
personally.
C
Microsoft
would
invest
in
putting
our
stuff
here,
as
if
that
makes
sense.
B
Yeah,
it
totally
makes
sense
that
that
you
guys
would
want
to
have
it
all
there.
I
think
it's
just
on
our
team.
We
just
decided.
We
just
want
our
one
place
to
be
the
open,
telemetry
repo,
whether
it's
the
python
one
or
the
contrib
one
like
we,
we
saw
it
worked
well
with
java
and
people
have
it
there,
and
maybe
we
think
it
would
work
well,
because
it's
we're
just
trying
to
extend
the
stuff.
That's
already
configurable
there
right,
like
extend
the
sampler,
extend
the
propagator,
extend
the
resources,
extend
the
ids
generator.
G
Okay,
nice,
hey
one.
Other
question
is
so
I
know,
like
the
exporters,
are
kind
of
standardized.
It's
always
like
open,
telemetry
exporter
and
then,
whatever
it's
going
to
be,
I
think
most
of
the
third
party
ones
are
following
that
too.
For
for,
like
our
sdk
extensions,
we
called
it
like
open,
telemetry
tools,
google
cloud
or
something
like
that,
should
we
just
maybe
try
to
standardize
a
name
so
regardless
of
where
it
lives,
when
they
all
end
up
in
pie
pie,
they
are
like
somewhat
uniform.
C
That's
a
good
idea,
yeah
we
at
least
for
our
sdk
exporter.
I
think
we
call
it
open,
telemetry,
azure,
monitor
or
something
like
that.
C
We
didn't
like
prepend
it
with
exporter,
because
it's
not
only
like
an
exporter,
so
this
is
pretty
much
like
our
sdk,
like
the
sdk
extension
pretty
much,
but
we
could
we
could
talk
about
that
offline.
I
guess,
might
be
a
bigger
discussion,
so.
H
C
Cool
all
right,
yeah,
okay,
so
just
we
could
just
get
right
into
pull
requests
now.
C
Awesome
is
away
in
the
call.
I
Hey
yeah,
I
just
updated
this.
What's
up.
G
I
Yeah
so
I
removed
like
we
talked
last
time.
I
removed
a
lot
of
some
functionality
that
I
had
added,
and
this
now
mostly
just
exposed
to
configuration
options,
ability
to
set
up
an
exporter
and
a
service
name.
So
service
name
is
the
it's
not
been
accepted
into
the
spec.
Yet
discussion
is
still
going
on,
but
it's
it's
kind
of
required
for
us
to
automatically
set
up
the
tracing
set
of
multiple
exporters.
I
So
it's
it
was
sort
of
a
blocker.
An
alternative
to
supporting
service
name
here
would
be
if
each
exporter
supported
had
its
own
environment
variable
for
service
name,
so
that
that
can
be
discussed.
But
but
I
think
that's
equally
risky,
as
in
the
spec
could
go
either
way
it
could,
it
could
say,
go
with
a
global
service
name
or
service
name
for
explorer,
so
I
think,
for
now
we
can
go
with
just
service
name,
and
so
this
isn't,
by
the
way,
an
outdated
comment.
F
I
I
need
to
update
the
comment
so
yeah,
so
if
you
please
go
over
the
code,
let
me
know
what
you
think
I
was.
I
was
still
updating
the
pr
adding
typing
hints
my
hints,
so
it
might
be
failing
again
I'll.
Let
everyone
know
and
get
her
once.
It's
ready.
C
Okay
sounds
good
yeah
if
you
could
just
update
this
with
like
a
new
description,
yeah.
I
C
C
Oh
yeah,
so
I
don't
think
this.
I
don't.
F
C
Flynn
is
in
the
in
the
call,
but
khan
just
wanted
to
call
this
out.
I
already
took
a
look
at
this.
It's
just
another
instrumentation
for
sk
learn,
which
I
have
no
idea
about.
I
made
a
couple
comments
for
that.
C
Basically,
the
the
only
outstanding
thing
is
that
this
instrumentation
actually
doesn't
take
a
dependency
on
base
instrumenter,
which
kind
of
goes
against
a
lot
of
the
designs
that
we've
been
using
for
all
the
instrumentations
it'll
be
nice
to
get
another
review
on
this,
but
it
seems
like
we're
still
kind
of
stuck
on
the
this
challenge.
C
So
if
anyone
has
any
ideas
on
how
to
deal
with
this
feel
free
to
comment
on
this
pr,
really
we
really
do
want
to
depend
on
the
base
instructor,
especially
with
all
like
the
logic
that
I'm
adding
for,
like
you
know,
being
able
to
extract
metrics
and
stuff.
It's
all
depends
on
the
fact
that
they
extend
from
the
base.
Instrumenter
so
might
be
something
else
to
look
at.
C
Exactly
yeah
yeah,
I
think
I
think
his
his
argument
was
like
not
many
people
are
going
to
autonomous
or
something
like
that.
So
I
I
don't
know
not
very
a
strong
argument,
so
we'll
see
yeah,
I
think
also
like
yeah,
just
a
note
for
the
future
too
like.
If,
if,
if
people
want
to
push
the
agenda
for
their
pr's,
it's
really
good
to
join
the
try
the
cigs
so
otherwise
like
it's
just
me
talking
to
myself
and
it's
just
nonsense:
right,
yep
cool,
oh
alex!
A
The
top
yeah,
no
sorry
I
I
just
added
the
link
to
where
the
sdk
extension
implementation
in
java
is
just
for
future
is
daniel.
In
the.
C
Call
today,
I
don't
think
so:
okay
yeah,
so
I
guess
he
moved
this
into.
Oh,
no,
it
was
always
in
draft.
I
I
think
alex
was
this
still
in
like
waiting
on
a
spec
change
or
something
like
that.
C
F
A
C
Okay,
this
is
mario's
pr
this
I
I
we
just
we
just
need
reviewers
on
this
pick
up
is
mario
on
the
call
oh
yeah,
yeah,
yeah
yeah,
you
wanna,
just
like
just
briefly
just
remind
us
about
the
details
of
this.
C
Nice,
okay,
yeah.
I
could
take
a
look
at
this.
We
just
need
like
a
couple
more
approvers,
so
I
think
that
just
needs
a
review
yeah.
We
already
got
that
cool
nice.
C
E
Yeah
this
pr
was
for
the
issue
to
create
coding
samples
first
span
outlining
context.
Behavior
could
be
honest.
I
wasn't
really
like
entirely
clear
on
like
what
was
asked
for,
but
cool.
C
Yeah
yeah
we'll
see
yeah,
but
that
also
just
needs
a
couple.
More
reviews
so
should
be
pretty
straightforward.
Nice,
damn
we're
going
through
these,
like
real
fast
record
exception
on
context
manager
exit.
Oh
wait!
You
want
to
talk
about
this.
I
So,
but
if
there's
an
exception
is
raised
within
the
within
that
context,
we
don't
ultimately
record
that
as
an
as
an
event
and
we
let
we
either
expect
the
instrumentation
the
order
instrumentation.
Do
it
or
sorry
the
instrumentation.
Do
it
explicitly
or
if
it's
manually
instrumented,
then
we
expect
the
user
to
catch
the
exception
added
as
an
event
to
the
span
and
then
maybe
re-raise
it,
because
that
would
probably
be
most
likely
the
case.
So
the
so.
The
end
result
is
that
when
manually
instrumenting
something
almost
every
single.
I
Exception
would
have
to
be
manually
added,
so
meaning
every
single
start
with
start
span
as
active
would
have
to
be
accompanied
with
a
try
catch,
which
seems
quite
tedious.
So
looking
at
the
prior
art,
jaeger,
python,
client,
consensus,
python,
client
and
if
I
remember
correctly,
data
dog
python
client
for
open
tracing
all
did
this
out
of
the
box.
I
So
I
think
we
should.
We
should
add
it.
I
don't
see
any
downsides
to
it
other
than
if
someone
didn't
want
to
explicitly
didn't
want
record
exceptions.
But
for
that
case
we
can
add
a
flag
that
defaults
to
false,
and
they
can
say
I
don't
record
exceptions
so
yeah.
C
This
seems
like
a
very
useful,
useful
feature.
It's
quite
annoying
for
people
to
like,
like
they
come
to
us
they're
like
hey
like
this,
I'm
not
getting
any
exceptions
from
this.
You
know
they
have
to
like
manually.
Do
it
themselves
yeah?
So
this
makes
a
lot
of
sense.
C
Do
you
think,
like
the
recommendation
for
customers
would
be
to
like
go
through
this,
this,
like
logical
flow,
if
they
want
to
get
exceptions
like
we
should
probably
remove
all
indication
of
like
like
whether
it
be
in
the
docks
or
anywhere
like
of
people
doing
it
manually.
I
guess
right.
I
Yeah,
I
think
this
should
work
transparently,
so
it
should
it
shouldn't
change
the
behavior
of
their
app
in
any
way.
So
if,
if
they
have
a
function,
that's
not
instrumented
and
it
traces
an
exception
and
once
they
start
instrumenting
it,
it
should
not
change
the
behavior,
but
just
implicitly
record
the
exception.
I
don't
know
if
that's
what
you
were
getting
at,
probably.
C
No,
I
was
thinking
more
of
like
like
currently,
since
we
don't
have
this
like,
like
customers
would
be
like
you
know,
with
with
span
and
whatever,
and
then
wrap
it
with
some
sort
of
try
catch
right.
I.
C
Manually
record
an
exception
right,
but
like
with
this
change,
they
wouldn't
have
to
do
that
anymore,
but,
like
they
wouldn't
know,
right
like
they
wouldn't
know
automatically
that
we
have
this
new
feature
now.
So
I
guess
we
just
have
to
be
be
kind
of
explicit
about
this
in
our
docs
or
like
a
feature
list
or
something
like
that.
I
Right
yeah,
I
don't
think
we
should
try
to
do
anything.
Try
to
automate
anything
around
that.
I
think
calling
it
out
very
loudly
in
the
release.
Notes
should
be
good
enough,
given
that
we
are
not
ga
yet.
Yes,.
D
I
I
C
Good
nice,
yeah
I'll
I'll
take
a
look
at
that
diego's
here
nice.
I
C
All
right
cool
protect
access
to
spam
implementation,
yes
wow!
This
is
very
recent
amos.
You
want
to
talk
about
this.
E
Yeah,
so
this
was
in
response
to
the
issue
where
we
did
not
want
to
allow
clients
to
directly
instantiate
spans.
The
idea
behind
the
pr
is
that
we
in
the
sdk,
we
hide
the
actual
span
implementation
behind
in
another
abstract,
based
class,
so
that
when
they
try
to
instantiate
span
from
sdk,
they
will
be
met
with
a
type
error.
It's
trying
to
instantiate
an
abstract
based
class,
and
then
all
internal
uses
will
be
using
the
protected
span,
which
is
bandwidth
and
underscore
in
front
of
it.
C
Right
cool
makes
sense
yeah.
I
remember
you
like
going
through
various
implementations
ideas
too.
It's
it's
good
that
we're
going
to
be
trying
to
like
do
a
approach
that
everyone
agrees
on.
E
So
the
one
thing
about
this
is
that
and
then
the
span
implementation
won't
show
up
in
the
docs
it'll
just
have
the
abstract
based
class.
I'm
not
sure
what
we
wanted
to
do
about
that
one
like
did.
We
want
to
hide
the
implementation
in
the
documentation
or.
C
E
C
E
No,
they
can
only
see
the
abstract
base
class
right
now.
I'm
sure
there's
an
auto
doc
setting
to
like
show
the
make
an
exception,
but
right
now
it
doesn't
okay.
E
E
Okay,
in
this
case,
we
move
the
span
implementation
to
the
protected
span
class.
G
So
yeah,
that's,
I
think,
that's
kind
of
did
you
see
my
other
comment
about.
You
can
kind
of
just
leave
the
span
span
class,
as
is,
and
just
add,
like
a
dummy,
abstract
method,
and
then
that
way
I
think
the
dot
can
stay.
The
same
like
like
the
only
thing
that
the
dummy
one
would
do
is
it
would
just
override
the
sorry.
G
The
only
thing
that
underscore
spam
one
would
do
is
it
would
override
like
that
dummy
abstract
method
so
that
it
can
be
instantiated,
and
that
way
you
wouldn't
have
to
touch
it
again.
E
Oh,
so
we
leave
the
implementation
in
the
the
unprotected
span
class.
Okay,.
E
Yeah,
I
think
I
misunderstood
that
okay
I'll
I'll
review
that
yeah
cool
will
that
leave
us
with
like
a
random
like
dummy
method.
That's
just.
C
I
feel
like
we're
doing
a
lot
of
hacky
things
to
like
adhere
to
the
should
not
be
immutable
kind
of
thing.
You
know,
I
think
the
most
important
thing
is
like
we
just
keep
track
of,
like
the
mechanisms
that
we're
using
to
you
know,
protect
these
classes
from
being
changed
and
just
be
consistent
with
them
across
the
whole.
C
The
whole
code
base,
like
we
already
have
like
you
know,
for
for
for
for
dictionaries.
We
have
like
mapping
proxy
type.
I
think
for
spam
context
we're
using
the
like
the
tuple
tuple
mechanism.
You
know,
and
now
here
we're
extending
from
an
abc
with
a
dummy
class,
so
yeah
a
lot
of
like
trickeries
that
we're
doing
just
because
python
is
a
very
dangerous
language.
So
yep
makes
sense.
C
C
All
right
cool,
we
didn't
get
a
chance
to
fill
out
like
many
issues
but
looks
like
aaron
has
an
issue
here
might
be
the
one
that
I
was
actually
looking
at
already
yeah
this
one,
and
you
want
to
go
over
this
for
real,
quick.
G
G
Right
now-
and
I
looked
I
I
mean
it-
wouldn't
make
a
lot
of
sense
to
me,
and
I
also
looked
through
the
spec
and
didn't
see
anything
about
that,
and
I
noticed
like,
for
instance,
in
the
otlp
exporter,
there's
sort
of
like
a
like
otlp
doesn't
support
that
either
it's
generally
supposed
to
be
like
the
resources
at
the
top
level
like
representing,
like
you,
know,
the
immutable,
whatever
it
says
in
the
in
the
docs,
like
the
basically
like
the
environment
that
you're
running
in
so
I
noticed,
like
the
other
exporters.
C
Right
yeah,
like
in
the
instrumentations
they're
like
during
runtime
based
off
of
the
I
don't
know
the
results
of
like
the
the
call
or
something
it's
adding
the
it's,
creating
new
resources
and
like
attaching
it
to
the
span
and
no
other
instrumentation
does
that
instead
of
instead
of
like
you
know,
just
setting
them
as
spam
attributes.
So
I'm
not
sure
who
created
that.
Maybe
there
was
a
specific
reason,
but
maybe
you
could
like
pinpoint
the
person
who
who
created
that
so.
G
Like
I
think
also,
I
mean
honestly,
I
feel
like
it
should
be
removed.
I
think
it's
just
from
spam.
That
is,
I
feel
like
it
was
kind
of
like
maybe
before
the
spec
was
solidified
or
something
like
that.
It
was
added
in
there
like
the
resources.
G
C
Yeah,
nowhere
else
do
they
ever
like
need
to
have
the
resource
on
the
span.
You're
saying.
G
I'm
not
not
super
sure,
but
I
don't
think
I
can
check
the
other
sdks
as
well,
so
it
just
doesn't
really
conceptually
make
sense.
I
I
feel
like
it's
not
supposed
to
be
there.
A
C
Don't
recall
doing
anything
with
the
resources.
To
be
honest,
I
feel
like
we
just
passed
it
into
the
provider
and
that
we
don't
do
anything
with
it.
I
don't
remember,
though
I
haven't
looked
at
metrics
for
a.
G
Well,
it's
like
available
to
exporters;
they
can
pull
it
off
the
meter
or
whatever,
like
that's.
What
google
has
the
google
cloud
explorer
has
like
a
native
concept
of
resource
sort
of
like
it's
very
similar
to
the
otlp
one,
so
we
just
send
it
right.
C
But
it's
like
a
it's
like
it's,
not
a
it's,
not
a
instrument.
Specific
concept
right,
like
each
instrument,
doesn't
need
to
know
about
the
resources
of
the
environment
right.
G
A
C
Yes,
yeah,
the
I
think
that's
actually
was
due
to
the
fact
that
we
removed
meter
from
the
asynchronous
instruments.
The
only
reason
we
needed
meter
was
because,
like
you
need
to
access
like
the
labels,
or
something
like
that,
I
don't
remember,
but
anyways
metrics
is
kind
of
outdated
right
now,
anyways,
so
yeah.
A
No
sorry,
I
just
brought
it
up
because
I
there
was
a
change
I
was
recently
merged.
I
think
yesterday
around
resources
being
available
to
the
export
pipeline
for
metrics,
and
I
wasn't
sure
if
the
same
was
true
for
where
the
resource
should
be
available
for
for
traces,
but.
C
Yeah
as
long
as
the
as
long
as
the
resources
are
like
the
meter
knows
about
them,
I
think
the
exporters
all
will
have
access
to
it
right
because
in
this
in
the
pipeline,
like
you
have
to
pass
in
the
meter
and
the
controller,
so
oh
and
each
instrumentation
each
instrument
has
access
to
the
meter
that
created
it
eventually.
C
C
Yeah,
so
when,
when,
when
exporters
see
spans,
are
they
able
to
get
the
tracer
somehow,
like
these
fans,
have
I
totally
forgot?
Do
they
have
a
reference
to
the
tracer
that
created
them.
C
Okay,
so
yeah
as
long
as
we
as
long
as
we
have
that
access
and
we
still
light
up
that
requirement
and
for
exporters
to
know
about
the
resource.
I
think
it's
fine.
G
G
Js
does
here
I'll
comment
on
that
issue.
C
F
Yeah,
I
just
have
a
question
for
aaron:
did
you
mention
the
oto
pix4
right
now
group
spans
by
spam
resource
right.
F
Yeah,
but
you
don't
think
this
is
right
or
percent.
I
represent
multiple
communication.
F
Libraries
I'll
be
confused.
How
do
you,
how
should
it
be
group
if.
G
Not
like
this,
I
think
I
think
it
would
probably
you
just
have
like
one
top
level
resource
from
the
provider,
so
so
they
would
basically
get
one
resource
for
all
of
the
the
spans
and
that
way
does
not
to
be
copied
into
each
span.
G
For
instance,
like
that's,
that's
the
reason
that
it
was
written
like
that,
but
I
think
I
think
the
reason
that
you
could
have
multiple
of
those
resource
bands
objects
is
because,
like
if
you
had
a
collector
or
something
like
that,
then
you
would
be
getting
from
multiple
different
you'd,
be
getting
metrics
from
multiple
different
resources
and
then
sending
them
again
onto
like
another
otlp
receiver
right.
G
I'll
have
to
look
into
this.
I
can.
I
can
open
a
spec
issue,
it
looks
like
it's
not
in
go,
but
it
is
in
ours
and
it
is
in
js.
So
I
can.
F
C
G
Oh,
no,
sorry,
I'm
talking
about
their
actual
spin,
like
they're
span
stuck
inside
of
the
api.
They
only
have
a
tv
links
record.
G
C
C
I
think
we
can
just
like
go
over
them.
Real,
quick,
see
if
there's
any
see
if
there's
any
np
impending
ones,
I
guess
we
could
focus
on
the
ones
that
are
specific
to
ga.
We
have
12
minutes
left
so
in
terms
of
oh
also
alex
is.
Are
the
issues
you're
able
to
see
them
in
the
burn
down
chart,
or
is
that
just
like
prs
and
stuff.
C
Okay,
how
do
I,
how
do
I
get
there.
A
There's
a
project
tab
at
the
very
top
of
the
repo,
also
you're,
not
sharing
your
screen.
I
don't
know
if
you
know.
C
A
C
Something
right:
okay,
cool!
So
what
do
you
think
about
the
like?
Our
velocity
in
terms
of
this
alex?
Are
there
any
like
pressuring,
pressing
issues
that
you
think
will
take
like
a
long
time
that
we
might
have
to
worry
about.
A
C
Yeah,
okay,
cool
yeah-
I
don't
really
see
it.
I
don't
think
there's
actually
much
value
in
going
through
the
issues.
They're
all
pretty
straightforward
and
looks
like
a
lot
of
them
are
signed
already
and
for
the
ultra
ones
alex,
and
I
will
just
triage
them
sometime
later,
but
yeah
like
feel
free
to
like
pick
any
of
these
up.
We
really
just
you
know,
need
the
ones
for
required
from
ga,
so
yeah,
I'm
pretty
straightforward.
C
Does
anybody
else
have
any
other
topics
they
want
to
talk
about?
I
feel
like
that's
pretty
much.
It
could
just
like
get
10
minutes
back.
If
that's
okay
with
you
guys
so.