►
From YouTube: 2021-06-01 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
A
Okay,
I
think
we
can
start
like,
looks
like
quickly
yeah.
Some
of
us
are
here,
so
it's
good
enough.
We
can
start.
There
is
nothing
in
the
agenda,
apart
from
a
small
nod,
which
I
put
a
few
minutes
back,
basically
giving
an
update
on
the
1.1
release.
A
So
that's
like
I
must
have
before
we
can
release
1.1,
because
1.1
contains,
like
other
bug,
fixes
which
enabled
like
instrumentation
scenario.
So
as
soon
as
we
close
on
the
configuration
part,
which
is
the
idea
for
tracer
provider
builder
and
like
release
another
beta
and
give
it
like
one
to
two
weeks
to
bake,
we
can
do
like
one
two
one
release.
A
I
don't
have
like
any
other
update,
maybe
like.
If
anyone
has
questions,
we
can
take
it
or,
like
maybe
victor
like
do
you
want
to
share
anything
about
the
prototyping
with
metric,
stk
or
anything
else.
We
can
discuss
right
now.
C
C
Yeah,
so
so
just
a
minute
I
mean
base.
We
thank
you
for
everyone
for
doing
the
pr
review,
so
that
has
been
merged
into
the
metrics
branch.
So
that's
the
initial
framing,
for
you
know,
make
taking
a
you
know,
a
value
from
instrument
and
pushing
it
all
the
way
to
some
basic
aggregator
to
some
exporter.
C
Obviously
it's
still
very
early
and
it's
subject
to
change
and
improvement.
So
please
don't
take
this,
as
you
know
anything
near
final,
but
the
next
step
on
it
is
that
I
think
there's
a
bunch
of
to-do's
in
there
starting
off
with
right
now
the
metric
item,
which
is
basically
the
definition
of
what
a
metric
is,
is
still
undone
or
ambiguous.
C
So
I
think
that's
where
I'm
gonna
try
and
clarify
what
a
metric
item
means
and
that
metric
item
is
what's
being
passed
to
all
of
the
processors,
including
the
exporter
and
then
so.
That's,
I
think
me
and
cj
were
kind
of
wanting
to
kind
of
lock
that
down
a
bit
and
then
probably
this
thursday,
maybe
riley
will
have
some
view
api
information
for
us,
maybe
in
which
case
we
might
you
know,
start
looking
at
that
and
maybe
doing
something
there.
C
So
that's
the
second
item,
and
then
the
third
item
is
that
I
know
in
the
two
weeks
ago
riley
asked
the
sdks
this
question,
which
I
don't
know
that
we
fully
answered
yet
is,
is
it
possible
and
how
would
we
support
multiple
frequencies
for
exporters
and
so
that's
also
an
area
that
I've
been
kind
of
trying
to
investigate
how
to
do
that
yeah.
So
those
are
the
three
areas
that
I
think
we
could
work
on,
and
anybody
who
wants
to
jump
in
and
help
please.
You
know
please
do
so.
A
So,
just
to
add,
like
that,
multiple
frequency
requires
a
bit
more
clarification.
It
is
multiple
frequency
within
the
same
provider,
so
you
have
a
single
provider
which
has
some
metrics,
which
is
expected
to
go
at
like
10
second
interval
and
some
metrics,
which
are
expected
to
be
like
send
out
us
like
one
minute
interval.
So
that's
the
question
which,
like
spec,
wants
to
answer
like.
If
it
is
different
provider,
then
we
are
already
fine,
but
the
same
provider
is
probably
very
complex.
We
just
don't
know
how
complex
it
would
be.
Yeah.
C
So
the
so
I've
been
talking
to
josh
joshua
mcdonald
in
his
gold
implementation
per
se,
and
so
it's
the
go.
Implementation
currently
also
does
not
support
multiple
frequency
for
exporter,
so
we're
kind
of
toying
with
you.
B
A
But
like
victor
like
this
is
something
which
we
are
not
like
trying
to
solve
like
right
away
because,
like
I
think
like
you
would
be
mostly
focusing
on
defining
the
metric
item
class
for
that
that's
correct.
Okay,.
C
A
Yeah
and
I'll
like
work
with
you
and
also
try
to
see
if
we
can
get
some
views
getting
started,
I
did
create
a
views
prototype
in
the
old
I
mean
now
deprecated
and
thrown
away
matrix
branch,
but
maybe
like
we
can
resurrect
some
of
the
code
from
that
or
maybe
like
just
rebuild,
based
on
the
existing
code
like
how
do
you
configure
a
view
and
it's
still
again
prototype,
because
the
spec
itself
is
being
in
pr
stage?
A
Only
it's
not
marked
at
all,
so
we'll
see
how
it
goes
so,
most
likely
we'll
have
like
more
updates
about
both
next
week
about
the
metric
item,
definition
and
views.
The
multiple
frequency
thing,
probably
like
in
like
another,
two
or
three
weeks
whenever
we
are
done
with
other
two
items,
correct
yeah
and
I
did
think
with
allen
like
last
week.
Like
allen,
do
you
have
like
any
update
to
share
like
basically,
we
are
trying
to
see
like
whether
we'll
get
like
more
hands
doing
more
work?
A
So
if
we
finish
the
initial
like
structuring
and
define
metric
item,
then
that
unblocks
anyone
from
writing
a
proper
exporter
like
a
prometheus
or
an
otlp
one
and
also
like
we
are
almost
unblocked
right
now
from
writing.
A
instrumentation
for
asp.net,
core
http
client
to
start
emitting
matrix
using
the
new
api.
A
So
those
are
like
all
items
which
can
happen
while
the
core
sdk
is
still
being
worked
on.
So
if
anyone
has
cycles
and
interested
in
working,
please
let
us
know
we
can
create
work
items
and
start
assigning,
but
if
no
one
else
is
going
to
work
on
it,
like
we'll
just
focus
on
the
sdk
pieces
right
now
and
come
back
to
instrumentations
and,
like
actual
prometheus
exporters.
Slightly
later.
B
Yeah
I've
spent
planning
on
spending
a
little
bit
of
time
this
week.
You
know
I
I
did
a
kind
of
proof
concept,
a
while
back
based
off
of
the
old
api
for
the
asp.net
core
instrumentation,
and
I
was
thinking
about
dusting
that
off
and
seeing
how
it
fit
with
the
new
stuff.
And
if
that
was
ready
and
and
yeah
I
haven't.
I
haven't
considered
the
the
otlp
exporter
stuff,
but
it
sounds
like
there's
still
some
things
that
need
to
fall
into
place
before.
A
Oh
yeah
yeah.
We
need
to
first
define
what
the
exporter
interface
would
look
like,
basically
defining
the
metric
item,
the
thing
which
exporter
gets
so
yeah,
that's
still
being
worked
on,
so
we
should
have
a
good
answer
by
end
of
this
week.
What
that
metric
item
would
look
like
yeah
and
after
that,
like
if
you
like,
if
you
think
that
you
will
have
time,
you
will
create
an
item
and
you
can
work
on
that
exporter,
while
victor
or
myself
would
work
on,
like
other
sdk
aspects
based
on
the
spec
progress.
A
Yeah
and
let
us
know
like
if
you
need
like
help
with
the
like
any
any
questions
about
writing
that
instrument
instrumentation.
I
think
there
were
like
open
questions
which
we
are
trying
to
answer
at
that
time.
Like
do,
we
create
a
single
diagnostic
source
subscriber
or
do
we
create
like
multiple
one
for
tracing
and
one
for
matrix?
A
B
A
Want,
okay,
got
it
yeah
yeah!
That's
like
a
general
status
for
metrics,
like
in
case
anyone
is
not
aware.
The
api
is
already
part
of
the
dot
net
preview.
Six
it's
available
in
daily
builds
now,
and
it
should
be
available
in
like
public
nougat
like
sometime
in
next
two
weeks,
so
you
can
like
take
a
look
at
it.
A
Use
it
if
you
have
any
feedback,
share
it
directly
with
dotnet
team
or
bring
it
to
the
open
sig
and
we'll
forward
it
to
the
tottenham
team,
because
one
of
the
goal
which
victor
and
I
am
trying
to
follow
was
we
want
to
make
sure
we
like
give
any
feedbacks
to
the
dotnet
team
at
the
earliest,
so
that
like
they
can
address
it
in
their
dotnet
six
time
frame.
A
That's
pretty
much
the
only
task
from
the
community
like
any
optimizations
for
aggregator
or
anything.
We
can
do
it
without
net
team
support.
We
can
like
take
enough
time
and
do
it,
because
we
already
have
a
number
commitment
to
that,
but
for
net,
as
we
all
know
like,
we
have
to
give
feedback
at
the
earliest,
so
that
they'll
have
enough
time
to
incorporate
that
into
like
upcoming
preview
releases
and
landed
in
dot
net
six
time
frame
so
yeah.
A
If
anyone
has
like
time,
please
you
try
to
use
the
metric
api
directly
without
open
elementary,
that
they
could
also
give
a
feel
of
okay.
How
how
easy
or
how
hard
the
aps
themselves
are.
They
are
mostly
following
open
telemetry
api
spec,
but
there
are
like
some
dotnet
specific
things
there
as
well.
C
Hey
c
joe,
we
we
had
the
one
time
we
had
the
was
it
the
the
grocery
example
and
whatever
example
riley
has.
We
probably
need
to
update
that
as
well.
Yeah.
A
You're,
like
yeah,
that's
something
which
we
can
come
back
this
week,
yeah,
because
the
whole
metric
sdk
work
is
expected
to
be
based
on
those
two
scenarios
which
are
outlined
in
the
metric
sdk
spec.
Yes,
so,
let's
try
to
I
mean
I
don't
know
whether
we've
ever
merged
it
or
not
like
we
can
try
to
like
rewrite
that
two
examples
with
the
new
apis
and
sdk
and
see
like
how
much
how
much
of
the
requirements
we
already
cover.
A
I
think
that
multiple
frequency
is
a
requirement
in
that,
so
we
can
clearly
say
that.
Okay,
this
is
something
which
we
don't
cover
and
like
views
are
also
part
of
it,
which
we
don't
cover
yet
yeah,
but
yeah.
Let's
work
on
that
like
this
week
or
maybe
early
next
week
as
soon
as
we
are
done
with
the
metric
item,
part.
A
There
is
like
there
is
like
a
console
app
already,
which
is
part
of
the
matrix
branch.
I
believe.
C
Yeah
also,
I
think,
there's
a
outstanding
pr
with
that
grocery
example.
So
we
could
either
revive.
A
A
It
yeah
they're.
The
ones
example
is
the
console
one
which
emits
something
some
metrics
right
yeah.
We
can
use
the
grocery
example
and
okay
yeah.
This
is
the
absolute
basic
example
right:
okay,
yeah:
let's
what
to
get
the
actual
example
into
the
matrix
as
an
example,
so
we
can
always
compare
like
how.
How
much
are
we
done
compared
to
the
expectation
from
the
tip
here,
thanks
for
bringing
it
back,
I
mean
we
think
the
pr
is.
C
A
Got
it
yeah
I
mean
I
I
do
remember
like
looking
at
it
some
time
back,
maybe
like
we
closed
it
without
merging
or
it's
march,
yeah
we'll
find
it
yeah.
Okay,
no
other
topics
to
discuss
so
we'll
see
again
next
week.