►
From YouTube: 2022-04-06 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
Okay,
I
think
we
can
probably
get
started.
Let
me
share
my
screen
here.
Everybody,
please
add
yourself
to
the
attendees
list
and
if
there's
anything
that
you
want
to
bring
up
in
the
meeting,
go
ahead
and
add
it
to
the
agenda.
A
Otherwise
I
guess
I'll
kick
us
off
by
introducing
per
anders.
I
I
hope
I'm
pronouncing
that
right
or
close
at
least
from
ikea,
who
wants
to
give
us
a
short
presentation
on
a
module
that
they
wrote
to
help
export
open,
telemetry
formatted,
trace
data
from
their
edge
computing
platform,
which
is
a
little
bit
restricted
and
was
not
able
to
run
the
standard
open,
telemetry
sdk.
B
Thank
you
daniel
before
I
start
just
a
quick
time
check
how
much
time
do
I
have.
A
The
meeting
is
an
hour
long.
Oh
we
we
have
yeah.
You
can
see
that
the
agenda
normally,
I
would
say
we
use
around
a
half
an
hour
of
the
meeting.
Sometimes
we
use
the
full
hour.
Sometimes
we
don't.
A
B
A
B
B
Yeah
cool,
so
my
passions
is
really
about
optimization
performance
and
observability.
I
belong
to
a
team
called
observability
pipeline
in
ikea,
and
that
belongs
to
the
operational
intelligence
group.
I've
been
working
with
ikea
for
10
years.
I've
obviously
been
through
the
kind
of
involvement
from
monitoring
into
more
mature
observability,
and
our
team
is
working
a
lot
with
basically
enabling
observability
to
other
teams
within
ikea
and
one
of
the
foundations
that
we
have
decided
to
work
with
is
open.
Telemetry.
B
Some
background
about
the
topic
of
today
is
basically
the
instrumentation
that
we
did
for
fastlace
computed
edge
platformer.
So
one
of
the
teams
who
are
looking
into
this
framework
with
the
solution
they
contacted
us
and
said
you
know
we're
going
to
do
this.
We
really
going
to
need
observability,
so
they
wanted
our
help.
Basically,
so
we
we
had
a
look
and
saw
what
we
could
come
up
with.
Fastly
is
a
cdn
provider,
you're,
probably
familiar
with
cdn,
just
very
brief
about
the
kind
of
evolution
of
cdn.
B
It
has
gone
from
being
more
static
delivery
that
obviously
could
be
covered
in
more
simple
or
simplistic
observability
to
more
advanced
features.
Now
they
actually
provide
run
times
where
we
can
execute
our
code.
That,
obviously,
is
fantastic,
but
we
also
need
to
observe
it
make
sure
that
it's
performing
as
expected
and
also
capture
potential
exceptions
and
obviously
the
environment
is
very
distributed,
which
adds
some
complexity
to
it.
So
we
identified
a
few
challenges
and
one
was
obviously
the
distribution.
B
It
was
kind
of
the
next
level
I
mean
we've
been
there
working
with
when
we
had
stuff
on-prem
in
different
data,
centers
moving
to
the
cloud
moving
to
kubernetes
cluster,
you
know
serverless,
containers
and
so
on.
So
this
is
kind
of
the
next
level
that
we
would
like
to
support
in
our
observability
framework
that
we
have
been
building.
B
Also,
the
runtimes
are
typically
stripped
and
restricted.
You
can't
do
exactly
what
you
can
do
when
you
control
everything
like
if
you
build
a
container
and
decide
which
packages
you
want
to
have
there
and
so
on,
we
don't
really
own
that
space.
We
need
we're
basically
just
able
to
provide
our
code
and
it's
going
to
run
in
there,
but
there
are
certain
parameters
that
we
cannot
control.
B
So
that's
why
this
level
of
visibility
becomes
very
important
to
them
and
finally,
we
need
to
come
up
with
something
that
makes
this
really
easy
for
them
to
instrument
and
also
to
consume
the
data
in
our
team.
We
have
two
desires,
I
would
say
the
first
one
is
obviously
open
telemetry,
we
fell
in
love
quite
quickly
with
that
and
it
fitted
our
requirements
very
well.
B
We've
been
using
the
collector,
obviously
a
lot,
because
that
allows
us
to
use
the
exporter
for
different
tools
that
different
teams
might
be
using,
but
still
we're
able
to
share
the
data
and
achieve
distributed
tracing,
which
is
kind
of
a
key
thing
we
wanted
to
have.
Second
one.
We
look
at
the
signals,
traces,
logs
and
metrics,
so
those
were
the
two
things
we
wanted
to
bring
to
the
team
who
was
looking
into
the
computed
edge
from
from
costly.
B
We
started
off
with
traces
that
seemed
to
be
the
most
complicated
thing,
but
also
the
thing
that
would
bring
most
value
since
the
performance
would
be
very
much
of
interest
and
they
would
need
to
understand
exactly
when
they
run
their
functions
or
methods.
They
really
need
to
understand
what.
Where
is
the
time
consumed?
B
B
We
will
obviously
still
have
a
lot
of
overhead
and
also
when
there
were
updates.
We
need
to
kind
of
go
through
that
process
again,
so
we
started
kind
of
from
the
other
way
around
see.
How
can
we
build
something
very
simple,
very
nift
that
could
fit
in
here
that
we
can
kind
of
work
with,
so
we
gave
that
a
try
just
to
you
know,
explore
to
start
with.
B
It
turned
out
that
it
worked
really
well.
So
we
built
this
very
small
library
where
we
were
able
to
get
traces
out
in
otlp
with
our
framework
apply.
We
have
certain
attributes
that
we
had
for
from
our
framework
to
make
sure
that
we
can
kind
of
allocate
the
traces
to
certain
teams
and
so
on,
and
we
achieved
this
by
javascript
wrapper
that
we
built
for
the
infested
computed
edge
and
we
sent
them
to
an
open,
telemetry
collector
and
then
forwarded
to
two
different
things.
So
we
tried
out
a
splunk
usability
and
gcp
tracing
in.
B
In
our
case,
the
way
we
enable
it
is
basically
a
wrapper.
So
what
you
see
here
before
is
basically
how
you
typically
add
the
event
listener
to
the
fetch.
So
that's
the
request
coming
in
to
the
fastly
computed
edge
and
then
you
basically
respond
with
your
function.
That
creates
a
response
object
and
what
we
did
is
then
just
include
our
library
and
then
wrap
the
function
that
will
return
the
response.
B
So
the
handle
request
in
this
case,
so
when
by
doing
that,
you
basically
get
auto
instrumentation
of
the
kind
of
full
execution
of
your
code,
you're,
also
wrapping
any
fetch
that
you're
doing
from
there
and
you
do
enable
capabilities
of
wrapping
logs
and
you
get
a
few
other
features
as
well.
I
will
share
with
you
so
we
also
tried
to.
B
I
mean
we're
obviously
looking
at
that
we
are
familiar
with
the
kind
of
official
javascript
instrumentation,
so
we
try
to
make
it
as
similar
as
possible
to
make
sure
that
people
who
actually
work
with
you
know
have
the
luxury
of
being
able
to
use
the
official
one
that
they,
it
should
not
be
a
big
gap
for
a
big
step
for
them
to
start
using
this
library
when
they
were
developing
for
computed
edge.
So
you
know
you
you
set
resource
attributes.
There
are
a
few
that
are
required.
B
That's
obviously
you
know
in
a
way
you
could
say
that
the
sdk
and
api-
we
kind
of
put
it
all
together,
trying
to
keep
it
really
small.
So
that's
really
not
by
the
standard,
but
that's
how
we
decide
to
do
it
just
to
keep
it
as
simple
as
possible.
So
you
specify
url,
you
specify
your
backend,
just
something
you
set
up
in
fastly
to
be
able
to
communicate
with
it,
and
then
we
using
basis
authentication
for
the
collector
to
make
sure
that
the
otlp
receiver
is.
You
know,
there's
more
than
just
the
securities.
B
Also
authentication
spans
are,
you
know,
created
in
a
similar
fashion,
with
the
official
you
can
see,
attributes
and
so
on
logs.
We
basically
just
made
a
wrapper
that
supports
json
logs
we're
using
splunk
internally
and
basically,
what
this
does
is
that
it
decorates
the
log
entries
with
like
things
like
trace
id
and
span
id
and
also
some
pieces
from
our
standard,
so
here's
an
example
from
what
it
would
look
like
in
splunk.
B
So
the
lower
entry
here
is
basically
something
that's
not
wrapped,
so
we
just
send
the
log
message
once
we
have
the
wrapper
automatically.
These
details
are
added,
so
you
get
the
spam
id.
You
get
the
trace
id
then
system
companies,
some
details
that
we
had
from
our
framework.
Basically-
and
we
made
an
example-
set
up
to
kind
of
verify
things
with
this
and
make
sure
it's
working,
so
we
have
the
main
service
computed
edge
service,
running
fastly.
B
B
You
know
collaborations
around
this,
how
we
work
with
it,
but
we
obviously
came
to
the
idea
that
you
know
maybe
it's
our
time
not
to
contribute
to
the
community,
because
we
have
got
so
much
from
open
telemetry
and
we
like
it.
So
we
thought
you
know,
let's,
let's
check
if
this
is
something
that
would
be
something
that
the
open
telemetry
community
would
like
to.
You
know
if
it
would
be
a
fit
in
in
one
of
your
repositories
and
more
people
can
use
it
benefit
from
it
and
obviously
also
help
to
improve
it
moving
forward.
B
Right
so
here's
just
a
front
end
that
basically
generates
two
traces
when
we
click
this
button.
So
if
I
click
here
it
generates
the
new
trace
and
that's
obviously
being
sent
then
per
what
I
shared
with
you
in
kind
of
the
setup
of
our
small
demo
environment.
So
it's
going
to
hit
one
of
the
computer
edge
functions
that
basically
forwards
the
request
to
one
static
resource
ikea,
another
function
and
also
finally,
to
our
demo
environment.
So
if
we
don't
look
at
what
the
traces
look
like,
I
did
some
precooking
here
to
save
us
time.
B
So
here
I
have
kind
of
the
full
execution
of
the
computed
edge
function.
So
you
have
that
span
in
here.
It
also
supports
obviously
incoming
headers,
so
the
trace
parent
header.
So
if
something's
kind
of
coming
from
another
system
or
from
a
front-end
instrumentation,
that's
obviously
being
picked
up
and
they
belong
to
the
same
trace.
So
in
here
we
in
this
demo
we
have
some
spans.
B
We
have
one
span
where
you
send
multiple
requests
synchronously.
So
here
you
hit
actually
sending
a
request
to
another
computer
edge
function,
and
here
is
where
you
get
it
out.
We
do
decorate
the
data
with
some
attributes.
So,
as
you
can
see
here,
you
have
the
service
version
in
fastly,
so
you're
able
to
kind
of
connect
your
performance
with
the
specific
version
of
your
your
service,
you
have
the
id
to
connect
which
application
you
actually
think
so
right
now,
I'm
looking
at
the
the
top.
B
B
You
know
if
the
expected
environment
actually
was
getting
the
hit
from
the
end
users
and
then
go
through
here
so
eventually
hit
our
test
environment
here
and,
as
you
can
see,
it's
a
java
application
here
with
a
lot
of
different
underlying
services
just
to
show
how
distributed
tracing
is
working
so
we're
basically
getting
the
trees
from
computed
edge
throughout
a
number
of
different
services.
Down
to
you
know
the
final
thing
here,
that's
what
it
looks
like
here
and
in
single
effects.
We
also
get
this
overview,
so
you
can
see
how
communication
is
happening
here.
B
You
have
the
main
function.
You
have
the
other
function.
We
talked
to.
You
have
the
ikea.com.
You
have
our
demo
applications.
Obviously
talk
to
a
number
of
services,
we
embedded
some
natural
failures
just
to
make
it
more
fun
to
look
at,
and
you
also
get
the
traces
in
here.
You
know
in
a
similar
fashion.
Obviously
they
I
mean
all
things
have
their
ways
of
kind
of
exposing
the
data
in
different
ways.
B
B
If
we
compare
to
how
you
set
things
up
in
in
open
telemetry
and
me
and
some
of
the
developers
have
had
a
look.
Obviously
I
had
a
call
with
daniel
last
week
and
which
was
very
informative
and
we
got
some
great
insight
there.
So
what
we
would
need
to
do
is
if,
if
this
would
be
of
interest
for
the
community,
it's
obviously
to
make
sure
that
we
adapted
to
your
ways
of
working
which
seems
to
be
very
mature
so
to
make
it
fit
all
right.
I
think
that's
pretty
much
it
any
questions.
A
Thanks
for
the
demo,
I
have
a
couple
of
questions.
I
I
already
talked
to
you
for
an
hour
before,
though
so
I'll,
let
others
ask
first
if
they
have
their
if
they
have
questions
yeah,
I've
got.
A
On
bundle
deployment
size
or
on
performance
impact,
are
you
asking.
A
Where,
where
are
you,
he
put
him
in
the
chat
that
he's
having
audio
problems?
He
can't
hear
us.
A
Nev,
I
can
give
you
a
little
bit
of
a
hand,
wavy
answer,
since
I
already
talked
with
pa
about
this
for
a
short
period
of
time.
Last
week
they
wrote
it
in
javascript,
not
in
typescript,
so
there's
no
transpilation
step
and.
D
A
Hello,
I
will
and
join
again
okay,
so
there
was
no
transpilation
step
and
just
the
the
raw
javascript
itself
was
only
a
few
hundred
lines
200
to
250,
something
like
that.
A
C
A
They
didn't
drag
in
any
of
the
hotel
api.
They
wrote
the
whole
thing:
it's
it's
completely:
standalone,
okay
and
they're,
just
generating
the
the
export
yeah
pa.
Can
you
hear
us
now
yeah,
okay,
you're?
Sorry
about
that?
I
don't
know
perfect.
So
nev
was
asking:
what
is
the
the
the
bundle
deployment
size.
B
The
code
is
basically,
let's
see
if
I
can
find
it
here
quickly.
It's
like
600
rows
and
the
bundle
size.
B
But
I
mean
we
obviously
like
I
said
we
started
from
the
ground
building
up,
so
it
I
I
think
you
know,
there's
probably
new
features
that
we
want
eventually
like
to
add
when
we
are
exploring
the
computer
edge
functionality
further.
But
right
now
I
mean
we
were
kind
of
working
hand
in
hand
with
the
people
working
without
exploring
that
so
feature
was
added
per
requirement
and
it
might
be
that
someone
else
would
like
to
send
a
log
somewhere
else.
B
For
example,
then
you
need
to
take
that
into
account
as
well
and
there's
probably
you
know
other
enhancements
as
well.
I
mean
that
and
I'll
you,
you
just
and
I
discuss
the
exception,
handling,
probably
be
improved
as
well,
and
that
will
obviously
add
up
as
well,
but
we
kind
of
started
off
from
a
different
direction.
So
we
started
building
from
the
ground
up,
but
we
obviously
try
to
apply
the
kind
of
open,
telemetry
standard
everywhere.
C
Yep
and
and
looking
at
your
your
basic
definition,
you
just
monkey
patch
anything
you
pass
in
and
then
just
decorate
the
output
yeah.
So
you
generate
it
from
the
patch
nice.
E
Yeah
great,
thank
you
for
your
presentation
and
I've
been
working
on
the
testing
and
testing
the
sdk
on
my
a
broker-like
environment
to
ensure
our
sdk
is
working
correctly
on
the
environment
like
worker
or
dino,
or
something
else
so
that'll
be
interesting.
Like
you
mentioned,
the
you've
been
using
the
instrument,
the
package
for
the
fetch
instrumentation,
and
we
have
been
identified.
E
B
No,
I
mean
not
really,
I
mean
we,
the
kind
of
fastly
environments
kind
of
a
black
box
to
us,
so
we
we
got
their
apis
and
we
were
able
to
run
our
code
per
their
definition,
their
apis
in
there.
So
we
haven't
really,
you
know,
been
able
to
get
too
much
insight
and
make
them
do
a
lot
of
changes
to
their
environments,
but
also
when
we
started
this,
I
mean
they're,
very
javascript,
influential
was
actually
in
beta
as
well,
so
we
we
got
started
quite
early
there.
B
E
B
Great
yeah,
I
think
I
mean
there
will
be
progress
in
this
as
well
as
new
move
forward,
and
there
might
be,
I
mean
we
obviously
got
in
contact
with
the
foster
computer
edge.
I
know
that
there
are
other
companies
and
solutions
working
with
similar
approaches,
so
it
also
might
be
adoption
and
more
flexibility.
Added
to
this
to
be
able
to
support.
You
know
more
more
platforms,
basically
there's
a
lot
of
things
going
on
in
this
space.
A
So
I
guess
we
should
talk
about
probably
what
the
next
steps
are.
You
had
mentioned
that
you
were
interested
in
in
upstreaming
this
into
the
contrib
repository.
Are
there
any?
You
know
anything
that
we
can
do
to
help
you
with
that
process,
or
are
there
steps
that
you
still
need
to
take
before
you
can
do
that,
and
what
would
your
expected
timeline
be
on
something
like
that.
B
I
think
there
are
two
things
we
need
to
do.
First
is
obviously
the
make
sure
that
the
testing
is
working
as
expected,
and
we
will
really
try
to
adapt
to
what
you
already
have
available
in
the
in
your
repo.
So
kind
of
I
mean,
as
I
said
me,
and
some
other
developers
have
a
look
at
it,
and
it's
very
mature
and
very
you
know
straightforward
as
far
as
we
can
see,
so
we
just
need
to
adopt
and
make
sure
it
kind
of
fits
in
there.
B
So
every
the
process
is
kind
of
smooth
before
we
actually
make
that
pull
request,
and
we
also
need
to
sync
up
with
with
our
legal
team
and
make
sure
that
you
know
everything
is
fine
from
their
perspective
because
ikea,
we
have
a
history
of
not
really.
You
know
it's
quite
sensitive,
how
you
use
the
ikea
brand.
You
don't
see
a
lot
of
companies
saying
that
ikea.
They
are
customers
of
ours
because
that's
basically
very
restricted
and
the
similar
situation,
I
guess,
have
been
around
open
source.
B
But
now
we
do
have
this
open
source
office,
where
people
are
actively
working
to
make
sure
that
we
are
able
to
contribute
to.
You
know
different
communities
as
well.
So
we
did
have
that
discussion
before
I
actually
approached
you
daniel
and
talked
about
different
ways.
How
can
we
do
this?
One
would
be
you
know,
put
it
in
our
organization
and
then
falsely
organization
or
open
telemetry.
B
So
we
need
to
kind
of
get
there
thumbs
up
that
this
is
good
to
go,
but
we
also
need
to
do
our
homework
when
it
comes
to
the
testing
right
now,
it's
javascript,
so
it's
not
typescript.
So
I
think
is
that
okay,
or
should
we
making
touchscript
instead.
A
I
mean,
in
my
opinion,
it's
not
a
deal
breaker,
whether
it's
typescript
or
javascript,
maybe
for
the
initial
open
sort.
You
know
the
initial
push,
we
can
use
what
you
have
and
then
you
know
maybe
a
translation
to
typescript,
maybe
something
we
want
to
do
further
down
the
line.
A
Just
in
terms
of
maintainability
and
stuff
like
that
yeah
you
know,
typescript
gives
obvious
advantages
from
a
development
perspective,
but
then
also
we've
been
talking
about
updating
our
examples,
for
instance,
so
that
they
are
type
checked
against
the
working
version,
which
only
works
with
typescript
to
make
sure
that
that
those
are
kept
up
to
date
more
easily
and
some
stuff
like
that.
But
I
I
don't
think
it's
a
deal
breaker
at
the
moment.
A
We
happen
to
have
all
typescript
at
the
moment,
but
I
think
that
that
is
just
because
we
started
with
typescript
and
kept
going
with
typescript.
This
will
be:
we've
had
a
couple
of
packages
upstreamed
from
from
other
contributors
and
vendors,
particularly
amir,
has
upstreamed
a
couple,
but
those
were
already
in
typescript
to
begin
with.
So.
F
A
B
I
have
one
more
question:
that's
regarding
the
examples
and
how
you
structure.
So,
if
I
would
assume
that
this
would
be
done
in
like
a
package
in
the
country
right
or
yes
and.
B
Is
like
examples
connecting
to
it
because,
right
now
our
example
is
very
much
ikea
focused,
so
it's
kind
of
built
for
for
our
teams
and
was
made
to
prove
certain
points
to
teams
based
on
question.
We
received
and
capabilities
we
were
asked
for
so
we
probably
make
the
example
more
global
and
you
know
just
making
use
of
the
basic
functionalities
that
we
have
in
there
make
sure
we
cover
it
in
the
examples.
B
A
One
more
quick
question
that
I
do
have
is
like:
how
do
you?
How
do
you
see
this
fitting
in
the
ecosystem
with
the
existing?
You
know
we
have
the
sdk,
which
obviously
didn't
work
for
your
use
case,
but
is
this
something
that
you
know
long
term?
A
Do
you
see
it
as
just
a
package
that
is
used
for
like
restricted
and
edge
computing
environments,
or
would
you
be
hoping
to
have
you
know
the
the
the
lessons
learned
from
this
package
incorporated
into
the
vanilla,
sdk
and
then
deprecate
the
the
package
that
you're
up
streaming
or
like
what?
What
is
your
long-term
vision
for
for
how
that
works?.
B
I
I
think
there
might
be
the
way
I'm
thinking
right
now
is
that
there
might
be
a
place
for
something
really
lightweight
when
you
just
need
that
basic
feature
and
you're
kind
of
rather
than
having
nothing.
You
want
to
have
this
that
the
full
sdk
won't
fit.
So
there
will
be
environments
where
some
of
the
vendors
they're
working
on
more
advanced
things
where
the
standard
sdk
would
work,
which
is
great,
but
I
think
there
will
still
be
a
space
for
these
really
lightweight
things
where
you
are
restricted
for
some
time.
G
Yeah,
I
was
gonna
say
with
regard
to
like
it
sounds
like
this
is
an
alternate
sdk,
but
it
also
sounded
like
it
doesn't
work
with
the
open,
telemetry
api
right
now.
I
just
wanted
to
call
out
like
for
all
the
instrumentations
and
stuff
in
the
contrib
repo
to
work.
I
believe
it
would
need
to
at
least
be
able
to
work
with
the
open
telemetry
api
is
that
right.
A
A
A
Aspect
of
it,
because
I
think
I
think
nev
would
be
quick
to
point
out
once
you
pull
in
the
instrumentation
packages.
You
pull
in
a
huge
amount
of
bundle
and
dependencies
and
stuff
like
that
which
is
sort
of
antithetical
to
the
the
point
of
of
this
package.
Yep.
C
Yeah,
I
I
think
at
some
point
at
least
what
we've
been
discussing
the
client
instrumentation
sig
is.
We
will
look
at
generating
a
browser-specific
version
of
the
javascript
api,
so
being
much
more
lightweight
and
we
can
probably
use
some
of
the
ideas
that
you've
got
there
as
part
of
that
and
right
now,
though
yeah.
If
you
drag
in
any
of
the
existing
otl
api,
it
becomes
extremely
problematic
from
a
size
perspective.
A
Okay,
well,
I
guess
you're
obviously
always
welcome
to
join
these
meetings
and
it
sounds
like
your.
Your
next
few
steps
are
at
least
internal,
so
I'll
wait
to
hear
from
you
on
those,
but
it
sounds
like
nobody
has
any
objections
to
you,
upstreaming
it
or
anything
like
that.
I
know
I
certainly
don't
as
long
as
what
we
talked
about
last
week.
A
Somebody
has
to
be
able
to
step
up
to
to
be
the
the
package
owner
and
you
know,
be
responsive
on
issues
and
and
things
like
that
on
it,
but
as
long
as
you
can
as
long
as
you
can
do
that,
then
I
don't
think
we'll
have
a
problem
great.
Thank
you.
A
Aaron
does
donated
code
need
to
be
modified
to
have
open
telemetry
authors
attribution.
You
know
that
is
an
excellent
question.
I
will
bring
that
up
at
the
governance
committee
meeting
this
week.
G
Maybe
if
amir's
donated
a
few
things
they
would,
they
would
know,
I
think,
for
when
google
donated
sql
commenter,
we
did
change
the
attribution
just
something
to
bring
up
with
your
legal
team
because
it's
you
know
maybe
a
few
steps
into
the
process
and
not
that
obvious
you
might
have
to
do
it.
A
Yeah,
I
think
that
the
historic
code
we
can
probably
keep
you
know
the
the
original
attribution,
but
certainly
moving
forward
code
is
usually
attributed
to
like
the
open,
telemetry
authors,
which
is
sort
of
a
a
broad
term
for
everybody
who
contributes.
A
A
A
One
of
the
concerns
that
was
brought
up
in
this
meeting
was
that
instrumentation
authors
felt
that
the
guidelines
were
a
little
bit
too
restrictive
when
it
came
to
attributes
that
are
not
in
the
semantic
conventions
and
stuff.
Like
that,
I
made
that
comment
on
the
issue
and
other
maintainers.
I
you
know,
gave
their
support
to
that.
They
felt
the
same
way.
So
this
is
something
that
they're
aware
of
the
specification
here
is
an
experimental
state.
A
So
I
I
believe
what
they
want
to
do
is
merge
this
pr,
as
is,
and
take
it
as
a
follow-up
to
carve
out
exceptions
for
packages
that
don't
have
or
for
instrumentations
that
don't
have
semantic
inventions,
but
that's
the
that's
the
current
status
on
that
anybody
that
is
interested
in
that
work
can
can
follow
along
in.
In
that
pull
request,
there
there's
been
quite
a
bit
more
discussion
mark.
I
know
you're
on
the
call,
if
you're
paying
attention,
would
you
like
to
talk
about
your
pr
here
or
is
there.
F
F
That
was
something
that
was
unfortunately
needed
since
we
had
this
like
circular
dependency
of
of
issues
or
stuff
that
was
working
progress
that
couldn't
move
forward
in
like
separate
prs.
So
we
had
to
bunch
it
up
all
together
into
one
yeah.
F
It
basically
removes
the
wip
the
work
in
progress
suffix
from
the
working
brokers,
packages
and
yeah
updates
a
lot
of
packages
which,
in
the
beginning,
only
included
the
the
otlp
exporters
but
then
started
also
including
like
some
instrumentation
packages,
because
there
were
bugs
in
the
newer
that
there
was
a
bug
that
was
introduced
in
the
newer,
newer,
stable
packages
and
yeah,
also
the
otlp
transformer
package
and
the
open
telemetry
sdk
node
package.
F
A
Okay-
and
I'm
sure
everybody
here
is
aware-
we've
been
talking
about
this
for
the
last
few
meetings
now
so
definitely
reviews
on
this
would
be
appreciated.
I'd
like
to
get
it
merged
soon,
because
it
is
very
large
and
touches
a
lot
of
files
that
other
prs
touch
and
the
longer
it
stays
open
the
more
difficult
it
is
to
keep
it
up
to
date
and
rebase
it,
and
things
like
that,
so
that
one
is
a
high
priority.
A
All
right,
the
next
item
I
have
here
is
a
a
pr
that
was
opened
as
a
part
of
a
feature
request.
This
user
wants
to
allow
span
names
to
be
customized
by
using
a
custom
reserved
attribute.
A
In
my
opinion,
this
is
not
really.
This
particular
implementation
is
not
really
in
line
with.
You
know
the
the
specification
of
attributes
and
the
way
that
they're
meant
to
be
used,
but
the
feature
request
itself
allowing
spam
names
to
be
customized
may
be
a
good
idea.
A
We've
seen
the
same
thing
before,
particularly
with
http
instrumentations,
if
you're
not
using
like
express
or
something
like
that,
to
give
you
a
better
path,
you
only
really
get
the
verb
which
is
sort
of
useless.
It
is
in
line
with
the
current
specification.
This
is
what
the
spec
tells
us
to
do,
but
if
a
user
wants
to
customize
their
name,
then
that
may
be
something
we
want
to
support.
A
I've
had
some
discussions
with
other
maintainers
and
with
some
specification
maintainers
about
this,
and
everybody
seems
to
kind
of
agree
that
this
is
a
problem,
but
nobody
really
has
a
great
solution
for
it.
Yet
so
I
don't
really
have
a
ton
to
say
about
this
other
than
to
bring
it
to
your
attention
in
term.
A
As
you
know,
a
feature
request
and
I
believe
there
is
actually
an
issue
for
the
feature
request
and
if
anybody
has
you
know,
ideas
on
on
ways
to
solve
this
that
are
more
in
line
with
the
spec
I'd
be
happy
to
hear
them
or
you
know,
comment
them
asynchronously
on
the
issue,
since
I
don't
think
the
person
that
opened
this
issue
is
here
but
yeah.
That's
just
please
take
a
look
at
that
on
your
own
time.
A
We
have,
I
just
copied
this
metrics
to
do
from
last
week.
I
put
I'm
working
on
this,
but
I
think
actually
mark
is
working
on
this.
That's
a
part
of
the
pr
that
he
was
or
a
follow-up
on
the
pr
that
he
was
just
talking
about
updating
the
the
otlp
of
metrics
exporters.
We
just
talked
about
that's
still
ongoing
refactoring
to
add
the
observable
registry.
I
believe
that
this
pr
has
actually
been.
A
Oh,
it's
a
draft.
Okay.
We
can
go
past
that
one.
Then
this
meter
shared
states.
Pr
is
still
open.
That's
this
one
here!
So
the
meter
identity
pr
depends
on
that.
So
the
meter
shared
states,
one
has
been
open
for
quite
a
while.
A
I
understand
that
it's
complex
and
that
the
the
metrics
sdk
in
general
is
complex
and
difficult
to
review,
but
it
is
blocking
other
prs.
So
getting
reviews
on
that
is
definitely
a
priority
at
this
time
and
then
aggregation
temporality
controls.
We've
had
no
no
movement
done
in
the
last
week,
but
that
is
still
to
do
this.
Sanitize
attribute
inputs,
pr
came
from
an
issue
that
was
opened
a
while
ago
about
circular
references
in
attributes.
A
A
There
is
also
a
bug
fix
that
was
opened
a
couple
of
days
ago.
The
content
length
header
was
causing
timeouts
with
the
otlp
http
exporters.
Svetlana.
Are
you
on
the
call?
Is
there
anything
you'd
like
to
say
about
this.
D
It's
pretty
much
ready
for
for
people
to
look
at.
I
know
there
was
one
approval
on
it,
but
if
anyone
has
any
kind
of
questions
or
feedback
that'd
be
great.
A
A
D
A
While
prepping
for
this
meeting,
I
noticed
that
the
timeout
pr
is
still
there
correct
me
if
I'm
wrong,
but
that's
blocked
on
something
else.
Right
now,
right.
D
Yes,
it's
blocked
because
we
have
two
learner
configuration
commands,
one
in
packages
and
one
in
experimental
and
my
pr
is
referencing
some
code
in
the
core
package
and
the
way
that
that
learn
is
set
up.
It's
not
actually
referencing
the
local
core
package.
Instead,
it's
referencing
the
latest
released
package,
which
is
a
problem.
A
Okay,
so
are
you
waiting
for
a
release
of
core
or
does
your
pr
actually
change
both.
D
It
changes
both
it
changes
core,
and
my
understanding
was
that
there
was
some
talk
about
a
pr,
possibly
the
one
that
you
talked
about
before
mark's
pr
that
that
was
also
going
to
fix
the
learner
commands.
A
It
will
not
fix
learning
commands,
but
it
will
I
mean
it
will
make.
It
will
fix
the
learn
of
commands
in
the
co
in
the
sense
that
they're
broken
right
now
and
and
don't
work
at
all.
It
will
not
link
together
the
experimental
and
the
stable
packages,
but
it
is
a
prerequisite
for
that.
I
think
so
once
that
pr
merges
my
plan
currently
is
to
you
know,
merge
the
packages
back
into
a
single
learn,
a
mono
repo,
like
we.
D
A
About
last
week,
there
are
some
advantages
to
having
them
separate,
but
I
think
the
pain
has
just
been
too
much,
so
I
I
believe
we,
the
plan,
is
to
to
go
back
to
a
single
learn,
a
mono
repo
for
those
packages
and
then
tooling,
to
ensure
that
the
versioning
for
the
stable
packages
stays
in
lockstep
and
the
versioning
for
the
experimental
packages
stays
in
lockstep.
If
that
makes
sense,.
D
Okay,
so
once
that's
done,
then
this
pr,
the
tests
are
gonna
pass
and,
and
it
just
has
to
be
looked
at
and
approved.
A
Okay,
yeah.
Obviously
I
can't
I
can't
say
that
that
will
happen
this
week
or
anything
like
that,
but
I
will
work
on
that
as
soon
as
I
can,
because
I
think
it's
that
particular
issue
is
causing
pain
for
a
lot
of
people
right
now.
So
I
think
it's
something
that
we
should
resolve
as
quickly
as
possible
and
I'm
also
going
to
work
on
release
automation
and
I
think
it'll
be
a
lot
easier
to
do
that
with
a
single
monorepo.
Also,
we
already
talked
about
the
meter
shared
states.
A
Pr
svetlana
looks
like
you
added
a
point
here.
Would
you
like
to.
D
Yeah
so
the
first
question:
the
order
of
preference.
So
when
someone
sets
up,
let's
say:
they're
setting
up
the
x
exporters
and
they're
they're,
trying
to
add
their
endpoint,
which
one
should
we
look
at
first?
Should
we
look
at
the
end
point
that
they've
added
to
the
config
file,
for
example
the
the
tracing
file,
or
do
we
look
at
the
the
env
variable
value.
A
If
there's
a
configuration
in
the
code,
then
that
should
override
the
configuration
variable.
I
think
the
the
the
order
of
precedence
would
be
code.
Then
the
environment
variable
than
any
default
value
or
implied.
D
A
A
I
I
don't
know
a
language
specific
thing,
or
maybe
it
was
too
far
along
or
too
too
deviated
by
language
to
specify,
but
that
may
have
changed
in
the
interim.
I
have
not
paid
that
much
attention
to
the
environment.
Variable
spec
beyond
the
you
know,
seeing
that
there
are
like
a
hundred
environment
variables
now,
so
it
probably
is
something
that
should
be
specified.
I
guess
I
I'm
just
not
familiar
with
the
spec.
I
don't
have
an
answer
for
you.
D
Yeah
I've
looked
at
it
and
I
haven't
seen
anything
so
far,
so
I
was
just
going
to
open
a
issue
about
it
in
the
in
the
spec.
A
Yeah
I
mean
ideally,
you
would
open
an
issue
in
the
spec
and
and
get
an
answer
from
them.
I
am
a
little
bit,
I'm
not
that
optimistic.
That
you'll
get
a
straightforward
answer,
but
I
think
that's
at
least
a
good
place
to
start,
and
if
you
don't
get
a
straightforward
answer
then
we
can.
We
can.
D
A
It
internally.
D
Other
issue,
I
just
wanted
to
get
some
feedback
from
others
that
I
may
know.
Basically
what
tyler
is
saying
here
that
the
spec
says
anytime,
you
set
the
end
point
that
doesn't
have
a
signal
in
it.
It
shouldn't
let
the
user
add
a
path
to
it
and
the
and
the
user
should
let
the
sdk
add
the
path.
D
So
I
kind
of
wanted
to
address
that
because
he
mentions
that
there
is
a
method
called
depend
resource
path
to
url,
if
not
present,
that
it
just
checks
to
see
if
there
is
a
path.
If
so,
don't
don't
do
anything
to
change
it,
otherwise
add
a
path
to
it.
So
again,
this
ties
back
to
the
spec
is
not
that
clear.
So
I
wanted
to
see
if
what
others
thought
about
this
issue.
A
This
is
because
we're
trying
to
to
be,
I
think,
a
little
bit
fancy
in
a
way
that
we
probably
shouldn't
have
so
we
we
look
at
the
url
and
we
append
the
path
if
it
doesn't
exist,
when
I
think
we
probably
should
have
just
taken
the
input
from
the
user
and
called
it
a
day,
because
while
the
spec
says
to
use
that
the
v1
traces
or
the
v1
metrics,
if
you're
setting
the
otlp
endpoint,
if
you
set
like
the
otlp
traces
endpoint,
then
I
think
we
should
use
it
directly.
A
Fortunately,
the
exporters
are
not
yet
released
as
1.0,
and
we
can
go
back
on
this.
It
might
cause
some
upgrade
pains
for
users,
though,
so
we
want
to
make
sure
that
we
document
it
really
clearly.
D
Yeah,
well
the
the
way
that
append
path,
if
it's
not
present,
that
that
doesn't
do
any
anything
wrong,
because
the
spec
says
to
add
the
path
to
the
end
point
when,
when
it's
not
a
signal
endpoint,
so
that's
correct,
except
we're
we're
just
doing
one
simple
check
that
says:
if
there
is
a
path
in
there,
don't
do
anything
to
change
it
and
just
re
return
that
url
and
what
tyler
was
saying
is
that
you
sh
you
shouldn't
even
be
checking
that
and
you
shouldn't
be
letting
users
set
their
path
if
they're,
using
an
endpoint
that
isn't
signal
specific.
H
A
B
A
Then
the
root
path
must
be
used
yeah.
So
if
it's
per
signal
we're
not
supposed
to
modify
it
if
it
is
so
yeah
if
we
currently
in
js,
if
you
set
otlp
exporter,
otlp
endpoint
and
you
have
v1
traces
on
there,
I
believe
we're
not
appending
like
we're
trying
to
do.
Detection
of
that
right.
D
Yeah-
and
I
think
what
tyler
is
saying,
is
that
that
endpoint
shouldn't
be
set
with
a
path,
so
we
shouldn't
even
be
checking
to
see
if
it
has
a
path,
we
should
just
append
the
path
blindly
and
if
the,
if
the
user
sets
the
wrong
end
point,
you
know
adding
a
path
to
to
that.
No
signal
specific
endpoint,
then
that's
the
user's
problem.
They
they
shouldn't,
be
adding
a
path
to
it,
because
it's
a
not
specific
signal.
Endpoint.
A
Yeah,
I
I
agree
with
with
tyler
here
in
the
speculation.
Second
example
is
the
opposite:
url
is
set,
v1
metrics
exporter
sends
to
metrics.
We
must.
A
Yes,
that's
the
signal
specific
yeah,
so
I
I
think
I
agree
with
tyler
here
that
we
should
sort
of
remove
that
detection,
and
you
know
it
does
make
it
possible
for
the
user
to
misconfigure
it,
but
it
also
makes
it
less
confusing
when
they're
trying
to
debug
their
issues.
But
honestly,
I
think
this
is
a
very
esoteric.
I
don't
know
how
he
even
found
this
issue
since
it
seems
like
you
know.
Obviously
he
probably
had
v1
traces
as
a
base
path
in
his
back
end
somehow
or
something
along
those
lines.
A
D
Okay,
I
could
I
could
take
on
netflix.
It
should
be
a
pretty
simple
fix.
A
Okay,
then,
I
will
assign
this
to
you,
and
that
is
good
timing,
because
we
are
out
of
time.
So
if
anyone
has
anything
quick
that
they
want
to
bring
up
now's
the
time
all
right,
otherwise,
I
will
talk
to
you
guys
next
week.
Thank
you
for
your
time.