►
From YouTube: 2022-03-15 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
B
Okay,
can
I
present.
B
Okay,
so
hello,
everybody,
you
may
not
know
me,
I
am
a
product
manager
at
elastic
on.
I
contribute
to
open
symmetry
in
some
kind
of
peripheral
things,
which
is
open
symmetry
for
ci
cd.
I
do
a
lot
of
things
for
jenkins
maven
on
I
come
here
today,
because
I
am
the
pm
lead
at
elastic
on
open
telemetry
on.
B
We
have
made
a
proposal
we
have
discussed
a
while
ago,
with
alolita,
with
a
christian
big,
big
gen
from
sumo
jonah
from
logsy
on
others
of
the
idea
to
add
the
elastic
command
schema
to
open
telemetry
to
enrich
on
the
idea
is
to
enrich
the
existing
open,
telemetry
semantic
conventions
with
all
the
namings
and
nomenclatures
that
the
elastic
common
schema
has
been
building
for
many
years
now
on.
So
we
have
created
an
otep
about
it
and
we
are
calling
for
feedback.
B
So
we
have
identified
the
benefits.
We
see
a
very
exciting
opportunity
to
accelerate
the
adoption
of
open
symmetry
logs
by
vendor
products
on
open
source
products.
You
can
imagine
it
apache
httpd
access
logs
the
engine
access
logs,
haproxy
access
logs.
You
can
imagine
all
the
network
components
that
produce
logs.
B
B
B
B
A
C
Can
you
talk
a
bit
about
the
mechanism
by
which
these
would
be
utilized
in
open
telemetry?
Would
that
be
by
providing
a
a
semantic
convention
schema
that
pointed
to
the
elastic
common
schema
instead
of
the
hotel,
schemas
or.
B
No,
it
would.
The
idea
we
had
is
to
completely
merge
on
the
idea.
The
decision
from
elastic
is
that,
if
elastic
common
schema
is
adopted
by
open
symmetry
to
enrich
the
existing
urban
telemetry
semantic
conventions,
then
elastic
common
schema
would
in
some
ways
disappear
as
elastic
common
schema
of
v1
would
disappear
on
elastic
as
a
company
would
embrace
open,
telemetry
semantic
conventions.
C
Sure
yeah,
that's
that's
understandable
if
there
are
conflicts
between
what's
in
the
semantic
conventions
today
and
what's
in
elastic
common
schema
today,
how
do
you
plan
to
handle
those.
B
Our
proposal
is
that
it's
likely
to
make
sense
that
the
existing,
open,
telemetry
semantic
convention
would
be
the
one
that
would
be
kept
as
a
kind
of
rule
of
thumb.
Then
we
would
evaluate
namespace
groups
of
conventions
by
group
of
conventions
to
see,
if
maybe
there
is
a
glitch
in
the
existing
something
uncomfortable
in
the
existing
open,
dymetry
semantic
conventions,
but
otherwise
elastic
as
a
company
is
ready
to
accept
that
something
which
will
change
some
examples
where
fleece
tv
here
are
pretty
simple
like
trace
id.
B
B
On
logs,
which
is
a
body
attribute
in
hotel,
which
is
of
a
type
any
when
in
elastic
the
equivalent,
is
a
message
which
is
a
string.
It's
text.
C
B
B
We
would
work
with
the
and
as
elastic
we
would
work
with
the
open,
dmt
community,
but
all
this
thought
process
has
gone
with
people
from
sumo
from
roxy
from
aws
from
so
on.
So
this
is
what
we
we
had
in
mind.
Does
it
make
sense.
A
A
Much
and
feel
free
to
reach
out.
Definitely
you
mean
now
I'm
trying
to
share
my
screen
now.
There's
a
pair
of
items
I
wanted
to
talk
about,
so
one
of
them
is
that
this
is
a
pr,
the
first
one
to
have
new
environment
variables
for
private
key
and
certificate
for
rtlp.
A
For
at
this
moment
we
only
have
one
now.
The
idea
is
that
we
could
have
more
you
know
defines
basically
this
is
a
it's
an
addition
and
an
addition.
Essentially
it
looks
super
straightforward,
logical.
The
only
thing
is
that
we
don't
have
enough
reviews.
So
please
take
a
look
at
that.
I
think
it
totally
makes
sense
to
have
this
one.
A
As
I
said
before,
we
need
more
reviews
so
far,
only
anurag
and
me
have
reviewed
that
and,
as
you
can
see
there,
he
has
been
waiting
for
feedback.
So
please
please
comment
on
that.
A
The
second
one
is
in
a
similar
state
that
it's
stock.
Actually
I
don't
know
whether
that
young
is
here
today,
but
essentially
the
idea
is
that
whether
http
codes
in
the
400
range
should
be
left
or
set
or
not.
At
this
moment,
the
server
wants
are
markers,
not
errors,
like
usual
stuff,
but
from
the
client
side.
A
They
are
considered
errors
and,
of
course,
there's
some
discussion
here
and
all
that
there's
a
link
here
summarizing
one
of
the
cases
is
that
you
can
get,
for
example,
this
code
four
to
nine,
which
basically
appears
when
you
hit
a
rate
limit.
So
technically,
it's
not
quite
an
error
in
some
to
some
degree.
The
second
one
is
when
you're
trying,
for
example,
call
a
few
potential.
A
You
know
end
points
and
then,
of
course
like
how
do
you
know
whether
this
is
something
you
were
trying.
A
Like
because
I
think
that's
quite
this
code
is
how
to
instrument,
so
maybe
it's
so
you
know
like
maybe
it's
not
an
actual
error,
but
if
the
user
is
the
one
that
explicitly
is
trying
to
perform
a
request,
then
most
likely
it's
not
an
actual
error.
A
A
The
author
or
the
pr
of
course
ask
like
what
should
we
do?
Do
we
keep
discussing
that?
Yes,
no,
but
basically
reaching
actual
decision
from
here.
That's
the
thing,
so
I
wanted
to
hit
the
outdoor
couldn't
be
here
today.
So
I
would
like
to
discuss
that
here,
even
if,
for
a
pair
of
minutes.
C
E
Yeah,
I'm
a
little
confused
on
this
one
as
well.
I
mean
when
I
was
taking
the
w3c
or
rfc.
Was
it
26,
something
like
that
defines
400
status
codes
as
client
errors,
like
that
seems
pretty
clear-cut,
that
those
are
client
errors?
E
And
I
I
want
to
kind
of
maybe
just
back
it
up
and
ask
the
question
like
if
this
is
getting
motivated,
because
users
are
getting
spammed
with
errors
like?
Is
that
a
problem
from
the
visualization
of
these
errors
or
the
processing
or
the
display
of
these
errors?
So
you
know,
like
that's,
I
think,
maybe
the
real
root
question
here.
A
F
Yeah
as
a
person
who's
been
involved
in
both
metrics
and
traced
for
a
while,
like
the
the
metrics
group,
has
proposed
a
quite
difficult
proposal
for
this
type
of
problem,
which
is,
we
have
a
way
to
configure
exactly
which
metrics
will
and
will
not
record,
and
we've
worked
out
a
configuration
for
that
that
gets
supplied
when
the
sdk
set
sets
itself
up
in
sampling,
people
kind
of
want
the
same
thing,
and
it
looks
very
similar
to
me.
F
That's
what
people
really
want
to
do
here
and-
and
we
have
not
gone
as
far
as
a
group
to
say,
there's
something
called
a
span
view
you
configure
it
by
giving
a
list
of
view
items
each
view
can
list
a
span
name
the
instrumentation
library,
maybe
some
attributes
and
then
some
criteria
for
whether
it
will
or
not
record,
perhaps
by
setting
sampling
probability
or
rate
limit,
or
something
like
that.
C
I
don't
know
if
that
would
solve
this
problem,
though,
because
the
server
side
of
the
span
would
then
be
left
dangling
without
a
parent.
If
you
don't
record
the
client
span,
I
think
that
span
is
going
to
get
recorded
one
way
or
the
other.
The
question
is:
does
it
have
the
error
flag
on
it?
Does
it
have
status
error
or
does
it
have
status
on
set
when
it
comes
out
of
the
instrumentation,
and
I
think
that
really
means
that
it
should
be
a
back
end
view.
You
know,
how
do
I
present
this?
C
Do
I
present
this?
As
you
know,
all
alarms
and
sirens,
and
oh
my
god,
something's
gone
wrong,
or
do
I
present
it
as
this
client
had
an
error,
but
the
span
above
it
doesn't
seem
to
have
had
an
error.
So
everything
is
maybe
okay.
C
We
should
be
calling
it
an
error
somewhere
and
if
the
user
chooses
to
do
something
to
suppress
or
ignore
that
error,
we
should
enable
that.
But
I
don't
know
that
that
should
happen
in
the
client
instrumentation.
F
Yeah,
I
I
the
minor
detail
I
left
out
is
that
the
400
status
comes
after
it
stands
finished,
so
you've
made
your
sampling
decision
at
that
point,
but
I
think
people
are
probably
likely
to
also
ask
for
a
configuration
that
determines
which
span
is
right,
but
I
see
your
point.
This
could
be
done
as
a
visualization
question.
G
Yeah,
it's
just
a
question
of
whether
it's
noise
by
default.
This
may
be
another
way
to
think
about
it.
A
lot
of
people
having
these
marked
as
errors
is
actually
noise
in
their
system,
and
then
they
have
to
go
around
disabling
it,
and
so
it's
kind
of
a
question
is
like.
Is
that
actually
the
default
and
you're
interested
in
400
is
errors
infrequently
enough
that
you
would
want
to
enable
it
when
you're
interested
in
it
versus
disabling
it
when
you're
not
interested
in
it?.
E
Yeah,
I
think
ted,
but
that's
like
kind
of
like
the
the
point
of
why
you
pay
a
vendor
right
like
or
or
it's
why
you
set
up
your
own
system
to
like
filter
this
stuff
out
cause.
I
think
that,
like
what
you
say
like
somebody's
noise,
is
somebody
else's
gold
right
like
right.
Finding
finding
these,
like
rate
limiting
things,
could
be
like
really
critical
to
somebody
and
they
could
be
completely
just
worthless
to
other
people.
G
Yeah
right,
I
guess
that's
why
I'm
just
saying
like:
what's
what's
the
the
the
default
situation
here?
If
is
it
by
having
these
marked
as
errors
by
default,
mean
that
it's
like
we're
just
creating
noise
and
work
in
general
for
users
of
open
telemetry,
and
they
should
be
using
like
the
collector
or
something
like
that
to
enable
this
selectively
in
their
pipeline,
or
is
it
common
enough
that
people
want
to
see
400s
marked
as
errors
that
that
they
wanted
on
by
default?
G
Does
that
make
sense
the
the
impression
I've
been
getting
from
a
lot
of
people
in
the
community?
Is
that
that
it's
it's
generally
noise?
But
it
seems
like
there's
like
a
split
opinion
here.
You
know
like
a
genuinely
expensive
opinion.
C
I
think
it's
an
important
error
signal.
400
errors
are
real
errors.
Something
has
gone
wrong
yeah,
even
in
the
case
of
like
a
404
where
you're
probing,
endpoints
and-
and
you
expect
that
occasionally
you're
going
to
get
404s
back.
That's
that's
still.
An
error
something's
still
gone
wrong
and
that's
maybe
the
one
case
where
I
can
see
turning
it
off,
but
by
default.
I
think
this
information
needs
to
be
there,
and
then
we
provide
some
mechanism
for
users
who
want
to
say
no.
H
D
C
E
Yeah
I
mean
I,
I
see
your
point
there's,
but
I
think
that's
just
the
question
of
layers
of
the
the
network.
What
do
you
consider
an
error
right
like
if
an
application
error
is
an
error?
Then
that's
an
error,
and
if
it
isn't,
then
you
know
maybe
you're
like
a
layer
two
guy
like
who
cares,
but
I
think
that
this
is
maybe
also
kind
of
just
getting
around
to
that
point
where
we
originally
had
this
problem.
E
We
just
started
to
like
include
this
concept
of
an
error
on
a
span
right
like
I
really
don't
want
to
unhash
that
conversation,
because
it
was
pretty
brutal,
but,
like
you
know,
I
think
this
is
maybe
getting
back
to
like.
Maybe
even
like
kind
of
what
josh
was
talking
about
a
simplified
version
of
like
you
know,
how
do
you
define
a
user
error
like
what
is
a
relevant
error
to
a
user
and
that's
going
to
be
different
in
many
different
contexts?.
E
That
what
we
currently
provide
provides
a
richness
to
express
that
or
configure
that
and
so
yeah
I
mean,
I
think,
ted's
just
doing
what
he's
you
know
come
to
this
conclusion
as
well
like
okay.
Well,
then,
how
do
we
like
hit
the
the
broadest
part
of
the
community?
I
I
don't
know.
I
do
want
to
say,
though,
that,
like
the
the
community
that
is
considering
these
are
errors,
and
it's
working
correctly
are
probably
not
vocalizing.
This
currently
right
now,
yeah.
E
G
Yeah
really,
really,
I
think
sometimes
we
can
try
to
get
like-
maybe
philosophical
about
these
things
like
what
is
technically
an
error
or
not,
and
but
to
me
the
the
question
comes
down
to
like
we.
We
want
to
provide
users
with
reasonable
defaults
right
like
when
they
install
open,
telemetry
and
turn
it
on
by
default.
The
instrumentation
they're
getting
out
of
the
box
is
admitting
production,
ready
information
and
they
don't,
generally
speaking,
have
to
go
in
like
they're.
G
Gonna
have
to
go
in
and
customize
things,
either
in
their
back
end
or
through
the
collectors
to
suit
their
needs,
because
their
needs
are
going
to
be
particular,
but
we
want
to
avoid
situations
where
open
telemetry
is
doing
something
by
default
that
you
just
like,
like
just
wouldn't
be
a
good
default
experience,
and
so
that's
that's
sort
of
the
the
way
I
think
about
these
400
errors
is
like
just
what
is
not
like.
Is
it
technically
an
error
or
not?
But
just
you
know
to
some
people
it
will
be
to
some
people.
G
It
won't
be
what's
just
the
the
best
default
experience
for
for
people
to
get
going,
but
I
I
will
say
since
it's
been
it's
been,
it
does
seem
like
it's
like
genuinely
split
right,
that
we
don't
seem
to
have
consensus
that
these
things
are
are
mostly
noise,
then,
actually,
I
would
say
my
suggestion
is
that
we
just
leave
them
as
as
errors
on
the
client.
G
For
the
time
being,
like
we
shouldn't,
we
shouldn't
go
it's
a
breaking
change
to
change
this
behavior
and
since
it's
not
extremely
clear
that
it
would
be
better.
If
we
did,
then
we
should
not.
I
I
I
I
think
the
major
thinking
is
if
we
treat
this
as
success
by
default,
a
lot
of
teams
which
don't
want
to
treat
it
as
a
success
might
be
surprised.
So
we
decided
to
be
a
little
bit
more
noisy.
We
tell
people
hey,
you
got
http
400.,
and
you
might
want
to
surprise
that
if
you
like,
if
that
makes
sense
for
you,
but
for
for
normal
people
like
you,
should
expect
everything
to
be
cracked
like
http,
200
or
like
300..
I
So
that
seems
to
be
a
reasonable
balance
like
I
I
I
guess
if
we
treat
http
400
at
success
by
default
and
allow
people
to
turn
that
to
failure,
a
lot
of
people
would
be
surprised.
A
G
I
would
suggest
we
we
say
that's
what
the
collector
is
for
generally
speaking,
and
we
could
have
a
broader
conversation
about
this,
but
if
we're
gonna
provide
options
for
instrumentation,
just
a
big
takeaway
I
took
from
open
tracing
and
the
instrumentation
there
is
that
it's
actually
really
painful
to
have
this
stuff
be
configured
by
configuring,
the
instrumentation,
unless
we
come
up
with
some
kind
of
shared
configuration
file
or
something,
if
you
just
say
each
piece
of
instrumentation
you
install
has
like
some
it's
like
own
way
to
like
configure
it
in
code.
G
F
F
Things
coming
together:
it's
like
the
ability
to
configure
a
view.
Yes,
someone's
going
to
someone's
going
to
be
able
to
do
a
collector
and
someone
else
is
going
to
come
in
and
say
gosh
darn.
I
just
want
to
modify
that
span
status
to
make
it
not
be
an
error.
It
seems
like
if
you
had
that
remote
configurability
you'd
incrementally
be
heading
towards
the
same
direction.
Somebody
someday
is
going
to
say
my
view
of
my
400
spans
is
to
suppress
the
error
bit
because
that's
how
I
want
it.
F
That's
the
right
level
of
noise
for
me
and
it's
gonna
be
way
more
work.
If
we
have
every
sdk,
do
that
probably
easier
to
start
with
the
collector's
side,
but
one.
G
I
I
do
think
it
would
be
helpful
to
have
this
stuff
be
configurable
at
the
source.
I
just
don't
think
it.
I
think
if
we
put
in
just
start
sprinkling
it
around,
as
like
un
un
unspecified
unsensually
specified
configurations
for
like
if
each
little
instrumentation
library
starts
sprinkling
on
configuration
options,
that's
that's
actually
the
road
to
hell
and
for
the
time
being,
we
should
just
stick
to.
G
If
you
want
to
configure
this
stuff,
just
stick
a
collector
in
your
pipeline
and
you
can
do
it
there
and
then,
like
you,
said
we're
going
to
add
remote
configuration
to
the
collectors.
So
it's
a
nice
place
for
you
to
remotely
configure
it
and
in
in
the
long
run
I
think
would
be
great
to
to
add
configuration
at
the
client
level,
but
we
don't
even
have
like
a
yaml
file
configuration
for
the
sdks
yeah.
I
guess
that's
what
I'm
saying
like
it
doesn't
yeah.
We
just.
G
There
yet,
even
though
it
would
be
very
helpful
to
have
all
of
that.
A
Yeah,
that
makes
sense.
I
will
put
this
yeah
all
these
notes
in
the
actual
pr
saying
that
yeah,
we
will
keep
things
the
way
they
are
now
and
let's
continue
discussing
on
how
to
do
that
happen
in
the
collector.
If
that
works,
then.
A
I
I
We
already
received
a
lot
of
approvals,
so
we're
going
to
merge
this
pr
after
this
meeting
another
small
one.
We
need
more
reviews,
so
this
one
basically
changes
the
wording
of
the
exemplar
part
for
people
who
don't
have
the
full
contacts
here.
So
exemplar
is
part
of
the
matrix,
ick
spike
and-
and
ideally
we
would
want
like
the
eventual
goal
is
to
see
if
we
can
enable
example
by
default.
If
you
have
the
tracing
enabled,
then
you
will
have
example
connecting
the
tracing
part
and
matrix
part,
but
so
far,
based
on
the
language
prototypes.
I
I
So
it's
a
very
small
change.
Please
take
a
look,
and
after
this
2prs
got
merged,
I
think
we
can
finally
go
back
to
the
the
the
memphia
that
marked
the
sdk
back
to
mix.
So
please
see
if
we
can
get
your
approval
after
both
these
issues
got
resolved
and
then
the
next
one
is
a
non-blocking
pr
from
island.
I
I
Currently
we
don't
have
that
wording
so
even
for
counter
or
something
they
will,
they
will
follow
the
the
overall
like
exporting
period,
which
is
a
very
long
time
like
60
seconds,
so
the
pr.
If
the
proposal
for
console
it
might
be
more
interactive,
so
reduce
the
time.
J
I
We
haven't
judged
this
yet,
but
this
seems
to
be
a
small
change
and
very
nice
to
have
so.
Hopefully
we
can.
We
can
get
this
merged
before
we
move
the
sdk
back
to
stable,
but
it
seems
like
we're
finally
getting
very
close
to
the
release.
So
thanks
everyone
and
for
the
remaining
prs
we
need
your
help
to
review
and
by
the
way,
if
you
still
see
any
blocking
issue,
please
call
out
and
join
the
friday
triage
meeting.
F
First,
I'd
like
to
respond
to
the
one
alan
just
described,
and
then
I
have
some
connected
remarks,
but
my
my
sort
of
starter
question
about
the
in-memory
exporter
is
whether,
if
you
give
it
an
infinite
interval,
isn't
it
then
a
pull
exporter
and
I've
always
thought
of
it
as
a
pull
exporter?
Actually,
I
wonder
why
we
have
this
disagreement.
F
Do
you
have
any
thoughts?
Why
wouldn't
you
see
this
as
a
pull
exporter.
J
F
Let
me
then
continue
my
line
of
questions,
because
I
think
it
might
reveal
a
little
more
so,
as
you
know,
the
issue
that
riley
covered
just
a
second
ago,
2404
is
my
pro
that
tries
to
clarify
temporality
controls
and
we've
gotten
enough
approvals
at
this
point
on
that
that,
I
think
we're
good
on
temporality,
but
the
review
thread
there
left
some
ambiguity
in
my
mind
that
I
want
to
share
and
see.
F
If
you
all
see
it
the
same
way
or
not
in
the
so,
there
are
two
open
comments
that
riley
left
on
that
pr
and
I
wanna
I
wanna
address
them
both,
but
before
we
that
one,
there
was
an
even
bigger
issue
that
I
I
backed
out
at
the
last
second,
because
I
was
trying
to
like
clarify
all
the
things
that
felt
ambiguous
to
me.
But
at
some
point
the
scope
became
too
large
and
we're
just
it's
just
the
temporality
control
pr
right
now.
F
But
it
left
this
item
which
talked
about
what
happens
when
a
view
is
configured.
So
it's
not
an
empty
set
and
none
of
the
views
that
are
configured
match
an
instrument
and
there's
this
line
in
the
spec,
which
I
don't
want
to
take
over
the
screen.
But
if
you
want
quickly
yeah,
I
guess
I
could
share
okay
I'll.
Do
this
right?
F
Okay,
all
right!
Now,
looking
at
my
screen,
so
this
thread
this
line
that
I've
been
asking
about
at
the
very
end.
You
know,
you'd
think
it
was
easier
for
me
to
find
now
that
I'm
talking
in
front
of
you
all,
we
resolved
the
issue
the
so
while
I
try
to
find
it
in
front
of
you,
the
question
is
when
a
view
doesn't
match,
but
there
are
views
what
should
happen
and.
F
Going
to
click
on
it
again,
I
feel
like
github,
okay,
there
we
go
all
right
now,
you're,
looking
at
my
screen.
Thank
you.
Thank
you,
jack.
Okay,
so
this
highlighted
text
is
the
one
I'm
I'm
referring
to,
and
I
remember
the
discussion
that
we
had
back
in.
I
don't
know
september
october
about
this
and
I
remember
it
coming
differently
in
my
head.
F
So
the
way
I
read
this
here
is
a
little
unclear
what
I'm
supposed
to
do,
and
it
sounds
as
if
every
sdk
can
just
decide
it's
on
its
own,
and
I
don't
think
that
that
was
the
intention
behind
this
discussion
that
we
had.
F
When
someone
configures
a
view,
it's
either
or
it's
one
of
those
two
and
right
now
we
have
this
this
paragraph
here
that
sort
of
doesn't
say
exactly
what
should
be
done.
F
It
makes
it
sound
like
every
language
gets
to
make
up
its
own
mind,
and
I
remember
there
being
this
discussion,
but
the
way
I've
seen
it
in
my
head
was
that
well
there's
this
there's
this
background
uncertainty
about
what's
a
reader
and
what's
an
exporter
and
I'm
gonna
try
to
explore
that
a
little
bit
right
now,
but
it
sounds
to
me
like
when
you
are
confronted
with
a
view
that
there's
no
match
you
will
either
have
to
configure
a
match
all
view
for
yourself
in
order
to
make
them
be
default,
enabled
or
you'll
have
to
config
you're
a
match
all
view
for
yourself
to
make
them
be
disabled,
or
we
will
have
to
just
explicitly
specify
that
when
you
register
views
they're
either
there's
either
default
exclusivity
or
default
inclusivity.
F
Now,
as
I
said,
there's
background
uncertainty
about
what's
a
metric
reader
and
what's
a
metric
exporter
from
the
from
the
library
guidelines,
open
telemetry
started
with
an
exporter
is
supposed
to
be
just
this
thing
that
knows
about
protocol.
It
can
take
some
data,
turn
it
into
the
wire
and
then
there's
this
notion
of
a
processor
that
we're
kind
of
emulating
from
the
tracing
sdk,
which
has
become
a
reader,
and
why
is
it
called
a
reader,
not
a
processor,
and
and
is
it
an
interface?
F
And
I'm
trying
to
I'm
trying
to
explain
a
number
of
vague
questions
right
now
and
I
feel
that
I'm
not
doing
very
well
but
in
in
this
review
thread
riley
points
out
that
I've
perhaps
overstated
something
that
says
that
readers
will
be
constructed
with
some
parameters.
I'm
trying
to
specify
exactly
what
the
reader
interface
is
when
you
construct
these
things,
because
it
is
trying
we're
trying
to
make
those
these
sdks
have
some
standard
appearance.
So,
when
you're
constructing
your
reader,
what
are
the
parameters
and
this
pr
of
mine
settles
that
a
bit?
F
So
it
says
that
you'll
give
your
default.
Temporality
settings
and
you'll
give
your
default
aggregator
settings,
so
those
are
the
reader
parameters
that
we've
agreed
to
in
this
pr.
The
question
is:
is
there
still
this
question
mark,
which
is
our
default
views
or
by
default
reviews?
Are
your
instruments
enabled
or
are
they
disabled?
When
you
have
views
that
don't
match
and
if
that's
a
question
I
believe
that
should
be
a
reader
parameter
explicitly
specified
now.
If
that
is
the
case,
and
you
list
you
look
at
my
list
of
things
that
the
reader
must
have.
F
F
So
that's
four
settings
that
you
give
to
a
reader
and
now
I
want
to
turn
this
into
a
group
discussion,
because
the
way
I
understand
readers
has
changed,
and
I
and
I
wrote
that
in
my
pr
and
I
can
back
out
the
change
that
I
made,
but
I
still
think
there's
a
difference
here
between
processors
and
readers.
The
reader
is
not
a
pure
interface
in
the
sense
that
I
can't
invent
my
own
and
just
plug
it
in
and
expect
it
to
work,
because
the
reader
has
some
shared
intimacy
with
the
sdk.
F
So
the
test
question
that
riley
asked
me
is:
is
it
okay?
If
your
if
your
prometheus
exporter
is
modeled
as
an
a
reader?
And
I
I
feel
like
there's
a
something
broken
in
this
in
this
dialogue
now
and
I
don't
know
where
to
fix
it,
but
I
feel
that
we
should
keep
readers
and
exporters
separate
and
have
their
responsibilities
be
very
clear
and
I'm
what
I'm
try,
the
the
the
confusion
that
we
were
working
through
in
this
pr
is
that
sometimes
you
will
set
up
your
reader
very
explicitly.
F
F
You
know
your
temporality,
you
know
your
aggregators,
you
know
you're
the
exporter,
so
what
reader
parameter
is
there
left
and
if
there
are
none,
then
it's
okay
to
model
your
metric
reader
as
an
exporter
and
make
them
the
same,
but
there's
still
that
one
parameter
left
which
is,
is
the
default
on
or
is
the
default
off?
So
I
don't
feel
that
we
need
to
block
the
spec
on
this.
I
actually
having
informally
surveyed
people.
We
all
seem
to
approximately
agree.
F
If
anyone
remembers
this
debate
from
september
or
october,
I
believe
that
that
what
people
really
wanted
was
the
following.
There
is
a
difference
between.
I
am
setting
up
my
sdk,
and
I
know
exactly
what
I'm
doing
versus
the
sdk
is
auto
configuring,
an
exporter
because
there's
an
environment
variable
set,
and
they
just
want
something
to
happen
because
they're,
not
configuring
it
by
themselves.
So
the
the
setting
up
and
auto
configuring
an
exporter
is
really
different
than
configuring.
F
An
exporter
by
yourself
and
all
we
have
to
do
as
a
spec
is
to
say
when
you're,
auto
configuring,
an
exporter
what
happens
and
then
for
the
reader
interface,
because
people
will
want
to
configure
their
own
very
explicitly.
You
get
all
the
parameters
available
to
you,
which
means
you
can
set
the
exporter,
the
temporality,
the
aggregator
and
the
default
enabled
property,
and
that
leaves
the
potential
that
you
might
be
able
to
configure
something
that
just
doesn't
work.
F
You
can
now
configure
a
reader
that
will
output
data
that
some
exporter
might
not
be
able
to
to
use,
and
I
don't
see
a
real
problem
here-
prometheus
exporter
you're
not
going
to
configure
a
reader.
Very,
it's
not
going
to
be
easy
to
accidentally
configure
a
prometheus
exporter
with
a
reader.
That's
not
correct,
because
probably
you're
going
to
auto
configure
that
and
auto
configuration
should
always
be
the
right
thing,
but
still
there
should
be
some
clarity
around
what
the
reader
interface
is.
F
I
And
just
sharing
one
thing
I
remember
in
the
open,
telemetry
downloads.
Originally
I
put
the
metric
reader
as
something
that
vendors
can
extend
and
provide
their
own
reader
and
later
I
changed
that
following
the
spec
so
make
reader
something
more
internal,
and
I
remember
a
developer
from
dynatris
commented
that
they
they
need
that
feature.
So
we
we
sort
it
out
by
telling
telling
that
developer.
F
I
have
a
guess
if
you
like,
based
on
prototyping
myself
and
it's
that
there
is
some
interface
here,
that
we
have
not
necessarily
exported
in
the
spec,
meaning,
meaning
we
have
not
clarified
or
specified.
That
is
like
or
akin
to
the
span
processor
in
the
trace.
Sdk
that
transforms
data
on
its
way
between
the
sdk
and
the
reader.
Essentially,.
F
This
could
be
a
place
where
you
redact
metric
labels.
This
could
be
a
place
where
you
well
in
tracing.
It
could
be
a
place
where
you
switch.
The
return
status
turn
off
the
error
bit
or
whatever,
like
these
are
places
that
you
can
process
metrics.
We
haven't
identified
that
and
it
sounds
to
me
like
someone
who
was
asking
for,
for
that,
saw
an
opportunity
to
extend
the
reader
instead
of
extending
the
reader.
H
I
know
you
asked
for
a
dynatrace
developer
to
respond.
I
think
the
developer
that
you're
referring
to
is
not
one
of
the
three
we
have
here
in
this
meeting.
Unfortunately-
and
I
am
not
sure
what
you're
referring
to.
I
I
F
Well,
actually,
I
I
feel
like
we're,
not
quite
done
with
this
conversation,
I
there's
some
comment.
That's
been
left
dangling
about
readers
being
factories
and
and
they're
in
your
my
my
own
pr
rally.
You
asked
if
I
should,
or
should
not
change
the
language
to
say
that
a
reader
is
an
interface,
and
I
try
I
did.
I
said
it's
not
an
interface
anymore.
F
I
feel
that
we
have
are
still
unclear
about
what
a
reader
is,
because
I
don't
because
when
the
reader
is
constructed
well
notionally,
when
this
thing
is
constructed,
the
sdk
doesn't
exist.
Yet
right,
you're
setting
up
an
sdk
you're
going
to
hand
it
something
which
is
going
to
be
the
reader
and
really
that's
not
the
way.
This
works,
because
the
reader
is
something
that
has
to
talk
to
the
sdk
and,
yes,
he
has
to
talk
to
the
reader.
F
So
the
sdk
somehow
has
to
be
involved
in
setting
up
this
reader
and
you
can
model
that
as
like
I'm
going
to
create
a
factory
and
then
the
sdk
is
going
to
call
the
factory
or
you
can
model
that
as
I'm
going
to
give
you
a
thing
and
you're
going
to
register
that
thing.
It's
this
act
of
registration
when
the
sdk
starts
and
says,
I'm
now
registering
the
meter
or
sorry
registering
the
reader
or
I'm
initializing
that
reader.
F
That's
the
point
where
the
reader
gets
to
know
who
the
sdk
is
and
the
sdk
gets
to
tell
the
reader.
It
exists
and
that's
the
there's
got
to
be
some
interface
there
and
we
haven't
specified
it
and
every
internal
sdk
is
going
to
do
something
different.
I
imagine,
but
that
I
believe,
is
the
place
where
you
would
insert
a
processor,
so
the
the
act
of
registering
a
reader
is
to
set
up
this
negotiation
between
the
sdk
and
the
reader
to
say.
I
exist
you're
going
to
pass
me
some
data.
F
You
can
also
flush
me
or
shut
me
down
it's
at
that
moment
where
the
s
the
reader
presents
itself
as
a
thing
that
can
receive
data
from
the
sdk
and
and
there's
some
sort
of
transaction
up.
That's
going
to
happen
when
the
data
gets
sent
from
the
sdk
to
the
reader
and
right
now,
there's
no
interface
specified
in
my
prototype.
It
had
a
start,
a
process,
a
finish
and
a
like.
That's
the
kind
of
interface
that
we're
talking
about
the
interface
between
the
sdk
and
the
reader.
K
Yeah
so
so
java
implements
the
the
factory
pattern
of
the
two
that
you
discussed
instead
of
you
know
registering
so
you
you
associate
a
metric
reader
factory
with
your
sdk
meter
provider
and
the
the
factory
method
has
a
method
called
apply
which
accepts
a
metric
producer.
That's
kind
of
the
missing
interface
that
you're
talking
about
the
metric
producer
is
how
the
the
reader
can
ultimately
pull
metrics
from
the
sdk
meter
provider.
F
So
maybe
then,
in
your
words,
the
this,
this
producer
interface,
if
we
were
to
specify
it,
would
be
yet
another
place
where
you
can
modify
data
between
the
sdk
and
the
exporter.
But
this
would
be
essentially
in
my
understanding.
F
Well,
I'm
not
clear
yet
on
whether
like
there's
some
ambiguity
there,
I
don't
want
to
specify
it
because
no
one's
asking
for
it,
but
I
I
do
think
that
this
notion
of
there
being
a
register
or
a
ply
and
a
producer
is
something
that
every
one
of
us
is
kind
of.
I
get
inventing,
because
there
was
some
question
that
we
didn't
understand
in
the
spec.
F
I
Yeah,
just
to
clarify,
like
we
talked
about
the
processor
and
later
we
decided
just
to
leave
it
out
of
scope
for
now,
and
I
I
I
think
josh
brought
this
up
was
thinking
like
once.
The
sdk
is
back
moved
to
stable.
What's
next,
and
this
seems
to
be
a
big
topic,
not
necessarily
saying
it's
blocking
anything.
I
F
It
I
just
want
to
make
sure
that
if,
if
there's
someone
feels
like
there's
something
missing
or
we
haven't
specified
an
interface
between
sdk
and
and
reader,
it's
like
there's
probably
a
shape
that
we
could
and
it's
like,
not
necessary
for
us
too.
But
I
also
think
now
that
we've
had
this
rich
conversation
around
the
problem.
F
There's
still
this
question
of
the
default
enabled
bit
that
I
that
I
removed
from
my
pr,
which
was
trying
to
interpret
and
make
more,
I
guess
more
rigorous,
the
specification
about
what
happens
when
a
view
is
configured
but
doesn't
match
any
instrument,
and
I
think
what
I
would
like
to
say
is:
there's
there's
some
sort
of
default
behavior
which
is
on
so,
if
you
give
us
instruments,
if
you
give
us
views
and
they
don't
match
an
instrument-
sorry
sorry,
the
default
is
off.
F
F
F
Then
we
don't
need
a
default
enabled
property
and
it
means
that
you
get
default
disabled
by
default
and
you're
going
to
have
to
write
a
view.
If
you
want
default,
enabled
and
other
views
and
that's
okay.
It
just
means
that
someone's
going
to
have
to
if
they
want
to
express
views
and
have
them
be
inclusive,
not
exclusive,
they
will
have
to
add
their
own
inclusivity
by
adding
another
view
to
match
everything,
and
that
seems
okay.
F
K
I'm
not
sure
I
have
the
same
read
as
you,
so
my
read
is
that
by
default,
if
you
register
views
and
none
match
that
that
an
instrument
that
matches
none
will
still
have
be
exported
and
have
a
default
view
and
there's
just
this
question
of
whether
the
sdk
it
says
the
sdk
should
also
provide
a
way
for
the
user
to
turn
off
this
default
behavior.
F
K
So
I
think
that
the
the
fact
that
a
reader
has
this
aggregation
function
where
you
know
it
takes
in
an
instrument
type
and
it
returns
a
particular
aggregation.
It
provides
that
mechanism
because
you
can
provide
a
reader.
You
know
an
aggregation
function
that
returns
drop
for
all
instrument
types
and
effectively
turns
off
the
default.
Behavior.
F
But
that
means
that
if
I,
if
I
want
to
set
views,
include
exclusive
views,
okay,
I'm
going
to
have
to
list
my
aggregation
because
I'm
going
to
set
drop
for
all
the
defaults
to
turn
off
by
default.
So
it
seems
like
there's
different
defaults
when
you
do
match,
when
you
don't
match,
is
what
I'm
trying
to
point
out.
So
when
you
do
match
you're
going
to
have
to
set
the
aggregation
if
you've
used
drop
to
disable
everything
by
default,
you're
going
to
have
to
set
every
aggregation
explicitly,
and
that
seems
like
a
headache.
J
F
But
it
also
seems
to
me
worse
to
have
this
to
this
optionality,
so
that
was
why
I
preferred
after
reasoning
through
this
yesterday,
if
we
remove
any
notion
of
this
being
configurable,
the
the
the
outcome
would
be,
preferably
you
just.
I
didn't
have
that.
I
had
the
text
somewhere,
so
this
one,
this
third
paragraph
here
if
the
instrument
could
not
match,
would
be
replaced
by
this.
It's
disabled
when
there
are
views
that
don't
match,
and
if
you
want
to
change
that
just
add
another
view
that
matches
everything
and
have
it
use
the
default
aggregations.
F
L
F
F
Moreover,
I
don't,
I
don't
know
that
we
need
to
resolve
this,
but
it
does
seem
like
it
leaves
open
an
opportunity
for
sdks
to
be
very
different
from
each
other
and
it
doesn't
seem
necessary.
F
My
my
feeling
well,
my
feeling
is
that
also
here
there's
a
question
of.
I
just
want
my
exporter
configured
automatically.
Just
please
do
the
right
thing
for
me
versus
I
am
a
developer
who's
being
very
clear
explicitly
about
what
I
want
to
view
and
like
those
two
different
users
are
different
use
cases
and
I
think
it's
okay
to
force
the
the
user
who
knows
exactly
what
they
want
to
be
a
little
bit
verbose,
whereas
we'd
like
the
default
behavior
to
be
right
for
the
user
to
just
ask
to
to
get
everything
automatically
enabled.
F
So
I
guess
there's
a
question
of
whether
we
ever
expect
automatically
enabled
sdks
that
also
have
views,
and
if
we
got
there
would
we
want
to
pass
that
along
to
the
user,
meaning
you're
going
to
write
a
yaml
file
that
says
default,
enabled
true
and
then
a
bunch
of
views
or
default
enable
false
and
then
a
bunch
of
views.
I'm
not
sure
what
we
really
want.
K
Here's
a
thought:
if
we
get
rid
of
this
line
that
says
the
sdk
should
also
provide
a
way
for
the
user
to
turn
off
the
default
behavior.
So
there
is
no
way
to
turn
off
the
default
behavior.
You
always
get
that
default.
Behavior,
then,
for
these
more
advanced
users
that
are
configuring
exactly
what
they
want.
It
is
more
verbose.
They
just
have
to
explicitly
opt
out
of
all
the
instruments
that
they
want
to
opt
out
of
by.
F
Adding
a
match
all
for
name
and
drop
as
the
aggregation
right
yeah.
I
think
I
agree
to
that.
Being
the
last
least
surprising
outcome
it
the
only
technical,
so
so
this
just
text
that
I'm
highlighting
here
would
then
change
not
to
what
I've
written,
but
the
instrument
could
not
match
any
directions
views
the
sdk
should
enable
the
instrument.
That's
that's
what
we
would
say
here
and
then
we
would
add
an
addendum.
If
you
really
want
exclusive
view
configuration
you
should
probably
add
the
last
view
configuration
is
match
all
and
drop
technicality.
F
F
I
don't
want
to
block
on
this,
but
I
I
I
I
think,
I'm
the
right
person
to
follow
this
with
a
pr,
but
I
will
make
it
allowed
for
ga.
Thank
you
all.
A
G
Yeah
totally,
we
don't
have
time
to
discuss
it
now.