►
From YouTube: 2021-10-19 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).
B
Good
yeah,
that's
good!
That's
good
yeah!
How
was
how's
chicago
these
days
getting
cold
yet
still
decent
anymore.
A
It's
it's
in
that
phase
of
the
year
where
it
sort
of
oscillates
wildly
between
like
nice
and
like
slightly
uncomfortably
cold.
So
like
two
days
ago,
it
was
like
in
the
40s
in
the
morning
and
then
like
right
now.
I
think
the
high
today
is
like
73..
So
it's
that
part
of
the
year,
which
is
fine.
You
know
yeah.
B
Yeah
good
place,
quiet
in
jersey,
city,
just
you
know
new
job
I
mean
probably
doing
similar.
It's
like
you're,
just
trying
to
figure
out
how
everything
works,
new
job,
stuff
and.
A
B
B
Different
yeah,
I
I'm
sure
it's
you
know
same
but
different
or
do
trade-offs
or
whatever,
but
yeah.
That's
good
trying
to
think.
If
anything,
I
made
a
bunch
of
pulled
pork
that
was
my
exciting
I
ate
and
then
proceeded
to
eat.
That
said,
nice.
A
B
Exciting
for
sure
yeah
I
I
feel
I
never
did
it
until
like
college,
and
then
I
was
like.
Oh,
this
is
like
a
lot
of
fun,
and
now
it's
like
I
need
to
like
find
more
people
to
carve
pumpkins
with
me.
Yeah
I'm
just
not.
The
problem
is
like
I
like
other
people's
pumpkins
mine
are
always
like
it's
sort
of
like
an
amorphous
object.
Well,.
A
A
E
E
A
B
F
F
Like
my
whole
life,
I
would
just
like
hack
at
it
with
like
a
random
knife
like
in
some
cases,
potentially
a
butter
knife,
and
then
we
did
like
this
pumpkin
carving
contest
at
a
previous
company
and
like
someone
rolled
in
with
like
a
tool
kit
like
it
was
like
exacto,
knives
and
shavers
and
all
this
stuff
and
like
we
actually
ended
up
having
a
really
nice
pumpkin,
and
I
didn't
think
that
was
possible
from
me.
So
it
was
like
that.
I
realized
that,
like
having
the
right
tool
actually
absolutely
changes,
everything.
G
B
H
B
I
just
did
a
dutch
oven,
it
was
more
like
carnitas,
I
guess
it
was
like
a
dutch
oven.
I
don't
have
a,
I
have
a
sous-vide,
but
I
don't
have
a
green
egg
or
anything.
I.
E
B
Yeah,
I
have
a
photo
somewhere,
I
posted
yeah.
It
was
good
it's.
I
followed
the
kenji
lopez
recipe
which
involves
a
lot
of
oil,
but
yeah
come
hang
out.
You
just
promise.
You
gotta
come
to
jersey,
city
yeah.
It
was
really
good.
You
know
turns
out
it's
really
hard
to
mess
up.
If
you
just
apply
time-
and
you
know
these
must
be,
but
I
don't
know
if
that
photo
is
publicly
available.
F
E
B
This
whole
essay
around
how
he
did
all
this
is
that
kind
of
scientific
around
how
using
oil
instead
of
stock
allows
the
meat
to
it's
like
allows
to
get
into
that
like
collagen
to
gelatin
like
zone
without
it
drying
out
or
something.
But
I
didn't
really
follow
that
I
just
did
like
stock
and
some
orange
juice
and
a
little
oil,
and
it
was
great
tastes
good
anyway.
H
I
have
a
pellet
smoker,
so
I
I
regularly
will
like
a
brisket.
I
occasionally
do
pulled
pork,
always
good
piles
of
like
shreddy
meat
are
definitely
up.
My
alley.
H
H
We
shall
now
move
on
to
the
spec
sig,
which
is
actually
super
quick.
So
I
don't
know
I
feel,
like
everybody
feels
like
tracing
is
done
for
the
most
part,
these
first
couple
things
are
semi-related,
but
then
most
of
it
was
a
matrix
update.
H
So
there
was
an
otep
around
schemas
and
there
are
three
kind
of
spec
prs:
that
kind
of
move
all
those
ideas
formally
over
to
the
spec.
So
those
need
to
be
reviewed.
I
need
to
look
at
them
because
the
next
comment
I'm
still
trying
to
get
like
an
idea
of
how
these
are
supposed
to
work
in
practice.
I
feel
like
I
have
like
a
really
you
know,
100-foot
view
of
this,
but.
H
John
was
asking
about
how
to
support
in
language
constants
for
semantic
conventions,
and
the
problem
he
was
describing
is
how
the
contents
can
evolve
without
breaking
instrumentation
libraries
that
use
older
versions
of
the
of
so.
H
H
But
yeah,
like
I
was
saying
I
feel
like
I
need
to
go.
Read
all
the
specifications
about
how
we're
actually
supposed
to
use
use
the
schema,
because
my
impression
was,
you
could
have
like
an
older
version
of
the
semantic
conventions,
library
using
the
older
versions
of
the
constants.
But
if
you
and
then
you
would
just
advertise
your
schema,
is
that
older
schema
and
then
the
receiver
would
be
able
to
kind
of
upgrade
or
leave.
As
is
like
your
your
constants,
like
whatever.
Actually
the
receiver
cared
about
for
the.
B
Yeah
my
I
have
to
read
these
three
things
I
had
also.
I
guess
you
just
yeah.
They
were
all
open
yesterday,
so
I
have
to
catch
up.
I
have
a
pr
implementing
schema,
url
and
ruby
that
is
open
for
review.
B
It
looks
like
one
of
them
is
relevant
here,
given
he's
talking
about
resource
detector,
whether
resource
detectors
should
supply
a
schema
url,
which
I
think
they
should.
But
my
understanding
was
you
yeah.
You
wouldn't
use
the
new
constants
with
an
older
schema.
The
whole
point
is
to
allow
that
translation
to
occur
within
a
processor
downstream
as
long
as
you
just
advertise
what
constants
you're
using
or
what
you
know.
As
long
as
you
send
along
the
schema
url
you're
using
so
and
if
you're
generating
the
constants,
you
would
just
you
wouldn't.
B
The
only
other
thing
I
found
is
that
it's
effect,
it's
not
a
particularly
useful
thing
in
practice
the
schema
url
outside
of,
like
I
think
it
helps
instrumentation
library,
authors,
do
the
sort
of
write
it
once
and
then
move
on
and
not
have
to
worry
too
much
about
like
updating
things,
but
I
don't
think
it's
a
terribly
useful
tool
like
given
what's
available
in
schema
urls
at
the
moment,
which
is
essentially
just
like
mapping
of
key
value.
B
B
So
I'm
not
sure
if
that
answers
or
helps
anything,
but
if
you're
it
would
be
nice
to
merge
in
the
schema
url
pr.
So
you
know
if
anyone's
reviewing
it.
I
guess
if
you
notice
anything
in
these
three
things
here,
please
let
me
know
if
I
missed
something,
because
I
I
didn't
take
these
into
account.
H
Cool
yeah,
I
guess
it'll
be
good
for
me
to
read
through
these
and
then
read
through
your
vr.
That's
why
I
feel
like
I
have
a
a
better
understanding
of
all
this.
H
So
that
was
kind
of
it
before
moving
on
to
the
metrics
update,
so
I'll
kind
of
quickly
go
through
that
they
are
trying
to
reach
feature
freeze
on
the
sdk
by
the
end
of
the
month,
and
I
guess
there
are
three
prototypes
in
flight
java.net
and
python.
H
H
Yeah,
that's
kind
of
the
overall
status
there
there's
this
project.
If
you
want
to
see
all
the
stuff
there,
the
two
issues
that
were
discussed
during
the
meeting
yeah-
I
don't
know
how
much
we
care
about
human
stuff
at
this
point
in
time,
but.
H
And
they,
I
think,
we're
talking
about
this,
a
little
bit
before,
where
there
is
this
desire
to
add
min
and
max
to
the
histogram,
and
I
think
it
was
causing
some
complications
depending
on
your
depending
on
the
way
you
want
to
aggregate
it
like
min
and
max,
didn't
make
sense
for
I'm
not
sure
if
it's
cumulative
or
delta
or
if
it
was
just
something
else
altogether.
But
there
was
with
all
the
schemes
that
we
support.
I
guess
like
min
and
max
was.
H
Yeah,
like
the
values
didn't
make
sense,
maybe
it's
for
accumulative
histogram,
I'm
having
trouble
recalling,
but
this
is
trying
to,
I
think,
ultimately
introduce
like
a
histogram
variant
that
a
min
and
max
would
work
for,
and
they
were
talking
about,
calling
it
a
mid
max
sum
count.
Histogram.
H
H
At
any
rate,
when
we
get
around
to
implementing
in
metrics
sdk,
there
might
be
a
couple
versions
of
a
histogram,
and
one
of
them
like
mid
and
max
will
make
sense,
and
one
of
them
it
well.
I
guess,
will
not
have
to
be
implemented.
H
Ultimately,
I
think-
and
I
guess
what
was
coming
up
was
they
were
trying
to
change
that
on
like
a
per
instrument
basis
through
views,
and
everyone
was
saying
that
that
was
a
little
bit
weird.
I
think,
ultimately,
the
person
who
was
opening
this
was
from
a
new
relic
and
he's
basically
was
saying
they
don't
really
care
about
per
instrument
temporarily
temporality
overrides.
So
this
is
basically
like.
H
Is
your
metric
value
like
a
cumulative
value
or
is
it
a
delta
value
and
he
was
saying
they
just
care
that
you
can
configure
this
for
all
instruments?
So
I
think
they
were
going
to
take
like
a
another
look
at
this
and
just
respect
this
so
that
you
could
specify
temporality,
maybe
like
at
the
exporter
level,
where,
like
I
want
all
deltas
or
I
want
all
cumulatives
and
streamline
it
rather
than
kind
of
having
it
on
a
per
instrument
basis.
H
So
yeah,
I
don't
know
if
I've
done
justice
to
any
of
these
issues
or
how
far
along
anybody
is
on
kind
of
the
metrics
stuff.
I've
been
just
kind
of
like
I
don't
know,
I've
been
exposed
to
a
lot
of
conversations
and
I've
read
through
like
enough
prs,
but
I
haven't
done
like
a
lot
of.
H
I
don't
know
lot
of
the
grunt
work
myself
on
it
all,
but
I
think,
like
the
biggest
thing
is
the
I
don't
know
for
me
like
understanding
the
the
different
temporalities
and
why
they
matter,
but
basically
kind
of
like
the,
if
you're
used
to
like
statsd,
where
you
kind
of
send
send
metrics
every
period
and
then
kind
of
reset
your
instruments.
H
That's
really
kind
of
like
this
delta
temporality,
where
you
are
sending
kind
of
like
data
for
for
these
individual
time
periods,
and
then
things
kind
of
reset,
and
then
there
are
kind
of
these
other
systems
where
everything
is
cumulative.
H
It's
kind
of
like
how
prometheus
works
so
like
your
counters
are
just
always
kind
of
increasing
in
value,
but
the
back
end
is
kind
of
like
doing
the
these
subtractions
to
kind
of
figure
things
out
for
you
and
it
seems
like
you
know.
There
are
a
lot
of
different
metric
systems
out
there,
but
they
generally
kind
of
like
fall
into
one
one
of
those
two
categories
and
there's
a
lot
of
a
lot
of
work
to
make
sure
that
everything
will
work
well
for
for
both
of
those
schemes.
F
Yeah,
that's
good
to
call
it
because,
like
I'm,
not
I
haven't
started
on
it
yet,
but
like
it
very
much
is
more
than
just
a
fleeting
intention
to
work
on
the
metrics
portion
of
open,
telemetry
ruby.
I
have
like
some
internal
stuff
that
I'm
focusing
on
right
now
at
the
company,
we're
almost
done
like
migrating
the
entire
ruby
fleet
at
shopify.
So
once
that's
done,
we
well
I'll
be
working.
I
want
to
work
on
the
metric
stuff.
H
Cool
yeah
and
and
as
a
cheat
sheet,
I
guess
there
are
those
sdk
implementations
already
in
progress
for
for
java.net
and
python.
So
if
you,
if
you
like
reading
code
in
any
of
those
three
languages,
there's
probably
something
out
there.
F
Yeah
definitely
like
I'll
try
to
draw
inspiration
from
those
ones
as
well
as,
like
you
know,
even
like
when
I
show
up
for
the
tracing
aspect
of
this.
It
was
very
much
far
along,
so
I
was
just
building
on
top
of
it.
It'll
be
fun
to
be
doing
the
the
foundation
of
the
metric
stuff.
So
I'm
pretty,
I
want
to
say-
and
I
give
you
a
excited
to
start
building
this
out.
I
think
it'll
be
really
useful,
so.
H
Yeah
yeah,
it's
always
fun
to
be
able
to
to
start
a
new
feature
rather
than
come
in
kind
of
like
halfway
through
and
play
catch
up
for
a
while,
but
but
yeah
the
the
metric
stuff
is
definitely
fairly
dense.
I
think
and
just
kind
of
understanding
all
the
terminology
and
why
the
whys
of
all
the
different
things
that
are
supported.
H
Excellent
dents
plus
dance
yeah,
they
they're
a
perfect
match.
F
For
the
the
instrumentation
saying,
I've
been
fairly
neglectful
like
last
week.
I
wasn't
there
the
week
prior
to
that.
I
only
caught
parts
of
it.
So
I
don't
really
have
anything
interesting
to
share
today.
Unfortunately-
and
I
don't
know
if
I'll
be
able
to
make
tonight
work
it
honestly,
the
timing
is
kind
of
rough
just
because
it's
like
smackdown
in
the
middle
of
the
evening,
so
I
have
to
run
out
and
do
stuff.
That's
either
like
the
sig
or
you
know,
go
get
groceries.
F
But
I
do
intend
to
like
keep
going.
It's
just
it's.
The
last
couple
weeks
have
been
difficult
and
today's
not
going
to
be
much
better,
but
I
will
continue
to
try
to
attend,
so
I
can
bring
back
stuff
there
and
continue
to
provide
friction
and
be
the
grain
of
sand
that
is
irritating
to
them
when
they
try
to
push
things
that
don't
necessarily
align
with
what
we
think
makes
sense.
H
Yeah
yeah,
no,
it
makes
it
makes
sense
for
us
to
have
somebody
participating
just
so
we
don't
get
stuck
yeah
so
that
we
can
participate
in
kind
of
shaping
the
way
that
that
stuff
goes
and
we
don't
just
get
stuck
with
whatever
some
other
group
decides
so,
but
yeah,
like
I
understand
scheduling,
is,
is
always
a
thing
so.
H
I
was
gonna
double
check.
I
know
like
I
wasn't
here
last
week,
but
the
week
before
tristan
was
asking
about
doing
a
joint
blog
post
between
like
ruby,
javascript
erlang
did.
Does
that
talked
about
last
week?
Has
any
movement
been
made
there.
B
I
told
tristan
I
would
talk
to
robert
and
then
I
forgot
until
about
30
minutes
ago,
so
so
no
yeah.
I
know
robert
is
interested
in
that
I'm
not
sure
if
the
timing
lines
up
with
what
tristan's
doing,
though,
so
I
won't
speak,
I'm
not
sure
I
don't
know.
If
there's
been
any
consensus,
though.
F
Yeah
so
like
the
idea
is
that
they're
just
want
to
do
like
a
blog
post,
announcing
like
the
1.0
of
multiple
language
implementations
like
I
can
just
reach
out
to
him.
I
don't
know
what
exactly
he's
looking
for
I'm
kind
of
missing
a
bit
of
context
here.
Is
it
like
just
someone
to
write
up
a
little
butter
for
ruby
or.
H
Yeah,
I
think
so
I
think
that's
probably
what
is
involved,
but
I
think
the
first
step
is
to
just
like
pinterest
in
and
just
mention
that
we're
interested.
What
do
you
need
from
us
and
yeah
yeah.
F
H
Yeah,
that
sounds
good,
so
I
guess
with
that
we
can
move
on
to
everything
there.
A
Yeah
I
put
that
in
there
I
just
I
noticed
it
this
morning
it
looks
like
the
the
the
person
behind
the
soccer
team
socket
tree.
Gem
has
implemented
their
own
metrics
and
traces
like
meta
wrappers,
with
like
configurable
back-end,
support
and
stuff,
which
is
cool
and
maybe
necessary
for
that
framework,
but
it
feels
a
little
bit
like
kind
of
actually
what
the
open
telemetry
project
is
trying
to
do
in
general.
So
I
didn't
really
have
much
to
say
about
it.
A
Actually,
I
was
just
kind
of
curious
if
people
had
read
it,
what
they
thought
if
they're
familiar
with
kind
of
the
work
that
they're
doing
in
this
this
area,
I
don't
know
just
seemed
like
something
we
should
maybe
keep
an
eye
on
and
try
and
I
would
hate
to
there
to
be
duplication
of
work
in
the
ruby
ecosystem.
Kind
of
feels,
like
the
goals
are
similar.
A
A
A
The
the
unwatch
button
up
at
the
top
there
should
be
what
options
are
there
for
us.
There
should
be
like
yeah,
I
guess
maybe.
G
B
Yeah,
no,
I
didn't,
I
mean
it
feels
duplicative
but
off
to
review.
What
are
you
saying,
yeah.
H
There
is
yeah
just
yeah,
so
there
is
like
there
is.
This
kind
of
I
don't
know,
conscious
distinction
between
the
open
telemetry
api
in
the
open,
telemetry
sdks
and
like
historically
going
back.
This
was
there
was
basically
before
open
telemetry,
there
was
open
tracing
and
there
was
open
census
and
open
tracing
was
like
just
an
api,
and
that's
really
all
it
focused
on,
and
then
anyone
who
wanted
to
kind
of
implement
an
sdk.
H
They
all
implemented
their
own
kind
of
like
api
compliant
sdk,
and
that
I
don't
know
that
whole
system
allowed
you
to
kind
of
build
things.
We
could
share
instrumentation
but,
like
the
rest
of
the
stuff,
is
kind
of
unshareable,
and
then
there
was
the
open
census.
Approach
was
kind
of
like
we're.
Gonna
build
you
a
bunch
of
gold-plated
amazing
sdks,
but
the
we
don't
expect
that
anybody
else
would
actually
kind
of
write.
One
situation
and
open
telemetry
kind
of
being.
H
The
merger
of
these
two
projects
has
kind
of
adopted
both
of
those
strategies.
There
is
like
this
distinction
between
api
and
and
sdk,
so
I
feel,
like
we
end
up
getting
in
this
situation
with
open
telemetry,
especially
like
on
the
sdk
side,
where
we're
trying
to
build
something
that
will
work
for
absolutely
everybody,
and
I
think
that's
nice
and
it's
a
good
goal.
H
H
I
don't
know
streamlined
for
your
use
case
and
in
that
way
like,
if,
if
you
wanted
to
shoulder
that
burden
of
kind
of
like
maintaining
your
your
own
kind
of
lightweight
or
alternative
sdk,
I
think
that's
not
not
a
horrible
thing
and
it's
actually
kind
of
one
of
the
goals
of
the
project
I
think
is
to
is
to
allow
for
this
and,
I
think,
yeah.
H
I
think
you
would
want
to
make
sure
that
you're
not
like
having
these
alternatives
in
conflict
and
if
there
are
things
that
you
can
kind
of
like
share-
and
you
know
work
on
together,
I
think
that's
that's
a
good
thing
to
try
to
like
foster,
but
if
somebody
is
trying
to
to
say
I
have
only
these
specific
use
cases
and
or
these
the
smaller
set
of
use
cases
and
want
to
build
this
alternative.
Sdk.
A
Yeah,
it's
interesting.
I
wonder
if
I
wonder,
if
like
what's,
what
would
come
out
of
this,
is
that,
like
the
the
socketry
sort
of
async
framework
needs
a
different
sdk
implementation,
because
this
almost
feels
like
an
api
and
an
sdk.
That's
then
designed
to
maybe
plug
into
the
open,
telemetry,
api
and
sdk,
which
feels
like
layers
on
layers
of
abstraction.
But
maybe
this
is
maybe.
This
is
a
use
case
where
an
alternative,
sdk
implementation
is
actually
what's
more
interesting,
I'm
kind
of
curious
to
see
what
they
come
back
with.
H
Yeah,
I
mean
ultimately
if
they
wanted
to
adopt
the
open,
telemetry
api
and
then
tell
whoever
to
plug
in
their
their
sdk
implementation,
and
I
think
that
that
would
be
perhaps
the
best
way
forward
for
them,
except
for
we
need
this
metrics
piece.
Yeah,
that's
true,
yeah.
F
I'm
just
like
looking
at
the
sock
tree
repo
in
there
and
it
it's
weird.
It's
like
the
traces
looks
like
it's
just
its
own
api.
Again,
like
it
looks
look
I
I
just.
I
wonder
if
this
is
not
just
like
recreating
some
of
what
we
already
have.
It
was
kind
of
shamelessly
just
like
going
through
the
repo
you
guys
were
discussing
this,
but
then
there's
like
an
implementation
of
an
open,
telemetry
back-end.
So
it
seems
like
it's
its
own
api
and
sdk.
I
think
like
what
people
were
saying
is
like
it.
F
It
just
seems
like
there's
a
bit
of
overlap
here.
I
wonder
if
we
could
potentially
encourage
them
to
attack
open
telemetry,
because
I
just
I
wonder
what
like
what
problem
this
is
actually
solving.
B
I
I
probably
can
answer
that
which
is
you
know.
This
is
probably
written
for
data
dog,
I
think
they're,
a
user
and
the
data
dog.
So
like
I
mean
I
don't
you
know,
I
don't
want
to
misspeak,
I'm
pretty
sure.
They're,
a
user
and
the
data
dog
sdk
is
an
api
or
you
know,
sort
of
bullshitty,
non-existent
and
wavy.
Whatever
works
for
data
like
they're,
not
well
doc,
they're,
not
documented,
and
don't
really
like.
So
it's
possible
that
and
the
open
telemetry
data
dog,
like
compatibility,
is
sort
of
yeah.
B
You
know
could
be
better,
so
that
might
be
a
blocker
is
like
he
might
be,
like
the
primary
target
might
be
his
specific
use
case,
which
is
datadog
and
then
it's
like
for
shoehorning
the
open
telemetry
stuff
in
there,
and
if
you
were
to
rely
on
the
open,
telemetry
stuff,
it
might
not
work.
I
don't
want
to
misspeak,
maybe
yeah.
Maybe
we
should
ask
ask
them
to
clarify
or
something
like
that.
F
Because
it
almost
seems
like
it's
like
sdk
agnostic
right,
like
it's
being
proposed
like
fender
agnostic,
but
it
seems
like
it's
sdk
agnostic
like
you,
could
plug
in
your
own
back
end
here,
but
that
would
be
just
like
here's
how
you
could
plug
open
telemetry
as
your
back
end.
So
it's
like
I
don't
know,
I
I'm
not
trying
to
be
too
critical
of
it.
F
I'm
just
trying
to
kind
of
understand
the
motivation
here
and
I
think
it's
probably
best
to
just
engage
with
them
over
the
discussion
and
see
what
they're
looking
to
solve
here
and
I
guess,
like
maybe
people
want
to
have
different
tracing
back
ends.
So
it's
like
I'm
just
trying
to
think
of
like
what
what
that
someone's
poor
setup
could
look
like
if
they
use
this.
It's
like
you,
have
this
back
end
or
sdk
agnostic
one.
So
it's
like
you're
using
this
trace
layer.
F
You're,
adding
a
lot
of
spider-man's
pointing
at
spider-man's.
A
I
appreciate
your
your
use
of
the
mean:
that's
that's
good
yeah.
I
guess
I
kind
of
I'm
I'm
curious
to
see
what
they
come
back
with,
because
I
I
also
feel
it's
a
lot
of
overlap
that
I
don't
understand
necessarily,
and
I
want
to
find
out
what
the
motivations
are.
So
we
can
collaborate
more.
I
suppose,
rather
than
have
different
tracing
standards.
H
A
B
You
can't
that's.
The
point
is
like
datadog
support
is
not
the
datadog
agent
has
doesn't
have
I
mean?
Maybe
they
have.
They
had
experimental
support
for
otlp,
but
I
it
was
in
a
beta.
I
don't
know
if
he's
aware
of
this
or
was
part
of
that
beta,
so
like
it's
possible
as
a
user,
a
specific
user
may
have
a
data
dog
agent
running
on
the
infrastructure
and
not
want
to
have
to
migrate
all
their
stuff
to
an
open,
telemetry
collector
or
you
know,
have
some.
B
Let
me
kind
of
do
this
thing,
so
I
can
position
myself
to
be
more
flexible,
but
in
the
meantime
I
can,
you
know,
still
ship
all
my
stuff
directly
to
the
datadog
agent
in
digital
format,
but
you
know
it
does
have.
It
will
have
one
of
these
days
it'll
go
to
lps
support.
I
wrote
I
wrote
it
before
I
left,
but
it
was
even
experimental
and
like
kind
of
was
only
being
dummy
like
beta
tested
with
maybe
a
few
people
who
may
nameless
anyway.
H
Potentially
they
would
be
a
good
candidate
for
first
party
open
telemetry
instrumentation
if
we
could
kind
of
sell
them
on
the
fact
that
you
just
bake
in
the
open,
telemetry
api
and
all
these
back
ends
actually
will
should
come
from
the
open,
telemetry
community.
Ultimately,.
E
H
F
Yeah,
like
part
of
this,
also
looks
like
a
an
attempt
at
an
instrumentation
api
right.
Like
we've
talked
about
that
a
little
bit
because,
like
like
an
I,
don't
know,
it's
the
zero
cost
thing
I'm
looking
at
that
it
looks
like
it's.
Basically,
it's
just
a
bunch
of
dynamic
pre-pending
right.
If
you
have
a
back
end
set
up
which.
F
Yeah
yeah,
this
is,
I
think
we
should
just
engage
with
them
and
talk
to
them
and
see
if,
like
we
or
can
serve
their
needs
better,
and
if
we
can't,
because
a
certain
vendor
doesn't
support
open
telemetry,
then
that's
hard
for
us
to
solve
for
them
right,
but
that
that
would
be
disappointing
if,
like
that
was
like,
like
I
don't
know
it
just
like
this
smells
a
bit
of
like
another
standard
someone
trying
to
come
up
with
their
own
standard
of
solving
a
problem
that
potentially
already
solved.
H
B
H
Yeah,
that
sounds
good,
so
I
would
encourage
people
to
participate
in
that
discussion
and
if
it
looks
like
it's
interesting,
we
can
we
can
always
let
the
maintainer
know
that
we
have
this
meeting
and
like
show
up
and
maybe
have
have
some
face-to-faces
and
see
if
it
makes
sense
for
them
to
kind
of
adopt
open,
telemetry
natively,
because
this
is
like,
ultimately
like
the
goal
of
of
the
project
in
the
longer
term,
so
yeah
having
some
some
people
blaze.
That
trail
would
be
great.
H
F
Is
there
something
to
move
on
to
respond?
There's
an
open
power
bite
eric.
I
think
it
looks
good
just
I
want
to
let
anybody
else
have
a
chance
to
look
at
it
before
I
just
went
ahead
and
merged
it.
I
usually
try
to
let
two
people
look
at
it
before
I
go.
It's
the
race
condition
with
gzip
errors.
F
I
think
it
looks
fine,
I'm
ready
to
just
go
ahead
and
merge
it,
but
I
figured
we
had
the
sig
today
and
just
give
people
a
second
chance
to
look
at.
It
looks
like
some
lower
level.
Zealand
error
that
seems
to
be
intermittent.
B
Perfect
yeah,
I
mean,
if
we
see
it
occurring
more
frequently,
we
can
maybe
try
to
address
the
recalls
but
like
let's
not
block
the
yeah,
no
retries
they're
fine.
F
That
was
easy.
That
was
the
only
thing
really
on
my
radar.
I've
been
more
focused
on
like
internal
things
right
now
and
just
like
the
adoption
of
open
telemetry
in
general,
rather
than
open,
telemetry
itself
working
on
an
application.
That's
interested
like
implemented
some
interesting
concepts
themselves,
just
kind
of
like
went
rogue
and
they
they
have
this
concept
of
their
app
of
verbose
mode
for
tracing
where
traces
are
conditionally
enabled,
if
they're
wrapped
in
the
context
of
something
being
verbose.
F
I
think
that's
an
interesting
idea.
I
don't
necessarily
care
for
the
way
they
implemented
it.
It
seems
fine,
but
I
don't
know
if
it's
like
enough
to
like
push
up
stream,
but
it
is
an
interesting
idea
that
has
come
up
a
few
times
of
like
having
a
verbose
mode
for
instrumentation,
like
I
think
of
like
the
graphql
instrumentation
and
resolving
certain
fields
like
tracing
the
time
around.
F
How
long
it
takes
to
resolve
fields
can
be
very
insightful,
but
it
also
makes
your
traces
explode
if
it's
a
big
graphql
query,
so
you
don't
want
that
on
by
default,
but
it
would
be
cool
if
you
could
conditionally
enable
this,
like
verbose
mode
on
a
single
request.
So
I've
been
thinking
about
that
a
bit
more.
Maybe
we
can
propose
something
there
because
I
feel
like
that
comes
up
enough
now,
where
people
want
these
added
details,
but
you
just
don't
want
them
all
the
time.
F
We
don't
really
have
an
answer
for
that
right
now
in
open
telemetry.
B
I
used
to
be,
I
think,
like
zipkin
had
sort
of
like
a
flag,
you
could
send
that
with
some
sort
of
like
vague
debug
flag.
Maybe
that's,
although
that
might
have
been
specific
to
sampling,
but
that
might
be.
I
don't
know
how
we
could
do
it
for
just
root.
There's
probably
some
ways
we
could
sneak
in
for
just
a
review
without
having
to
worry
about
like
some
crazy
otep
w3c
thing,
but
that
might
work
yeah.
I
agree.
I
think
it's
super
useful.
F
Yeah
yeah
and
there's
like
a
couple
other
things
that
are
kind
of
on
the
radar,
I'm
just
kind
of
like
brain
dumping
right
now,
just
to
maybe
share
what
we're
looking
at
internally
right
now,
tim's,
starting
on
a
pretty
big
migration
for
our
flagship,
app
at
shopify,
and
so
things
that
we
do
like
on
some
of
these
apps
are
like
track,
object,
allocations
and
garbage
collection
and
stuff
like
that,
and
we
have
a
couple
apps
like
one
of
the
one,
I'm
migrating
right
now
and
one
of
the
ones
tim's
starting
on
right
now,
and
we
want
to
make
that
more
generally
available
and
like
where
that
should
live.
F
If
we
want
to
like
keep
that
inside
of
shopify
or
ideally
it'd
be
nice,
if
we
could
push
it
upstream,
but
it's
just
I'm
not
sure
where
it
fits
at
the
moment,
because
it
probably
has
to
interact
with
your
rack
span
a
bit
and
it's
like
just
trying
to
get
a
sense.
So
that's
like,
hopefully
going
to
be
coming
up
soon.
We'll
see
some,
maybe
some
upstream
pr's
around
that,
hopefully
to
share
that
with
the
community.
F
Then
there
was
another
one:
adding
support
for
in
iraq,
I
think
would
make
sense
where
it
would
exist
is
to
force
the
sampling
priority
say
like
you
should
sample
this
request
pending
like
a
specific
flag
like
giving
the
ability
to
like
for
us
like
we
have
some
more
higher
volume
apps.
There
are
their
samples
at
the
application
level,
but
sometimes
you
just
want
to
give
a
developer.
The
ability
to
like
say,
hey,
make
sure
this
gets
traced,
because
I
really
need
to
look
into
this
and
right
now
like.
F
That
is
also
something
that
isn't
covered
in
open
telemetry
formally.
But
there
is
a
demand
for
it
internally
and
I
imagine
other
companies
probably
could
make
use
of
it.
The
developers
could
probably
make
use
of
this
so
there's
a
few
things
that
I
think
need
to
interact
with
rack
instrumentation,
but
I'm
not
sure
how
exactly
they're
going
to
fit
so.
H
That
last
thing
like
I
feel
like
you,
can
definitely
use
w3c
trace
context,
for
all
of
that,
like
you
would
probably
want
to
use
like
if
you
have
kind
of
some
custom,
some
custom
sampling
stuff
that
you
want
to
do
just
like
shopify.
That
might
not
be
something
that
everybody
wants
an
open
telemetry,
or
that
it's
going
to
be
way
too
hard
to
kind
of
get
specs
at
that
level.
H
It's
like
you
could
have
your
own
trace
data
entry,
that
kind
of
carries
any
additional
metadata
that
you
need
for
the
tracing
system
and
one
of
those
things
could
be
just
like
capture
this
capture.
This
trace,
at
least
for
shopify,
regardless
of
what
the
the
sampling
bit
says,
and
then
the
way
that
you
would
have
to
kind
of
implement
that
using
the
rest
of
the.
H
Have
to
have
a
custom
sampler
that
reads
the
the
shopify
trace
date
entry
and
does
something
special
based
on
it.
But
yeah
I
mean
there
are
yeah
there
there.
While
there
are
like
a
lot
of
options
out
of
the
box
that
are
going
to
work
for
everybody.
I
think
there
is
like
this
whole
yeah.
This
whole
series
of
other
possibilities
that
that
can
be
can
be
done
as
needed
for
for
people
using
open
telemetry
with
doing
like
a
little
bit
of
custom
stuff.
H
So
it's
not
like
rewriting
everything
but
just
kind
of
having
your
yeah
having
having
like
a
a
propagator
that
subclasses
the
the
w3c
one,
or
at
least
just
hooking,
into
the
tray
state
there
and
probably
having
a
custom
sampler
to
do
something
special
based
on
the
trace
date.
Yeah.
F
Here's
how
you
do
it,
oh,
like
anybody
else,
who's
consuming
all
the
temperature
ruby,
just
like
kind
of
trying
to
give
back
in
the
sense
that,
like
we've,
already
figured
out,
let's
just
share
the
solution
so
that
people
can
just
easily
adopt
it
where
they
need
it.
Not
everyone
has
to
kind
of
figure
it
out
on
their
own.
F
That's
more!
The
intention
like
I
know
we
can
figure
out
internally
and
just
keep
it
there,
but
the
idea
of
like
contributing
it
back
in
some
capacity.
Even
if
it's
not
expected,
I
think
there's
there
should
be
a
spot
for
that
or
it
would
be
nice
if
there
was
a
spot
for
that
and
somewhere
rebar,
maybe
the
contrib
repo
that
doesn't
exist.
That's.
B
What
I
was
about
to
say
is,
I
feel,
like
we've
had
a
few
where
it's
like,
oh,
like
with
that
stupid,
I
did
like
a
a
batch
trace
processor
for
a
while
ago,
and
that's
sort
of
like
has
you
know
like
died
in
darkness
as
I,
because
it
wasn't
and
there's
like
kind
of
nowhere
to
submit
it,
but
it
feels
like,
and
we
don't
have
a
contrib
thing
so
like
it
sort
of
feels
like
it's
like,
not
instrumentation,
but
kind
of
could
live
in
and
also
like,
not
something
like.
B
B
Maybe
there's
enough
of
these
random
things
and
even
like
resource
detectors,
maybe
like
where
we
could
start
to
have
a
reason
to
maintain
a
separate,
contrib
repo,
even
though,
like
I
don't
know
it's
if
otherwise
it
starts
to
just
get
real
messy,
even
if
it's
just
like
the,
I
sometimes
feel
like
the
expectations
of
it
just
living,
even
if
it's
technically
can
trip,
but
it
lives
in
our
re.
You
know
open
telemetry,
ruby.
It's
like
users
find
it
and
they're
just
like.
Oh
it's!
D
D
B
E
B
H
Cool
yeah,
all
that
discussion
was
good,
definitely
thumbs
up.
I'm
trying
to
contribute
things
back
that
that
we
think
the
community
could
use
longer
term.
I
do
think
we
need
to
figure
out
our
story
with
contrib.
I
think
it's
always
kind
of
like.
H
I
think
we
know
it's
something
that
we
want
to
do.
It's
just
been
a
matter
of
like
getting
the
stuff
set
up,
setting
up
the
policies
like
figuring
out
how
we
want
to
manage
all
of
that,
like
it's
kind
of
like
a
non
non-trivial
management.
B
You
go,
we
contribute
to
cloud
events.
I
had
one
quick
thing.
I
have
a
pr
in
there
for
the
ad
config
improvements,
which
has
fallen
a
little
bit
out
of
date.
There's
it's
977..
B
It
basically
adds
environment
variable
support
for
all
the
configuration
options
of
instrumentation
and
then
also
sets
the
sort
of
lays
out
the
framework
for
how
we
might
want
to
do
deprecation
support
like
messaging
around
deprecation,
it's
kind
of
like
I
implemented
it
like,
I
implemented
all
the
base
stuff
and
then
just
added
it
to
one
instrumentation
as
an
example.
B
I'm
I'm
hesitant
to
go
further
with
it.
If
people
you
know
if
the
implementation
is,
I
was
saying,
driver
the
other
day
it's
like.
If
the
implementation
is
terrible
or
like
you
know
the
or
the
approach
or
the
or
the
the
the
ergonomics
around
it
are.
You
know
really
unfriendly
like
I
don't
you
know,
I'm
not
gonna
waste
my
time
but
like
yeah.
I
think
it
could
be
helpful.
B
It's
something
I
think
people
would
use
because
it's
you
know,
environment
variables
are
popular
and
and
people
want
to,
and
we
have
all
these
toggles
available
that
kind
of
like
get
hidden,
so
it
all,
and
it
would
also
expose
a
way
to
then
like
easily
write,
a
rake
task
that
we
could
use
to
document.
What
all
these
environment
variables
are.
I'm
sorry
what
all
these
configuration
options
are
so
yeah
it
all
sorry.
I
also
based
on
top
of
that
instrumentation
helper
pr.
So
it's
a
little
bit
noisy
but
yeah.
B
I
guess
matt
and
rob
especially
like
I'm
curious
what
y'all
think
of
it
and
if
there's
you
know,
sort
of
toggles
and
levers
you
would
want.
As
a
you
know,
kind
of
advocate
for
these
tools,
this
would
be
a
maybe
the
right
time
to.
Let
me
know
so
I
could
have
a
man
but
yeah.
Just
review
reviews
would
be
helpful.
Thank
you,
sir.
G
F
B
H
Cool,
so
I
was
just
kind
of
scanning.
This,
like
is
is,
is
the
the
big
tldr
that,
basically
anything
that
comes
in
as
an
option
on
your
instrumentation?
Now
has
a
corresponding
environment
variable
and
yeah,
like
honor.
B
That
it
pulls
out
all
the
like
random,
like
hey,
like
there's,
just
these
like
invocations,
like
option
with
like
a
bunch
of
arguments,
sort
of
like
strewn
throughout
instrumentation
it
would
it
it
implements
a
framework
for
pulling
that
all
out
into
essentially
just
a
constant
that
you
declare
with
all
these
details
and
then
under
the
hood
in,
like
I
forget
one
of
the
likes
methods.
B
Basically,
then,
under
the
hood,
the
instrumentation
based
class
automatically
looks
for
that
constant
and
applies
all
those
options
and
in
the
middle
of
applying
it,
you
know
right
before
it
applies.
It
looks
at
the
environment
variables
and
says
like
okay,
like
it
allows
you
to,
you,
know,
configure
it
with
environment
variable
and
then
you
know,
like
some
of
these
options
are
in
strings.
B
B
That
would
be
the
much
cleaner
diff
to
view
anyway,
so
yeah,
that's
the
gist
of
it.
It's
not
crazy.
It's
just
sort
of
like
I
think,
a
little
bit
better
as
a
framework
and
then
something
we
can
enforce
for
like
new
future
instrumentation,
and
it
would
just
be
like
we
just
have
to
like
then
do
a
pass
across
all
the
instrumentation
and
do
you
know
like
the
cleanup
anyway?
Let
me
know
what
you
think.
I
I
I
So
we
use
our
custom
active
support
method
to
subscribe
and
under
the
hood
it
creates
the
spam
subscriber.
I
And
that
was
kind
of
like
my
attempt
to
simplify
it,
so
the
users
of
the
library
don't
have
to
create
the
span
subscriber
and
pass
it
into
the
subscribe
method.
It'll
just
be
a
single
call,
but
what
also
this
obfuscates
is
the
ability
to
unsubscribe
from
notifications
which
asn
provides.
F
This
adds
some
safety
around
like
the
start
and
end
behavior
with
active
support
notifications,
I
don't
think
we
need
an
unsubscribe,
because
I
think
they
can
just
use
the
regular
api
to
unsubscribe.
I
Sorry
they
can't
because,
under
the
hood,
what
they
expect
is
whenever
you
subscribe
to
active
support
notification,
they
return
you
a
subscriber
object
and
then
you
use
that
subscriber
object
to
unsubscribe,
which
we
do
not
expose
to
the
user
right
now.
I
F
I
think
so
I
think
so
I
think
it's
like
they
should
still
use
the
asn
like
the
proper
way
of
unsubscribing,
but
they
would
just
use
the
object
returned
by
our
custom
subscribe
method,
so
our
custom
subscribe
method
should
be
as
similar
to
the
formula
one
as
reasonably
possible.
Even
if
it's
a
little
bit
simplified,
it
doesn't
provide
all
the
bells
and
whistles
of
the
like
the
proper
one.
I
think
that's
okay,
because
we're
working
around
something
that's
a
little
bit
hacky.
F
And
then
for
those
who
don't
know,
rails
upstream
actually
fixed
this,
so
we
don't
need
the
happy
one
in
the
future.
I
And
the
interface
looks
fine,
like
the
method
signature,
the
configuration
options
that
were
there
before
are
now
just
arguments
to
the
subscribe
call.
E
I
Yeah,
it's
just
the.
I
wasn't
really
sure
about
the
like.
What
are
the
the
other
approach
that
I
was
thinking
is,
like
you
passed
the
list
of
active
support
notifications
that
you're
interested
in
as
a
config
instead
of
letting
the
user
subscribe.
At
some
point,
I
I
don't
know
which
one
which
way
is
the
is
the
semantically
correct
way
to
do
something
like
this
yeah.