►
From YouTube: 2020-11-17 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
Hey
good
morning,
everyone
just
wait.
Let's
wait
for
one
more
minute.
Meanwhile,
you
can
add
your
name
to
the.
A
All
right,
I
think
we
can
start
now.
Can
you
confirm
you
can
see
my
screen?
I
am
projecting
the
meeting
notes
now.
Okay,
thanks,
oh
yeah,
I
have
few
updates
and
then
we'll
go
over
remaining
agenda.
I
try
to
give
a
quick
summary
of
what
is
release
plans.
What
are
the
things
which
we
are
releasing
in
the
next
few
days,
so
the
first
update
is
the
rc
one,
which
was
marked
for
like
four
days
back
it's
going
to
be
released
today.
A
We
still
have
like
it
tends
to
be
fixed,
but
even
and
we'll
be
releasing
it
by
end
of
day
today.
So
that
would
be
the
first
release
candidate
and
you'll
notice
that
there
will
be
a
lot
of
breaking
changes
compared
to
the
last
beta,
which
is
expected.
We
cleaned
up
a
lot
of
apis
which
are
not
expected
to
be
public,
and
there
are
like
issues
like
in
the
change
log.
A
You
can
find
linked
issues
which
describes
this
and
what
are
the
alternate
options
as
well,
and
the
next
will
be
rc2,
which
is
expected
next
week
and
followed
by
that
the
actual
1.0.0
release,
which
should
be
like
number
last
or
december
1st,
but
anyway,
like
we
have
like
less
than
two
weeks
before
we
do.
The
final
release.
A
Sorry
finalizing
like
the
first
1.0
release
and
as
mentioned
earlier,
the
matrix
and
me
quickly.
Yeah
there
is
a
there
are
like
two
issues
which
have
been
so
matrix.
Plans
are
already
described
here
and
we
will
be
marking
anything
related
to
matrix
as
absolute
because
we
will
be,
as
mentioned
in
the
detail
plan
here,
we'll
be
like
removing
all
this
api
and
rebuilding
it
from
scratch.
A
But
everything
else
which
means
traces,
context,
propagation
and
logs
will
be
marked
ga
and
it
will
be
tagged
with
1.0.
What
that
means
is.
We
will
not
have
any
breaking
change
after
1.0
until
we
bump
the
major
version
to
like
2.0,
and
to
achieve
that,
we
have
identified
these
issues,
which
I
have
tagged
with
4ga.
So
you
can
see
it's
not
the
full
list
of
issues
which
we
have
opened
like
you
can
see
like.
There
are
close
to
100
issues.
A
I've
already
tagged,
16
of
them
as
required
for
ga,
so
you
can
expect
that
these
are
the
only
things
which
we'll
be
focusing
on
in
the
next
two
weeks,
and
some
of
you
may
be
wondering
like
why
some
bugs
and
some
pr's
were
left
out.
The
reason
is
anything
which
are
considered
additive
changes.
We
can
always
add
it
after
ga,
even
if
you
do
1.1
or
1.1
1.2,
we
can
still
and
keep
adding
things,
but
there
are
things
which
are
like
breaking
behavior,
slash
apa.
A
So
those
are
the
things
which
are
to
be
fixed
before
we
do
1.0
so
because
of
that
we'll
be
just
prioritizing
any
issues
which
are
marked
release
required.
4G,
like
some
of
them,
are
like
video
based
like
we
don't
like
the
first
one
itself.
The
current
subscription
model
ignores
version,
so
we
have
to
change
the
api
to
support
version.
So,
since
this
is
a
change
in
apa,
we
have
to
do
it
before
the
1.0
so
similar
for
all
the
other
things.
These
secure
changes
to
public
api.
A
So
we
are
going
to
do
it
right
like
before
the
1.0,
and
there
are
bugs
which
are
open,
which
are
like
non-bugs.
They
will
remain
as
non-bugs
in
1.0,
for
instance,
this
one
http
client
is
not
propagating
the
context
when
a
filter
is
applied,
so
these
are
bugs.
These
are
non-issues.
A
It's
not
like
a
p0
robot
because
it
won't
be.
It
won't,
have
any
impact
unless
there
is
a
filter
applied.
So
it's
it's
not
like
a
major
bug,
but
it
is
still
a
bug,
and
since
this
bug
fix,
does
not
accurate,
any
ap
change
or
any
changes
to
any
features,
we
just
treat
it
as
not
required
for
ga.
So
we
can
address
the
things
with
a
higher
priority
for
the
record
for
g.
A
So
that's
all
I
have
for
like
release
plans.
Okay-
and
one
final,
ask
is:
this-
is
something
which
we
briefly
covered
last
year
last
week
as
well.
So
in
preparation
for
ga,
we
have
a
like
alan,
has
put
together
a
nice
list
of
all
the
things
which
are
going
public.
A
I
think
I
spent
a
lot
of
time
on
the
prometheus
exporter.
It's
probably
okay,
because
even
if
we
change
the
api,
okay,
the
equator
is
still
growing,
but
it's
not
the
highest
priority
because
we
are
originally
in
the
other
two
parts.
So
if
you
any
of
you
have
free
cycles,
please
take
one
or
more
items
from
this
list
and
if
you
are
like
passionate
about
coding,
you
can
do
like
actual
coder
b
as
well
or
you
can
just
do
the
documentation.
A
I
mean
if
I
were,
to
give
an
example.
What
I
really
want
is
like,
for
example,
let's
say
you're
using
jager
so
go
to
the
folder.
This
is
a
read
me
and
make
sure
you
can
follow.
This
read
me
and
install
jager
and
see
your
spam
in
jager
ui.
There
are
like
fully
working
examples
here.
You
can
pretty
much
copy
paste
and
make
sure
like
it
is
working
as
documented.
A
If
it
is
not
working,
I
mean
if
it's
a
dog
issue,
if
you're
not
a
like
developer
guy,
just
create
a
dog
issue,
saying
that
this
is
broken.
If
you
know
the
fix
yeah
you're
happy
to
accept
ps
as
well,
and
similarly
do
it
for
each
and
every
component,
that's
ask
so
thanks
for
folks
who
are
already
signed
up
I'll
leave
the
list
open
for
one
more
week.
I
mean
in
fact
this
can
be
open
right
until
ga
so
appreciate
any
help
in
advance.
A
There
was
another
suggestion
as
an
alternate
or
as
a
complimentary
thing
to
this
issue.
There
was
a
suggestion
to
do
like
a
community
bug.
Bush
kind
of
thing
I
want
to
ask
like
if
there
is
any
interest
from
the
community
to
do
that.
Basically,
what
we'll
do
is
we'll
send
a
zoom
in
wait
for
like
a
couple
of
hours.
A
I
will
be
hosting
it
so
I'll
be
available
for
like
any
questions
as
they
come,
but
people
are
expected
to
do
a
web
bash
on
their
own,
but
I'll
be
available
or,
like
other
maintainers,
will
be
available
to
help
right
away
without
waiting
to
open
a
github
issue.
We
can
solve
things
much
faster
if
there
is
enough
interest.
I
can
try
to
find
some
time
before
the
ga,
like,
probably
sometime
next
friday
or
next
thursday,
or
even
after
that.
I
think
we
yeah
we
yeah.
A
We
don't
have
like
another
weekend
after
I
mean
another
friday
after
next
one,
so
this
friday
or
next
friday
or
would
be
right
place,
but
I
I'll
just
create
an
issue
if
I
see
like
enough
plus
one
so
I'll,
go
ahead
and
do
it
otherwise
I'll
assume
there
is
not
enough
interest
I'll.
Stick
with
this
one.
A
Okay,
yeah,
let
me
that's
the
only
agenda
which
I
had.
Let's
look
at
the
remaining
agendas.
So
let's
look
at
this
one
yeah,
so
alan
created
this
issue
a
couple
of
days
back
so
is
alan
on
the
call
yeah.
B
A
Just
summarize
for
other
folks
here
I
don't
have
a
strong
opinion
on
what
should
be
the
approach,
but
it
would
be
best
if
you
just
describe
the
background,
and
we
can
do
a
cube
discussion
right
now
and
then
make
a
final
code
in
the
pr
itself.
C
Yeah
sure
yeah
thanks
so
yeah,
I
I've
been
kind
of
reviewing
code,
namely
around
the
open
telemetry
protocol
exporter,
but
I
kind
of
expanded,
my
looking
at
all
the
other
exporters,
and
that
just
got
me
thinking
about
extension
methods
and
the
way
that
we
configure
the
tracer
provider.
So
in
the
code
example
there
that
I've,
provided
you
know
it's
it's
it's
just
in
the
context
of
the
asp.net
core
app,
but
the
the
issue
that
I'm
raising
here
is
a
little
bit
more
general
than
that.
C
Basically,
we
have
extension
methods
off
a
whole
bunch
of
things
so
like
in
this
example,
services.add
open,
telemetry
tracing,
that's
an
extension
method
off
of
the
iservice
collection,
which
is
a
non-open
telemetry
type
and
because
there's
a
using
of
microsoft,
extensions
hosting
at
the
top
of
this
file,
because
that's
pretty
standard
in
asb
net
core
app.
You
know
I
I
just
get
that
extension
method
without
having
to
think
about
it,
but
the
minute
that
I
get
into
then
configuring,
the
trace
provider
builder,
which
is
kind
of
implicitly
used
here.
C
You
know
I
the
first
method
that
I
use
here
add
source
is
not
actually
an
extension
method,
so
I
just
you
know
until
it
intellisense.
It
gives
me
that,
but
now
I
want
to
go
and
add
asp.net
core
instrumentation
and
that's
not
going
to
show
up,
because
I
don't
have
the
appropriate
using
opentelemetry.trace.
C
So
one
thing
that
I've
struggled
with
with
extension
methods
when
I've
been
learning
new
libraries.
Is
it's
not
usually
abundantly
clear
what
usings
I
may
be
missing,
or
maybe
even
packages
I
may
be
missing,
so
the
question
I'm
kind
of
posing
here
is
that
is
there
anything
that
we
can
do
to
make
these
extension
methods
a
little
bit
more
discoverable.
C
In
the
next
block
of
code,
I
kind
of
I
kind
of
showed:
what's
in
our
future,
you
know
as
soon
as
we
start
getting
into
the
metric
space.
You
know
the
builder
in
this
context.
It's
not
it's
not
obvious
here,
but
the
builder
in
this
con
context
here
is
the
metric
provider
builder,
which
has
you
know
its
own
set
of
extension
methods.
So
the
add
asp.net
core
instrumentation
here
is-
would
require
a
different
using
than
the
one
above.
C
So
with
that
in
mind,
I'm
asking
the
question
here:
does
it
make
sense
to
have
all
of
our
extension
methods
that
are
on
open,
telemetry
types
in
a
single
name
space
just
to
make
it
easy
so
that
I'm
like,
if
I
were
a
new
user
to
open
telemetry,
I'm
not
left
wondering
about
all
the
usings
that
I
may
need,
because
I'm
as
a
new
user.
I
may
not
be
super
familiar
with
the
organizational
structure
of
the
open,
telemetry
project
here.
C
A
The
package
part
which
you
mentioned
like
there
is
no
easy
way
to
solve
that
other
than
documentation
like
if
they
want
to
write,
add
asp.net,
core
instrumentation
or
add
zipkin.
They
have
to
first
install
the
package
without
which
nothing
would
happen.
So
that
is
already
a
non
but
solved
issue
using
documents.
Is
there
any
concern
there,
or
is
it
only
about
the
name
space
part.
C
A
Yeah,
I
think
most
of
our
document
starts
with
which
package
to
install
and
like
even
like,
I'm
just
taking
this
as
an
example.
So
this
is
all
about
http,
client,
instrumentation,
so
step
one
is
install
this
package,
but
in
step
two
we
are
adding
a
console,
but
we
made
sure
like
whenever
we
do
like
anything
extra,
we
make
sure
people
are
installing
the
corresponding
package.
So
I
think
we
are
good
from
package
perspective
and
documentation,
because
wherever
we
do
things,
I
mean
anyone
should
be
able
to
just
copy
paste.
A
This
code
install
this
package
and
any
other
package
mentioned
here.
They
should
be
like
running
this
one
without
any
compilation
issue,
but
then
the
question
of
like
what
what
using
statements
they
need
to
import,
which
is
which
is
not
straightforward,
like,
as
I
mentioned
like
the
currently.
The
way
it
is
organized
is
this
is
just
sharing
more
background,
so
anything
which
is
not
part
of
traces
or
matrix.
One
good
example
is
like
contact.
Oh,
there
is
no
yeah
anything
which
is
not
really
tied
specifically
to
a
matrix
or
tracers.
A
We
try
to
put
it
under
open
elementary
name
space.
Anything
which
is
tied
to
trace,
which
involves
like
instrumentation
for
trace
or
exporter
for
trace,
is
in
the
dot
trace,
namespace
and
same
with
like
logs
and
same
with
like
if
you're
using
resources,
then
it
is
open.
Elementary
dot
resource
matrix
would
be
open,
elementary
dot
matrix,
so
one
advantage
it
offers
is.
If
I
am
using
like
metrics,
I
don't
have
to
import
anything
related
to
trace.
I
all
I
need
to
is
open
elementary
dot
metrics.
A
It
kind
of
logically
separates
the
things,
and
even
the
package
organization,
as
recommended
by
open
telemetry
itself,
says
you
should
organize
the
package
in
like
this
way
like
open
elementary,
followed
by
trace
metrics
context
resource.
So
there
is
a
suggested
layout
which
we
are
mostly
following,
but
then
the
question
of
discoverability
would
come,
and
I
I
haven't
had
a
proper
chance
to
look
at
like
the
suggestion
like.
A
Were
you
suggesting
that
all
these
extents
all
these
methods
should
be
from
the
name
space
open,
telemetry
or
they
should
be
from
the
name
space
open
elementary
to
dot
extension,
so
that
usage
does
not
have
to
do
like
import
open,
elementary
dot,
tracing
open,
elementary
dot
resource
open
elementary
dot
metrics?
All
they
need
is
like
one
is
that
the
kind
of
thing
which
you
are
proposing,
or
it's
still
open.
C
C
From
the
need
for
declaring
and
using,
but
it
would
just.
A
C
A
A
Yeah,
I
think
things
which
do
not
like
do
not
fall
into
like
trace.
Strictly
that's
the
thing
which
we
put,
but
I'm
not
even
sure
whether
like,
let
me
just
take
one
propagator,
so
it
is
in
a
different
name,
so
it
is
in
open,
elementary
dot
context,
dot
propagation,
which
would
mean
like,
if
you
are
writing
a
like
instrumentation
and
you
are
using
like
you'll,
have
like
one
more
name
space
to
import.
A
A
Yeah
we
mostly
follow
this
one,
not
exact
match,
but
we
have
apa,
has
context
propagation
matrix,
trace
baggage
logs
and
for
sdk.
Also,
we
have
like
similar
thing
like
the
source
is
only
applicable
to
sdk.
So
we
put
it
like
this,
so
I
don't
have
strong
opinion
on
one.
A
One
reason
why
I
initially
like
this:
this
was
discussed
like
few
months
back
when
we
initially
moved
from
like
our
initial
step,
was
we
even
had
separate
name
space
for
each
and
every
exporter?
So
if
you
are,
if
you
want
to
do
like
use
zipkin
exporter,
then
it
would
be
open.
A
C
Right,
yeah,
just
okay,
I
just
took
a
stab
here.
It's
like
a
couple,
a
couple
of
them,
but
this
actually
applies
not
just
to
exporters,
but
it
would
apply
to
like
instrumentation
as
well
see.
A
So
you're
still
saying
like
for
like
zipkin
exporter
itself,
it
can
be
in
the
open
elementary.trace
but
the
extension
methods
to
enable,
because
that's
a
most
typical
way,
customers
interact
with
adding
an
exporter.
Then
let's
move
it
to
a
easier
namespace.
A
Is
that
like
so,
for
instance,
like
the
chicken
exporter
itself,
would
they
also
be
in
the
open
elementary
or
would
they
be
in
open
elementary.trace?
No.
A
Only
these
extension
methods,
so
that,
like
when
a
user
is
doing
like
this
code,
they'll
only
import
using
open,
telemetry
right,
okay
and
if
they
want
to
do
like
manual
like
something
more
advanced,
then
they
probably
need
to
do
actual
import
of
that
namespace.
A
A
A
D
D
C
A
Yeah
so
let's
take
a
good
example
like
which
one
I
should
pick.
Let's
look
at
stack
exchange
ready,
so
it
has
like
the
actual
instrumentation
which
would
go
into
like,
or
it
has
like
this
public.
It
would.
A
Name
space,
but
users
typically
interact
with
this
extension
method
like
address
instrumentation,
and
this
is
the
one
which
allen
is
proposing.
Let's
keep
it
simple
to
just
means
this
open,
telemetry,
yeah
yeah.
I
think
it's
a
nice
improvement,
but
I'm
still
asking
one
question
about:
how
would
it
look
I
mean?
How
would
it
look
if
you
do
things
which
are
not
extension
methods,
for
instance,
this
is
a
place
where
I
am
using
a
resource
api.
C
C
A
Yeah
but,
like
my
point
is
like
in
effect
like,
if
you
want
to
use
like,
if
you
want
to
use
an
actual
resource,
then
you'll
be
forced
to
import
the
resource
anyway,
even
if
the
extension
method
itself
does
not
require
it,
but
what
goes
into
the
method
is
an
actual
resource
builder,
which
is
now
in
in
a
different
language,
so
you'll
be
anywhere
forced
to
import.
That
is
that,
right,
but
and.
A
It
for
the
instrumentation
part
and
exporter
part
like
the
actual,
like
extension
method,
can
be
moved
because,
most
of
the
time
you
don't
really
need
to
know
anything
internally.
You
should
be
fine,
but
for
things
like
resource
or,
for
instance,
if
you
are
using
propagators,
you'd
still
be
like
importing
more
namespaces.
So
even
if
we
solve
it,
we
still
won't
solve
it
like
fully.
We
would
still
expect
people
to
import
more
namespaces
as
they
write
like
more
production-ready
codes.
I
mean
I
can
write
it
like
very
simple.
A
I
can
just
ignore
it,
but
eventually
like
when
people
are
in
production
scale,
they
would
eventually
have
like
resources
for
sure
they
would
most
likely
have
access
to
propagator,
because
if
they're
not
using
the
trace
context,
they
have
to
set
it
to
overrate
it
to
whatever
propagator
there.
You
see,
so
I'm
not
opposing
or
like
accepting
I'm
just
not
convinced
that
we
can
solve
this
completely
unless
we
put
everything
into
a
single
like
everything
which
user
ever
uses
would
be
just
open,
telemetry
and
rust
into
like
trays
or
matrix.
C
A
C
I
hear
you,
I
think
I
think,
then
you
know
I
mean
again.
I
wasn't
I
wasn't
thinking
about.
This
is
like
a
strong
opinion.
I
was
just
kind
of
going
through
it
and
I
I've
gone
through
this
a
number
of
times
and
then
I'm
like
oh
yeah.
I
forgot
to
add
this
this
using
so
I
just
I
just
wanted
to
raise
it
as
a
question
and
get
a
sense
of
whether
other
individuals
felt
like
this
was
any
usability
friction.
C
But
there
is
another
note
that
I
put
further
down
in
the
pr
here
that
if,
if
we
don't
change
anything,
the
main
thing
I
want
to
make
sure
is
just
a
as
a
developer
in
the
open
telemetry
project
that
the
guidance
here
is
clear.
That
last
example
here
this
might
actually
just
be
a
problem.
I
mean
or
a
bug
or
not,
really
a
bug,
but
just
an
oversight.
Now
that
I've
looked
at
it
a
little
bit
more.
A
So,
if
you
look
at
the
code,
like
the
add
open
telemetry,
you
don't
really
need
to
like
import
anything
other
than
microsoft
extensions
logging.
This
is
little
bit
weird
due
to
the
net
core
up.
2.1
special
case
believe
this
is
a
recommendation
from
I
logger
like
if
you
are
using,
I
logger
and
you
build
your
own.
I
logger
provider
and
extension
method
to
add
that
is
expected
to
be
in
the
same
name
space
so
that
when
like
let's
say,
the
user
is
having
add
open,
telemetry,
add
like
console
logger
at
some
other
logger.
A
They
don't
have
to
different
spaces
because
extension
method
they
encourage
to
put
under
microsoft,
extensions
login,
no
matter
like
which
package
it
comes
in.
C
C
Kind
of
like
poking
out
like
what
what
should
be
the
intuition
here
for
for
someone
developing
within
the
open
telemetry,
you
know
project
when
implementing
an
extension
method.
A
Okay,
I
got
it
yeah,
so
we
need
to
at
least
like
the
minimum
thing
which
we
are
proposing
is.
We
should
have
a
consistent
guideline
on
what
namespaces
your
extension
method
should
be
yeah
and
for
the
actual
code
itself
we
don't
really
care,
because
extension
methods
are
the
likely
way.
Users
are
going
right.
C
Yeah
and
unfortunately,
if
if
add
console
exporter
was
moved
to
the
opentelemetry.logs
namespace,
then
this
example
that
you've
pulled
up
here
would
actually
require
an
additional
using
for
like
using
open
telemetry.logs,
which
you
know.
I
guess
it's
kind
of
nice-
that
it
doesn't
require
that
using
right
now.
But
if.
A
Builder,
don't
add,
open
telemetry
is
following
what
I
logger
recommends.
It
should
be
in
the
extensions.logging,
so
this
part
is
neat
and
clean,
but
now
within
open
elementary,
we
have
the
option
of
like
sending
the
same
logs
to
multiple
processors,
slash
multiple
pipelines,
so
that
would
be
required
requiring
like
additional
name
space.
If
it
is,
I
mean
if
this
extension
method
is
changed
from
microsoft,
extensions
login
to
something
else
right,
yeah,
okay,
I
don't
have
a
strong
opinion.
A
So,
let's
like
discuss
this
in
the
pr
like
more,
and
I
mean
I
fully
agree
that
the
minimum
thing
we
should
do
is
consistently
ensure
that
extension,
at
least
the
extension
methods
should
be
in
the
single
name
space,
and
we
should
advise
folks
who
are
extending
the
sdk
to
do
the
same
and
for
the
rest,
we
can
follow
what
like
open
elementary
is
proposing
as
a
structure.
So
if
you
have
a
propagator
of
your
phone,
which
is
then
it
should
go
into
the
context,
propagation
or
trace
population.
A
If,
if
you're
writing
your
own
examples,
it
should
go
into
the
sdk.trace
at
least,
but
if
you
want,
you
can
provide
extension
methods
on
like
okay,
here's
my
example.
If
you
want,
even
if
you
write
an
assembler,
you
can
provide
extension
method
on
my
custom
sampler.
A
A
Yeah,
okay,
so
let
me
work
on
like
a
draft
document
and
put
it
here
and
I'll
review
it
in
conjunction
with
the
actual
proposal.
Here
I
think
it's
it's
a
neat
idea
to
just
bring
all
the
extension
methods
into
a
single
import
so
that,
like
every
example
which
people
are
following,
all
they
need
is
just
import
open,
elementary
name
space
and
it
should
work
and
if
they
need
some
advanced
scenarios
where
they
they
need
to
interact
without
using
extension
methods,
then,
yes,
we
need
to
force
them
to
import
more
yeah.
A
A
A
Then
it's
probably
you
don't
need
to
explicitly
import
these
things.
C
A
A
The
b
types:
okay
yeah-
this
is
a
little
bit
weird
for
me,
or
this
program
should
not
be
working
like
it
should
be
like
it
should
not
even
fail
to
it
should
not
even
compile
yeah,
see
it.
Okay,
yeah.
Let
me
take
two
action
items
to
fix
the
existing,
but
I
don't
really
need
to
have
it,
though.
All
I
need
is
like
make
sure
the
extending
sdk
piece
talks
about
this,
and
this
is
right
now
about
exporter
instrumentation
processor.
Some.
These
are
the
main
extensibility
points
right,
yeah,
these
four.
So
we
should.
C
A
Okay,
yeah
thanks,
for
I
mean
this
is
something
which
we
had
like
briefly
touched
upon
in
several
pr's.
When
we
were
moving
things
around,
there
was
question
we
keep
the
same
name
space
or
not
like
the
general
conclusion
at
that
time
was.
There
is
no
right
answer
like
it's,
mostly
like
personal
preference,
yeah
yeah,
and
I
I
tried
to
stick
with
this
mostly
yeah
anyway.
Thanks
for
bringing
this
up.
A
E
Question
about
recording
exceptions,
that's
mine,
I'll
talk,
hopefully
real
quick.
So
I
was
reviewing
the
sql
client
instrumentation,
and
I
noticed
that
in
some
cases,
when
we
record
the
exception,
sometimes
we
just
set
the
status,
but
in
some
other
instrumentations
we
actually
use
the
like
record
exception,
which
does
it
as
an
event
which
I
think
spec
says
it
should
do
that
if
possible.
E
So
is
it
just
an
oversight?
I
wonder.
A
E
Yeah,
so
it
doesn't
record
exception.
It
just
sets
status.
If
you
scroll
a
bit
down
there,
yeah
right
yeah,
so.
A
E
E
Okay,
yeah,
so
I'll
I'll
do
I'll
do
a
pr
for
that
one,
but
one
other
thing
related
to
that,
the
only
so
I
noticed
a
few
instrumentations
actually
like
don't
do
it
right
with
the
exception,
but
the
one
that
does
the
asp.net
core
one
it
has.
It
has
an
options
like
a
public
setting,
whether
it
like
controls,
do
that
or
not
so,
and
it's
also
the
only
one
that
does
it
so
should
all
of
them
have
it
or
should
none
of
them
have
it,
and
it
should
just
always
record.
A
Yeah
yeah,
so
general
thinking
is
if
there
is
some
work
involved
to
get
the
exception
like
in
this
case
it
would
be
like
you
are
storing
the
exception
using
like
when
you
call
exception
activity,
dot
record
exception.
We
are
calling
like
two
strings,
so
there
is
some
non-trivial
amount
of
price.
You
have
to
pay
to
record
this
exception,
so
the
general
recommendation
is
always
protected
under
a
flag
so
that
people
can
obtain
into
it
because
it's
not
not
free,
like
you-
have
to
pay
some
cost
to
record
this
exception.
A
So
if
my
back
end
does
not
have
a
way
to
deal
with
exception,
then
I
shouldn't
be
forced
to
pay
the
price
for
that.
So
that's
the
general
thinking
of
putting
it
under
record.
Except
me,
this
is
it's
not
like
a
rule,
but
we
should
try
to
do
like
for
it,
because
the
instrumentations
are
like
probably
in
the
hot
path.
Not
probably
they
are
in
the
hot
path.
So
if
I
know
that
I'm
not
going
to
use
exception,
then
I
should
be
able
to
opt
out
of
it
or
I
should
be
able
to
explicitly
obtain.
A
E
Okay,
okay,
so
I'll
I'll
submit
a
pr,
then
does
that
and
then
one
final
question
about
the
enrich?
E
Actually
we
have
it
on
the
screen
here.
I
found
it
extremely
difficult
from
just
this
to
even
know
how
to
use
it,
because
it
just
has
a
string
and
an
object
without
looking
at
how
the
instrumentation
calls.
B
E
E
A
So
that's
a
bug,
that's
a
dog
issue.
We
should
document
everything
I
think
most
of
them
are
already
covered
like
I
I
haven't
like
finished
reviewing
so
asp.net
core
has
it
and
we
should
have
it
for
spinet
as
well,
like
filter
enrich,
and
we
should
have
it
for
grpc.
If
it,
if
it
supports
enrich,
then
it
should
have
it
yeah.
It
should
be.
Okay,.
E
The
sql
one
doesn't
have
it
so
I
can
I
can.
I
can
do
that.
A
Yeah
but
the
actual
dog
comment,
when
you
I
mean,
if
you
are,
if
you
do
not
have
access
to
that
dog
and
you
are
looking
at
like
just
this
api
yeah,
I
mean
it's
not
very
straightforward.
A
E
A
Okay
yeah,
so
the
dock
itself
is
okay.
It's
just
said:
we
need
to
the
like.
Intelligence
can
also
help
us.
Okay,
yeah
I'll,
get
an
issue
just
to
track
that,
and
it
should
be
like
fairly
straightforward
to.
C
Just
basically
almost
copy
this
into
there
yeah
and
I
think
that's
actually
a
great
call
out
on
the
in
the
inline
docs
in
the
code.
Just
having
the
types
in
this
case
like
that,
you
have
on
the
screen,
have
http
requests
and
http
response,
mapped
to
the
to
the
event
names
that
there
they
correspond
to.
That
would
be
really
nice.
A
Yeah,
okay,
yeah
good
call.
I
will
create
an
issue
and
like
if
anyone
is
having
free
time.
Please
do
take
it.
Otherwise,
we
still
have
like
few
places
where
the
dork
is
incomplete
and
I
was
mostly
focusing
on
the
actual
md
file,
never
on
the
this
one,
but
thanks
for
calling
it
out
I'll
make
sure
like
when
we
are
doing
dog
wheel,
update
in
both
english
sense.
A
So
there
was
a
question
about,
like
exception
stack
trace.
I
think
it
was
someone
else.
It's
not
in
the
agenda
either.
Okay,
so
that's
a
separate
issue.
Okay,
we
can
get
to
it
later.
Okay,
then
we
have
last
one,
let's
open
it.
A
Oh
okay,
do
you
have
like
any
specific
questions
you
want
to
ask
or.
B
Yeah,
so
just
want
to
clarify
if
the
options
you
mentioned
in
this
pr
is
the
ingredient
api.
B
Oh
sorry,
I
lost
you
for
a
second.
Can
you
can
you
repeat
the
question?
I
mean
the
options
you
may
mention
in
this
pr
says
this
is
not
recorded
by
default,
but
you
can
provide
an
option
in
the
configuration
I
mean.
If
that
option
is
the
enrich
api
I
just
mentioned
no.
It.
A
A
So
whatever
you
did
here
in
this
pr,
users
can
technically
write
it
using
enrich
because
they
have
access
to
the
raw
object
and
they
can
read
it
and
call
set
tags,
but
we
don't
want
to
encourage
that
because
going
forward
like
several
years
from
now,
we
won't
be
like
asking
like
folks
to
pass
the
strong
object
as
it
is
because
this
these
are
like
special
instrumentations
which
existed
before
activity
source
and
at
that
time,
the
way
we
recommend
or
when
I
say
we,
the
way.net
recommended
libraries
to
instrument
was
using
diagnostic
source,
any
diagnostic
source.
A
There
is
no
you
you're
not
expected
to
populate
any
activity
tags.
You
just
create
an
activity
like
a
blank
activity.
Then
you
pass
the
raw
object.
That's
it.
The
job
of
the
library
is
done
at
that
point.
Then
it's
up
to
the
instrumentation
others
to
read
that
raw
object
and
populate
the
activity
that
was
the
like
recommendation
before
open
telemetry,
but
in
open
telemetry.
The
recommendation
is,
the
library
is
expected
to
like
populate
things.
Themselves
means
don't
give
us
like
raw
objects
and
expect
us
to
understand
what
it
contains.
A
The
libraries
should
be
instrumented
using
the
open
elementary
convention,
like
the
tags,
are
all
defined
in
well-defined
semantic
convention.
So
because
of
that,
we
need
this
feature.
We
don't
really
want
customers
to
write,
enrich
to
just
do
this,
especially
since
the
tags
which
you
are
adding
are
well
defined
in
semantic
conventions.
A
So
we
definitely
need
it,
but
only
ask.
Is
we
don't
want
it
on
by
default?
It's
just
like
the
record
exception
thing,
because
there
is
a
cost
involving
you
can
see
like.
We
have
to
do
some
string,
manipulation
and
headers
is
probably
fine,
because
we
are
just
reading
it,
but
then
we
are
doing
some
manipulation
here
so
protect
it
under
like
feature
flag
and
make
it
obtain.
A
So
if
a
user
really
cares
about
forwarded
for
or
sorry
the
client
ip
attribute,
then
they
will
opt
in
and
for
people
who
do
not
care
about
it,
they
don't
pay
the
penalty
and
there
is
no
hard
rule.
We
always
try
to
find
a
balance.
That
is,
I
mean
if
you
want
to
the
extreme
end,
is
we'll
have
a
option
per
tag
for
every
tag.
We
need
to
protect
it
with
a
option,
so
that
means
our
options
will
keep
growing
indefinitely.
A
So
we
try
to
find
a
balance
so
anything
which
the
spec
says
is
mandatory.
We'll
just
do
it.
There
is
no
way
to
opt
out.
I
mean
there
is
no
way
to
opt
out
using
the
instrumentation.
You
can
still
write
a
activity
processor
and
set
it
to
none.
That's
a
separate
thing,
but
for
anything
which
the
spec
says
not
required,
then
we
make
it
called
like
what
is
what
is
the
right
thing
for
us?
D
But
like
you
said
that
the
goal
of
the
sdk
is
to
find
a
balance
between
either
the
performance
penalty
or
user
configuration
of
the
sdk
right
so
and
that
you
said,
like
a
lot
of
attributes
in
this
spec
are
not
required
and
we'll
probably
end
up
having
a
feature
flag
for
each
of
those
attribute
which
can
be
like
toggled
on
and
off.
A
A
D
I
think
our
our
preference
is
that
we
keep
the
performance
overhead
minimal
in
favor
of
getting
like
a
one-time
configuration
from
users.
A
Oh
sorry,
I
didn't
get
that
so
you
are.
D
Saying
that
so
in
this
case,
what
I'm
trying
to
say
is
that
we
try
to
keep
the
performance
overhead
minimal
so
that
customers
can
opt
in
but
of
course,
in
their
configuration
of
the
tracer
provider
or
the
instrumentation,
they
would
have
to
do
more
work
of
choosing
what
they
want.
Yes,.
A
Okay,
yeah,
I
mean
it's.
There
is
no
straight
answer.
It's
like.
I
have
seen
like
different
six
hours
yeah,
it's
a
trade-off.
A
E
E
A
Oh
hello,
I
am
back
hey,
welcome
back
yeah.
I
had
a
power
outage,
so
I
just
switched
to
backup
internet.
So
maybe
I
have
a
little
bit
slower
connection,
but
hopefully
you
can
still
hear
me.
A
Yeah
we
can
hear
you
yeah.
Okay,
so
I
mean
I,
as
I
was
saying
the
general
thing
is
we
have
to
find
a
balance
like
ourselves,
given
that
asp.net
core
and
http
client
they
are
like
in
the
like
hot
path.
For
most
customers,
we
are
trying
to
avoid
as
much
allocation
as
possible.
So
that's
a
general
guidelines
but
like
whether
we
want
feature
flag
for
each
of
them.
We
can
take
it
on
an
individual
basis
like
in
the
pr
we
can
discuss
like.
A
A
Yeah,
I
didn't
look
at
all
the
tags
which
are
being
added
in
this
pr,
but
that's
my
general
thinking
after
I
looked
at
like
single
one.
I
mean
just
a
single
tag.
B
A
Yep
exactly
we
already
have
like
many,
like
not
many,
but
at
least
a
couple
of
options
on
spinach
core,
which
is
doing
the
similar
thing.
A
A
C
But
I
guess
I'm
thinking
like
if
I
had
custom
headers
that
were
specific
to
my
business
case,
then
it
might
be
nice
to
be
able
to
configure
instrumentation
rather
than
rather
than
like.
You
know,
back
to
the
enriched
conversation
me
implementing
the
enrich
thing,
which
is
more
complicated
than
just
configuring.
Like
hey
capture,
my
http
header,.
C
A
No
think
no
yeah.
If
there
are
any
other
questions,
we
can
discuss
it
now.
Otherwise
we
can
go
back,
get
10
minutes
back.
D
Cj,
I
had
one
more
thing
from
last
week:
it's
not
on
the
agenda,
but
we
had
a
discussion
about
the
ownership
of
and
maintainability
of
code
in
the
control
repo.
Did
you
get
a
chance
to
talk
to
others.
A
D
A
Okay,
yeah
so
we'll
have
the
same
conversation
next
week
or
I'll
put
the
contributor
one
back
to
the
next
week
agenda,
because
I
want
to
make
sure
we
keep
focus
on
the
1.0
release
right
now
and
everything
else
can
be
relatively
low
priority.
So
I'll
just
push
it
to
the
next
week
or
the
week
after
next
agenda.
A
A
Yeah
and
like
in
general,
like
anything
in
control
repo
by
default,
has
lower
priority
because
we
have
to
focus
on
releasing
the
actual
sdk,
so,
naturally,
anything
which
is
not
in
the
like,
open,
elementary.net
repo
will
be
treated
as
a
relatively
low
priority.
But
once
we
done
with
the
ga
we'll
get
back
to
each
of
them,.
A
All
right,
if
there
are
no
questions,
we
can
stop
fight.
10
minutes.