►
From YouTube: 2022-07-12 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
Hey
hey
good,
to
see
you
man!
Likewise,
how
are
you
doing
well
doing
well,
just
coming
back
from
a
week
off
and
then
I'll
be
gone
for
like
another
three
weeks,
man.
A
It's
just
like
we're
going
to
amsterdam
to
go
meet
up
with
the
rest
of
my
team.
I.
A
A
B
Yeah
I'll
I'll
remind
you
later,
I
have
good
restaurant
and
like
museum
and
stuff
recommendations
for
instagram
I'll
put
together
a
list.
What's
up,
how
are
you
nicholas.
D
That
was
my
my
20-year
service
award
at
the
fire
department
rescue
squad.
I
wrote
on
the
rescue
side.
I
was
on
the
ambulance
medical
services,
but
the
at
the
department.
The
traditional
20-year
award
was
an
axe
because
most
of
the
it
was
firefighters
who
would
make
it
to
20
years
and
so
like.
What
do
you
want
rob?
I'm
like.
I
want
him.
I
want
mother,
f
and
axe.
B
That's
stressed,
like
the
thor
you
know,
cosplay
events
have
a
sick
act.
E
The
attendance
was
sparse
last
week,
so
that's
why
we
just
had
some.
E
D
Have
you
seen
what's
going
on
in
the
world?
It's
a
lot
to
say
about.
E
F
Oh
yeah,
everybody
get
your
tittos
we'll
wait
as
long
as
it
takes
and
then
right.
C
D
F
All
right,
maybe
we'll
be
saying
all
right,
so
there
is
partial
success
and
in
otlp
export
responses.
We've
mentioned
for
a
couple
of
weeks
now
I
think
it's
just
been
going
to
review.
F
Any
idea
of
what
the
actual
proto
message
looks
like
in
here,
but
yeah
this
this
is
still
going
to
do.
I
think
what
will
happen
is
that
they'll
add
these
additional
fields
so.
F
Whenever
we
end
up
updating
our
protos,
I
think
you
will
need
to
be
sending
to
like
an
updated
ingest.
I
think
that's
the
takeaway
that
I
would
I
have
from
this.
F
If
you
yeah,
and
if
you
use
an
old
client
with
a
newer
ingest,
it
should
just
ignore
the
fields.
I
believe.
F
F
F
F
F
A
F
That's
fine,
I
think
the
new
thing
here
is
the
split,
but
if
everything
else
is
new
feel
free
to
take
a
look
but
yeah,
this
is
what
I
was
trying
to
scan
for
anyways.
F
I'm
not
sure
what's
going
to
happen,
but
I
kind
of
feel
like
this
ends
up
being
something
that
ends
up
being
a
concern
of
a
tracing
vendor.
More
than
anything,
it's
kind
of
like
people
upgrade
their
sdks
they've
already
built
like
a
bunch
of
alerting
and
other
stuff
based
on.
You
know
like
an
older
metric
so
like.
F
If
I
don't
know,
I
don't
want
to
sign
myself
up
as
a
vendor
for
this,
but
I
suspect
I
will
have
to
find
some
way
to
you
know:
keep
keep
on
top
of
like
changes
to
semantic
conventions
and
try
to
like
find
some
way
to
keep
your
own
stuff
working.
F
D
Is
that
what
if
we
have
to
change
something
and
there's
a
bunch
of
people,
have
already
adopted
open
to
entry
and
are
sending
telemetry
with
the
existing
names?
And
so
there's
like
there's
schema
already?
That's
production.
B
F
I
kid
I
think
we've
mentioned
this
several
weeks
in
a
row,
but
there
is
net
peer
and
host
name
attributes
and
now
there
are
net
sock
variants
of
those,
and
I
think
they
are.
They
are
used
when
you
only
use
one
pair
when
it's
unambiguous,
but
if
you're,
if
you're
going
through
a
proxy
or
some
other
intermediary,
you
can
use
both
of
them
to
represent.
F
What
you're
actually
talking
to
and
what,
what
the
actual
endpoints
are.
F
F
An
almost
infinite
level
of
nesting,
although
not
recursively
nested,
but
this
is
really
only
here
for
logs,
I
think
when
it
was
originally
introduced.
There
was
talk
about
introducing
it
for
metrics
and
traces.
A
lot
of
people,
including
myself,
pointed
out
that
tracing
back-ends
don't
really
support
this,
at
least
not
that
we
know
of,
and
nobody
could
point
out,
one
that
did
so.
You
would
have
to.
F
You
would
end
up
like
wanting
to
like
flatten
these
things
into
some
sort
of
key
value
pairs,
some
somewhere
and
it
can
get
challenging
and
just
end
up
with
a
long
dotted
string.
So
I
think
at
least
my
argument
was
like:
why
don't
you
just
have
a
dotted
string
key
with
a
value
that
you
determine
yourself?
F
F
But
yeah
as
long
as
what
armin
is
saying
for
this
table
is
true.
I
think
I
think
I'm
fine
with
this
the
more
clear
the
spec
is
the
better
as
long
as
we're
not
supporting
anything
new
for
traces
or
spans.
Just
yet,
I
don't
know,
did
any
of
that
rambling
make
sense.
F
So
I
think
the
next
steps
are
that
spec
will
start
to
appear,
and
this
is
events
built
on
top
of
the
logs
api,
and
I
think
it
will
ultimately
lead
to
spec
that
I
haven't
been
paying
a
ton
of
attention.
But
I
feel
like
logs
need,
are
in
need
of
some
spec
work
and,
if
that's
true,
I
think
that
will
be
taken
care
of,
along
with
the
events
that
are
going
to
be
built.
Kind
of.
F
Around
configuring
aggregations
with
metric
readers,
I
don't
know
that
anybody
is
far
enough
along
with
the
metrics
implementation.
That's
on
this
call
anyways
for
this
to
be
much
of
a
concern,
but
I
think
I
think
ultimately,
there's
going
to
be
some
clarification
and
I
think
the
clarification
is
going
to
be
these.
These
bullet
points.
F
Depending
on
where
you
configure
it,
there's
kind
of
like
a
a
precedence
that
I
think
was
kind
of
implied
by
the
spec,
but
maybe
not
explicitly
spelled
out,
so
I
think
they
wanted
to
spell
out
that
view.
Configuration
always
always
wins
once
they
exist.
Api
hints
would
be
the
second
thing.
F
F
B
Yeah,
sorry,
I
should
have
included
my
name.
I
think
the
there's
two
points
for
this
one
is,
I
was
hoping
ram
or
some
folks
from
helios
would
be
on
this
call,
because
this
is
the
you
know,
I'm
trying
to
figure
out
a
way,
a
path
forward
for
them.
They're.
Looking
to
add
hooks
to
the
rack
instrumentation,
for
you
know,
sort
of
like
request
and
response
hook.
B
I
took
a
look
at
the
pr
you
know.
I
think
I
think
the
question
there's
two
questions
here.
One
is
like
right
now,
this
specific
pr
has
the
request.
B
Hook
exposes
like
you,
know
the
active
spam
and
then
that
rack
m
variable
and
the
response
hook
exposes
the
active
span
and
like
the
request
and
the
response
body
and
yeah,
the
response
body
is
like
not
a
you
know,
json
blob
in
rack,
it's
like
a
there's,
a
specification
around
it
and
it's
a
pretty
complex
specification
and
there's
lots
of
there's
lots
of
foot
guns
with
how
you
may
interact
with
it.
For
example,
you
could
ask
you
know
like
if
you
attempt
to
read
the
whole
response
into
memory.
B
You
know
you
could
have
performance
issues
or
you're
supposed
to
there's
only
certain
innumerables
available
on
the
response,
and
so
you
know
my
review
of
this
was
sort
of
that
like
it
felt
like
yeah.
It
felt
like
we
were
exposing
far
too
much
to
the
the
end
user
here
who
that
end
user
is
whether
the
end
user
is
a
vendor
attempting
to
build
on
this
or
shopify
or
whatever,
like
it's
uncle,
that's
unclear,
but
yeah.
I
just
didn't
think
this
pr.
B
I
didn't
think
this
was
a
viable
feature
which
is
not
a
great
way
to
end
a
discussion
with
someone,
and
so
my
colleagues
felt
that
in
general,
like
hooks
in
general,
were
not
things
we
should
be
supporting
and
yeah.
I
think
there's
some
comments
on
here.
B
If
you
scroll
all
the
way
down
like
on
the
pr
to
not
on
the
code
review
on
like
the
first
pic,
what's
it
called
not
on
the
the
diff
on
the
conversation
you
scroll
down
to
the
end,
you
you
know
francis
supplied
like
how
he
felt
the
rack
instrumentation
should
be
as
of
32
as
of
10
minutes
before
this
call
should
be
set
up.
It's
unclear
to
me
still
like
yeah,
I'm
sorry
guys,
I'm
rambling,
it's
something.
B
Basically,
it's
unclear
to
me
how
we
want
like
how
do
we
want?
Let's
say
in
this
case,
helios
or
any
any
anyone
to
interact
with
our
instrumentation
is
the
idea
that
they
should
be
providing
like
procs
that
they
can
pass
into
our
hooks
like
just
providing
configuration
on
top
of
it,
or
should
they
is
the
expectation
that
we
want
them
to
essentially
provide
their
own
instrumentation
that
they,
you
know,
register.
B
B
B
Is
the
idea
that
we
would
maybe
provide
some
broader
extension
points
and
yeah?
I
think
they're
good
questions
that
extend
beyond
ruby
and
into
open
telemetry
like
in
general,
but
the
as
it
stands
today.
I
don't
think
this
pr
is
something
we
want
to
take,
but
I'm
not
happy
with,
and
I
think
it's
a
it's
a
total
punt
to
say
the
end.
I
think
we
need
to
say
like
this
is
what
we
would
want
instead
or
this
is
the
expected.
B
This
is
the
way
we
expect
you
to
provide
these
things
instead.
So
I'm
not
sure
what
that
is,
and
I
said
I
would
kind
of
think
about
over
the
weekend.
I
still
don't
know
the
answer.
I
think
there
are
some
ways
that
make
a
little
more
sense.
Maybe
we
could
do
something
similar
to
like
what
we've
done
with
the
metrics
reporter,
where
we
sort
of
have
like
an
op
class.
B
Maybe
we
have
some
sort
of
like
I
don't
know,
or
maybe
we
say,
here's
here's
an
example
of
how
you
might
provide
rack
instrument,
your
own
middleware
interac.
I
I'm
not
quite
sure-
and
you
know
I
was
hoping
to
have
a
discussion
about
it,
but
none
of
the
people
to
discuss
it
with
are
here
that
are
on
this
thread
or
on
this
on
this
issue.
A
So
we
I
think
this
is
like
the
from
the
the
opposite
perspective
right,
a
very
closely
similar
conversation,
where
I
felt
uneasy
about
adding
these
kinds
of
hooks
to
the
fact
the
faraday
instrumentation,
as
opposed
to
introducing
a
new
middleware.
A
I
was
a
little
unsettled,
a
little
uneasy
about
doing
that
there
for
very
similar
reasons
to
to
the
ones
described
here,
because
it
already
has
like
this
notion
of
you
want
to
build
and
add
features
to
it.
The
other
components
like
net
http,
like
the
other
clients
that
don't
have
this
concept
of
being
able
to
inject
customize
your
your
own
custom
code
into
the
execution,
stack
net,
http,
http,
client
or
the
you
know,
rest
client.
A
We
it
felt
to
me
more
like
we
didn't,
have
a
choice
in
order
to
be
able
to
add,
you
know,
blocks
for
response
and
request
hooks
or
whatever,
and
so
that
that
in
allowing
those
kind
of
set,
the
stage
created
an
opening
to
introduce
this
yeah.
A
You
know,
I
think,
I'm
I'm
citing
with
this
notion
here
that
if
the
rack
instrumentation
isn't
doing
what
you
want,
don't
don't
use
that
one
and
you
should
write
folks,
should
write
their
own.
If
they
want
to
build
on
top
of
it,
they
should
probably
add
their
own
middleware
that
is
injected
after
the
rack
middleware
is
we
have
the
precedent
set
with
that
with
action
pack
action
pack
leverages
the
existing
rackspan
injects
itself
sinatra
also
now
using
the
rackspan
and
injecting
custom
logic
there.
D
Which
we
have
an
open
issue
about,
because
action
pack
brings
in
if
you
do,
depending
on
the
ordering
of
anyway,
there
is
a
related
issue
with
instrumentation
based
on
rack
nicholas,
is
here
to
share
some
of
those
those
issues.
I'm
I'm
a
fan
before
we
move
to
that
specific
issue.
I
I
I
think
in
places
where
you
want
to
inject
specific
handling,
like
I
think
in
this
case
the
comment
from
ran,
I
guess,
is
the
person
who
opened
this
pull
request
the
comment
above
francis's
last
one.
D
His
second
point
was
that
francis's
suggestion
about
well,
you
could
just
make
your
own
rack
middleware
grab
current
span
and
twiddle
it
to
your
heart's
content.
He
goes
that
doesn't
do
quite
what
I
need,
because
I'm
trying
to
provide
instrumentation
to
my
customers
so
they're
trying
to
it's.
It's
not
their
use
of
open
telemetry,
it's
their.
D
It
feels
vendory
and
as
a
vendor,
I
might
make
my
own
rack
instrumentation
that
my
customers
could
choose
to
use
yeah.
D
D
It
so
maybe
at
the
moment
they
would
have
to
maintain
their
own
gem
if
they
wanted
to.
B
B
Was
a
bad
choice?
I'm.
A
Gonna
take
three
steps
back
and
say
I
I'm
not
regretting
that
we
added
the
hooks
to
the
clients
themselves.
The
clients
don't
have
like
the
the
like
htp,
for
example,
doesn't
provide
programmatic
hooks
or
an
execution
stack
that
you
can
inject
yourself.
Monkey
patching
is
all
we
got
right,
faraday's
a
little
bit
different
faraday
has
that
middleware
execution
stack
right.
It
has
the
ability
for
you
to
inject
things
into
it.
So
that's
the
only
one
that
I
was
referring
to.
That
was
the
one
I
was
unsettled
by.
I.
B
Well,
it's
a
good,
it's
okay
to
be
unsettled,
because
I
work
with
people
who
might
be
on
the
screen
right
now
and
their
first,
their
github
handle
starts
with
happenings
with
apostate
and
they
are
had
similar
concerns
and
and
expressed
internally.
That
reverting
hooks
in
general
is
something
they'd
like
to
do
so.
I'm
sort
of
representing
that
viewpoint,
because
francis
isn't
on
the
call,
so
I
don't
I
don't
want
to.
B
I
actually
don't
want
to
put
words
in
his
mouth,
though
I'd
prefer
to
like
let
him
speak
when
he's
available
to
maybe
that's
next
week
or
whatever,
but
I
just
want
to
say
that,
like
yeah,
I
I
mean
I
am
an
advocate
for
where
there's
no
way
to
access
an
http
client
span.
Having
a
hook
has
tremendous
value
to
users.
I've
seen
that
anecdotally.
In
my
past
professional
experience-
and
you
know
I
can
count
on-
I
can
there's
a
lot
of
support.
It
solves
a
lot
of
problems
for
a
lot
of
people.
B
It's
hard
to
do
that
on
a
kid.
You
know
in
it's
hard
to
not
have
hooks
for
some
hdp
client
stuff
and
not
and
have
it
for
others
like
that
feels
even
more
confusing,
but
I
I
do
agree.
It's
like
a
little
bit
of
some
unholy
this
there.
So
I
just
think
all
I
want
to
say
is
like
I'm
open
to
all
options
with
it.
If
we,
but
it's
more
about
establishing
precedent,
determining
what
we
think
is
the
right
path
forward
and.
D
As
as
an
alternative,
we
could
consider
accepting
procs
in
the
config,
for
auto
instrumentation
and
and
in
the
loading
of
auto
instrumentation,
where
we
say
like
something
was
successfully
loaded
with
this
config.
If
you
hand
us
procs,
I
don't
know
like
your
warranty
is
now
invalid,
because
if
you,
if
you
call
us
for
support
for
wild
memory
things-
and
you
have
these
procs
enabled
you're
going
to
have
to
like
show
that
it's
not
your
proc.
That's
blowing
up
your
memory.
B
It's,
I
think,
that's
a
you
know,
that's
a
possibility
too,
and
you
know
it's
really
it's
kind
of
it.
It
depends
on
the
level
support
we
want
to
prove
we.
You
know,
we
think
we
ought
to
provide
the
few.
You
know
the
the
users
of
it
and
also
like
from
the
economics
of
like
someone.
You
know,
I'm
not
a
vendor
right
now.
B
So,
like
you
tell
me,
is
it
a
high
hurdle
to
publish
your
own
gem
and
point
in
your
distro
to
it
like
well,
you're,
not,
are
you
even
maintaining
a
destroyer
like
then
that's
an
even
higher
hurdle.
So,
like
I'm
talking
circles,
I
I
think
the
short-term
thing
here
is
that
I'd,
like
some
consensus
on
whether
this
specific
rack
instrumentation
is
something
we
want
to
just
say
no
to
and
like
politely
and
if
so,
what's
the
immediate,
you
know,
let's
say
this
person
has
to
deliver
a
solution
to
their
users
tomorrow?
B
What
would
be
the
thing
we
tell
them
to
spend
up
all
night
doing?
Would
it
be
publishing
their
own
jam
and
including,
like
that's
fine,
but
I
think
we
should
tell
them
what
we
think
the
right
and
that
could
be
a
short
term
action
and
then
but
longer
term,
like
yeah,
I
think
some
of
the
questions
we're
discussing
are
worth
spending.
Many
meetings
on.
I
don't
know.
D
Oh,
go
ahead,
rob
I
I
think
we
should
talk
more
about
this.
I
don't
think
we.
I
think
that
there
is
enough
concern
that
we
don't
accept
this
pr,
as
is
today.
I
think
we
we
have
some
things
to
consider.
We
can
accept
it,
we
can
accept
it
and
go.
We
support
it.
D
In
that
scenario,
the
we
need
to
sort
of
document
better
how
to
write
documentation.
So
maybe
there's
some
some
documentation
and
maybe
like
base
classy
type
stuff
that
maybe
they
could
you
you
implement
this
class
and
override
these
things
and
you've
got
a
rack
instrumentation,
that's
custom.
Where
was
I
going
with
that?
One.
D
In
this
case,
where
rack
is
kind
of
a
low
level
one,
we
have
at
least
one
instrumentation
that
depends
on
the
rack
instrumentation
in
that
case
like
if
I,
if
I
make
if
as
a
vendor,
I
make
my
own
rack
instrumentation,
because
I
want
to
do
more
to
it.
How
do
I
tell
say
action
pack
use
mine,
because
this
is
the
rack
implementation
that
I
want
not
the
vanilla
upstream
one,
which
is
a
whole
interface
thing
that
we
don't
have
sorted
at
the
moment.
B
I'm
I'm
talking
too
much
and
I
think
I've
said
everything
I
want
to
say.
So
I
don't
I'm
sorry
to
continue
talking.
I
agree,
I
would
say
the
only
other
one
that
I
thought
of
him
ahead
is
something
similar
to
done
with
what
we've
done
with
metrics
reporter,
where
we
there's
just
like
some
no
op
class
somewhere,
that
if
people
want
to
bring
their
own
class
and
like
it's
already
like
baked
into
our
instrumentation
somewhere
like
and
then
they
can
define,
you
know
the
the
hooks
in
that
class.
B
That's
like
slightly
different,
a
different
version
of
of
having
hooks
via
config.
I
think
it's
like
a
little
higher
bar
of
like
expectation
that,
like
hey,
you
understand
how
to
write
rack
middleware,
but
not
that
rack
middleware
is
so
complicated
that
we
can't
document
how
you
know
this.
The
12
things
to
watch
out
for,
but
like
it's
pretty
complicated,
I
think
it's
slightly
too
complicated
for
just
like
a
little
config
option
that
people
are
gonna
like
try
to
write
in
line
and
inevitably
blow
up
their
apps
on,
but.
D
D
B
And
instead
of
a
support
ticket,
they
send
you
like
a
gift
like
sorry
for
wasting
your
man
hours.
The
the
other
thing
worth
mentioning
here
is
like,
I
think,
for
a
long
time
and
francis
brought
this
up
internally
and
like
it's
totally
valid
because,
like
for
a
long
time,
we've
been
doing
that
like
well.
Other
instrumentations
have
established
this
practice.
B
So
therefore
it's
okay,
and
this
would
be
an
instance
where,
like
maybe,
although
that's
the
case
like
we
want
to
be
strict
and
say
like
that's,
not
something
we
too
want
to
adopt,
because
the
fact
of
the
matter
is
most
of
these
were
not
like
conscious
choices
by
these
other
language
shakes.
It
was
because
they
ported
in
existing
telemetry
from
you
know,
that's
apache
2
from
long
ago
that
matt
ware
wrote
in
2014
or
whatever.
D
And
it
would
be
helpful
to
know
a
little
bit
more
concrete
like
how
are
you
using
the
stuff
and
like
instead
of
a
proc,
that
you
can
interrogate
the
incoming
m
object
and
another
product
that
can
interrogate
the
response
object.
Do
you
want
fields
off
of
those
things,
and
then
you
give
us
a
list
of
fields
that
we
pull
off.
Of
that
like
an
api,
can't
doesn't
have
to
be
like
you
have
immediate
access
to
the
vein
of
the
body.
B
Hesitant
to
provide
that
to
the
point
that
it
felt
silly
to
ask
again,
but
yes,
I
agree
that
was
andrew's
original
when
a
this
pr
was
originally
made.
Andrew
hayworth
he's
out
right
now
said:
hey
are
you
sure,
like
we
can't
just
improve
this
instrumentation
for
you
just
like
tell
us
the
fields
you
want
as
optional
config,
we're
happy
to
add
a
you
know,
happy
to
add
this.
Whatever
response
header
or
something.
A
On
top
of
our
stuff,
which
is
crazy,
yeah
there
there
was
a
a
person
that
we
that
I
met
at
the
hotel
community
day
that
wanted
hooks
like
this,
so
that
they
were
actually
they
wanted,
like
all
of
the
http
request,
attributes
to
be
available
as
that,
because
you
didn't,
you
know,
as
well
as
seeing
the
raw
response
body
get
written
to
the,
and
I
was
like
that
would
be
ins
that
would
that
would
produce
so
much
telemetry
data
like
essentially
you
you
are
like
recording.
D
A
Yeah
wireshark
yeah,
I'm
gonna,
take
this
thing
and
I'm
gonna
base64
encode
it
and
add
another
thirty.
Three
percent,
oh
size,
yeah.
E
A
I
was
like
well
what
do
you
need
that
phone?
It's
like
well
they're,
building
like
a
startup
that
was,
you
know
doing
for
for
exploratory
testing
and
like
being
able
to
leverage
tracing
in
in
pre-production
environments,
where
you're
doing
that.
D
I
feel
like
here's,
here's
documentation
on
how
to
write
your
own
instrumentation
for.
D
B
For
the
sake
of
okay,
those
are
all
good
points.
I
think
we're
have
similar
mindsets.
I
don't
want
to.
A
A
A
The
second
thing
is,
I
think,
we're
going
to
say
no
to
this
and
what
we're
going
to
offer
is
hey
y'all
write,
write
your
own
instrumentation,
your
own
gem,
maintain
that
and
figure
out
a
way
to
hook
that
in
yourself
like
make
your
own
distribution
essentially
of
the
instrumentation
packages,
and
then
the
third
thing
is,
if
that's
not
that
option
for
for
doing
that,
somebody
needs
to
do
some
explore
exploration
of
how
to
provide
an
easy
way
to
override
the
rack,
middleware,
injecting
some
sort
of
some
sort
of
component
helper,
or
something
like
that
that
people
can
programmatically
add.
A
That
was
something
that
you
mentioned
eric
and
I'm
kind
of
I'm
not
sure
how
you
know
where
my
head
is
at
with
that
other
than
just
saying:
yo
write
another
instrumentation,
you
know
another
middleware
that
you
can
stick
in
yourself.
You
know
if
that's
okay,
that's
summarized
like
where
I
think
we're
going
next
year.
E
No,
nothing
nothing
new.
We
should
write
some
docs
like
we
should.
We
should
have
a
template,
repo
or
whatever.
That
is
like
here's.
Here's
an
instrumentation.
C
E
That
you,
you
use
this
template
repo
and
it
can
hook
into
the
api,
no
problem
or
the
sdk
rather,
but
I
think
arielle
got
it
all.
Okay,.
B
D
I
put
two
notes
underneath
this
issue
on
the
agenda
about
it's
basically
accept
and
support
hooks
and
and
warn
that
their
warranties
void,
if
they
provide
them
or
we
don't
accept
hooks
in
the
auto
instrumentation.
If
you
want
to
get
fancy
with
customized
behavior,
that
is
custom
instrumentation,
you
should
write
and
we
write
documentation
on
how
that
works.
F
Yeah,
I
would
maybe
add
one
one
more
thing.
I
think
the
the
hook
for
the
response.
The
concerns
over
that
are
super
valid.
Like
I
know,
I've
seen
I
have
worked
places
where
we
have
done
unholy
things
to
the
response,
and
it
only
works
for
like
for
non-streaming
or
non-action
controller
live
things,
and
then
you
find
out
when
people
are
using
those
that
everything
is
broken.
So
I
think
definitely
there.
F
There
are
foot
guns
there
and
I
I
just
would
be
curious
if,
like
any
other
vendor
that
we
know
of,
has
ever
offered
anything
like
this
in
the
rack,
middleware
and
it
just
was
an
amazing
thing
and
it
worked
super
well
because
I
I
don't
know
if
one
offhand,
but
that
might
like
if
there
was
some
like
really
solid
prior
art
in
the
world.
I
think
that
would
be
something
worth.
B
To
the
data
dog
approach
for
security
signals
was
like
a
sort
of
guidepost,
for
maybe
what
the
right
thing
to
do
is,
which
is
they
provide
their
own
middleware
via
separate
instrumentation?
It's
not
called
instrumentation
because
it's
not
for
tracing,
but
it's
a
separate
rack,
middleware
and
yeah.
The
streaming
thing
I
bumped
into
trying
to
write
a
rum
feature
back
in
the
day
and
it
blew
up
so
okay,
cool
yeah.
Those
are
all
valid.
F
D
Yeah,
this
really
is
a
case
for
a
distribution,
an
open,
telemetry
distribution-
if
you,
if
you
have
a
case
for
your
customers,
that
you
can
provide
a
distribution,
and
I
would
recommend
that
custom
instrumentation
from
a
custom
instrumentation
from
a
vendor
can
be
a
standalone
library
that
anybody
in
the
open,
telemetry
community
could
like
opt
to
pull
in
that
instrumentation
in
like
shopify.
Maybe
francis
is
like
this
is
pretty
dope.
D
F
All
right,
good
conversation
on
that,
shall
we
move
on
to
the
next.
C
E
Great
thanks
for
your
contributions
and
then
we
haven't
released
anything
yet
because
I
don't
think
we've
released
anything
from
the
contrib
repo
yet
and
I
think
the
release
I
don't
know
matt,
maybe
you
release
the
main
repo,
but
at
least
for
the
contrib
repo.
I'm
wondering
I
was
wondering
we
were
wondering
last
week:
do
we
want
to
try
to
establish
a
release
cadence
or
at
least
some
internal
expectations
among
us,
maintainer
approver,
folks
to
just.
E
A
For
simplicity,
I
propose
we
check
in
this
week.
Should
we
have
a
release
this
week,
every
tuesday
and
be
like
sure,
and
then
somebody
goes
and
releases
everything
does
it
seem
like
a
reasonable
start?
F
I
think
anything
is
a
a
reasonable
strategy
here.
I
think
that
sounds
like
a
fairly
casual
one
that
works
well
for
us.
If
somebody.
F
Is
somebody
who
gets
their
pr
merged
and
wants
to
know
when
we
can
when
they
can
see
that
released?
I
think
it's
still
a
little
open-ended
for
them,
but
I
think
but
yeah.
I
guess
if
that
is
our
policy,
we'll
just
check
in
and
see
if
we
should
do
a
release
at
each
meeting,
we
can
just
tell
them
we'll
meet
on
tuesday
and
discuss
it
and
get
back
to
you
and
that's
probably
probably
good
enough
for
now.
B
Yeah,
I
just
to
be
clear.
You
know
I've
been
out
for
a
while
because
of
baby
on
board
and
do
we
know
how
to
release
contrib
right
now,
exactly
the
same
as
the
main.
B
But
have
we
done
it
like
yeah,
like
theory
and
practice,
so
like
no
yeah
you're
like
this
feels
like
it'll,
go
wrong,
yeah,
of
course,
because
we
haven't
practiced
yet
yeah.
Should
we
schedule
time
to
kind
of
run
through
like
do
a
thing
where
we
can
block
out
time
so
that,
if
stuff
blows
up
ariel
you're,
not
stuck
at
like
6
p.m,
randomly
on
a
friday
being
like
crap
me
being
stuck
yeah.
B
Yeah,
okay:
well
maybe
we
can
sync
up
after.
A
D
F
B
Although
like
it's
not
if
we
release
the
hook
stuff
in
the
client
and
then
like
next
week,
like
guess
what
the
next
release
we
pulled
them
out
and
they're
like
like
look
at
the
end
of
the
day,
we're
experimental
and
we
should
rely
on,
like
sometimes
experiments,
don't
pass
like.
So
that's,
okay,
but
that
would
be
funny.
A
F
D
A
E
E
E
C
C
C
Added
just
wasn't
clear,
so
there
was
like
a
little
bit.
I
mean
I
spent
like
five
minutes
being
like
why
there
for
my
interest,
endpoints
not
taking
on
the
config
and
then
just
reordered,
look
at
the
code
and
it
was
fine,
but
I
could
probably
do
something
to
just
update
the
documentation
just
to
reflect
that
in
the
readme
other
than
that.
I
don't
know
how
urgent
it
is
to
get
that
fixed.
A
I
got
me
they
got
me
asking
the
question
like
we
have
both
the
use
and
the
use
all
detects
the
map
of
the
things
that
you
want
to
configure,
but
use
all
really
doesn't
matter
because
they,
because
both
use
and
use
all,
are
trying
to
like
auto
load
gems.
A
I
think,
use
all
of
those
gems
that
if
stuff
is
required,
sorry
if,
if
bundler
goes
ahead
and
loads,
whatever
instrumentations
you
depend
on
it's
they're
going
to
get
automatically
registered
in
the
registry
and
the
installation
process
goes
through
and
installs
whatever
it
can
right
or
is
use
only
going
to
do
an
allow
list
of
the
things
that
are
that
are
pulled
from
the
registry,
even
though
they're
red
they're,
they're
registered
but
not
installed,
and
I
can't
remember.
B
A
Just
like
I
don't
know,
I
feel
like
that.
Having
used
and
use
all
and
taking
a
map
of
the
configurations
as
well
as
like
doing
like
this
one
line,
item
configuration
value
thing,
I
find
it
confusing
in
the
configurator
and
I
abandon
the
use
of
use
and
I
run
use
all,
and
I
only
install
the
gems
I
want
or
I
allow,
and
I
don't
use
the
all
instrumentation
job,
but.
F
Yeah,
so
I
think
that
middle
ground
with
use
is
so
that
you
could
technically
have
more
instrumentation
like
you
could
bring
in
instrumentation
all
but
pick
and
pull
from
that
and
it
would
all
be
registered
in
the
registry,
but
only
your
explicit
uses
would
get
installed.
F
That
was
kind
of
the
the
thinking
behind.
All
of
that.
A
I
don't
know
we
just
feel
that
feels
kind
of
weird.
Would
we
be
better
off
like
telling
people
to
use
the
environment
variables
and
say
shut
these
things
off?
I
don't
want
them
if
you're
using
the
all
gem.
Otherwise,
like
you,
would
you
cherry
picking
whatever
instrumentation
gems
you
want
to
bring
in
right
because
that's
what
we
do
essentially.
F
I
think
we've
yeah
we've
had
some
conversations
around
this
before.
I
definitely
think
what
you're
doing
at
github
is
what
I
would
be
doing
if
I
were
a
user,
but
I
think
I
think
some
users
want
to
just
grab
instrumentation
all
and
you
know
easily
pick
and
pull
from
it.
I
think
we
have
multiple
options
on
how
to
actually
do
that,
which
maybe
is
a
little
confusing.
D
The
initial
onboarding
experience
of
a
person
and
an
organization
and
initially
adopting
open
telemetry
they
like
the
fewer
lines
that
they
can
throw
in
an
initializer
the
better
that
onboarding
experience
is
because
they
get
an
initial.
Like
you
know,
five
lines
and
an
initializer
brings
in
open,
celebrity
turn
lights
up
all
the
instrumentation
of
the
things
that
they
use.
That's
a
pretty
delightful
experience.
Initially,
I
wouldn't
want
to
turn
that
off
it's
after
you've,
you've
tasted
all
of
the
automatic
stuff
you're
like.
Oh,
I
want
to
tamp
that
stuff
down.
A
D
C
D
All
right
get
to
know
it,
but
maybe
we
need
a
document
use
all
is
like
a
an
easy
onboarding
to
see
what
auto
instrumentation
does
for
you,
but
early
in
your
journey
with
instrumentation
you're,
probably
going
to
want
to
move
off
of
use
all
and
move
towards
discrete
named
investigations.
C
A
I'm
my
experience
is
the
opposite.
Is
I
continue
to
want
to
use
all
and
where
I'm
declaring?
What
I
want
to
include
is
what
I
declare
as
a
dependency
in
my
gem
file.
Okay,
you
know
what
I'm
saying
like
or
by
if
I
want
something
experimental,
I'm
passing
a
key
value
pair
that
says:
here's
an
instrumentation
name
with
instrumentation
enabled
true
or
false,
depending
on
like.
A
D
F
I
mean
it
would
just
randomly
wire
things
up
and
then
it
makes
it
makes.
The
use
command
seem
a
little
bit
more
useful
in
comparison,
but
I
see
what
ariel
is
saying
you
could
probably
use
all
is
good.
We
could
probably
get
rid
of
used
because
there
are
multiple
levers
there.
So
we
should
think
about
this.
E
I
actually
have
wasted
like
within
the
past
two
months,
I've
wasted,
like
a
day
of
my
time,
trying
to
track
down
like
where
something
was
configured
through
like
environment
variables
and
reuses
and
whatever
and
it's
like
yeah.
I
don't
yeah,
don't
without
going
into
all
the
details
of
how
the
kubernetes
gets
templated.
It's
just
like.
Oh
well,
yeah.
C
C
I'll,
just
kind
of
extend
that
a
little
bit
I
would
have
also
found
is
like
onboarding
teammates
and
people
into
the
ruby
instrumentation
can
be
quite
confusing
because
it's
like
oh
well.
How
do
I
now
go
and
you
know
add
this
configuration?
Oh,
it's
a
key
value
pair.
I
know
it's.
It's
an
environment
variable.
What
is
it?
I've
got
to
read
some
source
code
and
then,
depending
on
the
person
that
I'm
interacting
with,
maybe
they
have
enough
expertise
to
do
that
on
their
own.
C
D
We
do
get
signal
from
our
customers
about
how
they
really
like
being
able
to
configure
instrumentation
without
making
code
changes.
A
D
Super
duper
because
that
means
they
can
they
they
appease
auditors
and
that
they're
not
making
code
changes
to
make
config
changes.
They
and
you
can
drive
it.
I
don't
want
to
call
it
easy,
but
easier
in
a
world
where
you
have
yaml
pipelines,
pooping
up
your
kubernetes
instances
like
it's
easier
to
crank
out
a
file
or
an
environment
variable
than
it
is
to
twiddle
something
like
code.
That
goes
and
looks
up
the
contents
of
a
file
or
an
environment
variable.
A
No,
no
that's
like
essential
bro,
because
that's
part
of
the
spec
right,
the
spec
says
yeah.
For
anyway,
there's
even
like
the.
D
Hotel,
ruby,
instrumentation,
I'm
looking
at
nicholas's
bug,
hotel,
ruby,
instrumentation,
rack,
config
ops,
I
don't
think,
is
a
spec
environment.
Variable.
A
Nah,
it's
a
in
the
spec,
it
says:
if
for
for
language,
specific
things,
this
is
the
pattern
that
it
follows.
F
All
right
yeah,
so
it
sounds
like
we
can
have
better
docs
on
how
to
turn
stuff
on
or
on
and
off
and
depending
on
what
we
start
recommending
to
people.
It
seems
like
all
we
could
consider
removing
all,
because
it
might
just
be
an
additional
confusing
thing,
and
if
we
do
that,
we
might
want
to
rename
use
all
to
be
something
a
little
bit.
I
don't
know,
consider
a
rename
there.
D
Yeah,
I
will
say
that
the
the
bug
that
nicholas
had
raised
it
goes
back
to
the
rack
thing
where
we
have
instrumentation.
That
depends
on
other
instrumentation.
D
D
Like
use
all
with
a
map
with
named
instrumentations,
if
it,
if
action
pack
knew
that
it
was
use
all
with
named
instrumentations,
and
you
gave
it
a
rack,
config
action,
packs
instantiation
of
the
rack
instrumentation
could
go.
I'm
gonna
go
look
at
the
key
value
pairs
for
the
rack,
config
and
use
it.
Oh,
it's
empty
I'll
use
the
default
empty.
One.
C
D
A
All
right,
yo,
let's
sorry,
let's
beat
this
up
because
we
got
we
two
minutes
over
already.
I'm
gonna.
F
F
A
All
right
put
the
well
wait.
D
That
was
the
one
between
the
thing
that's
been
fixed
and
bug
snag
is
sam's
robocop
consolidation
take.
E
A
take
a
look,
if
you
don't
like
it,
you
can
say
so.
I
won't
be
offended
if
we
close
it.
It
was
a
terrible
way
to
spend
several
hours,
but
I
I
didn't
think
too
hard
about
what
I
was
doing
in
terms
of
the
trade-offs,
but
if
you
want
to
consolidate
rubocop
on
one
file
at
the
root
of
the
contrib
repo,
this
pr
is
your
chance
and.
C
E
D
E
But
yeah
I
it's
all
okay,
I
deleted
a
bunch
of
files
and
it's
all
in
a
rubocop.yaml
at
the
root
of
the
repo.
If
people
want
to
take
a
look.
A
Yes,
I
could
I
could
you
know
what
I'm
saying,
but
let's
see
here
call
bluey
right,
y'all,
see
this
google
stuff
here
right
and
which
one
of
these
is
ours,
this
one
right
and
let's
kick
off
this
action.
A
Let's
open
a
release
request
and
let's
run
this
workflow
on
the
main
branch
and
who
do
we
want?
We
want
to
open
the
telemetry.
I
wish
that
we
didn't
have
to
type
all
this
instrumentation,
because
I
spell
it
wrong
all
the
time
graphql.
This
is
our
candidate
right.
Our
first
one
did.
I
spell
all
that
right,
let's
open
up,
let's
run
that
workflow
and
see.
A
All
the
pii
gets
redacted
by
github
actions.
Okay,.
A
F
A
A
In
packaging,
it's
like
what
is
it?
What
I'm
looking
for,
where
I
say
did
you
mean
this?
Let's
see
again,
can
everybody
see
wasn't.
B
A
A
So
I'm
saying
so
that
didn't.
A
Best,
so
my
prediction
is
that
what
happens
right
now
is
that
this
fails,
because
the
all
gem
needs
to
get
bumped.
Oh
snap,
it
passed
nah
yo.
This
pr
is
gonna
break,
because
the
all
gem
is
gonna
try
to
reference,
something
that
is
a
different
bump,
and
this
is
saying
that
this
is
an
initial
release.
D
That
number
is
lower
than
the
lower
number.
A
D
A
D
A
B
D
That
still
think
it's
useful.
F
A
All
right
well,
so
what
we're
learning
today
that
we
cannot
release
like
this
so
easy.
We
can
essentially
also
looks
like
whatever
got
done
there.
We
missed
semcom,
so
it
didn't
pick
up
what
the
change
actually
was
because
they
didn't
use
conventional
commits
my
back,
so
it
didn't
pick
that
up.
There
wasn't
a
previous
tag
on
this
repository
and
that's
that
right.
A
D
D
Is
that
right?
So
a
thing
we'll
need
to
do
as
a
part
of
review
is
if
the
pr
doesn't
have
a
semantic.
A
Who's
there
it's
there,
you
know
what
I'm
saying.
Okay,
so
whatever
happened,
toys
didn't
pick
it
up
and
it
could
be
because
whatever
some
is
broken.
A
Don't
know
you
wanna,
you
all
y'all
got
five
more
minutes
to
take
a
look.
E
A
E
A
Okay,
don't
make
fun
of
my
absence
of
vs
code
skills
as
I'm
now
forced
to
use
vs
code
every
day.
So
what
are
we
looking
at
we're
looking
at
toys
right
and
it's
release
right,
and
this
is
release
requests
so
see?
What's
up.
C
A
The
code,
but
not
tell
me
what
the
code
does.
That's
you
got
the
private
v2
copilot
come
on.
You
know,
baby,
let's
see
it,
release
you
tills
does
something
where
it
looks
at
the
release
reference
for
each
of
these
populates,
the
requester
finish
the
gems.
I
don't
know
what
these
semantics
wrong:
confirmation,
ui
and
career
pull
request.
A
So
apparently
there's
some
sort
of
like
popular
requester
here
that
does
all
this.
For
each
of
these,
it
does
some
things
get
some
gem
info
he's
the
gem
list
of
all
the
things.
Where
does
it
get
some
the
conventional
commitments
like
where
it
figures
out
like
what
version
is
trying
to
do
something
with?
A
So
it
looks
at
these
change
log
entries,
so
where
is
it
so
if
it
had
a
full
change
log,
I
suppose-
and
it's
looking
at
these
change
log
entries
which
what
did
that
get
injected
from
note
from
build
change
logs
here?
So
let's
take
a
look
at
that.
What's
up
with
you,
what
are
brakes
here
holy
mackerel,
nobody
familiar
with
this
code!
B
D
A
So
analyze
the
messages,
I
suppose,
is
what
we
might
want
right.
So
where's
this
analyze
messages.
Oh
no,
we
were
just
looking
at
that:
analyzer
analyze
messages.
So
what
is
it
doing?
It's
going
to
a
gem
directory
and
it's
looking
at
the
latest
version
of
release
right,
there's
a
diff
and
then
it
calls
the
git
cli.
A
D
A
So
it's
doing
name
only
this
and
it's
pulling
the
log
stream,
but
it's
looking
at
the
last
version
and
the
last
version
came
from
where
well
nowhere
hey
robert
look,
it
says
right
here:
if
there
wasn't
the
last
version,
then
this
is
the
initial
release
and
wrong
return
baby.
So
it
didn't
look.
That's
the
answer.
Baby!
A
So
there
was
no
last
version,
so
you
know
whatever
okay
and
how
did
it
get
the
last
like?
How
did
they
try
to
interpret
what
the
last
version
was?
It's,
like
the
new
version
equals
the
date
equals
the
full
change.
Like
you
know,
these
are
all
nil
but
determine
the
last
version
yo.
What
up
baby?
Let's
do
it
y'all,
like
these
fun
code
reviews?
Oh
look
at
that.
It's
looking
at
all
the
tangs.
A
D
A
A
A
Yeah,
let's
do
rerun
all
jobs.
What
up.
D
D
Be
cool
is
if
we
had
a
get
these
github
actions
instrumented
and
sending
it
somewhere.
A
D
Bowen's
got
one
one
of
the
honeycomb
customers
has
an
open,
telemetry
one,
that's
quite
clever:
it's
there's
two
actions.
One
will
create
a
trace
of
a
workflow
in
all
of
the
jobs
in
that
workflow
as
like
a
the
workflow
runs
and
then
as
an
ending
thing.
It
goes
and
queries
the
actions
api
to
get
the
detail
and
then.
D
D
Can
see
a
workflow
and
jobs
and
your
end
unit
xmls,
that's
pretty
dope.
A
A
A
A
In
tanner
he
is
he's
a
maintainer
all
right.
Here's
what
we're
gonna
do.
Y'all
we're
gonna
take
a
little
bit
of
a
coffee
break
because
it
is
now
18
minutes.
Three
minutes
past
the
15
minutes.
I
agreed
that
we
were
going
to
time
box
this
too
yeah
we're
in.
A
I'm
gonna
let
y'all
go
if
anybody
is
interested
in
picking
up
this
adventure
a
little
bit
later.
Hey
hit
me
up
on
hit
me
up
in
cncs
slack
I'll.
Probably
take
a
look
at
this
like
again
in
like
an
hour
or
something
yeah.
A
E
A
So,
let's
see
here,
hotel,
contrib
release
dm
me
real,
quick,
an
email
address
through
cncf
slack
anybody
else
interested
in
hopping.
In
later,
I
can
probably
cannot.
D
B
D
A
Y'all
dm
me,
your
contact
info
on
cncn
slack
cncs
slack
and
I'm
gonna
send
y'all
an
invite
to
come.
Hang
out
at
this
thing,
yeah
nicholas.