►
From YouTube: 2022-09-07 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
Okay,
let's
start
yeah,
so
the
first
item
is
it's
your
pr
jack,
the
the
alignment
of
the
sdk
naming
within
the
new
api
thanks
for
creating
the
pr
by
the
way,
the
question
I
had
was
around
the
compatibility
matrix
that
we
have
right
now,
which
lists
the
features
that
are
implemented
in
java
and
python.
A
B
I
don't,
I
don't
have
a
strong
preference.
I
saw
your
comment.
I
think
it's
a
good
question.
If,
if
I
were
to
make
a
decision,
it
would
be
to
reset
the
compliance
matrix
and
go
and
file
issues
in
those
respective
repositories.
Java
and
python
to
you
know,
reflect
the
naming
convention
changes
and
going
up
afterwards.
A
A
So
if
let's
do
that,
since
there
are
no
opinions,
let's
do
that.
If
you
can
maybe
just
delete
the
the
check
marks
that
we
have
there
for
java
and
python
and
file,
I
don't
think
we
need
to
file
individual
issues
for
every
line
item
there.
Maybe
one
single
issue
for
java
and
one
for
python
should
be
sufficient
to
just
make
sure
that
the
maintainers
of
the
languages
are
aware-
and
it's
properly
tracked-
that
there
is
now
a
mismatch
between
the
existing
implementation
and
the
the
spec
and
yeah.
B
Yeah
that
sounds
reasonable,
I'll
comment
on
the
pr
and
then
go
ahead
and
file
those
issues
I'm
already
working
on
this
in
java,
I'm
changing
the
names.
We
we're
not
gonna,
we're
not
going
to
merge
that
pr
until
the
the
spec
pr
is
merged,
because
it's
kind
of
a
it's,
an
impactful
change
for
users
to
to
change
these
names.
So
we
we
want
to
make
sure
that
the
the
spec
is
pretty
confident
in
this
before
doing
that.
So,
but
we're
going
to
do
it.
A
Okay
yeah!
I
think
that's
fine,
otherwise,
I'm
good
with
the
pr.
This
is
great
and
I
think
christian
approved
already
so
david
and
then
you
guys
probably
need
to
take
a
look
at
the
pr
yeah.
Please
do
please
review
it.
A
B
One
quick
note
on
that
that
pr
so
t
green,
can
you
send
me
the
link
to
the
the
diagrams
to
yes.
A
I
I
need
to
I
need
to
yes,
I
need
to
add
you
using
your
email,
which
I
don't
have.
Can
you
dm
me
your
email
address
so
that
I
can
share
the
diagram
with
you.
B
Yes,
I
did,
I
sent
you
a
dm
just
this
morning,
but
it
wasn't
too
long
ago.
C
B
D
Yeah
so,
basically
to
summarize,
I
haven't
been
involved
in
the
log
six
until
recently,
so
maybe
this
was
a
decision.
It
happened
a
while,
but
my
understanding
of
the
logs
and
just
kind
of
globally
in
open
telemetry
was
there's
all
these
logging
libraries
out
there.
We
don't
want
to
be
yet
another
one.
So
there
was
a
conscious
effort
to
not
have
a
logging
api.
Essentially,
so
then.
D
A
Yeah,
we
still
are
right,
we're
still
not
creating
end
user
facing
purely
logging
library,
where
such
library
exists
in
the
in
the
ecosystem
of
the
particular
language.
There
is
log
for
j
in
java
world,
or
whatever
s,
log
back
or
others
right,
we're
not
going
to
create
yet
another
one
which
competes
with
those
loading
libraries.
A
The
use
cases
that
we
have
are
two
one
is
to
provide
means
for
those
existing
logging,
libraries
to
create
open,
telemetry
compliant
log
records,
and
that
is
not
a
new
use
case.
It
existed
in
the
past
as
well.
The
new
use
case
is
the
second
one,
which
is
to
create
structured
events
in
a
way
that
is
not
possible.
A
D
D
In
the
dot
net
repo
sig,
where
there's
the
log
emitter
thing
in
sdk,
so
we
have
a
couple
log
appenders
for
some
dot
net
libraries
that
are
implemented
just
with
a
ref
to
sdk.
So
we
didn't
need
anything
in
api.
D
A
A
That
is,
that
is
a
very
uncomfortable
way
for
the
users
to
do
the
logging
in
their
applications
right
and
on
purpose.
We
didn't
create
an
ergonomic
logging
api
there
to
avoid
competing
with
the
existing
proper
logging
apis.
Is
it
possible
to
use
it
as
a
logging
library?
I
mean
yes,
you
can
do
that,
but
that
is
not
the
purpose.
I
think.
Maybe
we
need
to
be
clearer
about
it,
but
we
try
to
call
it
out
in
the
api
that,
yes,
it's
it's
an
api.
You
can
make
a
call.
It
will
end
up
emitting
log
records.
A
Should
you
use
that
instead
of
the
logging
library
you
have?
No,
we
don't
think
so
right.
We
would
think
that
you
should
chain
the
the
calls
should
first
go
to
your
proper
logging
library,
which
then
have
this
appender
or
whatever.
Is
that,
then,
we'll
make
a
call
to
this
lower
level
logging
api,
which
will
which,
which
only
accepts
entire
log
records
right?
A
It's
it's
just
not
nice,
to
call
it
nice
to
use
it,
hopefully,
by
doing
it
by
structuring
it
that
way,
we
we
discouraged
people
to
to
to
use
it
instead
of
the
the
proper
logging
libraries
they
already
have
in
their
language.
If
we,
if
that's
not
good
enough,
I
guess
we
we
need
to
do
more,
maybe
to
clarify
this.
D
D
B
Well,
so
I
I
think
one
thing
I'd
like
to
add
is
that
you
know
all
these
producing
and
metrics
have
this
api,
sdk
distinction
and
logs
were
an
outlier,
and
so
I
think
part
of
this
decision
to
introduce
a
like
a
log
api
rather
for
the
appender
use
case.
Rather
than
telling
appender
implementations
to
use
the
sdks
api
was
to
bring
logs
into
alignment
with
the
other
signals.
B
D
A
A
D
Basically,
what
I
have
is
a
life
cycle
problem
here.
I
just
read
this
briefly,
but
it's
saying
you
should
basically
get
like
the
emitter
thing:
the
logger
provider,
through
the
default
that
right
there
is
a
big
challenge
for
me
because
there's
different
login
frameworks,
and.net
some
of
them
are
the
first
thing
you
initialize.
D
Some
of
them
come
later
on
once
the
host
like
dependency
injection
container,
is
available,
so
I
don't
necessarily
have
a
time
when
I
know
what
the
default
tracer
provider
is.
I
don't
know
when
it's
going
to
exist,
it's
kind
of
up
to
the
user.
We
provide
different
ways
for
them.
They
can
create
it
manually
and
own
it
fully.
They
can
extend
sort
of
dominance,
dependency
pipelines,
it's
part
of
like
the
host
startup,
so
just
trying
to
implement
this
log
appender.
D
I
don't
know
how
I'm
going
to
do
it's
it's
going
to
create
some
weird
coupling
problems
for
me
that
don't
really
exist
today,
just
through
the
nature
of
everything
is
built
through
the
sdk
off
of
the
tracer
provider.
So
if
you
want
to
do
a
log,
appender
todayin.net,
you
have
to
first
set
up
your
provider,
your
log
provider,
your
trading
provider,
whatever,
once
you
have
that,
then
you
can
hand
it
to
your
appender
and
it's
going
to
set
up
through
the
logging
line.
D
So
just
through
the
nature
of
how
it's
set
up,
I
don't
have
a
life
cycle
problem.
It's
just
kind
of
natural
if
you're
doing
your
logging
first,
so
you
can
capture
like
every
possible
type
of
exception.
Then
you
basically
build
your
logger
provider.
All
your
providers,
you
spin
up
your
blogging
library,
you
attach
everything.
Then
you
go
into
kind
of
your
application
startup,
so
it
all
just
sort
of
works,
maybe
unintentionally
but
nicely,
whereas
if
now
it's
through
the
api,
I
just
don't
know
how
I'm
going
to
solve
it,
and
we
thought
about
it
briefly.
B
D
B
So
I
guess
I
can
try
to
give
some
context
in
terms
of
this
in
java,
because
in
java
we
have
a
log
for
j
style
appender
and
we
have
globals
so
like
a
google
open
telemetry
instance
that
holds
instances
of
tracer
provider
meter
provider
and
eventually
it
will
hold
a
global
logger
provider
as
well,
and
so
the
way
that
the
logger,
the
log4j
appender
works,
is
so
effectively
your
logs.
Won't
your
logs
loaded
through
the
appender
and
through
the
open,
telemetry
sdk.
B
Until
you
set
up
your
global
open
telemetry
instance,
so
you
know
you're
not
going
to
have
100
percent
of
logs
unless
you
can
yeah-
and
I
guess
the
the
earlier
that
you
instantiate
your
global
open
telemetry
instance.
The
more
likelihood
you
have
a
comp
all
your
logs,
but
I
think
it's
always
possible
that
something
will
be
able
to
log
before
you
set
that
up
and
so
the
there's
the
possibility
that
some
some
logs
won't
flow
through.
But
you
know.
A
D
B
A
B
Yeah,
that's
that's
right!
So
in
log4j
you
know
you,
you
have
an
a
number
of
different
appenders
to
choose
from
from
ones
that
are
built
into
these
custom
openers
like
the
one
that
we're
talking
about
this
custom
opener,
which
bridges
those
logs
into
open
telemetry,
and
so
you
know
this
open,
telemetry
appender
would
effectively
just
be
sending
the
logs
to
a
no
op
implementation
until
one
is
provided.
A
B
B
Because
there's
a
log
for
j
and
the
other
log
framework
ability
to
obtain
a
logger
for
with
different
names
and
the
names
are
often
fully
qualified
class
names
in
java,
and
so
our
log
for
j
appender.
Just
you
know,
for
every
log
that
we're
processing
it
obtains
a
new
logger
for
each
effectively
full
full
last
name
or
each
logger
name.
That
is
comes
in.
D
Then
people
could
ship
like
a
message,
bus
that
takes
a
dependency
on
open,
telemetry
api
and
just
calls
that
has
its
logging
apr
right.
There's
no
reason
it
couldn't
be
done.
That
way,
there's
a
note
in
there
that
it
shouldn't
be,
but
we
are
essentially
opening
the
door
to
that
use
case.
I
don't
know
if
it's
a
problem,
something.
A
A
D
It's
a
good
question
I
feel
like
having
it
exclusively
in
sdk
would
prevent
more
libraries
from
doing
that,
because
they'd
have
to
take
a
dependency
on
the
sdk
and
their
at
least
in.net
carries
with
a
whole.
You
know
tree
of
transit
dependencies,
so
I
feel
like
just
by
nature
of
it
being
an
sdk
discourages
that
case,
even
though
it
could
be
done,
whereas
when
we
put
it
in
api,
it
becomes
more
tempting
so
just
to
make
sure
we're
all.
Okay
with
that
temptation
and
potential
use
case.
A
Yeah,
that's
a
good
point.
I
I
don't
know.
Does
anyone
know
if
there
is
a
reason
why
this
may
become
a
problem
like
people?
Let's
say
it's
not!
The
api
is
not
intended
to
be
used
to
be
called
directly
from
the
from
the
application
code,
but
people
still
do
that
because
it's
easy
it's
possible
to
do
right.
It's
it's
available.
A
B
One
thing
that
comes
to
mind
is
so:
if
they're
using
the
api
like
they're
using
eyes
of
other
log
frameworks,
then
they
might
expect
the
same
types
of
tooling
to
be
able
to
be
available.
In
terms
of
you
know
how
how
those
logs
are
export,
either
out
of
process
order,
files
or
filtered
et
cetera,
and
I
you
know
I-
I
don't
think
that
that's
an
actual
problem.
I
think
we
just
need
to
make
our
our
communication
clear
that
around
our
capabilities
that
you
have,
for
you,
know,
filtering
and
exporting
logs
yeah.
A
So
I
guess
we
need
to
be.
I
guess
we
need
to
have
a
firm.
I
guess
position
there
and
and
reject
the
the
request
to
to
expand
that
api
and
turn
it
into
an
actual,
proper
full-blown
logging
api,
with
all
of
the
capabilities
that
that
log4j
has
or
whatever
is
there
right.
So
we
we
should
avoid
doing
that.
That
still
should
remain
our
position.
A
We
should
we
should
keep
keeping
it
as
simple
as
it
is
right
now,
without
without
adding
more
and
more
capabilities
there.
So
I
guess
the
danger
here
is
that
there
may
be
an
elevated
expectation
from
the
users
as
soon
as
they
discover
the
taste
of
using
it.
They
may
start
asking
for
more
and
we
need
to
be
firm
not
to
give
that
that
more
capabilities
there
so
yeah,
I
don't
know.
B
And
I
think
it
I
think
it's
built-in
capabilities
right,
because
there
are
conditionable
capabilities
just
in
the
processor
and
exporter.
You
know
plug-in
architecture.
So
you
can,
you
can
do
a
lot
of
filtering
and
you
can
build
exporters
that
do
a
a
lot
of
different
things.
But
you
know
it's
it's
a
question
of
which
do
we
provide
out
of
the
box,
and
so
I
think
very
few.
C
I'm
not
100
sure
on
this,
but
I
have
a
feeling
that
android
side,
the
log
appenders,
may
not
be
supported
by
the
log
api
of
android,
in
which
case
people
might
tend
to
use
this
api
directly
to
generate
logs
if
we
needed
a
way
to
ship
the
log.
So
so
in
cases
where
the
languages
don't
support
the
logging
libraries
don't
support
an
appender
style
mechanism,
then
they
might
tend
to.
You
know,
use
this
library.
C
I
think
there
is
a
android.util.log
to
some
such
library
in
the
android
apis.
B
And
it
doesn't
have
a
facility
for
I
think.
C
A
I
guess
sometimes
you're
saying
what
happens
if,
if
in
the
particular
language
or
environment,
there
is
no
way
to
have
the
suspenders
that
will
recommend
right.
What
do
we
do
in
that
case?
Yeah?
That's
a
good
question.
I
guess
then,
there's
no
other
choice
than
to
go
and
build
a
logging
library
right.
That's
what
c,
plus
plus,
I
think
decided
to
do,
because
they
didn't
have
a
good
choice
of
a
loading
library
that
they
could
rely
on
and
they
they
built
their
own
and
that
that's.
A
We
knew
that
it's
a
possibility,
like
we
knew
some
languages,
simply
don't
have
a
good
industry
standard
logging
library
that
you
can
rely
on
we're
still
resisting
it
as
much
as
we
can
in
the
specification
but
yeah,
maybe
it's
unavoided
or
unavoidable
in
some
some
languages
or
some
some
environments
like
android.
If
that's
the
case,
what
do
we
do
there
like
outright
refuse
to
have
anything
like
if
the?
A
C
I
think
that
would
be
an
sdk
implementation,
a
bit
like
for
the
browser
like
there
is
no
standard
logging
library,
unless
you
want
to
capture
the
console,
but
that
doesn't
preclude
someone
going
and
writing
an
sdk
that
then
uses
the
api.
A
Yeah
yeah
exactly
exactly
I
guess:
someone
can
go
and
write
a
logging
library
for
others
to
use
and
that
logging
library
can
rely
on
our
highly
limited
api
to
to
to
emit
the
log
records
right,
and
I
don't
think
we
should
try
to
prevent
that.
If
people
want
to
do
that,
maybe
that's
the
only
choice
for
that
particular
language
or
environment,
then
so
be
it
right.
That's
a
that's
a
valid
use
case.
A
A
A
And
yeah
welcome.
Thank
you
for
joining.