►
From YouTube: 2021-04-15 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
Oh
wait:
I
got
a
bunch
of
github
notifications
from
you.
This
morning
sounds
like
you
were
busy
at
some
point
in
the
in
the
middle
of
the
night.
B
I
need
to
oh
wait.
You
you're
really
busy
on
other
hotel
room
things
right.
C
Yeah
I've
been
maintaining
the
splunk
distribution
for
js,
but,
but
so
far
haven't
haven't,
contributed
a
lot
to
the
upstream.
C
D
A
E
A
All
right,
this
one
might
as
well
get
started
laden
said
he
might
be
late
today.
So
let
me
just
make
sure
I'm
just
creating.
We
can
start
going
through
the
items,
so
I
guess
there's
only
one
topic
unless
other
people
have
anything
else
to
talk
about
that,
I
wanted
to
bring
up,
which
was
that
we're
going
to
do
a
release
on
monday.
A
A
I
think
I
think
at
some
point
we
should
probably
have
a
discussion
of
what
the
exact
expectations
of
our
release
cycle
should
be
because
I
feel,
like
we've,
been
kind
of
doing
it
on
an
as
needed
basis,
but
I'd
really
like
to
get
into
a
regular
like
every
two
weeks
or
something
we
make
a
release
or
whatever.
B
Yeah,
that
would
be
awesome,
quick
question
just
since
we
like
discussed
this
so
much
before,
but
I
see
it's
a
minor
minor
release.
What
were
the
pr's
in
there?
I'm
just
curious
like
that,
make
it
minor.
Are
we
just
gonna
do
minor
or
was
there
something
specific.
A
G
A
Not
not
specifically,
but
kind
of
as
a
best
practice.
I
I
feel
like
if
the
code
is
not
in
by
month,
like
the
code
is
not
in
by
monday,
we're
not
gonna
wait
for
prs
on
monday.
A
A
B
I
mean
I
know
we
talked
this
to
death
already.
I
was
just
gonna
like
I
guess.
If
we,
if
we
say
patch
mainly
for
like
I
don't
know
like,
I
was
just
gonna-
not
use
it
at
all
because,
like
one
one
common
thing
is
like
security
fixes,
I've
noticed
like
projects
that
have
a
lot
of
minor
versions.
They
almost
never
backboard
any
fixes
because
it's
like
just
a
huge
disaster,
so
I
mean,
if
we're
not
planning
to
do
that,
I
suppose
it's
okay.
B
A
A
A
All
right,
I
guess
we
can
talk
about
some
of
the
other
issues.
A
Here,
nope
all
right:
oh,
do
you
want
to
talk
about
these
two
issues
here.
C
Yeah,
so
we
have
had
a
few
use
cases
where
people
use
whiskey,
instrumentation
and
then
also
use
flask
or
django
or
any
other
framework
and
the
frameworks.
Currently
they
extract
the
remote
spam
contacts
from
the
incoming
request
and
create
a
server
span
so,
depending
on
whether
the
client
had
started
a
trace
or
not,
the
trace
ends
up.
So
we
either
end
up
with
two
traces,
one
that
whiskey
starts
and
one
that
django
slots
or
we
end
up
with
a
single
trace
where
whiskey
and
django
are
siblings,
instead
of
django
being
a
child
of
whiskey,
spanish.
C
C
So
this
would
solve
the
problem
as
a
so
I
looked
at
java
and
I
looked
at
node,
so
they
they
do
something
like
this,
but
they
go
even
a
step
further.
They
so,
for
example,
express
instrument.
Instrumentation
doesn't
even
generate
its
own
span.
It
just
grabs
the
parent
http
span
generated
by
http
instrumentation,
and
it
adds
its
own
information
to
the
parent
span
like
the
route
name
or
additional
attributes.
C
C
We
cannot
guarantee
that
django
will
be
used
with
whiskey,
always
at
least
in
in
development
with
run
server.
It
won't
be
so
so
we
can't
100
rely
on
the
fact
that
bearing
spend
will
be
available,
but
so
we
can
have
conditional
check
if
it's
a
we'll
be
using.
If
it's
not,
we
extract
from
the
incoming
headers
so
that
that
was
the
proposal.
C
I
think
silicon
raised
a
concern
that
it
would
there
be
any
possible
cases
where
a
non-server
span
span
not
related
to
the
incoming
request
would
be
active
in
the
context
think
it
is
when
very
rare
cases
possible,
but
I
would
say
in
that
case
it
should
be
considered
an
error
on
the
part
of
the
code
that
generated
the
span
and
set
it
in
the
context
of
a
flask
or
django
request
response
cycle.
C
C
A
I
mean
my
initial
thoughts
are
that
this
seems
to
make
sense,
and
I
yeah
I
I
agree
with
you
that
it
indicates
that
something
else
has
created
a
sp
appearance
band
that
isn't
the
server
or
that
is
that
is
the
server
spend.
That's
currently
in
the
context,
and
I
guess
like
there's.
No,
I
feel
like
this,
probably
as
far
as
we
need
to
go
to
try
and
guard
against
the
wrong
parents
fan
being
used
here.
A
Yeah,
I
I
don't,
I
don't
feel
super
strongly
here.
I
don't
know
if
sherkanth
or
someone
else
on
the
call
has
a
stronger
opinion,
but
I
could
go
either
ways.
E
I
I
don't
have
any
strong
opinions
either.
I
was
just
thinking
about
the
cases
where.
E
False
positive
cases
where
you
know
we
the
trace,
is
corrupted
kind
of,
for
example,
if
I
have
some
paper
where
I
want,
the
jungle
dress
to
be
a
jungle
to
to
extract
the
remote
contacts,
and
then
there
is
another
like
the
two.
I
have
two
branches
where
I
want
jungkook
to
extract
the
context
from
remote
context
and
and
then
there
is
another.
E
C
Loud
yeah,
I
think
that's
that's
probably
very
unlikely.
Maybe
one
use
case
is,
if
maybe
someone
wants
to
trace
the
entire
lifetime
of
the
process
and
start
to
spam
when
the
process
starts
and
then
ends
it
before
exit.
But
I
would
say
in
that
case
they
shouldn't
activate
it
in
the
context.
They
should
just
generate
the
span
and
just
end
it.
B
Another
use
case
I
may
have
heard
of
I
don't.
I
don't
know
if,
where
I
heard
this
but
like
using
a
like
a
profiler
with
context
to
send
like
a
lot
of
traces
to
a
system
or
to
a
profiler.
So
I
mean
I
don't
know
if
you
would
want
to
implement
that
with
the
span
context
or
if
you
would
want
to
create
like
a
different
context
to
do
that.
But
I
think
I've
heard
that
before.
H
I
think
the
approach
of
using
the
existing
span
sounds
great.
I've
been
meaning
to
to
do
this
work
with
falcon.
We
use
falcon,
but
I
haven't
had
a
chance
to
test
because
I've
been
working
on
bugs
on
the
grpc
stuff,
but
I
really
wanted
to
to
get
to
that
and
we
do
like.
I
have
been
looking
at
traces
flowing
from
the
client
through.
So
I
really
like
that
idea
of
using
it
if
it's
available.
A
C
No,
not
really,
I
guess
once
we
implement,
of
course,
first
one
for
philosopher
virginia.
I
guess
at
that
point
we
could
probably
look
into
extracting
common
code,
but,
but
so
far
it
looks
like
it
would
probably
just
be.
One
call
like
get
current
span
and.
B
C
D
D
All
right
cool,
the
other
issue
was
this
one.
C
C
The
solution
is
not
so
so
easy,
however,
so
I
was
proposing
that
any
instrumentation
that
creates
a
kind
set
to
client.
C
So
so
this
is
a
much
more
likely
issue
to
come
up,
so
people
might
instrument
xd
and
lcd
uses
requests
and
because
you
are
with
generates
three
client
spends
each
parent.
That's
very
great
situation
to
have.
A
What
do
you,
what
do
other
languages
do
about
this.
C
I'm
not
100
sure
I
think
they
do
something
similar,
but
I
can
look.
I
can
go
and
ask
other
things
and
figure
out
what
they
do,
but
I
vaguely
remember
they're
doing
something
similar
so
in
in
python.
We
have
one
use
case
today.
I
think
someone
contributed
instrumentation
for
url
and
they
thought
that
http
live
might
also
be
instrumented
in
the
future.
So
they
added
a
separation
mechanism
through
contacts,
but
it
adds
the
it
puts.
C
The
onus
on
the
on
the
parent
instrumentation
so
like
fcd
needs
to
set,
for
example,
something
it
needs
to
suppress
client
spends
under.
C
Coming
in
from
any
library
situation,
so,
like
request,
needs
to
set
variable
in
context
and
sort
of
hint
instrumentation
not
generated
not
generated
spam,
which
doesn't
seem
very
clean
to
me.
It
adds
a
lot
of
responsibility
on
instrumentation
and
then
it
also
like
we
also
lose
the
span
from
from
the
lower
level
libraries,
which
is
not
ideal
right.
C
Yeah
so
I'll
go
over
and
I'll
figure
out
what
other
language
they're
doing
for
this
in
the
meanwhile.
Does
anyone
have
any
concerns
or
thoughts.
F
I
think
updating
the
spanking
might
be
problematic
because
there
might
be
some
exporters
which
already
export
this
ban
on
start.
So
I'm
updating
the
spanking
afterwards
might
cause
problems
there.
C
A
A
A
Yeah,
it's
a
I
mean
it's
a
good
problem
to
solve,
though,
and
I'm
curious
to
see
what
you'll
find
out.
Looking
at
other
implementations
feels
like
I
feel
like.
This
is
definitely
something
that
everybody's
going
to
run
into,
or
everybody's
just
going
to
have
a
bunch
of
clients,
fans
that
don't
necessarily
mean
clients,
fans,
yeah,.
A
A
Michael,
do
you
want
to
talk
about
this?
One.
H
Yeah,
I
guess
the
the
question
is:
do
you
want
to
just
deal
with
this?
As
is
or
do
you
want
to
rework
the
trace
state
in
time
for
the
next
release?
Just
you
know
up
to
you
guys
it's
blocking
use
of
the
datadog
exporter,
which
is
why
I
was
trying
to
like
I've,
been
really
trying
to
work
on
this,
because
getting
this
done,
unblocks
me
to
actually
do
everything
with
with
open
telemetry
and
right
now,
I'm
totally
stuck
so
this
does
fix
it.
H
H
Yep
yeah,
that
was
that
last
question
there
I
mean
this
does
fix
it
like
we
kind
of
agree
that
it
does,
it
was
just
more
do
we
want
to
do
any
more
reworking
of
of
the
actual
class?
And
if
so,
I
don't
know
if
I'm
necessarily
the
right
person
to
do
it,
because
I'm
not
as
familiar
with
the
api
and
stuff
as
you
guys
are,
this
fix
does
fix
the
actual
problem.
But
you
know
it's
up
to
you
guys.
If
you
want
to
rework
it.
E
A
H
A
H
Also,
thanks
for
helping
finally,
finally
figuring
out
what
the
actual
problem
was
here,.
A
Yeah,
I
guess
my
my
only
comment
here
was
just
whether
or
not
I.
I
know
that
at
least
in
go
there's
a
whole
separate
package
called
semcomp,
and
I
was
I
was
just
curious
if
we
should
consider
doing
something
like
that
for
all
of
the
generated
semantic
convention
just
set
up
it's.
The
differentiation
is
very
clear
because
it
wasn't
clear
to
me
from
the
pr
like
the
the
package
path
is
like
open,
telemetry,
trace
attributes.
A
It
wasn't
necessarily
clear
to
me
that
these
were
semantic
conventions
and
that
they
were
auto-generated,
but
I
I
don't
have
like
a
strong
opinion
here.
I
was
just
curious
if
anybody
had
any
thoughts.
E
Have
like
a
manually
type,
this
semantic
convention
so
yeah,
I
decided
to
keep
the
resource
semantic
attributes
in
the
sdk
and
then
the
the
span
attributes
in
the
api.
So
if,
if
some
library
after
somebody
is
using
api,
they
can,
they
can
also
use
this
semantic
convention
like
http
semantic
convention,
etc,
etc.
So
that's
that's
the
reason
why
I
chose
to
do
this,
but
I'm
okay,
to
move
this
to
one
of
the
packages.
If,
if
you
want
to.
A
Yeah,
I
I
think
we
could
keep
it
in
the
in
the
same
packages.
I
I
was
more
meaning
like
the
the
path
inside
the
package,
would
would
be
more
explicit
if
you
had,
like
you,
know,
open
telemetry,
semconf
or
open
telemetry,
sdk
semconf,
or
something
like
that,
just
to
make
it
clear
that
these
are.
This
is
where
you
would
find
all
of
the
semantic
conventions
that
have
been
generated
from
the
from
the
yaml
or
whatever.
E
Yeah
right
yeah
that
that's
good
point
right
now:
the
movement.
E
It's
not
obvious
that
there
are
the
semantic
attributes.
What
do
what
do
you
suggest
changing
that
attributes
to
the
from
something
like
the
convention
convention
that
I.
A
B
I
was
thinking
it
would
be
nice
to
have
them
in
like
a
separate
python
pipe
package.
Just
because,
like
I
can
imagine,
some
use
cases
for
it
like
in
back
ends
or
like
people's
infrastructure,
where
they
want
to
use
these
semantic
attributes
like
but
they're,
not
using
the
hotel,
api
or
sdk,
because
it's
you
know
essentially
like
part
of
the
protocol
right
like
it's
like
a
hit
special
hints
for
the
ecosystem,
that
don't
really
depend
on
the
api
or
sdk
right.
E
I
I
took
with
java
what
it
does
it.
It
had
separate
tactics,
but
I'm
not
really
how
they
package
it
and
then
how
they
distribute
it.
But
it's
it's
not
part
of
the
api
or
sdk.
It
can
separate
yeah,
but
but
the
reason
I
in
python
I
did
because
this
resource
I
already
had
some
manually
typed.
E
So
I
thought
it
would
be
good
if
we
can
have
the
auto
generated
so
that
you
know
that
list
is
up
to
date
with
the
aspect
ml
files,
but
but
I'm
okay
with
having
this
update.
Also.
E
Yeah
they
are
publicly
exposed
in
sdk,
so
that
so
that
list
will
not
be
up
to
date,
so
it
will
be
yeah
this
this
list.
It
will
be
eventually
be
only
and
then.
B
A
B
Yeah
I
mean
maybe
maybe
I'm
overthinking
it
and
for
something
like
java
or
or
like
c
plus
plus
or
go
where
people
are.
You
know
writing
infrastructure
and
those
things
more
so
than
python
would
be
important.
I
don't
know
if
that's
too
much
work
or
if
it's
gonna
be
like
messy
to
do
that
or
not.
A
B
Yeah
yeah
exactly
is
anybody
opposed
to
having
a
separate
pie,
pie
package
for.
B
B
B
H
E
So
the
docs
is
failing
on
ci.
I
I
I
am
trying
to
figure
out
why
what's
happening,
but
the
even
the
error
is
not
very
clear
or.
E
I
I
I
tried
to
set
the
recreate
true,
but
it
didn't
solve
the
problem.
C
E
C
E
A
B
Yeah
yeah,
I
was
thinking
for,
like
the
caching
I
remember,
reading
in
the
circle
ci
docs,
when
we
were
using
that
because
they're
a
little
more
clear
that
you
can
put
like
a
cache
key,
just
like
a
number
and
then
you
can
increment
it.
Whenever
you
have
problems
like
this
and
then
it
would
sort
of
like
clear
all
the
caches
throughout
I'm
wondering
if
we
should
just
do
that.
B
B
B
B
E
And
I'll
try
to
I'll
try
to
remove
this
comment
and
then
see
if,
if
it
fixes
up
and
then
try
to
add
it
again
differently,
yeah.
E
Yeah,
I
remember
you
doing
something
in
main
repo
which
fixed
the
like
unusual
errors
in
yeah.
So
I
was,
I
was
wondering
if
you
can
help
me.
C
Yeah
this
is
the
same
feature
we
discussed
last
week.
I
had
it
implemented
for
general.
So
since
then,
I
added
support
for
a
few
more
frameworks.
Aaron
had
suggested.
We
implement
this
as
something
similar
to
a
propagator,
which
is.
This
is
like
logically
doing
the
same
thing
just
on
responses
requests,
so
I
did
that
and
it
does
it
the
users.
The
code
does
look
a
lot
cleaner.
Actually,
so
I
added
this
links
to
a
core
pr
that
adds
experimental
back
propagator
to
the
instrumentation
package.
C
A
B
Oh
it's
in
the
instrumentation
package.
Okay,
the
instrumentation
package
is
still
under
1.0
right,
like
less
than
1.0.
A
Right,
one
is
just
a
contrib
version
of
this
cool
any
other,
any
other
issues
or
pr's
that
people
want
to
talk.