►
From YouTube: 2021-08-27 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
C
B
C
Yeah,
so
I
think
the
plan
that
we
came
up
with
this
morning
was
that
the
most
important
thing
right
now
is
to
make
sure,
because
the
sdk
solution
is
actually
quite
complex.
There
isn't
there
isn't
like
a
simple
fix.
The
sdk
in
this
case
to
address
the
instrumentation
cardinality
in
a
patch
release
and.
A
B
Like
I'm
thinking
of
removing
the
check
for
the
configures
that
that's
probably
a
better
one,
rather
than
checking
that
as
well,
I
think,
I
guess
frank
also
pointed
out.
It
sounds
like
you're
easy
to
configure
and
then
metrics
will
get
disabled.
So
it
sounds
like
that
was
too
overreaching,
so
I'll
just
get
rid
of
that.
I
think
because
someone
could
always
use
a
configurable
exporter
if
they
need
to
programmatically,
add
an
exporter.
They
shouldn't
need
to
use
the
configure.
B
C
Yeah,
so
the
so
the
you
know,
the
emergency
patch
is
just
to
get
the
instrumentation
to
have
a
more
limited
set
of
attributes
with
the
goal
eventually
to
undo
that
change.
When
the
sdk
has
when
there's
a
hint
api
where
the
instrumentation
can
say
these
are
the
ones
you
really
care
about,
or
these
are
the
ones
that
are
going
to
be
guaranteed
to
be
cardinality.
C
Yeah,
it's
totally
it's
because
of
the
cardinality
coming,
coupled
with
the
fact
that
nothing
is
collecting
the
data,
but
if
there
weren't
a
cardinality
issue,
it
wouldn't
be
a
problem
because
it
would
just
be
accumulate.
It
would
just
be
using
the
same
set
of
attributes
as
the
key
every
time
and
there
would
be
no.
There
would
be
no
problem,
it's
primarily
due
to
the
cardinality
explosion
that
makes
it
makes
that
map
grow
without
bounds,
because
the
key
to
that
map
is
essentially
the
cardinality.
Is
the
you
know
the
attributes?
C
Don't
we
aggregate
points
on
the
unquestion
when
we
aggregate
points
we
have
to,
we
have
to
keep
the
attributes
around,
for
which
the
measurement
was
made
right.
So
you
make
a
recording.
You
have
a
set
of
attributes,
that's
along
with
that
recording
we
have
to
keep
the
recording.
We
have
to
have
something.
That's
accumulating
that
data
yeah
along
with
those
attributes
and
the
attributes
are
the
key
to
the
map
that
map
then
isn't
it.
B
C
C
B
C
I
mean
you
can
fairly
quickly
see
the
code
yeah.
I
saw
the
the
story-
pixels,
okay
in
the
yeah
inside
the
now,
of
course,
now
I'm
getting
the
beach
ball
an
idea,
thanks
idea.
Where
was
this?
It's
like
the
synchronous,
metric
storage
class
has
the
map.
That
was
that's
basically
the
map
that
was
leaking
in
that
in
the
in
the
images
that
were
shown,
and
you
can
see
those
attributes
on
lines.
C
32
are
the
the
key
to
that
map,
and
then
the
aggregator
handle
is
the
value,
which
is
the
thing
that
is
aggregating.
The
data
I
mean
there
is
there
there
will
be
probably
a
future
aggregator
that
will
keep
all
the
points
until
things
are
collected,
but
that
would
be
a
rare
use
case
that
people
would
have
to
opt
into
because
it
will
have
we'll
have
a
guaranteed
memory
issue
that
had
that
we
won't
be
able
to
control
that.
C
But
my
I
mean
I
think
what
we
need
to
have
in
eventually,
which
is
the
you
know
I
put
in
a
spec
issue
today.
Is
we
just
need
to?
We
need
to
be
watching
the
size
of
that
map
and
have
some
sort
of
just
circuit
breaker
that
says.
Okay,
you've
got
you've,
got
too
many
keys
in
your
map.
We're
going
to
stop
collecting.
C
But
the
the
in
the
metric
sig
today
when
I
brought
it
up
the
general
opinion
was
that
we're
not
quite
ready
to
spec
that
yet
we
we
could
put
like,
I
think
it
sounded
like
um.net-
has
some
sort
of
packed
experimental
hack
that
they've
put
in
that's
not
even
quite
that
simple,
but
that
we
want
people
wanted
to
think
about
it
before
we
had
a
recommended
way
to
approach
it
because
you
might
want
to.
C
C
I
mean
there's
still
the
case
where,
if
you
have
some
client
like
an
http
client,
that's
making
completely
arbitrary
requests
out
to
the
internet.
With
you
know,
who
knows
what
hosts
we
could
still
end
up
with
the
same
issue,
but
that's
probably
going
to
be
a
much
rarer
case
than
arbitrary
urls
that
are
causing
it
at
the
moment.
C
C
C
B
B
What
was
in
my
head
was
leaked,
not
big
scopes,
okay,
yeah,
okay,
that
makes
sense.
I
don't
think
that's
good
scope.
Checker
I
mean
I
guess
they
can
warn
you
about
a
week
before
you
accidentally
share
data
or
something
that
might
be
one
small
advantage,
but
it
will
still
be
too
hard
to
keep
up
everything.
B
Well,
I
mean
we
could
have
sampling
and
then
in
production
you
could
set
the
sampling
rate
down
or
something
that's
true.
Yeah.
C
B
That
nettie
does
that
I
think
so
yeah
they
have
three
flags
like
the.
I
think
the
default
is
actually
enabled
with
sampling.
You
have
to
opt
in
to
disable
it
completely.
C
B
C
C
C
B
B
B
C
C
C
B
B
C
Yeah
we
just
set
up
this.
We
started
out
at
like
0.8
when
1.0
was
released
and
so
we've
we
and
then
we
didn't
1.0
until
we
we
considered
ourselves
stable
got
it.
So
we
probably,
but
it
probably
would
have
been
a
good
idea
at
that
point,
to
sync
up
with
the
open
telemetry
version
and
then
keep
it
in
sync.
But
we
wouldn't
be
able
to
necessarily
keep
it
in
sync,
because
if
we're
like,
when
we
do
profiling,
that'll
be
before
like
that'll,
be
won't
be
in
like
synchronized,
with
a
upstream
release.
C
We're
gonna
add
features
before
we
upstream
them
like,
for
example,
we
actually
have
micrometer
metrics
in
our
agent
right
now,
because
hotel
metrics
aren't
ready.
B
C
Would
be
awesome,
I
like
your.
I
like
the
way
you
think
yeah
it
was
debated
and
we
chose
one
thing.
It's
probably
definitely
at
this
point
more
confusing
than
if
we
had
just
kept
it
relatively
synced.
We
could
just
have
four
numbers
right.
We
could
have
a
fourth
number,
so
we
could
have
the
first
two
numbers
synced
with
open,
telemetry
and
then
the
third
number
be
our
minor
version
and
the
phone
number
could
be
our
patch
version.
C
B
C
B
B
A
A
Not
a
yeah,
I
don't
think
we
need
a
patch,
but
do
not
think
it's
still.
It
seemed
like
still
a
good
thing
like
I
was
thinking
of
doing
something
in
our
distro
for
that,
since
we're
not
using
metrics,
we
have
no
metrics
exporter
right
now,
so
I
was
thinking
I
might
just
register.
B
I
mean
I
didn't
want
to
propose
making
the
default
for
auto
configure
disabling
metrics
until
it's
more
stable,
but
that
depends
on
how
stable,
like
I
sort
of
have
this
perspective,
that
we
had
metrics,
maybe
version
four
alpha
or
something
like
a
few
iterations,
now
we're
sort
of
back
to
the
first
generation
after
redesigning
it.
So
maybe
it
needs
a
couple
more
iterations
before
it's
default
enabled
again.
B
C
B
B
A
So
if
it's
off
there
won't
be,
we
still
have
the
memory
I
mean
it
will.
B
C
C
B
B
C
B
C
B
C
B
C
C
B
C
B
C
C
A
All
right
problem
solved:
honor
I
did
the
okay,
so
the
have
you
had
a
chance
to
look
at
the
pr
for
the
metrics.
B
B
A
Yeah,
I
was
very,
I
totally
went
back
to
that
issue
and
I
I
know
there's
a
way
to
do
this
more
simply
than
having
to
do
a
switch
statement
of
every
single
type,
so
that.
B
B
B
B
B
A
B
A
We
it's
a
good
question.
B
A
B
B
C
A
Yeah,
the
ordering
is
a
little
tricky
because
we
do
register
the
bytecode
instrumenters
very
early
on
before
we
configure
the
sdk
yeah.
So
it's
probably.
B
B
C
A
Cool,
so
on
on
this
one,
the.
I
think
we
all
sort
of
agree
that
in
this
case
it's
a
batch
receive
and
a
batch
process.
So
and
there's
not
really
an
example
in
the
for
this
in
the
spec.
A
So
I
think
we're
going.
It
seems
to
make
more
sense
to
have
a
single
receive
for
the
batch,
with
the
links
to
the
parents
or
to
the
consumer
spent
the
to
the
producers
fans
and
then
a
single
consumer
span
parenting.
The
receive
span.
A
So
I
think
matthias
is
going
to
change
this
and
I'm
going
to
pass
the
example
along
to
the
the
new
messaging
semantic
convention
working
group
and
make
that
their
problem.
Yep.
A
Oh,
we
talked
about
the
strict
context
check
so
first
did:
does
it
make
sense
sort
of
where
why
we're
seeing
it
in
at
least
in,
like
the
async
servlet
case,.
B
A
A
Here's
the
async,
so
in
this
case
we
start
async,
we
get
back
the
async
context
and
we
pass
it
this
runnable
and
so
in
the
runnable.
We
send
we
print
the
response
and
then
we
call
context
complete-
and
this
tells
this
tells
the
servlet
that
we're
done
with
the
response.
A
So
the
response
is
flashed
and
we
do
end
the
server
span
here,
but
the
scope
we're
still.
B
A
And
I
don't
really
see
a
way
around
that,
because
we
that
we
want
we
want
whatever
we
pass,
the
runable
we
passed
to
start.
We
need
to
propagate
context
to
that
runnable.
B
Yeah
yeah
pretty
good.
B
A
And
then,
even
in
the
sink
case,
I
was
thinking
like
say,
take
a
filter
that,
like
the
the
that
you
again,
you
flush
the
response
back
to
the
client.
So
the
client
has
the
but
oftentimes
you
have
a
filter.
That's
doing
some
cleanup
work
at
the
end
after
the
well,
not
often,
but
you
used
to
when
hibernate
the
open
session
and
vue
thing
was
popular.
At
least
I
worked
on
one
app
that,
unfortunately
did
kind
of
a
lot
of
cleanup.
Sometimes
after
the
response
was
flashed,
yeah.
B
B
But
just
even
like
what,
if
someone
had
clean
up
after
the
conflicts
but
complete,
I
think
we
just
don't
track
it.
So
is
this
just
the
best
we
can
do
or
is
there
still
something
better?
We
can
do
say
what
again.
So,
if
we're
scanning
this
bandwidth
context.complete,
but
the
user
might
have
some
cleanup
logic
after
calling
this
contextual,
complete,
that'll
not
even
be
part
of
the
spin,
so
that
seems
wrong,
but
if
it's
the
best,
we
can
do
it's
the
best
we
can.
B
Yeah,
so
let's
not
even
talk
about
textures
to
context.
Let's
just
talk
about
collecting
the
time
spent
in
this
request,
yeah,
so
it
doesn't.
It
seems
like
it's
very
easy
to
have
a
lot
of
unattributed
time
if
someone
wants
to
do
cleanup
logic
after
they
call
context.complete,
which
seems
like
a
reasonable
use
case.
A
No,
no,
it's
totally
allowed
and
probably
we
could
do
better.
B
I
think
the
way
to
phrase
it
is
probably
usually
we
mount
the
scope
around
user
code
for
propagation
and
then
we
want
all
that
user
could
also
be
part
of
the
spam.
That's
why
I
still
have
this
image
where
it's
supposed
to
be
possible
to
always
have
the
scope
life
cycle
the
same
as
the
span
life
cycle,
because
otherwise.
B
A
Yeah-
and
I
forgot-
I
was
had
missed
the
piece
of
the
puzzle
that
I
was
thinking.
Client
span
can
finish
and
we
or
the
response
is
done.
So
we
proceed
on
to
verify
things,
but
at
that
point
we
do
we
wait
for
the
server
span,
so
we
could.
B
B
Yeah,
and
so
that's
so
yeah
there's
many
accesses
to
this
problem,
but
one
of
them
is
that
point
where,
like
there's
many
asm
servers
where
it
also
like
it
returns
a
response
as
the
first
thing
and
then
it
just
processing
right,
add
ping
or
whatever
right
like
you,
send
http
like
you,
send
your
ad
request
and
then
it
returns
to
the
client
immediately
and
then
does
its
processing,
and
so
if
our
instrumentation
is
ending
the
span
as
soon
as
it
sends
a
response,
such
the
use
case
is
just
not
covered.
A
So
yeah,
so
I
think
we
could
cover
the
simple
case
of
waiting.
You
know
we
could
track
the
runable
that
we
passed
to
start
and
we
could
probably
tell
if
complete
was
called
in
there.
Yeah.
B
Finish
at
the
end
of
that,
what
to
do
right,
yeah,
and
so
that's
that's.
The
crux
of
my
argument,
like
yeah
radar
context
thing,
is
fighting
their
problem
with
their
instrumentation.
B
A
Got
it
yeah
so
in
like
certain
from
a
used,
the
user
scenario
like
if
they
then
spun
up
another
thread
or
something
to
do
more
background
work?
We,
wouldn't
we
wouldn't
wait
for
that,
but
we
could
wait
to
the
end
of
at
least
this,
which
seems
very
reasonable,
yeah
cool.
I
will
try
that
out.
That
makes
sense
to
me.
B
A
Oh
yeah,
and
if
you
saw
in
I
think
in
slack,
laurie
posted
a
a
good
way
of
reproducing
them
by
putting
a
sleep
right
before
the
context
close,
which
sort
of
essentially.
B
B
A
A
B
B
B
A
Ron
asked
a
little
bit
about
that.
Hopefully
we'll
get
somebody
trained
still
trying
to
get
more
people
to
try
these
out.
I
I
will
actually
I
will
post
to
because
I
suggested
we
kind
of
talked
about
how
there's
some
that
are
really
quite
painful,
like
the
one
that
john
and
jason
happened
to
pick
up
as
their
first
attempt.
B
A
There's
some
that
are
quite
you
know
not
easy,
but
much
more
straightforward.
So
I
recommended
pinging
us
on
slack
for
suggestions,
but
I
think
I'll
make
a
broad
announcement
on
slack
of
kind
of
asking
for
help
on
these,
because
this
is
great
progress.
But
it's
still,
but
it's
been
like
two
two
months
of
or.
B
A
And
so
yeah,
and
then
yes,
this
was
oh
yeah.
You
saw
mateish
put
in
the
pr
now
to
enable
the
library
tests,
suppression
tests,
so
that's
awesome,
and
then
this
was
just.
A
I
found
incredible
because
I
have
had
this
problem
before
in
glow
root,
where,
like
some
especially
some
older
cdi
stuff,
that
does
reflection
on
your
thing
on
your
classes
it
like,
even
though
we
you
know
inject
fields
as
synthetic
and
transient,
they
still
like
some
of
the
older
ones,
especially
pick
those
up
and
fail
on
things.
So
this
is
like
you,
actually,
that's
actually
hooks
to
like
exclude
it
from
even
the
get
declared
fields.
A
B
I
was
like
oh,
this
is
a
nice
trick,
but,
like
what
came
to
mind
is
I
can't
believe
trust
hasn't
already
used.
This
trick,
we've
seen
right.
A
Yeah
so
yeah
it's
we're,
like
I
mean
it's,
it's
lucky
to
have
laurie
more.
A
A
A
He
said
he
had
gotten
ping
to,
but
as
if
he
would
join
the
the
messaging
semantic
convention
working
group.
So
that
would
be
good.
A
B
Another
one-
and
I
was
like
it's
just
some
cardinality
whatever
matrix-
is
unstable.
I
don't
care,
but
once
remember
really
for
people
that
have
it
right.
B
B
B
A
B
B
B
A
Oh
yeah,
so
since
we
already
have
the
one
five
x
branch
do
we
can
we
still
use
the
cherry
pick.
The
cherry
pick.
B
C
Hey,
will
you
all
sort
this
out,
I'm
gonna
take
off,
but
have
a
good
day
evening.
See
you
later.
A
A
A
A
Anyway,
in
the
pr
that
was
associated
with
this
branch,
I
made
a
yaml
error
in
this
file,
so
github
is
verifying
ammo
on
pr
builds.
Now.
B
A
B
A
B
A
A
W3C
so
microsoft
kind
of
adopted,
w3c
a
while
back
for
internal
stuff
for
hotel
with
yeah
some
I
mean
on
the
java
side.
I
know
on
the.net
side
yeah
the
the
that's
the
path
forward.
I
mean
most.
B
A
But
I
have
heard
from
a
couple
of
java
teams
that
are
want
to
do
that
with
otel.
We
just
need
to
still
build
out
sort
of
that.
B
Yeah,
I
know
what
you
need
to
do:
yeah
yeah,
that's
what
we
were
doing.
Yeah.
B
B
It
doesn't
matter
that
much
and
that's
why
there
was
actually
a
big
debate
because,
like
mesoderm's
extra
sdks,
we're
not
maintaining
that.
So
no,
we
may
as
well
not
do
that,
but
it
is
an
interesting
way
to
look
at
it.
I
could
put
back
into
the
extra
anyways.
Is
there
a
point
to
hotel
not
conceptually
just
technically
like
more
instrumentation,
more
reviewed
and
that
sort
of
stuff,
because
technical
benefits,
but
conceptually
you
don't
need
an
open
stomach
if
you're
only
gonna
use
one
backhand,
that's
sort
of
a
fun
discussion
to
have.
A
Yeah
yeah
I've
been
noticing
lately
the
or
I've
been
feeling
the
the
goodness
of
having
the
the
review
of
like
lots
of
experts.
Oh.
B
A
A
B
A
Okay
cool,
so
I
will
I
will.
I
will
wait
for
yeah
and
I
will
I'll
kick
off
patch.
Let
people
know
on
slack
and
yeah.