►
From YouTube: 2021-10-06 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).
A
A
A
C
All
right,
folks
can
start
to
add
their
names.
That'd
be
great.
C
A
A
So
I
don't
know
what
happened
to
my
jager,
but
it
shows
weird.
So
this
is
the
typical
java
application.
It's
a
springboard
application,
no
custom
code.
I
broke
it
by
disabling
any
sort
of
suppression.
That
java
has
an
instrumentation.
A
So,
as
you
can
see,
this
is
the
first
server
called
http
post,
it's
traced
by
some
middleware.
Then
there
is
another
one
and
those
two
layers
they
just
don't
aware
of
each
other.
Some
applications
may
have
one
of
them.
Some
applications
may
have
two.
So
we
cannot
just
disable
this
instrumentation
or
say
we
don't
instrument
one
of
these
layers.
A
Okay,
so
then,
if
we
keep
going
so
this
is
the
http
request
and
I
see
three
of
them.
I
don't
know
why
sorry
http
outgoing
requests,
I
think
maybe
there
is
a
bug
or
something
but
the
first
layer.
It's
a
google
http
client,
the
second
layer,
it's
apache,
http
client
and
it's
pluggable,
so
you
can
plug
something
else
into
google
http
client.
So
in
some
cases
you
have
only
google
quite
instrumentation.
A
In
some
cases
you
have
both
and
you
don't
necessarily
know
when
you
instrument,
google
http
client.
If
there
will
be
another
layer,
instrumented
right
so
basically
this
is
no
suppression.
This
is
mongodb,
but
there
is
nothing
underneath
because
we
don't
trace
mongodb
protocol
right.
So
then
let
me
show
you
the
example
with
what
happens
in
java
without
like
with
the
current
configuration.
A
So
this
is
the
first
span
that
we
saw
before
it
has
routes.
By
the
way,
the
messages
you
see,
the
previous
one
was
http
post,
so
somehow
they
are
collapsed
together.
I
don't
fully
understand
the
whole
magic
behind
it.
There
is
a
controller
span,
it's
different
and
then,
though
there
is
one
http
get
the
mongodb
spans,
nothing
happened
with
them,
but
if
there
was
an
http
span
under
with
current
settings,
it
would
be
suppressed
on
javasci.
A
So
we
will
have
those
layers
of
different
things,
and
so,
if
we
return
back
for
a
second
in
this
java
world,
the
current
one
so
in
java-
because
we
have
so
many
things
instrumented,
this
is
the
reality
in
python.
A
You
would
see
similar
things
for
that
are
hidden
by
http
suppression
context
key
somewhere,
so
like
it's
already
done
inside
the
instrumentations,
it's
just
hidden
from
you,
so
my
sole
point
is
to
like,
like
re,
remove
this
duplication,
because
you
see
this
is
the
same
information.
It
has
the
same
duration
or
very
close
to
it.
Has
four
server
stances
the
same
story
so
basically
there
I
heard
concerns
that
we
are
worrying
about
removing
information.
A
A
C
I
mean
yes
from
when
you're
consuming
the
any
of
the
staff
traces
request.
Traces
to
me,
having
duplication
just
adds
to
makes
it
noisy
and
so
to
me,
having
some
level
of
suppression,
so
you
can
get
rid
of
the
dupes
is
great
as
far
as
like
the
the
implementation
yeah.
C
If
folks
have
I'm
not
one
way
or
the
other
like
opposed
or
four
it's
more
for
the
folks
on
the
call,
if
they
are
have
other
suggestions
in
terms
of
what
you've
already
presented
the
past
couple
weeks
in
terms
of
an
approach,
but
I
do
see
a
need
for
it.
F
You're,
just
also
adding
that
there's
definitely
a
need
for
it,
because
I
mean
you're
having
a
beautiful
trace
trees,
one
thing,
but
they
made
also
also
use
cases.
So,
for
example,
you
are
adding
up,
like
I
don't
know,
http
response
time
or
averaging
http
response
time
across
traces,
and
then
you
have
something
like
this.
F
When
you
have
basically
three
spans
representing
the
same
http
request,
this
can
become
very
tricky
actually
to
do
so.
I
definitely
think
there's
there's
a
need
for
that
and
just
another
question
that
I
had.
I
mean
that
may
be
like
something
completely
unrelated
but
as
I
understand
like
both
traces
that
you
showed
us
are
it's
the
same
application.
A
B
I
think
that
was
an
excellent
point
by
the
way
about
calculating
things
like
response
time
and
stuff
like
that,
I
think
that's
a
point
that
hasn't
been
made
so
far
that
duplicate
duplicate
instrumentation
may
actually
confuse
analysis
tools.
So
that's
that's
an
extra
reason
to
get
this
done.
One
thing
I'm
I'm
curious
about
is
for
those
different
layers
of
http
get.
B
A
Yeah,
so
this
should
have
identical
information,
because
in
java
it's
the
same
code
that
actually
extracts
the
attributes
or
more
or
less
the
same
so
there.
Unless
this
instrumentations
do
something
essentially
different
one
traces,
retries
and
others
other
doesn't,
then
they
have
the
same
information.
B
Right
and
but
if
when
instrumentation
is
suppressed
like
that,
it
also
just
means
that
additional
calls
to
like
add
attribute,
and
things
like
that-
would
still
work
right.
There's
they're
just
going
on
to
the
the
parent
span.
B
B
A
Yeah
so
one
of
the
things
I
had
to
implement
the
new
span
in
in
my
prototype
new
span
implementation
is
to
avoid
this
problem
exactly
so
the
spend
you
can
make
it
current,
but
it's
a
knob.
So
it's
still
the
still
the
the
previous
span
will
be
current.
B
A
B
I
see
so
any
that
I
guess
that
was
my
earlier
question.
Whenever
someone
calls
current
span
they're
not
going
to
accidentally
get
one
of
these
suppress
spans,
great
yep,
great
awesome,
and
I
guess
my
last
question
is.
I
think
this
is
great
for
combining,
like
the
logical
layer,
there's
still
the
question
of
if
we
have
underlying
implementation
details
around
retries
and
redirects,
and
things
like
that.
That
seems
like
information
that
may
only
be
present
on
the
bottom
right.
A
True
yeah,
so
if
we
are
willing
to
discuss
http
and
retries
here,
I
have
some-
I
don't
know
a
pitch
about
it.
So
basically,
my
way
of
thinking
about
it
that
for
http
we
have
to
instrumentary
tries
because
they
have
to
have
unique
context.
A
A
A
Doubling
this
number
is
hard.
Tail
based
sampling
is
not
always
possible.
So
what
I'm
saying
that
the
default
should
be
retries,
and
maybe
http
instrumentations
or
just
instrumentations
in
general-
should
have
a
configuration
option
to
enable
the
logical
part
like
that.
The
call
to
hdcp
client
was
retries
underneath,
and
this
is
like
the
verbose
configuration
the
logi.
The
logical
one
is
verbal,
it's
not
retries.
B
B
F
Pertaining
to
that
question
that
ted
raised-
actually
I
mean
just
maybe
30
minutes
ago.
I
actually
added
a
comment
to
the
suppression.
Pr,
and
I
think
one
interesting
question
came
to
mind-
is
what
actually
constitutes
an
instrumentation
layer
which
ties
somehow
in
like
to
ted's
question
like
it's
a
is
a
layer
just
a
single
span
or
what,
for
example,
yeah.
F
If,
if
one
of
those
things
would
http
libraries
here
would
not
just
create
one
span
but
two
spans,
let's
say,
but
then
both
spans
considered
being
one
layer
or
is
it
always
just
one
span
that
we
consider
the
layer
that
that
was
not
clear
to
me
and
that
is
kind
of
then
we
talk
about
like
suppressing
layers,
but
are
we
actually
talking
about
suppressing
something
different
in
single
spans
like
the
the
layer
concept?
F
It
was
not
like
yeah
completely
clear
to
me,
and
I
think
it
ties
into
attach
says
if
you
would
have
like
a
basically
your
http
request
with
three
tries,
as
children
basically
think
the
whole
kind
of
subtree
would
be
considered
a
single
layer,
but
then
a
wonder:
would
we
suppress
the
complete
layer
or
just
like
a
single
http,
get
spam.
A
Yeah,
that's
a
great
question
so
in
the
first
approximation
layer
is
a
convention
right,
so
the
database
or
the
http.
But
if
we
don't
well,
we
have
some
cases
when
we
by
design
have
multiple
layers
already
like
in
in
messaging,
even
though
we're
reworking
it.
But
let's
assume
the
convention
defines
more
than
one
layer,
so
the
convention
would
mention
there
is
a
parent's
pen
and
there
is
a
child's
pen
right
and
then
basically
I
would
say
that
I
should
define
it
better
in
the
order.
A
B
I
think
I
would
love
to
just
see
see
an
example.
It
just
seems
like
the
next
logical
step
like
we
know
we
have
retries
and
redirects
and
all
that
other
stuff.
That
can
happen,
and
I
that's
the
place
where
I
wonder
whether
the
I
don't
know
the
details
about
these
particular
implementations,
but
to
me
that's
a
place
where
the
high
level
wrapper
http
implementation
might
not
actually
know
any
of
those
details,
because
that's
all
happening
at
a
lower
layer.
So
I
would
just
be
curious
to
see
to
see.
B
A
It
was
recently
yeah
and
I
agree
the
example
would
be
great
I'll
work
on
something.
A
B
That's
that's
where
we'll,
if,
if
this
thing
goes,
gets
confusing
at
all,
it'll
probably
be
there
so
cool
and
I
see
dennis
has
his
hand
up.
D
Yeah,
just
just
wanted
to
clarify
this
like
a
couple
of
things
here.
So
basically
we
are
talking
about
these
layers
or
like
a
logical
kind
of
operations,
but
this
we
also
had
this
discussion
last
time
or
previously
related
to
this
kind
of
like
a
level
of
utilization
or
verbosity.
If
you
will
like
a
for
for
me,
it
sounds
really
similar
concepts
like
with
regards
to
the
way
how
we
want
to
define
all
the
spans
so
say
like.
If
we
want
to
have
detail
or
like
a
really
high
level
of
utilization.
D
We
want
to
see
all
this
spans,
even
if
clients
are
nested
or
like
http
client
arrested
like
like
we
have
in
this
example,
or
we
have
a
retrace
and
redirects
enabled,
so
we
also
see
them.
But
if
the
verbosity,
like
a
set
to
normal,
for
example,
we
can
just
see
top
level
span
and
that's
it
so,
like
a
can,
we
cover
all
these
cases
with
just
the
same
concept
of
verbosity.
I
mean,
should
level
of
visualization
and
this
layering
should
somehow
be
combined.
D
So
we
can,
like
you
know,
solve
both
problems
with
just
one
concept,
like
one
kind
of
unified
concept.
A
I
don't
know
for
me
verbosity
and
spence
sounds
very
difficult
right.
So,
for
example,
here
there's
three
things
that
we
have
so
three
http
spans.
They
are
not
aware
of
each
other.
It's
the
result
of
three
different
instrumentations
right,
so
one
of
them
cannot
say
it's
verbose
because
it
doesn't
know
comparing
to
what.
A
A
D
Yeah,
so
I
agree
that,
like
in
this
particular
case,
we
just
probably
can
safely
drop
them
and
we
are
still
good.
But
what
is
the
you
know?
Attributes
we
can
use
to
recognize
that
electrically,
just
like
this
dublicates
or
we
actually
have
something
meaningful
on
the
under
underneath
like
right,
like
redirects
or
root
rice.
D
So
just
for
me,
it
seems,
like
I
mean
I'm
not.
I
don't
have
like
a
real,
strong
opinion
here
yet
but
looks
like
if
we
generate
all
these
pens
and
then
somewhere
in
the
library.
Like
the
expert
on
the
exporter
level,
we
decided
that
all
these
things
somehow
related
together
so
depending
on
the
settings
that
we
have
for
for
exporter
or
for
open
telemetric
library,
I
don't
know
like
which
exact
place
it
should
be
put
but
depending
on
the
settings
we
can
just
you
know
kind
of
expand
them.
D
So
all
the
all
these
fans
will
go
to
the
to
the
back
end
to
younger,
so
we
will
see
all
of
them
or
we
can
just
collapse
them
to
to
see
just
one
one
top
level
span
or
something
in
the
middle.
So
fortunately.
A
F
D
A
Okay,
so
the
next
step
for
me
is
the
the
http
logical,
plus
physical,
and
how
it
might
work
with
suppression,
but
not
necessarily
it's
the
just.
The
the
understanding.
F
Remarks
for
the
suppression,
discussion
with
miller
and
the
eyeballs
just
also
to
make
the
the
case
stronger
here
for
the
need
of
that.
I
wonder
if
he
may
be
yours
in
the
other,
could
anyhow
in
any
way
show
that
this
is
a
problem
that
cannot
be
solved
on
the
instrumentation
side,
because
when
some
people
who
look
at
this
at
this
tree
here,
we'll
just
say,
okay
yeah.
This
is
broken
instrumentation
and
should
be
fixed
there
and
then-
and
I
wonder
in
in
this
particular
case,
could
this
be
fixed
in
the
instrumentation
at
all.
A
So
like
it,
it
might
be
so
potentially
you
can
have
a
configuration
that
will
say:
users
collect
this
server
layer
or
this
server
layer
right.
So
it
will
just
be
more
work
for
users.
So
perhaps
it's
possible,
but
it's
better.
We
don't
do
it
at
least
for
every
instrumentation
and
like
in
some
cases.
Let's
say:
let's
see
this
is
I'm
sorry,
I'm
I'm
getting
almost
here
this
google
http
client.
A
So
in
the
same
process
you
can
have
google
http
client
configured
to
use
apache
that
is
traceable
or
something
else
that
maybe
not
traceable,
not
instrumented
right.
So
even
in
the
same
process,
you
cannot
apply
the
process.
White
configuration,
never
collect.
Google
http
client
because
you
don't
know.
F
I
mean
it,
it
makes
sense.
I
was
just
thinking
about,
I
mean
with
the
suppression
approach.
Basically
one
I
mean
one
additional
kind
of
benefit.
That
one
gets
is
that
it's
configurable,
because
when
you
have
instrumentation
site
you
just
get
one
kind
of
predefined
solution,
but
here
basically
maybe
other
cases
when
you
want
to
see
all
the
spans
and
then
the
cases
when
you
just
want
to
see
like
one
http
spam,
so
yeah
that
makes
sense.
E
I
do
think
that's
a
good
point
about
that.
You
can,
while
you
could
potentially
configure
your
instrumentation
to
not
capture,
you
know
to
disable
disable
one
of
your
instrumentations
that
was
creating
the
duplicate.
E
C
All
right
thanks,
dude
mila.
This
is
pretty
good.
I
just
had
one
question
on
this,
though
I
mean
like
in
terms
of
existing
like
whether
it's
python
or
java
applications
that
you
know
that
you'll
be
getting
duplications
like
you
demonstrated,
I
mean,
what's
the
likelihood
of
like
or
like
the
percentage
of
applications
that
we
tend
to
see
this,
because
I
think
that'll
help
the
question
about
whether
it's
something
that
should
be
addressed
at
the
instrumentation
level
or
the
suppression
approach
in
my
thought,
as
a
user,
I
want
instrumentation
to
be
super
easy.
C
I
don't
want
to
be
overly
complicated
and
then,
in
the
event
that,
oh
you
know
what
duplications
are
never
going
to
be
an
issue
for
me,
so
I
don't
have
to
worry
about
that.
But
then,
if
it
does
then
okay,
I
know
that
there's
a
suppression
approach
within
the
spec,
so
that
was
just
me
thinking
out
loud
and
watching
the
demo.
A
A
In
my
case,
we
in
azure
as
the
case
we
do
http
instrumentation,
because
we
put
more
details
than
other
instrumentation
can
so
like.
For
me,
all
of
my
users
will
suffer
if
I
can,
if
I
don't
find
a
solution
for
this
problem,.
C
Makes
sense:
okay,
okay,
all
right!
Let's
move
to
the
next
topic.
I
think
it
lead
mila
you're
up
again
in
terms
of
the
spec
must
versus
should
or
yes,
freedom
did.
You
want
to
go.
Do
we.
A
Have
do
we
have
other
topics,
so
maybe
we
will
spend
10
minutes
on
this
if
we
have
other
topics
at
the
end,
so
I
don't
want
to
spend
too
much
time
on
the
discussion.
C
Sure
nobody
else
has
added
anything,
but
we
can
do
a
checkpoint
here
since
other
folks
came
in
later.
I
don't
know
if
james
or
steve
or
anybody
else
may
have
some
topics
that
they
want
to
discuss
now.
C
Or
ted,
do
you
want
to?
I
saw
your
otep
that
you
pushed
for
the
draft.
Maybe
did
you
want
to
talk
about
that,
a
bit
to
break
up
yeah.
B
I'm
happy
to
to
go
through
that
real
quick
get
some
feedback
there.
So
let
me
just
share
my
screen.
Real
quick.
B
Okay,
I'll
see
this
so
looking
at
rearranging
the
semantic
conventions
here
to
put
them
all
in
the
same
file
structure.
B
So
this
is
pretty
straightforward.
All
I've
done
so
far
is
just
reorganize
tracing
another
branch
where
I'm
working
on
adding
metrics
and
things,
but
my
hope
was
to
be
able
to
have
basically
a
single
file
that
just
has
all
of
the
conventions,
regardless
of
type
for
the
subject
matter.
B
B
And
that
kind
of
would
help
any
implementer
be
able
to
go
in
and
have
one
spot
where,
if
they're
looking
to
implement,
you
know
something
for
redis
like
redis,
hasn't
been
implemented,
yet
in
some
language
they
would
just
go
in
here,
so
I'm
just
reorganizing
it
right
now.
What
I
was
thinking
is
the
next
step.
You
can
see.
One
thing,
that's
helpful,
this
reorganization.
It
makes
it
clear
how
thin
some
of
these
are
compared
to
others.
So
you
know
with
cassandra:
we've
got
some
additional
attributes
with
redis.
B
The
way
I'd
like
to
normalize.
These
implementations
is
that-
and
this
is
maybe
where
I'd
like
some
feedback
is
to,
rather
than
just
put
the
additional
fields
to
require
that
for
each
implementation,
the
listing
is
complete,
so
actually
include
everything
that
was
like
a
relevant
convention
from
general
to
relist
it
in
some
way
here
with
a
description
of
how
it
should
be
implemented.
B
In
other
words,
this
sometimes
shows
up
in
like
these
examples
of
like
whether
something's
set
or
not,
and
if
it
is
that,
what
what
should
it
be
set
to-
and
we
have
some-
I
put
them
under
requirements-
just
sort
of
prose
descriptions
of
how
certain
values
should
be
set.
B
I
was
thinking
the
the
way
to
tell
whether
one
of
these
was
complete
and
could
get
signed
off
as
being
stable
would
be
to
actually
have
everything
accounted
for,
so
every
single
database
value
be
listed
for
each
every
single
attribute
be
listed
here
for
each
one
of
these
types,
with
an
explanation
of
what
it
how
it
should
be
dealt
with
with
this
implementation
so
again
just
to
make
it
so
that
someone
trying
to
implement
one
of
these
things
doesn't
have
to
have
any
guesswork
or
or
look
around
between
different
files
and
kind
of
piece
it
all
together.
B
I
don't
know
if
writing
that
in
like
prose
statements
is
the
best
way
to
do
it
or
to
put
it
into
tables.
I
don't
want
putting
it
into
tables
to
kind
of
mess
up
how
we
generate
these
semantic
convention.
Yaml
files
over
here,
that's
kind
of
what
I
was
thinking
is
the
next
step.
So
I'm
curious.
Do
people
think
that's
that's
a
useful
way
to
organize.
It
have
any
advice
on
what
they
like
to
see
there.
G
Yeah,
I
I
like
this
way
of
organizing
it.
Definitely
I
we
actually
did
something
similar
internally.
When
we
created
our
metrics
convention,
you
could
extend
instead
of
calling
it
implementations.
We
call
it
extensions,
so
a
similar
kind
of
thing
and
and
basically
for
the
exact
same
structure
as
that,
your
that
you've
got
here
and
it's
worked
well
so
far.
So
I
like
it,
is
this
just
for
tracing,
or
is
this
also
aiming
to
unify,
like
metrics.
B
B
Current
tracing
details,
we
would
add
the
metrics
details
either
fully
integrating
them
like
if
they're
all
related
like.
If
this
is
broken
out
by
like
subject
matter,
we
would
have
both
tracing
and
metrics
details
under
each
subject
matter
or
just
having
them
all
in
here,
but
maybe
in
separate
files
just
with
a
suffix.
G
Yeah,
oh
great,
another
question
I
have
actually
is
in
the
because
this
is
all
these
attributes
tables
and
things
are
generated
from
the
yaml
structure.
Right,
there's
some
this
there's
yaml
in
this
repo
somewhere
yeah
yeah.
B
I
think
it's
it's
the
other
way
around,
though
it's
these
these
blocks
here
are
used
to
take
these
tables
and
generate
the
yaml
files.
Oh
really,
I
thought
it
was.
Yemen
would
generate
pretty
sure.
I
could
be
wrong
about
this.
I'm
pretty
sure
it
goes
that
direction.
G
Oh
okay,
which.
B
G
B
Fair
enough
well,
I
was
curious
how
some
of
this
worked,
because
there
were
some
places
where
it
looked
like.
There
were
like
gaps
through
like
text
and
things
that
were
inserted
into
the
middle,
but
yeah.
B
Okay,
yeah
so
cool,
I
mean
either
way
I
hadn't
looked
at
it,
but
yeah
that
would
be
before
this
would
be
accepted.
It
would
be
to
figure
out
how
to
rejigger
those
tools
to
actually
produce
this
output
that
we
want
over
here.
G
B
Who
who's
like
actually
used
this
stuff?
I
I
forget
who
actually
built
these
tools
but
yeah
if
you'd
want
to
get
involved,
that'd
be
super
helpful.
G
Yeah
I
have
no
idea
who
built
it
either.
Maybe
I
can
have
a
chat
with
whoever
that
is.
If
you
go
into
the
database
yaml
as
well,
I
just
have
a
kind
of.
G
Yeah
you'll
see
that
maybe,
if
you
command
f,
extends
you
see
that
I
don't
know,
but
essentially
like
you'll,
see
that
other
parts
of
the
convention
extend
other
parts
of
the
convention.
For
instance,
yeah
like
so
ms
sql
extends
db
right
yeah,
and
then
that
inherits
like
the
attributes
of
db.
G
Would
it
be
helpful
to
make
that
a
requirement
in
your
say
in
your
implementation
structure,
if
something
is
going
to
implement
db,
for
example,
does
it
need
to
extend
it
in
this
yaml?
G
Is
that
that's
probably
a
sensible
requirement
to
have
also
I'd
I'd,
then
wonder
just
for
the
purpose
of
consistency
of
like
terminology.
Would
it
be
useful
to
call
that,
like
extensions
instead
of
implementations
in
the
folder
structure
as
well.
B
Yeah,
we
could
call
it
extensions.
I
do
want
to
include
under
those
the
main
reason
I
was
thinking
implementations
was.
It
wouldn't
just
include
these
attribute
extensions,
but
it
includes
a
bunch
of
other
details
about
how
to
like
how
to
go
about
implementing
various
things
so
yeah,
but
I
don't
know.
B
G
B
Either
way
yeah,
I'm
not
I'm
not
set
in
any
name
but
yeah.
It
would
then
be
like
under
here.
There
would
be
like
an
attributes
table,
and
that
would
be
maybe
the
attributes
could
be
called
like
extensions.
Maybe
that's
how
you
would
do
it
so
maybe
like
here
this
where
it
says
attributes
it
could
just
be
like
extensions.
B
You
know
yeah,
okay,
something
like
that.
Maybe
I
don't
know
and
then
that's
the
all
of
that
that
yaml
file
that
contains
all
of
this
stuff
would
then
you
know
right,
write
this
thing
out.
B
B
B
B
Cool
cool
yeah,
so
that's
where
that's
at
and
yeah,
I'm
just
gonna
try
to
get
get
everything
moved
over
into
the
structure.
I've
got
cube.
Con
coming
up,
that'll
blow
a
giant
hole
in
my
schedule
next
week,
but
other
than
that
should
get
done
pretty
quick,
it's
pretty
mechanical
and
then
the
next
step
after
that,
that
would
just
be
having
it
reorganized
and
then
once
we
did
that,
I
think
the
next
step
would
be
to
create
issues
and
start
assigning
people
to
like
each
each
class
right
like
so
each
extension
or
implementation
type.
B
You
know
and
then
we'd
be
able
to
point
those
smes
and
say
here
like
please
like
here:
here's
like
a
template
file
that
shows
how
this
just
you
know
how
this
should
be
filled
out.
Could
you
please
like
fill
everything
out
for
cassandra
and
then
other
people
who
are
experts
can
can
review
the
pr
and
sign
off
on
it
and
that's
how
well
like
on
a
practical
level,
how
we'll
move
forward
getting
all
these
things
to
stable.
B
I'd
love
to
see
ensure
that
there's
at
least
one
implementation
in
one
language
that
comes
along
with
each
with
each
pr
just
so
we
can
verify
that
what's
being
asked,
for
there
is
something
that
can
actually
be
be
implemented
and
there's
also
a
reference
code.
Implementation
people
can
look
at
for
the
instrumentation,
but
I
can
I
can
come
up
with
that
list.
As
part
of
part
of
doing
this,.
C
Thanks
dad
all
right
lumila
did
you
want
to
talk
about
the
consistency
versus
freedom
for.
A
Yeah,
thank
you
yeah,
so
we,
I
have
a
pr
for
sampling
attributes
and
I
I
kind
of
want
to
use
it
as
an
as
an
example,
or
maybe
just
a
bit
more
general
discussion
than
sampling
rules.
So
basically,
what
I'm
trying
to
achieve
is
I'm
we
have
an
http
spec
and
it
doesn't
define
which
attribute
should
be
provided
before
sampling
decision
is
made.
A
We
currently
say
like
everything
that
it's
not
great
for
performance,
so
I'm
trying
to
clarify
which
and
basically
the
rule
of
thumb.
I
came
up
with
it's
the
required
attributes
that
are
available
before
spanish
started
right.
A
So
the
whole
discussion
here
it's
about
whether
it's
a
must
or
should,
and
the
concerns
are
that
maybe
it's
not
always
feasible,
or
maybe
it's
an
overkill.
So
I
I
don't
really
understand
concerns
fully
juris.
Cora
is
the
person
who
has
the
most
concerns.
Bogdan
is
also
concerned
about
the
most
versus
should
so.
I
kind
of
I
want
to
have
this
discussion.
What
do
we
prefer?
A
B
I
I
would
go
with
with
the
should
actually
why,
just
because
I
would
say
well
for
two
things:
one:
we
can't
guarantee
that
all
of
these
attributes
are
available
like
some
of
them
we're
putting
in
as
required
right
and
so,
but
there's
some
of
these
attributes
we
want
which
are
not
required.
So
things
on
the
back
end.
B
B
B
A
But
it
doesn't
say
it
you
must
so
like
it.
It
cannot
be
not
feasible
to
provide
those
attributes
because
they
flow
before
the
headers
and
headers
is
where
you
get
your
parent
context
from
you
probably
cannot
not
have
this
information,
it's
just
you're,
not
willing
to
read
it
yet.
Probably.
B
Yeah,
I
mean,
I
think
I
I
guess
I'm
just
trying
to
be
a
little
pedantic.
I
think
these
should
be
added
at
span
start
time
if
they
can't
be
for
some
reason
they
should
be
added
anyways.
I
don't
know
if
you're
making
the
case
that
it's
like
look.
It's
like
inconceivable
that
these
wouldn't
already
be
available,
like
that's
that's,
fair,
so,
but
but
either
way.
I
think
just
just
mentioning
in
the
spec
here
like
these
attributes
are
necessary
for
sampling.
B
You
know,
therefore
they
must
be
provided
at
span
creation
time
when
possible
would
be
like
how
I
would
rephrase
that
subtly
so
must
right,
but
I
would
say
I
would
I
guess
the
part
I
would
get
rid
of
is
where
you
say
when
provided
at
all.
A
C
B
Part
part
of
the
reason
why
there's
different
sets
has
to
do
with
lowering
reducing
the
amount
of
parsing
needed
just
to
report.
What's
going
on
because
in
different
situations,
different
different
implementations.
Take
this
information
in
or
or
allow
you
to
access
it
in
different
ways
right.
It's
there's
not
one
universal
way
that
an
http
request
object,
hands
you
back
this
info!
So
that's.
Why
that's
why
it
says
it?
E
That's
what
we've
seen
in
the
java
instrumentation
is
that
all
the
and
we've
consolidated
recently
and
all
servers
fans.
You
know
they
get,
they
get
it
in
pieces
right.
You
get
the
host
port
path,
query
stream
and
then
all
client
http
instrumentations
have,
for
the
most
part,
the
url
and
in
you
know
like
80
plus
percent,
and
it
feels
better
to
have
consistency,
because
then
users
can
have
expectations
on.
You
know,
setting
up,
rule-based
samplers
and
not
have
to
worry
about
these
weird
different
cases.
B
I
definitely
think
part
of
how
this
spec
is
confusing
in
particular,
is
that
it
tries
to
combine
server
and
client
and
just
say
http,
so
maybe
that's
that's
all
it
really
is
it's
just
splitting
it
out
into
like
saying:
let's
just
have
an
http
server,
spec
and
http
client
spec.
D
Yeah,
this
can
be
the
one
possibility
and
actually
the
other
possibility
that
we
also
discussed.
So
we
have
this
table
like
which
actually
indicates
which
are
required,
which
are
optional.
So
maybe,
instead
of
like
having
these
phrases
like
master,
should
we
can
just
have
them
listed
saying
this
like
a
fourth
client,
this
is
the
requirement.
This
is
the
required
one
and
it
must
be
or
should
be
created
at
this
particular
point
right
so
like
on
the
span
creation
time
and
the
the
the
like.
D
Another
set
of
attributes
will
be
for
server,
and
we
also
can
you
know,
distinguish
them
by
the
creation
time
so
by
this
we
just
by
this
rephrasing.
Maybe
we
can
just
avoid
the
the
the
discussions
like
here.
C
So
my
my
thoughts
is
that
what
I've
seen
so
far
is
that
as
soon
as
we
we
say
use
the
word
should,
or
we
say
optional
folks
tend
not
to
use
those
attributes.
I've
seen
that
time
and
again,
and
then
usually
it's
only
through
advisement
of.
Why
is
this
not
working
and
then
we're
working
with
a
particular
customer?
And
then
we
say
well,
it's
because
you're,
not
you
know
using
this
attribute.
C
If
you
add
this
or
when
you're
in
the
case
of
like
generating
again
chart,
let's
say
you
know
the
span
name
is
you
know
very
generic
they're,
not
really
putting
anything
well
defined
there
same
thing
and
so
just
having
to
go
back
and
advise,
and
so
I
do
think
that
the
intent
of
what
luke
miller
is
trying
to
do.
It
makes
sense
if
it's
about
wordsmithing
or
whatever.
I
could
try
to
take
a
look
at
it.
C
Luke
noah
with
the
offline,
but
I
do
think
that,
whether
it's
separating
but
by
http's
client
and
htv,
whatever
it
is,
I
do
think
that
we
should
have
a
hard
look
of
what
is
absolutely
required,
and
you
did
mention
ted
earlier,
like
in
the
event
that,
if
you
are
using
sampling,
then
these
are
the
ones
that
are
required.
Well,
I
you
know,
I
know
that
there
is
a
small
audience
in
the
industry
who
doesn't
believe
in
sampling,
but
I
thought
tracing
in
general
requires
a
you
know,
sampling
right,
so
I
can.
C
I
can
see
how
this
is
not
applicable
for
metrics
semantic
dimensions
or
or
or
logging,
but
I
I
do
want
to
be
careful
about
like
how
we're
stating
all
those
things
but
yeah.
B
C
B
I'm
totally
sold
on
trying
to
be
more
stringent
here
about,
in
particular,
now
that
we
understand,
I
feel,
like
sampling,
just
wasn't
thought
through
when
this
spec
was
initially
written,
and
we
now
have
a
lot
of
instrumentation
available.
We
know
what
we
need
and
as
long
as
we
can
verify
that
what
we're
saying
is
strictly
required
and
the
spec
is
actually
feasible
for
like
90
of
instrumentation
to
produce.
B
Then
I
see
no
problem
trying
to
be
super
strict
here,
you're
totally
right
people
when
they,
when
they
see
like
optional
they're,
for
whatever
reason
their
response
there
is
to
not
not
include
it
so
yeah.
A
I
kind
of
thought
that
maybe
we
in
each
case
we
can
start
strict,
but
we
assume
the
implementations
of
the
stack
as
part
of
the
stabilization
and
then,
if
we
will
find
out,
it's
not
visible,
which
I
doubt,
but
let's
say
we
find
out,
then
we
can
soften
it.
But
if
we
start
soft
we
have
no
way
of
hardening
it
later
or
it
will
be
way
harder.
F
Again,
one
thing
I
was
wondering
about
here,
looking
at
it
from
a
different
viewpoint,
maybe,
but
I
was
wondering
if,
if
we
go
here
with
the
mass
terminology
and
then
there's
somebody
who
instruments
his
application
and
does
not
follow
it,
what
consequences
would
this
have
for
this
person?
I
mean,
I
know
with
the
tracing,
for
example,
the
chord
racing
spec,
there's
pretty
clear,
like
there's
must
in
there
and
if
an
sdk
doesn't
implement
it
or
if
an
api
doesn't
implement
it,
then
this
this
sdk
or
f
api
is
not
conformant
to
open
telemetry.
F
So
it's
the
case.
It's
pretty
clear,
cut
here,
but
with
the
semantic
conventions,
I
I
was
just
wondering
about
what
like
people
can
instrument
the
applications
with
a
completely
different
set
of
semantic
conventions
and
it's
still
open
telemetry.
F
So
I
was
wondering
what
what
the
what
consequences
there
would
be
for
somebody
who,
like
does
not
follow
the
math
directives
here.
Would
we
then
say:
okay,
this
application
does
not
I
I
guess
we
would
need
to
say
okay,
this
application
just
doesn't
follow
open
the
damage
with
semantic
conventions
and.
A
Holistically,
I
don't
think
applications
should
ever
follow
any
conventions,
it's
more
on
the
libraries
and
our
auto
instrumentation
packages,
and
I
don't
think
there
are
any
consequences
except
some,
some
sampling
scenarios.
Let's
say
they
want
to
work
or
something
else.
At
the
same
time,
I
feel
like,
maybe
x
years
from
now,
we
should
have
a
certification
that
we
can
run
instrumentation
against
something
and
say
good
or
bad,
and
if
somebody
which
is
should
be
there,
but
it's
not
there.
A
C
All
right,
so
I
think
that's
all
the
topics
for
today
only
have
a
couple
minutes
left.
So
I
wanted
to
say
thanks
for
the,
if
anybody
had
one
anything
last
minute
go
ahead
and
discuss
it
now,.
D
Yeah
I
added
this
this
last
topic
here,
so
maybe
we
can
just
go
through
it.
So
basically
that's
again
about
the
scope
of
the
changes
that
we
want
to
do
for
semantic
conventions
for
hdp
submitting
conventions.
Unfortunately,
I
cannot
share
with
screen
on
the
mac
michael
can
I
can
I
send
the
link
to
the
chats?
Can
you
please
help
me
to
share
it
sure,
one
second
yeah.
So
last
time
we
spoke.
Basically,
there
were
a
couple
of
changes
proposed
to
the
original
documents,
so
just
wanted
to
share
that.
D
So
I
added
these
general
concepts
here.
Basically,
that's
that's
something
that
we
discussed
last
time.
So
we
have
this
open
questions
related
to
like
a
configuration
like
which
language
you
want
to
do
want
to
use
to
set.
For
example,
what
is
the
status
codes?
D
Another
thing
is
just
the
thing
that
we
just
discussed
like
what
is
the
level
of
utilizations,
or
should
it
be
suppressions
or
whatnot,
and
another
thing
is
for
links,
so
I
added
this
this
stuff
here,
but
I'm
not
proposing
any
kind
of
solutions
in
this
document,
so
just
just
put
it
to
the
scope,
and
another
thing
that
I
added
here
is
the
security
concerns
concerns
it's
just
behind
the
middle.
D
So
basically,
some
attributes
can
contain
some
sensitive
information
or
potentially
sensitive
information,
and
we
also
probably
want
to
mark
these
attributes
or
just
like
emphasize
that
how
exactly
the
information
should
be
treated
in
these
attributes.
So
this
is
basically
about
the
scope
and
the
the
only
goal
that
I
have
for
this
document
is
to
agree
on
the
changes
that
we
want
to
do
for
the
semantic
conventions,
the
existence
of
many
convention
stock
to
basically
bring
it
to
the
stable
state.
D
So
do
you
guys
have
any
additional
comments
or
maybe
some
additional
things
that
we
want
to
add
to
the
scope
or
actually
yeah?
That's
the
main
question
that
I
currently
have,
and
we
can
continue
to
to
have
the
discussion,
maybe
in
slack,
but
there
is
no
much
activity
there.
So
that's
that's
why
I'm
asking
this
here.
C
Right,
I
think
the
only
comment
that
I
had.
Maybe
it's
a
question
to
ted.
Maybe
if
you
could
help
poke
some
of
the
community
to
see
if
they're,
okay
with
the
scope,
because
it's
just
it's
fine.
If
we
don't
have
everything,
I
do
think
we
just
have
to
have
a
set
of
items
that
we
can
feel
confident
that
we
can
get
to
a
1.0
spec
and
have
something
stable.
C
B
Yeah
I
mean
I
feel
like
as
far
as
like
declaring
things
stable.
We
we
need
to
have
implementations,
you
know
successfully
written
to
me.
That's
like
the
only
extra
thing
I
would.
I
would
say
it's
not
just
not
just
a
scope
of
spec
work
but
also
like,
like
you
know,
validation
with
actual
implementations.
C
Sure
I
mean
that
that
should
validate.
I
mean
you
need
that
in
order
to
validate
whatever
topics
we
have
within
scope
right,
I
think
the
challenge
that
what
I'm
hearing
from
dennis
is
like:
hey,
we're
not
having
enough
activity
to
ensure
that
that
otep,
which
is
really
just
to
say,
hey,
what's
the
scope
of
items
that
we
want
to
address,
you
know
to
get
to
1.0
and
then
your
part
about
hey.
Actually,
how
do
we
get
to
stability?
C
Yes,
all
that
is
absolutely
true,
so
I
don't
know
if
we
want
to
include
that
in
that
otap,
but
we
can,
if
you
think,
that's
relevant.
B
I
think
some
road
mapping
is
fine.
I
do
feel
like
like
as
far
as
oteps
go.
You
know
the
oteps
are
rfcs.
They
tend
to
be
more
focused
on
a
proposal
like
a
technical
change
to
the
spec,
so
I
think
one
reason
why
it
might
be
a
little
hard
to
get
feedback
here
is
just
more
just
like
here's.
A
road
map
and
people
are
like
okay
sounds
like
a
good
roadmap.
B
Maybe
one
of
the
really
what
it
comes
down
to
perhaps
is
just
ensuring
that
the
tc
is
aware
of
this
roadmap
and
is
signed
off
on
it.
It's
being
like
we're
gonna,
do
this
work
and
then
we're
gonna
say
these
things
are
stable
once
we're
done
like
tc,
please
like
confirm
you,
you
think
that's
this
is
reasonable.
Or
do
you
have
other
criteria,
because
that's
that's
who
ultimately
has
to
approve
this
thing?
B
Okay,
so
and
then
there's
just
the
the
practical
aspect
you
need
to
have
for
approvers
right
and
you
can
find
those
under
like
the
specs,
spec,
approvers
and
spec
trace
approvers.
B
B
If
you
look
in
the
code
owner's
file
for
for
this
repo
and
then
compare
that
against
the
github,
like
the
teams
and
the
open
telemetry
org,
those
are
like
the
specific
people
who
need
to
get
pinged
in
order
to
get
this
approved.
So,
okay.
D
B
Do
you
agree
that
this
scope
of
work
looks
correct
if
we
perform
this,
will
you
be
willing
to
if
we
perform
the
scope
of
work,
would
will
you
be
willing
to
sign
the
semantics
office
stable,
or
do
you
have
going
to
have
other
requirements.
C
Yeah
all
right
great
server
going
over
folks,
but
thanks
a
lot
good
discussions
today,
all
right
have
a
good
evening.
Thank
you,
see
ya.