►
From YouTube: 2023-02-14 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
C
D
I,
don't
know
whether
anybody
have
planned
to
drive
this
before
since
I
was
late,
hear
silence,
or
in
that
case
let's
start
it's
three
minutes
after
the
start
time,
so
I
think
that
we
are
good
to
go.
Thank
you
for
joining.
Okay.
Let's
go
with
the
first
item.
Trask,
usually
you
share.
You
want
to
share
this
time
as
well.
E
So,
as
part
of
the
HTTP
semantic
convention
stability,
they
wanted
to
bring
up
two
issues
that
are
affect
all
conventions,
and
so
therefore
we
need
to
resolve
them
one
way
or
another,
or
before
we
can
Mark
HTTP
stable
they're,
both
a
little
bit
I'd
say
a
little
bit
contentious
the
let's
start
with
the
most
contentious
one,
probably
changing
default
defaulting
the
seconds
in
Federation
So,
currently
in
HTTP
metrics
at
least
we
use
milliseconds.
E
So
this
would
need
to
be
changed
before
stability.
If
we're
going
to
do
it,
I
think
the
main
argument
that
I
see
for
going
to
seconds
is
that
that
is
what
Prometheus
uses,
but
anyways
we'd
like
to
open
the
floor
and
use
a
little
bit
of
time
to
get
thoughts
here.
E
And
it
can
be,
it
doesn't
have
to
be
Pro,
yes
or
no.
It
can
also
be
you
know
any
recommendations
on
how
to
move
what
we
should
do
as
a
stability
working
group
to
move
this
issue
forward.
Like
any
additional
thing,
you
would
like
us
to
research
on
this
in
order
to
make
a
decision.
F
A
It
costs
maybe
like
start
with
a
total
change
to
seconds
and
see
who's
strongly
against
that
and
if
there's
no
strong
pushback
like,
if
anyone
is
strongly
against
it,
we
can.
We
can
ask
for
the
actual
reason.
A
G
The
the
explicit
bucket
histogram
aggregation
has
default,
buckets
that
are
that
are
based
on
milliseconds
and
aligned
with
Prometheus
clients
default
buckets,
and
in
the
past
we
have
said
that
it's
a
breaking
change
to
change
those
default
buckets,
and
so,
if
we
were
to
change
the
default
units
for
HTTP
server
duration
from
milliseconds
to
seconds
than
the
default
buckets,
if
we
can't
change
those
defaults
would
not
be
useful
for
one
of
the
key
use
cases.
A
And
so
here's
my
my
suggestion.
We
talk
about
the
hint
API,
so
I
I
feel
like
number
one
to
me.
The
high
order
bit
is
to
have
a
better
unit
story,
aligned
with
premises.
Number
two
is:
this
can
be
fixed
if
we
have
the
hint
API
and
we're
saying
for
all
the
HTTP
durations
people
should
provide
the
hint
by
giving
a
like
more
reasonable
default
buckets
and
when
people
ship
the
HTTP
metrics
that
hint
should
be
provided
so
people
who
are
relying
on
the
current
icq
extra
places
buckets
the
default
one.
H
Well,
I,
don't
know
if
it
is,
a
lot
of
people
will
do
kind
of
spent
metrics
conversions.
So.
A
A
They're
using
the
preview
version
of
the
HTTP
Matrix
instrumentation
from
any
open,
Telemetry
language
implementation,
they
will
be
affected.
However,
I
want
to
make
it
very
clear
that
these
are
very
early
stage
experimentals
in
so
that
should
be
the
expectation
I
I
just
want
to
avoid
the
situation
where
we
ship
any
preview
release
and
be
too
worried
about
breaking
anything,
because
in
that
way,
that
defeat
the
purpose
of
running
experimental
thing,
not
saying
like
we
want
to
introduce
breaking
changes,
but
we
shouldn't
be
too
afraid
to
do
that.
H
Would
this
be
something
that
a
schema
translation
would
help
us
detect.
A
A
G
Let's
go
back
to
the
hint
API
suggestion
really
quickly.
Does
anyone
on
this
call
disagree
with
having
a
a
narrow
addition
to
the
histogram
API
that
allowed
a
user
to
specify
default
bucket
boundaries
if
they
aren't
already
specified
or
if
which
are
used,
if
the,
if
a
view
or
the
reader
hasn't
specified
other
defaults.
I
E
I
I
apologize,
I
was
talking
about
the
seconds
versus
milliseconds
issue,
I
I
do
support
API,
hints
and,
and
they
seem
like
a
reasonable
solution
for
many
problems.
Okay,.
F
Nice
well
I
think
the
issue
is
whether
there's
a
general
hints
API,
or
this
change
for
histogram
instrument
right
jack,
yeah.
G
I
I'm
of
the
opinion
that
we
should
not
try
to
boil
the
ocean
and
introduce
an
exhaustive
hint
API
in
in
one
in
one
attempt.
I
think
we
should
add
selected
additions
to
the
API
as
needed,
and
this
is
a
natural
first
candidate.
E
E
Currently,
the
Prometheus
exporters
can
deal
with
that,
and
you
know
Translate,
but
they're
I.
Guess
there
have
been
some
user
questions
about.
You
know
it's
not
quite
as
obvious
what
by
means
versus
if
we
used
bytes
the
contrary
on
the
the
other
side,
I
think
the
you
know
this
was
Josh
summarized
well
like
that.
It
is
a
standard
for
the
internationalization
seems
like
a
useful
part
of
that
standard.
B
B
J
Just
using
the
standard
like
yeah
like
there's
something
I'd
rather
not
open
till
on
a
trip,
become
a
standard
for
units.
B
A
Okay
cool,
so
so
my
takeaway
from
this
conversation,
we
picked
some
unit
number
because
at
the
time
we
believe
it's
an
international
standard
or
something
there
are
some
benefits
pros
and
cons,
and
we
consider
pros
and
cons,
probably
not
not
comprehensive,
study
based,
but
at
least
we
compare
the
pros
and
cons
and
they
made
the
decision
and
it's
too
late
to
revert
the
decision,
because
it'll
be
a
breaking
change
or
at
least
something
very
scary,
and
even
if
we
allow
additional
units
to
be
added,
that's
only
going
to
make
things
worse.
J
A
A
I
agree:
it's
a
year
we
allowance
premises
or
we,
along
with
the
international
standard,
instead
of
we
try
to
Define.
Yet
another
standard
totally
agree
with
that.
So
so
my
proposal
would
be
I.
I
should
just
go
ahead
and
close
the
issue
and
put
a
summary
of
this
discussion
so
later.
If
anyone
has
a
feeling
they're
saying
like
why
this
is
so
strange,
then
we
can
always
point
to
them
and
maybe
like
improve
the
documentation,
hope
that
eventually
people
would
get
educated.
E
And
if
we
ever
did
want
to
revisit,
you
know,
Josh's
proposal
of
adding
in
you
know,
support
for
bytes
that
would
might
take
away
from
the
HTTP
stability
is
that's
something
that
could
be
done
later
in
theory
like
if
we
did
want
to
revisit
that.
E
And
last
is
this
PR
change
to
user
agent
I
brought
this
up
last
week,
so
this
was
I
know.
It
mentions
ECS
here,
but
The
Proposal
here
is
to
make
this
change
independent
of
whether
we're
going
to
align
other
things
with
ECS,
because
the
user
agent
having
a
shared
user
agent
namespace,
is
beneficial
for
other
semantic
conventions
and
for
three
reasons,
one
having
a
shared
namespace
is
useful.
We've
already
seen
two
other
cases
where
we
want
to
have
user
agent
in
semantic
conventions.
E
The
second
reason
is
that
the
user
agent
string
is
being
has
been
deprecated
and
being
replaced
on
the
browser
side
with
like
different
components
of
the
user
agent,
like
browser
type
browser
version
version
that
kind
of
thing,
so
this
namespace
would
give
us
a
place
to
put
those
components
in
the
future,
and
the
third
reason
is
that
I
think
that
making
this
change
is
not
the
not
as
horribly
disruptive
to
users
as,
like
the
other
changes
that
we've
been
discussing
with
the
ECS
alignment,
changing
HTTP,
URL
Target
those
kinds
of
things.
E
So
I
guess
just
briefly:
if
anybody
has
concerns
otherwise
in
in
just
a
time
I
just
go
to
the
you
know,
post
on
the
pr
and
I
will
what
do
they
say
relinquish
my
time,
there's
some
better
word
for
that,
but
anyway.
Thank
you
all
this
was
super
helpful.
D
Sweet
thank
you
so
much
for
that.
Okay,
in
that
case,
let's
jump
to
the
next
one,
which
is
Tristan
spam
processor,
decorators,.
F
F
F
F
I
opened
a
PR
to
bring
it
to
bring
it
to
the
top,
so
people
know
about
it
by
to
add
it,
since
it's
a
must
to
the
the
spec
Matrix.
The
discussion
yesterday
seemed
to
boil
down
to
people
thinking
that
it
shouldn't
it
should
be
removed
instead
of
added
or
it
should
be
removed
from
the
spec
entirely
and
something
else
replace
it
in
the
future.
I'm
kind
of
a
I
keep
going
back
to
the
opinion
that
we
should
expand
on
it.
F
Since
we
seem
to
all
agree,
it
is
useful
instead
of
just
removing
it
but
opened
it
either
way.
I
don't
know
we
need
to
discuss
much
more
here,
but
it
especially
people
who
weren't
there
yesterday
have
any
thoughts.
I
Have
I
have
some
feedback,
I
mean
I,
feel
there's
an
asymmetry
between
the
spam
SDK
and
the
metrics
SDK
here,
and
one
thing
we
could
try
to
do
is
actually
fix
that
asymmetry.
You
know,
metrics
has
a
much
more
developed
notion
of
a
reader
and
exporter
relationship
and
there
are
guarantees
about
what
the
exporter
is
going
to
see
from
the
span
the
metric
reader,
and
we
give
you
the
ability
to
give
every
exporter
their
own
reader,
which
and
and
some
has-
and
we
have
some
isolation
requirements
stated
there.
I
So
when
I
listened
to
the
discussion
yesterday,
all
it
sounded
like
was
we
don't
have
the
concept
of
a
reader
or
a
really
well
defined
way
to
configure
slight
variations
in
the
export
path
and-
and
we
do
in
metrics-
if
this
decorator
is
trying
to
solve
that
problem,
could
we
turn
it
into
a
span
reader
interface
potentially
and
call
this
a
major
version
bump
like
we
are
fixing
the
Spanish
span,
SDK
API
here,
because
spam
processor
was
too
weak
and
we're
going
to
do
something
better.
That's
my
question.
F
My
understanding,
the
processors
I
think
have
basically
for
the
role
of
the
reader,
like
you
were
saying
the
and
they
have
the
guarantees
about
like
they're.
Not
nothing
else
is
going
to
mutate
what
it
has
and
it
passes
it
to
the
exporter.
So
I
think
I
mean
that's
kind
of
what
is.
I
F
You
can
have
each
processor,
each
built-in
processor
has
its
own
exporter
or
kin.
If
you
assign
one
and
they
can
each
have
their
own
configuration
it's
just
whether
or
not
you
can
change
the
Span
in
them
right
now.
No
language
implementation
has
anyway,
in
the
spam
processor,
for
batch
or
simple,
to
modify
this
band
so
that
configuration
differences
are
allowed
and
they
each
have
their
own
exporter
and
exported
has
their
own
its
own
processor.
But
you
can't
change
anything
so
it
doesn't
solve.
I
F
Not
sure
what
the
appetite
is
for
major
version,
but
but
it
might
be
that
we
can't
we
just
can't
do
anything
for
now.
If,
if
people
aren't
also
don't
have
an
appetite
for
expanding
on
decorators
and
making
it
really
a
part
of
the
spec,
so
I'd
be
stuck
for
now,.
I
I
can
say
that
there
are
definitely
good
sampling
use
cases
where
you
would
want
to
both
control
the
sampling
decision
up
front
and
then
modify
the
spam
before
the
Explorer
sees
it,
and
the
only
way
we
can
do
that
today
is
by
having
a
custom
exporter.
Basically
so
I
do
support
the
the
need
for
a
solution.
D
D
Okay,
thank
you
so
much
in
that
case.
For
the
sake
of
time,
well,
we
still
have
half
an
hour,
but
still,
let's
keep
moving
tigram
renaming
logs
to
lock
screen
API.
Please.
B
Yeah
very
very
quickly,
so
the
log
Sig
is
working
on
stabilizing
the
log,
API
spec
and,
and
we
plan
to
present
to
this
sig
the
details
of
what
exactly
that
API
is
what
what
are
we
planning
to
make
stable
declare
stable.
But
this
is
one
of
the
I
guess
final
touches
before
we
do
that
we
found
that
the
name
of
the
API
is
causing
confusion.
B
So
this
is
this
PR
renames,
essentially
the
API
to
from
logs
API
to
logs
Bridge
API
to
to
better
reflect
the
intent
of
the
API,
the
target
audience
of
the
API.
It's
primarily
built
the
intent
is
to
to
allow
creating
Bridges
from
other
logging
libraries
from,
for
example,
from
log4j
to
open
climate
right,
and
so
the
pr
renames
renames
the
the
API
to
help
prevent
that
confusion.
So
please
take
a
look
if
you
have
any
opinion
about
about
the
name
or
about
generally
about
the
loads
API.
Any
other
comments
are
welcome.
B
We
will
be
presenting,
as
I
said,
the
details
of
what
this
is
to
the
specification
Sig
soon
and
and
also
presented
the
maintainers
meeting,
so
that
everybody
is
aware,
but
if
you're
interested
any
any
any
other
comments
on
the
logs
API
as
it
is
now
are
also
welcome.
B
I
I
have
the
same
type
of
comment
as
I
just
gave
for
metrics
having
a
different
Concept
in
metrics.
We
built
something
called
a
producer
API,
which
was
formerly
called
bridge
and
I.
Wonder
if
the
word
producer
might
be
the
more
logical
choice
at
this
point.
I
understand
the
reason
to
rename
it
makes
sense,
but
I
I
just
recall
deciding
to
call
it
a
producer.
B
G
One
note
on
the
producer:
the
producer
API
in
the
metrics
SDK
is
that
it
uses
the
language
of
bridge
within
it.
So
you
know
the
the
language
says:
Metro
producer
defines
the
interface
which
Bridges
the
third-party
metric
sources,
which
third
party
metric
sources
much
implemented,
so
they
can
be
plugged
into
an
open,
Telemetry
metric
reader.
So.
G
B
D
Sweet
thanks
so
much
okay.
In
that
case,
let's
move
on
the
next
one.
I
put
up
myself.
It's
basically
just
for
adding
links
after
spawns
were
already
created.
There's
initial
agreement,
but
I
want
to
discuss,
are
coming
by
by
Tyler
regarding
the
fact
that
you
know
it's
getting
harder
to
add
members
to
the
spun.
Interfacing
all
I
think
go
sorry.
Go
C
plus
plus
has
the
same
problem.
D
Although
LA
Live,
one
of
the
maintainers,
said
that
he
could
be
fine,
adding
this
yeah
in
general.
Basically,
this
could
be
become
a
blocking
issue,
because
the
messaging
working
group
needs
this.
J
J
In
fact,
we've
made
it
clear
that,
like
this
kind
of
change
may
occur
even
in
a
without
a
major
version
bump,
but
the
thing
is:
is
that
I'm,
seeing
alternatives
to
the
proposed
solution
added
here
that
don't
cause
that
problem
and
that's
my
problem
is
that,
like
those
alternatives
are
not
being
explored.
D
Yeah
there
was
this
one
where
you
actually
specify
those
spun
Links
at
when
you
end
a
span.
What
was
the
problem
with
such
approach,
for
example,
or
that
that's
still
being
researched?
Let's
say:
I.
J
Don't
know
I
mean
Josh
pointed
out
that
there's
going
to
be
sampling
issues,
but
I
also
know
that,
like
this
PR
right
here
says
that
you
shouldn't
be
sampling
on
any
links.
How
did
after
start
anyways
so
like
I?
Don't
I,
don't
know
why
the
same
couldn't
be
applied
to
the
end
spans
Josh
and
I
pointed
out
that,
like
you
could
add
it
as
an
event.
J
You
know
include
some
sort
of
option
to
an
event
to
say:
like
here's,
a
link,
the
API
wouldn't
change,
you'd
still
be
able
to
add
it
on
a
the
event
has
been
always
good
and
then
you
know
just
interpret
a
link
from
that
event.
So,
like
I,
mean
I
think
like
I
think
there's
authentically
like
there's.
There
are
different
options
that
could
be
approached
here.
K
K
With
this
opportunity,
unfortunately,
is
that
it's
I
think
it's
the
most
intuitive
form.
It
basically
makes
links
like
adding
links
the
same
way
as
adding
events
and
attributes.
Now
you
can
either
add
them
ads,
Bank
creation-
or
you
add
them
later
on
with
a
dedicated,
API
and
I.
Think
just
from
a
spec
point,
an
intuitive
point
of
view.
It
would
be
hard
I
think
to
argue
by
saying:
okay
for
attributes
and
events,
it's
like
this,
but
for
links,
it's
different.
You
add
them
on
the
end.
Call
okay,
I.
J
Think
it's
hard
I
think
I
think
that's
a
good
reason
to
justify
this
as
a
first
proposal,
but
we're
showing,
like
other
objective
reasons,
why
this
is
not
a
good
idea,
so
I
think
then
it's
also
look
at
other
approaches.
I!
Don't
think
that
there's
hard
cognitive
overhead
for
somebody
to
say,
like
an
event,
happened
and
I'm
going
to
include
that
event
with
a
link
I,
don't
think
that
it's
a
hard
cognitive
overhead
to
say,
like
there's,
no
ad
link
method.
So
how
do
I
add
a
link
after
the
Spanish
created?
J
I
I
have
a
statement
which
is
not
really
in
for
or
against
the
proposal,
but
there's
an
issue
filed
a
while
back
that
we
don't
have
much
in
the
way
of
a
trace
data
model.
We
don't
say
what
a
span
link
means
we
more
or
less
describe
how
it
behaves
and
the
way
we
describe
it
today,
a
Spam
link
only
ends
up
being
recorded
on
one
side
of
the
link.
I
I
I
have
opinions
about
how
sampling
can
and
should
treat
span
lengths,
but
it
requires
that
we
just
write
down
what
a
span
link
means
and
and
if,
if
we
ever
hope
to
have
a
Spam
link
mean
something
to
both
sides
of
the
span
link,
meaning
the
thing
you
refer
to
as
a
meaningful
event
happening
as
well
as
this
band
that
refers,
then
we
need
to
to
write
down
that
data
model
and
explain
what
happens
when
a
Spam
link
happens
when
a
Spam
link
is
created
so
that
you
can
respond
to
it,
because
you
understand
what
it
means
not
not
saying
you
should
not
sample
based
on
span
length
because
span
links,
form
extremely
reasonable.
D
I
can
see
that
as
one
of
the
issues
that
may
be
blocking
these,
or
at
least
it's
a
required
follow-up,
but
in
general,
one
of
the
things
I'm
curious
is
about
adding
members
to
existing
interfaces.
D
Yeah
I,
don't
know
like
I
I
can
understand.
I
can
totally
see
we
refusing
to
change.
Api,
like
you
know,
like
change
the
spot
name
or
you
know
something
that
actually
changes
API
for
for
everybody,
but
adding
members,
yeah
I,
don't
know,
I
mean
I'm,
saying
this,
because
I
can
totally
see
in
one
year
or
two
years,
adding
more
members
to
do
the
spanner
Tracer
interface
and
that's
actually
a
real
possibility.
And
what
will
we
do
by
then
I?
Don't
know
whether
that
works.
D
Well,
actually,
the
working
group,
the
messaging
one
we
consider
a
few
of
them,
the
one
that
wasn't
based
on
what
I
hear
totally
considered,
was
adding
them
at
any
time
optionally,
instead
of
just
selling
them
well,.
J
Like
that's
great,
could
you
also
achieve
this
by
using
the
event,
because
that
would
be
less
turned
and
and
I
think
that's
that's
the
pushback
I'm
asking
for
and
I'm
asking
and
I,
don't
think
that
it's
being
receivable
I
think
it's
just
being
saying
like.
Well,
that's
just
the
language,
so
it
doesn't
really
matter
but
like
it
does
like
this
is
what
a
specification
is
for.
It's
the
collaboration
of
all
these
languages.
To
try
to
you
know,
evolve
together
and
I'm.
Saying
like
we
have
a
problem,
and
we
do
this
better.
Yeah.
D
I
mean
you've
been
the
one
was
indeed
discussed,
but
not
here.
It
was
this
course
in
the
working
group.
Okay
and
then
I
have
a
proposal
or
some
idea.
So.
I
So
I
think
the
for
me.
The
Surface
problem
with
putting
it
in
the
and
options
is
that
what
I
was
saying
earlier
is
I.
What
does
it
mean?
I
need
am
I
going
to
have
to
put
that
span
Link
in
end
of
both
spans
they're
linked
I
I.
Don't
want
to
have
to
write
two
spam
link
operations.
There's
one
link
between
two
spans,
so,
whether
I
put
it
on
the
a
span
or
the
B
span.
I
should
only
have
to
create
one
link
and
and
the
way
it
putting
in
the
end
options.
I
D
Okay,
okay,
so
basically
yeah,
based
on
what
you
said,
yeah
I
would
say
that
adding
a
link
at
spent
in
time,
it's
probably
like
not
something
we
can
consider
so
yeah.
Okay,
in
that
case,
let's
continue
talking.
D
Yeah
I
think
that
the
problem
there
is
that
I
I
find
two
solutions,
which
is
the
event
one
which,
which
we
discussed
already
we
can.
We
may
discuss
it
again,
listing
again
all
the
pros
and
cons
or
basically
breaking
the
span
interface.
The
factor
you
know
so
is.
D
A
We
consider
this
as
a
mitigation
for
null
and
later
we're
saying,
like
we're
ready
to
bounce
the
major
version
across
the
sky
kind
of
language
implementations.
Then
we
should
clean
this
up,
or
this
is
basically
saying
like
no.
We
should
just
use
this
event
thing
to
like
shove,
some
link,
specific
information
and
stay
with
that
direction
from
whatever.
J
I
mean
that's
a
good
question:
Riley
I
think
I
I,
don't
see
why
staying
with
the
lynx
forever
isn't
an
inappropriate
thing
given
like
adding
a
link,
you
could
also
annotate
that,
with
the
reason
it
was
added,
it
has
some
sort
of
classification
identifying
description
with
it.
It
also
helps
distinguish
between
the
things
that
you
linked
knowing
they
relate
at
the
start
versus
things
that
you
linked
ad
hoc.
As
the
span
progressed.
They
maybe
wanted
to
be
treated
differently.
A
Or
maybe
like
like,
do
we
even
think
at
some
point
we'll
go
to
the
extreme
situation
where
Spence
and
links
can
be
animated
independently,
so
we
can
emit
two
spans,
and
after
one
year
we
decided
okay,
those
two
spends
are
actually
related.
Let's
just
make
another
spending
using
a
dedicated
API
not
attached
to
any
spend.
So
so,
if,
in
the
future,
we
believe,
like
links
should
be
very
decoupled,
then
it
might
affect
how
we
think
about
this
problem
now
just
want
to
avoid
us
trying
to
shove
something
to
the
existing
one.
J
I
mean
that's
kind
of
why
I
was
thinking
originally
of
the
spand
end
as
well,
because
you
could
add
the
spand
end
right
now.
Totally
fine
like
you
could
just
say
that,
like
you
know,
it's
a
non-breaking
change
to
add
something
at
the
end.
But
then
what
Josh
is
saying
is
like.
If
there's
like
some
sort
of
sampling
API
in
the
future
that
we
need
this,
then
you
could
always
reevaluate
that
choice
and
add
it
as
an
event
or
or
if
we
really
decide
that
we
need
it
as
a
interface
to
the
span.
J
C
I
I'm,
putting
Riley's
concern
is
that
you
could
imagine
a
logging
API
at
some
point
where
you
you,
let's
suppose,
I'm
I'm,
treating
some
resource,
that's
being
taken
by
different
requests
and
each
request
has
a
span.
So
at
the
moment,
when
some
sort
of
contention
happens,
do
I
need
to
put
an
event
on
two
spans
or
do
I
need
to
put
one
log
event
out
to
say
there
was
a
contention
between
span
a
and
span
B
now
I
would
argue
that
a
statement
like
there
was
contention
between
Spanish
and
span
b
is
all
the
things.
I
It's
a
log
statement.
It's
an
event
on
span
a
it's
event
on
span
B.
It's
also
a
link
on
spin,
a
it's
a
link
on
span
p.
So
so
one
thing
happened
though,
and
we
could
add
a
new
event
for
that
in
the
future.
But
that's
going
to
raise
the
same
questions
about
major
version,
bumps
I
think
so
we're
back
at
the
same
place.
A
J
D
Okay,
yeah
I,
don't
know,
I
will
talk
to
you
honey,
so
maybe
we
can
re-massage
this
PR.
These
calls
whatever
options
there.
If
anybody's
interested
I
guess
we
can
disclose
that.
Maybe
next
right
well
I,
don't
know
how's
your
agenda
looking.
If
not,
we
can
discuss
that
offline
yeah.
D
Let's
see
honestly
the
the
event
alternative
for
me
has
been
like
I
feel
like
a
hack
and
something
like
can
you
match
in
there
you
we
put
in
there
everything
that
we
don't
want
to
have
to
respond
interface,
which
couldn't
be
great,
but
let's
see
what
can
be
done.
Let's
continue
discussing
that
offline,
I,
think
that
needs
more
time
and
yeah.
So,
let's,
let's
take
that
the
rest
of
line.
D
Thank
you
so
much
for
that.
Now,
for
the
sake
of
time,
let's
go
to
the
last
one,
which
I
suspect
will
take
a
little
while
to
discuss
Josh
well.
I
I
hope
not
I
just
wanted
to
give
everyone
a
reminder
of
this
PR
which
I
presented
here.
Maybe
five
weeks
ago,
I
said
it
was
medium
priority
and
I
came
I'm
now
back
with
some
results.
I
did
do
a
prototype
of
this
idea
that
was
discussed
five
weeks
ago.
The
idea
is
I.
Think
holding
us
to
a
pretty
high
standard
is
fairly
complex,
but
it's
not
so
bad.
I
If
you,
if
you
look
at
it
closely,
I
found
a
way
to
make
it
reasonable,
I
think
so,
if
you
scroll
all
the
way
down
to
the
end,
Carlos
and
I
just
want
to
say
the
reason
why
I
think
this
is
important
to
look
at
now
is
my.
I
It's
been
my
impression
that
we're
very
close
to
calling
metrics
1.0,
especially
with
the
go
SDK
being
very
close
to
its
beta
I,
would
like
to
see
us
be
done
with
open,
telemetries,
1.0,
metrics,
spec
and
not
change
it
much
more,
but
I
think
this
issue
at
least
has
been
sticking
out
for
a
long
time.
I
So
that's
why
I'm
working
on
it
and
I'm,
hoping
that
you
all
agree
and
if
not,
we
should
discuss
what
we
need
for
metric
stability
next
week,
if
you're
at
all
closest
issue,
please
read
my
final
big
block
comment
here:
is
that
I
found
a
lot
of
things
I
didn't
want
to
see,
but
ultimately,
what
we're
aiming
for
is
that
you
get
a
really
graceful
failure
mode
when
you
reach
your
maximum
cardinality
and
graceful
can
be
defined
a
lot
of
ways.
I
My
final
take
on
this
was
that-
and
you
know
the
the
there's
an
issue
open
that
was
calling
for
a
circuit
breaker.
The
issue
that
this
is
addressing
the
the
idea
of
using
the
word
circuit,
breaker
to
me
ended
up
being
really
important.
I
It's
this
idea
that
I
don't
want
this
limit
to
be
so
hard
and
fast
that
I
have
to
go
to
extra
trouble,
meaning
extra
allocations
or
extra
synchronization
I
just
want
to
break
as
soon
as
you
get
too
close,
or
at
or
reach
that
limit
and
and
break
in
a
in
a
well-defined
way.
So
the
well-defined
way
that
I
found
I
found
myself
trying
to
write
a
specification.
I
I
The
other
parts
of
this
are
saying
that,
like
it
doesn't
immediately
fail
circuit
breakers
fail
as
soon
as
you've
observed
the
the
limit
being
exceeded,
not
like
immediately
synchronously
at
the
moment.
So
it
means
that
all
I
can
promise
when
these
circuit
breaker
events
happen,
because
you
reach
Max,
cardinality
or
exceed
Max
cardinality.
Is
that
the
SDK
will
stop
allocating
memory
for
that.
I
G
G
G
Was
just
going
to
say
that
you
know
a
couple
of
weeks
ago
we
were
talking
about
when
the
when
the
the
threshold
is
exceeded
to
collapse.
All
of
the
series
into
one-
and
you
know
I,
was
thinking
about
that
more
in
the
complexities
associated
with
merging
all
those
series
and
potential
synchronization
required
I
like
how
you
phrased
this
a
lot
better.
Where
you
know,
once
you
exceed
the
threshold,
a
single
new
series
called
overflow
is
created,
and
you
know
representing
the
like.
All
all
series
that
exceed
the
threshold.
J
D
L
Yeah
I
just
want
to
add
this
is
super
important
in
light
of
the
cve
that
we
just
had
last
week
in
the
go
library
because
of
runaway
cardinality
from
HTTP
Target
I
think
this
would
have
made
that
effectively
a
non-issue.
D
D
If
not,
let's
go
back
to
reviewing
stuff-
or
you
know
like
like
the
stuff
that
trust
presented
or
just
go
for
a
couple
of
coffee,
Happy,
Valentine's
Day
by
the
way
stay
safe
and
talk
to
you
soon.
Thanks.