►
From YouTube: 2022-09-22 meeting
Description
Instrumentation: Messaging
D
C
C
D
C
C
B
C
Don't
I
don't
know
either
I've
talked
to
Morgan
a
little,
he
went
to
Detroit
and
he
was
hanging
out
with
Daniel
Dayla
a
little
while
ago,
and
he
was
saying
like
that
main
drag
I
think
where
the
conference
is
happening
like
it's.
It's
okay,
but
he's
also
like
yeah.
If
you
go
like
five
blocks
away
from
that,
like
you're,
yeah
I
wouldn't
be
walking
the
streets
kind
of
thing,
yeah.
B
C
E
C
I
know
you
know:
yeah
I
think
that
I've
I've
thought
about
going
to
the
kubecon
EU
twice
now
one
was
during
the
pandemic,
which
didn't
really
happen
and
the
other
was
at
the
start
of
the
pandemic,
which
obviously
didn't
happen.
Everything
got
canceled,
so
yeah
I
can
see
the
pain
of
trying
to
fly
across
the
ocean.
It's
not
fun.
F
C
C
C
C
Okay
but
yeah,
let's
jump
in
here
I
know
Anthony
said
he
wasn't
going
to
be
able
to
make
it
today,
so
I
think
we're
at
Quorum.
If
you
haven't
yet
already
add
yourself
to
the
attendees
list
and
if
you
have
agenda
items
you'd
like
to
talk
about,
please
add
them
to
the
doc
starting
off.
If
you
have
living
under
a
rock
I
think
everyone
on
the
call
earlier
knows
the
metric
SDK
was
released
technically
I,
think
on
Monday
and
so
yeah.
C
That's
out
that
was
it's
really
exciting.
I
thought
I'd
have
a
lot
less
to
do
once
that
went
out,
but
it
seems
like
the
opposite,
but
yeah
it's
it's
really
exciting.
We're
definitely
getting
some
people
to
use
it
across
the
board
and
I
think
it.
It
was
probably
ideal
where
we
released
it.
So
yeah!
Congratulations
to
everyone
thanks
for
all
the
effort
and
getting
this
done,
yeah
really
exciting,
yeah,
definitely
emojis
ever
all
over
the
place.
C
Okay,
that
said,
one
of
the
follow-up
things
was
the
opennesses
bridge.
We
had
left
out
of
the
alpha
release
and
David
put
together
a
really
quick,
essentially
like
support
for
this
new
SDK
by
adding
equivalent
support
that
used
to
be
in
the
open
census,
Bridge
plus
updating
the
example.
So
that's
all
ready
to
go,
there's
actually
a
release,
that's
staged!
That
needs
some
review.
C
That
being
said,
there's
I
think
a
good
amount
of
administrative
proposals.
Here.
Maybe
we'll
talk
a
little
bit
about
this
as
well,
because
there's
also
this
v032.1
Milestone,
which
is
including
a
bunch
of
bug,
fixes
for
the
SDK
I
think
that's
also
I
was
hoping
to
have
it
go
out
today,
but
there's
this
other
one
I
added
an
hour
ago.
So
I
don't
know
if
that's
possible.
C
It
would
also
might
be
that
we
skip
a
few
of
this
stuff
and
just
try
to
do
a
release
with
what
we
have.
So
that's
kind
of
what
I
wanted
to
ask
I
think
is
one
I,
don't
know
if
I'm
gonna
work
tomorrow,
I
think
I
need
a
little
bit
of
a
break,
so
I
might
take
the
day
off.
But
that
being
said
like
come
Monday
or
if
there's
another
maintainer,
I
guess
Aaron
you're,
the
only
other
maintainer
on
the
call.
C
If
you
want
to
pick
up
the
release
for
tomorrow,
I
would
be
in
favor
of
that
as
well.
I
think
that
what
we
could
do
is
honestly
and
I'm
open
to
suggestions
here:
bundle
of
the
v032
open
census,
Bridge
release
with
the
vzero
three
two
one
metrics
bug
fixes
and
literally
take
these
three
items
and
move
them
to
like
a
v032.2.
C
B
C
Think
that's
going
to
be
a
pretty
important
one.
This
was
also
a
pretty
important
one.
Currently,
the
metrics
don't
have
any
reader
resources,
yeah,
yeah
I
think
these
are
the
two
big
ones.
The
sanitizing.
The
metric
instrument
names
is
that's
right,
yeah,
it's
really
nice
too,
because
otherwise
you
have
to
do
these
View
renames
and
it's
yeah.
C
B
C
B
C
A
A
C
C
C
And
I
think
the
faster
we
can
get
our
release
cycle
up
right
now.
The
better
we're
gonna
have
user
expectation
met
because
yeah
I
think
fast
release
at
this
point,
especially
for
bug
fixes,
is
critical.
So
that
sounds
good.
Do
you
think
you
can
address
this
today
because
I'm
happy
to
approve
things
I
think
we
could
get
it
out
today
or
is
this
something
that
you
probably
did
tomorrow.
B
I
I
will
do
my
best
to
get
it
up,
probably
will
take
about
two
hours
to
get
it
out.
Okay,
like
a
PR
and
everything
all
set
up,
I'm,
okay,
fast
tracking
it
I
would
like
somebody
to
double
check
that
we
didn't
miss
any
other,
go
mods
or
and
that
the
the
changelog
looks
right,
but
other
than
that
yeah
I'm,
fine,
skipping
a
24-hour
hold
to
get
that
out.
C
C
C
Yeah
yeah,
which
is
like
kind
of
the
standard
sync,
but
one
thing
that
I
did
realize
is
when
we
released
the
alpha,
SDK
and
contrib
we
removed,
or
we
added
a
bunch
of
views
to
the
go
SQL
the
the
Cassandra
instrumentation
to
essentially
deal
with
the
Prometheus
sanitization
of
names
that
we
could
probably
remove.
So
that'll
actually
be
a
code
modification
we
need
to
handle.
I
can
I
can
sync
with
you
on
that
Barrel
I'll
show
you
what
I'm
talking
about
afterwards
yeah.
B
C
Okay,
cool
awesome,
yeah,
I'm,
I'm,
really
excited
you
know,
I
I
think
I
used
to
be
really
disappointed
when
we
would
release
something
there's
a
bunch
of
bugs
that
came
in,
but
I
I.
Don't
know
why.
I'm
like
really
motivated
by
this
I,
really
think
that
we,
if
we
release
something
and
it
was
perfect
and
there
were
no
bugs
coming
in
one-
it
would
have
been
perfect,
which
I
doubt
or
two
nobody
would
be
using
it
so,
but.
B
C
There's
a
if
you're
following
the
slack
Channel
there's
a
good
recording
of
the
meeting.
I
think
Robert
posted
that's
worth
checking
out.
It
has
a
great
demo.
That's
like
both
Solutions
there
and
one
of
the
things
that
the
group
kind
of
came
to.
The
conclusion
on
was
that
the
source-based
instrumentation
is
more
closely
matched
to
writing
manual
instrumentation.
In
fact,
it
will
take
your
source
code
and
it
will
just
auto
update
things
by
parsing
the
syntax
tree,
and
you
can
then
check
in
that
code.
C
C
I
don't
know
if
the
answer
to
that
is
yes
for
either
of
these
currently
yeah
I
I
mean
the
answer
also
would
be
like
I,
don't
know.
If
there's
anybody
here,
that's
familiar
enough
with
this
solution
to
say,
like
it's
going
to
be
able
to
progress
right
off
of
that
without
some
onboarding
time,
but
yeah
I
think
I
think
that's
a
general
concern
that
we
have
for
both
groups.
What.
C
C
Where
you'll
run
your
code
in
the
Java
instrumentation
sits
alongside
within
the
the
run
time,
and
it
actually
annotates,
as
things
are
happening-
and
this
is
kind
of
more
in
line
with
the
EVPs
solution-
is
where
your
source
code
remains
your
source
code
and
you
run
it
just
like
normal
and
then
all
of
a
sudden
you
go.
Okay,
I
want
to
start
Auto
instrumenting
it,
and
then
we
provide
to
instrumentation
for
X
number
of
libraries
very
similar
to
the
Java
automation
rotation
group
where
they
provide.
C
Right
and
this
instrumentation,
the
source
code
modification
is
not
necessarily
in
that
same
vein,
like
I,
think
it
still
provides
instrumentation
for
your
code,
but
it
helps
you
generate
that
instrumentation
I
guess
is
a
better
way
to
think
about
it
so
similar
to
how
we
already
host
a
bunch
of
instrumentation
in
the
contrib
library.
This
would
essentially
be
a
tool
for
you
to
go
in
and
say,
like:
okay,
I
want
to
generate
my
own
here's,
a
great
launching,
Point,
it'll
annotate,
a
bunch
of
functions.
C
Here's
how
you
would
use
this
and
at
the
end
of
the
day
you
get
done
generating
the
code.
You
run
your
compile
and
you
look
back
at
your
source
code
and
go
like
yeah.
That's
what
I
want
and
you
check
it
back
in,
and
it
goes
so.
It's
not
like.
There's
an
auto
function
to
it.
There
was
a
talk
of
like
using
debug
symbols
in
there,
which
would
kind
of
sit
on
the
side
of
a
binary
which
it's
it's
not
the
case.
Currently.
B
The
the
way
it
works
right
now
is
it's
a
lot
closer
to
like
Stringer
here,
where
it
generates
something
it,
and
this
modifies
the
code
and
whatnot
so
sort
of
so
sorry
to
to
cut
off
your
question.
I,
don't
know
if
there's
a
good
reason
for
it,
but
my
my
one
concern
with
that
is
there's
differing
levels
of
like
how
you
get
things
accepted
into
contrib
versus
this
brand
new
Repository.
B
Is
there
any
kind
of
risk
that,
by
putting
it
in
contrib
that
it
might
slow
the
development
of
this
in
any
way,
shape
or
form
just
because
of
lack
of
reviews
or
or
these
stricter
requirements?
I'm
not
saying
that
it's
a
good
idea
or
not
I'm,
not
I'm,
not
too
sure.
Like
honestly
I,
don't
know
where
most
of
this
should
live.
C
F
Now
I
know
that
we're
trying
to
get
to
the
point
that
we
don't
make
breaking
changes,
but
just
I
think
we
all
know
here
that
in
the
past,
there's
been
some
burden
to
go
through
the
contrib
and
make
sure
that
it
all
still
works
before
we
can
update
its
dependency
on
the
API.
You
know
to
kind
of
move
them
all
in
lock
steps.
So
the
more
things
there
are
that
are
committed
to
contribute.
F
There's
this
burden
to
keep
them
up
to
date.
So
I'm
wondering
what
this
code
generator,
whether
enough
people
will
have
the
the
familiarity
to
go
in
and
update
it
if
need
be
like
if
it
needs
to
generate
different
code
in
order
to
keep
up
with
the
with
the
API
or
the
SDK,
because
if
that
falls
out
of
Step,
it
might
be
harder
to
tell,
because
you
likely
would
not
be
like
a
build,
wouldn't
likely
catch
that
problem.
You'd
be
building
the
tool.
C
C
We
already
have
a
lot
of
code
there
that
doesn't
really
have
clear
ownership
other
than
the
people
that
are
already
owning
the
that's
all
project
right
and
I
think
that
before
the
way
I
saw
it
I
wanted
to
say
this
was
like
before
we
move
this
source-based
instrumentation.
We
need
to
have
an
ownership
model
that
more
matches
the
open,
summary
collector,
contrib
repository
for
our
contrib
and
the
way
that
they
have
it.
There
is
essentially,
they
have
owner
files
in
wherever
the
contrib
library
is
and
they're
harsh
about
deprecation.
C
So
if
something
is
owned
by
somebody
and
they're,
not
responsive,
it
gets
deprecated
and
if
they're
still
not
responsive
it
gets
removed.
Eventually,
depending
on
you
know,
release
Cycles
and
I
think
that's
the
the
right
approach
here.
We've
tried
to
encourage
essentially
we've
we've
stopped
accepting
new
instrumentation,
because
we
tried
to
encourage
this
distributed
model
that
go
is
inherently
based
on
like
this
distributed
model
and
I
think
that
there
needs
to
be
a
really
good
motivation
to
try
to
include
something
into
contribute
because
you're
right,
it
adds
developer
burden.
C
I
think
this.
This
meets
the
case
as
it's
a
it's
solving
a
very
important
need
for
open,
Telemetry
customers
or
open
temperature
users,
in
that
they
don't
know
what
they're
doing
they
come
to
the
project
and
they
go
okay.
How
do
I
start
using
otel
I've
heard
you
know
this
is
really
cool,
let's
go
use
it
and
they
go
like
okay,
like
like
wow,
okay,
well,
I
gotta
go
like
set
up
all
this,
like
API
usage,
okay,
great.
Why
is
why
I'm
not
getting
expands?
Now?
C
Oh
I
gotta
set
up
this
SDK
like
all
of
this
extra
like
burden.
It
takes
them
an
hour,
maybe
more,
even
if
they
have
to
do
a
lot
of
learning
about
like
the
ecosystem
to
get
up
and
running,
and
this
tool
allows
them
to
go
like
oh,
okay.
This
is
a
great
starting
point,
run
it
and
then
I,
don't
know
what
this
does,
but
whatever
like
check
it
in
and
I'm
seeing
code
and
I'm,
seeing
traces
and
I'm
seeing
metrics
in
five
minutes
right
like
that,
I
think
is
so
valuable.
C
That
I
think
it's
a
great
thing
to
live
on
its
own,
but
it's
been
asked
to
be
included
in
the
in
the
hotels,
ecosystem
and
I.
Think
it's
valuable
there,
because
it
does
something.
It's
something
that
we
can
provide
as
an
open,
sell,
mature
group
to
say,
like
yeah,
here's,
a
really
good
ease
of
use.
It's
also
a
good
launching
Point.
C
Yeah
like,
if
you
want
to
then
build
your
instrumentation
from
that,
like
here's,
a
good
starting
point
like
it,
you
know
if
you
want
to
build
out
attributes
in
other
annotations,
so
I
think
I
think
there's
a
bar
that
it's
meeting
here
but
I
think
you're.
Both
right
like
we
need
a
clear
ownership
pattern
and
I
think
that
that
also
taryn's
Point
like
would
alleviate
the.
C
Staleness
of
of
contributions,
because
the
other
side
is,
if
you
have
you,
know
two
three
developers
who
are
actually
working
on
this
and
they're
just
sitting
there
waiting
for
reviews
or
they're
sitting
there
waiting
for
merges.
That's
not
a
good
look
either.
So
we
want
to
make
sure
that
they're
enabled
to
have
access
to
be
the
you
know
the
experts
on
this,
so
they
can,
if
their
reviews
are
there
like,
maybe
it
clears
at
a
different
policy
than
what
our
Global
policy
is.
C
I
think
that
these
are
all
things
that
are
really
important
and
we
should
probably
try
to
get
right,
not
necessarily
just
for
this
project,
but
also
I,
think
for
the
health
of
contrib
in
itself.
You
know
I,
think
I'm
only
going
to
wax
a
little
poetic
here,
but
like
the
the
exams
SQL,
this
rotation
is
a
great
example
of
like
how
I
really
want
things
to
to
work
like
it's
becoming
more
popular
people
can
find
it
in
the
registry.
C
Like
it's
a
well-known
like
thing,
if
that's
a
great
good
one,
it
sparked
a
bunch
of
other
instrumentation
libraries
where
people
decided
they
want
to
do
things
slightly
different,
really
so
there's
different
ideas.
Then
the
collaboration
came
like
there's.
A
really
good
I
think
open
source
Community
like
engagement
at
that
point.
D
I
I
think
whether
it's
in
instrumentation
or
country
is
I
mean
quite
important
for
just
few
arguments.
You
said
I
think
the
most
important
regarding
end
users
is
that
it
basically
just
has
a
an
understandable
go,
install
path,
which
is
definitely
doable
and
very
good
at
open
symmetry
domain,
and
that
can
also
change
repositories.
If
we
need
so
yeah.
I
just
think
the
most
important
for
users
is
that
it's
just
like
comprehensible,
but
when
they
install
it
what
they
install
to
run
VCR
afterwards.
C
C
Yeah,
that's
a
good
question,
essentially,
okay!
Well,
there's
a
lot
I
think,
there's
a
lot
of
really
good
questions
here
and
a
lot
of
really
good
things,
but
I
just
wanted
to
see
if
I
think
this
group
was
amenable
to
that
and
it
sounds
like
there's
some
barriers,
one
of
which
was
that
we
need
to
get
the
ownership
structure
of
contrib
done
correctly
beforehand
and
I.
Think
that
that's
something
that
I'll
include
in
the
discussion
of
where
these
things
should
live
for
the
Poetry
go.
Instrumentation
group
foreign.
D
Yes,
so
we
discussed
before
this
holidays.
I.
Think
sorry,
if
I
took
a
bit
of
time
to
because
of
the
summer.
Basically
we
used
to
run
benchmarks
in
GitHub
actions
and
we
disabled
them
because
of
nosy
neighbors
and
too
unreliable,
and
so
I've
been
actually
discussing
with
Joshua
about
getting
self-hosted
security
action.
Runners
organization-wise,
because
I
figured
that
who
could
be
useful
to
over
six
as
well
and
running
a
virtual
machine
all
the
time
just
because
we
have
something
to
run.
D
D
A
Sure
yeah,
we
could
put
a
link
to
the
comment
I
made
on
your
issue
in
the
community.
Repository
probably
would
help,
but
I
I,
think
security
was
more
of
a
like.
This
gives
an
opportunity
for
like
any
otel
user,
who
can
submit
a
PR
potentially
to
like
misbehave
I
guess
is
what
I'm
trying
to
say,
I.
Think
there's
like
an
actual
like
GitHub
is
responsible
for
its
Runners.
They
make
sure
that
you're
not
going
to
go
DDOS.
A
Somebody
for
example,
and
I
think
that
when
you're
using
self-hosted
Runners
you
take
that
on
responsibility
yourself.
That
was
the
type
of
concern
I
heard
when
someone
mentioned
security,
but
I
did
also
throw
in
there
that
Josh
surf
from
Google
feels
that
this
is
actually
a
beneficial
thing
to
have.
A
If
you
can
get
coverage
on
more
than
one
Cloud
environment,
we
could
actually
test
the
the
detectors
the
resource
detectors
for
AWS,
gcp
and
so
on,
which
is
about
valuable
and
real
and
valuable,
so
I
think
the
biggest
reason
we
pushed
back
I'm
speaking
as
one
of
six
or
seven
people
in
the
room
of
course
was
like
it's
a
lot
of
work.
To
imagine,
setting
up,
terraform
and
then
being
responsible
for
it
and
I
think
nobody
wants
to
set
up
step
up
to
do
that.
A
Org-Wide
I,
certainly
don't
want
to
step
up
to
do
that
for
this
repository
either
my
preference
with
benchmarks
I
was
sort
of
thinking
about
it,
because
there's
that
PR
about
fuse
turning
into
pointers
right
like
what's
what's
the
Benchmark,
that's
improving
if
I'm
changing
benchmarks,
I
like
to
just
do
a
before
and
after
in
my
PR
description
and
like
otherwise
I,
don't
expect
them
to
run
as
regression
tests,
mostly
because
I've
also
had
a
little
bit
of
experience
dabbling
in
micro,
Benchmark
Suites,
like
I've.
Looked
at
how
jmh
jmh
I
was
called
sweet.
A
Works
did
some
like
experiments
that
light
step
a
few
years
ago
about
benchmarking,
tracers,
like
realistically,
if
you're
trying
to
measure
garbage
collection
overhead,
like
benchmarking,
is
hard
and
I.
Don't
imagine
a
little
bit
of
effort
producing
a
like
correspondingly
little
bit
of
improvement
in
my
I.
Don't
know
security
of
benchmarking
or
something
I
don't
know
like
it
just
seems
like
it's,
not
a
good
reward
for
the
mouse
set
up,
so
I
didn't
want
to
do
the
work
either.
A
A
I
have
to
go
to
consultant
notes,
I
I,
think
tigan
joined
late,
so
I'm
not
sure.
Okay
was
bugged
in
there
or
not-
maybe
not
no
wait.
We
had
Everybody
by
the
end.
Okay,
I
don't
quite
know,
but
I
think
they
were
so
so
please,
my
my
pushback
I'm
conveying
the
pushback
from
the
group
I
I
kind
of
volunteered
to
take
this
on
for
Damien
I
think
that
it
wasn't
a
no.
If,
if
someone
was
like
I,
this
is
the
policy.
This
is
the
terraform.
A
This
is
how
we're
going
to
make
make
sure
it's
attended
to.
This
is
how
we're
going
to
make
sure
it
shuts
down
when
no
one's
attending
to
it
like
I,
don't
know
what
that
I,
don't
know
how
we
should
do
it.
Maybe
a
better.
A
more
complete
proposal
would
would
sway
people's
mind,
especially
if
it
got
us
that
test
coverage
for
the
resource
detectors
you're,
probably
right
that
it
should
be
shared
across
the
organization
but
I.
E
E
E
A
E
A
C
Does
it
have
YC
back
anyways,
so
I
think
it
there's
a
lot
of
options
here.
I
I
think
that
if
we
talk
to
the
collectors
I
know,
the
collector
also
does
regression
testing
for
like
benchmarks,
I'm
pretty
sure
it's
like
Tegan
runs
it
on
his
laptop
or
like
a
handful
of
people
running
on
their
laptop.
So
it's
kind
of
like
the
opposite
of
what
we
wanted
to
do
here
and
I.
Think
it
like
that
works
really
well
in
the
early
part.
C
I
do
remember
that
the
main
reason
why
we
wanted
these
benchmarks
is
like
as
the
product
matures
and
you're
providing
a
stable
solution.
Stability
also
kind
of
like
says
like
if
you
do
an
upgrade
and
there's
a
performance
hit
of
like
you
know,
50
like
that's,
not
a
great
look
and
so
like
having
that
understanding,
I
think
was
key.
I.
Think
Josh
is
right,
like
I.
Definitely
think
we
do
a
good
job
of
like
micro,
benchmarking
and
asking
if
you
have
a
change
set
like
to
identify
the
performance
improvements.
C
C
Maybe
I,
don't
know.
Okay,
I
think
I.
Think
there's
a
clearer
answer
here,
and
that
is
somebody
just
needs
to
take
charge
and
proposal
out.
I
know
Tegan's
really
good
at
this
kind
of
stuff,
but
if
you
can
just
put
a
proposal
that
addresses
all
the
concerns
of
the
TC
and
like
how
you
would
do
things,
I
think
that
we
could.
C
C
E
E
C
C
I
would
worry
about
like
the
long-term
viability,
just
I
guess
as
long
as
you
have
buy-in
from
The,
Collector
and
saying
like
yeah.
We
understand
like
this
may
not
be
the
long-term
solution,
but
I
think
this
can
go
forward
just
because
it
really
stink.
If
you
know
in
a
future
version
of
this,
this
isn't
stable.
We
would
remove
this
this
function
and
they
were
not
so
happy
about
that.
But
I
don't
think
that's
going
to
be
the
case.
C
C
Yeah,
so
that's
that
was
the
thing
that
kind
of
stuck
out
to
me
and
again
I
wanted
to
think
about
this
a
little
bit
more.
But
it
sounds
like
you
understand
what
my
thoughts
are
as
well,
so
I'll
try
to
form
those
into
a
review
comments
and
see
if
I
can
come
up
with
a
better
solution
or
something
to
address
the
issue.
C
A
I
wanted
to
ask
David
if,
if
pushing
us
back
hard,
could
help
us
get
out
of
this
situation.
I
know
that
we've
got
lightstep
Engineers,
pushing
on
actually
instrumenting
the
The
Collector
and
when
I,
when
one
of
our
you
you
some
of
you,
remember
Gustavo,
he
was
showing
me
his
like
proof
of
concept
that
he
could.
He
could
use
the
new
SDK
and
the
new
bridge
and
like,
but
it
was
broken
somehow
and
I.
A
So
I'm
not
I'm,
not
too
eager
to
see
it
happen
and
I
do
feel
very
supportive
of
the
spec
for
a
metric
producer
and
I
feel
like
if
the
right
path
is
to
just
approve
that
It's
like
got
approvals
right
now,
it
could
even
merge
I
think
and
then
we
would
just
be
waiting
for
a
spec
release,
but
sometimes
specs
change
and
you
and
you
worry
they're
going
to
get
backed
out
and
then
this
is
not.
One
I
worry
about.
Frankly,.
E
A
Actually,
I
I.
The
reason
I
asked
my
question
on
it
yesterday
is
that
I
think
it
has
all
the
approvals
and
there's
no
remaining
questions.
So
I
I
found
one
like
I
just
didn't
understand
the
sentence
and
you
I
think
you've
answered
it.
I
think
I
could
merge
it
today.
I
don't
see
a
reason
not
to
it's
been
approved
for
days
and
days
and
days
and
weeks
right
do.
E
A
It
be
called,
can
we
just
make
it
experimental?
Is
it
I
mean?
Maybe
that's
maybe
that's
what
it
needs
and
is
to
is
to
separate
and
put
experimental
labels
on
the
parts
and
then
I
think
the
question
is
back
to
Aaron
and
Tyler
like
and
how?
How
much?
How
much
are
you
willing
to
get
ahead
of
the
spec,
given
that
the
spec
is
practically
being
written
to?
Let
us
do
what
we're
talking
about
right
here
in
this
group.
B
So
my
question
was:
was
a
little
bit
different,
but
I'll
take
that
first
off
we
have
been
almost
burned
a
couple
times
here,
so
caution
is
warranted.
I
we're
still
so
far
in
the
alpha
phase.
That
I
would
prefer
not
like
I
would
prefer
not
to
break
users
if
we
can
so
like
I'm
I
have
just
general
concerns
about
adding
an
API
that
we
know
we're
going
to
remove
at
some
point
in
time.
B
In
general,
like
this,
the
approach
in
this
PR
just
from
the
get-go
but
I
have
like
maybe
give
Bogdan
a
week
or
two
to
to
come
back
and
see
no,
no
like
seriously.
In
all
seriousness
like
this
was
written
because
we
ran
into
this
issue.
It
is
a
defect
in
the
spec
that
that
I
think
everybody
kind
of
recognizes
like
yeah.
C
I
yeah
I,
agree,
I.
Think
getting
ahead
of
the
spec
with
the
the
new
reader
OC
bridge
is
something
I
know
that
we're
gonna
have
to
walk
back
well.
I
very
likely
have
to
walk
back
getting
ahead
of
the
spec
of
this
meter.
Producer
thing
or
a
metric
producer
thing,
I
think
there's
less
of
a
chance.
We
have
to
walk
it
back.
I
know,
David
already
had
a
proof
of
concept
for
it.
C
So
I
know
it's
possible
and
I
think
the
key
thing
is
unlocking
the
The
Collector
to
use.
This
is
a
very
big
win
for
us,
so,
like
the
risk
reward
seems
way
more
on
the
reward
side
of
getting
the
the
spec
merge,
so
I
yeah,
that's
where
I
stand!
I
I
would
be
fine
getting
ahead
of
spec
on
on
this
on
this
area.
Here.
B
E
A
I
I
wonder
if
that's
what
Gustavo
was
experiencing
when
I
was
so
confused
that
that's
that's
one
possibility
the
one
that
I
identified
was
more
like
currently,
but
I
think
we
we'd.
We
would
have
seen
a
log
message
about
it,
but
like
double
registration
of
a
reader,
so
that,
like
is,
is
something
that
the
spec
says
you
can't
do
and
the
the
SDK
will
handle
an
error
or
log.
A
An
error
I
can't
recall
which
yeah
and
and
then
move
past,
and
so
I
thought
that
might
be
what
was
he
was
doing,
but
I
also
was
super
confused
by
this
strange
arrangement
of
temporary
Bridges.
Let's
say
I
think
what
you've
also
answered.
My
question
that
three
of
you
have
answered
the
question
I
came
with,
which
was
maybe
we
should
double
check
with
bognan
on
this,
but
I
think
you
did.
You
did
a
prototype
and
and
I
feel
like
this
anyway.
A
E
Yeah,
it's
pretty
straightforward.
It
looks
a
little
weird
in
Java
because
their
batch
of
or
like
the
metrics
from
producers
are
going
to
include
resource.
So
they'll
have
to
somehow
rewrite
the
resource
they
get
back.
But
in
go
it's.
It
looks
really
nice
and
go
because
I'm
familiar
with
go
and
yeah.
C
C
E
C
E
B
C
A
Thank
you,
but
I
think
we
should
I.
I
know
that
getting
this
The
Collector
to
to
use
the
hotel
go
is
our
real
top
priority,
but
I
think
it's
a
mistake
to
go
with
this
impossible
to
understand
hack,
especially
because
I
know
the
people
who
are
working
on
getting
the
collector
instrument
with
Hotel
go
are
going
to
be
able
to
do
this.
A
B
Will
say
just
to
kind
of
save
this
I
think
a
kind
of
halfway
step
that
I
think
could
probably
enable
this.
The
The
Collector
to
do
a
hack
of
their
own
is
to
just
accept
readers
in
the
Prometheus.
And
yes,
you
do
have
the
problem
that
if
you
send
it
a
misconfigured
reader,
you
get
garbage,
and
but
you.
B
A
So
then,
I
think
this
is
a
great
idea.
Can
I
just
check
if
I
understood
it,
so
that
makes
it
sound
to
me
like
injecting
a
bridge
is
really
just
a
reader
transformation.
So
I
give
you
some
readers.
You
want
to
put
a
bridge
in
there.
You
just
like
wrap
the
reader
wrap.
The
click
call
add
some
data
to
the
output
or
something
like
that.
C
C
But
I
think
I
think
you
could
actually
because
you're
kind
of
talking
about
wrapping
a
reader,
you
could
actually
abstract
both
of
those
methods
that
give
back
temporality
to
always
say
Delta,
or
that
always
say
cumulative
but
like
yeah
again
like
this
is
all
the
things
that
I
was
thinking
about
and
I.
Don't
know
if
that's
a
really
great
idea,
because
then
you're
having
the
users
essentially
like
asking
for
Delta
that
never
will
give
them,
but
he
doesn't
understand
why
so
then
like
what's
like,
there's
a
lot
of
like
confusion
that
gets
included
there.
E
Ahead,
David
I
actually
have
an
idea.
I
think
might
fix
this,
which
is
that
the
Prometheus
exporter
can
take
a
its
own
reader.
That
only
has
a
collect
function,
create
a
manual
reader
itself
and
then
basically
perform
the
bridging
but
perform
the
combination
of
the
two
metrics
in
the
exporter,
which
would
prevent
the
foot
gun
scenario.
E
C
E
That
no
it
it
can't
so
this
this
reader
won't
have
aggregation
right
like
this
thing
that
you
can
pass
into
it,
wouldn't
be
able
to
configure
aggregation,
it
would
just
be
able
to
provide
metrics
and
then
it
still
creates
a
manual
reader
and
then
we're
just
the
two
sets
of
metrics
yeah.
Okay
and
it
owns
the
manual
reader.
C
One
of
the
other
things
that
I
thought
of
was
you
could
have
the
new
function
for
the
Prometheus
exporter.
Give
you
something
really
nice
and
user
friendly,
but
then
also
like
expose
the
underlying
reader.
It
uses
as
like
the
struct.
So
like
anybody
like
who
wants
to
go
above
and
beyond
and
like
shoot
themselves
in
the
foot
you
could,
you
know
directly
configure
a
struct
versus
like
the
general
user
would
just
use
the
new
function.
C
E
E
I'll
I'll
give
it
till
the
end
of
the
week
to
see
if
we
can
at
least
get
bogged
and
on
board.
If
we
have
bogged
and
on
board,
then
I
feel
confident
that
we'll
likely
be
able
to
push
it
forward
and
I'll
propose
a
PR
to
implement
it
ahead
of
the
spec
and
go
if
there's
still
disagreement
by
next
week.
I
think
it
might
be
best
to
try
and
go
with
something
temporary
but
hopefully
less
bad
than
what
I
proposed
today.