►
From YouTube: 2021-06-08 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
B
Hey
hey,
I
think
we
can
start
now.
It's
four
minutes
past
start
time.
So
thanks
for
joining,
as
usually
don't
forget
to
add
yourselves
to
the
agenda.
B
So
yes,
first
of
all,
there
are
no
new
issues
to
triage,
so
we
are
cool
on
that
side
and
then
some
issues
that
I
put
together,
not
all
of
them
are
mine,
but
I
think
they
serve
some
attention.
B
This
first
one
is
about
splitting
out
grpc
versus
the
http
endpoint,
specifically
on
the
on
whether
it's
safe
or
not
safe
protocol.
I
don't
know
we
don't
have
people
who
have
been
discussing
that
year
here
in
the
code.
I
think
adam,
are
you
around?
Maybe.
B
He's
not,
but
please
pay
attention
to
that,
one
that
has
been
standing.
We
need
more
reviews
on
that
one,
the
next
one,
the
next
two
ones
are
related
to
otlp,
specifically
general
questions.
The
first
one
is
whether
we
should
discard
an
entire
set
of
partially
bad
data.
B
I
don't,
I
don't
think
we
can
discuss,
or
we
should
discuss
that
here,
but
please
pay
attention
to
that.
I
have
no
opinion
on
that
one.
Yet
the
second
one
is
similar.
It's
about
defining
more
specific
retry
logic
for
the
otl
exporters.
I
think
that
it's
not
very
well
defined
anywhere,
yet
yeah.
So
basically
that's
a
total
to
do
any
comments.
B
A
I
replied
to
the
first
one.
I
think
it's
a
reasonable
request,
but
it
requires
an
authentic
because
the
changes.
Well,
we
need
to
do
that
carefully
to
make
sure
that
it's
backwards
compatible.
B
Yeah
yeah
yeah,
out
of
curiosity,
how
complicated
you
think
you
could
get
with
the
first
one
regarding
handling
partially
bad
data.
A
Well,
it
shouldn't
be
very
complicated.
We
need
to
define
how
the
what
the
response
should
look
like
how
it
describes
what
portion
of
the
data
is
wrong
and
there
we
need
to
decide
how
granular
we
want
to
be
right.
Is
it
one
of
the
one
of
the
elements
of
the
top
level
slice
or
we
want
to
go
deeper?
You
probably
know
and
then
just
make
sure
that
the
existing
existing
senders
don't
get
confused
by
a
response
like
that,
so
that
it's
fully
backwards
compatible.
A
B
Okay,
perfect
yeah.
Well,
let's
just
follow
up
on
that
one.
Thank
you
for
that.
Okay,
very
good.
The
next
one
is
regarding
semantic
conventions.
There's
there
there's
a
standing
pr
regarding
function
as
a
service.
We
need
more
eyes
by
the
way.
So
if
you
know
anybody
who
has
experience
with
this
in
your
in
your
company,
please
bring
that
person
in,
but
there's
a
specific
question
that
I
have
been
wondering
about,
and
it's
about.
B
Somebody
asked
there
what
about
duplication
of
data
when
you
have
some
attribute
on
a
span
or
a
metric,
and
then
you
also
have
that
on
resource
and
whether
we
should
provide
any
guidance
there.
I
know
ted
you're
in
the
call.
So
probably
that's
something
for
you
to
jump
in
in
the
in
the
near
future.
I
think
that
there's
the
interest
in
the
semantic
conventions
and
instrumentation
stability
effort.
So
probably
that's
probably
for
you
to
pay
attention
to
this
one
in
the
in
the.
A
A
C
Answers
these
questions
it
in
general.
It
feels
a
little
awkward,
the
way
the
conventions
end
up
buried
in
the
different
parts
of
the
spec
it
I
feel
like
when
we
tackle
the
conventions
in
a
bigger
way.
Maybe
some
house
cleaning
pulling
them
out.
D
C
Yeah,
I'm
tempted
to
say
that
it's
almost
that
there's
like
suggested
places
to
use
them,
but
there's
no
wrong
place,
necessarily
the
conventions
or
conventions
and
possibly
we
have
more
specific
notes
around
traces
in
other
areas.
For
example
like
span
structure
and
things
like
that.
But.
A
We
should
have
a
single
directory
of
conventions
and
where
it
matters,
we
just
specifically
label
the
convention
to
be
applicable
to
the
particular
signal
and
call
out
what
are
the
specifics
if
it's
applicable
to
more
than
one
signal.
But
there
are
specifics
when
you
record,
for
example,
for
traces.
What
are
those
specifics,
but
I
feel
like
a
significant
portion
of
the
conventions
that
we
have
are
applicable
to
many
many
signals,
not
just
one
so
we're
with
the
current
structure,
we're
essentially
forced
to
duplicate
this
information
in
multiple
places.
D
Can
do
I
want
to
call
it
one
thing
around
semantic
conventions
and
like
resources
and
labels,
and
that
is
in
metrics
labels
or
sorry
attributes
and
resources,
attributes
and
metric
attributes
all
create
different
actual
time
stream
series
things
right
and
so
like
adding
new
labels
is
totally
different
in
the
metrics
world
than
it
is
in
traces
and
in
logs,
because
the
actual
identity
of
that
series
can
change.
D
When
you
add
labels-
and
so
there's
this
interesting
thing
that
I'm
seeing
now,
where
we're
adding
all
of
these,
like
optional
semantic
conventions
and
from
a
metric
standpoint.
That
has
me
really
concerned
with
how
we're
kind
of
treating
that.
So
I
want
to
call
that
out
as
like
a
I,
I
think
we
need
to
this
whole
like
should
I
make
a
label
and
a
resource,
or
should
I
make
it
in
the
trace
or
event
there's
this
also?
This
is
this
notion
of
identity
for
metrics.
D
That
matters
of
you
know
is
this
metric
stream
the
same
as
another
metric
stream,
and
that
is
not
the
case
for
events
and
logs,
and
that
could
also
correlate
to
this
question
of.
D
Should
I
make
something
be
a
attribute
of
an
event:
that's
common
across
logs
and
traces,
or
should
I
make
it
be
a
resource,
so
I
have
two
oteps
out
that
are
not
well
worded
and
I'll
try
to
make
them
better
kind
of
around
this
resource
issue
with
metrics,
and
I
think
this
is
something
we
do
need
to
dive
into
and
resolve
relatively
quickly,
not
just
getting
the
semantic
conventions
in
a
common
spot,
but
kind
of
understanding
the
implications
across
the
signals
of
the
semantic
conventions,
because
I
think
it's
different.
F
C
Though
I
would,
I
would
just
actually
say
it's
probably
less
different
josh
as
soon
as
you
start
thinking
about
making
metrics
out
of
span
attributes-
and
you
know
counting
log
events
and
things
like
that.
I
think
the
the
schema
proposal
that
tiegrin
put
in
is
like
a
good
scaffolding.
C
What
isn't
answered
from
the
current
otep
is
from
a
practical
standpoint,
how
how
do
we
manage
this
kind
of
versioning
going
forwards,
given
that
it's
not
that
everything
in
someone's
deployment
versions
with
the
spec,
and
it's
not
that
every
single
thing
that
they
deployed
at
one
point
needs
to
be
locked
at
that
version.
So
I
think,
there's
still
like
some
practical
work
to
be
done
around
schema
translations
in
the
collector
and
and
how
we
report
things
and
deal
with
all
that.
D
Yeah
yeah-
and
I
I
I
do-
I
will
admit
that
at
least
one
of
them
needs
to
get
a
lot
more
love
before
I
would
read
it
given,
given
the
feedback
I
have
so
far,
but
I'll
post,
both
of
them
in
the
I'll
put
it
as
a
potential
discussion
item
or
something
I'll
get
to
that
right
now,.
C
And
I'll
I'll
spare
everyone,
my
spaghetti
at
the
wall
solutions
right
now.
B
C
B
All
right
very
much,
thank
you
so
much
for
that.
Okay,
the
next
one,
is
something
I
am
not
sure
it's
important,
but
I
just
wanted
to
get
it
out
there
to
see
the
weather
there's
appetite
for
this.
This
is
regarding
the
effort
about
passing
a
resource
instance
to
samplers.
B
Basically,
we
have
a
pair
of
pr
related
to
this
one.
B
Probably
the
most
important
one
is
the
second
one
that
I
listed
there,
which
is
whether
samplers
should
be
associated
with
a
single
tracer
provider
and
work
done
proposal
at
the
time
I,
which
we
kind
of
agree
on-
and
I
still
do-
is
that
each
specific
number
should
have
its
own
specific
requirements.
B
However,
there
was
no
agreement
on
the
issue,
so
we
couldn't
close
that.
So
please
review
that
if
you
have
time
your
appetite,
the
second
one
is
related
to
this,
and
it's
and
it's
an
old
one
by
the
way
and
it's
whether
processor
and
exporters
should
receive
or
not
resource,
we
put
it
in
the
backlog,
but
probably
we
will.
We
should
decide
whether
this
is
important
enough
to
work
on
or
we
should
close
it.
B
I
I
have
no
opinion
on
that
so
far,
but
I
think
it's
important
to
mention
this
again.
I
think
bogdan.
You
have
a
specific
opinion
about
this.
One
on
whether
processor
and
exporter
instances
should
or
shouldn't
receive
a
resource.
G
B
Make
sense
to
me
yeah,
okay,
since
I
think
christine
is
not
around
no,
so
let's,
let's
go
back
to
those
issues
and
commend
there
more
yeah.
If
you
guys
are
interested,
please
please
put
a
comment
there.
I
think
it's!
B
It's
not
super
urgent,
but
you
know
this
is
something
that
has
been
there
in
the
backlog
for
some
time.
So
if
you
have
time
and
interest,
please
take
a
shot
at
that,
but
it's
not
origin,
I
think
other
than
that
ted.
Please,
on
this,
some
players
see.
C
Yeah
does
friday
9
a.m.
Pacific
work
for
people
who
are
on
the
call
right
now
we're
gonna
try
to
start
that
back
up.
There
doesn't
appear
to
be
a
great
day
that
everyone
can
make
it,
but
the
friday
european
friendly
airspace
is
available
for
some
strange
reason.
The
europeans
don't
want
to
have
meetings
the
end
of
day
on
friday,
but
that's
the
the
time
that's
available.
C
So
I'm
going
to
propose
that
that
we
start
that
up
9
a.m.
Pacific.
H
Could
you
post
it
on
the
on
the
issue
that
restarting
the
sampling
sig
is
discussed
because
atma,
who
would
be
interested
in
joining,
is
not
here
at
the
moment
and
I
think
he's
usually
not
working
friday
afternoon
or
evenings
surprise
yeah,
so
he
might
have
some
some
opinion
there.
One
thing
that
I
just
saw
on
on
thursday.
H
I
think
it's
8
a.m.
Pacific.
H
There
would
be
a
slot
in
between
the
language
6,
where
there
should
be
no
overlap
in
people
joining
both
language
6,
the
one
before
and
the
one
after
so
it
would
be
at
most
two
hours
at
once
if
someone
is
joining
sampling
and
the
language,
so
maybe
that
would
work
as
an
alternative,
but
you
can
just
propose
off
and
then
discuss
it
there,
yeah,
okay,
I'll,
propose
them
both.
Thank
you.
B
Great,
thank
you.
Thank
you
for
that.
Okay,
I
don't
think
we
have
any
more
items,
but
we
can
talk
about
something
else.
If
you
guys
have
something
from
the
top
of
your
head.
I
I
F
F
B
I
remember
j
mcd
also
was
interested
in
this
for
some
prometheus
stuff,
which
I
don't
remember
now
so
yeah,
maybe
maybe
it's
more
important
than
it
seemed.
D
You
if,
if
I
recall
correctly,
it's
kind
of
related
to
the
oteps,
that
I'm
writing
around
resource
identity,
which
is
resource
right
now,
has
a
single
attribute
set
right
and
there's
a
question
of
do.
D
I
need
to
have
my
identifying
set
immediately
so
that
I
can
identify
a
unique
resource
and
then
I
can
append
you
know
descriptive
labels
later
like
descriptive
attributes
and
I'd
and
know
which
ones
are
identifying
versus
which
ones
are
descriptive
or
not,
because
there
was
a
proposal
to
only
allow
late,
appending,
descriptive
attributes
and
if
we
have
very
clearly
identified
it,
you
know
identify
identifying
attributes,
descriptive
attributes
that
really
simplifies
the
semantic
conventions
around
required
and
not
required,
and
some
of
the
things
that
we
need
to
do
for
metric
identity.
D
So
I
would
be
a
fan
like.
I
think
this
is
all
kind
of
correlated.
I
think
I'd
be
a
fan
of
pushing
on
this
notion
of.
Do
we
want
identifying
versus
descriptive,
attribute
distinctions
within
resource.
My
question
to
you,
though,
for
javascript
is
that
true
for
javascript?
Are
these?
Actually,
you
know
you're
getting
more
descriptive
things
coming
in?
Are
you
getting
the
actual
identifiers
coming
in.
I
D
Expect
that
no
matter
what
we
do
anyway,
I
hear
you
yeah,
so
so
yeah,
that's
that's
kind
of
what
I
was
thinking.
So
this
is
you
need.
You
need
late,
binding,
identifying
attributes
yeah.
I
still
think
I
would
like
to
see
that
pushed
on
specifically
for
the
cloud
function,
use
case
as
well
and
lambda,
but.
I
Yeah,
I
mean
obviously
there's
a
lot
of
context
that
I
don't
have,
but
so
I
I
wasn't
going
to
propose
a
solution
now,
but
one
way
to
potentially
solve
this
would
be
that
the
resource
object
generates
like
a
uuid
when
it's
constructed
that
survives
for
the
length
of
the
process.
So
you
know
the
back
end,
even
if
it
got
an
identifying
resource
would
be
able
to
retroactively,
apply
it
to
oh,
I
everything
that
had
this
uuid
should
have
this
service
name
or
whatever
you
know.
I
I
don't
know
whether
that's
reasonable
or
not.
Obviously,
that
requires
back-end
changes,
and
things
like
that,
so
you
know,
like
I
said,
there's
a
lot
of
context.
I
don't
have.
G
But
I
think
I
think
there
are
a
bunch
of
discussions
about
this
and
the
tigran
had
that
good
proposal
about
something
which
we
will
discuss
called
entities
or
every
group
of
resources
have
have
a
identifier.
So,
for
example,
let's
say
for
pod,
the
uid
is
considered
identifier,
the
name
or
the
other.
G
Things
are
considered
just
optional
arguments
about
that
id,
but
that's
the
idea
of
the
the
grouping
of
the
the
things
so
anyway,
there
are
a
bunch
of
proposals,
ideas
and-
and
I
think
will
be
good
to
to
have
a
more
in-depth
design
and
proposal
for
solving
the
entire
solution.
The
entire
problem.
I
B
D
He
has
this:
he
had
this
idea
to
do
resource
discovery,
separate
from
pulling
metrics
and
then
join
together,
the
resource
and
the
metric
and
the
collector.
I
think
that
was
what
this
was
about,
if
I
recall
correctly,
but.
G
G
Yeah,
so
I
think
he
he
does
not
run
gosek
because
he
would
have
catch
the
permission
for
the
share
memory
problem
he
opened
for
everyone
anyway.
Yes,
so
I
think
that
was
the
case
for
that,
and
I
think
it's
important
for
metrics
backhands
to
know
which,
which
of
these
resource
labels
are
identity.
Labels
which
have
to
be
have
to
be
indexed
and
used
in
the
identity
of
the
the
metric
and
which
are
not
identity
labels.
A
B
Yeah,
just
please
do
so.
I
think
that
yeah,
I
am
afraid
that
maybe
forgotten
and
then
somebody
will
have
to
have
a
get
another
design
and
probably
will
be
noticed
as
good
as
yours,
so
yeah
please.
I
really
would
like
to
see
that.
A
Okay,
yeah
I'll
show
you
that
do
we,
we
don't
have
an
issue
right
for
me
to
put
that
link
yet
so
I'm
probably
going
to
add
it
to
the
meeting
next
year.
G
B
C
So
now
that
we've
merged
the
my
pr
that
relaxes
the
kind
of
squishy
requirement
of
node,
no
nesting
of
clients,
fans,
etc,
I
thought
it
would
be
good
to
start
creating
issues
for
where
we
have
gaps
in
our
knowledge
and
how
people
should
do
modeling
of
spans.
So
I
wanted
to
start
with
http
clients,
and
so
this
is
just
an
issue
I
put
in
today
to
track
sorting
out
how
we
should
do
make
recommendations
about
modeling
the
details
inside
an
http
client
call.
C
So
if
there
are
experts
in
http,
plus
networking,
instrumentation
and
monitoring
would
love
those
people
to
help
and
I'll
just
say
that
is
not
me.
I
know
it's
an
issue,
but
I
this
is
not
something
that
I
have
been
expert
in
at
all.
Yeah
john.
Do
you
mind
cross-posting,
that
in
hotel,
instrumentation
and
slack,
I
can
do
that
thanks.
G
C
D
So
I'll
see
if
I
can
pull
the
folks
on
our
end
that
we're
doing
some
envoy
integration
now
they
were
more
focused
on
logs
but
I'll
see
if
I
could
pull
them
in
for
for
tracing
as
well,
because
I
think
they're
effectively
doing
traces
via
logs.
For
some
reason-
and
I
forget
the
specifications.
D
B
G
Especially
if
you
are
from
from
javascript,
that's
that's
the
right
thing.