►
From YouTube: 2022-04-28 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
Hey
there
hey
how's
it
going
good.
How
are
you
doing
well
trying
to
see
if
I
can
figure
out
how
to
remove
that
extra
notes,
thing
that
we
have
in
the
agenda.
C
A
Okay,
all
right
looks
like
we're
one
minute.
Two
minutes
fast
make
sure
anyone
on
the
call
add
yourself
to
the
agenda
or
the
attendees
list,
and
if
you
have
anything
you
wanted
to
talk
about,
add
it
to
the
agenda.
It
doesn't
look
like
there's
too
much
added
currently,
but
we
can
jump
in
in
just
a
minute.
I
know
aaron's
not
going
to
be
able
to
make
it,
but
maybe
anthony
will
show
up
just
a
little
bit.
A
Okay,
yeah,
let's,
let's
jump
into
it
so
for
those
following
the
massive
stream
of
events
that
are
going
on
in
the
slack
channel
the
release,
1.7
and
v030
went
out
today.
This
has
fixes
for
some
some
packages,
as
well
as
the
added
back-end
in-memory
exporter
for
the
metric
test.
So
two
big
things
they've
already
been
updated
in
the
contrib
repo.
That
has
also
had
a
related
release
that
also
went
out.
A
A
These
are
in
a
stable
package,
so
you'll
probably
get
a
warning
if
you
don't
upgrade,
but
they're
not
going
away
until
a
v2
of
open
telemetry
comes
out.
So
just
a
a
word
of
relief.
If
you're
worried
about
getting
that
upgrade
down
but
yeah,
I
think
that
was
it
for
the
release
that
I
wanted
to
talk
about.
If
there's
any
questions
about
that.
A
Probably
not
I'm
looking
at
you
stephen
harris
for
an
upgrade,
but
yeah,
that's
pretty
recent,
so
yeah
I
haven't.
C
A
B
B
A
I
gotcha
we
have
an
issue
to
try
to
address
that,
but
I
have
not
had
the
time.
I
think
there's
still
confusion
if
we
want
to
do
a
deprecation
or
a
redaction.
A
A
Just
a
heads
up
we're
still.
I
think,
in
a
very
similar
place
that
we
were
last
week.
We
did
meet
monday
or
tuesday.
I
can't
quite
I
think
it
was
monday
and
we
talked
a
little
bit
about
sdk
design.
There's
some
notes
here.
There's
definitely
a
lot
of
the
discussion.
That's
happening
in
the
issues
themselves.
A
If
you
haven't
been
following
and
the
recording
for
that
meeting
should
go
up,
I
think
if
these
recordings
are
still
working
so
yeah
last,
I
heard
they're
still
working,
so
it
should
be
also
online
for
those
interested
in
the
discussion.
However,
that
being
said,
like
a
lot
of
the
discussion,
has
just
been
kept
in
these
issues
themselves,
so
yeah.
I
think
that
this
is
probably
a
good
overview.
A
10
is
what's
going
to
be
reported,
maybe
maybe
a
little
higher
next
monday
at
the
maintainers
meeting,
so
slow
progress,
but
does
you
know
not
being
reflected
for
the
amount
of
discussion?
That's
happening
here,
cool
with
that
there
is,
I
think
one
thing
I
wanted
to
ask.
I
think
josh,
because
aaron's,
not
here
anymore
and
anyone
else
on
the
call
there's
this
pr
here.
This
is
kind
of
the
entry
point
I'm
finding.
A
I
thought
there'd
be
a
little
bit
more
of
a
parallelism,
but
I
think
that
this
is
kind
of
just
the
basis
that
a
few
other
prs
could
be
built
from
so
interested
in
progressing
the
metric
sdk,
rework
the
revised
version.
Please
go
take
a
look
at
this.
This
is
kind
of
the
starting
point
as
we
discussed
last
week.
The
goal
is
to
try
to
build
up
the
interfaces
and
then,
from
those
we'll,
you
know,
be
building
out
the
implementation.
A
This
is
the
start
with
just
being
the
meter
provider
in
the
meter
structures,
there's
a
little
bit
of
a
discussion
that
can
be
seen.
That's
related
to
readers
in
here.
Definitely
another
good
issue
to
go.
Take
a
look
at
if
you
have
the
time
is
the
discussion
on
readers,
which
is
a
very
interesting
concept
that
is
new
to
the
meter
signal
that
is
not
in
the
metric
signal.
That
is
not
in
the
tracing
signal,
so
it'd
be
good
to
have
user
feedback
as
well.
A
I
don't
know
if
steve
you
have
some
cycles
on
this,
but
it'd
be
cool.
If
you
could
read
it
it's
kind
of
complex,
so
I
don't
know
if
it's
like
the
most
useful
of
your
time,
but
it
you
know,
I
think
that's
a
it's
an
interesting
discussion,
nonetheless,
because
it
will
be
a
little
bit
different
than
the
spam
processors
that
you
would
expect
from
the
tristate
signal.
A
Cool
yeah,
it's
a
good
one.
In
fact,
I
think
when
that
merges
we'll
be
well
on
our
way
to
views
and
then
instruments
so
yeah,
it's
it's
kind
of
a
milestone
in
my
opinion,
but
this
is,
I
guess,
the
starting
point
and
it's
pretty
straightforward.
Just
for
those
who
want
to
do
a
quick
review.
There's
I
mean
it
really
is
bare
bones
talking
about
configs
options.
A
These
are
all
expected
to
be
expanded
later
and
then
you
have
a
basic
meter
implementation
with
absolutely
no
implementation
underneath
it
and
a
meter
provider.
So
I
think
that
there's
some
good
discussion
here,
because
a
lot
of
this
is
really
reading
comments
and
validating
the
comments
are
expected.
A
lot
of
the
comments
come
directly
from
the
specification
which
we're
trying
to
make
sure
that
we
implement
here
and
one
of
the
things
that
I
wanted
to
ask
because
I
know
josh
is
on
the
call.
A
If
I
could
get
a
comment
on
this
is
if
this
looks
this
comment
looks
ready
to
resolve.
I
don't
know
if
you've
been
following,
I'm
guessing
a
few
other
things
to
do,
but
I
don't
know
if
you
have
the
time
to
take
a
look
at
this
one.
D
D
D
Why
that,
if
that
makes
no
sense,
then,
like
I
see
a
question
in
this
thread,
trying
to
redefine
the
specification
in
a
way
that
I
have
no
appetite
for
so
the
idea
that
there
are
some
things
being
discussed
like
whether
or
not
we're
going
to
flush
or
support
flush
and
shutdown
like
I
don't
feel
like
questioning
this
back,
so
I
think
we
should
just
accept
the
spec.
So
there
there's
a
little
bit
of
a
in
this
discussion
questioning
of
current
specification.
I
don't.
I
don't
feel
like
doing
that.
A
Statement,
let
me
make
it
clear
that
that's
not
my
goal
to
question
specification.
I
agree.
You
know
this
comments
on
whether
we
could
punt
on
the
flush
method.
It's
not
really
a
thing,
I'm
willing
to
move
on
because
it's
required
by
the
specification.
So
it
has
to
be
there
and
then
you
know
the
specification
also
says
that
it
flushes
all
telemetry,
that's
being
produced,
which
you
know.
However,
you
want
to
implement
that.
D
That's
that
that
shouldn't
be
taken
as
far
as
saying
we
must
have
an
interface
called
reader
to
me,
the
way
the
reader,
the.
What
the
reader
is,
is
a
configuration
of
an
export
pipeline
so
that
it's
there's
not
an
important
specification
question
to
be
answered
about.
Is
the
reader
a
thing
or
not?
What
what
we're
really
trying
to
answer
is?
D
A
A
It
has
a
world
view
of
like
how
it
passes
through
views
or
something
like
that,
like
eventually
the
reader
is
conceptually
the
thing
that
is
pulling
all
that
stuff
together
right
and
the
exporter
in
some
sense
is
the
thing
that
communicates
with
a
remote
third
party
and
whatever
that
is,
and
so
I
think
it
can
conceptually
be
the
same
thing
like
in
the
case
of
prometheus,
where
the
the
reader
is
something
that
pulls,
and
it
is
also
something
that
is
sending,
because
it
has
to
have
a
conceptual
understanding
that,
like
I'm
being
triggered
by
prometheus
right,
the
prometheus
export
right.
A
If
you
also
have
a
sorry,
I'm
trying
to
find
it,
but
like
an
export
interface
and
you
pass
that
to
a
periodic
reader,
the
periodic
reader
is
going
to
be
the
thing
that
says
like
okay
cool,
I
know,
and
I'm
going
to
take
that
and
I'm
going
to
pass.
You
know
this
interface,
something
where
this
is
a
push.
I'm
going
to
push
to
this
method.
A
D
D
A
A
D
D
Interface
because
they're
all
very
specific
to
that
purpose
or
the
application
that
that
you
have
so
I
do
have
a
type
in
my
my
branch
called
exporter,
it's
in
the
reader
package-
and
I
I
that's
to
me-
that's
intentional,
like
there's
still
no
distinction
between
reader
and
exporter
at
the
highest
level,
but
it
is
an
interface
named
exporter.
There's
no
reader,
because
what
you
do
with
the
exporter
is
you
give
it
a
reader
configuration
and
you
configure
it
to
to
the
to
the
meter
provider.
D
So
the
there's
a
with
reader
in
my
meter
provider
package
that
says:
here's
the
exporter
and
the
configuration
right
now,
the
exporter,
if
it's
going
to
be
periodic,
will
be
something
that
has
the
functionality
of
a
periodic
reader.
But
it's
still
an
exporter.
D
This
debate
is
interesting,
but
it's
not
changing
the
functionality
or
where
the
specification
is
being
met.
So
I
worry
that
this
is
blowing
us
down,
plus
that
this
is
a
detail
that,
like
matters
to
the
few
people
who
are
going
to
maintain
it.
So
I'm
worried
that
we're
just
this.
This
debate's,
not
too
too
important,
but
but
it's
it
is.
It's
still
a
debate.
I
don't
want
to
deny
that.
A
Yeah,
I
got
you
so
I
think
if
that's
a
yeah,
maybe
it's
just
a
terminology
thing,
but
at
the
end
of
the
day
like
I,
I
think
I
want
to
kind
of
go
back
to
this
pr
here
and
I'm
really
just
wondering
like.
Can
we
merge
this
as
it
is?
This,
I
think,
was
one
of
the
comments
that
was
kind
of
like
sticking
out
that
we
wanted
to
kind
of.
I
wanted
to
see
if
you're,
okay,
with
this
language
or,
if
you're,
actually,
if
you're,
asking
for
a
change.
A
This
topic,
I
think,
got
a
little
off
onto
the
weeds
that
I
wanted
to
like
isolate
that
in
the
reader's
issue.
But
I
just
I
want
to
say,
like
you
know
like,
is
there
something
that's
inherently
wrong
with
this
pr
that
we
need
to
fix,
or
can
we
merge
and
start?
You
know
continue
the
discussion
that
is
about
the
reader
stuff
in
the
reader
topic,
and
I
don't
mean
to
like
trivialize
it
like.
If
the
answer
is
no
like.
That's.
D
D
A
So
this
is,
I
don't
know
if
you've
read
my
last
comment
on
here
but,
like
the
question
is
that,
like
by
default,
the
returns
meteor
provider
is
configured
with
the
default
resource
and
no
readers,
which
I
think
is
an
accurate
statement
like
if
you,
if
you
it
is
okay.
I
just.
D
Don't
want
us
to
like
take
that
statement
and
and
and
move
to
the
and
therefore
the
logical
conclusion
is
that
we
can
break
from
the
spec
and
start
creating
meters
that
are
bound
to
meter
providers.
Later
you
got
to
provide
your
meetings,
oh
yeah
and
yeah.
Okay.
So
that's
important
to
me.
So
the
fact
that
you
can
do
this
with
no
readers
is
a
true
statement,
but
it
was
it's
nonsense
to
make
a
reader
provider
with
no
readers.
You
might
as
well.
Just
have
a
no
up
meter
reader,
there's
going
to
be
no
difference.
A
You
know
what
meter
reader
that's
a
good
one
yeah.
I
think.
D
A
A
Yeah,
no,
I
I
got
you
but
I
feel
like
if
we
can
work
that
in
somewhere,
that's
a
great
one.
So
I
agree
so
I
I
don't
mean
this
statement
to
be
in
that
vein,
that
this
is
justifying
that
we
need
to
have
the
other
way
around
and
I
feel
like
that's
the
next
part
of
this
discussion.
I
kind
of
want
to
go
into
that,
but
I
I
definitely
was
only
saying
that,
like
you
know,
either
in
either
case.
A
Actually
I
think
this
is
a
justified
statement
and
whether
we
go
where
what
was
I
saying
it
was
the
media
provider
registered
a
reader
or
the
reader
register
as
a
media
provider?
I
think
that's
the
the
next
discussion
I
kind
of
wanted
to
have,
but
I
think
that,
like
you
know,
spoiler
alert,
I
think
that
we
should
go
with
the
the
you
were
talking
about
with
the
meter
provider
registering
readers,
which
is
you
know,
with
the
options
that
you
have.
A
D
I
agree
I
now
that
we've
talked
about
it.
I
I
fully
approve
this
there's
a
skeleton
and
I
don't
we
disagree
with
that.
F
Do
we
need
to
say
more
should,
should
we
be
saying
by
default,
the
return
meter
provider
has
no
resource
on
no
readers,
and
this
is
useless.
Please
configure
them
or
is.
Is
that
implicit
in
the
fact
that
those
things
don't
exist
yet
in
this
sdk.
A
Yeah,
I
think,
yeah,
I
think,
there's
two
things
that
you
know
like.
Maybe
this
should
include
a
warning.
A
Right,
okay
and
then
the
other
thing
is
is
like,
if
not
done,
is
going
to
a
no
op
meter
provider.
A
Yeah,
okay,
those
are,
I
can
add,
a
sentence
to
encapsulate
this.
I
think
that's
a
good
addition
that
makes
sense
so
to
drill.
F
In
a
little
bit,
do
we
have
it
actually
return
a
no-op
meter
provider?
I
know
josh
said
that
would
be
a
meter
provider
without
a
reader
is
functionally
no
op,
but
is
it
actually
the
no
op
meter
provider?
Should
we
return
to
that
in
that
case,
or
should
we
return
one
that
does
stuff
but
can't
actually
export.
A
Oh,
no,
I
absolutely,
I
absolutely
think
we
should
return
to
noah.
That's
the
same
thing.
We
do
in
the
tracer
right,
like
our
the
tracer
provider.
Right,
like
we
say
like
oh,
we
know
this
is
going
nowhere
and
we
know
that
nothing
in
the
future
is
going
to
be
registered
to
change
that
so
don't
allocate
any
resources
like
just
give
you
a
new
op
like.
Currently,
we
don't
have
any
implementation.
The
whole
point
is
to
like
implement
this
later,
but
you
know
we
can
add
a
to-do
in
the
process.
D
F
A
Yeah
and
honestly,
it's
implementation
details,
so
I
I
don't
know
if
I
know
that,
like
realize
you're
like
oh
there's,
like
this
really
weird
edge
case
where
somebody
might
be
wanting
to
test
and
they
need
some
sort
of
validation
step,
but
we,
you
know,
fix
that.
I
think
that
we
could
address
that
at
that
point,
like,
I
think,
there's
a
lot
of
really
good
questions
here,
but
for
the
most
part
with
this
skeleton
we
can
push
those
questions
off
to
tomorrow.
If
that
makes
sense.
A
Okay,
I'm
going
to
take
that
this
action
item
to
adjust
this
flush
thing
again
like
I.
I
don't
think
this
is
really
a
question.
Oh
sorry,
my
internet
connection
will
start
from
cutting
out.
I
I
kind
of
want
to
resolve
this
like
include
a
flush
method,
this
flush
mesh-
that
is
from
the
specification
I
mean
they
call
it
force
flush.
I
guess
we
can
call
it.
We
go
into
a
bike
thing
but
like
otherwise
like
we
have
to
have
some
sort
of
method.
A
D
Or
anybody
else,
I
think
the
sdk
spec
actually
says
the
reader
method
is
named
flush.
So
the
fact
that
it's
force
flush
at
the
meter
provider
level
seems
to
be
specified
that
way.
I
don't
know
that
we
that
it
matters,
but
what
I
do
believe
is
that
this
this
question
of
what
kind
of
sense
does
it
make
that
there's
a
flush
method
on
a
pull
pull?
You
know
scraping
like
prometheus
exporter.
It
makes
no
sense.
That's
been
written
and
debated
like
it's,
it's
like
just
what
we
decided
to
do.
It
was
like
it's
fine.
A
A
D
I
think
that's
because
there
was
an
objection
to
a
flush
method,
because
people
see
a
flush
method
and
they
think
they
have
to
use
it
and
the
force
is
there
to
remind
them
that
that
it's
sort
of
an
optional
thing,
you're
being
paranoid.
If
you're
using
this
or
you
better,
really
have
a
reason
to
force
a
flush,
because
we
flush
when
we
export.
F
Right
yeah
that
I
seem
to
recall
sometime
last
year
having
discussions
about
needing
to
indicate
the
success
or
the
the
presence
of
failure,
and
not
the
absence
of
success
through
through
error
returns
on
this
one,
but
yeah
this
could
be.
No
error
means
nothing
happened,
nothing
didn't
go
wrong
or
nothing
went
wrong,
which
could
be
absolutely
nothing.
A
Oh,
my
god,
or
you
respond
with
an
error,
saying
like
everything
was
great.
Like
yeah,
you
don't
really
have
great
options
there.
Okay,
that
being
said,
I'm
gonna
resolve
this
and
I'll
take
these
two
action
items
for
afterwards.
Otherwise
I
think
that
we
can
merge
it
with
these
two
changes.
If
that
makes
sense
to
everyone.
A
Cool
well,
then,
status
update
our
milestone
is
getting
higher
than
10
already
so
yeah.
Okay,
then,
the
next
question
josh
I
wanted
to
talk
about,
looks
like
we've
got
a
little
bit
of
time
is,
I
think,
with
there's
a
long
thread
here.
A
I
don't
know
if
you've
read
it,
but
the
idea
was,
I
don't
think
it's
worth
pursuing
the
reader
register
a
meter
provider
option
anymore,
and
I
think
that
there's
a
lot
of
good
implementation
details
that,
like
you,
brought
up,
but
also,
I
think
that
at
the
heart
of
it,
I'm
not
conf
that
the
dissimilarity
between
the
tracing
signal
and
the
metric
signal
would
be
worth
it,
as
well
as
the
implementations
in
all
the
other
languages.
A
Do
it
the
other
way
around
so
like
it
really
isn't,
it'd
be
so
greenfield
that
I
don't
know
if
it's
a
useful
way
to
even
discuss
it.
I
think
that
having
the
meter
provider
have,
a
registration
method
is
going
to
be
just
more
in
line
with
expectations
for
people.
Who've
already
used
the
trace
signal,
as
well
as
anybody
else's
uses,
not
other
implementation.
So
at
this
point
I
I'm
going
to
say
like
let's
stop
pursuing
the
other
one
that
I
was
saying.
I
don't
understand
the.
D
A
Yeah,
I
still
think
it's
possible
to
do
it
that
way
where,
as
when
you
essentially
register
the
meter
provider
with
the
reader
it
reaches
into
the
meter
provider
and
says,
like
hey
anytime,
somebody
calls
flush
on
you
call
my
flush
as
well
and
essentially
like
you.
Just
have
the
entry
point
flush
be
on
the
meter
provider,
but
like
yeah,
I
can
see
that
one
being
confusing
because
you
are
like
you're
saying
like
passing
it
to
the
reader
on
creation.
So
why
is
the
career
like?
A
A
There's
a
few,
but
I
also
think
that
there's
a
lot
of
other,
like
you,
don't
pass
a
a
tracer
provider
to
a
span
processor
right
like
so
people
are
going
to
be
really
confused
if
you're
passing
to
a
reader
like
what's
the
difference-
and
I
think
there
is
a
you
could
say
like
well,
telemetry
can
flow
in
the
opposite
direction
so,
like
or
I'm
sorry
remember.
The
control
mechanism
can
flow
in
the
opposite
direction,
but
I
don't
think
that's
good
enough,
especially
when
other
implementations
in
other
languages
don't
do
that.
A
So
maybe
what
I'll
ask
from
you
is
to
just
forget
everything.
I've
said,
I
think
it's
a
great
academic
discussion
and
let's
move
on
to
just
the
registration
stuff
of
the
meter
provider
of
the
readers.
If
that
makes
sense,.
D
Yeah,
I
think
I
I
think
I
get
what
we're
talking
about.
I'm
not
sure
anyone
else
followed
that,
because
the
word
registration
is
being
used
in
a
couple
of
different
ways.
It's
a
confusing
word.
D
D
So
I
I
probably
have
different
reasons
for
rejecting
what
you
just
described,
but
as
long
as
we
agree
to
reject
it,
we're
now
the
and-
and
I
think
I
had
seen
this
debate
happening
at
the
spec
level
as
well.
There
was
a
question
from
honorable
at
one
point
saying:
why
does
the
spec
not
have
this
notion
of
a
producer
built
in
because
that's
how
java
does
its
registration
registry
as
soon
as
the
sdk
is
set
up?
D
It
calls
register
on
the
reader
reader
exporter
thing
and
then
you
know
receives
a
producer
after
which
things
have
started,
and
you
can
then
produce
metrics,
and
the
answer
was
that's
an
implementation
detail.
The
fact
that
meter,
but
but
then
that
the
java
team
came
back
and
said,
but
that
means
that
we're
not
actually
providing
a
metric
leader
when
you
start
the
sdk
we're
providing
a
factory
for
metric
readers
when
you
start
the
sdk
and
I-
and
that
was
where
I
don't.
I
didn't
call
it
a
factory
here.
D
I
called
it
a
registry
but
you'll
notice
that
there
is
such
a
thing
as
a
factory.
Basically,
because
it's
the
thing
that
actually
starts
things
happening
once
this
sdk
has,
so
it's
not
really
constructing
a
factory
method,
but
it's
like
this
is
the
the
call
to
the
factory-like
thing,
which
begins
the
thing
starting
or
whatever.
So
so.
In
that
sense,
I
was
kind
of
following
the
convention
that
I
had
seen
described
in
the
java
group
without
ever
really
reading
their
implementation,
but
I
think
on
first
principles.
D
This
gets
justified
by
the
idea
that
it
is
truly
the
the
different
reader
and
there
are
different
ways
of
imagining
you
can
do
the
pull
base
or
the
manual
in
memory
or
like
the
periodic
or
whatever
all
those
different
things
are
different
ways
of
choosing
when
to
trigger
another
collection,
so
that
in
fact,
they're
like
these,
these
reader
things,
these
reader
exporters
are
the
things
responsible
for
starting
collection.
So
right.
A
So
kind
of
on
that
topic,
then
I
imagine
we're
probably
losing
some
people,
so
I
apologize
on
that
one.
It
is
a
really
great
conversation
and
if
you
need
to
drop
off,
I
also
understand,
but
so
josh
on
the
idea
of
the
producer,
essentially
being
in
implementation
detail.
One
of
the
questions
I
had
on
the
current
design
is:
can
we
abstract
that?
Can
we
can
we
hide
that
and
not
have
it
be
exported
in
a
way
that,
essentially,
I
know
in
the
java
implementation?
They
don't
allow
third-party
readers.
A
They
specifically
have
some
sort
of
sealed
type.
That
is,
is
not
something
that
a
a
third-party
person
can
come
in
and
just
create
their
own
reader,
and
I
think
that
we
should
probably
try
to
do
the
same
thing
and
start
with
that
level
of
isolation,
because
I
really
there's
only
two
readers
that
I
think
we
know
of
and
then
I
think
there
are
ways
in
the
future
if
we
wanted
to
open
that
up.
Okay,
all
right,
maybe
that
was
a
statement.
D
I
said
that
I'm
chuckling,
because
I
still,
I
still
don't,
have
anything.
That's
a
reader.
The
the
the
thing
that
we
are
thinking
of
when
we
say
reader
is
a
construct
which
equals
the
the
exporter,
interface,
plus
the
configuration
and
nothing
more.
So
so.
The
fact
that
you
so
so
it's
like
more
like
the
reader
is
the
absence
of
an
interface
right
here,
and
the
fact
that
we
have
only
a
fixed
number
of
them
is
because
there
really
are
only
only
so
many
prototypes.
D
You
can
have
a
pole
based
thing
where
you're
the
responsible
party
and
you
can
have
a
periodic
thing
where
there's
a
pulse,
that's
generating
that
trigger,
and
there
aren't
very
many
other
ways
to
imagine
it.
Basically
so
that,
but
again
I
didn't
actually
create
a
thing
called
a
reader,
so
there's
nothing
to
seal
and
and
what
that
leaves
is
that
the
baseline
and
I've?
D
So
I've
only
needed
enough
reader
to
do
a
prometheus
exporter,
and
I
believe
that
this,
what
in
what's
in
my
branch
right
now,
is
like
kind
of
the
the
the
least
inner,
the
least
interface
surface
that
I
could
come
up
with
that
still
allows
an
exporter
to
exist,
and
so
your
your
question
about
sealing
the
the
reader
is
sort
of
like
yeah.
We
could.
We
could
further
structure
the
interfaces
so
that
there's
only
the
two
paths
to
construct
two
different
reader
experiences
or
something
like
that.
D
A
D
Which,
let's
see
oh
you're,
looking
at
that
okay,
so
look
at
reader.go?
What's
the
next
file.
D
I
just
was
refactoring
before
the
thing,
so
I
could
aaron
and
I
have
debated
whether
that
exporter
online
49
should
be
named
reader,
and
I,
like
it's
just
a
naming
question.
I
could
name
that
reader,
but
I
wouldn't
want
to
change
anything,
but
it
does
and
if
you
are
going
to
be
a
pool
based
exporter
when
you
receive
the
producer
you're,
just
gonna,
that's
the
first
thing
you
do
for
your
for
your
scrape.
D
Is
you
produce
metrics
and
then
you
output
them,
but
if
you're
push
based
or
periodic
based
you're
going
to
receive
that
producer
and
then
do
some
more
you're
going
to
like
put
a
loop
together
and
start
looping
or
whatever
and
and
the
fact
that
you
can
define
new
reader
behaviors
is
okay
with
me,
because
the
the
behaviors
are
constrained
to
this
interface
that
lets
you
produce
metrics.
However,
you
want
in.
A
Yeah,
this
is
starting
to
dawn
on
me
about
what
our
previous
conversation
about.
There's
no
difference
between
an
expert
or
reader
and
see.
A
So
I
don't
know
I
have
to
think
about
this.
Unfortunately,
because
I
I
I
haven't
looked
through
this
enough
yet
but
yeah,
there
was
a
distinct
difference
before
to
me
because
it
was,
you
would
only
ever
pass
an
exporter
to
a
periodic
reader,
and
I
I
don't.
I
want
to
think
through
this,
because
it
seems
like
having
that
layer
of
separation
allows
the
periodic
reader
to
be
reusable
and
the
polling
logic
to
not
have
to
be
recreated
in
every
single
editor.
D
It
so
if
you
want
to
submit,
if
you
want
to
meet
the
periodic
exporter
interface,
which
is
this
exporter
interface,
plus
one
more
method,
that's
like
export
these
metrics,
then
you
can
reuse
the
periodic
exporter
interface
and
the
periodic
metric
reader,
but
it
would
be
all
on
top
of
the
stuff
that
I've
shown
us
already.
That's
the
idea
so.
A
D
E
D
Sometimes
that
actually
helps
me,
but
I
I
admit
that
this,
the
name
reader
and
exporter
is
getting
confusing.
So.
G
Someone
new
just
to
give
you
some
input
as
a
new
person
if
there's
not
a
lot
of
difference
between
exporter
and
reader,
and
it
feels
like
a
difference
without
a
distinction,
it's
going
to
be
real
hard
for
people
to
adopt
and
I'll
be
the
first
one
to
implement
the
wrong
one
in
the
wrong
place,
and
hopefully,
there's
a
two
sentence
description.
That
explains
why
one
is
sort
of
a
contrast
from
the
other
yeah.
A
A
Because
I
look
back
and
I
look
at
the
tracing
signal
and
we
had
people
that
implemented
something
that
looked
like
this,
and
that
was
essentially
the
translation
layer
between
data
and
the
remote
endpoint
and
that
remote
endpoint
got
the
you
know
it
used
to
be
traces,
but
now
would
be
metrics
and
then
they
were
able
to
handle
off
where
that
went,
and
I
think
that
again,
like
similar
to
the
batching
span,
processor
or
the
the
simple
span
processor
like
the
periodic
reader,
can
be
thought
of.
A
As
that
like
it
can
be
thought
of
as
the
pulling
mechanism
that
ties
this
export
interface
to
the
meter
provider,
and
I
think,
if
that's
it's
lost.
If
you
try
to
go
in
this
direction,
where
essentially
you're
saying
like
all
spam
providers
or
sorry
spam
processors
should
have
just
been
exported,
there
was
no
distinction
between
the
two
is
how
this
would
be
thought
of
and
and
on
some
level
it
could
be
like.
I.
A
I
definitely
think
that
there's
an
added
layer
that
you,
in
fact,
I
think,
there's
some
optimization
that
you
could
have
in
certain
situations
where,
if
you
don't
want
to
use
a
batching
span
processor-
and
you
just
want
to
you
know
to
tie
to
an
exporter-
you
just
want
to
build
your
own
spam
processor.
You
can
make
some
optimizations
there,
but
I
think
for
the
most
part,
like
there's
a
layer
of
complexity,
that's
going
to
be
added
right
for
so
like
you're,
saying,
like
the
periodic
reader,
people
could
wrap
it.
A
D
So
yeah-
and
I
I
agree,
this
type
that
we
were
just
looking
at
of
mine.
I
named
it
exporter
because
I
think
of
a
prometheus
exporter
as
an
exporter,
but
if
prometheus
exporter
doesn't
never
gets
pushed
to,
it
doesn't
have
that
export
method.
It
is
going
to
collect
and
do
its
own
thing.
Therefore
I
should
call
that
a
reader,
so
you
can
rename
that
interface
exporter
and
now
there's
no
exporter
and
then
brad.
D
A
That's
that's
also.
The
next
point
is
I
I
would
flatten
all
this
like.
I
think
that
this
is
so
similar
to
the
span
processor
that
lives
in
the
sdk
trace
package
that
it
seems
like
you
can
get
rid
of
this
interface
entirely.
If
you
just
put
this
in
the
sdk
metrics
patrick
package,.
D
D
If
we
did
what
you're
suggesting
I'm
not
I
I
my
attitude
is
always
the
reviewer's
always
right
so
I'll
do
what
anybody
says
to
do
as
long
as
they
aren't
contradicting
someone
else,
and
in
this
case
it's
going
to
mean
taking
like
four
packages
and
flattening
them
into
one,
because
a
cycle
will
be
created
if
you
put
stuff
from
the
reader
package
into
the
meter
metric
package,
which
is
not
terrible,
but
it
is
factored
apart
right
now
for
a
reason,
so
maybe
I'd
I'd,
probably
rather
see
you
put
an
alias
into
the
metric
package
which
doesn't
break
the
cycle.
A
A
Yeah,
I
think
I
think
that's
true
and
the
way
I
looked
at
it.
I
think
that
that's
a
positive
way,
because
the
api
then
matches
a
lot
closer
to
what
the
tracing
signal
is,
and
you
have
everything
in
a
single
import
and
I
I
would
actually
agree
with
you
that
I
think
that
we
could
have
put
the
spam
processors
in
their
own
packages
and
it
would
have
been
better
structure.
A
But
we
didn't-
and
at
this
point
like
I
don't
think
that
it's
it's
it's
implementation
may
be
more
complex,
but
I
think
that's
not
something
that
the
end
user
cares
about
because
like
if
we
have
aliases
that
are
in
like
this
top
level
package.
If
we
go
back
to
brad
and
he's
looking
at
him
going
like
okay
but
like
which
one
do
I
use
like.
That's,
not
really
a
helpful
thing
to
be
doing.
A
D
You
would
import
the
metric
stk
and
then
you
would
import
the
prometheus
exporter
and
you
would
say,
with
reader
and
give
the
prometheus
exporter.
So
so
only
when
you
want
to
modify
options,
would
you
need
a
different
import.
A
Right
but
I
I
keep
in
mind
like
there's:
statsd
exporters,
there's
new,
relic
explorers,
there's
aws
for
explorers,
there's
gcp
exporters.
There's
you
know
right.
A
I
see
that's
where
I
don't
think
it's
the
case,
because
if
you
have
all
of
those
implementations
providing
a
reader
constructor,
they
all
have
to
implement
some
sort
of
periodic
scraping
logic.
And
that's
what
I'm
saying:
there's
a
separation
here.
No.
F
A
Right
and
that's
that's
how
I
see
it
and
like
that,
I
I
don't
see
it
being
much
different
than
the
batch
span
processor
like
when
you,
when
you
use
tracing
pipeline,
you
create
a
meter
provider
or
I'm
sorry,
a
tracer
provider,
and
you
pass
it
an
option.
You
know
with
batching,
or
I
can't
remember
that
exact
name
but
like
describes
the
batch
span.
Processor
that
exists
in
that
same
package
right,
like
there's.
F
So
I
think
what
I'm
getting
out
of
this
conversation,
though,
is
that
it
seems
like
there
may
not
be
a
need
to
expose
to
the
user,
who
is
configuring,
the
sdk,
the
concept
of
something
that
sits
between
the
sdk
and
the
exporter,
aka
the
reader
or
what
in
the
trace?
Where
was
the
batch
band
processor?
The
simple
span?
Processor
right?
F
Each
exporter
is
going
to
need
to
select
the
implementation
of
a
reader
that
is
appropriate
for
it,
and
that
could
be
one
that
we
provide
as
part
of
the
sdk
for
exporters
to
use,
or
it
could
be
one
that
the
exporter
itself
implements.
But
the
only
thing
that
gets
registered
with
the
meter
provider
is
the
exporter.
G
G
A
F
The
prometheus
exporter
would
register
with
the
the
meter
provider
to
get
data,
but
it
would
buffer
that
data
internally
rather
than
when
it
when
it
collects
or
what
it
when
it
reads,
shipping
the
data
by
push
somewhere.
It
would
read
data
to
be
provided
the
next
time.
An
http
request
comes
in
to
pull
that
data,
and
it
may
only
read
when
a
request
comes
in,
but
that's
that's
something
that
is
within
the
purview
entirely
of
the
prometheus
exporter.
That's
that's
functionality
that
doesn't
need
to
live
anywhere
outside
of
the
prometheus
exporter.
No.
A
Because,
okay,
if
I'm
going
to
call
it
an
exporter,
it
has
a
completely
different
set
of
functionality.
This
is
kind
of
where
we
started
the
discussion
about
like.
I
think
there
is
actually
a
difference
between
an
exporter
and
a
reader,
and
I
don't
think
that
you're
going
to
be
passing
an
exporter
to
like
a
manual
reader
that
doesn't
have
conceptually
any
sense.
I
do
think
that
you
will
be
passing
an
exporter
to
a
periodic
reader.
A
I
think
that,
similar
to
like
a
batch
fan
processor
that
does
batching
on
top
of
some
sort
of
export
pipeline,
the
periodic
reader
does
periodic
lookups
on
top
of
some
sort
of
export
pipeline,
and
that
export
pipeline
is
the
thing
that
it
actually
transmitted
somewhere,
but
the
pull
side
of
things
where
you
have
the
prometheus
exporter
in
itself.
It
has
to
do
the
reading
and
like
that
is
the
thing
that
is
is
defined
in
the
specification
as
this
collect
method
and
it
links
a
collect
method
to
an
http
request.
F
But
does
that
need
to
be
exposed
to
the
user
under
the
term
reader?
Or
can
we
call
that
an
exporter
which
is
what
most
people
are
going
to
think
of
it
they're
going
to
think
I've
got
the
prometheus
exporter?
Let
me
configure
it
to
export
prometheus.
Just
like
I'm
going
to
configure
an
otp
that
configures
otop
and
each
one
knows
what
kind
of
reader
they
need
to
actually
construct
and
register
with
the
meter
provider,
but
the
the
the
end
user
is
is
creating
you
know
new
meter
provider
with
exporter
new
prometheus
exporter,.
A
Well,
you
can't
register
a
prometheus
exporter
the
same
way.
You
would
register
an
otlp
exporter
like
that.
The
option
function
would
have
to
be
different
because,
like
the
the
way
that
it
transmits
can't
have
the
same
methodology
so
like
you
can't
pass
the
same
interface,
then,
unless
you
overload
it
now,.
D
I
want
to
draw
an
example
right
now:
in
an
http,
middleware
environment,
ignoring
telemetry,
ignoring
stuff.
We
you,
you
suppose
you
are
a
piece
of
middleware.
You
are
one
person's
client
and
you
are
another
person's
server
you're,
both
a
client-
and
you
are
a
server.
I
think
that's
the
type
of
naming
disagreement
we're
having
here
is
that
one
export
pipeline
contains
both
a
reader
and
an
exporter.
The
exporter
reads
from
the
sdk
and
the
sdk
flushes
the
exporter.
A
But
in
the
case
of
the
periodic
exporter
they
can
be
different
is
what
I'm
saying
in
in
in
a
poll
model
yeah
they're
the
same
thing,
because
they
know
when
you
have
a
client
requesting
that
they
need
to
be
pulling
from
downstream
right,
but
in
the
periodic
reader.
That's
not
the
case
right
like
it
can
also
be
that,
like
periodically,
I'm
gonna
pull
something
and
I'm
to
push
then,
and
the
way
the
direction
that
I'm
pushing.
A
Those
could
be
two
separate
components
and
the
way
like
the
thing
that
you're
going
to
push
to
you
could
you
could
put
in
a
new
relic
export
you
can
put
in
oclp
x,
like
all
of
these
different
pushed
end
points
in
the
same
way
that
we
do
the
tracing
setup.
Is
that
not
the
case?
I'm
not
disagreeing?
I
just
think
that
that.
A
A
D
D
So
I
think
I
still
think
of
prometheus
as
an
exporter
and
all
the
push-based
exporters
as
a
sub
set
of
exporters,
and
I
would
be-
and
I
so
so-
don't
really
care
about
the
the
naming
debate
that
I'm
willing
to
call
the
full-based
exporters
readers
of
the
first
class.
But
these
push-based
exporters
also
have
readers
so
there's
a
different
type
of
reader
there
and
I
yeah.
I.
A
A
They're
both
reading-
and
I
think
that
that's
why
there's
a
distinctive
like
thing
that
you
call
a
reader.
In
fact,
the
specification
says
that
the
periodic
reader
is
a
superset
of
the
direct
manual
reader,
because
you
can
still
call
the
collect
method
directly,
but
it
will
also
call
it
periodically
on
your
behalf,
and
so
I
think
that,
like
yeah,
I
think
that
there's
like
two
layers
there
like
one
is,
you
know
you
have
the
meter
provider
here.
A
Then
you
have
some
sort
of
reading
interface
that
sits
on
top
of
that
and
one
of
those
knows
where
to
send
it
because
it,
the
request,
came
into
that
reader
directly.
The
other
doesn't
like
the
other
needs
to
know
where
to
send
it
and
that's
where
an
exporter
sits
on
the
other
end
of
the
periodic
reader,
and
that's
where,
like
you,
have
a
distinct
interface
type.
A
It
seems
like
if
we,
if
we
collapse
them
to
always
be
the
same,
then
like
the
one
that
gets
pulled
the
prometheus
one
like
that
makes
sense
still,
but
the
one
that
pushes
it
has
to
get
recreated
or
you
have
to
do
some
sort
of
like
wrapping
around
it,
which
in
itself
is
like.
It
goes
back
to
that
registration
question
like
what
direction
is
this
all
flowing
right
like
if
I'm
going
to
have
my
otlp
export
or
wrap
a
periodic
reader?
A
But
if
I'm
registering
the
periodic
reader
with
my
exporter,
it's
the
other
way
around.
It's
the
same
same
problem.
We
were
just
talking
about
like
in
the
same
sense
that
if
I
register
my
meter
provider
with
a
reader,
then
how
how
do
I
have
the
flush
from
the
meter
provider
go
through
the
reader?
It's
the
same
thing.
If
I
have
an
exporter,
registering
it
with
a
reader,
how
do
I
have
the
flush
from
the
reader
go
back
through
the
exporter?
It's
it's
this!
It's
again
like
the
telemetry
control
flow
goes
one
direction,
but
the
other.
A
You
know,
control
flows,
go
the
opposite
direction.
If
you
go
back
direct
like
if
you
go
that
way,.
A
D
I
think
those
things
are
there.
I
just
I
just
don't
think
that
we've
agreed
on
how
to
name
them.
I
I'm
not
disagreeing
about
the
existence
of
these
things
and
we
should
probably
just
table
this
and
and
come
back
with
a
more
clear
statement.
D
You
know,
I
believe
there
is
a
type
called
and
there's
like
you
can
rename
all
the
things
in
my
presentation,
but
I
believe
there
are
these
distinct
types
and
these
things
and
and
there's
a
registration
like
a
method
for
attaching
them
to
the
sdk
and
like
there's
going
to
be
a
periodic
reader
and
there's
going
to
be
a
manual
reader
and
there's
going
to
be
an
exporter
and
a
periodic
exporter
and
like
we
could
shuffle
the
names
and
change
not
change
anything.
So
I
you
know
I
can
agree
to
like
you
know.
D
First
of
all,
my
branch
doesn't
have
the
periodic
or
the
push
based.
I've
only
done
the
the
basic
you
know
prometheus.
So
you
can't
see
this
in
my
branch
and
I
and
it
sounds
like
I-
should
incorporate
aaron's
work
and
come
back
with
at
least
something
we
can
look
at
here.
A
Yeah,
I
think
that
would
be
helpful
because
I
I
agree
like
I
think
I
I
agree
with
like
this
idea
that
there's
like
concrete
types
and
like
what
naming
is,
but
what
I'm
trying
to
say
is
like
that's,
not
the
discussion
I'm
having
is
that,
like?
I
do
think
that
there
is
a
distinction
between
like
the
periodic
reader,
because
it
has
another
type,
there's
another
thing
that
sits
with
it
and
how
that
how
that
couples
with
the
two
you
know
how
we
want
to
name
those
things.
A
I
think
that
I
I've
settled
on
anything
but
like
maybe
that's
not
like
ideal,
and
we
can.
We
can
address
the
naming,
but
I
think
that,
like
in
the
periodic
exporting
like
scenario,
there's
a
separation
of
duties
that
is
not
seen
in
in
without
without
actually
going
through
it.
So
maybe
it's
just
worthwhile.
A
F
The
risk
of
confusing
things
further
can
we
perhaps
consider
whether
we
could
eliminate
the
the
distinction
and
say
that
the
prometheus
exporter
is
an
exporter
that
gets
periodic
push-based
exports
and
it
pushes
to
an
in-memory
store
that
will
be
served
up
the
next
time.
An
http
request
comes
in
that's
how
the.
D
F
A
D
Right,
I
I
think
the
distinction
has
actually
been
collapsed
and
I
would
like
to
request
permission
to
finish
showing
that
meaning
that
everything
is
an
exporter,
some
of
them
handle
manual
collection
can
do
it
themselves
and
some
of
them
have
this
periodic
helper,
helping
them
and
and
those
things
satisfy
different
interfaces,
and
one
is
a
subset
of
the
other
to
me.
The
to
me
the
end
to
end
story
still
has
some
things
need
to
be
resolved
for
usability,
and
you
know
in
my
example,
the
to
to
start
a
prometheus
server.
D
You
create
a
new
sdk
and
you
create
a
previous
exporter
and
you
would
say,
with
reader
right
and
yeah.
That's
all
you
had
to
import,
but
the
reason
that
that
works
is
that,
like
all
of
our
defaults
across
the
sdk
are
made
tailored
for
prometheus,
so
that
you
shouldn't
have
to
change
any
defaults
and
you
get
prometheus
goodness.
D
Consequently,
I
don't
actually
ever
have
to
add
could
pass
configuration
options
when
I'm
with
reader,
because
there
are
all
kinds
of
options
that
you
might
set
to
change,
temporality
to
change,
aggregations,
to
set
views
and
so
on.
So
the
the
question
has
been
in
open
telemetry
for
these
kind
of
like
default
configured
exporters
like
if
you
have
an
environment
variable
that
says
start
me:
a
prometheus
export
or
an
environment.
Variable
that
says
start
menu.
Tlp
exporter,
the
exporter
is
responsible.
D
At
that
point,
the
sdk,
auto
configured
exporters
are
responsible
for
their
own
reader
configuration.
So
that's
what
I
want
to
do
is
see.
The
prometheus
exporter
can
say,
give
me
a
reader
config
your
default
reader
config,
and
then
I
will
still
not
have
to
import
the
reader
package,
because
what
the
simple
recipe
for
starting
a
prometheus
server
will
be
new
prometheus
exporter
and
then
with
reader
for
and
past
the
prometheus
exporter,
as
well
as
the
prometheus
exporter's
default
config,
and
that
will
accomplish
this.
A
I
think
we're
all
in
agreement
on
the
side.
Like
the
the
question
is
the
other
side.
I
think
we
need
to
probably
work
on
now.
D
Yeah
it
implements
down,
it
implements
flush.
How
does
it
implement
register?
It's
got
to
use
a
periodic
register
periodic
reader
to
do
that,
for
it,
because
the
periodic
reader
is
the
thing
that
receives
the
producer
when
it's
registered
and
then
starts
the
loop.
So
by
virtue
of
embedding
a
periodic
reader
for
itself,
it
now
satisfies
the
exporter
interface,
so
the
otsp
shutdown,
the
periodic
reader
implements
register.
A
A
A
Using
the
term
register,
what
I'm
saying
is
that,
like
you,
can
put
a
meter
provider
in
a
reader
and
we're
like
no
don't
do
that.
That's
a
bad
idea!
So
now
we're
saying
like
we
put
instead
of
an
exporter
inside
of
a
reader
you're
saying
put
a
reader
inside
of
an
exporter,
and
that's
that's
where,
like
this
conflict,
that
I'm
I'm
trying
to
raise
is
coming
up,
I
don't.
A
I
think
we
found
each
other
on
the
other
side
of
the
conversation
of
registration,
then,
because
I
I
would
say
the
same
thing
to
you
about
flushing
shutdown
being
the
opposite
direction,
but
I
also
want
to
say
that,
like
we
have
two
minutes
left-
and
this
is
something
that
is
definitely
not
resolved
so
josh.
I
would
love
to
see
some
sort
of
periodic
pipeline
in
your
branch
if
you
could,
if
you're
planning,
to
work
on
that
like
send
it
my
way.
I
also
know
that
you're
busy
so.
D
No
top
priority,
I'm
I'm
just
feeling
like
there's,
I'm
not
it's
not
clear
how
to
make
anybody
happy
here.
So
that's
all
I've
been
working
on.
A
Actually,
I
I
fear
that
we're
talking
a
lot
around
each
other
and
having
concrete
examples
might
solve
this.
Another
thing
that
may
be
helpful
is,
if
maybe
in
that
reader
issue,
you
could
just
give
a
high-level
interface
definitions
kind
of
similar
to
what
is
already
posted
there
as
to
like
what
interfaces
you
think
are
important
and
how
they're
structured
would
be
really
helpful.
A
Okay,
cool
yeah-
I'm
excited
about
that
and
then
maybe
we
set
up
again
like
monday
or
something
like
that
or
tuesday
for
a
little
deep
dive.
So
we
have
to
bring
everybody
into
this
conversation.
D
Everyone's
hung
on
so
it
must
have
been
somewhat
interesting.
Thank
you
all
for
hanging
on
appreciate
it.
A
I
really
appreciate
it
as
well
and
out
of
respect
for
my
son
brad.
I
see
you
have
a
topic
there.
If
anybody
can
just
respond
in
the
agenda
notes,
it
would
be
much
appreciated.
G
F
Yep
stop
by
the
aws
booth,
we'll
be
doing
some
some
demos
of
some.
E
F
A
Cool
awesome.
Everyone
thanks
for
joining
thanks
for
sticking
with
us.
E
We're
gonna
give
before
we
turn
off.
I'm
gonna
give
quick
update
on
the
benchmarks,
I'm
waiting
for
approval
for
the
boxes,
so
I've
submitted
a
issue
to
get
the
cncf
boxes
and
get
access
wait
for
approval
for
that
so
kind
of
a
holding
pattern.
Until
that
happens,.
A
Awesome
thanks
for
the
update
thanks
everyone
for
joining.
We
will
see
you
here
same
time
same
place
next
week
and
online
thanks.