►
From YouTube: 2020-10-08 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).
D
E
E
E
E
Yeah
you've
come
to
the
the
the
your
friday
morning
meetings
a
couple
times.
B
E
And
so
g1
issue
is
real
simple,
who
are
not
making
a
whole
lot
of
progress,
one
one
new
one
closed
still
ten.
We
we
have
been
keeping.
I
added
this
as
a
weekly
reminder
here
to
the
template.
I
copy
paste
to
make
sure
that
we're
not
falling
off
the
jfrog
snapshots
and
honorable's
been
keeping
us
up
to
date.
Lately
I
saw
there
was
just
one
to
update
us
to
zero
nine
one
release,
which
is
great,
because
we
will
target
zero
nine
one.
D
A
Is
fine,
yeah
yeah?
Let
it
be
zero
regarding
p1
issues
track,
you
can
approve
material
fix
for
config
and
then
it
will
be
two
down.
E
E
This
is
the
one
right
and
I
was
just
asking
about
yeah.
Okay,
yes,.
E
E
All
right
before
we
get
to
things
that
I
had
put
on
the
agenda
anything,
oh,
do
we.
A
E
A
pavel,
no
pablo,
okay,
a
couple
of
these
were
to
chat
with
pavel,
so
they
he
had
asked
about.
Well,
we
can
talk
about
them
anyway.
If
we
have
time
anything
that
people
want
to
chat
about.
E
So
I
had
asked
I
I
brought
this
up
the
background,
so
so
say
spring
scheduler
spring
scheduling
spans
should
those
spans
for
some
reason
I
had
initially
made
them
server
spans
and
the
reason
I
have
made
them
server
spans
may
be
more
related
to
my
backend
issues,
but
I'm
curious
if
that's
generally
so
like
on
the
back
end.
E
I
want
that
spring
scheduler
span
to
be
sort
of
this
top
level
concept
that
gets
tracked
as
a
sort
of
an
operation
as
opposed
to
a
parent
parentless
internal
span
is
the
other
option,
but
in
general,
when
I
see
a
parentless
internal
span,
I
just
assume
like
there's
a
lot
of
like
say,
live
jdbc
queries
during
app
server,
initialization
that
don't
fall
under
any
parent
service
band,
but
are
just
kind
of
these
miscellaneous
standalone
internal
spans
that
we
capture
so
by
calling
them
server
versus
internal.
E
That
allows
me
to
know
that
this
is
a
more.
This
is
a
important
top-level
concept
that
we
want
to
expose
to
the
user,
but
anurag
made
the
you
know
good
point,
also
that
arguing
for
internal,
that
you
know,
there's
no
client
side
of
this.
It's
not
like
client
server.
A
Specification
you
explicitly
says
server
span
indicates
that
the
span
cover
server,
sound
helmet
of
a
synchronous,
rpc
or
other
remote
request.
D
A
D
This
is
kind
of
a,
I
don't
know
it
feels
like.
There's
another
span
type.
That's
mankind
that's
needed
here,
but
it's
not
expect,
but
that's
I've
kind
of
felt
that
for
a
while,
I
haven't
yeah
like
a
background
job
or
exactly
something
along
those
lines
or
maybe
scheduled
or
scheduled
the
hours
yeah
anyway
yeah.
I
think
that
I
think
the
spec
is
has
a
gap
here.
D
A
A
D
I
mean
right
now
you
can
know
it's
a
local
route,
because
it's
internal
with
no
parent,
so
you
can
derive
that
you
can
derive
that
information,
which
is
probably
why
it
isn't
in
the
spec.
But
it
does
feel
like
there's
some
man
there's
some
semantic
in
my
head.
There's
some
semantic
gain
by
explicitly
saying
hey
that
we're.
This
is
a
thing.
That's
kicking
off
like
a
scheduled
task
or
some
sort
of
background
job.
E
And
to
me
there
there
is,
I
mean
I,
there
is
a
significant
difference
to
me
at
least
of
an
intentional
local
root
span
and
something
that
just
is
an
internal
span
that
we
capture
and
maybe
we
shouldn't
capture
those
is
an
option,
but
I
think,
but
I
do
think
like
say
a
jdbc
query
on
tomcat
startup,
it's
still
useful
to
capture
those
as
internal
spans.
E
Oh
you're
right,
those
would
be
client,
so
say
hibernate
or
something
else
that
so
yeah.
So
maybe
internal
is
not
that
useful
outside
of
a
parent.
A
E
E
Go
back
to
this
question:
how
how
do
we
differentiate?
How
how
can
I
I
mean?
Maybe
this
is
just
a
problem
from
I
mean
well
how
how
do
we
differentiate
between
an
intentional
local
internal
internal
local
route
span?
E
A
E
Yeah,
so
do
you
think
that
hibernate
I
mean
that
that
because
we
could
also
make
the
decision
that
I
mean
well,
I
guess
that
would
be
a
good
spec
question.
Also
if
internal
should
only
be
captured
like
in
does
internal,
I
mean
internal
kind.
A
A
A
A
E
Okay,
I
nikita
took
the
last
couple
of
spec
clarification
issues.
A
E
That
that
was
the
parent.
E
E
Spec
on
should
these.
A
F
My
opinion
is
that
they
should
be
client
calls.
A
E
I
agree
tyler,
and
this
was
my.
This
was
my
understanding
of
what
the
how
to
model
it,
but
as
nikita
nikita
convinced
me
on
tuesday
that
that's
not
how
the
spec
currently
reads.
A
F
The
something
to
clarify
on
the
spec
is
how
should,
in
that
case,
when
there
is
a
message
that
you
pull
off
like
that?
What
should
the
what
should
be
done
with
any
like
propagation
with
that
message,
and
what
should
the
resulting
trace?
Look
like
yeah,
the
linkage.
E
Yeah,
so
the
way
that
I
had
initially
implemented
this
in
for,
like
jms
kafka,
rabbit
mq,
was
parent
to
set
to
the
current
context
and
added
a
link
to
the
producer
message.
If
any
message
did
come
down
was
received.
F
And
that
makes
sense
to
me
I'm
just
saying
that
that
should,
if
it's
not
I'm,
not
familiar
with
what
the
spec
says,
but
if
that's
not
mentioned
in
the
spec,
then
it
should
probably
should
be.
A
E
Yeah
one
thing
that
I
was
thinking
about
is
there's
also
potentially
a
little
bit
of
difference
here
in
this
case
between
manual
and
auto
instrumentation,
because
in
manual
instrumentation
you
can
take
that
you
receive
call,
and
you
can
then
make
that
parent,
whatever
you're
doing
after
that,
to
process
that
message,
you
could
make
that
nice
link
there
and
then
I
would
support
making
that
receive
span
process
fun.
Well,
at
that
point
I
mean
yeah
your
manual
instrumentation,
I
don't
know
because
then
you
still
lose
con
parent
context.
E
E
A
F
E
F
If
it
would
be
beneficial
to
have
a
notion
of
a
soft
or
a
weak
referenced
scope,
what
does
that
mean
such
that?
So,
for
example,
in
the
case
of
that
receive
you
could
say,
hey
this.
If
something
comes
along
and
creates
a
new
span
following
this,
then
it
could
be
the
parent,
but
I
don't
want
to
hold
on
to
that
span.
If
it
gets
garbage
collected.
E
Where
do
you
store
that,
oh
you
store
it
in
context
as
sort
of
like
an
available
span
that
somebody
could
pull
from.
F
F
E
E
Yes,
that
would
have
been
from
1am
to
3am
your
time.
Tyler.
E
It,
let's
see,
oh
I
did.
I
made
a
proposal
nikita
on
naming.
I
know
we
were
just
so
that
we
can
hopefully
merge
this
prometheus
and
get
prometheus
pr.
We
were
stuck
a
little
bit
on
the
naming
of
this
thing.
That's
that
represents
pull-based
metric
exporters.
E
E
E
D
E
D
E
Think,
okay,
so
do
you
think
it's
still
worth
us
separating
the
concept
of
so
one
of
the
reasons
we?
So
this
was
sort
of
say
one
of
one
proposal
for
us
for
this,
for
people
who
are
implementing
a
pull-based
exporter,
for
example,
prometheus
in
this
pr
that
they
would
implement
this
versus
implementing
metric
exporter
factory,
because
this
doesn't
return
a
metric,
there's
no
metric
exporter
for
pull-based
metrics
or
at
least
the
metric
exporter.
E
The
sdk
metric
exporter
is
just
for
push-based,
so
we
just
call
like
start
on
it,
give
it
the
metric
producer
and
it
does
whatever
it
needs
another
option
here,
sort
of
going
all
in
on
the
the
or
the
use
case
that
we've
considered
the
only
use
case
we
have
really
so
far,
which
is
that
these
metric,
these
pull-based
metrics
essentially
create
a
metric
server
that
then
people
can
pull
from.
So
you
would
implement
this
implement
the
start
and
part
of
the
the
point
of
having
different
interface.
E
For
these
two
well
they're
slightly
different
because
of
the
I
mean.
Obviously,
the
metric
exporter
factory
returns
the
metric
exporter,
but
also
in
for
us
to
know
that
we
can
support
multiple
of
these,
but
only
one
of
these
and
they
they,
we
can't
hook
them
both
up.
At
the
same
time,
I
like
this,
you
like
metric
server.
A
D
A
D
What
about
I'm
trying
to
think
like
if
you
try
to
hook
jfr
into
the
metrics
like
what
you
how
you
would
implement
that
anyway,
it
wouldn't
really
be
a
server
in
that
case,
I'm
also
not
sure
it
would
be
pull-based.
E
And
almost
more
like,
oh,
I
see
like
I
was
gonna
say
bridge
like
micrometer,
but
no
probably
it
would
be
producing
aggregated
metrics
like
an
exporter.
D
E
All
right:
well,
if
I'm
I'll,
let
I
I
would
vote
just
metric
server
and
merge,
because
it
will
be
nice
to
have
prometheus
support
and
we
can
try
that
out.
E
John
honorag
was
mentioning
that
for
prometheus.
When
he's
used
it
before
that,
that
end
point
doesn't
do
diffs
it.
It's
like
it's
incremental,
but
our
end
point
I
assume.
Unless
internally
the
prometheus
is
well,
I
assume
it's
just
exposing
diffs
I
haven't
tried
that,
and
maybe
maybe
prometheus
has
both
options.
D
So
I
think
it's
complicated
and
it
depends
I
think,
on
the
type
of
metric
because
prometheus
and
I
think
actually,
we
have
a
bug
right
now,
also
in
the
way
we're
exporting.
No,
maybe
that's
otlp.
It's
I
think
it's
complicated
is
the
answer.
I
think
some
metric
types
prometheus
always
needs
a
needs.
Continually
increasing,
like
counters
always
should
never
be
differed.
Counters
are
always
monotonic.
I
think
I'm
not
a
prometheus
expert.
Just
you
know
yeah,
and
this
is
only
kind
of
what
I
remember
from
overhearing
conversations.
D
I
think
counters
are
always
monotonically
increasing
and
not
dips,
because
they
actually
use
the
reset
as
a
way
to
know
that
it's
the
counter
has
been
reset
like
it
going
dipping
negative,
I
think,
but
for
gauges.
I
think
the
gauges
are
just
you
know,
whatever
the
last
recording
was,
and
so
that's
kind
of
by
its
nature,
a
diff-
and
I
don't
know
about
other
things
like
I
think
if
I
recall
histograms
are
reported
as
a
set
of
gauges,
but
there's
so
many
metric
exporters
in
my
head.
Now,
I
I
honestly
don't
even
remember
so.
D
I
have
a
very
old
pr
now
that
would
allow
sdk
users
to
configure
it,
but
it's
kind
of
blocked
on
actually
having
a
metric
specification
for
the
sdk,
and
it's
because
this
is
kind
of
like
a
little
bit
of
a
views
like
this
is
the
this
is
what
views
are
supposed
to
provide.
It's
the
exporter,
like
the
previous
prometheus
exporter,
should
be
able
to
configure
views
and
say
I
need
these
things
to
be
diffs.
D
E
Okay,
cool
so
lots
more
metric
fun
to
come,
but
this
will
be
nice
to
I
kind
of
like
this
prometheus
exporter
as
a
local
testing.
A
way
to
locally
test
seems
like
a
cool
useful
for
us.
E
This
was
primarily,
I
wanted
to
check
with
pavel
if
I
wasn't
quite
sure
what
he
meant
how
to
solve.
I
suspect
so
one
problem
is
like
when
we
have
those
helper
class
names
all
in
the
in
like
an
abstract
base.
Let
me
share
my
whole
screen.
E
E
E
Just
by
having
grpc
context
available
and
then
it
tries
to
import
all
these
helper
classes
into
the
class
loader,
which
then
causes
problems
or
at
least
errors,
because
some
of
these
things
depend
on
open,
telemetry,
api
classes,
which
may
not
be
present,
and
so
that's
what
he
was
getting
like
here.
Class
not
found
attribute
consumer,
so
I
guess
sort
of
the
like
it
would
be
really
nice.
E
If
we
could
sort
of
say
all
of
the
instrumentation
should
share
a
single
muzzle
config,
where
they
either
all
get
applied
to
the
class
loader
or
none.
Do
I
don't
know?
If
that's
what
we
want
across
all
instrumentation,
there
may
be
some
like
servlet
instrumentation,
where
we
want.
You
know,
because
of
different
versions.
We
want
some
instrumentation
to
get
applied
and
some
not
to
get
applied
in
certain
cases.
B
E
You
would
not
get
this
error
right
correctly.
I
worry
like
I
worry
a
little
bit
about,
sometimes
our
instrumentations
sort
of
we
expect.
E
I
think
that
that
would
feel
like
the
safest
decision
since
a
lot
of
times
the
different
instrumentations
work
together,
I
don't
know
tyler
you
still.
You
have
thoughts
about
this.
E
No
problem
so
muzzle
so,
for
example,
we
have
lots
of
different
instrumentations
in
this
one
instrumentation
module
and
the
muzzle
is
very
different
across
them.
So
like
this,
one
muzzle
only
needs
something
very
limited,
whereas
the
other
one's
muzzle
needs
a
lot
more
to
be
present.
F
So
my
opinion
is
that
muzzle
should
be
consistent
for
everything
within
a
single
project.
F
If
that's
difficult
to
maintain
or
if
there
are
useful
boundaries
of
separation,
then
it
should
be
considered.
Then
then
you
should
consider
breaking
it
into
a
separate
module.
E
E
F
Through
muzzle
is
going
to
go
through
each
of
the
instrumentations
and
for
a
particular
version
or
whatever
it's
going
to
see,
if
that
particular
version
successfully
applies
for
each
of
the
inter
each
of
the
instrumentations
exp
successfully
applies
to
that
version.
F
So,
for
example,
if
you
have
a
version
that
it
works
for
some
instrumentation,
but
not
the
others,
then
a
muzzle
is
going
to
fail
that,
because
it's
being
applied
inconsistently,
which
happened.
F
Both
okay
well
think
about
it
at
runtime.
You
also
don't
necessarily
want
instrumentation
applying
independently
when
you
expect
it
to
all
work
together.
F
Okay,
I
see
so
you're
saying
muzzle,
should
maybe
gather
all
of
the
the
dependencies
for
ever
all
of
the
instrumentation
in
that
project
and
apply
it
to
each
instrumentation.
F
F
Is
that
being
applied
at
a
as
a
compiler
directive?
E
Oh
yeah
muzzle
check
yes,
yes,
we
have
various
ones
of
these,
oh
true,
so
that
would
if
we
could
do
that,
that
would
get
yes,
yes,
you're
right!
This
is
why
we
add
these
is
to
make
the
build
time
muzzle
happy.
F
So
if
you
make
it
apply
at
a
general
module
level,
then
in
theory
that
would
make
those
unnecessary.
F
And
so
the
the
one
thing
to
be
careful
about
is
to
make
sure
that
this
doesn't
cause
like
significant
increase
in
class
sizes
by
you
know
dramatically
increasing
the
number
of
references.
So
maybe
that
could
be
handled
by
having
that
reference.
Checking
done,
maybe
by
creating
a
separate
class
that
contains
all
of
those
and
having
it
in
a
single
place
and
then
having
each
of
the
instrumentation
for
a
module
reference
that
single
class
and
maybe
that's
the
right
way
to
do
it.
I
don't
know.
B
E
Nice,
I
will
open
an
issue
just
to
track
that,
so
we
don't
lose
track
of
that
idea.
E
All
right,
any
anything,
anybody
else
wants.
C
A
E
E
My
brain
is
yes
and
then
we're
good
to
merge
that.
E
C
E
C
Another
one
that
for
the
abstract
methods.
E
C
B
E
A
You
had
yeah
yeah,
so
I
have
two
very
related
problems.
One
is
that
I
have
a.
I
have
a
couple
more
people
from
splunk
joining
open,
telemetry
work,
at
least
occasionally,
and
I
look
at
our
backlog,
180,
something
issues,
and
I
am
I'm
really
in
trouble
to
find
how
how
should
I
direct
new
people?
A
What
what
issues
can
they
pick
as
a
like
first
introduction
to
open,
telemetry,
instrumentation
repo,
because
I
I
have
just
reviewed
quickly
reviewed
our
required
for
ga
issues
and
the
majority
of
them
cannot
be
done
by
new
contributors
and
and
that's
the
only
criteria.
I
know
right
now
how
to
pick
any
meaningful
issues
we
have
couple
of
like
health,
pointed
or
good
first
issues,
but
they
just
draw
a
handful
of
them.
A
A
I
don't
know
any
solution
to
that
right
now,
except
for
probably
making
like
proper
official
triage
periodically.
A
Yes,
do
you
have
any
easy
list
of
of
first
issues.
D
There's
several
and
there's
lots
of
help
wanteds
and
anything
in
the
api.
Sdk
is
going
to
be
a
lot
less
complex
than
instrumentation,
so
it
might
be
good.
There
are
a
few
good
first
issues
I'll
go
through
again
and
sweep
through
and
see
if
there's
more,
but
there.
A
D
D
Don't
you
and
I
chat
like
tomorrow
morning-
maybe-
and
we
can
maybe
go
through
and
see
if
we
can
find
some
good
stuff
to
chew
on?
Does
that
make
sense.
E
D
E
Yeah,
I
agree
with
that
and
also
nikita.
I
wouldn't
limit
in
the
instrumentation
repo,
don't
limit
to
g8
required
for
ga
yeah,
because
the
purpose
is
for
new
people
is
to
get
get
hands-on
experience
and
then
once
they
have
that,
then
they
can
start
tackling
the
other
stuff.
A
E
Yeah,
so
I
mean
people
have
new
contributors
have
reached
out
to
me
on
gitter
before
and
I've
kind
of
gone
through
and
picked
like
kind
of
a
curated,
a
couple
of
ones
that
I
thought
were
you
know
good
to
for
new
people
to
get
familiar
with
it,
but
yeah
that
was
in
a
very
you
know,
kind
of
curated
way
as
opposed
to
let's
maybe
next
tuesday.
A
D
So
the
way
I
like
to
distinguish
it
is
good.
First
issue
should
be
something
like
if
you
own
nothing
about
the
project
whatsoever
and
you're,
just
trying
to
learn
a
little
bit
like,
though
it's
often
things
that
are
good
for
documentation
or
they're,
really
small,
renaming
tweaks
or
something
really
kind
of
mechanical
refactorings
that
sort
of
stuff
and
then
help
one
into
something.
D
E
A
C
C
D
E
Okay,
we've
got
one
minute
before
our
five
minute
cut
off,
so
I
gotta
do
weekly
digest
speed
round
keeping
in
track
with
the
latest.
Sdk
snapshots
has
been
a
lot
of
work
because
there's
been
a
lot
of
good
changes
going
into
the
sdk.
E
We've
got
some
some
new,
a
new
contributor
ionis,
adding
doing
some
good
first
contributor
stuff.
We
updated
our
license
header.
The
only
reason
I
mentioned
this
is
because
I
think
it's
great
to
that.
We're
sinking
the
two
projects
more
and
more
love
to
see.
You
know
the
same
kind
of
spot
bugs
same
all
of
that
kind
of
tooling
the
more
we
share
the
better
parenting.
This
is
a
very
aws
lambda
specific
change.
E
Nikita
has
been
doing
a
bunch
of
great
github
actions
work.
I
think
we're
getting
super
close
to
being
able
to
turn
off
circle.
Ci
pavel
added,
a
sort
order
for
the
instrumentation
now,
so
you
can
enforce
that
one
instrumentation
happens
before
another
so
that
you
can
grab
the
span
context
that
another
instrumentation
provided,
which
is
helpful,
especially
for
vendor-specific
distributions.
E
If
you
want
to
add
some
servlet
instrumentation,
you
want
to
enhance
the
serverlet
instrumentation,
but
you
want
to
you
know
you
still
want
the
overall
span
to
be
created
first,
without
having
to
copy
that
whole
thing
over
the
code
over
jms,
oh
yeah,
test
containers,
yeah,
so
nikita.
I
think
this
is
our
first
test
containers.
E
E
So
this
fixed
a
lot
like
this
sporadic
failing
test.
That's
been
haunting
us
for
a
long
time,
split
out,
jrpc
library
instrumentation,
so
you
can
use
that
from
now
from
like
spring
spring,
auto
configure
and
marching
had
mentioned
that
this
was
his
top
priority.
If
we
did
do
if
we
split
out
the
instrumentations,
so
that's
really
helpful
for
getting
the
spring
cloud
sleuth
stuff
going
and
more
github
and
we
have
a
fancy
new
readme.
E
E
So
if
nothing
else,
yeah
ping,
any
anything
online,
getter
issues
thanks
everyone,
good
stuff.