►
From YouTube: 2021-01-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
Nikita
good
evening,
I
look
forward
to
you
bossing
us
around
from
now
on.
A
I
did
yeah
on
the
whole
configuration
story,
jason
and
I
have
been
working
on
converting
your
or
actually
working
on
figuring
out
how
to
convert
splunk
hotel
java
to
use
the
newer,
auto
configuration
story
and
found
one
bit
that
we
want
to
add.
So
I'm
going
to
pr
that
today.
So
we
aren't
kind
of
messed
up
when
015
hits.
C
Yeah,
the
back
story
was
so
I
I
wanted
to
try
and
experiment
in
using
the
latest
bite
buddy,
which
is
only
a
patch
release,
and
I
don't
think
it
fixes
my
problem,
but
I
wanted
to
try
it
so
new
bite
buddy
into
the
agents,
local
publish
the
agent
and
then
change
splunk
hotel
java
to
use
that
locally
published
snapshot
instead
of
the
remote
snapshot
and
everything's
broken
like
you
can't
configure
anything
anymore
in
splunk
at
all
java.
So
that's
that's.
What
started
me
down
that
path.
A
A
B
A
A
In
your
example
like,
for
example,
this
doesn't
have
any
configuration
at
all.
It's
just
like
a
new
demo,
exporter,
okay,
but
we
would
like
to
be
able
to
use
environment
variables
and
system
properties
to
configure
the
exporter,
and
we
no
longer
have
a
way
to
get
that
unified
view
of
things
in
the
configuration
like
to
normalize
those
properties
and
that
kind
of
stuff
and
then
use
that
for
doing
configuration.
That's
kind
of
thing,
one
like
it
might
be,
it'd
be
nice
to
have
a
something
to
do
that:
normalization
property
normalization
for
us
yeah.
A
Rather
than
having
to
repeat
that
code
right,
that's
one
and
two
there's
a
whole
bunch
of
built-in
hotel
spam
processor
configuration
that
we
would
like
to
leverage
like.
We
want
to
be
able
to
use
all
the
standard
environment
variables
for
the
spam
processor
configuration
but
then
give
our
own
export
and
your
example
just
uses
a
simple
spam
processor
which
again
doesn't
have
any
configuration.
A
So
we
really
would
like
to
be
able
to
do
some
fancier
exported
configuration
and
leverage
the
spam
processor
configuration
that's
built
in
and
we
have
a
plan.
We
know
how
we
want
to
do
it.
It's
actually
going
to
be
pretty
easy.
It's
going
to
look
just
like
the
propagator
configuration
right
now,
spi,
where
you
can
give
it
your
propagator,
a
name
we'll
be
able
to
do
the
same
thing
with
the
exporter,
give
your
exporter
a
name
and
then
provide
all
the
standard
configuration
for
it.
A
B
But
that's
specific,
but
you
see
when
you
said
that
you,
you
are
going
to
do
a
new
spi
for
the
exporter
and
we
already
have
that
the
similar
spi
for
propagators
right.
Does
that
mean
that
every
single
bit
that
you
would
would
want
to
change
against
default
or
from
from
default
will
end
up
being
an
nspi.
C
A
B
B
C
A
Rid
of
that
processor
yeah,
I
think
this.
This
is
to
kind
of
a
little
bit
to
address
your
desire.
I
think
everyone's
desire
that
very
few
people
care
very
much
about
the
details
of
the
spam
processor
and
most
people
care
a
lot
about
the
details
of
the
exporter,
especially
vendors,
who
are
going
to
have
custom
exporters
left
and
right.
B
A
A
B
B
B
A
There's,
I
think,
there's
a
there's
a
little
subtlety
there
like.
Let's
say
you
want
to
set
your
propagator,
but
you
want
to
use
all
the
defaults
for
the
the
default
environment
settings
for
your
sampler
right.
The
sampler
has
a
bunch
of
environment
variables,
right
yeah
like
you,
I
want
to
use
those,
but
I
only
want
to
override
the
one
thing
like.
I
only
want
to
change
the
propagator
I
don't
want
to.
I
want
to
use
the
defaults.
I
want
to
use
the
built-in
stuff
for
everything
else
right,
yeah!
A
B
Yes,
absolutely
so,
first
of
all,
we
pre-populate
everything
with
the
default
and
then
end
user
can
decide.
I
want
to
change
to
swap
one
thing,
and
currently
we
can
do
that
with
almost
everything
except
exporters
and
I'm
fighting
about
propagators
and
exporters
cannot
exactly
because
the
current
processor
is
strange
yeah
so
for
this
particular
problem
right
now
before
1.0.
B
A
B
A
Think
another
thing
to
think
about
is
like
here's
another
use
case.
Let's
say
I
want
to
use
the
the
what's:
it
called
not
the
best
brand
processor
but
the
the
disrupter,
the
disrupter
spam
processor,
but
it's
one
of
the
standard
exporters,
so
I'm
kind
of
back
in
that
same
situation
now
right
where
yeah.
A
If
I,
if
so
that's,
I
think
that's
a
real
life
example
where
I'm
I'm
for
me,
I
want
to
always
be
on
the
disruptor,
but
I
want
to
use
the
built-in
jaeger
grpc
and
now,
even
with
the
current
system,
I'm
going
to
have
to
reproduce
the
config
on
that
exporter
to
be
able
to
support
that
right.
Yep,
so
yeah
exporter,
spam,
processor,
config,
they
are
tightly
interwoven.
D
F
A
It's
all
right,
no
worries
well
welcome.
I
guess
we're
15
minutes
into
the
meeting
already,
so
we've
been
talking
about
the
configuration
sdk
configuration
story
which
has
taken
a
bit
of
work,
because
I
now
believe
that
configuration
is
the
second
hardest
problem
in
computer
science.
E
And
by
that,
do
you
mean
the
auto
configure
stuff
that
hotel
java
has
or
just
like
configuring
things
in
general?
Well.
A
E
Right
and-
and
that
was
kind
of
one
of
the
reasons
why,
four
years
ago,
when
we
started
microprofile,
we
created
a
config
spec,
because
that
was
like
a
huge
gap
that
wasn't
anywhere
and
we're
like.
This
needs
to
be
solved.
Not
saying
that
they've
done
it
a
great
way,
but
it's
better
than
nothing.
A
Yeah
anyway,
so
we
really
want
to
get
1.0
out
in
the
next
two
to
three
weeks,
and
so
we
want
to
get
just
to
get
the
configuration
story
in
a
usable
place
for
both
vendors,
who
want
to
customize
the
agent
and
for
people
who
want
to
tweak
anything
they
want.
So
I
think
we're
getting
all
those
we
have
a.
We
have
one
more
pr,
I'm
going
to
try
to
put
in
today
that
I
think
will
tie
the
knot
on
the
last
little
bits
for
tracing
okay
and
then
we
can
keep.
A
Yep
yeah,
it's
really
mostly
to
support
custom
distributions
that
need
non-standard
exporters.
A
Nikita
apparently
has
gone
on
record
as
being
concerned
about
excessive
spi
growth.
Fair
enough
other
announcement
default
branch
has
been
changed
over
to
maine.
This
is
being
done
across
all
of
the
projects,
so
update
your
forks
and
your
local
copies
to
point
to
the
renamed
branch.
A
I
guess
one
thing
I
should
bring
up
is:
it
looks
like
we're.
Switching
our
build
over
to
kotlin
kotlin-based
gradle.
A
A
Yeah,
that's
the
end
of
my
agenda.
What
do
you
all
want
to
talk
about.
F
I
love
that
this
is
the
end
of
violence.
Have
you
guys-
and
I
I'm
sorry-
I
have
been
kind
of
missing
for
a
while?
Has
anybody
talked
about
what
happened
at
the
metrics
powwow
two
weeks
ago?.
A
What's
your
impression
here
and
I'd
like
to
hear
what
you
you
thought,
the
outcome
from
that
was.
F
I
think
it
depends
on
what
we
now
do
next,
because
it
could
end
up
being
a
whole
lot
of
nothing.
You
know
it's
it's
on
us.
I
think
to
kind
of
push
things
along.
So
joni
opened
a
couple
issues
about.
F
I
think,
against
the
spec
repo
trying
to
bring
up
some
of
the
conventions,
for
example
that
micrometer
uses
as
far
as
like
trying
to
get
naming
conventions
and
to
carry
on
the
conversation
about
how
many
different
metrics
types
there
are
given.
That
there's
basically
like
double
the
number-
and
I
think
some
of
those
conversations
have
to
continue
from
a
java
working
group
perspective.
I
kind
of
wanted
to
come
back
to
what
we
had
talked
about
in
terms
of
positioning
or
making
micrometer
and
the
open
telemetry
implementation
for
metrics
work
more
closely
together.
F
I
know
ken
has
you
guys
have
been
talking
about
the
batch
observer,
for
example,
which
was
the
piece
that
I
was
missing
to
get
function,
timers
working
to
have
a
a
micrometer
registry
that
would
basically
write
directly
to
an
hotel
implementation
with
as
little
as
possible
in
the
way.
But
I
I
just
didn't
know,
I
don't
know
where
you
know
this
group
as
a
body
is
thinking
right
now
about
about
metrics,
given
the
api
is
potentially
up
for
revision.
A
So
the
outcome,
the
concrete
outcome
it
was
discussed
in
the
spec
meeting
this
week-
is
that
well
in
the
metric
spec
meeting
last
week
is
that
the
plan
that
is
currently
being
moving
forward
is
first
and
foremost,
to
reconcile
the
open,
telemetry
metrics
data
model
with
other
open
source
data
models
that
are
already
very
popular
like
prometheus,
especially,
you
know:
corinthians,
open,
metrics
and
yeah.
A
A
And
then
so,
once
that
data
model
discussion
has
taken
place,
which
honestly
I
have
no
idea,
how
long
that's
going
to
take-
and
it's
honestly
one-
I
don't
care
very
much
about
personally,
but
I
am
very
glad
there
are
people
who
care
very
strongly
about
it,
but
it's
one
that
I
mostly
want
to
listen
to
and
learn
rather
than
try
to
impose
any
sort
of
thoughts
right.
So
once
that
is
that
discussion
is
complete.
A
F
A
F
Like
that's
that's
interesting,
so
I
guess
to
me:
that's
like
back-end
data
propagation
to
make
systems
interoperate
for
collection,
which
is
fine,
but
that
to
me
puts
more
pressure
on.
I
guess
it
doesn't
really
put
pressure
but
like
it
just
means
like
the
micrometer
from
the
java
perspective,
for
example,
micrometer
and
the
prometheus
client,
and
then
whatever
other
agents
like
there's
a
strong
case
that
they
have
to
continue
to
be
viable
for
metrics,
because
we
don't
have
an
api
to
replace
them.
F
I
think
I
would
like
this
group
to
have
a
like.
In
my
personal
opinion,
these
libraries
should
always
work.
We
shouldn't
be
looking
to
supplant
them
if
they're
already,
you
know
in
significant
use,
I
guess
like
ken,
could
you
know
we?
We've
I've
had
a
lot
of
trouble,
for
example
with
the
purpose
of
the
microprofile
metrics
spec.
F
Why
do
we
need
a
new
spec?
We
have
libraries
that
are
super
well
utilized.
Super
well
understood
that
can
speak
any
backend
language.
You
want
like
format,
you
want
so
as
long
as
those,
for
example,
push
out
in
a
format
that
open
telemetry
likes
the
entire
world
is
happy.
A
So
right
we
know
micrometer,
you
can
already
do
a
micrometer
registry
that
is
prometheus,
friendly
and
probably
statsy,
I
assume
yep,
and
so
that
you
can
point
any
of
those
things
at
the
collector.
At
that
point,
once
that
story,
once
the
collector
story
is
straightened
out,
then
all
that
stuff
should
just
work.
You
can
use
your
micrometer
registry.
That
points
at
prometheus
and
pointed
at
the
collector
would
be
done.
F
A
If
you're
happy
with
way,
micrometer
works
right,
so
then
the
third
step-
and
maybe
this
would
happen
in
parallel
with
the
collector
work,
because
I
think
there's
actually
the
people
who
are
interested
in
that
are
not
exactly
the
same.
The
third
step
is
then
go
back
to
our
the
apis
that
have
been
defined
and
revisit
them
and
make
sure
that
they
make
sense
in
the
context
of
that
data
model.
F
A
I
think
that's
probably
true,
yes,
okay,
that
make
me
that
makes
sense
to
me
again.
A
It
hasn't,
I
hadn't
thought
about
that
in
particular,
because
again,
this
is
one
of
those
things
where
I'm
happy
to
listen
and
learn,
and
I
don't
have
too
many
strong
opinions.
I
think
the
api
is
annoying
right
now
that
you
have
both
long
and
double
and
you
have
to
care
about
it.
I
agree
with
that,
but
it's
also
something
that
that
I'm
also
happy
to
go
along
for
the
ride,
with
what
the
people
who
have
stronger
opinions
feel.
So,
yes,
I
think
that's
definitely
a
possible
fallout
from
the
data
model,
okay
and
so
yeah.
A
F
A
ways
away:
yeah,
that's
what
I
that's
the
feeling
I
was
getting.
So
I
don't
know
if
it's
worth
like,
I
kind
of
feel
like
I
threw
some
pasta
on
the
wall
to
say
here's
what
a
an
open
telemetry
micrometer
registry
might
look
like,
but
I
think
that's
just
gonna
be
on
hold
until
we
have
any
idea
of
what
that
what
that
api
is
gonna,
end
up
being
yeah.
F
Exactly
which
we
already
have
right,
we
already
have
okay,
so
the
other
question
then
coming
out
of
thank
you
for
answering
all
of
my
questions
by
the
way.
I'm
sorry
that
I'm
like
picking
on
you,
but
I.
F
The
other
question
it's
very
loose
in
my.
D
F
F
F
F
Oh,
no,
it's
back
the
instrumentation
stuff,
so,
okay,
so
so
with
tracing
pieces.
Looking
from
a
java
perspective,
we
know
we
have
sleuth
able
to.
I
haven't.
Looked
at
the
details
of
how
sleuthing
and
open
telemetry
tracing
are,
are
working,
you
know
or
being
compatible
now,
but
I
I
know
that
that
works
happening,
and
I
know
that.
F
From
a
the
automatic
instrumentation
perspective,
that's
still
focused
around
tracing.
Do
you
see
there
being
a
separation
of
concern
still
between
the
kind
of
base
automatic
instrumentation
agent
library?
I
guess
that
was
kind
of
being
created?
That's
still,
I
think
mostly
focused
on
tracing
and
then
a
separate
concern
for
metrics.
Do
you
still
see
those
two
things
being
combined
at
some
point.
A
So
my
nikita
might
have
some
thoughts,
but
I
think
that
there
probably
will
be
metrics
added
to
the
auto
instrumentation
once
the
story.
The
metric
story
is
solidified,
okay,
but
that
would
be,
but
that's
auto
instrumentation
and
those
metrics
could
be
whatever
we
thought
was
like.
We
could
start
putting
timings
in.
A
We
could
start
doing
all
that
sort
of
stuff.
If
we
wanted
to.
B
B
F
How
do
we
make
sure
that
we're
not
double
measuring?
I
actually
have
that
problem
with
open
telemetry
in
general,
also
because
I
know
there's
some
libraries
that
at
the
code
level
want
to
add
trace
like
ad
spans
and
traces
whatever
automatically,
but
then
also,
you
have
auto
instrumentation
libraries
that
want
to
do
that,
and
I
don't
understand
what
we're
doing
to
make
sure
that
we're
not
being
redundant.
B
Currently,
nothing
except,
except
of
accepting
that
there
is
a
concern
here
that
we
should
solve,
but
that's
good
question.
There
is
an
issue
about
that
somewhere
in
our
backlog.
We
have
no
idea
how
to
solve
that.
Yet.
A
It's
just
an
example.
I
did
this
to
myself
today.
Well,
I
was
not
this
week
while
I
was
experimenting
with
the
agent
and
annotations
and
what
happens
if
you
do
nested
client
spans
and
how
that
stuff
gets
suppressed
or
doesn't
et
cetera,
et
cetera,
and
I
annotated
a
spring
batch
method
with
a
width
span,
and
then
I
got
two
spans.
I'm
like
well,
that's
silly
string
batch
is
already
instrumented.
I
can
remove
mine,
but
I
could
see
it
pretty
easily
like.
A
F
Your
manual
one
right
but
like
with
some
of
the
corkus
stuff
or
or
some
of
the
things
that
ken
and
I
are
working
on,
for
example,
we'd-
have
the
instance
where
the
quercus
open,
telemetry
support
would
would
add
a
span,
but
then
the
instrumentation
agent
might
also,
but
neither
of
those
are
in
the
user's
control.
A
Right
now
we
have
this.
We
have.
We
already
have
this
issue,
even
just
within
the
instrumentation
agent
itself,
right
now
like
there's
jax
rss
client
instrumentation.
That
then
will
get
augmented
by
additional
http
client
instrumentation
under
the
hood,
and
they
have
different
information
information.
Some
people
would
like
to
only
have
one
span
for
that.
Some
people
would
like
to
have
two
spans
and
there's
actually
no
right
answer
about
whether
you
want
to
have
it
duplicated
or
not,
because
there's
different
layers
have
different
amounts
of
information
and
can
put
different
things
on
those
fans.
A
So
I
think
there's
a
so.
I
will
say
that
I
brought
this
up
fairly
emphatically
at
the
spec
meeting
yesterday
morning
and
ted
young
when
he
gets
back
from
his
vacation,
is
going
to
start
some
sort
of
group
or
have
some
meetings
to
really
talk
about
seriously.
What
the
span
data
model
should
look
like
around
this
sort
of
thing
like,
but.
B
F
B
That
would
be
my
first
thought
because
well,
I'm
in
auto
implementation,
it's
easier
for
us
to
fix
that
right
than
okay,
libraries,
so
yeah
and
exactly
the
same
with
the
same
problem.
I
think
we
we
with
metrics
as
well.
It's
maybe
more
complicated,
because
when
you
count
requests
you
can
count
them
on
different
levels.
How
we
detect
that,
but
essentially
that's
the
same
problem
and
yes,
I
think
that
outer
instrumentation
should
back
off.
E
D
E
A
E
F
Some
history
of
a
few
different
library,
like
you
know,
we
have
lots
of
different
instrumentation
people
providing
micrometer
binders,
for
example,
to
measure
libraries
it's
almost
like.
We
would
want
some
way
for
a
library
to
say
I
have
or
for
you
to
detect.
Oh,
this
instrumentation
thing
is
enabled,
or
this
micrometer
binder
is
enabled-
or
I
don't
know
something
to
be
able
to
turn
stuff
off.
Even
if
it's
a
something
you
figure
out
at
build
time
would
be
preferable.
Obviously,
but.
D
A
B
One
of
the
possible
ways
is
that
we
in
auto
instrumentation
always
want
if
we
can
provide
library
instrumentations
as
well,
so
we
we
provide
just
like
wrapper
or
handler
or
listener
callback
that
user
can
apply
manually
and
auto.
Instrumentation
is
just
by
code,
manipulation
to
apply
that
piece
of
code
automatically.
B
B
A
B
B
E
So
so,
just
some
kind
of
like
sbi
kind
of
thing
that
frameworks
can
create
that
auto
instrumentation
like
looks
for
and
then
interacts
with
it
through
that
kind
of
thing,.
B
A
Yeah,
I
mean,
I
think,
when
we're
in
this
utopian
world,
where
everyone
builds
instrumentation
into
their
libraries,
we'll
have
good
problems
to
solve
and
it'll
be
a
happy
happy
world.
B
B
But
well,
I
do
hope
that
at
some
point
a
community
will
start
pushing
library
authors.
Why
don't
you
provide
telemetry
built
in
yeah?
Everybody
else.
Does
I
have
to
choose
between
two
connection
pools
these
pro
pro
provides
telemetry.
This
doesn't
that's
still
well.
I
choose
that
because
that's
good
or.
E
Cool,
I
I
have
a
question
which
I'm
not
sure
it's
been
a
while
has
there
been
any
further
discussion
at
the
spec
around
how
to
hand
properly
handle
traces
in
terms
of
whether
something's
a
follow-off
follows
from
a
child
of
and
all
that
kind
of
stuff,
because
I
know
maybe
like
three
or
so
months
ago.
There
was
a
lot
of
discussion.
I
think
that
got
pushed
post
ga,
but
I'm
not
sure
if
anyone's
talked
about
that
again
since
nope.
A
A
I
think
everybody
knows
that
none
of
the
existing
like
open
tracing,
didn't
solve
this
problem.
Open
census
didn't
solve
this
problem
like
nobody
actually
built
this
kind
of
comprehensive
model.
Zipkin
has
their
way
of
modeling.
It
jager
has
their
way
of
modeling
it
and
they're,
not
at
all
the
same
so
coming
to
some
sort
of
common
way
to
do.
It
would
be
good.
A
Yeah-
and
I
agree-
I
wholeheartedly
agree
with
that
sentiment
that
you've
voiced
it's
like
if
we
get
nothing
else
out
of
here.
Just
having
a
common
set
of
conventions
would
be
incredibly
helpful
for
everyone,
yeah
for
sure.
F
A
Want
that
exactly
all
right?
Well,
thanks!
Everybody
yeah,
look,
look
for
the
o15
release,
either
later
this
week
or
early
next
week,
and
that
will
that
will
be
the
plan.
Is
that
will
be
our
release
candidate
for
1.0?
Okay?
So
we
will
not.
The
spec
group
has
requested
that
no
languages
release
1.0
until
the
spec
has
actually
released
1.0,
so
we'll
hold
it
release
candidate
until
the
spec
actually
gets
our
together
and
releases
the
1.0
version
so.