►
From YouTube: 2021-04-20 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
B
B
B
Okay,
this
is
it.
I
think
we
can
start.
Thank
you
guys
for
joining
us.
Usually
yes,
so
we
have
a
few
items
on
our
agenda
today,
so
we
can
start
with
tigran
yeah.
This
came
out.
Please.
A
Yes
sure
so
I
made
this
proposal
last
week.
It's
about
telemetry
schemas.
The
idea
is
that
the
instrumentation
will
declare
the
schema.
The
schema
of
the
telemetry
is
a
meeting.
It
will
be
part
of
our
specification.
A
It
will
evolve
together
with
our
semantic
conventions
that
the
goal
here
is
to
allow
such
a
revolution
right,
so
that,
instead
of
freezing
our
semantic
conventions,
instead
of
freezing
the
implementations
that
depend
on
the
semantic
conventions
in
the
instrumentation
have
a
mechanism
which
allows
the
conventions
to
be
changed
over
time,
if
necessary
and
the
instrumentation
to
to
use
this
change
in
instruments
and
change
the
amount
of
conventions
over
time
in
a
way
that
makes
it
possible
for
the
consumers
of
such
telemetry
also
understand
what
has
changed
and
how
to
deal
with
that.
A
That's
the
proposal
there's
no
tab.
It
affects
not
just
the
specification.
Obviously
it
affects
all
the
instrumentation.
The
initial
impact
is
going
to
be
minimal,
there's
not
much
to
content
there.
So
that's
the!
I
guess,
that's
good
news,
but
the
the
long
term
impact.
I
think
it's
significant.
A
Please
have
a
look.
I
need
eyes
on
that.
I
need
reviews
and
opinions
comments
if
you
agree
with
that
approvals
as
well.
The
link
is
there
just
take
a
look.
B
Yeah,
thank
you
so
much
for
putting
that
together
and
just
to
be
clear.
I
think
that
I
would
like
to
have
people
approve
that
if
they
are,
if
they
are
confident
that
this
approach
is
is
good
to
go,
the
details
can
be
sorted
out
later.
What
we
have
you
know
like,
I
know
that
the
details
there's
some
details
still
in
the
air,
don't
focus
on
them.
For
now.
C
One
thing
that
I
feel
would
benefit
that
work
from
someone
with
perspective
would
be
to
comment
from
the
I.
There
was
a
question
from
victor
about
avro
and
parquet,
which
are
both
systems
that
do
schema
evolution,
and
I
just
thought
it
might
be
useful
to
have
someone
who
understands
those
systems
comment,
because
I
don't.
A
Yeah,
so
I
I
try
to
reply
to
that,
but
I
agree
with
you
the
more
eyes
we
have
on
that,
and
also
people
who
do
have
the
the
experience
and
more
experience
than
I
or
anybody
else
may
be
ahead.
That
would
be
very
beneficial
to
do
more
comparisons
with
other
systems
which
handle
this
this
or
similar
problems.
I
think
we
what
we
have
is
somewhat
different
from
what
the
other
systems
sold,
but
the
analogies
are
there,
so
it
could.
D
C
I've
never
even
heard
of
that
anthony.
Would
you
like
to
tell
us
more.
D
C
Thank
you.
I
guess
I
was
a
little
familiar
with
it.
I
misunderstood
you
but
yeah
that's
another
area.
We
should
all
look
at.
B
Yeah,
I
think
that
so
I
I
think
we
have
a
few
yeah
approvals,
but
yeah
we
need
definitely
more
eyes.
So,
let's
try
to
push
people
all
right.
Anything
else
on
that
front
before
we
move
before
we
move
to
the
next
one.
A
B
Perfect,
thank
you
so
much
perfect,
okay.
So
the
next
point
is
precemec
synthetics
context,
propagation,
best
practices.
E
Yeah,
so
the
idea
is
that
I
was
looking
at
how
synthetics
and
and
context
propagation
borders
and
everything
is
being
handled
by
open
telemetry.
I
couldn't
find
anything
referring
to
that.
Essentially,
the
problem
is
that,
let's
consider
that
we
have
some
company
or
like
like
some
service,
that
is
having
some
sort
of
robot
that
makes
calls
like
synthetics,
essentially
to
some
service
by
some
other
company
to
verify.
E
What's
the
response
time
to
verify,
if
there
are
errors
and
etc,
and
maybe
we
would
like
to
leverage
tracing
so
if
this
request
comes,
then
we
would
like
to
make
sure
that
it's
being
sampled,
so
we
would
like
to
know
what
was
the
idea
of
the
request,
so
this
could
be
later
investigated
if
something
strange
happened,
things
like
that
and
now
the
problem
is
that,
since
these
are
two
organizations,
they
might
have
separate-
let's
say
collection
strategies,
so
it
cannot
be
just
like
a
simple
context:
propagation
and
things
get
tricky,
and
I
was
thinking
how
should
be
this,
let's
say
taken
further
there.
E
The
three
ideas
I
had
is
that
maybe
we
should
just
use
normal
trace
propagation,
and
the
challenge,
though,
is
that
in
the
organization
in
the
first
organization
there
is
a
root
span
generated
and
the
second
organization
doesn't
have
access
to
that
response.
So
that
would
need
to
be
somehow
sent,
or
maybe
that's
that's
fine.
The
second
idea
is
that
maybe
baggage
could
be
used
for
identifying
the
request.
However,
I'm
not
sure
if
baggage
attributes
are
being
exported
with
with
spans,
I
think
they
are
not
and
that
they
are
just
available
in
the
context.
E
And
then
I
recall,
we've
been
discussing
the
problem
of
the
border
between
organizations
when
context
propagation
is
being
considered,
and
the
the
suggestion
was
that
there
is
this
links
feature
which
is
not
actually
used
much
to
my
best
knowledge
and
open
telemetry.
That
would
probably
work
the
best,
because
two
separate
traces
can
be
linked
together
as
having
some
sort
of
relationship.
The
second
one
would
not
need
to
know
anything
about
the
first
one,
but
would
still
contain
some
information
about
it,
but
I
think
it's
not
possible
to
send
it
in
the
context
right
now.
F
Everything
I
I
I
haven't
participated
in
discussions
around
this
topic
before,
but
I'm
also
very
much
interested
in
this.
In
this
problem
space.
We
we
have
similar
relationships
with
different
parties,
continuing
traces
which
may
re-enter
back
into
our
system,
and
I
think
some
some
recommendations
around
how
we
might
want
to
trace
across
multiple
systems,
potentially
with
different
trace
collections,
would
be
greatly
appreciated.
E
Yeah
one
thing
that
could
work
here
if
we
could
somehow
send
like
have
have
some
extension
to
tracing
context
and
send
information
about
the
essentially
a
link.
So
so
then
the
receiver
would
create
a
new
trace,
but
would
include
information
that,
like
there
was
some
other
trace
that
has
some
relationship
with
the
new
one.
That
could
be
one
of
the
of
the
answers
for
that
problem,
but
yeah.
That's
that's
interesting.
One.
C
G
Yep
and
sergey
speaking
so
dino
president
at
some
point
created
this
I
don't
know
was
it,
it
was
brother,
but
I
think
it
was
one
of
the
customers
and
like
from
instagram.
They
created
a
link
back
to
dynatrace,
so
they
can
view
traces
across
different
collection
systems,
and
I
think
they
just
did
it
by
based
on
trace
id,
so
they
continued
trace
id
and
because
of
the
same
header,
it
was
possible
to
do.
G
If
you
trust
in
trace
id,
then
situation
is
very
easy,
like
I
mean
relatively
like
easier
than,
if
you
don't
so,
if
you're
keeping
trace
ideas
and
and
if
nobody's
even
using
trace
state,
then
at
least
you
have
all
the
traces
in
your
system
created,
minor
problem
can
be
if
a
sampling
was
kicked
in
and
somebody
else,
however,
wrote
your
sampling
decision,
then
you
have
a
mismatched
sampling
decision
and
maybe
you're
losing
part
of
it.
G
But
I
mean
if,
if
everybody
expects
something
id
as
well,
then
station
even
better
but
then
trace
state
can
help
you
stitch
together,
input
to
other
system
and
output
like
in
trace
going
back
to
your
system.
So
if
you,
if,
before
you're
calling
somebody
else,
you
put
your
lice
last
span
id
into
trace
state
and
it's
supposed
to
be
propagate
those
away
and
when
trace
will
come
back
to
you.
You
reach
the
last
span
id
from
this
tray
state
and
use
it
to
stitch
together
as
your
parent.
G
Little
did
it
in
azure
back
then.
F
It
might
be
worthwhile
opening
an
issue
to
track
this
and
maybe
get
more
input
from
others.
On
this
topic
I
mean
I'll
have
a
few
thoughts.
I'm
sure
any
other
people
here
would
as
well.
H
It
would
be
really
nice
if
there
was
a
standard
way
to
identify
synthetic
requests,
so
that
services
would
have
a
way
to
identify
them
and
potentially
sample
them
differently
or
provide
additional
information
or
extract
baggage.
Or
something
like
that.
So
I
think
there
would
be
definitely
some
value
in
having
some
standardization
about
what
we
recommend
for
identifying
synthetic
requests.
C
Similarly,
there's
a
there's
a
request
here
about
whether
we
should
report
baggage
in
the
span
data
and
that's
never
been
addressed,
and
I
know
there
are
tickets
or
issues
open
about
it
and
it's
something
that
users
ask
for,
but
we've
just
somehow
not
gotten
to
that
point.
H
C
Possible
explanation
that
I
might
throw
out
is
that
we've
we've
been
starting
to
recognize
different
types
of
attribute
in
a
resource
whether
they
describe
the
process
as
an
identifier
or
a
descriptor,
or
whether
they're
not
identifying,
and
I
found
an
issue
in
the
prometheus
working
group
yesterday
to
ask
what
they
think
of
an
external
label,
because
it
seems
to
be
both
of
those
things
and
baggage
definitely
falls
into
this
category
of.
Is
it
a
property
of
the
span
or
is
it
probably
the
trace
or
is
it
prop?
C
Is
it
something
else,
and
we
don't
know
whether
it
should
just
we
can't
just
throw
it
into
the
resource?
We
can't
just
throw
it
in
the
span
attribute,
because
it
somehow
exposes
this
uncertainty
that
we
have
and
I'm
hoping
that
the
tiguan's
pr
about
or
otep
about
schema
it
might
open
up
a
door
for
us
like
if
you
had
a
schema
to
tell
you
what
types
of
key
were.
C
What,
then,
you
might
say,
select
all
the
baggage
that
are
span
attributes
and
put
them
in
the
span,
but
don't
select
all
the
baggage
attributes
that
are
arbitrary
types
of
thing,
because
they
might
not
be
good
spam
attributes
because
they're
not
identifying.
Perhaps
they
might
tell
you
how
the
replication
worked
instead
of
how
the
span
is
just
a.
C
E
B
H
Yeah,
there's
a
there's
a
every
other
week:
4
p.m:
asia,
pacific
friendly
spec
meeting.
That's
supposed
to
happen
that
literally
only
anurag
and
I
ever
show
up
to
so-
we've
been
using
it
as
a
one-on-one
for
java
stuff,
but
it's
really
there
for
asia.
Asia
pac's
specification
discussion.
So
if
there
are
people
who
are
able
to
show
up
to
that
will
be
very
helpful.
B
Yeah
totally,
okay,
next
point
reverting
the
value,
the
null
value
passed
through
you
get
tracer.
This
is
an
issue
that
you
john
opened.
I
did
mention
this
yesterday
and
it's
about
considering
reverting
this
change.
B
Do
you
want
to
explain
that
the
issue
yourself,
john?
As
you
open
it.
H
Yeah,
so
there
was
at
some
point,
I
don't
remember
exactly
the
number,
a
change
to
the
spec
kind
of
very
kind
of
late,
or
maybe
it
was
after
1.0,
maybe
1.1
or
one
point
I
think
1.2.
Actually
that
made
it
so
that
the
instead
of
having
a
fallback
tracer
name,
which
ends
up
his
instrumentation
library
name,
it
was
there
was
a
pull
request
that
specified
that
you
should
not
use
a
fallback
and
you
should
pass
through
nulls
and
empty
strings,
even
though
they're
not
valid.
H
This
actually
is
which
I
tried
implementing
this
in
java
and
actually
has
a
lot
of
ripple
effects.
If
we
allow
nulls
in
java
to
go
through
that,
because
it
ends
up
affecting
every
single
and
actually
a
breaking
behavioral
change
for
every
exporter
that
now
has
to
have
to
has
to
look
and
potentially
handle
null
values
in
instrumentation
library
names.
So
unless
so,
I
think
this
is
actually
a
breaking
change,
at
least
for
java.
H
B
Yeah
ted
mentioned
something
interesting
there
that
we
started
this
having
a
canonical
name
or
that
that
was
attempt.
So
this
we
wouldn't
have
this.
The
other
interesting
point
is
that
a
lot
of
I
think
we
should
try
to
implement
things
more
before
we
merge
stuff
in
specification,
because
even
small
changes
may
break.
You
know
code
in
very
unexpected
ways.
B
B
Something
something
yeah:
something
got
lost
there
yeah
anyway.
Next
one
order
of
precedence
for
environment,
provided
attributes.
D
Yeah,
so
this
is
a
question:
that's
come
up
in
the
the
go
seek
as
we
implement
an
environment
research
detector
and
what
order
that
should
be
folded
in
to
the
user
provided
attributes
in
the
sdk
the
the
spec
says
you
know,
I
I
think
it's
fairly
clear,
that
it
says
that
the
the
environment
goes
secondary
to
user
provided,
but
I
consider
the
environment
values
to
be
user,
provided
and
user
provided
isn't
really
defined
elsewhere.
So
what
exactly
is
secondary
to?
What
I
think
is
the
the
question
here.
D
I
don't
know
if
it's
a
real
practical
issue
yet
or
not.
I
think
it's
a
user
interface
user
experience
kind
of
issue
right
as
a
user
who's
configuring
an
application.
I
would
normally
expect
that
if
I
provide
configuration
overrides
via
the
environment,
those
are
overrides
and
it
overrules
anything
that
is
set
in
the
application.
That
would
otherwise
be
hard-coded
right,
but
this
seems
to
say
it's
the
exact
opposite.
If
the
application
specifies
one
of
these
resource
attributes,
it
will
take
precedence
over
anything
I
put
in
the
environment,
and
I
can't
do
anything
to
change
that.
H
D
Right,
an
application
developer
will
have
to
specify
resource
detectors
in
an
order,
and
they
will
be
applied
in
that
order.
The
the
question
then
becomes
we're
told
to
fold
in
the
environment
values
automatically
in
trace
providers
and
meter
providers,
which
order
do
we
do
that
in
do
we
do
it
before
or
after
the
the
ones
that
were
built
up
potentially
automatically,
potentially
by
a
developer.
H
Just
I'm
just
thinking
again
from
a
practical
perspective,
the
things
that
can
be
provided
via
environment,
I
guess-
or
just
currently
in
the
specification
or
just
that,
the
big,
the
one
big
environment
variable,
which
is
the
hotel
resource,
attributes
right,
but
I
guess
that
could
potentially
override
any
of
the
auto
detected
ones,
because
you
can
put
anything
in
there
that
you
want
yeah.
That
makes
sense.
Okay,
thanks.
G
Personally,
I
would
put
down
some
use
cases
and
some
examples
of
what
user
can
configure,
what
detectors
can
detect
and
what
the
environment
variable
would
do,
and
probably
that
will
explain
better
the
behavior
that
we
want
and
will
make
us
understand
better.
What
is
the
right
order.
C
There
are
three
categories
that
we
need
to
pay
attention
to:
there's
things
that
are
hard-coded
and
have
defaults
in
the
code.
There
are
things
that
are
passing
through
the
environment
and
they're
things
that
are
more
explicit,
like
the
user
called
with
attributes,
and
I
would
give
the
users
with
attributes
the
highest
priority
and
then
I
would
give
the
the
environment
and
then
I
would
give
anything
hard-coded
in,
but
I
really
agree
that
the
resource
detector
falls
in
between
two
of
those
categories
and
I'm
not
sure
how
to
answer
this
question.
C
D
I
When
I
first
read
the
specification,
so
I
think
it
makes
sense
to
call
out
the
use
cases,
but
I
I
would
back
a
change
to
flip
this
if,
if
we
can
do
it
in
a
non-breaking
way,
in
some
fashion,
to
like
give
the
devops
person
an
ability
to
override
resource
attributes
on
the
fly
and
like
reconfigure,
the
kind
of
names
and
attributes
that
they
want,
especially
to
deal
with
like
bugs
and
things
right,
like
you're
asking
for
a
use
case,
one
of
the
use
cases
is
there's
something
we
didn't
expect
and
I
need
to
make
a
change
and
I
don't
want
to
have
to
go.
I
Ask
the
developer
to
change
the
code
right.
That's
like
to
me
always
the
holy
grail
use
case
of
something
went
wrong
anyway.
I
I
think
it's
worth
calling
this
out
and
trying
to
correct
it
in
some
fashion,
but
we
might
need
to
take
some
time
and
and
document
like
why
we
think
this
is
inverted
and
like
and
exactly
that
use
case
for
people
who
don't
who
might
not
agree,
and
then
we
can
outline
exactly
what
control
we
want
to
give
to
people
who
aren't
the
application
developer.
I
But
it
should
be
crystal
clear
when
you
read
the
spec
this
override
order.
Otherwise
everything
falls
apart.
This
is
like
as
bad
as
java
log
xml
configuration
right.
C
I
feel
like
we
can
always
leave
a
possibility
for
the
user
to
get
the
overrides
in
the
order
they
want.
If
we,
if
they
explicitly
provide
the
detectors
in
the
order
so
like
in
anthony's
example.
If
they
didn't
provide
the
environment
detector,
then
we
should
put
it
last
so
that
it
overrides,
but
if
they
did
provide
the
environment
detector
somewhere
in
the
middle
of
their
detector
list,
we
should
apply
it
in
the
order
they
gave
it
to
us.
D
Well,
so
I
I
think
that
probably
gets
to
the
second
part
of
this,
which
may
be
implicit
in
my
issue
here,
but
I
think
we
had
read.
The
sdk
must
extract
this
information
as
saying
that
the
transfer
provider
and
meter
provider
must,
if
the
user
provides
a
resource
fold
in
the
environment
variables,
and
it
must
do
it
in
some
order
right
so,
whether,
regardless,
whether
the
user
had
an
environment
resource
detector
in
their
resource
construction,
initially
or
not,
we
have
to
pull
that
in
either.
That
must
should
be
softened
or
clarified.
H
Is
there
anything
just
along
these
same
lines,
we're
talking
a
lot
about
ordering
of
resource
auto
detectors?
Is
there
anything
in
the
spec
about
sdks
actually
having
to
provide
this
facility
of
of
ordering
resource
detectors,
because
I
know
at
least
in
the
java
there's
there's
no
there's
no
way
for
the
sdk,
unless
you
do
it
yourself
very
manually
for
like
the
auto
detection
stuff
to
have
an
order
applied
to
it.
It
just
is
what
you
get
whatever
you
get.
I
We
actually
have
a
problem
with
that.
We
were
trying
to
write
our
gce
and
gke
detectors
and
sometimes
gke
is
detected
as
gce
if
gke
doesn't
run
first.
So
I
actually
think
we
need
a
well-defined
order,
especially
for
those
of
us,
providing
those
auto
detectors
to
make
sure
that
if
there
is
such
a
conflict,
where
one
can
look
like
another
thing,
but
is
more
specific
that
we
we
get
the
correct
detector
and
we
don't
have
to
bundle
all
that
code
together
anyway.
D
B
That
would
be
great
okay,
so
I
will
assign
this
item
this
issue
to
you
for
now
and
we
can
see
how
it
goes
from
here,
but
having
the
scenarios,
it's
a
good
start.