►
From YouTube: 2022-02-10 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).
B
B
I,
like
the
shades
yeah
I
got
these.
These
are
like
blue
light
blocking
glasses,
so
they
completely
block
the
lights
in
the
evening
and
they're
supposed
to
help
with
sleeping-
and
you
know.
B
Everything
looks
very
orange
for
them,
but
I
don't
mind
I'm
just
I'm
not
working
in
any
graphics
related
stuff.
So
whatever.
B
B
A
C
Have
you
seen
the
the
apps
you
can
get
for
your
computer
that,
like
yeah,
do
the
same
thing:
yeah,
probably
not
as
well.
B
It's
not
the
same
thing:
they
like
change
the
color
temperature,
but
they
do
not
eliminate
the
blue
light,
so
your
monitor
still
emits
the
blue
light,
but
it's
just
a
bit
less
of
it.
Okay,
these
are
supposed
to
completely
filter
it
out,
and
I
I
just
judging
by
the
the
color
thing
that
they
are
doing
that.
A
A
A
A
The
already
reducing
chance
of
successful
release
may
as
well
throw
them
all
in.
So
I
will
plan
to
merge
those.
A
So
the
reason
we
need
this
in
our
integration
tests
is
the
sdk
lives
in
the
agent
class
loader
and
our
tests
don't
so
we
can't
get
the
like
the
span
data
directly
into
the
test
to
verify.
So
we
actually
marshal
into
a
byte
array.
We
can
transfer
the
byte
array
across
the
class
loaders.
The
class
loaders
can
see
that
and
unmarshal
it
in
the
normal,
the
testing
class
loader.
C
Yeah
yeah
I
mean
so
those
are
internal
classes
used
at
your
own
risk.
So
you
know
those
in
particular
the
which
are
just
like
the
marshalling
classes.
I
think
are,
are
unlikely
to
change
invisibility.
They
could
change
a
name,
but
you
know,
I
think
something
to
that
effect
will
always
be
there.
Cool.
C
Exactly
so,
there
was
an
issue
with
the
sdk
where,
if
you
configure
the
exporter
to
be
otlp-
and
you
don't
have
the
otlp
exporter
on
your
class
path,
then
there'll
be
a
no
pointer
exception.
C
When
you
try
to
shut
down
the
periodic
metric
reader
and
actually
like
for
that
matter,
you
know
whenever
you
try
to
export
as
well,
because
what's
effectively
happening
is
you'll
configure,
periodic
metric
exporter
with
or
periodic
metric
reader
with
a
null
exporter.
So
anytime,
you
try,
to
you,
know,
collect
metrics
and
send
them
to
the
null
exporter.
You'll
get
a
null
pointer
exception
and
so
yeah
this.
This
pr
fixes
that
and
there's
it
shouldn't
be
a
problem
for
the
agent.
C
Laurie,
you
know
talked
about
this
because
the
agent
packages
up
the
the
otlp
exporter,
but
it
is
a
problem
with.
I
think
you
mentioned,
that
there's
a
there's
a
test
agent
which
doesn't
package
the
otop
exporter
and
so
for
the
test
agent.
Where
the
you
know,
the
otlp
exporter
isn't
on
the
class
path
that
actually
every
single
like
test
that
uses
that
exits
with
this
null
pointer
exception,
or
you
know
at
the
end
of
when
on
shutdown,
throws
this
null
pointer
exception.
A
Lori,
what
I
say
yeah,
so
what
were?
What's
your
thought
you
looked
at
this
the
most
I
think.
D
D
C
You
know
yeah
so
just
like
temporarily,
until
the
next
release
comes
along
for
the
sdk,
so
temporarily
package,
the
the
exporter
in
the
test
agent,
instead
of
in
the
extension,
is
that
what
you're
suggesting.
D
A
Cool,
so
I
but
yeah
that
I
think
that
makes
sense
that
no
pat
no
need
to
patch
for
that,
even
if
we
have
to
live
with
it
for
in
the
the
tests
for
a
month,
that
seems
fine
or
it
seems
like
a
java
agent
issue.
A
Mates
any
of
your
prs
I
saw
there
was,
did
you
already
merge
the.
A
E
B
Yes,
so
my
creator,
once
I
mean
it,
would
probably
be
cool
if
this
one
could
merge
too,
but
I
won't
we,
we
won't
be
able
to
finish
the
from
load
for
the
release
so
that
the
user
who
filed
the
bug
but
machine
is
not
it's
not
working
correctly.
We'll
probably
have
to
wait.
B
A
Yeah,
so
I
did,
I
did
review
it.
If,
if
anybody
else,
I
guess
wants
to
review
it
go
you
know
it's
a
would
be
good,
but
otherwise
it's
good
to
merge
and
include.
A
All
right,
jack.
C
Yeah
yeah-
I
can
talk
about
this
so
for
anyone.
That's
not
familiar.
There's
been
this
debate
at
the
sdk
and
spec
level
about
a
couple
of
things
related
to
metrics
that
are
all
kind
of
intertwined.
C
C
You
know
the
java
sdk
has
allowed
that
so
far
for
synchronous
instruments,
so
you
can
ask
for
the
same
synchronous
instrument
from
a
meter
twice
and
you
can
record
data
against
it,
but
as
it
stands
today
at
the
spec,
that's
technically
not
allowed
java
and
a
couple
of
other
languages
think
that
that
should
be
allowed,
that
you
should
be
able
to
ask
for
the
same
instrument
multiple
times
and
get
a
valid
instrument
back
and
then
record
against
it
related
to
that
issue,
though,
if
you're
allowed
to
ask
for
the
same
instrument
multiple
times.
C
Well
then,
it
follows
that
you
should
be
able
to
register
multiple
callbacks,
so
asynchronous
instruments
should
so
that
that's
where
multiple
callbacks
is
intertwined
with
this
issue
of
instrument
identity-
and
you
know-
I-
I
think
that
we
and
java
have
have
talked
about
the
use
cases
for
that,
especially
for
like
things
like
the
micrometer.
C
C
So
you
should
be
able
to
like
register
a
callback
and
then,
at
the
end
of
that
callbacks
lifecycle,
you
should
be
able
to
remove
it,
and
so
these
three
things
are
kind
of
intertwined
instrument,
identity,
multiple
callbacks
and
then
extending
the
ap,
the
callback
api,
with
some
sort
of
remove
or
unregister
method,
and
so
this
this
affects
the
spec
at
the
api,
the
sdk
and
at
the
data
model
level.
C
So
it's
it's
pretty
extensive
in
terms
of
its
impact
and
a
lot
of
several
of
the
language
sigs
have
expressed
that
this
is
really
important
for
the
stabilization
of
the
sdk.
So
we
don't
want
to
build
an
sdk
and
an
api
that
don't
have
this
capability
in
it.
They
don't
think
it's
worth
it.
So
you
know
java
has
expressed
that
sentiment.
Go
has
expressed
that
sentiment.
C
Javascript
and
python
have
expressed
that
so
there's
there's
a
lot
of
consensus
there,
but
in
order
to
not
delay
the
sdk
stabilization
too
much
there's
a
push
to
you
know
prove
out
that
this
is
a
reasonable
approach
in
in
a
reasonable
timeline,
and
so
there's
different
folks
from
each
of
the
six
that
are
trying
to
go
and
and
seek
consensus
from
their
sig
on
whether
or
not
this
approach
is
reasonable
and
fits
the
requirements,
and
so
the
ask
that
that
that
I
have
is
to
if
you're
so
I've
a
prototype
pr
out
there.
C
That
proposes
a
you
know,
extending
the
api
with
supporting
multiple
callbacks
and
supporting
the
ability
to
remove.
So,
if
you're
on
the
instrumentation
side
of
this,
if
you
could
go
check
that
out
and
see
if
that
would
fit
your
needs,
if
there's
any
gaps
in
there
or
like
there's
any
blind
spots,
that
would
be
great
and
if
you're
interested
in
going
to
evaluate
it
at
the
spec
level.
I've
also
linked
the
spec
pr
there.
C
So
that,
actually,
you
know
is,
is
where
you
can
find
the
language
changes
that
I
try
to
embody
in
the
the
sdk.
Pr
that
I
proposed
so
yeah
what
I'm
trying
to
get
is
consensus
from
this
group
that
you
know
we
can
in
fact
embody
this
proposed
language
at
the
spec
level
and
and
basically
you
know
a
thumbs
up
from
us
and
then
I
can
take
that
to
the
spec
and
if,
if
other
sigs
also
give
the
thumbs
up,
this
will
happen
and
it
will
be
part
of
the
initial
sdk
stabilization.
A
Mate,
do
you
think
is,
can
we
evaluate
it
just
via
the
prototype
like
should
do?
Should
we
prototype
the
instrumentation
like
see
what,
if
the,
if
we
can
update
all
the
micrometer
stuff
like
I
was
just
thinking
like
if
we
could
build
it,
get
a
snapshot
and
try
to
redo
all
that
micrometer
stuff.
B
I
could
try
that,
but
I
don't
think
that
it's
that
necessary.
I
I
will
review
jax
pr
to
the
player
tomorrow
anyway,
but
I
mean
just
just
knowing
that
there's
a
remove
method
that
actually
or
closed
if
it's
not
a
close-up,
a
closed
method
that
actually
removes
the
callback
shouldn't
be
enough.
I
mean,
if
you
look
at
how
the
micrometer
bridge
is
constructed,
you
could
just
replace
my
own
hacky
async
something
handle
with
the
observable
something
something
that
comes
from
sdk
and
it
would
be
just
pretty
much
the
same.
B
A
B
A
B
B
A
I
had
one
question
jack:
what
was
the
data?
How
does
it
affect
the
data
model.
C
So
one
of
the
implications
of
having
being
able
to
call
or
ask
for
an
instrument
multiple
times
is
like
conflict
resolution.
So
if
I
ask
for
the
same
instrument
by
name
but
with
a
different
description
or
unit
or
instrument
type,
what
should
happen
and
the
change
to
the
data
model
is
that
the
the
sdk
is
going
to
be
accommodating
of
those
conflicts
to
this
to
as
much
extent
as
possible.
So
it's
going
to
accept
like
if
you
ask,
for
you,
know,
http
server,
duration
and
description
is
foo
the
first
time.
C
If
you
a
second
time
you
ask
for
http
server
duration
in
the
in
the
description
is
bar,
then
that
would
be
allowed.
So
we
won't
log
an
error
and
give
you
like
a
no
op
instrument
in
that
case,
we'd
give
you
a
valid
instrument
in
both
cases.
C
What
we
would
do
is
we
would,
if
we
detect
some
sort
of
conflict
in
instrument
registration,
we're
supposed
to
log
an
error
message
describing
how
you
can
use
the
view
api
to
resolve
that,
and
so,
if
you
don't
use
the
view
api
to
resolve
that
conflict,
then
we
propagate
that
conflict
to
export
and
so
on.
Export
you
would
have,
like
you
know,
instruments
with
the
same
name
but
different
in
like
descriptions
in
that
case,
and
so
that's
considered
an
error
state
for
consumers
of
the
of
this
exported
data,
and
it's
it's.
C
It's
unspecified
how
a
consumer
should
what
a
consumer
should
do
in
that
situation,
but
it's
acceptable
for
them
to
reject
the
data.
So
you
know
I,
the
basic
idea
is
like
okay,
you
can
get.
C
You
can
register
like
duplicate
instruments
that
are
in
conflict
with
each
other
and
we'll
just
propagate
the
data.
All
the
way
to
your
back
end
and
your
backend
is
free
to
reject
that
data,
but
the
sdk
is
going
to
give
you
hints
on
how
you
can
resolve
that
conflict.
That's
kind
of
the
the
big
picture
story.
A
A
F
I
had
a
small
you
know.
I
was
wondering
about
the
context
around
pr
by
materials
a
few
weeks
ago
for
the
http.route
tag
like
I
was
searching
how
to
correlate
metrics
and
traces
and
that's
kind
of
the
missing
key,
but
I
didn't
find
anything
about
that
tag
at
the
specification
level.
I
only
saw
it
on
the
java
instrumentation
side,
and
I
was
wondering
was
that
something
like
just
a
local
thing
that
you
guys
are
doing
or
will
it
kind
of
migrate
into
the
specification
like
or
you
know?
F
B
I
I
think
the
metrics
spec
mentions
hdb
the
target-
that's
a
good
name,
but
as
an
example
of
that
it
presents
a
route
right
so
with
like
template
parameters
like
id
here
for.
B
Parameter
which
is
kind
of
confusing,
because
if
you
take
like
the
literal
target
from
the
url,
it's
going
to
be
high
quality
most
likely.
If
you
use
path
params,
it's
definitely
going
to
be
a
technology,
so
I
think
we've
decided
to
use
http
roots
because
it
already
contains
or
is
supposed
to
contain
a
low
cardinality
root
pattern
in
spans,
and
we
just
use
that
as
a
design
matrix.
B
I'm
not
sure
about
this.
What
should
we
do
with
the
spec?
I
would
probably
personally
prefer
changing
it
so
that
it's
also
replaced
the
route
instead
of
target
but
yeah,
and
I
think,
there's
like
much
more
context
than
that.
F
Okay,
I'm
wondering
about
it
because
I'm
in
the
process
of
migrating
a
few
common
stuff
into
like
basically
to
follow
the
semantic
convention.
So
we
can
produce
the
exact
same
data
that
you
would
produce
if
it
was
made
with
the
open
telemetry
agent
and-
and
this
is
this-
is
a
key
like.
We
are
always
trying
to
figure
out
how
to
correlate
metrics
and
and
and
traces,
and
this
one
seems
to
be
the
key.
B
Yeah
but
spike
also
mentions
them
using
http
url
for
clients,
fans
which
it's
originally
requested,
url,
which
is
like
100
percent
sure
to
be
high
quality
url,
which
is
probably
not
a
good
idea
for
a
metric
attribute.
B
We've
recently
changed
that
in
our
instrumentation,
so
that
we
use
that
peer
name
and
that
peer
report,
instead
of
url,
because
a
user
actually
logged
an
issue
about
that,
but
it
creates
a
continuity
explosion
so
yeah.
Let's,
I
think
that
probably
we
should
rethink
what
attributes
should
be
added
to
client
and
server
networks
in
this
pack.
B
There
is
a
easy
replacement
for
hdp
targets.
The
root,
but
url
is
probably
a
bit
more
complicated,
since
the
client
usually
doesn't
have
the
access
to
like
root
patterns,
the
http
guys
you
have
just
the
raw
url
and
let's.
F
A
Yeah,
I
can
open
a
spec
issue
to
mention
what
we've,
what
we're
capturing,
where
kind
of
we've
landed
and
see
if
there's
get
feedback
on
that.
E
G
I
also
had
a
poc
for
spring
boot
configuration
it's
scheduled,
but
well.
I
still
have
to
find
the
bandwidth
to
implement
that.
E
A
All
right,
then,
well
wish
me
luck
with
our
our
horrible
release
track
record.
A
I
think
at
one
point
I
told
honorag
that
I
think
about
50
of
our
releases
failed
the
initial
time,
but
then
I
had
to
revise
that
after
the
fact
and
brought
it
down
to
about
10
after
I
reflected
more
realistically,
I'm
sure
this
one
will
fail
the
first
time
too,
because
we
continue
to
muck
around
in
the
release
scripts,
but
it's
all
good.