►
From YouTube: 2020-12-09 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
C
B
B
B
Well,
that
might
be
the
difference,
let's
see,
but
it
sounds
like
we
obviously
have
some
fairly
severe
naming
confusion,
because
even
I
don't
remember
which
is
which
and
how
it's
supposed
to
work.
Okay
is
the
documentation
like.
Does
the
javadoc
at
the
class
level
on
trace
multipropagator,
explain
what
it's
supposed
to
do.
A
C
A
C
B
That's
the
one
that
I
guess
is
designed
so
that
you
can
like
have
just
the
set
of
all
the
different
kinds
of
propagation
you
want
rather
than
the
formats
of
propagation.
I
think
we
need
some
better
naming.
I
don't
know.
I
think
we
argued
about
the
name
on
this
when
we
first
came
up
with
it,
and
obviously
we
ended
up
with
something
that
didn't
really
end
up.
C
Yeah
well,
okay,
so
I
think
I
was
looking
at
this
in
the
first
place,
because
I
was
looking
at
some
of
the
other
propagation
stuff
and
there's
an
issue
around
this
because
jaeger
and
b3
we
want
to
support
but
they're
kind
of
squirreled
away
inside
of
the
extensions
right
right,
and
so
I
filed
an
issue
to
bring
them
up
and
in
looking
at
that,
I'm
like
well,
this
trace
multi
seems
very
useful
as
well.
Why
don't
we
bring
that
up?
C
C
B
I
don't
know,
can
you
create
an
issue
for
this,
so
we
can
at
least
make
sure
we
don't
lose
track
of
it.
Yes,
thank
you,
sir.
C
Who
else
is
a
maintainer
at
this
point?
Onorag
and
bogdan
bogdan.
B
B
B
I
think
we
probably
need
to
have
at
least
one
significant
issue
added.
That
is,
I,
I
would
say,
almost
p1
for
ga,
which
is
to
actually
document
our
configuration
story
and
implement
it.
B
So
yeah,
that's
probably
good
enough.
I,
although
I
might
want
to
create
another
issue
which
is
for
someone
to
actually
provide
it
like
write,
a
design
document
which
we'll
get
down
to
here
in
a
minute,
and
maybe
that
could
just
be
done
as
a
part
of
the
other
one.
I
don't
know
anyway,
we
got
five
things
done
in
the
past
week.
B
That
seems
good-ish.
I'm
gonna
get
rid
of
this
comment
now,
because
that
was
left
over
from
last
week.
B
B
B
All
right
yeah,
so
I
just
have
this
big
question
that
I
think
I
think
we're
at
a
point
where
we've
realized
that
what
we
have
built
is
a
little
is
not
is
a
confusing
b
potentially
wrong,
at
least
in
one
scenario
and
c,
not
actually
written
down.
B
So
I
think
I
want
to
put
a
pause
on,
and
I've
been
blocking
all
of
these
prs
that
change
configuration
in
the
api
and
sdk
until
I'd
really
like
to
have
a
document,
a
design
about
what
we
want
this
to
look
like
what
are
our
goals?
What
are
our
guiding
principles,
and
what
do
we
want
things
to
look
like
in
the
end,
maybe
not
in
every
gr
like
nitty-gritty
detail,
but
just
like
the
general
structure,
and
so
I
wrote
down
a
series
of
five
questions
that
popped
into
my
head
as
soon
as
I
started.
B
Thinking
about
this
that
have
come
up
that
people
have
asked.
Nikita's
asked
some
of
them.
I've
asked
some
of
them.
Bogdan
has
changed
some
of
them
via
prs
that
haven't
been
approved.
B
So
questions
like
what
like,
when
you
use
the
built-in
spi,
what
do
you
get
like?
What
comes
with
that
and
then
the
the
maybe
even
more
important
question
if
you
get
a
handle
to
an
spi
default,
spi
created
instance,
what
can
you
do
with
it?
What
can
you
change?
What
can
you
modify?
What
is
updatable,
if
anything
or
do
you
get
like
and
if
that's
the
case,
the
built-in
sbi
seems
kind
of
worthless,
because
it
gives
you
an
sdk.
A
Because
I
I
just
discovered
that,
like
all
real
life,
there
are
fbi
for
open
telemetry
and
for
tracer
sdk
pro
provider
different
spi's,
and
so
we
now
have
at
least
three
different
ways
to
like
configure
sdk
well,
two
different
apis
plus
plus
manual,
okay.
So.
B
I
would
say
a
year
ago
we
only
had
a
global
open
telemetry
instance
pretty
much.
The
only
way
you
could
create
it
is
via
sbi,
and
you
could
then,
once
you
got
that
spi
created
one,
you
could
add
spam
processors
and
hence
exporters
you
could
update
his
trace
config.
You
could
do
things
with
it
at
that
point
now
fast
forward.
A
B
A
A
B
A
A
B
E
So
one
potential
consideration
when
deciding
for
for
deciding
why
we
might
need
an
official
global
is,
in
the
case
of
automatic
instrumentation
being
applied
to
an
already
instrumented
app.
Do
we
want
to
be
able
to
share
that
global,
somehow.
E
So
nikita,
I
think,
you're
more
familiar
with
how
the
the
agent
is
handling
the
that
that
bridge
api.
A
A
A
E
Anyway,
so
I
I
guess,
what
I'm
trying
to
say
is
like
if
you
are,
if
you're
talking
about
from
the
java
agent's
perspective,
I
think
that
it
becomes
helpful
to
have
a
definitive
instance
of
like
what
that
global
tracer
is
and
not
have
a
global
global
for
whom
sorry
a
global
instance
of
the
open
telemetry
for
whom
global.
E
B
We
started
having
these
discussions
at
least
a
year
ago
and
didn't
really
come
to
any
conclusion,
because
nobody
had
a
firm
design
that
would
satisfy
all
of
these
things.
B
So,
a
year
later,
we
still
don't
have
a
firm
design
and
we
have
a
confusing
configuration
story
and
we've
kind
of
evolved
our
way
into
a
bit
of
a
mess.
In
my
opinion,
and
I'm
I'm
not
I'm
saying
I'll,
take
all
the
credit
for
it.
I
don't
care
all
the
blame.
You
can
blame
me
for
all
of
it.
I
don't
know
whatever
don't
doesn't
matter
to
me.
B
C
B
Yeah,
no,
I
mean,
I
think,
whatever
whatever
answer
you
have.
Well,
it's
not
quite
true
because
bogdan
pointed
out
a
really
interesting
use
case
that
I
hadn't
thought
about
at
all
last
night,
which
is
for
as
an
example,
our
tracing
sdk.
Some
of
our
components
aren't
tracing
sdk
need
a
metrics
sdk
because
they
record
metrics
about
what's
going
on
in
the
span
processor
and
bogdan
pointed
out
that
it's
possible
that
someone
might
want
to
do
tracing
in
an
exporter
to
trace
their
external
calls
as
a
part
of
the
exporter.
B
B
The
interesting
thing
is,
for
example,
when
I
was
at
new
relic
our
new
relic
exporter.
At
one
point,
when
I
brought
in
a
metrics
exporter,
it
got
instrumented
by
the
agent.
This
is
before
the
agent
provided
metric
export,
and
so
I
saw
I
saw
my
http
calls
going
out
as
a
part
of
my
metric
exporter.
E
E
Up,
I
mean
yeah
for
batching,
you,
you
in
theory
could
do
tracing
for
that,
but
again
like
what's
what's
the
value
of
that
who's,
looking
to
see
traces
being
reported
in
their
in
their
traces,
so.
B
Well,
let's,
let's
take
the
other
direction,
then
would
we
want
to
be
recording
metrics
about
how
the
metrics
sdk
is
being
used?
Yes,
so
then
metrics
needs
metrics
and
so
you're.
E
B
B
B
D
B
E
B
Which
is
okay
or
has
been
okay,
but
I
think,
as
we're
getting
close
to
release
and
people
are
telling
us
that
our
sdk
configuration
is
going
to
be
locked
in
stone.
We
probably
need
to
have
a
coherent
story
about
how
it
should
work
before
we
release
it.
B
A
B
E
A
A
Global
yeah
so.
A
B
Yes
agreed
well,
I
guess
I
took
on
the
responsibility
of
writing
up
our
release
and
versioning
story,
so
somebody
else
should
take
on
the
the
bonus
of
sorting
this
stuff
out.
B
Although
I
don't
know
who
that
would
be,
maybe
I
can
get
on
it.
Maybe
I
can
get
onorock
to
do
it.
A
A
C
A
A
A
A
B
E
Well,
so
let
me
ask
this
in
that
case
of
you
know
web
logic
with
three
different
war
files
each
having
their
own
instance
of
you
know,
open
telemetry,
and
then
you
add
a
java
agent
into
the
mix.
E
E
That
scenario
that
you
mentioned
having
web
sphere
or
web
lot
like
some
container
app
container
with
a
bunch
of
different
war
files
and
each
having
their
own
open,
telemetry
and
then
adding
a
separate
java
agent
onto
the
mix.
What
what
would
you
expect
to
happen
in
terms
of.
E
B
I
know
I
know
what
I
would.
I
think
if
I
were
a
product
manager,
what
I
would
say,
because
and
because
I
don't
know
all
of
the
internals
and
difficulties
of
the
java
agent,
I'm
just
like
a
product
manager
right,
I
can
invent
all
sorts
of
crazy
stuff
yeah.
B
What
I
would
want
is
one
agent
I
mean
you
only
get
one
agent,
so
that's
not
a
surprise,
all
of
the
auto
instrumentation
to
apply
everywhere
and
then
each
of
the
individual
apps
to
be
able
to
be
configured
somehow
magic
with
their
own
exporter,
with
their
own
service
name
with
their
own
re,
so
their
own
resource
and
propagator.
A
B
A
C
B
I
know
net
has
this
as
well.
I
don't
know
if
they're
doing
anything
to
solve
it,
but
I
know
that
net
like
if
you're
running
a
net
app
server,
whatever
ie
or
not,
ie
whatever.
Yes,
yes,
yeah
there,
you
go
or
yeah
that
thing
that
you
can
have
multiple
apps
running
in
that
which
essentially
have
the
same.
C
B
C
C
A
C
E
Just
do
one
I
mean
I
can
tell
you
what
I
would
like
as
like
a
vendor.
I
would
like
to
say:
hey
you
can
have
whatever
you
want,
but
as
soon
as
you
add
our
java
agent,
it's
going
to
hijack
what
you're
doing
and
send
it
to
where,
where
we
want
it
to
that's,
that's
going
to
be
the
easiest
to
support
definitively
yeah.
E
E
A
Well,
the
another
option:
another
ideal
solution
is:
if
we
detect
there
is
sdk
in
application,
then
we
just
use
that
sdk.
The
problem
is
what
what
does
it
mean.
B
You
can't
do
that
really
because
remember
with
most
app
servers,
you
can
load
a
war
or
year
at
run
time
after
everything
has
already
started
up,
so
you
already
have
the
global
yeah
installed
the
at
the
app
server
level
in
that
in
its
class
level.
A
D
A
E
E
Yeah,
what
is
the
current
state
nikita
of
the
bridge?
Does
the
java
agent
actually
inject
the
api
into
the
bootstrap
or
just
the
bridged
api.
E
So
if
it's,
if
they're
not
if
you're
not
injecting
the
the
full
ap
the
un
shaded
api,
then
you
might
be
able
to
have
some
decision
making
about
whether
you
want
to
do
it
or
not.
A
E
E
E
Delegated,
but
now
that
I
think
about
it,
the
other
issue
with
that
is
around
context
propagation
right.
So
in
that
scenario,
if
you've
got
multiple
different
tracer
providers,
kind
of
working
together
on
a
single
context
that
that
could
spell
complexity
pretty
easily
yeah
each
of
those.
B
E
A
B
Let
me
let
me
rephrase
you
need
to
be
aware
of
the
decisions,
but
and
you
need
to
know
how
it
works
and
how
to
actually
use
the
configuration,
but
the
specific
decisions
about
the
globals
versus
the
non-globals
versus
spi
versus
non-sbi
versus
what
you
can
configure
at
the
api
level
versus
what
you
can
configure
only
at
the
sdk
level
shouldn't
the
act.
They
shouldn't
impact
as
long
as
you
know
what
they
are
you
can
work
with.
It
should
be
able
to
work
with
it.
A
E
Totally
fine,
I'm
not
sure,
so
I
think
it's
what
tyler
was
saying.
I
I
think
what
I'm
saying
is.
I
don't
have
enough
context
to
answer
that
question.
Just
generically
like
I.
I
would
need
to
look
at
the
specifics
and
even
then
I
would
probably
want
to
I.
I
can
only
think
of
it.
B
B
Oh,
I've
been
pissing
him
off
this
morning.
Already
nikita,
don't
worry
by
blocking
all
his
people
well
and
telling
him
that
we
need
to
rewrite
metrics
right.
He
finally
like
he
had
been
completely
unaware
that
there
was
an
issue
out
there
in
my
pr
et
cetera,
et
cetera,.
A
So
so
yeah,
so
that
means
that
we
don't
so
yeah.
We
have
to
write
the
design
dock
and
it
is
a
good
thing
right
now
to
re,
to
remove
global,
open,
telemetry
completely
and
to
remove
spi
performant
telemetry
configuration
because
they
are
well
if,
if
and
to
have
like
the
bare
minimum.
Well,
not
birmingham
there.
Well
that
the
most.
A
B
A
B
So
because,
right
now
you
can
say
open,
telemetry
sdk
dot.
Whatever
the
method
is,
I
don't
remember
what
it
is
off
top
of
my
head
get
get
trace
global
tracer
management.
A
A
B
I
guess
do
we
need
that
global?
I
would
rather
so
I
I
I
don't
know
what
the
end
state
of
this
is
going
to
look
like.
We
could
take
the
approach
of
tear
it
all
down
and
basically
get
it
down
to
purely.
The
only
thing
you
can
do
is
use
a
builder
to
create
your
stuff
and
your
that's
the
only
option
you
have,
and
there
is
no
global.
B
But
in
the
meantime
we're
definitely
well.
I
would
maybe
not
definitely,
let's
say
we're
not
in
a
release-
1.0
state
without
some
answer
for
the
existing
users,
about
how
they're
supposed
to
actually
like
how
instrumentation
is
supposed
to
be
written.
If
there's
no
global,
all
instrumentation
that
uses
that
global
is
going
to
have
to
do
something
else
right,
we
will
essentially
break
every
piece
of
instrumentation
in
the
world
that
accesses
the
global,
which
sounds
like
most
of
the
agent.
B
B
Sorry
I
mean
it's
just
it's:
the
global
is
accessible
via
the
sdk,
but
it
is
the
same
global
just
for
the
just
the
one.
That's
in
the
api.
Yes,.
D
B
B
Yeah
because
of
the
global,
I
think
I
mean
I
could
be
wrong,
but
we
I
mean,
I
know
people
have
already
gotten
super
like
at
0.10
when
we
broke
every
single
api.
Everyone
got
well,
not
everyone.
A
number
of
people
who
are
paying
a
number
of
vendors
got
very
aggravated
with
that
change.
A
B
Instrumentation
so
before
we
go
down
that
road,
I
want
to
make
sure
that's
where
we
really
want
to
do,
and
we
can
have
a
really
good
story
about
how
people
should
be
doing
things.
So
we
don't
break
everything
and
then,
in
the
next
release,
bring
a
whole
bunch
of
stuff
back
that
they
could
have
been
using
before.
Could
that
make
sense.
E
Clarify
really
quick:
what
is
what
exactly
are
you
suggesting
needs
to
be
done?
Do
we
need
to
remove
the
global?
Is
that
what
you're
saying
who.
B
Among
other
things,
yeah.
E
The
the
hazards
of
what
he's
proposing,
if
you
remove
the
global,
then
it
makes
it
impossible
for
a
user
using
the
the
api
in
their
code
to
actually
interact
and
report
traces
to
the
java
agents.
C
E
So
then,
then
it
so
so,
basically
what
you'd
have
to
do
is
instead
of
doing
at
the
global
level.
You'd
probably
have
to
hijack
the
builder,
and
so
the
builder,
instead
of
returning
what
they
were
expecting
would
return
a
static,
whatever
instance
that
you
define
at
the.
A
A
B
E
B
Say
this
is
why
we,
I
think
we
need
to
write
it
down,
because
until
we
have
it
written
down,
we
don't
have
a
straw
person
to
hit
with
a
broom
and
break
apart.
A
B
B
A
A
A
B
So
if
there
is
a
vendor
who
wants
to
provide
their
own
sdk
implementation
via
sbi,
that
we
currently
that
we
do
support
that
at
the
moment
like,
rather
than
doing
what
you're
doing
nikita
with
your
manual
building
up
of
a
vendor
distribution,
you
could
create
an
spi
for
it
and
have
that
be
the
thing
that
actually
does
all
of
that
work.
But
but
the.
B
It
just
provides
that
facility,
I
mean
yeah
just
provides
that
as
a
possible
facility
that
the
sdk
will
support
out
of
the
box
or
the
api
excuse
me
will
support
us.
Yes,.
B
I'm
I'm
not
100
sure
that
saying
there
can
be
only
one
is
the
right
answer
for
configuration,
because
I
think
there
are
other.
There
are
multiple
use
cases
for
configuration
and
I'm
not
sure
that
there
is
one
true
way
that
you
can
say.
This
is
the
only
way
yeah,
I
think
or
something
I
mean
right
now.
We
provide
both
environment
variables
and
system
properties
for
configuring
things
like
that's
two
different
ways
right
like
yeah,
I'm
not
always
doing
one.
B
B
B
Well,
what
I
was
going
to
suggest-
and
it's
unfortunate-
that
it's
not
till
tomorrow,
more
than
24
hours
from
now,
is
to
get
well.
I
know
you
won't
be
around
nikita,
but
that's,
I
think,
that's
fine,
because
you're
not
a
maintainer
of
java,
but
get
me
and
honorable
bogdan
in
a
call
tomorrow
in
the
after
the
evening,
call
that
we
hijack
the
instrumentation
sig
evening
instrumentation
sig,
when
we
can
actually
get
all
three
maintainers
on
here
on
a
call.
B
B
Sorry,
I
said
nikki
I'm
in
honor
of
set
up
a
call
to
just
go
through
this
stuff
and
convince
him
yep
and
convince
him
that
he
should
do
it
if
he
has
opinions
that
he
should
write
them
down
so
that
they
will
be
the
ones
that
are
adopted,
because
I'm
pretty
sure
whoever
writes
this
down
is
the
one
who's
going
to
get
what
they
want.
B
B
If
I'm
acting
as
the
benevolent
dictator,
I'm
going
to
favor
the
people
who
are
writing
it
writing
down
what
I
want
to
see
or
write
down
something
and
something
that
we
can
talk
about
so
anyway.
Okay
make
sense,
good.
My
action
item,
I'm
going
to
write
down
an
action
item
because
leaving
with
an
action
item,
is
terrible
john
to
talk
to
on
a
rob
about
this.
D
B
All
right:
well,
thank
you,
everybody
for
talking
about
this
stuff.
It's
as
I
I
was
I've
told
nikita
and
I
told
bogdan.
I
think
I've
decided
in
the
past
year
that
configuration
is
the
hardest
thing
to
get
right,
because
it's
a
human
problem.
Everybody
wants
to
do
things
differently
and
there's
no
one
true
way
to
configure
anything
well.