►
From YouTube: 2021-09-16 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
A
C
C
I
think
johannes
left
us
some
agenda
to
discuss.
C
C
C
B
D
B
D
So
I'm
just
trying
to
skim
it,
so
is
it
that
christian
is
saying
that
we
shouldn't
have
a
create
span,
because
it's
not
a
networking
concern
and
your
argument
is
that,
yes,
we
should
is
that
right.
In
summary,.
C
Yeah,
I
think
this
is
one
of
the
things
that
we
would
have
to
decide
in
this
working
group
that,
even
though
it's
not
a
network
call,
but
the
the
context
it
has
is
unique
per
message.
C
And
if
we
have
a
bunch
of
messages,
each
message
has
a
unique
context,
but
they
are
transported
together
right
or
maybe
they
are
created
in
one
context,
buffered
in
memory
and
sent
from
the
other
threat
right.
So
they
have
to
carry
the
context
but
how
we
rip
and
if
they
carry
a
context,
it
should
be
a
unique
one,
which
means
the
new
span.
B
B
D
I'm
just
thinking
I
I
think
for
the
stuff
I've
done
to
date.
At
any
rate,
I've
treated,
create
and
publishing
it
publishing
as
one
span,
but
that's
also
because
we
haven't
had
the
ability
to
batch
the
actual
publishing
to
a
broker
aspect.
It's
always
been
one-on-one,
so
they
were
indistinguishable
from
that
perspective.
But
I
certainly
agree
that
if
there's
the
ability
to
batch
a
group
of
messages
and
send
them
to
a
broker
at
once,
that
is
the
published
step.
A
B
Yeah,
I
just
want
to
open
the
specification
to
make
sure
that
I'm
saying
correct
things,
so
I
I
think
that
regarding
the
batching,
but
actually
it's
a
different
topic-
maybe
I'll
open
it.
When
we
talk
about
batching,
so
never
mind
for
now,.
A
C
C
So
like
you
can
have
multiple
retries,
but
still
one
message
created
right
and
then
there
is
a
question:
how
will
representative
tries?
We
don't
have
an
answer
as
well
right
all
right
so
also
like,
I
think,
for
the
backhands.
C
D
D
It
would
look
very
weird
to
have
a
incoming
span
potentially
into
something
that
then
produces
messages
and
then
have
a
whole
bunch
of
other
retry
spans
and
then
a
real
one,
and
it's
it's
a
little
obtuse.
Looking
at
that
as
to
what's
caused
that
to
happen
without
something
in
front
of
it.
That
says:
oh
I'm
trying
to
create
something.
C
And
I
I
heard
a
lot
of
discussions
and
a
lot
of
arguments
around
that
we
kind
of
already
have
instrumentation
and
they
kind
of
work
already.
A
For
the
for
the
java
instrumentation
that
we
have,
I
mean
we've
kind
of
all
known
that
the
messaging
semantic
conventions
were
still
in
flux
and
it
hasn't
really
even
been
clear
for
we've
had
lots
of
discussions
internally
among
the
java
instrumenters
how
to
even
interpret
the
specs.
A
A
A
And
there
was
a
previous
discussion
like
around
the
earlier
this
year
when
the
sdks
were
starting
to
go
1-0,
there
was
discussion
around
telemetry
stability
guarantees,
and
that
was
we
were
told
explicitly
by
the
open,
telemetry
community
to
not
release
to
not
declare
stability
of
any
telemetry
until
the
those
backward
compatibility,
telemetry
guarantees.
C
Yeah
so
basically
yeah,
okay
cool
great.
So
then
it
seems
we
are
kind
of
in
consensus
within
this
small
group
that
we
probably
want
to
separate
our
creation
and
publishing
right.
So
this
the
first
discussion,
so
I'm
tr
I'll
try
to
document
what
we
discovered
and
now
pink
christian
to
comment
on
this.
C
C
B
I
have
something
that
I
want
to
talk
about.
If
it's,
okay
with
you,
I
implemented
the
aws
sqs
instrumentation
in
node
and
like
every
week
I
get
people
writing
me
opening
issues
saying
that
the
messaging
on
sqs
doesn't
work
because
sqs
by
default
is
doing
batch
receive
and,
according
to
the
specification,
it's
a
very
like.
Where
does
it's
opening
a
new
trace
for
the
receive?
A
I
was
curious
what
you
were
where
you
were
going,
if
you
don't
mind
picking
it
up
from,
you
were
right.
When
you
were
breaking
up,
you
were
saying
that
the
sqs
might
default
back
receives
and
so
something
about
the
spec
starting
saying
to
start
a
new
trace
and
then
guessing
that
users
were
complaining
that
traces
were
broken.
B
Yeah,
it's
it's
like.
Never
being
it's
every
time
every
week
someone
else
saying
your
instrumentation
doesn't
work
like
it
follows
the
spec,
but
it's
it
goes
against
what
people
expect
the
traces
to
be
so
if
they
send
a
message
and
the
message
is
received
on
the
other
end,
so
people
are
expecting
it
to
be
one
place,
so
they
they
like
have
a
single
trace
and
they
can
see
the
the
operations
in
a
singular
logical
flow.
B
But
but
current
specification
states
that
when
we're
doing
patch
receive,
then
we
should
open
a
new
trace
for
the
receive,
and
I
completely
understand
why.
But,
but
I
think
it's
a
very
problematic
issue.
At
least
my
feedback
from
people
is
that
it
goes
against
what
they
expect
to
see.
So
I
want
to
ask
about
your
opinions.
C
I
think
in
azure,
as
the
case,
we
decided
that
even
if
we
just
receive
a
batch,
but
we
don't
follow
the
current
conventions,
I'm
sorry,
but
we
decided
that
if
we
receive
a
badge,
but
there
is
a
one
message-
we'll
still
continue
a
trace,
because
this
is
easier-
and
I
think
this
is
because
of
the
current
state
of
all
the
tracing
backends,
that
don't
support
links
well
and
assuming
they.
They
did
that
for
the
customers
there
will
be
much
less
difference
between
if
it's
a
single
trace
or
it's
multiple
traces.
B
So
it's
only
if
it's
a
single
message,
if
you
better,
receive
multiple
messages,
but
then
you
process
them
one
by
one,
then,
for
this
flow,
you're
still
creating
a
different
race
on
the
receiver
right.
C
For
the
instrumentation
and
sdk,
we
don't
know
what
happens
besides
our
api
right.
So
besides
the
sdk
api,
so
if
user
receives
a
badge
when
they
write
their
for
loop,
we
cannot
instrument
it.
So
we
can
tell
users
how
to
instrument
them
and
we
can
provide
like
I,
I
tried
to
do
it
with
our
current
instrumentations
and
like
what
we
can
provide
on
top
of
open.
Telemetry
is
easier
ways
for
user
to
extract
the
context
from
the
message.
Maybe
sdk
should
provide
some
apis.
C
Maybe
instrumentation
package
should
provide
this
convenience
method
to
extract,
but
I
think
this
is
the
we
can
leave
it
beyond
this
current
specification
discussions.
C
It
can
be
added
on
top,
but
basically
we
have
to
create
a
new
trace,
because
we
have
10
different
messages,
which
one
would
we
pick
and
then
we
like
to
work
with
the
backhands
would
eventually
support
it
right,
but
before
that
we
can
tell
users
what
to
do
to
trace
in
the
video.
This
is
my
opinion.
B
So
you're
saying
that
you'll
do
a
batch
receive
you
get
back
like,
let's
say
10
messages
and
then
the
user
has
to
iterate
over
those
messages,
and
you
are
not
even
able
to
create
the
processing
spans
and
understand
the
context
of
downstream
operations.
C
Right
so
in
in
case
we
have
some
handlers
handler
apis
and
many
streaming.
Sorry,
many
messaging
sdks
allow
you
to
have
a
handler
per
message,
and
in
this
case
we
are
able
to
instrument
single
messages,
but
if
it's
just
a
batch
receive-
or
if
this
is
a
batch
received
handler,
then
we
just
do
our
best
effort
here.
B
B
C
And
the
problem
here
is
that
not
it's
just
that
we
want,
if,
if
we
knew,
we
always
want
to
to
have
single
message
processing,
it
would
be
easier,
but
we
don't
know
right.
So
let's
say
you
take
a
hundred
messages
of
this.
I
don't
know
temperature
information
and
you
aggregate
it
and
you
create
an
average
thing.
C
B
Yeah,
I
agree
it
is
a
problem,
but
I
think
that
if
a
user
is
a
better
receiving
100
messages
and
then,
let's
say
for
which
message
is
doing
a
db
operation,
so
at
the
end
it
just
gets
like
100
db
operations
without
any
context
of
what
causes
this
operation
to
to
be
initiated.
B
So
if
he
has
like
a
he
knows,
okay,
I'm
processing
a
message
and
because
of
the
processing
of
this
message,
I'm
accessing
the
db.
Then
everything
is
much
more
organized,
but
is
a
technical
issue
of
how
to
tell
that
this
is
the
situation.
C
C
So
let
me
see
how
I
can
separate
them
and
they
go
and
let's
say
in
java,
they
discover
with
an
annotation
and
assuming
they
can
put
the
right
context
there,
or
maybe
we
provide
some
examples
to
them.
They
just
go
and
discover.
Okay,
I
just
dropped
my
function
with
this
annotation
and
I'm
done
and
now
it's
perfect
right.
C
B
Unfortunately,
I
don't
have
a
solution.
I
I
have
to
say
that
on
my
side,
my
experience
is
that
people
they
don't
go
so
deep.
They
install
whatever
is
on
the
market
like
whatever
they
found
they
find
in
the
registry,
and
then
they
look
at
the
trace
and
if
it
doesn't
look
good
they're,
just
disappointed
they're,
not
making
any
effort
to
to
change
their
code
or
to
add
things
like
many
of
the
consumers
they
use
like.
B
Vendors,
that
okay
or
the
government
sdk,
and
they
don't
want-
or
they
don't
have
the
energy
or
the
wheel
to
to
start
instrumenting
their
own
code.
Specifically,
so
I
think
it's
it's
going
to
be
an
issue,
at
least
on
on
the
feedback
that
I'm
getting
from
from
our
users,
which
are
very
confused,
and
so
I
I
just
want
to
hear
if
you
have
opinions
about
it,
but
I
think
we
all
agree
that
it's
a
difficult
situation
to
handle.
A
Maybe
this
would
could
be
you
know,
because
it's
a
that
makes
a
lot
of
sense
as
a
default.
You
want
users
to
get
that.
A
You
know
nice
behavior,
what
looks
nice
in
most
cases
and
in
most
back
ends
and
to
let
mill
is
earlier
when
point
about
back
in
support
of
links,
but
having
that
be
a
configuration
option
to
use
links
and
instead
of
parenting
in
that
way,
which
I
think
is
the
better
long-term
solution
is
the
links
because,
like
the
batch
like,
if
somebody
is
doing
something
like
in
a
batch
say
in
their
say,
they
have
a
scheduled
job,
and
in
that
you
know
once
an
hour,
they
pull
down
a
bunch
of
messages
and
process
them.
A
A
A
I
mean,
I
guess
the
only
question
there
is
is
if
we
do
have
a
telemetry
stability
guarantee
at
some
point.
After
that,
we
probably
can't
flip
the
default
behavior.
The
default
configuration
option.
C
I
think
when
we
talk
about
telemetry
stability,
we
mostly
talk
about
things
like
attributes
but
like
if
you
have
a
span
with
the
right
parent
or
if
we
have
a
spend
with
a
link,
it's
it's
kind
of
beyond.
You
have
to
support
it
either
way,
unless
some
exporters
or
backhands
rely
on
very
specific
things
right,
which
also
could
happen.
Yeah,
you're
right.
A
Yeah,
I
I
think
of
the
telemetry
stability
in
terms
of
like
if
people
have
set
up
alerts
on
certain
things-
and
I
could
see
possibly
I
mean
you
know
it's-
it's
not
gonna
break
many
people,
so
I'm
not
hugely
concerned
about
it,
but
I
think
that
the
goal
in
the
community
is
to
have
more
is
to
have
that
strict
telemetry
stability
at
some
point.
C
B
C
Okay,
then,
I
think
it
kind
of
makes
sense
to
to
talk
about
these
items,
even
though
we
don't
have
the
enough
people
to
build
the
con,
like
the
the
community-wide
consensus,
at
least,
we
can
understand
each
other
better
and
next
time
we
will.
It
will
be
easier
for
us
to
talk
about
something.
What
do
you
think.
C
I
think
we
put
it
out
of
scope
in
this
spec
because
it's
just
it
sounds
like
it's
still,
this
asynchronous
pattern,
but
the
all
the
attributes
we
will
put
the
information.
We
would
need
all
the
logic
about
the
retries,
the
span
creation,
which
spans
you
create
it's
just
too
different.
C
So
I
think
we
decided
to
keep
what
is
that
anyway,
we
decided
to
keep
them
out
of
school.
C
Right
so
there
is
no
spence
to
publish
and
receive
right.
There
is
a
spend
to
create
and
spend
to
process.
C
D
D
I
can't
remember
the
it
might
be
a
netty
channel
internally.
I
can't
remember
exactly,
but
it's
still
being
published
to
a
channel,
it's
just
that
it
doesn't
then
get
written
to
a
broker.
C
D
D
Currently
there
wouldn't
be
a
value
for
that
now,
whether
that
means
that
needs
to
be
an
optional
field
or
whether
it's
still
required,
and
we
add
an
option
for
like
internal
or
something
to
indicate
that
it's
not
going
through
a
broker,
but
I
think
most
of
the
stuff
is
still
applicable.
C
Okay
and
then,
when
we
have,
let's
say
this
specification
where
we
say
this
is
applicable:
if
it's
not
the
memory
cure
channel
and
then
this
is
optional
because,
but
if
you
have
a
broker,
then
you
have
to
put
it.
C
It
sounds
to
me
that,
like
let
me
give
you
an
example,
I
have
a
team
of
developers
who
work
on
sdks
and
they
don't
have
any
knowledge
about
tracing
very
little.
So
when
I
give
them
spec
like
that,
they
don't
understand
it.
They
need
my
help
to
parse
it,
and
I
want
to
eliminate
myself
in
the
process
and
write
the
spec
that
people
who
are
not
very
deep
into
tracing
can
understand
so
some
clarity
around
this.
It's
it.
It
really
bothers
me
and
I'm
not
opposed
to
this
thing.
It's
just
the
the
general
impression.
A
Can
what
exactly
are
we
talking
about
with
in-memory
cues?
I
mean.
Is
this
something
that
really
like
a
real
like
messaging
cues,
or
is
this
just
like
say
any
kind
of
cue
that
I
throw
things
into
locally
and
pull
from.
D
D
Where
you
will
often
as
instead
of
having
direct
calls
between
methods
you'll
chain
a
different
execution
together
with
in
what
we
have
in
quarks,
we
call
it
like
outgoing
methods
that
produce
messages
and
incoming
ones
that
receive
them.
So
you
can
chain
these
together
into
a
sequence
and
you
can
broadcast
so
that
the
same
message
can
be
sent
to
multiple
methods
and
all
this
kind
of
stuff.
So
it's
kind
of
a
way
to
separate
the
code
into
more
district.
D
No,
we
actually
well
with
carcass.
We
create
spans
as
well,
so
you
can
see
or
each
hop
is
a
separate
span.
D
D
Yes,
so
I
guess
I
I
should
clarify
that
this
isn't
creating
a
span
on
every
use
of
completion
stage
or
anything
like
that.
This
is
purely
because
what
we
do
with
quarkus
is
we
kind
of
allow
you
to
create
methods
that
can
be
used
as
part
of
a
reactive
stream,
but
done
in
a
declarative
way
to
help
those
who
are
more
familiar
with
the
java
e
and
spring
programming
models
to
implement
reactor
streams.
D
So
it's
basically
at
each
of
those
that
we're
automatically
creating
spans
for
producing
the
messages
that
might
go
into
that
in
memory
channel
and
then
receiving
them
in
the
channel
as
well.
I
don't
think
the
expectation
is
that
those
methods
would
be
very
small,
so
sometimes
they
are
a
reasonable
execution
time
as
well.
D
C
D
I
don't
think
there's
anything
in
the
current
java
telemetry
agent.
We
I've
done
this
within
our
reactive
libraries
that
interact
with
quarkus
and
the
hotel
agent.
D
C
A
Sounds
I
mean
it
sounds
like
messaging
sounds
very
similar.
I
I
think
from
the
I
wouldn't
necessarily
want
to
have
those
on
by
default.
A
I
mean
from
our
particular
customer
base
because
they
are
very
since
we
charged
by
ingestion
they're
very
always
concerned
about
additional
sands,
but
it
would
be
also
nice
to
have
a
if
there
was
a
way
to
crop,
and
I
guess
if
we
found
a
way
to
if
we
suppress
those
spans
that
we
still
propagated
the
context.
A
A
D
Yeah,
I
think
that
if
you
there's
going
to
be
the
ability
to
suppress
a
span,
you
definitely
want
the
context
propagated,
because
there
could
be
situations
where
you
have
an
application.
That
has
a
bunch
of
phases.
You
have
a
incoming
or
consuming
side
from
somewhere
externally
do
a
bunch
of
stuff
internally
and
then
send
something
out.
Another
message
out
and
you
don't
want
to
lose
that
connection
between,
even
if
you're
not
showing
the
spans
inside.
C
D
Possibly
for
some,
but
with
qarcus,
we
do
because
we
define
metadata
in
addition
to
the
payload,
that
maps
onto
like
kafka,
record,
headers
or
amqp
headers
or
whatever
it
might
be.
If
you're
dealing
with
external
and
internally,
it's
just
a
java
object.
A
I
could
be
a
good
helpful,
like
addition
to
the
definition
of
what
memory
q
here
means
is,
I
think
those
two
points
about
they
have
like
names
like
they're
sort
of
like
real
q
named
cues
and
the
the
messages
that
you
can
attach
to
the
messages.
A
C
And
so
maybe
we
can
kind
of,
if
you
maybe
you
can
summarize
what
are
the
things
that
would
be
useful,
like
maybe
the
attributes,
just
briefly,
without
naming
maybe
just
document
what
you've
done,
how
it
works.
It
would
really
help,
and
I
think
that
these
two
specs
share
a
lot
in
common,
at
least
the
relationships
between
spans
for
sure
and
having
them
be.
C
D
Okay
I'll
add
something
to.
I
think
the
comment
in
that
otep
I
added
about
it,
so
it
can
flesh
out
some
more
awesome.
C
Okay,
so
the
last
thing
is
the
settlement
optional
settlement.
I'm
sorry,
I'm
not
familiar
with
the
discussion
here
is
anyone
here
who
was
part
of
it.
B
Yeah,
it
was,
I
hope
my
internet
is
stable
enough.
If
you
can't
hear
me,
then
I'm
sorry-
and
we
can
this.
B
Yeah
so
so
I
was
just
reviewing
the
hotep,
and
so
can
you
hear
me
yeah
sorry.
Can
you
hear
me
yeah
yeah?
So
so
there
was
talking
about
the
settlement
part
in
the
in
in
real
world.
The
settlement,
like
does
not
always
settlement
like,
for
example,
some
systems
once
they
deliver
the
message.
It's
considered
settled
and
other
systems.
They
just
do
like
a
pub
sub.
B
So
so
it's
just
writing
a
comment
about
it,
but
I
think
the
interesting
issue
is
whether
we
should
create
a
spend
for
the
settlement
or
whether
the
settlement
should
be
part
of
the
processing
span
or
the
receive
span,
because
I
think
it's
not
very
clear.
Sometimes
you,
like
the
user,
has
to
like
specifically
says
I
want
to
settle
this
message
and
then
I
think
it's
it's.
C
So
I
think
if
the
settlement
for
this
system
is
optional,
we
are
not
going
to
create
the
spend
either
way
right.
So
there
is
probably
no
api,
no
nothing
and
since
like
for
the
first
part
of
your
question
right
so
for
the
system's
optional
settlement,
yeah.
Is
there
any
problem
with
just
this
part?
Okay,
no
settlement
no
span.
C
B
I
think
some
flows
can
contain
a
settlement
and
some
will
not
contain
a
settlement,
so
I
think
it's
something
worth
mentioning
in
the
spec,
so
it's
obvious
to
people
that
it's
optional,
that
they
can
either
expect
it
or
not,
expect
it,
and
also
it
can
be
beneficial
for
implementation,
libraries
to
document
if
they
like
how
they
handle
settlement
if
they
create
a
spend
for
settlement.
C
I
think
about
like
let's
say
the
case:
where
users
explicitly
call
settlement,
they
want
to
know
if
they
called
it
right.
So
if
their
application
work
works
correctly
and
that
they
they
settled
the
right
one.
Maybe
if
it's
per
message,
then,
if
they
forgot
it
or
maybe
if
they
threw
an
exception
before
that
that
then
they
called
the
wrong
settlement
method,
they
would
want
to
know.
C
And
then
settlement
is
an
remote
procedure,
call
usually
right,
so
if
it
does
not
complete
or
if
it
never
like,
reaches
the
destination,
they
would
want
to
know
that
it
wasn't
settled
because
of
the
network
issue.
C
C
Even
then,
there
are
some
configurations,
for
example,
we
abandon
message
or
we
put
it
to
the
deadlocker
queue
and
it
depends
on
the
number
of
times
we
processed
it
and
the
user
configuration.
C
So
I
think,
as
a
sdk,
we
want
to
provide
this
visibility.
What
really
happens
beyond
this
handler?
So
your
message:
it's
still
your
message,
even
though
that
you
didn't
write
the
code
to
settle
it.
It
was
attempted
three
times
and
then
put
to
the
dead
letter
queue
and
go
there
and
check
and
like
where
what
happens
the
stage
of
this
message,
it's
part
of
the
settlement
call,
so
we
should
tell
users
that.
C
C
Did
you
hear
my
long
speech?
Do
you
do
you
have
anything
you
don't
agree
or
want
to
challenge.