►
From YouTube: 2021-02-18 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
A
A
A
Surprisingly,
like
the
lte
is
pretty
amazing,
we're
able
to
work
on
it.
C
A
C
D
D
D
A
Yeah
I
want
to
check
with
honorable
when
we
talk
with
him
this
evening,
if
he
still
wants
to
try
to
get
the
the
java
agent
one
zero
right
out
like
right
after
that,
I
think,
last
week,
kid
or
the
week
before
he
was
hoping
to
get
the
java
agent
1-0
out
by
the
end
of
the
month
for
some
release
that
he
had.
A
So
that
would
be,
I
mean
a
tight
turn
around
compared
to
what
we
normally
do,
but
since
no
breaking
change,
if
no
breaking
changes
seems
doable.
If,
if
I
don't
have
any
objection,
if
that's,
if
he
really
wants
to
do
that.
D
A
Yeah,
so
speaking
of
our
like,
as
far
as
our
one
zero
tasks,
this
one,
I
think
I'm
gonna
mark
this.
One
done,
I
think,
with
the
the
auto
generation
of
the
licenses
now
in
in
the
jar
file,
as
they
probably
have
yeah,
so
we're
generating
them
into
the
license.
Folder
this
cradle
task
grabbing
all
the
licenses
via
maven
palm
files
from
the
dependencies
and
then
sticking
that
into
the
the
java
agent
jar.
Also,
I
think
that's
going
to
be,
then
we
can
close
this
out.
A
Yes,
this
one
john,
I
think
john,
did
you
just
do
this
in
the
hotel
java,
repo.
A
A
A
D
Something
else
I
put
in
a
pr
to
make
to
actually
implement
the
defaults
that
are
in
the
spec.
That's
maybe
what
you're
thinking
of
because
we
had
already
documented
what
the
defaults
were
and
what
the
possibilities
are.
I
think,
and
so
we
just
the
documentation,
didn't
match
the
implementation.
So
that
may
be
what
you're
thinking
of
okay.
D
A
B
D
E
I
still
think
that
this
documentation
is
quite
confusing.
It
mixes
trace
propagators
and
baggages
pro
pro
propagator
without
any
distinction.
E
E
E
E
D
Yeah,
the
auto
configuration
module
needs
a
ton
of
documentation
period
like
right.
Now,
it's
basically
not
documented
in
any
particular
good
way
at
all.
So
that's
definitely
neat.
If
someone
had
some
time,
it
would
be
really
great
to
write
some
documentation
for
that
module.
A
And
the
the
doc
that
is,
there
is
mostly
copy
paste
from.
D
A
You
think
we
should
have
that
copy,
I
mean
the
duplicate,
or
do
you
think
we
can
reference
like
point
people
over?
Will
that
be
too
many
layers
of
indirection.
B
A
Yeah,
I
think
it's
a
good
point
that,
with
given
the
stability,
it
shouldn't
be
a
maintenance.
A
E
E
B
A
Couple
like
debug
hotel
agent
enabled
yeah
like
that.
A
Now
the
the
instrumentation
specific
config
is,
I
mean
if
we're
declaring
one
zero,
the
java
agent
one
zero
stable.
Are
we
gonna
hide?
Those
is
idea
to
hide
those
config
options
or
to
not
or
to
explicitly
say
that
the
config
options
are
not
stable.
E
E
A
A
Yeah,
I
would
probably
be
good
I'll
try
to
put
together
a
list
of
what
we're
more
specifically
declaring
stability
around
and
not.
C
C
There's
an
issue
right:
2
302.,.
C
Which,
I
think
is
a
completely
reasonable
concern.
I
mean
I,
I
wanted
to
push
back
a
little
bit
on
the
a
la
carte,
picking
and
choosing
of
url
components,
and
in
order
to
do
that,
I
wanted
to
put
something
out
there
and
it
sounded
like
it
sounds
like
john
wants
to
take
it
and
just
make
it
completely
generic
like
let
people
build
and
plug
in
whatever
kind
of
filter
they
want
for
any
any
spam
attributes
or
whatever.
A
So
I
started
reading
of
this
pr
or
this
yeah.
This
discussion
here
was
sort
of
that.
The
the
open
telemetry
way
was
going
to
be.
Do
all
do
that
kind
of
data
scrubbing
in
the
collector
potentially
as
deployed
as
an
agent.
So
it's
still,
you
know
on
the
same
box,
so
it's
just
localhost,
so
the
the
sensitive
data
never
even
leaves
the
box,
but
it's
not
then
done
in
process,
and
then
each
language
doesn't
need
to
build
out
capabilities
to
scrub,
that
data
cool.
C
A
Yeah
I
mean
I
know
for
our
particular
implementation.
Our
particular
needs
in
azure
we're
not
using
the
collector,
sadly,
and
so
that's
not
an
option
for
us,
and
so
what
we've
done
for
that
is
sort
of
build
out
a
similar
to
the
collector's.
A
Telemetry
processor,
yaml-based,
telemetry
processors,
we
have
sort
of
a
json
based
basically
copy
of
that
config
and
apply
that
in
the
in
the
span
processor,
and
it's
certainly
something
that
I
mean
we'd
be
more
than
happy
to
contribute
upstream.
A
If
that's
something
that
I
just
gotten
pushed
back
in
the
past
sort
of
that.
Oh
this
is
the
open
telemetry
way.
We
don't
want
to
be
adding
the
that
kind
of
thing
to
every
language.
F
So
in
the
the
java
meeting
yesterday
there
was
an
interesting
discussion,
I
think,
about
annotation
processing
and
you
know
other
ways
of
applying
instrumentation
that
I
think
might
be
relevant
here
just
for
for
future
consideration.
D
Were
chatting
about
there,
it
was
kind
of
questions
asked
by
josh
surith
and
maybe
a
little
bit
of
by
ken
finnegan
from
red
hat
was
more
about
like
additional.
Well,
it's
two
things
one
metrics
like.
Could
we
have
annotation
based
timings?
D
So
you
know
it's
a
little
speculative
at
this
point,
but
this
seemed
like
a
really
interesting
idea
in
order
like
or
maybe
it's
an
option
on
with
span
or
something
like
that,
or
probably
an
additional
additional
annotation
for
timings.
D
But
then
the
other
question
was
from
josh.
Would
we
like?
Should
we
should?
Would
we
like
to
have?
Should
someone
try
to
build
a
build
time,
annotation
processor
for
withspan
and
other
any
other
annotations?
D
That
would
do
things
like
kind
of
the
similar
to
what
dagger
or
auto
value
or
any
of
the
other
kind
of
build
time.
Annotation
processors
do
to
create
to
use
those
annotations
to
build,
compile
time
or
build
artifacts,
or
you
know,
classes
that
would
provide
the
additional
implementation
without
having
to
have
the
by
code.
D
Manipulation.
Implementation
in
the
agent
there's
a
lot
of
words
there.
Hopefully
that
made
some
sort
of
sense,
but
the
idea
is
something:
that's
not
agent,
not
by
code
based
but
a
but
a
build
time.
Annotation
processor-
and
I
said
this
sounds
amazing
and
fantastic.
Please
build
this
for
me.
I
will
use
it
tomorrow.
D
F
In
general-
and
I
think
annotation
processing,
as
well
as
interesting
to
a
degree
because
there
is
there's-
certainly
a
cost
penalty
associated
with
the
annotation
based
instrumentation,
that
some
custom.
Some
people
are
just
not
interested
in
accepting,
because
you
know
you
you
can.
Potentially
you
can
even
do
something
like
annotation
inheritance
or
things
like
that
that
some
people
really
want
annotations
on
interfaces,
for
example,
that
maybe
you
could
also
do
on
at
compile
time.
That's
much
harder
to
do
at
runtime.
F
So
anyway,
I
just
thought
it
was
an
interesting
discussion
that
some
of
you
folks
might
also
have
thought
interesting.
A
Yeah,
I
totally
agree
with
leaning
into
annotations
john,
had
brought
that
up
before,
like
for
users
recommending
the
width
band
because,
like
it's,
it's
non-trivial
to
do
even
a
basic
thing
with
the
java
api,
you
have
to
do
the
try
with
resource.
You
have
to
start
the
span
and
the
span
set
up
the
scope
right
where
the
width
span,
there's
just
a
lot
less
that
you
can
mess
up,
get
wrong.
D
Yeah,
having
that
with
span
and
especially
then
being
able
to
call
span.current
and
just
add
stuff
to
it,
as
you
need
to
is
really
like
once
you
kind
of
that
my
eyes
open,
I'm
like
holy
moly.
This
is
so
easy
to
do
like.
Why
are
we
telling
people
to
do
this
complicated
thing
with
all
these?
You
know
very
specific
requirements
about
how
it
has
to
work.
Let's
make
it
easy.
D
D
Oh
yeah
yeah
true,
I
mean,
and
you
know
one
of
the
options
that
new
relic
had
on
their
span.
Annotation
was
like.
Should
I
start
a
new
thing
here?
It
was
actually
in
that
case
was
starting
to
trace,
but
we
could
imagine
having
an
annotation
like
an
annotation
option
on
with
span.
That
would
say,
don't
start
a
new
span
if
one's
already
in
progress
just
let,
but
if
there
isn't
one
then
create
one
that
would
be
a
pretty
easy
option
to
add
and
fairly
easy
to
implement
as
well.
C
So
I
think
I
think
we're
talking
about
annotations
originally
in
the
context
of
this
uri
component
redaction
thing
so
tyler,
I'm
curious
what
your
idea
was
that
like
to
that
end,
are
you
thinking
that
we
could
allow
people
to
either
slap
a
new
annotation
or
another
field
on
the
existing
annotations
to
then
apply
the
redacting
logic?
Is
that
the
idea
or
an
idea.
C
Sorry,
there's
a
there's,
an
issue
open
about
censoring
url
components
because
they
contain
sensitive
data
and
by
component
I
mean
like
the
path
portion
or
the
query
string,
primarily
and
that's
what
we
were
talking
about
when
the
annotation
thing
got
brought
up,
and
so
I
thought
you
had
an
idea
about
that.
F
Yeah,
that's
that's
also
kind
of
tricky.
I
mean
there's
also
the
the
whole
question
of
how
do
you,
if
you're,
just
looking
at
just
a
raw
url?
How
do
you
extract
out
the
high
cardinality
versus
the
low
card,
melee
parts
of
the
url.
F
F
I
I
didn't
bring
that
up
for
that:
okay,
yeah!
Okay,
sorry
I
I
I
maybe
I
just
bought
buttered
in
at
the
wrong
point.
In
the
conversation
I
apologize.
C
Won't
be
the
last
time
tyler
geez
yeah.
You
know
me.
Sorry,
it's
all
good,
I'm
just
I'm
still.
I
guess
I'm
curious
on
that
url
component,
one
where
we
left
that
off
do.
We
think
we're
probably
leaning
towards
something
a
little
more
general
purpose.
A
Then
it
would
probably
be
worth
replying
with
sort
of
the
current
options
today
that
they
could
use
either
hotel
collector,
with
attributed
processors
on
gamma
based
attribute
processors
in
their
code
they
could
override
the
http
url.
A
This
is
a
little
bit
harder
than
it
should
be
for
because
we
add
a
span
for
the
controller
call.
So
if
they
do
span
current
inside
their
controller,
they're
gonna
get
the
controller
span
when
really
they
want
the
server
span.
A
A
C
I
was,
I
was
approaching
it
with
my
user
hat
on.
I
think
there
was
a
user
that
showed
up.
That
was
like
hey,
my
secrets
are
being
leaked
and
I
mean
the
first
thing
is
well
don't
put
secrets
in
there,
but
if
you
are
and
that's
hard
to
change,
how
can
we
help
to
mitigate
that
because
they
won't
be
the
last
person?
That's
doing
that
probably
are.
Are
those
secrets.
C
Our
parameters.
F
Yeah,
so
at
datadog
we
we
don't
send
the
query
portion
at
all
like
we
just
don't
even
include
that
they
there
is
excuse
me.
F
We
do
have
an
option
that
allow
users
to
select
specific
query
parameters
to
include
as
tags.
So
that
would
probably
be
my
suggestion
of
like
having
the
query
portion
be
like
a
an
opt-in
rather
than
an
opt-out.
F
E
F
Please
I
was
saying
I
would
I
would
escalate
that
to
the
semantic
attributes
group
like
the
spec
should
really
reconsider
that
as
a
security
hole.
That's
well.
That's
this.
A
Topic
here
that
john
opened
and
that's
where
the
current
current,
as
of
may
5th
2020
discussion,
pointed
to
it
should
be
done
in
the
collector.
F
C
A
Yeah,
so
what
we
have
is
these:
we
basically
copied
the
hotel,
collector
yaml
based
processors,
and
so
you
can
in
the
hotel
collector.
Has
these
like
attribute
processor
match
these
fan
names.
Remove
this
attribute
key.
A
Yeah,
so
you
can
do
regex,
okay,
matching!
Oh
that'll,
get
you
there,
yep
yeah
regex
extraction.
It's
not
simple!
It
starts
to
be
it's
not
it's
not
what
I
would
call
a
really
lovely
user
experience.
C
F
The
other
thing
you
have
to
be
careful
with
is
high
volume,
red
jacks
and
high
volume.
Url
parsing
can
get
pretty
expensive.
A
Yep
another
reason
why
yeah
the
the
open,
the
open
telemetry
way
currently
is
saying:
well
that
should
be
done
in
the
agent
collector.
A
Yeah-
and
I
wonder
if
you
know
given
your
experience
also,
if
that
were
a
config
option,.
F
Because
it
I
mean
from
my
experience
and
I'm
sure
that
there
are
orgs
out
here
out
there
that
violate
this,
but
generally
speaking,
sensitive
data
should
not
be
in
the
path
portion
of
a
url.
It
should
not
be
in
the
url
period,
but
usually
it's
not
at
least
it's
not
in
the
path
yeah.
You
would
think
I.
A
I
I
I've
had
a
I've,
had
a
customer
not
so
recent
or
recently
that
it
was
gps
location
in
the
path,
and
that
was
not
great.
A
C
A
A
It
would
probably
be
worth
even
something
on
the
readme
as
a
how
somewhere
like
how
to
redact
sensitive
data,
even
just
generally
pointing
to
these
options.
D
Well,
there
are
users
asking
important
questions.
I
don't
want
to
abandon
them,
but
I
also
don't
know
how
to
get
them
to
actually
do
like
go
to
the
places
we
want
them
to
go
like
that
question
the
one
right
below
that
it's
like
people
are
gonna.
Ask
this
question.
I
mean
this.
Is
it's
a
weird
question?
Obviously
there's
tons
of
nuance
and
there's?
No.
I
don't
want
to
just
do
an
answer
here,
although
I
could
so
I'm
like.
A
F
Is
it
reference
still
on
any
of
the
other
open
telemetry
pages
that
I
don't
know?
I
know
it's
not
in.
D
So
anyway,
I
don't
know,
I
don't
have
an
answer
I'm
just
like.
If
anybody
knows
like,
if
it
were
slack,
you
could
put
a
message
in
the
like
a
description
in
the
channel
that
says
this
is
this
channel
is
not
used
anymore
or
we
could
archive
the
channel
and
when
people
saw
it
they
would
see
the
message
as
well,
but
I
don't
know
if
that's
possible
in
getter.
A
Yeah,
I
would,
I
would
be
fine
with
just
deleting
the
channels.
A
D
F
Hilarious
that
github
discussion
seems
to
basically
recreate
the
stack
overflow
experience.
F
C
D
I
think
the
other
thing
people
don't
understand
what
github
discussions
are
like
I've
repeatedly
said:
hey,
could
you
create
a
discussion
and
they
go
and
create
an
issue
which
is
okay?
I
wish
you.
I
wish
there
were
a
way
to
move
an
issue
into
a
discussion
rather
than
just
have
to
work
on
the
issue,
but
you
know
people,
don't
I
don't
think
people
know
what
github
discussions
are
it'll.
C
D
C
D
That's
certainly
one
way
to
do
it,
I'll
I'll,
communicate
with
the
maintainer
other
maintainers,
first,
just
to
make
sure.
D
A
C
Well,
I
want
to
make
sure
that
as
a
community
also
on
these
sig
meetings
were
nice
and
opening
and
say
hi
to
new
people.
So
julia
g
has
been
lurking
and
I
just
wanted
to
say:
hi
we're
nice
and
friendly.
Hopefully,.
G
A
G
G
G
A
Joining
thanks
for
jason
for
being
on
the
welcome
train.
C
A
D
I
had
just
a
general
question:
does
anyone
tried
using
the
hotel
java
agent
with
closure.
B
E
D
F
Though
I
think
we've
had
a
customer
in
the
past
used
closure
and
they
complained
that
there
was
a
pretty
high
overhead
specifically
due
to
everything,
enclosure
being
runnable.
And
so
the
runnable
instrumentation
was
very
burdensome.
F
And
I
think
that
that
was
one
of
the
reasons
that
richard
went
and
like
refactored
a
lot
of
that
instrumentation.
In
an
effort
to
try
to
reduce
our
dependency
on
runnable
instrumentation.
F
Yeah
I
mean
just
instrumenting
every
runnable
in
the
whole,
entire
application
has
its
own
overheads
either
way,
but
on
frameworks
like
closure,
I
believe
that
are
even
more
heavily
reliant
on
it.
It
just
becomes
kind
of
crazy.
D
F
I
mean
I,
I
would
suggest
that
if
you
want
to
take
the
time
like
put
a
smoke
test
into
the
repo
using
closure,
pick
whatever
is
the
most
common
like
closure
application
framework
and
put
something
in
there,
I
wonder:
can
closure
apps
be
built
with.
D
D
E
D
F
So
random
thought
just
came
to
my
mind,
while
we're
talking
about
like
weird
things
that
we
support.
I've
had
some
feedback
from
my
teammates
at
datadog
on
the
test
framework,
the
the
the
test
assertion
for
the
spans
being
kind
of
you
know
difficult
to
work
with
and
not
super
nice.
F
I
was
wondering
if
any,
oh,
they
also
don't
really
like
groovy.
D
Every
one
of
those
things
that
you
just
said
yeah,
and
especially
anyone
who
doesn't
like
groovy
they're,
my
best
friend
I'll,
buy
them
a
beer.
So
my
question.
F
Is
yeah?
What
would
a
better
test
assertion
kind
of
system
look
like
for
for
something
that
you
know
isn't
dependent
on
spock
or
groovy
or
whatever,
so
we
so
just
fyi?
I
don't.
D
F
D
D
F
Their
best,
I
I
do
agree
with
that-
I
think
that's
mainly
groovy
assertions
than
spock
yeah,
so.
E
F
The
other
thing
I
really
like
about
spock
is
the
data-driven
testing
part
of
it.
It's
so
much
nicer
than
anything
junit
has.
But
yes,
I
understand
that
that
is
the
the
general
feel
of
groovy
and
spock
is
difficult
for
people
to
accept.
C
Yeah
the
data
I
agree,
the
data-driven
stuff
is
pretty
nice,
but
I
think
for
anybody
coming
in
and
looking
at
the
tests,
it's
a
there's
a
huge
curve
to
like
learning
how
this
stuff
works
and
as
soon
as
you
encounter
your
first
test
failure,
you
have
to
jump
in
and
learn.
F
That's
the
question
I'm
trying
to
ask
is
like
what
would
a
better
java
based
span
assertion
framework.
Look
like.
E
D
Well,
with
java
15,
don't
we
have
the
expanded
text
blocks?
We
could
re-implement
the
the
database
stuff
using
expanded
text
box
on
java
15
text
blocks.
E
F
F
A
John,
do
you
have
a
link
to
some
the
java
sdk
examples
of
how
the
span
verification
there
or
a
class
I
could
follow.
D
D
F
I
do
think
that,
like
an
assertion
framework
would
make
sense
to
exist
in
the
like,
how
have
that
be
like
a
a
separate
publishable
artifact
from
the
the
the
java
repo
rather
than
the
instrumentation
repo.
If
we
could
say
hey,
you
know
some
assertion
framework
like
providing
us
tooling
or
simplification
for
that
in
that
repo,
it
does
seem.
A
Yeah
mateish
was
doing
some
work
recently
around
pulling
in
the
java
sdk's
assertions
into
the
library
tests
so
that
they're
usable
from
our
the
instrumentation
library
tests.
F
So
one
thing
I
thought
would
be
really
cool
is
be
able
to
like
have
more
like
a
higher
level
assertion.
So,
for
example,
say
I
have
say
I'm
writing
like
a
histrix
instrumentation
or
I'm
writing
http,
instrumentation
or
http
client,
for
example
like
I
could
define
generally
you
know
these
types
of
instrumentations
use.
It
should
look
like
this
and
then
be
able
to
like
assign
that
to
a
variable
and
then
override
it
as
necessary.
E
That
we,
that
we
more
or
less
have
with
those
server
spam
blah
blah
blah,
which
encapsulates
already
a
lot
of
those
conventions.
F
Right
so
so
we
have
that
we
create
those
helper
methods.
That
kind
of
do
that,
but
the
problem
with
those
helper
methods
is
any
variability
in
them
becomes
like
you
get
a
ton
of
method,
arguments
that
really
kind
of
becomes.
You
know
burdensome.
F
A
F
I
have
a
good
one:
yeah
is
anyone
working
on
the
or
did
you
already
do
the
ben
tray
migration
thing
yeah,
that's
already
done.