►
From YouTube: 2023-02-03 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
So
this
is
why
I've
been
not
super
available
in
the
instrumentation
repo.
Lately,
sorry
you're
doing
you're
doing
good
work.
It's
probably
the
most
important
thing
I
can
think
of
right.
Now
you
know:
geometry.
Like
the
first
semantic
conversion
civilized
yeah.
We
will
be
very
nice
to
release
some
stable,
Java
instrumentations.
C
A
Everyone,
let's
get
right
to
it,
Riley
did
you
happen
to
hear
from
Alex
if
he
was
able
to
join.
B
A
Him
about
him,
okay,
so
we
can
Circle
back.
Maybe
if
we
think
we
need
more
time
from
him.
We
could
potentially
schedule
some
being
earlier
next
week
since
he's
in
Germany
so
yeah.
So
let's
talk
ECS
alignment
and
how
that
obviously
affects
HTTP
semantic
stability
effort,
and
so
the
SE,
the
Otep
I,
think
there's
there's
been
well.
A
There
was
also
support
on
the
earlier
Otep
like
from
Yuri
and
alolita,
so
it
felt
like
there
was
some
broad
support
of
this
effort
in
open
telemetry,
so
I
want
to.
You
know,
give
it
a
really
serious
consideration
here
before
we
Mark
any
before
we
Mark
HTTP
semantic
convention,
stable
and
so
I
think.
The
the
way
that
I
would
propose
we
go
is
really
making
a
concrete
effort
of
what
that
would
look
like
for
HTTP
showing
whether
that
could
work
for
HTTP.
A
What
are
the
up
size
downsides
and
then
I'm
taking
that
to
the
community
to
broader
books
on
definitely
a
plan
to
bring
to
cover
this
in
next
Tuesday's
spec
meeting,
both
from
a
hey
everybody,
I
kind
of
intentionally
scare
people
that
this
is
happening,
but
also,
you
know,
try
to
draw
attention
onto
it.
D
I
I've
been
thinking
about
this
a
lot
lately.
Sorry,
my
cat
wants
attention.
Always
when
I
don't
want
her,
so
okay,
I
think
there's
one
thing:
one
thing
to
ask
around
ECS
right
is:
what
do
we
gain
by
aligning
with
ECS
and
I?
D
Think
what
we
gain
is
really
strong
alignment
with
logging
semantic
conventions,
and
then
the
next
question
is:
what
do
we
lose
and
one
of
the
things
that
I've
been
thinking
about
is
like
Prometheus
metric
conventions,
because
that's
another
thing
that
you
we
we've
seen
in
semantic
invention
requests
of
like?
D
Should
we
aligned
with
what
Prometheus
looks
like
I
think
you
know
talking
through
this
with
some
folks
around
around
that
the
Prometheus
metric
convention
thing
there's
some
Nuance
there
that
I
think
we
have
to
call
out,
but
I,
don't
think
we
actually
lose
too
much
depending
on
what
we
do
here.
There
are
a
few
things
we'll
have
to
look
out,
but
I
I
want
to
make
sure
that
we're
kind
of,
like
understanding
that
you
know
ECS
applies
to
logging.
D
It
has
log
based
metric
support
right,
it
doesn't
re
I,
don't
think
it
has
a
bunch
of
stuff
specific
to
tracing
that
we
had
before.
But
when
we
merge
this
stuff
together,
we're
really
blending
two
communities.
D
So
one
thing
to
that
I'm
nervous
about
is
one
thing
that
we
could
lose
is
control,
and
that's
one
thing
to
call
out
in
that
document
of
the
way
that
we
keep
control
in
immediately
is
really
a
workaround,
and
it's
okay
and
I
even
proposed
it.
But
it's
kind
of
gunky,
which
is
we
try
to
have
the
ECS
semantic
convention
group
right,
work
with
standards
and
we
work
independently,
and
we
have
a
sync
point
between
the
two.
D
The
the
problem
here
is:
if
we
decide
to
make
a
change
that
we
think
is
worthwhile,
it
would
break
existing
Integrations
of
ECS
right
and
they're
likely
to
say
no,
because
they
have
a
bunch
of
software
that
already
leverages
those
conventions.
If
we
want
to
make
a
change,
if
they
decide
to
make
a
change,
we
might
also
have
to
say
no,
because
you
know
we
have
to
consider
the
amount
of
instrumentation
we
support
and
the
amount
of
breaking
changes
that
that
is,
whereas
they
have
a
different
kind
of
qualification.
D
So
what
I
would
suggest
going
forward
with
this
alignment?
I
think
trying
to
preserve
the
bridge
between
the
two
and
keep
things
together
as
much
as
possible
makes
sense,
but
what
I'd
suggest
is
we
need
to
look
at
where
the
the
gravity
of
adoption
Lies
over
time.
D
My
expectation
is,
if
we
do
this
well,
people
who
want
trace
and
log
instrumentation
and
metrics
will
eventually
adopt
the
open,
Telemetry
semantic
inventions,
at
which
point
we
would
kind
of
be
the
source
of
truth.
If
we
do
this
poorly
ECS
Remains
the
source
of
Truth
all
the
time
and
we're
just
asked
to
do
what
they
do
right
for
logs
and
then
metrics
and
traces
diverge
in
weird
ways.
D
So,
anyway,
my
a
couple
couple
suggestions
based
on
on
that
decision.
One
is
I
like
what
you
did
of
saying
practically
what
the
hell
does
it
mean
to
open
Telemetry,
so
we
can
really
evaluate
it
on
kind
of
brass
tacks
and
say
like
okay.
If
we
look
at
this
specifically,
do
I
lose
Prometheus
metrics.
D
D
D
D
Okay,
anyway,
outlined
a
bunch
of
the
the
macro
things
when
I
look
at
the
specifics
of
what
you
propose
I'm
actually
on
board
with.
Let's
do
it.
B
For
the
for
the
micro
thing,
I
want
to
see
like,
where
are
the
extremes,
so
one
extreme?
Is
we
just
keep
doing
our
own
thing
and
and
don't
even
think
about
these?
Yes,
it
will
be
different
and
there
will
be
two
different
things.
Another
way
is
there's
no
ECS
ecis
will
be
donated
to
the
cncf
and
their
open,
slab
it'll
be
a
rename
and
it
will
make
a
joint
announcement
and
and
elastic
would
agree
that
moving
forward.
B
D
Yeah
I
guess
the
cabin
I'm
going
to
throw
out
here
is
like
so.
The
interesting
thing
about
ECS
specifically
right
is
the
interesting
thing
about
any
convention.
Splunk,
for
example,
has
an
APM
offering
that
has
expectations
of
what
metrics
look
like
with
names
and
such
you
know,
datadog
has
that
Google
we
have
that
with
like.
If
you
use
these
names,
you
get
this
value,
I'm
sure
Microsoft
does
ECS
also
does
I.
D
D
So
my
fear
here
is
there's
the
elastic
ski
elastic,
the
project
that
has
built
a
whole
slew
of
things
against
the
particular
conventions
right
and
so
what,
when
they
come
into
open
Telemetry,
we
need
to
recognize
that,
like
they're,
both
an
open
source
solution
and
a
vendor
right
and
I
think
if
we
take
that
as
the
mindset
going
forward
and
we're
like
this
vendor
has
done
a
whole
lot
of
awesome
work
in
open
source
with
an
open
standard
that
bootstraps
us
into
defining
a
new
convention
that
will
be
very,
very,
very
compatible.
D
Maybe
subtly
different
right
in
a
way
that
we
can
both
adopt
it
going
forward.
That's
kind
of
the
that's
the
the
middle
ground
of
the
extreme.
That
I
think
is
really
compelling
to
me.
D
But
if
we
were
to
say
like
we're
not
going
to
make
any
changes
whatsoever
to
ECS,
you
know
that's
that
is
likely
to
keep
elastic
very
happy,
but
that
also
puts
a
whole
bunch
of
limitations
on
us
being
able
to
address
tracing
right
and
so
I
think.
There's
a
yeah
there's
a
middle
ground
here
that
I'd
love
for
us
to
be,
but
I
I
love
that
you
called
out
the
two
extremes
and
then
it
gives
us
that
spectrum
of
how
we
want
to
live
this
world
and
like
what
we
want
to
do
going
forward.
E
E
Implications
of
any
changes
that
we
will
be
doing
like
I
definitely
understand
the
value
of
like
evaluating
and
eventually
making
the
decision
about
the
alignment,
but
for
now,
if
we
do
that,
many
changes,
even
if,
like
I've
been
considering
that's
HTTP
conventions,
are
not
stable,
yet
they
they
are
implemented
quite
widely
right.
A
lot
of
clients
already
have
have
all
of
them
and
if
they
are
making
this
this
kind
of
changes
now
during
the
effort
when
we
try
to
stabilize
so
many
like
https
and
many
conventions,
it
will
be
a
lot
of.
E
It
will
be
a
really
long
tail
for
all
the
instrumentations
to
actually
you
know,
Implement
them,
and
also
like
considering
the
fact
that
many
customers,
for
example
in
Microsoft,
a
lot
of
teams,
are
using
existing
instrumentations
and
it
will
be
a
really
long
transition
periods.
Even
for
this,
for
this
particular
change,
so
I
would
maybe
so
the
The
Proposal
here
is.
Maybe
it's
like
to
discuss
these
two
things
separately,
focusing
on
https
management
conventions
and
everything
that
we
have
right
now
to
make
it
stable
with
some
kind
of
trade-offs
and
going
forwards?
B
And
once
that's
determined,
then
the
answer
is
yes,
then
what
he
described
like
people
will
spend
two
years
to
make
the
shift.
If,
if
we
decided
not
not
to
align
with
ECS
and
literally
agree
to
align
with
ECS,
it
will
not
be
two
years.
It'll
be
20
years.
C
C
Done
a
bunch
of
breaking
changes
in
HTTP
and
messaging
conventions
recently,
and
even
though
materials
did
a
lot
of
work
to
align,
I
haven't
heard
anyone
complaining
about
it.
So
far,.
B
D
So
Trask
just
to
talk
brass
tacks.
If
you
go
back
to
your
list
in
the
issue,
if
you
want
to
present
that
real,
quick
I
think
what
I
want
to
call
out
here
is
a
lot
of
these
HTTP
method
changes
here,
where
there's
no
equivalent,
we
can,
you
know,
add
something
which
makes
sense
the
one.
D
Some
of
these
are
just
subtle
changes
which
I
think
aren't
like
super
breaking
and
kind
of
easy
to
deal
with
if
we
go
to
the
net
peer
and
net
host
I
feel
like
this
is
this
is
where
those
net
Peer
Net
host
changes
to
going
to
source
and
destination.
D
That's
that's
a
really
interesting
shift
and
to
your
point,
we
should
provide
some
smooth
transition
to
users
in
the
interim
like
if
that
means
we
double
produce
attributes
for
a
time
to
make
that
transition
smoother.
D
If
that
means,
we
lean
really
hard
into
schema
URLs,
which
I
still
think
aren't,
there's
not
enough
backing
tooling
behind
them
to
actually
have
them
serve
the
need
which
this
is
what
they're
supposed
to
help
you
do
like
I
think
we
can
decide
we're
going
to
move
to
this
new
style
and
then
look
at
the
friction
of
each
move
and
say
this
needs
to
be
addressed
very
delicately.
Maybe
this
one
involves
double
writing
for
a
time
this.
You
know
this
one
doesn't
need
to
be
as
delicate
kind
of
like
the
existing
breaking
changes.
D
We've
got
where
there's
appetite
for
people
to
change
immediately
like
span
name
change,
absolutely
I
think
there's
appetite
for
that.
One!
It's
breaking,
but
I,
don't
think
people
are
going
to
complain
significantly
because
of
the
Improvement
that
that
the
braking
change
is
bringing
some
of
the
like
net.pear
to
Source.
I
think
actually
is
an
improvement,
but
it's
more
subtle
and
might
need
a
different
kind
of
transition.
D
Yeah
effectively
my
view
on
backwards,
compatibility
is
kind
of
what
ladmilla
was
was
hinting
at
there.
If
no
one
complains
then
you're
compatible
right.
So
so,
because
perfect
backwards
compatibility
means
no
change,
because
sometimes
people
rely
on
bugs
right.
So
you
have
to
kind
of
understand
the
the
scope
and
look
at
that.
So
it's
a
good
point
to
call
out
that
we
we
do
need
to
I.
Think
these
specific
ones
here
we're
going
to
need
to
to
Really
address
with
a
good
transition
flow.
D
E
I
actually,
second,
this
idea
of
transitioning,
but
like
the
whole
idea
of
transitioning,
we
need
to
Define
both
both
States
right
from
transition
from
one
from
A
to
B.
And
that's
what
I'm
saying
about
the
current
state
right,
because
I
mean
the
ECS
is,
is
it
is?
E
It
is
a
big
thing,
but
I
don't
think
it
is
the
last
thing
that
that
will,
you
know,
will
be
the
reason
to
to
make
some
changes
right,
and
definitely
we
just
need-
maybe
not
right
now,
but
we
need
to
Define
this
transitioning
process
what
it
makes,
what
it's
still
basically
yeah,
what
it
takes
to
from
one
stable
version
to
another
stable
version,
but
anyway,
for
now
foreign.
E
So
I'm
just
like
trying
to
say
that,
with
the
current
state
of
things
and
the
already
existing
instrumentations,
it
might
be
beneficial
to
keep
kind
of
status
quo.
As
is,
and
just
do
small
adjustments
just
to
make
things
easier
for
to
make
all
the
things
stable
for
now,
but
in
in
in
parallel,
just
to
think
how
we
can
transition
from
this
first
stable
version
to
the
second
stable
version.
B
My
suggestion
is
the
opposite
side.
We
should
look
at
the
long
term
thing
and
acknowledge
that
EPS
is
bringing
a
lot
of
value
and-
and
we
should
work
with
ecis
closely
and
see
if
we
could
make
that
change
and
and
make
it
an
unbox
the
thing.
So
if
we
couldn't
make
the
change
and
align
with
gcis
and
agree
on
how
we're
going
to
work
moving
forward,
then
we
kind
of
already
like
we
already
proved
that
within
maybe
like
two
months
time.
B
Even
we
cannot
align
with
ECI
some
HTV
semantic
conventions
aligning
with
ecis
and
other
things
are
going
to
take
more
than
two
years.
Then
there's
something
in
practice
for
open
parametry.
So
we
decided
what
we're
not
going
to
align
with
ECS
the
recent
time
box.
That
I
think
will
have
a
very
clear
conclusion
whether
we
can
align
with
this
yet
or
not,
and
that
would
solve
the
long-term
issue.
E
Yeah,
that's
a
really
good
point
and
you
you
mentioned
it
last
time
when
we
talked
about
this
like
a
just
a
weekend
time
box
and
make
sure
that
ECS
folks
can
push
it.
But
to
be
honest,
I
don't
think
it
is
actually
realistic
right
to
do
all
this
stuff
in
in
two
months,
just
by
PCS
folks
too,
to
push
all
this
stuff.
So.
C
If
maybe
we
can
help,
we
can
help
ourselves
by
limiting
scope
of
this
particular
group
to
saying
we're
not
aligning
with
ECS.
Here
we
are
learning
attribute
names
and
finding
the
best
things,
and
we
will
try
to
align
as
much
as
possible
and
we
will
see
what
comes
out
of
it.
So,
ideally
the
ideal
outcome
of
this
project.
We
will
find
perfect
attributes
that
we
like,
and
they
are
the
same
as
an
ECS
or
maybe
ACS
needs
to
make
some
additions
or
small
changes
we'll
see.
C
But
let's
put
ECS
out
of
here
and
since
we're
only
talking
about
attributory
names,
we
can
I,
don't
know,
provide
some
poly
Fields,
so
span
processor
that
unifies
all
this
stuff
together
for
https
parents
right.
We
already
have
this
poly
field
on
The
Collector
right,
so
it
can
be
obtained.
It
can
be
default
for
some
time.
I
think
we
can
find
solutions
to
preserve
compatibility,
and
we
can
also
not
go
into
the
discussion
about
DCS
as
a
whole.
Here.
A
So
I'd
like
to
go
back
just
to
address
one
of
Dennis's
concerns
because
they're
about
you
know
this
long
tail
of
migrating.
If
we
do,
you
know,
as
we
make
changes
because
part
of
the
process,
the
semantic
convention
stability
process
that
Ted
outlined
explicitly
calls
out
for
the
this
group
to
continue
working.
It
may
shift
members,
but
have
a
one
three
months
after
stability
to
be
dedicated
to
going
around
and
updating
all
of
the
open,
Telemetry
instrumentations
across
all
the
languages.
A
So,
for
example,
I,
don't
see
that
long
tail
being
a
big
problem
for
open,
Telemetry
instrumentations,
because
at
least
I'm
committed
to
rallying
you
know
all
the
different
instrumentation
maintainers
to
make
to
update
and
to
update,
and
then
the
other
thought
that
came
up
in
my
mind
with
this
was
it
would
be.
A
Potentially,
it
would
be
nice
to
use
this
as
like
I
want
to
say
leverage,
but
in
that
in
you
know,
sort
of
motivation
for
ECS
to
do
this
like
if
we
could
get
some
kind
of
a
commitment
from
them
of
saying
you
know
if
we
decide
if
this
group
decides
say
that
it
is
a
reasonable
thing
to
do
for
HTTP,
you
know.
A
If
you
do,
you
know
if
you
commit
to
to
to
it
also
so
that
we're
not
just
left,
you
know
doing
all
of
the
work
sort
of,
because
if
we
could
do
that
and
we
could
come
out
with
a
joint
announcement
between
open,
Telemetry
and
ECS
at
the
end
of
this,
you
know
and
say
that
would
to
me
that
would
justify
all
the
breaking
everything.
A
A
Can
we
talk
about
the
immediate
next
steps,
then?
Do
we
have
contacts
other
than
Alex
within
ECS,
because
I
can
definitely
from
that
perspective?
I
can
I
could
try
to
get
the
ball
rolling.
B
I
I
don't
know
some
questions
to
to
Alex
and,
and
he
replied
and
I
haven't
gone
through
all
like
he
made
a
very
long
reply,
but
he
was
basically
concerned
about
hey.
If
open
Telemetry
is
many
conventions
based,
as
is
then
many
things
are
incompatible
with
ECS
and
how
do
they
merge
things
and
and
he's
worried
about
that?
So
so,
if,
if
open
plump,
she
could
offer
okay
like
we're
willing
to
make
breaking
changes
in
the
https
management
convention
to
match
ECS
as
much
as
possible.
C
A
I,
if
we
could
get
that
kind
of
you
know
joint
announcement
agreement
between
those
two
communities
at
the
highest
level,
then
to
me
it
just
that
end
result
justifies
the
breaking
changes
and
the
work
that
goes
into
it
now.
The
timeline
is,
of
course,
a
concern,
but
you
know
I
think
we
have
set
a
date
and
I'm
willing
to.
You
know,
push
people
and
say
like
hey.
We.
If
this
is
going
to
happen,
it
needs
to
happen
now
so
get
on
board.
B
D
Two
things
so
that
are
really
important
to
call
out
Riley
number
one
where's,
the
most
contention
going
to
come
from
in
ECS.
It
is
not
HTTP,
it
is
resource
semantic
conventions,
that's
the
one
I'm
the
most
nervous
about
aligning.
If
you
look
at
the
current
resource
semantic
conventions,
I
think
there
are
more
vendors
in
otop
aligned
with
our
resource
semantic
inventions
than
not
products,
even
though
they're
not
stable,
and
then
the
breaking
change
of
that
is
is
somewhat
impactful.
D
And
then,
if
you
look
at
the
differences
so
far
in
ECS
and
our
resource
semantic
inventions,
they're
they're
quite
high,
for
example,
we
have
resource
and
management
conventions
that
say
kubernetes
theirs
says
like
orchestrator,
or
something
like
that.
It's
like
in
a
world
before
kubernetes
the
we
I
think
if
we
had
a
resource
semantic
inventions
group
in
parallel
to
this
group,
that
commitment
could
be
made
and
I
want
to
do.
D
I
absolutely
agree
with
you:
we
should
make
that
commitment
and
try
to
figure
this
out
with
ECS,
but
for
the
purpose
of
this
group,
what
I'd
recommend
is
use
ECS
as
an
input
of
existing
conventions,
like
one
thing
that
we
should
be
doing
when
we
Define
our
semantic
conventions
is
look
at
the
state
of
the
world
and
use
that
as
input.
If
there's
existing
conventions
that
make
a
hell
of
a
lot
of
sense,
we
shouldn't
be
Reinventing
the
world.
A
Okay,
so
that
sounds
like
a
good
sort
of
like
we've
got
sort
of
two
paths
to
or
a
couple
of
paths
to
go
down.
One
is
on
the
HTTP
for
this
group,
very
specifically
continuing
I
think
to
explore.
A
You
know
what
we
can
learn
from
the
ECS
conventions
and
if
we
think
that
you
know
in
an
Ideal
World
say
where
we
didn't
have
to
worry
about
breaking
changes.
If
we
would
make
these
changes
like
not
I
would
I
would
say
we
we
can
make
two
different
decisions
here
and
I
think
we
should
make
two
different
decisions.
A
One
is
whether
we
would
make
these
changes
if
we
didn't
have
to
worry
about
backward
compatibility
and
one
if
we
did
care
about
backward
compatibility
because
I
think
then
the
overall
picture
the
overall
agreement
would
affect
which
one
then
we
choose
again,
that
if
we
had
a
good
story
to
say
at
the
end
of
the
day
of
we
are
aligning
across
the
board,
then
I
would
say
you
know,
let's
break
otherwise.
Maybe
we
don't.
A
So
that's
one
path
to
specifics
here:
Josh
the
yeah,
the
resource
semantic
I-
don't
fully
understand
this,
so
maybe
we
can
less.
Maybe
you
can
open
an
issue
to
start
fleshing
that
out
a
little
bit
or
at
least
calling
out.
You
know
what
the
problems
are.
D
Yeah
I'll
take
I'll,
take
ownership
of
that
no
problem,
but
if
you
think
about
HTTP
semantic
conventions
being
stable
right,
remember
that
resource
is
a
huge
part
of
your
labels
that
people
rely
on
if
those
aren't
stable,
we're
still
in
trouble.
A
So
is
this:
blah
is:
is
research,
semantic
convention,
a
blocker
for
HTTP
semantic
stability.
D
No,
but
it
might
be
a
blocker
for
actual
adoption
by
users,
which
is
what
I
anyway.
That's
why
I'm
calling
it
out
so
I?
Don't
think
this
group
needs
to
pay
attention
to
it
at
all
and
I'll
take
on
that
action
item
to
go,
try
to
figure
out
and
address
that
we
might
need
to
spin
up
a
group
quick
to
address
it,
given
the
difference
between
ECS
and
what
we
have
today.
Yeah.
A
Okay,
great
and
I
will
take
the
the
third
action
I
think
of
I'll
start
floating
in
the
around
the
governance
Committee.
Just
to
see
you
know
who
may
have
contacts
within
elastic
ECS
and
to
start
socializing
this
idea
and
see
what
people's
feedback
is.
A
A
Cool
so
yeah,
let's
keep
on
this
front.
Let's
keep
banging
away
on
this
issue,
I'm
still
Lynn
Miller
of
me
ping.
You
at
some
point,
I,
didn't
quite
understand
some
of
our
conventions,
also
in
the
context
of
what
it
means
in
HTTP.
In
reality,.
C
Yeah
and
I'm
a
bit
lost
between
service
client
destination
and
Source
right.
Okay,.
A
A
I'll
set
up,
let's
you
and
me
sync
on
that
yep
I
will
post
on
the
issue.
C
A
B
A
We
didn't
get
to
I
know
we
wanted.
We
do
care
about
retries
and
connection
semantic
conventions.
Maybe
next
Friday
no.