►
From YouTube: 2022-09-13 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
B
Starting
time
and
a
decent
crowd,
if
anybody
else
shows
up.
B
Go
ahead
and
go
through
a
specsig
recap
brought
to
you
by
nobody
seeking
sponsors.
There's
this
issue
with
Prometheus
namespaces.
That
seems
to
keep
coming
up.
B
And
yeah
I
think
I.
Think
I
didn't
fully
understand
what
they
were
talking
about
for
a
while.
I
still
feel
like
a
lot
of
people
are
clueless
in
this
conversation,
but
I
feel,
like
maybe
I,
had
a
breakthrough
and
understanding
what
exactly
is
being
proposed.
I
think
the
the
end
result
of
this
discussion
was
that
the
author
was
going
to
write
up
something
that
people
could
understand,
but
I
think
what's
happening
is
for
Prometheus
in
order
to
kind
of
make
sure
that
metrics
are
unique
in
in
hotel.
B
We
have
a
media
provider
and
the
meter
provider
has
a
name
and
a
version,
and
that's
how
we
kind
of
ensure
that
there
isn't
clashes
between
metrics
Prometheus
doesn't
really
have
that,
so
they
rely
on
like
a
prefix
for
the
metrics
and
I
think
really
they
just
want
to
use
kind
of
like
the
scope
name
as
the
prefix,
but
I
think
what
had
happened
is
that
the
scope
name
can
be
quite
long
depending
on
languages
that
can
be
very
long
like
in
Java
I
think
they
end
up
being
like
the
fully
qualified
class
name,
and
that's
like
a
little
bit
too
long
for
Prometheus,
so
I
think
they
were
suggesting
just
having
a
short
name,
and
then
somebody
was
like.
B
Why
don't
you
just
call
it
a
namespace
and
other
people
were
just
saying
like
isn't
this
just
scope,
but
that
I
think
is
at
least
the
tldr
of
the
issue.
It's
ongoing.
There's
no
resolution,
but
if
any
of
that
is
something
that
you're
interested
in
feel
free
to
follow,
the
issue
is.
C
This
a
this
is
a
potential
spec
change
to
support
the
fact
that
Prometheus
requires
a
prefix
in
the
metric
name
in
order
to
I'm
I
think
what
I'm
wondering
is
to
put
it
nicely,
why?
Why
is
this
an
otel,
specific
problem
that
requires
a
spec
change?
It
almost
feels
like
a
config
option,
for
maybe
the
exporter
in
The,
Collector
or
something
you
know,
I'm
kind
of
I
guess
I'm
kind
of
curious.
Why
it's
a
spec
issue?
If
you
have
any
insight
on
that.
B
Yeah
I
think
I
think
there
are
a
lot
of
questions
in
in
the
saying
I.
Don't
think
anybody
I
think
there's
a
lot
of
resistance
from
having
to
actually
add
anything
to
to
hotel
or
the
hotel,
spec
and
I
think
there
is
a
huge
desire
to
be
able
to
kind
of
determine
something
at
like
the
exporter
level
or
something
else
that
can
just
be
appended
on
so
I
think
gotcha,
yeah,
I,
I
think
your
argument
has
been
represented
there.
B
I
really
don't
know
what
the
what's
the
direction
of
this
is
actually
going
to
take,
but
at
least
I
feel
like
after
having
heard
bits
of
this
argument
for
the
last
month
or
two
I
feel
like
I
finally
understand
at
least
what
is
being
talked
about,
which
is
an
achievement.
C
Definitely
definitely
cool
that
makes
sense.
I'll
I'll
read
the
issue
and
I
mean
you
know.
We
we
have
like
in
the
spec
there's
recommendations
for
like
how
you
should
translate
things
to
Jaeger,
for
example,
for
tracing,
like
so
I
mean
I.
Guess
like
a
recommendation
of
like
there's
ways
to
do
it,
that,
like
don't
like
couple
us
too
Prometheus
I,
guess
so:
okay
cool!
Thank
you.
My
my
questions
are
answered.
I
yield
the
floor,
cool.
B
All
right,
so
the
thing
that
was
also
slightly
contentious
is
that
we
changed
from
instrumentation
library
to
instrumentation
scope
and
with
instrumentation
scope.
You
now
get
this
ability
to
add
scope,
attributes
and
that
that
ultimately,
is
considered
a
a
breaking
change,
because
before
it
was
kind
of
like
the
name
and
version
attributes
that
kind
of
identified
the
thing
producing
the
Telemetry.
But
now
that
you
can
add
these
scope
attributes
it
kind
of
like
opens
up
the
door.
B
So
if
you
were
kind
of
trying
to
group
Telemetry,
if
you
were
grouping
Telemetry
by
name,
inversion
or
just
kind
of
by
scope
in
general,
that
kind
of
changes
with
the
addition
of
scope,
attributes
so
I
think
there
have
yeah.
B
Ultimately,
I
think
the
idea
is
that
we
need
to
decide
whether
or
not
the
all
these
scope
attributes
are
identifying
or
not
and
or
whether
we
just
kind
of
pick
some
of
them
to
be
identifying,
and
there
were
three
proposals.
I
think
all
right.
B
This
one
was
closed,
so
this
was
full
scope
name,
it
existed
for
a
short
period
of
time
and
it
was
basically
saying
that
you
could
just
so
people
know
what
what
one
of
the
ideas
was
was
to
have
something
called
Full
scope,
name,
which
was
the
scope
name
and
then
all
the
key
value
pairs
kind
of
concatenated
together
as
one
string
kind
of
like
a
user
agent
in
a
in
a
way
that
you
would
always
produce
kind
of
the
same
string,
but
that
would
make
everything
basically
kind
of
feed
into
the
identity.
B
Some
of
the
other
things
are
basically
remove
scope,
attributes
from
the
scope,
identity,
which
I
think
it
just
means
that
name
and
version
are
the
only
things
that
actually
matters
from
scope
and
I
believe
this
is
the
direction
that
we
are
headed.
There
was
one
approval
earlier
and
then
there
are
now
two
more
approvals,
so
this.
B
Direction
that
folks
are
going
so
basically
yeah
go.
B
B
Do
you
return
a
new
Tracer
provider
for
every
like
set
of
scope
attributes,
but
it
seems
like
you,
meters
or
tracers,
are
identified
by
name
version
and
schema
URL.
So,
regardless
of
what
additional
scope
attributes
are
there,
these
are
the
identifying
things.
C
I
mean
I
always
was
a
little
confused
about
what
scope
attributes
really
brought
to
the
table.
Other
that
you
know
resource
attributes
for
signal
specific
attributes
couldn't
already
provide
so
I
guess
in
some
ways,
like
makes
sense
to
me,
but
I
I,
don't
know
I'm
kind
of
interested
to
see
what
people
find
them
on.
B
All
right,
there
was
another
question
not
related,
but
somewhat
impacted,
I.
Think
by
previous
questions
should
Scopes
be
allowed
to
conflict
between
metric
producers
and
the
SDK,
and
ultimately
there
was
at
least
this
outcome
saying
that
the
metric
readers
should
warn
users
about
conflicts,
but
should
pass
the
metrics
through
to
to
exporters.
A
B
The
latest
action
was
basically
a
reiteration
of
that
comment.
The
magic
reader
should
emit
a
warning
about
the
duplication,
with
steps
for
users
to
resolve
the
duplication.
B
B
Next
up
I
just
kind
of
brought
back
up:
otlp
Jason,
Json
stability.
It
was
it's
something
that
has
been
talked
about
for
for
quite
a
while
and
I
think
June
June
or
July.
We
at
least
kind
of
came
up
with
this
list
of
things
that
needed
to
be
done
to
declare
otlp,
1.0
and
then
I
think
Bill
just
got
busy
with
summer
vacation.
So
I
was
just
resurfacing
this
to
see
if
there
was
any
like
big
block
areas
or
we
could
start
looking
into
this
a
little
bit
more.
C
What
otlp
Json
is
kind
of
like
the
one
of
the
big
blockers
there
and
I'm
wondering
what
really
has
to
be
decided
for
oclp
Json,
no
one
to
be
experimental.
Was
it
just
the
the
key
naming
thing
that
I
remember
from
a
while
ago.
B
So
there
was
that
and
then
I
think
one
of
the
other
things
that
that
came
up
so
yeah
I
think
ultimately
being
happy
with
the
names
in
the
Proto.
Buffs
is
one
of
the
big
concerns
because
protobuf
you
can
kind
of
rename
things
that
will
and
it's
not
a
photobomb
breaking
change,
but
it's
definitely
a
Json
breaking
change.
B
So
once
things
are
declared,
stable
names
are
kind
of
locked
in
and
then,
as
the
enum
value
names
in
in
Json
I
think
were
another
thing
that
was
being
talked
about.
If
you
just
use
the
number
that
the
genome
is
represented
by
then
things
just
work
out,
so
I
think
people
wanted
to
specify
that
that
was
going
to
be
the
case.
I
feel
like
there
was
an
issue
somewhere.
B
B
But
I
think
yeah
I
think
JavaScript
already
was
using
the
the
numerical
version
of
the
enorms,
so
it
did
not
seem
like
that
was
super
controversial.
C
B
Yeah
I
think
yeah
otop
Json
has
really
been
the
only
way
to
get
spans
out
of
the
browser
which
makes
this
quite
important.
I
know
there.
There
is
some
work
being
done
potentially
to
make
protobuf
export
from
the
browser
possible
put
over
http
but
I.
Don't
think
I,
don't
think
the
current
Js
exporters
work
from
the
browser
other
than
the
OTL
PJs
on
version.
B
But
yeah
I
think
there
is
really
no
resistance
to
moving
this
work
forward.
I
think
it's
just
that
it
keeps
getting
like
put
on
the
back
burner,
so
I
just
wanted
to
resurface.
That
last
but
not
least,
I
think
we're
down
to
our
last
minute
on
the
Sam's
out
of
here.
So
we
could.
We
could
extend
this
for
for
a
long
long
time,
but
we
will
not.
We
will.
We
will
wrap
this
up
the
Boolean
environment,
variables,
business,
I,
think
yeah.
The
discussion
today
was
basically
the
phrasing
of
these
environment.
B
Variables
must
must
be
phrased
such
that
false
is
the
default
value,
and
that
case
insensitive,
true,
is
the
only
thing
that
toggles
it
on
I
think
there
was
some
discussion.
B
Most
of
the
discussion
was
around
like
what,
if
you
need
to
change
the
behavior
of
the
environment
variable
this
kind
of
false
restriction
makes
things
difficult,
but
people
I
think
the
consensus
was.
A
D
B
And
if
it
did
happen,
where
you
had
to
introduce,
like
you
know
a
it
changed
this
environment
variable
such
that
the
true
or
false
would
be
interpreted
differently.
It's
really
just
a
different
environment
variable
and
you
would
probably
have
to
go
through
some
sort
of
like
deprecation
strategy
to
it.
B
Deprecate
the
current
thing
introduce
a
new
one,
but
that
would
be
the
way
to
resolve
such
a
conflict.
I
believe
so,
it
seems
like
this
stuff
is
rounding.
The
corner.
C
I
guess
the
upside
is
that
open
Telemetry
will
have
one
of
the
most
robust
specifications
for
how
to
parse
environmental
variables
of
any
project
out
there,
because
I
mean
this
is
kind
of
it's
kind
of
the
status
quo
for
a
lot
of
things
like
what
exactly
what
is
a
Boolean
value,
no
I,
don't
know
sort
of
the
whole
industry's
been
very
comfortable
with,
like
nobody
knows
it's
very
up
in
the
air
for
quite
a
while,
so
I
don't
know
be
nice,
I
guess
for
that
to
be
decided,
but.
A
B
C
C
C
A
B
Yeah
looking
at
the
agenda,
it
is
empty
and
nobody
nobody's
at
this
meeting.
So
this
is
not
even
happening
now.
Is
there?
Is
there
anything
we
would
like
to
talk
about
with
our
repo
I'm.
E
Curious
about
progress
on
metrics,
because
you
know
it's
got
that
busy
season
coming
right:
Robert,
where
shopping
season
starts
in
a
couple
of
weeks
or
whatever.
D
I,
don't
have
a
good
update,
I
I'll,
be
honest,
I've
been
just
like
super
distracted,
I
got
a
house,
but
not
yet
like
in
a
couple
days,
so
I've
been
going
through
all
of
that
just
kind
of
kind
of
like
address
and
deflect
here.
So
we
could
talk
about
the
house
that
I'm
getting
if
you
want.
No,
the
pr
is
actually
at
a
point.
The
latest
PR
is
adding
the
synchronous
aggregation.
D
So
that's
been
kind
of
a
big
thing
to
move,
because
it's
just
like
how
do
we
accumulate
these
metrics
in
memory
and
then
dump
them
out
after
I?
Don't
know
if
Matt
you
want
to
just
like
pull
up
the
pr
just
to
show
that
like
stuff
has
been
happening,
it
should
be
the
top
pull
request
in
the
list.
I
think
it's
like
the
part
of
the
most
recent
one
I
should
say
so.
There's
been
a
lot
of
like
work
being
done
on
it.
D
It
slowed
down
the
last
couple
weeks,
I
took
some
time
off
and
then
I'm
taking
some
time
off
next
week,
but
this
is
at
a
point
where
I
need
to
Hound
my
two
to
four
reviewers
Francis
and
Andrew,
to
be
like,
hey,
like
what's
missing
on
this
one
and
the
next.
The
next
Fallout
piece
to
this
will
be
working
on
the
metric
reader,
which
is
kind
of
like
our
spam
processor
I'm,
going
to
draw
parallels
there
follow
on
to
that.
D
It's
the
exporter,
once
this
gets
merged
in
I'm,
opening
the
door
to
anybody,
who's
interested
in
working
on
an
asynchronous
instrument,
so
I
mean
don't
everyone
jump
in
at
once,
but
it
is
there.
There
is
work
to
be
carved
off.
I
did
create
a
project
board
for
this
work.
It
is
very
sparse,
so
yeah.
If
you
go
to
projects.
C
D
So
very,
very
simple:
I
did
actually
order
them
in
some
sort
of
what
I
think
to
be
a
reasonable
way.
So
once
this
gets
merged
in
I
think
again,
this
this
opens
the
door
for
someone
to
work
on
asynchronous
instruments,
we'll
see
what
has
to
change
for
it
to
fit
metric
readers.
This
is
what
I'm
going
to
jump
on
next.
So
then
we
can
I
can
work
on
the
exporter
after
which
will
be
the
oclp
exporter.
D
Just
as
like
the
first
Target
views
is
I,
don't
know
how
much
anyone
cares
or
has
thought
about
views
or
what
they've
or
even
read
about
them.
It's
this
way
of
just
kind
of
modifying
the
Telemetry
Data
before
it's
emitted.
We're
probably
gonna,
have
to
do
some
code
surgery
to
fit
it
in
after
we've
kind
of
accepted
and
acknowledged.
That
is
a
means
of
like
trying
to
expedite
an
already
slow
process.
D
Yeah
I,
don't
know,
I,
don't
know
what's
worth
getting
into
the
Nitty
Gritty
of
it.
I
have
been
running
some
just
like
local,
simple,
like
profiling,
in
terms
of
like
memory
profiles
of
the
work
I've
been
doing
just
to
be
like
how
bad
is
this
really,
if
we're
gonna
activate
all
the
data
in
memory
at
whatever
interval-
and
it's
I
mean
I
benchmarking
against
itself,
but
it's
like
it's.
Okay,
we've
made
some
reasonable
decisions,
I
think
yeah,
no,
there's
a
there's
a
lot
of
stuff
in
there
there's
a
lot
going
on.
C
I
was
gonna,
say:
is
there
a
way
to
parallel
lies
even
more,
you
know,
I
mean
we
definitely
all
want
to
help.
I
know.
I
know,
you've
got
a
ordering
in
mind,
I
guess
but,
like
you
know,
feel
free
to
tap
out
and
let
someone
else
take
it
for
a
while
at
the
game,
and
then
we
can
I
I.
Think
async,
not
alone.
D
After
this
gets
murdered,
I
think
async
instruments
are
not
blocked
by
anyone
or
anything.
So
it's
just
like
if
you
would
like
to
do
that.
Please
do
the
metric,
reader
and
again
I
think
is
relatively
disconnected
from
the
rest
of
the
stuff
and
like
in
terms
of
like
two
things
can
get
worked
on
at
once
and
even
the
asynchronous
instruments.
Once
one
is
done,
then
people
can
split
off
the
other
two
right
and
then
once
the
metric
reader's
done
and
the
exporters
get
written.
D
A
D
D
D
So
I
don't
know
if
that
was
helpful
at
all.
That
is
the
metrics
update
that
I
have
again.
If
we
wanted
to
get
into
the
more
specifics
of
it,
we
could
Francis
and
I
are
meeting
with
Tristan
after
this
to
talk
about
some
of
the
metrics
were
because
I
believe
he's
working
on
the
Elixir
perlang,
which
one
is
it
elixir
the
likes
of
the
language.
C
Yeah
so
I
mean
Elixir
is
elixir
and
erling
both
run
on
the
beam
virtual
engine
or
virtual
engine.
You
can't
think
words
or
not
yeah
as
Java
is
to
Guess
that
that
was
the
what
I
was
there.
Thank
you,
I,
don't
know
if
Elixir
is
actually
implemented
in
terms
of
erling
I.
Think
it's
I,
don't
actually
know
that
for
sure,
but
it's
it's
essentially
early
but
nicer
in
in
my
or
nicer
Syntax
for
rubiists
in
a
lot
of
ways,
but
also
has
some
own
interesting
things.
It's
a
cool
language,
laughs.
D
Trying
to
think
of
anything,
that's
like
worth
bringing
up
the
picture
shows
the
modification
since
the
last
time.
This
is
kind
of
like
the
general
idea.
You
have
a
meter
provider
meter
instrument.
An
instrument
will
have
many
metric
streams.
Each
metric
stream
has
an
aggregation.
The
aggregation
right
now
we're
just
doing
like
the
default
set,
but
they
are
technically
configurable.
D
As
you
add
new
metric
readers,
they
get
their
own
metric
stores,
which
will
look
at
all
the
existing
instruments
and
kind
of
create
them
as
needed.
So
you
can
create
your
things
in
all
sorts
of
wacky
and
out
of
order
ways,
and
it
should
continue
to
work.
D
Aggregation
is
basically
the
idea
of
like
how
should
we
accumulate
this
Delta
or
cumulative
I
did
about
add
a
bunch
of
stuff
in
there
to
make
sure
that,
if
you're
doing
cumulative
as
you
export,
your
data,
that's
being
exported,
doesn't
get
mutated.
So
there's
a
lot
of
extra
allocations
there,
which
pains
me,
but
it's
necessary
for
it
to
actually
work
because
that's
how
computers
work
as
far
as
I
understand
the
data
points
are
just
the
simple
data
points
that
get
emitted
out
of
your
hypothetical
hypothetical
exporter.
I've
been
trying
to
keep
this
really
simple.
D
To
reason
about,
because
it's
necessary
for
me
to
be
able
to
do
that.
But
hopefully
it
will
be
easier
for
people
to
contribute
to
as
well
like
I've
looked
at
some
of
the
other
implementations,
and
there
is
a
lot
of
inheritance
and
interaction.
I
found
it
really
really
hard
to
kind
of
piece
together
and
I'm.
So
I'm
doing
my
best
to
avoid
that
in
the
spirit.
If
it's
simpler
to
read
and
if
it
does
need
to
evolve,
it
needs
to
add
some
extra
abstractions
to
make
it
better
cool.
C
I
mean
it
was
a
good
update,
I
think-
and
yes,
please
do
bug
me
for
reviews
I've
been
kind
of
hands
off
for
a
while,
because
I
you
know
just
was
waiting
for
you
to
you
know.
Let
me
know
when
it
was
ready
for
review
again,
but
I
can
definitely
take
another
look.
Yeah
I
think
that
sounds
great
metrics
are
happening.
E
I
think
I
think
there
was
like
a
uncle.
There
was
some
conversation
about
an
issue
that
was
open
with
respect
to
configuration,
options
and
load
order
for
the
auto
instrumentations
and
I.
Don't
know
that
we
resolved
it
it's
kind
of
talking
about
a
way
forward
for
it
and
I.
Don't
know
why
I
can't
find
it
now,
but
Andrew
had
recommended.
Oh
rack
configuration
options
are
ignored,
I'm
curious
about
other
people's
opinions
about
this
one
I'm
gonna
put
it
in
the
agenda.
If
I
can
get
back
to
it,.
A
E
E
So
yeah,
you
know
some
of
the
challenges
that
we
faced
here
is
that,
when
instrumentation,
like
action-packed,
specifically
tries
to
install
the
you
know,
has
an
explicit
dependency
on
the
rack,
instrumentation
yo
yeah
Nick
knows
it
doesn't
have
access
to
any
of
the
the
only
variables
that
it
has
access
to
are
what
the
instrumentation
based
class
knows
about
which
it
can
pull
from
the
environment
variables.
E
E
So,
depending
on
the
order
in
which
you
are
declaring
these
things,
action
pack
will
like
in
in
this
particular
order
that
Nick
pointed
out
here.
If
you
place
action
pack
in
order
first
in
the
collection,
it'll,
look
to
see
that
rack
wasn't
installed
and
it
won't
look
it
up
in
the
configurator
to
say:
hey,
look!
What
programmatic
option
you
know!
Options
were
provided.
E
E
To
a
couple
of
folks
to
Jake
and
Nick,
who
pointed
these
things
out
here
and
I
looked
into
it
a
little
bit
and
was
like,
maybe
this
might
necessary,
necessitate
a
change
of
some
sort,
because
right
now
the
configurator
is
the
only
thing
that
knows
about
those
programmatic
options,
not
the
registry
or
the
instrumentations
themselves.
E
And
so
perhaps
you
know
Andrew
had
suggested.
Perhaps
we
Implement
a
dependency
chain
and
then
instrumentations
are
installed
in
the
order
of
declared
dependencies
as
a
possible
solution,
so
I
kind
of
wanted
to
field
people
out
for
this
one.
We
don't
have
to
dig
into
it
necessarily
here,
but
some
feedback
from
from
you
Robert
in
particular,
would
be
interesting.
E
D
Remember
this
I
remember
like
doing
this
like
this
issue
is
a
result
of
code.
Some
code,
I
wrote
so
I
feel
proud
to
have
some
significance
in
the
world.
It's
I
think
for
me,
like
at
a
high
level
like
we
should
decide
what
the
desired
behavior
is
because
I,
don't
think.
That's
like
I
haven't
read
the
issue
but
like
we
need
to
have
some
concise
like
what
should
it
do
before
we
change
anything
right
like
what.
D
What
do
we
want
to
happen
and
I
know,
there's
some
things
that
we've
been
doing
internally
and
I'm,
not
saying
that
the
open
source
Community
should
reflect
what
we
do.
D
We
can
continue
to
deviate
from
it,
but
right
now,
because
we
have
this
like
opinionated
rapper
gem,
we'll
programmatically,
make
a
bunch
of
decisions
and
we
say
hey.
This
is
opinionated
this
our
opinion
and
we
want
everyone
at
our
company
to
use
it,
but
we
don't
want
them
making
these
calls
to
configure
to
initialize
or
anything
like
that.
We
don't
want
them
to
fuss
around
with
any
of
the
kind
of
open,
Telemetry
boot
code.
We
don't
want
them.
Writing
open
Elementary
code
unless
they're
adding
spans
really
so.
A
D
You
add
an
environment
variable
it'll
supersede
the
programmatic
decisions,
which
I
think
is
probably
not
intuitive
to
the
rest
of
the
world.
I
feel
like.
Usually
you
expect
your
code
to
take
precedence
over
your
environment
variables.
If
you
explicitly
say
do
this
and
it
does
what's
in
your
variable
right,
I,
I,
don't
know
what
the
right
decision
is.
I
know
that
the
decision
for
environment
environment
variables
take
precedence,
has
been
working
for
us,
but
again,
like
I.
Think
one
of
the
hard
parts
of
this
this
entire
issue
isn't
the
changes
required.
E
E
Go
ahead,
if
you
click
that
link
to
that
real,
you
know
to
the
action-packed
railtime
line
13.
in
the
in
the
comment
itself:
Matt
it'll
jump
to
the
install
line.
Specifically
it's
calling
install
without
the
options
that
were
provided
and
that's
because
only
the
configurator
knows
what
those
options
were.
The
registry
is
unaware
of
them
and
the
instrumentation
itself
is
unaware
of
them.
E
D
E
E
So
if
you
declare
action
pack
in
there
with
some
options
and
then
rack
with
some
options,
the
same
problem
will
will
occur
because
action
pack
will
get
installed
first
and
it'll
attempt
to
install
rack,
because
again,
the
problem
is
the
fact
that
the
instrumentation
is
attempting
to
install
things
without
taking
without
you
one
using
the
user-defined
options
and
two
without
considering
the
the
Precedence
there's
nothing
in
there.
That's
sorting
the
installation,
it's
depending
on
the
user,
saying
I'm
declaring
these
things
in
this
specific
order.
C
A
C
C
The
the
simplest
solution,
in
my
mind,
is
just
to
find
a
way
to
determine
the
ordering
of
these
installations,
because,
if
you
are,
if
you
are
explicitly
installing
rack
yourself
and
as
long
as
we
can
sort
of
convince
the
configurator
to
collect
everything
that
should
be
installed
and
wait
until
the
end
to
do
so
and
then
sort
it
according
to
an
ordering
that
could
be
done
in
a
way.
That's
backwards
compatible
and
you
might
even
be
able
to
infer
it
based
on
you
know,
gem,
specs
and
stuff.
C
E
That,
though,
I
I
think
the
problem
is
that
we're
installing
things
from
multiple
places
and
there's
multiple
things
that
know
about
the
configurations
and
I
think
that
the
the
instrumentations
don't
have
a
dependency
on
the
configurator,
which
is
what
knows
about
those
values
and
but
they're,
but
it.
But
it
knows
about
the
registry
and
so
I,
don't
know
that
it
should
be
trying
to
install
things
itself
or
that
we
need
to
have
some
sort
of
I
mean
I.
D
I
just
want
to
like
call
it.
I
was
wondering
why
I
haven't
run
into
this.
Just
like
an
interesting
anecdote.
If
you
use
the
rails
instrumentation,
because
rails
gets
called
after
the
rap,
it
works,
because
rails
also
includes
action-packed
right,
because
I
was
like
I'm
sure
I've
been
using
use
once
and
working
and
I
know
we're
using
action
pack
and
it
is
working.
But
it's
because
we're
not
explicitly
calling
action-pack
we're
explicitly
saying,
use
all
and
we're
including
rails,
not
action-packed,
really
so
rails
gets
called
after
the
rack.
E
No,
no
in
the
in
the
rapper
gem,
it's
probably
declared
alphabetically,
so
rack
comes
from
before
rails
and
Rex
getting
installed
before
rails
gets
installed
and
then
rails
has
at
that
point
it
installs
action-pack,
with
no
options.
Action-Pack
tries
to
install
rack
but
rack's
already
installed.
So
it
does
nothing
oops.
C
So
I
I
have
a
question
and
that
what
if
we
tried
to
solve
this
with
non-technical
means
first,
should
there
be
enhanced
documentation
that
documents
this
sort
of
weird
Corner
case
that
you
could
run
into
and
then
perhaps
even
if
we
could
even
perhaps
log
a
warning
in
the
action-pack
instrumentation
saying
like
or
or
in
the
rack
instrumentation
saying,
oh
look,
you're
trying
to
reinstall
something
that
was
already
installed.
Maybe
you
want
to
change
your
ordering
something
you
know.
Should
we
should
we
try
this
with
just
making
the
the
corner
case
very
explicit?
D
Another
thing
to
like
think
about
too
is
like
this
is
an
issue
because
action-packed
doesn't
do
anything
without
so
it
it's
trying
to
install
the
instrumentation,
but
we
could
say
that,
like
we
can
kind
of
cut
the
tie
there
and
you'd
be
like
yeah,
you
can
still
action
pack.
It
just
won't
do
anything
unless
you
have
the
rack
instrumentation
as
well,
because
it's
it's
literally
just
exists
as
a
means
right
now
to
augment
rack
spans.
That's
that's
kind
of
its
purpose.
Right
now,.
E
E
D
I
mean
we
could
start
gravitating
to
this
world.
We're
kind
of
amused
about
it.
A
bit
in
the
past,
where
it's
like
elasticsearch
is
a
good
example
here,
just
because
it
kind
of
beaten
up
on
it
a
few
times,
there's
interpretation
for
it.
It
looked
just
like
net
HTTP
instrumentation
or
what
have
you
and
I
was
like.
Well,
if
you
add
it,
it's
going
to
create
these
like
two
spans
that
are
like
almost
identical
typing,
with
the
most
identical
attributes.
D
It's
like
well,
you
could
use
elasticsearch
to
augment
the
net
HTTP
instrumentation,
but
what,
if
you
don't
have
it
did
that
HTTP
instrumentation?
For
whatever
reason,
then
it
should
probably
create
its
own
span
right.
So
so,
maybe
maybe
that's
like
the
approach.
Maybe
we
actually
do
go
after
that,
where
it
says
like.
If
I
have
this
enrichable
dependency
installed,
then
do
it
otherwise
I'm
going
to
create
my
own
span,
but
we'd
have
to
be
pretty
sure
that
it's
not
going
to
get
installed
after
and
we
still
kind
of
run
into
that
ordering.
E
Anyway,
I'm
just
putting
it
out
there
to
think
about
a
little
bit
now
that
you've
got
asynchronous
meters
to
think
about
because
yeah
another
thing
I,
don't
know
Andrew,
you
suggested
again
kind
of
like
coming
up
with
a
dependency
tree
and
I
I'm
kind
of
I'm,
still
like
instinctually
leaning
towards
moving
this
functionality
into
the
registry
and
saying
that
the
registry
knows
about
what
the
configuration
options
are
for
specific
instrumentations.
But
you
know
that
creates
a
constraint
on
other
implementations
of
instrumentations.
Also.
E
Are
we
required
to
use
the
registry
of
somebody
who
creates
a
third
party
instrumentation
of
some
sort,
so
just
just
throwing
putting
that
out
there.
C
I
mean
if
they
decide
to
have
inter
instrumentation
dependencies
that
are
important
and
weirdly
acting
in
certain
cases,
then,
yes,
they
might
be
required
to,
but
yeah
I
mean
also.
If
they
we
also
don't
really
have
any
non
-official
instrumentation
yet
or
third
party
instrumentation,
and
even
if
they
did,
they
could
yeah.
Unless
they
also
then
introduced
the
same
kind
of
corner
case
I,
don't
I,
don't
know
I
I,
probably
isn't
the
thing
I
I'm
concerned
about
right
now,
I
guess,
but
I
I
see
what
you're
saying
it
could
happen.
E
Well,
I,
don't
know,
I'd,
be
that
horse
to
death
great
seeing
everybody.
Congratulations
again,
Robert
on
how's,
it's
not
yours
yet
and
I'm
so
excited.
A
E
So
Nicholas,
are
you
gonna,
go
to
rubyconf
I
heard
that
you
did.
You
put
the
the
tickets
in
because,
if
you're
flying
from
across
the
pond
to
come
to
the
United
States
for
a
ruby
comp
and
if.
A
A
Yeah,
so
sorry,
can
you
hear
me
yeah,
okay,
yeah
I
am
actually
going
to
go
to
ruby.com,
so
I
did
get
tickets
to
kubecon
in
October,
but
I
couldn't
get
my
Visa
sorted
in
time.
We
have
like
a
four
month
backlog
in
South
Africa,
so
I
am
going
to
be
rubyconf
in
Houston
Texas
end
of
November,
so
it'll
be
good
to
see
anybody
who's
Keen
to
come
through.
A
D
D
But
my
sister
I
was
staying
in
her
apartment.
She
lives
right
by
the
ocean,
which
sounds
wonderful.
D
She
has
the
shadiest
windows
in
the
world,
so
at
5am
it
was
Mad,
Max,
Fury,
Road,
seagull
Edition
every
single
morning
at
5am,
and
there
was
no
hiding
from
it.
It
was
I
I.
It
was
total
Anarchy
chaos
whatever
like
imagine
loud
bird
settings
or
sounds
and
like
multiply
that
by
the
largest
number
you
can
come
up
with,
and
it
was
that
it
was
just.
It
was
comical
if
it
wasn't
so
upsetting,
like
I
I,
don't
even
I
can't,
as
you
can
see,
I'm
struggling
to
articulate
how
chaotic
was
I
couldn't
believe
it.
A
D
Went
to
Sunrise
Lakes
hiked
up
to
see
the
sky
Train
like
it's,
it's
beautiful
if
you're,
a
sucker
for
the
views
of
mountains
and
oceans
and
lakes
and
all
the
fresh
air,
and
no
bugs
like
Vancouver
North
Vancouver
Whistler,
like
the
Sea
to
Sky
Road,
is
like
awesome.
It's
just
it's
a
lot
of
fun!
I
highly
recommend
it.
E
So,
wonderful
friends,
if
I
don't
see
you
here,
potentially
in
in
November,
October
I,
don't
know,
I,
don't
even
know
when
we'll
be
confident.
If
we
don't
see
each
other
y'all
have
a
great
time
and
or
maybe
not
maybe
I'll
see
you
next
week.
Who
knows
I
gotta
drop
off,
though,
have
fun
guys
cool,
see.