►
From YouTube: 2022-05-03 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
What's
what's
new
at
lightstep,
what's
going
on
right
now,.
A
Yeah
yeah
things
are
good.
I
am
trying
to
to
yeah
convince,
I
think,
we're
gonna,
hopefully
sort
out
our
open
internal
open,
telemetry
roadmap
a
little
bit
better.
Soon.
A
There's
always
like
this
question
about
how
quickly
should
we
move
to
adopt
to
let
open
telemetry
features?
So
that's
always
trying
to
trying
to
improve
our
roadmap
there.
A
B
Yeah
yeah,
I
find
that
we
have
a
similar
like
discussions
internally
like
when
do
we
adopt
things
because
in
the
past
we've
adopted
things
too
early
and
it's
kind
of
just
been
not
quite
stable
enough,
and
it's
really
just
hurt
us-
and
I
think
this,
like
it
kind
of
brings
us
to
here,
is
like
a
lot
of
things
can't
be
declared
stable
because
the
semantic
convention
isn't
stable
and
it
relies
on
the
semantic
convention
like,
for
example,
a
bunch
of
the
like.
B
A
Yeah
totally
and
like
there's,
like
kind
of
an
interesting
dynamic
where,
on
the
one
hand
I
like
want
lightstep
to
adopt
things
faster
because
it
it
means
there's
like
just
from
a
business
standpoint.
A
I
want
to
talk
about
them
early
as
part
of
evangelizing
open
telemetry,
and
that
would
like
be
a
lot
more
effective
for
me.
If
I
could
then
just
like
point
at
lightstep
doing
something
useful
with
those
features,
but
the
the
flip
side
is
if
it's
like
a
brand
new
thing,
then
that
means
light
step
would
be
implementing
a
feature
for
which
there
is
currently
no
source
of
data.
A
I
think
especially
around
like
the
the
metrics
stuff,
where
it's
sort
of
like
well
we're
gonna,
put
metrics
and
all
this
cool
metric
stuff
into
open
telemetry,
but
it
will
probably
be
a
fairly
like
slow
adoption
curve.
Who
knows
who
knows,
I
suspect
it
might
be
a
slow
adoption
curve
for
something
like
hotel
metrics,
because
most
people,
when
they
showed
up
like
didn't,
have
a
tracing
system.
So
you
know
they.
You
like
added,
open,
telemetry
and
you've
got
a
tracing
system,
but
most
people
are
walking
around
with
some
kind
of
metrics
implementation.
A
Already
at
least
that's
my
impression
and
so
to
adopt
hotel
metrics
might
like
is
going
to
require
either
like
adapters
to
make
it
like
just
just
easy,
tush
or
something
you
know
I
I
suspect
it's
there's,
there's
there's
an
aspect
of
like
well:
what's
broke
about
our
existing
metrics
like.
Why
should
we
bother.
B
Yeah
yeah,
no
definitely
metrics
is
a
bit
of
a
more
of
a
migration
we've
had
like
stuff
stuff
like
micrometer,
bridges
and
stuff
like
that
in
java
is
help
is
helping
us,
though,
like
same
api,
different
kind
of
output,
but.
A
Yeah,
but
my
hope
is
that
we
can
get
at
least
some
vendors,
preferably
lights
up,
but
somebody
to
start
implementing
making
use
of
things
like
metric
exemplars
yeah,
starting
to
make
use
of
the
way
that
open,
telemetry
correlates
across
all
these
different
data
streams.
Because
that's
like
to
me,
the
real
there's
like
to
me
open
telemetry,
has
two
parts:
there's
the
it's
like
a
standard,
an
open
standard
so,
like
everyone
should
adopt
it,
so
they
don't
have
to
keep
migrating
between
instrumentation
every
time
they
they
want
to
change.
A
You
know
where
they
send
the
data.
A
A
Yeah,
it's
just
this
funny
thing
where
I
think
most
companies,
if
they
were,
they
would
like
think
of
a
feature
they
wanted,
and
then
they
would
change
their
data
protocol
and
their
instrumentation
to
work
with
the
new
feature.
But
this
is
like
this
new
model
where,
on
a
certain
level,
open
telemetry
is
kind
of
inventing
not
exactly
inventing
features
but
inventing
like
better
data
than
anybody
has
seen
before.
A
That
will
then
allow
people
to
go,
build
interesting
features
that
they
maybe
didn't
think
to
build
earlier,
because
they
were
kind
of
still
stuck
in
like
everything's
siloed
mode.
So
it's
it's
kind
of
like
in
it.
There's
it's
going
to
be
like
a
bit
of
a
a
slower
roll.
I
think
at
first,
but
but
we'll
see,
I'm
I'm
intrigued,
but
we
have
to
get
it
all
finished,
speaking
of
which
it
feels
like
we're
close
to
the
finish
line.
A
I
don't
know
if
milla
can
make
it,
but
it
did
seem
like
I
went
to
the
spec
meeting
this
morning
and
there's
some
desire
for
her
pr
to
get
kind
of
broken
down
into
like
two
pr's
for
some
reason,
but
I
did
make
it
clear
to
the
the
tc
and
the
spec
group
that
this
was
like
the
last
piece
of
the
puzzle
for
us
and
can
they
they
please
like
get
this
one
in
quick
and
also
can
they
please
delay
cutting
a
release
of
the
spec
until
this
is
in?
A
We
don't
miss,
miss
a
window
for
getting
the
jump
on
on
starting
to
implement
all
this
stuff,
so
so
that
was
all
well
received.
So
my
hope
is
that
by
the
end
of
this
week,
that
stuff
will
all
be
committed
and
we'll
have
like
a
a
spec
release
like
early
next
week
and
and
we
can
get
cracking
on
on
instrumentation
she'll
feel
really
good.
B
A
Yeah
yeah,
that's
what
I
think
we
had
a
discussion.
I
wasn't
sure
if
you
were
here
for
it,
but
we
had
a
discussion
which
is
that,
even
if,
even
if
it's
not
fully
stable,
if
we've
made
all
the
changes,
we
think
we're
gonna
make
and
all
that's
left
is
you
know
convincing
the
community
to
market
stable
will
still
at
least
have
a
a
schema
version.
A
You
know
migrations.
You
know,
data
migrations
from
that
point
going
forwards,
but
also
like
when
we
do
market
stable.
I
feel,
like
the
chances
are
extremely
high
that
that
it
will
this
version
will
be
stable,
effectively
stable
because
it
wouldn't
it
wouldn't,
have
anything
different
in
it.
I
don't
think
someone
else
is
going
to
come
along
and
break
the
the
work
that
we
just
did
and
we
don't
have
any
plans.
A
A
You
can't
make
a
change
to
it
unless
you
also
provide
a
schema
migration,
and
I
would
argue
that
it
like
the
schema
migration
literally
has
to
like
be
built
as
a
prototype
is,
like
proof
not
just
like
hand
wavy,
we
could
probably
migrate
successfully,
which
means
you
know
we
have
to
have
the
the
schema
migrator
system.
Added
to
the
collector.
A
I
would
argue
like
that
that
work
should
be
completed
before
we
start
talking
about
making
changes
to
anything.
We've
marked
stable,
but
the
point
is,
if
you
can
make,
if
you
can
make
a
migration
for
it,
then
there's
a
way
for
people
to
update
to
the
newer
instrumentation,
but
not
break
their
dashboards,
and
so
far
that's
kind
of
what
we're
saying
stable
means
is
not
that
we'll
never
change
it,
but
that
will
only
change
it
in
a
way
that
you
could
translate
it
back
into
what
you
had
before
and
and
we'll
see.
A
If
that
works,
it
does
require
people
to
use
the
collector.
It
does
that's,
you
know
not
ideal,
but
I
would
also
say
that
in
general,
when
something
is
stable,
we
should
only
make
additive
changes
to
it.
You
know
the
only
reason
you
would
have
to
write
a
migrator
is,
if
you,
you
literally,
were
mutating.
What
was
you
know,
attributes
that
were
coming
out
of
it
already
or
something
like
that,
and
hopefully
something
like
that
would
be
rare
yeah.
A
Don't
think
I
think
we
want
to
like
push
back
on
doing
that
unnecessarily,
but
but
I
don't
know
that
we
want
to
like
fully
close
the
door
to
saying
you
know
if,
if
we
had
to
for
some
very
valid
reason
that
that
you
know
you
couldn't
just
tell
people
to
use
a
migrator,
but
my
hope
is,
we
won't
have
to
do
much
of
that
and
it'll
mostly
just
be
additive
changes
but
anyways.
That's
that's
the
idea
and
it's
not
they.
They
people
may
have
to
run
a
collector.
A
I
think
the
other
thing
that's
interesting
is
for
for
back
ends
to
also
potentially
look
at,
including
that
translation
process
in
the
back
end,
potentially
like,
like
the
back.
If
the
back
end
knows
what
version
of
the
data
it
is
expecting
to
power,
the
various
things
that
the
user
has
set
up,
then
the
backend
could
also
notice
when
it
was
getting
a
mismatch
and
do
the
translation
there
and
then
the
end
user
wouldn't
have
to
worry
about
it.
You
know,
I
think,
most
vendors
kind
of
do
something
like
that.
A
Internally
anyways,
you
know
whenever
they
they
update
their
their
stuff.
You
know
so
at
any
rate,
that's
that's
that's
the
idea,
but
yeah.
Hopefully
we
don't.
Hopefully
we
don't
have
to
keep
around
with
the
conventions
like
http
is
not
changing
very
quickly.
I
would
like
to
think
we
could
just
get
it
right
and
move
on,
but
I
I'm
less
certain
about
things
like
database
stuff
and
message
queues.
Things
like
that.
I
can
totally
see
us
yeah.
B
I
guess
the
next
question
would
be
what
is
the
next
section
of
the
convention
that
I
mean.
I
know
that
messaging
is
being
worked
on,
but
what
would
be
the
next
one?
Would
it
be,
would
it
be
databases,
or
would
it
be
something
like
system
like
host,
metrics
kind
of
thing
or
yeah?
It
could
be
computing.
A
I
I
would,
I
would
say
it's
kind
of
practically
speaking:
it's
it's
what
we
can
get
the
subject
matter,
experts
for
personally,
I
would
like
us
to
tackle
the
database
stuff,
especially
sql,
sooner
rather
than
later.
So,
that's
why
I'm
starting
to
like
ask
around
for
people.
A
You
know
if
there
are
like,
I,
I
think,
atlassian's
like
a
big
postgres
shop,
not
mistaken.
So
if
we'd
be
able
to
to
maybe
schedule
a
few,
there
are
some
some
willing,
postgres
operators
at
at
atlassian
who'd,
be
willing
to
like
participate
on
some
level
around
reviewing
at
least
like
reviewing
like
open,
telemetry's
instrumentation
for
postgres
and
just
coming
back
with
their
recommendations
for
what
they
like
to
see
like
if
they
want
to
fully
participate
in
the
group.
A
B
Yeah
I
had
I
had
a
quick
ask
around
before
I
didn't
get
any
bites,
but
I'll
I'll
I'll
keep
I'll
keep
looking
yeah
yeah,
maybe.
A
Something
we
can
do
as
a
group
is,
is
just
make
a
a
right.
You
know
make
a
write-up,
that's
some
things.
We've
had
success
doing
this
in
the
past.
Just
when
I've
worked
with
some
other
pms
is
basically
to
figure
out
a
way
to
make
the
ask
written
up
in
a
way
that
is,
could
be.
People
could
use
internally
right
to
bring
to
to
managers
internally.
A
So
just
we
can
think
of
a
good
way
to
to
phrase
some
of
these
resource
requests
and
just
have
like,
like
a
written
thing
that
we
can
pass
along
to
people
that
can
kind
of
help.
A
A
So
yeah,
but
I'll
start
poking
people
on
my
end,
to
see
see
who
we
can
get.
A
A
A
A
Like
the
observer
paradox,
I
think
you
can
get
into
where
database
statements
and
other
things
are
large,
and
I
do
know
people
sometimes
have
concerns
over
the
the
volume
of
telemetry,
they're
emitting,
and
so
that's
kind
of
a
question
I
have
around
stuff
like
sql
is
like
is
that?
Are
there
concerns
around
some
of
these
fields
being
useful
but
but
expensive,
essentially
to
capture
like
likewise
like
scrubbing
those
fields?
Might
some
of
this
stuff
might
be
computationally
expensive?
A
And
I
don't
know
I'm
pretty
rusty
on
what
kind
of
trade-offs
people
want
to
want
to
see
there.
B
Yeah
cool
so
essentially
we're
just
waiting
on
luke
miller's
pr,
that's,
basically
what
we're
waiting
on
and
the
spec
has
been
kind
of
poked
about
it.
A
Yeah
yeah
that
that's
that's
basically
it
and
I
think
the
next
step
is
instrumentation.
I
was
thinking.
Unfortunately,
I
was
looking
at
at
the
registry
and
we
don't
currently
have
things
tagged
instrumentation.
The
registry
isn't
tagged
currently
by
what
semantic
conventions
it
emits,
which
I
think
would
be
kind
of
nice
for
us
like.
I
can
do
a
search
for
the
word
http
and
I
get
like
a
list
of
stuff
as,
like.
You
know,
kind
of
a
starting
point,
but
maybe
just
a
spreadsheet
is
the
easiest
way
to
go.
A
So
I
can
just
really
quick
just
create
a
spreadsheet
of
http
instrumentation
so
that
we
can
just
have
a
way
to
just
keep
track
of
all
the
stuff.
That's
out
there
and
just
kind
of
divvy
it
up
and
go
to
town
on
on
getting
it
all
updated,
yeah.
So
you'd.
A
Yeah,
I'm
just
you
know,
we
have
a
very
basic
registry
and,
as
I'm,
you
know
trying
to
turn
it
into
something
useful.
This
was
like
a
thing
I
noticed
just
now.
I
was
like
what
http
instrumentation
do
we
have
and
I'm
like,
oh
well,
we
haven't
indexed
anything
in
here
like
that,
so
I
can't
really
ask
the
registry
to
to
cough
up
all
the
http
stuff
or
all
the
sql
stuff
or
all
the
db
stuff,
but
that
might
be
useful.
A
Likewise,
it
would
probably
be
useful
if
these
things
not
just
mentioned,
which
semantic
convention
they
emitted,
but
also
which
schema
version
they
were
on
the
more
of
that
information
we
can
get
into
the
registry
in
a
way
that
keeps
itself
up
to
date,
the
more
the
more
useful
the
the
registry
will
will
be
in
the
future
when
we
have
to
do
more
of
this
work.
A
B
A
In
the
in
the
registry
you
mean,
or
the
in
the
actual
instrumentation
in
the
registry
yeah,
the
registry
is
literally
just
it's
just
a
flat
file
in
the
the
the
website's
built
on
hugo
and
I'm
pretty
sure
the
the
registry
is
basically
just
a
pile
of
yaml
files
that
hangs
out
in
the
that
hugo
github
repo.
A
So
it's
it's
not.
It
is
very
dumb.
It's
very.
It
would
be
very
easy
to
manually.
Add
these
tags
to
it,
but
it
would
be
we've.
We've
discussed
whether
or
not
there
should
be
some
some
other
way
of
having
the
registry
be
updated
by
things
getting
pushed
into
it
or
it
having
a
list
of
places
where
it
goes
and
and
looks
on
some
schedule
for
information,
because
if
we're
going
to
get
back
past
anything
but
like
the
most
basic
of
information,
then
it's
just
going
to
be
this
issue
of.
A
How
do
you
keep
this
thing
up
to
date?
Yes,
so,
but
we
we
also
haven't
fully
figured
out
what
exactly
we
want
the
registry
to
be.
One
thing
it
could
be
useful
for
is
so
in
languages
where
everything
isn't
automated.
One
of
the
trickier
parts
of
installing
open
telemetry
is
just
knowing
what
instrumentation
packages
you
need
to
install
and
java.
A
It
just
automatically
does
everything,
and
there
are
some
like
scripts
python-
has
like
a
cool
script
that
will
basically
look
at
your
manifest
scan
your
manifest
for
what
libraries
you
have
installed
that
match
some
data.
You
know
database,
it
has
of
like
what
instrumentation
is
available
and
then
spits
out
like
something
you
can
paste
into
your
whatever
they
call
it
in
python,
like
your
ini
or
your
your
manifest.
A
Basically,
so
you
can
just
run
this
script
and
it'll
spit
out
paste
this
stuff
into
your
manifest,
and
you
now
have
the
instrumentation
packages.
Oh,
that
is
very
cool,
and
it
would,
I
think
I
was
thinking
it
would
be
cool
to
to
try
to
generalize
that
and
if,
if
something
needed
to
do,
that
is
a
genuine
registry,
not
just
like
a
web
page.
You
know
on
our
website,
but
like
an
actual
like
place
for
these
tools
when
they
run
to
to
query
to
get
their
list
of
available
instrumentation.
A
A
A
I've
done
a
lot
of
go
programming,
I
kind
of
like
the
language,
but
I
definitely
feel
like
the
community
is
like
sort
of
like
like
like
an
old
person
where,
if
you
like,
take
their
photograph
like
you've
stolen,
my
soul
come
come
back,
but
one
thing
that
you
can
do
in
go
is
create
like
rewrite
tools,
essentially
where
you
leave
like
a
specially
formatted
comment
and
then
so
it's
not
dynamic
at
run
time,
but
at
compile
time
you
can
write,
go
preprocessors.
A
That
will
look
at
these
comments
and
then
like
update
or
spit
out
a
blob
of
code
for
you
and
and
actually
like
go,
has
some
like
pretty
decent
code
writing
and
rewriting
tools
built
into
the
language.
A
That
code
looks
ugly,
my
god,
but
but
they
work
well,
and
so
I
was
thinking
like,
maybe
for
go
being
able
to
to
write
something
that
actually
just
oh
see,
rightly
being
able
to
write
something
that
actually
just
does.
Does
the
whole
thing
for
you
right
like
looks
at
your
open,
telemetry,
config
file,
or
whatever
looks
at
your
your
go.
Go
package
list.
A
Spits
and
then
like
writes
into
your
file
all
of
the
installation
or
setup
code,
the
degree
to
which
it
can
so
just
just
kind
of
like.
So
it's
not
like
an
agent
that
like
dynamically
binds,
but
it
is
a
thing
that
on
some
basically
like
a
temp,
automated
template
generator
that,
as
as
close
as
it
could
to
complete
just
be
like
here
here
is
all
your
setup
code
have
fun.
B
Yeah,
that's
an
interesting,
that's
an
interesting
idea.
I
like
that,
just
anything
that
will
make
it
easier
to
get
started
the
I.
I
also
did
notice
that
there
is.
If
we're
talking
about
go.
There
is
a.
It
seems
like
there's
a
new
thing
going
on
in
the
go
world
where
they
are
using
ebpf
or
something
to
make
something
similar
to
an
agent
in
go,
which
is
which
is
an
interesting
project
too.
A
Yeah
I
haven't
been
following
that
too
closely.
I
know
I
think
dinah
trace
had
like
a
go
agent
thing,
but
when
I
looked
at
it,
it
looked
very
sus
to
me.
You
know
like
like
it
had.
B
A
B
A
A
I'm
I'm
curious
how
what
the
limitations
or
downsides
for
it
are,
you
know:
does
it
set
up
context
propagation
properly
like
what
does
it
do,
but
but
yeah
it's
really
cool.
A
If,
if
this
ends
up
being
like
the
way
to
do
it
and
go,
I
think
that
would
be
awesome
in
general,
these,
like
modern
languages
that
are
still
under
heavy
active
development.
I
have
some
hopes
after
we're
stable,
that
we
could
start
going
to
the
language
developers
and,
to
some
degree
start
seeing
if
we
could
get
more
like
runtime
level
integration
for
for
some
of
this
stuff.
A
You
know,
I
don't
know
exactly
what
that
means,
but
you
know
the
the
the
other
approach.
Besides
monkey
patch
instrumentation
like
this,
this
thing
is
just
to
have.
Like
actual
you
know,
language
support
or,
like
you
know,
hotel
instrumentation
just
baked
into
go
http
rather
than
rather
than
like
some
instrumentation
package.
You
have
to
remember
to
install
like
if
they
just
like,
stick
it
directly
into
the
library,
then
then
we're
done
and
in
general
that's
that's
the
direction.
A
A
But
I
I
haven't
really
been
pushing
on
that
until
we
truly
get
everything
stable,
because
I
think
I
think
those
people
will
would
get
mad
at
me
if
we
convinced
them
to
do
that
and
then
broke
something
on
them.
B
I
don't
know
I
noticed
that
josh
ceruth
is
back.
I
wonder
if,
at
some
stage,
he'd
be
interested
in
getting
involved
in
semantic
convention
stuff.
That
was
just
the
only
other
thing.
A
A
Enough
yeah
yeah,
but
yeah
he
is,
he
is
interested
in
in
getting
instrumentation
and
all
that
stuff
stabilized
so
hopefully,
they'll
be
able
to
to
provide
some
support
for
the
database
stuff
but
yeah.
I
guess
I
guess
this.
A
The
takeaways
from
this
meeting
are
you
know
if
people
can,
you
know,
get
some
ideally
some
work
time,
if
possible,
penciled
out
to
to
actually
like
migrate
some
of
this
instrumentation,
if
possible
and
also
you
know
the
ask
around
to
see
about
getting
subject
matter
experts
for
any
other
semantic
conventions
they
want
to
hit
up
next,
I
think
sequel
would
be
a
great
one
to
hit
up,
but
if
people
are
like
really
ready
to
go
with
one
of
the
other
ones,
we
can
we
can
get
cracking
on.
A
B
B
Yeah,
there's
there's
kind
of
nothing
being
done
in
the
metrics
semantic
well,
in
terms
of
it
doesn't
even
have
yaml
files
yeah.
That's
that's
one
of
the
things
I'm
trying
to
add
in
like
is
that
yeah
yeah
stuff
great?
I
just
need
someone
from
metrics
to
review
that.
Actually,
maybe
I
should
get
riley
to
review
that.
A
Yeah,
yes,
he
would
be
the
right
person
for
that.
I
don't.
Is
there
any
update
on
the
the
schema
processor?
Well,
yeah
it
got
merged.
I
think
yesterday
I
did.
A
That's
good
yeah
yeah,
all
right,
we'll
we're
finally
like
unblocked
on
a
lot
of
fronts.
So
it's
that's
good,
but
but
now
I
think
it's
going
to
be
then
back
boomeranging
back
to
us
to
now
keep
keep
the
pace
up
if
we
want
to
get
the
rest
of
this
stuff
rest
this
stuff
over
the
finish
line.
B
A
And
I
know
they
were
they're
working
on
defining
semantic
conventions
for
like
the
java
runtime,
that's
maybe
another
area.
Besides
system
metrics-
and
you
know
library,
library
instrumentation
is
a
runtime
instrumentation
from
all
the
the
other,
various
runtimes
like
python
and
ruby,
and
no
even.
B
Yeah
that'll
be
that'll,
be
interesting.
Yeah,
cool
yeah.