►
From YouTube: 2020-11-04 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
B
Yeah
totally
a
couple
items
here:
the
first
is
just
trying
to
as
we're
freezing
the
tracing
spec
and
moving
on
to
really
trying
to
get
users
to
try
the
project
and
get
feedback.
You
know
before
we
go
ga
I
put
together
a
sort
of
user
research
like
dog
fooding
guide.
B
So
this
is
like
a
just
a
very
basic
exercise
about
walking
through
all
of
the
basic
things
that
an
end
user
would
have
to
do
to
use
tracing
so
how
to
install
the
node
sdk,
how
to
install
some
auto
instrumentation
and
then
trying
all
of
the
basic
commands
the
end
user
would
use
like
getting
the
current
span
and
adding
attributes
and
creating
child
spans.
So
it's
just
a
simple
walkthrough
of
doing
those
steps
that
asks
for
your
feedback
along
the
way,
and
I
would
really
really
really
appreciate
it.
B
If
people
from
these
different
cigs
first
gave
it
a
try
on
their
own
work
and
if
you
do
have
time,
maybe
try
another
language
that
you
know
that's
implemented
in
open,
telemetry
like
python
or
something
like
that
and
give
it
a
try
there
so
that
we
can
start
giving
each
other
some
feedback.
B
I'm
going
to
open
this
up
to
the
the
general
public
to
come
in
and
do
it,
but
I
feel
like
we
should
maybe
do
a
round
of
dog
fooding
our
own
stuff
before
before
then
so
that
that's
my,
my
big
big
ask
is
to
please
give
this
a
try.
It
shouldn't
take
very
long
and
if
you
could
also
recruit
a
couple
other
people
to
give
it
a
try,
maybe
people
you
work
with
or
just
people.
B
You
know,
maybe
people
you
know
on
twitter,
but
it
seems
like
the
right
time
to
be
getting
this
kind
of
user
feedback.
B
If
it's
not
exactly
the
right
time,
you
can
go
into
that
doc
and
update
the
node.js
entry,
and
I
think
my
one
other
request
there
is
you
could
list
like
which
version
you'd
like
people
to
try.
If
there's
like
a
particular
minimum
version
or
something
like
that
or
you
made
a
big
change
and
you
want
people
to
try
a
later
version,
so
that's
that's
my
big
request.
A
No
questions
from
me.
I
think
I
already
signed
up
in
the
maintainers
meeting
saying
I
would
do
python
and
ruby,
which
I
am
still
planning
on
doing
for
javascript.
We
know
that
the
configuration
story
is
a
nightmare
right
now.
B
Okay,
good-
that
was
my
next
next
point,
because
that's
this,
I
I've
done
workshops
and
all
of
these
and
I've
been
trying
a
lot
of
the
ones
that
are
about
to
ga
yeah,
there's
something
about
the
way
configuration
how
configuration
works
in
js.
That
looks
like
it
would
be
awesome,
if
only
I
knew
what
that
config
object.
Looked
like
yeah.
A
Yeah
so
because
we
used
one
config
object
to
configure
all
of
the
plugins
and
we
wanted
the
plugins
to
be
dynamically
loaded.
The
typing
system
doesn't
link
anything
together.
So
it's
just
like
completely
untyped
blob
of
stuff
yeah
bart
obecny
rewrote
our
instrumentation
base
module
that
we
expect
instrumentations
to
be
written
from,
and
the
new
experience
is
that
you'll
configure
each
one
individually
rather
than
having
this
one.
B
B
A
A
So
it's
a
little
bit
more
explicit
and
then
you
know
most
of
the
time
if
you
don't
have
an
object.
It'll
just
use
default
values
so.
B
Great
yeah,
as
long
as
the
options
are,
are
documented
somewhere.
That
was
the
main
thing
I
struggled
to
find
was
like,
besides
just
the
structure
of
the
object,
just
understanding
what
what
the
options,
even
even
were
a
little
difficult.
I
was
gonna
suggest
if
you
stick
with
something
like
that,
you
can
pass
for
the
this.
Maybe
also
goes
for
the
core
sdk,
not
just
the
plugins,
but
if
it
does
end
up
being
just
like
a
big
json
object
which
I'm
not
against,
but
just
having
like
that
schema
posted
somewhere.
B
Like
here's
an
example,
you
know
config
object
just
with
every
option
listed
on
it,
so
you
can
see
the
structure
of
the
thing
that
something
like
that
would
would
have
helped
me
figure
out
how
to
configurate
it,
okay,
yeah,
so
that
that's
my
main
feedback
other
than
that
like
yeah,
it's
starting
to
feel
feel
really
awesome,
maybe
some
some
funkiness.
B
I
know
you're
struggling
with
around
the
fact
that
this,
like
asynchronous
loading
detection
of
resources,
I'm
not
sure
where
that's
come
along,
but
you
know
that
was
the
one
thing
where
I
was
like
when
I
started
the
simple
like.
Oh,
this
is
kind
of
like
against
the
grain
for
how
synchronous
requires
tend
to
work
in
in
node,
and
I
came
up
with.
B
We
came
up
with
what
looked
like
an
elegant
solution
and
you
know
I've
seen
you
know
the
way
you
put
into
a
separate
file,
but
I
don't
know
if
that's
solvable
or
not,
but.
A
C
A
A
For
the
time
being,
that's
just
the
way
it
is.
If,
if
someone
has
a
proposal
to
change
it,
I'm
I'm
happy
to,
is
it
causing
problems
for
you.
B
It's
not
causing
problems,
it's
just
again,
like
maybe
a
documentation
thing
explaining
that
that's
what's
what's
going
on!
It
took
me
a
second
to
figure
out
why
my
stuff
was
funky,
and
then
I
was
like
oh
okay.
I
have
to
like
get
this
stuff
loaded
and
then
require
the
rest
of
my
application
and
I
think
there's
some
examples
showing
that,
but
because
that's
like
slightly
different
than
what
I
think
users
might
expect
it
tends
to
be.
B
I
mean
you
all
know
this
right,
but
it
tends
to
be
like
you
want
to
load
all
of
your
load.
Everything
synchronously,
ideally
you're,
starting
a
node
app.
So
I
don't
think
I
don't
think
it
could
be
helped
if
we
wanted
to
detect
resources,
though
so
that
was
just
yeah.
A
A
B
My
opinion
honestly,
is
that
this
is
really
just
a
documentation,
documentation
thing
as
long
as
it's
like
clear
to
end
users.
This
is
how
you
bootstrap
it,
and
this
is
why
you
need
to
you
know,
do
some
asynchronous
work
and
then
call
call.
You
know
basically
then
require
the
rest
of
your
app.
Then
your
app
will
load.
In
the
same
same
way,
it
would
normally
load
only
we've
now
preloaded.
All
of
this
open,
telemetry,
stuff,
asynchronously.
A
Yeah
there
there
is
one
problem
it
does
cause,
although
maybe
in
some
ways
be
unavoidable.
The
the
gcp
resource
detector,
for
instance,
is
asynchronous
and
it
uses
the
node
fetch
module
so
that
module
is
loaded
and
resources
are
detected
and
then
tracing
is
set
up
that
fetch
module
is
then
not
instrumented.
A
So
if
you
use
the
gcp
resource
detector
before
setting
up
the
instrumentation,
the
node
fetch
module
fails
to
instrument
is
that
that
is
that,
like
gcp
code,
that's
like
code,
we
don't
own,
it
is
code,
we
don't
own
yes,
so
we
have
to
find
some
way
to
either
to
like
apply
the
instrumentation,
then
load
the
resources
and
then
enable
the
already
applied
instrumentation
on
a
new
tracer
provider.
So
like
the
load
order
is
going
is
a
known
problem.
I
guess
is
the
shortcut.
B
A
B
If
only
we
knew
people
who
worked
on
gcp
maybe
solve
this
for
us.
Okay,
let
me
see
if
I
can
actually
find
someone
who
can
deal.
A
D
I
guess,
while
we're
on
that
topic,
I
have
heard
at
least
that
this
newer
version
of
the
gcp,
the
gcp
module-
requires
maybe
node
10.,
so
it
by
by
using
like
the
sdk
package
or
by
depending
on
that
module.
You
kind
of
end
up,
not
you
know,
having
your
minimum
node
be
v10
rather
than
eight,
which
I
think
is
what
most
of
the
components.
B
Right,
that's
that's
also
good,
but
yeah
oh
see.
If
I
can
maybe
poke
some
people
at
google
and
just
like
hey,
could
you
guys
maybe
fix
this
or
give
us
an
alternate
implementation?
We
can
use
that
doesn't
haul
in
this
big
dependency
chain.
Yeah.
That's
always
going
to
be
a
problem
with
these
things
right.
A
Yeah,
it's
going
to
be
a
problem.
It
happens
to
be
a
problem
with
gcp
right
now,
but
it
could
potentially
be
a
problem
with
you
know.
Some
new
cloud
provider
starts
up
and
then
you
know
uses
something
other
than
node
fetch
like
they
use
axios.
Maybe,
and
now
that's
loaded
too
early-
and
I
I
think
we
have
to
solve
this
problem
in
a
more
general
way.
B
Yeah
I
mean
the
the
the
ideal
solution
of
not
requiring
this
stuff
isn't
just
because
of
this
instrumentation
problem,
but
the
more
stuff
we
haul
in
the
more
like
version,
conflicts
and
other
things
can
pop
up
and.
A
Yeah,
so
that
the
currents
so
that
the
instrumentation
module
that
again
the
same
one,
that
bart
wrote,
those
instrumentations
can
be
instantiated
before
the
tracer
provider.
So
they
they
instrument
the
module
and
then
they
just
call
the
global
tracer
provider
which
by
default,
is
no
up.
So
if
we
rewrite
the
node
fetch
instrumentation
in
this
new
instrumentation
package
style,
it
will
load
before
the
resource.
A
The
resource
will
call
will
load,
node
fetch,
which
will
be
instrumented
when
it's
loaded,
but
will
just
generate
no
op
spans
when
it's
called
and
then
a
tracer
provider
is
loaded
after
the
fact
like
that
that
all
works,
it's
just
that
the
instrumentation
hasn't
been
rewritten.
Yet
I
see
oh
well,
that's
good
to
hear
so
that
this
is
a
a
in
progress
fix,
but
the
true
fix
depends
on
rewriting
all
of
our
instrumentation
libraries,
which
we
have.
A
I
don't
know
more
than
I
want
to
rewrite,
but
we're
gonna
have
to
do
it.
So
at
some
point
we'll
just
have
to
bite
the
bullet.
B
A
So
auto
loading
has
issues
for
a
handful
of
different
reasons
for
one
thing:
in
javascript,
it's
really
common
to
use
things
like
webpack
and
the
yarn
plug
and
play
loader
and
things
that
depend
on
being
able
to
statically
analyze
all
dependencies
at
compile
time
or
at
process
start.
So
anyone
using
the
yarn
plug
and
play
module
system
has
issues
where
they
need
to
explicitly
white
list,
all
of
the
instrumentation
libraries
because
they're
dynamically
loaded,
and
it
complains
about
that
again
fixed
by
this
new
instrumentation
system.
A
So
what
what
we
can
have
is
a
module
that
we've
been
calling
a
meta
package
which
depends
on
all
these
other
modules
and
right
now
it
just
depends
on
them
and
they're,
auto
detected
and
loaded
in
the
future.
It
will
have
to
depend
on
them
and
re-export
them
and
then
you'll
just
have
to
like
import
default
modules
from
open,
telemetry
instrumentation
and
then
just
call
some
generic
enable
method
which
will
enable
all
the
default
ones
that
way
the
dependencies
are
all
statically
analyzable.
A
B
I
just
don't
know
how
quickly
I
can
find
it
and
I
don't
want
to
spend
10
minutes
doing
it
right
now.
That's
totally
fine!
I
just
you
know
I'm
putting
together.
You
know
docs
and
workshops
and
trying
to
about
like
how
to
get
started.
Knowing
some
other
things,
and
I
just
want
to
make
sure
I
don't
throw
something
out
there.
That's
like
about
to
you
know,
go
out
with
wash
so
I'm
happy
to
to
watch.
A
The
other
thing
related
to
that
is
our
getting
started
guide,
which
was
written
before
our
sdk
module
was
written.
So
we
we
now
have
a
single
module
that
you
just
install
open,
telemetry,
sdk
node
that
sets
everything
up
for
you
and
the
getting
started
guide
does
not
have
any
references
to
it
at
all.
So
the
getting
started
that
that's
how
we
are
hoping
users
will
actually
get
started,
so
the
guide
needs
to
be
rewritten.
B
Okay,
that's
super
helpful
and
I'm
glad
to
see
that
that
stuff
is
all
on
the
table.
Okay
and
yeah.
Just
to
reiterate
my
first
ask
maybe
as
part
of
doing
this
when
that
gets
out.
B
Maybe
it's
like
this
next
version
of
node
that
we
want
to
go
through
this,
maybe
user
research
on,
but
maybe
yeah
once
that
version's
out,
if
people
could
could
try
a
walkthrough
and
just
just
confirm
the
how
the
feels
of
using
it,
but
it
sounds
like
y'all,
actually
have
that
stuff,
pretty
well
loaded
in
your
head.
So
I
appreciate
that.
A
A
A
C
But
but
the
the
fact
that
we
need
to
rewrite,
like
maybe
10
plugins,
seems
really
long
for
the
ga.
So
I'm
not
really
sure.
What's
what's
the
play
here.
B
A
C
A
Maybe
we
should
create
a
project
in
the
contrib
repo
and
create
an
issue
for
each
one
or
something
like
that.
Yeah.
C
Yeah
yeah
sure,
and
we
should
start
with
the
with
the
car
plugins
because
they
are
the
biggest.
I
think
right
now.
A
And
then
I'll
create
a
project
and
put
all
of
those
issues
into
one
project
so
that
we
can
just
start.
You
know
start
tackling
them,
but
I
I
agree
we
should
do
the
core
ones.
First,.
C
A
C
Yeah
and
I'm
not
sure
do
we
need
to
rewrite
the
test
too.
The
test
should
be
fine
like
like
they
are
not
right.
Now.
C
Yeah
I
mean
just
let
the
loading
the
the
fact
that
we
need
to
load
the
plugin,
but.
A
Yeah,
okay,
that
makes
sense,
and
then
once
we
have
in
in
this
new
instrumentation
style,
we
should
be
able
to
do
multiple
instrumentations
per
package.
So
we
may
want
to
wrap
http
and
https
into
the
into
one
instrumentation
or
into
one
package.
A
Yes,
yeah,
but
we,
I
think
we
should
be
able
to
have
a
single
instrumentation
that
does
both
with
the
new
with
the
new
system.
C
So
I'm
not
sure
if
it's
really
helpful
to
have
one
plugin,
because
there
is
the
quick,
the
http
free
implementation
that
should
come
out
and
not
do
we
want
to
to
implement
it
in
the
same
plugin
as
http,
2
and
http1.
Or
do
you
do
we
make
every
time
multiple
plugins.
A
A
I'll
create
issues
today
so
that
when
you
start
working
you
can
assign
yourself
the
issue
just
so
that
people,
don't
you
know
two
people
working
on
the
same
instrumentation
or
something
like
that
would
be
a
problem,
yeah
sure,
okay,
everything
else
pretty
self-explanatory
for
this
one,
we're
waiting
on
a
minor
refactor
from
review
comments.
A
No,
that
was
this
one,
I'm
sorry
this
one
jt
malinowski
said
that
the
pr
should
be
available
this
week,
maybe
even
tomorrow
and
yeah
everything's,
pretty
pretty
self-explanatory
here.
Just
please
review
the
ones
that
need
reviewing.
A
C
C
And
I
did
the
last
one:
it's
mostly
just
the
issues
about
the
possible
context
leak
that
we
have.
We.
We
mainly
need
more
information
about
about
the
the
the
setup
of
the
user
that
opened
the
issues,
but
I'm
just
I
just
wanted
to
say
that
I
got
the
issues.
I
got
some
issues
with
my
one
of
my
applications.
C
A
Okay
for
that
user-
I
I
want
like
I.
I
want
more
information
like
a
minimal
example.
Yeah
great,
but
so
you
said
you
have
an
application
that
is
exhibiting
some
context.
Leak.
C
Yeah
yeah
is
it,
but
it's
not
it's
not
really
all
the
time,
it's
on
specific
trace
and
I'm
not
sure
if
it's
that
application,
or
maybe
it's
our
application,
that
does
the
entry
point
but
mostly
like
to
put
it
simply,
it's
mostly
a
getaway
and
we
saw
some
spun
getting
linked
to
one
trace.
But
it's
not
it's
not
looking
to
the
right
race,
I
mean,
like
the
user
said,
but
it's
mostly
like
I
don't
know
it's
not
really
linked
to
how
much
request
I'm
sending
to
it.
C
I'm
not
sure
if
it's
maybe
the
backend
that
I'm
using
I'm
using
a
stack
driver,
I'm
not
sure
if
it's
stacked
there,
the
problem,
maybe
or
some
something
in
between
so
I
might.
I
might
debug
my
application
in
the
in
the
future
and
see
if
it's
really
a
problem
with
the
asico's
contact
manager
or
not.
A
Yeah,
I
would
say
like
if,
if
you
think
it
might
be
the
back
end,
you
can
always
you
know,
add
an
add,
an
exporter
and
just
export
to
jager
or
something
yeah
temporarily,
and
then
I
would
also
try
like
disable
all
of
the
plugins
and
re-enable
them
one
by
one
and
see
you
know
it
depends
how
how
easy.
C
A
C
A
A
Seems
like
no:
if
that's
it,
then
I
guess
give
everybody
half
an
hour
back
and
I'll
talk
to
you
guys
next
week.