►
From YouTube: 2021-09-30 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
D
B
All
right
nikita.
A
A
There
are
several
methods
in
our
instrumentation
module
class,
which
are
currently
auto
generated
by
muzzle
code
generation
plugin
and
at
least
no
exactly
one
of
them
which
say
get
helper
classes
names.
A
If,
if
we
remove
the
possibility,
if
they,
if
they
remove
the
way
for
end
user
to
manually,
override
that
method
manually
provided,
then
instrumentation
will
not
work.
All
other
muscle
generated
methods
are
just
safety
net,
so
implementation
will
continue
to
work
without
them.
But
this
one
is
required.
D
If
I
may
just
correct
one
thing,
the
we
have
one
method
for
generating
the
context
or
virtual
field
mappings,
which
is
not
exactly
the
safety
net.
I
mean,
if
muscle,
doesn't
pick
up
those
classes,
we
don't
the
fields
won't
get
injected
to
those
okay.
A
B
And-
and
it
does
seem
like
will
be
the
interface
that
now
has
those
methods
that
gets
overlaid
during
muzzle
during
code
gen
is
that
public?
That's
essentially
part
of
our
public
stability
contract
right
for
backward
compatibility,
but
it's
not
we're
not
exposing
it
to
users.
B
B
B
Yeah,
the
gray
area,
we
have
to
treat
it
as
with
the
same
safety
and
carefulness
as
public
api
in
terms
of
breakages
anyways.
B
A
A
B
I
think
materials
didn't
you
have
a
thought
on
hiding
some
of
those
things.
D
D
A
But
if
you
still
want
to
have
that
backward
compatibility,
even
if
just
binary,
no
not
source
compatibility,
then
again,
what's
the
difference?
Are
they
part
of
the
extension
api
module
or
they
are
in
separate
module
which
still
we
have
to
maintain
if
the,
if
the
compatibility
requirements
are
exactly
the
same,
then
different
modules
will
not
give
us
anything
or.
B
A
Okay,
I
will
think
about
that,
but
one
more
note
you
see
that
even
if
we
remove
that
method
from
instrumentation
module,
then
actually
end
users
still
can
write
that
public
method
in
their
subclass
and
the
muscle
generator
will
still
back
off.
So
everything
will
continue
to
work.
It's
just
not.
It
just
will
be
like
tribal
knowledge,
not
publicly
supported.
D
Not
really,
I
think
in
in
some
of
the
latest.
Pr,
probably
you
have
changed
the
method
handle
invocation
to
a
casting
to
an
interface,
so
they
they
have
to
implement
the
interface,
the
muzzle
something
something
something
muzzle
interface
and
then
implement
method
methods
from
that
interface
and
then
that
interface
is
kind
of
private.
D
A
D
A
Yeah
right,
okay,
then
I
will,
I
will
think
about
that
separate
module.
If
I
see
any
any
benefits
in
that
or
if,
if,
if
there
is
none,
then
we'll
just
move
everything
back
because
well,
what's
the
point
that
okay.
A
A
Then
my
second
question
is
again:
I
try
to
take
a
look
at
those
three
api
modules
that
we
want
to
declare
stable
and
okay
extension.
Api
model
is
quite
small,
and
I
know
it
by
heart.
I
can
say
yes,
I'm
I'm
now
comfortable,
it
can't
be
declared
stable,
but,
for
example,
if
I,
if
we
look
at
the
instrument,
instrumentation
api,
that's
huge
model,
it
contains
a
lot
of
classes,
a
lot
of
methods.
How
do
we
decide?
Yes
now
it
can
be
stable.
A
A
A
B
So
my
my
read
my
thought
on
why
I
wrote
that
was
say
the
the
change
like
which
attributes
that
we
should
be
capturing
so,
for
example,
that
the
discussion
we've
had
around
the
http,
I
think
am
I
linked.
B
No,
I
didn't
so
the
whole
thing
about
their
certain
required
like
say
for
http
server.
We
capture
scheme
host
and
target
what,
if
the
semantic
conventions
before
they
go
stable,
decide
that
we
should
capture
a
scheme
host
path,
query
string
instead,.
A
B
A
A
D
A
B
So
we
had
this
discussion
before
about
what
is
the
value?
Do
we
is
there
a
big
benefit
for
us
to
stabilize
extension
api
before
instrumentation
api?
Since
I
mean
extensions
depend
on
all
three
of
these,
so
it's
not
like.
We
can
say,
extensions
are
stable
until
all
three
are.
A
B
I
think
just
all
of
you
know
vote
all
of
us
say:
yes,
I'm
comfortable,
no,
more
changes.
B
Two
checkboxes
and
what's
the
advantage
like
like
to
me
like
what?
What
are
we
gaining
by
declaring
this
stable
by
itself?
It
seems
to
me
like
it's
either
all
three
of
these
all
three.
We
need
all
three
of
them
to
have
true
stability
from
a
user
perspective.
A
Probably
I
am
just
trying
to
like
to
chip
off
like
divide
and
conquer,
or
currently
we
have
this
big
big
single
ball
of
some
some
substance
and
we.
D
Oh,
like
I
think
we
have
an
issue
about
the
instrumentation
version
that
it
should
be
read
from
some
properties
file
or
something
something
and
right
now,
it's
just
hard
coded
with
the
jar
implementation
version
manifest
attribute,
which
is
not
exactly
correct,
probably.
D
D
A
B
B
C
B
Forth
so
maybe
yeah,
it
totally
will,
but
maybe
like
phase
one
pass
and
then
we
still
need
a
final
review
and
then
a
final
final
review.
A
A
A
Least,
I
know
some
requirements,
so
that's
that's
already
good.
So
when
they
are
checked,
I
will
start
pushing
directly.
B
Sir,
if
you
all
are
on
slack,
you
saw
that
had
a
little
snafu
with
the
161
release,
and
so
I
just
I
trying
to
document
and
see
what
we,
how
to
make
things
more
smooth
in
the
future
and
part
of
the
problem,
but
part
of
the
problem.
Well,
part
of
the
problem
was
me,
but
the
other
part
of
the
problem
was
that
our
tags
don't
build
successfully
after
they've
been
made
oftentimes
because
of
dependencies
on
latest
collector,
some
dependencies
on
snapshot,
gradle
plugins
and
some
other
reasons.
B
What's
great,
is
that
we've?
Actually?
These
have
been
resolved
just
in
the
last
couple
weeks.
So
and
those
were
our
main
two
things
that
were
causing
back
ports
in
the
last
two
releases,
patch
releases.
B
And
I'm
not
sure
this
is
a
this
one
is
a
big
deal
since
it's
pretty
easy
to
mitigate
and
doesn't
require
necessarily
back
porting
if
it
causes
problems,
but
just
wanted
to
be
sort
of
transparent
about
that,
and
if
anybody
has
ideas,
thoughts,
please
post.
B
So
we
did
get
out
162
and
I
think
that's.
B
Good
any
other
topics:
anybody
wants
to
chat
about.
C
I'm
just
working
on
getting
the
the
jfr
agent
data
into
new
relic-
it's
not
quite
there
yet,
but
we're
making
progress,
and
I'm
I'm
chatting
to
jack
about
that.
F
What's
the
I
think
he's
just
prototyping,
you
know
he
just
wants
to
land
it
somewhere
to
visualize.
It.
C
B
F
Yeah
yeah,
it's
so
there's
there's
some
caveats.
So
cumulative
metrics
aren't
supported
yet
we're
trying
to
work
on
that
and
right
now.
It's
only
grpc
there's
no
http
protobuf
for
http
json
support
but
yeah.
So
there's
a
free
tier
for
new
relic.
So
you
can
you
can
send
your
data
in
and
visualize
it
and
start
to
get
a
feel
for
it.
C
B
F
Anybody
else
so
one
one
minor
thing:
I
noticed:
there's
a
grpc
version,
difference
between
the
open,
telemetry
java
project
and
the
instrumentation
project,
and
I
I
found
I
found
where
in
the
code
it
it
it's
coming
from
and
and
how
and
and
like
I'm
gonna,
I'm
gonna
open
a
pr
to
fix
it.
But
I
guess,
is
there
any
sort
of
process
for
ensuring
that
shared
dependencies
are
synced
for
versions
or
is
it
just
kind
of
ad
hoc.
F
Yeah
it's
so
it's
not
in
the
place
that
you
would
expect
it's
not
in
the
dependency
management
section.
It's
in
the
the
java
agent
exporters,
the
build.gradle
for
that.
B
F
I'm
not
exactly
sure
it
is
causing
a
problem.
One
thing
I
noticed
was
that
I
was
when
I
was
using
1.5,
1.5.3
or
two
of
the
agent,
and
I
was
sending
data
to
to
to
the
new
relic
backend.
Actually
I
was
getting
these
weird
errors
and
I
was
trying
to
track
that
down
and
I
came
across
this.
This
dependency
difference
and
and
I've
I've
known
I've.
I've
noticed
that
in
in
certain
grpc
versions,
there's
there's
like
methods
added
or
removed.
F
You
know
different
transitive
dependencies
on
guava
sometimes,
and
so
I
think,
to
the
extent
that
it's
it's
possible,
we
should
keep
those
in
sync
and-
and
this
is
just
like
a
minor
thing,
but
I
was
just
curious
if
you,
if
you
all
tried
to
do
that
in
any
way
to
sync
shared
transitive
dependencies,
so
for
them.
B
F
B
F
The
instrumentation,
so
the
instrumentation
has
a
dependency
on
it,
because
when
you
package
up
the
agent,
you
need
to
have
some
sort
of
default
implementation
so
that,
when
you
use
the
auto
configure
module
and
set
your
environment
variables
to
use
grpc
that
there's
something
available
on
the
class
path
like
some
grpc
implementation
on
the
class
path.
So
it
has
to
choose
some
reasonable
default.
B
Got
it
expressly
because
it's
not
included
in
the
exporter
right,
okay,
yeah,
so
I
feel
like
that
is
I
mean
it's
sort
of
intentional
that
the
sdk
says
hey.
We
support
any
grpc
version,
so
I'm
not
sure
it's
a
version,
so
I
don't
see
it
as
a
virgin
conflict
based
on
how
honorable
has
explained
that
to
me
previously
and
that
that
choice
of
making
it
a
compile-only
dependency
but.
B
F
That
assumes
that
the
grpc
apis
are
stable
and
that
the
implementations
don't
like
call
methods
that
are
changed
and,
and
that
has
happened
so
you
know
method
and-
and
I
I'd
have
to
dig
up
some
specific
examples,
but
I
I've
noticed
you
know
runtime
errors
when
my
api
version
of
grpc
is
one
dot
x
and
my
in
my
implementation
version
is
different.
So
so
right
so.
B
I
would
raise
that
as
an
issue
in
the
sdk
repo
that
it
needs
to
be
documented.
What
version
of
grpc
is
supported?
I
think
okay
right,
like
yeah,
I
mean.
B
B
Yeah
and
if
you
do
get,
if
you,
if
you
get
an
actual
error,
that
then
definitely
open
that
in
the
instrumentation
repo,
that
would
be
help
really
helpful.
F
Yeah,
I
I
have
gotten
real
errors,
but
I'm
trying
to
track
down
exactly
what
the
cause
is,
whether
it's
a
behavioral
issue
with
the
combination
of
the
grpc
implementation
and
the
api,
like
some
compatibility
issue
with
different
versions
there
or
whether
it's
on
our
new
relic
side.
So
I
don't
want
to
speak
too
soon
on
that
still
doing
digging
into
that
cool.
A
We
have
several
classes
like,
for
example,
bootstrap
package,
prefixes
holder,
which
is
used
by
our
tool,
link
specifically
by
agent
installer
and
used
by
our
internal
instrumentations,
like
class
law
order.
Instrumentation,
and
I
think
that's
only
usage.
There
should
be
it's.
It
shouldn't
be
actually
part
of
the
public
api,
but
it's,
but
it
is
used
by
some
of
our
instrumentations
and
tulip.
A
F
B
Only
thing
only
only
problem
I
can
think
of
is
like
writing
tests
or
something
that
oh
yeah,
but
tests
should
be
extension.
I
mean
like
yeah,
that's
kind
of
weird.
I
don't
know.
A
E
You
don't
want
to
have
a
compiled
and
dependency.
You
could
do
some
tricks
with
like
have
some
sort
of
interface,
that's
part
of
like
the
public
api
and
have
the
implementation
of
that
interface
in
some
secret
part
and
just
class
4
name.
It.
E
Like
coming
back
to
your
previous
goal
of
declaring
the
thing
stable,
basically,
if
you
manage
to
remove
almost
everything
from
the
public
api,
then
it's
much
easier
to
declare
it
stable.
A
A
D
B
Okay,
yeah
I've
gotten
pretty
comfortable
with
the
internal
package
concept,
just
because
it's
used
so
much
in
the
sdk
repo.
Now
so
I
think
that's
a
I
don't
have
any
issue
with
having
that
carrying
that
over
and
not
you
know,
preferring
I
think
the
stance
in
the
sdk
repo
has
been
to
prefer
using
the
internal
package
versus
trying
to
do
something
via
reflection.
A
C
B
B
All
right,
just
briefly
the
la
in
the
last
week
we
talked
about
transforming
lambda
classes
that
went
in
the
might
laura.
You
might
have
been
on
to
something
about
the
concern
about
native
images.
It
did
run
into
a
problem,
but
then,
but
then
also
by
adding
more
including
more
classes
into
the
pre-compilation
step.
I
think
got
around
that.
So
I
will
keep
you
posted.
B
B
To
capture
one
of
these
one
of
these
four
sets,
and
so
we've
sort
of
decided
or
we're
trying
to
consolidate
and
simplify
the
instrumenter
apis,
and
what
we've
seen
is
that
all
of
our
client
libraries
instrumentations
all
captured
url
already
so
we're
just
going
with
url
and
not
capturing
these
others
for
clients
and
on
the
servers
we're
going
with
this.
B
The
only
exception
that
we've
that
is
netty
today
is
giving
us
url,
so
we'll
we'll
have
to
revisit
that
still.
But
I
think
that's
a
good
and
I
think
that's
some
of
the
spec
discussions.
I've
seen
around
the
stabilizing
the
http
semantic
conventions
have
also
been
kind
of
discussing
this
idea
of
there's
so
many
different
options
that
makes
it
harder
for
back
ends.
It
makes
instrument,
it
makes
telemetry
less
consistent,
so
there
may
be.
We
may
be
able
to
influence
that
a
little
bit.
B
B
Well,
it
makes
our
instrumenter
apis
clearer,
like
I
think
part
of
the
goal
of
is
to
provide
a
little
bit
more
prescriptive
advice
in
the
instrumenters
like
just
seeing.
All
of
these
different
options
can
be
could
be
more
overwhelming
for
users
versus
like
two
that
are
clearly
named
like
server
or
client
yeah.
So,
like.
B
If
server
do
url,
if
client
do
the
three
yeah
and
even
better,
we
have
the
hp
client
attributes
extractor,
we
have
a
http
client
attributes,
extractor
that
you
use
for
ac3d.
E
E
B
And-
and
I
do
think
it
would
make
so-
the
discussion
in
the
spec
is
around
potentially
reducing
this
matrix
for
the
benefit
of
back
ends.
B
But
we'll
we'll
see,
that's,
I
think,
there's
a
otep
where
there's
some
discussion
going
on
right
now:
cool.
B
Nikita's
been
doing
a
lot
of
work
around
stabilizing
the
apis,
reducing
the
public
api
service
surf
surface
and
then
some
more
good
progress
on
the
instrument
or
api
conversion
two
merged
and
for
pending.
So
yay.
B
And
that's
it
any
any
last
topics,
but.
C
Yeah
so
I
spoke
to
the
the
folks
at
red
hat
and
the
legal
folks,
and
they
they
were
happy
for
it
to
go
to
contra.
So
I've
got
a
fork
of
contrib
with
with
another
sub
project
called
jfr
streaming.
It's
super
alpha,
but
that's
that's
where
I'm
working.
If
anyone
wants
to
come
and
splash
around
in
my
code,
feel
free.