►
From YouTube: 2021-11-16 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
Okay,
next
time,
so
I
was
doing
some
cleanup
earlier
just
to
get
the
milestones
ready,
because
we
are
still
planning
to
do
one
two
two
one,
sorry
one
day,
two
by
end
of
this
month,
so
our
first
blocker
is
unblocked,
the
stable
release
of
diagnostic
source
is
done.
The
open
elementary
spec
is
expected.
As
of
today.
A
It
is
still
expected
to
be
marked
stable
on
november
30th,
so
we
should
be
able
to
release
metric
support
in
one
dot
in
either
on
november
30th
or
like
a
couple
of
days
later,
but
not
not
more
than
that.
A
But
to
do
that,
I
basically
moved
some
of
the
advanced
features
in
the
views
and
take
some
glass
to
the
later
milestone.
A
So
I
created
1.3
tagged
it
with
two
months
from
now
I
mean
three
months,
but
I
consider
december
most
people
would
be
on
vacation,
so
there
wouldn't
be
enough
people
to
approve,
so
it
basically
has
like
leftover
from
the
sdk,
which
we
are
like
not
handling
in
one,
that
includes
using
views
to
change
applications,
supporting
additional
tags
from
baggage
and
adding
etcetera.
So
these
three
will
not
be
part
of
one
door
too,
and
I
also
created
another
issue
explicitly
tracking
the
prometheus
one,
because
we
don't
have
the
prometheus
spec
stability.
A
You
can
see
the
suspect
for
prometheus,
it's
still
being.
There
are
actually
pull
request,
which
is
making
it
happen,
but
I
don't
think
it
would
be
happening
as
a
stable
one
by
the
same
name
as
the
sdk.
So
what
that
really
means
is
when
we
do
the
1.2
release,
it
will
only
contain
the
api
and
sdk
the
prometheus
would
be
still
marked
as
like
1.2,
some
like
beta
or
rc
version.
A
It
won't
be
stable
because
I
don't
expect
it
to
be
stable
on
same
day
as
the
sdk,
because
there
are
still
quite
a
large
number
of
open
issues,
so
that
would
mean
the
api.
The
1.0
release
only
contains
the
api
industry
gaming,
technically
just
sdk,
because
api
is
already
done
on
number
nine
from
the
donating.
A
Yeah,
it
should
be
because
let
me
quickly
open
the.
A
Otp
protocol
itself
is
marked
stable,
so
this
I
expect,
would
be
marked
stable
along
with
the
sdk,
because
the
protofiles
we
go
to
product
files.
A
Should
be
unlocked
from
the
protofire
itself,
so
bearing
any
last
minute
changes
in
the
spec
about
otlp,
we
should
be
good
to
go,
but
I'll
keep
a
close
eye
like
if
there
is
anything
which
requires
us
to
hold
off,
then
we
will
hold
off,
but
otherwise
we
should
be
good
to
go
like
alan.
Is
there
like?
Was
there
anything
in
otp
in
particular,
which
you
are
concerned.
C
Nope,
I
just
wanted
to
confirm
that
understanding
that
I
I'm
not
aware
of
any
concerns.
I
yeah.
A
A
Which
is
not
stable
is
something
which
we
don't
support
right
now,
which
is
the
histogram
the
exponential
one.
So
that's
why
the
overall
status
of
this
talk
is
mixer,
but
everything
else,
the
metric
point,
wage
histogram
is
stable,
except
the
exponential
one
which
we
don't
support
anyway,
at
least
in
1.2.
A
We
should
be
unlocked
from
the
data
model
site,
but
this
is
good
point
I'll,
just
clarify
whether
we
need
to
specifically
wait
for
it
for
tlp.
A
If
there
is
a,
if
there
is
no
movement
in
this
status,
then
we
have
to
wait
for
otlp
to
be
delayed.
I
mean
until
this
becomes
stable,
but
I'm
not
aware
of
any
active
discussions
in
the
matrix
meeting.
So
maybe
this
would
be
considered
as
part
of
the
sdk
release,
because
without
any
exporter
at
all,
it
would
be
like
pointless
to
release
an
sdk,
almost
pointless
I'll,
just
clarify
in
the
next
spec
meeting
to
see
whether
this
would
also
be
stable
by
end
of
month,
okay,
okay,
yeah.
Now.
A
Having
said
that,
we
still
have
like
some
critical
issues
to
be
addressed,
so
I
think
I
have
it.
Almost
all
of
them
are
tagged
with
1.2,
so
we'll
be
using
the
1.2
milestone,
2
release,
I
mean
to
indicate
the
things
which
we
need
for
1.2
and
we
use
1.3
for
under
there,
the
required
for
gs.
It
may
or
may
not
make
sense
anymore,
because
this
was
created
in
the
1.2
time
frame.
So
it
may
not
really
make
sense.
A
We
can't
really
use
the
milestones
alone
to
indicate
which
ones
are
required,
so
we
want
to
like
quickly
go
over
this
today,
because
some
of
the
things
are
like
very
important.
So
let
me
go
from
the
back.
I
mean
bottom
up.
This
is
just
a
like
update
to
the
community
like.
When
are
we
going
to
release
it?
So
no
action
item
is
needed.
This
is
something
which
was
opened
in
the
very
early
stage,
but
we
still
need
to
close
on
it.
A
So
basically,
when
metric
tags,
so
the
keys
and
names
keys
and
values
are
currently
exposed
as
an
array
in
the
metric
point,
so
this
issue
is
open
to
track.
Should
we
make
it
a
I
list
instead
of
an
array
so
probably
like
I'll
reach
out
to
michael
who
originally
writes
this
and
see
if
there
is
anything
which
we
can
do
there
and
close
on
it
relatively
easy
to
fix,
but
it's
important
because
it's
part
of
the
public
epa,
then
these
two
issues
are
really
related
and
alanine
is
actively
working
on
the
cleaning
up
part.
A
So,
as
a
summary,
what
we
are
currently
experiencing
is,
if
you
ever
use
a
particular
key
value
pair
combination
and
even
if
you
don't
use
it
for
like
rest
of
the
time,
it
still
takes
up
memory
holding
one
metric
point
to
be
only
used
for
that,
which
means,
if
there
is
a
total
cap
on
the
overall
metric
points
and
any
unused
metric
points
are
like
not
reclaimed,
so
that
would
really
restrict
the
ability
for
users
to
limit
their
total
number
of
metric
points.
A
Closely
related
to
that
is,
we
currently
have
a
hard
coded
value
for
maximum
metric
points
in
its
2000.
A
So
two
things
for
this
issue
to
be
close
one
is,
we
probably
want
to
expose
some
ap
for
users
to
change
it
and
we
need
to
decide
on
what
is
the
default,
so
these
two
are
related
and
this
is
actively
being
worked
on.
So
as
soon
as
we
close
on
this,
we
should
be
able
to
tackle
the
next
one,
the
ability
to
support
multiple
readers.
A
I
think
it's
still
p2
it's
important
for
some
users,
but
not
not
that
many
users
were
concerned
with
this,
but
lukas
already
has
a
pr
out
for
it.
So
I'm
hoping
that
it
should
be
relatively
straightforward
to
get
it
merged
and
handling
disposal
of
instruments.
So
this
is
partially
done
and
it
has
like
close
ties
to
the
ability
to
forget
metric
point
because
when
an
instrument
is
disposed
or
rather
a
meter
is
disposed
which
calls
disperse
on
the
instruments.
A
A
Let
me
come
back
to
this
one.
A
little
later
I
mean
towards
the
end,
because
I
just
want
to
clean
all
the
metric
lighted
one
first
and
then
there
is
a
little
bit
of
validations
done,
so
mysql
is
doing
some
pr.
I
think
it's
not
done
because
we
want
to
validate
that
for
counter
the
value
is
positive
and
for
histogram
there
is
no
validation,
but
if
the
value
is
negative,
we
should
not
incorporate
that
into
so
it's
like
very
small
thing.
The
spec
is
already
very,
very
clear.
A
It's
just
an
internal
implementation
thing,
so
this
is
also
very
related
to
the
metric
point
cleaner,
because
right
now,
since
we
are
actively
keeping
metric
points,
even
if
now
update
so
once
we
do
the
cleanup,
this
issue
would
be
like
automatically
resolved,
because
if
the
metric
point
is
not
active,
we
won't
be
exporting
it.
A
This
is
just
cleanup
which
has
already
added
the
cas
to
support
asp.net
core
6.0
and
x
in
general,
but
there
are
like
few
hardcoded
things
which
were
done
at
that
time,
because
0.6
at
that
time
was
not
installed
in
the
ca
machine.
So
it's
slightly
easy,
but
it's
just
a
like
infrared
lighted
thing.
A
This
is
another
one
about
metric
configuration
and
validation,
so
there
are
like
tiers
already
doing
that,
so
it
should
be
relatively
easy
and
it
should
be
closed
in
time.
These
two
are
like
general
things.
It's
like
catch-all,
so
we
recently
enabled
public
aphro.
A
So
now
we
need
to
review
all
the
public
api
in
the
metric
thing,
because
we
have
quite
a
large
number
of
public
api
make
sure
we
are
not
exposing
anything
which
is
not
really
required
and
then
just
a
catch-all
item
for
all
the
tools,
because
there
are
a
lot
of
to-do's
in
the
metrics.
A
A
So
that's
the
reason
why
we
decided
not
to
merge
any
new
features
to
the
metrics
specifically
because
when
we
are
able
to
release
this
table,
we
don't
want
to
be
like
adding
new
features
which
can
potentially
affect
the
stability
and
then
the
last
one
this
one
this
is
not
related
to
matrix.
So
let
me
come
back
to
it
in
a
few
seconds
so
before
that
like
are
there
any
questions
on
the
1.2
release?
A
A
Now,
let's
maybe
this
is
vishwash.
Can
you
walk
us
through
this
issue?
Actually,
this
is
not
the
issue
which
you
want
to
discuss.
I
think
the
one
which
probably
a
different
issue-
okay,
come
on.
A
It
should
be
here.
Sorry,
I
probably
linked
the
wrong
issue,
so
I
will
update
the
milestone
to
reflect
this
one.
So
vishwash,
can
you
just
quickly
walk
us
through
the
issue
and
the
workarounds
or
proposals
you
have,
so
we
can
make
an
informed
decision.
D
Yeah
sure
so
so
this
is
about
the
new
api
changes
in
activity
class
starting
diagnostic
source
version,
6.0,
so
starting
6.0
version
activity
class
has
introduced
two
new
properties,
status
and
stylus
description
and
build
with
the
activity
class
as
opposed
to
what
we
support
today.
D
So
users
can
use
a
set
status
on
the
activity
and
then
can
set
the
state
status
on
as
a
activity
status
code
and
description,
so
the
behavior
is
same
as
we
do
right
now
in
the
api
using
activity.
Extensions
in
case
of
error,
the
description
is
valid.
Otherwise
the
description
is
not
valid
for
other
two
status
quo,
meaning
unset
and
status
quo.
Okay.
D
D
So
we
we
need
to
have
a
way
in
exporters
to
understand
those
new
properties
on
activity
and
then
set
the
stat
statuses
on
that.
So
I
have
created.
So
there
are
two
possible
ways
that
I
have
created
here.
One
is
we
go
and
update
all
the
exporters,
meaning
like
there
are
two
two
ways
which
we
will
do
one.
D
We
will
look
up
the
the
properties
on
activity,
status
and
status
description
and
if
those
are
not
set,
we
will
fall
back
to
the
the
tags,
hotel
status
code
and
hotel
status
description.
D
D
D
So,
instead
of
changing
all
the
exporters
to
to
look
up
the
the
properties
on
activity,
we
we
do
some
change
in
the
sdk
via
switch,
which
will
be
on
by
default,
meaning
that
if
the
custom,
customers
or
users
are
using
the
older
way,
we
would
look
up
those
tags
and
set
the
properties
on
activity,
and
this
will
be
on
by
default.
And
then
we
on
the
exporter
side,
we
only
look
up
the
the
properties
on
activity
so
that
we
don't
have
to
update
all
the
exporters.
D
We
just
do
one
change
in
sdk
and
the
exporters
like
we.
We
update
the
exporters
just
to
look
up
the
properties
on
activity
instead
of
the
tags
and
again
the
the
recommendation
would
be.
The
same.
D
Users
should
migrate
to
the
new
api
for
setting
statuses
and
we
mark
the
set
status
in
api
extensions
as
obsolete
and
then
ultimately
remove
it
in
the
next
major
version
bump.
So
this
is
the
second
proposal
I
will
like
here.
I
am
using
that
in
the
simple
activity,
export
processor
and
patch
activity
export
processor-
if
you
see
like
so.
D
If
we
take
an
example,
so
we
just
set
a
switch
which
will
be
on
by
default
if
the,
if
the
user
is
using
the
newer
way
already,
they
can
turn
off
this
switch
so
that
we
don't
iterate
through
the
activity
tags
to
set
properties,
because
the
properties
will
already
be
set,
and
we
set
the
properties
here.
D
So
this
is
the
wave,
however,
like
it's
just
talking
to
sejo,
and
we
we
found
an
issue
with
this
like
the
there
could
be,
so
this
only
works
in
case
of
the
the
simple
and
batch
activity
processor.
If
a
user
is
using
their
own
custom
processors,
we
won't
be
able
to
do
this,
so
if
they
have
their
own
custom
processor,
with
the
the
exporters
that
we
have,
it
will
still
break
so
yeah
here,
I
don't
think
like.
D
A
Yeah,
so
the
advantage
of
this
proposal
is,
we
don't
need
to
do
any
fallback
mechanism
index
individual
exporters.
They
will
only
look
at
the
status
and
status
description.
Only
the
direct
native
field
in
the
activity
and
the
responsibility
of
operating
that
is
either
user
directly
doing
it
or
if
the
user
uses
the
old
way
and
the
sdk
would
if
they
see
the
activity
tags
are
set
for
the
status
they'll
copy
that
status
into
the
native
field,
so
exporters
code
can
be
relatively
simple.
D
For
this
approach,
so
the
other
one
was
like
we
could
extend
this
like
since
the
activity
like
the
apis
are
getting
updated
like
in
future
releases
with
link.net
7.
If
there
are
any
such
changes,
we
can
make
use
of
this
setup
and
then
introduce
more
switches
in
future.
Oh
yeah,
that's
about
the
storage
yeah.
E
That's
the
big
one
for
me
is.
I
was
just
trying
to
think
of
something
we
could
put
in
place
that
will
allow
us
like.
I
brought
up
the
the
exception.
The
record
exception
right
now.
That's
also
an
extension
and
there's
an
issue
in
run
time.
You
know
to
build
it
natively
on
activity,
so
we'll
have
the
same
problem
in
the
future.
E
A
E
Well,
the
original
suggestion
I
had
was
we
go
one
base
class
further,
so
we
put
it
on
the
generic
base
exporter,
it's
a
type
t,
so
you
would
have
to
do
like
you
know.
If
t
is
activity,
some
instance
name
and
then
put
it
there,
so
I'm
pretty
sure
everyone
that's
building
an
exporter
would
have
to
derive
from
base
exporter
somewhere
in
their
chain
right,
yeah.
A
A
E
A
So
that
would
be
okay.
This
is.
E
A
E
A
A
A
You
cannot
do
that
in
the
processor.
I
believe,
because
processors,
the
users
can
add
their
own
processor
and
the
status
itself
could
be
set
in
like
one
of
the
processors.
So
if
it
is
happening
like
later,
we
wouldn't
even
know
that
the
status
was
let
set
by
the
user.
Yes,
which
makes
me
wonder
like
the
only
option
would
be
to
do
that
in
where
is
our
document
for
exporter?
Is
this
the
one
yeah
so
exporter?
A
Oh,
there
is
a
thing
called
base
exporter.
Maybe
we
should
be
able
to
do
that
in
the
base
exporter.
What
do
we
have
in
base
exporter?
E
A
E
E
A
So
I
don't
see
like
any
easy
way
of
like
putting
that
logic
upstream,
like
anywhere
in
the
sdk,
based
on
what
I
just
saw
like
it
looks
like
we
have
to
do
that
in
individual
exporters.
A
I
mean
we
have
to
like
solve
this
like
really
soon,
because
otherwise,
when
people
use
the
diagnostic
screen
package,
six,
they
would
be
inclined
to
use
the
activity
dot
set
status
than
at
one.
They
would
be
surprised
to
see
it's
not
supported
in
the
exporter.
So
like
michael,
what?
What
do
you
think
of
the
original
one
then,
like
modifying
individual
exporters,
to
like
look
for
attacks
in
the
original
place
as
before
and
use
a
fallback
to
look
at
the
activity
status.
E
A
Yeah,
at
least
we
cannot
do
that
in
a
way
which
ensures
everyone
gets
it
like.
We
can
do
it
in
such
a
way
which
helps
the
people
I
mean.
E
We
can't
we
can't
do
it
a
hundred
percent,
because
yeah
people
can
make
custom
processors,
but
I
feel
like
we're
getting
into
like
edge
conditions
of
edge
conditions
like
if
people
are
making
their
own
custom
processors
and
they're
not
deriving
from
ours
and
they're,
manipulating
status
code
in
their
custom,
processor
they'll
run
into
dragons,
but
is
that
is
that
common
like?
If
we
do?
What?
What's
on
that?
Second
pr
will
that
take
care
of
you
know
99
of
the
use
cases
out
there.
A
Yeah,
I
think
we
should
do
it
in
not
the
batch
and
simple
like
it
should
do
on
the
base
class
of
this,
so
that
would
cover
like
more
scenarios
like
you,
you
are
proposing
right
like
if
you
do
it
in
the
base
class
of
these
classes,
it
would.
E
E
D
E
It
could
break
yeah,
but
it
also
if
the
user
is
savvy
and
they
go,
they
understand
the
situation
and
they
turn
this
off.
Then
it
will
be
more
optimal
than
the
first
pr,
because
it's
going
to
loop,
it's
going
to
check
activity
status
and
then
loop
tags.
So
we
could
potentially
avoid
some
of
that
yeah.
Okay,.
A
Yes,
so
so
let
me
rephrase
why
I
understood
so
with
this
approach.
We
would
enable
a
feature,
fly
kind
of
thing
static
and
it
would
be
on
by
default,
which
basically
means
we
would
iterate
through
the
activity
tags,
irrespective
of.
A
And
the
exporter
would
be
like
relatively
easy.
It
just
looks
at
the
status
now
once
the
user
has
switched
to
using
the
activity
status.
They
still
like
this
behavior.
This
kind
of
is
no,
but
even
though
we
iterate
through
the
tags,
we
won't
find
any
tags
with
status
there.
So
nothing
happens
here,
but
the
exporter
sees
the
status
being
set
natively
on
the
activity,
so
in
that
case
it
works,
except
that
there
is
a
performance
penalty
of
iterating
the
tax.
A
Now
third
is
most
nice
scenario,
where
the
user
realizes
okay,
I
should,
if
I'm
setting
status
date
directly
on
the
activity,
then
I
should
go
and
turn
this
feature
flag
off,
so
that
we
don't
have
this
penalty
and
exporters
would
continue
to
work.
So
that's
the
most
happy
pack,
okay,
it
seems
reasonable.
A
A
Even
the
benefits
are
like
we
have
a
much
simpler
exporters.
I
think
that's
a
reasonable
thing
to
do.
Okay,
so
michael,
could
you
like,
like
review
this
beer?
I
think
let
me
show
you
still
how
to
try
to
move
to
this.
A
D
E
A
Oh
sorry,
I
I
I
think,
I'm
not
clear
so
let.
E
Me
go:
go
up
to
the
the
next
class,
the
simple
or
the
batch
export
processor.
Do
they
call
the
base.
E
E
E
A
Yeah,
so
it
looks
like
with
like
relatively
small
changes
to
the
pr.
We
should
be
able
to
do
that
in
the
upstream
sdk.
So
all
we
need
is
to
make
sure
like
it's
like.
It's
very
clearly
documented
that,
like
if
you
are
using
1.2
and
using
diagnostics
or
six-
and
you
have
three
options
like
you-
continue
to
use
the
activity
dot
set
status
from
the
extension
method,
which
is
storing
it
on
tag.
It
would
work,
but
it's
inefficient.
A
E
Take
and
we
could
you
know
we
could
prob
my
I
can
guide
read
me
that
says
you
know
if
you're
going
from.net
five
to
dot
net
six,
here's
the
new
stuff,
here's
what
we
have
done,
here's
your
options
and
what
you
should
do,
I
see
so
make
it
more
discoverable.
A
Okay,
so
you're
basically
suggesting
like
some
dope
like
somewhere
here,
not
really
tied
to
any
exporter
which
says
like
migrating
from
dot
net
five
to
six.
Something
like
that.
Is
that
what
you
are
referring
to.
E
C
A
Yeah
that's
reasonable,
so
I
think
some
immediate
action
item
is
like
which
way
if
you
would
update
the
pr
to
move
the
check
one
level
in
the
base
class,
so
we
would
cover
more
scenarios
and
number
two
we
need
to.
We
still
need
to
update
the
exporter
to
look
for
activity
in
sorry
activity,
dot
status
in
all
the
exporters
and
modify
the
dock.
We
have
a
talk
about
like
how
do
you
extend
the
sdk
to
right
exporter?
A
So
it
might
be
better
to
call
it
out
here,
because
status
is
explicitly
in
activities,
probably
not
obvious,
so
that's
but
relatively
low
priority
and
then
finally,
one
daw,
which
would
cover
at
least
the
general
for
now
it
will
only
cover
the
status
and
we
could
mention
that
the
metrics
are
also
supported
in
the
dot
methods
that
can
be
a
placeholder
which
we
can
add
for
more
and
more
things
as
dotnet
evolves.
A
Okay,
that
seems
reasonable.
I'll
update
the
notes
to
just
summarize
what
we
discussed
right
after
the
meeting
so
which
was
like.
Are
you
clear
on?
What's
the
next
step
to
be
done?
Oh.
D
Yeah
yeah,
I
think
I
am
I'll,
try
it
out
and
I'll
update
the
vr
just
one
more
quick
question:
the
changes,
the
switch
and
the
the
changes
that
I
have
should
it
be
part
of
the
api.
I
have
put
that
in
sdk
right
now,
but
I.
A
Oh
okay:
let's
quickly
discuss
that
also
okay,
so
where
is
that
switch
coming?
Michael,
do
you
have
any
thoughts
on
that?
I
think
we
for
the
propagators
we
have
it
on
apa,
but
the
only
way
to
set
that
is
by
using
the
sdk.
If
I
remember
correctly,.
E
A
Yeah,
so
this
is
how
we
have
it
for
the
propagators,
so
we
could
do
it
similar
to
propagates,
because
this
is
only
one
which
feels
like
naturally,
related
to
the
one
which
we
are
talking
about,
something
which
affects
the
entire
sdk
in
a
static
way
like
not
specific
to
an
individual
provider
instance.
A
A
Yeah
yeah,
what
we
would
do
in
that
case
would
be.
We
take
the
one
from
the
native
one,
the
activity
dot
status,
one
because
even
with
the
switch,
we
only
do
it.
If
it
is,
let
me
take
it
if
it
is
not
on
the
if
it
is
not
set
on
the
original
status.
A
So
if
it
is,
if
the
user
has
like
activity
dot
set
status
set
to
anything
other
than
handset,
then
we
would
just
not
even
go
into
this
app.
C
And
so
I'm
just
thinking
this
through
so
the
let's
say
they
they
turn
the
switch
off.
Will
the
tags
that
are
set
by
the
library
author
still
come
through
or
will
they.
E
So
it'll
allen
will
it'll,
go
it'll,
show
up
as
tags,
but
what
we're
doing
is
jaeger
and
zipkin
have
their
own
error
flag
that
like
causes,
you
know
the
span
to
color
in
red,
so
we
look
at.
We
try
to
find
our
open
telemetry
status
and
then,
if
we
determine
its
error,
we
add
the
extra
zipkin
or
jager
behavior.
E
A
C
E
A
A
Yeah
but
then
there
is
no
yeah,
so
when
you
upgrade
from
like
1.1
to
1.2,
the
extension
method
would
be
just
a
wrapper
around
the
native
activity
status
yeah.
That
would
avoid
this
issue
vishal
and
bottom
like
if
some
instrumentation
library
is
still
using
the
old
one,
they
don't
need
to
do
any
special
step
to
migrate.
They
would
be
automatically
migrated
when
the
sdk
is
updated.
C
We
are
doing
a
transformation
to
our
own
data
model
from
the
otlp
data
model
and
if
it's
not
then
set
as
a
first
level
property
like
an
otlp
data
model,
then
we
might
not
behave
correctly.
Got.
A
It
yeah,
so
I
think
the
only
change
would
be
like
instead
of
doing
this,
obsoleting
we'll
do
like
mark
it.
As
I
mean
we
do
change
the
behavior
to
set
it
on
the
activity
dot
status
directly.
A
I
was
thinking
through
that
like
would
that
be
a
breaking
change
if
they
just
update
the
api
and
they
are
still
on
the
old
version
of
the
sdk,
but
that's
not
possible,
because
when
you
install
the
new
sdk,
you
would
automatically
get
the
new
version
of
the
api
as
well,
and
the
new
version
of
the
sdk
by
default
knows
how
to
nostril
look
for
activity
dot
status
directly.
A
Yeah,
that's
a
good
call
out
yeah.
I
think
we
switch
like
when
you
update.
You
can
update
the
statement
to
say
that
we
can
continue
to
offer
this
extension,
but
the
body,
the
body
of
the
extension,
would
be
modified
to
store
the
status
natively
instead
of
tags,
and
specifically,
this
is
for
those
instrumentation
libraries
who
are
extremely
using
the
extension.
So
they
don't
need
to
like
do
anything
to
get
benefit
from
this.
D
Sure,
but
just
to
call
it
out
that
could
only
help
who
are
using
such
status
method.
A
Yep
yeah,
I
think
maybe
like
that's
the
last
thing
which
I
wanted
to
discuss,
so
maybe
I'll
quickly
ask
something
about
the
pr
which
alan
has
and,
like
I,
I've
been
like
hydrating
on
top
of
that,
so
not
sure
like
which
one
should
I
open,
maybe
I'll,
just
open
mine,
and
if
you
don't
mind,
it's
basically
copying
all
the
content
from
like
other
two
pr's.
A
They
added
like
something
on
top
of
that.
So
it's
it
appears
as
my
name,
but
it's
really
aligned
but
anyway,
so
yeah.
A
So
basic
number
one
issue
which
we
are
trying
to
solve
is
like
if
you
are
using
delta-
and
we
have
this
dictionary,
where
we
keep
track
of
all
the
non-key
value
pairs
and
it's
mapped
into
a
number,
and
that
number
is
an
index
in
the
array
which
points
to
one
of
the
instances
of
metric
points.
So
what
we're
trying
to
do
is
after
this
is
as
of
today,
we
are
only
concerned
with
the
delta,
because
cumulative
the
user
is
anyway
deciding
to
have
cumulative.
A
So
we
kind
of
decided
for
now
that
they'll
pay
the
cost
we'll
keep
that
state
from
the
beginning
of
the
process
forever,
but
for
delta,
like
based
on
the
spec
supplemental
guidance,
we
technically
can't
forget
everything
which
happened
right
before
the
collect,
but
we
are
not
that
aggressive.
We
are
just
like
like
after
every
collect.
We
move
it
into
a
intermediate
state
like
candidate
for
removal,
something
like
that
and
if
it
is
still
unused
in
the
next
collect,
which
basically
means
a
particular
key
value.
A
We
are
like
very
less
aggressive,
so
we
keep
the
points
as
candidate
for
removal
until
there
is
an
actual
need
to
free
up
the
space.
I
think
in
this
beer,
I'm
like
bit
more
aggressive.
So
the
moment
we
see
there's
a
point
which
is
in
the
status
photosystem.
A
If
the
status
is
like
collect
candy
for
removal,
we
remove
it,
even
if
there
is
no
immediate
need
in
the
snapshot
so
probably
like.
These
are
things
which
we
will
be
trading
a
little
bit
more,
but
the
net
effect
of
this
changes.
We
now
have
a
log
around
the
hot
path
we
we're
previously
avoiding
this
log
in
the
thing
it's
right
here
yeah.
So
we
had
this
concurrent
dictionary
and
we
were
just
looking
at
if
this
is
a
key
value
pair,
which
we
have
seen
before.
A
If
it
was
something
which
we
have
seen
before,
then
there
was
no
lock
it's.
Basically,
this
line
and
concurrent
dictionary
does
not
have
a
lock
on
reads
since
dot
net
5.
I
think
so.
We
are
basically
like
log
free.
So
now
we
have
to
introduce
a
lock.
It's
not
like
full
log,
it's
reader
log,
so
I
mean
like
it's
not
really
blocking
like
any
number
of
readers
from
going
in,
but
still
based
on.
My
bench,
I
mean
benchmark,
shows
like
less
than
10
percent.
A
Overheard
of
doing
this,
but
benchmark
doesn't
spin
up
multiple
thirds,
so
I
ran
the
stress
test
where
we
try
to
really
use
like
multiple
threads,
all
of
them
trying
competing
so
there
we
found
like,
even
though,
like
multiple
readers,
all
of
them
are
like
reading.
We
found
that
the
overall
throughput
dropped
significantly.
I
think
the
measure
was
like
we
were
at
close
to
seven
million
per
second.
We
were
able
to
do,
but
now,
with
the
this
change,
we
dropped
to
around
three
and
a
half
to
four
million
per
second.
A
A
So,
even
though
it
appears
like
very
like
concerning
numbers,
we
might
be
able
to
like
do
some
optimizations,
based
on
what
alan
was
describing.
I
think
basically
like
two
ideas
like
one
is
only
need
to
worry
about
cleanup
when
we
are
like
out
of
data
point.
So
when
we
start
the
aggregator
store,
we
create
a
thing
like
2000
by
default,
so
we
let
user
configure
it.
So
we
don't
need
to
do
any
of
this
cleanup
until
we
reach
that
point,
so
we
should
be
able
to
detect
that.
A
Are
we
within
that
limit
or
not,
and
then,
based
on
that,
we
can
have
a
different
code
path
with
and
without
the
radar
load,
and
also
maybe
we
can
let
the
user
configure
do
they
want
the
points
to
be
reclaimed
or
not,
if
they're
not
interested
in
reclaiming
the
point
or
they
can
like
set
the
value
to
be
like
really
high.
Basically,
let's
say
they're
willing
to
pay
like
memory
cost
upfront.
A
So
if
that's
the
case,
they
will
never
practically
have
to
reclaim
a
memory
point
or
metric
point,
which
means
we
would
be
avoid
able
to
avoid
this.
These
two
points
we
just
discussed.
We
haven't
tried
to
incorporate,
so
I
expect
we
would
have
a.
I
mean
I'll,
convert
this
from
draft
to
reviewable
like
later
today.
After
addressing
at
least
all
the
correctness
issues.
A
A
Yeah
things
like
there
are
several
opportunities
for
us
to
improve
this
from
being
in
the
hot
path
like
one
is
what
you
just
recently
described.
Do
it
only
if
we
are
in
the
delta
mode
number
two
is
do
it
only
if
you
are
exceeding
the
I
mean
if
you
are
reaching
the
metric
point
limit.
A
So
if
you
are
like
starting
with
2000
points
so
until
we
have
seen
at
least
like
2
000
points,
there
is
no
need
of
worrying
about
cleaning
up,
so
you
don't
need
to
take
the
lock
in
the
hot
path
and
the
moment
you
hit
that
point
then
then
onwards,
you
are
in
the
lock
state,
but
the
user
has
once
we
expose
the
ability
for
users
to
increase.
The
limit
users
can
like
avoid
this
log
completely
by
setting
a
higher
limit.
C
C
Thought
about,
as
as
we've
been
working
on
this
is,
it
would
be
really
nice
to
get
some
diagnostic
data
specifically
around,
like
what
people
are
hitting
cap,
wise
and
so
on,
and
you
know,
of
course
we
have
the
logs,
but
I
think
some
of
the
other
open
telemetry
sdks
have
begun
to
record
diagnostic
metrics
yeah.
I
think
we
briefly.
A
Test
upon
it,
so
mike
not
this
maxwell,
microsoft,
we
added
a
pr
where
we
explored
this
idea,
and
this
is
something
which
I
think
we
are
sorry.
It's
a
issue.
Sorry,
it's
a
pr.
So
basically
what
we
were
trying
to
do
was
we
do
use
a
like
number
like
counter
to
indicate
the
number
of
metric
points
we
are
dropping
for
all.
The
three
reasons
like
one
is.
The
like
data
points
are
over.
You
don't
have
any
data
point
and
now
sorry
metric
point.
Then
there
is.
A
We
also
have
a
limitation
on
the
metric
overall
that
can
lead
to
metric
being
lost,
and
then
there
is
third
thing,
which
is
the
users
did
an
incorrect
configuration,
so
it
could
be
instrument,
name
is
incorrect
or
the
view
name
is
incorrect
or
even
worst
case,
like
the
value
itself
is
like
failing
the
sanity
check
like
negative
or
something.
A
So
we
do
like
some
numbers,
and
at
the
I
mean
we
just
keep
that
number.
But
when
we
are
like
shutting
down,
we
put
an
error
message
like
using
our
existing
event,
source,
which
simply
says
like
yeah.
We
dropped
so
many
metrics.
For
this
reason,
we
dropped
that
many
for
another
reason
and
so
on
and
so
forth.
So
we
did
it
for
like
logging,
this
is
yeah,
so
it's
basically
only
for
tracing
time.
It
says
the
batch
export
processor
internally
has
a
circular
buffer
very
similar
to
the
metric
points
right.
A
A
So
I
think
we
should
do
something
similar
for
metrics,
because
it's
very
critical
that
if
the
user
is
like
finding
that,
okay,
my
sums
don't
add
up,
they
need
to
do
like
some
sort
of
troubleshooting
and
when
they
enable
self
diagnostic,
they
should
be
able
to
see
this
logs
so
island.
Would
this
address
what
you
are
after.
C
Yeah,
I
think,
can
in
part,
does
that
actually
generate
a
metric
that
could
then
be
exported
as
well.
The.
A
Like
was
done,
no
that's
something
which
we
have
to
like
spend
some
time
designing.
So
what
I
was
like
initially
planning
at
the
very
like
basic
thing
is
like
here
like
we'll,
keep
a
counter.
So
we
counter
us
in
just
a
pure
long
value,
which
we
do
an
interlock
increment
whenever
we
drop
a
metric.
A
So
that's
the
basic
thing,
but
I
think
it
can
be
extended
to
use
like
either
we
use
the
matrix
api
itself
to
do
that
or
we
can
use
the
because
we
are
already
using
event
source
for
all
our
internal
logging.
A
We
can
use
the
event
counter,
which
is
sitting
nicely
on
top
of
event,
source
to
report
that,
and
once
we
have
a
like
ability
to
convert
the
given
counter
to
our
metric,
we
should
be
able
to
like
modify
the
self
diagnostics
module
to
listen
to
that
and
convert
that
into
an
actual
metric
and
push
it
forward.
A
That,
like
it,
requires
like
some
like
design
hand
like
prototyping
before
we
can
incorporate
sure
it's
a
very
nice
feature,
because
I
mean
there
is
another
thing
which
we
briefly
discussed
in
one
of
the
issues
where
so,
let's
say
like
you
are
using
like
delta
and
like
you
are
not
updating
any
metrics
so
and
once
we
do
the
cleanup
part,
we
will
stop
exporting
anything.
A
So
there
is
no
way
to
know
from
the
exporter
or
the
back
end.
That,
like
are
you
still
up
and
running
or
like?
Did
you
just
crash?
And
so
we
need
to
like
do
something
like
like
some
heartbeat
or
something
to
indicate
that
we
are
still
alive,
but
we
are
not
exporting
anything
because
there
is
no
new
update,
so
we
could
like
piggyback
on
that
approach
to
indicate
okay.
A
We
are
reporting
this
many
data
and
by
the
way
we
also
dropped,
like
so
many
items
on
the
floor
because
of
xyz
reason:
yeah,
it's
something
which
we
need
to
address.
I
think
it's
something
which
we
need
like
some
time
to
like
design
first,
so
for
1.2
timeline,
I
think
the
least
we
should
do
is
make
sure
like
wherever
we
say
to
do
log.
A
We
at
least
do
the
logging
so
like
when
someone
enables
the
self
diagnostic
they'll
at
least
see
that
okay,
okay,
I'm
missing
matrix
because
the
sdk
dropped
it
and
sdk
is
aware
of
the
fact
that
it
is
stroping
it
and
not
due
to
any
other
part.
So
that's
the
minimum
bar
for
like
first
table
and
then
we
can.
I
try
it
on
that
and
build
like
something
more,
which
can
really
tell
how
many?
How
many
are
we
dropping.
A
Yeah
it's
it
requires
some
design
because
in
application
itself,
where
I
work
actively
like
we
did
introduce
something
like
this,
we
use
like
event
counter
to
log
our
own
statistics,
and
then
you
have
a
way
to
listen
to
that.
You
encounter
ourselves
and
report
it
as
a
metric,
so
I
have
like
some
like
experience
doing
that,
but
it
definitely
requires
some
design
because
we
want
to
do
it.
The
right
way
in
open
element.
A
A
Yes,
so
we
are
almost
out
of
time
so
now
that,
like,
let
me,
let
me
quickly
ask
one
more
thing,
since
we
have
folks
here
so,
okay,
michael,
so
this
is
about
the
issue
which
I
briefly
mentioned
earlier,
so
about
exposing
the
keys
and
values
as
arrays.
I
think
you
left
a
comment
like
to
victor
a
few
months
back
about
making
this
I
list
or
innumerable.
A
Could
you
like
explain
like
what
advantage
or
what
disadvantage
would
how
we
would
have
by
using
this
supply,
because
this
is
a
public
api,
so
exporters
would
see
metric
point.
They
would
see
all
these
things.
So
can
you
explain
like
the
reasoning
behind
shifting
this.
A
But
so
when
you
made
the
comment
originally
so
at
that
time
we
were
like
really
in
a
different
architecture
than
the
current
one.
So
this
is
a
specific
comment:
yeah,
sorry
for
not
opening
it
early.
Let's
see
this
was
like
way
in
the
prototyping
stage.
B
A
I
think
let
me
go
to
the
very
beginning,
so
this
is
the
equivalent
of
metric
point
from
that
world,
so
the
public
property
right
now
we
have
keys
and
values
exposed
differently
like
two
separate
fields,
but
at
that
time
it
was
just
an
array
of
key
value
pairs.
But
right
now
we
have
a
array
of
string
and
array
of
object,
call
it
as
keys
and
values.
E
Yeah,
where
is
data
point,
so
this
is
where
does
that
array
come
from?
Is
it
from
the
dotnet
api?
That's
just
coming
into
us.
A
So
the
dotnet
gives
us
a
read-only
span
and
we
the
very
first
time
we
see
a
new
combination.
We
literally
copy
the
string
and
object
from
the
release,
fan
and
store
it.
In
a
heap.
I
mean
we
just
do
like
new
string
and
copy
it
over
and
then.
A
Yes,
until
we
clean
up
so
if
you
ever
clean
up,
then
we
have
to
re-allocate
it
on
the
memory,
but
if
it's
a
frequently
used
one,
it's
like
one
time
thing,
so
this
would
be
just
pointing
to
that.
It's
like
there
is
no
like
within
sorry
within
here.
We
never
do
like
new
here,
it's
always
given
to
it
from
the
sdk,
and
that
sdk
is
like
reusing
it.
A
As
long
as
that
metric
point,
that
combination
is
reasonably
easily
used.
E
And
it's
probably
fine.
It's
probably
just
me
misunderstanding
how
the
api
was
working.
A
Okay,
okay,
yeah,
then
I
I
will
update
a
comment
here
saying
that
no
longer
I
concerned
with
the
new
one
so
now
that
we
have
two
more
minutes
left
I'll.
Ask
the
last
question
here,
which
is
so
right.
Now
we
have
like
few
public
apis
in
public
fields.
Let's
just
focus
on
the
long
value
and
for
each
of
this
public
thing
we
have
an
equivalent
like
private
field.
A
Now
this
works
so
far.
The
only
issue
is
now
we
are
going
to
add
like
for
histogram,
we
need
to
add
like
min
and
max.
A
So
we
definitely
need
to
increase
the
size
of
this
metric
point
struct
overall,
because
we
need
to
have
the
private
version
of
min
and
max
and
then
correspondingly
the
public
version,
so
that
would
it
make
sense
to
create
a
different
like
field
within
metric
point,
which
would
point
to
the
histogram
as
a
whole,
like,
for
example,
explicit
counts
and
bucket
counts
and
min
and
max
are
only
going
to
be
applicable
for
histograms.
A
So
we
could
do
like
a
public
field
like
call
it
like
histogram
data,
which
contains
the
bucket
counts,
explicit
bounds
and
mean
max
required
for
histogram,
so
that
at
most
we'll
take
the
size
to
store
that
up
front
in
this
class
supposed
to
like
having
like,
probably
like
six
fields.
Right
now.
A
Is
that
something
which
you
know
top
of
your
head
like?
Is
it
something
which
we
can
optimize.
E
A
I
see
okay,
so
this
is
something
for
us
to
like
follow
up
offline,
because
I
want
to
make
sure
we
close
it
before
stable,
because
this
is
part
of
the
public
structure.
If
we
like
ship
it,
we
cannot
change
anyway.
So,
okay,
let
me
sing
with
you
offline
to
see
if
you
have
any
way
to
optimize.
I
did
ask
I
learned
about
like
this
particular
thing
like
we
are
basically
like
whenever
we
create
a
metric
point.
A
We
are
allocating
this
like
array,
so
when
we
reclaim
a
metric
point,
we
are
like
repeating
this
thing
so,
but
that
should
be
like
relatively
easy.
We
should
be
able
to
just
reuse
it,
but
just
reset
all
the
points.
So
I
thought
about
this
issue.
A
While
I
was
discussing
this
with
talent,
okay,
so
let
me
sing
with
you
offline
and
see
if
you
can
come
up
with
something
to
optimize
this
thing,
so
yeah,
so
don't
have
any
other
questions
so
I'll
work
with
ellen
to
finish
up
the
like
clean
up
here
and
then
figure
out.
What
are
the
things
which
we
want
to
so
that
user
can
control
the
metric
point
and
they
can
like
optimize
the
avoiding
the
look
for
themselves.
A
Okay,
yeah
now
other
questions.
I
think
we
can
end
now
so
I'll
update
the
notes
with
what
we
discussed
shortly.
A
Okay,
yeah.
Thank
you.
Oh
it
looks
like
we
had
a
new
member
joining,
but
not
longer
now
so
I
forgot.
C
Yeah
she's,
a
new
member
of
of
my
team.
I
invited
her
to
come
to
this
sick
meeting,
but
she's
she's
going
to
be
working
in
open
telemetry,
not
necessarily
just.net,
but
she's
kind
of
getting
the
the
tour
okay
got.