►
From YouTube: 2023-01-24 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
B
Okay,
let's
start
yeah
I
think
thank
you
for
joining
the
first
item.
The
first
two
items
are
mine.
The
first
one
is
about
just
a
PR
that
Tyrant
created
just
for
clarifying.
What's
the
behavior
for
otlp
when
there's
empty
or
not
not
present,
Trace
ID
or
spot
ID,
we
discussed
in
the
past
few
changes
already.
This
is
the
last
item.
We
need
to
Mark
OTL
PJs
on
a
stable.
So
please
take
a
look.
It
has
enough
reviews,
but
we
need
more
eyes.
So
it's
not
a
surprise
later
on.
B
B
A
You
all
right
real
quick,
so
we
in
Python
we
see
the
a
PR
from
this
user
who
wants
to
have
a
a
metric
exporter
that
is
not
periodic,
but
but
rather
exports
metrics
when
the
user
instructs
exporter
to
do
so,
so
we
were
going
back
and
forth
on
which
will
be
the
best
way
to
implement
it.
And
after
discussing
this
for
a
while,
we
came
to
the
conclusion
that
it
will
be
better
if
we
could
have
a
new
class
name.
A
C
A
B
A
Okay,
great
so
I'll
I'll
open
an
issue
Andy.
Our
related
question
is:
how
do
we
know
if
we
should
or
should
not
bring
some
new
feature
to
the
spec,
or
should
we
always
bring
any
new
feature
to
the
spec,
because
sometimes
it
kind
of
happens
that
the
new
feature
needs
happen,
but
they
may
be
particular
to
a
language,
so
it
may
not
make
sense
to
bring
into
respect,
but
sometimes
it
also
happens
that
new
features
this
one
are
requested
which
may
affect.
A
B
D
A
A
B
Is
an
issue
that
Riley
created?
We
have
to
come
back
to
that
and
grab
that
up.
What
basically
was
about
basically
try
to
prevent
that
six
extent:
parts
of
specification
while
allowing
them
to
extend
other
parts,
so
we
actually
have
to
clarify
that,
but
usually,
if
you
want
to
touch
default,
values
or
anything
that
is
not
language
specific
should
be
discussing
the
specification.
But
anyway,
this
is
a
good
call
to
bring
that
issue
back
to
life
all
right.
F
I
put
a
link
in
the
in
the
chat,
so
I
have
some
recommendation
that
you
can
follow
this,
but
coming
back
to
your
original
question,
I
think
for
each
language,
rival,
the
maintenance
should
feel
more
responsible
of
deciding
what's
the
best
practice.
For
example,
like
the
specific
case
you
can
decide
whether
this
is
something
that
can
be
already
achieved
with
existing
thing,
then,
if,
yes,
you
should
tell
the
the
guy
no
there's
already
something
you
don't
want
to
invent
a
new
thing,
or
maybe
your
specific
product
has
some
experimental
feature
you
can
tell.
A
B
B
F
Yes
and
one
additional
thing
so
for
people
working
to
look
into
this
discussion
in
the
metric
size
DK,
we
talked
about
something
like
we
might
want
to
decouple
the
collection
cycle
versus
the
exporting
cycle.
For
example,
you
can
have
a
matrix
size
DK,
which
collects
the
temperature
from
from
a
real
sensor
every
one
second,
but
you
don't
want
to
keep
reporting
them,
maybe
just
because
you
want
to
reduce
the
total
number
of
requests.
You
only
export
everyone
minutes
to
The
Collector,
or
maybe
you
don't
even
control
the
cycle.
F
You
only
report
the
premises,
but
you
still
want
to
have
the
sense
of
reporting
the
data
and
then
you
you
store
them
temporarily
in
memory.
I
I
feel
this
Force
flash
might
touch
that
part.
So
at
least
we
want
to
make
sure
if
we
change
something
here
later,
we
want
to
decouple
the
reporting
versus
collection
cycle.
We
still
can
I'll
add
comment
in
the
issue.
B
F
E
B
You
actually
I,
don't
know.
What's
the
state
on
the
language
is
there
I
know
that
when
we
were
considering
bringing
some
prior
art
like
data
dogs,
you
know
components?
Is
that
basically
automatically
have
that
out
of
the
box?
It's
not
cheap,
of
course,
or
at
least
it's
not
well.
At
least
it
comes
with
a
price
but
to
pay
what
otherwise.
It
was
already
available.
G
G
G
But
if
the
collector,
if
it
was
in
The
Collector,
because
we
had
this
debate
when
we
did
when
we
introduced
that
into
Java
in
the
first
place
was
whether
it
should
really
you
know,
I
mean
just
push
it
off
unsanitized
to
a
local
collector
agent
and
do
the
sanitization
out
of
process.
There
seems
like
maybe
a
better
set
up
and
more
cross-language
support.
B
G
B
Yeah,
perfect,
okay,
let's
copy
a
link
to
that
and
I
will
put
that
in
the
issue
itself,
because
I
think
it's
important
that
we
want
to
make.
Even
if
it's
only
a
recommendation,
it
could
be
great
to
actually
Point
people
to
something
that
already
exists.
Well,
citizen
works.
Well,
okay,
perfect
I
will
comment
after
the
call
on
this
one
sweet.
Thank
you
so
much
for
the
information
Trask.
Okay,
the
next
one
is
on
you
actually
so
project
tracking.
G
G
As
you
can
see,
though,
in
the
top
level
Group,
which
is
there's
still
certain
spec
issues
which
cross
all
semantic
conventions,
sort
of
are
General
blockers
for
any
semantic
convention
to
go
stable,
and
so
those
are
still
being
handled
at
that
level.
So
there'll
be
a
lot
of
coordination
between
the
two
groups
and
that's
why
we're
kind
of
just
doing
it
as
a
subgroup,
and
if
you
are
so,
we
do
have
two
TC
sponsors.
G
We
do
have
a
doodle
out
right
now
to
try
to
plan
meetings,
part
of
Ted's
process
I
mean
it's
very
compacted
right,
a
lot
faster
than
we've
ever
well.
We've
never
gotten
semantic
conventions
to
stability,
but
every
time
we've
kind
of
try
to
take
it
takes
a
long
time.
So
part
of
one
of
the
ideas
Ted
had
was
to
meet
multiple
times
a
week
to
try
to
iterate
more
quickly
and
keep
the
semantic
conventions
from
finishing
in
2030..
G
F
G
F
I
I
was
thinking
if
folks
might
find
this
like
open
time
trip
blog
as
a
place
for
people
to
just
create
some
energy
there.
I
remember
like
for
Matrix.
We
put
something
we're
saying
like
we're:
we'll
spend
a
year
to
stabilize
the
metrics
SDK
spec,
and
we
put
some
exact
date
by
telling
people
when
we'll
release
the
experimental
version.
The
Bergen
Tool
Mark
that
as
stable,
although
we
we
didn't,
meet
all
the
Milestones
but
having
the
initial
thing
is
generating
the
energy
like.
We
actually
attracted
a
lot
of
talents
from
from
the
community.
F
So
it's
a
wonder,
active
HTTP
thing
can
can
leverage
the
similar
idea
here,
like
once,
you
put
a
clear
stake:
On
The
Ground
by
telling
people
we're
going
to
make
it
stable
by
end
of
April,
although
we
know
that
we
might
sleep
for
a
few
weeks
or
even
a
month,
but
having
that
date
is
giving
people
this
like
very
clear
Target.
So
they
can
backtrack
and
see
how
far
they
are.
G
B
I
Oud
absolutely
so
this
disappear
has
been
boring
for
a
few
weeks.
I
have
two
questions
on
the
pr
itself.
There's
a
question
from
one
of
the
approvers
I'm,
not
sure.
If
he's
here
today,
I'm
sorry
who
asked
if
this
particular
contribution
should
be
made
under
a
different
folder
for
cloud
provider,
so
I'd
love
for
kind
of
get
your
expertise
on
this
one.
I
really
don't
know
where
things
go.
So
if
you,
if
you
click
on
the
pr,
this
is
an
open
question
there.
I
That's
the
first
one.
The
second
is
the
second
just
popped
up,
arming
just
is
doing
a
review,
and
he
mentioned
that.
Maybe
some
of
those
environment
variables
should
actually
be
mapped
to
service.name
service.
Instance.Id
I,
don't
know.
What's
the
best
move
here,
so
I'd
love
to
get
your
expertise
on
this
and,
if
possible,.
C
So,
on
the
first
part
of
your
question,
I
think
that
the
the
cloud
provider
subfolder
should
work
quite
well
is
I.
Think
hero
Kudos
constitute
the
cloud
provider
like
the
others.
Do
we
have
Lambda
and
such
Technologies
there,
for
example
in
I,
think
the
hero
code,
I
know,
should
also
work
there,
and
the
other
topic
is
with
the
application
name
and
ID
that
you
proposed
there.
C
I
was
just
wondering
if
it
might
usually
or
maybe
always
coincide
with
the
definition
we
already
have
for
service.name
and
service
dot
instance
ID,
but
I
like
the
the
knowledge
of
how
people
usually
use
in
structure
Heroku
dinos.
If
they
usually
run
one
service,
I
I
would
think
so
or
if
you
might
have
many
services
running
in
one
one
Dyno
could
also
be
possible.
Maybe
you
have
some
better
insights
there.
I
Yeah,
it's
a
good
point.
It's
a
good
point
if
you're
using
this
okay,
but
it
usually
is
one
and
thank
you
for
linking
to
the
service
name
and
all
that
so
I
think
we
could
actually
just
reuse
that
for
most
of
it,
there's
some
additional
things
that
I'd
be
able
to
tack
on
that
there
may
be
still
a
crew
specific.
The
thing
that
gave
me
pause
for
the
cloud
provider
is
that
it
would
be
a
new
folder,
I
I
hope,
that's,
okay,
it's
just
I,
just
see
a
AWS
folder
in
there.
I
C
I
C
C
For
example,
there
is
the
release
version
and
release
commit
in
there
and
I
I
wonder
if
that
could
also
be
a
generic
topic
that
we
would
would
like
to
track
on
top
level
or,
if,
since
that,
doesn't
sound
here,
Rocco
specific
to
me,
but
it
auto
has
been
around
for
a
while
and
it
hasn't
come
up
in
the
past.
So
maybe
maybe
it
is
mostly
interesting
for
Heroku
use
cases.
I
don't
know.
B
By
the
way,
my
two
cents
on
that
front
and
I
remember
back
in
the
day
when
I
was
trying
to
map
some
kubernetes
stuff
to
existing
semantic
conventions.
Is
that
there's
always
the
risk
that
you
we
try
to
too
hard
to
force
things
that
we
are
adding
to
map
existing
stuff
and
sometimes
the
mapping?
The
mapping
is
not
really
one
to
one.
B
Sometimes
there's
something
specific
like
let's
say
on
one
in
hotel,
we
have
the
somatic
convention,
which
is
expected
to
never
change,
and
you
have
this
one
that
is
almost
the
same
in
your
new
component,
but
this
new
one
is
almost
the
same,
but
it
changes
it
does
change
over
time.
So
there's
always
a
Temptation
about
trying
to
reuse
that
and
I
think
it's
great
if
we
can
actually
reuse
a
lot
of
those
things
as
long
as
as
there
is
a
an
obvious,
direct
mapping.