►
From YouTube: 2021-04-08 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
Thanks
regan,
I'm
still
waiting
for
the
thing
you
promised
me.
B
So
we
have
someone
new
here
today.
I
believe
ali
madskin.
C
Yeah,
what's
up
man,
you
wanna
like
not
to
put
you
on
the
spot.
You
wanna
just
like
introduce
yourself
to
the
rest
of
the
group,
a
deer.
D
C
So
alex
isn't
gonna
be
here
today,
so
I
guess
we
could
just
like
get
started.
C
All
right
so
a
lot
of
pr's
on
the
agenda
today,
let's
start
with
this
topic.
Oh
wait:
did
you
put
this
on
it's
dependency,
pinning.
A
Oh
yeah,
so
so
let
me
quickly
go
over
it.
So,
right
now,
whenever
we
release
something.
So
let's
say
the
next
release
is
going
to
be
1.1
bump
all
the
packages
to
1.1,
and
then
we
pin
dependencies
to
the
same
version
so
for
the
next
release.
Sdk
1.1
will
depend
on
api
one
by
one
and
for
example,
distro
will
1.1
depend
on
sdk
and
api
1.1,
so
this
works,
but
this
creates
a
bit
of
inflexibility
for
users.
So
now
considering
we
are
past
1.0
and
things
shouldn't
break.
A
I
think
we
should
keep
the
version
range
as
flexible
as
possible,
so
sdk
1.1
should
still
have
dependency
on
api
1.0
and
above
and
anything
less
than
2.0
until
until
at
some
point
in
time,
when
sdk-
let's
say
1.5,
depends
on
some
feature
in
api
1.5.
At
that
point,
sdk
can
have
minimum
version
of
opi
1.5.
A
C
Yeah,
this
makes
sense
to
me.
We
just
didn't
really
address
this
after
our
1.0
release,.
C
We're
considered
stable
this
totally
makes
sense,
as
you
can
see
here
like
you
outlined
here,
it
does
create
a
bit
of
an
overhead
for
maintainers
yeah
alex,
and
I
are
trying
to
figure
out
like
a
better
way
to
polish
up
our
release
process
so
but
yeah
this.
This
makes
sense
to
me
so
yeah.
A
A
C
Right,
that's
true,
I
think
I
think,
for
every
release.
We
still
kind
of
need
to
manually
go
through
and
see
which
instrumentations
have
changed.
C
So
like,
if
we
we'll
see
yeah
we'll
see
if
this
is
like
a
lot,
that
is
a
good
suggestion.
We
might
want
to
enforce
that
or
be
mindful
of
it
whenever
people
make
new
prs,
but
I'll
have
to
still
go
through
the
used
case
of
what
it
actually
means
if
we're
released
so,
but
for
this
issue,
yeah
like
we,
we
agree
that
this
this
needs
to
be
done.
So
does
anybody.
B
Sure
no
yeah
this
this
definitely
seems
like
it
makes
sense.
Something
else
about
pin
independence
is
that
I
think
we
should
consider
is
the
fact
that,
so
far,
when
we
are
testing,
we
don't
have
fully
defined
virtual
environment
right,
I
mean,
if
some,
if
something
is
updated
and
breaks
in
one
of
the
dependencies
that
we
have
for
testing.
For
example,
in
python,
our
ci
crashes
right.
B
In
that
way,
we
will
make
sure
that
we
are
always
testing
with
something
that
we
know
some
fixed
virtual
environment.
Now.
That
means
that
every
time
that
there
are
updates
in
the
testing
dependencies,
we
should
update
them
by
hand,
but
maybe
there's
a
way
to
automate
that
task
as
well.
Anyway.
Just
something
to
consider.
A
Used
that
before
so,
I
think
that
makes
sense,
especially
for
for
regular
apps,
but
for
for
a
library
like
ours.
I
think
there's
a
bit
of
a
risk
like,
for
example,
recently
ci
drove,
because
a
dependency
of
data
dog
exposure
had
a
breaking
change
and
because
of
that
ci
was
broken.
If
we
had
been
the
dependency
using
pip
freeze,
we
would
never
have
detected
the
breakage,
but
then
we
would
have
released
a
package
that
would
break
it
breaking
news
as
environments,
so
using
the
library
was
that
sorry,
which
library
was
that
sorry?
A
B
We
should
always
use
a
fixed
virtual
environment
so
that
our
testing
results
are
reproducible
and
we
don't
get
like
sudden
crashes,
but
that
those
dependencies
for
the
testing,
peripheral
environment
would
have
nothing
to
do
with
the
oasis
that
the
users
use
for
installation.
A
B
No,
no,
no,
it
has
nothing
to
do.
It
just
reminded
me
that
you
should
talk
about
sorry
for
introducing
something
that
is
not
complete.
C
Yeah
no
worries,
I
think
that
makes
sense
too
do
we
do
we
have
an
issue
for
that
earth.
F
C
All
right,
then,
moving
right
along.
C
Know
the
topics
then
we'll
just
go
right
into
issues
and
prs.
Then.
C
Cool,
I
don't
know
who
added
this.
C
Looks
like
this
person
is
not
in
the
call
right
now,
but
looks
like
away.
You
commented
on
some
of
this.
Did
you
add
this
issue
or
what
to
the
agenda.
C
Right,
you
can
explain
it.
A
A
Yeah
pretty
pretty
much
the
same
format,
but
it
would
require
it
would
be
slightly
different
because
the
detectors
found
would
be
needed
to
be
plumbed
through
to
the
to
a
different
to
the
configurator
so
that
it
because
if
they
need
to
be
instantiated
and
then
the
instances
need
to
be
put
provided
to
the
provider,
I
think
so
yeah.
So
we
need
a
function
that
very
similar
to
what
we
have
now
to
detect
all
the
all
the
instances.
A
Sorry
all
the
implementations
and
then
just
send
those
references
to
the
configurator,
so
so
yeah,
but
more
or
less
the
same
yeah
makes.
D
C
All
right,
so
I
added
this.
This
issue
makes
sense
to
me
pretty
much.
C
I
believe
we
have
the-
I
think
away,
has
a
kind
of
pro
for
this
too,
but
the
instrumentations
themselves
have
dependencies
on
the
libraries
of
the
instrument
and
I
think
they
pin
those
versions
to
something.
C
When
we
upgrade
the
or
run
open,
telemetry
bootstrap,
it
also
upgrades
the
underlying
libraries,
so
those
issues
make
sense
to
me.
I
was
just
kind
of
curious
about
surcon's
comment.
C
I
wasn't
too
sure
what
you
were
trying
to
point
out
here.
If
you
can
kind
of
explain
what
the
problem
is
for
this.
E
So
if
I,
if
I
use
these
dependencies
in
some
txt
file
and
then
try
to
do
the
pinstar,
it
fails.
But
if
I
like,
as
I
mentioned
here,
if
I
install
like
like
first
the
instrumentation
library
and
then
the
library,
then
it
gives
it.
But
if
I
install
the
library
first
and
then
the
instrumentation.
B
E
Uninstalls,
the
library
and
then
updates
it
yeah
that,
like
this,
was
more
like.
Why,
like?
Why
is
doing
that.
C
E
Yes,
so
alex
alex
has
like
pointed
out
right,
so
I
try
to
do
the
same
with
the
you
know,
the
like
the
requirements
file.
If
you
it
didn't,
you
know
update
it
it
directly
through
an
error.
So
right
so
I
was.
I
was
confused
like
why.
Why
did
that.
C
E
I,
instead
of
you,
know
installing
like
this:
if
I
have
the
requirements
file,
it
would
throw
an
error.
It
would.
You
know.
C
Cool
yeah
that
makes
sense
to
me,
can
you
can
you
kind
of
like
comment
on
that
to
explain
the
context
of
that,
because,
just
by
looking
at
what
you
posted,
I
can't
really
connect
it
with
the
original
issue.
E
B
A
Yeah,
we
don't
have
to
get
rid
of
it,
but
if
the
so
there's
a
poc
pr
linked,
that's
one
of
the
possible
solutions.
So
if
we
go
with
that,
then
bootstrap
will
not
be
required
anymore,
but
people
can
still
use
it.
If
they
want
we
can
we
can.
We
can
discuss
that.
I
think
that's
a
separate
topic
if
you
want
to
remove
it
or
not,
so
we
yeah
once
we
have
this
bootstrap
wouldn't
be
a
required
piece
in
the
workflow,
but
maybe
nice
to
have
for
some
some
workflows.
A
C
C
C
All
right,
so
I
had
this.
This
is
an
issue
from
a
long
time
ago.
C
I
think
your
suggestion,
I
guess,
to
refresh
your
memory
of
we
want
to
in
all
of
our
instrumentations.
We
have
this
kind
of
like
usage
section,
which
you
know
pretty
much
only
handles
like
how
to
collect
stuff
without
an
sdk
which
pretty
much
kind
of
just
does
nothing
really.
It
only
applies
for
certain,
like
library,
users,
laser
console's,
trying
to
update
these
examples
to
include
like
the
actual,
concrete,
full-fledged
examples.
C
I
think
the
reason
why
we
didn't
want
to
do
this
before
was
because
this
would
require
people
to
install
the
sdk
which
isn't
a
requirement
to
use
the
instrumentations
themselves,
so,
which
is
why
we
left
them
out
of
the
usage
docs.
C
I
think
she
caught
it
up
a
good
point.
It's
like
this
does
kind
of
cause,
confusion
and
like
why
have
a
usage
stock
if
people,
if
the
the
normal
use
case,
people
can't
even
do
anything
with
it,
so
I
think
the
suggestion
was
to
remove
the
usage
docs
and
just
link
to
the
folder,
in
which
we
have
all
of
the
examples
that
people
will
refer
to
when
they
want
to
try
to
instrument
properly.
C
Yeah,
it's
our
examples.
Folder,
so
we'll
probably
have
a
folder
for
if
people
want
like
for
every
kind
of
instrumentation
type
that
you
can
kind
of
do
and
then
we'll
just
like
link
it
to
their
circumstances,
kind
of
the
understanding
that
we
had
last
time,
I
haven't.
E
So
the
usage
examples
it
doesn't
give
anything
as
an
end
user.
I
would
expect
it
to
you
know,
give
me
something
so
yeah.
So,
if
like,
if
you
do
not
want
to
keep
the
sdk
like
on
the
code
to
be
in
instrumentation,
we
can
put
keep
all
them
in
examples,
folder
and
then
just
hyperlink
them
to
the
main
repo
yeah.
C
I
think
also
it'd
be
also
good
to
just
like,
so
we
don't
have
to
kind
of
like
have
this
discrepancy
of
our
usage
docs
between
all
of
our
instrumentations,
like
execution-wise
like,
for
example,
if
you
only
change
the
aoipg
instrumentation
like
this,
one
will
be
missing
usage
docs,
but
have
a
link,
but
all
the
other
ones
will
look
differently
right.
So
I
guess
I'll,
like.
C
C
Yeah
otherwise,
like
people
would
be
completely
lost,
so
I
think
that'd
be
good.
So
do
you?
Do
you
still
want
to
work
on
this
pr?
This
draft.
C
E
C
Cool
next
up
a
bunch
of
stuff
by
the
way.
C
Nice
yeah
wait
when
you
want
to
talk
about
this.
A
E
A
A
I
need
to
add
so
the
real
use
cases
I
need
to
add
a
couple
of
books
like
request
hooks
or
response
hooks
to
all
the
web
frameworks
to
customize
something
for
my
distro,
but
there's
no
way
right
now
to
do
that
so
only
way
I
can
do
that
right
now
is
to
implement
a
custom
command
instrument
command
and
then
like
overwrite,
it
open
elementary
instrument
with
it,
so
that
that
involves
copying
the
whole
thing
and
it
doesn't
make
sense.
So
this
thing
it
extends
the
instrument
command
a
bit.
A
It
also
extends
distro
interface
and
then
allows
me
to
write
a
simple
function
like
override
a
method
on
the
distro,
a
distro
class
to
customize
the
initialization
of
instrumentations.
So
if
you
look
at
the
code,
so
I
added
one
more
entry
point
initially
but
alex
suggested.
Maybe
we
can
have
a
method
on
distro
and
that
made
a
lot
of
sense
to
me.
So
I
added
that
so
so
now
we
yeah
here
when
we
load
the
distro,
we
don't
immediately
run
it
call
configure
on
it.
A
We
return
it
back
and
if
we
don't
find
anything,
we
return
a
default
distro
and
then
in
could
you
scroll
down
yeah
here
so
here
we
get
the
distro
back.
We
call
configure
on
it
here
instead
of
inside
load
distros
and
then
the
only
other
changes
we
provide
this,
for
instance,
to
load,
instrumenters
and
then
load
instrument
is
called
instead
of
calling
instrumented
instrumenter.instrument.
B
Actually,
actually,
I
was
just
taking
a
look
at
this
this
morning
and
I
haven't
yet
had
the
time
to
read.
A
Contributions
yeah,
so
these
are
pretty
straightforward.
I
don't
think
we
need
to
really
discuss
them.
C
Cool
yeah
we'll
take
a
look
at
them
when
we
have
the
time.
So
this
is
similar.
A
C
A
It's
pretty
similar
this.
A
Is
is
3.95,
I
think.
A
Yeah,
so
this
is
so.
This
is
basically
the
use
case
where
I
need
request
response,
headers,
sorry,
books,
so
splunk
is
working
on
a
drama
product.
I
don't
know
if
I'm
supposed
to
share
that,
but
so
basically
we
need
to.
We
need
our
web
customers
web
services
to
respond
with
a
trace
response
header,
which
basically
contains
the
wct
trace
context,
and
this.
A
Of
the
hotel
spec,
but
it
will
be
at
some
point:
there
is
a
wtgc
spec
out
there
that
has
not
been
accepted
yet,
but
it's
in
the
in
the
process.
So
this
feature
basically
implements
what
this
spec
describes
right
here:
yeah
the
trace
response
yeah.
So
the
idea
is
we
just
like
we
send
the
tracing
context
to
outgoing
requests.
This
is
the
reverse
of
it.
It
sends
a
tracing
context
in
a
response.
So
the
use
case
is
something
like
you
open
a
website.
That's
service
site
rendered.
A
A
So
that's
the
use
case.
So
so
this
is
the
pr.
If
we
think
this
can
be
useful
for
people
or
for
other
vendors.
We
can
merge
it.
If
not,
it's
not
a
huge
deal,
because
I
can
use
the
request
responses
to
implement
this
in
my
gesture,
but
be
still
nice
to
have
this
so
yeah.
The
information.
E
A
C
C
Yeah
yeah
exactly
seems
like
a
cool
feature,
I'm
just
not
sure
whether
or
not
like
the
whole
supportability
and
the
consistency
across
all
instrumentations
thing.
A
F
Okay,
I
have
a
quick
comment,
seeing
as
like
most
of
the
people
in
the
w3c
trace,
trace
parent,
like
trace
context
committee
or
whatever
are
involved
in
open
telemetry
like
do
you
see
this
probably
making
its
way
into
the
propagator
spec
in
in
our
open
telemetry
spec
yeah.
A
F
A
A
A
F
A
F
Yeah,
I'm
just
wondering
if,
if
we
could
implement
it
with
like
the
existing
propagator
interface,
so
that
would
be
easy
to
swap
out
in
the
future
and
like
we'd
have
our
own
like
back
propagator,
that's
not
stable,
but
that
could
be
used
like
as
a
maybe
like
a
contrib
propagator
or
something
like
that
and
then
eventually
make
its
way
into
the
the
other
repo
and
then
like.
I
understand
what
you're
saying
is:
there's
no
way
to
have
it
global
right
now,
but
like
we
can
instantiate
one
or
something
I
don't
know.
C
Aaron,
what
you
said
was
actually
a
good
point.
Can
you
like
kind
of
summarize
what
you
set
here?
I
think
that's
also
a
path
that
we
might
want
to
explore
too
so
yeah.
F
C
A
So
this
one
isn't
ready
for
review
just
it
was
just
one
idea
of
how
we
could
implement
this.
So
this
comes
back
to
the
earlier
issue,
dependency
issue.
We
saw
and
diego's
comment
about
removing
the
bootstrap
command
and
I
think
I
think,
in
the
last
meeting
we
had
discussed
the
problem
where
we
wanted
to
where
the
proposal
was
to
remove
direct
dependencies
from
instrumentations.
A
So
the
request
instrumentation
doesn't
specify
request
library
as
a
dependency,
at
least
as
an
install
time
dependent.
So
this
is
a
possible
solution
for
that.
Could
you
could
you
open
the
the
link
in
the
description.
A
A
So
this
means
it
will
never
complain
whether
if
falcon
is
not
installed
or
a
compatible
version
is
installed,
if
we'll
just
ignore
it
and
just
silently
install
the
instrumentation.
So
that
means
if
the
instrumentation
is
part
of
a
larger
bundle,
everything
will
get
installed
and
it
will
never
complain
now.
The
the
problem
is
when
the
instrumentation
is
applied.
A
It
needs
to
one
not
crash
on
import
errors
and
do
it
needs
to
be
able
to
figure
out
if
the
library
it's
instrumenting
is
compatible
or
not
so
to
fix
that
we
want
the
instrument
command
it
now
uses.
The
package
require
hooks
to
figure
out
the
package
number
listed
in
target
dependencies
and
if,
if
the
package
is
incompatible
like
if
it,
if
it
sees
this
instrumentation
requires
requests,
2.0
and
3.0
installed,
then
it'll
log,
your
warning
and
skip
it'll,
not
instrument
it.
A
C
Is
that
encapsulated
here?
Sorry,
I
guess,
like
my
generic
thought
from
like
the
beginning,
it's
like,
if
we
don't
install
these
underlying
libraries
right
then
like
when
we're
trying
to
patch
certain
things
like
those
methods
or
import.
Libraries
won't
exist
right.
C
D
A
So
yeah
yeah,
so
I'll
quickly
go
over
it
so
right
now
there
are
two
ways
to
apply
the
instrumentations
one
is
with
the
open,
telemetry
instrument
command,
which
then
dynamically
discovers
instrumentations
and
loops
over
them
and
applies
every
single
one.
So
so
here
we
have
a
solution
for
that.
So
when
we
yeah
right
there
so
now
could
you
scroll
up?
Please
do
the
instrument
come
on
right
right
here,
so
yeah.
A
So
here
we
earlier,
we
were
just
blindly
loading
entry,
point,
dot,
load,
load,
the
instrumenter
and
just
call
instrument
command,
because
we
are
guaranteed
by
pip
that
there
will
be
no
dependency
complex.
But
now,
since
we
don't
have
that
we
get
the
entry
point,
then
we
cross
it
through.
This
get
target
dependency,
conflicts
function
and
this
basically
checks.
A
A
A
C
I
guess
what
I
was
more
referring
to
is
like
when
I'm
writing
a
new
instrumentation
or
something
right
and
like
I
don't
make
the
underlying
library
as
a
dependency
when
I'm
doing
like
the
actual
patching
and
stuff
right,
like
the
classes,
won't
exist
right.
F
A
C
A
Yeah
but
yeah
it's
solving
that,
but
it
also
solves
if
you
do
it
manually
so
but
in
manual
case
it's
in
manual
case,
it
only
checks
for
version
conflicts
not
for
install
conflicts.
So
in
manual
case,
if
request
is
not
installed,
but
you
import
the
request
instrumenter,
it
will
result
in
an
import
error,
but
I
think
that's
accessible,
because
people
who
are
manually
instrumenting
requests,
it's
like
why
wouldn't
they
have
requests
installed
in
the
first
place.
C
Right
so
yeah,
so
maybe
I
just
understood
what
the
because
originally
I
thought
we
were
just
removing
the
library
from
the
instrumentation
right.
A
That
so
yeah,
so
this
is
like
it's
kind
of
like
optional
dependencies.
A
If
you
do
something
like
pip
install
open
telemetry,
it
installs
up
an
elementary
api,
but
then
you
can
also
say
pip
install
and
then
tell
me
brackets
say
sdk,
for
example,
so
it'll
install
the
sdk
extra
requires
dependency.
I
don't
know
if
that
makes
sense.
So
it's
it's.
Let's
say
you
have
a.
A
Driver,
for
example,
an
orm
okay,
so
the
orm
works
with
postgres
mysql
sqlite,
and
if
you
install
the
orm,
you
don't
want
to
pull
in
every
single
driver
right.
You
just
want
to
pull
in
the
orm
the
driver
for
your
database.
So
in
that
case
you
install
pip,
install
myo
and
in
square
brackets.
You
mentioned
the
extra
what
what
we
have
called
extra
dependencies.
So
if
you're
using
postgres,
you
would
say,
we've
installed
my
orm
and
then
square
back
expose
this.
So
it
will
selectively
pull
in
these
optional
dependent
dependencies
only
for
posters.
C
A
A
I
think
that
would
be
the
case,
but
if
it
is,
we
would
document
that
you
can
install
that
with
the
target
to
also
pull
the
library,
but
I
think.
F
A
It's
probably
gonna
happen:
yeah
yeah,
it's
because
people
usually
have
like
if
they
they
implement
something
with
flask,
and
then
they
install
the
flask
instrumentation.
C
Awesome
all
right,
I
guess
that
was
pretty
much
all
over.
We
have
a
lot
of
prs
this
week.
Anyone
else
want
to
bring
up
anything
before
we
just
call
it
early
meeting
today
just
go
ahead
and
just
tackle
these
reviews.
C
All
right
cool!
Well,
if
that's
the
case,
then
I
we'll
see
you
guys
next.