►
From YouTube: 2022-02-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
Okay,
let's
start
so,
I've
put
the
first
item
there.
It's
a
pull
request
to
remove,
remove
the
or
deprecate
the
log
name
field
in
the
in
the
otlp,
the
proto,
it's
already
removed
from
the
specification,
and
I
also
started
removal
in
the
collector
so
and
we
just
needed
to
to
be
also
deprecated
in
the
proto.
I'm
replicating
it
for
now,
we'll
give
it
a
bit
more
time
for
the
cleanup
to
happen
everywhere
and
then
it
will
be
removed.
A
A
C
Think,
okay,
so
just
a
couple
quick
things
on
the
log
collection,
library,
the
first
one
field,
syntax
change,
so
this
pr
has
already
been
reviewed
by
quite
a
number
of
folks
and
seems
seems
to
be
well
received.
So,
first
of
all,
if
you
want
to
take
a
look,
please
do
now
or
soon,
but
I
think
I
have
a
question
on
this,
though
this
is,
I
think,
the
first
of
what
will
be
a
series
of
breaking
changes.
C
C
C
Observed
time
stamp
is
a
notable
one.
I've
proposed
some
changes
to
the
way
parsers
work
in
terms
of
their
default
behavior,
mainly
that
they'll
be
non-destructive
when
they
parse
and
that
by
default,
they'll
parse,
two
attributes
instead
of
to
body.
So
that's
probably
the
biggest
breaking
change.
I
anticipate
here
and
then
there
are
a
couple
of
very
minor
things
like
the
file
input
operator,
puts
some
attributes
on
logs
that
are
no
longer
well.
There
are
no
semantic
conventions
for
those
attributes
and
they
don't
match
so
there'll
be
a
small
change.
There.
A
So
for
the
changes
that
we
already
know
that
we
know
for
sure
that
they
will
be
happening
like
the
observed,
timestamp
and
then
the
log
name
removal,
maybe
maybe,
would
touch
this
the
others
they
may
need
to
to
be
discussed
right.
Maybe
we
need
to
do
some
design
reviews
and
it's
not
a
given
that
they
will
be.
A
They
will
exactly
happen
in
the
way
that
you
think
that
they
will
happen.
They
may
also
take
quite
some
time
before
we
make
a
decision
about
how
we
go
about
those.
I
don't
think
we
should
be
delaying
this
right.
What
what
we
have
now
like,
like
it's
going
to
be
a
very
large
batch
and
probably
delayed
by
a
few
months.
A
Okay,
I'm
good
with
that.
Those
are
also
quite
unrelated
to
each
other
right.
There's,
no
interconnection
there,
no
interplay
there!
So
we're
not
we're
not
actually
simplifying
the
life
of
the
the
user
by
batching
those
changes
together.
I
don't
think
so.
It's
they
are.
Quite
unrelated,
they
need
to
deal
with
each
one
of
those
changes
if
they
are
affected
separately.
A
C
Yeah
yeah
yeah,
okay.
I
think
it
makes
sense.
C
All
right,
the
other
item,
so
I
pulled
up
this
issue
quite
a
while
back.
You
know.
The
original
stanza
contribution
had
a
notion
of
resources
and
attributes,
but
both
of
these
were
supported.
As
map
string
string,
I
think
we've
well
established
that
attributes
is
going
to
support
structured
values.
C
But
when
I
wrote
up
this
issue,
I
was
kind
of
thinking
that
resource
also
needed
to
support
this
in
the
data
model,
it
does
specify
resource
as
map
string
any,
but
I
think
practically
speaking
here,
I
don't
I'm
not
aware
of
any
actual
use
case
for
resource
to
be
structured,
and
I
think
all
of
the
semantic
conventions
that
I'm
aware
of
in
general
are
basically
still
map
string
string
and
that
it's
just
that
the
the
key
is
a
string
that
essentially
implies
structure
but
doesn't
actually
have
doesn't
require
that
there's
like
a
nested
structure
to
it.
C
So
I
just
wanted
to
run
this
by
everyone
is
this.
Does
everyone
think
this
is
a
correct?
Interpretation
of
the
changes
should
be
made
there
that
it's
only
the
attributes
that
should
be
given
structure.
D
A
E
Thanks
yeah,
I
I
recall
that
few
months
ago
I
was
making
this
pr
about
naming
attributes-
plural
in
case
there
might
be
an
array.
But
when
I
was
looking
for
examples,
I
think
we
had
two
two
cases
back
then
so
it
was
like
really
not
very
common,
but
I
still
gonna
note
that
yeah
we
have
those.
B
A
Okay,
who
has
the
next
item
log
name
and
block
type.
B
That's
that's
me
just
I
saw
that
you're
looking
at
removing
log
name,
and
I
was
coming
in
to
say
that
for
both
span
events
and
rum
events,
having
that
name
field,
there
seems
pretty
critical.
B
A
It's
already
removed.
First
of
all,
we
went
already
through
multiple
rounds
of
discussing
it
and
it's
removed.
It's
not
in
the
specification
anymore.
The
I
guess,
with
regards
to
ram
with
how
ram
might
be
using
this,
the
the.
A
B
So
the
the
problem
with
using
a
dedicated
attribute
is,
is
efficiency
right,
it's
the
same
as
span
name
you
you
have.
When
you
have
events,
you
have
a
primary
index
that
you're
going
to
be
using
to
compare
all
of
these
events
against
right,
like
so.
The
same
way
like
span
name
is
pulled
out
into
like
a
top
level
field.
B
It
seems
like
event.
Name
should
be,
should
be
treated
the
same
and
have
the
same
semantics
as
the
span
name.
This
is
also
like
span.
Events
are
another
example
of
an
event
type
where,
where
you
have
a
name
that
you're
using
as
a
primary
index,
I
wasn't
aware
that
it
was
already
removed.
I
thought
I
thought
the
debate
was
whether
or
not
to
remove
it.
Maybe.
A
I
don't
know
if
you
want
to
to
to
bring
that
up
again.
We
need
to
start
from
the
specification
again,
but
I
I
would.
I
would
highly
highly
prefer
that
we
don't
do
that
like
if
there
was
a
decision.
I
wouldn't
want
to
revert
that
decision.
Unless
there
are
very
good
arguments,
I
mean
that's
fine.
If
you
have
good
arguments
that
we're
not
yeah
part
of
the
original
discussion,
then
that's
that's!
That's
okay.
We
can
do.
B
Well,
I
can,
I
guess
I
can
go,
try
to
review
some
of
the
original
discussions,
but
I
do
feel
like
just
from
talking
to
this
group
briefly
things
like
figuring
out
how
to
handle
spam
events
weren't
brought
up
as
part
of
that
the
the
rum
stuff
was
was
in
a
pretty
rough
state
until,
like
the
past
couple
of
weeks,
as
far
as
just
figuring
out,
what
it
is
we
want
to
need
is
like
people
in
that
group
kind
of
got
up
to
speed
with
what
open
telemetry
currently
has
so
yeah.
A
I
think
it's
fine
ted,
if
you
want
to,
if
you
want
to
open
that
discussion
again,
it's
fine
yeah,
it's
an
it's
going
to
be
an
additive
change
right.
It's
not
a
breaking
change.
What
we
wouldn't
we
didn't
want
to
happen
is
that
we
found
that
the
log
name
is
not
necessary,
but
we
cannot
remove
it
anymore,
because
that
would
be
a
break
exchange
totally
now.
B
A
A
But
please
please
do
go,
read
the
the
discussion
like
that
there
were
multiple
like
I.
I
can
give
you
the
links
to
the
issue
and
to
the
pr's
there
are.
There
were
multiple
pr's
even
around
this,
and
maybe
they
answer
your
questions.
Maybe
they
don't
and
if
they
don't,
then
please
submit
another
or
reopen
the
issue
or
submit
a
new
issue
and
and
we
can
discuss
it.
B
Yeah
yeah
I'm
happy
to
to
research
the
prior
discussion
before
wasting
a
year.
All's
time
on
it
and
again
I
do
apologize
for
you
know
being
late
to
the
party.
A
B
F
F
B
D
Can
I
can
I
jump
in
so
ted
at
some
point,
you
said
event
name
you
know
in
in
when
you
were
talking.
I
was
wondering
whether
that
was
a
a
slip
or
a
freudian
slip,
or
you
know
you
know.
One
of
my
shortcomings
is
that
I
don't
really
have
a
ton
of
visibility
into
some
of
the
other
sort
of
strains
of
open,
telemetry
and
then
how
people
think
about
you
know
things
on
the
tracing
side
on
a
metric
side.
D
B
Yeah
yeah,
I
guess
to
to
my
mind.
Actually
the
only
difference
between
a
log
and
event
is.
Is
this
name
field
essentially,
but
the
the
things
we're
we're
looking
at
using
it
for
are
all
currently
called
events
and
going
forward
we'd
like
to
use
the
logging
data
stream
as
the
place
to
to
put
them,
because
you
know
the
case
of
span.
B
Events
like
they're
they're,
clearly
things
that
it's
it's
just
obnoxious
to
have
for,
for
the
end
users
to
have
some
of
them
in
another
spot
going
forwards,
except
for
some
backwards
compatibility
reasons
and
yada
yada
and
then
likewise
with
rum,
you
know
creating
a
whole
new,
separate
data
stream
for
for
ui
events,
just
seemed
just
seemed
like
overkill
and
what's
been
designed
here
seems
like
it.
Works
works
just
fine,
but
yeah.
I
guess
in
a
way.
Maybe
my
proposal
is,
does
have
like
a
big
sounding
thing
of
like
this
shouldn't
just
be
logs.
B
This
should
be
events
before
I
don't
know
what.
A
Before
we
try
to
do
that,
please
see
that
the
the
current
specification
of
the
logs
says
that
the
events
and
loads
are
the
same
thing
right.
So
if
you
want
to
deviate
from
that,
that's
that's
also.
That
contradicts
with
what
we
have
in
the
specification
right.
So
we
need
to
define
what
what
exactly
is
the
difference
in
that
case.
B
B
It
would
just
be
that
an
event
like
to
to
me
the
only
difference
between
an
event
and
a
log
is
that,
with
events,
you
are
trying
to
do
aggregate
analysis
across
all
of
the
same
event
right
versus
application
logs,
where
you
you,
may
you
may
or
may
not
be
doing
that,
but
that's
not
like
the
the
primary
purpose
of
an
application
log
to
to
me,
but
again
it's
I
think
it's
like
very
fuzzy,
which
is
why
I
don't
I
I'm
fine
calling
them
all
logs
or
calling
them
all
events
or
something
I
I
strongly
prefer.
B
C
D
Means
that
we
need
like
that,
this
needs
to
be
basically
a
global,
replace
of
logs
to
events.
I
don't
know,
probably
not
right
now,
but
you
know,
given
all
the
history
that's
here,
but
I
agree
with
you
that,
like
you
know
the
longer,
we
are
doing
these
things.
The
more
this
all
looks
like
just
events
and
that
that's
really
the
super
class
right
and
from
so
I
I
totally
get
it
and-
and
I
I
think
this
this
model
is
like
flexible
enough,
so
I
I
think
it's
great
yeah.
B
Yeah,
the
the
only
other
thing
I
just
wanted
to
maybe
footnote.
I
don't
know
if
there's
been
a
discussion
here
yet,
but
this
has
come
up
in
the
rum
sig,
which
is
you
know,
we'd
like
to
use
logs
as
we're
also
going
to
use
spans
to
model
some
some
user
interactions.
B
But
there's
there
are
plenty
of
gui
events
that
they're
clearly
just
events,
but
they
are
a
little
different
from
application
logs,
just
in
the
sense
that
they're
gui
events-
and
you
would
want
to
funnel
all
of
these
into
like
a
rum
analysis
tool-
and
they
may
also
count
as
noise
potentially
if
you
were
shoving
them
into
an
application
logging
tool,
yeah
you'd,
because
there'd
be
so
many
of
them,
yeah
right
and
so
the
other
field
we
were
thinking
about
wanted
to
propose
here
would
be
like
a
type
field.
B
B
So
the
the
express
purpose
of
this
field,
the
value
in
this
field-
would
be
kind
of
the
intention
of
being
able
to
take
something
like
gui
events
and
give
them
give
them
a
label
so
that
you
could
easily
easily
filter
them
out
or
or
grab
them
depending
on
what
you
were
trying
to
do.
So
I
don't
mean
type
as
in
like
this
is
a
tcp
handshake
event
type
I
mean
you
know.
This
is
a.
This
is
a
this
is
a
gui
event
versus
an
application
log.
G
Yeah,
it's
a
classification
of
the
of
the
name
of
the
event,
so
I'm
glad
you
brought
that
up.
That's
the
strongest
argument
for
me
in
terms
of
getting
rid
of
the
name
field,
is
that
the
name
field
by
itself
isn't
particularly
useful
because
back
ends.
G
They'd
want
to
be
able
to
filter
off
portions
of
the
the
log
stream
for
different
types
of
processing
based
on
categories
of
event
names,
so
so
a
type
is
kind
of
necessary
with
that
for
it
to
be
useful,
I
think
the
attribute
solution
is
better
than
having
two
top
level
name
fields
or
potentially,
I
think
they're,
probably
apples
that,
like
they're
on
the
same
they're
about
the
same
in
terms
of
usefulness
but
like
if
you
have
an
attribute
whose
key
is
something
like
realm
event
and
whose
value
is
the
name
of
the
event,
then
you,
your
backend,
can
use
the
presence
of
that
key
to
filter
off
data
to
have
you
know
from
event
specific
processing
so
that
you
know,
based
on
the
presence
of
the
key.
G
Instead
of
you
know,
looking
at
both
the
type
and
and
the
name
values.
A
G
A
How
we
solve
the
other,
the
other
classification
problems-
the
semantic
conventions
solve
this
by
the
fact
of
the
presence
of
a
particular
attribute
right.
The
presence
of
it
indicates
that
the
event
or
the
span
or
the
resource
belongs
to
a
particular
class
with
the
additional
benefit,
because
of
using
the
attributes
being
that
you
can
have
unlimited
number
of
dimensions
across
which
you
can
do
the
classification,
whereas
if
it's
a
field,
you're
limited
to
a
particular
single
or
maybe
two
different,
two
dimensions
but
you're
still
limited
to
whatever
you
think
are
the
way
to
classify
things.
A
H
No,
it's
good,
I
was
gonna
say
like
the
only
thing
I
would
add
is
like
we
currently
have
span
events
and
they
have
the
name
field
in
the
data
model
right
it's
like.
If-
and
I
don't
know
if
this
is
the
case,
but
if
the
long-term
vision
is
to
replace
spam
events
with
with
logs
like
what
would
happen
with
the
name
field
on
on
the
span,
events.
A
B
And-
and
for
me,
it's
actually
it's
just
so
the
only
nuance
here
for
why
I
would
argue
for
any
of
these
things
to
be
a
field,
and
it's
true,
actually,
maybe
name
isn't
in
this
category.
I
just
I'm
suspicious
that
it
is
because
it's
the
case
with
spans
in
trace
processing,
but
you
often
have
in
your
data
processing
pipeline.
B
B
Switching
so
it's
true,
maybe
name,
is
something
in
the
case
where,
by
the
time
you're
you're
getting
to
name
you're,
trying
to
look
at
all
of
these
attributes
to
figure
out
the
kind
of
indexing
you
want
to
do,
but
for
this
category
field
that
that's
a
place
where
that
this
would
be
happening
earlier
on
in
some
kind
of
like
front-end
proxy,
almost
or
something
like
that
right,
where
you're
trying
to
very
efficiently
funnel
this
stuff
out,
does
that?
Does
that
make
sense.
A
Theory,
you're
right
in
theory,
you're
right
in
practice.
I
think
it
would
be
very
difficult
to
demonstrate
significant
difference
in
the
performance
because
you
already
have
to
deserialize
the
protobufs,
whether
it's
the
top
level
field
there
or
it's
another
lookup
in
the
attributes.
A
In
the
grand
scheme
of
things
of
what
you're
doing
there
with
serialization
deceleration,
I
suspect
it's
going
to
be
insignificant
impact
of
the
performance
of
putting
that
into
india
attributes.
I
may
be
wrong.
Maybe
it's
worth
benchmarking
to
see
how
significant
the
difference
is.
Well,
that's
my
gut
feeling
that
it's
going
to
be
negligible.
G
And
to
add
to
that
a
bit,
so
you
know
that
kind
of
presumes
that
you
can
look
at
the
bites
of
a
protobuf
and
get
to
a
certain
point
and
not
necessarily
scan
all
of
them
in
short
circuit
and
exit
early
based
on
the
presence
of
you
know
some
field,
I'm
not
sure
how
reasonable
that
is.
But
you
know,
even
if
that
is
reasonable.
B
Yeah
totally
fair
and
the
way
that
sounds
good.
A
The
way
that
we
would
be
doing
that
today
is
by
using
the
open,
telemetry
collector.
There
is
an
attributes
processor.
You
would
use
that
to
look
at
the
value
of
a
particular
attribute
and
do
something
drop.
It
reduct
it
route
it
somewhere
else.
That's
how
you
do
it
today,
having
some
sort
of
partial
deserializer
that
looks
at
the
the
top
level
field,
somehow
in
a
more
efficient
way.
In
theory,
it
sounds
interesting
in
practice
who
would
be
doing
that
right
like?
Where
is
the
software
that
does
it
today?
Yeah?
I
don't
know.
B
Well,
I
think
I
totally
agree
that
any
our
any
design
decision
being
made
in
the
name
of
optimization
needs
to
come
with
some
like
practical
proof,
so
I
think
yeah.
This
is
the
thing
I
can
take
it
back
to
lightstep
martin,
you
might
wanna
just
have
a
look
at
whether
that's
that's
going
to
be
necessary
for
for
you
guys
but
yeah.
That's
the
only
reason
why
I
would
put
it
as
a
top-level
field,
otherwise
yeah
there's
no
there's
no
reason.
B
All
of
these
things
can't
be
attributes,
but,
but
I
do,
I
will
say
that,
like
I
do
think
those
those
are
valid
design
requirements
when,
when
we're
designing
our
data
structures,
we
do
need
to
to
think
a
bit
about
how
they're
going
to
be
used,
but.
A
B
And
so
yeah,
I'm
happy
if
I
can't
come
back
with
with
that,
then
I'm
I'm
personally
totally
fine
with
this,
these
just
being
semantic
attributes.
That
was
really
the
only
reason
why
I
was
I
was
bringing
it
up,
but
my
instinct
is
that
it
is
useful
because
that's
why
they've
been
made
fields
in
the
past,
but
I
could
be
completely
wrong
about
that.
Maybe
that's
just
just
because
they
were
seen
as
part
of
the
core
design
of
these
things,
so
they
were
pulled
out
into
fields.
D
Click
on
you
seem
to
have
written
an
article
on
partial
decoding
of
protocol
buffers
I
have,
but
we're
not
using
that.
A
D
About
the
article
right,
no,
that's,
okay!
I
understand
that,
like
you
know,
from
the
sort
of
from
the
from
the
from
the
spec
perspective,
this
is
a
physical
concern.
Basically,
you
know
a
logical
concern
right.
I
guess
this
would
be
one
way
to
frame
it,
but
you
know
I
like
when,
as
ted
was
spelling
it
out
it.
Certainly
it
certainly,
you
know,
triggered
a
couple
thoughts
in
mind
from
you
know
the
dispatch
on
the
back
in
perspective
and
all
that,
but
but
yeah.
C
D
B
Yeah
yeah
yeah
and
I'm
I'm
happy
to
to
limit
it
to
just
the
you
know,
putting
the
efficiency
aside,
there's
still
the
semantic
questions
around
things.
Like
the
name
field,
I'm
happy
to
tackle
those
regardless.
B
I
do
think
there's
a
thing
jack
mentioned.
We
don't
have
to
dig
into
it
too
much
right
now,
but
there
is
this,
this
kind
of
back
and
forth.
We
do
with
our
data
modeling
and
open
telemetry
around.
Do
we
include
dispatch
fields
for
switching
or
do
we
do
sniffing
of
required
semantic
attributes,
and
I
I
tend
to
to
come
down
on
the
side
jack
proposed
of.
B
Like
you
know,
things
should
be
described
by
like
the
chunk
of
semantic
attributes
they
have,
but
there
are
some
situations
where,
where
that
that
that
can
get
again
inefficient
because
you're
having
to
do
a
whole
bunch
of
checking
a
whole
bunch
of
different,
the
presence
of
a
whole
bunch
of
different
keys,
and-
and
I
wonder,
if
that's
a
thing
that
gets
overwhelming
past
a
certain
point
or
not,
but
the
the
only
other
thing
tricky
there
is.
B
It
feels
a
little
weird
because
you're
you're,
just
presuming,
there's
gonna,
be
a
required
key
that
you
could
use
to
identify
the
presence
of
a
of
a
semantic
class
like
yeah.
If
that
makes
sense
like,
like
we
don't
label
these
things
as
being
with
their
semantic
name
space.
A
The
specification
doesn't
say
explicitly,
but
I
think
the
way
that
we
treated
the
semantic
conventions,
I
think
implicitly
that
was
assumed
right-
that
there
would
be
will
be
in
the
set
of
the
semantic
conventions
about
the
particular
concept.
One
of
those
at
least
is
required,
which
which
allows
you
to
sniff
on
it
right
to
understand
whether
it's
present
or
not.
That
was
my
operating
mode,
at
least
for
for
a
long
while
at
all
inflammatory-
and
I
think
it's
worth-
maybe
adding
some
sort
of
clarification
or
some
sort
of
guidelines.
Yeah.
B
Yeah,
I
I
would,
I
think
I
would
like
that
like
I
do.
I
think
it's
a
thing
I
have
been
running
into
more
and
more
lately.
This
is
coming
up
with
links
and
like
managing
async
workloads.
In
some
of
these
things
is,
we
do
have
some
concepts
that
are
related
to
how
we
expect
our
data
to
be
used,
but
we
don't
write.
We
don't
write
any
of
that
stuff
down.
B
We
tend
not
to
write
down
that
stuff
in
the
spec
and
as
we're
becoming
more
mature,
I'm
feeling
more
and
more
like
we
probably
should
write
some
of
that
stuff
down
and
we've
kind
of
been
getting
away
with
it,
because
a
lot
of
the
things
we've
been
modeling
are
like
old
concepts.
B
That
would
be
helpful
it's
this
is
this
matters
way
more
with
links
than
with
with
this
attribute
sniffing,
but
I
think
it's
another
case
where
it'll
be
helpful.