►
From YouTube: 2021-03-09 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
C
A
Got
a
new
the
blur
you
doing
the
the
blur
background
now
and
I've.
My
co-workers
started
doing
that.
B
Oh
well,
my
laptop,
I
gotta
pour
some
on
the
curb
for
it
died
yesterday.
I
don't
know
so
I
you
know
had
to
had
to
go,
get
it
repaired
and
I
received
a
loaner
laptop,
and
so
it
doesn't
have
anything.
And
of
course,
I'm
not
the
kind
of
person
that
does
smart
things
like
have
time
machine
backups.
B
So
I
couldn't
just
like
restore
my
whole
state
like
everything's,
fine
and
then
no,
I
just
gotta
like
reset
up
this
loaner
laptop
from
beginning.
I'm
sorry
hey.
Hopefully
this
doesn't
make
it
on
this
conversation
doesn't
make
it
on
youtube.
Somebody
at
the
time
post,
just
like
my.
A
A
E
D
D
Cool
great,
no,
it's
it's
nice
to
see
some
new
faces
yeah.
Maybe
we
can
just
do
some
quick,
quick
introductions
and
then
start
up
meeting
I'll
start
off.
I'm
matt!
I
I
work
for
lightstep.
I
I've
been
with
this
project
for
quite
a
while.
I
guess
since
the
summer
it
began
not
as
long
as
francis
francis
was
here
a
little
bit
longer,
but
I
can
hand
it
off
to
him
for
a
quick
intro.
H
Yeah,
I'm
francis,
I
I
think
I
started
open
telemetry
ruby
at
the
time
I
was
looking
to
take
over
maintenance
of
open
census
ruby,
so
it
was
a
pretty
natural
transition.
For
me,
I
work
for
shopify.
I
lead
distributed
tracing
efforts
and
robert
who's
somewhere
down
there.
Robert
works
with
me
on
that.
I
A
F
B
And
I'm
andrew's
teammate
amarillo
also
on
the
observability
team
at
github
and
I'm
gonna
toss
it
over
to
francis
wang.
C
Hi,
I'm
the
on
the
other,
francis
yeah,
I'm
an
independent
software
consultant.
Some
of
my
clients
are
are
interested
in
overtones.
We
actually
haven't
done
a
lot
of
implementation
yet,
but
I've
been
just
sort
of
helping
out
where
I
can
ryan.
Where
did
you
win?
I'm
sorry,
patrick.
E
Patrick
yeah,
so
I'm
patrick
and
yeah
I
work
at
splunk
and
trying
to
get
some
telemetry
data
out
of
our
we
just
kind
of
got
acquired
into
splunk
and
so
trying
to
like
really
wrap
around
the
telemetry
get
some
of
our
applications
too
much
data
into
like
the
bigger
system
and
really
I'm
just
kind
of
following
ryan.
Around
who's
got
more
of
a
passion
we
work
together.
G
That
I
got
skipped
yeah
patrick
kind
of
covered.
It
look
just
looking
to
get
more
involved.
I
think
our
team
names
are
a
little
weird,
but
you
know
signalfx
is
now
a
part
of
splunk,
so
I
don't
know
what
to
call
them
at
the
moment,
but
I
know
they're
getting
more
involved,
but
I
think
their
focus
is
a
little
more
on
a
java
and
go
from
the
start.
So
there's
maybe
a
little
bit
of
opportunity
for
us
to
help
them
out
and
help
the
community
at
the
same
time,
well,
helping
ourselves
too.
G
So
patrick
and
I
are
on
the
synthetics
team,
which
was
obviously
rigor
so
where
we
fall
under
what
they're
trying
to
build
out
as
the
larger
observability
suite
so
we're
close
by,
but
not
really
touching
the
apm
stuff
directly.
E
Yeah,
I
feel
like
there's
still
a
little
bit
of
we're
recently
acquired
recently
enough
that
we
haven't
and
also
I
feel
like
there
might
be.
You
know,
everybody's
work
from
home,
so
there's
not
like
a
lot
of
feeling
of
we
just
bump
into
each
other's
in
the
hall
and
like
really
talk
about
a
lot
of
stuff,
but
yeah
there's.
Definitely
like
a
lot
of
communication
with
the
signal
effects,
at
least
to
some
degree.
There
is
we're
kind
of
feeling
it
out.
Maybe.
H
Yeah
we
have
shopify
folks
have
a
pretty
strong
connection
with
the
signalfx
team
and,
more
so
the
omniscient
team.
So
we
were
working
with
omniscient
before
they
were
required.
H
Wait
do
we
want
to
move
into
the
spec
sig
update,
yep.
D
Yeah,
like
I
was
saying
it,
it's
always
good
to
see
some
new
faces
and
usually
for
this
meeting
I'll
kind
of
recap:
the
spec
sig.
That's
the
meeting
that
goes
on
before
this
kind
of
spec
level.
Things
end
up
trickling
down
to
us
at
some
point
and
then
we
kind
of
start
going
over
things
related
to
to
our
repo.
So
if
anybody
has
like
things
that
they
would
like
to
discuss,
I
don't
know
we
always
have
an
agenda.
D
D
So
I
think
changes
come
into
the
spec
stig
and
they
do
want
to
have
like
a
somewhat
regular
release,
cadence
of
things
that
have
been
decided
and
yeah.
I
think
that
was
the
first
question.
This
should
should
be
the
first
week.
Should
it
be
monthly,
I'm
not
sure
if
that
bullet
point
was
bogged
in
we'll
actually
do
we
release
today
or
decide
on
when
that
should
be.
D
The
next
thing
there
are
two
things
about
semantic
conventions:
I'll
group
them
together,
even
though
they
didn't
group
in
the
spec
sig,
one
was
there's
an
issue
about
semantic
conventions.
These
are
the
attributes
on
instrumentation,
whether
the
what
are
the
names,
the
keys
for
those
should
be,
whether
we
should
prefer
compact
names
or
whether
we
should
prefer
more
like
readable
names,
and
I
think
the
example
was
one
of
the
resource
reviews
zone.
D
I
think
they
were
saying
this
is
usually
called
availability
zone
at
most
cloud
providers
and
having
it
as
zone
is
more
concise,
but
nobody
really
knows
what
it
is.
So
there's
a
long
discussion.
I
think
there
will
be
some
kind
of
a
a
a
follow-up
all
right
yeah.
I
was
remembering
this
right
so.
D
Yeah
so
there's
a
long
discussion
about
what
we
should
do
here.
I
believe
people
were
wanting
or
people
who
were
leaning
towards
the
the
more
descriptive
even
if
longer,
one
which
I
think
makes
sense.
D
Consistent
formatting
of
semantic
convention
values,
so
the
keys
are
pretty
pretty
consistent.
They
use
like
this
dotted
notation
casing
is
consistent,
but
the
the
values,
on
the
other
hand,
are
kind
of
like
the
wild
west,
where
some
of
them
will
be
camel
case.
Other
one
will
be
snake
case.
Some
of
them
will
be,
you
know
all
lowercase,
so
there
was
a
just
a
desire
to
kind
of
make
this
a
little
bit
more
uniform.
D
D
Yeah
and
I
guess,
while
we
were
on
this,
there
was
some
discussion
about
having
like
a
a
max
key
length.
I
know
there's
been
discussions
on
this
before.
Apparently,
nothing
has
been
decided,
so
that's
still
up
in
the
air.
D
Moving
on
there
is.
C
D
Cool,
so
I
think
last
time
we're
running
this
meeting
and
it's
hard
for
me
to
remember,
but
I
think
I
was
talking
about
the
metrics
work.
The
metrics
work
has
been
there's
a
few
things
like
there.
The
group
has
split
into
there's
like
a
data
model
group
and
there's
kind
of
like
an
sdk
api
group.
D
They
each
kind
of
have
like
some
deadlines
agendas.
All
of
that
there
are
some
documents
around.
If
you're
interested
you
can
dig
them
up,
but
I
think
this
was
just
kind
of
like
a
summary
of
the
the
proposed
workflow
for
the
the
data
model
group.
D
So
I
think
yeah
this
bullet
point
list
is,
is
what
they're
interested
in
right
now.
First
up
histograms,
then
types
types
schema
and
meta,
temporality,
aggregations
and
then
kind
of
up
in
availability,
metrics.
D
D
There
is
a
prometheus
compatibility,
spec
underway,
so
there
is
a
prometheus
working
group
and
from
what
I
understand,
the
spec
right
now
really
just
kind
of
is
a
document
as
to
how
things
are
currently
handled.
I
think
I
think
it's
like
a
first
step
there,
there
kind
of
is
prometheus
support.
It's
not!
I
don't
think
what
people
want
in
its
final
form,
but
I
think,
as
a
starting
point,
iana
has
a
document
of
how
things
are
currently
working
to
kind
of
start
start
iterating
on
from
there.
D
There's
a
desire
to
choose
a
name.
D
D
Yeah,
I
think
that's
true
at
least
having
having
one
way
that
we
can
refer
to
it
in
our
documentation
will
at
least
be
helpful.
So
if
we
use
three
different
names,
people
don't
get
the
impression
that
there's
that
they're,
actually
three
different
things.
D
Whatever
there
is
some
brief
talk
about
something
that
was
deferred,
defining
transport
environment
variables
for
zipkin,
jager,
etc.
I
feel
like
this
is
the
thing
that
keeps
coming
up
where.
D
It's
something
that
I
think
does
not
so
much
apply,
usually
to
dynamic
languages,
I
think
maybe
compiled
languages
might
bundle
a
lot
more
export
functionality
together,
and
it
makes
sense
to
kind
of
have
like
four
for
otlp,
for
example,
or
or
for
most
of
these.
There
are
multiple
transport
formats,
whether
you
use,
maybe
json
or
protobuf,
and
you
kind
of
have
like
an
option.
D
I
know
for
most
of
the
dynamic
languages
like
if
there
are
multiple
options
for
any
export
format.
It
usually
comes
as
a
separate
package,
so
there
doesn't
make
a
whole
lot
of
sense
to
have
an
environment
variable
to
switch
between
them
because
kind
of,
like
whatever
package
you're
using,
is
going
to
determine
the
transport,
but
for
languages
where
that's
not
the
case,
I
think
they
they
do
want
to.
D
I
think
other
things
that
were
discussed
was
that
they
wanted
to
have
kind
of
a
some
sort
of
like
time
guarantee
for
how
long
something
will
be
supported
as
if,
if
something
is
deprecated-
and
I
think
they
were
talking
about
like
a
three
to
six
month,
time
range
for
where
things
would
definitely
be.
D
D
D
F
Iteration
was
that
brought
up
because
they
are
planning
on
making
a
lot
of
version
changes
soon
or
because
they
just
want
a
general
stability
guarantee.
D
It's
a
good
question.
I
didn't
think
that
there
was
anything
major
on
the
horizon,
but
they
wanted
to
have
a
process
in
place
before
beforehand.
D
Maybe
maybe
there
are
some,
maybe
in
the
background
there
are
like
some
desires
to
make
some
changes.
They
just
want
to
be
able
to
figure
out
how
to
how
to
plan
that
makes
sense.
D
So
yeah,
the
next
thing
is
it's
kind
of
around
instrumentation.
D
I
think
yeah
the
last
time
I
ran
this
meeting
was
two
weeks
ago,
so
I'm
having
trouble
remembering
back
then,
but
I
feel
like
we
went
over
some
documents
and
ted
had
this
one
that
we're
like
had
laid
out
like
three
or
four
kind
of
different
improvements
in
in
the
tracing
world
or
kind
of
adjacent
to
tracing.
Now
that
tracing
is
1.0
and
one
of
them
was
instrumentation.
D
Instrumentation
is
not
yet
1.00,
but
now
that
we
have
a
stable
tracing
api,
I
think
that's
a
priority
is
to
get
things
kind
of
short
up
there.
So
I
think
he
was.
It
was
just
a
call
to
action
for
anyone
who
wants
to
kind
of
head
up
this
group
in
these
discussions
for
for
firming
this
stuff
up
a
little
bit
more,
I
feel
like
the
semantic
conventions.
Things
that
was
talking
about
earlier,
would
kind
of
fall
into
this
category
as
well,
but
yeah.
D
The
stability
requirements
so
for
instrumentation,
just
instrumentation
the
output
of
instrumentation
will
be
some
spans
with
attributes
and
events
etc.
So
once
you
kind
of
call
instrumentation
stable,
what
does
that
mean?
If
you
want
to
like
add
or
remove
an
attribute
later,
for
example,
I
know
tigran
had
opened
an
otep
around
versioning
a
long
time
ago.
D
Yeah,
I
guess
back
in
january.
He
was
volunteering
to
champion
this
through
as
kind
of
a
way
to
to
indicate
what
what
stability
means
and
how
things
would
would
change.
D
There
kind
of
is
a
maintenance
challenge
there,
just
with
like
number
of
libraries
and
then
kind
of
other
thing
is
that
instrumentation
targets
you
know
underlying
frameworks
and
libraries
and
those
frameworks.
Libraries
are
always
changing
and
kind
of
the
currently
in
scope.
Supported
versions
of
those
things
are
always
changing,
so
just
kind
of
trying
to
find
ways
to
manage
that
whole
process.
H
Long-Term,
there
should
be
an
overarching
goal
here
to
firstly
make
open
telemetry
successful
enough
that
people
want
to
instrument
their
libraries
directly
with
open
telemetry
and
then
encourage
upstream
projects
where
we've
built
some
auto
instrumentation
encourage
those
upstream
projects
to
actually
absorb
the
instrumentation
into
themselves,
rather
than
rather
than
it
being
maintained
as
part
of
open
telemetry.
It
should
become
an
integral
part
of
those
those
upstream
projects,
but
that
launches
into
the
third
bullet
point
here
about
how
should
our
installers
treat
third-party
instrumentation,
and
this
is
robert's
queue.
I
So
this
is
really
relevant
to
what
I've
been
working
on.
While
what
I
was
at
work
on
yesterday.
So
last
week
it
was
last
week
I
had
put
up
a
pull
request
to
instrument
google
api's
core
gem.
It's
basically
a
gem
that
gets
used
across
all
the
generated
gems
for
whatever
end
points,
google
services,
but
in
doing
that
talking
to
daniel,
he
said
he'd
much.
Rather,
why
don't?
I
We
just
support
it
first
party
in
the
application
itself
and
while
working
on
it
yesterday,
I
realized
that
we
don't
really
have
a
convention
for
how
these
first-party
instrumented
libraries
should
interact
with
what
we've
done
like.
Should
we
they'd
be
inheriting
from
like
the
base
instrumentation
class?
I
think
so,
but
I
kind
of
like
to
open
that
up
for
discussion
to
see
if
what
people
think,
if
it's
not
too
much
of
a
derailment,
I
can
even
point
to
the
pr
that
is
doing
it
to
kind
of
just
a
simple
idea.
I
So
I
was
thinking
about
it
because
this
gem
does
actually
have
the
concept
of
options
and
some
form
of
configuration
that's
specific
to
it,
but
when
open
census
or
well
opens
this
is
a
part
of
it.
You
could
configure
this
gem
to
say:
should
you
use
opencensus,
and
so
then,
if
it's
available
and
you've
configured
it
to
use
it
it'll
use
opencensus,
but
in
the
case
of
open
telemetry,
we
do
have
this
concept
of
a
base,
instrumentation
class,
that
checks
for
compatibility.
I
I
would
expect
that
I
can
configure
it
the
same
way
as
I
would
any
other
instrument
of
library.
I
would
go
through
my
config
hook.
I'd
pass
in
the
options.
I
would
either
enable
it
or
disable
it
and
then
hopefully
everything
just
works
right,
but
that
does
require
pushing
in
some
dependency
on
open,
telemetry,
potentially
right.
I
So
now
that
it
provided.
H
A
little
bit
of
context
does
anybody
have
thoughts
yeah,
so
the
alternate
like
one
perspective
is
that
you
know
you
want
all
your
telemetry
configuration
in
one
place
and
it
makes
sense
to
do
that
in
your
open,
telemetry
sdk
configure
block.
The
other
perspective
is
that
you
know
you
want
all
your
google
api
client
configuration
in
one
place,
and
that
includes
you
know
telemetry,
so
whether
it
should
have
the
most
logging
or
whatever-
and
I
imagine
that
there's
always
going
to
be
that
tension
between
you
know.
H
Do
you
want
all
your
rails
configuration
in
one
place
or
do
you
want
all
your
telemetry
configuration
in
one
place
so
yeah?
I
don't
know
what
a
I
don't
know.
What
the
right
thing
to
do
is,
I
think
it
kind
of
depends
on
whether
you're
maintaining
one
of
those
projects
or
you're,
maintaining
open
telemetry
and
maybe
you
know
end
users
have
a
different
perspective.
B
I
So
like
the
way
that
I
kind
of
envision
it,
if
we
encourage
libraries
to
include
this
instrumentation
based
class,
the
install
path
for
all
the
instrumentation
would
be
the
same
as
any
of
the
third-party
instrumentation
gems
that
we've
written.
So
if
there's
environment
variables
variable
specific
to
how
it
should
be
instrumented,
then
it
would
be
like
it
would
for
us
in
our
perspective,
maybe
that's
why
I
obviously
I
do
have
a
bias.
I
Then
it
becomes
a
little
bit
blurry
and
I
think
this
is
more
to
what
you're
saying,
if
I'm
understanding
correctly
is
that
in
the
first
party
library,
like
this
google
apis
gem,
if
they
have
a
logger,
should
they
use
open,
telemetry's
logger
in
part
of
the
instrumented
path
and
in
which
case
like
they
probably
also
have
a
logger
that
they
can
configure
through
the
google
gems.
So
it's
which
one
you
use
when
and
then
which
one
takes
priority
and
I
think
ultimately,
that
probably
ends
up
being
at
the
discretion
of
the
library
maintainer.
I
I
will.
This
is
just
off
the
cuff,
because
I
didn't
really
think
too
much
about
this
product.
You
bring
it
up.
I
don't
think
it
would
be
unreasonable
for
any
logging
to
come
out
be
kind
of
under
the
configuration
control
of
the
library,
but
any
if
the
tracing
configuration
stuff.
Anything
that's
really
specific
to
open,
telemetry
tracing
would
be
configurable
by
the
tracing
configurables
and
like
we
do
have
some
support
for
environment
variables
in
the
tracing
install
hooks
for
like
whether
it's
enabled
or
disabled.
I
I
don't
think
we've
extended
it
beyond
that,
but
I
don't
know
if
that
answers
your
question.
I
think
it's
kind
of
open-ended
still.
H
I
think
there's
a
counterpoint
which
is
first
party
instrumentation
like
this
could
potentially
be
using.
H
You
know
in
an
end
user
environment
could
be
using
an
alternative
sdk
that
may
configure
things
differently
and
if
their
documentation
needs
to
take
that
into
account,
then
it
becomes
a
little
bit
confusing,
whereas
if
they
can
just
say
you
know,
here's
how
you
configure
tracing
instrumentation
in
our
gym,
then
it's
a
little
bit
cleaner
for
them.
Their
documentation
is
more
consistent.
H
Also
like,
as
this
becomes
more
pervasive
as
open
telemetry
becomes
more
pervasive.
How
much
do
we
want
our
configuration
to
reign
supreme
and
how
much
do
we
want
it?
Just
to
be
another
thing
that
people
do
right:
they,
they
just
add
telemetry
metrics
logs
traces
to
their
to
their
gems,
without
having
to
think
about
the
open,
telemetry
ecosystem.
As
such,
they
just
care
about
the
api.
F
As
as
an
end
user,
I
can
say
that
I
greatly
appreciate
the
simplicity
of
a
centralized
configuration
for
all
of
this.
That,
to
me,
is
very
nice.
I
don't
have
to
go
through
the
docs
for
15
different
gems
that
I'm,
depending
on
to
find
out
how
to
enable
their
tracing.
I
can
just
pull
it
from
the
instrumentation
registry,
and
that's
that
is
nice,
something
else
that
was
brought
up
earlier
about
loggers
and
things
just
to
share
perspective.
F
I
would
be
very
surprised
if
a
gem,
I
was,
depending
on
reconfigured
the
open,
telemetry
logger
in
any
way
or
or
tried
to
do
anything
like
that,
and
I
would
expect
that
any
telemetry
related
things
coming
from
that
gem
would
go
through
the
hotel
logger,
because
that's
where
I
would
look
to
configure
anything
telemetry
related,
but
I
can.
I
could
definitely
see
how
people
might
you
know
that
both
sides
of
that
could
be
valid.
H
To
think
right,
the
open,
telemetry
logger
was
principally
intended
for
the
use
of
the
open,
telemetry
sdk
and
maybe
the
api-
it's
not
really
intended,
as
the
logger
instance
that
you
know
your
application
is
using
or
or
other
gems
that
are
built
on
top
of
open,
telemetry
yeah.
So
it's
just
meant
to
be
for
internal
logging,
but
the
other
perspective
of
like
having
a
single
place.
I
guess
one
thing
is
that
the
registry
may
not
be
intended.
H
I
haven't
really
looked
at
it
closely,
but
I
don't
know
if
the
registry
is
intended
to
capture
you
know
the
reddest
gem
providing
its
own
telemetry.
I
think
it's
intended
to
capture.
H
H
So,
like
I
think
the
registry,
if
we
get
to
the
point
where
you
know
the
majority
of
gems,
that
people
are
writing
use
open,
telemetry
instrumentation,
like
they're
written
with
integrated,
open,
telemetry
instrumentation,
then
I
doubt
people
are
going
to
be
adding
their
gems
to
that
open
telemetry
registry.
H
F
I
When
you
inherit
from
that
that
base
instrumentation
class,
like
I
have
in
this
pr
we're
looking
right
there,
one
of
the
benefits
of
that
is
by
like
there's
a
hook
on
the
inheritance,
so
that
will
automatically
register
this
library,
whether
or
not
installs,
successfully
or
not.
You
can
actually
dig
into
that
and
see
like
okay,
I've
added
all
these
libraries.
And
if
you
look
at
your
registry
here,
we
don't
actually
make
that
easy
to
do
in
the
api,
but
you
could
see
all
the
things
that
kind
of
caught
was
caught
by
that
hook.
F
Yes,
that
is
actually
what
I
was
referring
to,
not
the
open,
telemetry
website.
I'm
sorry,
I
I
like
the
the
base
instrumentation
library
class
here.
I've
been
writing
some
internal
stuff
and
I
hooked
into
it
as
well,
and
it
was
just
a
very,
very
pleasant
experience
to
configure
and
use,
and
I
thought
it
was
very
ergonomic,
so
I
I
was
basically
just
voicing
support.
I
think
that's
the
right
way
to
do
it
and
I
hope
everybody
does
it
that
way.
Personally,.
H
F
For
gems,
we're
so
to
to
provide
a
little
bit
of
background,
we
are
writing
a
gem
internally
for
github
stuff
that
auto
configures
open
telemetry
in
the
way
that
we
expect
you
should
with
the
right.
You
know
pointing
to
the
right
collectors
and
things
like
that,
and
as
we
are
working
on
things
that
are
not
yet
instrumented
upstream,
our
gem
is
also
providing
additional
like
github
telemetry.
You
know
instrumentation
and
then
hooking
into
the
global
hotel
registry,
and
things
like
that.
H
Yeah,
we
have
exactly
the
same
thing
at
shopify.
One
thing
we
did
recently
was
actually
split
that
up
into
multiple
gems,
in
the
same
way
that
you
know
auto
instrumentation
in
open,
telemetry,
ruby
is
provided
in
separate
gems.
D
So,
just
to
add
to
this
a
little
bit,
I
think
this
is
an
interesting
use.
Case
is
coming
at
a
good
time,
and
this
has
been
an
excellent
discussion.
It
does
seem
like
there
might
be
some
value.
D
I
think
I
think,
there's
definitely
some
value
in
encouraging
first
party
instrumentation
to
still
use
this
instrumentation
based
class,
because
it
is
kind
of
like
a
way
to
know
what
instrumentation
is
present
in
the
system
and
in
the
future
future
when,
like
you
know
when
everything
under
the
sun
has
included
open
telemetry
by
default,
that
might
be
a
little
too
much
for
some
applications
and
you
may
want
to
have
an
easy
way
to
just
kind
of
configure
the
no
op
tracer.
D
D
I
think
that
this
you
know,
instrumentation
based
class,
was
definitely
written
with
the
third
party
instrumentation
case
in
mind,
because
that's
what
we
had
so,
I
think
there
might
be
like
definitely
some
improvements
that
could
be
made
if
we
want
to
try
to
encourage
first
parties
but
yeah.
H
If
you
want
to
get
like,
we
don't
right
now
have
a
really
great
way
of
getting
a
list
of
all
the
tracer
instances
in
the
system
I
mean,
I
guess
you
could
look
for
you
know
tracer
instances
and
iterate
over
them,
but
could
that
provide
an
alternative
way
of
getting
configuration,
information
or
centralizing
configuration.
D
It's
possible:
we
are
definitely
not
making
full
use
of
the
tracer
provider
mechanism
and
for
full
historical
context
that
actually
came
out
after
this
system.
D
To
some
degree,
so
that
might
be
one
reason,
but
I
I
haven't
really
seen
it
used
like
this
elsewhere.
D
Just
yet,
I
will
say
one
thing
that
that
came
to
mind
as
we
started
talking
about
this
first
party
instrumentation
stuff,
is
that
we
have
some
problems
with
open,
telemetry,
ruby,
there's
one
problem
that
I
was
aware
of
that
I
that
we
were
definitely
kind
of
deferring
at
least
I
was
aware
of
it
a
year
ago
and
have
since
decided
not
to
worry
about
it,
but
mainly
there
is
like
this
timing
issue
between
when
you
get
a
tracer
from
the
tracer
provider
and
when
you
may
have
registered
an
operational.
D
Tracer
provider,
so
you
may
end
up
getting
a
no
op
tracer.
If
you
call
this
too
early,
so
there's
there's
a
way
to
fix
this
and
the
way
that
people
have
done
this
elsewhere
is.
D
The
kind
of
the
default
tracer
provider
that
you
before
you
wire
up
an
operational
tracer
provider,
so
the
no
op
will
really
just
return
like
a
tracer
proxy
that
will
that
will
forward
things
on
to
just
a
no
op
tracer
and
then,
once
you
register
a
tracer
provider,
it
can
forward
to
the
proper
tracer
and
you
no
longer
have
to
return
a
proxy.
You
can
return
a
concrete
instance
at
that
point,
but
that
is
some
work
that
will
need
to
be
handled
for
first
party
instrumentation
to
work
seamlessly.
H
H
To
point
to
its
thing,
so
you're
going
to
get
an
api
tracer
instead
of
an
sdk
tracer
and
then
the
sdk
will
configure
itself
overwrite
the
tracer
provider
like
the
global
tracer
provider
and
subsequent
things
will
get
sdk
traces.
So
now,
you've
got
a
no
op
tracer
in
potentially
a
bunch
of
places,
and
you
might
be
wondering
why
you're
not
getting
spans
from
those
things.
H
I
think
this
was
something
that
I
had
considered
for
metrics
or
it
maybe
had
come
up
in
the
context
of
the
metrics
api
a
while
back.
We
don't
really
have
anything
reasonable
in
the
the
metrics
case,
but
it
was
a
consideration
there
about
whether
you're
getting
a
valid
meter
amount.
D
Yeah,
so
this
is
handled
properly
in
njs,
so
really
you
have
a
a
proxy
tracer
and
then
a
proxy
tracer
provider.
This
ends
up
being
the
one
that
gets
wired
up
by
default.
It
returns
this
proxy
tracer.
The
proxy
tracer
has
the
actual
tracer
instance
that
backs
it.
D
It's
not
like
a
hard
thing
to
to
fix,
but
it
is.
It
is
a
thing
that
we
that
we
should
address.
D
That
was
all
this
for
us,
that
might
be
a
bit
of
a
yeah
that
might
be
a
little
bit.
Oh
a
tangent,
but
while
we're
on
this
topic,
I
just
wanted
to
throw
that
out
there,
because,
like
it
could
this
could
be
something
that
you
run
into
when
with
instrumenting
the
google
apis.
If.
D
H
Sorry
I
I
was
just
going
to
say
like
if
you're
using
the
instrumentation
based
thing,
then
your
tracer
is
going
to
get
initialized
when
the
sdk
is
running
the
initializers
or
the
installers.
So
that's
actually
one
of
the
benefits.
I
guess
that
you
get
from
using
that
instrumentation
based
class,
but
yeah.
If
your
application
is,
you
know
getting
a
global
tracer
for
itself.
For
example,
before
the
sdk
is
initialized,
then
that's
going
to
be
problematic.
D
Yeah
actually
mention
it.
That
was
one
of
the
one
of
the
reasons
why
I
felt
like
it
was
cool
to
defer.
This
is
that
the
way
instrumentation
base
is
designed.
It
is
kind
of
like
the
last
thing
that
runs
in
sdk
configure
and
that's
on
purpose,
so
that
everything
is
already
set
up.
So
if
first
party
instrumentation
does
use
its
foundation
base
technically,
don't
have
this
problem
so.
F
F
You
know
that
you
should
use
it
this
way
because
you'll
get
these
benefits
and
here's
why
I
didn't
find
it
personally
very
difficult
to
go
in
and
figure
out
what
to
do,
but
I
can
see
how,
like,
maybe,
that
people
writing
their
own
first
party
instrumentation
might
grab
the
global
open,
telemetry
tracer
before
things
are
configured
etc.
Maybe
that
would
just
be
a
good
place.
Here's
why
you
should
do
this.
Let's
document
that
and
say
this
is
the
happy
path
that
we
have.
You
know
here
are
the
pitfalls.
I
That
was
actually
my
first
pass
at
this
when
I
first
looked
at
this,
it
was
like
okay
I'll
just
like
do
the
simple
thing,
I'll
find
and
replace
census
with
like
telemetry
right
and
I
was
like.
Oh,
I
don't
have
a
tracer,
so
I'm
gonna
have
to
initialize
a
tracer,
but,
like
I
thought
about,
I
was
like
well.
I
have
no
idea
if
I'm
gonna
get
the
right
trace
or
what
this
actually
fires
up.
So
I
thought
about
kind
of
like
the
arguments.
I've
already
mentioned.
I
So
repeat
that
but
like
why
not
just
use
this
instrumentation
base.
The
only
thing
that's
awkward
is
like
finding
the
right
home
for
this,
and,
like
I
guess
usually,
this
would
probably
be
done
hopefully
by
like
the
first
party
maintainer,
so
they
can
be
opinionated
about
where
this
type
of
code
lives
in
their
code
base.
But
for
me
I
just
like
I'll
just
slap
it
here
and
see
what
daniel
says.
I
D
Yeah
so
to
round
out
this
conversation
and
tell
me
if
any
of
this
is
inaccurate,
but
it
sounds
like
it
sounds
like
we
think
there
might
be
some
benefits
to
having
first-party
instrumentation
use
instrumentation
based
as
long
as
it's
not
like
a
huge
inconvenience
to
the
library
authors,
that's
to
kind
of
figure
out
this
system.
D
So
if
that
is
accurate,
then
maybe
our
stanch
should
be.
We
should
try
to
make
this
easy
for
first
parties
to
use
and
adopt,
and
maybe
we
will
need
to
make
a
few
tweaks
there
and
then
see
what
first
parties
have
to
say
about
this
and
kind
of
get
their
input.
Ultimately,
I
think,
like
this
is
one
test
case
and
then
anybody
else
who
is
like
trying
to
add
stuff.
D
I
think
we
want
to
be
very
interested
in
helping
them,
helping
them
get
off
the
ground
and
kind
of
getting
their
opinions
on
these
things.
H
H
I
know
it
doesn't
seem
like
a
lot
of
code,
but
it
would
be
really
nice
if
this
got
down
to
a
one-liner
for
common
cases.
D
Yeah,
so
I
I
definitely
think
there
are
improvements
that
can
be
made
to
to
make
this
a
little
bit
easier
and
those
will
become
apparent.
I
guess,
as
as
we
do
this
thing
quite
clearly,
I
think
like.
F
Yeah,
if
you're,
if
your
instrumentation
is
always
present
and
always
available,
then
it
does
feel
like
a
lot
of
ceremony
or
if
the
only
thing
you
need
to
check
is
perhaps
the
presence
of
a
specific
gem
version
or
something
you
don't
have
options,
etc.
It
could
be
made
simpler.
I
would
agree,
I
also
didn't
find
it
horrible,
but
yeah
the
easier,
the
better.
Generally
speaking,.
I
Yeah,
but
the
nice
hook
that
remains,
I
think,
is
like
the
compatible
hook.
I
could
see
being
really
nice
here
because
you
could
define
the
compatibility
with
your
like
as
a
maintainer.
You
could
say:
oh
this
instrumentation
is
only
compatible
under
whatever
criteria
so
like
that
one's
still
nice,
but
present
loses
all
of
its
value.
I
think
and
then.
H
I
H
Compatible
is
interesting
because
you
probably
want
to
invert
the
compatibility
check.
You
actually
want
to
see
what
versions
of
the
open
telemetry
api
or
sdk
you
might
be
compatible
with.
Arguably,
although
you
can
do
that
with
like
gem
spec
constraints,
but
it
it
might
be
interesting
to
think
about
use
cases
like
that,
generally
speaking,
if
you've
got
this
kind
of
first
party
instrumentation,
then
it's
always
going
to
be
compatible
with
itself,
but
is
it
compatible
with
open
telemetry
version
x?
Who
knows
yeah.
D
One
thing
that
I
had
in
the
back
of
my
mind
for
that
compatible
hook
as
well,
is
if,
if
you
are
redis-
and
you
are
first
party
instrumentation,
you
may
want
to
sniff
some
constants
to
see
if
you
also
have
the
open,
the
third
party,
reddit's,
instrumentation
and
kind
of
make
a
decision
off
of
that
or
or
vice
versa.
If
you're,
the
third
party
redis,
you
might
want
to
check
for
the
first
party,
so
so
yeah.
D
I
think
I'm
guessing
that
install
and
present
are
required
hooks
and
if
we
just
made
these
optional
things
that
have
meanings,
they're
provided
but
aren't
forced
to
be
here.
We
could
kind
of
streamline
this
all
a
little
bit.
I'm
sure
there's
plenty
more
things
that
that
we
can
add
to
this.
If
we
kind
of
take
the
first
party
point
of
view.
H
We
have
eight
minutes
left.
Do
we
want
to
dive
into?
I
don't
know
issues
pr's
questions
that
folks
on
the
call
might
have
the
one
thing
that
I
wanted
to
bring
up
is
it
would
like.
We
have
three
outstanding
things
before
we
can
declare
a
release
candidate.
I
had
a
hopeful
target
of
trying
to
get
that
done
this
week.
A
I
would
love
any
other
feedback
on
the
zipkin
stuff.
I
know
that's
kind
of
blocking
the
rc
there's
one
or
two
sounds
I
know
about
still,
but
I
definitely
could
use
some
feedback
on
the
flushing
and
retry
behavior
specifically
and
then
matt
as
I
poke
around
all
the
other
zipkin
implementations
and
complaints
it
just
it's
always
you
somewhere
down
the
line
on
those,
so
any
feedback.
There's
appreciated.
A
I've
spent
a
lot
of
time
with
sipkin
recently
for
other
unrelated
issues
trying
to
trace
on
envoy,
and
I
don't
like
the
spec
at
all
and
I'm
confused
by
it.
So
yeah.
D
Yeah
I
took
a
quick
look
at
that
yesterday
I
was
out
last
week.
I
probably
made
that
a
little
bit
more
clear,
so
I
I
did
a
lot
of
catch-up
yesterday.
So
if
anybody
was
wondering
where
I
was
that's
where
I
was
where
were
you
not
but
yeah,
I
can
take
a
look
at
the
connect
exporter.
I
saw
your
comment
that
there
you
tested
it
and
there
are
a
couple
things
that
are
still
outstanding,
so
everything
that
I
did
see
when
I
glanced
over
it
looked
decent.
A
Yeah
I
can
clean
up
those
it's
like
some
spam
tag
or
whatever
spanish
tributes
are
a
little
funky
in
a
couple,
but
it
might
just
be
the
tests
of
the
local
tests
but
yeah.
My
larger
concerns
are
that
I've
bought
something
in
the
core.
You
know
like
export,
which
I
don't
think
I
have,
but
it's
nice.
The
confidence
check
would
be
super
helpful.
If
someone
has
time.
D
Cool
yeah,
I
think
your
comment
was
talking
about
status,
was
looking
a
little
wonky.
A
D
D
A
I
don't
know
I
should
be
able
to
have
time
to
do
another
pass
on
those
other
issues
today
or
tomorrow.
My
week
was
a
little
crazy
this
week.
So
far.
Okay,
I
don't
have
any.
I
haven't
reviewed
the
jaeger.
I
can
also
review
the
jaeger
thing.
I
guess
I've
been
proved
familiar
enough.
A
few
weedy,
more
reviews
there.
I've
mostly
been
looking
at
the
other,
there's
been
a
couple
like
work
in
progress.
Pr's
that
I
was
trying
to
comment
on
with
little
help.
D
Cool
yeah,
I
did
make
another
pass
to
the
jaeger
propagator
yesterday
and
it's
looking
pretty
good
like
I
just
because
these
things
are
tricky.
I
did
do
like
an
end-to-end
test
with
it
and
I
discovered
a
bug
unrelated
to
the
jaeger
propagator
that
was
causing
baggage
problems
was
actually
like
breaking
propagation
altogether.
So
I
opened
that
pr
last
night
I
think
it's
already
merged.
So
that's
that's
good
news
and
then
I.
D
The
problem
actually
was
not
with
baggage
itself.
It
was
with
there's
a
rack
and
getter
that
kind
of
abstracts
away,
reading
keys
from
from
a
a
rack
end
or
just
like
regular
hash.
Basically,
it's
the
key
uppercase
with
http
appended
to
it
and
yeah.
Basically,
the
last
line
of
the
method
was
like
blah,
blah
blah
dot
up
case
or
blah
blah
blah
dot
down
case
bang
and
those
methods
are
tricky.
D
H
Yeah
for
the
jaeger
propagator.
I
have
this
draft
pr
for
implementing
fields
in
propagator
that
actually
changes
the
structure
of
the
api
a
little
bit.
I
expected
that
to
be
controversial
or
part
of
that
to
be
controversial
and
they
weren't.
So
that's
pleasing,
but
I'm
not
going
to
make
my
like
I'm
not
going
to
make
it
dependent.
H
Sorry,
I'm
not
going
to
couple
the
two
pr's,
so
whoever
gets
in
first
the
other
person's
going
to
have
to
do
some
work,
so
there's
probably
benefit
to,
like
the
other
francis
getting
that
in
first
so
that
you
force
me
to
do
the
work
in
my
pr
and
that's
cool,
I'm
I'm
fine
with
that.
D
Yeah,
so
I
think,
as
far
as
this
goes
like
I
said
I
I
did
an
end-to-end
test
with
this,
and
these
were
the
things
that
I
found
so
like
this
is
as
easy
as
just
adopting
that
these
docs
for
copy
pasta
before
I
did
a
refactor,
if
you
copy
pasta,
the
new
docs
you'll
be
good
this.
D
I
don't
know
how
this
wasn't
getting
hit
elsewhere,
but
I
was
getting
a
unfound
constant
error,
so
I
had
to
add,
add
trace,
because
these
are
in
open,
telemetry,
trace,
trace
flags,
and
the
nesting
of
this
propagator
will
not
find
that
constant.
D
And
then
this
was
this
other
one.
Where
I
think
I
was
actually
looking
at
ariel's,
ot
propagator
and
if
you're
setting
multiple
baggage
values
using
dot
build
will
be
be
more
efficient,
so
yeah,
I
I
think
I
don't
know,
I
don't
know
if
you
had
a
chance
to
look
over
these
comments
francis.
But
if
there's
any
questions,
let
me
know,
if
not,
I
feel
like.
D
Cool
and
then
we
can
unblock
other
francis's
keys
work,
and
we
can
look
at
that-
and
I
guess
we're
at
time,
but
the
other
thing
that
we
kind
of,
I
think
were
somewhat
discussing
was
looks
like
it's
actually
been
merged,
but
maybe
somewhat
related
to
fields.
Is
that
inject
both
mutates
the
carrier
and
returns
the
carrier?
D
H
Over
time,
yeah
there's
actually
an
inconsistency
in
the
spec,
but
the
spec
is
pretty
clear,
at
least
at
one
point,
we're
in
saying
that
the
carrier
is
expected
to
be
mutable,
so
the
top
pi
here
at
638
at
draft
pr
that
actually
makes
a
change
to
have
it
not
return.
The
carrier
got
it
cool.
D
D
All
right,
so
we
are
two
minutes
over.
We
at
least
touched
on
the
three
items
we
need
for
our
rc,
so
yeah
I'll
I'll
keep
an
eye
on
these
things,
and
I
am
I'm
on
the
clock
this
week.
So.
H
H
There
was
a
recent
spec
change
relating
to
the
user
info
being
removed
from
that.
So
I
had
a
pr
up
to
fix
that
this
morning.
Also
some
of
the
database
related
semantic
conventions
changed.
I
had
a
pr
up
yesterday
to
fix
those
as
well.
So
any
little
things
like
that.
Little
discrepancies
you
see
in
our
implementation
versus
the
spec
definitely
raise
issues
for
those.
H
D
Yeah-
and
I
guess
on
that
topic-
yeah
just
these
are
the
things
we
know
we
need
for
for
rc
that
are
missing,
but
there
are,
like
I'm
sure,
a
ton
of
things
that
we
will
find
through
the
rc
process,
that
we
should
open
issues
and
and
fix
that's
kind
of
part
of
the
ice.
The
rc
process
and.
H
For
new
folks,
we
have
two
milestones
here:
we've
got
the
rc
and
then
we've
got
the
actual
1.0
release.
The
second
milestone
largely
has
documentation
issues,
so
I
am
probably
going
to
defer
documentation
issues
to
to
the
second
milestone,
but
anything
relating
to
you
know
the
api
and
the
sdk
semantic
conventions.
That
sort
of
thing,
definitely,
you
know
open
them
and
I'll
tag
them
against
the
rc.
If
it
seems
like
they
would
block
the
rc.
H
A
This
yeah
that
guy
participates
the
guy
who
runs
that,
along
with
liz
from
honeycomb
had
mentioned
in
one
of
the
sigs
they're
looking
for
cfps,
I
think
they're,
especially
looking
for
end
users,
user
stories
or
whatever.
So
I
don't
know,
people
like
doing
that
stuff
I'll,
probably
submit
something
because,
like
I
don't
know,
there's
some
dev
evangelists,
who
probably
wants
to
date
a
dog
to
be
involved
in
some
way,
but
yeah.
Just
a
heads
up,
I
figured
I'd
share.
I
hadn't
seen
it
until
the
other
week.
D
Cool
all
right:
we
are
five
minutes
over.
So
let's
let
everybody
get
to
your
next
thing:
yeah
flag,
man,
any
pr's!
If
you
need
me,
there's
there's
a
cncf
slack
I'll,
be
paying
attention
there
as
well,
so
bring
stuff
up
for
for
the
new
faces.
Try
to
join
that
slack,
I'm
not
sure
what.
H
Yeah
discussion
was
happening
on
gitter
and
now
the
community
has
largely
moved
to
the
cncfs
cloud
native
computing
foundation
slack
and
there
are
various
open,
telemetry
dash
whatever
channels
in
there.
I
can't
remember
if
it's
hotel,
prefix
or
open
telemetry
hotel,
yeah.
H
G
Okay,
so
something
kind
of
minor
that
I
ran
into
while
trying
to
get
the
open,
telemetry
stuff
set
up
for
our
application.
I
could
be
a
little
wrong
here.
I've
read
through
so
much
documentation
on
different
projects.
The
last
few
days,
I
couldn't
find
anything
that
kind
of
listed
for
the
instrumentation,
like
the
the
gem
version
compatibility.
G
So
it
wasn't
until
you
kind
of
had
the
app
up
and
running
that
we'd
blow
up
for
some
things
like
for
us
we're
running
an
older
version
of
sidekick,
so
it
wasn't
until
it
tried
to
actually
make
one
of
the
calls
that
it's
like.
Oh,
the
method
definition
changed
from
being
like
three
parameters
to
four
and
there
isn't
really
anything
in
the
gem,
specs
limiting
versions
or
anything
like
that.
I
I'll
fix
that
they're,
basically
the
instrumentation
based
class
we've
been
talking
about
previously.
You
can
set
up
compatibility
check
and
I
did
not
set
kind
of
the
lowest
compatible
version
and
you
suffered
the
consequences.
G
D
Yeah,
I
think
that's
good
feedback,
and
I
think
we
will.
We
will
run
into
this
a
little
bit
more.
It
would
be
nice,
I
think,
even
with
instrumentation
based,
we
might
even
be
able
to
find
some
way
to
auto
generate
such
things,
but
it
would
be
nice
to
have
a
compatibility
matrix
for
for
things
or
at
a
bare
minimum
documentation
on
the
readme,
for
what
is
expected
to
work.
I
Just
an
over
over
but
ryan,
if
you
want
to
post
an
issue
on
it,
that'd
be
great
because
I
did
set
a
minimum
version
for
it.
So
if
you're
running
into
that,
that's
not
good.
G
I
know
there
was
a
similar
issue
around
like
rails
4
2
support
like
I
don't
know
what
thoughts
or
conversations
have
been
in
there
for,
like
you
know.
Clearly
we
don't
want
to
support
super
outdated
versions
of
things,
but
being
the
open
source
tracing
library
like
might
need
to
be
a
little
flexible
there.
I
don't
know
what
the
thoughts.
G
A
This
week,
if
we
support
rails
rails
too,
so
just
be
careful,
it
gets
ugly
yeah
exactly
welcome
to
instrumentation
so
zero
flex.
I
think
we
should
be
cut
through
it
and
like
be
not
super
helpful.
While
we
still
can
because
we're
getting
stuck
with
it
eventually.
G
A
You
fix
your
security
vulnerabilities
before
you
worry
about
your
observability,
crazy
old.
You
know
versions
of
stuff
right.
Sorry,
sorry,
I'm,
like
extremely
bitter
and
not
meant
to
I
didn't
mean
to
disparage
your
point.
I
think
it's
yeah,
you
need
it's
super
important
to
have
clearly
documented
what
our
versions
support
is
and
also
deprecation
policies
for
those
things.
I
D
Cool,
yes,
let's
wrap
this
up.
I
think,
and
we
can
continue
discussions
online
and
hopefully
see
everybody
next
week.