►
From YouTube: 2021-05-12 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).
B
A
B
B
A
A
Likewise,
well,
do
you
work
I'm
working
with
splunk,
you
might
know
always.
A
Yeah,
I'm
talking
with
him
from
time
to
time,
yeah
yeah,
exactly
yeah,
okay,
awesome
yeah!
We
might
actually
you
know,
come
in
contact
because
always
shared
me
like
some
stuff
that
you
you
are
also
working
with
like
we
might
want
to
think
on
that
at
some
point
as
well.
A
C
C
D
D
E
D
E
Okay,
the
first
thing
that
I
have
on
the
agenda
is
to
release
the
api.
The
next
version
of
the
api
we've
made
quite
a
few
changes
based
on
the
spec
review
and
making
the
changes
in
core
based
on
those
changes
is
difficult
when
it's
not
released.
Yet
what
would
you
guys
think
we
should
do
this,
or
should
we
wait
until
the
changes
in
core
are
made?
First,.
E
All
right,
the
one
in
particular
that
I'm
thinking
of
is
the
rap
span
context
helper.
E
E
F
It
I'm
fine
with
it,
but
could
we
just
include
like
the
spr,
especially
the
one
that
removed
the
the
instrumentation
expression,
since
it
will
require
some
change
in
the
in
the
core
and
in
control?
If
you,
if
you
release
it
now,
we
could
remove
update
all
the
plugin
for
the
next
release.
E
Yeah
so
merge
the
merge,
the
the
suppress
one
first.
E
E
It
was
probably
this
year.
E
F
I
I
think
the
discussion
is
really
quite
long
about
how
we
should
do
it.
I
think
he
wanted
us
to
make
a
decision
at
the
other
thing.
E
Yeah,
so
I
I
think
that
this
has
been
open
for
a
while
I'd
I'd
like
to
just
make
a
decision
and
implement
it.
I
think
nassim
probably
added
this
here,
but
he's
not
in
the
meeting
today.
E
Personally,
I
I
think
it's
fine
at
to
add
it
to
the
interface
I
had
hoped
that
we
wouldn't
have
to,
but
valentine
you
brought
up
a
good
point
with
the
tracer
name.
I
think
we
we
probably
have
to
just
because
of
that
right.
E
Yeah,
so
that's
fine,
unless
someone
has
some
reason
that
we
shouldn't.
I
think
we
should
just
make
the
decision
now.
F
Yeah
and
the
last
comments
from
from
florina
actually
brings
up
another
solution.
What
would
be
it
to
implement
the
best
tracer
and
then
so?
The
common
stuff
I
implemented
once
in
in
one
tracer,
but
I
think
I
don't
think
it
will
be
easier
because
this
base
tracer
should
be
in
the
ipa.
I
think
so
that
it's
not
really
a
good
solution
too.
So.
E
F
E
E
I
was
making
the
the
suppress
tracing
change,
which
I
originally
was
implementing
as
an
api
extension
package
as
we
talked
about
last
week,
but
as
I
was
implementing
it,
I
I
didn't
like
it
because
it
was
adding
a
new
package
that
then
core
had
to
depend
on
it.
The
tracing
package
had
to
depend
on
it.
E
The
instrumentation
package
had
to
depend
on
it
and
it
was
pretty
clear
that
it
was
like
it
is
a
part
of
the
sdk
and
just
for
this
one
feature,
I
think
that
we
should
add
it
to
the
sdk
so
adding
it
to
the
core
for
the
suppress
tracing
context.
Key,
we
can
make
an
api
extension
package
if
we
still
feel
like
we
want
one,
but
this
particular
feature
I
don't
think,
should
go
in
an
extension
package.
E
I
think
it's
it's
clear
enough
that
this
is
a
feature
of
the
sdk
it
should
be
in
the
sdk.
Are
you
guys?
Okay
with
that
I,
before
I
went
too
far
away
that
I
wanted
to
make
sure
that
I
wasn't
moving
in
a
direction
that
that
people
were
unhappy
with,
particularly
since
we
talked
about
this
last
week
and
we're
talking
about
a
different
solution.
F
Yeah
about
this,
I
think
it
it's
actually
the
same
system
that
we
should
implement
than
the
the
discussion
with
last
week
about
the
http
name,
so
the
other
instrumentation
can
rename
them.
We
were
just
using
about
putting
utils
inside
the
instrumentation
bus
package,
and
so
the
sdk
can
depend
on
can
can
use
the
the
the
information
from
the
instrumentation
package
to
to
check
if
the,
if
the
key
is
is
the
is
the
tracing
is
to
place
or
not.
I'm
not
sure
if
it's
clear
or
not.
E
So
I
I'm
not
sure
what
you
were
trying
to
say.
Are
you
agreeing
or
disagreeing.
F
I
I'm
agreeing
that
you
should
be
on
the
on
the
sdk
part,
but
I
was
suggesting
to
put
it
inside
the
inside
the
instrumentation
package
like
like.
We
should
do
for
the
http
spam,
so
instrumentation
can
access
it
when
they
want
when
they
want
it
and
and
so
the
yeah
sorry.
D
But
we
are
also
discussing
I
mean
if
we
cannot
have
this
in
the
api,
then
I
guess
you
should
have
this.
I
don't
know
why
that
is
separate
packet
from
this
new
package
that
we
paid
for
the
like
api
extension.
E
Yes,
so
that's
what
I
was
saying
is:
I
started
implementing
an
api
extension
package,
but
then
it
was
being
depended
on
by
so
many
different
packages
within
our
repository
that
it's
not
it's
not
an
extension,
it's
it's
a
core
feature
of
the
sdk
and
the
sdk
doesn't
work
without
it.
So
to
put
it
in
an
extension
package,
I
don't
think
makes
sense.
D
E
D
E
D
Okay,
sdk,
if
we
put
this
intensity,
that
means
anything
we
need
to
depends
on
sdk
like
instrumentation
from
some
point.
We
don't
want
that.
E
It
does
mean
that
so
it
means
that
if
instrumentations
want
to
use
this
feature,
they
will
have
to
depend
on
the
sdk
on
the
core
package,
which
doesn't
mean
they
can't
be
used
with
other
sdks.
But
it
would
mean
that
this
feature
might
not
work
with
a
third-party
sdk.
So
if
some
tracing
vendor
made
their
own
sdk,
then
they
may
have
a
different
method
to
suppress
tracing.
E
G
G
D
If
I
understand
this
correctly
so
currently,
we
need
only
the
api
for,
like
the
instrumentation
to
to
to
suppress
the
the
context
yeah
yeah,
and
if
you
remove
this
from
the
api,
I
would
assume
that
we'll
create,
like
whatever
we
call
it.
It
can
be.
D
E
It
doesn't,
but
it
would
be
if
the
instrumentation
wants
to
suppress
tracing
with
our
sdk.
They
are
depending
on
our
sdk
and
it
wouldn't
necessarily
work
with
third-party
sdks,
just
like
it,
wouldn't
necessarily
with
the
api
extensions
package.
There's
no
guarantee
that
the
third-party
ftk
implements
the
api
extensions
either.
D
Yeah
I
mean,
but
I
think
this
is
fine
here,
because
we'll
still
be
able
to
quickly
move
it
back
to
the
api.
If,
finally,
one
day
the
api
and
the
spec
decides
that
okay-
let's
let's
have
it
back
to
the
api-
maybe
it
will
be
a
bit
different,
but
it
might
happen
that
we'll
have
it
back
in
the
api
and
then
we
can
get
rid
of
this
package.
F
For
me,
I
think
I
agree
with
daniel
on
the
fact
that
third
party
sdk
will
need
currently
to
implement
this.
If
we,
if
we
have
a
specific
packages
for
it,
so
I'm
fine
moving
it
into
the
core.
E
Yeah,
well,
I
know
that
amir
maintains
instrumentations
that
use
it.
So
I
guess
amir.
If
you're,
if
you're
paying
attention,
would
you
be
okay,
depending
on
the
open,
telemetry
core
package
in
order
to
get
access
to
this
function?.
H
D
E
E
E
D
D
D
D
I
mean
my
god
thing
tells
me
that
basically
we'll
we'll
have
it
in
the
api
sooner
or
later,
just
another.
E
E
F
D
F
Yeah
yeah,
but
if,
if
you
don't
need
it,
I
mean
the
the
this
is
only
the
for
the
http
plug
in
our
instrumentation
that
are
using
the
system.
Of
course.
Obviously
people
will
install
it
because
they're
mostly
using
the
http
with
the
system,
but
it's
not
a
dependency
for
every
instrumentation
and
that
doesn't
force
any
third
party
users
to
use
it
actually.
D
E
Yeah,
because
we're
using
symbol.4
technically,
we
could
do
that,
but
I
think
that
introduces
like
an
implicit
dependency
that
could
easily
break.
So
you
think
the
core
package
is
too
heavy,
basically
for
an
instrumentation
to
depend
on.
Is
that
what
you're
saying.
D
I
A
E
E
D
Okay,
then,
in
your
sdk
you
will
have
to
use.
You
will
have
to
take
our
sdk.
You
will
have
to
sdk
just
to
use.
One
function
so
sounds
weird,
but
yeah.
E
B
E
So
if
we
make
it
another
package,
what
should
we
call
it?
Because
it's
not
they're,
not
api
extensions?
I
think
it's
it's
an
sdk
specific
thing,
but
should
we
make
a
package
for
essentially
sdk
context
helpers
for
the
suppress
instrumentation
one
and
for
the
http
span,
one.
D
Don't
worry,
there
might
be
a
few.
That
would
be
basically
just
a
shortcut
for
for
the
api
so
like
instead
of
I
don't
know
with,
I
mean
the
most
famous
one
with
span,
so
we
will
so
that
we
could
be
able
to
to
have
like
one
one
function.
That
does
those
everything
with
the
callback
like.
Currently,
you
have
to
use
like
context
with
context
active
and
spanner
and
so
on.
Here
we
could
have
like
one
helper
in
this
package.
D
D
I
mean
I
would
be
fine
with
just
even
like.
I
know
we
can
call
it
suppress.
I
api,
suppress
or
api
context
extension
or
whatever
the
name.
D
D
D
G
E
Yeah
I
mean
it
kind
of
is,
and
it
kind
of
isn't
the
the
it's
definitely
sdk
related.
But
it's
not
an
extension
like
that.
This
suppressed
tracing
without
it
the
sdk,
doesn't
work,
but
you
end
up
in
a
in
an
infinite
loop
when
you
try
to
export
spans
so
to
call
it
an
extension
doesn't
feel
correct
to
me,
but
I
also
understand
not
wanting
to.
E
Not
wanting
to
force
people
to
depend
on
the
core
package,
because
it's
too
big,
I
don't
know
off
the
top
of
my
head,
how
big
the
core
package
is
as
a
dependency,
but
I
understand
the
idea
of
trying
to
minimize
you
know
those
external
dependencies.
E
F
E
F
And
especially
because
I
think
the
the
only
sorry
the
the
since
this
is
the
speed
instrumentation
that
is
depending
on
it,
and
this
is
another
new
thing-
I
don't,
I
don't
think
the
actual
burden
size
and
the
wall
threshing
take
take
your
importance
there,
because
we
are
using
nodes.
So
you
don't
have
those.
E
E
E
E
G
E
Okay,
so
let's
move
on
to
the
next
one,
if
that's
okay,
yep,
okay,
I
was
trying
to
implement
the
default
service
name.
According
to
the
specification,
every
resource
has
to
have
a
service
name,
that's
part
of
the
sdk
specification
and
I
originally
implemented
it
as
sort
of
naively
the
pr
has
been
open
for
a
while.
It's
already
actually
gotten
a
couple
of
reviews,
but
essentially
in
the
constructor.
If
there
is
no
service
name
at
construction
time,
then
one
is
automatically
added
based
on
some
set
of
default
rules.
E
The
reason
this
doesn't
work
is
especially
as
I
was
going
through
the
tests.
It
became
apparent
that,
as
you
create
and
merge
resources
together,
you
know
only
the
final
resource
needs
to
have
a
name.
E
E
E
E
I
would
what
I
just
want
to
move
this
service
name
logic
into
the
tracer
provider.
Does
that
seem.
F
I
I
also
think
that
that
the
fact
to
move
the
the
this
to
the
I
agreed
to
to
move
it
to
the
transfer
provider,
but
I
would
say
that
it
might
be
the
same
problem
with
the
metrics
sdk
later
on
that
we
want
to
set
the
met
the
service
name
to
inside
it.
So
I
I'm
not
sure
if
moving
it
into
the
the
tracer
provider
would
solve
the
issue
in
the
long
term.
E
F
Yep,
so
I
actually
agree
to
to
try
to
remove
the
logic
from
the
exporter.
I
I
think
we
could
still
allow
exporters
to
to
to
to
rename
the
the
service
name
if
they
want
to
but
yeah.
I
really
really
duplicated
logic
across
the
exporter,
but
I
think
the
my
main
issues
is
where
to
move
this
service
name,
to
avoid
like
duplicating
for
each
signal
that
we
have
like
metrics
or
traces
to
have
like
a
specific,
a
specific
like
thing,
a
way
to
configure
the
the
service
name
by
default.
E
E
I
had
to
change
so
many
like
tests
across
so
many
different
packages
that
it
seemed
like,
maybe
there's
an
easier
way
to
do
it,
but
I
I
agree
that
this
is
probably
going
to
be
a
problem
with
metrics
too,
so
we
should
probably
just
keep
it
the
way
that
I
have
the
pr
and
it's
just
an
unfortunately
big
pr
for
a
small
feature,
and
it
is
what
it
is
but
you're,
okay,
with
removing
the
logic
from
the
exporters,
then.
F
Yeah
for
sure,
for
sure
I
think
it's
way
better
to
move
to
move
it
and
we
we
can.
We
can
still
I
mean
if
you
don't
mind,
just
throwing
your
you
worked,
you
work,
so
you
could
still
throw
the
pr
and
move
it
logic
outside
exporters
and
we'll
see
later
on
with
the
metric
sdk.
When
we
start
working
on
it,
I
think,
but
it
really
depends.
What
do
you
want
to
do.
D
E
The
exporters
right
now
all
implement
their
own
service
name
logic
and
it's
actually
different.
So
like
the
zipkin
one
uses
the
service
name
from
the
resource
by
default
and
the
one
you
provide,
as
the
configuration
is
just
fallback
and
the
one
for
the
otlp
uses.
If
you
provide
it,
it's
like
an
override,
so
the
logic
is
opposite.
E
E
E
For
now,
we'll
just
the
current
pr
as
it
is,
is
working
it's
just
requiring
a
lot
of
changes
to
tests
that
I
didn't
want
to
have
to
make,
but
it's
fine
I'll,
just
I'll
just
change
them
valentine.
Do
you
want
to
talk
about
this
next
option?.
F
F
That's
just
a
pretty
opposition
and
yeah.
So
I
opened
last
week
and
nobody
made
any
comment
on
it.
So
I
will
just
ask
people
to
look
at
it
and
tell
me
if
it's
something
we
want
to
do
or
not.
E
Okay,
this
next
one
was
a
bug
actually
from
last
week.
It
has
a
pr.
I
just
needs
reviews.
Actually
it
looks
like
not
anymore.
Cool
proved
an
hour
ago,
so
never
mind,
and
then
there
are
spec
review
issues,
some
of
which
have
pr's.
Last
week
there
were
no
pr's
for
these
two,
so
they're
new,
so
they
need
to
be
reviewed.
These
were
created
by
where's
they're,
relatively
straightforward.
E
We
already
talked
about
the
service
name
and
I
am
working
on
these
two
prs,
but
it
would
be
much
easier
if
we
release
the
api
first.
So,
like
I
said
earlier
after
we
merge
this
press
instrumentation
changes.
I
think
we
should
release
the
api.
D
For
the
recent
api,
I
think
last
thing
is
the
pr
I
opened
with
the.
D
E
Yeah
I,
if
you
asked
me
a
month
ago,
I
would
have
said
a
week.
I
I
had
been
hoping
you
know
to
get
it
done
as
soon
as
possible
for
a
long
time
now
the
the
spec
review
pushed
it
back
further
than
I
had
hoped,
but
these
are
the
last.
These
issues
that
we
just
talked
about
are
the
last
issues.
Before
we
do
the
sdk
rc
most
of
them
already
have
prs.
E
I
would
hope
that
we
could
do
it
at
next
week's
seg
meeting
if
possible,
but
I
keep
saying
that
and
it
keeps
not
happening,
so
I
really
don't
know
what
to
tell
you.
I
don't
want
to
make
any
promises,
but
hopefully
soon
I
I
know
that
that's
not
a
very
helpful
answer.
I
E
Yeah
I
it's,
I
think
the
the
remaining
issues
are
small
and
there
aren't
that
many
of
them.
So
I
would
hope
we
should
be
able
to
get
this
done
in
the
next
week
and
rc
is
exactly
what
it
says:
it's
just
a
release
candidate,
so
it
doesn't
mean
we
have
to
stop
working
or
that
we're
done.
E
So
I
I
hope
next
week
at
the
sig
meeting
and
if
it
doesn't
happen
by
next
week,
then
you
know-
I
would
say
the
week
after
that
at
the
very
latest
or
I
will
start
to
become
quite
irritated.
E
Okay,
does
anyone
else
have
anything
that
they
want
to
talk
about
today,.
E
Nope
then
everybody
enjoy
looks
like
there's
a
shh.
E
Okay,
I
guess
everybody
have
a
good
week
and
I
will
talk
to
you
next
week.
Oh
one
thing
worth
mentioning,
I
don't
know
how
many
people
are
attending
observability
fest
next
week,
but
it's
monday
and
tuesday,
so
I
will
be
less
available,
monday
and
tuesday
next
week
than
normal.