►
From YouTube: 2023-01-09 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
Hey
everyone
welcome
back,
we'll
get
started
in
one
more
minute.
B
Foreign
welcome
back,
everybody
hope
everyone.
If
you
had
a
holiday,
that
it
was
good
and
fun
and
productive,
we're
gonna
get
started
with
the
regular
maintainers
and
and
regular
check-in
meeting
and
then
we'll
go
from
there,
so
starting
with
the
Sig
check-in.
So
for
the
spec,
we've
got
a
actual
release.
Pr
for
January
Carlos.
C
C
Yeah
sorry
about
that
yeah,
so
basically
I
think
that
a
lot
of
people
came
back
last
week.
So
my
plan
was
to
create
a
PR
for
this
big
release,
but
I
think
that
a
lot
of
people
were
still
on
holidays
and
hopefully
they
are
back
so
I
will
create
it
now
yeah.
So
hopefully
it
looks
great.
So
sorry
for
the
delay.
C
Yeah,
but
I
just
wanted
to
be
sure
that
it's
it's
safe
but
yeah.
Today
I
will
have
the
pr
oud,
okay,
cool.
B
No
updates
from
logs
or
or
product
or
PHP
for
Java
we
have
SDK
version
1.22.0
released
last
week
and
we'll
be
doing
the
same
for
job
instrumentation
and
you
have
a
contribute
for
JS.
We've
reduced
the
approval
requirement
to
one
following
the
lead
of
other
sigs
I.
Remember
that
conversation
from
late
last
year
and
we're
working
on
the
1.9.0
release
of
incremental
improvements
and
we're
working
on
high
resolution.
Histogram
support
based
on
Nico
and
Java
implementations,
cool,
no
updates
for
python
or
dotnet.
D
E
It's
it's
for
PR's
in
JS.
Actually,
if
you
look
at
the
community
repository
how
to
set
up
a
new
reboot,
it
actually
recommends
one
which
I
didn't
realize
until
I
was
working
on
this
I
think
most
PRS
that
are
impactful.
We
will
still
wait
for
more
than
one,
but
this
requirement
was
causing
a
lot
of
load
because
of
smaller
things.
You
know,
wording
changes
basic
fixes
that
you
know
don't
really
require
a
lot
of
eyes
on
them.
E
So
I
think
the
official
policy
in
JS
now
is
one,
but
I
still
expect
to
wait
for
two
to
three
on
more
impactful
changes.
Okay,.
B
Thank
you
all
right
for
python,
move,
no
updates
norfolk.net
for
go.
We've
released
0.35.0
for
metrics,
that's
68,
complete
both
SDK
and
API.
Changes
are
expected
in
the
next
release.
Meanwhile,
for
everything
else,
we're
on
version
1.12.0,
which
includes
an
update
for
semantic
conventions
for
the
go
folks
on
the
call
I'm
curious
like
do
we
have
a
I
guess,
an
ETA
or
like
just
a
vague
notion
of
what
the
flight
path
would
be
for
for
metrics.
D
For
metrics
yeah
I,
don't
know
about
an
ETA
I
think
that
there's
a
little
bit
more
instability
in
the
API
than
we
realized
and
that's
kind
of
changing
some
timelines.
A
little
bit
I
think
okay,
pushing
them
back
a
little
bit,
but
we
are
pretty
actively
trying
to
address
all
of
them.
So
I
I
think
that
once
we
have
this
release
that
we'll
have
a
little
bit
better
of
an
understanding
of
that
timeline,
I
think
I've
got
it.
D
Maybe
that
that's
a
fair
enough
answer,
yeah
I,
but
we
are
going
to
be
a
little
bit
more
confident,
I
think
in
the
API
compliance
with
the
specification.
So
that's
kind
of
the
plan
there.
Okay.
B
C
plus
plus
three
version
1.82
out
this
week.
This
includes
metrics,
post,
GA
fixes
and
other
build
improvements
coming
down
to
the
community
demo,
no
major
updates.
Since
the
break
resource
detection,
new
metrics
instrumentation
have
been
added
already
for
comms.
We
have
a
January
2023
release
that
includes
two
blog
posts
and
lots
of
new
documentation
for
PHP
and
use
a
working
group,
no
updates
there
and
then
for
functions
of
service.
This
is
new
I
feel
like
interesting,
we're
restarting
the
Lambda
work
group
to
the
generic
functions.
B
F
Yeah
I
can
give
a
quick
update,
so
we've
been
hearing
from
a
lot
of
our
end
users
and
customers
that
the
current
kind
of
Lambda
extension
implementations
are
inconsistent,
aren't
giving
them
the
information
they
need
and
hard
to
set
up,
and
so
I
talked
to
some
other
vendors,
awf,
Blanc,
Cisco
and
I.
Think
honeycomb
as
well,
and
we
all
agreed
that
you
know
this
area
I
needed
a
bit
more
attention
on
the
current
Lambda
repo
didn't
have
ownership
and
wasn't
being
really
kept
up
to
date.
F
F
B
D
Yeah
thanks
so
in
the
process
of
validating
the
API.
One
of
the
things
that
we've
identified
in
the
ghost
said
was
that
the
global
meter,
API
or
meter
provider
API,
is
under
defined
and
that
it
isn't
really
well
defined.
Just
says
like
that.
Something
needs
to
exist,
but
the
behavior.
What
we're
finding
in
in
doing
a
little
bit
of
a
deep
dive
into
this
is
different
based
on
the
language
things
and
so
I've
gone
and
I
think
understood
a
little
bit.
D
Some
of
the
differences
that
the
language
things
have
and
and
the
hopes
of
trying
to
provide
a
unified
API.
Here,
it's
maybe
retroactively
specifying
this
is
the
goal.
So
one
of
the
key
things
is
like
if
you're
a
maintainer
here,
please
go,
take
a
look
at
this
and
read
it,
and
if
you
see
that
your
language
is
not
mentioned,
add
what
it
does
and
if
it
is
mentioned
and
it's
incorrect
try
to
fix
it.
G
D
B
All
right,
moving
down,
Ted
I
added
you
here
as
well,
looks
like
you
added
some
content
so
for
everyone's
context,
like
we,
we
there's
a
PR
road
map
for
open
Telemetry
that
we
discussed
previously
in
December
and
Ted
and
I
met
late
last
year
to
talk
about
other
improvements,
we
can
make
to
be
projects
overall,
sort
of
Direction,
not
changing
the
direction,
but
just
making
it
more
clear
and
concise
and
and
better
spread
out
across
all
the
teams.
B
So
everybody
understands
what
we're
all
working
towards,
as
well
as
just
general
project
management
improvements
that
we
can
make
Ted.
Do
you
want
to
take
it
from
here?
Yeah.
H
Totally
so
I
put
together
a
little
dock,
you
can
hop
over
to
that
or
I
can
share
my
screen
either
way.
Just
to
just
like
briefly
paraphrase.
What's
going
on
here,
like
what
Morgan
said,
we
did
a
good
recap
with
the
community
and
based
on
that
and
based
on
my
experience
with
the
the
current
working
groups
and
getting
feedback
from
them.
We
identified
just
like
a
couple
ways
that
we
could
improve
our
current
spec
process
and
you
know.
H
Basically,
we
have
a
bunch
of
open
issues
right,
there's
currently
36
open,
oteps
and
549
open
spec
issues,
which
is
not
weird
for
big,
open
source
project.
You
go
to
most
open
source
projects
and
there's
just
a
huge
pile
of
open
issues,
but
because
our
attention
is
spread
very
thin.
H
We've
noticed,
we
have
a
pile
of
things
that
we
know
we
want,
but
they're
tricky
enough,
that
I
think
as
a
community,
especially
as
like
a
spec
Community.
We
need
to
kind
of
focus
our
attention
on
them
to
actually
work
out.
H
The
details
and
those
issues
just
tend
to
stall
and
the
working
groups
that
we
spin
up
for
the
spec
have
a
tendency
to
get
really
deep
into
their
work
and
then,
when
they
try
to
get
their
work
actually
pushed
through
the
spec
that
can
be
slow
and
difficult
for
them,
because
there's
like
a
bit
of
a
disconnect
between
when
that
group
gets
more
attention
from
TC
members
or
the
rest
of
the
spec
Community.
H
So
they
don't
get
a
lot
of
attention
when
they're
working
on
it
and
then
when
they
show
up
with
all
their
proposals,
it's
usually
kind
of
a
surprise
to
everybody
else,
and
so
that
all
of
these
things
just
add
up
to
stuff
being
a
little
slow,
which
is
the
feedback
we
get
from.
Our
community
seems
slow
to
get
anything
pushed
through
the
spec,
but
we've
been
doing
a
lot
of
work
to
to
clean
this
up
that
we'd
like
to
kick
off
this
year.
H
The
start
of
that
Morgan
did
a
great
job,
putting
together
a
strategic
road
map
which
is
I,
think
the
the
guide
star
so
we're
going
to
go
through
and
try
to
prioritize
our
work,
and
in
order
to
do
that
prioritization
we
need
to
know
what
the
community
cares
about.
So
Morgan
did
a
great
job
of
pulling
the
community
and
condensing
that
down.
H
So
I,
don't
know
if
you
want
to
pop
over
to
that,
but
just
let
people
know
that
roadmap
is
available,
we're
going
to
publish
it
in
the
community
repo,
so
really
encourage
people
to
to
look
over
this
roadmap
doc.
I,
don't
know
if
you
want
to
hit
on
the
there's
like
the.
H
Great,
so
that's
great,
but
we
then
need
to
go
a
level
deeper,
which
is
we
have
to
actually
connect
that
to
our
backlog,
and
so
that's
where
it
comes
into
issue
prioritization.
H
So
we
started
to
develop
a
project
management
process.
We
haven't
been
using
it
a
lot
and,
with
this
year,
kicking
off
I
want
us
to
use
the
time
we
have
in
this
meeting,
as
kind
of
a
place
to
start
triaging
all
of
our
existing
work
and
seeing
if
we
can
get
it
slotted
in
to
this
process,
it's
a
very
basic
process.
H
At
the
moment
we
have
a
project
board
where
we
can
list
all
of
the
different
projects
that
we
want
to
work
on
and
then
identify
which
ones
we're
actively
working
on
and
and
then
try
to
find
a
middle
ground
of
scheduling.
H
The
next
set
of
projects
I
think
that
level
of
project
management
would
be
enough
for
us
just
knowing
what
are
the
projects
that,
as
a
community,
are
a
priority
to
us
as
opposed
to
just
the
stuff,
that's
showing
up
in
the
backlog,
all
the
time
being
able
to
say
we
know
these
things
are
a
priority.
We
know
what
we're
currently
working
on
and
we
know
what
we'd
like
to
work
on
next,
once
we're
done
with
our
current
projects.
H
Some
of
these
are
like
big
projects
with,
like
a
working
group,
that's
actively
meeting
to
try
to
solve
them,
but
then
we
also
have
a
pile
of
oteps
that
are
just
one-off
oteps,
that
we
know
we
care
about,
or
at
least
I
think
we
care
about,
but
they're
kind
of
stalled,
and
we
want
to
get
those
kind
of
into
the
mix
as
well.
So
we
can
start
processing
them.
H
As
a
corollary
to
this,
we
need
more
working
group
participation
from
core
open
Telemetry
members,
in
particular,
we'd
like
to
see
at
least
two
TC
members
participating
in
any
working
group,
but
I
would
like
to
also
open
that
in
general
to
the
the
rest
of
the
core
Community,
as
we've
moved
out
of
the
realm
of
distributed
tracing
more
and
more
of
the
new
work
is
work
that
had
the
basically
new
members
and
outside
members
or
the
subject
matter.
Experts
so
like
the
rum
client
stuff
is
a
good
example
right.
H
We've
got
a
bunch
of
client,
Telemetry
rum
people
who
are
experts
in
that,
but
they're
new
to
open
Telemetry,
and
so
it
I
found
that
these
working
groups
work
a
lot
better.
If
there's
at
least
some
people
in
them
who
are
open,
Telemetry
insiders,
you
might
say
you
don't
have
to
be
subject
matter
experts,
but
it's
helpful
to
communicate
to
the
subject
matter.
Experts,
open,
telemetry's,
existing
architecture
and
kind
of
help
them
figure
out
how
to
work
their
project
into
the
stuff
that
we
already
have
so
I.
H
Think
it's
critical
that
TC
members
be
there,
but
you
know
for
the
rest
of
us
who
care
about.
You
know
the
open,
Telemetry
moving
forwards.
Being
able
to
kind
of
keep
track
of
these
working
groups
would
be
helpful.
H
So
that's
the
basic
pitch
we've
got
Carter
Socha
on
the
phone
who
I
think
you
just
met,
he's
a
product
manager
at
lightstep
and
he's
very
generously
generously
decided
to
donate
some
of
his
time
on
a
regular
basis
to
help
us
do
this.
Project
management
and
we've
got
a
lot
of
time
left
on
this
call.
So
when
we
finish
up
with
whatever
else,
we
want
to
talk
about,
I
think
it
would
be
great
to
maybe
start
triaging
some
of
these
oteps
and
walking
through
this.
B
H
D
H
D
Yes,
we
do,
okay,
because
I
think
that
that's
going
to
be
key
is
well.
Maybe
it's
also
you're
asking
in
this
meeting,
specifically
for
the
maintainer
buy-in
as
well,
but
like
you're,
saying
people
with
history
here,
I
think
it
you're
pointing
out
that
they're
going
to
be
the
the
main
ones
right
or
are
you
asking
us.
H
The
so
the
the
TC
is
are
the
spec
maintainers.
That's
essentially
what
it
means
to
be
a
TC
member.
So
yes,
they
they
have
to
do
it.
They
have
a
TC
meeting,
that's
just
with
them,
and
I've
been
talking
with
the
TC
through,
like
the
governance
committee,
TC
channels
and
so
they're
they're
bought
into
this
this
process.
The
main
thing
they've
requested
is
like
they
want
help.
Organizing
the
project
management,
they're,
they're
glad
to
you
know,
participate
in
this
whole
thing,
but
they
felt
like
they
needed
help.
H
Actually
you
know
getting
it
all
organized
and
since
I
don't
want
to
add
another
meeting
to
the
calendar.
I
was
thinking
since
this
meeting
has
a
lot
of
the
right
people
in
it.
It
would
be
good
to
use
this
as
kind
of
like
a
triage
meeting
where
we
go
over
this
stuff,
because
the
spec
meeting
on
Tuesday.
We
really
need
to
spend
that
time
actually
like
talking
about
spec
issues.
E
Yeah
so
a
couple
of
things:
I
guess
you
addressed
one
of
my
comments
at
the
at
the
last
second,
there
I
was
gonna
say:
is
this
the
right
meeting
to
triage
these
projects
and
is
the
specification
a
better
form
for
that?
But
my
bigger
concern
is:
if
you
want
two
TC
members
in
each
of
these
working
groups,
it
seems
like
you're
very
quickly,
going
to
run
up
on
a
bottleneck
right
now.
E
There
is
no
obvious
path
to
become
a
TC
member
or
expand
the
TC,
so
I
think
a
prerequisite
to
this
whole
process
is
a
way
to
expand
the
pool
of
people
who
can
effectively
Steward
projects,
whether
that's
adding
a
new
project,
Steward
role
or
a
obvious
path
for
expansion
of
the
TC
I,
don't
see
two
two
members
of
the
TC
joining
every
working
group
being
a
scalable
solution,
Beyond,
two
or
three
working
groups.
Maybe
four.
H
I
I,
totally
agree
and
I
think
part
of
it.
Part
of
what
I'm
hoping
to
do
here
is
actually
expose
our
bottlenecks
and
be
be
conscious
about
them,
because
the
side
effect
is
like
by
not
having
project
management.
That
bottleneck
still
exists.
Essentially,
when
these
working
groups
try
to
get
their
stuff
approved.
You
know,
and
you
need
like
for
approvals
and
all
of
that.
H
It's
we.
We
already
have
that
bottleneck
essentially,
but
we
aren't.
We
aren't
being
conscious
about
it
and
like
picking
which
of
the
projects
we
want
to
focus
on,
and
so
my
hope
is.
We
can
start
with
that
figure
out
what
our
actual
level
of
concurrency
and
throughput
is
and
I
completely
agree.
I
think
that
makes
it
more
clear
why
we
would
add
more
TC
members,
what
kind
of
TC
members
we're
looking
for
like
what
areas
of
expertise
do
we
need
people
to
have
that
kind
of
thing.
G
E
Josh
also
just
put
in
the
chat
here
that
maybe
rotation
of
TC
membership
should
be
discussed.
I
think
that's
also
a
valid
concern,
but
at
my
primary
concern,
right
now
is
with
the
expansion
of
the
body
of
people
who
can
effectively
Steward
projects,
whether
it's
TC
or
otherwise,
but
yeah.
That's,
that's
all
I
really
had
to
say
about
it.
I
think
in
general,
whatever
of
the
proposals
seem
solid,
I
just
worry
about
that
bottleneck
and
I
I
wanted
to
make
it
clear
that
I
view
it
as
a
blocking
prerequisite.
I
I
The
same
thing,
you
know
you
called
out
that
you
know
there's
not
much
expertise
in
some
of
these
newer
signal
types.
You
know
profiling
or
events
that
we're
working
on
on
the
TC
I
mean
the
TC
hasn't
changed
composition
since
I.
Think
Riley
was
the
most
recent
member
added
around
the
time
while
the
metrics
work.
So
it's
been
about
a
year
since
we've
had
changed
there.
H
Yes
and
we
get
actually
feedback
from
the
TC
and
the
approvers
around
when
some
of
these
things
get
stalled.
People
are
saying,
like
I,
don't
have
expertise
in
this
area,
so
I
don't
feel
comfortable
hitting
the
approve
button,
which
is
the
correct
response
right.
We
don't
want
people
rubber,
stamping
things,
but
it
also
means
we
can't
move
forward
until
we
we
get
that
expertise
so
yeah.
E
I,
don't
think
the
TC
has
to
be
experts
in
everything,
but
I
guess.
One
micro
problem
we
have
is
that
PR's
in
the
spec
don't
get
merged
unless
they
have
approvals
from
TC
members,
and
maybe
that
is
a
flawed
premise
on
its
own.
Maybe
the
TC
is
not,
should
not
be
approving
every
single
PR,
but
should
be
finding
the
correct
people
who
should
be
approving
them
and
determining
when
there
are
enough
subject
matter.
Experts
that
have
weighed
in
yeah.
E
H
It's
not
that
the
TC
members
who
joined
that
working
group
need
to
be
subject
matter,
experts
for
that
working
group,
but
if
they
participate,
the
goal
of
that
participation
is
that
they
become
familiar
enough
with
that
domain,
that
they
can
actually
work
with
the
subject
matter,
experts
to
get
things
approved
and
when
that
working
group
kind
of
works
alone
and
then
like
brings
their
proposals,
you
know
to
the
backlog
as
like
oteps
it's
because
the
TC
and
spec
approvers
don't
have
any.
They
haven't
built
up
any
state
along
with
that
working
group.
H
H
But
we'll
also
have
to
see
so
my
hope
is
by
by
being
just
more
conscious
about
this
I'm,
definitely
not
proposing
that
we
have
a
process
totally
worked
out
and
that
we
have
all
the
answers
but
I
think
by
spending.
You
know
this
quarter
really
trying
to
put
this
together
is
going
to
kind
of
flush
out
a
lot
of
these
issues
that
we've
kind
of
known
that
we've
had,
but
it
will
I'm
hoping
to
just
create
a
process
for
us
to.
Actually
you
know,
process
them
essentially.
J
Alex
yeah
I
just
wanted
to
add
a
quick
note
on
the
the
thought
around
expanding
the
TC
I.
Think
one
thing
to
keep
in
mind
is
that
the
TC
won't
be
the
only
bottleneck
as
if
we
decided
to
you
know,
grow
to
TT
to
Triple
its
size
and
we
were
doing
14
different
working
groups
in
parallel.
The
bottlenecks
would
then
be
moved
to
the
different
project
implementations
who
couldn't
keep
up
with
just
the
sheer
volume
of
things
that
would
be
implemented.
J
B
Like
like
to
be
clear
like
it's
not
saying,
we
can't
do
other
things,
but
it's
more
like
the
core
Focus
the
project
and
thus
the
TC's
time
and
like
like.
If
people
don't
know
what
they
want
to
work
on,
like
the
the
core
things
we're
going
to
work
on
are
these,
and
that
should
help
the
TC
and
other
groups
who
might
be
bottlenecking
things
prioritize
what
the
focus
should
be.
I
E
I
mean
to
clarify
that
I
was
not
necessarily
calling
for
the
expansion
of
the
TC
either.
Just
if
we're
going
to
have
these
sort
of
project
stewards,
maybe
we
should
consider
that
they
don't
necessarily
need
to
be
TC
members,
maybe
there's
another
role
that
could
be
created
for
that.
H
It
might
be
possible
to
have
I
think
that
other
role
is
spec
approver,
essentially
I
I
feel
like
we
can't
separate
the
project
Steward,
like
the
people
participating
in
these
working
groups
from
the
people
who
have
to
approve
this
stuff
in
the
backlog,
because
that's
that's
kind
of
like
the
prob.
One
of
the
problems
we
have
right
now
is
there
is
this
separation
between
the
people
who
approve
stuff
and
the
people
who
are
participating
in
the
the
working
group?
H
So
I
don't
think
it's
it's
actually
possible
to
kind
of
hand
that
responsibility
off,
because
it's
more
about
building
up
the
state
in
the
minds
of
the
people
who
are
responsible
for
you
know,
keeping
our
spec
coherent
and
moving
forwards.
They
have
to
understand
what
all
the
proposals
are
and
kind
of
be
part
of
the
process
and
I
completely
agree
that
this
is
going
to
limit
how
many
things
we
can
do
at
once,
which
is
a
good
thing.
H
I
mean
that
limit
exists,
anyways,
but
I
think
it
will
also
help
for
the
projects
that
we're
explicitly
choosing
not
to
work
on
at
a
moment.
I
think
it
will
help
people
who
want
those
things
to
feel
better
as
well,
because,
instead
of
just,
why
is
no
one?
Responding
to
my
my
Otep
or
my
issue,
they're
able
to
to
get
a
clear
response
of
this
is
like
this
is
our
current
roadmap.
This
is
how
much
we
feel
like
we
can
deal
with
at
the
moment,
and
you
know
we'll,
hopefully,
work
on
your
thing.
B
H
I
think
I
think
it
might
be
good,
so
I
can
start
sharing
my
screen
here
so
got
so
much
soon.
Chrome
go
away.
Zoom
crown
I
got
one
sir,
get
this
onto
my
other
monitor.
Okay,
now
I
can
see
Okay.
So
this
is
our
road
map.
People
are
kind
of
familiar
with
this.
H
These
are
the
oteps
that
we
have
opened.
We've
got
36
of
them
a
huge
pile
of
issues.
We've
created
a
concept
called
a
project
tracking
issue.
So
if
we
go
to.
J
H
So
I
believe
for
every
working
group
we
currently
have
open.
We
have
an
issue
describing
that
working
group
what
the
heck
it
is
they're
doing
if
they've
got
a
project
board
for
managing
their
pile
of
issues.
What
they're
going
to
try
to
deliver
who
the
heck
is
working
on
it?
H
Do
we
have
TC
members
involved
so,
for
example,
Lambda
has
Carlos
from
the
TC,
but
it
would
be
great
to
get
another
TC
member
when
are
they
meeting,
etc,
etc?
And
all
of
these
are
on
a
project
board.
H
So
these
are
all
our
active
current
projects
so
for
these
these
things
are
coming
along
and
the
main
thing
here
actually
is
to
get
TC
members
involved
in
all
of
them.
In
particular,
client
instrumentation
needs
to
have
two
TC
members,
I
think
tigrin
has
offered
to
join
this
working
group,
but
he's
been
on
vacation,
so
I
don't
actually
know,
but
we
do
need
another
TC
member
and
in
general,
there's
some
tricky
issues
that
have
come
up
as
part
of
client
instrumentation
relating
to
logging.
H
So
having
an
events,
model
turned
out
to
be
this
complex
issue
that
we
have
to
think
through
and
the
other
complexity
is,
it
turns
out.
Clients
have
resource
like
attributes
around
things
like
session
ID
and
time
zone
and
whether
the
user
is
logged
in
that
are
really
important
pieces
of
information
to
attach
to
all
the
data
coming
out
of
that
client.
H
Currently,
resources
are
the
set
of
attributes
that
we
attach
to
all
the
data
coming
out
of
a
process,
but
resources
are
mutable,
and
these
these
things
are
actually
mutable
right
session,
IDs
change
over
time,
mobile
clients
go
to
sleep
and
they
wake
up
and
they're
in
a
different
time
zone
and
because
we've
said,
resources
are
immutable
because
we
were
thinking
more
about
server-side
stuff
that
turns
out
to
be
a
tricky
wicket.
H
So
those
are
two
examples
like
events-
and
you
know
what
I've
been
calling
ephemeral
resources
where
this
working
group
hasn't
been
able
to
make
process
progress
and
get
over
the
Finish
Line,
because
they've
got
some
tricky
stuff
that
actually
requires
the
rest
of
us
to
kind
of
pay
attention
to
them.
So
we
can
once
we
get
some
TC
members
involved
with
this
working
group.
H
We
can
kind
of
come
back
and
figure
out
how
we're
going
to
tackle
those
those
tricky
problems
but
I,
don't
think
we'll
be
able
to
get
over
the
Finish
Line
unless,
like
we
actually
concentrate
at
least
enough
of
us,
concentrate
on
solving
the
various
issues
with
adding
something
like
that
to
open
telemetry
I've
put
a
couple
of
individual
oteps
on
here.
That
I
know
are
things
we
want
to
work
on
that
won't
get
over
the
Finish
Line.
Unless
we
concentrate
on
them,
one
is
a
columnar
encoding.
H
So
this
is
a
new
protocol
for
The
Collector,
that's
much
much
more
compressed
than
our
current
protocol.
I
know.
This
is
something
that
Josh
has
been
working
on
and
is
excited
about,
but
we'll
have
to
get
this
more
organized
in
order
to
get
it
over
the
Finish
Line
I,
don't
know
if
we
can
work
on
it
right
now,
I
don't
know
if
we
have
enough
bandwidth
to
work
on
this
and
that's
one
of
the
things
I
want
to
figure
out.
Another
tricky
thing
is
elastic
comment
schema.
E
A
H
So
that's
another
thing:
that's
on
this
backlog,
so
for
the
rest
of
our
time
here,
I
kind
of
like
to
just
start
going
through
these
oteps
and
figuring
out
just
kind
of
getting
a
sense
of
them.
Putting
them
onto
the
project
board
and
I
would
also
like
to
start
getting
feedback
from
you
all
about
how
we
can
actually
improve
this.
H
We
can
figure
out
next
steps,
but
I
think
the
first
step
is
to
figure
out
which
of
these
things
in
here
map
onto
our
roadmap
as
like
priority
items
and
which
of
these
things
in
here.
Don't
map
onto
that
roadmap
and
to
also
identify
things
here
where
we
know
we
really
want
to
do
this.
We
know
this
is
important.
H
For
example,
there's
some
things
in
here
that
are,
we
have
some
holes
in
our
tracing
model
and
I
believe
there's
some
oteps
in
here
wanting
to
address
those
holes,
and
you
know
we
know
we
need
to
deal
with
that,
but
we
don't
know
when
so
I
was
thinking.
We
would
just
go
through
these
things.
Next,.
K
C
By
the
way,
sorry
for
interrupting
I
think
I
mentioned
last
week
that
there's
a
discussion
happening
that
you
see
I
know
you
know
that
Tigger
and
Riley
and
worked
on
having
on
holidays,
but
the
plan
is
that
we
actually
first
of
all,
make
your
tips
repo
part
of
the
specification
repo.
So
hopefully
more
people
pay
attention
to
that.
But,
more
importantly,
we
want
to
reduce
the
number
of
active
attempts
at
a
time.
So
basically
it's
like
we
either.
You
know,
make
progress
or
say
you
know.
C
We
won't
work
on
this
at
this
time,
and
this
is
this
goes
in
a
list
of
potential
projects,
but
they
won't
exist
as
an
active
attack
and
there
was
a
mention
of
maybe
having
five,
which
I
don't
know
whether
it's
I'm
not
enough
of
a
pool
or
actually
would
be
great.
So
so,
basically,
one
of
the
things
is
that
we
were
trying
to
discuss
water
depths
could
be
the
ones
that
are
most
important
at
this
very
moment.
For
example,.
H
Yeah
yeah
I
think
that's
that's
great.
That's
kind
of
what
I
would
like
to
figure
out
as
well
I
think
as
a
first
step.
I
would
like
to
maybe
just
go
through
these
and
because
anyone
in
the
community
can
make
an
Otep
yeah,
but
I
think
some
of
these
are
things
that
we're
either
working
on
or
we
know
we
want
to
get
done
in
some
way
and
I'd
like
to
just
start
by
maybe
tacking
those
things
on
here
as
potential
projects.
H
B
B
H
Them
on
here
do
we
want
to
go
ahead
and
do
that
maybe
I
don't
think
we
have
P0
P1
P2.
Let's.
B
B
B
Yeah
so
like
well,
a
label
for
the
priority
and
the
and
the
topic
yeah
great
and
I'm,
just
looking
for
the
labels
that
we
used,
let's
see
if
I
can
find
one
if
we
care.
So
if
we
want
to
reuse
just
the
priority
labels
which
we
might
not,
it
was
priority.
Colon
p
number
like
priority
colon
P1
priority,
colon
P2,
okay,
okay,
so.
A
H
Great
and
then
on
a
roadmap,
we
have
what
continued
investment.
This
isn't.
H
Logs
semantic
convention
rum,
profiling
demo-
this
is
almost
like
associating
them
with
a
working
group.
Yes,
maybe
we
can
hold
off
on
that
because
for
the
stuff
that
isn't
a
working
group,
for
example,
if
you
go
look
at
this
guy
firmware
resources,
because
this
working
group
has.
C
H
Project
board:
you
can
see
it's
part
of
the
realm
group
and
you
can
pop
over
here
and
you
can
see
everything
that
group
is
up
to
so
for
stuff.
That's
already
in
progress.
I
find
this
is
helpful
to
understand,
but
maybe
we
do
need
a
ROM
label
over
here
just
to
make
it
easier
to
to
sort
by
these.
So
let's
add
it
set
a
new
label
so.
H
H
So
let's
look
at
this
from
the
top:
a
proposal
for
CI
CD
observability
support
by
open
telemetry
if
anyone
is
on
the
call
who's
familiar
with
any
of
these
by
the
way,
if
just
like
quickly
pop
in
when
we
get
to
that
one.
So
anyone
familiar
with
this,
where
this
proposal
is
coming
from
I.
B
H
I,
imagine
that
this
the
focus
here
is
like
semantic
conventions
for
CI
CD
yeah.
That's.
H
Cicd
is
super
cool,
but
it's
super
duper
not
on
our
roadmap
right
now,
so
I'm
gonna
pass
on
putting
that
one
on
to
our
priority
list.
Yes,.
H
H
And
then,
as
far
as
priority
goes,
this
is
a
working
group.
We've
already
kicked
off
right,
so
it's
essentially
P0
I,
don't
know
if
we
want
to
reflect
it
that
way,
but
I
feel
like
for
all
the
working
groups
we
currently
have,
in
other
words,
the
work
we
have
committed
to
getting
done
for
better
or
worse.
You
know
this.
This
is
the
stuff
that
we
have
said.
We
are
going
to
finish
these
things
in
parallel,
because
we've
already
started
them.
H
B
A
H
D
I
think
that's
a
good
point
Ted.
That
I
think
you
do
need
to
have
some
sort
of
way
to
Signal.
Anything.
That's
actively
at
work
in
progress
is
a
P0
because
to
your
earlier
point
about
showing
bottlenecks
or
even
like
bandwidth,
we
need
to
be
able
to
track
that
so
I
think
that's
a
that's
an
important
thing
for
all
the
existing
projects
that
are
asserted.
H
Extending
Trace
functionality
to
support
payload
collection,
so
I
believe
this
is
related
to
the
big.
This
is
not
really
just
the
client
working
group,
but
I
know
what
is
being
asked
here
is
being
able
to
collect,
like
the
body
of
say,
HTTP
requests
right.
So
when
we
record
an
HTTP
request
being
able
to
actually
record
the
content
of
that
HTTP
request,
I
can
see
why
that
is
useful
and
I
can
see
why
that
is
super
dangerous.
As
far
as
loading
the
the
size
of
telemetry
coming
out
of
a
system.
B
H
Very
useful,
so
this
is
not
something
we
can
just
push
a
button
and
be
like
that's
great
and
I.
Don't
think
this
is
on
our
roadmap.
Currently.
G
For
what
it's
worth,
this
is
a
very
popular
user
request,
but
I
agree
it
doesn't.
It
should
be
lower
priority
than
the
things
that
we
have
in
Flight
already
great.
A
K
Yeah
I
think
I
added
a
comment
in
there
as
well,
linking
this
to
effectively
an
event
based
on
the
cloud
of
its
definition.
So
it
would
actually
be
a
log
event,
not
a
trace
record.
H
But
but
long
story
short
I,
don't
I,
don't
think
this
is
something
we
can
wade
into
without
agreeing
as
a
community.
We're
gonna
tackle
it,
because
it's
gonna
need
a
lot
of
thought
and
it
would
be
better
to
do
that.
Thought
like
coherently
and
quickly,
rather
than
smeared
out
forever.
So
I'm
just
gonna
pass
on
prioritizing
this
right
now,
because
it's
it's
not
currently
on
our
roadmap,
which
may
be
wrong.
H
H
Not
really
there's
stuff
like
this
and
various
other
things
in
here
that
we
know
we
want,
but
I'm
just
going
to
pass
on
those.
For
now
add
sampling,
Sig
research
notes.
H
H
Does
anyone
remember
how
to
mark
Marco
Pierre's
draft.
E
Of
a
reviewers
I
meant
yeah,
there.
H
H
Great,
this
is
draft
moving
on
app
name,
spacing
semantic
convention.
Well,
we
know
semantic
conventions
are
important
for
manual
instrumentation
by
suggesting
name
spacing
as
a
means
to
organize
data
with
the
app
prefix.
H
Was
this
I
recall
this
stuff
coming
up
in
the
client
Sig
around
a
weird
naming
convention
where
they
call
their
services
apps
and
we
call
our
services
services
and
they
don't
like
to
call
client-side
Services
Services,
because
it
was
weird,
but
nevertheless,
service
name
is
kind
of
what
they're
stuck
with.
H
No
okay,
so
this
is
more
about
a
way
to
name
space
things
that
are
not
coming
out
of
the
instrumentation
we
install,
but
instrumentation
application
developers
are
writing.
L
I
I'm
not
sure
if
this
directly
relates
I
haven't
read
the
whole
thing
yet,
but
there's
also
the
issue
of
like
say
a
particular
Library
database.
Library
name
named
Ecto
has
specific
metrics
that
it
wants
to
report
like
what
order,
in
the
naming
name
spacing
for
specific
app
names
versus
the
semantic
conventions
where
they're
all
the
same
that
hasn't
been
defined.
Yet
I
was
thinking.
This
was
related
to
that,
but
maybe
not.
K
Yeah,
it's
probably
related
to
from
a
client
perspective
if
you
want
a
location
for
an
application
or
a
library
or
whatever,
to
include
their
own
custom
definitions
which
so
that
they'll
flows
through
to
the
back
end
and
from
an
open,
Telemetry
perspective.
We
just
need
to
define
the
location,
not
the
actual
Hispanic
convictions
for
everything.
I.
K
It
includes
the
application
so
so
that
one's
talking
specifically
about
the
app
namespace
like
it
Microsoft,
we
I
have
a
bunch
of
internal
teams
that
have
they
collect
their
own
set
of
data,
and
they
want
someone
to
put
that
so
that
it
flows
through
to
the
back
end.
H
Okay,
I'm
going
to
label
it
semantic
convention
for
now,
but
avoid
prioritizing
it
because
it
our
our
priority
that
we
Define
semantic
conventions.
It
was
about
stabilizing
the
conventions
we
have
for
the
instrumentation
we're
providing-
and
this
is
more
about
how
do
we
extend
our
semantic
conventions
to
help
organize
application.
H
Who
are
writing
their
own
semantic
conventions,
so
that
seems
like
a
little
bit
different
than
what
we
meant
as
a
priority,
so
I'm
just
going
to
pump
ephemeral
resource
attributes
this
one's
mine,
I
I,
have
Let
It
Go
fallow
because
it
is
impossible
to
get
this
one
pushed
over
the
Finish
Line
until
I
get
a
coherent
number
of
TC
members
to
both
understand
what
the
heck
it
is.
We
are.
H
Are
immutable
but
the
way
you
use
these
things
is
the
same
way.
You
would
use
a
resource
and
there's
a
related
issue
around
being
able
to
have
a
subset
of
resources,
be
the
ones
that
are
the
identifier
resources
versus
just
some
other
resources
that
you
tacked
on.
H
That's
the
thing
I
know:
Josh
serith
cares
a
lot
about,
and
this
feels
related
to
that
anyways
I'm,
going
to
put
it
area,
clients
and
I'm
going
to
label
it
Priority
P0,
because
this
is
part
of
an
active
working
group
and
networking
groups
blocked
until
we
we
figured
either
accept
this
Otep
or
replace
it
with
something
better.
H
So
this
is
about
the
fact
that
we
have
span
level
attributes,
but
we
don't
have
anything
broader
than
a
span
level
attribute
in
tracing
and
that
today
causes
end
users
to
abuse
baggage
by
if
they
want
an
attribute
to
be
applied
at
like
a
trace
level
or
at
like
a
service
level
or
something
they
take
that
and
they
put
it
in
the
baggage
and
they
have
like
a
span
processor
that
then
tax
the
baggage
on
as
a
span
attribute
onto
every
span,
which
works
in
a
very
hackish
way,
but
then
also
like
bloats
your
messages,
because
you're
you're
putting
things
in
baggage,
not
because
you
wanted
to
use
it
as
baggage,
but
because
you
wanted
your
back
end
to
like
know
about
these
attributes.
H
Great
I'm,
a
fan
of
it
too.
This
is
like
a
hole
that
we
have
yeah
but
like
again,
though,
this
is
like
totally
100
something
we
can't
solve
unless
we
we
look
at
it
as
a
group,
because
I
don't
think
we
should
be
Cavalier
about
packing
things
on
toward
tracing
model.
At
the
same
time,
this
is
not
something
that's
like
on
our
our
roadmap
of
things.
To
do
so,
I'm
curious.
Do
people
have
thoughts
about
how
they
want
to
go
ahead
with
something
like
this?
H
Comes
up
a
lot
right
like
like
I,
have
heard
from
end
users
quite
a
bit
about
this
particular
thing,
going
all
the
way
back
to
the
open
tracing
days.
This
is
a
thing.
That's
been
around
forever
and
I
know
datadog,
for
example,
has
Trace
attributes
or
something
like
it.
So
there
are
other
tracing
systems.
We
could
look
at
that
have
a
solution
for
this
problem.
B
H
B
H
H
H
H
Time
zone
time
reminder-
and
we
will
pick
this
up
again
next
week-
Ted.