►
From YouTube: 2022-07-14 meeting
Description
Instrumentation: Messaging
B
Yes,
I'm
joining
to
listen
in
on.
I
heard
that
the
work
with
honeycomb
and
lightstep
on
the
launcher
may
be
discussed,
and
I
was
just
interested
in
hearing
about
that.
More
than
anything.
A
C
All
right,
can
you
hear
me?
Yes,
sorry,
I'm
still
half
on
vacation,
so
the
mic
issues
are
sometimes
here.
A
We'll
give
just
another
minute
or
two
for
people
to
filter
in
is
there
going
to
be
anybody
else
from
lightstep
joining
no
philippines
mentioned
that
you've
been
speaking
with
alex
bowden.
D
I
know
not
that
I'm
aware
of
okay,
although
I've
also
spoken
with
aaron
at
open,
telemetry
community
today
somewhat
about
this
topic,
so
I
should
have
at
least
one
other
person
here,
who's
at
least
faintly
familiar
with.
What's
going
on,
provided
that
I
wasn't
rambling
incoherently
during
that
day,.
A
D
Yeah
sure
all
right,
so
let
me
give
a
little
bit
of
context
and
also,
I
think,
apologies.
I
think
some
of
us
like
we
were
intending
to
attend
this
sig
like
two
weeks
ago,
but
combination
of
like
out
of
offices,
team
off
sites,
conferences
that
kind
of
stuff
made
that
a
bit
of
a
challenge.
So
here
we
are
hey
so
high
level
context
here.
D
So
honeycomb,
like
light
step,
is
building
out
some
effectively
wrappers
around
sdks
that
just
make
it
easier
to
config
and
send
data
to
our
endpoints,
the
intent
being
that
like,
if
you're
getting
started
using
us,
then
you
use
that
it's
instead
of
a
whole
bunch
of
lines
of
code.
It's
like
maybe
three
lines
of
code,
but
then
you
use
open,
telemetry
api,
just
as
if
you're
using
the
vendor
neutral
sdk.
Since
lightstep
has
already
built
some
of
these
things
with
what
are
called
launchers.
D
D
Okay
well,
rather
than
write
a
whole
bunch
of
code
ourselves,
let's
like
what,
if
there's
like
a
more
common
thing,
that
everybody
could
use,
that
is
vendor
neutral
and
then
vendors
themselves
can
just
like
layer
a
really
small
config
thing
on
top
of
it
in
their
own
package,
that
they
maintain
themselves
seemed
like
a
decent
enough
idea.
So
we're
like
okay,
let's
experiment
with
it.
I
worked
with
alex
on
the
light
step
side
and
we
forked
the
go
launcher
at
the
time.
I
believe
since
then,
there's
been
some
stuff.
D
That's
been
added
to
the
upstream
launcher,
but
we
haven't
pulled
any
of
that
in
because
I
believe
it's
like
some
experimental
metrics
stuff
that
we're
not
interested
in
at
least
not
right
now,
and
we
refactored
it
so
that,
like
all
of
the
stuff
that
makes
it
like
two
or
three
lines
of
code
to
configure
the
go
sdk
and
then
send
it
off
to
light
step,
is
vendor
neutral
and
then
there's
a
light
step
package
and
a
honeycomb
package.
D
This
is
just
in
the
current
code
base
and
then
those
just
layer
on
top,
so
you
could
just
use
the
vendor
neutral
one,
and
then
there's
there's
like
an
api
for
setting
an
endpoint
setting
headers
that
kind
of
stuff
to
effectively
recreate
what
like
the
light
step,
one
does
or
what
the
honeycomb
one
does,
and
that
is
completely
discreet,
separate
from
anything
that
has
the
words
light
stepper
honeycomb
on
it
that
it
basically
works,
and
so
we
haven't
put
like
a
ton
of
time
into
it.
D
But
it's
to
the
point
where,
like
it's
usable
and
yeah,
let
me
actually
do
that.
It'd
be
fantastic,
put
a
link
in
chat
here.
This
is
in
the
the
branch
that
that
we
have
it
in
actually
that's
from
the
commits.
D
You
can
figure
it
out,
so
the
main
difference
there
is
that
there's.
D
There's
really
like
just
two
or
three
subfolders:
there's
the
launcher.
Subfolder
the
lightstep
subfolder
in
the
honeycomb
subfolder
just
for
convenience
is
sake
they're
all
in
the
same
repo,
but
they
don't
have
to
all
live
in
the
same
repo
like
this
just
for
co-development
to
make
it
easier.
D
The
launcher,
one,
I
think,
is
the
most
interesting
bit,
because
this
basically
pulls
all
the
stuff
that
sets
up
that
like
sets
up
the
right
resource
attributes,
establishes
a
tracer
provider
like
all
that
kind
of
stuff
and
turns
the
20
to
30-ish
lines
of
code
that
you
write
to
initialize
tracing
into
like
two
or
three
lines
of
code,
depending
on
what
additional
things
you
want
to
throw
in
there.
D
D
I
guess,
and
if
that
jives
with
plans
that
you
have
about
improving
ergonomics
around
initialization
and
if
there's
anywhere,
that
we
could
meet
with
this
and
and
have
something
or
if,
if
this
like
collides
with
other
plans
that
you
might
have
or
or
something
like
that,
so
it's
it's
at
a
state
where,
like
it,
you
can
play
around
with
it
and
see
that
it
works.
D
But
it's
not
like
this
production
ready
thing
that
we
think
is
ready
to
go
that
everybody
needs
to
use
immediately.
So
that's
my
high
level
explanation
of
it
all.
So
I'm
curious
what
people
think.
E
I'll
just
step
up
and
ask
how
how
different
is
it
to
the
java
auto
configuration
sdk,
which
also
has
a
way
of
essentially
scaling
up
and
setting
exporters
plus
headers
access
tokens
things
or
from
environment
variables,
at
least
as
I
I
understand,
I'm
not
a
huge
java
guy,
but
looking
at
that
order
configuration
api,
it
seems
like
it
could
do
similar
things.
D
Yeah,
it's
it's
it's
pretty
much.
I
mean
you
know
like
the
nouns
and
verbs
are
a
little
different,
but
it's
pretty
much
the
same,
like
you
call
launcher
dot,
configure
open
telemetry.
That
gives
you
back
a
thing
called
a
launcher,
and
then
you
defer
shut
down
it
and
then
from
there
you
could
set
your
own
environment
variables
like
just
like
otlp
exporter,
the
header
otlp,
the
header,
that
kind
of
stuff,
and
then
it
should
all
work.
The
same
way,
there's
also
some
like
little
helpers.
D
If
you
don't
want
to
use
environment
variables,
you
can
do
like
dot
with
service
name
dot,
with
headers
dot
with
endpoint
that
kind
of
stuff.
But
I
think
conceptually
it's
pretty
much.
The
same
model.
A
D
There's
no
like
additional
environment
variables
that
are
supported
beyond
what
I
think
like
the
base
sdk
supports,
if,
if
that
makes
any
sense
at
least
I
don't,
I
don't
believe
we
intended
to
add
any
additional
environment
variables
propagation,
I
believe
the
default
is.
It
sets
up
the
same
thing
as
the
the
the
auto
propagator
package
that
that
you
all
recently
released
basically
does
the
same
thing
to
my
knowledge,
but
all
of
all
of
these
things
are
could
potentially
change
so
yeah.
D
I
believe
this
registers,
so
this
doesn't
do
anything
with
the
meter
provider.
Yet
that
would
have
to
be
something
that
will
be
added.
I
believe
it
registers
the
tracer
provider
when
you
call
configure
open
telemetry.
D
D
Right
like
if
they
wanted
to
use
http
instead
of
grpc
yeah,
I
don't
think
there's
there's
anything
that
would
prevent
that
from
being
added.
That
would
just
be
an
additive
thing
that
we
would
that
so
like
let's
say
hypothetically,
we
had
already
released
this
as
like
a
pre-alpha
or
something
like
that.
We
would
probably
just
just
have
that
be
additional
work,
that
we
would
do
on
the
path
towards
non-pre-alpha
and.
A
A
With
with
exporters,
we
want
to
be
careful
about
pulling
in
dependencies
that
an
application
author
may
not
want
like
this
one
pulls
in
grpc,
which
has
a
fairly
heavy
dependency
set
that
someone
who
doesn't
want
to
use
that
may
not
want
to
pull
in.
So,
I
think
with
autoprop.
We,
because
the
propagator
packages
are
fairly
small.
We
pull
in
all
of
our
default
propagator
packages,
but
with
with
exporters
we
would
want.
A
You
know
to
explicitly
have
the
the
application
author
pull
in
packages
or
provide
a
bundle
package
that
says
you
know
give
me
all
the
exporters
that
just
imports
them
for
side
effects,
but
something
like
that
would
probably
be
the
way
to
go
and
then
have
an
option
to
say
you
know,
with
exporter,
have
support
environment
variables.
I
think
the
spec
is
ready
to
find
an
environment
variable
for
selecting
exporter
as
well.
D
Okay,
yeah,
I
think
I
think
that
makes
sense.
I
think
the
question
that
I
would
have
there
is
is
like,
like
should
grpc,
be
a
default
like
like,
if,
like
I'm,
just
kind
of
imagining
like
if
I'm
a
developer-
and
I
want
like-
oh
I
don't-
I
don't
particularly
care
about
the
format
I
just
want
to
have
like
two
lines
of
code
to
then
to
then
work
like
what
should
be,
or
should
that?
Should
that
be
a
thing
like?
D
Should
there
be
a
default
that
then
you
could
then
change,
or
should
this
be
something
where
you
have
to
pull
in
several
different
components
or
something
like
that.
A
Sure,
but
I
think
the
point
would
be
that
the
the
base
package
wouldn't
include
any
export
packages
as
dependencies.
It
would
simply
include
the
mechanisms
for
selecting
an
exporter
from
those
that
are
registered,
and
then
the
honeycomb
package
could
include
the
http
and
grpc
otlp
exporters
to
register
them
for
to
make
them
available
for
use
by
the
base
package.
C
But
I
I
think
we
are
kind
of
drifting
a
little
bit
off
course
here.
So
I
want
to
say
thank
you
for
for
doing
some
legwork
on
this.
I.
C
We
have
been
focusing
on
getting
functionality
available
and
allowing
users
to
have
a
a,
not
a,
not
necessarily
a
have
a
wide
range
of
choices,
which
can
also
mean
that
they
are
overloaded
with
those
choices
so
having
something
that
helps
people
getting
you
know
day
one
getting
going
on.
This
is
appreciated.
A
Yeah,
I
absolutely
second
that
I
mean
I.
I've
pulled
us
into
minutia
a
little
bit
in
terms
of
implementation
details,
but
that's
largely
because
I
think
this
is
a
thing
we
should
be
doing
is
the
direction
we
should
be
going,
and
I
just
want
to
make
sure
we're
kind
of
moving
in
the
right
direction
to
make
it
supportable
and
not
overwhelming
for
users.
D
Would
it
would
it
be
helpful
to
like
gather
just
like
a
list
of
these
sorts
of
issues,
and
then,
like
I
mean
I
think
we
could?
I
like,
I
would
certainly
say
that
we're
comfortable
with
taking
point
on
like
going
through
them
one
by
one
to
be
like
okay.
This
is
like
a
potential
way
that
we
could
address
each
of
those
and
then
come
back
in
the
next
thing
and
say
like
okay.
D
This
is
kind
of
how
the
shape
of
it
could
potentially
look
and
like
here's
one
option,
here's
here's
another
option
that
sort
of
thing,
because
I
definitely
like
to
if
there's
a
way
to
move
forward
with
with
this,
with
aims
to
having
like,
basically
almost
all
of
it,
be
vendor,
neutral
and
sitting
somewhere.
That's
not
you
know
it
doesn't
require
you
to
have
the
words
honeycomb
or
light
stuff
attached
to
it
or
insert
vendor
here
then
I
would
definitely
love
to
progress
that
forward.
A
Yes,
I
think
a
good
next
step
here
might
be
a
design
document
layout.
What
are
our
goals?
How
do
we
intend
to
achieve
them
and
use
that
for
discussion
in
order
to
further
the
discussion
of
what?
What
are
we
actually
going
to
build?
Where
will
it
all
live?
How
will
it
function?
I
think
this
is
a
great
prototype
and
proof
of
concept.
Now,
let's,
let's
take
that
and
kind
of
try
to
formalize
what
we
want
to
do
in
terms
of
bringing
it
into
the
fold.
B
A
C
D
Yep
agree:
okay,
awesome.
We
will
take
point
on
doing
that,
getting
a
draft
up
so
that
everybody
can
bang
around
on
it
and
figure
out
what
the
right
shape
is.
D
I
think
what
we
we
could
probably
do
is
like
have,
I
don't
know,
have
like
some
some
words
that
are
like
appropriately
cagey
enough
that
are
like
these
are
the
this
is
the
intended
philosophy
and
intended
yadda
yadda,
and
then
hopefully,
that
makes
it
clear
that,
like
everything,
that's
in
there
is
up
for
change
so
long
as
the
the
spirit
of
reducing
lines
of
code
that
it
takes
to
get
started
is
still
ultimately.
A
C
Thank
you.
Sorry,
here's
a
quick
look
of
the
board.
I
believe
we
have
completed
a
number
of
tasks
this
past
week.
C
We
had
captured
that
we
have
to
create
async
instruments,
but
we
actually
split
that
off
and
do
cr
async
instruments
and
also
the
callbacks
because
of
how
they
line
up
the
one
big
thing
that
I
want
to
call
out
is
it's
one
of
these
later
ones,
but
with
the
export
data
structure,
and
I
guess
the
rename
that
should
be
landing
soon,
the
exporters,
their
actual
logic,
should
be
ready
to
be
picked
up.
So
that
was
a
big
unblocking
of
a
number
of
tickets.
C
So
you
should
notice
that
the
block's
gone
down
dues
have
gone
up
and
in
progress
is
still
roughly
the
same
yeah.
So
I
think
overall
we
are
making
making
pretty
good
progress.
A
C
Yes,
yes,
exporters
should
be
on
blocked;
they
should
be
in
the
to
do
column.
Here's
prometheus
standard
out,
otp
metrics.
I
would
also
call
out,
though,
we
have
example
codes
for
each
of
these
oftentimes.
Those
examples
have
to
have
like
a
full
working,
end-to-end
sdk.
C
C
You
know
where
the
poll
reader
is
active
or
pushes
to
the
exporter
as
a
mostly
stable.
A
A
Currently,
the
the
author
of
the
pr
has
initially
started
using
the
the
auto
prop
package
that
we
just
released
but
based
on
some
feedback,
they've
pulled
that
back
and
are
now
just
implementing
fixed
propagators,
because
they're
slightly
uncomfortable,
changing
environment
variables
through
code
and
autocrop
doesn't
provide
a
mechanism
for
specifying
which
propagator
should
be
default
by
id
rather
than
by
providing
a
propagator.
A
So
what
they
would
like
is
to
have
a
config
file
that
has
a
field
for
which
propagators
you
want
to
use
with
the
same
structure
as
the
environment
variable,
but
would
be
able
to
be
provided
at
initialization
time
via
code.
So
I'll
probably
create
an
issue
to
to
discuss
that.
But
since
it's
happening
now,
we've
got
people
here.
I
just
wanted
to
bring
it
up
and
see
if
anybody
has
any
thoughts
or
concerns
on
that
sort
of
approach.
E
A
Yeah
well,
thankfully,
the
collector
already
has
that
decided,
so
they
have
a
config
file
structure
and
and
marshalling
on
muffling.
All
of
that,
so
they
would
handle
that
the
the
question
is
just
if
they
have
a
string
can
they
use
that
string
to
say
give
me
a
new
autopropagator
using
this.
You
know
the
the
propagator
with
this
id
as
the
default,
instead
of
requiring
them
to
set
the
environment
variable.
E
Okay,
yeah,
I
just
really
get
back
to
the
prior
topic
where
we
had
the
jamie-
and
I
guess
philip
talking
about
potential
configuration,
auto
configuration
and
you
know
being
able
to
do
that
from
a
config
file
as
well.
I
wonder
whether
we
would
look
at
that
inside
of
actual
go
implementation
itself.
A
Yeah,
I
would
love
for
us
to
go
that
direction.
That's
something
that
probably
has
to
happen
through
the
spec
process,
though,
because
that
should
be
common
across
all
of
the
sdks
similar
to
the
way
the
the
environment
variables
are
specified.
There's
been
discussion
of
doing
that,
but
we've
never
really
got
any
traction
on
on
anybody
making
a
concrete
proposal.
Okay,.