►
From YouTube: 2021-05-11 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
Is
anyone
familiar
with
the
ruby
client,
it's
failing
ci
for
everyone
at
the
moment
on
the
repo
and
I'm
just
looking
at
it
looks
like
there
was
some
off
change
recently
and
the
way
that
the
appraisal
setup
is
it's
using
the
latest
version
of
it.
So
I
guess
it's
pulled
like
a
new
release
and
it's
expecting
some
authentication
stuff
to
be
set.
I've
been
playing
around
with
it,
but
I'm
just
trying
to
ramp
up
quickly.
I
don't
know
it
might.
I
might
be
wasting
time
if
someone's
like.
A
C
Is
that
note
we
can
probably
get
started
with
the
meeting
if
anybody
else
have
any
insights
feel
free
to.
Let
us
know.
C
Yeah,
so
if
there's
any
burning
questions,
I
guess
we
can
cover
those
up
front.
I
see
there
is
a
bullet
point
that
reiterates.
I
think
I
dropped
in
the
cncf
slack
yesterday,
but
if
not
sure,
if
everybody
pays
attention
over
there,
there
is.
There
was
a
request
at
the
maintainers
meeting
yesterday
for
some
dynamic
languages
to
start
looking
at
prototyping,
the
metrics
api
and
sdk.
C
And
there
is,
there
is
an
otep
pr
off
the
top
of
my
head.
It
might
be
146
also
linked
there
that
this
work
would
be
based
off
of
and
yeah.
I
think
there
are
prototypes
ongoing
in
three
typed
languages,
so
they
were
kind
of
asking.
You
know
python,
ruby
js,
like
is
anybody
interested
in
prototyping,
something
so
yeah?
C
If,
if
you
are
interested
in
half
the
time
and
watching
this,
this
would
be
just
a
good
way
to
get
involved
and
actually
kind
of
influence
the
direction
of
things
I
know
sometimes
like
if
we,
if
we
are
actively
involved
in
the
prototyping
of
something
we
can
steer
it
in
a
direction
that
that
we
like,
if
we
just
kind
of
sit
back,
we
were
kind
of
left
with
like
what
what
everybody
else
gave
us.
So
that's
that's
one
motivation
for
trying
to
participate.
B
Yeah,
I
don't
want
to
commit
us
like
github
to
writing
it
or
anything,
but
we'd
certainly
be
able
to
assist,
and
we
would
certainly
test
it
because
metrics
are
something
we're
extremely
extremely
interested
in,
so
I'm
willing
to
collaborate
on
it.
But
I
don't
know
that
I
want
to
volunteer
to
do
it
all
myself
or
anything
also
because
it
probably
wouldn't
turn
out
very
nicely
if
it
did,
but.
C
B
C
Yeah
so
so
think
about
it,
and
if,
if
anybody
does
want
to
pick
that
stuff
up,
yeah
go
for
it
and
if
there's
anything
I
can
do
to
help
get
the
get
you
with
our
information.
Let
me
know.
C
I'll
go
ahead
and
jump
into
the
specs
egg.
I
don't
think
it
should
take
too
long.
C
There
is
a
semantic
conventions,
pr
for
mobile,
if
you're
interested
have
opinions
check
that
out
there
is
this
crossed
out
stuff
that
I
do
think
is
somewhat
important
if
you
are
in
the
right
space,
but
I
think
this
guy
evo
he
opened
a
handful
of
spec
issues
around
real
user
monitoring,
so
kind
of
like
tracing
from
the
browser's
perspective
and
some
of
the.
C
There
are
some
things
that
are
really
straightforward
in
the
browser
and
there
are
some
things
that
are
much
less
so
and
I
think
a
lot
of
people
who
spend
a
lot
of
time
working
on
fixing
from
a
browser.
I
have
thought
about
this
stuff
a
lot.
I
think
there
are
some
kind
of
varying
opinions
out
there
on
what
yeah
just
very
opinions
on
how
things
should
work.
C
But,
oh,
it
looks
like
it
looks
like
eric
is
here
I
feel
like
this.
Would
this
is
good
for
you
to
hear
but
yeah
for
people
who
work
at
places
where
people
have
some
expertise
in
browser.
I
think
bringing
this
issue
up.
Yeah
bringing
this
to
their
attention
would
be
a
good
idea.
I
think
evo
is
looking
for
a
to
get.
The
discussion
started
on
real
user
monitoring
and
just
getting
some
kind
of
definition
around
how
hotel
wants
to
handle
this.
B
E
Matt,
you
are
pretty
active
on
the
js
repo.
They
have
a
client
side
implementation
right.
Is
it
you?
How
is
that?
Does
anyone
really
use
that
one
in?
Is
there
any
feedback
around?
That?
Is
it
incredibly
heavy.
C
So
I
think
I
think
people
are
using
it.
I
think
it
is
heavier
than
people
wanted
to
be.
I
I
know
a
few
people
have
come
in
who
have
like
browser
expertise
and
they
they're
asking
hard
questions
about
package
size,
and
I
hope
they.
I
secretly
hope
that
they
come
and
like
fix
that
problem,
but
they
usually
end
up
leaving
and
yeah
yeah
without
doing
such
things.
C
There
is
some
browser
auto
instrumentation
there,
but
I
think
it's
I
think
it's
pretty
minimal,
which
which
I
think
is
what
you
want
for
browser,
but
I
think
there's
just
a
number.
E
I
can
run
this
up
to
five
poll
here.
The
the
rom
group
is,
like
surprisingly,
dis,
separate
from
actually
my
team.
The
backstory,
if
anyone
is
interested,
is
that
we
had
a
beta
thing
sitting
on
our
js
tracer
that
did
essentially
what
now
I
think
it
is
is
y'all.
The
open
telemetry.js
is
doing,
which
is
like
traditional
tracing
of
fetch
and
whatever,
and
it
was
it
bloated
package
sizes.
It
was
really
low
value
and
they
basically
threw
it
out
and
implemented
something.
That's
like
really
like
just
a
proprietary
like
it's
it.
E
Just
like
spams
out
events
which
we
stitch
together.
I
think
in
our
back
end
with
traces
closer.
Probably
I
guess
what
honeycomb
looks
at
or
for
you
know,
can
you
know
it's
just
like
lots
of
little
events?
Not
like
you
know
these
like
connect
distributors,
and
but
it's
it's
incredibly.
You
know
specific
to
the
the
back
end
you're
using
and
sort
of
not
built
in
a
way
to
be
extensible,
or
you
know,
maybe
intentionally
and
yeah,
and
so
they
found
greater
success
there.
So
it's
really
not
even
tracing
it's
more.
E
Just
like
selective
logging
with
you
know
details
so
I
this
is
a
minefield
but
yeah
I
can.
I
can
see
if
I
can
get
folks
from
that
team
to
jump
in.
I
don't
know
how
keen
they
are
too,
because
it's
not
an
open
source
project.
If
I
recall
correctly
anyway,
that's
for
that,
we.
F
Do
I
think
we
do
have
at
honeycomb?
We
do
have
people
using
the
open
sourced
honeycomb
js
libraries
to
instrument
their
front
ends,
usually
the
trouble
they
have.
There
are
not
so
much
around
semantics,
although
they
probably
run
into
semantics
when
they
get
advanced
enough.
It's
more
about
the
timing
of
your
clients,
like
clock,
skews
of
total
shenanigans.
F
Shenanigans
are
involved
with
clocks
and
but
they,
but
we
have
seen
people
doing
tracing
from
events
from
a
client
side
correlated
with
calls
to
the
back
ends
and
authentication
also
becomes
a
problem
there
where,
wherever
you're
collecting
data,
the
secrets
to
emit
events
are
something
that
you're,
presumably
putting
into
your
front
end
and
so
people.
F
So
if
people
are
people
have
to
go
digging,
but
if
your
api
keys
for
emitting
events
to
whatever
your
collector
is
or
in
your
front
end,
you
can
have
problems
with
people
finding
those
secrets
and
then
spamming.
Your
data
sets.
So
it
ends
up
being
like
a
weird
architecture.
Thing
like
where,
where
do
you
collect
the
huge
volume
of
events
that
you're
coming
that
you're
getting
from
the
front
end?
And
do
you
run
your
own
collector
and
have
all
your
front
ends
come
into
a
collector,
so
you're
paying
for
ingress
and
egress?
F
For
this
event,
data
two
or
more
times
so,
in
addition
to
the
semantic
conventions
of
how
do
you
describe
what's
happening
in
front
end
and
in
mobile
you've
got
architectural
concerns
about?
Where
do
you
collect
the
data
and
route
it
to
places
that
it's
useful.
E
C
Yeah,
at
any
rate,
I
think
this
is
a
little
bit
more
of
maybe
a
js
concern,
but
if
and
yeah
like,
I
do
think
there
is
bare-bones
stuff
that
generally
works
in
in
the
ecosystem
for
javascript.
But
if
you
know,
people
who
this
is
kind
of
their
bread
and
butter
that
you
might
work
with,
maybe
point
them
towards
this
issue
and
maybe
direct
them
over
to
the
js
seg
too.
F
Would
it
be,
would
it
be
basically,
whatever
conventions
are
sort
of
decided
upon
for
this
front-end
languages
like
javascript,
basically,
will
be
the
ones
emitting
this
data,
and
if
it's
data
that
you
want
in
your
back
ends
say
ruby,
it's
something
that
you
would
put
in
the
baggage
and
then
you
would
extract
it
out
of
the
back
end
and.
C
I
think
so
there
is
this
tricky
part.
There
is
a
yeah.
There
is
this
kind
of
dance
that
has
to
be
done
between
your
back-end
service
and
the
browser
in
order
to
stitch
up
a
trace
for
the
initial
page
load.
E
C
Yes,
I
think
this
is
probably
not
the
place
to
get
into
the
details.
Suffice
it
to
say
that
your
back
end
application
does
need
to
know
a
little
bit
about
the
browser
and
it
will
send
it
will
send
a
specially
crafted
trace
parent
back
to
the
browser
in
a
meta
tag,
and
the
browser
will
kind
of
use
this
to
create
a
span
in
post
for.
C
So
yeah
the
first
non-crossout
item
we've
talked
about
this
telemetry
schema
stuff
a
little
bit,
and
it
is
the
kind
of
way
that
we
expect
to
be
able
to
have
instrumentation
to
be
able
to
a
declare.
Instrumentation
stable
and
b
have
a
way
to
like
change
it
over
time
without
breaking
things
or
breaking
back
ends.
C
So
as
a
first
step
down
this
path,
there
is
a
you
will
need
a
schema
url
for
your
tracer
meter,
api
and
sdk.
So
I
think
this.
C
D
C
Etc
and
then
there
is
a
complementary
pr
in
the
for
otdlp
that
would
that
would
possibly
pass
this
up.
So
I
think
your
ultimately.
C
Will
provide
this
url
to
your
your
tracer.
Your
tracer
will
stable
that
on
to
to
the
spans
that
it
generates,
and
then
the
back
end
will
get
the
schema
url
with
the
spans
or
metrics
and
can
handle
any
potential
compatibility
issues.
C
There's
so
I
think
tigran
is
asking
people
to
consider
prototyping
this
and
he's
just
looking
for
feedback
as
to
how
people
feel
about
this
scheme.
In
general,
I
think
he
was
saying
there
is
a
prototype
for
go
already.
C
I
didn't
have
like
a
strong
impression
as
to
like
when
this
would
become
a
reality
and
what
it
would
actually
affect.
F
C
So
right
now
like
instrumentation
is
not
it's
not
stable,
we're
not
we're
not
releasing
it
under
any
like
1.0
numbers,
and
I
think
part
of
it
is
because
they
want
to
have
a
way
to
be
able
to
change
the
semantic
conventions
over
time
without
breaking
back
ends.
C
I
don't
know
like
the
way,
I
kind
of
think
that
this
would
probably
work,
and
I
could
be
totally
off
phase
because
I
haven't
tried
to
actually
implement
sound
like
a
back
end
but
like
if,
if
the
semantic
convention,
if
some
attribute
names
changed,
you
know
between
versions,
I
feel
like
you
could
have
this
thing
kind
of,
like
you
know,
rails
database
migrations,
whereas,
like
your
stuff
comes
in
like
you
could
have
like
a
pipeline
that
renames
things
or
handles
conversions,
to
kind
of
like
upgrade
your
schemas
or
upgrade
an
old
schema
downgrade
a
new
schema
whatever
and
just
kind
of
handle.
C
All
of
the
things
that
your
back
end
kind
of
needs
to
to
not
break
you
know,
and
some
back
ends
might
not
care
too
much
about
like
about
most
of
the
attributes.
I
I
think
this
is
another
thing
I
think
you
know.
Tracing
back
ends
have
different
different
requirements
on
kind
of
the
the
incoming
data.
Some
have
very
little,
but
I
feel
like.
C
One
thing
that's
fairly
important
that
I
think
a
lot
of
tooling
is
built
around
is
having
like
error,
an
error
tag,
an
error
attribute
of
true
on
a
span
where
there
was
an
error,
for
example,
and
if
this
changed
to
like
is
error
or
something,
then
that
that
would
probably
break
a
back
end.
But
other
things.
G
C
I
don't
know
less
crucial
attributes.
They
are
probable,
there's
probably
not
a
lot
of
special
logic
built
around
them,
so
it
might
not
be
a
big.
G
G
Described
in
other
formats,
so
jaeger
exporter
zip
connects
borders.
For
example,
we
do
have
mappings
for
hotel,
specific
fields
to
attribute
names
in
the
spec
for
other,
like
instrumentation
library
version
instrumentation
library
name.
G
So
that's
something
that's
not
called
out
here.
The
default,
if
we
do
nothing,
is
that
it's
assumed
to
be
the
version
of
the
schema
that
corresponds
to
the
sdk
version,
which
is
fine
for
built-in
stuff,
but
we
should
probably
try
to
implement
this.
I
mean
it's
not
not
insanely
difficult.
G
That's
a
good
question.
I
would
assume
it
should
anybody
who's.
G
I
don't
know
like
if,
if
you've
got
some
weird
scenario
where
people
are
instrumenting
their
stuff
in
open
telemetry,
but
they're
emitting
jager
to
something
and
then
that
their
back
end
is
ultimately
translating
it
back
into
otlp,
you
know
if
we
picked
some
arbitrary
vendor.
That
happened
to
be
wrapping
jager,
formatted
stuff
in
some
way
and
then
wanted
to
adhere
to
open
telemetry
semantic
conventions.
On
the
back
end,
you
know
cough
splunk
cough,
then
you
know
the
the
ability
to
identify
which
schema
version
is
in
use
is
probably
pretty
important.
C
All
right
yeah,
I
think
I
think
that
would
be
useful
feedback
on
on
these
issues
and
then
yeah,
like
I
was
saying
like
I
don't
I
don't
understand
when
this
would
come
in.
Is
this
a
1.0
concern?
Is
this
like
a
1.1
kind
of
it's.
G
There's
a
version
thing
somewhere
that
says
this
is
since
1.4
of
the
spec.
I
can't
remember
where
I
saw
it
but
yeah
since
1.4.0
schema,
url,
optional,.
G
Well,
I
mean
it's
1.4,
the
tracing
right,
so
we
don't
have
to
do
this
for
1.0
this
doesn't
get
1.0.
This
is
a
definitely
a
post,
1.0
thing
now.
They're
doing,
I
think,
point
releases
of
this
spec
every
month,
so
where
four
months
past
1.0,
I
guess
got
it.
C
Cool
so
yeah
at
some
point
we
might
be
putting
the
cart
before
the
horse.
We
should
probably
get
to
1.0,
but
we
should
consider.
We
should
at
least
look
at
this
to
make
sure
that
it
passes
the
smell
test
and
we
should
prototype
it
at
some
point
in
these
comments
I
think
about
exporting
other
formats
and
how
this
should
be
handled
for
year,
zipkin,
etc
are
are
valid
and
probably.
C
C
I
think
there
was
a
scheme
to
be
able
to
pass
status
to
span
and-
and
that
would
kind
of
give
you
like
an
easy
way
to
be
like
no
really.
This
is
the
status
because
you
that
happened
at
a
reliable
point
in
time,
whereas
any
other
stand
set
status
did
not
necessarily
have
a
game.
G
C
I
think
the
whole
thing
just
to
jog
everybody's
memory
here
is
that
setting
something
okay
is
like
a
special
case,
because
we
like
to
make
things
complicated
and
have
lots
of
special
cases,
but
technically,
like
the
instrumentation,
should
not
be
setting
a
span
as
okay,
it's
kind
of
meant
for
the
user
to
override
something
so
like
things
should
from
the
sdk
or
from
the
instrumentation.
C
I
think,
should
come
to
you
either
just
unset
or
set
as
possibly
error
if
it
determines
things
to
be
an
error,
but
the
user
can
always
say,
okay
even
to
something
that
had
been
previously
set
as
an
error,
and
basically
the
idea
with
this
pr
is
that
once
it
has
been
set
to
okay,
any
other
spam
status
call
will
just
be
ignored.
C
I
feel
like
there
are
problems
with
all
these
schemes
we
kind
of
like
talked
through
them.
I
think
last
week,
and
I
know
there's
a
pretty
big.
It
seemed
like
a
lot
of
people
on
this
call
liked,
having
like
a
rules-based
system
on
the
back
end,
which
I
kind
of
like.
I
feel
like
all
of
this.
C
But
yeah,
that
is
the
update
here.
I
don't
know
if
we're
going
to
solve
this
problem
on
this
call.
B
Yes,
not
sure
that
there's
really
much
we
can
do
about
it
one
way
or
the
other.
It
seems
like
there's
a
strong
contingent
of
people
who
feel
that
it
should
be
this
way.
We
could
tell
them.
We
don't
think
so,
but
I
mean
it
seems
like
it's
just
okay,
I
don't,
I
don't
know
really
what
to
make
of
it.
I
don't
know
that
there's
much
for
us
to
do
unless
we
really
really
feel
strongly
about
it,
and
I
think
after
reflecting
on
it,
I
don't
feel
that
strongly.
A
C
I
think,
as
long
as
we
as
long
as
you
know
how
it
works,
we'll
be
able
to
work
around
it
and
I
don't
know
we'll
see
how
it
plays
out
in
the
real
world.
I
guess
I
think,
is
kind
of
my
feeling
and
if
it's
good
enough,
it's
good
enough.
F
And
totally
okay,
if
you
want
to
punt
this
for
a
conversation
to
have
on
a
discussion
or
an
issue,
is
there
a
way
to
implement
this?
If,
if
this
is
the
spec
that
comes
down,
is
that
auto
instrumentation
will
over
only
ever
set
error
and
then
at
a
point
where
we're
finalizing
a
span
we
go
if
it
hasn't
had
an
error
set,
we'll
assume
it's
okay,
set
it
okay
and
if
it's
been
said,
okay,
auto
instrumentation
doesn't
clamber.
What's
that.
G
So
all
this
will
be
done
internally
in
the
sdk
span.
Implementation
you'll
just
have
that
state
machine
that
says,
ignore
attempts
to
unset
if
it's
been
set
to.
Okay,
then
don't
allow
overriding
it
with
error
and
otherwise
just
leave
it
on
set.
G
So
instrumentation
is
required
to
set
error
when
certain
conditions
apply,
and
you
know,
depends
on
the
semantic
inventions,
but
okay
outside
of
that
instrumentation
should
not
be
setting
it
to
okay
explicitly
you
just
leave
it
on
set.
So
this
is
just.
G
Yeah
yeah,
I
think
if
people
come
to
us
and
say
hey,
how
can
I
override
you
know
for
instrumentation
xyz?
How
can
I
get
it
to
ignore
these
things
that
it's
currently
setting
as
error?
G
Maybe
we
can
document
how
to
write
or
or
maybe
we
can
implement
a
helper
span
processor
that
would
do
the
right
thing.
Have
that
rules-based
thing
that
will
hammer
in
okay
if
they
want
to.
B
Or
whether
it's
worth
just
looking
through
the
instrumentation,
it
looks
like
we
only
only
the
rack
middleware
actually
sets
the
span
status
to
okay,
otherwise
we're
mostly
already
doing
the
right
thing
and
just
not
touching
it.
So
that
would
be
just
the
one
thing
I
think
we'd
have
to
clean
up
yep
cool.
C
Not
so
much
adding
this
hotel
service
name
environment
variable,
but
the
fact
that
it.
C
That
it
will
be
considered
somewhat
special
in
the
face
of
hotel
service
name
being
set
as
part
of
hotel
resource
attributes.
C
C
Why
do
we
have
some
some
variables
that
are
more
special
than
others,
and
how
are
we
supposed
to
like
know
about
this
and
reason
through
it
more
or
less,
and
I
I
kind
of
agree
with
the
fact
that,
like
there's
just
a
lot
of.
C
There
are
a
lot
of
things
that
we
are
like
declaring
special
by
like
documentation
and
other
things,
but
just
like
no
way
to
really
know
that
as
like
a
programmer
or
have
some
like
modeling.
I
guess
that
represents
this
to
some
degree
like
you
would
like
to
have
like
a
data
model.
I
guess
that
like
had
the
special
stuff-
and
you
know
the
the
proper
hierarchy,
so
that
it
was
easier
to
work
with.
G
Yeah,
I
think
it's
called
out
here,
because
there
is
special
handling
of
the
service
name
and
there's
requirement
in
like
the
jaeger
exporter,
for
example,
that
it
did
like
it
look
for
the
service
name
and
if
the
service
name
is
not
set,
then
go
look
at
the
default
attribute
and
get
the
default
service
name
and
then
there's
like
requirements
around
what
the
default
service
name
should
be.
G
If
nobody
provided
one-
and
that's
principally
because
jaeger,
like
the
jaeger
protocol-
and
I
think
the
zip
can
protocol-
require
the
service
name
to
be
set
in
a
distinct
field.
So
couldn't.
G
C
And
that
that
was
ultimately
the
rebuttal
is
service.
Name
already
has.
This
is
already
a
special
case,
even
when
it's
in
hotel
resource
attributes-
and
it
seems
to
be
one
of
these
things
that,
like
almost
every
back
end
requires,
I
don't
know
if
there's
any
back-end
that
actually
works
on
a
service
name.
So
it
makes
sense
that
it
is
kind
of
the
one
special
thing
sony.
F
C
Yeah
yeah
java
app
right,
so
at
any
rate,
this
did
turn
into
an
enormous
bike
shed,
but
I
think
the
the
idea
is
fine.
B
C
And
I
think
yeah
I
think
that
was
the
the
reason
for
the
bike
chat
was
to
kind
of
make
sure
that
there
aren't
possibly
some
better
ways
to
have
something
special
or
not.
I
think.
C
I
don't
think
there
was
a
really
good
resolution
there,
but
if
yeah,
if
there
is,
if
there
are
further
developments
on
this,
I
will
I'll.
Let
you
all
know.
C
C
There's
I
mean
there's
that
pull
request
to.
If,
if
you
like
to
comment-
and
I
think,
there's
also
a
related.
C
Yeah
the
unclear
merge
order.
Issue
is
possibly
related.
A
Can
I
jump
in
with
a
quick
one?
It's
not
a
pr
or
anything
the
attribute,
we're
setting
it
a
few
places,
it's
http.status
text
in
the
specification
it
was
marked
as
obsolete
and
removed,
we're
still
setting
it
in
a
bunch
of
different
places.
A
The
reason
why
I
paying
attention
to
it
is
because
it
came
out
today
that
one
of
the
applications
in
our
organization
is
using
status
code
418
for
something
real,
which
is
amazing,
I'm
a
teapot
yeah
yeah,
but
so
the
issue
comes
up
that
the
racquet
till
when
it
tries
to
map
the
code
to
the
text.
It
doesn't
have
an
entry
for
418.
A
So
it
raises
an
error,
and
there
they've
configured
the
error
handler
to
any
of
these
like
invalid
attributes
to
actually
raise
in
ci,
so
they
could
catch
any
of
these
instead
of
them
just
like
quietly
happening
in
their
logs,
which
is
great.
But
when
discussing
it,
because
it's
like
well,
should
they
should
the
application
patch
thrack
details
for
this
one,
so
they
can
use
the
code
and
just
live
happily
ever
after
or
should
we
potentially
remove
the
status
text
because
it's
been
removed
from
the
spec?
A
I
can
link
the
issue
that
made
it
obsolete.
I
just
wanted
to
see
if
we
were
hanging
on
to
it
for
any
specific
reason
and
what
how
people
felt
about
it.
I
kind
of
like
that.
It's
there
I
think
there's
value
in
it,
but
if
it's
not,
it
was
like
explicitly
removed
from
the
spec.
It
always
makes
sense
for
us
to
do
the
same.
B
Don't
separate
the
description
if
the
reason
can
be
inferred
well,
yeah
I
mean
I
would
say
we
should
remove
it.
Then
I
think
equally,
I'm
surprised
that
rack
doesn't
have
a
418
entry
and
we
should
also
probably
fix
that,
but.
A
Okay,
yeah,
I
think
as
long
as
there's
no
I'm
just
looking
for
resistance
against
removing
it,
and
in
the
absence
of
that,
I'm
just
gonna
go
ahead
and
remove
it
everywhere.
C
Yeah
sounds
good,
I
suspect
it
was
just
an
oversight.
There's
a
lot
of
things
to
keep
keep
up
with.
A
And
then
that
thing
I
mentioned
earlier,
I
put
up
a
full
request.
I
was
wrong
in
what
I
thought
it
was.
I
just
read
the
error
message
wrong.
I
think
one
of
the
the
tests
had
a
matcher
that
didn't
match
the
error
output
anymore.
C
C
B
I
mean
it
was
worth
thinking
about
again
to
make
sure
I
didn't
have
any
feelings
about
the
ruby
implementation,
but
I
don't
it's
mostly
just
I
just
don't
care
for
that
part
of
the
api,
but
that's
fine.
I
don't
have
to
like
everything
so
I
have.
I
have
no
complaints
about
our
implementation
of
it
at
all.
B
C
I
think
I
think,
there's
a
good
deal
of
weirdness
there.
I
don't
know
that
you're
gonna
avoid
it
and
avoid
it
completely
with
any
implementation,
but
yeah.
I
I
will
agree
that
there
is,
is
a
learning
curve
into
weirdness
there,
but
it
is
pretty,
I
don't
know
it
does
match.
I
think
what
what
other
open
telemetry
implementations
are
are
generally
doing
yeah.
I
would
agree.
C
Any
any
other
concerns
come
up
over
the
last
week.
E
The
the
the
instrumentation
there
is,
I
don't
think
that
blocks
the
rc
at
all.
There's
one
small.
I
need
to
make
a
pr
there's
one
small
typo
in
our
in
one
of
our
instrumentation,
all
in
the
instrumentation,
all
gem,
I
think
around
the
version
of
postgres
to
use.
That
was
the
only
thing
I
noticed
as
weird,
but
the
tc
review
shouldn't
be
related
to
that.
As
far.
G
E
E
Yeah,
I
I'm
just
okay,
let's
do
it
and
and
then
let's
all
write
blogs
about
it
and
promote
it
and
tweet,
and
I
don't
know.
C
So
yeah
about
a
tc
review.
I
did
mention
this
at
the
maintainers
meeting
yesterday,
just
briefly
that
you
know
they
always
ask
for
a
status
update
and
I'm
always
like
ruby
we're.
You
know
we're
we're
close,
there's
an
issue
or
two
in
our
backlog
for
the
milestone,
but
so
I
gave
that
usual
update,
as,
along
with
we
might
be
interested
in
a
tc
review.
We
were
kind
of
discussing
that
as
a
sig
and
javascript
daniel
dowdler
from
javascript
at
least
chimed
in
saying
he
thought
the
review
was
valuable
for
them.
C
So
I
was
just
going
to
pass
that
on.
I
don't
know
I
thought.
E
C
B
Does
do
we
need
to
block
the
release
candidate
on
a
review
from
the
tc
or.
G
G
G
To
see
what
the
appetite
is
for,
I
have
not
yet
it
was
kubecon.
Was
it
earlier
this
week
or
maybe
still
going
on
our
camera?
Last
week?
Sorry
cubecon
was
last
week
so
yeah
I
didn't
reach
out
to
anybody
that
are
a
bit
busy
with
kubecon.
C
C
G
C
Excellent,
I'm
sure
they
will
appreciate
that
all
right
is
there.
G
I
think
it's
just
prep
a
release.
Really
I
don't
know
if
we
have
anything
queued
up
that
we'd
like
to
do
as
a
0,
18
0
release
or
if
we
just
want
to
jump
straight
to
a
1.0,
rc
1
for
sdk
and
api
and
then
release
everything
else
is
0
18.
B
0.,
I
don't
think
anything
major
has
changed
recently
with
the
api
or
the
sdk.
The
changes
have
all
been
around
resource
detectors
and
instrumentation
and
exporters
and
things
so
yeah.
A
G
We
wanted
to
split
up
the
resource
detectors,
so
we
extract
the
gcp
resource
detector
from
the
general
framework
for
resource
detection.
Does
anybody
have
opinions
about
moving
the
general
framework
into
the
sdk,
or
do
you
want
to
keep
that
separate?
C
My
gut
feeling
without
having
double
checked
the
spec,
is
that
the
mechanism
should
probably
be
part
of
the
sdk,
and
then
the
individual
implementations
can
be
in
their
own
gems,
but
kind
of
like
the
resource
detection
based
stuff
could
go
in
there.
F
G
Api
says
nothing
about
resources.
Resources
are
just
an
sdk
concept,
so,
okay,
whereas
with
instrumentation
like
you
need
the
instrumentation
should
ideally
only
depend
on
the
api
and
not
depend
on
the
sdk,
so
you
can
swap
out
and
swap
in
an
sdk
implementation.
Okay,
so.
B
G
We
maybe
we
want
to
take
a
quick
look
at
that
again,
it
doesn't
have
to
get
the
rc.
We
can
do
the
rc
and
then
do
this
refactoring
before
1.0.
B
Yeah,
I
think
we
might
have
to
change
something
just
reading
through
the
the
spec
but
yeah,
I
would
say
we
should
still
go
forward
and
just
work
on
that
in
parallel.
It's
we've
been
talking
about
doing
a
release
candidate
for
a
while,
and
I
think
we
should
just
go
for
it.
There's.
G
C
B
C
Yeah,
given
that
you
know
I
can
go
either
way
on
this,
if
we
wanted
to
address
that
before
the
rsc,
we
could,
if
we
wanted
to
start
an
rc
and
then
just
address
that
in
rc2-
that
I
think
would
be
really.
I.
G
Think
I'd
like
to
I'd
like
to
start
the
rc
process.
I
think,
where
we've
been
in
this
sort
of
holding
pattern
for
a
while,
we've
cleaned
up
all
the
little
straggling
issues.
You
know
this
is
the
kind
of
stuff
that
we
should
be
cleaning
up
during
rc
and
before
1.0.
So
I
think
we
should
just
proceed.
C
C
Yes,
yes,
so
thumbs
up:
let's,
let's
get
an
rc
going
cool.
G
Do
we
have
any
pr's
and
issues?
There
is
a
pr
about
jaeger
collectors.
I
was
exporting
to
jaeger
collectors
with
self-signed
certificates.
This
is
not
an
issue
that
affects
us,
and
so
we
haven't
really
thought
too
deeply
about
it.
It
seems
like
it's
a
ruby
specific
thing,
maybe
I
don't
know
so
I've.
G
I
think
this
is
good
to
go,
but
if
anybody
has
strong
opinions
about
this,
please
be
vocal
on
this
pr.
B
I'll
take
a
look
at
it.
I
I
was
actually
thinking
about
it
this
morning
and
the
main
thing
I
was
thinking
about
was,
I
can
never
remember
the
result
of
the
bit
shifting
and
the
integer
results,
and
that
might
be
nice
to
clarify
that
somehow,
but
yeah
I'll
I'll.
Look
at
it
one
more
time:
cool
thanks.
B
G
G
There's
this
active
job
instrumentation
somebody
wrote:
maybe
we
should
get
around
to
reviewing
it
at
some
point.
Yeah.
B
I'm
fine
we've
got
our
own
internal
version.
We
can
take
our
time.
So,
okay,
it's
not
urgent,
but
if
anyone
does
use
active
job
heavily
and
wants
to
test
it,
I'm
definitely
curious
what
you
think
we
don't
do
explicit
context
propagation
in
the
jobs
and
we've
been
debating
that
internally,
whether
or
not
we
even
want
such
a
thing.
B
G
Yeah,
that's
fair.
We've
chosen
to
use
the
messaging
semantics
for
now,
while
the
job
thing
is
getting
figured
out,
so
I
think
we
have
instrumentation
for
sidekick
here
the
I
do
think
you
should
propagate
context
with
the
job.
What
you
choose
to
do
with
it
on
the
other
side,
is
the
the
interesting
thing
right?
Do
you
want
to
start
a
new
trace
with
a
link
to
the
thing
that
included
or
do
you
want
to
continue
the
trace
as
a
follows
from
type
thing.
B
Yeah
the
thing
that
I
was
really
not
sure
about
the
first
pass.
I
did
at
doing
this
actually
just
mangled
the
arguments
of
the
job
itself
and
passed
in
context.
Basically
as
a
hash
and
rails
can
serialize
that,
and
it
worked
well
enough,
although
I
did
run
into
some
problems
and
little
bugs
here
and
there,
where
I,
I
wasn't
popping
the
arguments
off
correctly
and
little
things
and
that
could
work.
The
other
approach
I
was
thinking
of
was
actually
patching
active
job
itself
to
accept
some
other.
B
You
know
like
baggage
sort
of
attribute
that,
like
or
headers
or
some
sort
something
else
that
it
would
serialize
automatically
separate
from
job
arguments,
which
would
be
a
bigger
change
for
the
instrumentation,
something
we
could
propose
upstream
to
rails.
If
we
thought
it
was
useful,
it's
basically
the
the
real
problem
is
just
that:
there's
no
there's
no
way
to
send
along
additional
information
without
a
job
aside
from
what
rails
already
sends.
B
That
was
mostly
what
I
ran
into.
If
people
have
opinions
on
that,
I
definitely
interested
because
it
it
would
be
nice
to
at
least
optionally
be
able
to
pass
context
or
something.
I
would
agree
that
would
be
nice,
just
wasn't
really
sure
how
to
do
it
without
wanting
to
you
know,
vomit.
Looking
at
the
code
that
I
had
written.
G
Yeah
we
had,
we
had
internal
instrumentation,
for
I
think
it's
rescue
that
has
to
deal
with
weirdness
around
whether
you're
using
active
job
with
rescue
or
you're,
just
using
kind
of
naked
rescue
and
it's
horrible.
The
code
is
really
nasty
and
buggy
and
yeah,
even
even
the.
A
Sidekick
instrumentation
is
active
job
aware
so
it'll
do
some
some
voodoo
to
make
sure
it
pulls
out
the
job
class
name
and
other
relevant
information,
because
it
doesn't
actually
know
if
it's
from
active
job
or
not
so
sidekick
is
doing
a
little
bit
stuff
there.
If
you
want
to
look
at
that.
B
Yeah
I'll
take
a
look
at
that
and
if
I
come
up
with
a
scheme
for
passing
the
context
without
wanting
to
hate
hate
it,
I
could.
The
pr
could
also
possibly
update
the
psychic
instrumentation
to
be
aware
of
that
as
well.
But.
E
I
mean
obviously
isn't
this
sort
of
the
point
of
open
telemetry.
Is
that
like
previously?
We
wouldn't
you
know,
you
don't
really
have
grounds
to
make
an
upstream
pr,
because
it
you
know,
vendors,
have
opinions
or
whatever,
but
we
could
do
that
in
a
way
that
you
might
be
more
palatable
for
for
railscore.
G
Yeah,
I
mean
ultimately
it's
a
chicken
and
egg
thing
right.
It's
like
we
need
to
show
that
open
telemetry
is
successful
and
is
largely
supplanting.
You
know
all
these
vendor
instrumentation
approaches
before
we
can
go
to
something
like
rails
and
say:
hey
we're
super
successful.
You
should
just
include
open
telemetry
instrumentation
directly.
G
F
B
B
That's
this
is
actually
good
to
think
about,
though
I
I
think
I
will
take
another
look
at
it
and
see
what
I
can
do
and
see.
If
I
can
write
something
that
we
could
upstream
to
rails
and
if
it
proved
successful
at
our
repo
monkey
patching
it
in
then
we
can
we
can.
We
could
send
it
to
them
and
see
what
they
say.
I
think
you're
right.
It's
an
interesting
chicken
and
egg
problem.
I
don't
know
how
we
would
ever
prove
to
rails
that
open
telemetry
is
successful
and
has
supplanted.
B
F
If
there
was
some
weird
of
gen
some
way
to
generize
it
like
at
least
through
active
record,
there
is
this
co
there's.
This
missing
concept
of
you've
got
a
job.
You've
got
parameters,
you've
passed
the
job
and
then
there's
this
context
that
who
called
this
job
and
how
do
you
keep
track
of
that
and
how
might
active
support
notifications
tell
you
that
this
happened
well.
D
One
of
the
things
that
probably
has
to
be
dealt
with,
I'm
sure
some
of
you
guys
don't
already
have
just
the
writing.
For
me,
though,
is
that,
like
this
isn't
an
http
request
or
a
network
request,
it's
actually
saved
in
some
sort
of
backing
service
right
and
often
right.
When
you
make
the
background
system
system,
the
parameters
themselves
normally
are
really
small.
It's
like
three
integers
or
one
id.
You
know
whatever
right
so.
D
Hotel
baggage
into
it,
which
is
way
bigger
and
then
jam
it
into
like
I
mean
god,
help
you
if
you
try
to
do
this
in
delayed
job
you're
broke
in
your
my
sequel
table,
which
you
shouldn't
be
using
anyway,
but
right,
like
I
do
sort
of
wonder,
there's
a
there's,
a
non-trivial
performance
problem.
Right
I
mean
do
I
have
that
wrong.
Have.
F
B
Oh,
I
I
have
stories
I
could
tell
here
about
background
job
systems.
I
I
once
worked
for
a
place
that
include
entire
http
requests
into
redis
and
then
pulled
them
off
asynchronously
and
it
was.
It
was
a
trip.
It
actually
worked
for
the
most
part,
which
is
the
worst
part.
That
said,
I
think
active
job
actually
just
serializes
everything
to
json
and
then
I
think,
even
for
other,
even
job
q
systems
that
shouldn't
be
serializing
ton
of
things
into
it.
I
think
active
job
forces
you
to
do
that.
B
So,
if
you
use
active
job,
you've
accepted
that
overhead
already,
I
think,
but
it's
fair
to
say
we
shouldn't
add
more
than
is
necessary.
I
I
said
baggage
I
should
clarify.
I
was
mostly
thinking
of
just
specifically
the
context,
but
we
could
extend
it
to
baggage
if
we
wanted
and
let
people
do
that.
B
F
B
Yeah
I
mean
active
job,
defines
a
whole
serializer
interface.
Basically,
that
defines
how
to
serialize
and
deserialize
things
essentially
from
json.
I,
if
I
had
to
guess,
which
is
just
a
guess.
I
would
imagine
that
if
this
mythical
background
context
thing
already
exists
in
rails,
it's
probably
just
a
hash
of
things
that
are
serializable
to
json,
but
yeah.
I
will
look
into
that
and
report
back.
Actually,
I
will
research
a
bit
today.
F
From
from
a
vendor
perspective,
we
have
seen
just
in
the
domain
of
keeping
track
of
background
jobs.
Our
customers
have
wanted.
Sometimes
they
want
them
inserted
into
traces.
Sometimes
they
want
links
to
new
traces
with
links
back
to
the
original
caller,
largely
the
influences.
F
G
Good
yeah,
I
think
we
should
probably
go
back
to
sidekick
instrumentation
and
add
that
option.
I
do
know
that
we
have
seen
if
we
we've
gone
back
and
forth
at
shopify
on
using
linked
traces
or
using
follows
from
and
when
we
use
follows
from
so
we
extend
the
trace.
We
have
had
quite
regularly
traces
with
tens
of
millions
of
spans
yeah.
G
Yeah,
it's
just
impossible
like
nobody's
looking
at
that
right.
The
other
thing
is
that
a
lot
of
a
lot
of
analytics
tools
that
are
built
assuming
microservices.
G
Tend
to
not
represent
those
things
well
as
traces,
so
they'll
tell
you,
you
know
the
trace.
Duration
was
five
minutes,
and
that
had
that's
because,
like
the
request
took
100
milliseconds,
but
then
the
background
job
ran
five
minutes
later
right.
So
the
analytics
tools
aren't
really
well
designed
for
this
kind
of
thing.
So
I
think
having
a
configuration
option
is
a
good
idea
and
we
should
go
back
to
the
psychic
instrumentation
and
add
that.
F
I'll
go:
take
a
look
at
honeycomb's
own
implementation,
for
keeping
track
of
at
least
sidekick
and
see
what
we
do.
It's
actually
a
community
honey
kick
is
the
that's
not
part
of
the
core
stuff
I'll
see
what
what
they.
G
Yeah
cool
that'd
be
helpful.
I
know
we're
over
time.
There
is
one
draft
pr.
That's
been
hanging
out.
It's
really
just
a
placeholder
from
miguel
montalvo.
He
reached
out
to
me
in
the
cncf
slack
and
said
that
he
was
resolving
some
issues
with
his
pr
and
he's
hoping
to
push
something
up.
I
think
today,
so
in
general,
I'm
not
fond
of
these
placeholder
pr's
I'd
rather
just
assign
issues
to
people,
but
anyway,
once
this
is
done.
Maybe
we
can
ask
him
to
not
do
it
that
way.
G
Next
time,
but
anyway,
we
should
see
some
movement
on
that
pr.
So.
G
So
that's
all
I
had
we're
over
time.
Was
there
anything
anyone
else
wanted
to
talk
about
not
really
nope
cool
hi.
Everyone
good
bye,.