►
From YouTube: 2022-05-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).
A
Okay,
I
think
we
can
start.
You
can
start
by
writing
your
name
in
the
attendees
list.
Just
a
side
effect
update,
like
we
mentioned
this
week
back
the
protofiles
for
logs
are
now
stable.
It
just
got
merged
like
few
minutes
back,
so
that
technically
unblocks
us
from
doing
otlp
exporter
for
logs
in
a
stable
way.
A
That's
just
a
update
on
the
specs
side.
It
looks
like
we
have
some
items
in
the
agenda,
so
since
I
added
most
of
the
things
I
can
go
about
it,
but
before
that,
are
there
any
questions,
anything
which
is
not
listed
in
the
agenda
to
discuss.
A
All
right,
let's
start
with
this
one,
so
this
is
something
which
we
discussed
about
a
month
and
a
half,
or
maybe
two
month
and
a
half
about
keeping
the
or
moving
the
instrumentation
libraries
from
the
core
repo
to
the
export
contract
contract
repo.
A
So
I
just
want
to
bring
this
topic
again,
having
written
down
like
all
the
pros
and
cons,
so
I
just
want
to
get
a
q
feedback
from
the
community
right
now
to
see
if
we
should
proceed
with
this
move
and
keep
the
main
repo
only
for
things
which
are
speculated
or
specified
and
all
the
instrumentation
libraries
can
be
hosted
in
the
country.
The
breaker
was
not
in
a
very
great
shape.
It
looks
like
it's
it's
fairly
better.
Now
I
think
the
ca
is
green.
A
A
We
need
to
decide
like
what
would
be
the
criteria,
but
cases
it
gives
us
like
two
advantages.
One
is
we
can
use
that
as
an
indirect
way
of
end-to-end
testing.
A
We
have
like
tests
for
ap
and
sdk,
but
these
instrumentation
libraries
do
like
sort
of
end-to-end
test
like
it
uses
instrumentation
sdk
exporter.
So
it's
a
nice
way
of
doing
it
into
interest,
and
also
we
can
host
like
couple
of
instrumentation
libraries
as
a
reference
guide
for
others
to
follow,
and
I
would
suggest
at
least
http
client
and
sp
netcode,
because
they
are
mostly
aligned
with
the
net
release
lifecycle.
A
So
whenever
there
is
a.net
release,
there
is
new
http,
client
and
shortly
or
almost
on
the
same
day,
there
is
an
asp.net
core
thing,
so
everything
else
could
be
like
potentially
moved.
So
that
would
be.
I
think
we
can
move
asp.net,
grp
senior
client.
If
there
is
no
direct
dependency,
sql
client
could
be
moved
or
we
could
choose
to
keep
it
that
can
be
discussed
and
then
stack
exchange
reduce
can
also
be
moved.
A
This
looks
like
there
is
a
oh
yeah.
Oh
allen
just
mentioned,
so
there
are
like
certain
advantages
because
we
can
like
right
now.
The
release
is
like
really
tight.
Everything
is
like
released
in
one
shot,
so
it's
a
little
bit
slow
as
opposed
to
the
contrary
player.
We
can
independently
release
any
of
the
packages
and
also
like
it's
very
much
what
others
are
doing
in
the
open
elementary
space.
They
keep
the
core
ripper
very
small
and
agile,
and
keep
all
the
things
outside.
So
any
comments
or
thoughts
on
this
one.
A
Okay
now
comment,
so
I
think
I
hear
no
objection
so,
which
means
I
can
at
least
start
moving.
Some
things
maybe
start
with,
along
with
suggesting.
A
Yeah
I
mean,
if
you
are
choosing
like
completely
arbitrary.
I
would
prefer
to
keep
the
http
client
and
asp.net
core
purely
because
they
are
like
shipped
by
the
runtime
itself,
which
we
anyway
have
a
strong
dependency
on,
so
be
typically
not
required,
but
typically
we
would
have
a
open
elementary
release
following
every
dotnet
major
release,
because
we
have
a
hard
dependency
on
the
system,
dot
diagnostic
source,
at
least
in
the
initial
fields
like
once
things
get
stabilized.
A
We
may
not
need
to
do
anything
it
would.
It
should
just
work
as
long
as
they
don't
break
any
backward
compatibility
things
but
yeah,
so
I
would
start
with
moving
the
radius
and
grpc
client
if
I
can
move
it.
A
Grpc
and
asp.net
core,
not
http
client,
so
I'll
have
to
check.
I
think
asp.net
core
is
like
a
mix
of
both
spinal
cord
and
grpc.
So
if
you
keep
hp
net
core
here,
then
that
means
the
grpc
for
server
would
automatically
be
in
the
same
repo
but
then
grpc
client.
If
it's
completely
independent,
we
can
just
need
to
know
like
whether
there
are
any
inter
dependencies
between
them
yeah.
A
A
A
The
easiest
to
start
with
would
be
ready,
so
maybe
we
can
test
the
water
with
just
that
and
then
maybe
next
deal
with
sql
and
then
deal
with
the
grpc
one
or
maybe
the
asp.net
code
and
spin
it.
These
two
are
relatively
isolated
from
everything
else,
so
that
could
be
moved.
So
there
is
another
question
about
the
examples,
because
we
have
been
keeping
examples
here.
A
I
don't
know
whether
we
are
yet
ready
to
move
it
out.
One
concern
is
like:
if
we
move
the
grpc
thing
then
we'll
have
to,
it
would
be
better
if
you
move
the
grpc
example
as
well,
because
it's
currently
a
project
reference.
A
So
I
think
when
I
do
the
actual
movement
I'll
probably
move
some
of
the
examples,
the
asp.net
one.
So
we
can
only
maintain
the
console
and
spin
it
core
one.
It
may
be
the
micro
service
example
for
now,
but
there
is
a
overall
open
elementary
white
test
application
or
demo
application
being
brought
up,
so
it
won't
be
just.net.
It
will
be
like
mix
of
every
language,
so
we'll
see
what
they
are
doing
and
try
to
steal
something
from
that,
so
potentially
creating
a
dedicated
repo.
A
Just
for
the
examples,
I
think
that's
what
java
does,
but
anyway,
let's
take
it
one
step
at
a
time.
So
I'll
only
move
those
examples
which
are
like
really
easily
liftable,
along
with
the
corresponding
instrumentations.
A
A
I
think
this
is
a
point
which
you
want
to
discuss
like
what
do
we
do
with
known
like
non-standard
type,
4
attribute
values.
A
A
A
Let's
see
if
we
can
find
it
from
the
conversation,
I
think
this
is
the
one
which
you
wanted
to
discuss,
maybe
yeah.
This
is
this.
Is
it
yeah.
B
Yeah
so
this
method
I
mean
just
so
everybody's
aware
at
this
point
it
it
only
is
used
for
currently
resource
attributes,
attributes
on
metrics
and
attributes
on
logs.
The
trace
exporter
has
its
own
awesome
sauce
as
far
as
attributes
go.
B
So
it's
it's
not
quite
in
line
with
this
pr
with
the
all
the
supported
types,
but
I'm
going
to
follow
up
with
that
for
for
the
trace
stuff,
but
basically
the
the
main
conversation
that
I
was
hoping
to
drive
with
this
pr
was
just
to
settle
on
the
types
that
we
want
to
declare
support
for,
and
so
I've
effectively
expanded
it.
It
now
supports
almost
all
of
the
built-in
value
types
for
c-sharp
plus
strings,
of
course,
and
and
arrays
of
all
of
those
things.
A
B
That's
that's
what
this
pr
does.
You
did
highlight
that
it.
It
does
also
introduce
a
breaking
change,
which
is
a
point
of
conversation
for
us
to
have.
I
didn't
actually
realize,
but
it
I
guess
at
some
point
in
time
all
of
our
exporters,
jaeger,
zip
pin
and
so
on
do
just
a
two
string.
Any
arbitrary
object
that
isn't
one
of
the
you
know
other
types
I
thought
at
one
point
we
were
inconsistent
in
that
way,
but
in
this
pr,
as
I
currently
have
it,
it
does
not
do
that.
B
I
don't
know
if
that's
the
right
thing
to
do.
I
have
some
opinions
about,
like
you,
know,
tostring
being
potentially
weird
and
maybe
problematic
in
some
cases,
but
if
people
feel
strongly
that
we
should
not
make
this
change
this
breaking
change,
I
my
my
opinion
is
not
super
strong.
I
just.
C
A
But
the
point
here
is
like
the
open
elementary
specification
does
not
even
allow
like
a
date
time
to
be
used
to
say,
attribute
value,
so
it's
just
that.
Like.Net
does
not
have
like
any
nicer
way
of
designing
that
api.
It's
just
object,
so
it
can
take
everything,
so
I
don't
think
like
we
need
to,
like
suppose,
someone
puts
like
a
good
or
a
daytime
or
something
else
which
even
though,
has
a
nice
string
representation.
A
A
Yes,
that's
a
that's
the
only
concern
which
which
should
be
the
case
for
anything,
because
the
off.net
api
is
not
just
meant
for
open
telemetry.
It
can
be
used
outside
of
open
telemetry.
So
they
like
something
known,
open
telemetry
could
support.
A
B
B
Right
yeah,
so
I
mean
they
have
the
yeah.
The
api
implementation
is
in
the
open,
telemetry
project,
so
yeah,
that's
the
key
difference
here.
A
B
So
it's
going
to
be
supported
on
the
issue
of
of
this.
That's
linked
to
this
pr
that
I'd
opened
a
while
back
someone
had
commented
on.
I
mean
this
is
just
an
idea.
I
don't
know
if
it's
the
greatest
idea,
but
it
had
commented
on
this
point.
If
you
scroll
down
a
little
ways,
it's
this
guy,
the
cj
cg110
in
one
of
his
comments
he
said
like
hey.
B
B
B
Well,
I
think,
ideally,
we
we
make
a
decision.
I
know
this
pr
is
just
in
the
context
of
the
otlp
exporter,
but
I
think
we
make
a
decision
and
and
try
our
best
to
make
all
of
them
align.
At
least
that
was
my
thought.
A
A
A
custom
thing
yeah,
it's
not
like
the
sdk
itself
can
enforce
it.
Like
I
mean
I
mean
if
that
was.
If
we
were
to
enforce
it,
then
the
sdk
before
giving
items
to
the
exporter
should
like
drop
everything
which
is
now
one
of
the
type
that's
going
to
be
quite
expensive.
You
might
write
over
it
and
do
that
in
the
sdk
itself.
A
Right
yeah,
but
I
mean
I,
I
still
don't
have
a
proper
answer
for
the
original
concern
which
michael
was
raising
like
it
would
be
unexpected
for
certain
users
that
they
would
be
using
the
they
would
be
just
using
that
activity
and
there
is
no
intelligence
or
anything
which
tells
what
values
are
supported.
So
they
might
be
like
accidentally,
using
like
things
like
time
span
or
dating
or
like
guide,
may
be
like
the
goodies,
the
class.
So
they
could
be
using
those
things.
A
C
A
Think
one
option
is
like
if
we
like-
let's
assume
that
we
are
going
with
this
approach
of
not
supporting
it
and
not
pulling
to
string,
we
could
like
emit
that
warning
like
if
you
are
ever
going
to
drop
anything.
We
can
just
do
a
warning
as
well,
so
at
least
they
know
like
if
they
are
missing
like
something
they
would
know
from
the
lobby
that
okay.
This
is
the
reason
why
this
is
missing.
It's
because
we
don't
know
how
to
convert
this
value,
so
we
are
just
dropping
it
on
the
floor.
A
C
C
I
formattable
is
available
since
like
400,
so
that
one
you
can
always
do.
I
think
I
span
formattable
is
also
always
I
formattable
you
can
just
do
it.
You
can
format
to
a
span
in
the
newer
runtimes
that
doesn't
really
help
us
in
this
case,
because
we
need
to
basically
end
up
with
a
string
anyway,
there's
no
way
to
avoid
that
allocation.
So
if
we
just
went
with,
I
formattable,
it's
probably
fine,
it's
something
we
can
look
into.
A
Okay
yeah,
it
looks
like
a
lot
of
almost
all
the
things
which
we
want.
On
top
of
that
we
get
like
some
nice
potential
things
which
people
could
be
and
accidentally
putting
like
daytime
goods
yeah
wrong
times.
Man
yeah,
oh
lot
of
things
from
windows,
okay,.
A
Okay,
so
let's
put
a
comment
on
that
pr
about
like
potentially
raising
this
may
be
like
we
can
take
it
as
a
follow-up
like
which
merge
this
pr,
like
first
make
it
consistent
at
least
within
otlp
resource
logs
and
tracers,
or
maybe
like
we
can
like
block
the
pr
from
vmers.
Until
we
explore
this,
one
either
way
works
fine,
and
then
you
can
decide
whether
you
want
to.
B
Yeah
and
then
we
can
move
forward
and
then
and
then
try
the
I
formattable
approach,
because
this
pr
does
fix
some
important
things
that
yeah.
A
A
D
A
Oh
okay,
yeah
thanks
for
this,
so
think.
The
only
concern
which
I
had,
which
I
left
in
the
previous
year
was
that
do
we
mean
this
pr
is
introducing
the
copied
version
of
metric
which
is
unaffected
by
subsequent
updates
to
the
metric.
A
So
the
question-
which
I
think
mothra
is
also
asking-
and
I'm
also
asking
is:
do
we
want
to
allow
in-memory
exporter
to
continue
to
be
used
the
old
way
where
it
would
be
affected
by
subsequent
updates,
but
they
choose
to
do
that,
or
should
we
just
block
in
memory
exporter
from
ever
using
that
and
only
allow
the
new
api
which
would
be
the
metric
metric
copy?
A
Any
anyone
has
thought
like
maybe
like
branch
you
might
have
like
explored
this
little
bit
in
the
early
days
that
you
are
helping
us.
Do
you
have
any
thoughts
on
this
one?
Actually,
maybe
just
find
the
original
pr.
That's
it
the
super
seeds
right
there.
Oh,
the
supersuits
one.
Yes,
that's
where
I
saw
the
cod
snippet,
which
found
a
little
bit.
Let
me
just
open
that
exact
spot.
D
So
the
the
comments
I
was
getting
on
this
original
pr
is
that,
since
we
know
that
metric
is
buggy,
should
we
allow
any
user
to
like
continue
to
create
the
exporter
and
expect
a
metric
to
be
exported?
D
So
I
was
told
that,
like
we
know,
it's
buggy,
we
shouldn't
ship
it.
So
I
blocked
it
here
with
the
third
exception
and
then
cj
saw
it
and
he's
like.
D
A
A
So
with
this,
even
without
this
throwing,
we
know
we
still
live
with
that
assumption.
So
any
if
someone
is
using
in-memory
exporter,
they
have
to
understand
that
the
state
could
be
updated,
but
if
they
orchestrate
things
in
such
a
way
like
they're,
usually
used
for
unit
tests.
So
if
you
orchestrate
things
in
such
a
way
that
you
don't
provide
any
update,
then
you
kind
of
leave
with
that
limitation.
So
that's
why
we
already
had
like
all
these
tests,
which
were
like
running,
and
we
do.
D
Have
some
valid
use
cases
where
some
unit
tests
prometheus
and
the
otlp
are
testing
their
unique
serialization?
So
those.
B
D
Want
the
actual
metric
object
so
by
blocking
it
here
I
had
to
then
like
do
some
other
stuff
to
still
provide
them
with
that
metric
object.
So
the
newer
pr
to
balance
the
two
is
in
the
extensions
class.
I
just
put
a
remarks:
is
that
like
hey,
if
you
use
this
be
aware,
metric
can
still
get
updated.
A
Anyone
else,
like
any
opinions
on
this
one,
I
don't
think
like
there
is
a
perfect
answer.
How
to
like
find
some
balance.
I
mean
like
two
choices.
We
have
one
is
to
leave
both
options,
so
in
memory
exporter
can
be
used
with
the
like
metric
classes,
just
like
any
other
exporter,
but
they
whoever
is
using
it.
They
should
understand
the
limitation
just
like
any
other
exporter,
so
that's
things
being
consistent
and
for
testing
purposes.
A
We
wanted
to
give
this
additional
option
for
people
who
want
to
test
things
and
not
being
affected
by
subsequent
updates.
So
for
that
we
provide
anything
on
top
of
the
existing
thing.
So
that's
why
I
was
suggesting
we
should
keep
the
existing
one
if
the
user
use
it
it's
their
choice
and
we
should
make
it
feasible
for
them
to
do
the
proper
testing
without
being
affected
by
by
allowing
this
extra
apa.
A
So
my
thinking
is.
We
should
keep
both,
of
course,
like
the
document
should
say
that
this
one
is
the
preferred
one,
because
this
would
be
unaffected
by
any
subsequent
updates.
But
if
you
don't
care,
then
you
can
simply
use
it
just
so
that
it
looks
like
nicer.
A
You
know
that
you
are
getting
the
exact
same
thing
as
any
other
exporter
would
get
like
prometheus
or
anything
else.
So
it's
I
think
it.
There
is
some
value
in
keeping
that,
but
I
I
just
want
to
hear
from
others
for
like
whether
anyone
else
have
opinions
on
the
suspect.
B
I
haven't,
I
can't
say
that
I've
stayed
super
up
to
date
on
this
pr,
but
just
on
this
question
of
keeping
both
the
way
that
I've
been
kind
of
thinking
about
the
memory
exporters
that
we're
the
end
users,
it's
for
unit
tests-
and
I-
and
I
haven't
heard
anybody
talk
about
like
other
use
cases
like
actual
like
production,
use
cases
or
something.
So
I
I
too
like
the
idea
of
just
providing
both
options
if
they're
valuable
for
our
purposes
for
our
test
unit
test.
A
Purpose-
oh
it's
not
just
just
like
there
are
other
people
who
write
instrumentations.
They
want
to.
You
know
test
that
they
are
emitting
it
the
right
way
so
for
them
also
like
they
can
also
use
in
memory
export
because
they
cannot
like
really
export
it
to
like
otp
and
validate.
So
they
can
use
in
memory
exporter
to
validate
that.
Their
instrumentation
is
emitting
the
matrix
with
the
right
name,
right
value,
and
so
it's
used
for
testing,
but
not
just
for
testing
by
ourselves.
It
could
be
used
by,
like
other
library,
orders
as
well.
B
A
A
Haven't
been
super
up
to
date
with
the
latest
changes,
so
yeah,
maybe
like
we'll,
give
it
like
another
day
for
folks
to
give
it
some
thoughts
like
the
argument
is
like
we
mean
just
to
give
the
background
once
again
like
we
did
not
ship
the
in-memory
exporter
as
stable,
because
we
wanted
to
see
whether
it
could
be
like
we
would
be
like
breaking
it
in
to
support
the
metric
okay
one.
A
So
whatever
we
decide
here,
if
you
choose
to
like
just
break
the
existing
one
and
keep
the
metric
op
one,
that's
fine
like
there
is
no
like
actual
impact
on
the
release,
because
we
never
released
a
stable
of
in
memory.
So
that's
the
additional
background
context.
I
think
you
you
were
gone
when
we
did
the
actual
release.
Okay,
yeah,
let
like
please
go
and
take
a
look
at
the
pr
like
leave
your
comments,
so
the
I
think
the
most
recent
pr
is
the
only
one
which
is
open.
A
Everything
else
is
closed,
but
it
does
help
yeah.
It's
the
previous
ones,
are
still
kept
as
drafts
in
case.
You
want
to
see
the
comments
which
we
just
talked
about
about
like
throwing
or
just
keep
it
supported.
If
you
really
want
to
use
the
old
way
fully
understanding
the
consequence
then
go
for
it
or
if
you
want
to
do
like
the
copied
one,
then
you
can
do
it.
D
A
D
Yeah
most
likely,
I
think
I
did
a
different
hack
to
make
that
work
yeah.
I
solved
it
with
a
different
method.
Okay,
so
I
think.
A
The
reason
is
like
if
we
keep
the
original
memory
exporter
for
unit
testing
the
people
who
are
testing,
they
know
that
they
are
getting
the
exact
metric
as
any
other
exporter
would
get
so
maybe
like
they'll
feel
more
confident
and
they
are
okay
to
orchestrate
things
in
such
a
way
as
to
not
have
any
further
updates,
and
it's
very
easy
to
orchestrate
that
way,
because
all
our
existing
tests
were
working
even
with
this
limitation.
A
A
Okay,
so
we'll
give
like
folks,
one
more
day
or
maybe
two
more
days
just
to
go
and
look
at
it.
I
would,
I
think
there
is
a
ask
to
do
a
release,
so
we
see
like
if
it
happens
in
the
next
one
or
two
day,
we'll
do
the
release,
including
the
this
change.
Otherwise
we'll
keep
it
open.
But
I
encourage
everyone
to
like
spend
a
little
bit
of
time,
because
we
explicitly
did.
A
Exporter
to
support
this
scenario,
so
we
would
be,
I
mean
we
want
to
release
it
in
1.344
and
based
on
our
promised
milestones,
we
don't
have
a
lot
of
time
for
the
next
stable
release.
So,
let's
quickly
look
at
that
as
well.
The
last
topic
is
also
about
release,
so.
A
Students
so
1.3
we
would
be
releasing
in
like
less
than
20
days
from
now,
because
the
main
thing
is,
we
don't
have
any
features
added.
We
have
like
some
bug,
fixes
some
additional
metrics
added
in
the
http
and
this
one
there
is
no
update
on
the
spec
yet
so
quite
likely.
This
will
be
moved
out
of
this
one,
but
the
other
key
thing
would
be
supporting
the
memory
exporter
stable.
One
then
rusty
are
all
like
cleanups
and
dropping
those
things
so
yeah.
A
The
reason
is,
we
have
done
so
many
changes
in
the
login
otlp
log
exporter
area,
which
people
want
to
use
so
I'll,
be
proceeding
with
a
release
if
we
can
get
matrix
before
that,
that
would
be
great,
but
if
it
doesn't
meet
this
day,
we
can
still
do
it
in
beta
3,
because
there
is
not
not
much
risk
of
doing
it,
even
in
like
very
close
to
the
actual
1.3
stable.
A
Okay,
I
think
that
covers
all
the
topics
and
I
already
updated
about
the
otlp
log
product
being
stable,
so
we
are
kind
of
unblocked
now
from
using
the
otp
exporter
in
a
stable
way.
We
have
like
few
other
things
to
resolve,
so
we
won't
be
declaring
each
table
right
away.
We
just
should,
like
I
mean
we
haven't
shipped,
we
merged
prs,
which
improved
the
otp
log
exporter.
A
So
once
we
ship
this
thing
and
ask
people
to
use
it,
we
know
of
more
feedback,
because
we
enabled
one
thing
was
the
scopes
thing
I
logo
scopes.
A
A
Different
people
have
a
completely
different
expectation
from
scope,
so
we'll
see
like
how
the
next
release
goes
and
based
on
that
are
just
something
anyway,
we'll
make
a
final
quote
before
we
call
it
stable
any
other
questions
to
come,
and
I
just
want
to
like
quickly
ask
a
couple
of
things.
So
there
are
like
plenty
of
issues
which
are
marked
like
good,
first
issue
or
help
wonder
so.
If
anyone
has
he's
looking
to
contribute,
please
like
try
to
help
here.
A
A
It's
been
a
pain
to
merge
beers,
because
this
is
very
flaky
fails
frequently,
I
think
mothra
did
some
investigation
here
but
like
we
don't
really
want
to
be
doing
this
way.
We
just
want
to
move
to
the
right
way
of
logging,
which
is
like
somewhere
yeah
dotnet
has
documented
the
process.
A
How
many
volunteers
to
look
at
this?
That
would
be
great
because
this
is
like
really
affecting
our
case.
Like
constantly
we
have
to
retry
the
cas.
I
mean
only
maintenance
access
to
retry,
okay.
So
if
anyone
has
volunteer,
I
mean
what
I'm
doing
for
this
one
I
will
assign,
if
not,
we
keep
waiting
and
then
there
are
like
other
few
other
things
as
well
here.
So
please
take
a
look
and
see
if
you
have
time
for
working
on
anything.
A
All
right
that
ends
discuss
any.