►
From YouTube: 2021-02-26 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
Hello
for
portlanders.
B
B
A
A
A
A
A
A
We
have
to
non-splunk
people
have
to
band
together.
D
A
A
Yeah,
so
we
discussed
this
with
honorable
on
tuesday
wednesday,
and
so
I
john
is
everything
looking
good
for
one
sdk
one
zero
end
of
tomorrow.
That
is
still
the
plan
awesome.
A
So
then,
I
think
the
plan
our
plan
is
our
target,
is
gonna,
be
mid
next
week
to
release
the
java
agent
one
zero.
A
A
So
it's
a
you
know:
it's
a
limited
one,
zero,
the
instrumentation
repo,
but
it
serves
a
good
purpose.
Well,
it's
a
good
it's
it's
our!
What
I
think
a
lot
of
us
or
a
lot
of
people's
customers
are
using.
A
Yeah
we
don't.
I
know
that
I
mean
the
instrument,
the
library
instrumentation
instrumentation.
Api
artifact
is
a
high
priority.
A
So
that
people
in
spring
land,
spring
cloud
sleuth,
can
use
that
and-
and
we
all
know,
there's
a
lot
of
work
to
go
in
that
instrumentation
api
and
that
thanks
matthias
for
kicking
that
back
off
again
this
week
with
the
working
on
the
tracers.
D
You
said
that
we
all
know
that
there
is
a
lot
of
work
to
do,
but
do
we
I
mean,
do
we
have
that
work
somehow
captured
and
visible,
because
well,
if,
if
I
would
have
to
like
start
working
on
stabilizing
instrumentation
api
tomorrow,
I
have
no
idea.
Where,
should
I
start.
D
A
I
would
vote
for
renaming
it.
You
know
sooner
than
later,
if
only
to
avoid
confusion
between
with
the
hotel
api,
tracer.
D
But
if
we
rename
that
to
instrumentor
sooner
than
later,
with
the
end
goal
to
that
should
in
the
future
cover
both
tracing
and
metrics,
but
we
cannot,
but
we,
but
it's
it.
It's
api
is
still
totally
spun,
span,
centric
and
racing's
centric,
and
we
don't
know
what
metric
center
kpi
will
look
like.
A
Sort
of
change
instead
of
start
span
and
start
operation,
like
kind
of
the.
D
D
A
Yeah,
so
I
think
I
mean
we
do
have
we
do
know
what
the
use
case
is,
which
is
primarily
around
sampling.
I
think
that
it
spans
if
people
are
sampling
at
you
know
one
percent.
D
A
D
Yeah
but
yeah,
but
that
that
will
not
work
with
the
specific
use
case
that
you
just
said,
because
if
we
are
sampling,
then
okay,
we
simply
okay.
You
mean
that
okay,
sorry
anyway,
my
I'm
still
like
reluctant
and
unsure
that
we
can
right
now
start
imagining
that
abstraction
until
we
have
actually
written
some
code
for
using
metrics
in
our
implementations,.
A
Yeah,
that's
definitely
fair,
and
so
I'm
not
sure
when
we
should
start
prototyping
metrics.
A
I
don't
know
john.
If
you
have
any
thoughts
on
like
I
know
it
would
be
nice
to
start
thinking
about
metrics
in
the
in
instrumentation,
but
at
the
same
time
it
is,
you
know,
a
moving
target,
and
so
it
may
make
sense
to
wait
for
that
to
stabilize
a
little
bit
more.
B
Well,
in
the
spec
meeting
this
week,
somebody-
I
don't
remember,
who
put
oh,
is
riley,
I
think,
put
or
published
what
he
felt
was
a
reasonable
timeline
for
metrics
and
it
had
the
spec
being
complete
in.
F
D
We
can
but
then
do
we
want
instrument
to
be
like
feature
proof
for
the
future
metrics
api
as
well
or
not.
If
we
are
currently
aiming
for
tracing
specific
and
racing,
only
api
abstraction
object.
We
can't
do
that.
Certainly
you're
worried
about
making
a
future
proof
yeah
and
if,
if
we
are,
if
we
are
renaming
tracer
to
instrument
because
of
the
reason
that
we
want
to
have
the
single
abstraction,
then
it's
to
earth.
D
F
Okay,
I
mean
I,
I
take
an
extreme
stance
on
being
backwards
compatible,
so
I'm
not
gonna.
I
just
wanted
to
see
where
you're
coming
from
that's,
where
you're
coming
from.
A
D
A
Yeah,
I
think,
there's
going
to
be
a
lot
of
duplicate
like
because
a
lot
of
those
dimensions
for
metrics
come
from
the
same
things
we're
already
capturing
in
the
tracer
like
db
name.
D
D
A
Well,
and
just
the
last
thing
on
this,
the
from
december
right,
we
would
even
if
we
are,
can
migrate
our
code
internally
for
our
library
instrumentations.
If
we
have
any,
you
know
if
we
break
any
existing
apis,
any
public
apis
in
tracer,
for
example,.
D
B
B
Because
there's
no
like
ted's
timeline
or
ted's
road
map
that
he
put
together
didn't
have
that
on
the
roadmap
at
all,
like
defining
stability,
guarantees
for
telemetry.
D
D
A
Because,
where
I'm
coming
from,
I
see
that
we
want
metrics
and
traces
are
very
close
together
in
that
we
want
to
capture
metrics
about
the
span
about
the
same
operations
that
the
spans
are.
A
D
A
D
But
logs
potentially
you
want
to
have
access
logs
in
exactly
the
same
way,
and
these
are
dimensions
that
I
I
my
point
being
is
that
I
I
I
can
understand
three
separate
apis
and
all
one
api.
I
cannot
understand
why
we
have
like
traces
and
metrics
together
and
logs,
but
and
we
don't
care
about
logs.
I
can
understand
that.
D
A
D
Truth,
truth
being,
I
have
currently
no
idea
what
exactly
openglm
network
wants
to
do
with
logs
my
for
for
me
the
what
I'm
trying
currently
trying
to
understa
understand.
Why
do
you
think
that
we
cannot
release
stable,
instrumentation
api
without
metrics,
but
you
think
that
we
can
release
stable
information
api
without
logs.
A
Because,
well,
I
think
we
probably
you
know
we
could,
but
I
see
them,
as
I
see
a
potential
issue
there
for
moving
forward,
because
the
metrics
we
want
to,
like
I
mean
most
like,
like
a
lot
of
monitoring
tracing
solutions.
Do
this
they
have
this
operation
concept.
A
You
want
your
span
like
I
I'm
hesitant
to
even
recommend
open
telemetry
tracing
to
our
customers
right
now,
because
they
can
capture
traces,
but
there's
no
way
to
capture
like
metrics
and
metrics
are
so
critical
from,
like
you
know,
even
like
my
request,
request
count
my
average
response
time,
my
99th
percentile,
and
if
they
instrument
with
traces
now
and
on
the
back
end,
we
kind
of
shim
that
when
we
start
going
to
what
we
really
need
is
they'll
need
to
call
the
metrics
api
also
to
capture
those
counts
response
times.
D
D
I
will
that
be
breaking
on
non-breaking
changes.
It
doesn't
separate
questions
for
for
me,
but
you're
concerned
that
they
will
have
to
update
either
the
new
version
of
the
api.
D
Yeah,
I
mean
I
mean
you:
yes,
either
release
instrument
stable
api
together
or
to
have
right
now,
like
unified
api
right
right
right
away.
D
D
First
of
all,
I
I
propose
to
not
introduce
breaking
changes.
I
propose
to
introduce
a
new
api,
but
anyway
I
what
what
I
mean
is
that
currently
all
clients
of
instrumentation
api,
okay,
sprint
sleuth
as
well
all
clients
except
sprint
clues-
are
living
in
the
in
this
very
same
river.
D
F
D
F
Yeah,
I
want
to
also
just
throw
this
out
there
because
I'm
not
sure
if
it
helps
or
not,
but
I
think
it
might
help
in
thinking
about
this
problem
that
is
that
this
api-
this
is
we're
talking
about
an
instrumentation
api
and
the
I
and
api
is
interface
and
there's
this
idea
of
interface,
segregation
principle
and
if
we
think
about
tracing
and
metrics
and
logs
as
different
interfaces,
that
might
give
us
an
improved
way
of
thinking
about
this,
like
I
don't
know
that
we
necessarily
need
to
have
a
universal
api
for
all
of
those
concerns
if
they
could
be
broken
down
into
smaller
concerns.
F
There's
certainly
going
to
be
a
lot
of
instrumentation
that
never
cares
about
logs.
I
think
that
was
trust's
point
and
today
there's
a
lot
of
instrumentation
that
doesn't
care
about
metrics
and
probably
won't,
but
keeping
those
as
separate
wires,
but
not
trying
to
force
a
unified
api.
I
think,
might
actually
help.
D
A
So
I
think
the
the
yeah
I
mean
it
can
be
anybody
right.
Anybody
who
wants
to
write
http,
client
instrumentation
for
their
particular
homegrown,
http
client.
D
D
D
D
D
D
D
A
Yeah
well,
let's
ask
sergey
from
open
tracing
because
open
tracing
I
mean
was
very
heavy
on
the
library
instrumentation
in
that
ecosystem.
E
D
E
A
So,
just
to
I
mean
I
don't
have
any
con,
I
mean
I
just
think
we
have
to
either
say
it's
public
or
it's
not
right.
I
mean
if
we
want
to
say
it's
not
public
to
other
people
to
use,
then
we
need
to
put
it
under
a
dot
internal
package,
the
way
that
the
sdk
is
doing
for
internal
stuff,
that
is
technically
public,
but
not
allowed
for
other
people
to
use
to
allow
breaking
changes
still.
A
D
Yeah,
I
I
cannot
say
I
I
I
don't
want
it
to
be
public.
I
I'm
trying
to
because
well,
I'm
probably
somehow
baghdan's
attitude
is
a
little
bit
contagious,
I'm
currently
thinking.
If
we
declare
it
public
and
published,
then
we
have
to
support
that
for
for
a
long
time
so
before
doing
that,
it
may
probably
nice
would
be
nice
to
understand
who
and
how
is
going
to
use
that,
and
and
and
that,
for
me
in
general,
is
part
of
the
bigger
question.
How
do
we
want
or
how
do
we
envision
the
future
contributions.
D
Unfortunately,
I
don't
have,
I
don't
have
like
the
vision
right
now.
I
have
concern
that
indefinitely.
Piling
new
instrumentation
to
a
single
repo
will
end
badly
sometime
in
the
future.
If
we
are
successful
and
well,
if
not,
it
does
matter
anyway,
and
I
am
trying
to
understand
how
can
we
solve
that,
and
I
don't
know
yet.
D
A
D
D
A
So
I
don't
think
this
is
too
well.
This
is
not
too
high
priority
for
me,
at
least
because
the
java
agent
is
sort
of
like
this
convenience
mechanism,
and
if
you
really
want,
I
mean
I,
I
definitely
think
we'll
add
this
in
the
future.
D
A
A
A
If
it
was
all
just
java
agent
instrumentation,
I
wouldn't
really
care
too
much
about
you,
know
break
you
know
even
breaking
or
bumping
it
to
2-0,
because
there's
not
really,
you
know,
there's
a
there's,
not
really
that
much
downside.
You
don't
end
up
in
dependency.
Hell.
D
D
D
That
we
will
be
like
few
future
proof
regarding
metrics,
I
don't.
I
don't
believe
that.
A
Yeah
yeah,
and
certainly
we
can
always
you
know
we
can
always
just
add
new
methods
and
deprecate
old
stuff.
If
that's,
you
know,
if
we
find
that
that's
what
we
need
to
do.
Yes,.
D
A
G
I
think
the
thing
that
scares
me
the
most
about
it
is
how
would
the
interaction
of
some
instrument
or
api
interact
with
the
actual
java
agent
and
if
there's
a
version,
mismatch
like?
How
does
that
I
mean
we've
already
had
to
kind
of
jump
through
the
hoops
of
having
a
version
mismatch
with
the
actual
underlying
sdk,
but
and
there's
also
a
level
of
agreement
that
that
the
the
ap
the
sdk
is
going
to
be
stable
right.
A
A
Okay,
all
right:
well,
it
will
be
good
to
get
I'll
be.
I
look
forward
to
discussing
this
with
honorag
this
evening,
because
I
know
he
is
very
interested
in
moving
the
instrumentation
api
forward
to
stability.
A
The
main
desire
is
that
our
library
instrumentation
depends
on
this,
and
so
we
don't
want
transitively.
So
we
don't
want
people
to
end
up
in
dependency.
Hell
of
having
to
you
know
not
being
able
to
pick
versions
that
match
or
having
breaking
to
always
be
able
to
use
the
latest
instrumentation
api,
and
that
will
work.
G
So,
but
what
I'm
saying
is
like
if,
if
all
of
the
instrumentation
is
bundled
into
the
same
repo,
then
we
can
expect
that
they
should
all
share
common
release
attributes
and
that
I
mean
it's
like
any
library.
If
you
pick
two
different
versions
that
are
inherently
incompatible,
then
that's
on
you.
B
Right
with
those,
obviously
people
can
do
whatever
they
want
right.
There's,
no,
there's
no
way
to
stop
anyone
from
doing
things
that
are
potentially
breaking,
but
what
we
do
guarantee
is
that
at
run
time
in
the
sdk
that,
if
you
use
the
bom
in
the
sdk,
you'll
get
upgraded
to
the
right
versions.
The
latest
versions
of
the
api
that
the
sdk
uses.
A
B
Well,
it
has
to
be
public
class
because
we
don't
want
to
have
everything
in
one
package,
but-
and
we
can't
actually
do
that
across
modules
anyway,
because
of
the
module
system.
So.
A
A
Yeah,
I
know
he's
planning
on
spending
some
time
on
this
going
forward.
Now
that
he's
done
with
there's
all
the
sdk
stuff
crash
has
let
up
so
it'll
be
good
to
get
somebody.
You
know
after
they've
had
some
time
to
think
about
this.
A
Obvious
anything
else.
A
I
know
I
don't
really
know
what
nikita
say
here
other
than
the
same
thing
that
when
this
has
come
up
before,
as
we
keep
kicking
it
down
the
road
until
maybe
it
becomes
so
painful
that
we're
motivated
to
do
something.
D
A
A
A
Sorry,
no,
no.
I
have
no
good
ideas
here.
D
A
All
right
we're
at
our
five
minute
five
minute
cut
off
window
here
any
any
last.