►
From YouTube: 2022-07-21 meeting
Description
Instrumentation: Messaging
B
Sorry
we're
currently
experiencing
some
technical
difficulties,
we're
looking
for
someone
who
can
claim
the
host
one
of
us.
Can
we
just
need
to
find
the
key
it's
here
somewhere?
It's
probably
another
cash
questions.
C
Can
you
hear
me
now?
No,
yes,
okay,
a
little
hard
refresh,
seems
to
fix
the
problem.
Okay,
sorry
about
the
delay,
everyone
I,
don't
know
what
was
going
on
there.
Of
course,
it's
the
day
that
I'm
not
sitting
at
my
office
that
I
have
issues
well
welcome.
We
are
definitely
past
time,
so
why
don't
we
jump
into
this
yeah?
C
Exactly
if
you
haven't
yet,
please
add
your
name
to
the
attendees
list
and
if
you
have
anything
you
want
to
talk
about,
please
add
it
to
the
agenda
and
I
will
try
to
pull
up
my.
C
Cool
so
to
start
us
off,
we
have
this
launch
proposal
for
a
simplified
Hotel
go
inits
that
we
wanted
to
talk
about.
I,
don't
know
who
added
this,
but
if
you
wanted
to
add,
take
over.
D
Yeah
sure
this
is
well
Jamie
created
the
issue,
but
we
were
here
last
week
and
we
discussed
just
with
mouth
words
wanting
to
do
something
like
this
and
working
with
Alex
Bowden
over
at
lightstep
to
sort
of
reshape
their
Go
Launcher
to
be
mostly
vendor
neutral
and
then
layer
on
some
vendor
specific
stuff.
D
And
so
everybody
here
was
like
cool
sounds
good
in
theory,
let's
create
an
issue:
let's
have
a
little
design
doc
and
let
people
party
on
it
for
a
little
bit,
and
so
that's
what
we
did
and
here
to
discuss
so
I
don't
know
like.
If
protocol
is
like
hey,
we
all
read
it
and
check
it
out
or
just
do
that
asynchronously
and
then
come
back
with
feedback
but
wanted
to.
Let
you
all
know
that
that
is
here
and
Jamie
could
probably
speak
to
a
lot
more
of
this,
because
she
wrote
the
design.
E
Yeah
I
mean
I
think
also
like
what
Philip
said.
If
there's
a
thing
we
want
to
read
through
it
now
and
talk
about
it
or
if
it's
something
that
you
all
want
to
look
through
after
and
like
get
back
on
it
there's
the
detail
in
this
design
dock
here
with
the
intention
of
adding
comments
and
things
like
that,
and
the
issue
also
includes
a
link
to
the
branch
which
right
now,
the
idea
is
that
the
vendor
neutral
launcher.
E
We
have
a
fork
of
the
go
contrib
repo
and
the
goal
would
be
once
it's
sort
of
agreed
upon
or
approved,
or
you
know
whatever
else.
We
would
want
to
submit
that
as
a
PR
to
live
in
the
go
contrib
repo
and
then
for
anyone
who
hasn't
read
through
it
yet
or
isn't
really
aware
of
it.
E
Yet
that
would
be
the
vendor
neutral
launcher,
just
to
primarily
streamline
configuration
and
simplify
things,
and
you'll
see
noted
in
here
that
vendors
can
have
a
package
that's
compatible
with
it,
to
make
setting
up
to
send
to
their
back
end
easier
like
for
honeycomb
or
lights,
except
there's
one.
But
you
know
whatever
all
their
back
end,
could
do
it
or
not?
Do
it
and
just
use
the
launcher
as
is
and
have
it
go
to
localhost
42317
or
wherever
else
they
want
it
to
go.
B
C
Yeah
I
think
that's
good
I.
Think
I'd
probably
want
to
have
that
conversation
asynchronously
just
in
case
there's
people
that
also
want
to
talk
about
this
I
have
looked
through
this
a
little
bit.
I
have
some
questions,
I
guess
really.
The
answer
was
maybe
like
is
the
best
place
for
comets
here
or
in
the
issue.
Do
you
think.
E
I
think
it
might
be
I,
don't
I,
don't
know
what
the
normal
process.
Maybe
it
was
requested
that
we
do
a
design
doc
separately
like
this
in
Google,
to
have
this
all
written
out,
I
think
either
one
is
fine
or
both
whatever
seems
easier
to
work
with
I
think
we're
we're.
Okay
with.
A
C
Yeah,
so
one
of
the
things
that
kind
of
stuck
out
to
me
was
this
configuration
there's.
So
one
of
the
things
is
that,
like
there's
an
environment,
we're
able
to
submit
what
exporter
is
used
if
I'm,
not
mistaken,
I
think
it's
just
called
the
otlp
exporter
or
something
like
that.
You
could
choose
the
Jaeger
otlp
grpc
or
something
like
that.
Is
that
plan
to
be
included
here.
D
Thank
you
most
most
likely
yeah
it's
not
in
there
right
now,
but
unless
there's
like
a
good
reason
not
to
have
it
I
think
it's
pretty
straightforward
to
add
it
too.
So.
C
Yeah
so
that's
kind
of
a
those
Advocate
question:
I
guess
maybe
that
wasn't
the
most
honest
thing
to
say,
but
I
I
guess
the
question
is
is
like?
Is
everyone
going
to
be
okay
with
that
import?
I
guess
is
the
question,
because
this
is
going
to
be
a
heavy-handed
or
if,
if
we
do
something
like
that
similar
with
the
propagation
you're
going
to
record
all
of
the
propagators.
E
Right,
yeah
and
I
guess
we
kind
of
briefly
touched
on
it.
On
the
bottom,
I
tried
to
use
the
Otep
as
sort
of
the
structure
to
kind
of
give
the
document
a
little
more
structure,
I
left
out
some
pieces.
E
The
idea
generally
is
that
there
are
some
default
configurations
that
are
very
commonly
used
and
so
as
a
trade-off
that
ends
up,
meaning
that
there
will
ultimately
be
some
dependencies
in
there
that
aren't
used.
So,
for
example,
if
we
brought
in
say
the
HTTP
exporter
and
the
grpc,
then
you're
only
using
one
of
those,
the
goal
would
be
that
they're
smaller
packages,
that's
a
trade-off.
You
have,
it
simplifies
configuration,
but
has
a
little
bit
of
extra
bloat
there
because
of
some
of
the
dependencies.
E
The
idea
of
this
would
be
if,
if
having
some
of
those
extra
dependencies
that
are
deemed
to
be
important,
that
should
kind
of
follow
along
with
this
launcher
everywhere.
If
having
those
couple
of
extras
are
too
much
for
you-
and
you
are
that
concerned
with
the
size
size
of
the
packages,
then
it
may
not
be
that
this
is
the
thing
for
you
to
use
and
that
you
would
just
continue
to
initialize
and
use
the
go
SDK
as
it
is
today.
E
But
if
those-
and
maybe
that's
part
of
the
question
of
how
many
things
are
in
there
by
default,
like
grpc
and
HTTP,
probably
should
both
be
along
for
the
ride
always
but
I.
Think
that's
probably
a
question.
That's
a
good
question
to
ask:
is
what
about
any
other
exporter
that
we
might
normally
have,
or
some
of
these
other
features
what's
considered
appropriate
for
the
default,
or
do
we
keep
these
certain
ones
in
here
and
you
can
still
import
other
things
if
you
need
it
on
top
of?
What's
a
part
of
this
anything.
B
E
Not
default
adds
more
code.
Anything
that
is
default
adds
more
dependencies
that
may
not
be
used
so
there's
trade-offs.
There.
C
Yeah
I
agree,
and
then
it
also
maybe
this
is
also
talking
about
like
the
vendor
specific
packages
as
well,
but
like
the
extensibility,
I
I
first
off,
want
to
say,
like
I
agree
with
that
statement
like
if
the
package
is
too
big.
Maybe
this
package
isn't
for
you
and
I
would
come
to
the
same
conclusion,
but
I
think
we
need
to
make
sure
that
we're
explicit
and
I
think
that
we
need
to
make
sure
there's
sign
off
on
everyone
who's
kind
of
interested
in
this.
C
If
that's
an
okay
Direction
and
if
they
have
qualms
with
that,
then
maybe
we
could
discuss
it.
I
think
is
is
important
to
make
That
explicit,
but
as
with
the
the
with
propagator
configuration
this
one
kind
of
is
interesting
because
you
have
Trace
contacts
and
baggage
here,
which
I
think
is
it.
It
reminds
me
of
the
the
auto
prop
package
that
we
just
released
last
cycle
and
I
think
that
might
be
a
good
answer
for
how
we
can
make
extensions
here,
because
I
would
hate
it.
C
So
somebody
comes
along
and
they
say
like:
okay,
I've
got
a
really
cool,
Kafka,
propagator
and
I
want
to
include
that.
How
would
you
include
it?
C
I
think
in
this
launcher
is,
is
the
question:
if
you
use
the
autoprop
package,
you
can
register
it
and
then
you
could,
you
know,
call
it
out
an
environment
variable,
but
I
want
to
make
sure
that
we
have
that
extensibility
here
or
or
in
the
dependency
chain
that
we
use
I
think
is
going
to
be
critical,
because
otherwise
it's
just
going
to
be
a
very
static
thing
and
then
we're
going
to
have
bloat
as
people
are
like
well
I
want.
You
know,
company
xyz's
export
or
can
we
add?
C
That
is
this
kind
of
a
key
thing
here
as
well.
B
I
would
suggest,
perhaps
even
having
that
as
separate
from
the
launcher
package
as
something
that
can
be
used
without
the
launcher,
and
then
the
launcher
could
include
that
and
include
a
default
set
of
components
that
it
registration
of
the
otlp,
grpc
and
HTTP
exporters,
and
then
any
vendor
package
is
simply
import
for
side
effects,
whatever
exporters
they
need
as
well.
Where
we
have
a
an
all-in
can
drive
exporters
package,
you
can
import
for
side
effects
that
brings
in
all
of
the
exporters
and
registers
them.
C
C
The
next
thing
that
I
saw
is
minor,
but
the
resource
attributes
can
Define
the
service
name.
So
just
a
heads
up,
that's
gonna
have
to
get
parsed
I.
Imagine
everyone
this
everyone
on
this
call
has
done
this
like
three
times
already
so
I.
Don't
know
why
I'm
saying
it
but
other
than
that
I
I
think
it
sounded
like
reading
through
this,
the
configuration
for
extension
with
Fender
specific
packages.
There
were
two
approaches
here:
I,
don't
know
if
I
quite
grocked
what
those
two
approaches
were.
E
I
think
generally,
the
the
two
different
approaches
were
strictly
using
environment
variables
versus
having
the
ability
to
add
it
in
code
so
like
in
the
first
example.
We
just
have
launch
or
configure
open
Telemetry,
and
in
the
second
example,
we
have
launcher,
configure
open,
Telemetry
and
launcher
dot
with
service
name
honeycomb
dot
with
API
key
honeycomb
dot.
Another
thing
that
we
may
have
so
in
the
API
key
specific
example.
Here
in
the
first
example,
you
don't
add
any
extra
code,
you
just
set
honeycomb
API
key
and
the
code
knows
what
to
do
with
it.
E
C
Okay,
that
makes
sense-
and
so
somehow
this
this
setup
here,
like
there's,
going
to
be
a
side
effect
when
you
call
this
because
you
imported
this,
is
that
what's
going
to
happen?
Yes,
okay,
it's.
C
Yeah
yeah
I'm,
also
just
it's
one
of
those
nerds
type
things
I,
think
I'm
just
trying
to
think
of
how
you
would
do
it,
but
it's
possible
I
know
that
I
know
it's
possible,
so
both
of
these
should
be
possible
with
this
proposal
right.
It's
not
one
or
the
other.
E
Right,
yeah,
yeah,
sorry
and
we're
we're
working
on
we're,
trying
to
have
cleaner
versions
to
look
at,
which
is
why
we
have
the
almost
their
work
and
progress
branch
of
just
the
launcher
and
then
separately.
We
want
to
have
the
work
in
progress,
here's
what
it
looks
like
in
honeycomb,
but
there
is
actually
a
branch
out
there
right
now.
I
can
find
the
link
for
it.
That
has
here's
an
example
using
light
steps
vendor
package.
Here's
the
example
using
the
honeycomb
vendor
package
and
an
example
of
them
in
use
as
well.
Okay,.
C
I
gotcha,
okay,
that
makes
sense.
A
I
have
one
question:
I:
have
you
so
I
think
it
definitely
looks
great
and
it's
going
to
be
something
which
is
going
to
make
things
a
lot
easier
to
set
up
a
project.
My
question,
I
guess,
is:
have
you
considered
kind
of
writing
an
Otep
and
maybe
adding
the
launcher
as
an
open
Telemetry
specification
so
that
we
could
have
like
over
long
wages,
also
implementing
similar
launchers
and
have
a
kind
of
similar
interface
for
all
languages
to
do
their
own
launchers?.
E
Okay,
we
hadn't
specifically
considered
that
for
this,
but
I
do
like
that
idea
and
I
think
that's
something
that
lights
up
might
have
some
different
launchers
like
this,
which
is
part
of
where
we
liked
the
idea
of
making
it
vendor
neutral
and
pushing
it
up.
Philip.
Do
you
have
any
other
feedback
on
that.
D
Yeah
we
talked
about
this
a
little
bit
like
this.
Is
me
and
Austin
like
stuff
about
like
super
high
level
like
hey,
we
have
like
I
believe
it
was
four
launchers
for
the
different
languages
that
effectively
accomplish
the
same
goal.
Just
was
slightly
different
idioms,
because
each
language
has
different
idioms
for
doing
certain
things,
with
the
intent
that
hey
the
majority
of
that
could
actually
be
upstream
and
better
neutral
and
then
just
layer
on
vendor
specific
config.
D
We
haven't
died
in
it
dived
into
any
specifics,
other
than
go,
and
so
I
think
like
this
is
the
first
like
I.
Guess
you
think
of
it
like
an
experiment
like
hey
did.
Does
this
like
even
make
sense
in
the
first
place
and
if
it
does-
and
it
seems
like
it's
the
right
call,
then
then
yeah,
let's,
let's
maybe
draft
a
no
type
and
see
if
we
can
do
that
for
the
other
languages.
B
Yeah
I
would
expect
one
of
the
first
questions
if
a
notep
were
proposed
to
be
what
languages
have
implemented
this
or
have
sort
of
concept.
So
this
is
a
good
start
to
having
one
we
would
probably
if
we
wanted
to
go
down
that
want
to
find
another
language
that
is
as
different
as
possible
from
go
sh
pretty
easy,
because
it
goes
different
from
us
other
languages
so
that
we
could
show
that
it
can
work
in
multiple
languages
and
multiple
ecosystems.
C
Yeah
and
on
that
note,
though
I
I
don't
know
how
far
you
can
stray
from
go
or
or
the
the
type
of
language
that
go
is
because
I
know
in
a
lot
of
other
languages,
the
the
setup
is
done,
not
in
code
really
it's
it's,
including
Imports,
like
in
Python
and
in
Java.
It's
essentially,
you
say
include
this
and
then,
if
you
need
to
configure
it,
it's
runtime
arguments
or
its
environment
variables
or
something
like
that.
C
Like
the
the
code
setup
is
not
usually
there
just
because
of
the
structure
of
the
language,
so
I
think
it
would
have
to
be
something
in
like
a
compiled
language,
maybe
like
C
or
C,
plus
or
I'm,
trying
to
think
of
another
one.
That.
D
D
C
So
I
guess
the
takeaway
I
would
say
is
I
would
support
doing
this
experiment
and
then,
if
there's
enough
desire
in
other
languages
to
then
unify
in
a
notep
and
honestly
yeah
I
think
if
there's
another
desire
in
other
languages,
it
might
just
be
a
specification
issue
but
we'll
see
but
Damian
I
think
that's
a
good
point
euros.
E
Cool
so
I
guess
I
know
we.
We
talked
about
a
couple
of
things
here,
I,
don't
know.
If
that's
something
that's
anyone
is
able
to
add
either
comments
to
the
doc
or
on
the
issue.
The
sort
of
you
know
kind
of
outlining
those.
If
there's
anyone
else
that
needs
to
comment
on
it
or
just
kind
of
figure
out
what
what
our
next
steps
would
would
look
like.
C
Yeah
I
I
would
make
a
proposal
for
this
I
think
we
do
a
bad
job
at
having
these
kinds
of
proposals
in
like
a
pipeline
for
it,
but
I
think
that
we
should
say
something
to
the
effect
of
like
we
need
positive
engagement,
so
if
you're
on
here
and
you
want
to
say-
like
your
company
or
you
yourself-
want
to
support
this
comment
on
like
the
GitHub
issue,
I
think
is
ideal
or
react
to
it
in
a
positive
fashion.
C
C
You
know
three
I,
don't
know
a
number
three
or
five
approvals,
because
the
last
thing
you
want
is
like
there
to
be
an
echo
chamber,
somebody
to
start
building
a
PR
and
then
nobody
reviews
it.
That's
not
fun
and
also
I.
C
Think
we
want
to
prioritize
time
wise
to
make
sure
that
we
have
like
enough
developer
engagement
to
work
on
one
or
the
other,
and
so
I
think
that's
kind
of
how
I
would
approach
this
I
could
say
that
I
would
support
this
in
the
issue
and
I'll
try
to
voice
that
into
issue
after
the
after
the
meeting
I'll
also
take
it
as
an
action
item
Jamie.
Those
comments
that
I
I
kind
of
raise
I'll
try
to
comment
them
I
think
in
the
doc,
the
design
doc.
E
I
did
take
some
notes.
I
can
I
can
put
some
of
those
comments
on
there
if
that's
helpful,
and
if
you
want
to
expand
upon
them.
If
there's
like
a
thing
that
I
missed
I
guess
the
other
question
is,
if
you
think
it's
easier
to
have
it
in
the
issue.
I
could
also
like
paste
the
content
of
the
doc
into
an
issue,
or
something
like
that.
If
that
seems.
C
I
so
I
didn't
want
to
say
it
because
I
know
it's
an
added
overhead
of
work,
but
the
problem
is
I've.
Seen
this
before
is
like:
we've
done
these
design,
docs
and
then
people
a
company
will
leave
and
then
the
Google
Doc
access
just
goes
away.
I,
don't
know
if
that's
going
to
be
the
case
in
this,
but
I
think
if
we
keep
it
in
an
issue,
it's
a
lot
easier
to
ensure
that
that's
going
to
be
there
going
forward,
and
everyone
knows
the
conversation
going
forward.
C
It's
also
harder
to
comment
on
specific
sections
of
it.
So
I
can
see
it
both
ways,
but
I
would
prefer
the
GitHub
issue.
I,
don't
know
if
anybody
has
strong
opinions,
otherwise.
B
I
think,
if
we're
going
to
move
it
to
GitHub
in
order
to
enable
commenting
on
specific
portions
of
it,
we
should
instead
do
it
as
a
PR.
Adding
a
markdown
file
to
you
know
the
place
where
we
expect
to
start
building
it
out.
Something
like
that.
C
Yeah,
that's
a
great
idea
have
like
a
design
folder
or
something
like
that.
Added
to
GitHub
or
open
television
go
contribute
right.
C
E
Sure
you
could
definitely
do
that
so
I'll
I'll
transfer
into
a
PR.
So
you
can
easily
point
out
things
and
write
things
on
on
different
spots.
It's
all
in
one
place
and
so
we're
thinking
just
so
now
to
read
me
under
a
launcher
directory,
but
a
design
dot
MD
under
a
launcher
directory.
That
sort
of
a
thing.
C
So
I
was
thinking
just
in
the
top
level,
open
Telemetry
go
contrib
repository
just
put
a
design
folder
and
then
do
like
zero
zero
one
dash,
aperture
dot
MD,
but
that's
just
I
think
that's
more
kind
of
yeah.
Okay
Anthony
gave
the
thumbs
up
that's
kind
of
just
kind
of
following
what
the
Otep
style
was
and
I
want
to
say:
I
apologize,
because
I
think
this
is
a
thing
we
should
have
for
how
to
submit
designs
and
proposals
like
this
of
a
big
nature.
C
So
maybe
you're
going
to
be
kind
of
the
guinea
pig
and
we
can
capture
what
we're
doing
here
in
in
our
contributing
dock
as
well.
C
Too
close
to
home
there,
okay,
cool,
okay,
and
that
sounds
good
and
then
I
will
also
then
once
I
send
Jamie
I'll.
Try
to
add
those
comments
in.
D
C
Awesome,
thank
you
both
for
tackling
this.
It's
not
a
small
task.
I
know.
Let
me
see
if
I
can
go
back
to
sharing
real,
quick.
C
Okay,
last
thing
on
the
agenda
was
check
in
on
the
metric
system
projects.
Our
progress
says
73
complete,
which
I
think
is
the
same
as
last
week.
So
I
definitely
know
that
issues
have
been
completed
and
new
ones
have
been
added,
so
I
think
we're
just
kind
of
did.
Us.
C
Okay,
all
right
we're
definitely
moving
up.
Oh
actually,
Aaron
I,
don't
know
if
he
showed
this
last
week,
but
there's
like
this
a
little
burn
down
board.
We
found
asynchronously,
which
yeah
definitely
looks
like
some
things
got
done
here
and
it's
a
slow
trickle
to
read
this.
You
want
the
red
line
to
approach
the
blue
line.
I
think
is
the
idea
or
all
lines
to
approach
the.
A
Purple
is
done
so
you
want
purple
to
reach
the
red
line.
Yeah.
C
I
know
right
I
know,
then
they're
gonna
start
asking
hard
questions
like.
Can
you
filter
this?
Or
can
you
do
other
things?
And
let
me
tell
you
I,
don't
know
the
answer
to
that.
C
But
that
being
said,
do
you
think
we're
having
some
good
progress
currently
in
progress
right
now
we
have
the
open,
Summit
Tree
pipeline
structure,
which
this
PR
is
addressing
this
some
aggregator
I
am
about
to
push
it
an
update
from
Maine
and
the
new
testing
I
could
start
using
it
here.
So
this
should
be
re
submitted,
not
as
draft
just
hopefully
today
same
with
the
last
last
value
aggregator.
C
That
being
said,
I
think
I,
don't
know
how
much
we
went
over
last
week.
Sorry
again,
I
wasn't
here,
but
there's
a
fair
amount
of
stuff
to
do.
C
One
of
the
things
that
we
did
add
back
if
you're
looking
to
pick
something
up
is
the
exporter
code
for
Prometheus
standard
out,
metrics
and
then
oclp
metrics
can
probably
start
to
be
added
back
in
because
we
have
the
interfaces
defined
and
I
I
think
that
you
can
essentially
stub
in
your
own
data
structures
that
you
will
be
expecting
to
get
and
then
start
working
on
your
transforms.
C
So
if
you
are
looking
to
pick
something
up,
that's
a
good
area
that
I,
don't
think
anybody's
working
on
right
now,
I
know
Aaron
is
is
more
in
the
the
top
end
of
ingestion.
So
I
don't
know
if
you
want
to
talk
a
little
about,
maybe
the
Callback
handling,
or
that
was
also
added
Aaron.
A
There's
not
too
much
left
to
do
so.
The
current
the
current
work
is
on
the
pipelines.
A
I
think
we
may
just
for
convenience,
want
to
add
a
kind
of
registry
for
our
pipelines,
just
something
that
you
can
look
across
multiple
pipelines
just
because
that's
used
in
a
couple
different
places,
but
the
next
step,
the
next
step
after
pipelines
are
finished,
is
essentially
wiring
up
the
instruments,
synchronous,
asynchronous
and
then
end
callbacks
is,
is
somewhat
a
part
of
that
all
to
register
themselves
properly
with
the
pipeline
outputs
and
then
also
accept
the
inputs
to
you
know:
Drive
the
inputs
to
the
appropriate
aggregations
that
are
underlying
them.
A
C
Awesome
I
guess
I
guess
this
is
accurate,
then
this
Upstate,
so
that's
good.
If
you're
looking
for
issues,
this
is
a
good
place
to
look
also
to
keep
in
mind
if
you
have
I
think
bigger
overarching,
SDK
questions
that
are
around
performance
or
enhancements
or
extensibility.
We've
definitely
started
to
capture
those
in
this
beta
Milestone.
There's
some
pretty
good
ones
here.
I
think
we're
really
trying
to
focus
our
development
effort
on
getting
something
working.
C
That's
accurate,
currently,
maybe
not
the
most
optimal,
maybe
not
the
most
I
think
concise,
but
has
a
solid
enough
API
where
we
could
iterate
on
it
and
get
that
out
as
the
alpha
release,
but
anything
that
we've
kind
of
started
to
discover,
as
maybe
we
want
to
come
back
and
touch
on
these
sort
of
things.
We
started
adding
to
this
beta
Milestone,
so
please
feel
free
if
you,
if
you
have
issues
like
that
to
start
including
them
in
this
Battlezone
I
think,
is
kind
of
a
key
thing
here.
C
Okay
with
that,
that's
through
the
written
agenda
stop
sharing.
If
anybody
else
has
something
else
they
wanted
to
talk
about
I'll
pause
here,
you
can
bring
it
up.
C
No
go
cool.
Well.
Has
anybody
used
open
Telemetry
in
the
past
week,
two
weeks,
even
any
good
user
stories?
You
know
customers
using
third-party
using.
D
Yeah,
we
not
not
necessarily
go,
but
yes
and
we've.
We
had
a
fun
session
where
one
of
our
Engineers
was
like.
I
know
nothing
about
open,
Telemetry
and
I'm
going
to
pretend
like
this
is
the
first
time
I'm
ever
using
honeycomb
and
stumbled
through
trying
to
set
up
a
tracer
in
Python
but
managed
to
get
it
to
work,
and
so
we're,
like
oh
cool,
there's
a
lot
of
tutus
that
we
have
here
but
like
they
were
successful
in
an
hour.
Yay.
C
Wow,
that's
that's
great
news,
honestly,
yeah
I
think.
D
I
think
that
the
big
hour,
no
less
wow,
yeah
yeah
I
I,
mean
I
think
the
big
thing
is
probably
I
think
this
is
true
with
everything
which
is
the
getting
started.
D
Stuff
was
oriented
around
like
you're,
literally
starting
fresh
and
a
lot
like
he
was
like
Hey
I
already
have
this
app
that's
using
flask
and
like
could
I
figure
out
how
to
get
like
the
flask,
instrumentation
and
instrument
the
database
calls
and
then
add
some
manual
instrumentation
and
that's
where
he
struggled
the
most
with
was
like
how
do
I
get
this
thing
initialized
in
the
context
of
my
existing
app
so
I,
imagine
that's
going
to
be
a
similar
struggle
that
everybody
has,
regardless
of
what
language
they're
using
and
so
that,
like
my
brain,
was
turning
like.
D
Oh,
we
have
a
lot
of
work
to
do
and
docs
just
across
all
languages
for
this
kind
of
stuff,
but
I'm
glad
he
was
at
least
successful.
E
Yeah
we
realized
that's
like
the
the
hard
part
one
having
someone
who's
like
I,
don't
know
this
language,
or
this
thing
and
I'm
new.
It's
my
first
day,
it's
not
his
first
day,
but
acting
that
way
and
that's
when
you
start
seeing
the
different
perspectives
of
oh.
That
seemed
really
obvious
to
me
because
I
know
whatever
I
know,
but
to
someone
who's
brand
new.
It's
it's
not
obvious
and
then
I
feel
like
it's
with
anything
with
learning.
A
C
I
I
think
docs
are
a
really
good
place
for
this,
but
I
also
kind
of
Wonder,
like
I'd
love,
to
see
more
talks
like
at
conferences,
especially
ones
that
get
recorded
and
then
shared
around,
because
I
think
that's
also
like
just
fun
Medium
as
well.
I
think
blog
posts
can
be
fun
if
it
really
specifically
fits
your
need,
but
it's
like
I
think
also.
C
Talks
can
be
a
little
bit
more
like
Broad
and
tell
you
how
to
like
set
things
up
in
general,
but
yeah
I
think
docs
are
a
great
starting
point,
but
I
also
I
just
hope,
as
this
thing
becomes
more
popular.
We're
going
to
see
a
lot
more
of
that,
like
just
organic
people,
are
like
I
didn't
know
what
I
was
going
and
let
me
describe
that
hour
that
I
just
went
through
so
yeah.
B
Yes,
that's
a
hugely
important
step
in
getting
effective,
Ducks
right,
because
us
as
people
who
are
down
in
the
weeds,
fully
enmeshed
in
it,
we
don't
know
what
users
who
are
coming
to
it
from
the
first
time.
Don't
necessarily
know
right,
it's
it's
all
intuitive
to
us
because
we've
been
doing
it
for
a
long
time.
So
we
can
write
docs,
saying
here's
how
you
get
started
and
and
miss.
B
D
Right
right,
yeah,
once
you've
developed
your
curse,
knowledge,
you
don't
want
to
you're,
not
as
helpful
anymore
as
instead.
If
anybody
isn't
aware,
there's
the
I
think
it
conflicts
with
this
Zig,
but
there's
the
end
user
working
group
Sig
as
well.
That
Shar
is
starting
to
spin
up,
and
so
we
had
like
a
session
where
it
was
like
everybody
submits
their
topics.
There's
like
a
lot
of
asking
questions
and
people
talking
about
how
to
do
stuff.
D
D
Entertaining
those
I
definitely
would
recommend
reaching
out
to
char
or
anyone
in
that
sick
to
learn
more.
C
Yeah
I
thought
I
saw
that
they
were
conflicting
with
this
or
another
thing.
I
can't
quite
remember,
but
I.
Imagine
those
are
recorded
right.
Those
they're
on
the
zoom
meetings
right,
Phil,
okay,
yeah!
That
might
be
one
that
I
need
to
go,
find
on
YouTube,
Somewhere,
well,
cool,
yeah!
That's
a
good
suggestion!.
C
Nothing:
okay,
oh
one
of
the
other
things
is
I
mentioned
this
like
two
weeks
ago.
There
is
a
proposal
in
the
community
repo
to
have
Auto
instrumentation
using
ebpf
one
of
the
proposals
that
we
saw
a
little
while
the
POC
it
looks
like
it's
gonna,
be
accepted,
I
think
I'm,
asking
questions
now
around
how
we're
maintain
it
as
a
community
but
I
think
the
approach
is
something
that
the
community
currently
is.
Okay
with.
C
So
if
you
have
issues
with
it
which,
by
the
way
just
the
approach,
if
I
understand
it
correctly
and
I'm
I'm
a
butcher,
it's
like
I'll
read
the
issue
as
the
authority
docket,
but
they're
going
to
look
at
a
certain
subset
of
functions
and
a
certain
subset
of
instrumentation
or
in
packages
that
accept
context
and
then
use
the
context
to
help
propagate
span
context,
instead
of
using
go
IDs
to
try
to
track
processes,
so
it
sounded
interesting.
It
sounded
hard,
but
it
also
sounded
possible.
C
C
I
I
would
I
would
hope
and
I
so
I
don't
know,
but
I
would
hope
it's
its
own
repo
with
its
own
maintainers
and
approvers,
which
maybe
there's
gonna
be
some
crossover.
I
I
would
definitely
think.
Well,
there's
going
to
be
this
crossover
it's
going
to
use
up
until
it
should
go,
but
I
I
think
like
the
maintainer
and
the
people
that
they
might
cross
over
as
well.
I
I
would
hope.
C
There's
the
people
that
are
interested
from
this
project
that
are
interested
in
that
one
and
are
either
approvers
or
maintainers
I
I'm,
considering
asking
to
be
maintainer
but
I'm,
also
very
overloaded,
so
I'm
really
I'm,
really
hoping
somehow
bogdan's
ability
to
accomplish
things
at
an
unbelievable
Pace
Pace
are
somehow
comes
to
my
end,
but
haven't
gotten
there
yet.
C
Yeah
I
think
with
that
I,
don't
know
if
there's
anything
else,
we
need
to
talk
about,
so
we
can
probably
end
it
here
thanks
everyone
for
joining,
please.
If
you
haven't
already
go,
read
Jamie
and
Phil's
design,
talk
and
we'll
see
you
next
week
same
place
same
time,.