►
From YouTube: 2021-09-29 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
C
C
Folks
can
add
their
names
and
looks
like
we
have
a
few
agenda
items
if
you
can
fill
in
any
additional
agenda
items
that
folks
have
that
they
want
to
discuss
today.
That'd
be
great.
D
D
D
Any
comments
or
yeah
there
is
a
document
under
this
pr
I
can.
I
can
send
directly
to
chat.
D
So
yeah,
basically,
this
document
has
two
main
sections:
this
roadmap,
which
is
really
kind
of
just
just
a
proposal,
and
basically
this
this
one
contains
some
stages
that
we
need
to
go
through,
and
the
second
part
is
is
about
scope,
so
we
have
some
scenarios
and
open
questions
that
we
need
to
cover.
D
D
So
if
you
go
through
these
scope
items,
we
had
some
discussions
internally
in
microsoft
and
those
items
that
were
defined
there,
but
definitely
will
be
interesting
to
get
more
ideas
and
more
feedback
on
this.
So
do
you
want
me
to
go
through
all
the
items
that
we
have
here
just
to
provide
some
really
brief
context?
D
Yes,
please
right,
okay,
so
the
first
one
is
about
error
status.
So
basically,
we
currently
have
all
the
like
a
forex
responses
or
response
codes
treated
as
error,
but
in
many
cases
it
should
be
defined
by
the
application
owner.
So,
for
example,
this
40409
is
something
that's
sometimes
is
not
actually
an
error.
D
But
yeah
we
have
a
lot
of
different
opinions
here
and
it
will
be
worse
to
discuss
and
make
it
done.
Another
one
is
about
different
at
like
at
this
required
attribute
sets.
So
currently
we
have,
we
are.
We
have
like
a
specify
that
url
should
be
required,
but
if
not
then
like
the
following
attributes
or
attribute
sets
also
should
be
defined
like
scheme
host
and
targets
or
scheme
pure
name
purport
and
target,
and
so
on.
D
D
So
the
proposal
here
might
be
to
like
a
define
some
attributes
or
attribute
set,
which
is
which
the
only
should
be
required,
and
it
also
can
be
defined
like
a
differently
for
client
and
server,
just
because
on
client
we
have
url
like
a
as
a
string,
but
on
server.
Sometimes
it's
not
not
like
the
url
as
a
string
is
not
materialized.
D
So
we
have
a
scheme
host
and
target
there,
so
we
can
just
say
that,
for
example,
for
client
http.url
should
be
required,
but
for
server
like
a
scheme
scheme,
a
hosting
port
should
be
required
and
that's
it
so,
no
other
options
like
available,
but
yeah.
This
is
just
this
purple,
so
the
third
one
is
is
about
like
this
optional
attributes.
D
So
basically
we
just
need
to
define
like
which
attributes
should
be
or
like
which,
which
are
optional
and
for
library
owner
it
makes
sense
to
to
set
just
because
we
we
should
should
not
like
we
should
not
be
overwhelming,
and
the
context
should
be
should
be
clear
for,
like
their
library
owners,
the
next
one
is
about
read
rights,
redirects
and
possibly
hedging
policies.
D
So
the
idea
here
is
that
so
we
can
have
top
level
spam
for
retries
and
redirects,
and
maybe
hedging
policies
as
well,
so
it
can
be
like
a
set
for
it
can
be
visualized
with
different
layers,
so
the
top
level
span
can
have
what
can
actually
can
correspond
to
like
an
api
operation
and
next
next
spans
canon
by
like,
at
this
rate,
rise
or
redirects.
D
So
that's
gonna
be
the
option.
Another
option
will
be
just
to
have
all
of
them
as
siblings
and
third
option
basically
can
be
just
have
one
one
spam
and
basically
high
height,
all
these
retries
and
redirects.
So
this
is
something
that
can
be
can
be
set
as
a
configuration,
probably,
but
that's
something
that
we
need
to
address
as
well
sampling.
The
next
item
is
about
sampling,
basically,
that
this
one
is
about
like
which
attributes
we
need
to
set
free
sampling
and
which
attributes
make
sense
to
set
post
sampling.
D
So,
for
example,
if
you
have
if
we
identify
a
particular
spam
to
be
simple
out,
probably
it
makes
no
sense
to
set
duration
and
like
a
status
and
all
this
stuff,
so
another
one
is
so.
The
next
items
are
like
not
not
so
clear,
so
the
one
is
related
to
context.
Propagation
basically
is
like
do
we
want
to
like
reuse
all
the
information
that
we
have
for
http
client
or
from
underlying
layers,
basically
to
include
them
to
the
to
the
spans
that
we're
generating
another?
D
So
that's
basically
some
scenarios
that
then,
when
we
have
some
long-running
operations
on
server,
and
we
want
to
also
like
identify
this
operation,
somehow
the
same
actually
or
not
same
with
really
similar
for
websockets,
and
maybe
jrpc
also
goes
here,
so
that
that's
something
that
we
can
discuss
and
the
last
item
that
we
have
here
is
about
response,
requests
and
response
body.
D
Capturing
is
definitely
not
something
that
we
want
to
like
include
or
make
it
active
by
default,
but
some
in
some
scenarios
or
some
people
still
want
to
capture
requests
and
response
body
or
hitters
as
a
part
of
spams
and
that's
something
that
we
just
need
to
probably
define
like
which,
which
attributes
or
black
we
can
justify
attribute
sets
that
can
be
used
by
by
by
users.
D
So
here
is
the
here
is
the
proposal,
and
this
is
the
like:
a
like
attempt
to
define,
define
the
roadmap
or
like
a
scope
for
the
for
the
improvements
for
the
current
http
specification,
and
I'm
really
open
for
ideas
and
would
like
to
start
the
conversations
and
discussions.
E
Awesome
yeah.
Thank
you
so
much
I
having
thought
about
this
stuff
for
a
while.
I
totally
agree
with
the
the
list
of
things
you've
put
here
and
I
think,
like
I
mentioned
in
a
prior
meeting,
I
I
feel,
like
a
number
of
these
issues,
actually
open
up
like
general
issues
or
like
concepts
that
are
currently
poorly
defined
in
open
telemetry,
for
example,
with
I
put
some
of
this
in
the
chat,
but
with
error
status.
E
But,
like
you
say,
the
end
user
on
some
level
is
gonna
want
to
be
able
to
configure
this
stuff
and
we've
never
created
any
kind
of
convention
or
description
for
like
what
a
configuration
language
should
look
like
for
this
stuff,
and
it's
actually
really
tricky
to
some
degree
because,
like
on
what
level
are
you
like?
The
level
of
granularity
for
configuration
can
be
a
little
difficult
difficult
because
it
might
get
into
different
configurations
for
like
different
instances
of
the
same
same
plugin,
but
anyways.
E
That's
an
example
of
something
we
we
don't
really
have
a
precedent
for,
but
I
think
would
be
very
useful
here.
E
Another
example
is
like
with
retries
and
redirects
and
all
of
that,
it's
sort
of
like
you,
know,
granularity.
That
kind
of
I
have
penny.
It's
not
really
time.
E
Dinner
for
things
like
retires
and
redirects,
that
feels
like
log
levels,
essentially,
which
is
not
a
concept
we've
ever
really
applied
to
tracing
rather.
E
So
that's
that's
another,
like
general,
like
another
place
where
we
need
to
develop
like
like
the
general
concept
and
then
apply
it
here,
which
is
kind
of
like
why
we
haven't
done
it
yet.
Essentially,
it's
a
little
more
work
than
just
just
figuring
out
the
details.
D
Right
right
so
like
before
it
tries
it's,
it
can
be
treated
as
like
a
lock
levels,
but
from
the
other
hand,
it's
also
about
the
span
structure
right,
so
how
we.
E
E
Which
I
kind
of
agree
with
is
the
idea
that
this
stuff
should
would
logically
be
structured
as
spans
for
a
lot
of
these
things
like
like
retries
and
redirects,
and
things
like
that,
like
individual
http.
Requests
should
totally
have
like
a
span
structure,
but
that's
also
like
totally
noise,
potentially
for
a
lot
of
situations,
and
we
have
not
taken
like
that
concept
of
like
log
levels
and
applied
it
to
to
span
structure
right,
like
there's
no
api
for
for
doing
that.
In
open,
telemetry.
D
Yeah,
that's
a
good
point,
so
sometimes
we
are
interested
in
really
like
a
top
level
operation.
Sometimes
we
don't
need
to
go
like
a
one,
one
level
deeper
and
maybe
two
level
deeper.
So
that's
something
that's
or
like
includes
some
information
about
tcp
or
some
tls.
E
D
Definitely
that's
something
that's
we
need
to
address
before
before
version
points,
one
one,
two,
zero
right.
E
Yeah
and
I'll
mention
the
the
third
thing,
which
is
you.
You
talked
about
long-lived
connections,
right
examples
of
where
yeah
you
have
web
sockets
or
long
pulling
or
just
like
http,
2
pipelining.
E
There's,
there's
all
these
things
where
the
the
handshaking
is
something
you
might
be
interested
in,
but
it's
at
like
a
different
level
like
the
the
transactional
context,
is
usually
on
the
individual
message
or
you
know,
on
the
individual
requests,
not
on
the
the
overall
pipeline
and
again,
that
kind
of
that
kind
of
branching
is
not
something
we
have
put
a
lot
of
effort
into
modeling
in
open.
Telemetry
like
like
traces,
are
basically
a
tree
structure
right
now,
and
this
also
is
coming
up
in
the
messaging
group.
E
We
have
a
concept
called
links
where
you
could
link
traces
together,
so
you
could
have
one
trace
for
the
overall
say,
websocket
connection
or
something
like
that,
and
you
could
be.
You
know
whenever
you
start
an
individual
request
or
event
in
that
pipeline.
It
it's
part
of
that
one
transaction,
but
it
could
link
to
this
other
trace
of
the
overall
overall
connection,
but
we,
this
is
something
where
we
we
have.
E
Some
basic
tools
for
doing
it,
but
we've
never
we've,
never
done
it
and,
I
suspect,
there's
like
implementation
details
and
things
like
that
could
be
tricky
here.
So
so
that's
just
another
place
where
this
is
also
coming
up
in
the
messaging
group
right,
because
you
have
the
same
same
issues
with
message:
queues.
D
That's
correct:
yeah
probably
also
has
some
http
specific,
like
attributes
when
we
are
doing
like
one
polling
or
streaming,
it's
something,
that's
yeah.
Definitely
the
the
overall
approach
should
be
the
same,
so
it
should
be
unified.
E
Yeah
yeah
like
we
need,
we
need
to
develop
like
the
general
concept
and
then
like
describe
like
how
how
should
links
like
be
used
to
do
this
like
in
such
a
way
that
we
can
go
to
observability
back,
ends
right
and
be
able
to
explain
to
them
how
they
should
be
modeling
links
as
data
structures
within
their
systems
to
match
how
we're
planning
on
using
links
in
our
schema
and
then
on
top
of
that
then
being
able
to
describe
you
know
these
are
the
attributes
you
should
put
on
the
the
websocket
connection.
E
These
are
the
attributes
you
should
put
on
the
like
message:
queue
session
or
whatever.
A
Can
I
jump
in
into
this
conversation
for
a
second
definitely
yeah,
I'm
kind
of
interested,
how
we
can
just
organize
this
process,
because
I
I
assume
there
are
people
out
there
who
maybe
have
some
additional
ideas
and
just
not
discussing
not
going
into
the
solutions.
Just
basically,
how
can
we
define
some
list
of
things
and
after
which
we
think
we
we
can
make
http
stack
stable
and
are
we
even
in
the
position
to
create
this
list
now.
D
Yeah,
basically,
that
that's
that's
the
main
idea
behind
this
request
or
behind
this
document.
E
Yeah,
I
I
think
lumiere
is
correct,
and
I
mean
my
suggestion.
There
would
be
the
the
the
three
things
that
I've
just
mentioned
right
like.
I
think
those
need
to
be
broken
out
into
their
own,
like
their
own
issues,
to
be
solved
right
like
how.
How
do
we,
how?
How
should
we
model
configuration
for
instrumentation?
E
How
should
we
model
being
able
to
control
the
granularity
of
span
structure?
If
that's
what
we
want,
and
how
should
we
be
from
a
data
structure
perspective?
E
How
should
we
be
using
links
to
connect
transactions
with
with
sessions
that
encapsulate
multiple
transactions
in
some
way
and
like,
like
all
three
of
those
things
I
think
have
like
issues
and
we
could
use
this
stuff
as
like
examples
of
like
the
targets
that
we're
trying
to
hit,
but
but
I
would
suggest
kind
of
coming
at
it
from
that
perspective,
and
then
you
know
making
sure
that
we
can
apply
it
to
http
and
we
can
apply
it
to
like
the
messaging
stuff
and
it
just
ensuring
it's
going
to
work
in
these
different
different
contexts.
A
E
Yeah
am
I
it's
sort
of
like.
I
think
we
should
use
http
and
messaging
as
as
like
the
targets
that,
like
these
are
like
the
things
we're
gonna
prototype.
You
know,
but
it's
yeah.
It's
like
these
general
concepts
like
we
don't.
We
don't
have
them
right
now
and
I
think
we
have
to
like
think
about
them
as
more
general
concepts
that
we're
applying
to
this
stuff
and
and
work
that
those
concepts
out.
D
I
see
I
see
so
basically
you're
like
proposing
to
postpone
this
work
for
now
like
for
http
before
we
can
define
these
these
fundamentals
and
then.
B
B
So
what
I
mean
here
is
with
those
when
we
spec
out
those
general
concepts
in
how
far
are
they
independent
of
the
messaging
and
http
semantic
conventions,
and
also,
for
example,
if
something
changes
in
those
concepts?
Basically,
does
that
invalidate
the
conventions
that
we
that
we
have
kind
of?
What
is
the
compatibility
there,
and
also
maybe
to
a
certain
way
in
how
far
we
can
just
put
them?
B
These
concepts
like
on
top
of
existing
conventions
and
maybe
a
work
on
conventions
like
independently
of
those
concepts
and
just
have
those
kind
of
like
retries,
be
an
add-on
to
any
set
of
semantic
conventions
that
we
basically
just
kind
of
put
like
on
top
that
there
is
kind
of
some
specifications
around
three
tries
and
those
can
be
like
put
on
top
of
http
and
on
top
of
messaging,
because
I
I
I
don't
see
it
strictly.
That
way.
B
B
A
I
think
there
are
things
that
I
maybe
come
on
top
of
whatever
we
define
in
http,
then
maybe
long
polling
is
it
comes
on
top
of
it,
but
they
feel
like
things
like
retries
are
fundamental
because
we
either
consider
the
retry
spend
the
try
spanish
in
http
span
or
reconsider
the
logical
span
as
an
issue
to
be
spent.
We
cannot
do
both
and
we
we
kind
of,
have
to
agree
on
one
thing
and
then
we
we
have
to
repeat
it
everywhere,
because
otherwise
it
will
be
just
too
hard
to
maintain.
E
Yeah,
I
certainly
think
we
can.
We
can
sort
out
how
we
want
to
structure
this
stuff
on
that
level,
like
maybe
independently
of
how
the
heck
are,
we
gonna
add
granularity,
like
I,
you
know
to
to
me.
It
makes
sense
to
to
figure
out
these
things
as,
like,
a
nested
span
structure
that
that
we
would
be
happy
with
and
then
there's
this
issue
of,
like
sometimes
sometimes,
details
are,
are
noisy
and
we
want
to
suppress
details
so
like
what
is
our
general
mechanism
for
suppressing
details,
you
know
which.
C
Visit
in
terms
of
semantic
conventions,
I
mean
I
get
conceptually
how
we
want
to
break
two
apart,
but
at
the
same
time
we
do
need
to
have
some
initial
list
that
we
can
work
off
of
right
and
gain
confidence
in
that
agreement.
So
I
think
we'll
need
some
action
item
to
get
that
going.
E
Yeah
so
and
sorry,
I
feel
like
I'm
I'm
dominating
this
conversation,
but
I've.
I
have
thought
about
this
stuff
a
bit
so
here.
Here's
how
I
would
suggest
moving
forwards
for
errors
in
http.
E
What
what
does
the
configuration
language
look
like
for
this,
like,
I
think
someone
should
should
take
a
stab
at
just
without
worrying
too
much
about
you
know
how
to
generalize
this
stuff.
Just
if
we're
going
to
supply
people
with
default
error
mappings,
what
what
would
we
want
to
give
them?
What
is
the
most
useful
configuration
language
to
give
to
end
users
for
being
able
to
modify
those,
so
that
would
be
like
a
concrete
thing
that
would
move
http
forward.
E
Likewise,
a
proposal
for
a
layered
model
of
http
requests
that
gets
in
all
these
details
about
retries
and
everything
else
like
it
would
be
great
to
see
a
proposal
for
that
model.
That's
that's
a
task.
Someone
could
take
on
right
now
and
then
the
third
task
is
yeah
on
a
practical
level.
What
does
modeling
these
connection
issues?
Look
like
so
picking
something
like
http,
2,
pipelining
or
websockets,
or
something
like
that
and
identifying
like
just
like
how
should
someone
model
that
and
like
what?
E
What
is
the
practical
difficulty
of
actually
capturing
that
data
from
these
libraries,
like
someone,
could
really
just
focus
on
digging
into
those
details?
B
I
I
fully
agree
just
what
I
want
to
add
to
this
is
that
I
think
the
hotep
that
dany
setup
can
actually
think
surf
is
a
starting
point
for
this,
because
what
the
odep
can
do
is
I
mean
it
basically
lists
all
those
points
and
basically
what
we
can
do
with
this
output,
we
can
just
use
it
to
agree
on
the
scope.
I
think
it
was
initially
10
that
that
basically
of
this
that
we
have
those
open
points,
the
other
does
not
propose
any
solutions,
yet
it
just
lists.
B
Okay,
those
are
the
points
that
we
need
for
making
http
semantic
conventions
stable,
and
then
we
kind
of
maybe
put
this
also
into
a
vital
discussions
and
see.
If
that
really
is
enough,
we
get
people
weighing
in
and
then
basically
once
we
agree
on
the
scope,
then
we
create
issues
and
then
yeah
tackle
those
having
individual
issues
that
basically
boils
down
to
what
we
are
had.
What
you
laid
out
here
before
yeah,
because.
D
Yeah,
actually,
that's
really
similar
that
I
wanted
to
propose
so
like.
I
fully
agree
that
we
need
to
deal
with
these
fundamental
things
and
this
can
be
created
as
separate
issues,
but
overall
we
still
have
them
mentioned
in
this
year
and
yeah.
I
would
just
want
to
agree
on
a
scope
with
the
community,
basically
just
to
outline
what
we
want
to
solve,
including
these
fundamental
things
so
like
for
me.
It's
like
kind
of
kind
of
thing
that
can
be
done
in
parallel
and
like
once,
we
agree
on
on
this
scope.
D
We
just
can
work
on
them
individually
and
independently,
and
once
all
these
things
are
basically
closed,
we
can
consider
semantic
convention
specs
stable,
so
that
that's
that's
my
proposal
here
as
well.
E
Totally
agree,
other
people
have
their
hands
up,
but
just
just
real
quick,
my
suggestion.
E
If
people
want
to
modify
the
scope
like
go
ahead,
I
think
this
is
a
good
basis
and
I
would
just
ask
that
this
otep
just
be
modified
to
for
each
of
these
issues.
Just
mentioning
the
the
general
concept
that
it's
related
to
just
so
people
are
clear.
E
We
need
to
figure
out
how
to
model
it
here,
but
this
is
also
going
to
bleed
into
like
trying
to
sort
out
this
general
concept
that
we
want
to
share
with,
with
other
semantic
conventions.
D
F
E
So
I
think
it's
it's
it's
two
pieces
I
think
we
have
to.
We
have
to
solve
it
well
enough
that
future
amendments
can
be
done
in
such
a
way
that
they
work
with
our
schema
transition
concept
for
backwards
compatibility.
E
I
think
that
that
is
what
I
think
the
goal
is
to
feel
like
we've
got
this
got
this
in
there
enough
that
we've
got
examples
of
implementing
it
in
multiple
places,
so
we're
satisfied
with
it
and
maybe
even
just
a
test
like
an
example
of
trying
to
perform
a
a
schema
translation.
We
have
just
haven't
really
done
much
of
that
and
when
we've
done
all
of
that,
then
it's
like
all
right.
We
have
all
of
the
pieces
together.
E
We
understand
what
we're
doing
so
now
we
can
mark
this
as
stable,
because
we
know
what
the
scope
of
change
we're
going
to
be
able
to
make
is
going
forward.
B
B
Yeah,
just
just
a
note
from
my
side
on
this
I
mean,
as
I
see
it.
I
definitely
think
it
should
be
a
mandible
because
also
for
for
messaging,
for
example,
there's
already
some
issues
that
you
say:
okay,
that's
not
coming
in
1.0,
but
maybe
at
a
later
point.
So
it's
not
that
we
are
like
targeting
the
final
state
here,
but
just
the
1.0
state
that
should
be
amended,
but
at
the
same
time
from
1.00
it
also
must
be
backwards
compatible.
A
I
haven't
you,
I
have
a
quick
note
on
scope
versus
work.
I
don't
think
we
need
to
agree
on
school
before
we
start.
So
there
are
some
issues.
We
should
be
able
to
start
working
on
like
errors
retries
most
of
them,
it's
something
that
we
will
have
to
solve
and
the
new
scope
items
can
come
on
top
of
that
and
we
shouldn't
be
blocked.
C
Yeah,
I
agree,
I
think,
there's
some
ones
that
are,
you
know
well
defined
that
we're
well
aware
of,
and
just
start
with
those
I
do
want
to
do
a
time
check,
because
we
spent
a
lot
of
time
on
this
one.
So
dennis.
C
D
Good,
so
I
will
like
put
all
the
suggestions
that
I
got
here
to
the
pr
and
we'll
try
to
communicate
this
one
once
again.
In
slack.
C
Sounds
good
yeah
and
I
know
you
posted
in
slack-
may
need
to
repost
this
specifically
for
this
hotep.
Okay,
ludmila
did
you
wanna
talk
about
layers
and
suppressions.
A
Yeah
I
I've
been
experimenting.
I
have
a
couple
of
different
approaches.
I
tried.
Maybe
I
can
quickly
share
how
the
code
looks
like
and
then
I
I
have
an
interesting
discussion.
I
want
to
start
so.
Let
me
share
my
screen.
A
So
the
one
approach
I
experimented
with
is:
we
talked
about
it
that
we
can
set
a
type
on
the
span
builder,
so
basically
every
span
knows
which
kind
of
layer
it
belongs
to
and
then,
when
we
start
in
use
pen,
so
let's
say
scroll
down
so
like
let's
say
we
started
the
database
span
and
let's
say
we
try
to
start
another
database
span
right.
So
I
think
the
one
of
the
questions
we
had.
What
is
this
pen
like?
Can
we
do
this?
We
can
it's.
A
A
So
this
way
everything
works
like
when
we
add
attributes
when
users
add
attributes
they
never
make
edit
them
to
duplicates,
then
they
add
it
to
the
the
real
span.
A
A
The
problem,
one
of
the
problems
here
that
I
don't
really
want
to
talk
much
about
is
the
performance
because,
ideally
we
don't
even
want
to
start
suppressed,
spends
and
what
I'm
proposing
it's
to
some
extent
orthogonal
to
this
work.
It
we
need
it
regardless.
A
It's
some
early
check
that
we
should
even
try
to
start
the
span
and
all
instrumentations
would
check
it
first
and
then,
let's
say
then
they
will
provide
the
attributes
relevant
for
sampling
or,
if
it's
a
knob
like
in
my
labor,
I
don't
know
if
tracer
is
a
real
or
it's
not
real
and
I
can
short
cut
the
instrumentation
code
by
just
returning.
If
tracer
is
not
real,
so
something
along
those
lines
will
help
and
it
will
solve
the
performance
from
like
a
bit
worse
performance
in
this
case
as
well.
A
A
Okay
and
then
I've
got
an
interesting
comment
on
the
otep
that
I
really
want
to
discuss
that.
Okay,
in
this
case
this
type,
it's
a
span
property,
but
we
have
things
that
are
similar
to
type
which
are
not
the
instrumentation
library,
but
maybe
a
schema
url.
A
So
maybe,
if
we
make
like
if
the
tracer
would
say,
okay,
I'm
sending
http
expense
version
x.
A
Maybe
if
we
make
the
type
as
part
of
schema
euro,
then
what
it
would
mean
it
would
be
even
nicer.
So
when
we
create
a
tracer,
then
we
provide
a
type
somehow
and
then
the
tracer
becomes
typed,
not
the
span,
and
then
this
tracer
can
only
meet
database
spans
and
then
we
we
won't
even
introduce
a
new
concept
here
because
schema
url.
It
shouldn't
necessarily
be
that
just
the
the
url
to
all
semantic
conventions.
It
could
be
url
to
a
specific
convention.
A
Yeah,
so
the
question
I
I
want
to
discuss
is
whether
we
want
pens
to
be
typed
or
we
want
tracers
to
be
typed
and
with
type
tracers
that
the
chances
for
like
instrumentation
errors
are
higher.
We
probably
won't
expect
users
to
know
the
subtle
difference
or
tell
me
if
it
doesn't
make
sense
at
all.
G
I
have
a
question:
how
could
you
say
mark
a
trace
as
like
instrumentation
type
database,
when,
theoretically,
one
trace
could
have
lots
of
different
types
of
things
like
it
could
have
an
hdb
call
on
it
as
well.
A
A
D
Yeah
one
one
thing
for
one:
once
short
questions
like:
if
you
have
typed
tracers,
will
that
mean
for
end
users
that
they
will
need
to
like
instantiate
different
traces
in
their
code
if
they
want
to
do
like
a
instrument,
different
layers,
which
is
like
another
portion
of
code
that
needed
to
write?
A
Realistically,
don't
expect
users
to
ever
write
any
tracing
code,
at
least
that's
my
goal
that
users
should
not
do
any
tracing.
If
they
do,
then
I
don't
expect
almost
all
of
them
ever
following
conventions,
because
it's
too
hard
and
then
for
like
very
super
advanced
users
who
want
to
follow
the
conventions.
So
this
is
my
concern.
The
library
code
concern
to
to
create
the
tracers
in
the
right
way,
and
yes,
it's
error
prone
and
also
specifying
the
type
on
the
span
is
also
error
prone,
just
a
little
less.
A
E
I'm
I'm
always
nervous
about
types
getting
added
into
open,
telemetry
schema
stuff,
but
I
do
think
what
you're
proposing
here
seems
reasonable.
E
I
just
I
think
the
the
thing
to
always
really
double
check
about
this
stuff
is
to
ensure
we're
not
making
a
category
error
right
like
when
you
say
something
is
typed
like
this.
It
assumes
it
can
only
have
one
type
at
a
time.
E
So
that's
a,
I
think,
to
check
which-
which
I
think
maybe
makes
sense,
but
it
gets
back
to
you
know.
Do
we
have
spans
that
are
like
both
database
spans
and
http
spans
simultaneously,
like
yeah.
A
E
A
So
then
the
database
creates
database
spans
right
and
if
the
database
happen
to
run
on
top
of
http,
the
http
spans
will
be
most
likely
created
by
auto
instrumentation
and
the
database
should
not
have
them.
So
you
have
retries
right
and
if
we
think
about
so,
let's
decide
about
retries
if
you
want
to
have
a
context
per
try
which
you
want,
if
you
want
to
get
support
from,
what's
there
underneath
right.
So
if
you
come
to
azure-
and
you
say:
okay,
I
have
this
100
of
tries.
A
Please
help
me
investigate
issue
with
fifth
of
them.
Azure
support
will
have
a
hard
time
finding
the
steps,
unless
it
knows
exactly
what
they
are
looking
for
right.
So
basically
it
implies
new
context
for
try.
That
implies
that
http
spans
should
be
created
for
try,
and
it
implies
that
if
you
have
tries,
then
you
have
different
spans
for
database
and
http,
because
you
have,
you
can
have
more
than
one.
E
Yeah
but
then
I
think
where
the
the
question
comes
in
is
then
you've
got.
This
say
like
mongodb
is
an
example
where
you
have
a
logical,
http
request,
which
mirrors
the
database
request
for
the
most
part,
and
you
would
potentially
want.
I
think.
Maybe
this
is
the
question
like
do
you
want,
like
a
database
span
with
all
the
mongodb
attributes
on
it
and
then
underneath
it,
a
matching
http
span
with
all
the
http
attributes
on
it,
or
do
you
want
those
collapsed
into
one
span
that
has
http
attributes
and
database
attributes
yeah.
A
I
think
one
approach,
one
thing
this
slayer
simon
tradition
helps
with
is
the
configuration
that
we
can
hide.
So,
for
example,
here
I
have
a
thing
called
suppression
strategy,
and
it
has
three
different,
at
least
in
this
proposal.
Three
different
values
right,
it's
the
you
can
suppress
by
kind,
which
means
all
client
spends
will
be
collapsed.
It
means
the
database
spends
will
be
chosen,
which
means
that
none
of
the
htc
attributes
will
be
collected,
which
means
that
all
of
the
things
that
identify
the
database
uniquely
should
be
on
the
database
pen.
A
Then
you
can
choose
the
the
kind
and
type
which
means.
If
I
have
database
and
http,
they
will
be
different
stands,
but
if
I
have
two
http
ones,
they
will
be
collapsed
and
the
third
choice
is
suppress.
None.
What
I
didn't
think
we
don't
have
is,
let's
say
one
only
wantation
to
be.
Maybe
I
I
want
to
trace
end
to
end,
but
I
don't
want
an
extra
stance
and
it
feels
like
this
is
a
shift.
That's
turning
off
instrumentation
for
the
database
right.
F
You
guys
sean
yeah,
I'm
I'm
slightly
nervous
with
the
concept
not
with
the
actual
concept
itself,
but
the
ability
to
shoot
myself
on
the
foot,
potentially
working
with
a
lot
of
developers
that
just
want
to
get
things
out
done
out
of
the
way
and
often
leave
telemetry
as
a
set.
Once
and
forget.
F
I
have
concerns
that
people
will
choose
what
they
think
is
the
best
and
when
they
start
comparing
like
service
a
to
service
b,
they'll
start
seeing
like
different
view,
views
of
the
world,
and
that
scares
me
in
a
way
because
it
means
we
can
no
longer
the
the
import
like
the
like
the
in
on,
like
the
cognitive
thing
that
I'm
thinking
about
is.
We
can
no
longer
compare
results
between
these
two
services.
F
If
we
have
two
different
strategies
being
used
here
and
the
flip
side
of
that,
if
we're,
if
some
library
was
able
to
order
instrument
that
and
then
hide
this
away
from
the
user,
it
could
be
rather
confusing
from
the
gets
like
from
the
start,
like
open
telemetry
itself.
Open,
like
includes
like
a
lot
of
cognitive
load,
and
my
concern,
is
adding
more
cognitive
load
of
how
traces
work
could
be
problematic
of
how
people
understand
how
the
services
is
working.
A
I
kind
of
read
that
we
want
everything
to
be
the
same
everywhere.
It's
just
it's,
it
sounds
like
people
have
different
choices
and
we
have
a
problem
with
it
that,
whether
we
want
it
or
not,
we
we
kind
of
introduce,
duplicates
and.
A
Do
something
about
it?
We
just
don't
meet
the
we
it's
broken
and
we
don't
need
user
demand
to
be
able
to
configure
it.
Also,
the
backends
have
different
choices
like
let's
say:
azure
monitor,
prefers
clients
plans
to
be
collapsed
to
one
the
the
top
top
level
most.
I
assume
that
some
back-ends
prefer
the
other
way
around
so
like
how
can
we
introduce
this
configuration
in
the
easiest
way?
I
think
that
this
is
the
the
trade-off
right.
We
want
the
configuration
we
just
want
it
to
be
easier.
F
Yeah
absolutely
my
thoughts
on
this
is
to
make
it
explicit
as
possible,
so
rather
than
making
it
simple
making
it
so
you
have
to
choose
the
thing
right
so,
like
I
know
my
service
is
using
this
very
specific,
specific
implementation
of
sampling
or
aggregation
like
it
is
very
clear
to
me
what
my
service
is
doing,
like
that's
kind
of
my
thoughts
on
this
at
the
moment,.
A
D
One
thing
I
wanted
to
add
here
like
if
we,
if
you
have
this
spans
typed,
I
believe
all
the
types
just
should
be
defined
up
front
like
I
should
be
standardized
as
a
part
of
the
specification,
but
that
basically
means
that
if
you
want
to
add
more
layers
which
are
not
defined
yet
it
can
be
hard
to
do
so
right.
A
Well,
okay,
you
can
realistically
have
it
configurable,
it
could
be
from
string.
You
can
provide
them.
If
you
want
right,
so
we
don't
have
to
define
upfront.
We
can
support
the
few
that
we
are
that
we
have
conventions
defined
for.
D
Okay,
so
some
of
them
will
be
like
a
strictly
fine
and
some
sometimes
user
will
have
some
flexibility
here.
A
D
Right,
but
in
this
case
we
can,
we
can
be
in
a
situation
where
we
have
like
a
spam
set
as
db
and
something
else
something
custom
or
http
and
something
custom.
I
mean
it's
not
not
really
easy
to
verify.
Probably.
A
B
B
I
think
that
was
at
least
one
of
the
initial
kind
of
intents
of
making
the
tracers
named
and
versioned,
and
I'm
not
sure
how
well
it
goes
together
like
with
typed
tracers,
because
I
mean,
when
I
use
a
type.
A
type
tracer
like
mongodb,
for
example,
might
create
like
database
bands
but
also
might
create
yeah
kind
of
internal
spans
or
other
things,
and
I'm
not
sure
how
this
kind
of
the
tracer
name
is.
B
A
filtering
mechanism,
kind
of
fits
in
with
the
typed
tracer
and
another
remark
about
the
type
tracer
is
that
the
at
least
we
had
is
on
the
c
plus
plus
side
some
use
cases
there.
We
had
like
a
requirement
that
you
can
use
like
the
c
plus
plus
sdk,
without
using
a
tracer
provider,
so
you
could
just
kind
of
create
your
tracer
yourself
and
pass
that
like
as
some
argument
to
some
other
program.
B
A
A
I
can
imagine
that,
with
the
same
process,
there
is
a
tracer
of
version
x
that
technically
produces
the
schema
version
x,
but
the
libraries
which
use
this
tracer
produce
schema
version
y.
So
and
in
the
same
process
you
can
have
a
hundred
of
different
schema
versions,
because
libraries
produce
certain
schema
version.
Then,
basically
the
schema
url
that
we
have.
It
basically
should
point
to
the
convention.
It
shouldn't
point
to
the
general
schema
overall
one
right
and
then,
if
we
it
points
to
convention,
then
it's
basically
the
type
that
we
we
want
to
introduce.
A
So
this
was
my
way
of
thinking
that
we
already
have
this
concept.
It's
just
not
fully
fleshed
out.
It
feels
to
me,
but
I'm
I
don't.
I
want
to
keep
digging.
I
don't
want
to
block
on
whether
the
type
is
on
the
tracer
and
the
span,
but
it
seems
like
something
we
have
to
decide
to
make
progress
on.
I'm
happy
with
this
outcome.
If
we
feel
this
will
be
the
perfect
solution.
E
I
I
dig
it,
I
think
what
you're
doing
is
is
right,
but
personally
I
I
have
trouble
really
evaluating
this
stuff
without,
like
looking
at
real
world.
Examples
like
I
would
love
to
see
like
mongodb
instrumentation
in
like
java
and
python,
like
that.
Does
this
and
just
be
able
to
look
at
the
code,
be
able
to
look
at
the
output,
and
you
know
in
light
step
and
and
just
be
like,
is
this?
E
A
E
Yeah-
and
I
would
like
to
this
meeting
is,
like
I
think
too
late
for
him
to
come,
but
diego
works
on
the
python
team
works
at
lightstep
and
he's
willing
to
spend
cycles
creating
a
python
prototype
of
the
instrumentation
stuff
you're
doing
in
java.
E
So
maybe
I
can
just
try
to
connect
you
two
together,
so
he
could
he
could
try
to.
I
personally
think
it's
it's
always
good
to
to
see
these
prototypes
in
more
than
one
language,
just
it.
You
know
flushes
out,
like
some
details
and
stuff,
like
that.
Also
it's
easier
for
me
to
read
python
code
than
this
java
code.
C
Yeah
thanks
for
sharing
with
me,
we
are
at
time
and
we
didn't
get
to
your
attributes
for
sampling
or
ted
your
spec
refactor,
so
do
either
of
you
want
to
just
summarize
real
quick
on
that.
Or
do
we
just
want
to
wait
till
next
week.
G
E
Oh
yeah,
I
mean
I
was
just
gonna
just
gonna
like
show
people
what
the
refactoring
I've
been
doing,
looks
like
real
quick.
But
it's
not
it's
not
a
big
deal
I'll
try
to
get
get
what
I'm
doing
just
push
up
to
github
and
I
can
post
a
link.
You
know
in
the
in
slack,
but
I
think
james
it'll
make
you
happy.
E
I
know
one
thing
you
were
raising
an
issue
about
was
like
all
of
the
the
like
implementation,
specific
details,
being
kind
of
like
mushed,
together
with
everything
else,
and
I
think
that
the
new
layout
I'm
working
on
is
it's
like
conceptually
makes
a
lot
of
this
stuff
easier
to
read.
You
know
at
the
expense.
E
Yeah
yeah
the
end
goal
is
to
to
put
all
the
semantic
conventions
together
and
then
in
a
way
that,
where
there's
some
standard
structure
to
how
it
all
works
and
then
be
able
to
apply
like
code
owner
permissions,
so
that
we
can
get
it's
easy
and
straightforward
to
give
code
owners,
you
know
to
each
each
block
of
conventions.
A
A
C
Okay:
okay,
yeah.
Let's
we'll
take
a
look
at
that
thanks,
ludmila
thanks
everyone
and
sorry
for
running
late
and
we'll
see
you
talk
to
you
guys
in
another
meeting.