►
From YouTube: 2021-08-10 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
A
A
B
C
I
tried
to
find
it.
I
couldn't,
I
don't
remember,
did
the
spammers
on
the
priority
of
like
environment
variables
versus
configuration
so,
for
example,
if
you've
set
the
service
name
and
then
environment.
E
B
E
But
I
I
did
catch
that
it
was,
did
the
spec
decide
precedence
between
encode
configuration
and
environment,
variable
configuration
and.
E
I
believe
nothing
has
changed
there
and
that
in
code
configuration
will
will
take
precedence.
But,
like
I
haven't,
looked
at
this
for
a
little
bit
and
I
feel
like
I
did
see,
an
issue
come
through
more
recently
kind
of
discussing
this.
E
C
C
I
forgot
where
it
was
settled
for
some
reason
I
thought
I
remember
environment
variables
winning,
but
I
guess
I'm
just
remembering
just
came
across
like
we
have
just
the
context
there
is
we
have
our
configuration
wrapper
and
when
it's
like
rails,
we'll
we'll
pull
the
app
name
from
from
like
rails,
the
module
name
kind
of
thing,
but
there
was
a
team
who
wanted
to
override
it
and
we
don't
really
expose
that
to
them,
and
I
was
like,
oh:
if
the
environment
variable's
supposed
to
win,
then
this
could
be
an
easy
win,
but
that's
fine!
E
I
feel
like
this
is
a
hotly
debated
topic
and
like
yeah,
I
think
if
things
are
the
way
that
they
were,
they
kind
of
are
following
more
of
the
the
12-factor
strategy
which,
basically
you
you
can
have
environment
variables,
be
the
thing
that
wins
out,
but
you
need
to
kind
of
like
omit
encode
configuration
for
that
to
happen.
C
E
E
Best
practices
for
no
code
configuration
which
is
not
exactly
what
you're
asking
for.
I
think
it's
asking
about
full
configuration
by
environment
variables
or
perhaps
configuration
files.
E
All
right
yeah,
this
is
something
I
will
pay
attention
to
and
if
I
find
anything
interesting
there,
I'll
I'll
definitely
bring
it.
B
E
So
yeah
I'll
go
ahead
and
start,
maybe
with
the
spec
sig
update.
Specs
thing
was
pretty
pretty
short.
If
anybody
digs
anything
up
on
configuration,
feel
free
to
yeah
just
speak
up.
If
you
find
anything.
E
There
was
a
reminder
about
these
outstanding
probability:
sampling,
oteps,.
E
But
basically
they're.
E
E
So
there
was
an
earlier
version
of
this
that
was
trying
to
address
the
context
propagation
by
modifying
the
w3c
trace
parent
header
see
we
talked
about
that
a
little
bit
about
it,
not
being
like
a
terrible
idea
by
any
means,
but
being
one
that
is
unlikely
to
like
be
implemented
or
passed
like
at
a
spec
level
like
anytime
soon.
So
the
current
iteration
is
using
trade
state,
which
is
a
place
where,
where
the
stuff
can
be
propagated,.
E
There's
still
a
lot
going
on
around
the
actual
histogram
implementation
for
for
metrics.
I
don't
know
all
the
details,
but
it
has
been
a
hot
topic.
E
I
think
these
next
three
were
the
more
interesting
takeaways
from
this
meeting
and
somewhat
relevant
to
us,
they're
kind
of
like
the.
They
are
a
call
for
three
additional
cigs
to
kind
of
be
be
spun
up.
So
one
is
an
instrumentation
sig,
I
think,
probably
quite
relevant
to
a
lot
of
folks
here.
So
I
think
unofficially,
they've
been
using
like
the
the
4pm
slot
of
the
spec
sig
meeting
for
the
instrumentation
sig.
E
So
they
are,
they
are
actually
trying
to
like
formalize
this
and
and
agree
on
a
time.
It
looks
like.
E
Yeah,
it
looks
like
they
would
probably
actually
replace
this
4pm
tuesday
slot
with
the
with
an
official
kind
of
instrumentation
thing.
E
I
think
there
very
well
could
be
some
logistical
problems
here
in
terms
of
of
overlap
between
this
overlap
between
like
the
content,
I
guess
of
both
of
those
sigs
and
maybe
varying
degrees
of
overlap
between
the
people
that
can
actually
attend
those
sessions,
because
there's
also
a
third
which
is
also
gonna,
have
some
overlap
with
both
of
those
it's
a
messaging
semantic
conventions
praising
working
group.
So
I
feel
like
that,
overlaps
a
lot
with
the
instrumentation
sig
and
definitely
semantic
conventions.
F
Yeah,
I
think
it
would
be
good
to
have
some
overlap
on
direction
with
at
least
messaging.
I
know
there's
a
lot
of
sort
of
like
almost
like
some
follows
from
relationships,
or
some
things
are
it'd
be
nice
to
have
some.
You
know
like
some
things
in
in
tracing
uis
seem
to
be
driven
by
specifically
messaging
semantic
inventions,
whether
you
represent
things
as
a
just
a
request
response,
or
you
have
like
a
sort
of
like
a
a
cue
in
the
middle
in
the
little
diagram
service
flow
map.
F
So
it
would
be
nice
to
have
some
consensus.
E
F
E
E
No,
I
it's
it's
not
entirely
wrong,
but
yeah.
I
think.
E
I
think
I
think,
there's
just
been
like
an
ask
to
review
it
and
speak
now
or
forever
hold
your
peace,
because
it's
been
open
for
a
while.
E
And
then
there
was
there's
a
pr
for
tls
semantic
conventions.
It
does
look
pretty
thorough.
E
E
I
think
the
author
said
this
is
spun
out
of
a
contribution
to
hotel
js.
So
I
think
there
is
probably
an
instrumentation
kind
of
using
this
in
the
wild.
E
Yeah
and
then
there's
a
metrics
update,
the
the
metrics
api
is
stable.
I
think
they
are
still
working
on
aspects
of
the
sdk.
E
B
C
So
this
one
is
like
not
it's
like
a
subtle
detail
that
has,
I
think,
some
interesting
implications,
so
basically
the
rails
instrumentation
as
I
have
it.
This
a
lot
of
stuff
hasn't
been
released
yet
so
it's
kind
of
freely
in
flux.
A
C
So
basically,
the
the
install
here
would
actually
run
the
install
scripts
against
all
that.
We
don't
need
to
look
at
the
code.
I
think,
if
you
just
go
back
to
the
the
main
page
there,
you
can
probably
get
the
interesting
bit
on
the
comments,
just
don't
refresh
because
you
might
lose
it
apparently.
So
what
it
was
doing
is
to
go
through
install
but
naively
I
just
set
it
to
install
like
an
empty
hash.
C
C
But
me
and
andrew
had
a
few
kind
of
back
and
forth
comments
there
and
maybe
the
the
bottom
comment
I
left
there.
C
Let
me
scroll
a
little
bit
further
down
probably
illustrates
like
the
alternate
approach
a
little
bit
so
there's
one
more
to
go
down.
C
C
You'd
have
two
ways
of
doing
this,
so
you
would
pass
through
your
configuration
into
rails
and
you'd
say
this
is
for
action
pack
and
you
give
it
the
same
options
that
you
would
give
action
pack
directly,
but
it
would
have
had
to
like
jump
through
that
layer
going
through
rails,
so
you,
but
this
would
allow
you
to
say,
see,
use
all
or
see
use
like
instrumentation
rails.
C
C
So
this
differs
from
what
I
actually
had
on
this
pr,
where
you
you're
basically
limited
to
using
use
all
but
there's
never
any
level
of
past
these
configuration
options
through
rails
configuration
that
then
gets
passed
down
through
to
like
action,
hacker
action
view.
I
don't
know
if
that
explanation
was
clear,
because
it's
kind
of
awkward.
But
basically
the
question
is
here
like
what?
A
Yeah,
I
was
thinking
about
it
a
little
bit
today
and
and
I'm
not
actually
sure
that
the
alternate
proposal
is
necessarily
any
better.
I
mean
you
know
we're
kind
of
picking
between
two
options
that
are
just
differently
confusing
to
me
in
different
ways
right,
so
I
think
that
that
kind
of
hits
at
the
something
we
talked
about
in
the
comments
which
was
to
some
extent.
This
is
just
we
need
to
write
this
down
a
little
bit
more
clearly
about
how
you're
supposed
to
do
it,
and
then
a
lot
of
our
problems
probably
go
away.
A
I
think
like
when
I
was
thinking
about
this
today.
Two
thoughts
came
to
mind
other
than
documentation,
which
was
first.
What
why
do
we
even
have
use
all?
Why
isn't
that
necessarily
the
default?
It
seems
like.
Maybe
that's
our
sort
of
implied
preference
in
the
repo
is
that
you
should
be
calling
use
all
most
of
the
time
and
then,
if
you
really
don't
want
instrumentation
at
all
period,
like
a
specific
one,
then
you
shouldn't
put
it
in
your
gem
file.
Something
like
that.
A
I
wonder
why
we
don't
necessarily
just
allow
that
to
be
the
default
and
only
you
know
allow
you
to
override
it
with
c
dot
use
instead,
and
the
second
thing
I
was
thinking
about
was
that
if
we
exposed
a
way
to
set
instrumentation
options
independently
of
calling
use
that
might
allow
us
a
bit
more
of
a
flexible
approach
or
an
approach,
that's
more
logically
consistent.
A
Maybe
you
say
here
are
my
instrumentation
options
and
here's
what
I
want
for
all
of
them,
and
then
I
call
c
dot
usal
or
whatever,
and
then
those
options
are
whatever's.
What
is
applied,
but
I
don't
know
if
that's
necessarily
better
either.
C
Yeah,
I
don't
I
don't
really
I'll
be
honest.
I
don't
really
know
the
history
between
the
two
choices
there,
like
I'm
biased
and
that
I
know
how
we've
been
using
it
internally
and
we
we
have
the
wrapper
gem
and
we
include
all
the
ones
that
if
you
have
this
gem,
we
want
it
to
be
instrumented,
so
you
may
not
have
instrumentation
for
it
you
may
whatever,
but
then
we
use
ceus
all
we
pass
in
the
big
configuration
hash.
They
have
it.
C
They
have
it
great,
and
I
like
this
approach
because
it
still
gives
an
application
owner
if
they
choose
like
they
cannot
it's
it's
not
documented,
but
you
can
pass
an
environment
variable
to
disable
instrumentation
like
a
specific
one
or
in
that
case
like
we
could
disable.
Certainly
it
wouldn't
really
make
sense
for
us
in
our
use
case,
because
we
included
that
instrumentation.
Why
would
we
include
it
if
it
wants
to
be
disabled
and
if
it
needs
to
be
disabled
for
one
specific
application
for
some
unforeseen
reason
they
do
have
an
escape
hatch
there.
C
G
So
there's
three
kind
of
use
cases
here.
G
One
is
I
just
pull
in
the
instrumentation
all
gem,
so
I
get
all
the
available
instrumentation,
but
then
I
explicitly
go
in
and
say
I
want
to
use
this
one
this
one
this
one
and
this
one
and
here's
the
configuration
options,
there's
kind
of
the
the
default
approach,
which
is,
let
me
explicitly
list
all
the
instrumentation
that
I
want
to
add
in
my
gem
file
and
then
just
say:
use
all
so
I'll,
just
use
a
default
configuration
or
maybe
environment
variables
to
configure
the
the
instrumentation,
but
I'm
going
to
explicitly
list
the
instrumentation
in
my
my
gem
file
and
then
there's
the
mode
where
I
want
to
do
that.
G
I
want
to
use
all
all
the
instrumentation
that
I
added,
but
I
want
to
override
some
settings
for
certain
things
and
that's
where
you
use
all
with
some
kind
of
configuration
hash.
G
G
I
don't
know
right
where
we're
trying,
like
use
all
kind
of
says,
I'm
using
my
my
gem
file
to
control
which
instrumentation
I'm
pulling
in,
whereas
use
is
saying
I'm
not
using
my
gem
file,
I'm
just
like
relying
on
some
kind
of
auto
detection
to
figure
it
out,
and
then
I'm
explicitly
listing
the
things
in
my
config
block
that
that
I
want
to
actually
use.
G
So
question
is
which
one
is
more
rubyish,
which
one
is
going
to
be
more
common.
What
kind
of
like
do
we
want
to
support
the
all
those
models,
or
do
we
just
want
to
pick
one
and
say
no?
No,
this
is
the
official
one,
the
presence
of
the
all
instrumentation,
like
instrumentation,
all
gem
and
the
convenience
of
using
that,
even
though
we
don't
use
it,
we
use
something
similar
but
like
a
more
curated
list
of
instrumentation
gems.
G
The
convenience
of
that
is
pretty
significant.
I
guess
like
it's,
a
significant
win
for
getting
people
on
board
with
open,
telemetry,
ruby.
G
C
I
guess
when
I
think
about
it,
I
think
of
I'm
reaching
for
instrumentation
all,
and
I
use
all
it's
because
I
just
don't
want
to
think
about
it.
It's
like
my
big
catch
on
that
like
this
is
the
easy
button,
but
then,
when
I
think
of
the
use
case
of
where
I
say,
I
want
instrumentation
all,
but
I
only
want
to
use
these
three
and
that
use
case
to
me
like.
I
understand
why
we
might
want
to
support
it.
C
It
just
seems
strange
it
because
it's
like,
why
am
I
taking
the
whole
like
the
kitchen
and
the
kitchen
sink
and
then
saying,
but
only
give
me
these
three
forks,
like
it's
just
kind
of
weird,
because
the
like
usually
taking
that
approach.
Let's
say
we
hypothetically,
we
took
away
the
the
use
command.
We
just
said
everybody's
using
all
all
the
time,
then
they
would
effectively
have
to
go
through
and
explicitly
write
the
better
through
the
environment
or
through
a
configuration
hash,
disable
all
the
ones
they
don't
want,
which
is
obviously
really
awkward.
C
A
G
Yeah
I
mean
the
the
use
case
is
potentially
that
I'm
getting
like.
I
want
the
convenience
of
instrumentation
all,
but
I'm
getting
all
the
spam,
the
logs
pam
and
I
just
want
to
get
rid
of
it,
which
is
kind
of
a
shitty
reason
to
do
it.
The
the
other
reason
is
a
lot
of
our
documentation.
Does
that
right?
Our
documentation
says,
pull
in
this
gem
dependency
for
that
particular
instrumentation
and
then
configure
it
with
c
dot
use
and
the
name
of
the
instrumentation
in
the
hash.
G
But
you
you're
right.
If
we,
if
we
effectively
got
rid
of
that
mode
and
just
said
use
all
is
default
at
which
point
we
probably
want
to
rename
it
to
use,
then
that's
probably
more
in
line.
Then
we
then
we
have.
F
Sometimes
what's
getting
used
can
depend
on
environment,
so
in
a
test
environment,
if
there's
a
integration
like
r-spec
or
something
they
might
only
want
to,
you
know
enable
the
or
that's
a
you
know
for
certain
environments
in
staging
or
something
they
might
want
to
have
noisier,
instrumentation
or
development,
and
then
production.
Maybe
they
don't
want
some
middleware
spans
or
so
I
don't
know.
I
think
I
think,
there's
no
e.
F
The
answer
is
it
is,
it
depends
and
there's
going
to
be
a
percentage
of
users
who
always
break
a
you
know
like
who
have
a
valid
use
case
for
otherwise
like
stupid
approaches.
So
I
don't
know
I
don't
know
what
to
have
to
ask
for
yeah.
G
I
I
think
the
enabled
false
is
the
way
to
address
disabling
instrumentation,
while
still
using
all.
C
Right
the
way
I
think
about
this
is
like
if
we
were
to
get
rid
of
the
use
keyword,
there
we'd
basically
be
moving
the
opt-in
from
the
configuration
level
to
your
gem
file.
So
you're
saying.
C
It's
also
available
as
a
configuration
option,
so
you'd
be
able
to
you
so
like
your
opt-in
would
exist
at
the
gem
file.
So
this
is
how
you
decide
what
you
opt
into,
but
you
can
opt
out
even
if
it's
in
your
gym
file,
so
you
can
always
opt
out.
If
it's
included
in
your
gem
and
it's
been
configured,
you
can
always
say
disable
and
you
can
disable
it
through
the
environment
variable
or
through
an
explicit
configuration
hash.
F
I
think
what
if
we
add,
so
between
versions
of
package
gets
added
an
instrumentation
gets
added.
Would
the
user
then
need
to
disable,
wouldn't
go
in
and
update
and
add
false?
That
seems,
like
it
possible
a
use
case
right
yeah?
I
don't
know.
If
that's
I
I
guess,
would
they
not
have
included
the
gem
anyway
or
would
that
all
jam
include
it
automatically?
G
A
A
B
E
E
Admittedly,
there
are
like
the
system
does
kind
of
give
you
some
other
escape
hatches
and
yeah.
I
guess.
Ultimately,
I
don't
know
I
was
the
one
who
added
all
these
options,
and
most
of
them
were
just
like
things
that
seemed
like
they
would
be
useful.
E
I
don't
know
that
all
of
them
had
like
real
world
use
cases
so
like
some
of
them
might
still
be
imagined,
and
that's
it's
probably
useful
to
work
out
if
they're,
if
they
are
actually
like
legitimate,
real
world
use
cases
or
if
they're,
just
like
added
complexity,
for
no
real
benefit.
F
A
Going
to
say
robert,
I
think
I
I
think
it's
actually
really
interesting
what
we
might
choose
to
do
in
the
future,
with
like
configuration
options,
and
I
don't
actually
really
know
what
the
right
choice
is
right
now,
but
I
mean
in
terms
of
this
pr,
I
think
what
you
actually
wrote
originally
is
probably
fine.
I
don't
think
it's
actually
that
big
a
deal,
because
that
is
something
we
can
definitely
solve
with
documentation.
A
Any
any
surprises
can
be
easily
right
there
in
the
readme
for
the
rails,
gems,
saying
like
if
you
do
it
this
way,
you'll
need
this
additional
stuff
or
whatever,
and
that's
totally
fine
with
me.
I
don't
think
we.
I
don't
think
we
have
to
block
it
on
reworking
our
config
stuff.
I
know
it's
my
fault.
I
brought
it
up,
but
yeah
like
made
me
think,
like
yeah,
I
think
it's
actually
a
bigger
decision
than
just
this.
You
know.
G
G
I
don't
think
the
nested
configuration
options
is
the
right
way.
I
think
we
should
ideally
have
configuration
options
for
instrumentation
specified
in
one
spot.
The
there
was
one
aspect
of
that
that
I
wanted
to
bring
up
yeah,
so
the
like
nesting.
It
makes
it
easier
to
implement
the
dependencies
because
you
can
just
call
install
and
pass
in
the
hash.
A
A
Why
is
the
configuration
options
so
closely
tied
to
the
use
or
use
all
statement
if
they
weren't
so
closely
tied
if
they
were,
if
we
were
able
to
access
them,
you
know
from
within
the
instrumentation
classes,
somehow
or
or
elsewhere.
I
think
it
actually
gives
us
a
lot
more
flexibility
to
do
something.
That's
more
sensible,
maybe
yeah.
G
Potentially,
instead
of
passing
in
the
hash
to
that
install
fun
or
install
method,
if
the
install
method
could
go
back
and
look
at
the
config
option
and
retrieve
its
configuration,
then
you
wouldn't
even
need
to
pass
down
any
config
options
to
the
dependent
gems.
Instead,
they
would
just
be
going
back
to
the
config
object
and
looking
up
their
configuration.
A
Right
because
then
the
rails
gem
could
install
all
of
its
dependencies
and
the
configuration
already
specified
elsewhere
would
in
fact
control
their
options
and
whether
or
not
they're
enabled-
and
I
think
that
makes
it
easier
for
rapper
authors
to
to
it-
gives
them
a
way
to
say.
Like
here's,
our
static
set
of
configurations
and
and
let
you
know,
I
don't.
F
Know
it's
our
number
one
ruby
on
boarding
like
support
ticket
or
one
of
them,
is
people
getting
confused
on
nested
there's.
No.
The
conventions
for
data
dogs
configuration
block
are
very
bad
in
that,
u
it's
like,
doesn't
even
it's
not.
It
won't
be
like
specific
to
like
active
record
as
a
you
know,
sub
instrumentation
or
whatever
it
just
like
says.
There's
like
some
phrase
like
can
I
don't
know
like
database
name
or
something,
and
so
but
it's
incomplete.
F
It
doesn't
work
for
all
the
subjects
so
like
it's
better
to
just
keep
it
separate
and
or
sometimes
there
will
be
like
the
right
configuration
in
the
rails,
like
nested
block
and
then
later
also
have
conflicting
configuration
in
you
know.
They'll
also
add
active
record.
You
know
that
and
there's
conflicts
and
people
get
confused
so
like
having
one
source
of
truth
and
just
you
know
letting
documentation
solve
our
problems,
I
think
is,
will
be
a
lower
headache.
Long
term
yeah.
E
I'm
just
curious
if
the
proposal
here
is
more
or
less
just
to
kind
of
have
like
an
accessor
for
config
on
like
instrumentation
base,
so
that
so
that,
if
something
does
kind
of
wire
up
like
a
handful
of
instrumentation,
that
it
at
least
has
access
to
that,
so
that
you
can
kind
of,
you
can
still
use
this
kind
of
flattened
structure
that
we
have
kind
of
for
as
yeah
as
using
these
all
works
today.
C
Yeah,
I
think
it
becomes
part
of
like
the
instrumentation
registry,
I
think,
like
you
registered
instrumentation,
and
then
also
you
can
register
the
configuration
for
it.
Then
anyone
who
installs
it
will
just
use
that
what's
provided
there.
I
think
it
probably
will
still
need
potentially
some
room
for
I
don't
know.
Actually
I
don't
know
I
need
to
take
a
bunch
of
it
more
because
I
feel
like
maybe
they're
still.
I
means
for
like
overriding
stuff,
but
I
don't
know
why
that
would
come
up,
but.
A
C
Actually,
I
don't
know
where,
like
the
split
happens,
is
like
you,
yeah
in
your
configurator,
you
have
a
separate
thing
for
passing
in
your
full
configuration
hash
for
all
the
gems
you
care
about
and
then
whether
you
use
use
or
use
all
if
you
use
use,
if
only
use
the
ones
you've
specified
directly
and
it'll.
Look
up
the
configuration
from
that
set
separate
kind
of
past
and
value.
If
you
use
use
all
it'll,
just
look
up
anything,
that's
present
there.
C
A
Yeah,
which
is
fun
I
mean
if
we,
if
you
it
depends
on
how
you
set
it
up,
but
I
think
it
certainly
could
be
pretty
simple.
We
if
we
allow
it,
you
know
the
it's
a
hash
right.
If
we
allow
the
keys
to
be
the
instrumentation
class
names
and
the
values
to
be
whatever
options
they
accept,
and
then
you
know,
then
it's
it's
a
I
mean
it
may
be
spread
across
multiple
lines.
A
A
G
Yeah,
I
think
that
sounds
good
a
you.
You
may
want
to
address
the
use
case
of
what,
if
somebody
wants
to
support
providing
their
instrumentation
configurations
like
a
yaml
file
right,
that's
going
to
be
somebody's
going
to
want
to
do
that.
It's
a
matter
of
time!
Do
we
have
any
support
for
that
today,
because
I
don't
think
we
really
do
yet
no,
but
it
would
be
pretty
easy
to
build
with
the
use
all
thing
because
you're
just
ultimately
getting
a
hash,
a
single
large
hash
that
you
pass
in.
So
that's
true,
yeah.
C
Something
else
that
I've
been
thinking
about
doing,
but
haven't
really
done.
I
think
I've
mentioned
it
before
really
briefly,
but
I
don't
know
if
we
should
wait
for
respect
for
it,
but
I
think
it
would
make
a
lot
of
sense
to
allow
a
lot
of
this
configuration
of
instrumentation
to
be
done
through
environment
variables.
We
already
allow
it
to
be
disabled
yeah.
We
definitely
I
I
yeah.
C
I
think
because,
like
I'm
thinking
of
our
use
case
of
it
and
like
how
we
deploy
open
commentary
at
shopify-
and
I
can
see
a
lot
of
value
there,
if
a
specific
team
wants
to,
for
example,
enable
or
disable
database
confiscation,
because
we
we
provide
this
opinionated
set
of
configuration,
it
would
be
really
nice
to
let
a
team
have
their
own
kind
of
one-off
escape
patch,
where
they
can
just
say.
C
You
know,
for
this
particular
thing
I
would
like
for
it
to
behave
differently
and
and
that's
okay
like
we
give
them
that
power,
and
I
think
that
probably
could
find
some
broader
use
in
the
community
as
well
like
there's
a
lot
of
application
owners
out
there.
I'm
sure
that
want
to
do
all
their
configuration
through
environment
variables.
That's
fine.
A
G
So
one
of
the
things
that
we
use
callables
for
a
lot
is
multi-valued,
so
basically
enums.
It
would
be
really
nice
if
we
had
cleaner
support
for
enums.
So
you
didn't
have
to
use
the
quotable
approach
for
those.
It's
just
such
a
common
thing
that
we
want
to
do,
and
I
think
it's
going
to
become
increasingly
common,
that
having
direct
support,
free
nums
would
be
nice.
G
A
G
Really
come
with
and
come
up
with
any
concrete
suggestions
for
improvements,
but
now
it
does
sound
like
we
have
a
bunch
of
concrete
suggestions
for
improvements.
One
well
a
few
questions
about
that.
One
is:
should
we
address
each
of
these
with
a
separate
issue,
or
should
we
try
to
tackle
all
of
them
at
once?
G
Should
we
delay
the
1.0
release
until
we
somehow
perfect
the
sdk
configuration,
or
should
we
just
proceed
with
it,
as
is,
and
somehow
make
it
clear
that
the
sdk
configuration
mechanism
may
evolve
in
future
releases
and
kind
of
a
middle
thing
is:
is
there
stuff
that
we
definitely
want
to
improve
to
configuration
before
1.0
or
do
we
just
want
to
completely
decouple
1.0
and
configuration
changes.
A
I
worry
that
if
we
block
1.0
on
it
we're
never
going
to
release
the
1.0,
that's
my
main
thought
and
I
think
that
what
we
have
today
is
pretty
workable,
so
I
think
it's
okay
to
go
on.
I
would
also
say
we
should
do
separate
issues
for
these,
because
I
think
some
of
these
ideas
could
be
worked
on
in
parallel.
They
don't
all
depend
on
each
other,
yep
I'll,
open
at
least
one
or
two
issues.
A
In
the
background
here
at
least
like
the
the
enums
one,
for
example,
could
be
like
a
good
first
issue
sort
of
thing.
You
know
it
doesn't
seem
terribly
terribly
difficult.
Yeah,
I
don't
wanna.
I
don't
think
I'd
wanna
block
the
1.0
release
on
it.
I
think
the
most
important
consideration
there
is.
Can
we
do
it
in
a
way?
That's
backwards,
compatible
with
how
you
configure
things
today,
and
I
think
the
answer
is
probably
yes
for
all
cases.
A
G
C
Cool,
so
I
don't
think
we
should
yeah,
I
was
just
gonna
say
like
support
for
not
blocking
it,
and
I
think
we
like
a
while
back.
We
talked
about
like
the
instrumentation
based
industry
was
kind
of
apart
from
the
sdk
and
the
api,
and
so
it
said
it
wouldn't
necessarily
kind
of
get
locked.
It
was
more
coupled
with
this
condition.
I
know
it's
in
that
gray
area
so
like
I,
it
does
impact
like
the
api
for
the
sdk
yeah.
C
C
E
E
I
think
the
idea
behind
this
all
is
like
it
is
pretty
simple.
It's
ultimately,
it's
just
a
hash
like
as
long
as
you
can
provide
configuration,
the
name
of
the
thing
that
you're
configuring
and
then
keys
and
values
for
the
things
that
you're
configuring
on
that,
then,
generally
it
all
kind
of
works
out.
So
whether
the
hash
is
coming
from
in
code
config,
you
know
yaml
or
some
clever
way,
to
kind
of
hash
by
environment
variables,
some
convention
around
environment
variables
that
you
can
turn
those
into
a
hash.
C
That
was
my
big
topic
for
the
day.
This
is
more
for,
for
I'm
just
going
to
drop
it
in
the
chat
here.
Last
week
we
talked
a
little
bit
about,
or
just
like
briefly
beginning
the
college
cycle
profiling
and
like
tracking
allocations.
Someone
internally
company
has
been
working
on
a
gem.
I
don't
know
if
it's
public
or
not,
but
it
detracts
allocations
and
he
has
been
making
some
changes
there,
but
he's
hoping
that
he
can
upstream
some
changes
to
ruby
itself.
C
So
we
won't
need
a
separate
gem
to
do
that,
so
that
might
at
least
take
your
curiosity
of
it.
I
think
he
has
like
a
whip
at
the
bottom
of
that
email,
but
it's
just
yeah
not
necessarily
super
relevant
to
what
we're
working
on,
but
those
relevant
to
last
week's
little
chat.
There.
E
Yes,
I'm
actually
aware
of
this-
I
I
know
jason.
I
work
with
him,
he's
an
awesome
guy
and
yeah
like
he.
He
said
this
a
number
of
years
ago
and
it's
cool
actually
to
see
that
somebody
else
has
found
this
and
is
like
he's
interested
in
it.
C
Yeah
so
yeah
started
sure
that's
kind
of
neat,
so
john
is
putting
up
like
a
pr
to
try
to
hopefully
get
some
stuff
there
upstream,
because
I
think
some
of
the
things
are
already
available
in
jruby
and
for
four
years
so.
G
G
I'm
not
sure
when
it
was
added.
I
suspect
it
was
added
to
jruby
and
truffle
ruby.
Just
picked
it
up
from
back
in
the
days
when
truffle
ruby
was
kind
of
posted
under
jay
ruby
yeah.
So
I
I
do
think
it's
been
there
for
a
little
while
john
was
not
aware
of
it,
and
somebody
internal
pointed
him
at
like
somebody
who
was,
I
guess,
working
on
truffle
ruby
pointed
in
at
their
support.
So
I
think
it
was
tenderlove.
F
C
C
Yeah
but
other
than
that,
I
don't
think
I
I
don't
think
I
have
anything.
I
do
want
to
try
to
get
that
rails.
Pr
in
that
that
we
were
just
discussing
keeping
in
mind
the
consideration
of
the
future
changes
that
will
be
coming
in.
I
think
it's
probably
in
a
reviewable
state
or
should
be
a
real
estate.
I
made
some
thought
changes
to
craft
some
docs
around
it.
It's
mostly
just
changing
documentation
and
deleting
a
couple
lines
of
code
yeah.
C
We
we
have
a
few
changes
that
have
come
in
recently
on
like
database
statements,
making
things
a
little
bit
more
consistent.
C
Francis
made
a
good
suggestion
that
we
should
probably
add
just
like
built-in
support
for
adding
or
deprecating
configuration
operator
options.
I
think
that
would
be
really
nice,
but
once
this
rails
pr
gets
in,
I
would
like
to
go
for
a
release,
the
rails,
car
and
then
the
the
last
database
statement.
Pr,
I
think,
there's
one
more
one
or
two
more,
but
then
I
would
like
to
make
a
release.
Unless
someone
has
any
reason
I
should
not
or
if
I
should
wait
to
get
anything
else
and.
G
C
Right,
it
doesn't
have
to
wait.
It's
just
I'm
planning
on
just
doing
a
big,
lock,
step
release
like
not
block
step,
but
a
big
kind
of
a
big
bang,
release
of
everything
across
the
board,
and
I
don't
want
to
release
rails
and
it's
changing.
Yeah.
Okay,.
A
A
For
it,
I
will
be
happy
to
stand
for
rails
pr
momentarily.
I
think
it's
fine,
I
don't
think
there's
anything
I
know
of
that
needs
to
wait
I'll,
probably
throw
up
a
quick
pr
for
updating
the
semantic
conventions.
Again
they
had
another
release,
but
that's
not
that
important.
I
don't
think
there's
anything
that
really
affects
us
other
pr's.
A
The
only
thing
I
was
going
to
bring
up
is
that
if
anyone
has
a
big
grpc
installation
and
can
test
the
pr
I
put
up,
I'm
going
to
refactor
it
a
bit
to
do
some
other
things,
but
it
is
workable,
as
is
it's
miserable
to
look
at
the
code,
I
don't
suggest
it,
but
if
anyone
had
like
I
just
I
don't
have
access
to
any
sort
of
installation.
A
C
I
think
we
do
have
some
use
of
it,
but
I
have
to
look
because
I
think
the
there's
a
gem
internally
that
does
depend
on
grpc.
It
does
use
it
for
its
communication,
but
I
think
what
they
did
is
they
actually
added
first-party
instrumentation
to
the
gem
itself,
so
because
this
is
for
auto
instrumentation
right.
C
G
Yeah
one
thing
I
noticed
I
was
away
last
week,
so
I
was
just
catching
up
yesterday
and
today,
but
I
noticed
that
the
port
has
changed
for
otlp
http
didn't.
G
F
G
They've
they've
had
long-standing
issues
supporting
grpc
and
http
on
the
same
port
in
the
collector
and,
like
that's,
been
batted
around,
for
I
think
well,
over
a
year,
and
eventually
they
settled
on.
You
know
what
let's
just
split
the
ports
at
which
point
that
probably
brought
out
a
whole
bunch
of
people
from
the
woodwork
to
say
yep.
F
F
But
it's
not
so
the
the
revert
hasn't
certainly
hasn't
been
approved
of,
but
it
seems
like
it
might,
because
the
guy
seemed
to
really
know
it.
He
seemed
really
good
to
go.
So
I
don't
know
how
you
say.
Basically
in
the
collective
meeting,
everyone
was
like
it
sounds
reasonable,
but
we'll
have
to
look
at
the
code.
So
revert
was
merged
in
the
spec.
F
G
Okay,
I
don't
think
I
had
anything
else.
I
wanted
to
discuss.
G
The
only
thing
blocking
is
the
versioning
document.
I
think.
G
Cool
it
should
be
relatively
easy
to
put
something
together
for
this.
I
think
the
js1
is
pretty
brief
and
just
points
back
at
the
the
document
in
the
spec
repo.
G
We
can
do
that
or
we
can
go
and
like
daniel,
had
put
together
a
pretty
extensive
google
doc.
That
could
just
be
translated
to
mark
down
and
added
as
our
versioning
instability
doc.
But
it
depends
whether
anybody
has
a
bandwidth
to
read,
understand
and
translate
that
versus
just
doing
the
simple
thing.
A
Yeah
I
mean
if
we
don't
I'll
I'll
read
through
it.
I
have
bandwidth
today,
I'm
not
really
doing
anything.
So
I
will
take
a
look
at
that
and
see
if
there's
anything
that
like
looks
reasonable
to
or
looks
like
see
if
there's
anything
above
and
beyond
the
general,
you
know
spec
level
stability
guarantees
that
we
need
to
have
differently.