►
From YouTube: 2021-10-25 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Doing
great
doing
great
as
her
as
usual,
it
would
be
great
to
get
a
check
in
different
maintainers.
D
A
Yeah,
starting
with
the
spec
yeah
maintainers,
can
fill
out
their
section
real,
quick,
the
maintainers
for
present.
A
No
we're
just
maintainers
could
fill
in
their
respective
sections
on
updates.
E
A
G
A
A
But
yeah,
maybe
we
can
do
a
shout
out
again
at
our
respective
companies
and
on
the
internet
and
we're
looking
for
more
php
maintainers.
That
would
be.
D
H
H
Right
now,
yeah
right
now,
we
want
to
finish
the
api
first
and
we're
making
whatever
sdk
changes
are
required
to
get
the
api
correct.
But
then,
once
that's
done,
we'll
focus
on
making
the
sdk
actually
compliant
with
smacks.
Awesome.
A
I
A
J
To
address
some
bugs
yeah,
I
can
kind
of
talk
about
that
yeah,
so
we
plan
to
do
a
little
bit
of
a
bug
release
last
week,
just
a
bunch
of
cleanup
after
the
stable
release
we
found
more
so
still
working
on
that
and
so
yeah.
We
delayed
decided
to
delay
until
this
week.
J
It's
not
really
critical,
I
think,
but
we
wanted
to
try
to
get
a
few
more
fixes
in
to
this
release
so
hoping
to
get
that
out
this
week
we
also
have
identified
two
new
features
that
we
really
want
to
try
to
address
in
the
near
term
and
add
them
into
the
projects,
one
of
which
is
sdk
logging.
This
is
not
to
be
confused
with,
like
the
logging
signal
itself,
but
this
is
around
troubleshooting
and
debugging,
and
that
kind
of
thing
and
then
environment
configuration.
J
We
currently
support
some
configuration,
but
we
want
to
try
to
address
the
other
parts
of
the
specification
that
we
don't
support
for
environment
configuration
to
provide
compatibility.
So
we
have
two
two
new
projects
to
track
those.
A
Awesome
yeah,
actually
sdk
logging.
I
know
something
diego's
working
on
in
python.
That's
actually
an
area
of
the
spec
that
I
think
is
a
bit
underspecified
right
now
around
you
know.
We
say
that,
like
the
api
shouldn't,
throw
exceptions
or
return
errors,
but
it's
pretty
big
past
that
point
about
what
should
be
done
with
those
things
and
for
dynamic
languages.
A
It's
actually
even
a
little
more
confusing,
because
how
far
does
like
should
not
throw
go,
for
example
like
what,
if
you
just
pass
like
you
know,
arbitrary
garbage
parameters
into
an
api
call,
you
can't
do
that
in
a
typed
language
because
it
won't
compile,
but
you
can
do
that
in
a
dynamic
language
so
like
should
it
swallow
all
of
that
stuff
too
or,
like
you,
know,
where's,
or
should
it
blow
up
if
you've
just
genuinely
misused
the
api
and
passed
it
stuff
that
it
doesn't
take?
A
So
that's
the
thing
they're
working
on
wondering
about
in
python,
because
people
are
wondering
about
that
in
other
languages.
Maybe
that's
something
people
could
get
together
about.
I
I
yeah
actually
ted.
I
I
had
have
been
working
on
this
prototype
for
handling
python
and
I
have
so
far
discovered
a
few
things
that
I
hadn't
considered
some
time
ago,
the
issue
of
crashing.
If
bad
parameters
are
being
passed,
I
think
now
it's
a
pretty
minor
with
the
rest
of
the
stuff
that
I
don't
think
it's
relevant.
I
I
think
it
definitely
will
I
mean
making
a
correct
implementation
of
this
mechanism
will
have
an
impact
on
the
api
design
and
the
way
that
it
interacts
with
the
sdk.
I
will,
with
these
new
stuffs,
that
I
have
I'll
try
to
put
a
prototype
as
soon
as
possible
so
that
I
can
show
you
and
discuss
it
with
you,
so
I
can
give
you
better
information.
J
A
K
Yeah,
we
definitely
need
more
contributors
when
we
have
some
contributors
coming
doing
some
patch
kiss
and
bug
fixes,
and
then
they
give
out.
So
we
need
somebody
who
can
work
on
long
term
for
at
least
metrics.
A
A
So
again,
if
people
could
maybe
go
back
to
their
place
of
work
and
say
hey,
we
need
some
some
additional
people
power
on
c
plus,
because
I
think
it's
the
number
of
companies
contributing
to
it
right
now.
It's
pretty
limited
right.
It's
like
mostly
microsoft,.
K
L
A
Yeah,
but
I
mean
this
will
matter
more
when
it
comes
to
integrating
with
service,
not
application
services,
but
more
like
things
like
nginx
and
databases
and
other
other
stuff,
like
that.
That's
that's
a
very
common
use
case
for
this
yeah.
L
Lower
level
services
and
also
the
frameworks
that
have
plugins,
for
example,
like
you,
use
a
c
plus
plus
engine,
and
then
you
allow
python
and
other
higher
level
language
to
write
on
top
of
it,
and
then
you
want
a
consistent
traits
across
different
languages
from
the
same
process.
I
think
there
are
many
folks
asking
for
this
feature,
but
people
who
have
knowledge
both
sides
and
being
able
to
solve
that
issue.
Actually
the
population
is
small
and
it
seems
so
far
most
of
folks
are
coming
from
microsoft,
like
the
os
group
and.
A
Okay,
I'll
try
to
reach
out
I'll
try
to
reach
out
at
light
set
see
if
we
can
bring
someone
in
from
there,
but
if
other
people
their
orgs
can
reach
out,
I
feel
like
there
has
to
be
people,
especially
at
some
of
the
big
companies
who
have
excellency
c
plus
developers,
who
could
help
with
this
all
right
and
there's
a
blog
post,
good
timing
to
share
that
blog
post
around,
maybe
as
part
of
recruitment
effort,
doesn't
look
like
there's
any
ruby
updates.
A
M
Well,
pretty
good
we're
getting
a
lot
of
traction:
nice
just
trying
to
sort
out
how
to
deal
with
changes
in
the
apple
support
on
ios
and
stuff
like
that
and
how
we
represent
that
in
simber
a
little
a
little
tricky.
We
only
got
three
numbers,
so
we
kind
of
want
to
reserve
the
major
version
for
open
telemetry
changes
and
we'll
have
to
figure
out
the
rest
from
there.
A
M
A
Yeah
yeah,
it
seems
like
that
would
be
worth
a
major
version
bump
of
the
of
the
sdk,
I'm
not
sure
if
have
maintainers
dealt
with
this
from
other
languages.
I
know
java
did
this
at
one
point,
but
maybe
they
were
still
in
beta.
M
L
Yeah
double
check
in
doughnut
we
we
dropped
the
very
old
version
which
has
been
declared
by
by
the
donut.
That's
unsupported
and
the
reason
is
for
security,
and-
and
in
that
case
we
don't
bounce
the
version,
because
all
the
apis
are
still
compatible
when
people
use
the
supported
version.
So
from
their
perspective,
there's
no
point
but
people
who
are
using
the
old
version
we
have
mentioned
in
the
documentation
that
they
can
stick
with
the
old
version
and
we
won't
maintain
them
because
the
donut
runtime
itself
is
unsupported.
M
L
M
A
C
We
have
a
similar
issue,
we
need
to
address
and
go
as
well.
Currently,
our
minimum
supported
version
is
115,
but
that's
out
of
support
upstream.
They
only
support
the
last
two
versions
so
currently
116
and
117,
and
that's
going
to
be
on
a
six-month
rolling
cycle.
So
every
six
months
one
of
those
is
going
to
fall
off.
C
C
Yeah-
and
I
think
we
end
up
in
this
at
least
and
go
we
end
up
in
the
same
position
that
the
writer
is
discussing
with
net
right,
the
api
itself
hasn't
changed
in
an
incompatible
way.
It's
just.
We
may
start
making
use
of
features
in
newer
versions
of
the
language
that
will
drop
support
for
older
versions
and
and
so
it's
not
a
not
really
a
backwards,
incompatible
change.
It's
just
a
I'm,
not
sure
how
you
describe
that
sort
of
incompatibility.
A
B
A
Is
it
a
smooth
path
where
people
are
not
expected
to
have
any
trouble
to
bump
up
to
the
latest
version
of
co,
because
they're,
just
they're
like
us,
they're
just
adding
things
they're,
not
they're,
not
putting
any
bear
traps
out
into
the
road
versus
a
like
python,
2
to
python
3,
or
you
know
some
major
language
rev
where
actually
dropping
support,
would
would
mean
significant
work
for
for
people
who
were
on
the
older
version
of
the
language.
M
Well,
I
added
a
link
to
the
discussion
that
were
that
we
added
to
the
repo
there.
So
if
anybody
wants
to
chime
in
great.
B
M
Yeah,
I
think
that
histograms
might
have
been
the
last
major
metric
type
that
we
were
missing
awesome,
I'm
not
sure
if
the
full
functionality
is
operating
correctly
but
yeah
I
mean
I'm
using
it
in
my
in
my
work
at
elastic,
so
it
seems
to
be
doing
what
it
should
be
awesome,
so
so
you're
using
it
in
production
at.
A
M
A
N
Okay,
hi
everyone.
I
have
promised
to
give
a
presentation
to
the
go
sig
this
thursday.
I
keep
failing
to
produce
this.
This
sort
of
summary
of
where
we
are
the
sdk,
is
in
good
shape.
N
A
Awesome
well
in
general,
this
is
making
me
feel
good
with
the
the
sdk
going
into
feature
freeze.
Hopefully
in
like
a
week,
it
looks
like
if
end
of
october
is
really
the
goal,
then
we've
got
several
implementations
that
are
like
pretty
far
along.
So
that
means
rolling
into
beta
for
metrics
by
before
end
of
the
year
is
like
actually
a
feasible
goal,
which
just
makes
me
really
happy
so
good
job
everybody
pushing
hard
on
that.
A
A
Okay,
yeah
yeah
in
general,
more
approvers
and
contributors
to
collector
would
be
great,
but
I
guess
don't
be
a
stranger.
A
And
then
erlang
tc
review
for
ga
the
tc
gets
to
learn
early.
It's
a
lot
of
fun,
it'll
be
good
for
you,
tc,
okay,.
L
L
And
that
the
second
question
I
haven't
seen
rust
here
looks
like
rust
is
getting
popularity
from
the
repo.
So
I
added
the
last
topic.
Maybe
next
time
we
can
cover
that.
A
Yeah
I
feel
like
the
the
rest
community
is
chugging
along
on
its
own,
but
is
a
little
disconnected
from
the
rest
of
the
community.
I'm
gonna
try
to
start
going
to
the
rest.
Sig
the
rest
sig
meets
tomorrow,
tuesday
3
p.m,
pacific,
so
it
might
be
good
tc
or
just
some
other
maintainers
or
core
contributors
who
are
interested
to
maybe
start
poking
around
the
rest
world
it'd
be
nice
to
have
a
rest.
Maintainer
come
to
this
call,
but
maybe
we
can
go
reach
out
to
them.
It's
the
first
step.
O
Actually,
I'm
one
of
the
rough
maintainers-
oh
hey
yeah,
like
I'm
just
checking,
so
I
haven't,
had
a
skate
meeting
for
a
while.
So
personally
I
have
something
to
deal
with
being
a
previous
mountain,
so
I
haven't
contributed
as
much.
O
A
Okay
yeah,
maybe
this
is
something
carlos.
I
see
we
have
at
least
one
tc
member
on
the
call
you
know
we're
doing
like
we
tend
to
reserve
these,
like
reviews
for,
like
you
know
at
the
very
end-
and
I
know
in
the
case
of
like
c
plus,
plus
and
other
languages-
that's
that's
been
a
bit
of
a
surprise,
sometimes
where
people
are
like
cool
we're
super
late
in
beta
we're
coming
out
with
a
release
candidate,
and
then
they
find
out
that
they
were
like
there's
some
thing
in
the
spec.
A
That
would
cause
the
tc
to
ask
them
to
to
do
something
differently,
rather
than
that
happen
to
rust,
maybe
the
tc.
Could
someone
from
the
tc
could
like
do
do
like
an
early
review
of
the
current
state
of
rust
and
give
them
some
some
feedback.
O
A
Awesome
awesome.
Thank
you
great.
Okay,
I
think
that's
the
the
end
of
the
maintainers
check
in
unless
anyone
has
any
final
report
backs,
they
wouldn't
give
seems
good
okay
on
to
the
the
rest
of
the
business.
So
I
have
a
thing.
This
is
a
question
from
the
gc.
A
We
are
interested
in
what
the
current
state
of
open
tracing
compatibility
is
in
different
languages.
So
the
reason
for
this
is
open.
Telemetry
is
now
incubating
in
the
cncf
and
we
would
like
to
archive
open
tracing,
which
is
the
cncf
retirement
plan.
This
would
be
helpful
because,
there's
still
you
know
from
outside
of
the
community,
there's
still
some
confusion
about
which
project
people
should
use,
and
we
really
want
to
push
everyone
to
to
open
telemetry.
A
So
we'd
like
open
tracing
archived
on
the
open
tracing
websites,
we'd
like
to
say
this
is
this
is
done,
go
use
the
new
thing.
However,
one
of
the
requirements
is
that
for
every
language
that
we
have
an
implementation
in
hotel
and
there's
pre-existing
open
tracing
implementation-
or,
I
should
say,
pre-existing
open,
telemetry
open
tracing
api,
because
there
is
no
implementation
that
we
supply
an
open
tracing
bridge
that
is
as
compatible
as
possible.
I
think
there
are
some
issues
around
things
like
baggage.
A
And
the
open
tracing
api
not
taking
context
in
some
language,
for
example,
but
in
general
support
for
open
tracing
instrumentation,
seems.
B
A
A
requirement
we
need
to
have
before
we
can
before
we
can,
you
know,
be
honest
and
actually,
you
know
say
we're
shutting
down
open
tracing
in
this
language
because
there's
a
replacement,
so
I
was
actually
curious.
I
know
we
have
done
work
in
a
number
of
languages
to
support
open
tracing
bridge,
and
I
was
just
wondering
what
the
current
state
is.
A
So,
if
maintainers
just
wouldn't
mind
writing
into
the
meeting
notes
right
now,
just
in
your
language
or
a
language
that
you
know
about
what
the
current
state
is,
if
the
state
is
there,
there
is
no
bridge
right
now.
That's
fine
just
report
that
as
well,
and
this
will
give
us
a
sense
of
how
much
work
there
is
to
be
done
before
we
can
before
we
can
do
that
archiving
process
and
the
cncf
is
bugging
us
about
this,
which
is
partially.
Why
I'm
asking?
A
A
A
So
go
bridge,
we've
got
one:
we've
got
one
in
js,
snow
bridge
and
php.
That
net
has
a
sham.
You
know
if
anyone
knows
the
state
of
java.
E
J
J
When
you
say
the
specifications
experimental
for
the
bridge,
I
thought
there
was
a
pretty
stable
statement
saying
that
you
needed
to
provide
backwards,
compatibility
for
it
as
a
part
of
the
specification,
but
maybe
I'm
missing
something.
What
part
are
you
referring
to?
Carlos.
E
The
important
thing
is
that
in
open
tracing
spam
context
and
backus
were
in
the
same
instance,
so
how
to
group
them
and
how
to
propagate
them
is
what
is
defined
mostly
and
a
few
other
things,
but
so
yeah.
The
idea
in
general
is
that
we
support
open
tracing
like
totally
but
the.
How
is
so
some
of
the
details
of
the
how
are
mentioned
there.
Let
me
just
space
it
here.
E
Else,
well,
it's
well
yeah!
There's
there
are
some
things
about
error
mapping.
You
know
how
to
map
that
it's
probably
very
straightforward,
but
we
need
to
have
all
the
language
to
do
exactly
the
same
thing:
okay,
but
yeah.
Of
course
the
the
big
portion
is
the
backus
handling.
A
Know,
okay,
so
yeah
more
work
and
again
I
don't
want
to
distract
everyone
by
context,
switching
over
to
a
bunch
of
open
tracing
stuff.
So
we
can,
I
think,
tackle
that
as
a
community
after
metrics
feels
like
it's
a
good
place,
we
have
some
breathing
room,
but
it's
good
to
know
that
there
are.
A
E
Yeah,
this
is
a
very
important
issue
or
pr
sorry.
Basically,
there
were
two
related
prs
field
and
basically
we
were
wondering
like
for
other
propagators.
It
wasn't
clear
as
long
for
other
environment
variables
what
to
do.
If
you
specify
an
explicit
empty
value
and
of
course
now
we
want
to
have
for
the
other
propagators
variable.
E
For
example,
we
want
to
say
that
you
have
specified
known
explicitly
to
say
that
there's
nothing
to
propagate,
you
know
you
will
not
propagate
anything,
and
the
thing
is
that
this
may
be
a
breaking
change
for
some
languages,
so
we
wanted
to
see
what's
the
actual
case.
E
Do
maintainers
have
a
feeling
that
this
could
be
breaking
anybody
like
or
what's
the
current
handling
there?
What
do
the
what's
happening
in
there?
I
would
say-
and
you
use
an
a
small
clarification
before
that
we
already
asked
in
other
similar
environment
variables,
to
have
explicit
known,
which
means
that
if
you,
if
you
have
an
empty
value,
is
going
to
use
the
default.
E
E
Okay,
if
there
are
no
comments,
please
consider
following
it
up
later
today
or
in
the
following
days,
and
let
us
know
we
are
planning
to
do
a
release
of
the
spec
next
week,
hopefully
like
the
monthly
cadence,
and
it
would
be
nice
to
be
sure
that
we
are
not
impacting
anything
too
badly
worst
case,
we'll
just
postpone
it
for
the
next
release.
But
it
would
be
nice
to
get
an
idea.
A
Yeah
great,
so
people
are
probably
gonna
bug
you
about
not
just
none,
but
I
I
accept
propagation
in,
but
I
don't
propagate
out
and
then
people
are
gonna.
Wanna
get
really
tricky
about.
A
Actually
I
wanna
propagate
here,
but
not
this
other
place,
because
that
goes
out
to
some
third-party
service.
So
this
is
one
of
those
I
think
in
the
long
run
related
to
some
of
that.
Targeting
work
we've
danced
around
in
the
past
around.
How
do
you?
K
J
J
J
Yeah
we
have
like
we've
talked
about
this
in
the
past
environment
variables
are,
I
don't
know,
let's
just
say,
not
cutting
it.
That's
a
debate
in
itself,
but
like
yes,.
J
A
So
I
know
this
is
something
bogdan
has
a
lot
of
interest
in
and
he's
writing
a
proposal
right
now,
but
I
think
we're
we're
a
little
weighed
down
with
with
metrics
and
some
other
things,
but
it
is.
It
is
something
that's
on
my
on
my
mind.
It
feels
to
me
that,
like
right
now,
there's
not
enough
bandwidth
to
to
really
dive
deep
into
it,
though
unfortunately
yeah
I.
J
A
But
bogdan
it's
every
time
you
talk
about
just
like
I
have
ideas,
I'm
gonna
write
a
thing,
but
he's
he's
busy
and
for
me
the
the
main
thing
I
keep.
I
mostly
push
back
on
adding
one-off
versions
of
this.
It
comes
up
in
several
different
areas.
It
comes
up
in
view.
Configuration
is
specifically
like
a
predicate
language
for
for
targeting
like
how
do
we
target
things
view
configuration
sampling.
A
Instrumentation
enablement
or
just
any
per
span
or
per
instrumentation
manipulation
of
some
kind.
A
A
In
the
meantime,
people
can
build
this
crap
into
plug-ins,
so
one
example
of
this
is
the
jaeger.
Has
a
remote
config
plug-in
for
sampling?
That's
fine!
I
just
don't
want
open
telemetry
to
have
some
official
way
of
configuring,
this
kind
of
stuff.
Until
so,
we've
sorted
all
these
details
out,
but
yeah.
It's
something,
I'm
keeping
track
of
tyler,
but
yet
no
one's
pushing
gonna
push
this
on
the
maintainers
anytime.
Soon
yep
sounds
good.
A
Okay,
tristan's
writing
some
things
because
he
can't
talk
got
an
otep,
almost
ready
for
per
config
named
tracers,
which
covers
this
stuff,
not
environment,
variable
config
file
stuff,
but
for
I
want
to
propagate
here,
but
not
there,
because
it
handles
the
ability
to
configure
a
specific
instrumentation
library
to
have
a
specific
config
yeah.
It's
a
great
example
and
yeah
proper
gauges
aren't
in
the
tracer
config
yeah.
That's
true,
that's,
I
think
part
of
the
tricky
bit
with
propagators
their
own
separate
thing,
but
yeah
worth
looking
at.
A
A
People
are
going
to
want,
especially
around
baggage,
is
like
it's
very
difficult
to
understand
when
to
drop
baggage
and
when
to
propagate
it,
because
there's
no
concept
of
a
trust
boundary
or
a
network
boundary
generally
speaking
like
as
a
mechanism
open
telemetry
can
rely
upon,
so
it
really
does
come
down
to
configuration
of
some
form
or
using
service
mesh
or
network
proxies
to
scrub
this
stuff
out
of
it
tricky
tricky
thing,
not
a
basic
use
case,
but
long
term,
we'll
want
to
solve
that
for
people
who
care
about
security,
okay
enough
on
propagators,
the
hotel
road
map.
G
A
Yes,
so
some
context
here
is:
we
want
to
have
a
much
better
roadmap
and
like
public
status,
page
for
open
telemetry.
This
is
probably
one
of
the
biggest
pieces
of
feedback
we
get
from.
A
The
community
is
they're
excited
about
open
telemetry,
but
it's
very
hard
to
understand
what
the
state
of
the
project
is
and
where
what
are
expected
timelines
and
things
like
that,
which
is
understandable,
because
it's
a
big
project
and
we're
not
done
yet
so
josh
is
trying
to
put
together
a
blog
post
on
the
state
of
open
telemetry
and
then
we're
going
to
use
this
to
make
a
more
detailed
version
of
the
open,
telemetry
status
page.
There
is
a
status
page
right
now
that
gives,
I
think,
important,
high-level
information
about
the
project,
but.
A
Josh's
main
request
is:
if
maintainers
could
could
look
through
this
and
and
just
update
or
confirm
the
sections
related
to
their
language.
So
he'd
like
to
to
just
have
like
a
basic
table
of
you,
know
traces
metrics
logs,
like
what
what's
the
current
state
of
things.
So
that's
that's.
The
main
request
have
a
look
at
what's
supported
in
your
language
and
what
degree
the
that
stuff
is
present
in
this.
This
talk,
so
that's
a
big
thank
you
from
from
me
and
josh
to
everyone.
D
J
Yeah
so
just
kind
of
we
touched
on
this
topic
and
I'm
guessing
well,
I
hope
other
people
care
about
it,
if
not
like
I'm
happy
to
just
move
on
but
like
in
looking
at
sdk
logging
in
the
ghost
we
kind
of
touched
on
a
bunch
of
issues,
and
it
wasn't
as
straightforward.
I
think,
as
as
we
would
have
liked
it,
and
I
think
that's
in
part
due
to
go
not
having
kind
of
like
a
standard
logging
package
but
kind
of
just
breaking
it
out.
J
I
noticed
first
off
that
the
sdk
we
were
talking
about
it
being
underspecified.
One
of
the
things
I
did
notice
is
that
the
logging
levels
that
are
specified
there
are
info
and
that's
it
and
that's
just
like
the
default
logging
level,
but
there's
no
real
guidance
as
to
like
what
levels
need
to
be
supported.
J
This
is
going
to
be
a
compatibility
issue,
so
if
you
have
any
sort
of
logging,
which
I
think
is
only
ruby,
erlang
and
js,
currently
that
I
saw
support,
although
tristan
did
mention
that
he
doesn't
actually
think
the
erlang
support
for
the
environment.
Variable
is
hooked
up
so
yeah,
I
don't
know.
I
guess
ruby
and
js
right
now
support
the
environment
variable
for
logging.
So
take
a
look
at
that.
I
think,
if
there's
maybe
a
intersection
of
what
it
does
exist
and
a
minimum
set
that
can
exist.
J
I
think
it's
also
a
proposal
in
that
issue.
Just
recently,
that
would
probably
say,
like
other
language,
can
extend
it.
It's
worth
spending
time
on,
especially
if
you
wanted
to
support
this.
The
next
thing
that
we
kind
of
noticed
is
like
how
do
you
not
impose
a
logging
framework
on
users?
I
know
that
things
like
like
in
java,
it's
just
kind
of
assumed
that
it
will
be
you're
going
to
be
using
vlog4j
because
that's
just
like
what
it
is,
but
like
definitely
like
in
go.
J
We
have
this
problem
where,
if
we
chose
to
say
log
with
the
standard
library
or
we
chose
to
log
specifically
with,
like
you
know,
zap
or
an
instrumentation
package,
it
requires
the
users
of
open
telemetry
to
then
import
that
as
well
as
use
that
in
their
own
frameworks.
So
if
they
log
in
a
different
format
or
a
different
framework,
how
do
you
provide
compatibility
across
that?
I
think
that's
something
that
needs
to
be
thought
of
carefully.
J
One
of
the
things
that
we've
kind
of
realized
recently
and
we
discussed
in
our
sig
meeting
last
week,
was
that
you
know
splitting
logging
dependencies
is
also
a
possibility
where
you
could
have
you
know
your
api
from
you
know
some
sort
of
logging
api
split
from
something
the
user
can
pass
you,
which
would
be
an
implementation
of
that
api
and
a
very
similar
design
pattern
that
already
exists
in
open
telemetry
for
other
signals
and
we've
actually
there's
some
external
dependencies.
J
That
like
do
these
sort
of
things
which
is
kind
of
nice,
because
then
we
can
rely
on
them
to
do
all
of
our
logging
but
like.
How
do
we
integrate
that?
But
then
it
kind
of
also
brings
up
that
same
question
as
to
like,
what's
the
long
term
story
here,
for
integrating
with
the
logging
signal,
because,
ideally
I'm
guessing,
we
want
open,
telemetry,
sdk
logs
to
also
be
shipped
to
the
same
destination
that
any
logging
signal
is
going
to
be
shipped.
J
So
thinking
about
that
in
the
long
term
is
also
something
I
think
that
we
wanted
to
try
to.
You
know,
consider
and
not
block
on
if
you're
going
to
provide
logging
platforms,
yeah
and
then
I
guess
the
only
other
thing
on
top
of
that
was
then
how
does
that
extend
beyond
the
api
boundary?
So
if
you
have
instrumentation
libraries
and
they
want
to
log
through
the
same
pipeline
like
how
are
they
given
access
to
this?
J
So
I
think
there's
a
lot
of
open
questions
here
and
they're
probably
answered
by
people
in
this
projects,
but
I
we
weren't
familiar
with
the
answers.
In
fact,
you
know
the
logging
sig
is
probably
a
place.
We
need
to
kind
of
connect
with,
but
yeah.
I
just
wanted
to
raise
some
of
these
questions.
Other
people
are
aware
of
it.
J
A
J
Well
so
I
mean
I,
I
don't
have
a
specific
example
because
we're
still
in
the
real
early
stages,
but
I
can
imagine
the
situation
exists
where
there
is
a
you
know,
a
state
where
you
want
to
do
some
sort
of
like
info
logging
on
the
telemetry
that
you're
generating
to
to
produce
you
know,
say
something
like
a
debug
log,
so
you're
troubleshooting
a
project
you
want
to
know
if
the
instrumentation
is
working
correctly,
you
want
to
be
able
to
produce
logs
to
you,
know,
indicate
state
of
that
or
indicate
flow
of
the
instrumentation
library.
J
So
I
could
imagine
the
instrumentation
library
could
try
to
solve
this
on
their
own
and
build
their
own
logging
platform,
which
is,
I
think,
a
bad
idea
or
try
to
hook
into
what
the
sdk
already
provides
it
to
unify
those
logging
messages.
So
if
you're,
you
know
running
the
sdk
in
a
debug
state,
you
would
also
get
the
instrumentation
library
debug
messages
alongside
it.
This
is
my
thought
on
that
matter.
Does
that
make
sense.
A
Yeah,
yeah
diagnostics
is
something
again.
It's
to
me.
It's
on
the
list
of
things
to
get
out
the
door
once
where
it's
like.
We've
got
getting
open,
telemetry
production
ready,
which
is
like
metrics
and
production,
logs
working
and
telemetry
and
instrumentation
in.
B
A
A
stable,
stable
place
and
my
hope
was
to
turn
attention
to
to
diagnostics
after
that,
as
as
a
group,
I
wanted
to
do
it
this
summer,
but
there
just
wasn't
enough
bandwidth
to
think
about
all
these
things.
At
the
same
time,
I
I
think
yeah,
the
short
term
is
just
yeah,
though,
when
the
sdk
has
problems.
How
to
you
know
where
in
the
spec
is
that
that
underspecified
longer
terms?
Yet
how
do
we
provide
better
diagnostic
tools
for
people
who
are
trying
to
debug
their
instrumentation
right?
J
Yeah,
the
thing
is
it's
like
back
to
that
comment
of,
like
you
know,
getting
things
production
ready.
I've
had
a
few
conversations
with
a
few
different
people,
and
you
know
it's
also
stated
like.
If
you
can't
troubleshoot
and
you
can't
understand
the
the
bad
state,
it's
not
production,
ready
like
it's,
it's
just
not
like
you
can
run
it
sure
and
you're
going
to
provide
stability
guarantees
from
the
package.
But
if,
like
something,
goes
wrong
in
production,
you'd
be
able
to
find
out
what
it
is
yeah,
and
so
I
think
that's.
J
I
think
one
of
our
main
concerns
is
why
we
want
to
prioritize
specifically
around
the
sdk
logging
right
now.
The
only
thing
is
we
don't
want
to
paint
ourselves
into
a
corner.
That
is
the
problem
also
yeah.
A
I
I
think
a
good
next
step
is
to
start.
I
think
that
the
number
one
commonality
that
would
probably
have
to
happen
is
start
defining
just
semantic
conventions.
For
these
these
errors
and
logs
that
the
sdk
would
have
to
produce
right
like
there
are,
there
are
common
ones.
You
know
at
minimum.
How
do
we
identify
something
is
an
sdk
coming
from
the
sdk
so
that
it
can
just
go
out
assuming
the
logging
system
in
open
telemetry
is
working
to
the
effect
that
it
can
send
logs?
A
How?
What
would
these
messages
look
like?
How
do
you
avoid
a
feedback
loop
or
you
know?
What
is
it
if
there's
a
circuit,
breaker
mechanism,
you
have
in
mind
like
those
yeah
and
then
like?
How
does
someone
plug
into
this
thing
with,
like
their
local,
locking,
agent
or
standard
out,
like
those
those
things
to
me,
seem
like
production
production
issues
that
that
we
should
solve?
First.
J
Yeah
and
I
think,
if
that
kind
of
gets
down,
it's
a
little
tough
to,
I
think,
see
the
details
in
a
conversation
like
this,
and
maybe
some
diagrams
would
help
but
like
exactly
like
what
you're
saying
is
like
we
ultimately
want
to
be
able
to
integrate
with
the
logging
signal.
But
what
happens
when
open
symmetry
goes
wrong
right
like
that's
what
the
whole
point
of
this
is
is
to
find
out
what's
going
on.
So
how
do
you
also
integrate
with
like
standard
out
logging
or
other
logging
platforms
that
you
could?
J
You
know
switch
to,
and
I
think
it's
important
we've
identified
in
separating
those
concerns
and
separating
the
api
from
the
implementation
of
that
api
and
allowing
the
user
to
provide
some
sort
of
generic
way
to
implement
it,
and
one
of
those
implementations
definitely
needs
to
be
open.
Telemetry's
logging
implementation,
but
maybe
they
also
want
to
put
in
something
that
is
not
that
and
yeah
use
that
I
think,
is
kind
of
the
key.
This.
A
A
A
For
example,
there
are
places
where
the
api
actually
has
mechanisms
right
for
like
registering
things.
For
example,
I
don't
know
how
common
it
is,
but
anyways
long
story
short
a
like
an
error
handler
provider
or
something
like
that.
Some
public
I've
wondered
whether
just
handling
this
like
the
way
we
handle
every
other
sub-component
of
open
telemetry.
You
could
have
an
error.
A
You
know
an
error
receiver
that
people
could
register
to
and
the
sdk
could
also
register
itself
as
one
something
something
like
that.
But
anyways
I
don't
get
too
much
into
the
weeds
there.
Tyler.
P
I
definitely
think
these
would
be
welcome
questions
at
the
logging
sig
traditionally.
Well
recently,
the
city
has
mostly
focused
on
the
collector,
and
so
just
in
general.
I
would
put
this
out
there
that
sdk
perspectives,
language
implementations
perspectives,
would
definitely
help
enhance
that
group's
ability
to
sort
of
address
the
problems
across
the
board
so
certainly
would
encourage
you
to
bring
those
and-
and
I
think
to
some
of
these
points
at
least
there
would
be
some
some
decent
answers
for
you
there.
P
I
won't
go
into
them
now,
but
I
think
we
could
have
some
good
conversations
there.
We'll
say
as
far
as
the
like
sort
of
this
question
of
consuming
your
own
signals
and
things
like
that,
stanza
had
to
solve
a
lot
of
that,
and
I
think
there
there's
maybe
at
least
a
a
good
core
of
an
idea
there
that
we
could
maybe
try
to
hash
out
into
a
more
generalized
solution.
So
we'd
like
to
talk
about
that
too.
J
Okay,
yeah
I'll
plan
on
joining
it's
a
wednesday.
It
looks
like
so
I
should
be
able
to
make
that
awesome.
A
Great
yeah,
that's
awesome,
and
as
far
as
diagnostics
is
concerned,
I
definitely
would
like
to
tackle
that
part
holistically.
Not
not
this
issue
of
like
there
are
things
blowing
up
and
there
are
errors.
An
end
user
needs
to
consume
these
real
errors,
but
the
other
issue
you
were
discussing
around
like
I'm
confused
about
what
is
going
on
with
this
stuff
and
I'm
trying
to
debug
the
instrumentation.
A
I
think
that's
that's,
definitely
a
thing
we
need
to
to
solve,
but
I'd
like
to
just
put
that
in
a
separate
bucket,
because
that's
the
stuff,
where
I'm
now
not
running
in
production
mode,
I'm
running
in
some
kind
of
development
mode
trying
to
pick
through
this
versus
the
the
stuff
that
would
be
coming
out
in
production.
If
that
makes
sense,.
J
Yeah,
I
don't
think
we
had
any
plans
to.
I
definitely
don't
we
didn't
have
any
clients
to
log
in
instrumentation,
and
so
that
wasn't,
but
we
just
wanted
to
make
sure
that
it's
you
know
if
that
is
a
plan
in
the
future,
to
not,
like,
I
said,
close
the
door
right
now,
but
I
also
realized
we
have
two
minutes
left
in
the
meeting.
So
I
don't
want
to
take
up
too
much
more
time
on
this.
A
I
think
it's
fine.
Oh
sorry,
there
is
one
more
item.
A
B
Be
quick
basically
just
wanted
to
communicate
this
across
on
behalf
of
tigran
tigrin,
we
have
an
agent
management
work
group
that
has
been
formed.
It
had
its
first
meeting
last
tuesday
and
I
think
thanks
for
adding
in
more
information
here.
Basically,
we
do
meet
every
other
tuesday
at
11
a.m.
Pacific,
and
there
is
a
channel
in
case
people
are
interested
to
join.
That's
been
added
here
as
well.
Yeah,
I
think,
on
the
channel.
Tigran
has
added
more
reference
along
the
agent
management
spec
other
proposals
and
issues.
B
B
A
Working
group
initially,
which
I
thought
was
like
an
interesting
addition
to
an
open
source
project
but
anyways
okay,
yeah
we're
at
time.
This
is
great,
great
maintainers
meeting.
I
thought
a
lot
of
good
information
was
communicated,
really
excited
about,
say
the
project.
I
think
we're
gonna
hit
2022
in
like
really
good
shape,
so
good
job.
You
all
you're,
rockstars,
see
you
on
the
internet.