►
From YouTube: 2022-02-22 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
Just
fyi
for
everyone
I
changed.
Some
of
I
started
changing
the
zoom
links
back
to
the
old
format.
Yesterday
I
haven't
done
all
the
meetings,
but
this
is
one
of
the
ones
I
changed.
If
you're
here
you're
on
the
right
link,
I
just
added
the
the
new
link
into
the
doc
and
the
calendar
was
updated
last
night.
So
all
that
should
work.
B
Okay,
let's,
let's,
let's
start
thank
you
for
joining
as
usual,
I
see
too
many
people,
so
I'm
guessing
that
most
people
came
back
from
the
long
weekend,
at
least
in
the
states.
Okay.
So
let's
go
over
the
agenda
yeah
by
the
way,
don't
forget
to
add
yourselves
to
the
attendees
list.
I
only
see
four
names.
B
C
Yeah
so
this
came
up
when
we
were
discussing
adding
environment
configuration
of
propagators
to
the
go
sdk,
and
I
found
what
seems
to
be
a
contradiction
in
these
specifications
here
where
the
api
spec
says
that
the
api
must
have
no
op
propagators
in
the
absence
of
explicit
configuration,
but
the
sdk
configuration
spec
says
the
default
environment.
Configuration
value
is
trace,
context
baggage
and
I
don't
see
how
a
default
can
be
considered.
An
explicit
configuration.
C
C
B
C
B
So
probably
we
need
to
yet
to
clean
that
up
for
sure,
by
the
way,
the
section
that
you
mentioned
anthony,
I
think
it
was
well
long
long
back
in
the
day
we
had
the
impression.
Well,
we
had
this
idea
that
context
can
exist
as
a
single
artifact
artifactor
package.
That's
why
the
default
would
be
an
op
and
then,
of
course,
we
try
to
install
the
propagators
depending
on
whether
the
api
or
sdk
is
there
okay,
yeah.
Let's
follow
this.
C
Up
so
so
walking
walking
back
to
history,
though
it
used
to
be
that
there
was
a
default
propagator
configured
in
the
api
and
then
it
was
trace
contact
baggage
and
at
the
same
time
the
sdk
configuration
was
like
that,
and
then
we
changed
the
api
back
to
a
no
op
default,
but
didn't
change
the
sdk
configuration.
C
So
my
my
wondering
is:
was
that
just
an
oversight
at
that
time
or
was
that
an
explicit
choice
and
I'm
missing
something
in
the
text
of
what
was
changed,
because
I
I
still
don't
see
how
to
reconcile
if
you
have
an
sdk
installed,
but
you've
done
nothing
else.
You've
made
an
explicit
choice
to
have
these
propagators.
B
C
B
Make
sense
any
other
maintainers
around
to
poke
what
you
decided
to
do
for
your
own
implementation.
F
At
least
in
javascript,
if
you
only
have
the
api
installed,
there's
no
propagators
and
the
environment
variables
only
affect
sdk
behavior.
We,
I
guess,
do
consider
that
in
this
case
your
quote,
explicit
configuration.
If
you
configure
the
sdk,
then
you
do
get
the
default
propagators.
It
does
not
leave
them
as
noah.
F
B
G
I
think
the
default
is
trace
context
and
baggage.
That's
largely
due
to
the
fact
that
the
api
is
actually
implemented
by
the.net
team
and
not
necessarily
the
open
telemetry
project.
So.
C
B
Make
sense
yeah,
thank
you
so
much
for
raising
that.
I
think
that
at
the
very
least
we
need
better.
You
know
better
explanation
and
better
rewarding
on
that
one.
Thank
you
for
raising
that.
Okay,
that's
that
one
for
now.
Moving
to
the
next
point,
john
micrometer
micrometer.
D
Yeah
sorry,
I
forgot
I
put
this
on
the
agenda
yeah,
so
this
was
a.
This
came
up
during
a
discussion
in
the
java
sig
right
now
in
the
java
core
sdk
or
core
repository.
D
We
have
an
open
census,
shim
and
an
open
tracing
shim,
and
there
is
a
micrometer
which
is
the
the
probably
one
of
the
top
two,
if
not
the
top
metrics
library.
For
java
there
is
a
shim
in
the
instrumentation
repository
at
the
moment,
but
we
don't
feel
like
this
is
actually
instrumentation
and
so
we're
trying
to
figure
out
where
this
belongs
and
given
that
micrometer
is
well
certainly
compared
to
open,
telemetry
metrics
vastly
more
popular.
D
There
is
at
least
an
opinion
among
some
of
the
maintainers
that
the
micrometer
shim
belongs
in
the
core
repository
alongside
open
census
and
open
tracing,
but
also
it's
not
really
a
part.
It
isn't
one
of
the
things
open,
telemetry
came
from
and
is
not
obviously
not
specified
in
the
specifications,
so
we're
not
exactly
sure
what
to
do
with
it.
It
feels
weird
to
move
it
to
contrib
when
it
is
such
a
core
part
of
the
java
metrics
ecosystem.
So
I
just
wanted
kind
of
some
opinions
from
other
maintainers.
D
G
Well
I
don't
know
I
don't
have
data
on
this,
but
I
don't
think
that
it's
necessarily
as
popular
as
micrometer
I
most
net
developers
I
meet,
aren't
actually
very
familiar
with
it,
but
it
is
something
that
a
and
there
is
an
open
pr
that
we
currently
have
inside
of
our
contrib
repo
for
a
shim
for
event
counters.
So
that
is
the
decision
we're
making
for
that.
F
Similarly,
in
node.js
there
are
some
native
instrumentation
points
that,
to
the
best
of
my
knowledge,
almost
no
developers
are
even
aware
of.
For
the
most
part,
we
do
have
a
couple
of
them.
Instrumented
and
those
instrumentations
are
in
the
contrib
repository,
but
I
wouldn't
necessarily
call
them
a
super
important
part
of
the
ecosystem
or
anything
like
that,
because
they're,
not
all
that
widely
used.
B
Yeah,
I
would
actually
would
like
to
ask
the
metrics
group:
how
important
do
you
think
micrometer
is
for
this?
I
know
that
there
was.
It
was
part
of
some
discussions,
but
what
would
you
say
if
you
were
to
give
your
opinion
on
this
one.
D
H
I
agree
the
project
came
out
of
you,
know
open
senses
and
open
tracing,
so
there
was
definitely
an
emphasis
on
backwards,
compatibility
and
bridging
from
the
old
ways
of
tracing,
and
so
there
wasn't
explicitly
references
to
the
old
ways
of
metrics
or
the
dominant
ways
of
metrics
as
much
we
referred
to
prometheus
a
bit,
but
the
open
source
metrics
was
quite
bigger
in
scope.
So
I
think
the
idea
is
correct.
H
That
john
states,
we
you
know
the
micrometer
is
so
important
if,
if
it
had
been
mentioned
two
two
three
years
ago,
it
probably
would
have
been
put
into
the
charter.
I
think
it's
just
reflecting
an
open
census
background
that
we
don't
have
that
explicitly
stated.
C
B
Yeah,
let's
just
see,
I
also
think
it's
it's
correct.
Maybe
we
should
have
just
small
line
somewhere
in
the
spec
saying,
like
you
know,
micrometers
important
enough.
We
care
about
that.
We
may
write
some
spec
parts
for
that
in
the
future
and
yeah.
Based
on
what
you
might
be
saying,
I
think
it's
okay
to
go
into
core.
F
Will
it
primarily
be
maintained
by
the
the
java
maintainers
or
is
there
a
group
of
micrometer
folks
that
will
be
working
on
maintaining
it?
The
only
question
I
have
is:
if
you
put
something
in
core
it
implies
a
level
of
support
that
can
trip,
doesn't.
D
Have
yeah?
I
think
that
this
is
an
excellent
question
and
actually
what
the
first
thing
I
asked
the
micrometer
team
is
definitely
interested
in
helping
maintain
it
absolutely,
but
I
think
the
core
maintainers,
that's
me,
jack
and
honorard
are
also.
D
We
are
not
averse
to
helping
maintenance
when
working
working
on
meditating.
F
Yeah,
I
guess
that's
that's
the
important
part
to
me
as
long
as
you're
willing
to
if
there's
some
you
know,
emergency
issue
on
it
that
you're
not
that
the
maintainers.
If
you
want
to
be
able
to
say,
ask
the
micrometer
folks
about
this,
then
it
should
go
and
contrib.
If
you
are
willing
to
handle
you
know
an
emergency
fix
on
your
own,
then
I
have
no
problem
with
it
being
in
core.
D
B
Okay,
yeah
keep
us
posted
on
that.
What's
the
final
result,
thank
you
for
that.
Okay,
if
that's
all
for
now
on
that
point,
we
can
go
to
the
next
one.
I
just
put
this
one:
it's
a
pr
from
tigran.
Basically
it's
about
renaming
instrumentation
library
to
instrumentation
scope
in
the
proto
in
the
proto-repo.
B
Basically,
it's
from
acquired
perspective,
it's
not
a
breaking
change
and,
as
the
node
mentions,
this
is
mostly
breaking
json
http
because
of
the
name
changes.
Otherwise,
it
looks
great
it's
part
of
the
pr
already
merged
last
week.
So
please
take
a
look
in
case
you're,
curious
and
review
and
approve
that
accordingly,.
D
H
To
walk
through
the
list
of
bullet
items
here,
although
I'll
say
I'm
also
on
vacation
in
this
week,
so
it's
just
this
hour
for
me,
the
the
question
that
we've
been
grappling
with
is
whether
it's
time
to
mark
the
sdk,
spec,
stable
and
or
whether
there
are
still
lingering
points
to
confusion.
H
We
don't
really
have
that
many
completely
implemented
view
sdks.
At
this
point
so,
however,
I
think
we're
sort
of
we're
sort
of
looking
for
progress
and,
if
we're,
if
we're
not
intending
to
make
any
more
breaking
changes,
we
should
probably
call
it
stable
riley
put
up
this.
The
first
two
pr,
the
first
pending
blocking
issues
summary
here
is
a
minor
pr
that
riley
put
out
that's
number
2372,
and
then
this
there's
one
open
issue.
H
H
Right-
and
this
has
also
been
the
one
that
josh
sureth
mentions,
although
he
is
also
on
the
call
and
in
my
opinion
this
is,
this
question
needs
an
answer
and
I
haven't
been
able
to
answer
it
myself.
F
His
first
name
is
equally
difficult
to
pronounce
everything
he's
in
asia.
He
will
never
join
this
meeting.
I
I
don't
know
specifically
what
time
it
is
over
there,
but
either
very
late
at
night
or
very
early
in
the
morning.
He's
one.
H
Who's
been
responsible
for
a
number
of
really
important
issues,
so
this
is
well
put,
and
I
think
we
should
focus
on
this
before
we
perhaps
follow
through
on
marking
the
stable,
the
spec
sdk
spec
mixed
as
riley
has
proposed.
H
So
if
you
have
some
attention
for
it
this
week,
please
look
at
that
one
if
you're
implementing
views.
This
is
a
question
about
the
mechanics
of
the
spec
and
the
way
they
relate
to
the
views.
Well,
we
have
quite
a
lot
of
time
left
in
this
window.
I
can
briefly
mention
the
other
four
pr's
that
are
in
this
non-blocking
list
below.
H
Whether
we
name
these
preferences
or
whether
we
make
them
programmable
but
there's
there,
this
one
seems
to
be
a
reaching
conclusion:
the
idea
that
we
would
have
preferences
names
always
cumulative
or
prefer
delta,
and
that
these
control,
the
encoding
of
of
cumulative
monotonics
and
but
not
the
non-monotonics,
so
that
up
down
counters
remain
cumulative
and
counters
can
be
delta,
even
if
they're
asynchronous.
H
This
was
discussed
last
week
because
it
requires
a
conversion
from
cumulative
to
delta
for
asynchronous
instruments,
which
I
was
my
personally
hoping
to
avoid.
But
we've
we've
argued
that
it's
important
at
this
point,
and
so
this
will
be
so
we're
not
going
to
change
the
spec
to
to
discourage
that
mode.
The
cumulative
to
delta
conversion.
H
That's
probably
the
most
substantial
of
the
prs
that
are
in
this
list
here,
the
other.
The
next
three
are
my
opinion:
not
substantial
changes,
but
you
could.
You
could
disagree
with
me.
The
first
is
a
fairly
pure
refactoring,
the
way
the
sdk
the
api
spec
was
written.
There
were
a
number
of
sections
that
were
just
duplicated
and
it
made
it
really
hard
to
read
and
edit.
H
H
This
second
one
make
callback
requirements,
apply
to
user
documentation.
That
was
suggested
by
honorable
in
the
last
review,
and
I
postponed
it
for
another
pr,
it's
pretty
straightforward.
The
idea
is
that
we
have
these
statements
in
the
api
spec
that
say
you
must,
or
you
should
not
do
something,
and
it's
really
meant
for
the
user,
not
for
the
author
of
the
api.
So
the
way
this
is
written
is
just
to
change
those
shoulds
into
should
into
must
document
what
the
user
should
do
this
last
one.
H
This
might
sound
controversial,
it
might
sound
esoteric
and
in
a
corner
case.
This
is
a
proposal
and
you
could
debate
whether
it
is
a
a
change
or
not
from
what
we
have.
I
believe
what
we
have
is
so
loose
and
gives
the
sdk
author
so
much
freedom
that
what
we
have
is.
Actually.
This
is
not
a
change,
the
idea
being
that
callbacks
that
are
able
to
report
multiple
instruments
was
never
discouraged
or
disallowed.
It
was
just
not
stated
that
callbacks
could
be
abound
to
more
than
one
instrument
in
the
hotel
go
prototype.
H
We
did
it
that
way
and
I've
tried
to
make
this
explicitly
allowed.
This
is
a,
in
my
opinion,
very
extremely
important
for
expensive
measurements,
like
the
garbage
collection
statistics
or
the
you
know,
reading
a
slash,
proc
file
to
get
some
numbers.
Those
are
expensive
ways
to
read
metrics
and
if
you
can,
you
should
do
it
once
not
once
per
metric.
H
So
we've
got
many
examples
of
why
that's
useful.
I
also
don't
think
it
breaks
back.
So
that's
it
is
there
anything
we
should
discuss.
I
would
like
someone
else
to
take
over.
B
H
And
yeah
well,
my
opinion
is
that
the
issue,
the
the
issue
that
has
no
pr
associated
with
about
readers
and
collect,
is
a
request
for
clarification
that
is
not
going
to
change
people's
implementation.
That's
the
way!
I
understand
it,
but
I
haven't
spent
enough
time
with
that
issue,
so
I
think
that
we
should
really
look
at
that
one
in
particular,
or
wait
for
more
views
sdks
to
be
completely
implemented.
My
understanding
was
that
we
were
stuck
up
on
those
api
questions
that
we
resolved
last
week.
H
The
issue
of
multiple
duplicate
instrument
registration
was
causing
us
to
ask
all
these
questions
about
the
views.
Therefore,
we
had
to
pin
those
down
now
that
that's
been
merged.
My
question
to
the
rest
of
us
is:
are
we
still
uncertain
about
the
metrics
sdk
spec
and
do
you
see
changes
or
do
you
use
your
jesse
clarification.
B
Opinions
everything
looking
correct
what
a
video
oh.
E
No,
I
think
most
clarifications
will
be
happening
in
the
future.
In
my
opinion,.
I
I
think
I
think
that
I
think
the
clarification
about
preferred
aggregation
temporality.
I
agree
that
we're
reaching
a
conclusion.
I
think
it
it's
fairly
important
to
to
have
that
one
resolved.
H
Great,
if
you
do
wade
into
that,
it
is
lengthy.
If
you
get
down
to
the
bottom,
you
can
see
that
we're
reaching
agreement.
Josh
sheriff
made
a
recommendation
to
me
to
actually
scope
it
back
a
little
bit.
So
if
you
agree,
go
look
at
that
particular
comment
and
we
can
get
that
done
very
quickly.
H
G
I
put
a
comment
on
your
pr
right
before
this.
H
Meeting
so
I
don't
even
know
if
you
had
a
chance
to
see
it,
but
actually
I
did
see
that
alan
and
that
was,
I
haven't,
thought
through
it.
Yet.
But
if
you'd
like
to
speak
in
front
of
the
group
right
now,
that'd
be
great
or
we
can
take
that
offline.
G
G
The
statement
you
have
about
the
delta
preferred
basically
is,
is
making
an
implicit,
implicit
tie
from
instruments
to
the
notion
of
temporality,
which
my
understanding
doesn't
really
exist
within
the
specification
today,
but
it
would
if
this
pr
would
emerge,
as
is
my
my
understanding
of
temporality,
is
that
it's
relatively
decoupled
today
currently
from
from
instruments
and
that
it
it's
really
simply
a
notion
that
affects
how
an
aggregation
would
behave.
G
G
I
think
the
nice
thing
about
that
is
that
it
also
enables
us
for
if
the
day
comes,
where
we
actually
do
want
a
delta
non-monotonic
sum
that
you
could
get
that
from
up
down
counter
by
simply
using
the
view,
api
and
configuring
a
different
aggregation.
So
just
maybe
the
regular
sum
aggregation
which
already
supports
this
notion
of
of
preferred
temporality.
G
H
I,
if
anyone
else
wants
to
take
that
I'd,
be
glad
to
open
the
floor.
H
I
don't
feel
I
have
the
most
carefully
prepared
remarks
on
this
one.
I
think
I
y
you're
probably
right
that
the
connection
between
what
we're
calling
the
synchronous
instruments
producing
delta
observations.
Naturally
it
is
we've
we've
danced
around
the
wording.
I
mean
it
says
something
like
even
in
my
recent
pr
2317,
I
changed
the
word
from
absolute
to
current
and
I
tried
writing
cumulative
and
guard
corrected
me.
H
So
the
idea
that
asynchronous
callbacks
report
current
values,
I
think
the
trouble
you
get
into
alan
with
your
question-
is
that
you
then
say:
okay,
I'm
looking
at
these
two
cumulative
values
and
I
need
to
aggregate
them,
so
I
add
them
to
the
aggregator
and
the
problem
is
that
you
end
up
multiplying,
like
you
add
the
cumulative
values
over
and
over
again,
and
so
the
distinction
between
temporality
seems
decoupled
until
you
get
up
to
view
setting
to
setting
up
views
because
you
have
to
decide
when
to
reset
your
aggregator,
which
is
which
is
orthogonal
to
how
the
aggregator
works.
H
So
this
is
a
complicated
way
of
saying
I
think
you're
right,
but
this
is
just
a
hard
area
to
specify
you
could
ask
questions
like
what,
if
I
wanted
a
instrument
that
was
asynchronous
but
reported
at
delta,
for
example.
How
would
I
do
that
and
because,
because
you're
trying
to
say
well,
if
these
are
decoupled,
how
do
I
make
an
asynchronous
instrument
that
produces
a
delta?
And
I
think
the
answer
is
you
use
a
delta
instrument
from
your
callback,
I.e,
use
a
synchro's
instrument
from
your
callback
or
use
an
asynchronous
instrument
synchronously.
H
Those
are
both
ill-defined
statements,
but
I
I
wouldn't
lean
in
the
direction
that
you're
suggesting,
I
think,
which
is
to
consider
temporality
part
of
the
aggregation,
but
it's
really
hard
to
explain
why.
I
think
that
I
wish
someone
else
would
speak.
E
Just
but
if
we
don't
consider
temporality
to
be
part
of
the
aggregation,
aren't
we
naming
temporality
aggregation
temporality.
Is
that
the
name
that
we
give
yeah
segregation
temporarily.
H
H
That
there's
a
natural
form,
essentially
that
that
synchronous
instruments,
when
you're
dealing
with
aggregation,
arrive
with
temporality
delta,
aggregation
temporarily
delta
and
conceptually
you're
supposed
to
think.
Well,
the
the
thing
I'm
observing
is
the
cumulative
sum
of
all
the
deltas
that
I've
that
I've
witnessed,
or
something
like
that
so
that
I
don't
know
I'm
sick.
That
was
that
was
a
confusing
statement.
E
Yeah
because
sorry
to
interrupt
at
least
in
the
in
in
your
python
in
the
python
seek
we,
we
once
had
a
small
discussion
about
this
when
we
were
trying
to
work
with
the
synchronous
and
synchronous
aggregations,
and
we
we
asked
ourselves
if
we
shouldn't
look
into
the
instrument
synchronicity
with
that.
I
mean
if
the
instrument
is
synchronous
or
not
to
make
the
decision
instead
of
looking
in
the
temporality
that
is
associated
with
the
instrument
somehow,
but
but
yeah.
H
Let's
step
back
a
little
bit,
the
whole
point
of
this
pr
is
that
we
think
there's
a
concept
of
I
want
to
say
temporality,
but
the
exporter
should
be
independent
from
the
measurements
that
are
taken.
You
should
be
able
to
change
from
a
synchronous
to
an
asynchronous
instrument
and
continue
having
the
same
export,
and
you
should
build
change
from
asynchronous
to
synchronous
and
continue
having
the
same
export.
H
Therefore,
we
configure
temporality
for
the
export
independently
of
configuring
temporality
of
the
observation
and
the
the
instrumentor
who
actually
makes
those
observation
has
to
choose
whether
they're
choosing
current
or
change
current
values
or
change
values
when
they
do
their
instrumentation.
So
so,
there's.
H
So
I
see
whether
we
can
consider
this
a
change
of
temporality
or
the
choice
of
a
new
aggregator
seems
to
be
the
topic
here.
I
think
I
would
have
to
go
offline
and
come
up
with
some
better
reasoning,
yeah,
for
why
the
current
state
is
preferred
in
my
opinion,
but
I
don't
have
a
good
answer.
I
So
one
more
one
more
alternative
suggestion,
so
alan
allen
talks
about
having
a
a
different
aggregator
that
matches
the
output
behavior
that
we
want.
But
another
thing
I
was
thinking
about
was
what,
if
there's
a
an
attribute
or
a
property
that
the
sum
aggregator
takes,
which
indicates
whether
or
not
it
it
interprets
the
preferred
temporality
strictly
or
not.
So
if
by
default
it
would
have
a
non-strict
interpretation
of
their
preferred,
temporality
and
so
up
down
counters
would
report
in
cumulative
temporality,
because
it's
it's
unusual
that
they
would
be
able
to.
I
They
would
be
useful
in
in
delta
values,
and
but
if,
if
somebody
wanted
to,
they
could
change
the
sum
aggregation
to
have
to
obey
the
preferred
temporality
strictly,
in
which
case
it
would
always
be
delta
or
always
be
cumulative.
Based
on
your
preferred
temporality.
I
think
that
achieves
the
same
effect
and
it
a
lot.
It
keeps
the
door
open
for
a
future
where
we
somebody
might
want
to
have
delta
non-monotonic
sums
exported.
But
you
know
it's
it
it.
G
I
think
don't
all
of
these
solutions
sort
of
have
the
issue
that
the
views
are
like
specified
globally
right
now
you
can't
configure
a
view
for
a
given
metric
reader,
so
if
you
want
them
to
be
independent,
then
like
there's
no
way
to
do
that.
With
the
view
configuration
right,
I
found
an
issue.
H
About
that
I
haven't
thought
a
pr
about
that.
I
think
that
this
was
uncontroversial
and,
if
you're
going
to
go
to
the
trouble
with
20
views,
why
not
make
them
support?
Why
not
make
readers
support
different
view
configurations?
Otherwise,
I'm
not
sure
what
the
point
is:
yeah
yeah.
H
Riley
argued
that
that
would
be
a
non-bloc,
a
non-breaking
change.
You
would,
you
know
you
would
have
one
standard
view
that
may
be
applied
by
default.
Then
you
could
have
per
reader
views
configured
and
so
on,
but
we
are
getting
away
from
the
issue
of
whether
you
specified
temporality,
independently
of
aggregation
or
not.
I
kind
of
like
jack's
suggestion,
but
I
have
to
think
about
it.
A
little
bit
more.
I
And
I'll
write
that
up
in
the
pr
just
to.
I
Clear,
thank
you
just
wanted
to
bring
it
up
here,
while
everyone
is
present,
but.
H
Yeah,
I
think
I
mean
I'm
remembering
back
to
that
confusion
that
existed
a
year
ago
when
we
were
working
around
these
same
ideas
and
I
think
the
the
counter
confusion.
That
happens
is
that
someone
says
well.
I've
got
these
asynchronous
asynchronous
counter
observations
from
an
asynchronous
callback
and
you're
and
there's
some
aggregation.
H
So
you
put
them
into
the
sum
aggregator
and
it
adds
a
current
running
total,
which
is
not
what
you
mean,
and
so
you
can
either
change
how
the
aggregators
work
or
you
can
change
how
the
aggregation
works
to
handle
that
issue,
and
I
guess
we
leaned
towards
changing
how
the
aggregation
configuration
works
rather
than
you
know
configuring
when
you
reset,
rather
than
changing
the
aggregation,
but
I
think
this
will
be
confusing
either
way.
So
you've
raised
a
good
point
jack.
Thank
you
and
ellen.
G
Thank
you
yeah.
I
equally
need
to
think
about
this
more.
I
feel
like
both
of
these
both
my
suggestion
and
maybe
jack
suggestion
two
may
suffer
from
some
of
the
same
things
that
you've
raised,
but
I'm
still
trying
to
kind
of
get
my
head
around
it.
That
last
point
you
just
made
that
you
know
some
aggregation.
G
You
expect
values
to
be.
You
know
summed
up
and
in
the
case
of
an
asynchronous
up
down
counter,
that's
not
really
how
it
operates,
which
I
don't
know,
I
guess
to
me,
is
still
I'm
leaning
towards
it's.
It's
a
totally
different
flavor
of
aggregation.
I
It
does
kind
of
some
asynchronous
up
down.
Counters
still
do
some
in
some
circumstances,
that's
a
hard
to
say,
but
so,
if
you're
using
an
attribute
processor
that
drops
dimensions,
then
you
would
have
to
sum
across
those
cumulative
values.
H
And
then
that
actually
gets
I
mean
I
was
kind
of
trying
to
stay
away
from
all
the
complexity
here,
but
but
maybe
the
solution
is
that
we
define
aggregation
to
be
a
little
bit
more
sophisticated.
So
right
now
we've
been
kind
of
making
a
simplification
for
an
activation.
There's.
This
notion
of
a
decomposable
aggregate
function
that's
described
in
the
spec,
and
it
says
that
you
can.
H
You
can
decompose
your
work
and
and
the
aggregator
just
does
that
and
if
that's
as
simple
as
we
have,
then
you
end
up
having
these
other
problems
that
are
orthogonal
which
have
to
do
with.
When
do
you
reset
the
activator
and
are
the
inputs
to
the
aggregator
being
merged
in
a
temporal
or
spatial
way?
H
I
think
that
that's
what
we're
hiding
by
this
oversimplification,
because
when
you
are
merging,
I
say,
merge
because
I'm
thinking
of
just
add
another
aggregator
in
whether
I'm,
whether
I'm
merging
with
my
previous
value
of
myself
or
whether
I'm
merging
with
a
a
sibling
so
to
speak,
like
jack,
just
described
you
end
up
with
different
desired
behavior
based
on
the
temporality
that
you've
configured.
H
So
if
I
have
asynchronous
counters
and
I'm
and
I
have
a
subsequent
observation,
the
idea
is
that
it
overwrites,
but
if
I
have
asynchronous
counters
and
I'm
merging
with
another
observation,
based
sum
so
now
it
seems
like
I
need
to
know
whether
I'm
merging
spatially
or
merging
temporally,
and
so,
if
we
define
the
aggregation
interface
to
be
a
merge,
a
reset.
H
H
Plus
thumbs
up
from
aaron,
that's
somebody
understood
something
there
and
I've
wanted
that
that,
but
it's
a
hint
of
what
I
just
described,
it's
already
present.
So
when
we
add
min
max
to
histogram
the
min
max
behavior
is
breaking
that
decomposable
aggregation
function
so
that
when
you
merge
two
histograms
together,
you
want
to
max
their
max
and
min
them
in,
but
over
time,
because
we
expect
them
to
be
have
delta
behavior.
H
When
you
merge
in
your
subsequent
values,
even
for
a
cumulative
histogram,
you
want
to
reset
your
min
and
max.
So
now
those
min
and
max
behaviors
are
totally
out
of
out
of
the
ordinary.
So,
whatever
we
do,
hopefully
the
mid
max
behavior
will
become
clearer,
and
maybe
that
will
help
you
think
through
this.
As
you
all
comment
on
that
issue,.
B
I
guess
that
I
have
a
question
that
is
not
related
to
this
specific
point,
which
is
on
on
the
on
the
other
item
filled
by
legend
cass,
or
I
forgot
his
how
to
pronounce
his
username,
like
that's
technically
america's
blocking
and
since
there's
no
pr,
I
I
think
that
we
need
women
need
somebody
to
drive
this
to
own
this
point.
Otherwise,
you
know
we
will
be
probably
busy
with
the
other
discussion.
H
I
would
like
to
nominate
aaron
abbott,
who
is
here
and
works
somewhat
closely
with
josh
s
who's.
The
one
who's
really
raised
this
as
a
blocker,
and
maybe
two
you
could
out
there
and
you
could
get
in
touch
with
josh
and
coordinate
with
him
and
see
if
we
can
resolve
this.
G
Okay,
sure
I
can
do
that
does
do
we
know.
Riley
is
like
current
thinking
on
this.
H
I
I
believe
that
riley
doesn't
see
this
as
an
issue
and
that's
why
I
see
it
as
a
clarification
only,
but
I
I
also
haven't
invested
enough
to
really
understand
it.
B
B
H
H
Two
weeks
ago,
two
or
three
weeks
ago,
we
were
all
saying
yeah.
We
want
to
implement
this
sdk
spec
and
the
view
stuff
is
coming
together,
but
we're
all
hung
up
on
these
duplicate
instruments
and
and
in
the
hotel,
go
repo.
We
didn't
even
want
to
change
our
api
or
move
anything
forward
because,
like
it
all
seems
so,
hung
up
on
these
questions
of
duplicate
instruments
and
also
duplicate
callbacks
and
things
like
that.
H
Do
we
feel
less
resolved
now
I
we
did
merge
a
big
pr.
We
made
a
pretty
big
change,
it.
Doesn't
it
changes
the
way
air
handling
is
specified?
My
question,
roughly
speaking,
is
when
will
we
know
if
we
can
implement
these
sdks
now
I
feel
like
we
were
waiting
for
something
there
now.
I
don't
think
we're
waiting
anymore
other
than
for
this
clarification
that
we
just
discussed.
H
So
hopefully
you
have
the
answers
you
need
now
with
with
duplicate
instruments,
and
my
question
is:
can
we
implement
this?
I
don't
know
the
answer
I
mean,
I
think
I
know
the
answer,
but
I
haven't.
We
haven't
actually
finished
it.
So
I'm.
I
Not
sure
yeah,
I
think
it's
implementable,
but
so
I
have
an
action
item
for
myself
to
go
and
make
sure
that
the
java
sdk
it
implements
all
the
new
language
that
was
specified
in
that
big
pr
that
was
merged
and
that
all
the
implications
of
it
can
be
handled
in
a
sensible
way.
H
In
that
discussion
there
there
were
my
pr
2317
referred
to
many
issues
that
were
open.
It
closed
a
few,
but
also
left
a
few
open.
I
think
there
was
one
number
2232
which
was
about
stop
destroy.
Discussion
was
basically
came
in
because
of
I
think
this
was
a
micrometer
bridge.
Question
had
to
do
with
micrometers
api
allows
you
to
delete
something
and
have
all
the
metrics
that
you've
been
reporting
stop,
and
this
discussion
there
is
totally
unresolved.
H
I
think
it's
probably
out
of
scope,
but
maybe
it's
not
prometheus,
has
a
similar
api
called
delete.
We've
never
done
anything
or
talked
about
this
really
in
this
group
at
some
level,
I
think
of
it
as
an
way
out
of
scope.
The
thing
that
was
being
requested
for
the
micrometer
bridge
was
basically
trying
to
delete
a
bunch
of
state
and,
in
my
opinion,
the
way
to
do
that
would
be
to
delete
to
have
some
sort
of
combination
exporter.
H
That
would
have
a
separate
sdk
for
every
library
and
as
soon
as
you
want
to
delete
one,
you
stop
that
library
and
you
stop
exporting
it,
whereas,
what's
being
requested,
is
more
like
a
an
api
to
delete
instruments
or
to
delete
time
series
which
is
asking
for
a
lot.
That's
never
been
asked
for
in
the
past,
and
I
don't
really
want
it.
But
I
thought
I'd
ask
what
if
anyone
has
thoughts
or
feelings
on
that.
I
So
I
think
we
need
mateosh's
feedback
on
this,
he's
the
one
that
opened
the
original
issue
in
response
to
building
the
micrometer
bridge
that
we
spoke
about
earlier.
My
feeling
is
that
having
the
ability
to
remove
callbacks
solves
this,
and
I
know
he
was
really
excited
about
that.
I
think
I
need
to
go.
I
slash.
We
need
to
go
check
in
with
him
and
confirm
that.
H
Yeah,
so
I
saw
it
as
a
minimum
requirement,
but
but
the
actual
issue
asked
for
more-
and
I
don't
really
want
to
do
that.
So
how
do
you
stop
using
a
synchronous
instrument?
You
stop
using
it?
How
do
you
delete
the
resource
available?
You
stop
using
the
meter
provider
and
you
delete
the
meter
provider
and
you're
done,
but
what
this
is
asking
for
is
a
way
to
have
a
meter
provider
sort
of
and
then
have
instrumentation
libraries.
H
Aka
meters
come
and
go,
but
when
a
meter
goes
all
the
time
series
it's
been
recording
should
also
go
and
that's
the
can
of
worms
that
we
could
avoid
just
by
making
it
an
exporter
issue
like
so.
Each
library
could
then
have
its
own
exported
state.
The
critical
question
here
is
sdks
are
required
to
do
something
about
single
rider,
so
you
are
required
as
an
sdk
to
do
aggregation
now.
What
if
this
micrometer
bridge
produces
metrics
that
are
conflicting?
Do
you
expect
the
sdk
to
re-aggregate
from
multiple
libraries?
H
I
Yeah,
exactly
that's
that's
kind
of
where
I
stand
on
this
so
but
you
know
I
think,
you're
right.
I
think
we
do
need
to
clarify
whether
this
is
important.
I
suspect
that
it's
not.
I
suspect
this
is
a
nice
to
have.
H
J
Not
not
an
expert
on
the
deletion
part,
but
I
I
just
wanted
to
I'm
not
quite
sure
how
the
micrometer,
instrumentation
or
or
bridge
now
works
with
it
like.
Is
it
basically
a
micrometer
instance
running
somewhere
that
then
exports
data
to
open
telemetry
or
is
it
the
other
way
around?
Is
it.
I
J
H
Yeah
and
he's
proposing
to
say,
there's
a
way
to
delete,
so
those
stop
exporting,
which
is
something
prometheus
supports,
and
the
imaginary
scenario
here
is
something
like
I've
got
a
long
running
process
and
it
has
components
that
come
and
go
so
like.
I
am
a
task
manager
and
I
pull
tasks
they're
long
running
though
so,
while
a
task
is
running,
I
export
its
metrics,
but
then
I'm
overloaded.
So
I
want
to
shed
some
loads,
so
I
shut
down
those
tasks
and
I
move
them
somewhere
else
now.
K
A
It's
slightly
tangentially
a
tangential
topic,
I'm
updating
all
the
calendar
zoom
links
today.
I've
already
done
a
bunch,
so
hopefully
there
will
be
no
more
issues
going
forward.
J
Is
this
any
in
any
way
related
with
the
videos
of
these
recordings
going
up.
A
No,
although
that
was
I
think,
fixed
a
few
weeks
ago-
and
the
nice
thing
about
the
way
we
have
been
using
zoom
for
the
last
few
months
is
that
the
titles
would
come
through
correctly
and
we're
going
back
to
the
old
system.
So
the
titles
will
no
longer
come
through
correctly,
but
the
meetings
will
be
more
reliable
and
actually
occur,
which
is
good.
A
Okay,
yeah
it's
complicated
and
I
hope
the
things
randomly
getting
deleted
from
the
calendar
is
related
to
zoom.
If
it
is,
then
this
will
fix
that.
If
it's
not,
then
we
need
to
chase
that
down.