►
From YouTube: 2021-02-04 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
Yes,
I
had
a
some
additional
challenges
during
the
trip,
but
I'm
glad
you're
back.
D
E
B
Last
week,
basically,
as
I
was
saying,
zach
already
heard
the
story,
so
the
u.s
introduced
a
new
rule
that
you
need
to
take
a
covet
test
before
you
can
board
a
plane
and
you
know
sure
it's
well
intended,
but
so
you
have
to
do
this
most
most
countries
have
such
a
requirement
for
visitors.
B
B
B
Basically,
you're
stranded
like
I,
I
literally
have
no
polite
ways
that
that
can
be
expressed
in
a
recorded
meeting
to
say
what
I
think
about
it,
because
I
only
had
to
travel
two
hours
in
one
direction
to
take
a
test
and
two
hours
to
go
back
home
and
the
next
day
again,
two
hours
and
two
hours
to
pick
up
the
results,
and
but
some
people
might
be
in
a
situation
where
they
don't
even
have
that
opportunity
and
they
just
want
to
go
home
so
yeah
anyway.
B
A
All
right,
I
see
that
ted
join
us
today,
first
time
that
I
see
you
on
dotnet
stuff,
so.
G
G
Don't
know
you,
maybe
you
can
oh
yeah,
okay,
yeah,
my
name's
ted.
I
work
at
lightstep,
I'm
one
of
the
co-founders
of
the
project.
I
currently
spend
most
of
my
effort
working
on
the
spec,
and
lately
I've
been
doing
a
lot
of
work,
trying
to
get
us
to
1.0
and
to
get
tracing
stable,
so
figuring
out
a
lot
of
like
the
stability
guarantees
we
want
to
offer
and
like
how
versioning
is
going
to
work
and
all
that
stuff.
G
So
so
yeah
mostly
you'll,
see
me
on
like
spec
calls
and
things
like
that,
and
I
tend
to
do
a
lot
of
like
just
organizing
behind
the
scenes
so
but
yeah
it's
been
a
while,
since
I've
made
the
rounds
to
all
the
cigs,
and
so
I
thought
it
would
be
good
to
get
started
with
that.
So
yeah
nice
to
meet
you
all
as
well.
A
All
right,
I
I
think
we
can
go
to
the
first
topic
that
chris
put
there
for
for
us.
I
think
chris,
if
you
can,
share
the
dog
and
go
over.
B
I
actually
just
started.
I
started
today,
but
I
haven't
quite
finished.
C
Okay,
yeah,
so
what
I
threw
out
there
was
taking
it
it's
coming
from
the
viewpoint
that
we're
settling
on
a
single
semantic
convention
and
if
we're
doing
that,
then
there's
two
options
that
that
we
can
pursue
with
respect
to
handling
the
instrumentation,
and
so
one
was
fully
embracing
the
open,
telemetry
sdk
sooner.
C
The
other
is
to
continue
making
modifications
to
the
existing
open
trace.
Oh
tracer,
to
to
get
us
to
where
we
can
have
this
early
alpha.
A
I
I
I'm
gonna
just
give
my
opinion
kind
of
right
from
the
start.
In
this
regard,
I
think
we
should
be
be
going
to
the
option
that
we
do
independently
on
our
branch,
because
I,
I
think
the
the
challenge
to
integrate
directly
with
the
let's
call
sdk,
the
open,
telemetry
sdk
for
net
are
pretty
big.
You
know,
and
if
we
try
to
take
that
route
first,
we
are
going
to
be
a
long
time
until
we
can
have
kind
of
anything
that
we
can
really
ask
people
to
be
using.
B
And
when
you
say
also
chris,
when
you
say,
use
the
opening,
let
me
sdk
gmail
and
actually
reference
sdk
or
do
you
mean
just
use
the
same
conventions
as
they
do.
B
So
yeah
I
I
I
have
no
strong
opinion
about
this,
but
my
general
take
is.
We
should
do
the
minimum
necessary
to
to
like
become
sort
of
a
beta
version
stage
and
then
do
everything
else
based
on,
because
once
once
people
somebody
uses
us
for
for
real
people
will
start
making
requests
and
then
we
can
prioritize
work
according
to
that,
and
without
that
we
are
just
essentially
have
nothing.
C
Yeah-
and
so
I
think,
one
of
the
sticking
points
last
time
was
going
down
to
just
a
single
semantic
convention,
as
opposed
to
having
the
configuration
for
switching
between
both
theta
dog
conventions
and
open
telemetry
conventions
to
facilitate
the
merging
back
and
forth,
and
so
that
that
was
something
that
wasn't
talked
about
in
the
proposal.
But
I
just
wanted
to
ensure
that
we're
all
on
the
same
page
there
in
the
last
sig
meeting
I've
mentioned
concerns
of
that
approach,
with
at
least
some
of
the
probably
data
store
instrumentation.
C
C
B
I
mean
what
what
specifically
is
the
delta?
It's
just
the
names
of
the
of
the
tags,
or
what
else
is
there.
B
C
A
A
Log,
sorry,
I
mean
span
logs
that
these
are
things
that
are
attached
to
a
span,
but
they
have
a
time
stamp
and
I
use
it
for
things
even
like
record
exceptions.
For
instance
great.
B
So
basically,
what
you're
saying
is
we
can't
just
we
can't
just
do
the
plugin
at
export
time.
We
need
to
do
this
when,
when
spencer
created.
C
B
Yeah,
I
think
I
think
I
think
that's
not
necessary.
The
the
challenge
is
slightly
different.
I
think,
but
please
to
correct
me
so
essentially
datadog
because
of
datadoc
makes
you
so
many
contributions.
B
So
the
challenge
is
twofold:
first,
we
need
to
have
as
little
work
as
possible,
integrating
in
one
direction
and
then
second
is
we
want
to
make
it.
It
should
lower
the
burden
to
integrate
in
another
direction
right.
So
it's
not
so
much
about
supporting
two
things.
Using
configuration
it's
more.
B
How
can
we
structure
the
code
so
that
it
flows
easily
and.
A
Yeah,
so
just
for
me
to
reward
what
we're
saying
confirm.
So
in
that
sense,
it's
very
it's
high
priority
for,
for
your
perspective,
that,
with
whatever
we
do,
we
do
in
a
way
that's
easy
for
things
to
go
back
and
forth
between
the
ripples.
B
Yeah,
I
I
just
I
just
I
just
like
I
and
I
I
keep
saying
it's
this
I
realize
it
like
says
the
same
thing,
but
to
me
it's
like
the
the
most
important
thing
is
once
once
auto
has
shipped
and
therefore
became
more
important,
there's
more
resources,
and
then
it
might
change.
But
right
now,
just
because
of
the
sheer
amount
of
contributions
that
are
flowing
from
data
dog
to
open
telemetry.
B
It
will
be
the
case
that
it
would
be
hard
to
convince
the
datadog
product
people
to
to
spend
a
lot
of
work
on
making
things
that
benefit
open
telemetry,
but
do
not
benefit
datadog.
Even
they.
If
they
don't
damage
data
dock,
it
still
will
be
time
spent
right.
So
so,
if
we
want
to
make
refactorings
that
need
to
flow
back
into
data
docs
so
that
we
can
make
the
code
flow
and
support
all
the
conventions,
I
think
and
zac.
I
would
be
curious
about
your
perspective.
B
I
think
it
will
be
fine
as
long
as
it's
very
clear
that
there
is
no
performance
impact
and
the
work
overhead
for
the
data
dock
is
not
like.
It
is
basically
appropriate.
You
know
if
we,
if
we
have
to
go
and
rewrite
all
our
tests
and
like
re-run
all
of
our
stuff
and
all
of
these
things
we'll
just
say
no.
This
is
too
much
work,
but
for
no
benefit.
We're
not
going
to
take
this
integration
back
from
auto
intro
into
data
datadock.
B
But
if
you
say
okay
guys,
all
you
need
to
do
is
every
time
you
are
putting
tags
on
a
span.
You
need
to
have
like
one
layer
of
indirection
that
is
like
resolved
at
compile
time,
therefore,
not
really
adding
any
runtime
overhead
so
that
you
call
some
method
called.
I
don't
know,
put
tags
on
spam
and
and
this
method
can
be
kind
of
dependency
injected
at
compile
time,
either
using
a
open,
telemetry
kind
of
tag,
putter
or
a
datadog
tag
put
or
something
like
that.
B
It
will
be
okay
because,
like
we
just
take
the
one
integration
back
and
everything
is
fine
and
we
understand
that
we
haven't
actually
actually
the
the
great
performance
we
have
made
the
code
slightly
more
complicated,
but
we
wanna
like
be
all
together
in
the
same
boat
and
the
open
telemetry
guys
benefit,
because
now,
when
we
continue
making
new
integrations
or
fixing
existing
integrations
or
whatever
it
it,
you
know
it's
easily
flowing
in
both
directions.
Do
you
see
what
I
mean
so
and
zach?
A
So
just
also
trying
to
clarify
here,
because
I
had
the
impression
that
perhaps
I
mistaken
this,
but
I
had
the
impression
that
perhaps
the
preferable
scenario
for
you
in
that
context
will
be
to
have
kind
of
a
runtime
config
that
can
tell
which
you
want
to
use.
A
But
you
are,
it
seems
that
is
also
fine
if
it's
a
build
time
requirement
as
long
as
doesn't
impact
the
the
cost
both
if
it's
a
build
runtime
doesn't
should
not
affect
their
runtime,
but
also
that
doesn't
affect
the
flow
of
contribution
between
the
the
the
two
sides.
B
B
So
if,
if
given
these
two
requirements,
such
me
are
much
more
important
than
compile
time
versus
runtime,
if
compile
time
is
easier,
I
would
go
for
it
and
then,
if
in
some
future,
runtime
becomes
a
thing,
then
we
can
talk
about
it.
E
Yeah,
I
I
completely
agree,
I
think,
last
time
too,
I
was
expressing
that
it
didn't
matter
to
me
if
we
decided
to
do
the
like,
we
didn't
have
to
have
like
side-by-side
choosing
at
runtime
like
sort
of
strategy
like
we
don't
need
that
and
that's
so
if
we,
if
we
choose
to
do
compile
time,
that's
completely
fine,
whichever
way
is
going
to
make
it
easier
for
us
to
individually
work
on,
you
know
implementing
one
versus
the
other,
so
that
otel
can
make
progress
and
datadog
can
make
progress
without
overlapping
or
overstepping
on
each
other.
A
Great,
I
think
we
have
clarity
on
this.
It
was
something
that
it
was
like
from.
I
think
the
the
early
discussion.
A
I
think
this
gives
the
path
that
we
should
go
now
and
actually
to
be
fair.
I
wanna
think
later
with
greg
about
the
status
of
the
activity
source
stuff,
but
actually
I'm
planning
to
prioritize
this
experimentation
path.
You
know,
so
we
can
start
really
to
dog
food.
C
It
will
look
vastly
different
than
what
we
need
to
do
to
honor
the
to
get
all
the
data
that
that
meets
the
hotel
semantic
conventions,
and
so
those
two
instrumentation
implementations
would
look
quite
different.
C
I
unfortunately
I
don't
have
a
concrete
example.
I
suspect
that
the
data
store
instrumentation
will
likely
be
the
ones
where
we
see
this
the
most
just
just
because
the
different
types
of
data
that
get
collected
there.
B
So
I
would
say
if
this
is
numerous,
that
if
this
is,
if
there
are
tons
of
examples
like
this,
then
of
course
maybe
we
need
to
talk
again,
but
if
there
are
only
a
few
of
them,
one
thing
to
consider
is
essentially:
if
data
dock
has
more
data,
then
it's
okay.
It's
easier.
B
We
just
put
subset
on
open
telemetry,
but
if
open
telemetry
has
more
data,
then
we
can
probably
we
should
just
do
the
work
on
data
dock
side
to
add
the
additional
data
that
is
expected
for
by
open
telemetry
choose
this
particular
integration
that
is
affected.
B
Of
course
we
need
to
look
at
the
specifics,
because
if
it's
just
a
tracer
side
change,
then
we
can
just
do
it.
If
it's
some
back-end
change,
then
we
may
or
may
not
be
able
to
do
it,
but.
B
Most
of
these
things
are
just
span
tags
on
the
span,
so
most
of
this
will
probably
be
client-side
change
and
basically
I'm
just
the
way.
I
understood
your
your
your
example.
Please
correct
me
if
I'm
wrong,
it's
something
like,
for
example,
datadock
right
now
collects
only
database
name,
but
opentelemetry
also
collects
stable
name,
and
I
don't
know
column
name
for
a
query
just
making
it
up
and
to
make
things
equivalent.
B
We
need
to
collect
more
information
so
well,
let's
change
the
integration
to
collect
all
of
these
three
things
and
then
still
use
this
layer
of
direction
to
use
the
different
convention.
C
Yeah,
so
so
that's
something
that
could
work
without
hopefully
creating
a
ton
of
overhead
for
for
both
sides.
I'm
just
wondering
in
the
long
term,
if
it
makes
sense
to
to
continue
to
maintain
that
complexity
or
if,
at
some
point,
the
instrumentation
for
open
telemetry
will
just
be
different
enough.
B
G
Know
not
to
I
mean
I'm
new
here,
but
we've
taken
a
lot
of
data
dog
contributions
in
other
languages
and
in
all
those
cases
it
was
just
a
one-way
contribution
and
in
fact
we
require,
as
part
of
it,
for
the
license
files
to
change
and
to
hand
the
copyright
over
to
open
telemetry
authors.
G
Part
of
this
was
because,
as
other
people
start
working
on
this
stuff,
it
be
felt
like
like
favoritism
or
a
conflict
conflict
of
interest,
and
so
we
ended
up.
You
know
requesting
that,
if
anyone's
going
to
donate
stuff
to
open
telemetry
that
it
that
it
that
be
handed
over
whole
hog
and
be
open,
telemetry
focused-
I
I
don't
know
the
details
about
how
you
guys
are
trying
to
set
this
up,
because
I
don't
know
much
about
net
or
auto
instrumentation
and
net.
But
I
will
say
yeah
like
long
term.
G
G
That's
trying
to
happen
so,
like
tyler
benson,
initially
tried
to
keep
the
java
auto
instrumentation
and
I
think
a
similar
thing
and
but
like
threw
in
the
towel.
I
think,
a
year
ago,
on
that.
B
I
I
I
sort
of
agree
on
a
from
an
ideological
standpoint
if
I
wear
like
an
open,
telemetry
head
the
reason
I
am
actually
saying
this.
I
know
it
sounds
contradictory,
but
it's
not.
Let
me
explain
so
when
I
say
these
things.
I'm
actually
feel
like
I'm
more
representing
the
interest
of
open
telemetry
rather
than
data
doc
in
this
particular
case,
because
the
thing
is
the
reality
of
things
right
now
and
it
may
change
in
the
future.
If
it
changes,
things
will
be
different,
but
right
now,
specifically
for
our
project.
B
There
is
just
not
a
huge
amount
of
contributions
that
are
not
coming
from
datadog
that
are
coming
from
other
sources
and
because
of
that,
if
we
make
it
a
hard
for
datadog
to
contribute,
they
will
simply
say
well
fair
enough
guys,
you
you're,
free
to
take
it
anytime,
you're
free.
We
donated
things
and
you're
you're
happy
to
integrate
the
flow
like
any
time,
but
we
have
already
donated
the
things
at
some
point
and
we
can't
spend
a
lot
of
cycles
to
kind
of
architect
for
open
telemetry.
B
So
so
now,
when,
once
the
open,
telemetry
project
reaches
a
critical
mass
and
it
can
live
by
itself,
I
think
what
you
say
is
completely
right
and
you
kind
of
can
fork
and
then,
if
you
know,
you
can
really
be
completely
focused
on
open
standards
right,
but
before
it
reaches
a
critical
mass.
If
you
essentially
say
we
make
it
so
hard
for
the
code
to
flow
in
in
that
direction
that
it
hardly
ever
flows,
then
what
keeps
open
telemetry
the
open,
telemetry
fork
alive.
G
So
I'm
I'm
wondering
what
so.
What's
the
and
again,
I
don't
know
there's
boundaries
of
this
project
like
I'm,
actually
curious
how
this
relates
to
like
the.net
core,
I
kind
of
presume
it's
similar
to
the
way
the
java
agent
relates
to
like
the
core
java
stuff.
But
I
know
a
lot
of
this
is
getting
like
integrated
into
net
itself.
G
So
I'm
pretty
fuzzy
about
like
how
all
that
works,
but
I'm
just
wondering
what
what
the
actual
overhead
is
like
if
they
were
just
just
forks
of
each
other
like
what
it
would
just
be
like
the
issue
of
having
to
copy
paste
code
from
like
one
code
base
to
another,
or
is
it
that
like
this,
is
under
like
really
rapid
development,
or
something
like
that,
and
so
it's
it's
not
easy
to
just
like.
A
Let's
say,
and
we
are
moving
kind
of
slowly,
because
we
have
the
architectural
internal
issue
that
we
kind
of
started
to
focus,
but
we
decided,
by
kind
of
the
end
of
last
year
that
we
want
to
take
a
different
approach
that
is,
to
allow
us
to
experiment
more
with
the
open
telemetry
itself
and
it
in
that
approach
that
we
start
to
reach
these
questions
first,
without
resolving
the
thing
about
the
runtime
type
and
that
that's
a
separate
discussion,
I
can
provide
you
with
a
link
with
the
dog
for
that.
A
So
but
right
now
it's
we
are
not
moving
fast
on
the
open,
telemetry
side.
You
know,
that's
that's
the
reality
of
the
project.
At
this
moment
you
know.
I
think
that
if
I
take
what
I
see
happening
and
thinking
about
open
telemetry,
I
think
that
at
this
moment
our
interest
is
trying
to
keep
as
close
as
possible
with
the
data
dog.
A
I
can't
I
can't
even
guess,
with
any
kind
of
reasonable
information
when
that
should
be
happening,
but
I
think
this
is
the
path
that
I
see
so
on
the
short
run,
I
want
to
make
a
hotel
releases
that
people
can
use
following
the
integrations,
the
standards
of
open,
telemetry
specification.
A
But
I
wonder
people
start
to
use
open
telemetry,
so
you
can
gain
the
momentum
you
know
so
after
you
gain
that
momentum,
then
I
think
in
the
future
then
becomes
a
real
thing
that
then
data
dog
can
see
the
open
telemetry,
as
their
solution
makes
sense.
G
Yeah,
I
think
so
so,
just
to
clarify,
I
think
the
situation
I
know
that.net
is
open,
telemetry
is
looking
to
1.0,
and
that
is,
I
believe,
like
core
instrumentation
and
dotnet
itself,
plus
the
open,
telemetry
apis
and
sdks.
G
G
Right,
and
so
this
is
just
like
a
sort
of
this
sort
of
like
how
java
went-
this
is
a
separate
project,
and
so
it
would
be
coming
over
and
it
currently
doesn't
make
use
of
the
open,
telemetry
sdk
or
any
of
that
other
stuff.
G
And
so
it's
the
plan
right
now
to
to
like
switch
it
over
to
to
using
like
open
the
open,
telemetry,
sdk
and
all
of
that,
but
you're,
saying
you're,
saying
like
that,
would
make
it
hard
to
keep
the
two
of
them
in
sync,.
B
So
think
about
this,
so
it's
not
about
branding
statements
right,
so
open
telemetry
is
a
con
standard
and
also
an
implementation
of
a
standard
using
the
sdk
right
yeah.
So
for
technical
reasons
that
if
you
like,
we
can
explain
it
does
very
much
make
sense
for
an
open,
telemetry,
auto
instrumentation
solution
to
use
the
standards,
but
not
the
sdk
right
I
mean.
B
You
know
yes,
it
has
to
do
with
version
conflicts,
library,
conflicts
and-
and
things
like
that,
but
I
think
in
the
long
term
and
people
might
agree
or
disagree.
In
my
opinion,
it
should
not
be
the
goal
of
open,
telemetry,
auto
instrumentation,
to
use
the
sdk
as
an
implementation
detail.
It
should
play
nice
with
the
sdk
as
an
er.
G
So
okay,
does
this
mean
what
about
manual
instrumentation,
interacting
with
the
automatic
instrumentation.
B
Manual
instrumentation
in
the
long
term
should
be
done
using
either
the
open,
telemetry,
sdk
or
the
net
apis
which
are
compatible
with
the
open,
telemetry
sdk
and
the
autumn.
Instrumentation
should
be
able
to
play
nice
with
it.
So
you
know
spans
should
be
able
to
kind
of
interject
and
do
the
right
things
and
whatnot.
G
Right
like
I
would
expect
the
you
know
that
you're
going
to
auto
install
the
instrumentation
for
your
framework
and
your
database,
clients
and
stuff,
but
then,
as
an
application
developer,
you
want
to
add
your
own
instrumentation.
G
So
it
is
a
goal
to
make
sure
like
that:
that'll
actually
work,
yes,
okay
and
then
on
the
sdk
side.
I
think
that's
more
about
people
wanting
to
be
able
to
install
exporters
and
other
kinds
of
plug-in
samplers
and
things
like
that.
Would
the
the
auto
instrumentation
being
separate
from
the
sdk
like
cause
an
issue
there.
B
B
I
personally
believe
it
not
only
shouldn't,
but
also
must
not
for
a
good
reason,
namely
when
you
are
talking
about
the
sdk,
then
you
as
an
application
developer
will
plug
in
whichever
exp
exporters
you
want,
and
then
you
will
rebuild
your
application
retest
the
application
decide
that
you're.
You
convinced
yourself
that
it's
good
enough
and
then
you
will
deploy
it.
However,
in
an
auto
instrumentation
case,
the
plugins,
the
the
data
export
is
essentially
now
became
part
of
your
environment,
because
the
the
trace
is
part
of
the
environment.
B
It's
something
you
attach
to
a
running
application.
We
should
limit
the
opportunities
that
the
customer
of
so
there
is
no
open
telemetry.
Now
there
is
a
vendor
like
splunk,
who
takes
open,
telemetry,
auto
instrumentation
and
customizes
it
so
splunk
as
a
vendor
should
very
much
be
able
to
plug
in
things
whatever
they
need.
But
now
splunk
has
a
customer,
I
don't
know
mysite.com
and
they
should.
B
They
should
have
very
limited
opportunity
to
programmatically
configure
exporters
and
plugins,
because
that
is
part
of
of
splunk's
decision
how
much
opportunity
they
want
to
give
to
their
customers.
For
that
not
open
sources,
because
splunk
might
say:
oh
our
customer
should
do
it.
What
plug
must
say?
B
No,
our
customers
should
not
be
able
to
do
it,
because
then
we
have
to
support
them
after
they
made
crazy
customizations
and
we
don't
want
to
support
them
so
so
because
of
that
the
the
the
plugins
that
should
be
there
on
the
vendor
side
rather
than
on
the
customer
side.
However,
we
should
certainly
play
nice
with
the
sdk.
G
If
you
switch
between
like
auto
installing
the
plugins
versus
manually
installing
the
plugin.
G
B
So
for
context
you,
you
brought
up
java
now
a
few
times
so
the
biggest.
B
So
there
was
somebody
who
has
resourced
a
significant
amount
of
resources
to
work
on
open,
telemetry,
auto
instrumentation
solution
like
with
full-time
or
even
more
than
one
person
and
like
committed
and
whatnot
right,
and
because
of
that
that
project
could
afford
to
diverge
from
from
datadock
where
it
originated
and
be
alive
and
develop
right
right
now.
Everybody
who
contributes
to
the
net
part
or
equivalent
is
doing
it
part
time.
B
B
The
the
whatever
the
ideal
architectural
solution
might
be.
Reality
is,
we
must
make
it
within
the
constraints
of
people
only
working
in
part-time.
If
we
we-
which,
if
we
plan
for
something
that
requires
people
to
work
full-time,
then
it
will
just
not
happen
for
now
when
changes
when
it
changes,
it
changes
and
we
will
readjust
so.
G
This
is
like
the
perfect
being
the
enemy
of
the
good
enough
you're,
saying
that
it's
it's
moving
slow
enough
that,
like
the
the
reasonable
solution,
would
be
to
just
like
try
to
cobble
something
together.
That's
just
a
based
off
data
dog
and
if
more
resources
show
up,
then
that
thing
can
get
worked
off
on
its
own
at
that
point,
and
if
people
want
to
do
the
work
of
making
it
directly
use
the
sdk
or
whatnot
or
do
all
of
that
stuff
exactly.
B
Essentially-
and
you
guys-
please
please
correct
me
if
I'm
wrong
the
way-
I
see
the
realistic
way
forward
for
the
immediate
future.
Not
long
term
is
to
keep
integrating
code
from
datadog
without
making
them
making
it
too
hard,
because
we,
every
time
we
integrate
the
code
when
it
should
do
work
and
it
takes
time
and
then
do
the
minimum
amount
of
modifications
on
top
of
data
doc
continuous
integration,
the
minimum
amount
of
delta.
That
is
required
to
say
that
we
it's
it's
open,
telemetry
like
enough
to
make
it
official
open,
telemetry
beta.
B
It
requires
adhering
to
some
conventions
and
a
few
other
things
that
that
paolo
has
on
the
list
and
not
more
than
that,
because
if
you
shoot
for
more,
it
will
take
you
long.
Okay,
yeah.
A
Yeah
thanks
yeah
ted.
If
you
check
I,
I
have
at
least
like
five
bullet
points
kind
of
what
I
consider
what
we
need
to
do,
a
reviews
in
in
the
previous
meeting
I
put
there
you
check
that
it's
the
very
minimum
and
fits
this
picture
that
we
we
talked
about.
You
know
yeah
and
I
think
there
we
can
build
the
momentum
to
kind
of
eventually
get
to
that
future
future
that
we
want
for
our
open,
telemetry
distribution.
G
Yeah,
no,
that
makes
a
lot
of
sense.
I
mean,
I
definitely
know
yeah
on
the
java
side.
It
was,
you
know,
a
fair
amount
of
work,
but
because
trask
was
on
it
full
time,
in
addition
to
tyler
that
it
was
you
know,
trask
was
the
beast
and
he
was
able
to
to
just
kind
of
shovel
a
lot
of
that
stuff
in
and
that
made
it
feasible.
Okay,
thanks.
A
G
I'll
check
in
with
lightstip
to
see
I
mean
we
do
have.
We
don't
have
like
a
lot
of
c
sharp
talent
over
here,
but
I'll
see.
If
we
do
have
someone
who
can
can
help
out
more-
and
I
do
know
that
like
honeycomb
has
at
least
one,
I
know
the
dot-net
person
at
honeycomb,
so
I'll
ask
around
and
see
if
we
can
get
some
more
resources
over
here.
B
Yeah
and
that's
the
context
why
I'm
kind
of
saying,
let's
make
it:
let's
make
data
dot
compatible,
let's
make
a
data
compatible
actually
by
saying
that,
I'm
looking
out
and
while
wearing
this
particular
hat,
I'm
actually
looking
out
for
open
telemetry
changes,
not
data
log
interest,
because
right
now
the
live
comes
from
from
the
data
contributions
and
we
make
it
just
easy.
So
so
yeah,
okay.
G
C
Greg
there
is
a
use
case
that
I
want
to
call
out
that
wasn't
mentioned,
but
I
am
seeing
it
happen
at
new
relic
right
now.
Okay,
that's
that's
where
we
have
people
who
are
using
open,
telemetry
and
they're
using
the
the.net
sdk,
but
there's
instrumentation
gaps
there,
and
so
that's
where
they're
wanting
to
leverage
some
auto
instrumentation
to
to
fill
in
some
of
those
instrumentation
gaps,
postgres
being
one
of
the
like
the
most
common
ones,.
B
So,
but
what
what
is
specifically
the
scenario
that
you
mean,
the
scenario.
B
B
So
that
requires
dealing
with
activities.
Well,
no
actually
does
it
for
now
it
only
requires
dealing
with
diagnostic
source.
B
But
but
they
have,
they
have
an
application
that
uses
open,
telemetry
or
sdk,
meaning
activity
or
diagnostic
source.
B
But
there
are
so
sorry,
but
when,
when
you
say,
they're
able
to
see
most
of
the
things
using
open
image,
sdk
does
it
mean
that
it's
custom
instrumentation
using
activities
or
does
it
mean
that
the
library
is
emitting
diagnostic
source
events
and
the
open
telemetry
is
the
key,
collect
them
and
turn
and
send
them.
C
Most
likely
the
la
the
latter
okay,
so
like
asp.net
core,
for
example,
okay
and
http
client,
those
are
all
diagnostic
source,
instrumented
and
so
on
so
either
way.
The
open,
telemetry
sdk
allows
out
of
the
box
visibility
for
the
application,
however,
they're
not
getting
visibility
into
their
postgres
database
calls
and
because
there's
no
diagnostic
source
or
activity
source
instrumentation
for
that
library.
I.
B
Wish
we
had
a
one
or
two
customers
having
the
same
problem,
because
that
would
make
our
product
guys
resource
the
diagnostic
source,
versioning
problem,
full-time.
E
C
A
It
yeah
so
so
these
these
goals
for
the
long
pole
work,
I
don't
see,
because
then
we
need
to
support
the
achieved,
an
activity
source.
It
goes
to
the
wrong
pole,
but
I
think
yeah.
This
is
a,
is
a
go
for
the
long
pole
work
about
supporting
the
open,
telemetry
api
and
I
I
just
to
make
the
terminology
a
little
bit
better.
A
I
would
say
the
following:
the
auto
instrumentation
looks
to
work
with
the
open,
telemetry
api
instrumentation,
but
the
plans
to
support
the
sdk,
that's
the
one
that
substantiates
exporters,
and
this
thing
that's
the
really
part
I
think
greg
was
talking
about
the
distributions
and
the
conflicts
that
we
have
there.
A
I
think
a
reasonable
first
goal
and
then
is
further
down
the
road
we
can
discuss
about
the
sdk,
but
it's
support
to
open
telemetry
api,
but
but
to
be
fair
to
be
fair,
the
priorities
that
I'm
looking
for,
I'm
being
more
modest
than
that
you
know
I
I.
B
And
I
think
what
I
see
as
a
goal
is
one:
we
take
no
dependencies
on
open,
telemetry
api,
so
there
is
no
no
dealing
with,
but
if
somebody
has
a
telemetry
that
is
emitted
using
open,
telemetry
api
where
compatible
source
and
also
auto
stimulation
telemetry,
then
it
interjects
correctly,
because
you
know
you
can
have
a
span
emitted
d1,
then
inside
of
it
experimented
the
other
and
so
on,
and
it
should
be.
The
nesting
should
just
work
yeah
and.
F
G
Cool,
I
have
a
dumb
question,
but
is
it
feasible
to
for
cases
where
people
are
already
just
manually
installing
everything
but
they're
missing,
like
plugins
for
certain
things
to
just
extract
extract
those
instrumentation
packages
from
the
auto
instrumentation
and
like
install
them
manually
or
is
like
that
method
of
instrumentation.
A
G
The
question
is
for
the
use
case
of
someone
saying
like
I'm
using
the
sdk,
I'm
to
it
as
a
way
of
like
avoiding
the
issue
of
auto
instrumentation,
the
the
auto
instrumentation
mixing
with
the
sdk
for
the
time
being,
if
someone's
like.
I
just
need
postgres
instrumentation
added
to
this
system.
G
A
Yeah,
so
so
to
give
the
context
greg
in
java,
you
could
pick
up
a
package
that
does
the
experimentation
for
that
specific
thing
and
put
there.
You
know
basically,
that
we,
without
all
the
machinery
that
we
have
to
emit
the
ia
or
kind
of
it's.
G
This
is
definitely
the
case
in
java,
where
it's
not
like
you're
manually,
installing
an
sdk
and
also
installing
the
auto
instrumentation.
It's
just
that
like.
If
you
install
the
agent
any
manual
stuff,
you
write
still
works.
It's
not
that,
like
the
sdk
has
to
work
together
with
the
auto
instrumentation.
If
that
makes
sense,
it's
just
being
able
to
intercept
the
open
telemetry
api
calls.
A
Yeah,
I
think
I
think
that
that
is
where
you're
gonna
go
and
but
once
more
that's
the
long
pole
that
we
have
to
work
on
the
to
deal
with
the
runtime
type.
That
brings
a
lot
of
complications.
A
A
A
So
I
I'm
good
and
I'm
I'm
gonna-
do
some
initial
work
on
that
kind
of
try
to
separate
one
thing
about
the
config
that
we
mentioned.
So
we
can
inject
more
open,
telemetry,
config
and
kind
of
some
of
the
stuff
that
I
notice
when
pulling
changes
from
upstream.
Just
to
kind
of,
perhaps
I
want
to
make
some
class
partial
and
just
have
a
file
on
the
hotel
side,
because
then
how
the
hotel
code
is
isolated.
It's
my
stuff
like
that,
but
then
I'll
put
in
pr's
and
zack
greg
tony.
B
Yeah
yeah,
hey
by
the
way,
david
thanks
for
your
email.
I
responded
yesterday
about
the
stick,
walking
things
yeah
yeah
I
saw
it.
I
just
haven't
responded
yet
yeah
yeah.
So
that's
that's
a
whole
exciting
different
conversation
where
we
can
chat
about
that.
One
of
these
yeah.
F
B
Of
these
days
and
on
a
on
a
side
note
so
noah
was
asking
about
and
guys
for
you.
This
may
be
relevant.
So
noah
was
asking
about
comments
on
a
api
edition
that
they're
looking
at
that
is
targeted
at
customizing
the
trace
id.
B
So
basically
the
scenario
is
say:
you
are
you're,
creating
a
you're
instrumenting
the
application
and
you're
either
a
vendor
like
us
or
you're
the
application
server.
Now
a
trace
id
comes
you're,
creating
a
new
spam
when
you,
when
you.
B
When
you
are
receiving
the
the
the
sorry,
I'm
I'm
losing
it
when.
G
B
Receiving
the
request
you
are
creating
a
new
span
and
right
now
the
trace
id
of
the
span
is
generated
automatically
by.net,
based
on
the
trace
context
that
is
provided
to
activity.start.
B
Exactly
thanks
david
and
some
people
requested,
including
myself,
can
we
please
customize
the
creation
of
the
trace
id
just
in
case
you
don't
want
to
use
the
w3c
standard,
you
want
to
use
something
different
or
what
not
so
they're
having
an
applied
proposal
of
how
to
do
this
so
feel,
free
to
comment.
If.
B
Essentially
has
the
same
request
as
we
had
datadog.
They
have
a
little
scope
down.
I
suggested
two
sources
for
both
trace
id
and
span
id.
They
only
needed
solved
for
trace
id,
which
is
fair
enough
and
so
yeah
take
a
look
and
one
other
thing.
Actually
I
don't
know
whether
david
you
have
any
context
on
this,
something
that
we
encountered
related
to
activities
so
back
last
year
I
discussed
in
on
github.
B
Can
we
please
modify
activity
properties
not
during
start
but
later,
because
it
seems,
like
the
whole
open.
Telemetry
architecture
is
conceptualized
so
that
once
activity
is
started,
you
no
longer
modify
its
tags
and
then,
but
at
that
time
I
struggled
for
a
good
example
why
we
want
to
modify
the
activity
later
after
it
created.
I
had
a
strong,
intuitive
feeling
that
it
will
come
up,
but
I
couldn't
actually
give
a
good
example,
but
now
I
can
so
say
we're
instrumenting,
an
application
that
use
that
doesn't
process
requests.
B
So
this
the
span
begins
before
I
put
the
call
on
the
wire,
but
a
lot
of
interesting
information
about
the
the
span
is
only
can
be
extracted
from
from
from
after
the
call
on
the
y
returned
right
because,
like
lots
of
irrelevant
stuff
is
actually
in
the
message,
the
whole
context,
propagation
from
from
the
the
guy
who
put
stuff
into
the
queue
yeah,
I
only
have
it
after
I
received
the
response.
B
Okay,
so
so
in
that
context,
maybe
4.6
we
can
revisit
the
this.
This
this
whole
thing.
H
So
maybe
I
don't
remember
enough
about,
I
remember
the
issue
and
you
filed
and
it
was
too
close
to
5.0.
I
would
either
reopen
that
issue
or
file
a
new
issue
with
the
additional
thing,
because
I
I'm
not
actually
all
that
involved
in
the
managed
api
service
area.
So
that's
tark
and
noah,
and
so
I
can
tell
you
maybe
we
can
revisit
it.
But
I
don't
remember
enough
of
the
details
to
tell
you
if
it's
yeah
sure.
C
H
B
I
think
I
think
the
if
there
was
if
there
was
even
a
desire
to
change
anything
that
would
more
be
inside
of
the
open
telemetry
code
rather
than
the
net
code.
Okay,
because
dotnet
only
made
the
recommendation
to
never
change
those
properties,
while
open
telemetry
actually
took
a
dependency
on
that
yeah.
B
Okay
sounds
good
cool
yeah,
guys
thanks
david
for
posting,
the
link,
so
if
you're
interested
in
the
other
and
the
trace
id
generation
stuff,
then
take
a
look.