►
From YouTube: 2022-02-10 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
D
I
don't
know
if
aaron's
there,
but
I
can
hear
you
diego
all
right.
Yeah.
B
E
B
All
right,
aaron,
I
saw
that
you
added
this
pr
for
metric
reader
storage,
yeah.
That's
everybody
again!.
D
F
C
B
D
D
I
went
to
try
and
run
it
this
morning
with
the
the
getting
started
example
and
it
it
just
errors
out.
That
may
be.
I
I
We
need
to
combine,
like
I
think,
there's
four
open,
vrs
or
five
and
once
they're
all
combined
together.
It
should
work,
but.
B
Matrix
is
very
exciting
but
yeah.
So
let's
give
a
minute
for
people
to
add
their
prs
issues
document
and.
B
H
B
F
Yeah,
it's
you
wanna.
D
D
B
Okay,
I
guess
we
we
have
enough
stuff
in
our
documents
so
that
we
can
begin
all
right
once
again
welcome
everybody
later
on.
You
want
to
talk
about
the
work
that's
going
on
in
the
documents
sure.
F
Yeah,
so
basically
this
it's
just
been
a
couple
of
pr's
in
our
repo,
as
well
as
the
the
television
website,
repo
pretty
much
just
following
the
template
that
philip
proposed
the
other
other
day,
because
we
gave
him
the
go
ahead
and
yeah
I've
just
been
reviewing
some
of
them,
but
you
know
feel
free
to
take
a
look.
Make
sure
that
all
the
content
is
still
there.
F
I'm
sure
you
can
you
guys
can
find
the
the
related
prs
so
yeah.
I
think
they're.
Just
looking
for
python
contributor
helpers,
sorry
feedback
for
the
website,
repos,
so
yeah
feel
free
to
take
a
look
at
those
with
you
guys
at
the
time.
B
F
B
F
B
I
More
there's
not
too
much
to
say
the
design
dock
has
a
bit
on
it
and
it
was
in
the
prototype.
But
basically
this
component
is
for
each
metric
reader.
I
We
create
one
of
these
and
it
acts
as
like
a
top
level
like
the
top
level
storage
that
holds
all
the
other
views
and
stuff
for
the
metric
reader.
So
for
each
each
metric
reader
will
get
its
own
instance
of
this,
which
will
give
you
independent
views
for
each
one,
so
so
that,
like
collection
and
temporality
between
the
different
readers
won't
affect
each
other.
B
Excellent,
this
is
excellent
effort.
Thank
you
very
much
ar,
and
I
just
wanted
to
point
out
something
here.
I
think
this
piece
of
code
that
you
have
here
solves
the
problem
that
I
had
in
my
usbr
that
you
pointed
out
that,
because
I
was
using.
A
B
That
had
like
a
regular
expression
that
wouldn't
match
anything
but
yeah.
So
so
I
I
guess
we
can
pretty
much
remove
that
entirely
from
my
my
views,
pr
and
use
this
approach,
my
my
only
question
was
how
how
do
we
intend
to
okay?
So
when
you
create
a
meter
provider,
you
have
an
option
there
to
specify.
If
you
want
to
have
this
default
view
active
or
not
right,.
I
B
I
B
Okay,
you
want
to
add
it
here,
yeah,
so
that
this
one,
your
subject
can
have
it
all
right,
it's
nice!
The
next
thing
is,
I
wanted
to
ask
you
a
little
bit
about
what
ideas
do
we
have
for
this,
because
I
see
that
what
you
have
here
is
a
function
that
returns
a
view
and
receives
an
an
instrument.
So
is
this
view
created
on
the
fly
to
be
able
to
match
this
instrument
or
something.
B
I
Yeah
exactly
so
so
when
the
when
your
vpr
is
merged
in
you
would
basically
just
stick
in
the
name
and
then,
given
that
it'll
just
only
have
the
instrument
name.
So
all
the
other
fields
will
be
defaulted
right.
H
B
I
B
So
aaron
and
I
we
had
some
questions
about
what
what's
the
meaning
of
wild
cards
and
it
things
ended
up
with
a
vr
here
that
specifies
what
wild
card
what
cards
mean
here.
It's
a
pier
from
riley,
which
pretty
much
adds
these
two
characters,
this
one
much
in
one
character
and
this
one
matching
zero
more.
So
we're
gonna
move
from
using
regular
expressions
which
I
had
in
my
vr
to
only
support
this.
B
I
Yeah,
I
think
I
thought
about
this
too,
and
I
don't
remember
if
slash
like
the
file
name,
separator
character
is
a
valid
instrument
name,
I
think
it
is
and
and
if
it
is,
then
that
also
has
special
meaning
in
fn
match.
So,
for
instance,
like
it's,
basically
like
a
like
a
path
glob
right.
So,
oh
sorry,
it
says
not
special
in
this
module.
It's
special
in
the
blog.
B
Okay,
so
if
we
use
fn
match,
we
will
also
be
adding
support
for
for
these
two
matching
mechanisms
which
are
not
defined
in
spec.
I
B
B
Yeah,
well,
I
can
in
order
not
to
take
too
much
time
from
this
meeting.
I
can.
I
can
take
a
look
at
this
and
add
a
solution
in
the
interview.
F
Sorry
one
more
question,
so
the
the
question
mark
in
asterisk
support
would
be
in
the
actual
instrument
name.
B
No
in
the,
in
the
view,
string
that
matches
instrument
names,
okay,.
E
All
right,
okay,
so
where
were
we
there's.
I
Was
that
was
that
alex
go
ahead?
Aaron,
okay,
real
quick,
there's
one
other
thing
there
in
the
in
the
spec
discussion,
which
was
well,
I
think,
a
lot
of
different
cigs.
They
make
view
almost
like
a
sampler
in
the
tracing
world.
So
basically
what
you
can
do
is
you
can
subclass
view
and
you
can
implement
the
like
matching
predicate,
so
you
could
override
the
matching
behavior
to
be
sort
of
custom.
I
B
I
Yeah,
it
would
all
be
easy.
I
guess
it's
just
the.
The
point
is
right
now.
If
we
have
a
class
view,
and
it
has
like
a
method
match,
there's
nothing
stopping
people
from
subclassing
it
overriding
that
which
is
fine.
I
think
we
just
need
to
decide.
If
we
want
people
to
do
that
or
not.
If
we
don't,
then
we
need
to
have
like
another
layer
of
interaction
to
hide
the
matching
behavior
right.
D
I
E
We
can
make
it,
we
can
add
double
underscore
yeah,
but
then
you
can't
call
it
from
elsewhere.
I
E
B
Calling
match
from
view
from
metric
readers
from
the
metrogrouper
storage
code
here
right.
F
F
F
Yeah,
I
don't
think
that's
the
point
of
contention,
it's
it's,
we
can
use
double
underscores
we
want
if
we
use,
make
it
private
or
protected
it's
just
that
we
just
got
to
choose
between.
You
know
like
subclassing
it
and
just
have
the
view
view
class,
letting
users
do
that
or
letting
users
override
the
the
match
method.
That's
it.
B
B
All
right,
aaron
is
something
else.
Do
you
want
to
mention
about
this
year.
I
D
D
D
Just
going
to
say,
if
we,
you
know
if
the
implementation,
so
this
is
going
back
to
your
your
reviews,
pr
they
go
if
implementing
the
wildcard
support
is
that
can
be
done
separately?
I
would
just
keep
that
as
a
separate
pr
than
the
rest
of
the
views
implementation.
If
that
makes
sense,
because
it
could,
it
could
just
be
its
own
functionality
that
we
can
add
after
oh
yeah.
B
I'd
say
that
we
do
that,
because
I
mean
the
the
wildcard
support
is
not
even
merged
into
the
specs
right:
okay,
yeah,
all
right
yeah!
I
can
do
it.
Okay,
so
yeah
pretty
much.
You
can
have
it
merged
very
soon,
great
all
right!
So
moving
on
to
the
next
topic
here
we
have
second
with
spr
a
temporarily
conversion
for
histogram
all
right.
A
Yeah
this
this
this,
this
one
is
the
last
one
that's
remaining
in
temporary
conversion,
only
the
remaining
metric
point.
So
this
implements
that
I
have
one
question,
though,
so
we
have
like,
we
have
minimum
value
maximum
value
in
the
histogram
aggregation,
but
they
are
so
they
aren't
really
used.
As
of
now,
when
we
are
collecting
the
metric
points,
I
was
wondering:
what
do
we
so
do
about
them?.
A
So
it
mentioned
something
like
you
can
so
they'll
not
be
you
can't
use
them
in
the
temporary
conversion,
but
you
may
choose
to
create
a
new
something
like
gauge
with
them.
So
it
wasn't
very
clear
to
me.
I
Yeah,
I
think,
for
maybe
like
for
a
first
draft.
If
we're
doing
delta
to
cumulative,
we
can
keep
them
and
then,
if
we're
doing
the
other
way
around
the
one
where
it's
impossible,
we
could
just
remove
them.
J
A
Yeah,
so
so
that
that's
the
situation
that
I
read
on
the
specification,
but
so
if
we
keep
them
but
the,
but
the
proto,
like
the
proto
point,
does
not
have
these
values
right.
Where
do
we
keep
them.
I
A
A
If
you
want
to
add
them
to
the
like,
send
them
to
the
expert
place,
the
product
point
does
not
have
these
these
attributes.
I
mean.
I
Is
it
the
part
of
the
proto
point
or
the
or
like
the
data
class
wrappers?
We
have.
A
I
I
think
we
are
like
mimicking
the
the
proto
structure
in
our
data
classes,
so
both
of
them.
I
also
looked
at
the
proper
definitions.
They
also
don't
have
it.
Oh.
A
Okay,
I
think
like
we
can
like
this,
can
be
attributed
so
that
we
can
look
into
that
in
in
separate
issues.
A
Right
this
is
crazy,
but
I
had
question
around
min
max
like
we
haven't.
We
have
them
in
the
aggregation,
but
we
are
not
really
using
and
I
don't
see
how
we
can
use
them
in
the
histogram
like
while
exporting
the
histogram
to
point.
So
I
was
wondering
what
do
we
do
about
them?.
B
All
right,
great,
okay,
I'll,
definitely
try
to
take
a
look
at
this
today.
Great
contribution.
B
An
important
missing
component
here.
Thank
you.
Second,
all
right,
there
are
no
more
comments.
Okay,
I
think
we
have
this
pr.
This
one
is
mine.
F
Yes,
yeah,
just
not
that
I
have
any
comments
on
it.
Just
wanted
to
see
what
the
the
current.
B
B
So
here
we
have
so
we
are
having
some
trouble
with
this
method.
B
This
collect
method
return
type,
so
we
we
went
from
being
able
to
return
on
to
only
to
return
some
to
indicate
the
situation
where
collect
has
been
called
and
aggregate
has
not
been
been
called
before.
I
suggested
that
we,
instead
of
returning
none,
we
could
return
a
sum
object
whose
value
is
none.
B
I
think
her
in
agreed,
and
then
I
was
thinking
about
an
asynchronous
did
this
in
the
this
same
situation,
collect
being
called
before
aggregate
happening
in
a
synchronous
instrument,
but
yeah,
and
I
added
that
in
this
comment-
I
I
don't
think
that's
gonna
happen
right,
aaron,
because
the
metric
reader
storage,
we
always
call
when
a
collection
happens.
B
I
Right,
except
that
there's
no
guarantee
a
callback
will
emit
the
same
label,
sets
like
the
same
measurements
for
label
sets.
So
as
an
example,
if
you're
monitoring
processes
on
your
system
and
then
processes
dies
the
next
time,
you
get
a
scrape,
you
won't
even
see
that
process.
You
won't
make
any
measurement
for
that
that
callback
cycle.
I
I
Yeah
you'd
use
the
previous
value
which
you
can
get
from
doing.
You
know
you
know
like
we
have
the
previous
value
saved,
so
you
could
get
it
from
that
another
option
and
I
I'm
not
100
clear
on
the
semantics
of
this
still
is.
You
would
just
skip
that
point
when
you
go
to
export
that
time
around.
I
think
for
some
metric
back-ends
that
makes
sense
and
for
some
metric
back-ends
that
doesn't
make
sense.
A
I
So
I
think,
like
the
title
of
the
merge,
asynchronous
and
second
of
some
aggregations
in
some
ways,
they
like
need
to
behave
a
little
bit
differently
and
we're
trying
to
generalize
it
so
that
they
behave
the
same
way.
I
I
think
returning
like
none
from
the
collect
method
might
be
the
best
way
to
handle
that
and
then
let
the
temporality
conversion
portion
say.
Oh,
there
was
no
measurement
this
time
around
so
I'll
either
return
nothing
or
I'll
return.
The
previous,
the
previous
collection
windows
value
right.
I
I
mean,
I
think
I
think
we
should
merge
them
because,
like
at
some
point
like
they
really
like,
the
cumulatives
and
deltas
are
kind
of
the
same
thing.
I
I
think
it's
reasonable
to
just
have
the
have
the
special
cases
for
asynchronous
instruments
directly
in
there
and
then
try
it
like,
like,
for
instance,
gage
they're,
going
to
behave
exactly
the
same
way
for
last
value,
for
instance
right.
So
I
don't
know.
I
think
I
think
returning
none
would
do
the
trick.
I
That
yeah,
that
that
works,
the
only
issue
with
that,
I
think,
is
semantically
in
proto
buff,
a
none
valued
like
in
or
float
is
a
zero
there
well,
at
least
in
proto2
right
there's,
no
empty
fields.
I
D
I
Yeah,
I
think
I
think,
if
we
could
factor
out
the
like
decomposable
aggregate
function
or
whatever
it's
called
so
like
the
sun,
the
the
actual
aggregation
from
the
like
operation,
that
would
that
would
probably
also
do
the
trick.
I
B
B
Great
okay!
Next
year,
next.
A
I
Oh
so,
basically,
this
one
was
an
understand
misunderstanding
that
I
was
having
a
lot
of
our
dark,
a
lot
of
our
docs.
They
suggest
using
underscore
underscore
name
underscore
underscore
for
the
name
field
for
tracer
and
meter
right.
So
that's
apparently
not
what
we
were
supposed
to
be
doing.
I
had
a
look
around
at
what
other
languages
are
doing
and
basically
for
a
single
library.
I
They
will
use
the
same
tracer
or
meter.
So
it's
like
the
instrumentation
library,
not
like
the
source
file
or
the
specific
class
you'll
notice
that
that's
pretty
different
from
what
happens
in
logging,
so
in
logging,
it's
most
conventional
to
use
the
name
of
the
class
you're
in
for
like
a
logger
in
that
class
or
in
python
the
name
of
the
module,
and
that's
why
this
spec
dr
is
here
because
they
want
to
sort
of
unify
all
those
fields
so
that
they
make
sense
in
the
data
model.
I
D
I
was
going
to
say
I
pasted
a
link
in
the
and
the
doc
here
that
shows
our
documentation,
which
is
recommending
passing
in
the
underscore
score
name
like
aaron
is
saying
here.
I
Yep
and
I
think
for
our
instrumentation
packages,
there's
just
a
single
init
file,
so
it
actually
does
do
the
same
thing
in
those
cases
but
as
like
a
general
thing,
the
it's
not
really
a
good
recommendation.
I
don't
think.
D
D
Oh
sorry,
just
the
idea,
if
you
look
at
that,
like
the
examples
that
we
give
is
don't
use
like
use
the
fully
qualified
name
yeah,
which
is,
which
is
what
we,
what
you
would
want
to
use.
But
then
the
first
line
in
the
stock
is
confusing
because
it
says
use
underscore
underscore
name
which
wouldn't
give
you
the
same
thing.
A
Okay,
we
need
to
update
the
instrumentations
here
because
so
usually
the
recommendation
is,
it
say
like
if
the.
If
the
library
has
a
instrumentation
natively,
you
can
use
the
request.
But
if,
since
we
are
having
like,
we
are
patching
and
providing
the
instrumentation
library,
it's
fine
if
we
use
the
open
delimited
instrumentation
that
requires,
I
think
we
don't
have
to
update
the
instrumentation
libraries,
but
if,
if
they,
if,
unless
there
are
multiple
even
within
the
instrumentation,
there
are
multiple
addresses
used.
I
I
I'm
just
gonna
say
yeah.
I
don't
think
we
should
update
them
because
at
this
point,
like
you
know,
it's
been
there
for
a
long
time
and
I
think
it's
probably
pretty
reasonable.
In
most
cases,
what
we're
gonna
say
later.
F
Well,
the
the
pr
itself
is
a
different
proposal.
Right
then,
our
simple
change,
the
doc
name
stuff
to
use
the
instrumentation.
I
Library,
I
I
don't
remember,
because
they
went
back
and
forth
like
quite
a
few
times.
I
think
at
one
point
they
were
going
to
add
another
field
to
differentiate
these,
so
so,
for
instance,
like
you
would
have
like
sort
of
like
the
logger
name,
which
would
be
like
the
fqdn
of
the
class
you're
in
and
then
you
would
have
the
instrumentation
library
name,
which
would
be
like
hey.
This
is
the
library's
name,
even
across
multiple
files.
D
In
depth,
I
I
think
they're
just
adding
this
notion
of
instrumentation
scope
and
making
it
clear
in
the
documentation
that
that's
what
this
field
is
intended
on
serving
for
the
trace
and
the
meter,
but
just
just
a
second
stepping
back
to
what
you
were
saying
about
needing
to
update
the
instrumentations.
It
does
look
like
basically
anywhere
we
get
a
tracer
in
any
of
our
instrumentations.
We
use
the
underscore
underscore
name
field
for
identifying
that
instrumentation,
which
I
guess
I
guess
most
of
our
instrumentations-
are
a
single
file.
A
So
like,
if,
if
you
want
to
know
like
what
what
triggered
this
change
right
so
in
in
in
logging
sdk
there,
we
have
a
log
emitter
like
similar
to
get
tracer.
We
will
call
the
get
emitter
under
underscore
name
right.
So
there
was
a
like
conflict
of
interest
like
this.
So
why
is
there
a
notion
that
you
want
to
have
like?
That
should
be
the
logger
name
right?
A
Why
do
you
have
another
get
emitter,
instrumentation
library,
so
that
that
triggered
this
change
so
basically
to
like
the
the
emitter
like
the
get
racer
or
get
meter
rocket
emitter
that
should
signify
the
it's
a
scope.
It's
not
a
you
know
it's
not
a
single
file
or
single
class.
It's
intended
to
be
a
scope,
a
library
like,
let's
say
the
whole
instrumentation.
A
A
A
So
right
now,
like
our
understanding,
is
that
we
use
double
underscore
name
double
underscore
right.
So
this
this
changes
to
you
know
or
tell
the
readers
that
you
know
don't
make
it
like
two
different,
two
different
names
for
the
same
instrumentation
that
you
are
doing.
Let's
say
in
a
request:
instrumentation,
I
have
like
two
different
get
tracers,
make
sure
that
they
are
the
same
name,
don't
make
it
two
different
names
for
the
same
same
same
instrumentation,.
D
One
another
thing
that
might
be
worth
calling
out
here
is:
you
know:
most
of
our
instrumentations
are
still
pre
1.0.
So
if
we
wanted
to
change
them,
now
is
a
good
time.
It
would
require
us
at
least
make
it
clear
that
we're
going
to
change
the
names,
but
I
think,
at
the
very
least,
we
should
also
update
the
documentation
on
creating
instrumentations
to
call
out
that
this
is
the
way
that
people
should
think
of
naming
their
tracers
moving
forward.
D
D
B
This
change
tries
to
do
that
because
they
they
try
to
put
in
the
specification.
The
meaning
should
be
that
right,
and
that
is
a
a
field
that
the
user
can
change.
So,
instead
of
having
a
a
non-user
definable
field
that
can
be
defined,
defining
the
spec
that
says
instrumentations
should
that
create
a
tracer
should
fill
this
field.
That
is
not
user
definable
right
in
this
way,
which
would
make
sense,
but
I
don't
know
if
anyone
else
finds
it
also
weird
that
we're
trying
to
define
and
expect
something
that
it's
not
part
of.
F
D
B
B
D
Yeah
speaking
of
spec
issue,
the
next
one's
also
a
spec
issue
that
I've
mentioned
in
at
least
one
of
the
python
channels,
but
I
think
diego
you've
taken
a
look
at
this,
but
the
call
out
from
the
spec
meeting
this
week
was
to
get
more
people
to
look
at
this.
I
think
aaron
also
commented,
so
thank
you
for
that.
D
If
anybody
else
has
any
thoughts
on
this,
now
is
the
time,
because,
specifically
the
folks
in
the
spec
meeting,
riley
was
looking
for
help
to
try
and
prove
out
that
this
will
work
for
other
languages
than
java
and
I
think
go
was
the
other
one
that
was
planning
on
proving
it
out.
I
B
So
this
vr
and
this
issue
here
I
think
they
are
related.
B
B
B
The
issue
that
I
find
with
this
is
that
here
this
approach
requires
to
add
another
method,
to
the
synchronous
instruments,
name
observe,
which
first
of
all
can
be
called
synchronously
by
the
user.
There's
nothing
that
stops
the
user
to
do
that.
Doing
that
and
in
correct
me,
if
I'm
wrong,
but
calling
this
will
trigger
the
aggregation.
I
I
But
I
think
approach
three
is
the
one
you're
describing
which
is
the
one
that
josh
mcdonald
had
for
go.
If
you
scroll
down
as.
B
I
B
I
While
you
do,
that,
does
everybody
unders?
Does
everybody
understand
what
the
issue
is
and
what
the
proposals
are
trying
to
solve.
A
Yeah
yeah,
I
I
I
I
read
through
the
this
pr.
I
understand
what
they're
trying
to
solve.
I
haven't,
you
know,
really
fully
looked
at
it,
but
I
understand
the
issue
here.
I
B
Yeah,
okay,
so
my
question
is
this:
I
created
this
example
right,
which
is
pretty
much
similar
to
that.
We
have
a
synchronous
instrument
with
an
observed
method.
B
If,
if
I'm
not
mistaken,
the
observed
method
will
receive
a
measurement
will
send
it
to
the
aggregation
right
to
be
aggregated
and
then
we'll
return.
It
is
that
what
the
observer
method
is.
I
B
Okay,
so
it
doesn't
have
it
doesn't
tell
the
aggregation
to
do
anything.
It
just
returns
so.
I
B
I
Yeah
public
yeah
and
then
the
next
approach
is,
is
kind
of
similar.
Basically,
the
callback
receives
a
function
that
I
can
use
to
say:
hey
make
this
measurement
on
this
instrument
that
wouldn't
require
changing
the
api,
or
rather
the
interface
for
the
asynchronous
instrument.
B
Yeah,
okay,
the
approach
three
well
this
this.
I
Is
the
one
that's
problematic,
like
you
said,
diego,
because
basically
the
you
have
to
have
some
sort
of
mechanism
to
know
like
to
know
that
the
observed
function
is
being
called
from
within
a
valid
registered
callback.
B
Yeah
right
so
yeah
it
it
requires
you
to
know,
I
mean
to
inspect
the
stack
trace
of
something
good,
nice.
Okay,
some
questions
that
I
had,
and
our
answer
is
that
this.
B
Okay,
yeah,
I
guess
people
will
please
take
a
look
at
this.
I
do
have
some
questions
about.
What's
going
to
happen
here
when
you're
on
register
happens,
it's
not
that
really
specified.
D
So
I
know
there
at
this
at
the
spec
called
they
mentioned
that
they
were
going
to
have
a.
I
think
it
was
like
a
week
to
decide
whether
or
not
this
will
go
in
the
specification.
Is
there
any
questions
that
we
have?
That
would
be
blocking
this
from
going
into
the
spec.
I
guess
this
the
question
that
I
would
like
to
maybe
get
answered
in
the
next
few
days
here.
If
we,
if
we're
going
to
run
into
big
problems,
we
should
identify
it.
I
I
So
yeah,
you
could
do
another
approach
where
you
have
like
add
instrument
to
the
measurement,
the
measurement
class,
and
then
you
would
just
pass
it
in
yourself.
That
would
work
as
well.
I
B
I
B
I
So
so
they're
a
bit
different
right
so
like
this
one
is
just
intended
for
making
instrumentation
for
asynchronous
instruments.
So,
like
the
return
value
from
the
callback,
the
one
internal
to
the
sdk
is
gonna
have
some
other
stuff.
So,
for
instance,
it's
gonna
have
context
which
you
don't
have
in
an
asynchronous
callback.