►
From YouTube: 2022-03-07 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
B
A
Okay,
let
me
let
me
just
open
share
my
screen
and
probably
we
can
talk
the
current
status
and
probably
what
we
can
do.
A
A
I
think
if
you
have
seen
that
block
diagram,
a
magnetic
storage
gets
created
for
whenever
new
instruments
get
created.
So
when,
if
you
see
somewhere,
I
mean
just
to
give
this
bit
of
idea
what
exactly
we
are
doing
here.
So
whenever
a
new
instrument
gets
created
somewhere
in
meter,
sorry,
it
has
to
go
into
sensing.
A
So,
whenever
a
new
meter
is
a
new
instrument
gets
created,
we
check
for
that
instrument.
If
it
we
don't,
we
need
to
collect
the
metrics
for
that
instrument
or
not.
How
do
we
check
it?
We
check
the
so
there
is
a
view
configuration
which
gets
created
during
the
configuration
of
sdk
and
through
that
we'll
see
if
we
do
need
to
collect
the
matrix
for
that
particular
instrument
or
not
so
that
that
basically
checks
the
view.
A
So
that
that
is
something
which-
and
it
depends
what
kind
of
view
we
need
to
create
if
the
if
there
would
be
synchronous,
storage
and
there
would
be
a
asynchronous
storage
depending
on
the
kind
of
instrument
we
are
going
to
create.
So
if
it
is
something
like
observable
gauge,
this
would
be.
This
will
require
an
ace
recognized
instrument
to
get
created
why
we
create
different
different.
So
when
we
say
controller
storage,
that
means
this
is
this
is
this:
is
the
in
memory
storage
to
aggregate
those
measurements
which
are
coming
from
these
instruments?
A
An
aggregation
map
which
contains
for
a
given
instrument,
a
given
instrument,
will
can
can
have
different
properties,
attribute
properties
for
each
of
those
attribute
properties.
We
have
to
do
a
separate
aggregation
and
it
just
maintains
that
aggregation
information
in
a
hashmap
and
whenever
the
collect
request
comes,
it
will
just
read
this
hashmap
and
it
will
return
all
the
data
or
all
the
aggregated
matrix
from
that.
That
is
what
it's
supposed
to
do,
which
it
is
not
doing
as
of
now.
A
So
whenever
the
connection
is
doing
yeah,
this
is
the
color
should
do.
It
should
collect
all
the
metrics
generated
which
is
stored
in
this
attribute
hashmap,
and
it
should
return
that
through
this
callback,
which
is
which
is
being
passed
so
the
metric
data
should
get
generated
here.
It
should
return.
A
A
A
So
if
it
is
a
delta
matrix,
it
should
be
very
straightforward.
We
maintain
activity,
we
just
need
to
iterate
over
this
hash
map
and
return
all
the
matrix
which
is
collected
yeah,
and
we
clear
up
this
matrix
this
hash
map.
So
when
the
next
collection
will
happen,
it
will
just
read
the
data,
because
every
time
we
are
going
to
clear
and
clean
up
this
hashgraph,
so
every
collection
will
only
have
the
delta
matrix
information.
B
Could
it
be
combined
also
com
combined?
Also
like
can
I
have
this
hashmap
having
both.
A
No
it's
this.
This
is
the
hashtag
just
stores
the
aggregated
matrix
for
a
given.
It
just
maintained
for
the
set
of
attributes
which
are
coming
from
measurement.
It
just
contains
the
aggregated
data
for
that
attributes
for
each
of
those
attributes,
yeah.
A
So
if
we
clear
it
after
every
aggregation,
we
get
a
delta,
we
will
get
a
delta
matrix.
So
so
we
have
to
add
some
logic
here.
So
one
thing
is
the
first
one
it
would
be
for
delta
matrix.
That
would
be
very
straightforward
straight
forward.
We
just
need
to
just
need
to
iterate
over
this
and
collect
the
matrix
and
call
this
callback
and
then
clear,
but
with
every
every
collection
we
also
have
to
somehow
maintain
the
cumulative
cumulative
metrics
also
somewhere.
A
We
have
to
store
start
storing
that
also
so
that
whenever
we
we
are
collecting.
Whenever
we
are
sending
this
information,
we
should
store
this
information
in
a
cumulative
somewhere
hash
map
or
somewhere.
We
have
to
store
it
so
that
whenever
a
request
is
coming
for
cumulative
matrix,
we
should
be
just
reading
that
that
that
data
from
that
hash
map-
and
we
should
send
it
so
it's
maintaining
the
history
of
all
the
data
which
has
come
till
now.
A
A
In
fact,
this
contains
the
time
series
more
of
a
time.
Theory
is
better,
but
that
would
be
only
one
last
recall
of
the
history.
It
will
not
have
all
the
all
the
metrics
which
we
have
got
till
now.
It's
just
aggregation
or
the
merge
of
all
the
matrix
data
like
number
of
requests
coming.
So
this
will
have
number
of
requests
for
number
of
http
requests,
say
an
example.
If
it
is
a
counter
type
instrument,
this
will
contain
number
of
requests
which
we
are
getting
from
a
given
time.
A
A
A
So
it
won't
be
costly
operation,
but
this
it
will
have
us,
so
we
have
to
maintain
that
storage.
The
problem
is
that
this
has
to
be
maintained
for
all
the
collectors,
which
is
a
problem
right
now,
because
each
of
these
collectors,
so
it's
possible
that
one
of
the
collector
is
reading
every
15
minutes,
but
other
collector
is
reading
every
30
minutes.
A
A
It's
not
it's
a
feature
freeze
for
sdk,
so
so
api
is,
I
think,
stable
sdk
is
feature
freeze.
So
that's
why
it
first
from
experimental.
It
goes
to
feature
freeze
and
then
it
goes
to
stream.
A
So
sdk
must
support
multiple,
multiple
reader
instances
to
be
registered
on
the
same
metric
meter
provider
and
the
metric
reader
collect
invocation
on
one
metric
reader.
Instant
should
not
introduce
side
effect
to
other
metric
level
instances,
so
I
have
given
metric
instance
is
receiving
metric
data
points
that
have
delta
temporarily.
A
It
is
expected
that
the
sdk
will
update
the
time
bridge
for
that
particular
metric
in
the
reader
instance
only,
which
is
something
which
we
have
to
figure
out,
how
to
do
it
so
subsequent
metric,
so
that
that's
the
reason
why
I'm
trying
to
add,
I
think
I
was
checking
how
the
how.
A
A
A
A
A
A
Also,
when
all
the
collectors
have
done
the
collection
for
a
given
time
period,
we
don't
need
to
maintain
the
cumulative
storage
of
all
the
data
once
the
collection
has
happened
at
a
given
time,
so
that
that
that
somewhere,
that
logic
has
to
be
built
here,
I
don't
have
any
idea
of
now.
I
need
to
see
probably
more
how
to
do
that,
but
this
this
this
is
more
of
a
gray
area.
A
A
A
So
that's
that's
something
which
probably
have
to
will
need
more
thought
and
that's
the
reason
I'm
not
touching
it
as
of
now,
probably
I
think
easy
part
would
be
definitely
doing
a
data.
Probably
we
can
definitely
we
can
at
least
implement
that,
but
I
think
cumulative
needs
more
thoughts.
A
I'll
say:
probably,
let's
both
of
us
do
some
more
go
through
go
through
the
specs
and
go
through
some
existing
implementations
and
then
probably,
let's,
let's
discuss
in
a
couple
of
days,
something
that
slips.
Probably
will
have
better
idea.
B
A
A
If
you
are
going
to
maintain
the
storage
and
the
collection
has
to
go,
I
mean
there
would
be
lots
of
locks
which
we
have
to
create,
because
there
would
be
a
central
central
component
which
has
to
call
the
collection
for
all
those
metric
reader
so
that
to
me
it
looked
to
be.
It
may
not
work,
or
at
least
unless
until
we
have
a
locks
at
the
at
the
global
level,
I
think
they
would
that.
That's
what
it
looked
to
me.
A
A
B
A
And
I
was
thinking
if
we
can
definitely
if
we
can
avoid
these
knocks
on
together
or
if
we
could
do
it,
only
their
minimum
level
will
be
needed
for
only
for
a
given
instrument.
If
you
are
doing
a
collection,
we
are
doing
logs
only
for
that
particular
instrument,
even
if
there
are
say
four
metric
leaders
registered
for
a
given
instrument,
we
are
going
to
do
not
only
to
take
care
of
those
four
metric
leaders,
but
the
way
python
is
doing
it.
A
B
B
A
Not
make
sense
to
block
them,
so
this
film
does
not.
This
will
not
have
that
contention,
because
we
have
separate
storage
for
each
of
those
meters,
so.
A
B
A
A
Anytime,
whenever
you
feel
comfortable,
I
think
I'm
I'm
fine
I'll
have
some
time
this
week
to
spend,
spend
on
my
tricks.
I
think
definitely
I
want
to
do
it
so
whenever
you
feel
thursday
or
friday.
So,
let's
see
on
thursday,
let's
keep
it
thursday
say
yes
same
time.
If
we
feel
that
either
of
us
not
are
not
prepared
or
not
ready,
that
we'll
move
it
to
the
friday.
A
Thanks
yeah
thanks:
let's
do
that
sorry,
I
think
I
I
I
thought
I'll
be
spending
some
time
this
weekend
to
really
go
through
the
design
and
probably
come
up
with
something,
but
I
think.
B
A
Yeah
yeah
yeah,
if
something
you
are
there,
probably
just
think
me
if
you
have
some
doubts
and
probably
if
you
have
some
better
ideas
the
way
we
are
doing
with
this
thing
and
let's,
let's
probably,
we
can
discuss
it
ad
hoc,
soon,
yeah
yeah
great.
Otherwise,
we
are
going
to
sync
it
up
on
thursday,
10
10
am
fragment
time
and
then
and
then,
let's.
A
No,
no
definitely,
I
think
it
was
not
me.
I
think
it
was
basically
really
really.
I
think
he
has
been
looking
to
europe
and
he
was
very
happy,
so
he
just
pinged
me.
What
do
you
think?
I
think
I
said
yeah.
That's
definitely,
I
think,
he's
doing
a
very
good
book,
so
I
think
welcome
on
board
and
congratulations
and
I'll
suggest.
I
think
there
is
a
sick
meeting
for
maintainers.
A
If
you
go
to
the
calendar
google
calendar,
in
fact
it
was
today
it
was
my
fault
I
should
have
probably
been
to
you.
9
am
every
monday
yeah,
that's
that's!
There
is
a
maintenance
meeting
so
feel
free
to
join
it
today.
I
already
have
mentioned
that
in
today's
meeting
that
we
haven't
maintained
your
name,
so
they
know
that
you
are
simply
place.
Maintainers
feel
free
to
join
and
yeah.
B
A
We
just
we
just
in
that
meeting.
We
just
gave
a
quick
update
on
where
we
are
what
we
are
doing
it
so,
as
of
now
I
just
added
so
it's
a
very
short
update,
what
we
are
doing
and
where
we
are
in
this.
If
you
see
this
agenda
just
go
through
this
so
yeah
there
I
mentioned
that
we
are
within
my
trainer,
so
I
think
they
welcomed
you.
You
know
I
mean,
then
I
I
realized
that
I
should
have
asked
you
to
join
the
meeting,
but
that's
fine.