►
From YouTube: 2021-11-11 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
C
B
Actually,
I
could
I
mean
if
it's
got
bad
ux
that
lets
you
accidentally
quit
easily.
Then.
C
A
Yeah
yeah,
I
woke
up
for
the
sampling
sig.
E
D
After
nearly
11
years
at
red
hat,
it
was
time
to
move
on
and
still
doing,
observability,
but
now
actually
at
a
from
a
user
perspective
rather
than
a
vendor.
One.
B
A
E
That's
unfortunate,
it
probably
needs
anorak
too,
but
it's
mostly
jack.
I
think
anurag
and
john
are
the
ones
that
I
really
need,
but
this
is
metric
stability.
I
want
to
make
a
set
of
bugs
and
things
that
we
we
want
to
get
done
before.
We
consider
what
we
have
stable
you're
talking
about
the
sdk
rather
than
the
api
yeah,
the
sdk
rather
than
the
api
yeah.
I
think
I
think
from
an
api
standpoint.
E
B
I
don't
know
what
you
thought
about
that
just
as
a
you
know,
because
the
spec
is
now
marked
the
spec
metric
spec
for
the
api
is
now
stable.
It
could
yeah.
E
I
I
we
could
here's
here's
my
concern,
so
this
is
one
of
the
weird
things
in
the
spec
and
and
we've
gone
back
and
forth
on
this.
I
think
you
know
how
like
there's
required,
naming
conventions
for
things
and
we
used
to
have
errors
thrown
from
the
api
and
then
we
removed
it
because
there's
this
other
thing
about,
if
you
have
a
bad
name,
you're
supposed
to
keep
it
like.
That's
in
the
spec,
I
want
us
to
kind
of
rule
one
way
or
the
other
for
java
of
like
here's.
E
B
The
question
is:
is
it
is
the
api
itself
binary
backward
compatible
like
we
had
to
actually
change
our
api
surface
and
they?
What
the
user
uses
then
that's
a
reason
to
hold
off.
But
it's
just
if
it's
just
some
internal
implementation
of
the
no
op
api
implementation
of
the
of
itself
and
what
the
right
way
to
say
that
yeah,
then
that's
right
like
we
can
change
the
behavior
in
there.
B
E
You
know
how
global
looks
up,
auto,
configure
and
like
make
sure
auto
configure
runs
and
that
sort
of
thing
we
I
I
kind
of
broke
that
hook
slightly
in
the
current
sdk
and
we
sort
of
limp
around
everything's
gravy,
because
we
own
everything
and
it's
not
stable.
If
we
add
back
in
the
api,
I
want
that
hook
to
exist,
but
that
means
there's
kind
of
this
weird
dependency
on
auto
configure
and
on
the
sdk.
E
B
Don't
know
102
degree
weather
yeah,
you
never
know
what'll
happen,
so
I
think
I
think
this
is
good.
Questions
like
to
map
out
like,
what's
going
to
happen
in
the
next
release
or
two
for
metrics,
like
after
we
release
1.9,
which,
by
the
way,
I'm
not
ready
to
release
1.9
the
quid
pro
quo
has
not
yet
been
implemented.
I
don't
have
my
android
fix
yet.
A
We
don't
get
to
bank
on
promised
futures.
C
A
B
Exactly
wait,
no.
E
I
know
it's
a
holiday
in
some
places.
At
least
I
saw
this
in
an
email.
B
Interesting
anyway,
I
think
it
would
be
good
to
map
out
1.10
and
probably
1.11
for
metrics,
especially
if
we
are
going
to
start
exposing
the
high
high
debt
high
definition
hi,
whatever
the
other
histogram,
it's
a
good
histogram.
E
E
C
B
A
E
A
I
had
this
question
come
up
also
any
because
for
our
for
tracking
what
goes
into
releases
on
the
instrumentation
side,
too,
anybody
have
thoughts
on
why
to
use
one
versus
the
other.
A
D
I've
tended
to
use
it
as
a
milestone.
More
aligns
with
releases
and
project
is
more
like
an
area
of
things
that
might
be
within
a
larger
thing,
so,
for
example,
with
carcass,
I
had
a
project
board
for
all
things,
observability
and
any
issues
were
added
to
that
board,
but
they
might
have
been
resolved
across
many
different
releases
or
milestones.
D
A
I'm
also
noticing
that
the
the
project
board
for
open
telemetry
java,
like
the
sdk,
the
ga
one,
still
has
two
hanging
out
in
the
to-do.
B
Yeah,
we
should
probably
deprecate
that
whole
that
whole
project
at
this
point
yeah
or
repurpose
it
for
something
else.
E
A
E
E
E
E
I
can
also
make
it
if
that's
acceptable
and
then
maybe
at
tonight's
meeting,
which
I
don't
know
if
I'll
make
it
depends
on
how
long
my
volleyball
game
takes.
Maybe
we
can
discuss
with
honorable
jack
and
john
and
whoever
else
is
there
if
we
have
forum
or
quorum
on
like
people
working
on
the
metrics
part
to
like
it,
outline
on
the
issues
and
things
that
we
need
to
get
resolved
because
that's
unreasonable.
B
Sounds
good?
We
can
make
a
decision
on
if
there's
anything
we
need
to
just
get
1.9
released
if
there's
anything
outstanding
as
well.
At
the
same
time,
oh
great
great
yeah
sounds
good
jack,
I
mean
so
the
first
agenda
item
jack,
said
offline
or
in
slack
or
somewhere
that
he
would
like
he
thinks
that
that
pull
request
should
get
merged.
So
someone
has
time
it.
E
Yeah
this
is
this
is
really
important
if
we
want
to
leverage
the
collector
for
anything
not
prometheus.
A
If
other
people
can
look
at
it,
that'd
be
also
good
josh.
Why
is
this
im
so
critical
for
the
collector.
E
So
right
now
the
default
is
cumulative,
metric,
temporality,
right
and
so
java's,
the
one
the
java
sdk
decides
how
to
aggregate
metrics
internally
and
then
shoots
off
these
aggregated
metrics
for
jack.
Specifically,
you
know
they
have
a
delta
backend,
where
they
want
delta
metrics.
Anybody
who
has
a
delta
backend
like
statsd
and
others
right.
If
you
want
to
get,
have
the
collector,
receive
delta,
metrics
and
export
delta
metrics,
you
want
to
receive
in
delta
metrics,
so
the
you
cannot
do
that
today.
E
That's
that's
impossible
to
send
otlp
with
deltametrics,
given
the
shifts
that
we
had
where
the
exporter
now
controls
the
temporality
right.
So
when
we
change
to
have
the
exporter
control
the
temporality,
we
also
added
a
environment
variable
that
would
configure
it.
When
I
implemented
the
change
in
the
sdk,
I
didn't
do
the
environment
variable
that
was
in
auto
configure.
That
was
a
separate
pr.
So
this
those
those
two
changes
kind
of
need
to
tie
together
to
like
fit
round
them
out.
E
So
I
I
do
think
we
want
this
in
this
release,
specifically
because
we
need
to
make
sure
that
the
hook
that
we
have
meets
those
use
cases
for
any
kind
of
delta
back
end
and
jack's.
Actually,
the
best
person
to
comment
on
that.
A
E
A
A
E
So
it
already
does
kind
of
the.
If
you
look
at
the
statsd
receiver
in
the
collector,
inherently
any
stats
d
receivers,
doing
delta
cumulative
transitions
in
various
ways,
or
at
least
one
delta
to
another
delta
aggregation.
E
So
there's
already
some
of
that
in
the
collector
and
yes,
I
think
it
will
definitely
have
delta
cumulative.
I
think
josh
mcdonald
was
one
of
the
30
projects
he
signed
up
to
do
was
that
or
said
that
he
would
touch,
I'm
pretty
sure,
someone
else
would
do
it
if
if
he
doesn't
get
around
to
it
before
someone
else
and
the
other
thing,
I
want
to
point
out
accumulative
to
delta.
I'm
not
sure
if
that
will
go
into
the
collector
or
not
that
one
is
less
likely
to
be
seen.
E
Favorably
delta
to
cumulative
is
probably
going
to
be
seen,
favorably
the
I
think
for
the
most
part,
if
we're
using
deltas,
we
want
deltas
all
the
way
down.
F
Yeah,
if
I
may,
I
don't
have
much
time
because
I'm
gonna
have
to
leave
soon,
but
so
I
started
to
recently
look
a
little
more
into
the
open
telemetry
size.
As
I
mentioned,
I'm
going
to
take
over
a
lot
of
ken's
work
here
at
red
hat,
and
I
was
even
discussing
this
with
ken
the
other
day
right.
So
one
one
of
the
prototype
implementations
that
I
did
on
something
that
I'm
working
on
was
to
use
like
a
third-party
library
which
is
pretty
much
delegating
everything.
F
That's
open,
telemetry
related
to
the
instrument
or
api
right.
So
we
were
discussing
if
this
was
the
proper
way
to
do
it
by
either
using
the
instrumenter
api
or
just
like
manually,
retrieving
the
tracers
from
from
the
tracer
builder
or
the
tracer
provider,
and
then
doing
that
well
manually.
I
guess,
if
you,
if
you
look
into
the
open,
telemetry
dot,
io
documentation
and
if
you
follow,
let
me
see
how
the
page
it's
it's
called.
But
basically
you
have
like
this
section
where
you
see
how
to
do
manual,
instrumentation
or
whatever.
F
F
I
place
it
on
the
chat
of
zoom,
so
my
question
was
mostly:
I
tried
to
figure
out
if
the
instrumenter
was
actually
the
right
way
to
do
it
for
third-party
libraries
and
if
it
was
supposed
to
have
like
third-party
libraries
outside
of
the
open,
telemetry
repo,
because
well,
when
you
go
to
the
open
climate,
repo
you'll
see,
there
are
like
a
bunch
of
implementations,
but
I'm
guessing
that
you're
free
to
do
your
own
implementation
and
have
you
outside
the
reaper
right
and
if
that's
the
case,
then
the
instrument
api
will
be
the
right
way
to
do
it,
not
how
it's
right
now
documented
into
the
manual
instrumentation
website,
or
at
least
what's
the
recommendation
right.
D
A
Our
goal
is
for
that,
to
be,
you
know,
a
sort
of
opinionated.
D
A
A
So
when
you're
so,
okay
http-
this
is
a
library
instrumentation,
but
you
could
kind
of
see
this
like
you're
talking
native
instrumentation
roberto,
where
you're
actually
you're
not
creating
a
separate
library
to
do
instrumentation
of
your
big
heat.
You
want
to
bake
that
straight
in.
F
Yeah,
basically
baking
instrumentation
on
an
existing
application
or
existing
another
existing
library,
pretty
much
the
same
as
you
have
over
there
with,
for
instance,
okay,
http
or
even
like
spring
web,
but
just
as
a
first
party
library,
not
inside
these
repo.
A
Yeah,
so
the
other
things
that
the
instrumentor
api
gives
you
is
that
you
could
expose
like.
You
could
allow
users
to
pass
in
like
a
to
customize
it.
So
we've
got
customization
points
for
the
instrument
or
api,
so,
for
example,
users
could
pass
in
their
own
attribute
extractor,
and
this
will
get
called
on
start
and
on
end
and
they
could
extract
some
additional
custom
attributes.
They
want
from
the
request
and
response.
F
Yeah
yeah,
one
thing
that
I
enjoyed
is
that
basically
you
just
delegate
pretty
much
everything
to
the
instrumenter
and
the
instrumenter
implementation
is
handling
pretty
much
everything
right.
So
I
was
doing
that
for
http
and
for
some
java
method
calls
right.
So
I
was
basically
reusing
those
server
and
client
http
extractors
right
where
we're
basically
just
reading
whatever
tags
and
putting
things
on
the
right
tags.
A
Yeah
and
we're
hoping
at
some
point,
I
think
once
once
the
instrument
or
api
once
we
get
through
stability
on
that
we're,
we
have
some
nice
testing
infrastructure
that,
like
for
http
servers
and
http
clients
a
basically
this
standard
suite
of
all
these
different
tests
and
verification
steps
that
we
reuse
across
all
of
the
server
http
server
and
all
of
the
http
client
instrumentations
in
this
repo,
and
we
think
that
that
could
be
super
valuable
for
people
implementing
those
outside
of
the
repo.
Also.
F
Yeah,
definitely
that
was
something
that
I
was
actually
looking
for.
If
there
was
some
kind
of
testing
framework
that
I
could
use
to
validate
that
my
implementation
was
actually
well
as
expected,
but
I
couldn't
find
anything
that
I
could
use.
I
think
there
is
like
a
github
issue
for
that
as
well.
A
See
yeah,
so
the
good
thing
is
that
so
the
bad
thing
is
that
our
testing
infra
has
historically
been
all
groovy
and
but
we
do
want
to
move
to
java
in
large
part
for
this
scenario
of
we
don't
want
to
force
groovy
on
downstream
folks
and
but
honorable
already
converted
the
http
client
and
http
server
tests
to
pure
java.
A
So
this
is
what
I
would
check
out
and
so
there's
yeah.
You
can
just
take
a
look
at
all.
There's
just
there's
a
ton
of
tests
and
you
can
some.
You
can
opt
out
of
several
of
the
tests
because
there's
weird
edge
cases
where
some
http
client
libraries.
E
A
Support
things
or
don't
work
correctly,
yeah
I'll
have
a
look
thanks.
F
A
A
So
for
http,
we've
got
ok,
http,
we've.
A
C
F
The
question
so
thank
you.
Thank
you
so
much
I
I
I
may
probably
try
to
look
into
into
the
test
and
see
if
that
requires
some
expansion
or
if
I
can
use
them
as
is,
and
try
to
to
help
on
that
on
that
area.
I
can
probably
try
to
help
on
under
the
documentation
for
the
instrumental
api
for
the
website
as
well.
A
Yeah,
that
would
be
awesome
if
you
take
a
look.
There's
actually
mateish
has
recently
written
some
pretty
amazing
doc.
Actually.
A
A
A
Okay,
yeah,
so
writing
that,
so
this
is
specific
to
java
agent.
This
one
writing
instrumentation.
A
F
That
I
followed
right-
oh
great,
you
found
that
yeah.
I
found
it,
but
the
the
point
is
right.
So
the
the
initial
part
is
you
go
to
the
website
right
and
and
then
you
don't
find
anything
out
of
it.
Yes,
then
I
I
ended
up
searching
into
into
the
repo,
but
that
that's
why
it
also
created
this
question
where,
if
this
instrumental
api
was
something
just
for
internal
usage
or
if
it
was
supposed
to
be
used
externally,.
A
Right
so
it's
not
it's
not
stable,
yet
we're
getting
pretty
close
to
marking
it
stable.
But
I
think
that's
that's
the
only
caveat
I
would
say
as
far
as
using
it.
D
A
I
have
a
very
good
question.
I
think
the
it
makes
sense
to
me
for
it
to
be
a
separate
artifact,
at
least
from
from
just
the
api,
which
is
respecting.
G
A
Yeah
yeah
and
lower
level,
but
whether
it
should
you
know,
live
in
the
instrumentation
repo
or
be
more
closely
aligned
in
the
open
climate
in
the
api
repo.
D
Yeah
cause,
I
think,
in
the
discussions
I
was
having
with
roberta
about
this
in
my
head.
The
instrumentation
repo
was
instrumenting,
specific
libraries
and
then
the
agent.
So
it
seemed
odd
that
there
was
this
api
that
everyone
who's
doing
their
own
direct
things
should
be
using
instead
of
the
sdk
okay.
E
Can
I
take
it
in
my
head?
Can
I
take
a
crack
at
answering
this,
so
I
think
the
fundamental
reason
is
the
open-source
api
is
meant
to
be
consistent
across
all
the
different
languages
and
incredibly
stable
like
it's.
It's
meant
to
be
like
an
http
style
api
where
once
it's
there,
we
kind
of
don't
change
it
fundamentally,
because
it
should
always
be
binary,
compatible
and
kind
of
always
be
there
almost
like
jdbc
v1.
E
You
know
for
java,
whereas
the
instrumentation
api
should
be
way
nicer
than
something
that
cannot
change
right
way,
nicer
way
easier
to
use,
and
so
you
should
be
freely
able
to
take
it
dependency
on
the
instrumentation
api.
That
makes
it
easy
to
use
our
api
and
does
all
those
convenience
things,
but
we
don't
want
to
bake
the
behavior
of
instrumentation
api
straight
up
for
everyone
who
takes
dependency
we'd
rather
have
like
that
compatibility
at
this
at
the
open,
telemetry
api
level.
E
If
that
makes
sense,
given
how
deeply
we
want
this
thing
to
get
dependent
on
it
can't
break
it
can't
change,
whereas
instrumentation
api,
we
we
can
do
more,
we
can,
we
can
be
more
aggressive.
We
can
do
cooler
things,
that's
why
it's
nicer.
A
E
I
I
mean
I'd,
be
a
fan
of
that.
I
also
think,
though,
that
the
you
sh
don't
need
to
specify
the
java
instrumentation
api,
if
that
makes
sense
like
a
spec
component
of
it,
the
spec
component
yeah.
So
there's
a
spec
component
of
what
pure
underlying
signal
apis
need
to
look
like
across
all
languages,
but
an
instrumentation
api
could
be
very
different
in
different
languages
and
to
the
extent
you
can
make
it
as
nice
as
possible
for
java,
like
that.
That
needs
to
happen.
D
Right
that
makes
a
lot
of
sense
that
the
generic
api,
even
though
it's
language
specific,
has
a
lot
of
things
in
there
that
aren't
necessarily
nice
for
java,
because
it's
got
a
cater
for
other
languages,
whereas
this
one
can
go
all
out
and
do
everything
that
java
can
that
other
languages
can't
maybe
it's
just
a
nomenclature,
naming
kind
of
thing
where
it's
in
my
head,
instrumentation,
I
tied
to
agents
and
there
was
like
okay,
that's
not
an
api,
we
should
be
using.
So
I
I
don't
know
how
to
fix
that.
D
But
maybe
it's
just
a
naming
thing,
and
and
and
maybe
as
trust
was
saying,
just
a
better-
well
advertising
it
for
one
yeah
like
a
better
like
promotion
of
this
is
the
thing
you
should
be
using,
rather
than
the
hotel
sdk
apis
directly.
F
More
stiff
to
use
right
sorry,
what
was
that
rebecca
and
it's
even
more
safe
to
use
because
it
shields
you
for
a
lot
of
complexity,
so
for
for
for
a
regular
user
or
some
for
some
implementer,
it
will
handle
a
lot
of
things
for
you
that
you
might
forget,
if
you're,
just
using
the
regular
sdk.
A
Yeah
that
that's
great
to
hear,
because
that
that
was
definitely
the
the
stated
goal
in
that
instrument
or
api
was
to
sort
of
help
kind
of
direct
people
into
what
they
need
to
capture.
A
This
honorary
kid-
if
you
haven't
seen
this
yet
this
otep
kind
of
came
out
of
the
instrumentary
api.
The
java
experience
with
the
instrument
api
and
some
of
the
discussion
in
here
definitely
reflects
that
that
difference
across
languages
like
and
we're
having
a
really,
we
kind
of
got
a
little
bit
blocked
on
this,
just
because
every
language
has
very,
very
different
opinions
about
what
makes
sense
to
their
users.
So
I
think
kind
of
onorak
had
landed
later
in
the
discussion
on
that.
A
Any
that
was
a
great
topic
by
the
way
anything
else.