►
From YouTube: 2021-10-12 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
Not
I'm
not
too
sure
how
attendance
is
going
to
be
today,
given
that
cubicon
is
going
on.
So
let's
see
if
folks
join
all
right,
but
right
now
I
don't
see
anything
in
the
agenda,
so
maybe
let's
give
five
minutes
and
see
how
it
goes
and
then
more
folks
join.
Then
maybe
we'll
add
some
agenda
topics,
otherwise
you
may
need
to
cancel.
Oh,
let
me
join.
B
A
Yeah
they
can
probably
catch
up
on
the
recording.
So
maybe
we
just
do
the
demo
go
through
it
and
then
then
we
can
let
folks
catch
up
on
recording.
B
Let's
probably
make
it
then
so,
yeah
last
week,
together
with
mila,
we
had
some
experimentations
related
to
the
http,
retries
and
redirects.
So
basically,
that's
the
topic.
We
want
to
clarify
for
http
semantic
conventions
doc
this
this
is
the.
This
is
something
that
we
have
like.
I
proposed
for
changes
for
the
scope
in
the
pull
request
that
we
discussed
probably
last
time
so
and
a.
C
B
Actually
I'm
doing
this
for
the
first
time
on
zoom
so
looks
it
should
be.
It
should
be
all
right
yeah.
We
can
see
okay,
yeah
amazing,
so
this
is
the
this
is
jager
ui
and
I
have
already
I
have
some
like
a
different
examples
of
how
it
can
be
done
with
net
instrumentation.
B
So,
first
of
all
just
wanted
to
bring
a
little
context
here
so
for
net
applications.
We
have
auto
instrumentation,
which
is
available
for
http
client
and
for
http
server
for
asp.net
core.
So
I'm
going
to
show
you
how
it
actually
works
with
kind
of
totally
default
behavior
when
all
the
instrumentation
enabled-
and
we
have
vanilla,
http
client
for
the
pads
and
how
it
actually
works
for
both
retries
and
redirects
and
then
like
just
to
show
how
it
can
be
done
differently.
B
I
have
all
this
like.
I
want
to
instrumentation
disabled
and
have
have
the
instrumentation
for
the
code
fully
manual.
So
basically
the
scenario
for
the
first
or
the
first
scenario
is
the
following.
So
we
have
some
api.
B
Actually,
I
was
using
this
public
api
ipis.org,
so
we
are
sending
just
requests
to
404
and
basically
server
response
which
for
oppor
in
this
case,
so
we
have
clients.
B
Main
place,
yeah,
sorry
yeah,
all
yeah.
Probably
this
piece
can
not
be
zoomed
but
basically
yeah.
So
this
this
api
returns
just
404.,
and
in
this
case
we
have
client,
instrumented
or
actually
auto,
instrumented
and
service,
like
I'm,
not
instrumented.
So
we
are
not
collecting
traces
from
service
and
server
side
in
this
case
and
the
the
result
looks
like
like
the
following.
So
basically
we
have
dotnet
client
app.
We
have
top
level
spam
created.
This
is
called
start.
B
So
this
is
the
the
case
for
all
the
cases
that
I'm
going
to
do
show
today.
So
this
is
like
a
level
top
level
span
and
we
have
auto
instrumentation
enabled
with
rich
rice
available
inside
like
a
vanilla,
http
client.
So
this
actually,
this
one
did
retries
three
times,
but
in
the
end
it's
still
like
a
four
or
four
just
because
the
api
always
returns
four
or
four.
But
I
said
like
a
three
times,
but
we
have.
We
see
only
one
trace
here.
B
That's
because
the
way
how
auto
instrumentation
works,
actually
it
reuses
the
like
overall
or
the
like
a
initial
http
request
and
then,
if
it's
available,
then
all
the
traces
are
suppressed.
So
basically,
that's
how
it
looks
like
for
like
a
really
standard
behavior
that
we
have
currently
for
that
net.
Just.
E
B
Exactly
exactly
so,
that's
basically
just
the
current
behavior,
but
if
you
go
like
a
and
do
is
like
according
to
specifications,
so
we
have
like
this
instrumentation
disabled.
So
everything
it's
debated
manually
but
still
client
is
instrumented.
Service
server
side
is
not
instrumented,
then
it
will
look
like
the
following
or
but
it
is
oh
yeah
here
it
is
so
we
have
dot
net
app.
We
have
three
retries
but
like
and
all
of
them
just
to
this,
like
a
public
apis.org
for
a
form.
B
The
thing
is
that
we
have
these
three
retries
but
kind
of
the
problem
here
is
that
we
see
we
see
them,
but
the
problem
is.
We
cannot
correlate
them,
so
we
cannot
say
that
actually,
those
are
retries
for
for
the
same
requests
just
because
we
don't
have
any
kind
of
top
level
span
or
top
level
layer
or
something
so
we
see
just
three
tries.
B
We
see,
there's
siblings
in
terms
of
spams,
so
this
is
the
default
behavior
or
sorry
like
I
expected
behavior,
but
probably
this
can
be
something
that
can
be
improved.
B
B
So
this
is
the
example.
So
here
we
have
like
this
again
top
level
span.
Then
we
have.
Oh
I'm
sorry.
This
is
the
like
the
same,
the
the
exactly
what
I
said,
but
this
is
for
without
instrumentation
enabled
so
here
we
have
just
like
a
top
level
span
for
http
clients
right,
but
since
we
don't
have
because
of
this
back
end
up
in
the
input
map,
we
don't
have.
We
don't
didn't
see
any
reach
rights
from
the
client
side
perspective,
so
we
only
see
traces
from
server
side
perspective.
B
So
this
one
is
a
client
side,
client
side
span
and
these
two
are
server
side.
So,
since
the
first
one
just
returns
like
a
404
or
server
returns,
404
for
a
sec
first
request
and
then
it
returns
200.
Then
we
see
these
two
two
server
side
spans,
but
this
is
for
auto
instrumentation
and
the
same
the
same
stuff
is
for
there.
It
is
so
it
should
be
this
one,
the
same
stuff,
but
with
this
metal
instrumentation.
B
So
here
we
again
like
I
see
two,
two,
two
retries,
so
this
is
the
client.
This
is
server.
This
is
client
with
the
server,
but
again
like
no
correlation
between
between
tries.
B
Right
and
actually
that's
that's
the
kind
of
kind
of
behavior,
the
current
behavior
or
expected
behavior.
According
to
the
current
version
of
the
http
semantic
convention,
specification.
E
B
Correct
yeah,
thanks
for
the
correction.
Actually,
since
we
don't
have
it,
we
kind
of
identify,
then,
basically,
all
we
can
do
is
just
have
have
this
behavior,
but
what
we
can
improve
and
that's
exactly
what's
the
points
for
experimentation
that
we
did
with
ludmila?
Basically,
we
can
have
so
it
should
be.
It
should
be
it.
We
can
actually
introduce
like
a
top
level
span
or
basically
for
each
retry.
B
We
can.
We
can
say,
okay
if
we
want
to
correlate
all
the
traces
for
retries,
we
can
create
a
top
level
spam
when
we
start
like
http,
http,
operation
or
http
call,
and
then,
if
we
see
all
these
retrieves,
we
can
actually
have
them
correlated
right.
So
let
me
see
what
we
have
here.
So
probably
not
the
one.
So
I
have
too
much
well.
E
Denis
you're
looking
so
basically
the
idea
of
having
logical
span
like
in
the
perfect
world.
We
don't
want
to
have
a
logical
span
for
every
try
because
most
of
the
for
every
request,
because
most
of
the
requests
have
just
one
try.
It
would
imply
that
we
have
logical
and
physical
for
all
for
everything
which
is
too
much
and
we
thought
like
how
can
we
achieve
like
conditional
thing?
So,
if
they're
right
right
can
we
have
a
logical
call
right?
This
picture
is
probably
logical.
Call
all
the
time.
B
Right,
so
that's
actually
logical
call,
but
only
logical,
collegial
call
only
so.
Basically
what
we
see
here
that
from
the
client
side
perspective
we
we
we
see
this
read
right.
So
this
is
the
client.
We
see
this
kind
of
call,
but
we
don't
see
since
we
don't
have
any
physical
kind
of
or
kind
of
transport
or
http
level
calls
or
spams,
then
we
just
see
the
top
level
one,
because
just
that's
the
one
that
we
have
on
the
top,
so
those
two
are
server
or
from
the
server
side.
B
So
we
can.
We
can
do
it
like
this.
So,
instead
of
like
I
see
all
the
details
related
to
like
a
retries
from
the
client
side,
we
can
say
okay,
so
we
have.
We
have
a
client-side
call.
It
was
eventually
success
successful,
but
it
has
basically
two
tries
just
because
we
see
two
server-side
spans
here
right.
So
this
can
be
that's
basically
the
way
how
we
can.
We
can
change
the
behavior
so
instead
of
having
just
client
sides
client-side
spans
that
are,
we
cannot
correlate.
B
We
can
have
just
one
logical
span
and
inside
is
all
the
like.
Basically,
since
we
have
server
also
instrumented,
we
can
actually
see
this
two
as
a
device,
but
again
like
in
case.
If
server
is
not
instrumented,
we
actually
losing
all
these
details
about
retries.
B
So
this
is
the
basically
opposite
behavior
to
the
behavior
that
I
showed
previously
and
the
third
option
is
actually
we
can
combine
both
and
we
can
see
like
at
this
logical
span
and
physical
span.
So
this
is
the
another
example
that
I
have
here.
So
that's
that's
exactly
it
so
here
we
have
all
the
details
available
right.
So
here
we
have
this
logical
span,
basically
saying
about
like
we
are
going
to
start
this
http
call,
and
then
we
see
physical
clients,
client
thrice,
and
we
see
that
the
first
one
was
unsuccessful.
B
This
is
a
server
run
and
then
we
have
second
client
try
and
this
one
was
successful.
So
this
picture
provides
us
like
a
full
details,
all
the
all
the
details,
but
in
the
same
time
we
have
too
much
data
here
right.
So
if
this
this
behavior
is
enabled
by
default-
probably
it
will
be-
it
can
be
like
too
much
information
right
because
we
don't
have
in
real
world.
We
don't
have
retries
like
happening
all
the
time.
B
So
in
this
case
we
have
like
a
plus
one
logical
span
for
for
for
ev,
every
single
call.
So
that's
that's
all
I
have
for
reed
rice.
So
basically,
we
have
several
ways
of
doing
improvements,
but
probably
the
next
step
will
be
just
to
collect
the
feedback
like.
B
How
do
you
guys
feel
about
which
way
we
probably
or
what
want
to
go
and
how
we
can
change
the
the
current
behavior
in
a
way
that
it
will
be
like
a
more
it
will
provide
more
information,
we'll
be
providing
more
like
a
details
about
what
is
happening.
B
B
Yeah,
so
probably
that
will
be
the
next
yeah
we
can
do
it.
So
maybe
that's
that's
probably
something
that
you
can
talk
about
just
because
it
was
your
idea
originally
right.
E
It
doesn't
matter
yeah,
so
basically
the
idea
of
this
simple
will
it's
not
great
to
have
so
we
have
to
have
one
per
try,
because
we
want
context
to
be
unique,
but
it's
not
enough,
because
if
the
raw
tries,
if
there
are
multiple
tries,
we
cannot,
we
don't
know
if
if
they
were
retraced,
having
both
tries
and
logical
span
is
a
very
strict
resources.
E
E
So
we
cannot
insert
this
pen
in
the
tree
right
because
it's
done
already,
we
cannot
change
the
graph,
but
we
can
link
the
new
logical
stand
to
the
choice
and
this
the
logical
span.
Creation
technically
can
be
optional,
so
users
can
obtain,
but
it
doesn't
have
to
be
because
it's
it's
very
cheap
right.
We
are
adding
a
new
stand
for,
let's
say
one
percent
of
calls.
E
E
We
are
not
married
to
this
approach,
but
basically,
if
we
can
come
up
with
a
conditional
thing
that
adds
a
span
if
there
were
multiple
tries,
I
think
whatever
we
can
come
up
with
would
be
great.
This
is
the
goal
that
we
want
to
have.
B
So
maybe
maybe
next
step
here
will
be
just
to
flesh
it
out
and
like
I
have
it
documented,
and
then
we
can
discuss
it
once
again.
Maybe
next
week.
E
E
So
I
think
currently,
at
least
in
java
right,
it's,
there
is
no
physical
spans,
they
are
all
logical
and
the
problem
is
this:
that
they
have.
They
share
the
same
context
and
users
don't
have
enough
visibility
because
they
don't
know
if
it's
the
the
logical
call
that
took
that
much
or
it
was
ten
retries
right.
E
B
Yeah,
so
maybe
we
can
just
like
just
describe
all
this
stuff.
H
Okay,
can
anyone
and
everyone
here?
Yes?
Okay,
sorry,
I
don't
know
if
you
heard
anything,
no,
okay
cool,
so
I
was
saying
that
the
issue
has
come
up
about
reprice
for
the
adobe
sdk
instrumentation
and
that
currently
the
sdk
doesn't
even
provide
any
sort
of
hook.
That
will
allow
re-injecting
context
for
retries.
H
You
can
get
notified
on
a
retry,
but
you
can't
modify
the
request
anymore
after
that
starts
happening.
I
have
filed
an
issue
before
just
because
I
thought
it'd
be
nice
to
at
least
have
that
possibility.
But
for
now
we
haven't
really
found
a
reason
to
prioritize
that
over
the
retry
count,
which
is
what
we
render
in,
for
example,
x3.
B
So
basically,
like
I
currently
have
just
retry
count
for
the
top
level,
like
a
call
yeah.
But
basically
you
don't.
You
are
not
interested
in
the
visibility
like
why
it
actually
happens
or
why
you
had
a
retry
in
terms
of
like
a
duration
of
the
request
or
any
other.
E
H
I
think
it
does
make
sense
yeah.
We
just
need
to
take
into
account
that
some
libraries
might
need
to.
We
might
need
help
on
the
library
side,
also
like
they'd,
always
sdk,
for
example,
like
I
filed
this
show
a
couple
of
years
ago.
I
never
prioritize
it.
They
never
prioritized
it,
but
we
could,
but
in
currently
it's
just
not
possible
to
implement
for
the
adobe
sdk
yeah.
E
H
B
But
like
I
just
to
clarify
for
for
my
format,
knowledge
or
for
my
understanding
like
a
since
or
to
be
able
to
like
achieve
this
retro
account.
Basically,
you
need
to
have
requests
propagated
from
the
client
right,
so
you
need
to
have
the
same
trace
propagated
over
and
over
again
for
each
try.
But
if,
if
the
client
does
not
support
any
kind
of
distributed
tracing
that
will
be
not
available
right,
so
you
will
not
see
any
retry
accounts
just
for
like
a
vanilla,
http
client.
B
So
if
I
have
just
like
simple
http
clients
which
does
not
support
this
distributed
tracing,
you
will
never
know
if
the
the
requests
that
I,
like
you
are
receiving
from
dornis
client
are
retries
are
just
individual
yeah.
H
So
if
the
aws
stick
has
that
same
problem,
like
I
think
many
in
many
cases,
if
the
client
doesn't
have
a
callback
on
retries
or
something
like
that,
it
is
hard
to
get
information
about
retries,
including
even
just
account
with
aws
sdk.
We
do
have
a
callback
that
gets
invoked
and
retries
that
doesn't
allow
re-injecting
context,
so
we
are
able
to
get
a
con
account
without
new
spams,
while
some
libraries
probably
won't
even
allow
that
that's
true
right.
B
Yeah,
oh
yeah.
Basically,
the
one
thing
that
can
be
improved
here,
based
on
the
proposal
that
you
know
just
shared,
maybe
like
as
a
part
of
this
callback
additional
spam
can
be
created
in
case
retry
happen.
So
I
mean
it
looks
like
it
will
be
something
really
simple
to
do,
and
it
can
provide
more
information,
basically
just
to
have
this
logical
span
implemented.
B
Okay,
so
actually
yeah.
I
spent
a
lot
of
time,
but
I
probably
also
wanted
to
show
a
couple
of
things
related
to
redirects,
so
maybe
I
will
skip
all
this
stuff.
Basically,
the
idea
is
the
same,
so
we
can
have
this
one.
I
found
a
question
to
the.
F
B
Yeah,
that
is
so
actually,
as
per
the
current,
like
http
semantic
conventions
documents.
We
need
to
set
client
like
a
client
status
as
error
for
everything
which
is
not
like
100,
200
or
300.
B
F
Because
one
thing
I
wonder
here
is
that
I
mean
one
like
very
common.
I
think
troubleshooting
workflow
is
that
yeah.
You
there's
something
wrong
with
your
application
and
then,
for
example,
you
look
at
all
traces
that
have
errors
set
on
spans
and
I
mean
here
basically
that
could
be
like
a
force
positive.
Basically,
because
you
have
the
first
three
try
fails,
but
the
second
we
try
kind
of
the
the
first
try
fails,
but
the
second
retry
succeeds.
F
E
I
think
that
the
this
binary
error
or
success,
or
no
it's
these
three
things
right.
It's
not
very,
it's
not
extremely
useful
on
one
side.
If
you
look
into
this,
you
immediately
understand.
Oh
okay,
my
first
http
request
failed
and
the
second
succeeded.
It
was
a
retry
right.
It
is
if,
if
there
was
no
exclamation
mark,
you
wouldn't
know
that
it's
the
case,
you
can
think.
Oh,
there
are
two
http
requests
done.
Why
so,
like?
E
Maybe
the
whole
idea
of
this
look
for
all
errors
in
my
application?
It's
already.
We
don't
support
it
across
open
telemetry.
Well,
because,
like
404
is
error
and
it
shouldn't
be
probably
503.
Maybe
we
need
to
have
a
retriable
transitive
error
thing
or
something
but,
like
I,
don't
think
we're
introducing
a
new
problem
with
this.
F
F
E
B
B
B
It
will
be
just
redirect,
but
this
the
problem
is
the
same.
Do
we
want
to
see
just
logical,
logical
spam
or
we
see
want
to
see
physical,
but
we
cannot
correlate
them
or
we
need.
We
want
to
see
both
and
the
the
same
proposal
that
led
miller
shirts
actually
works
for
this
as
well.
So
this
is
the
like
a
kind
of
corner
case
when
we
have
or
like
the
case
when
we
have
logical
and
physical,
so
we
have
logical
started.
Then
we
have
http
call
for
http
get
to
this
url.
B
It
actually
responds
with
302
or
301
and
different
locations.
So
the
client
just
does
this
like
a
car?
Does
the
redirect
and,
like
I
end
up
with
with
this
server
spam,
so
I
believe
that
that's
exactly
the
same
idea
can
be
applied
here,
so
we
can
have.
B
We
can
see
if,
if
it
was
some
redirect,
then
we
can
generate
one
more
span
and
then,
like
add
links
to
these
two,
so
we
can
see
it
as
a
logical
kind
of
logical
span
that
unifies
or
actually
make
connects
these
two
together.
E
B
Actually,
the
same
problem
is
applicable
to
retries
as
well,
so
why
it
happens
like
a
what
about
the
request,
duration,
so
for
troubleshooting.
I
believe
it's
really
useful.
A
All
right,
so
thanks
for
the
demo,
I
don't
see
any
other
agenda
items,
but
just
asking
them
that
anybody
else
has
topics
they
want
to
discuss
be
before
we
close
the
call.
A
No
okay,
so
then
I
guess
the
next
action
item
will
just
then
be,
I
guess,
dennis
as
far
as
the
proposal
putting
that
down
and
you
know
just
sharing,
so
we
can
review
and
then
I
guess
have
a
great
evening
rest
of
the
evening
and
I'll
see
you
guys
in
another
meeting
this
week.