►
From YouTube: 2022-03-16 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).
C
D
I
think
we
can
start
in
maybe
one
minute
to
have
any
items
in
the
agenda,
so
it
should
be
related.
D
Okay,
I
think
we
can
start
now
yeah
if
you
are
in
the
call,
please
make
sure
to
add
your
name
since
there
is
no
agenda
I'll,
give
a
quick
update
on
the
current
status,
but
qca.
D
If
not
I'll
give
a
quick
update
on
the
release
and
then
you
can
go
over
the
tiers,
open,
vrs.
Okay,
let
me
yes,
it
looks
like
allen
is
not
joining
so
maybe
once
he
gets
here.
D
I
can
ask
him
if
you're
ready
for
another
release,
because
the
last
release
we
had
like
some
breaking
changes,
especially
for
people
who
are
using
the
otlp
exporter,
so
we
have
fixed
it
and
there
is
a
pr
in
the
spec
repo,
which
is
sorry
this
one
which
talks
about
what
is
the
default
reader,
which
should
be
associated
with
in
memory
and
console.
So
that
would
be
a
nice
thing
to
have
in
the
next
release.
So
hey
ellen.
D
I
was
just
talking
about
this
vr,
which
would
make
our
life
slightly
easier
by
allowing
consolidated
spotter
to
be
default
paired
with
push-based
periodic
exporter.
D
So
I
think
it
would
make
sense
for
us
to
see
if
this
gets
washed.
If
it
gets
smart,
we
can
take
it
in
and
then
do
a
release.
Think
we
don't
need
to
well
yeah.
There
was
another
issue
for
otl
exporter
which
is
fixed,
but
it
may
be
okay
to
wait
for
this
spec.
Also
to
be
more
so,
we
can
combine
that
into
the
upcoming
release.
D
D
Yes,
as
soon
as
we
have
that
we'll
do
the
release,
so
that
would
be
like
there
is
some
logistic
challenges
which
we
faced
last
time.
We
think
we
there
are
some
issues
open
there.
It's
mostly
about
the
versioning.
We
were
using
the
rc-10
so
which
were
treated
as
like
older
than
energy.
D
So
we'll
it's
not
an
issue
for
the
core
packages,
because
we
are
still
at
rc
for
four
or
four
three,
but
I
I
would
like
to
use
the
dot
followed
by
the
actual
number,
so
dot
one
dot
two,
so
that
will
not
cost
this
problem
anymore.
So
we
need
to
like
figure
out
how
to
handle
that
now
that
we
already
have
ten,
can
I
go
back
and
do
like
dot
11?
D
Will
it
be
treated
as
a
new
one,
so
so
a
little
bit
experiment
to
do
before
you
decide
on
the
questioning,
so
I'll
also
make
a
fix
to
the
contributing
dog
or
releasing
doctor,
make
it
very
clear
here
and
maybe
utkash
when
he's
here
I'll.
Let
him
know
about
the
control
report,
because
we
are
going
to
face
the
same
issue
in
the
contract
with
password
yeah.
That's
the
release
update,
maybe
like
we
are
seeing
like
good
progress
in
the
metric
spec.
D
So,
finally,
some
pr
which
were
lagging
for
like
months
received
enough
approvals.
You
can
see
like
after,
like
several
attempts
it.
This
has
like
enough
approval,
so
I
think
this
will
get
much
very
soon.
So
that
would
think
it's
from
where
it
says
this
is
the
blocking
issue,
maybe
yeah
these
three.
D
So
this
is
already
going
to
these
two
are
already
covered
by
the
same
gear.
So
after
that
there
is
nothing
left.
So
if
things
move
as
per
this
plan,
then
we
should
have
the
spec
being
stable
case
by
the
latest
by
next
week.
So
we
should
still
need
like
at
least
a
week
or
two
to
make
sure
like
we
don't
have
like
any,
because
we
did
like
a
lot
of
changes
in
the
last
two
months.
So
we
need
to
make
sure,
like
things
are
still
good
enough.
D
So
we
need
to
do
the
proper,
like
check
to
make
sure
like
nothing
is
like
having
an
issue
so
especially
the
metric
side
yeah.
So
that's.
A
Just
regarding
that,
you
know
related
to
the
release
question
for
you.
The
otlp
thing
was
not
the
only
bug
that
I
created
in
the
last
release.
I
I
have
some.
I
have
a
bug
that
I'm
I'm
almost
ready
to
pull
up
back
at
a
draft
yeah
that
we
might
want
to
wait
on
yeah
exactly
this
one
right.
There
multiple
views.
D
Yeah
yeah
yeah.
We
definitely
need
to
address
that.
It's
wait
that
was
not
introduced
in
the
last
release.
It
was
there
oh
yeah.
Actually
it
was
introduced
yeah,
it
was
the
instrument.
Identity
was
new
thing:
okay,
okay,
yeah.
That
makes
sense.
Let's
wait
for
that.
Also,
it
should
be
fine.
D
We
could
still
target
like
doing
it
by
this
friday,
if
not
like
latest
by
early
next
week.
So
there
is
another
thing
which
we
want
to
really
make
it
part
of
the
next
release.
I
mean
1.0.
This
is
something
which
we
discussed
earlier
activity
status.
D
We
have
the
approach,
I
think
it
just
a
matter
of
like
doing
it
for
all
the
exporters,
so
eugene
is
already
on
the
pr.
So
it
looks
good.
I
offer
to
spend
some
more
time
reviewing
it
so
that
we
can
make
it
part
of
1.2.
D
The
reason
is
like
it's
really
like:
1.2
is
claiming
to
be
not
just
a
matrix
supporting
release.
It's
also
covering
the
dot
net.
D
6
so
and
status
is
added
in
dot
net
6,
so
it
makes
sense
to
add
it
part
of
the
1.2
release,
if
at
all
possible-
and
it
looks
like
we
should
be
able
to
make
that
happen
in
1.2,
so
it
should
be
a
good
good
payout
for
the
next
release,
depending
on
how
many
of
them
we
could
cover
like
this
week,
even
if
we
have
just
one
that's
at
least
good
enough
for
a
demonstration
of
the
concept
and
copying
it
over
to
other
exporters
should
be
very
easy
yeah.
D
So
that's
the
update
on
release.
So
now
we
can
go
to
the
topic
which
I
think,
michael
adams,
about
promisius
exporter.
I
really
apologize
for
not
being
very
active.
I
really
just
asked
michael
go
and
fix
whatever
is
needed
for
the
prometheus.
So
michael,
do
you
want
to
like
drive
it
or
do
you
just
want
me
to
oh
before
we
go?
I
think
we
have
a
new
person
in
the
court,
so
maybe
it's
time
to
live
chin.
Do
you
want
to
just
say
hello
to
the
rest
of
the
folks
here.
D
Well,
you
can
hear
us
you're
still
on
mute,
so
we'll
come
back
after
we
go
over
the
prometheus
exporter
to
introduce
new
members,
okay,
yeah
michael,
like
do
you
want
to
like
walk
us
through
the
issues
and
like
your
proposals,
I
think
yeah
there
are
two
pairs,
so
maybe
I
can
open
one
and
you
can
go.
Yeah
sounds
good.
Okay!
Let
me
open
the
first
one
and
I
will
also
grab
the
second
one.
E
So
today
we
have
there's
two
different
ways
to
do
prometheus.
You
can
launch
sort
of
a
standalone
version
using
the
http
listener,
which
is
kind
of
net
framework
way
of
doing
a
web
service.
We
also
have
an
asp.net
core
middleware
version,
depending
on
if
your.net
framework
or
your.net
core
it
will
switch.
So
if
your
dotnet
framework,
you
don't
get
the
middleware,
you
just
get
the
listener
it's
enabled
by
default.
E
If
you're
targeting
netcore
app,
you
have
asp.net
core,
we
disable
the
listener
by
default,
and
we
do.
We
allow
the
user
to
register
the
middleware.
We
can't
do
it
automatically,
so
the
middleware
is
internal
and
we
have
a
single
extension
which
registers
it
basically
as
a
forked
pipeline.
So
it's
using
the
map,
registration
style
and
then
it
has
a
path.
E
You
can
configure
that
path
via
the
options.
So
there's
some
gaps
we
have
like
you
can't
put
anything
in
front
or
behind
of
that
middleware.
If
you
wanted
to
add
authentication
or
you
wanted
to
validate
some
custom
headers
or
something.
So
we
need
to
allow
that
support
somehow
different
ways
to
do
that.
We
could
just
make
the
middleware
public
and
let
the
users
figure
out.
E
However,
they
need
to
make
that
happen.
That's
sort
of
what
travis
was
pushing
for.
I
decided
to
do
have
some
extensions
to
sort
of
help
the
user
through
that.
So,
if
you
look
at
this
pr
there's
a
bunch
of
discussion,
some
of
it
is,
I
define
sort
of
the
use
cases
that
were
that.
I
think
we
should
support
so
there's
a
very
simple
use
case,
which
is
what
we
have
today.
E
You
just
want
to
register
it
at
the
default
path,
which
is
slash
metrics
in
your
regular
pipeline.
So
there's
an
extension
that
just
allows
you
to
do
that.
That's
sort
of
the
first
one,
if
you
scroll
down
you,
can
now
also
do
that
basic
registration
as
well
as
pass
a
callback
that
allows
you
to
register
anything
else
in
that
sort
of
branch
pipeline.
So
if
you
wanted
to
set
up
authentication
or
any
other
middleware,
you
can
now
do
that
from
this
extension.
E
That
extension
always
fires
before
our
prometheus
middleware
is
registered.
So
presumably
somebody
might
want
to
do
something
after,
but
if
you
look
at
our
middleware,
it
basically
writes
out
the
response
and
doesn't
call
the
next
delegate.
So
I
don't
see
any
usefulness
that
would
come
out
of
supporting
that
because
we
won't
even
call
it
so.
This
extension
allows
you
to
just
do
stuff
before
the
middleware,
which
seemed
like
the
only
valid
case
to
me.
D
About
this
one
right,
yes,
like
just
okay,
yes,
you're,
basically
saying
any
custom
actions,
custom
configuration
which
the
user
has
will
be
done
before
and
we'll
always
make
sure
we
always
add
the
prometheus
one
as
the
last
middleware.
D
E
If
you
scroll
down
now,
here's
another
one
where
you
can
change
the
path:
okay,.
D
Technically,
this
is
something
which
they
can
give.
No
think
this
has
to
be
given
by
I
mean
I
was
thinking
like
whether
this
is
like
can
be
achieved
by
the
first
one,
by
providing
the
scrape
and
point
path.
E
E
E
E
Basically,
yeah,
if
you
look
at
line
188,
so
if
you
don't
specify
the
path,
we
will
take
it
from
the
options,
so
you
still
have
the
ability
in
your
startup
configure
services.
If
you
bind
prometheus
exporter
options
to
your
configuration,
you
can
still
control
it
externally
through
a
json
file,
command
line
environment
variables,
so
that's
still
preserved.
D
E
E
So
allen
was
looking
at
the
asp.net
core
repo.
They
seem
to
do
both
things.
You
have
a
bunch
of
extensions.
The
middleware
is
also
public,
I'm
kind
of
leading
to
keeping
it
internal
just
because
our
middleware
isn't
really
meant
to
be
extended
like
it.
It
writes
the
response
and
it
terminates
so
to
allow
people
to
just
use
it.
D
D
I
think
there
were
like
another
discussion
about
trying
to
declare
like
where,
in
the
middle
of
so
many
things
I
might
be-
maybe
here
or
maybe
somewhere
here
there
was
like
some
discussions
around
the
prometheus
exporter
being
like
very
neutral,
doesn't
know
anything
about
espana
core
doesn't
know
anything
about
http
listener.
D
D
I
think
it
would
be
called
open,
elementary.exporter.prometheus.asp.net
core
something
like
that,
so
that
we
can
keep
the
like
the
core
exporter
like
really
really
small,
without
any,
without
not
much
extensibility
points
and
things
like
riley,
or
someone
mentioned
the
use
case
where
we
cannot
really
assume
people
are
going
to
use
sp
core.
D
That
could
be
people
using
like
wcf
or
ovin
based,
so
they
they're
going
to
like
I
mean
that,
will
force
us
to
add
or
modify
the
exporter
to
be
aware
of
now
spinner
code,
but
in
the
future
like
more
and
more
the
framework.
So
the
way
out
of
that
one
way
is
to
keep
the
core
one
independent
of
any
particular
web
hosting
technology
and
provide
extension
packages
for
asp.net
core
and
in
the
future.
If
there
is
a
need
for
wcf
or
something
like
that,
it
can
be
like
really
independent
package.
D
So
the
user
only
needs
to
pull
whatever
they
need.
They
don't
need
to
pull
in
any
extra
packages
if
they
don't
care
about
that.
But
I'm
now
I'm
hoping
that
that
comment
was
somewhere
here,
but
maybe
it's
in
an
issue.
D
A
The
the
package,
if
that's
what
you
were
looking
for,
I
think.
D
Yeah,
you
can
continue
think
we
are
just
describing.
I
mean
discussing
the
lighter
thing
about
like
the
idea
of
keeping
the
prohibition
exporter
the
core
exporter
being
like.
D
D
So
let
me
ask
you
one
question:
so
the
http
listener
thing
which
we
currently
use
for
the
dotnet
framework
is
that
a
like
production
recommended
thing,
or
is
it
only
for
like
testing
purposes.
E
It's
a
good
question.
You
should
probably
ask
runtime,
I
assume
it's.
I
mean
it's
like
it's
in
system.net,
to
go
double
check.
D
Because
if
you
were
to
go,
go
to
the
route
of
like
like
core
exporter,
not
having
any
knowledge
of
asp.net
core,
would
that
mean
like
it
won't
have
any
knowledge
of
any
hosting
techniques,
including
the
http
listener
approach?
Or
would
that
I
mean
would
that
be
part
of
the
core
exporter
and
sp
net
core
and
wc?
If
other
things
can
like
be
like
additive
things?
On
top
of
that,
as
a
separate
package.
E
I
think
it
might
be
surprising
for
anyone
on
asp.net
core.
I
think
I
think
the
the
feeling
the
instinct
people
have
to
you
know
configure
authentication
through
the
middleware.
I
think
that's
sort
of
natural
when
you're
in
the
asp.net
core
world.
I
think
discovering
that
we
were
starting.
You
know
a
listener
inside
the
process
running
kestrel.
I
think
that
would
be
very
surprising
for
false.
E
D
Okay,
yeah.
That
makes
sense,
but
my
question
was
more
about
like
will
there
be
anything
called
open,
elementary.exporter.prometheus.
E
It's
a
good
question
I
mean
just
from
like
code
reusability.
It
would
be
nice
if
everything
was
in
a
project
that
was
referenced
by
you
know
sort
of
the
end
of
the
line
things,
but
we
could
also,
you
know,
have
a
project
that
we
don't
ship
and
we
just
include
those
files
into
the
other
projects
and
there's
there
is
a
way
to
like
consume
an
assembly
inside
your
code.
I've
never
played
with
that.
I
don't
know
if
alan
you
have
any
experience
with
that.
D
That
sounds
like
the
easiest
way
to
go,
because
we
already
have
so
many
code
doing
that
already.
E
I
think
that
would
eliminate
a
lot
of
the
confusion
when
you're
just
looking
at
that
options
class
and
it
has
some
listener
settings
and
then
a
path
that
applies
to
both.
If
we
just
split
them,
it
would
just
keep
the
options.
Simple
you'd
only
see
the
options
that
apply
to
whatever
you're
consuming.
D
You
think
I
mean
whatever
we
decide
here,
we'll
probably
have
like
some
implication
on
the
other
stuff
as
well.
For
example,
like
I
mean
we
have
a
single
package
for
http
client,
the
instrumentation
for
http
client,
and
it
has
a
bunch
of
things
which
are
only
applicable
to
the
framework
and
another
set
of
things
which
are
only
applicable
to
the
http
client.net
core.
So
there
were
like
some
confusion
originally,
but
since
we
have
a
long
time
before,
we
will
stabilize-
and
we
thought
we'll
come
back
to
it
later,
but
for
prometheus.
D
We
have
to
solve
it
reasonably
fast
because
as
soon
as
the
metric
is
done,
I
think
people
will
like
work
towards
making
is
making
the
prometheus
one
also
stable,
so
yeah.
I
think
I
mean
I
like
the
idea
of
like
having
like
two
separate
packages,
the
confusion
which
michael
you
are
referring
to
is
like
somewhere
here
right.
So
this
part-
and
there
is
this
middle
sorry-
there
is
this
application
built.
D
Basically,
the
sp
net
core
hosting
way
in
the
same
package
is
potentially
confusing,
so
we
could
separate
that
out,
but
even
then
like.
Let's
assume
that
we,
the
only
thing
which
we'll
ship
for
now
is
the
sp
net
core
middle
middleware
based
option,
and
even
if
you
don't
ship
this
thing,
we
need
to
first
confirm
whether
this
is
something
which
is
like
production
recommended
or
not.
I
think
yeah.
We
can
ask
that
in
the
runtime
folks.
D
I
can
take
that
action
item
to
see
whether
it
is
something
which
is
recommended
for
like
production
or
just
for
like
testing
something,
and
we
could
end
up
with
just
a
spinner
core
thing
and
it
would
make
sense
to
add
the
pr
because
it's
anywhere
tied
to
asp.net
core,
so
it
makes
sense
to
do
things
the
experiment
core
way,
and
I
mean
I
don't
feel
like
any
obvious
concern.
With
this
approach,
I
mean
we
need.
D
We
can
potentially
review
the
like
all
the
public
api
once
again
to
see
whether
we
can
collapse
one
of
one
or
two
of
them,
but
based
on
what
michael
just
described,
it
looks
like
we
need
to
expose
like
this
many
public
eps
and
I
don't
see
any
major
issue
with
that.
Either.
A
E
D
A
Desire
is
to
have
things
run
in
front
of
the
branch
pipeline.
I
I
thought
the
way
middleware
worked
is
that
common
middle
you,
you
could
set
things
up
such
that
common
middleware
would
be
invoked
for
all
the
branches
that
then
come
later.
E
D
Okay,
but
at
least
for
the
immediate
plan,
we
should
be
okay,
exposing
this
thing
there
is
one
caveat
like
we
would.
We
would
potentially
like,
like
after,
like
initial
few
races,
we
could
potentially
release
this
as
a
separate
package.
So
core
is
consuming
this
package.
They
may
need
to
rename
the
package
they
consume
to
the
company
elementary
exporter
from
the
sp
net
core,
and
you
should
be
okay
with
that,
given
it's
still
not
stable.
F
D
Explanation
which
you
gave
because
it's
not
like
a
typical
middleware,
because
we
make
one
thing
which
really
struck
me
was
like
we
don't
call
the
next
one
anyway,
so
we
are
not
being
like
a
friendly
middleware,
so
we
don't
really
need
to
expose
it
to
the
user.
A
So
I
think
we
actually
close
is
the
request
actually
closed
after
that,
or
is
it
potential
to
like
write
a
response?
We
close
it.
Okay,.
F
D
Always
expose
it
later,
if
yeah
that's
my
general
thing
that
we
can
always
like
keep
things
internal
and
adding
it
back
would
be
always
an
option
right.
We
write
the
status
quo
right,
I
mean
after
this.
No
one
can
fight
use.
My.
D
E
Okay,
but
you
can
you
can
also
do
that
with
a
middleware
before,
because
how
middleware
works
right
is
like
they're
called
in
order
on
the
way
in
and
then
the
reverse
order
on
the
way
out.
So
if
you
put
something
before
like
compression
or
something
it
still
has
a
chance,
you
know-
and
it's
finally
or
you
know
if
it's
a
compression
case,
it
just
switches
the
whole
response
buffers
it
all
up,
writes
it
out
when
it's
done,
but
you
could.
E
D
Yeah
also
like
michael,
do
we
know,
did
you
hear
from
travis
about
this
pr
like
did
he
have
any
concern
or
will
this
unblock
his
scenarios?
I
didn't
read
the
the
full
description,
but.
E
D
That's
the
case,
I
think
like
to
make
some
decision
to
unblock
him.
Let's
like
decide
that
we
will
like,
with
this
prayer.
D
D
D
You
don't
need
to
like
really
do
it
like
today,
but
like
it
could
be
good
to
keep
this
in
mind
that
we
will
have
like
if
you
are
recommending
it
to
your
customer,
just
a
heads
up
that
we
might
be
splitting
it
into
a
different
package,
but
that
should
be
like
a
like
expected
thing
if
it's
a
non-stable
package,
so
I
don't
think
it's
a.
E
I
think
originally,
when
I
worked
on
prometheus,
this
was
supported
and
then
somebody
went
in
and
added
validation
that
made
it
impossible.
B
A
The
internals
of
you
know
that
we're
using
http
listener,
and
I
think
that
makes
sense
if
like
http
listener,
is
this
thing,
that's
what
they
were
using
behind
the
scenes.
A
D
D
No,
no,
I
think
it's
different,
so
I
think
this
summarizes
it.
Actually,
it's
basically
what
we
discussed
earlier,
like
we
want
to
like
make
the
exporter
like
specific
to
the
underlying
mechanism
rather
than
exposing
it,
because
currently
doesn't
the
name
doesn't
sound
like
it's
tied
to
anything
in
particular,
so
we
want
to
expose
this
in
a
general
purpose
thing.
So.
D
Bro,
it's
not
a
security
event
financial,
so
that
would
answer
the
I
mean
that
would
give
the
answer
to
this
one,
but
I
think
okay.
Now
I
remember
like
why
else
involved.
Oh,
yes,
we
had
this
discussion
about
this
one
yeah,
because,
okay,
so
in
short,
like
whatever
we
discussed
about
like
if
we
make
the
exporter
unaware
of
any
specific
platforms
and
we
like
ship
dedicated
ones,
then
it
should
solve
like
the
problem
described
here
as
well.
A
Okay
just
decide
now,
regarding
that
I
just
bought
the
link
in
the
channel.
It
is,
I
think
I
know
why
the
security
concern
came
up
is
because
it
is
a
security
concern,
but
if
we're
actually
exposing
that
it's
http
listener
that's
being
used,
then
you
know
we
can
just
direct
them
to
this
documentation.
It's
not
an
open
telemetry.
It
wouldn't
be
able
to
open
telemetry
like
sdk
specific
problem,
but
that
big
warning
there
yeah.
D
D
Of
course
we
want
to
like
advise
users
about
it
by
linking
to
the
dock
which
ellen
shared,
so
by
splitting
the
package
into
dedicated,
it
would
solve
like
bunch
of
problems
so
maybe
like
michael,
would
you
want
to
like
work
on
that
like
once
we
done
with
this
one,
or
do
you
want
to
like
just
create
an
issue
and
see
if
anyone
else
has
time
to
pick
it
up.
E
I
can
create
the
issue
and
see
if
anybody's
interested,
otherwise
I
don't
I
don't
mind
doing
it.
Okay,
oh.
D
D
Yeah-
maybe
let's
discuss
that
like
later,
because
we
have
a
very
lighter
discussion,
which
I
really
want
to
quickly
ask
today
and
we'll
release
it
later.
So
for
now,
sorry.
D
D
D
D
So
we
never
discussed
this
in
detail,
but
maybe
it's
trying
to
like
start
thinking
about
this
one,
because
most
likely
we
want
to
like
decide
what
would
be
the
final
resting
place
or
like
final
shipping
place
for
these
instrumentations.
Would
that
be
the
contrib
one
so
that
we
can
kick
out
everything
which
says
instrumentation
from
hearing
potentially
even
the
extension
slot
hosting?
Even
this
is
also
not
strictly
from
the
spec,
so
we
should
be
able
to
remove
that
as
well.
D
So
that
way,
like
the
only
thing
which
would
be
in
this
repo
would
be
the
thing
which
has
a
spec
return
in
the
open,
elementary
spec
repo.
That's
one
way
of
doing
it,
but
then
the
question
is
in
the
control
repo.
There
is
no
way
to
really
tell
whether
a
package
can
be
like
really
is
really
actively
maintained
or
not,
because
anyone
can
come
and
contribute
and
then
they
could
just
disappear.
D
We
do
have
like
testing
for
the
sdk
and
apa,
but
by
virtue
of
having
the
instrumentations
here,
they
offer
us
like
free
testing.
We
several
times
we
discovered
issues
with
the
core
sdk
just
by
working
on
the
instrument,
so
they
actually
are
in
a
way
beneficial
to
us,
because
that
really
validates
the
or
help
us
validate
very
quickly.
Whether
this
will
break
something
a
landing
unintentionally.
D
So
it
may
be
of
some
benefit
to
keep
some
of
the
instrumentations
here.
But
for
that
we
need
to
define
like
some
sort
of
policy
like
because
we,
whatever
we
decide
it,
should
be
like
applicable.
So
if
someone
tomorrow
comes
and
submits
a
pr
for
an
instrumentation,
we
should
have
a
clear
guidance
which
says
what
packages
gets
hosted
in
the
main
trip
versus
what
goes
into
the
contrib.
D
Having
like
had
time
to
like
think
through
this
one.
But
I
was
quickly
thinking
we
should
at
least
keep
the
asp.net
core
and
the
http
client
one
in
the
main
drupal.
D
The
main
reason
is:
they
are
almost
released
along
with
the
top-notch
release
and
we
already
have
a
leading
edge
dependency
on
the
diagnostic
source,
which
gets
updated
with
every
dot.
Naturally
so,
and
these
two
are
sp
core
and
http
client
are
like,
as
part
of
in
fact,
http
client
is
really
part
of
the
github
dot
net.
D
Slash
runtime
group
or
hispanic
core
is
part
of
the
sp
net
core
organization,
but
still
these
are
like
always
shipped
together,
so
it
probably
makes
sense
to
keep
them
here
as
the
core
instrumentation,
which
is
required
for
every
almost
every,
not
really
every
but
most
of
the
top
net
customers,
and
we
can
move
everything
else.
D
That's
one
way
of
in
so
that
we'll
have
like
some
core
instrumentation
doing
us.
The
end-to-end
testing
for
free,
because
if
you
break
something
really
cool,
we
know
like
immediately
rather
than
releasing
something
and
later
when
someone
updates
the
control
before
releasing
that
okay,
this
got
broken.
So
we
need
to
go
and
fix
something
and
release,
but
we
don't
need
to
make
that
decision
today,
we'll
let
everyone
like
think
on
this
program
a
little
bit
more.
D
I
also
don't
know
like
whether,
like
individual
companies
wants
to
offer
because,
like
there
is
this
aws
concept
like
that
they
have
a
distro
where
they
take
like
four
co,
maybe
like
they
take
a
sub
module
from
this
one
they
offer
like
support
the
aws
support.
I
don't
know
whether,
like
new
record,
any
other
vendor
has
any
thoughts
on
that.
So
I
mean
for
the
best
of
my
knowledge.
I
don't
think
microsoft
has
made
any
public
announcements
on
this
one.
D
So
for
now
it's
just
like
any
other
packages
which
is
not
stable,
but
this
is
something
we'd
like
to
discuss,
maybe
over
the
next
several
meetings
because
curve,
allen
or
michael
love.
Anyone
else
any
any
thoughts
on
this
one
is
it
like.
Did
I
just
throw
some
random
topic
without
any
warning.
A
D
Was
like
some
discussion?
Maybe
you
were
part
of
it
like
there
was
like
java
instrumentation
had
some
thing
in
the
main
draw
point
like
the
issue
was
discussed
in
the
spec
and
they
said
as
long
as
the
maintainers
are
fine
just
do
whatever
like
you
can
decide
what
packages
you
want
to
host
this.
D
A
D
Yeah,
I
think
for
now,
then
maybe
we
can
just
like
differ
making
a
decision
on
this
one
for
like
some
more
time
so
like
last
week,
we
added
to
kasha's
a
new
maintainer
for
the
contract
when
he's
already
doing
a
lot
of
cleanup
there.
D
So,
like
I
mean
we
still
haven't,
finished
cleaning
it
up,
because
we
don't
know
how
to
assign
code
owners.
So
we
still
like
working
or
working
through
that,
so
maybe
like
in
a
few
weeks
we'll
have
it
ready.
D
Then
we
can
come
back
and
make
this
decision
like
how
and
we
cannot
now
that
the
naming
is
done
like
it
doesn't
matter
whether
we
ship
it
from
here
or
the
contract
report.
The
name
would
be
the
same.
The
only
thing
which
meant
only
thing
which
tells
us
where
this
is
coming
from
is
the
source
url
in
the
new
get
package.
So
that
way
people
can
still
tell
where
it
is
coming
from
yeah.
D
So,
let's
wait
for,
like
maybe
a
few
more
weeks
for
us
to
like
finish,
wrapping
up
like
organizing
the
country,
repo
and
like
start
shipping,
all
the
packages
in
the
new
version
and
the
new
name,
and
then
we
can
come
and
come
back
and
decide
what
we
do
about
the
individual
instrumentation
and
that
will
also
be
a
good
time
to
discuss.
Where
do
we
host
the
prometheus
platform?
Specific
exporters,
okay,
yeah?
So
that
means
like
if
anyone
has
like
topic,
I
mean
something
to
think
about
it
or
learn
from
other
six.
D
D
Okay,
let's
quickly
go
back
to
notes
to
see
if
there
is
any
other
topics
added,
no
and
the
or
was
the
new
journey
they
seem
to
have
left.
So
we
don't
have
any
new
journey
right
now,
since
we
have
a
few
minutes
left,
maybe
we
can
quickly
go
through
some
years
in
case
anything
needs
immediate
attention.
Please
bring
it
now.
Otherwise
we
can.
D
Yeah,
I
think
this
is
fairly
straightforward,
so
probably
yeah,
we
already
created
an
issue
and
I
left
a
comment
and
we
decided-
or
we
discussed,
that
we
did
the
same
work.
The
fact
that
we
could
change
the
settings
after
constructing
the
factory
was
not
like
the
intention,
so
we
could
fix
it,
so
this
seems
to
be
taking
a
snatch
of
the
options.
D
D
B
Do
shallow
or
deep
copy
it
does
both
it's
deep
copying.
Everything
is
in
the
object,
but
that
then
copies
the
reference
to
those
other
classes,
so
the
list
of
processors
and
the
resource
builder,
the
reference
to
those
gets
copied
okay.
But
for
this
use
case
it's
not
a
problem,
but
for
naming
wise
it's
a
bit
of
a
misnomer.
D
I
was
thinking
like
what,
if
we
instead
of
doing
this
thing,
what
if
we
do
it
by
hand
like
we
only
have
like
one
two,
three,
maybe
four
things
right.
Five
things,
including
the
processor
processor,
is
intentionally
like
capable
of
being
modified
after
the
fact
as
well,
so
maybe
like.
If
it's
just
like
one
two,
three
and
four,
then
we
could
do
a
copy
ourselves.
Yes,
yeah.
That's
that's
also
valid.
D
I
mean
at
least
I
don't
recognize
if
you
are
using
this
built-in
member
wise
clone,
so
we
should
be
able
to
just
take
a
snapshot
similar
to
what
we
do
for
tracing
and
it
is
intentionally
allowed
to
add
processors
now
because
tracing
allows
it.
So
it
makes
so
decent
to
allow
logging
to
also
add
processors
after
constructing
the
logger
factory.
D
So
can
you
like
review
the
tracing
one
and
see
if
you
can
make
the
same
behavior
it's
not
by
accident?
It
was
intentionally
added
as
a
feature
to
the
tracing
sdk
to
allow
processes
to
be
added.
So
it's
a
documented
feature
so
make
sure,
like
you
have
the
same
behavior
as
us
tracing
for
this
one.
Also
yeah
minor
command
about
like
not
using
this
one
like
by
hand
copying
just
three
three
or
four
three
fields
and
then
resource
yeah,
four
okay,
it
should
be
like
relatively
straightforward.
D
Let's
look
at
anything
else.
I
think
this
we
don't
need
to
discuss
so
travis
has
been
like
offering
to
fix
the
analyzer
because
he
was
primarily
affected
by
that
when
he
just
we're
scoring
back
so
nothing
like
which
requires
like
a
huge
discussion.
We
should
be
just
like
reviewing
the
pr's
and
making
sure
it's
not
breaking
anything
accidentally.
D
D
Yeah,
so
I
think
I
left
a
comment
somewhere.
Maybe
it's
gone
now
so
for
logger,
it's
a
bit,
it's
a
bit
different
by
design
because
it
doesn't
follow
the
proper
provider
pattern,
primarily
because
we
are
not
designing
this
from
scratch
because
we
are
just
building
onto
whatever
the
eye,
logo
or
infra.
Also,
the
user
doesn't
almost
they
never
deal
with
provider
directly.
They
always
use
the
I
mean
the
way
they
set
up
open
loading
in
general
is
by
constructing
the
logo
factory.
D
So
we
should
focus
on
that
terms
because
we
already
took
independence
and
high
lower,
so
we
should
stick
with
the
terms
from
there,
and
I
mean
I
don't
know,
what's
the
right
thing
to
put
here,
but
let
me
think
about
it
and
give
some
feedback
here,
because
the
terms
like
I
mean
it's
technically
correct,
but
the
user
is
not
doing
it,
so
it's
more
like
making
it
slightly
tweaked
so
that
it
covers
the
intent,
yeah
and
probably
like.
D
D
Yeah,
that
would
be
it
any
comments
on
this
part
like
maybe
like
other
people
who
have
like
worked
on
looking,
might
might
have
some
comments,
so
we
want
to
like
document
like
this
like
similar
to
what
we
have
for
tracing
and
logging,
where
we
specify
that
the
construction
of
the
provider
is
the
key,
no
matter
what
you
do
without
a
well
defined
or
well-constructed
provider,
nothing
is
going
to
happen.
Everything
is
known,
so
that's
the
message
which
we
want
to
include
here.
D
D
Okay,
we'll
leave
it
for
the
pr
for
people
to
comment.
So
I'll
look
do
do
another
comment
here.
This
may
be
of
interest
for
folks.
So
so,
unlike
the
tracing
and
meter
tracing
and
matrix,
the
loading
has
one
peculiar
aspect.
Where
you
need
that
logo
factory
to
obtain
the
logger.
D
There
is
no
other
way
you
can
create
a
logger,
but
for
metrics
and
tracers
you
don't
need
the
provider
once
you
create
it,
you
can
just
save
it
somewhere,
but
you
don't
really
need
it
because
you
can
construct
activity,
source
or
meter
like
using
the
constructor.
So
that's
a
difference
between
here.
So
maybe
that's
a
good
thing
to
include
like
mention
somewhere
here
I'll
leave
it
as
a
comment
like
once
the
meeting
is
over
and
if
maybe
alan
like,
if
you
have
some
better
wording
here,
please
help
with
that.
D
It's
not
like
p0,
but
it's
really
nice
to
have
like
nice
document
about
login
and
thanks
mothra
for
helping
with
the
dogging
dogs.
That
was
our
like
something
which
we
are
missing
for
quite
some
time,
but
now
that
we
are
getting
it
okay,
so
this
one
we
covered
and
this
one
so
which
is
not
here,
he
won't
be
working
for
at
least
one
more
month
this
on
vacation.
So
this
is.
D
I
can
give
an
update
on
why
this
is
important,
so
we've
been
having
this
hacky
instrumentations
for
espnet,
core
http
client
and
finally,
the
contain
is
moving
away
to
use
the
activity
source
directly.
D
So
that
means
we
can
get
rid
of
all
the
hackiness
which
we
have.
We
use
the
add
legacy
source
and
some
reflection
to
set
the
kind
and
activities.
Also
we
don't
need
to
do
that
anymore
in
seven
onwards,
so
this
was
just
a
draft.
We
have
to
quickly
test
whether
http
client
is
doing
the
right
thing,
so
we
we
still
need
the
code,
as
is
because
we
need
to
support
older
versions
of
http
client,
so
we
opened
like
two
issues,
one
for
tracking
http,
client
and
one
for
explaining
code.
D
A
So
yeah
in
the
last
release
I
I
landed
the
work
to
handle
the
whole
instrument.
Identity
thing.
That
is,
that
it's
now
possible
for
an
instrument
with
the
same
name,
description,
units
and
so
on
to
be
declared
multiple
times,
and
that
should
result
in
a
in
a
legit
metric
stream
that
you
can
record
against
and
so
on
and
the
way
we
implemented.
A
Identity,
okay,
right
yeah,
so
each
each
instrument
that
gets
registered,
they
basically
yeah
and
and
the
the
name
yeah
so
I'd
introduce
this
thing
called
instrument
identity.
So
when,
when
an
instrument
is,
is
instantiated
it
the
identity
is
captured
and
then
there's
a
map,
as
we
said,
there's
a
map
to
instruments
to
the
metric
that
they
influence.
A
But
I
guess
I
guess
the
name
instrument.
Identity
is
kind
of
indicative
of
my
the
all
right.
My
original
approach
is
kind
of
naive,
especially
when
it
comes
to
views.
So
this
test
that
you
have
up
on
the
screen.
A
The
complexity
with
views
is
that
I
a
it's,
not
really
an
instrument
identity
that
we're
after,
given
that
when
you
instantiate
an
instrument
and
it
matches
multiple
views,
it's
really
that
we
want
the
metric
stream
identity
is
how
I'm
thinking
about
it
now.
So
you
know
you
have
these
metric
stream
configurations,
you
know
they
they
have.
You
can
configure
tags
to
filter
and
you
can
also
configure
histogram.
A
Bounds
is
another
thing
and
basically
the
identity
that
I'm
after
here
is
not
just
about
the
instrument,
but
about
the
entire
definition
of
the
view,
plus.
The
instrument,
so
that's
what
I'm
fixing
in
this
pr,
okay,.
D
D
Then
you
have
another
instrument
that
would,
by
definition
it's
a
duplicate
because
it
matches
with
the
original
instrument
in
all
aspects.
So
we
treat
that
as
a
it
should
contribute.
I
mean
whatever
we
do
with
instrument
one.
It
should
be
having
the
same
impact
now,
if
you
do
instrument
two
dot,
increment
or
whatever,
for
that,
which
means
that
this
instrument
two
would
also
contribute
equally
to
this
metric
stream
and
this
metric
stream
okay
right
and
that
that
part
is
currently
broken
right.
That's
what
you.
A
D
Like
like,
is
there
any,
like
think,
is
there
anything
which
is
for
now?
Let
me
take
a
very
specific
example,
so,
in
the
absence
of
views,
if
you
create
two
instruments
like
this
like
having
the
exact
same
identity,
it
will
not
result
in
two
streams
because
they
are
supposed
to
contribute
to
a
single
stream
that
is
by
the
spec
right
now.
D
Let's
say
I
create
one
instrument,
just
one
instrument,
then
I
use
two
views
for
that,
having
exact
same
thing
here,
so
basically
I
ignore
these
two
for
now
so,
which
means,
when
I
create
this
instrument,
I'm
going
to
get
two
streams
one
from
this
and
one
from
this
they
are
exactly
the
same.
D
A
It
has
like
so
I
might,
but
if.
A
D
D
One
thing
one
like
implementation
detail,
which
might
affect
things
like
we
kind
of
treat:
oh
yeah,
no,
because
if
you
don't
have
a
view
matching
an
instrument,
we
add
a
null
and
we
treat
that
null
to
indicate
that
okay,
now
we
need
to
apply
the
default.
So,
okay,
okay,
yeah
I'll,
wait
for
your
like,
updated
pr
and
then
take
a
look
at
it
yeah.
This
is
a
very
interesting
problem.
I
could
find
never
paid
attention
that
close
but
yeah.
D
D
Okay,
yes,
that's
it!
We
are
one
minute
over
time,
so
yeah
thanks.
Everyone
we'll
see
you
again
next
week.
Okay,
now
I
don't
see
my
exit
button.
Okay,
it's
like
yeah.