►
From YouTube: 2022-07-18 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
B
B
Okay,
me
too:
okay,
thanks
yeah.
So
probably
I
think
just
a
brief
about
the
specs
update,
I
think
which
can
potentially
affect
that.
However,
changes
in
cpr
space
implementation-
I
don't
see
anything
directly
affecting,
as
of
now
so
add,
support
for
partial
success
in
the
otp
export
response.
A
B
Open
and
probably
it
will
need
some
changes
in
our
otlp
exporter
once
once
the
changes
are
merged.
So
it's
basically
supports
not
just
success
in
failure,
but
also
the
partial
upload
status
or
partial
success.
B
B
B
Other
discussion
going
on
the
split
schema
transformation.
I
don't
see
as
of
now
directly
affecting
us,
we
don't
suff.
I
mean
we
don't
have
that
transformation
from
the
schema
files
to
these
source
files
for
c
c
plus
place
for
matrix.
As
of
now
I
know
mark
you
have
done
the
implementation
for
traces
and
resources,
but
for
matrix
we
haven't
done
so.
B
Environment
variables
are
stable,
so
this
this
is
for
matrix,
periodic
matrix
export
environment
variables.
We
don't
have
to
have
this
provided
support
of
that.
The
environment
variables
are
still
optional,
but
we
do
support
the
matrix,
the
x,
the
variables
for
otlp
exporters
for
traces
and
also
for
matrix.
So
I
think
it's
good
to
support
to
continue
supporting
it.
Also
for
the
periodic
exporter,
so
I'll
create
a
github
issue
for
this,
and
probably
you
can
take
it
over.
B
Clarify
the
configuring
aggregation-
I
haven't
gone
through
this,
but
probably
I
think
it's
still
open,
but
yeah.
I
think
probably,
if
somebody
didn't
want
to
go
through
this,
I
haven't
gone
through
that,
but
it's
good
to
really
mention
that
in
the
potential
changes
in
the
specs
which
can
have
changes
in
our
matrix
implementation.
B
Anything
else
you
or
you,
anybody
feels
that
there
is
texts,
changes
which
can
have
any
any
potential
change
in
our
traces,
matrix
or
logs
implementation.
This
is
a
consolidation
of
what
I
have
been
seeing
from
past
one
week.
I've
just
had
it
here.
A
B
So
I
have,
I
don't
know
I
think
I
I've
been
working
so
in
memory
magic
exporter.
I
think
this
is
already
in
review.
There
are
some
issues
in
build
for
windows
and
probably
I
think
if
we
need
to
look
into
that,
what
exactly
is
the
issue
in
this?
I
think
jan
was
working
on
that
I
think
he
was
not
able
to
figure
out
the
issue.
He
didn't
have
the
environment
to
really
debug
it
further.
B
B
B
But
I
think
this
was
something
so
I
felt
it's
a
substantial
change.
It
took
some
time
to
really
work
on
this,
so
it
basically
has
three
different
changes.
One
is
to
support
adding
multiple
callbacks
for
a
given
async
instrument.
As
of
now,
we
only
support
adding
one
callback
releasing
instrument,
and
so
second
is
that
now
that
we
support
multiple
callbacks,
that
we
have
to
ensure
that
the
callback
should
be
called
only
once
for
a
given
instrument.
A
B
May
be
multiple
views
defined
for
a
given
instrument,
so
that
means
there
will
be
multiple
storage.
Multiple
exports
happening
through
a
given
instrument,
but
that
does
not
mean
that
we
should
be
calling
callbacks
multiple
times
for
that,
and-
and
apart
from
that
now
that
there
are
multiple
async
callbacks,
we
also
have
to
take
care
about
the
attribute
filtering.
We
should
be
doing
attribute
filtering
separately
for
each
of
the
views
different
views
so
that
that's
a
change
three
changes.
B
I'll
summarize
that
in
the
description-
and
probably
it
will
be
ready
for
me
for
review
this
one
is
and
other
one
was.
I
think
that
would
be
also
somewhat
substance,
not
a
very
big
change,
but
I
think
some,
a
medium
change
would
be
add
configuration
option
for
irrigation
creation.
We
don't
support
it
as
of
now
and
that
requirement
has
been
coming
every
now
and
then
so.
Basically,
we
use
example
is
for
histogram
application.
B
We
just
use
the
default
values
default
values
for
the
buckets
as
the
default
values
will
be
specified
by
the
sdk,
but
I
think
sdk
owners
should
be
able
to
modify
those
bucket
values
and
they
should
be
able
to
configure
it.
Similarly,
for
that
aggregation
also,
so
that
has
to
be
added.
It's
not
there.
As
of
now
yeah.
A
We
somehow
support
this
right.
We
we
have
this
constructor
that
they
can,
at
the
point
data
point
or
pointing.
B
B
Pipeline
of
specifying
is
missing,
I
think
in
aggregation.
So
if
you're
talking
about
the
aggregation
class-
probably
it
may
be
there,
but
it's
not
there
in
the
view
class
somewhere.
In
the
view
we
have
to
provide
a
support
to
so
that
sdks
owner
should
be
able
to
provide
their
own
bucket
values
so
quickly
going
to
even.
A
No,
we
have
this
constructor
that
takes
a
point
data
or
data
pointer,
how
it's
called
there.
You
can
change
the
pocket
values.
B
Yeah
yeah,
I
that's
right,
but
we,
the
problem,
is
we
this?
We
are
not
calling
it
anywhere.
As
of
now
I
mean
there
is
no
way
to
call
this
constructor,
and
so
we
don't
provide
a
mechanism
even
though,
even
though
this
this
conceptual
supports,
but
we
don't
provide
a
mechanism
for
the
application
developer
to
provide
these
values
and
pass
it
to
this
constructor.
B
B
B
Type
where
we
specify
what
type
of
aggregation
it
is,
but
somewhere
it
should
come
like
the
way
we
are
providing
the
attributes
processor
to
filter
somewhere.
We
have
to
provide
the
first
so
based
on
the
aggregation
type,
which
is
specified
here.
Somehow
we
have
to
specify
the
complication
for
the
aggregation
type.
Also,
okay,.
B
Then
somehow
somehow
it
should
come
in
the
view
constructor.
What
are
the
configurations
which
a
histogram
can
take?
We
have-
which
I
mean-
I'm
not
sure
it
should
come
here,
but
somehow
here
we
need
to
provide
a
mechanism
in
the
views
to
provide
the
configuration
values
and
then
pass
it
to
the
h2ground
aggregation
class.
B
B
B
B
B
I
mean
at
least
supporting
the
aggregation.
It
should
not
be
bigger
change.
We
do
need
to
modif
support
this
in
configuration
also-
and
apart
from
that,
I
think
this
would
be
a
smaller
change.
I
think
it's
how
we
end
up
with
how
we
specify
the
aggregation
temporarily
and
reality
that
needs
some
change
and.
B
B
And
yeah
at
the
exponential
histogram
aggregation
we
don't
support
as
of
now
and
yeah.
This
is
to
upgrade
the
instrumentation
library
map
to
the
scope
matrix.
So
I
think
scope
is
not
looks
clear
to
me.
I
think
it's
we
just
need
to
define
how
much
time
it
is
going
to
take.
I
don't
think
it's
in
july
31st
still,
but
I
have
been
adding
a
couple
of
weeks
every
time
one
week
prior
to
the
deadline
just
keeps
on
heading,
but
I
think
let's
do
one
thing,
probably
in
the
next
meeting.
B
I
think
it's
good
to
really
discuss
this
and
probably
see
have
have
more
accurate
timeline
for
this,
and
then
I
think
we
can.
We
should
be
good.
B
A
A
A
B
Okay,
fine
yeah,
that's
what
I
I
just
kept
kept
it
open.
I
thought
probably
you
want
me
to
want
to
debug
it
hey
tom.
Do
you
have
any
idea,
like
this
delete
macro
coming
from
somewhere
from
windows,
library
from
any
of
the
library
which
is
kind
of
strange?
This
is
a
very
generic
macro.
I
mean
surprised
that
somebody
is
defining
it
like
this.
A
Given
that
it's
only
failing
on
one
platform,
I
suspect
that
it's
coming
from
some
windows
out
of
file.
If
it
was
coming
from
grpc
or
upsell
or
whatnot,
it
would
fail
on.
B
A
A
I
haven't
heard
about
who
we're
just
finding
this
live
eraser
library,
but
I
can't
in
the
world
replying
as
well.
B
B
Otlp
http
matrix
exporter.
I
think
I
have
done
a
review
of
this
and
looks
good
to
me.
B
That
should
be
this,
is
I
mean
this
is
because
of
one
of
the
pr
which
should
be
merged
today,
so
yeah.
So
I
think
once
it's
once
it's
reviewed
by
one
of
you
guys.
I
think
I
can
probably
it
should
be
good
to
have
been
good.
You
can
ask
him
to
erase
it
and
then
I
think
we
should
be
able
to
go
to
merge.
A
B
B
B
B
Is
it
for
linux?
Okay,
this
is
called
this
is
for
linux.
This
is
a
different
issue.
I
think
probably
some
of
the
constructs
from
google
tests
are
not
supported
in
gcc
4.8.
This
is
feeling
for
that.
So
probably
this
at
least
we
know
what
to
do
for
this.
We
may
have
to
remove
that
google
google
test
constructs,
but
I
think
it
was
something
else.
Something
else
is
successful.
Right
you
can
see.
It's
clicking
on
your
result
is
not
freaking.
B
If
in
bazel
we
need
to
see
in
bezel,
we
may
have
defined
the
macro
for
matrix
preview.
Indeed,
in
that
case,
this
code
may
not
be
built
also,
so
that
could
be
also
given
a
case
in
britain
that
need
to
see
I
mean
if
we
are
already
building
the
bezel
with
that
macro
enabled
for
the
matrix
preview,
then
this
code
will
not
be
called
so
that
has
to
be
seen.
B
A
So
I
have
a
question
in
general:
what
what
do
we
do
with
dependencies?
Do
we
try
to
keep
up
to
date
with
them
or
not,
because
it's
with
bazel,
I
noticed
today
that
absol
also
is
moving.
A
B
B
It
should
be
just
specific
to
you,
the
the
components
which
are
dependent
on
those
libraries.
I
think
we
probably
have
should
have
an
exception
for
those
components.
They
may
not
be
able
to
bring
with
c
plus
plus
11,
but
in
general,
because
otlp
exporter
is
not,
everybody
would
be
using
otd
exporters
just
because
of
the
otd
grpc,
not
supporting
c
plus
11.
B
B
So
I
mean,
if
absence
of,
say,
observers
stop
supporting
c
plus
plus
11.
Then
in
that
case,
probably
we
may
not
be
able
to
build
the
sdk
using
epson
libraries
and
we
will
not
be
able
to
use
otlp
gig
our
pc
exporter,
for
we're
not
able
to
build
otp
rpgs.
A
A
Yes,
so
my
concern
is:
I
need
to
go
in
production
with
with
traces
at
some
point
and
to
do
that
we
need
up
to
date
dependencies
in
general,
because
if
there
is
a
bug
in
one
dependency,
we
need
to
be
able
to
fix
it.
A
A
B
B
So
mark
right
now,
what's
what's
the
issue
we're
placing
in
this
pr?
I
went
back
to
this
pr
so.
A
A
So
this
one
I
tried
to
upgrade
grpc
alone
and
at
buildbreaks,
because
grpc
requires
a
newer
version
of
upsell,
so
I
upgraded
upsell
as
well
and
for
for
the
cmake
file.
It
seems
to
be
okay
and
for
bazel
it
crashes,
but
I
cannot
figure
why
I
have
no
experience
at
all
with
bazel
to
start
with.
So
I
don't
even
know
where
to
start
and
I'm.
A
A
A
B
A
B
B
A
A
B
B
A
B
B
B
B
For
the
issues,
I
think
probably
we
can
go
through
the
major
issues.
I
think
I
don't
want
to
go
through
all
of
them,
maybe
already
okay,
it's
still,
but
the
issue
is,
I
think
we
I
just
created
one
of
one
issue
like
otl
usb
exporter.
Cmake
will
should
not
depend
on
november
json.
As
of
now
it
does
install
low
one
lumen
json,
but
it
should
not
be
installed
if
it
is
for
grpc
exporter,
so
we
just
created
that
yes,
this
is
as
I'm
created
by
you.
B
I
think
thanks
for
this
add
ci
drops
without
the
nipple
here.
This
probably,
I
think
we
have
to
do
it.
My
tech
preview,
without
without
both
of
them
and.
B
B
B
A
For
for
logs,
I've
already
started,
and
I
will
have
that
soon
enough.
I
think
for
matrix,
I'm
waiting
for
all
the
merge
to
to
go
away.
B
B
B
Okay,
input
of
spanx
spam
processor
online
should
be
readable
span.
I
think
this
is
something
which
is
easy
to
implement.
I
think
as
to
what.
B
You
had,
as
suggested,
I
think
you
just
need
to
have
one
virtual
method,
which
is
defined
in
recordable
and
supposed
to
work
want
to
provide
support
of
this
override
this
method
in
any
of
the
exporters.
They
can
do
that
so
proper
from
sdk
side.
We
just
need
to
implement
one
virtual
method
in
the
recorded
one,
and
nothing
can
be
a
good
thing.
Then
we
have
good
to
be
specs
compliant,
so
I
think
probably
we
can
take
it
over
take
it.
B
B
Sorry,
sorry,
all
right,
yeah,
okay,.
B
This
I
haven't
seen
that
it's
a
crash
segmentation
fault
is
happening
when
using
nuke
provider,
but
haven't
seen
that-
and
I
probably
so
I
don't
see
it's
very
important-
I
mean
unless
and
that
somebody
want
to
look
into
that.
A
I
haven't
seen
it
either
somehow
I
suspect
that
it's
not
related
to
the
new
provider
or
the
type
of
provider
itself.
I.
A
B
B
B
And
okay,
this
is
somebody
wants
to
have
example
for
async
http
tracing
how
example,
I
think
it's
I've
added
again.
I
added
help
wanted.
I
didn't
really
think
that
it's
any
way
different,
how
we
do
traces
for
think,
http,
library
or
racing
the
shooting
library.
The
spam
creation
should
not
be
different
for
either
of
them,
but
I
think
somebody
is
suggesting
that
we
should
have
example
for
both
of
them.
B
A
Yes,
this
one,
so
if
we
don't
depend
on
on
json
at
all,
I
think
we
can
just
avoid
installing
it.
So
that
would
be
much.
B
B
B
B
B
B
B
Module
and
the
scenario
which
is
that
the
source,
if
the
source
will
leave,
then
we
won't
have
any
support.
We
do
not
have
any
git,
so
we
need
some
way
to
install
it.
So
when
we
do
a
source
release.
A
B
Yeah
but
but
this
will
be
required
for
the
for
say
zipkin
or
any
other
exporter
which
is
dependent
on
c2
and
json
right
now
or
even
otl
or
tlp
http.
B
A
B
B
B
B
A
A
So
this
is
already
there
a
couple
of
statics
which
are
causing
trouble
in
general.
I'm
wondering
a
lot.
There
is
a
lot
of
code
in
the
sdk,
which
is
pretty
much,
if
not
header,
only
at
least
in
a
lot
of
cases
in
hello
files,
and
do
we
want
to
do
that
or
do
we
want
to
move
the
code,
mostly
in
c
files.
B
Yeah,
I
think
it's
good
to
move
at
least
for
sdk,
it's
good
to
move
the
code,
which
is
only
in
header
better
to
move
it
in
c
files.
I
mean,
I
think
we
should
not
have
added
header
file,
should
not
only
have
the
class
definitions
and
the
declarations
which
will
not
have
any
definitions,
because.
B
A
A
A
B
B
B
A
Speaking
of
libraries,
I
noticed
that
there
are
some
pr
some
issues
to
move
some
external
code
like
etw
exporter,
and
you
know
an
axis
search
exporter
to
a
different
repository,
and
I
noticed
that
those
libraries
sometimes
include
recordable
in
their
own
libraries.
So
we
probably
need
to
sort
of
the
library
dependencies
before
moving
the
elastic
search
code
out,
for
example,.
B
B
B
Should
have
been
in
the
cc
file,
it
should
be
included
in
cc
file
if
it
is
included
in
that
their
header,
I
think
they
should.
That
should
be
fixed.
We
need
to
fix
it.
The
problem
is
here
is
probably
we
need
to
discuss
further
on
that.
B
B
Okay,
now
then,
this
this
needs
to
be
actually
not
listening.
You
should
be
in
ccp.
B
A
B
Yeah,
I
think
that's
all
this.
I
think
that's
so
old
once
anything
here,
I'm
64
building
ci
the
storm
is
created.
B
B
B
A
B
Okay,
now
this
is
this
is
not
specific
to
the
protocol
or
the
wired
protocol.
This
is
basically
from
the
at
the
api
level.
This
is
basically
at
the
ap
level.
B
B
Okay,
I
think
if,
at
the
exporter
side,
probably
it's
this.
B
B
B
Double
star
I
mean:
how
should
we
pass
that
as
a
span
attribute,
but
not
not
how
we
are
going
to
support
it
in
the
exporter?
Okay,
I
mean
it
should
it
could
be.
B
B
Okay,
this
we
have
been
discussing
and
probably
we
don't
really
support
undefined
behavior
sentinel
rules
and.
B
I
think
we
have
been
already
discussing
these
issues
most
of
them.
We
not
somebody
if
you
want
to
pick
it
up
to
support.
I
think
you're
good,
it's
good
for
that.
B
B
B
This
one
thanks
mark
for
taking
it,
and
we
should.
B
B
A
B
Will
not
here
because
you
are
not
part
of
the
open
telly
might
be
coming
tonight.
I
don't
know
you're,
not
part
of
that.
A
I
have
a
quick
question:
this
is
the
open,
telemetry
cpp
repository.
There
is
also
the
ext
open,
telemetry
cpp,
or
something
like
that
for.
A
B
B
A
A
A
B
There's
no
separate
meeting
the
the
reason
why
we
don't
have
separate
meeting
is
that,
since
this
this
is
not.
A
B
Actively
updated,
okay
and
most.
A
B
B
They
normally
join
this
meeting
and
then
when
they
want
to
discuss
anything
and
that
that's
how
that's
how
it's
being
run
as
of
now,
there's
no
separate
meeting,
there's
not
separate
slack
tenant
for
this,
and
we
use
the
same
slash
panel
and
the
same
meetings
in
white
for
both
of
them
and
yeah,
so
that
that's
how
it
says
up
now.
So,
even
so,
we
have
to
move
some
component
from
main
repo
to
the
content
before
I
think
we
have
to
discuss
it
in
this
meeting
only
and
then
we
should
be
able
to
do
it.
B
So
only
change
is
coming
in
the
coordinate
file,
so
for
each
of
the
components
we
add
some
specific
people
who
really
own
those
components,
and
apart
from
that
most
of
the
approvals
are
part
of
the
main
report
are
also
part
of
this
group,
so
so
no
issues,
information
most
of
the
discussions
are
happening
in
the
same
meeting.
Okay,
okay,
I
think
that
past
the
time
oh
okay.