►
From YouTube: 2023-03-13 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
All
right
we'll
get
started
slightly
smaller
crowd
than
usual
and
guessing
a
lot
of
that's
due
to
the
switch
to
Daylight
they're
switched
to
or
from
daylight
savings
time
that
just
took
place
on
North
America.
So
it's
kind
of
a
rough
Monday
morning
for
a
lot
of
people.
So
we'll
start
working
through
some
of
the
items
here.
I
know
Bob
and
Ted.
A
Both
messaged
me
saying
they
couldn't
attend
today,
but
Bob
I
know
had
left
some
updates
here
that
he
wanted
people
to
discuss
and
be
aware
of
so
starting
Vlogs
Jack.
You
added
that
there's
presidents
had
to
stabilize
the
logs
Bridge
API
and
SDK.
So
this
is
what
allows
third-party
logging
systems
in
each
language
to
communicate
with
Hotel
logging
I.
Think
Jack.
Did
you
want
to
talk
more
about
that.
B
Yeah
so
some
of
you
were
probably
in
attendance
in
last
week's
specification.
Sig
tigrin
gave
this
presentation
about
our
intent
to
stabilize
the
open,
Telemetry
logs,
Bridge,
API
and
SDK,
and
as
part
of
just
our
effort
to
stabilize
that,
we
wanted
to
announce
that
to
the
maintainers
as
well.
And
so,
if
you
don't
mind,
Morgan
I'd
like
to
share
and
kind
of
go
through
the
presentation.
A
B
Can
everyone
see
my
screen?
Okay
confirmed
all
right.
So,
as
I
mentioned,
we're
preparing
to
Mark
the
log
Bridge
API
and
SDK
is
stable,
I'm
going
to
walk
through
what
we
already
have
is
stable,
what's
experimental
and
what
we
plan
on
stabilizing.
You
know
the
Prototype
implementations
we
already
have
and
talk
about.
What's
next,
so,
what's
already
stable,
there's
a
log
data
model
document,
that's
been
stable
for
a
while
and
and
the
log
signal
as
part
of
the
otlp
specification.
B
B
What
we
plan
to
stabilize
are
these
experimental
documents
representing
the
logs
Bridge,
API
and
SDK,
so
the
logs
Bridge
API,
it's
also
been
called
the
logs
back
in
API
or
the
logs
that
Pender
API
kind
of
the
intent
behind
it
is
that
it
allows
you
to
bridge
logs
from
existing
apis
existing
log
Frameworks.
So
in
Java
that
would
be
things
like
log4j
and
Java
utilities,
logging
and
log
back.
B
This
API
is
what
you
use
to
bridge
those
into
open
telemetry,
and
one
thing
we
want
to
make
clear
is
that
this
is
not
a
general
purpose.
Logging
Library!
This
is
not
an
API
that
we
should
promote
to
end
users
and
that
they
should
use
in
place
of
existing
libraries
and
Frameworks.
We
don't
want
to
reinvent
the
wheel,
so
this
API
and
SDK,
it
mirrors
the
tracing,
API
and
SDK
in
a
lot
of
ways.
So
just
like
there's
a
tracer
provider,
there's
a
logger
provider
just
like
there's
a
tracer
there's
a
logger.
B
You
know,
there's
log
record,
processor
and
log
record
exporters
and
a
lot
of
the
concepts
are.
Are
you
know
exactly
the
same
in
the
logging
signal?
So
it's
I.
Guess
comparatively
simpler
than
in
tracing,
because
we
inherit
a
lot
of
stuff
and
there's
a
little
bit
less
scope,
so
the
idea
of
like
sampling
doesn't
occur,
for
example,.
B
They
would
continue
to
use
their
their
existing
logs
Library,
so
in
this
case
log
for
J
and
that
log
Library
would
be
configured
to
bridge
the
log
records
into
the
open
Telemetry
ecosystem
by
an
appender
and
the
Pender
would
use
the
log
Bridge
API
to
actually
perform
the
translation
from
the
the
Upstream
system
to
open
telemetry
and
the
log
Bridge
API.
The
implementation
of
it
is
the
logs
SDK,
and
you
know,
once
log
records
are
in
the
log
SDK
they
get.
They
get
batched
up
and
exported
out
of
process
using
otlp.
B
You
know
we
have
five
languages
here:
java.net
python,
JavaScript
and
C
plus
plus-
and
you
know
some
of
these
are-
are
a
bit
further
along
than
others,
so
in
in
java.net
and
python,
there's
there's
append
or
implementations
for
a
couple
of
popular
logging,
libraries
and
I
know.
I
can
speak
for
Java
in
particular,
but
so
the
otel
Java
agent
will
automatically
you
know
Bridge
logs
from
popular
logging
libraries
into
into
the
the
existing
prototypes
and
while
the
export
over
otlp
is
disabled
by
default.
B
If
you
turn
it
on
it,
just
kind
of
works
is
the
way
you
would
expect
it
so
I
think
it's
a
pretty
popular,
it's
pretty
popular
amongst
our
users,
so
it
has.
It's
been
exercised
quite
a
bit
to
give
you
an
example
of
what
this
looks
like
I'm,
going
to
go
through
an
example
in
Java
and
the
source
code.
You
can
go
look
at
this
here,
but.
B
So
what
I
have
here
is
an
application
that
it
kind
of
demonstrates
a
lot
of
the
different
things
all
in
one
place
that
you
can
do
with
the
open,
Telemetry
logs,
Bridge,
API
and
SDK.
So
a
little
bit
of
background
in
Java
there's
a
couple
of
different
popular
solutions
for
logging.
There's
this
thing
called
Java
utilities,
logging,
which
is
which
is
kind
of,
doesn't
have
great
ergonomics,
but
is
built
into
the
Java
runtime,
and
so
you
don't
have
to
have
any
dependencies
to
use
it.
B
So
folks
like
to
use
it
there's
this
thing
called
SL
left4j's
standard
standard
login
for
facade
for
Java,
which
aims
to
be
a
standardized
logging
API,
that
all
applications
can
use,
and
you
configure
your
own
implementation
of
exactly
how
those
logs
get
processed
and
consumed
and
then
another
popular
logging
solution
is
is
called
log4j,
and
so
this
this
application
actually
demonstrates
kind
of
taking
all
those
apis
that
exist
in.
In
you
know,
configuring
them
to
bridge
their
logs
into
open,
Telemetry
and
Export
over
otlp
and
I.
B
Have
a
I
got
a
collector
running,
and
this
collector
is
configured
just
to
receive
logs
over
otlp
and
to
you
know,
use
the
the
logging
exporter
to
kind
of
print
them
to
the
council
to
kind
of
show
how
all
this
works,
and
so
you
know
going
back
to
the
application.
Let's
kind
of
look
at
what
this
does
really
quickly.
So
there's
some
initialization,
we
initialize
open
Telemetry,
and
we
you
know
this
is
just
some
initialization.
B
That's
required
to
set
up
the
the
one
of
the
logging
Frameworks
and
then
each
of
these
sections
down
here
demonstrates
kind
of
how
logs
work
with
a
particular
library
and
framework.
First
we
have
log4j,
and
so
we
log
some
so
some
log
messages
and
we
log
them
in
a
couple
of
different
ways.
We
log
them
with
and
without
a
spanning
context.
B
One
of
the
key
aspects
of
this
of
the
open,
Telemetry
log
solution
is
that
logs
support,
Trace
contacts,
propagation,
and
so,
if
your
logs
are
recorded
in
the
context
of
a
of
an
of
a
span
that
spans
ID
and
its
corresponding
Trace
ID
will
be
propagated
onto
the
log
message.
So
you
can
correlate
those
two.
This
demonstrates
that,
with
and
without
a
spanning
context,
I
also
demonstrate
structured
logging
here.
So
you
know,
if
your
logging
framework
supports,
you
know
structured
key
value
pairs.
B
B
This
is
slf
for
J
standard
logging,
facade
for
Java,
which
uses
log
back
as
it's
configured
back
end
for
the
API
and
then
log
back
bridges
into
open
telemetry.
B
Here
we
show
Java
utilities
logging.
This
is
the
the
API
that's
built
into
into
the
Java
runtime,
and
then
this
little
section
of
code
down
here
actually
demonstrates
using
the
the
open
Telemetry
log
Bridge
API.
So
you
know
there's
a
bunch
of
warnings
here
that
say:
Hey
users,
don't
don't
go.
Try
to
mimic
this,
but
this
is
the
type
of
code
that
is
written
in
the
appenders.
So
if
an
appender
is
written
that
needs
the
bridge
log
records
into
open
Telemetry,
then
this
is
kind
of
the
API
that
it
uses.
B
But
again
it's
not
to
be
used
by
end
users,
so
yeah.
If
we,
if
we
run
this
application,
let
me
get
a
shell
out.
We
can
kind
of
see
how
these
logs
manifest
and
oh
I.
Guess.
Let
me
let
me
back
up
a
step.
Well,
I
want
to
show
one
more
thing
about
like
just
how
you
can
figure
these
log
Frameworks
to
to
you
know
include
the
appender.
B
So
you
know
you
can
configure
it
in
a
variety
of
ways,
but
one
popular
way
is
via
this,
like
XML
based
configuration
scheme,
and
so
you
know
here
we
say
hey
at
at
the
root
level:
we're
going
to
log
all
log
records
that
are
at
level
info
or
more
severe,
we're
going
to
log
them
all
to
the
console
and
we're
going
to
log
them
all
to
this
open,
Telemetry
offender
in
this
open,
Telemetry
appender
is,
you
know,
defined
up
here,
including
this
line
in
this
XML
configuration.
B
You
know,
causes
log4j
to
go,
look
for
a
an
appender
class
called
open,
Telemetry,
appender
and
it
searches.
You
know
the
the
class
path
because
we
added
in
the
right
place,
because
we
add
this-
the
package
that
that
appender
lives
in
to
the
the
set
of
packages
to
go
search
in
and
so
yeah
we
configure
the
appender.
B
We
say
to
use
the
appender
at
the
info
level
and
we
have
a
similar
thing
going
on
for
log
back
I'm
not
going
to
go
into
that,
because
I
think
it'll
just
be
confusing
to
look
at
all
the
different
implementations.
But
that's
essentially
the
the
extent
of
the
configuration
that's
needed.
B
B
This
is
the
collector
that's
configured
to
receive
logs
via
otlp
and
log
them
out
to
the
console
with
the
logging
exporter
and
let
me
zoom
in
a
bit
and
then
I'm
going
to
just
run
this
application,
and
this
application
is
just
going
to
log
some
messages:
flush
them
out
to
The
Collector,
and
then
you
know
and
terminate.
B
So
we
see
some
log
messages
logged
to
the
console
and
if
we
go
over
to
the
other
shell,
where
the
collector
is
running,
we
should
see
those
logs
in
the
collector's
console.
We
do
there's
a
lot
here,
let's
kind
of
just
look
at
a
couple
of
one
or
two
log
records
to
see.
If
we
can,
you
know
find
anything
interesting.
So
you
know
the
resource
is
standard.
This
is
the
same
resource
that
would
be
included
on
any
traces
or
metrics
that
were
exported
over
otlp.
B
The
scope
is
the
name
of
the
scope
is
equal
to
the
name
of
your
logger.
So
whatever
you
name
your
your
logger
in
which
is
like
a
popular
thing
to
do
in
in
logging
Frameworks
you,
you
name
the
you,
give
an
ID
or
a
natural
key
to
the
logger
that
you're
going
to
use
to
emit
records.
So
that
name
that
you
give
your
logger
manifests
as
the
instrumentation
scope
name
and
then
you
know
for
the
log
records
what's
interesting
here.
The
the
string
message
manifests
on
the
body
of
the
log
record.
B
If
there
were
any,
if
there
was
any
structure
in
the
log
record,
you
know
if
there
was
any
structured
logging
going
on,
then
we
can
extract
that
structure
and
include
it
as
in
in
attributes.
So
here
we
have
an
attribute
attached
to
the
log
record
for
a
key
value
pair.
B
A
And
just
to
clarify
Jack
the
trace
and
span
and
betting
typically
today
before
any
of
this
is
used
used
in
the
public.
When
people
want
to
embed
the
trace
and
span
IDs
in,
say
log
for
with
logs
written
with
log4j,
they
have
to
write
a
I
think
a
log
offender
or
something
within
log
log
for
J
to
achieve
that
with
the
hotel
logging
bridge
I'm
guessing
they
don't
have
to
do
that,
because
now
the
otel
SDK
is
doing
the
correlation
yeah.
A
So
now,
like
they're
effectively,
if
you
already
had
the
hotel,
I,
guess
Java
SDK,
linked
to
your
application,
to
take
advantage
of
our
logging
capabilities,
you're,
actually
making
what's
effectively
an
easier
change
than
you
would
have
made
today
to
embed
the
trace
and
span
IDs.
Definitely
I
like
this
yeah
nice
cool.
B
A
Even
better
and
so
I've
written
down
a
question
that
note
says,
but
that's
that
for
for
Java,
then
this
this
is
done
through
the
Java
agent.
Is
that
going
to
be
the
case
in
other
languages
as
well,
where
if
customers
are
using
their
producers
or
using
the
agent
it'll,
take
care
of
logging
automatically
for
them.
A
B
So
Dan
I'm
going
to
stop
sharing,
and
you
know
if
there's
any
questions
that
we
want
to
talk
about,
we
can
do
that.
I.
Think
Dan
has
asked
a
question
in
the
comments,
so
what's
the
current
guidance
around
the
terms
Bridge
versus
a
Pender,
are
we
going
to
standardize
in
a
single
term
to
reduce
user
confusion?
I
think
we
should
standardize
on
a
single
term.
B
You
know
there's
there's
use
of
both
terms
in
in
different
signals,
so
in
in
metrics,
for
example,
we
have
this
idea
of
a
well
there's
use
of
several
different
terms,
there's
like
a
penders
bridge
and
then
in
metrics
there's.
Also
this
idea
of
a
producer,
a
metric
producer
is
this
new
prototype.
B
Api
that
you
can
use
to.
You
know,
provide
an
alternative
producer
of
metrics.
Besides
the
metrics
SDK
in
those
metrics
get,
you
know
exported
via
readers
or
you
know,
consumed
via
readers
and
exported
via
otlp,
and
you
know
the
the
metric
producer
document
or
part
of
the
specification
calls
the
thing
a
Metro
producer
and
then
says
that
the
producer
is
responsible
for
bridging,
and
so
you
know
we
can't
really
get
our
language
straight.
B
Even
even
over
there
I
think
for
now
the
terms
like
bridge
and
a
Pender
are
a
bit
like
synonymous
with
each
other,
but
if
we
can,
we
should
we
should
kind
of
standardize
on
a
single
term.
B
I,
don't
think
everybody
like
I,
don't
I,
you
know
it's
a
it's
like
a
language
thing.
When
people
hear
Bridge
or
Pender
they,
they
have
different
assumptions
and
conclusions
that
they
make,
and
so
some
are
more
intuitive
to
certain
folks
than
others.
C
For
what
it's
worth,
I
also
prefer
the
term
Bridge.
The
word
offender
to
me
implies
that
something
is
being
added
to
the
logs
as
they
stream
through
the
component,
but-
and
you
could
argue
that
context
is
being
appended
to
the
logs.
So
maybe.
A
C
A
And
I
had
more
of
a
comment
than
a
note
here
than
a
question
here,
but
just
emphasize
like
the
the
apis
that
Jack
was
showing
that
we've
added
to
the
opensometry
sdks
like
these
are
absolutely
not
meant
for
end
user
consumption
in
that
people
should
not
be
writing
log
statements
in
their
apps
of
things
and
and
Jack.
Please
chime
in
if
I'm
incorrect
about
saying
any
of
this,
but
like
right
now.
A
It
is
not
the
intent
of
open
Telemetry
to
provide
end
user
facing
like
really
nice
apis
that
people
can
use
to
generate
logs
within
their
Java
applications
or
python
applications.
Or
what
have
you.
This
is
different
than
what
we've
done
with
traces
and
metrics,
where
we
do
have
many
end,
user-facing
apis
embedded
in
our
sdks.
A
This
is
just
being
done
because
there's
so
many
logging
Solutions
already
out
there
and
it
doesn't
necessarily
make
sense
to
reinvent
the
wheel
in
the
future.
Perhaps
I'm
not
saying
that
this
will
happen,
but
it
is
possible
that
that
decision
you
know
later
on
in
the
project
people
start
demanding
this
and
maybe
for
certain
languages,
say:
hey
fine.
A
That
decision
has
not
been
made.
That
decision
will
not
be
made
for
a
long
time,
like
don't
don't
count
on
this
happening,
but
even
if
that
decision
does
get
made,
we
would
write
new
end
user
focused
apis
with
the
SDK
for
that
and
I'm
saying,
let's
just
emphasize
like
just
be
be
in
whatever
it
is.
You
do
like
Jack
was
showing
in
the
comments
like
make
sure
it's
very
clear
to
whoever
uses
our
sdks
that
they
should
not
like
manually
be
creating
log
statements
with
these
apis.
B
And
one
one
addition
to
that:
Morgan
is
there.
We
opened
an
issue
recently
to
talk
about.
You
know
if
we
were
to
add
a
a
future
end
user
facing
log
API
in
the
future.
Like
you
know,
we
want
to
make
sure
that
whatever
we're
doing
with
this
log,
Bridge,
API
and
SDK
is
compatible
with
that
or
have
at
least
the
story
on
how
we
would
grow
into
that
future.
My
opinion
is
that
we
should.
B
We
should
do
this
all
with
you
know
with
documentation,
so
we
shouldn't
we
shouldn't,
have
anything
in
like
the
naming
of
like
code
components
that
says
that
this
isn't
user
facing.
We
should
have
that
done
in
in
you
know
in
comments
and
docs
yeah,
and
so
that
you
know
the
same
component
that
isn't
user
facing
today
could
become
user
facing
in
the
future.
If
we
wanted
to
expand
the
scope.
B
A
Yeah
and
so
so
for
context
for
everyone
else
like
this
has
been
a
I
think
a
debate
for
some
time
between
different
people
in
the
community,
about
whether
we
should
have
user-facing
logging
apis
again,
like
the
decision
right
now
is
no
but
I
I
could
I
could
see
us
revisiting
this
and
I'm
not
saying
this,
because
I
have
strong
opinion
about
it,
but
I
could
see
us
revisiting
this,
if
only
because
certain
sigs,
like
C
plus,
for
example,
have
come
up
and
said:
hey
you
know,
C
plus
plus,
is
very
different
than
Java
and
Java.
A
Everyone
uses
like
log4j
or
or
the
built-in
Java
logging
apis
for
C,
plus
plus
there's
no
clear
winner.
Why
shouldn't
open
Telemetry
offer
a
great
you
know,
end
user
logging
API,
no
real
response
to
that,
because
that
seems
very
reasonable,
and
so
perhaps
in
the
future
we
will
revisit
this
starting
with
a
certain
set
of
languages,
but
in
this
first
logging
release
that
we're
working
towards
the
apis
should
all
be
marked
in
the
in
their
code,
comments
and
documentation
in
whatever
other
Marketing
Systems.
A
B
And
one
of
one
of
the
reasons
that
we
don't
want
to
have
a
full
user-facing
log
API,
is
that
the
existing
login
Frameworks
have
are
really
rich
ecosystems
with
all
sorts
of
options,
for
you
know
what
to
do
with
those
logs
when
they're
processed,
you
know
all
sorts
of
different
explorers
for
sending
to
different
network
locations,
rotating
file,
appenders
and
all
sorts
of
scope
that
we're
just
not
ready
to,
and
we
shouldn't
try
to
reinvent.
A
Exactly
okay
and
you
answered
my
other
question
here:
does
anyone
else
have
any
questions
or
comments
about
this.
A
A
All
right,
PHP
Bob,
had
mentioned
on
slack.
He
can't
make
today,
but
there
were
some
pretty
major
updates,
looks
like
the
alpha
of
metrics
is
out
wow,
considering
where
PHP
has
been
in
the
past.
That's
actually
really
impressive
and
the
pre-alpha
of
logs
I
don't
know
if
that's
out
or
has
just
gotten
started,
but
great
progress
on
PHP
or
Java.
We've
got
SDK
1.24
coming
out
instrumentation
releasing
this
week
and
moving
on
to
C,
plus
plus
1.83
was
released,
which
includes
the
logs
Bridge,
API
and
SDK,
as
per
the
specs.
A
Some
performance
improvements
for
metrics
and
build
improvements
all
right,
no
other
major
updates,
there's
one
and
feel
free
to
add
more
there's
one
other
major
item
on
the
docket
today.
A
After
now
that
we've
finished
Jack's
presentation
on
logs
and
that's
just
a
summary
of
the
governance
committee
and
Technical
committee
Summit
that
took
place
last
week
so
last
Tuesday
and
Wednesday-
we
had
all-day
meetings,
sort
of
partially
in
person,
partially
remote
with
I,
think
all
or
effectively
all
the
members
of
the
governance
committee
and
Technical
committee,
where
we
discussed
the
project
State
and
his
status
and
things
that
we
can
do
to
improve
the
project
and
and
various
other
tidbits
and
Daniel.
A
Not
to
put
you
on
the
spot
too
much.
But
I
was
wondering
if
you
wanted
to
co-present
with
me
some
of
the
the
things
we
discussed
and
some
of
the
findings.
This
is
somewhat
preliminary
because
I
don't
think,
we've
had
a
chance
to
really
sit
down
and
Munch
on
the
notes.
C
Yeah
I'm
happy
to
do
that.
I
may
have
to
walk
away
at
any.
Second,
though,
when
my
contractor
actually
arrives.
That's.
A
Fine,
do
you
want
to
start
presenting
and
then
I
will
sort
of
do
a
like
on
my
end,
I'll
copy,
whatever
you
have,
and
then
that
can
take
over.
C
Yeah,
so
what
I
can
say
is
we
had
various
I
think
eight
different
sessions
regarding
different
topics,
the
most
important
of
which
revolved
I'm?
Sorry,
my
contractor
is
actually
yeah.
I
have
to
go
no.
A
Worries
so,
as
Daniel
said,
we
had
these
meetings
last
week,
I'm
just
going
to
pull
up
our
notes,
I'm
not
going
to
start
presenting
them,
but
I'm,
just
going
to
speak
to
the
main
topics
that
we
discussed.
I
think
we'll
have
more
in-depth
conversations
about
this
on
the
maintainer's
call,
probably
starting
next
week,
just
because
this
was
this
is
still
very
fresh
and
so
people
haven't
had
a
chance
to
to
Really
synthesize
it
yet,
and
secondly,
Daniel
and
Ted
were
leading
a
lot
of
these
discussions.
A
Daniel
just
had
to
hop
off
and
Ted
is
in
here
this
week,
so
expect
more
on
this
next
week,
but
I
do
want
to
go
over
just
some
of
the
topics
we
discussed,
so
we
can
prepare
people
for
next
week,
so
one
of
the
core
ones
was
the
responsibilities
of
the
governance
and
Technical
committees.
A
This
has
been
not
nebulous
in
the
past
but
at
the
same
time
there's
certain
areas
where
the
responsibilities
haven't
been
fully
I
think
it's
defined
as
people
would
like,
and
this
has
popped
up
once
or
twice
recently,
but
it
sort
of
popped
up
sort
of
somewhat
consistently
throughout
the
project,
and
so
one
sort
of
repositioning
that's
being
considered
is
making
the
governance
committee
a
little
bit
more
involved
in
the
sort
of
product
management.
A
A
It's
been
seated
to
the
technical
committee
and
so
Ted
and
Alita
and
Austin
myself
are
writing
a
proposal
to
make
that
a
little
more
a
bit
of
a
formal
responsibility
of
the
governance
committee
and
Josh
sarath
also
be
collaborating
with
that,
just
to
also
clarify
the
the
gc's
role
in
core
project
governance.
A
Another
big
topic
was
the
donation
of
elastic
common
schema.
This
is
something
that
I
think
originally
popped
up
about
two
years
ago,
where
there
was
a
proposal
between
the
logging
Sig
within
open,
Telemetry
and
elastic,
to
bring
in
the
elastic
common
schema
to
extend
open,
telemetries
semantic
conventions.
We
have
a
great
set
of
semantic
conventions
that
I
think
we're
generally
very
happy
with,
but
they
only
describe
a
fairly
thin
set
of
things
and
they're,
also
not
1.0.
A
Yet
that'll
come
up
in
a
minute
elastic
bringing
in
the
parts
of
Alaska
kind
of
schema
that
are
not
conflicting
with
the
open.
Telemetry
semantics
would
be
an
interesting
way
of
rapidly
expanding
the
scope
of
our
semantics
and
taking
advantage
of
work
that
a
lot
of
very
smart
people
have
already
done.
So.
A
This
was
a
discussion
point
about
two
years
ago
and
it's
been
kind
of
quiet
since
then,
but
this
has
popped
up
again
recently
and
so
there's
there's
been
new
Outreach
between
elastic
and
I,
think
alolita
and
one
or
two
other
people
on
the
GC
and
TC
about
bringing
this
in
to
open,
Telemetry,
and
so
there's
that
may
end
up
happening
fairly
soon.
The
Crux
of
this
is
that
elastic
is
willing
to
make
changes
to
this.
A
So
what
it
looks
like
will
happen,
assuming
that
everybody,
you
know
we
sign
off
on
this-
would
be
we'd
bring
in
the
parts
of
ECS
that
don't
conflict
with
the
open,
Telemetry
semantics.
The
parts
of
ECS
that
do
get
that
do
conflict
would
most
likely
get
Rewritten
to
match
the
open,
Telemetry
semantics,
and
then
it
just
becomes
one
set
of
semantics,
all
governed
within
open,
telemetry,
so
exciting
stuff.
There
obviously
I'm
vastly
oversimplifying
the
amount
of
work
that
this
would.
This
would
take.
A
It's
it'd
probably
be
a
fairly
big
effort,
but
I
think
it
would
also
have
a
large
payoff
related
to
this.
There
was
also
a
conversation
about
the
stability
of
our
semantic
conventions.
There
are
many
that
I
think
are
unstable.
There
are
many
that
are
are
I,
think
in
practice
stable,
but
in
that
we're
not
rapidly
changing
them,
but
formally
they're
still
not
stable.
A
Yet
this
is
causing
some
consternation,
I
think,
with
maintainers
and
committers,
and
also
with
end
users
who
want
these
things
to
be
stable
and
so
Josh
and
Trask
and
gerasi
are,
are
going
to
be
putting
forward
some
proposals
on
how
we
can
more
rapidly
achieve
that.
Obviously,
the
elastic
donation
will
at
least
be
the
one
part
of
those
proposals,
or
at
least
be
referenced,
because
that's
going
to
fill
in,
ideally
that'll
fill
in
the
gaps
that
are
not
even
defined
with
an
open
Telemetry
at
all.
Today,.
C
Another
topic
was:
can
I
interject
here
real,
quick,
absolutely
yeah,
because
I
think
it's
important
for
this
group
in
particular,
one
thing
that
we
discussed
around
the
semantic
convention-
stability
and
what
I
believe
Morgan
was
about
to
talk
about
next,
which
is
contrib
stability.
Is
that,
as
the
specification
group
goes
about
stabilizing
semantic
conventions,
they're
doing
so
on
a
schedule
sort
of
one
at
a
time,
I
think
they
hope
to
go
faster
than
one
at
a
time
in
the
future.
C
But
that's
sort
of
the
the
Cadence
we're
on
right
now
and
as
they
go
the
the
proposal
and
keeping
in
mind.
This
is
just
a
proposal.
C
Is
that
as
they
stabilize,
they
will
be
expected
to
the
the
instrumentations
that
take
advantage
of
them
will
be
expected
to
stabilize
on
a
similar
time
frame
and
at
the
time
that
the
semantic
convention
stabilizes
the
TC
or
the
spec,
maintainers
or
or
whoever
would
then
determine
either
that
this
is
a
high
priority,
instrumentation
or
not,
not
to
say
that
that
things
aren't
the
highest
priority.
Aren't
they
also
important,
but
if
everything
is
important,
nothing
is
important
in
something
like
HTTP
is
obviously
more
important
than
you
know
something
else.
C
C
Obviously,
that's
all
very
hand
wavy
right
now,
and
it
is
just
a
proposal
which
is
subject
to
approval
by
the
standard
Otep
process
can,
since
it's
not
even
an
Otep.
Yet
it's
obviously
in
very
early
stages,
but
I
just
thought
that
that
was
important
for
for
this
particular
group.
A
Okay,
we
will
keep
going
and
again
we're
just
going
to
be
a
probably
several
deeper
discussions
about
this.
The
next
few
weeks
after
people
have
time
to
synthesize
this,
and
once
we
start
getting
some
of
the
docs
and
and
action
items
out
that
were
referenced
here.
Another
this
topic
was
just
better
ways
of
gathering
and
integrating
feedback
across
the
project.
A
Things
like
feature
trackers
voting
on
allowing
people
to
vote
or
or
put
more
weights
behind,
wanting
certain
instrumentations
or
features
or
Integrations
things
like
that,
and
there
was
another
conversation
about
the
probably
topic
people
don't
care
about
about
that
much,
but
the
moving
the
projects
of
the
cncf
graduated
status,
more
impactful
for
our
presence
at
Cube
anything
else.
So
I
don't
think
it's
a
super
high
priority
for
most
people,
but
Austin
had
given
an
update
on
that.
C
A
My
usual
expectation
for
any
kind
of
delivery
or
anytime
we
needed
to
be
at
the
door.
Yes,
all
good.
Okay,
that
was
it
for
the
core
set
of
topics.
I've
outlined
I'm,
just
going
to
check
the
notes
to
see
if
anything's
been
added,
I,
don't
think
so
any
other
topics
conversation
points
updates
that
people
want
to
provide
this
week.