►
From YouTube: 2022-07-12 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
Please
review
the
link.
Is
there
it's
about
being
able
to
indicate
that
the
request
was
partially
successfully
processed,
partially
failed
yeah?
We
have
some
rules.
I
just
did
another
review.
I
had
a
comment.
There
generally
looks
good
to
me,
but
there
is
some
nuances
that
I
think
is
worth
specifying
clearly
so
yeah
I
don't
know
if
anybody
has
anything
they
want
to
talk
about
right
now
on
this
one.
A
This
is
a
change
that
did
happen
a
few
weeks
ago,
where
we,
I
think
it
was
about
system
some
system
metric.
I
don't
remember
the
name
we
eliminated
the
direction
attribute,
so
I
want
to
make
sure
we're
able
to
describe
changes.
This
particular
change
and
other
changes
like
this
in
the
schema
files.
A
A
B
Yeah,
I'm
here
carlos,
wanted
to
look
last
time,
but
he's
not
here,
so
I'm
not
sure.
Basically,
we
last
time
we
discussed
that
we
need
an
agreement
from
java
folks
from
trusk
and
he
prototyped
this
change
and
he
approved
it.
So
if
somebody
has
a
capacity
and
can
take
a
look,
it
would
be
great
to
a
proof
and
merge
this
one
has
been
out
for
for
for
a
while,
otherwise
I'll
try
to
pink
carlos
and
see
you
and
he
can
give
back.
C
Joy,
you
have
the
next
item.
I
believe
sorry,
I
read
the
wrong
list.
May
I
take
the
next
one,
which
I
was
late
for
on
the
first
bullet.
Add
support
for
partial
success
in
otp
export
response
that
has
been
approved
in
the
protocol
repository
and
extensively
discussed.
Jawah
has
written
a
change
to
the
otlp
exporter
specification,
which
just
says
in
words
the
same
thing
and
we'd
like
you
to
look
at
that,
hopefully
approve
it.
It
has
been
discussed
again
in
the
protocol
repository
if
you
follow
the
links
there.
A
On
that
one
josh,
I
I
revoked
my
approval
because
there
is
a
small
nuance
that
I
think
is
worth
clarifying
with
regards
to
a
situation
when
there
is
a
zero
or
non
zero
unset
value.
I
wonder
what
you
think
about
it.
So
please
take
a
look.
If
you
have
a
chance
sure
my
last
comment
there.
C
A
A
Okay,
next
one
nev.
E
Yeah
this
is
the
the
clarification
around
attribute
support.
E
Still
these
reviews-
I've
almond,
gave
me
some
reviews,
so
I've
addressed,
I
think,
all
those
removed
some
stuff
and
reworked
some
stuff,
so
I
get
more
reviews
would
be
good.
Please.
A
A
D
Yeah
sorry,
it
was
me
yeah
I
just
want
to.
I
just
want
to
know
now
that
the
old
tap
is
is
merged.
What
are
the
next
steps?
Yeah.
A
Yeah
so
as
we
discussed
in
the
log
sig,
the
next
steps
is
to
start
adding
the
api
to
the
specification
repo
and
the
last
time
we
talked
in
the
log.
Six
santos
said
that
he
will
start
doing
it
as
soon
as
the
optip
is
merged.
Now
that
it's
merged,
we
should
expect
that
to
happen,
and
then
the
discussion
will
be
on
the
on
the
pr's
that
are
filed
against
the
specification
report.
A
I
expect
that
it
will
be
multiple
pr's.
It
will
take
quite
some
time
yeah
that
is
expected.
A
I
think
so
yeah,
that's
that's
the
expectation
right.
We
need
some
adjustments
there
as
well.
So,
but
probably
we
should
start
with
the
api.
I
don't
know
what
was
santosh
planning
to
do
exactly,
but
he
said
that
he's
he
will
prepare.
He
will
line
up
some
pr's
there.
So
supposedly
we
should
see
something
soon.
A
D
F
F
Clarify
configuring
aggregations
with
metric
readers,
so
this
one
was
when
we
triaged
it
looks
like
this
one
deserves
a
discussion.
Let
me
pop
it
in
here.
F
So
I
put
I
put
a
a
discussion
point.
The
comment
at
the
very
bottom
on
this
one
is
basically,
I
think
we
have
two
action
items
on
on
this
particular
bug.
One
is
we
need
to
clarify
the
order
of
configuration
for
aggregation
so
basically
like.
F
F
Then
the
exporter
default
aggregation
is
used
and
then
another
aggregation
is
used,
but
I
wanted
to
clarify
with
everyone
who
has
been
working
on
that
to
make
sure
that
is
the
intention
of
the
spec
before
we
go
update
to
like
be
explicit
here
and
then.
The
second
thing
is
there's
this
notion
of
whether
or
not
if
views
are
the
last
thing
that
overrides
do
they
need
access
to
understand
what
exporter
is
participating
in
an
aggregation.
F
So
there's
like
two
components
to
this
bug
that
I
think
weren't
some
discussion.
The
first
I
think,
is
rather
easy
for
us
to
kind
of
just
yes,
that's
what
we
intended
in
the
spec
and
kind
of
move
forward,
the
second
one
I'm
not
sure
of
so.
I
just
wanted
to
open
that
up.
As
a
question.
G
F
Oh
re,
sorry
I
I
when
I
say
reader
so
reader
delegates
to
exporter,
but
it's
the
same.
The
same
thing
when
I
say
that
so
like
the
the
metric
reader
defines
a
default
aggregation
operation
right
where
you
select
the
default.
G
I
mean
for
what
it's
worth
josh.
This
is
the
reading.
Your
interpretation
is
interpretation
I
had
but
yeah,
maybe
making
that
clear
is
also
probably
a
good
idea,
there's
also
a
little
unclear,
because
the
view
can
also
set
the
default.
So
there's
like
this
overlap,
I
think
that's
where
the
confusion
comes
from.
F
Yeah
yeah,
the
reason
I
suggest
number
two
is,
I
feel
like
that,
makes
it
explicitly
clear
that
view
is
last
because
if
you
has
access
to
exporter,
that
means
that
vue
would
override
exporter
right.
F
I
don't
know
if
that's
a
good
idea
at
all
honestly.
I
think
it
might
be
a
terrible
idea,
but
making
it
very
explicit
to
users
and
and
implementers
of
the
spec.
What
that
override
is,
I
think,
is
the
important
bit
here.
That
second
thing
I
just
wanted
to
tease
out
and
see
what
we
all
felt.
C
Josh,
I'm
having
trouble
understanding
the
question.
The
second
part
of
the
question,
the
first
part
I
agree,
the
the
view
would
override
the
default
and
the
default
might
be
per
exporter
and
then,
if
there's
no
default,
we
have
a
standard
right.
But
I
can't
the
language
here
about
one
one
aggregation
configured
biometric
reader
should
be
visible
to
other
metric
readers.
I
don't
understand.
F
Oh
so
that
the
concern
was
whether
or
not
like.
If,
if,
if
I
define
a
metric
reader
that
says,
histograms
should
have
explicit
buckets
of
10,
20
and
50,
and
I
have
another
metric
reader
that
says
explicit.
Bucket
histogram
should
have
10
20
and
100,
and
then
I
have
a
view
that
says
buckets
should
be.
You
know
only
10
and
20
right
as
their
as
their
limits,
which
one
wins
like
that
that
that's
the
fundamental
question
being
asked
here
of
like
do
those
two
exporters
get
to
see
each
other's
config?
F
F
I
think
it's
almost
implicit
that
you
need
to
have
separate
memory
per
reader,
given
the
way
it's
written,
and
I
think
it's
not
clear
to
implementers
when
they
go
read
that
that
that's
the
case
we
had
tried
at
one
point
in
time
to
like
have
a
single
bit
of
metric
memory
that
is
shared
and
reused
across
readers.
F
That
was
like
the
initial
design
of
the
java
sdk
and
we're
moving
away
from
that,
and
the
person
asking
this
question
I
know,
is
implementing
the
javascript
version
and
had
mimicked
that
java
implementation
that
tried
to
share
all
the
memory.
So
it's
like
when
you,
when
you
start
from
that
question
things
are
very
weirdly
worded
in
the
spec
and
I
think
we
need
to
be
explicit
right.
So
all
the.
C
Old,
all
the
old
hotels
and
sdks
did
it
that
way
by
the
way,
as
well
as
go,
and
I
I
consider
what
you're
talking
about
to
be
an
optimization
that
someone
could
make
and
when
you
look
at
how
much
trouble
they're
going
to
go
to
you
really
need
to
have
a
demand
for
more
than
one
reader
to
perform
very
well
before
you
go.
Do
that
I've
never
considered
this
to
be
an
important
optimization.
That's
why
I
haven't
done
it,
but
you
could
go.
C
F
Joined
that
camp
now,
I'm
I'm
fully
on
board
with
that.
Personally,
I
think
we
should
explicitly
kind
of
talk
through
that
in
the
spec
make
it
clear
to
people
who
read
the
spec,
that
that's
the
case,
but
secondarily
the
the
other
bit
the
second
bit
the
bit
that
I'm
talking
about
with
like
a
view
having
aspect
to
exporter.
This
is
the
notion
of
view
is
meant
to
be
your
last
line
of
defense
to
correct
issues
with
instrumentation
right.
F
It's
this
it's
it's
that
I
have
full
control
at
some
point:
the
influence
between
view
and
exporter.
I
don't
think
was
teased
out
in
the
exporter
design.
C
C
The
way
I
interpreted
our
our
spec
was,
if
you're
configuring
auto-configuring
an
exporter,
it
will
provide
something
otherwise
the
reader
configures
it
so
like.
When
it
comes
to
evaluating
what
aggregation
should
I
use?
There
are
only
the
things.
The
steps
that
you
described
in
the
first
step
consult
the
view
if
it
has
something
consult
the
exporter
provided
or
reader
configured
default,
there's
no
access
from
the
reader
to
the
exporter.
For
that
it's
just.
C
F
I
guess
I
mean
the
reader
should
view
have
access
to
the
reader.
Here's
if
I'm
configuring
views
as
a
user,
and
I
have
two
readers
should
I
be
able
to
say
this
metric
on
this
reader
is
this
type
of
histogram
this
metric
on
this
reader?
Is
this
other
type
of
histogram?
Should
I
be
able
to
do
that
yay
or
nay,.
C
F
C
This
is
why
I
found
an
issue
about
this
a
long
time
ago.
I
think
it
would
make
sense
to
let
each
reader
configure
their
own
views
and
there
is
an
open
issue
about
that,
and
that
would,
I
think,
solve
this
problem.
F
Okay,
so
let's
take
this
particular
issue
as
raised
and
and
defer
that
second
question
to
your
open
question
about:
should
each
reader
have
its
own
view
set
and
we'll
answer
it
on
that
and
then
the
specific
thing
about?
Let's
make
the
hierarchy
like
outline
somewhere,
I
don't
know
where
we
should
put
that
in
the
spec,
but
it
sounds
like
that's.
The
resolution
of
this
bug
is:
let's:
let's
make
it
explicit
this
overrides
this
overrides
this,
so
it's
clear
to
everybody,
yeah
sounds
good
to
me.
C
And
it
just
said
like
when
I
was
first
prototyping
the
views
in
the
reader
implementation.
It
seemed
like
each
reader
could
have
a
independently
specified
view,
and
that
would
solve
the
problem
that
we've
been
discussing,
and
it
would
almost
not
at
all
change
my
implementation,
because
I
already
have
to
evaluate
each
view
in
the
context
of
each
reader,
given
the
defaults
that
are
different.
Therefore,
my
my
my
implementation
is
practically
not
going
to
change
to
support
multiple
per
reader
views.
That's
the
bottom
line.