►
From YouTube: 2020-07-02 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
A
B
A
A
A
A
A
But
it's
like
it's
like
you,
have
these
Auto
detectors
for
like
GCP
and
AWS,
and
you
might
not
be
in
GCP
or
AWS
so
like
you,
may
have
to
wait
for
those
to
timeout,
so
there's
some
latency
and
like
there's
just
this
whole,
oh
yeah,
I
think
the
biggest
complications
come
around
like
how
to
deal
with
that.
Is
it
okay
for
the
app
to
block
for
a
moment,
while
it's
doing
that
and
seem
like
that
was
really
unpopular
so,
but
ideally,
you
kind
of
want
to
pass
these
into
your
tracer
provider
or
meter
provider.
B
A
A
B
A
A
A
A
There's
a
new
label
release
required
for
GA
I
think
maybe
our
repo
even
has
that
now
I
think
they
might
have
added
it
everywhere.
A
Yeah
I
think
you
were
required
to
like
write
like
a
null
for
for
the
keys
or
something
right
if
you've
failed
previously,
but
you
no
longer
are
required
to
do
this.
A
So
I
think
it's
I
think
this
is
kind
of
to
support
the
case
where
you
do
want
to
try
to
extract
multiple
types
of
context,
so
you
could
potentially
do
like
b3
and
then
trace
contacts,
and
it's
like
whichever
one.
B
The
trace
context
as
a
whole
should
be
cleared
like
this
is
distinction.
Are
you
doing
multi
propagators
or
stack
propagators?
They
referred
to
it
here,
or
are
you
just
using
a
single
little
propagator
and
actually,
in
either
case,
you
need
some
kind
of
wrapper
around
this?
It
actually
clears
context,
but
the
problem
is
if
you've
got.
B
B
A
A
A
B
It
does
open
telemetry
context
with
currents
after
it's
extracted,
so
it's
going
to
do
extract
the
context
is
whatever
and
then
it's
going
to
figure
out
whether
it
uses
a
front-end
context
or
not,
or
it's
just
going
to
use
the
extract
of
context.
So
my
understanding
here
is
that
this
will
just
like.
If
we've
got
an
old
propagator,
it's
not
going
to
clear
the
context.
It's
not
going
to
do
anything
with
context.
B
That
it
has,
unless
I'm
missing
something
and
probably
missing
something
HTTP
extract
from
end
so
for
open,
telemetry
propagation
HTTP
extract
in
so
the
second
line
in
this
method
does
that
get?
Does
that
have
some
context
parsed
into
it,
or
that
just
has
the
environment
and
it
returns
an
empty
context.
So
this
one.
A
B
So
this
this
shouldn't
leak
because
it's
the
with
current,
so
you
have
an
empty
context.
You
extract
some
context.
You
set
that'll,
be
the
current
context
with
with
current
and
then
at
the
end
of
that
block.
It's
going
to
unset
the
contour
reset
the
context
of
the
previous
context
right,
the
empty
one,
yeah.
A
B
A
A
So
yeah
I
think
that
through
if,
if
we're
file,
I'm
refine,
if,
if
you
are
seeing
some
issue,
is
that.
A
Yeah
but
I
think
this
is
really
to
kind
of
support
that
mode
where
you're
trying
to
propagate
multiple
types
of
context
or
at
least
accept
multiple
types
of
context
and
I.
Think
kind
of
current
cement
pigs
would
make
it
kind
of,
like
last
last
extraction,
wins
kind
of
saying,
like
I,
think
in
reality
you
should
only
ever
end
up
with
one
type
of
stand
context,
but
as
soon
as
you
start
propagating
like
multiple
types
of
context
like
who
knows,
yeah.
B
I
guess
like
in
a
in
our
case
we're
going
to
be
migrating
between
contexts,
propagation
formats
or
from
a
custom
one.
We
have
internally
to
w3c
each
race,
bunch
action
tricks,
Marik
things
so
temporarily,
where
temporary,
it's
probably
quite
a
long
time,
we'll
be
running
with
two
propagators
or
to
extract
those
two
injectors.
A
Yeah,
so
this
is
exactly
the
use
case
that
we
want
to
support
so
I
think
you're
in
a
good
situation
to
say,
make
sure
this
is
gonna
work
for
you
and
be
suggest
changes
if
it
doesn't,
but
oh
yeah,
I
kind
of
think
that.
A
That
without
this
change,
it
makes
that
kind
of
hard,
because
I
could
really
become
like
order
dependent
and
if,
if
you
have
like
your
old
service,
just
sending
the
old
context
and
your
new
service
is
sending
trace
context,
and
you
know
you
have
an
ordering
issue,
you
could
kind
of
like
obliterate,
your
your
older
contacts
that
successfully
extracted.
If
your
trace
context,
that's
extractor
came
later
yeah,
that's
right.
B
B
A
C
A
A
B
A
Basically,
I
realized
at
one
point
that
cigs
were
adding
environment
variables
in
a
kind
of
just
like
one-off
ad
hoc
way,
and
they
were
often
adding.
Alright
I
was
noticing
instances
where
you
kind
of
had
configuration
for
the
same
thing,
but
it
was
like
different
names
between
different
languages,
so
I
thought.
Maybe
we
should
have
a
spec
that.
A
A
A
But
some
more
kind
of
some
more
interesting
things
came
out
of
all
of
this,
and
that
is
I'm
noticing
that,
like
everybody's
Jaeger
exporter,
is
different,
for
example,
and
it's
like
not
just
in
configuration
but
also
like
in
export.
It's,
like
you
know
it's
a
toss-up
of
whether
or
not
you're
getting
your
instrumentation
library
or
standout
status
on
your
span,
for
example.
So,
like
I
think
you
know,
people
are
getting
the
key
elements
of
like
the
mapping
from
hotel
to.
A
A
Kind
of
replied
saying
that
these
are
slightly
different
concerns.
If
you
are
using
the
probability
sampler
you'll
just
pick
up
that
configuration
from
that
environment
variable
if
you're,
not,
then
you
won't,
but
if
you
do
want
to
be
able
to
to
specify
a
sampler
from
an
environment
variable,
we
can
do.
This
I
feel
that
it
becomes
a
little
bit
more
tricky
and
in
general,
I,
think
like
whenever
you
want
to.
A
So
I
was
saying
you
could
have
like
a
registry
where
you
look
these
up
and
people
would
have
to
be
able
to
register
their
custom
things.
The
other
option
would
be.
You
can
only
do
this
with
built-ins
and
I
guess.
The
other
question
was
like
what
are
some
other
things
that
are
there
other
approaches
that
would
work
so
I'm
mainly
just
open
this
for
kind
of
feedback,
and
let
people
tell
me
what
they
would
like
to
see.
B
A
A
We'll
see
if
anybody
actually
cares
enough
to
a
little
bit
more
and
then
it
was
almost
the
exact
same
thing
for
configuring
propagators
by
an
environment
variable
this
one
I
kind
of
think
people
might
want
to
do,
but
it's
kind
of
its
kind
of
the
same
exact
thing
right
this
is
it
an
extension
point.
People
can
have
more
propagators,
then,
or
they
can
add
propagators
that
don't
come
stock
with
the
SDK
yeah.
B
B
A
A
There
there
are
people
I've,
seen
this
camp,
who
is
pretty
like
protobuf
averse.
They
don't
want
a
dependency
on
protobuf
like
at
all
so
I
think
to
satisfy
this
group
of
users.
You
kind
of
need
a
you
would
need
a
package
that
was
just
JSON
or
HTTP
and
then,
if
you
want
to
do
protobuf
over
HTTP,
that
might
be
a
separate
package
and
then
G
RPC.
So
you
may
end
up
with
three
different
packages.
B
A
A
A
B
C
A
B
A
A
A
A
B
A
A
B
So,
okay,
do
you
want
to
buy
things
a
question,
or
do
you
want
to
like
the
issues
open,
there's
a
question
Anthony
resolved?
Do
we
feel
like
that
resolution
is
no
resource
initialization
and
should
support
other
things
based
on
like
the
way
we're
doing
it
in
code
and
based
on
this
otep?
Or
do
we
just
want
to
pop
the
question
to
later
master.
A
It's
a
pretty
old
question
and
I
think
I.
Think
with
all
we
know
about
resources.
Today
we
are
doing
the
right
thing.
I
think
that
could
change
I
think
we
should
revisit
it
when
otep
one-one-one
merges,
but
for
now
like
for
now
I
think
we
have
what
people
are
going
to
need
to
be
able
to
to
add
more
data
to
the
resource
like
one
way
or
another.
A
user
can
get
the
key
value
pairs
they
need
into
the
resource.
So
I
feel
like
that's
a
pretty
good
position
to
be
in
so.
A
A
B
A
B
Okay,
so
based
on
that
I
think
I'll
move.
So
this
was
the
context
extraction.
One
that
we
were
discussing
earlier
sounds
like
we're,
probably
spec
compliant
here
so
I'll
just
validate
that
and
then
close.
This
issue
this
issue,
and
then
we
have
the
instrumentation
naming
which
Eric
was
working
on
I.
C
C
Whatever
you
know,
my
view
is
I,
don't
care
at
all,
it's
all
about
what
is
where
we
can
form.
You
know,
form
consensus.
I
mean
I
care
in
that
I
want
it
to
be
reasonable,
but
I
don't
have
strong
views,
but
yeah
I
think
I
grab
the
missing
bits
from
the
you
know:
the
co
comments
and
stuff
it's
a
little
I.
Don't
love
calling
a
million
things!
Intrument
ation,
but
that's
I,
guess
what
the
spec
wants
to.
Okay.
A
Yeah
yeah
I
feel
like
instrumentation
adapter.
Just
some
of
the
phrasing
worked
out
a
little
better
and
then
I
think
sometimes
he
ended
up
with
instrumentation
instrumentations
in
the
find/replace.
So
I'll
just
go
back
and
kind
of
look
that
over
as
far
as
instrumentation
:
:
base
versus
like
face
instrumentation
I,
don't
really
care
I
just
felt
like
we
could
lose
one
instrumentation
out
of
that
whole
nightmare
of
a
name
by
was
calling
it
brace.
C
B
B
C
A
B
C
I
school
I
can
update
that
tomorrow.
I
can
get
that
up,
probably
by
the
end
of
the
week.
What
about
the
you,
guys've
opinions
I,
know
Matt.
You
would
link
to
the
spec
about
the
update
for
like
a
suggestion
to
update
some
of
the
environment
variables
on
instead
of
it
being
like
open,
telemetry,
instrumentation
Sinatra
enabled
would
be
like
oh
tell
underscore
language
or
score.
It's
not
sure.
I
had
updated
it,
but
I
can
undo
that
if
it's
unrelated
or
it
should
be
a
super
PR,
but.
A
C
C
Like
if
global
conflict
and
someone
just
wants
to
set
like
open,
telemetry,
instrumentation
disabled
across
all
their
language
level,
like
clients,
they
might
just
want
to
set
one
end
bar
across
a
bunch
of
different
languages.
You
seen
that
on
the
data
dog
side,
but
probably
not
an
issue
for
right
now,
yeah
yeah,
probably
I,
guess
I
could
come
in
yeah.
I
can
comment
on
this
backup
I
feel
strongly
about
it,
which
I
don't
I.
B
Have
to
drop
off
for
another
meeting.
I
did
have
one
comment,
though.
We
have
some
pretty
substantial
changes
that
are
breaking
changes
going
out
in
this
next
release.
We
probably
need
to
document
them
reasonably
well,
so
people
know
what's
changing.
For
example,
the
in-memory
format
the
span
ID
and
trace
ID
has
changed
and
that
will
impact
people.
Writing
exporters
may
impact
people
who
have
written
custom
propagators
and
things
like
that.