►
From YouTube: 2022-01-25 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
B
C
Some
of
us
at
lightstep
have
been
using
this
extension
called
clockwise
to
help
manage
our
calendars,
and
we
discovered
this
week
that
it's
been
causing
chaos
for
us
and
creating
a
bunch
of
like
copied
meetings
for
us
on
our
calendars.
If
you
use
clockwise,
you
should
check
into
that.
D
D
C
Hi
I
put
together
a
little
bit
of
a
presentation-
I'm
I
wasn't
coordinating
with
riley,
though
so
maybe
one
both
of
us
have
a
little
bit
of
an
update.
I
have
been
working
on
triaging
our
issues
and
updating
the
board.
I'm
going
to
share
my
screen
and
show
you
what
I
got.
C
Okay,
here
we
are
in
the
notes.
Okay,
I
we'll
pull
up
the
project
board.
I
made
some
edits
yesterday
to
this
board,
because
I
was
looking
through
current
issues
that
we
are
working
on
if
you
came
to,
if
you
don't
remember
the
way
this
was
a
couple
few
weeks
ago,
the
the
big
item
we've
been
paused
on
is
marking
the
metrics
sdk
as
mixed
stable.
C
That
we
kind
of
didn't
didn't
agree
to
that
at
the
sort
of
last
minute
in
december,
and
a
few
issues
have
been
lingering
since
then
one
of
them
is
meter
and
instrument,
identity.
We've
talked
about
that
at
least
two
weeks
or
two
meetings
in
a
row
here
and
the
other
exemplar
is
being
enabled
by
default.
I
think
we've
basically
resolved
on
that
one
I'll
get
back
to
that
one.
C
I
want
to
talk
about
what
I
see
as
three
lingering
issues
that
are
all
interconnected
and
see
if
we
can
get
some
opinions
out
on
them.
Hey,
hey
josh,.
D
D
That's
not
a
blocker
for
the
stable
release
and-
and
I
suggest
that
we
use
the
similar
thing
like
we
really
focus
on
getting
the
initial
stable
release.
My
point
is:
we
couldn't
get
the
initial
stable
release.
Of
course
there
will
be
more
clarification,
questions
similar
like
the
the
tracing
api.
We
like,
we
still
see
like
a
new
additions
to
the
api
spec,
but
it
doesn't
necessarily
block
any
of
the
stability.
C
Yeah,
thank
you.
I
was
gonna.
Have
a
brief
talk
about
exemplars
after
this
other
stuff.
But
yes,
I
agree
with
you.
So,
just
to
summarize,
we
think
with
exam
cars
that
we
would
get
to
a
ga
release,
the
famous
1.0
and
have
exemplars
be
off
by
default,
with
a
a
very
clear
indication
that
this
is
going
to
change
in
the
very
soon
afterwards
to
be
on
by
default
that
we
that's
what
we
think
or
expect
to
happen.
Would
that
is
that
what
you're
saying
I
agree?
C
Okay,
so
got
thumbs
up
from
riley
there,
I'm
going
to
continue
now
summarizing
these
other
three
issues
that
are
on
the
plate,
and
I
think
that
we
can
find
a
way
around
them.
So
I
will
give
you
my
my
opinions
here.
So
it
starts
with
meter
and
instrument
identity,
and
that
has
a
linked
pull
request
that
I
myself
wrote
in
after
volunteering
after
one
of
these
meetings
in
prior
weeks.
C
So
so
there's
that
and
people
have
started
looking
at
that
and
giving
me
a
few
bits
of
feedback
and
what
it
discussed,
what
we
discovered
as
we
were
doing,
that
was
sort
of
connected
issues.
So
now
I'm
going
to
walk
into
a
a
little
summary
and
then
I'm
going
to
give
you
an
example
to
motivate
this.
C
So
I
myself,
working
in,
go
sdk
have
been
trying
to
finalize
our
api
and
the
questions
have
been
coming
up
around
asynchronous
instruments
and
they're
definitely
connected
with
these
questions
about
meter
and
instrument
identity
because
the
question
always
comes
down
to
even
if
we
can
explain
what
to
do
with
duplicate
instruments.
What
do
we
do
with
duplicate
callbacks?
C
So
there's
basically
a
is
a
decision
that
has
to
be
made
about
how
to
think
about
duplicate,
callbacks
and
what
to
do
about
them
and
it
comes
down
to
what
the
users
think
and
what
is
easy
and
what's
convenient
for
them.
So
I've
made
a
proposal
here
that
we
basically
embrace
the
idea
of
multiple
callbacks
and
embrace
the
idea
that
these
callbacks
can
be
one-to-many
with
instruments,
because
we
have
real
use
cases
and
performance
needs
in
that
area.
C
So
this
is
a
very
light,
very,
very
brief,
relaxing
of
the
spec
that
I've
got
proposed
and
then
I
want.
I
picked
up
one
more
issue
here,
that's
connected
with
that
and
there's
no
connected
linked
pr
on
this
one
yet,
but
it
would
be
very
easy
to
make
one,
and
so
I'm
gonna
now
try
and
link
these
all
together
with
a
motivating
example
daniel.
You
have
your
question
your
hand
up
I'd
like
you
to
ask
your
question.
First,.
E
Yeah
for
the
the
one-to-many
callbacks.
Are
you
referring
to
this
same
exact
callback
used
in
two
different
instruments
or
one
instrument
with
two
callbacks
registered.
C
I
am
referring
to
this
the
latter
of
those
examples,
and
we
do
need
to
be
very
careful
about
what
we're
saying
I,
I
don't
think
of
callbacks
as
having
we'll
see
the
the
proposal
that
I'm
making
is
to
consider
callbacks
to
be
the
thing
of
that.
We
count
and
have
identity
when
we're
talking
about
registration
with
the
meter.
C
So
you
can
register
the
same
instrument
as
many
times
as
you
like,
because
they're
the
same
instrument
as
long
as
they're
the
same
duplicate
registrations,
but
every
callback
is
unique
and
every
callback
will
be
called
is
what
I'm
is.
What
I'm
going
to
propose
here,
because
it
solves
our
problems,
and
I
do
have
a
motivating
example
to
help
jess.
C
Just
now
and
and
the
reason
that
I
like
put
this
issue
here-
number
22
32
into
the
kind
of
to-do
list,
and-
and
I
think
it
is
elevated
to
a
kind
of
connection
with
these
instrument.
Identity
questions
is
that,
once
you
begin
having
multiple
callbacks,
you
begin
asking.
What
do
I
do
when
I
don't
want
to
use
this
callback
anymore,
which
is
equivalent
to
what
do
I
do
when
I
don't
want
to
use
this
instrument
anymore
in
a
world
before
you
had
multiple
callbacks?
C
Okay,
I
I
do
want
to
now
give
you
this.
Like
brief
kind
of
presentation.
Can
you
see
my
slide
that
I'm
now
pushing
up?
So
this
is
a
little
informal
slide
deck,
I'm
just
going
to
like
sweep
sweep
through
it
here
to
try
and
explain
why
I'm
thinking
about
this?
The
way
I
am
so
the
the
motivating
example
I
have
for
here
here
is
entirely
based
on
asynchronous
instruments,
because
those
are
the
ones
that
are
causing
us
questions
here,
although
at
the
end
I
have
a
note
to
get
back
to
synchronous
instruments.
C
So
for
this
I'm
imagining
a
a
like
a
worker
architecture
where
these
horizontally
skilled
workers
they're
just
identical
to
each
other.
They
start
up
and
they
ask
that
some
central
service.
What
are
my
jobs
or
tasks
that
I'm
going
to
be
processing
and
there's
those
are
called
partitions.
There's
some
large
job
and
they've
been
partitioned
into
small
jobs.
So
now
this
worker
is
going
to
start
up
and
just
pick
some
of
them
and
start
working.
C
This
is
a
fairly
common
architecture
around
the
internet.
I
believe
at
least
I've
seen
it
a
few
times,
so
this
is
now
like
a
picture
of
a
system
that
I've
got
two
workers
and
three
and
three
partitions
for
each
worker
and
I'm
going
to
show
you
a
little
bit
more
on
the
next
slide
about
how
each
of
those
workers
has
four
metrics
each
all
of
them
asynchronous.
So
now
I've
got
a
situation
where
there
are
24
time
series,
two
processes,
three
partitions,
each
worker
and
four
metrics
for
each
partition.
Riley.
C
I'd
be
glad
to
sure
okay,
so
I'm
going
to
keep
going.
So
this
is
just
an
example
of
the
layout
I'm
imagining
here.
So
this
is
now
a
kind
of
picture
of
the
instrumentation
library.
Its
name
and
version
are
known.
Partitions
is
like
a
library
of
code
that
I've
written,
let's
say,
and
it's
version
is
1.0.
C
I'm
just
trying
to
show
you.
This
is
an
instrumentation
library,
so
I've
got
one
meter
now
and
I've
instantiated
this
once
well.
This
is
the
question
now.
Do
I
want
to
instantiate
my
instrumentation
library
once
per
partition
object,
or
do
I
want
to
instantiate
it
once
and
have
my
instrumentation
library
know
about
all
the
partition
objects?
C
This
gets
down
to
the
question
about
callbacks
directly,
so
this
is
like
the
first
example
I
might
have
written
if
I
was
forced
to
use
one
callback
and
the
users
are
telling
us
the
feedback
for
these
issues,
that
this
is
a
bad
pattern
and
I
want
to
show
you
this
is
a
bad
pattern.
It
also
hurts
concurrency.
It
forces
the
callback
to
deal
with
concurrency
in
a
way
that
affects
the
user
programming,
and
I
don't
want
to
take
this
lock.
C
C
So
this
pattern
smells
really
bad
to
me
and
if
I
want
to
have
to
work
around
this
by
like
working
around
locking,
I'm
just
pushing
that
complexity
somewhere
else
and
the
point
is,
there
is
complexity
to
keep
track
of
things
that
are
like
coming
and
going,
but
we
can
have
the
sdk
manage
that,
so
I'm
now
imagining
a
constructor
for
my
partitions
object
where,
instead
of
having
one
partitions
library,
know
about
every
partition,
I
just
instantiate
the
instrumentation
library
again
and
again,
once
per
partition
object.
C
So
at
the
beginning
of
my
new
partition
constructor
I
construct.
I
get
my
sorry
back
to
that.
I
get
my
meter
provider.
I
start
I
start
with
a
meter
provider.
I
get
my
meter,
I
create
four
instruments
and
I'm
this
is
going
to
be
duplicate.
If
there's
another
partition
running
in
my
my
process,
that's
that's
they're
the
same
instrument,
because
it's
the
same
instrumentation
library
being
instantiated
again
so
then
I
create
my
partition
object
and
I
start
calling
creating
callbacks
and
the
point
here
is
in
this
model.
I'm
now
describing
to
you.
C
So
then,
inside
my
my
callback,
I
would
make
observations
about
exactly
one
partition
and
then
be
done,
and
then
the
result
of
this
is
that
the
the
sdk
is
going
to
have
one
callback
per
live
partition.
Okay-
and
this
leaves
us
with
a
question
about
what
happens
when
you
want
to
shut
down
your
partition
and
I'm
pointing
back
to
this
issue
about
unregistering
instruments
and
or
unregistering
callbacks.
I
could
find
a
way
to
disable
a
callback
by
just
milling
it
out
or
like
I
see
that
my
partition
has
been
shut
down.
C
I
am
now
a
dead
callback.
I
will
return
without
making
any
observations,
but
the
users
are
just
going
to
come
begging
for
a
way
to
like
literally
disable
this
callback
and
tell
the
sdk
to
stop
using
it.
So
we've
seen
these
requests
prometheus
has
this
and
I
don't
want
to
go
too
far
into
how
prometheus's
data
model
is
impacted
here,
but
I
have
to
this
is
actually
pretty
important
data
model
question
now.
So
the
question
is:
what
happens
if
I
had
a
partition
move?
C
Well,
if
I'm
crashing,
the
situation
is
pretty
simple,
because
when
you
crash,
like
all
the
series
die
and
you
have
to
start
them
all
over
again
and
there's
no
risk
of
overlap
and
there's
not
really
much
ambiguity
like
at
the
moment
of
handoff,
I
crash.
So
all
the
stairs
stop.
I
started
a
bunch
of
new
partitions
on
a
bunch
of
new
workers
that
one's
straightforward.
C
But
what
happens
if
you
decide
to
find
a
way
to
decommission,
live
partitions,
so
you're
going
to
say
I
want
to
take
this
partition
off
of
that
worker,
shut
it
down
and
open
this
partition
on
that
worker
and
now
what
I
expect
to
happen
is
that
I'm
going
to
stop
reporting
those
metrics
on
one
machine.
Wait
till
it
starts
up
again
and
start
recording
those
metrics
on
another
machine
and
prometheus
has
a
has,
has
a
problem
with
this,
and
they
have
a
solution
which
is
called
this
delete
method.
C
C
It
causes
too
much
trouble
so
to
avoid
breaking
the
single
writer
rule
either
we
have
to
stop
find
a
way
to
stop
reporting
prior
data
from
the
original
worker,
or
we
have
to
find
a
way
to
really
embrace
these
overlaps
and
just
let
them
keep
going
and
and
that
this
is
now
coming
down
to
a
data
model
question,
and
I
think
I've
probably
worn
you
out
with
words.
I'm
going
to
pass
this
back
to
the
group
before
I've
before
long.
The
question
is
so.
C
Let
me
give
you
a
simpler
example:
that's
not
so
complicated
as
my
work
example
suppose
I'm
just
a
single
prometheus
sdk
and
I
am
going
to
export
one
gauge
well,
prometheus
doesn't
have
actually
previous
does
have
a
way
to
do
asynchronous
type
instruments,
but
it's
not
very
formalized
the
way
we've
done
so
in
your
prometheus.
Let's
just
say:
straightforward.
You've
got
this
use
of
a
synchronous
gauge
and
you
inside
of
some
handler,
you
set
it.
You
set
the
gauge.
C
C
When
an
application
stops
reporting
a
metric,
does
the
sdk
have
to
remember
it,
and
this
question
can
be
different
for
stickers
and
asynchronous
instruments
for
for
the
synchronous
instruments.
I've
just
described
how
prometheus
handles
it
and
if
you're
a
cumulative
exporter,
you
might
just
assume
that
you
must
have
memory
because
of
the
nature
of
being
a
cumulative
exporter.
C
So
we
might
not
actually
need
an
option
here
to
say
when
I
stop
reporting,
please
stop
sending
metrics,
because
if
it's
cumulative,
that's
never
the
right
thing
to
do,
but
if
you're
pushing
your
metrics
and
you
stop
producing
a
date,
a
piece
of
data.
When
do
you
stop
sending
that
to
the
server?
And
I
think
that
there
there
you
can
have
an
option,
so
you
might
say
to
the
synchronous
instruments
after
you
stop
reporting
for
an
interval.
C
If
you
are
no
longer
seen
again,
you
are
gone
forever,
so
this
could
be
useful
in
a
high
cardinality
setting.
So
we
might
want
to
be
able
to
control
whether
there's
memory
I'm
raising
this
question,
as
does
the
view
need
to
be
able
to
control
its
own
memory
because
prometheus
needs
memory
and
an
otlp
exporter.
Doing
push
does
not
need
memory.
C
So
there's
a
question
there
and
it
comes
back
to
asynchronous
instruments
now
and
it
seemed
like
a
diversion,
but
I'm
back
in
asynchronous
instruments,
which
is
because,
if
you're
an
asynchronous
instrument,
I
don't
think
you
need
memory,
but
there's
kind
of
an
implementation
reason
why
it's
useful-
and
I
and
it's
just
in
the
depths
of
this
situation
here,
but
I'll,
try
and
get
out
of
my
like
the
whole
web
doug
is
that
if
the
asynchronous
instrument
must
always
generate
its
full
set
of
observations,
then
you
only
need
to
remember
the
prior
window
of
state
and
you
can
detect
when,
when
time
series
go
missing
and
questions
have
come
up
about
how
to
do
views
over
asynchronous
instruments
and
this
question
about
whether
an
instrument,
whether
an
observation
can
go
missing
or
not
impacts
correctness.
C
I
put
a
link
here
and
I
I'm
gonna,
now
return
to
the
meeting
notes
and
and
wrap
up
my
my
my
monologue
here
and
let
you
all
ask
questions
so
back
in
the
meeting
notes.
I've
now
linked
I've.
I
ran
through
my
presentation
with
my
example:
I've
linked
the
three
issues
below
meter
and
instrument,
identity,
enable
multi-instrument
callbacks
and
allow
unregistered
destroy
instruments
which
I
want
to
be
callbacks
and
finally,
this
link
to
a
passage
that
we
already
merged.
C
I
want
to
link
that
before
I,
let
you
all
ask
me
questions
because
it
it's
relevant.
We
put
this.
There
was
a
question
filed
a
month
ago.
How
do
you
calculate
an
asynchronous
view
and
the
question
is
when
you're
removing
attributes,
there's
some
correctness,
questions
and
they
do
relate
again
to
whether
asynchronous
instruments
have
memory
or
not?
Okay,
I
it's
too
complicated
to
summarize
at
this
point,
but
I
I
return
it
to
you.
Tigran,
you
have
your
hand
up
and
then
I
know
riley
had
a
question
afterwards
or.
A
C
That
I
meant
library
name
in
in
my
example,
so
that
they
would
be
identical
copies
of
instrumentation
library
for
each
partition.
A
C
I
mean
okay
go
back
there,
okay
yeah
it.
I
I
mean
I
I
passed.
I
think
I
passed
a
quoted
string
partitions
and
that's
what
I
meant
to
so
that
every
I
could
have
put
a
you
know.
Qualifier,
like
you
know,
partitions.org
fancy
partition
library
is
what
I
meant,
but
they're
all
the
same.
Instrumentation
library.
C
And,
and
in
my
example,
I
stumbled
over
the
kind
of
desire
to
have
static
attributes
at
the
instrumentation
library
level,
like
every
metric
inside.
My
instrumentation
library,
in
this
example,
has
a
partition
attribute,
which
is
the
same
as
every
other.
It's
not
the
same
as
the
resource,
because
it's
scoped
to
an
instrumentation
library,
but
I
did
not
want
to
talk
about
that.
D
Riley
your
hands
up
as
well,
so
before
going
into
the
details,
I
have
my
first
question
so
so,
which
issue
do
we
think
is
a
blog
for
the
sdk
stable
release.
I
won't
hyper
focus
on
that.
For
example,
I've
seen
some
good
pr
about
allowing
multiple
callbacks.
They
are
only
changing
the
api
spec,
which
is
already
stable.
D
I
I
I
think
we
we
should
continue
on
this
discussion
and
exploration,
but
anything
changed
to
the
api
is
going
to
put
additional
burden
on
existing
like
language
maintainers,
so
they
have
to
make
a
decision
whether
they
implement
based
on
the
current
api,
or
they
want
to
prototype
this
in
order
to
give
feedback
for
the
pr.
I
I
wonder
if
we
should
postpone
this
discussion,
hyper
focus
on
getting
the
first
stable,
sdk
release.
C
D
Yeah,
but
that
can
be
changed
later
right.
I
mean
like
after
we
release
the
initial
stable
release,
so
all
the
languages
are
unblocked,
they
know
what
exactly
they
have
to
do,
and
then
we
have
additional
thing
like
in
api:
we're
not
breaking
anything
the
fact
that
we're
having
a
pr
on
the
stable
api.
I
believe
we
know
that
we're
not
breaking
anything
we're
adding
some
additional
feature
that
can
happen.
C
Yeah
I
sort
of
agree,
but
then
I
sort
of
find
reasons
to
to
like
think
that
this
is
I'm
pulling
up.
I'm
gonna
share
again
because
if
you
look
in
instrument
identity-
and
I
did
this-
is
the
multi-instrument
callback,
so
this
this
pr
itself
only
touches
the
api,
as
you
say,
but
it's
it's
it's
blocking
us
and
go
from
doing
what
we
like
and
it's
related
to
all
these
questions,
and
but
I
but
I'm
trying
to
connect
it
to
I
clicked
the
wrong
one.
C
D
C
It
can
I'm
going
to
say:
it'll
still
hold
up
the
golang
api,
then
all
these
issues
that
I'm
describing
will
hold
up
the
api
for
us
and
we
can
talk
about
them
and
maybe
we
can
work
around
them.
But
I
don't
think
that
that
is
what
we
want
to
do
at
this
time.
So
but
you're
you're,
correct
riley
and
what
was
I
gonna
say.
F
C
That
way,
that's
basically
what
I'm
my
hunch
is,
and
I
don't
want
to
try
to
explain
that
to
this
larger
group,
when
it's
a
few
people
talking
about
go
in
front
of
everyone,
but
the
idiomatic
thing
that
feels
right
to
me
and
go
that
breaks
the
api
spec.
It's
the
api.
Spec
says
that
instruments
have
one
callback
and
I
want
to
say
that
instruments
have
many
callbacks
and
I-
and
this
feels
important
enough
to
to
be
talking
about
but
you're,
I
think
riley
is
correct.
C
We
could
continue
marking
sdk
stable
without
these
nice
to
haves
and
the
api
changes
I'm
trying
to
make
are
all
loosening
current
restrictions
so
that
they
should
be
not
creating
new
work
for
existing
implementations.
I'm
trying
to
say
it's
optional.
If
you
want
to
support
multiple
callbacks,
if
that's
an
idiomatic
thing
to
do
for
you
and
your
library,
then
you
do
and
the
reason
why
I'm
saying
it's
well
defined
is
that
the
data
model
has
a
lot
of
clear
rules
about
duplicates
already.
D
I
see
so
maybe
we
can.
We
can
have
a
quick
estimation
on
like
what
are
the
additional
effort.
These
prs
are
going
to
put
on
a
language
maintainer,
because
I
believe
one
high
order
bit
for
the
matrix
work
is
to
have
a
very
scoped
spike
released
as
stable,
so
language,
like
all
the
languages,
can
start
to
implement
and
shift
their
stable
version.
D
The
fact
that
we
cannot
ship
the
stable
sdk
spec
is
because
many
sdk
maintainers
they
they
are
still
in
progress
of
catching
up.
So
the
fact
that
we're
we're
like
changing
the
scope
again
and
add
additional
thing
my
water
is
it
seems
we
don't
have
a
clear
line
later.
We
might
add
another
thing,
so
the
the
feature
matrix
keeps
growing
and
the
maintainers
will
eventually
complain
because
they
cannot
catch
up.
D
So
by
feature
freeze
I
mean,
like
we
have
a
consensus
like
it's
really
a
high
bar.
Unless
something
is
really
blocking,
people
cannot
make
progress.
We
have
to
change
this
back.
Let
me
make
the
change
anything
else
it's
nice
to
have.
We
can
continue
the
discussion,
but
we
should
hold
the
pr
until
we
release
the
initial
stable.
That's
my
personal
suggestion.
C
Okay,
I
I
would
like
to
turn
that
into
a
question
for
say
the
maintainers,
because
the
proposal
to
allow
and
to
fully
bless
mult
duplicate
instruments
and
multiple
callbacks
shouldn't
require
any
work.
It's
optional,
so
it
shouldn't
require
anything
at
all.
If,
if
that
seems
like
the
right
idiom,
though
it
lets
you
move
forward
without
this.
C
Just
clumsy
api
getting
getting
in
your
way,
so
I
do
see
it
as
a
compatible
compatible
with
feature
freeze
change
and
it's
just
making
a
slight
wording
change.
I
was
going
to
show
you
the
very
small
pr
now
in
more
depth
that
adds
multi
callback
potential
right.
So
it's
all
I
did
was
remove.
C
C
So
your
current
implementation
that
lets
you
pass.
The
callback
in
the
constructor
is
associating
one
callback
with
one
instrument
and,
if
you,
if
that's
all,
you
have
that's
an
option,
I
think,
but
if,
if
there's
an
idiom
and
a
demand
for
more
performant
asynchronous
instruments
where
you'd
like
to
make
multiple
observations
from
one
callback
or
where
you'd
like
to
make
multiple
callbacks
to
make
multiple
observations,
that's
naturally
going
to
happen
for
you,
because
the
spec
allows
it.
But
okay,
we've
talked
a
lot
about.
This.
C
Riley
is
mostly
right
that
we
could
move
on
and
call
these
fixes
after
stabilization.
I
just
I'm
not
happy
with
where
the
api
lands
at
that
point.
C
To
riley's
point,
we
should
not
talk
about
the
last
issue
I
had
here.
We've
already
talked
about
exemplars,
but
I
did
file
a
new
issue
and
I
just
want
to
put
it
in
front
of
people,
and
you
can
say
no
to
me,
but
as
I
was
implementing
the
views,
implementation,
I've
prototyped
it
far
enough
to
get
a
good
feel
for
it
and
I'm
ready
to
say.
I've
talked
about
the
one
issue
question
mark
about
memory
behavior
already.
This
is
the
only
other
question
I
came
up
with
in
looking
at
the
views.
C
Spec
as
as
it
stands,
it
seems
like
a
lot
of
effort
to
go
to
to
not
be
able
to
configure
more
than
one
different
views
for
different
readers,
and
I
I
tried
to
make
a
a
quick
explanation
of
why
what
I
think
might
happen.
C
Why
that's
no
big
deal,
and
the
answer
is
because
I
have
an
intermediate
aggregation
being
calculated
either
way
like
I'm,
going
to
compute
all
the
unique
aggregations
that
I
need
to
know
on
the
fly
and
then
every
collection
period
I'm
going
to
send
those
to
all
the
views
that
need
them.
So,
at
the
point
of
collection,
I
don't
care
whether
every
view
had
the
same
reader
or
whether
are
one
to
one
with
readers
or
whether
there's
more
than
one
reader
and
so
on.
C
In
other
words,
it
doesn't
matter
to
me
how
many
readers
there
are
and
they
should
be
able
to
have
different
view
configurations.
That's
my
request.
It's
pretty
minor
in
my
opinion,
but
this
would
definitely
be
something
that
we
that
we
are
are
not
future
frozen.
C
If
we
do,
I
have
now
reached
the
end
of
all
my
metrics
topics
and
if
we
decide
that
that
is
a
terrible
idea
per
metric
per
reader
metric
views,
I
can
I
can
live
with
it,
but
it
seems
to
me
like,
if
anyone's
imagining
more
than
one
metric
exporter,
they're
very
likely
to
want
to
change
the
cardinality
constraints
on
each
exporter
differently.
So
having
the
ability
to
change
your
views
per
reader
seems
powerful
and
fairly
easy
to
do.
C
Anyone
want
to
comment
on
that
one,
and
then
I
will
just
I
try
to
hand
off
this
meeting.
Yeah.
D
C
I'm
just
worried
about
breaking
things
right
after
we
stabilize
things,
so
it's
worth
thinking
through
I've
talked
way
too
much.
We've
also
hit
our
tie
box
for
metrics.
I
was
going
to
mention
exponential
histograms,
but
I
don't
think
we
should.
If
you're
interested
you
can
click
a
link.
D
Yeah
can
be
added
as
a
non-bracing
change.
I
think.
Okay,
maybe
yeah,
like
you
add
view
and
view
will,
by
default,
apply
to
all
the
reader
but
individual
reader.
Allow
you
to
either
a
reader
view.
C
Thank
you.
So
if
everyone
just
to
summarize
riley's
opinion
here
today,
we
can
continue
stabilizing
the
sdk,
and
I
I
will
let
everyone
else
comment
or
think
about
that.
As
we
move
on
I've,
I've
talked
about
myself
here
carlos.
Would
you
take
this
next
bullet
or
continue
the
meeting
for
me.
B
Yeah
sure,
well
it's
about
sampling
right,
so
so,
essentially,
what's
yeah,
we
want
a
last
review
cycle
if
possible.
This
is
for
the
probability
sampling
trace
state
specification.
Give
me
a
second
I'm
trying
to
share
my
screen
now.
C
B
Yeah,
actually,
we
already
have
enough
reviews
by
the
way-
and
that
includes
odd
mark
from
mana
trace,
he's
an
expert
in
the
field.
He.
C
Made
that
includes
a
honeycomb
engineer
and
a
an
app
dynamics,
engineer
who
were
all
very
interested
in
this
topic,
we're
having
trouble
getting
general
purpose,
hotel,
spec
reviewers
to
like
read
through
it
all
the
way
and
and
and
commit
their
brain
to
say.
Yes,
so
so,
where
there's
a
little
bit
of
uncertainty
about
whether
we
should
just
trust
the
experts
here
and
that's-
that's
all.
B
Yeah
but
as
I
had
mentioned
somewhere
else,
I
think
that
you
know
this
is
something
experimental,
so
you
can
go
in
honestly
and
we
can
start
playing
with
that.
This
can
go
to
a
content
repo,
even
you
know,
but
the
idea
is
that
we
don't
want
to
have
every
vendor
implementing
this
in
the
middle
term
future
with
different
approaches.
We
just
want.
You
know
at
least
have
some
kind
of
standards.
So
anyway,
as
I
said
before,
we
have
enough
reviews.
B
It's
it's
a
relatively
complex
pr,
but
we
are
planning
to
merge
this
week
if
everything
goes
correct.
As
I
said
before,
there
was
a
lot
of
feedback,
extensive
feedback
and
there
are
no-
and
there
are.
This-
is
based
on
a
few
steps.
Two
or
three
I
remember
so.
A
lot
of
stuff
has
been
addressed.
C
B
Sweet
okay:
tigran:
do
you
want
to
take
over
or
do
you
want
me
to
drive
this
part?
No,
actually
I
can
do
right.
A
Sweet
this
is
this
is
again
about
the
logger
name,
which
is
not
actually
the
logger
name.
It's
a
tracer
and
meter
name
as
well.
So
a
bit
of
history
there.
I
I
initially
proposed
that
we
introduced
the
concept
of
a
logger
name
specifically
to
record
what
the
logging
library
is
typically
called
their
logger
name,
which
to
me
appears
to
be
different
from
instrumentation
library
name
as
we
capture
it
for
traces
and
meters.
A
I
was
so
some
people
agreed
with
that
some
others
disagreed
and
the
people
who
disagreed
said
that
actually,
the
instrumentation
library
name
is
supposed
to
capture
the
logger
name,
because
the
intent
of
this
rotation
library
name
is
to
reflect
the
instrumentation
scope
so
to
say,
and
the
scope
can
be
an
arbitrary
string,
not
just
a
library
name
I,
for
the
sake
of
making
progress.
A
A
This
pr
simply
clarifies
or
extends
in
a
way
right
dilutes,
I
would
say
the
the
semantics
of
that
argument.
It
says
that
it
can
be
an
instrumentation
library
name,
but
it
can
be
also
other
things
like
the
module
name,
the
package
name
class
name
or
anything
that
the
the
developer,
who
wants
to
create
a
meter
or
tracer.
A
A
We
we
say
that
the
logging
is
inherently
different
from
tracing
and
metrics,
and
there
the
name
of
the
trace,
the
name
of
the
logger
that
we
obtain
can
be
either
the
library
name
or
blah
blah
blah
whatever
I
said
right
or
we
actually
for
the
logger
capture,
two
different
things
separately,
the
library
name
and
the
logger
name,
which
can
be
the
class
name
or
other
things,
but
not
the
library
name
right.
There
are
options
there.
A
Either
of
these
options
means
that
we
accept
that
logging
is
different
and
it
is
not
uniform.
It
cannot
be
consistent
from
from
this
perspective,
with
the
tracing
and
metrics
right.
It's
going
to
be
different
either
way
is
fine
with
me,
but
I
need
the
sig
to
rule
on
this
right.
We
either
go
with
the
consistency
route
and
consistently
make
this
tracerometer
logger
name
to
be
the
instrumentation
scope
or
we
do
not.
A
A
The
pr
is
there
I'd
like
people
to
speak
to
tell
what
they
think
to
object
to
agree
to
to
come
to
a
conclusion.
We
need
a
conclusion
on
this,
and
this
is
blocking
the
logging
seek.
We
cannot
wait
anymore.
This
has
been
going
on
for
more
than
two
months
already,
so
we
need.
We
need
a
decision
on
this.
D
A
Yes,
I
I
on
purpose
I
posted
this.
The
the
second
pr
is
actually
a
different
approach,
which
is
which
is
contrary
to
the
first
one
right.
So
I
want
one.
I
want
a
decision
on
one
of
these.
Maybe
there
is
another
decision.
I
don't
see
that
right.
A
Maybe
there
is
another
approach
possible
if
somebody
has
great
ideas
that
that
will
be
excellent
like
how
do
we
resolve
this,
but
for
now
at
least
the
two
possibilities
that
were
discussed
so
far
is
this:
we
either
make
logging
different
by
introducing
the
logger
name
as
a
separate
concept,
or
we
make
it
uniform
with
traces,
traces
and
metrics
by
changing
the
tracer
name
and
meter
name
to
be
what
the
logging
needs
to
be
as
well,
by
extending
it
to
allow
it
to
be
a
library,
name
or
or
more
than
library
name,
not
just
library.
A
What
do
you
do?
Yeah
we?
We,
we
published
a
roadmap
and
we
said
that
the
logging
sig
is
going
to
have
a
stable
data
model.
This
quarter
by
the
end
of
the
quarter
awesome,
and
this
one
is
blocking
us.
I
do
not
want
to
wait
until
the
end
of
the
quarter.
A
I
don't
want
to
wait
another
two
months
until
we
make
a
decision
on
this.
It's
not
going
to
help.
We
waited
for
two
months
already
yeah,
so.
A
A
Yeah
yeah,
I
I
I
again,
I
don't
think
we
can
wait
until
the
end
of
the
march
end
of
the
march
is
when
we
declare
the
data
model
stable.
This
is
only
one
of
the
issues
that
we
need
to
resolve.
If
we
wait
for
this
one
until
the
end
of
the
march,
it's
very
likely
going
to
sleep
there.
There
are
going
to
be
other
issues
to
resolve,
so
I
need
this
to
be
resolved.
D
Sooner
than
that
yeah,
so
my
suggestion
is
put
an
exact
date.
Maybe
it's
fair
to
say
like
like
everyone
like,
I
gave
you
one
month
and
if
you
couldn't
figure
out
what
what
we
need
to
do
after
one
month,
I'm
assuming
that
we
won't
be
able
to
make
decision
after
three
months.
So
I'm
going
to
do
this
anyway,
and
then
you
guys
have
one
month
to
make
your
decision,
because.
D
A
Yeah
yeah,
okay,
yeah,
makes
sense
to
me.
Josh,
you
want
to
say
something
you're
on
nuke
can
we
have
anthony
first.
F
A
It
can
be.
That's
fine,
that's!
Okay!
That's
that's
a
separate
decision,
whether
it's
an
attribute,
whether
it's
a
top
level
field
in
the
data
model
that
works.
That's.
We
can
discuss
that
separately.
The
the
question
here
is
that
if
the
logger
name
is
recorded
in
the
instrumentation
library
name,
then
we
no
longer
can
have
that
as
an
attribute
or
as
another
field
as
well
right,
that's
that's
pointless.
C
I
I've
I've
been
following
this
debate,
but
it
feels
like
it's
moving
so
slowly
that
we
all
lose
context
on
it
every
time.
So
I
think
we
should
try
and
just
resolve
this
as
fast
as
we
can
and
keep
talking.
I
reviewed
the
pr
and
it
felt
like
it
was
unobjectionable
to
me
until
I
read
more
questions
coming
out
and
realized
that
I
didn't
fully
understand
it.
So
I
was
just
going
to
offer
a
thought
experiment.
C
Would
you
feel
differently
about
this
debate?
If
there
were
an
api,
because
I
don't
think
the
user
would
change
their
calls?
If
there
were
an
api,
they
would
just
update
to
open
telemetry
and
they
start
calling
whatever
this
name
is
the
thing
you
used
to
get
your
logger,
at
which
point
you
would
have
the
opportunity
to
have
instrumentation,
like
library,
name,
equaling,
log
name
and
I'm
just
having
trouble
phrasing.
Why?
C
This
feels
like
a
non-issue
to
me,
but
I
mentioned
earlier-
and
I
mean
it
sounds
like
we'd
like
these
to
be
attributes,
but
we
don't
really
want
them
to
be
attributes
on
every
log,
because
they're
constant
for
this
entire
instrumentation
library.
Right
so
could
we
have
attributes
at
the
instrumentation
library
level
and
would
that
solve
this
problem?
For
you.
A
I
don't
think
it's
an
attribute
of
the
library
the
most
I
guess,
common
way,
that
the
logger
names
are
specified
in
java,
at
least
it's
the
class
name
and
in
a
library
you
can
have
multiple
classes.
So
it's
not
a
library
attribute,
it's
a
finer
granularity
type.
Eclipse
right.
A
A
So
it's
if
we're,
if
we're
thinking
of
this
in
the
hierarchical
terms,
it
would
be
something
below
the
instrumentation
library
level
right
which
we
do
not
have
which
doesn't
exist.
It's
the
log
record
itself.
That's
why
we
would
put
it
there.
I
understand
your
point:
it's
probably
not
going
to
be
the
best
way
in
terms
of
efficiency,
because
it's
going
to
be
very
repetitive:
you're
you're,
probably
using
the
same
logo
name
in
multiple
records,
but
I
think
that's,
probably
okay,
it's
not
a
huge
deal
in
my
place.
That's
an
orthogonal.
C
Name
of
yeah-
yes,
yes,
I
I
will
close
my
statement
here
by
saying
I,
like
the
hierarchical
interpretation.
I
wish
that
we
would
just
say
that
these
strings
are
scoped
names
and
that
they
are
nested
among
each
other
in
a
sensible
fashion,
so
that
you
can
have
your
logger
name,
be
a
prefixed
by
your
instrumentation
library,
name
and
and
wave
away.
This
problem.
A
D
A
C
I
think
I
meant
the
opposite
that
doesn't
bother
me
at
all.
It
seems
like
the
same
idiom
applied
to
chasing
and
metrics.
I
might
like
to
have
a
file
level
granularity
on
where
my
metrics
are
coming
from.
I
don't
know.
E
I
already
put
my
objections
on
the
pr.
I
don't
think
the
pr
needs
to
be
rejected
out
of
hand,
but
I
do
not
think
it
can
be
merged
in
its
current
state
because
we
can't
lose
the
instrumentation
library
name
and
if
in
under
the
current
pr,
somebody
could
just
get
a
tracer
with
a
class
name
instead
of
the
instrumentation
library
name
and
we
lose
that
information
and
we
can't
lose
that
information.
E
So
from
that
perspective,
it's
a
breaking
change.
If
we
added
something
hierarchical
like
what
josh
said.
That's
totally
fine
with
me
as
long
as
we
have
the
instrumentation
library
name,
having
things
nested,
underneath
it
fine
whatever,
but
we
need
the
instrumentation
library
name.
A
E
A
F
E
There
are
existing
back
ends
in
the
wild
receiving
this
data
that
expect
the
interpretation
library
name
to
mean
something
particular,
and
if
you
change
that
meaning
that's
you
know.
A
F
A
E
A
B
Perfect
thanks
for
that,
I
think
we
only
have
then
the
prometheus
otp
data
model.
G
Yep
so
hi,
I'm
david
ashford.
I
don't
know
if
I've
actually
said
anything
at
this
meeting
before,
but
I
hang
out
with
the
collector
sig,
the
ghost
egg,
the
prometheus
work
group.
I've
been
working
on
it,
it's
actually
not
much
of
a
proposal,
it's
more
a
documentation
of
all
of
the
work
that
josh
mcdonald
and
joshua,
and
obviously
many
others
have
done
to
try
and
make
otlp
and
prometheus
more
compatible.
G
G
G
G
Things
like
state
sets
info
as
well
as
exponential
histograms
that
I
think
we
should
save
for
individual
discussions,
but
otherwise
I'm
hopefully
I'm
hoping
that
this
is
not
very
contentious
and
will
save
some
of
the
issues
for
follow-ups.
But
I
appreciate
eyes
from
approvers
as
well
as
other
languages
that
I'm
not
as
familiar
with
and
I'm
happy
to
answer
questions
if
anyone
has
any
now
but.
A
Thanks
for
the
pr,
I
think
this
is
very
useful.
It
would
ensure
the
consistency
in
this
mapping
right
across
the
languages.
It's
very
important.
Thank
you.
B
C
Of
your
heads
during
my
monologue
on
duplicate
instruments,
both
jack
and
daniel,
spoke
up
to
say,
hey,
this
has
been
a
problem.
Duplicate
callbacks
is
a
real
thing.
We
sort
of
keep
getting
users
asking
for
could,
if
there's
a
moment
to
just
say
that
out
loud
I'd
like
to
hear
it.
G
Yeah,
so
in
java
it's
idiomatic
to
request
the
the
same
instrument
from
a
meter
multiple
times,
you
know
using
the
same
instrument,
type
name,
unit
etc,
and
you
know
that
makes
sense
and
there's
an
obvious
way
to
handle
that
for
for
synchronous
instruments.
But
you
know,
there's
a
there's,
an
inconsistency
between
our
synchronous
instruments
and
asynchronous
instruments
and
that
you
can
request
the
same
synchronous
instruments
multiple
times,
but
without
some
sensible
you
know
definition
of
what
to
do
with
with
multiple
callbacks.
G
If,
if
present,
then
you
know
we,
we
don't
really
know
what
to
do
if
multiple
callbacks
are
registered.
So
this
this
has
been
something.
We've
talked
about,
something
that
has
come
up
in
multiple
issues
for
us
and
we
would
like
it
to
be
resolved
at
the
spec
level.
If
we
can't
resolve
it,
I
suppose
we
can.
You
know
disallow
requesting
the
same
instrument
multiple
times
from
the
same
meter,
which
is
what
the
api
currently
specifies,
but
I
think
that
our
users
would
be
disappointed.
E
Thank
you,
yeah.
I
have
more
or
less
the
same
thing
to
say
that
jack
did
the
javascript
implementation
was
based
on
the
java
implementation,
so
no
surprise
that
they
have
similar
problems.
E
E
Right
now
we
just
allow
the
constructor
that
the
yeah
in
the
constructor
we
have
a
callback
but
changing
it
to
have
like
an
add,
a
callback
method
or
something
like
that
wouldn't
be
too
difficult.
G
It
wouldn't
be
a
breaking
change
for
java,
either
to
add
this
later
it
would
just
have.
We
would
just
be
forcing
existing
consumers
of
the
api
to
change
their
patterns
where
they've
gotten
used
to
being
able
to
you
know,
request
them
all
the
same
instrument
multiple
times.
C
For
me,
the
the
ideal
outcome
of
this
whole
topic
would
be
to
make
three
quick
changes
to
the
specification.
Two
of
them
are
the
pr's.
I've
already
got
open
and
one
more
is
just
say
you
can
allow
you,
you
can
delete
callbacks.
That
would
be
it.
That's
my
preference,
but
I
think
riley's
caution.
Cautious
approach
is
also
viable
here.
It
sounds
like
in
the
current
java
api
you'd,
say
new
async
instrument
and
and
pass
a
callback.
The
first
time
it'll
succeed.
C
C
D
C
In
our
last
minute
would
be,
let's
just
agree,
that
all
the
things
about
duplicate
instruments
and
callbacks
are
post
ga
and
the
only
issues
that
were
then
remaining
were
the
one
about
examples
which
you
already
agreed
about,
and
the
one
about
maybe
expanding,
to
be
multiple
views,
which
riley
has
already
argued,
is
backwards
compatible
as
well?
So
should
we
mark
the
api
sdk
stable.
F
I
think
the
last
concern
we
had
on
the
sdk
stability
was
views,
implementation
in
multiple
types
of
languages.
Are
we
at
a
point
with
other
languages
that
we're
comfortable
with
that?
I
know
you
said
you're
comfortable.
It
can
be
implemented
in
go
dan.
How?
How
does
it
look
in
javascript?
That
was
one
of
the
other
paradigms
that
we
were
concerned
about.
E
So
far
we
have
nothing
that
is
really
blocking.
I
know
one
of
our
maintainers
who
you
might
know
as
legendicus
he's
in
asia,
so
he
doesn't
attend
the
meetings
ever,
but
he's
opened
a
couple
of
issues
on
the
spec
for
clarifications,
but
I
don't
think
any
of
them
are
really
like
hard
blockers
they're,
just
we're
looking
for
guidance
as
we
implement.
C
B
D
Yeah,
I'm
I'm
going
to
like
resurrect
that
pr
and
and
take
the
the
feedback.
So
I
make
the
update
and
please
block
the
pr
if
you
think
it's
still
like,
there's
some
blogging
issue
for
you
and
maybe
we
can
give
a
week
next
tuesday.
We
we
should
make
a
decision
and
meanwhile
josh
thanks
for
driving
the
the
further
like
addition
to
the
api
and
sdk
spec.
So
I
I
think
we
can
continue
that
discussion,
but
this
two
separate
thing
doesn't
have
to
interfere
with
each
other.