►
From YouTube: 2023-03-02 meeting
Description
Instrumentation: Messaging
A
Oh
yeah
yeah
that
happens,
yeah
we're
on
vacation
or
just
busy.
B
B
A
D
A
No,
no
I
think
we're
just
waiting
for
Quorum
looks
like
we
have
it,
so
we
could
probably
just
jump
in
here.
Sorry
I'm
turn
off
notifications
and
stuff.
So
yeah,
if
you
haven't
already
welcome
everyone,
please
add
yourself
to
the
attendees
list
and
if
you
have
something
you
want
to
talk
about,
please
add
to
the
agenda:
I
will
start
sharing
my
screen.
Here's
a
second.
A
Okay,
cool
start
us
off
talk
about
the
release
candidate.
We
just
got
out
I,
think
I.
Think
this
morning,
yeah
I
think
it
yeah
two
hours
ago.
Okay,
it's
been
a
long
day
already
so
yeah.
This
is
a
good
one.
It's
a
release
candidate
for
1.15
and
then
also
has
a
metrics
release,
but
this
includes
the
metrics
API
in
the
stable
release
or
the
stable
1.0
modules.
So
this
is
I
think
the
next
step
in
in
the
metrics
release
pipeline.
So
it's
a
celebration.
F
A
Definitely
want
to
pause,
and
just
say
thanks
to
everyone
who
got
us
here
us
thinking
about
it.
The
other
day,
like
I,
think
when
I
started
working
at
open
symmetry
back
in
like
2019
I,
was
working
on
metrics
and
the
specifications.
So
it's
been
a
long
road
yeah,
so
yeah
I
think
it's
it's
worth
celebrating
to
get
to
this
point.
We
still
have
ways
to
go,
but
yeah
I
think
it's
worth
celebrating
your
milestones.
A
Cool
with
that
said,
I
think
that
if
you
have
a
company
that
uses
the
metrics,
API
or
instrumentation
in
your
own
projects,
updating
to
this
release
candidate
and
getting
any
sort
of
feedback
to
the
project
would
be
great.
I,
don't
know
what
our
timeline
is
for.
How
long
we
want
to
wait
before
we
make
a
full
release.
So
imagine
it's
probably
more
than
a
week
but
I
think
that's
kind
of
up
to
the
project.
So
you
know
hopefully
within
a
week
or
two
you
can
get
back.
A
If
there's
no
issues
there
shouldn't
be,
we've
thought
a
lot
about
it,
but
you
know
I,
don't
know
what
I
don't
know.
So
that's
also
something
to
keep
in
mind.
A
Yeah
I'm
kind
of
in
the
same
boat
I
think
that
we
were
like
20
days
out
between
the
last
two
releases,
so
I
I,
don't
I,
don't
know.
I
I,
don't
see
a
big
impetus
to
to
not
release
this
so
I
I,
don't
know
I'm
I'm
open
to
hear
what
people
think
on
timeline
for
this
release
candidate
would
be.
F
D
A
Good
so
yeah,
if
you
have
some
ideas
for
improvements
for
issues
that
you
find
please
get
back
to
us
within
two
weeks,
so
yeah,
okay,
cool
next
up,
I,
wanted
to
ask
a
question.
So
this
last
release
that
we
did
the
114
one
or
zero
38
release.
A
It
looks
like
the
project
might
actually
have
made
the
Beta
release.
Successful
I,
think
that
was
the
intent,
but
I
just
wanted
to
kind
of
double
check
with
the
community
and
see
what
we
think
on
this
one.
A
A
Yeah
yeah
I
think
I
think
we
can
close
it.
This
also
needs
to
get
updated
the
project
status
and
then
otherwise.
I
think
that
we
could
say
that
that
release
was
the
Beta
release,
maybe
Aaron
I
know
you
talked
to
us
about
some
language.
We
could
update
the
release
itself
to
say
that
this
also
included
the
Beta
release.
D
A
D
A
Yeah
yeah:
let's
see
if
it
just
figures
out
really
quick.
A
Okay
status
yeah
here
we.
D
F
Actually,
this
is
in
our
repo.
This
may
be
okay,
I
think
the
issue
I
had
was,
for
some
reason,
the
GitHub
actions
workflows
in
the
the
website,
repo
weren't,
working
correctly
on
on
a
pure
that
I
made
to
change
like
one
word
and
some
markdown
so.
A
A
I
don't
know
if
it
is
I'm
looking
at
this
content
and
there's
nothing
that
stands
out
as
saying
what
our
status
is
here.
I,
don't
know
where
that's
actually
being
set
okay,
but
I
think
that
we
have
a
good
starting
point.
At
least
we'll
include
here,
I.
B
A
Okay,
so
this
looks
like
this
all
needs
to
get
put
into
an
issue
Aaron.
You
would
raise
your
hand
that
you're
willing
to
close
it.
Are
you
willing
to
create
an
issue
to
track
all
this.
A
A
Okay,
cool
awesome.
Well,
that's
also
doubly
exciting.
Then
we
have
the
beta
out
for
the
SDK
alpha
or
RC
for
the
API.
So
metrics
is
coming
along
one
of
the
kind
of
touch
base
on
just
like
next
steps
for
the
SDK
ga
I
think
we
built
this
out
a
little
while
ago.
It's
the
project
board
for
the
metrics
SDK
GA.
It's
still
needs
something
similar
I
think
to
what
we
did
for
the
API.
So
it's
more
fields
and
then
once
that's
done,
we
can
start
working
down
this
backlog.
A
There's
fair
amount
of
just
verification
issues
here,
in
fact,
I
think
it
might
only
be
verification
issues.
Let
me
document
the
public
interfaces,
which
has
an
assignee
TC
review.
Debug
logging
is
also
on
here
in
this
memory
leak.
This
memory
leak
I
think
we
determined
that
it's
coming
from
some
conf
and
using
this
net
peer
attribute
is
actually
being
encoded
in
metrics.
So
I
don't
know
if
this
should
block
our
metrics
SDK
GA,
given
it's
not
actually
so.
Actually
let
me
just
pull
this
out
of
here.
I,
don't
think
this.
A
To
fix
the
semcom
stuff,
so
I'll
keep
it
in
the
Milestone,
but
I
don't
think
it's
actually
blocking
the
SDK,
but
yeah
the
debug
walking
as
well
I
know
Aaron.
You
also
commented
on
this
one
I
don't
know
if
this
should
block
the
ga
release
here.
I
think
it's
important
but
I'm
open
to
suggestions
on
whether
we
want
to
wait
to
have
this
done
before
we
go.
Ga
with
our
SDK
I
think
this
sounds
good
by
the
way
Aaron.
E
E
I'd
be
hesitant
to
have
nothing
there,
just
because
it's
hard
to
tell
what's
going
on.
E
A
When
I
was
tracking
down
that,
like
multiple
readers,
not
exporting
thing
like
I,
essentially
added
a
debug,
so
this
is
why
I
created
the
issue,
because
I
was
like
it'd,
be
really
nice
to
know
when
you
set
this
thing
up
like.
What's
it
actually
doing
so,
I
I,
agree,
I,
think
having
something
and
I
don't
think
it's
going
to
take
too
much
given
how
long
the
other
debug
log
can
be
set
in
okay.
So
we'll
include
it
here:
okay,.
E
Yeah,
like
honestly,
I
think
the
majority
of
the
work
is
adding
some
export
or
the
the
formatting
functions.
A
Yeah
I
agree:
the
the
reader
configuration
was
a
little
bit
harder
because
there's
like
spelling
out
like
what
exporters
are
there
as
well,
but
it's
not
impossible.
It's
it's
pretty
straightforward,
okay,
so
yeah
I
think
we'll
keep
that
there
so
okay
other
than
that
I
think
it's
just
verification.
So
that's
kind
of
my
plan
for
the
next
week,
oh
and
then
there's
this
this
one
as
well.
A
The
docs
there's
like
a
framework
for
what
is
expected
for
we
want
to
include
for
the
metrics
SDK
this
again
similar
to
like
the
debugging
log.
This
is
probably
useful,
not
useful.
This
is
kind
of
high
on
the
usability
side
of
things
so
having
something
for
users.
I
think
is
pretty
important
when
we
go
for
a
ga.
What
are
other
people's
thoughts
on
having
this
for
the
Metro
SDK
ga.
E
We
need
to
have
some
minimal
documentation
of
how
to
use
the
thing.
I
don't
know
if
we
need
the
full
filled
out
stuff,
but
we
need.
We
need
something
like
I
think.
A
Okay,
cool,
then
we'll
keep
it
in
the
this
project
other
than
that
these
verification
tasks
are
really
high
level,
just
breaking
those
sections.
So
that's
how
I
did
in
the
past,
so
it's
hopefully
parallelizable
but
other
than
that
I,
don't
think
we
need
to
go
through
too
many
of
these
reviewing
them.
E
Are
three
things
that
I
can
think
of
off
the
top
of
my
head
from
the
specs
that
aren't
solidified?
Yet,
but
do
we
want
to
spend
a
little
bit
of
Cycles
to
like
get
an
opinion
on
specifically
the
Overflow
mechanism
that
was
proposed
for
if
there's
too
many.
E
The
capacity
limit,
the
hints
API
that
gets
brandied
around
every
once
in
a
while,
specifically
for
making
for
having
instrumenters,
be
able
to
recommend
a.
B
E
And
then
the
third
thing
that
I
would
say
is:
do
we
want
to
try?
Do
we
need
to
get
some
kind
of
experiment
on
like
capping
memory
usage
so
somehow
introducing
forgetting
into
the
cumulative
exporters.
A
So
our
previous
conversations
have
said
no
that
we
didn't
want
to
do
memory
optimizations
before
we
did
this,
especially
it's
just
the
thing
that
we
didn't
want
to
do
is
release
it
and
then
realize
memory
optimizations
were
needed
with
an
API
change,
but.
A
That
issue
we've
actually
gone
through
and
we've
made
sure
that,
like
we
should
be
able
to
address
those,
the
forgetting
I
think
is
something
that
I
definitely
don't
feel
comfortable,
including
a
solution
for
it
without
guidance
from
the
SDK
or
from
the
specification
just
because
you
know
that
is
that
conversation,
if
you
go
look
at,
has
taken
a
lot
of
different
approaches
like
you
know
whether
it's
cycle
based
whether
it's
its
own
API,
whether
it's
you
know
I,
don't
know,
there's
all
kinds
of
different
solutions
there.
A
You
know
a
dedicated
instrument
to
like
you
know,
remove
things
so
that
one
I
think
I'm
a
little
bit
like
more
skeptical
about
trying
to
introduce
now
but
I
I
I
do
like
David's
approach.
He's
he's
on
leave
at
this
point,
but
you
know
he
said
like
especially
for
asynchronous
instruments
like
just
drop
them
the
moment.
They're,
not
there
I
think
that
that's
a
great
solution
for
like
90,
maybe
80
of
all
use
cases,
because
that
also
gets
us
to
the
point.
A
A
But
you
know
for
for
all
the
other
asynchronous
instruments
you
can
kind
of
mock
out
something
that
could
forget
so
again
like
that's
another
reason
why
I'm
like
I,
don't
know,
there's
a
lot
of
different
solutions
here,
so
I
think
there's
some
good
ideas,
but
until
like
the
specification
says
that,
like
we
need
to
be
dropping
cumulative
things,
I
think
that
are
are
set
up
for
the
SDK
is
set
up
so
that
we
can
do
it
on
cycle
based
if
it's
going
to
be
a
dedicated,
API
I.
A
Think
that,
like
we'll,
have
to
look
at
that
when
it
comes
out
I
guess
because
that
would
come
through
I
think
it's
just
going
to
be
an
SDK
API,
I
guess
right.
E
A
A
Yeah
I
don't
know
either
that's
a
good
question:
okay,
but
then
for
the
the
hints,
API
I
think
that's
also
another
one
where
so
the
big
part
of
the
hints
API
is
in
the
API
itself
right.
So
that's
going
to
be
some
like
I
see
that
as
an
option
that
you're
going
to
pass
during
instrument
creation
using
the
open,
sloucher
API
right
so
I
I
would
see
that,
as
as
an
option
to
like
history
and
creation
right.
A
B
E
But
that's
that's
not
what
the
hints
API
is
intending
to
do
at
least
not
my
understanding
of
it.
A
F
E
F
E
A
So
intentionally
like
the
hints
API
was
initially
for
histogram
buckets,
but
I.
Don't
think
that
that
was
the
oh,
like
the
long-term
ultimate
conclusion
right
like
it
was
supposed
to
be
applicable
to
all
instruments,
I
think
in
in
the
in
my
understanding
of
that
right,
like.
A
E
Yeah
and
like
I,
don't
even
think
they've
scratched
the
surface
of
what
happens
to
the
hints
API.
If
you
have
some
kind
of
view
transform
or
you
combine
different
instruments
like.
A
E
A
Yeah,
so
so
I
think
that
that
kind
of,
like.
A
That's
a
good
point,
so
I
think
to
Anthony's
point
though
it's
like
you
know,
if
you
did
have
a
hints
API
that,
like
you,
wanted
to
just
pass
to
all
instruments
could
become
a
histogram.
We
might.
E
Satisfy
our
option
structure
right,
my
real
want
from
us
is
just
to
try
and
generate
some
kind
of
idea
of
what
we
can
do
like
what
is
possible,
what
isn't
possible
so
that
when
we
discuss
it
at
the
specification
levels,
if
they
come
back
and
say
no,
no,
we
need
an
extra
parameter
or
you
know
something
that's
kind
of
Off
the
Wall,
where,
like
we
have
the
the
research
that
we've
done.
That
says
no,
that
that's
not
going
to
work
without
breaking,
go
or
or
something
like
that
or
we
could
do
it
and
go.
E
A
Yeah
I
expect
the
hints
API
is
one
of
those
ones
where
they're
going
to
have
proposals
that
require
some
sort
of
like
group
of
concept
as
well.
So
I
could
see
that
happening
there.
A
In
my
opinion,
I
don't
know
if
it's
going
to
include
a
selector,
because
it
already
is
kind
of
being
selected
by
the
instrument
you're
passing
it
to,
but
it
would
include
you
know
hints
as
to
like
all
of
the
the
output
parameters
that
it
could
contain
and
so
I
don't
know
I
like
I,
see
in
my
situ
like.
If
you
take
that
situation,
and
then
you
know
you
are
providing
a
a
histogram
bucket
hint
to
a
counter.
It's
like
okay.
A
At
some
point,
the
user
needs
to
kind
of
understand
that
what
they're
saying
is
maybe
not
necessarily
useful,
but
also
like
to
Anthony's
point.
If
later
on,
there's
a
view
that
transforms
that
to
be
a
histogram,
then
the
hint
would
actually
apply.
And
so
then
you
don't
know
it
seemed
like
it
seemed
like.
That
seems
seems
fine,
because.
A
You
can't
apply
currently
a
histogram
aggregation
to
something
that's
asynchronous
as
far
as
I'm
concerned.
A
I
might
be
wrong
on
that
one,
but
if
that's
the
case
then
like
having
that
partition
that
we
already
have
across
synchronous
and
asynchronous
instruments
is
seems
like
a
natural
boundary
yeah
I
mean
this
is
something
that
I
was
thinking
about.
When
we
were
partitioning
up
the
instrument
options,
it's
like
do.
We
want
instrument
options
per
instrument,
or
do
we
want
it
to
be
founded
on
the
synchronic
asynchronous?
E
A
Other
ones:
well,
they
have
a
builder
where
they
have
key
value
options
that
can
always
extend
a
function
like
their
function.
Signatures
aren't
static,
yeah
or
they
can
override
methods.
So
they
can,
you
know,
have
multiple
different
signatures
for
the
same
function
or
I'm,
sorry,
the
same
method.
A
So
these
are
all
shortcomings,
I,
think
of
well.
Shortcomings
depends
on
how
you
define
shortcomings
if
they
go
programming,
language,
creative
and
so
yeah,
yeah
constraints,
that's
the
right,
word,
yeah
and
so
I
think
that
they
don't
necessarily
have
to
deal
with
this
problem.
As
as
we
do.
A
Yeah
so
I
think
the
thing
that
I'm
kind
of
thinking
back
on
with,
like
you
know
how
far,
how
do
we
want
to
partition
our
options
right
now
and
do
we
want
to
go
down
to
instrument
level?
I
do
remember
this
also
the
same
conversation
for
the
spanned
start
options
and
the
span
and
options.
Originally,
we
had
it
as
a
single
span
option
and
before
the
release,
we
separated
them
based
on
feedback
from
the
open
census.
A
People
just
saying
that
you
know
like
this
was
a
mistake
that
they
made
in
in
their
release
and
having
the
span
option,
be
a
single
type.
A
Stay
tuned,
yeah,
exactly
and
so
I
think
that
kind
of
comes
back
like
did
we
foresee
in
the
future
our
API.
So
the
problem,
the
problem
also
like
just
to
point
it
out,
is
like
if
we
do
split
up
our
instrument
options
further
like
that
means,
there's
going
to
be
eight
different
instrument
options,
there's
gonna
probably
be
two
more
one
for
asynchronous
one
for
synchronous
and
then
a
third
for
all
instruments.
A
Right,
like
the
instrument
option
of
like
I,
think
with
unit
is,
is
an
instrument
option
right
now,
so
I
mean
there's
like
gonna,
be
like
11
different
options
there
that
a
user
has
to
read
through
the
docs
to
figure
out
which
one
they
can
actually
pass.
A
You
know
because,
like
passing
a
direct
instrument,
option
seems
pretty
straightforward.
We
probably
won't
have
any
because
there's
nothing
specific
to
instruments
at
this
point,
so
they
have
to
realize
that,
like
you
know
a
with
synchronous,
counter,
I,
don't
know
what
the
name
is
but
like
with
synchronous.
Counter
instrument
option
is
also
a
synchronous
option,
which
is
also
an
instrument
option
and
you
could
pass.
A
A
A
You
know
like
the
option,
parameters
that
you
accept
also
include
some
sort
of
like
typed
implementation
of
a
hint
so
like
you
could
provide
a
hint
and
a
hint,
maybe
as
an
interface
and
then
there's
a
histogram
hint
and
then
there's
a
a
counter
hint
or
something
like
that.
Like
can
you
structure
your
options,
I
think
around
that
to
try
to
address
I
mean
the
problem
there
is
that,
like
you're,
not
going
to
have
compile
time
checks
that
you're
passing
you
know
the
appropriate
things
at
the
appropriate
places.
A
Yeah
I
I
do
think
that
for
the
hints
API
we
could
solve
this
like
based
on
what
we
just
kind
of
talked
about,
like
I,
think
that's
a
fine
Edge
case
in
saying
that
if
you
pass
a
hints
API
to
set
the
buckets
of
a
counter,
that's
on
you
like.
Maybe
you
want
to
do
that?
Maybe
you
know
like
that,
makes
sense
to
you,
but.
E
I
mean
at
the
specification
level
you
could
say
you
could
just
say
something
along
the
lines
of
any
options
that
are
passed
that
are
not
apply.
Build
to
a
to
the
current
either
instrument
or
aggregation
are,
are
ignored
right,
but
yeah.
A
I
mean
I
think
that's
exactly
I
think
that
was
Riley's
Point
as
well.
In
that
conversation
was
just
like
hints.
Api
are
not
like
a
not
like
a
view
where
it's
going
to
be
applied.
It's
a
hint
right,
it's
something!
It's
a
suggestion.
It's
not
necessarily
like
the
resolution
path
of
that
hint
is
not
going
to
explicitly
always
be
followed.
I
think.
A
I
don't
know
so
based
on
this
conversation,
I
think
our
current
option
structure
does
make
sense
and
I
probably
wouldn't
recommend
changing
it,
but
if
others
think
otherwise
I
think
if
somebody
wants
to
take
some
time
to
think
about
the
aidance
API
I
haven't
looking
at
the
PR,
but
it
isn't
it
isn't
that
fully
fleshed
out
yet
I
think
as
well.
So
we're
we're
thinking
about
the
next
issue
that
Aaron
brought
up
was
the
setting
capacity.
I.
A
Think
that's
also
something
that,
since
it's
going
to
be
defined
at
the
meter
provider
level
like
it's
again
like,
we
can
add
an
option
there
I
think
I,
don't
think
that's
going
to
be
too
hard.
The
implementation
is
all
going
to
be
internal
to
the
SDK.
So
I
think
that
that's
again,
like
I,
don't
think
our
API
to
the
SDK
is
going
to
change
so
I
think
that's
something
we
could
probably
one
time
until
it's
defined
in
the
specification.
E
A
A
C
Hello,
yeah,
I
I've
started
working
on
adding
Go
Auto
instrumentation
to
the
operator
and
as
part
of
that
work,
I
wanted
to
use
an
official
open,
Telemetry
image
instead
of
the
key
value
image.
C
So
I've
opened
a
PR
to
add,
essentially
releases
workflow
to
that
go.
Auto
instrumentation
repo,
like
shamelessly,
stolen
from
the
key
Val
release,
but
since
everyone
here
I
think,
is
any
maintainer
on
the
go
repos
and
maintainer
on
this
I
wanted
to.
You
know,
bring
this
to
all
of
your
attention
and,
most
importantly,
ask
you
to
name
the
image
or
at
least
sign
off
on
the
name
of
an
image
if
you're
willing
to
have
an
image
at
all.
A
Okay,
so
this
creates
a
Docker
image
as
a
release.
C
Yeah,
so
as
the
original
key
vowel
repo,
which
was
was
donated
as
part
of
their
release
process,
they
they
push
and
they
build
and
push
an
image
to
Docker,
hub,
Eden
or
Ed
and
I'm
not
sure
how
he
prefers
to
be
called,
but
he
has
worked
through
tigrin
and
gotten
the
docker
credentials
and
stuff
added
to
this
repository,
and
so
it's
ready
to
go
in
theory.
I
can't
test
it,
of
course,
and
the
question
is
stolen
or
borrowed.
C
There's,
there's
is
open
source
and
so
we're
we're
taking
their
open
source
code
and
using
it
in
our
open
source
code,
and
he
has
a
signed
off
on
that.
And
so
the
big
question
is:
is
the
maintainers
of
this
repository
willing
to
maintain
an
image?
I
noticed
that
the
other
Auto
instrumentation,
like
figs,
don't
have
their
own
images
like
the
Java
agent
the.net
agent?
They
don't
have
their
own
I,
don't
even
know
the.net
likes
being
called
an
agent,
but
they
don't
they
don't
produce
their
own
images.
C
My
understanding
is
that
the
go
ones
is
special.
It's
got
that
offsets
file,
it's
doing
ebpf.
It's
got
a
launcher.
It's
got
all
this
extra
stuff,
it's
not
run
as
an
in
a
container.
It's
run
as
a
sidecar
in
the
operator.
So
like
there's
a
lot
of
good
reasons
to
have
an
image
and
I
wanted
to
get
sign
off
from
the
maintainers
that
yes,
you're,
willing
to
publish
an
image,
and
if
you
are
willing
to
publish
an
image.
What
would
you
like
that
image
to
be
named.
A
Yeah
there's
a
lot
of
questions
there.
So
I
would
definitely
I'm
just
gonna
say
like
I,
don't
think
we
should
make
a
decision
in
this
sig
meeting
call.
We
should
probably
wait
till
next
Tuesday
when
the
auto
importation
per
go.
Sig
needs
because
I'd
want
opinions
from
the
the
community.
There.
A
A
Yeah
it's
new
and
it's
it's
small
Aaron
and
I
generally
go
there
as
well.
So
you
have
you
have
two
of
the
maintainers
here
but
I
think
if
that's
like
something,
I
I,
don't
see
a
problem
with
it,
but
I
would
want
input
from
that
Community
before
we
did
something.
A
C
A
Yeah,
it's
it's
not
it's
like
I,
said
new,
so
I
wouldn't
expect
everyone
to
know
about
it.
It
is
also
every
two
weeks,
so
it
didn't
happen
this
week,
but
yeah.
Let's,
let's
talk
about
that
I
mean
what
you
have
here
seems
reasonable,
so
yeah
I
think
if
that
sounds
good
I.
C
A
Ok
Okay
I
think
I
should
be
there
and
then,
if
not
Aaron's
should
be
there
and
then,
if
not
so
we
could
talk
about
it
there
as
well.
I.
F
A
Okay
cool,
so
it
was
useful
bringing
it
up
here.
Okay,
next
up
on
the
agenda
Anthony,
it
looks
like
you
have
a
question
about
it.
F
Yeah,
so
so
there's
been
some
renewed
discussion
on
this
PR
or
this.
This
issue
I
think
it
goes
back
a
ways,
but
recent.
F
This
I'm
trying
to
understand
why
the
the.
A
Yeah,
okay,
so
the
HTTP
client
obviously
uses
protobuf
to
encode
its
payload
right,
and
so
it
needs
access
to
the
I.
Think
it's
Proto.
A
Yeah
Proto
go
projects
and
this
oclp
project
here
it
needs
a
dependency
on
grpc
that
dependency
comes
from
this
being
a
part
of
the
pack
or
the
module,
and
specifically
this
export
service.
E
The
fundamentals
is
to
because
the
service
is
also
defined
at
the
same
place,
that
the
message
is
defined,
that
the
service
is
used.
It's
the
way
it's
generated
in,
go
either
currently
and
I.
Think
I
I
think
I
tried
a
couple
different
ways
to
get
it
to
not
generate
there's
going
to
end
up
with
a
grpc
dependency
right
yeah.
So
so
we
could.
We
could
generate
everything
up
to
the
message.
A
Yeah
so
here
it
defines
the
client
as
well
as
the
the
message
in
the
same
package,
and
so
this
is
where
the
grpc
dependency
comes
from,
and
there
is
a
way
yeah
as
Aaron's
pointing
out
is
you
can
specify
to
not
generate
the
service,
and
so
what
we
could
do
is
we
could
then
split
up
this
otlp
module
and
the
module
can
be
broken
into
the
client
and
the
message.
So
the
collector
would
have
the
message
here
and
then
in
another
one
it
could
have
the
the
client.
A
A
So
you
run
into
this
situation
where,
like
there's,
it's
a
nasty
Edge
case,
but
it's
required
because
we
generate
the
Proto
using
the
standard
definition,
and
so
it
generates
the
service
for
the
grpc
service
as
well.
In
the
same
Library.
A
So
well
that
and
also
keep
in
mind,
you
have
to
split
up
the
configuration
options
because
currently
they
share
the
same
package
and
that
package
I
mean
that's,
that's
something
we
could
do
in
fact,
I
think
both
Aaron
and
I
have
tried
doing
it,
but
It
ultimately
comes
back
down
to
this.
Where
this
this
repository
would
need
to
get
restructured
and
and
I
think
that's
the
that's.
A
The
Crux
of
the
argument
here
and
I
think
that
there
is
a
way
to
use
the
tooling
to
not
generate
the
service,
and
then
maybe
we
could
set
up
a
different
I,
don't
know
actually
where
it
would
be
set
up.
If
there's
like
a
sub
module
here,
that
would
have
a
different
service,
but
like
it
would
need
to
get
split.
Here
is
the
dependency
issue.
Does
that
make
sense?
Anthony
I.
A
Yeah,
it's
it's
I,
don't
I,
don't
like
I'm,
not
I,
don't
know!
I,
look
at
this
and
I
say
like
this
is
adding.
A
This
is
adding
overhead
I
think
in
binary
size,
but
it
also
is
like.
Is
this
doing
the
same
thing
for
all
go
compilers
like?
Does
the
tiny
go?
Compiler
also
have
this
dependency
issue
going
to
be
solved
in
that
way,
because
I
feel,
like
ninety
percent
of
the
use
cases,
don't
care
about
this
like
a
binary
size,
that's
I,
don't
know.
A
Five
megabytes
bigger
doesn't
make
a
difference
whether
you
know
like
if
it's,
if
it's
a
full
gig,
maybe
but
like
at
this
at
this
size,
it's
not
a
big
deal
and
for
users
that
it
does
make
a
difference
like.
Is
there
a
different
compilation
option
for
them
that
could
actually
resolve
this
issue
without
actually
having
to
change
the
code
base
is
also
something
I
think
it
could
be
looked
into.
F
F
A
So
it
doesn't
that
I
can
tell
you,
I
I
did
validate
that
yeah
I
I
did
split
it
and
then
I
tried
rebuilding
it.
I
still
have
symbols
from
grpc
included.
A
I
I
can't
say
that
that
was
like,
like
pre-18,
that
I
validated
this
so
like
it
may
have
changed
so
I
guess
we
could.
It
could
be
another
exercise
to
try
it
again,
but
I
would
be
surprised.
You
know.
I
also
know
that,
like
you
know,
Robert
has
done
this
in
the
past
as
well.
Where
he's
looked
at
like
testing
symbols
are
included
in
the
binary.
A
Those
aren't
used
in
in
the
runtime
right
like
so
like
I
I
mean
like
there's.
Definitely
something
like
the
go.
Compiler
I
think
has
a
lot
of
optimizations
for
binary
size
that
aren't
included,
but
yeah
I,
just
don't
think
they're
the
default.
E
The
other
thing
that
I've
was
looking
at
this
morning
was
because
of
how
we've
structured
it.
We
also
have
something
similar
and
related
in
that
we
from
the
like
Hotel
http.
E
It
actually
calls
into
the
the
hotel
or
hotel
Trace
internal
packages,
and
that
actually
exposes
this
kind
of
semi-public
API.
That
will
break
things
if
we,
if
we
make
breaking
changes
in
it.
So
you
can't
just
have
non-breaking
changes
in
the
internal
package
or
you
can't
have.
A
Yeah,
that's
a
that's
a
good
thing
to
talk
about
because
you're
talking
about
the
issue
where
there's
incompatibility
between
like
zero,
eleven
one
and
zero
eleven
two
and
that's
that's
an
issue
so
I
I,
don't
know!
That's
not
like.
That
is
a
compatibility
issue
across
packages
right.
It's
it's!
Definitely
it's
something
where
one
package
may
become
incompatible.
If
you
don't
do
upgrades
across
the
whole
thing,
I
I
definitely
remember:
I
I
couldn't
find
it,
but
I
definitely
remember
when
we
were
talking
about
versioning
stability
at
the
specification
level.
A
Having
this
rolling
forward,
versioning
policy
was
something
that
I,
remember.
Ted
saying
is
something
we
want
to
do
or
to
support.
A
You
know
saying
that,
like
yeah
like
seeing
exactly
what
what
happened
so
like
the
the
zero
eleven
one
is
not
necessarily
guaranteed
to
be
compatible
with
zero
11,
you
know
two
of
another
package
like
there's:
there's
no
compatibility
guarantee
that
the
specification
level
that
being
said,
I
I,
am
also
seeing
a
proposal
from
Robert
and
Anthony's
asking
for
it
that,
like
we
try
to
not
do
this
I
I
have
no
strong
feeling
about
not
doing
this.
A
There's
going
to
be
some
overhead
and
we
can
build
some
tooling
around
it,
but
I
also
think
that,
like
we
are
in
compliance
with
what
the
open
source
your
versioning
policy
does
require.
So
if
we
can
make
it
better,
I
think
that
sounds
great,
but
I
also
like
I'm,
hesitant
to
say
that
we've
did
something
something
like
outside
the
bounds
of
openstorm
a
tree.
At
this
point.
F
F
Dependency,
that
has
implementation
that
takes
a
dependency
in
the
API
may
bump
that
to
a
newer
version
than
the
SDK
that's
being
used
and
isn't
going
to
change
the
SDK,
and
so
the
application
author
then
needs
to
know.
Oh
my
dependency
increased.
The
API
version
I
need
to
go
and
increase
the
SDK
version
into
badge.
A
A
The
other
way
doesn't
is
isn't
something
we
want
to
do
where
if
you
have
an
SDK
at
a
newer
version,
it
means
that
the
API,
the
1.0
API,
is
not
supported
anymore.
So,
if
you
upgrade
the
SDK
to
like
you
know,
I
don't
know
114
and
you
still
are
using
instrumentation
that
uses
like
1.2.
A
That
should
still
work
right,
but
the
other
way
around,
where,
if
like
you,
upgrade
your
API
instrumentation
and
you
know
the
114
and
your
SDK
is
still
at
1.2
they're,
like
I,
think
the
versioning.
There
is
saying
that,
like
we
should
actually
encourage
users
to
be
upgrading
their
SDK
and
I
think
that
in
a
sense
like
you're,
right,
I
think
we're
on
the
line.
But
I
think
that
is
what
the
the
spirit
of
the
the
burgeoning
policy
there
is
saying.
It
wants.
F
A
That's
that's
definitely
true,
I!
Think
in
this
situation
it's
cutting
the
correct
way,
but
I
I
hear
you
like
it.
There's
nothing
preventing
us
from
cutting
the
opposite
way
by
doing
something
inappropriate
in
the
future
that
that's
true,
so
I
think.
That's
why
I
I
think
then,
if
that's
the
case
like
yeah
having
a
policy
to
prevent
these
sort
of
external
module
in
internal
package,
dependencies
is
going
to
be
useful.
A
A
E
A
E
E
We
should
either
not
use
it
or
if
we
do
use
it,
be
explicit
and
say
this
is
public,
you
can't
break
it.
It
follows
all
of
the
exact
same
public
requirements
of
like
you
can't
change
the
signature.
You
can't
remove
it.
You
can't
do
all
of
that.
The
the
other,
the
only
caveat
there
is,
if
you've
made
it
like
a
filled.
D
A
Yeah
and
I
think
that's
that's
a
good
idea,
because
it
not
only
you
could
actually
solve
it
very
similarly
to
what
we
already
have.
So
if
you
have
an
internal
module,
that's
external
to
the
you
know
the
sub
module.
You
could
always
all
right,
see,
I!
Think
thanks
for
joining,
you
can
always
just
put
the
code
there
and
have
the
generation
script
loaded
at
that
level,
so
that
it
generates
back
downwards
right.
So
you
have
a
central
place
where,
like
it
all
come
from
so
I
think
that
sounds.
A
That
sounds
fine.
I.
Do
think
that,
like
it's,
an
icing
on
the
cake
and
I
think
that's
a
great
direction
we
should
be
going
into
so.
I
also
think
that
we
need
to
document
this
in
our
contributing
talk,
because
this
is
this
is
not
necessarily
something.
That's
obvious
that
we
want.
Also,
you
know,
having
multi-module
systems
is
not
usually
how
people
start
your
go
code.
So
we
are,
you
know
outside
of
Google.
Sorry
Mike.
You
know
a
little
bit
unique
here.
I
think.
E
A
That
sounds
good.
Could
you
make
sure
you
tag
Robert
index
I
know
he's
been
working
on
this
as
well:
okay,.
C
A
Yeah,
okay,
well,
cool
I!
Think
with
that
we
have
a
path
forward
on
it
and
we're
at
the
end
of
the
agenda.
So
I.
A
Okay,
well,
if
that's
the
case,
I
think
we
could
probably
end
the
meeting
here.
I
know:
Aaron's
furiously
typing.
A
Okay,
cool
cool.
E
A
It
here
and
we'll
see
you
all
next
week
or
asynchronously
until
then,
all
right,
bye,
bye.