►
From YouTube: 2022-04-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).
B
B
C
So
I
guess
I've
been
stuck
again
busy
doing
application
insights
releases.
I
I
think
I've
managed
to
do
like
four
on
friday,
just
fixing
bugs
for
once
earlier
in
the
week,
so
I
still
haven't
had
a
chance
to
catch
up
on
on
all
the
documentation,
but
this
week
is
looking
well,
maybe
looking
better
now,
my
mother,
I've
released
to
the
internal
team
and
they
seem
to
be
accepting
it
so
far,
so
hopefully
they
don't
raise
any
issues.
B
Yeah,
but
I
think
it
was
the
same
topic
he
probably
would
feel
like
you
know.
The
discussion
was
done
in
the
previous
meeting.
B
A
Okay,
so
I
so
we
so
I
brought
this
this
this
topic
in
in
the
specs
josh
you
were
there.
I
it's
like.
We've
been
going
in
the
direction
of
storing
the
session
information
on
the
resource.
I
think
our
reason
was
like
we
wanted
to.
We
don't
want
to
duplicate
the
data
on
on
all
the
signals.
A
I
know
there
is
also
so
like
we.
We
have
a
prototype
for
for
updating
for
storing
the
session
information
on
on
the
resources
and
we
updated
it
or
sometimes
updated
it
last
week
with
the
the
concept
of
the
resource
provider,
and
so
I
think,
did
you
did
you
want
to
talk
about
that
santosh
or
demo,
that
that
would
work.
B
Well,
there
isn't
much
in
the
demo
it's
basically,
there
is
a
resource
provider
which
is
passed
on
to
the
trace
provider
instead
of
a
resource
that
is
passed
today,
and
you
know
every
time
you
create
a
span
today,
you,
the
trace
provider,
passes
that
resource
to
the
tracer
and
the
tracer
gives
that
to
the
span.
B
Instead,
in
this
prototype,
what
we
did
was
the
at
the
time
of
the
tracer
giving
the
resource
to
the
span.
It
would
ask
the
resource
provider
get
me
the
latest
version
of
the
resource
resource
or
the
current
version
of
the
resource
so
which
might
be
different
from
the
resource
that
was
used.
You
know
a
couple
of
minutes
ago,
so
that
way
you
know
each
span
could
potentially
get
a
different
resource,
a
slightly
modified
resource,
so
that's
possible.
B
B
I
I
see
a
connection
to
your
other
comment
where,
if
we
could
somehow
indicate
that
a
resource
has
some
identifying
attributes
plus
optionally,
you
know
additional
attributes,
then
this
session
id
could
go
as
in
in
as
a
second
category
of
attributes
in
the
at
the
resource
level,
and
we
could
even
have
you
know
the
condition
that
the
resource
provider
you
know
as
long
as
it
is
giving
you
the
same
resource.
B
So
actually
it's
interesting
that
tigran
has
an
independent,
otip
right
now
on
the
attributes
at
the
scope
level,
and
he
has
a
an
interesting
feature
where
he
is
talking
about
inheritance
of
the
scope
level,
attributes
being
passed
on
to
the
individual
signals
like
span
and
locks.
B
B
Then
those
can
be
overridden
at
the
scope
level,
which
can
further
be
overridden
at
the
signal
level,
and
then
these
you
know
the
session
id
is
something
that
could
be
be
kept
at
the
top
level,
and
then
we
have
use
cases
where
we
have
more
use
cases
where
you
know
there
are
some
attributes
that
are
common
to
all
the
signals.
B
Let's
say
the
page
id
on
which
all
these
events
are
coming
from,
so
that
page
id
could
be
one
more
at
the
top
level
and
it
is
not
identifying
the
resource,
but
it
is
a
common
attribute
to
all
the
signals,
so
so
that
inheritance
concept
is,
is
surely
interesting,
but
I
think
it
could
be
taken
to
one
more
level
up
in
addition
to
at
this,
you
know
keeping
them
just
at
the
scope
level.
If,
if
that
concept
is,
is
seriously
considered.
D
I
try
just
sometimes
I
try
to
say
very
little
in
the
specs,
because
I'm
worried
that
the
more
we
talk,
the
less
we
do
and
and
sometimes
I'm
afraid
that
there's
like
a
group
that
needs
something
and
the
the
sort
of
ideal
solution
would
come
if
one
person
would
devote
a
lot
of
time
and
resources
to
to
a
good
write-up
essentially,
but
when,
when
no
one
puts
for
forth
a
lot
of
time,
we
end
up
with
this
sort
of
like
muddle
muddy
to
middle
ground,
where
nobody
actually
has
done
enough
research
to
figure
out
what
we
need.
D
I'm
afraid
of
that
happening
here.
I
just
wrote
down
at
least
four
options
that
you
discussed
like
that.
We
kind
of
see
as
avenues
for
us
and
I'm
I'm
not
sure
what
the
best
one
or
the
most
palatable
one
will
be.
D
E
Sorry
I
missed
the
the
beginning,
but
the
the
feedback
we
just
got
in
the
spec
meeting
was
you
know:
could
we
look
at
instrumentation
scopes
as
the
place
to
to
put
session
id?
This
is
a
new
concept
being
added,
but
the
tc
members
that
were
there
generally
felt
like
this,
was
like
the
appropriate
envelope.
E
So
we
got
a
much
more
positive
response
from
the
tc
about
adding
this
information
to
scope,
which
would
have
a
little
more
repetition
than
resource
scope,
but
is
still
much
saner
in
my
mind
than
stapling
this
stuff
as
attributes
onto
onto
everything.
B
Yeah
it's
the
point
is
taken,
but
I
think
there
are
still
some
flaws
in
that
ted.
I
see
they
could
be
minor,
but
the
you
know
the
argument
against
that
is
it's
just
that
you
know
it
could
even
be
taken
one
level
higher
like
it's
possible
that
there
are
attributes.
B
You
know
that
are
common
to
multiple
instrumentation
scopes
and
that's
what
we're
trying
to
do.
So
if
we
had
another
concept
of
you
know
object.
That
is
one
layer,
above
all
the
instrumentation
scopes.
You
know
we
could
keep
this
thing
there
and.
B
E
E
So
there
was
some
of
the
I
brought
up
like
the
the
how
that
seemed
unoptimal
to
have
this
repeated
and
the
pushback
from
the
tc
was
that
repeated
information
is
no
big
deal,
because
even
trivial
compression
should
eliminate
it,
and
so
I
wanted
to
bring
that.
E
E
One
is
like
if
the
answer
of
like
compression
just
solving
all
of
our
over
you
know
wire
protocol
overhead
from
having
repeated
information.
If
that's,
if
that's
not
an
acceptable
solution
for
clients,
I
think
we
need
to
to
to
bring
a
technical
case
explaining
why
their
ideas
about
how
compression
makes
a
problem
go
away,
isn't
true,
yeah
for.
E
B
C
E
That's
awesome
yeah
that
that'll
be
really
helpful.
I
think,
and
then
the
other
issue
is
more
of
like
a
conceptual
one
that
I
didn't
totally
get
but
josh
you
might
understand
what
both
tigran
and
bogdan
were
saying
was
that
resources
were
seen
as
describing
the
telemetry
source,
the
source
of
the
telemetry
and
that
session
ids
a
session
didn't
seem
like
a
description
of
the
telemetry
source.
E
We
didn't
have
time
to
get
into
it,
but
it
seemed
to
me
that
they
were
kind
of
saying
that
the
telemetry
source
was
in
a
way
describing
a
physical
resource
of
some
kind,
which
is
partially
why
they
feel
that
resources
need
to
be
immutable.
I
personally
don't
know
like
to
me.
That's
not
like
a
super
compelling
argument,
but
you
know
the
the
the
project
leads
to.
D
Do
look
at
it
that
way,
yeah!
I
don't
see
a
conceptual
distinction
there
where
they
seem
to
like.
What's
the
difference
between
the
source
like
a
host
name
or
a
machine
name
and
like
some
other
attribute
that
gets
applied
at
the
resource
level,
because
I
wanted
it
there.
So
I
could
query
the
telemetry
that
came
from
there
so.
E
E
I
don't
that
just
maybe
sounds
like
banging
our
heads
against
their
heads
for
a
while,
but
the
the
practical
implement
implication
that
came
up
out
of
that
was
this
vague
notion
that
some
back
ends
use
the
immutability
of
the
resources
as
identifying
the
source,
which
I
think
I
kind
of
just
agree
with
with
josh's
proposal
like
it's
a
little
it
to
me
it
just
it's
actually
like
a
hole
in
our
specification.
E
I
kind
of
assume
that's
what
they're
saying
when
they're
saying
back
ends
rely
on
the
light,
the
immutability
of
resources
they're,
doing
something
like
that,
like
they're,
just
hashing
the
resources
and
they're
using
that
hash
is
essentially
the
instance
id
that's
nuts,
I
think
that's,
I
think,
that's
like
a
result
of
us
not
producing
what
josh
was
saying,
which
is
like
a
list
of
the
identif,
a
list
of
the
resource
attributes
that
you
should
use
to
identify
an
instance
of
something
yeah
rather.
D
There's
like
the
core
of
this
debate,
is
something
like
our
what's
the
purpose
of
telemetry
here.
Is
it
to
describe
the
world
the
way
it
that
we
know
it
or
is
the
purpose
of
the
telemetry
to
like
issue
statements
that
you
can
observe
like
those
are
different
summaries
and-
and
I
guess
the
way
you
can
one
way
of
framing
a
resource
attribute
is
these
attributes
are
tokens
I
will
use
to
identify
instrumentation
points.
D
There's
any
span
created
in
this
resource
by
this
key
is
something
I
can
query
and
when
you
change
the
definition
to
be,
these
are
the
source
of
telemetry.
You
stop
being
able
to
use
the
individual
attribute
to
select
the
telemetry,
because
it's
now
part
of
an
entity
or
something
like
that.
E
It
seemed
like,
like
anyways,
like
some
practical
work
that
might
help
this
group,
like
just
as
part
of
like
if
we
want
to
continue
to
roll
the
boulder
up
the
hill
of
changing
the
way
resources
work.
It
seems
like
one
of
the
things
we
have
to
do
is
address
this.
One
thing
we
have
to
do
is
knock
aside.
This
idea
that
compression
will
will
save
us
from
inefficiency.
E
Two
is
to
address
this
idea
that
resources
should
be
conceptually
defined
as
something
that
would
include
a
session
identifier
like
just
you
know,
if
that's
that
whatever's
going
on
there
just
needs
to
be
clarified
conceptually
like
if
there's
some
people
saying
this
needs
to
be
identifying
a
physical
resource.
So
something
like
a
session
isn't
really
the
like
the
yeah.
D
D
I
why
I
bring
up
prometheus,
because
they're
in
prometheus
instance
and
job
are
going
to
be
reused.
How
do
you
know
the
difference
between
a
restart?
If
you
can't
talk
about
the
distinction
between
instance
and
job,
which
are
very
identifying
and
like
restart
number,
which
is
totally
not
identifying
yeah
and
then.
D
E
So
that
yeah,
that's
the
third
thing.
I
just
think
there's
three
things:
there's
the
the
compression
inefficiency
issue,
there's
the
conceptual
issue
of
like
why,
like
a
resource,
why
a
session
is
like
an
identifying
characteristic
that
the
resources
should
be
defined
as
something
that
would
include
a
session?
I
think
maybe
it's
because
people,
I've
noticed
a
lot
of
back-end
programmers
when
they
hear
session,
they
have
a
very
transactional
view
of
the
world
and
so
they're.
E
That's
why
you're
getting
this
feedback
from
people
like
yuri,
who
are
like
this
should
be
like
a
trace
id
or
like
this
is
like
baggage,
because
from
my
back-ends
point
of
view,
if
they
were
to
be
thinking
about
sessions,
they
would
only
be
thinking
of
sessions
in
terms
of
transactions,
and
so
I
think
that's
just
like
this
conceptual
mismatch
that
we
need.
E
B
Since
you're
talking
about
kubernetes
resources
too,
I
just
realized
that
all
the
kubernetes
resources
have
a
field
called
state
where
all
these
you
know
restarts
of
what
anything
that
is
changing
our
time
is
kept.
So
maybe,
if
resources
in
open
telemetry
2
have
a
state
field
and
separate
set
of
attributes
under
the
state,
and
so
those
can
be,
you
know
eliminated
from
being
identifying
the
resource.
D
That's
one
of
the
approaches
like
I
mean
I
kind
of
wrote
down
when
we
started
this
meeting,
you
you
iterated
over
a
bunch,
so
one
approach
we
could
come
away
with
is
just
add
another
field
to
the
resource,
which
is
things
that
are
not
identifying,
but
we
also
just
like
key
values
associated
with
telemetry,
because
you,
you
know
how
to
use
key
values
to
find
telemetry
and
that's
what
we
mean.
D
I
feel
like
that's
more
problematic
than
potentially
the
the
grander
solution,
which
is
one
I've
been
thinking
about
and
tried
to
not
say
about
much.
But
here
it
is
okay.
I've
said
this
in
the
past
and
long
ago
we
can
find
the
old
issues.
I
won't
do
it
now.
D
But
if
you
were
to
make
advantage
take
advantage
of
the
schema
url
and
it
might
require
just
development
like
we
don't
know
how
to
use
more
than
one
scheme
at
a
time
maybe
or
like
each
live
scope,
has
its
own
schema
and
there's
a
little
bit
of
lacking
clarity.
But
suppose
you
had
a
schema
and
it
did
what
you
wanted.
What
you
want
is
to
is
to
say
inside
of
my
resource,
I
will
have
these
attributes
and
the
attributes
fall
into
three
categories.
D
Attributes
can
be
identifying,
attributes
can
be
descriptive
and
they
can
be
like
non-descriptive
and
and
every
attribute
will
fall
into
one
of
those.
And
if
you
are
looking
for
that,
traditional
interpretation,
which
is
what
is
the
thing
producing
producing
telemetry,
you
must
just
look
at
the
identifying
resources
and
you
will
find
all
of
the
telemetry
for
that
particular
process.
D
The
way
it's
traditionally
been
described
and
if
you
want
to
know
everything
about
the
telemetry
and
all
the
keys
and
values
that
you
can
use
and
and
the
things
that
we've
defined
in
the
schema,
then
just
use
all
the
attributes.
D
But
if
you
start
using
attributes
that
were
called
non-descriptive,
like
sampling
rate
or
or
like
some
other
baggage
that
had
nothing
to
do
with
anything,
then
you
might,
you
might
have
meaningless
interpretation,
which
is
okay,
but
you
should
kind
of
know
when
you're
doing
that
anyway,
I
think
if
we
had
and-
and
the
reason
I
say
schema
is
like
we
spent
40
minutes
in
today's
spec
sig
talking
about
attributes
whether
they
have
name
spaces,
whether
they're,
descriptive,
identifying
et
cetera
like
if
there,
if
you,
if
we
could
change
our
data
protocol
and
have
a
struct
for
every
attribute,
you
might
have
a
short
name,
a
long
name
and
a
type
information
and
a
help
string.
D
What
does
this
attribute
mean?
So
if
you
had
those
four
fields,
we
could
solve
all
these
problems,
but
we
don't
want
to
go
back
and
we
don't
want
to
pay
the
wire
costs
for
that
either.
That's
why
I
think
the
schema
url
is
a
good
solution
here.
Is
you
just
declare
those
things
to
be
what
types
they
are
and
give
the
help
strings
and
what
give
their
short
and
long
form
names
give
them
name
spaces.
D
Put
that
all
in
a
schema
and
then
forget
about
it,
because
when
you
come
to
the
interpretation,
if
you
care
you're,
going
to
go,
look
up
the
schema
and
like
filter
out
the
non-descriptive
or
the
non-identifying
attributes,
and
then
now
you
can
tell
what
the
process
is,
but
you
also
have
the
session
there
for
what
you
needed
it
for
that's
all.
I
want
to
say.
C
I
guess
holding
on
for
that,
in
terms
of
when
we
get
to
defining
the
individual
events,
I'd
like
to
extend
that
and
actually
say
well,
we
actually
have
an
event
schema
so
that
effectively
hotel
will
have
a
set
of
known
event,
types
that
we
send,
but
you
can
have
third
parties
go
and
define
their
own
and
that's
just
described
by
the
schema.
D
So
I
guess
I'm
kind
of
painting
a
picture.
I
think
the
road
map
to
overcome
to
tigran
and
bogdan's
objections
here
is
to
somehow
introduce
this
extra
information
so
that
you
have
two
ways
to
pick
apart.
The
resource
one
is
everything
which
is
current
and
one
is
a
little
bit
more
nuanced.
D
E
Is
it
feasible
to
just
do
the
simpler
thing
of
just
saying
just
just
identifying
the
subset
of
predefined
resources
that
you
would
use
to
identify
an
instance
like
choose
from
the
following
list
of
you
know
we
have
things
like
service
instance
id,
and
you
know
you're
saying
if
there's
something
like
restarts
or
if
there's.
E
If
service
instance
id
is
not
always
going
to
be
present,
let's
say
like
just
saying
like
these:
following
resources:
identif
identify
the
the
instance
essentially.
D
D
And
so
then,
when
you
read
this
data,
it
has
a
schema
url
that
points
out
prometheus
if
you
parse
that
but
you've
cached
that
information
at
this
point,
you've
parsed
that
once
you
said,
oh,
I
know
it's
got
job
and
instance.
So
then
the
prometheus
data
comes
in
and
you
can
see
it's
got
job
and
instance,
and
maybe
yeah.
D
E
My
question
is:
do
we
need
to
to
go
all
the
way
to
the
level
of
making
it
dynamic?
Where
you
know,
resource
providers
are
also
spitting
out
this
list,
or
can
we
just
bake
it
into
the
spec
like
that?
This
is
this?
Is
the
list
of.
D
B
E
B
So
what
would
be
a
backward
compatible
approach
here?
How
would
we
go
from
what
is
there
today
to
a
you
know
a
schema
based
resource?
Would
you
be
adding
new
field
in
the
resource
called
describing
attributes,
and
you
know
non-describing
at
some
other
fields
with
a
different
name,
but
the
type
is
still
a
key
value
that
exists
for
the
attributes.
E
I
don't
know
that
I,
like
the
term,
descriptive
versus
identifying
but
yeah
you're
right,
santosh
like
if
we,
if,
if
one
of
the
requirements
is
that
look,
we've
made
a
commitment
to
back
ends
that
these
resources
are
mutable
in
a
way
that
sessions
would
break.
So
we
can't
just.
We
can't
just
update
the
spec
to
say,
like
you
should
use
the
following
resources
to
identify
an
instance,
because
we
didn't
say
that,
and
people
are
now
using
all
of
them.
So
we
can't
just
add
the
session
yeah.
Then
adding
like
a
new
thing.
E
That's
like
resources,
but
just
name
something
different
like
process
scope
or
something
like
that,
where
we
put
this
stuff
would
be,
would
be
the
solution
right
like
if
we're
being
told
we
can't
we
resources,
have
to
be
immutable
for
the
life
of
this
stuff
and
that's
that's
a
it's
a
nonsticker
to.
B
So
I
I
think,
if
I
understand
you
correctly
ted,
I
think
you
are
trying
to
introduce
one
more
layer
between
resource
and
the
instrumentation
scope,
and
you
know,
and
and
since
tigran
is
talking
about
inheriting
of
the
attributes
anyway,
you
know
so
you
could
start
off
with
yes.
B
E
E
This
this
layer.
Well,
if
we're
talking
about
instrumentation
scopes,
that's
that's
a
new
concept
that
hasn't
been
added.
Yet
that's
like
going
in
right
now,
so
one
option
is
just
to
to
ride
that
train,
go
into
the
instrumentation
scope
proposal
and
say
make
sure
that
it's
described
in
such
a
way
that
these
things
are
inheritable
in
a
way
that
doesn't
cause
a
bunch
of
duplication
right
because
they
might
be
described
as
inheritable,
but
in
a
way
where
information
is
like
just
merged
in
in
all
the
little
instrumentation
scopes.
E
We
just
want
to
make
sure
that
proposal
doesn't
work
that
way
right.
We're
saying,
there's
some
way
for
instrumentation
scopes
to
be
inheritable,
so
you
could
have
a
top
level
scope,
that's
only
injected
into
the
data.
Once
I
don't,
I'm
not
sure
how
that
would
work.
I
mean
unless
you
had
like
instrumentation
scopes,
each
instrumentation
scope
have
being
like
basically
like
put
into
a
graph
or
something
like
that
with
each
one
having
a
parent
and
an
id.
E
D
D
What
they
will
see
after
this
is
each
session
is
a
process,
is
a
resource
and
there's
nothing
too
wrong
with
that,
except
that
you
can
no
longer
infer
from
one
session
to
the
next
that
they
were
on
the
same
device,
except
that
there's
going
to
be
a
device
attribute
and
like
you
can
so
my
point
being,
is
that
the
worst
that
happens
here
is
the
people
who
have
the
very
strict
back
indie
interpretation,
that
resources
or
resources
and
they're
immutable
will
see
each
session
as
a
resource,
and
I
don't
think,
that's
a
problem
and
then
the
so.
D
So
that's
the
backward
compatibility
approach
and
that's
why
I
like
it.
So
then
you
could
say-
and
you
know
for
those
of
you
who
are
interested
in
this
new
nuance-
that
we
bring
to
the
table
here.
You
can
distinguish
between
things
that
are
variable
at
runtime
and
and
the
true
resource
that
that
has
some
notion
that
we
haven't
defined
whatever
it's
the
device.
It's
the
proc.
It's
the
address
space
of
a
single
linux
process.
D
I
don't
know
what
that
is
really
because
we
haven't
defined
that
ever,
but
whatever
that
is
can
be,
can
be
located
by
parsing
the
schema
file
looking
for
the
list
of
identifying
attributes
and
only
focusing
on
those,
so
there's
a
path
for
the
legacy
forward.
If
they
want
to
take
it,
but
we
don't
break
anything
other
than
stuff
that
we
mean
to
break
basically
yeah.
B
Actually,
I
I
last
time
I
checked
with
the
I
don't
know
who,
but
in
the
back
end
we
do
have
schemas
for
different
entities
and
then
we
map,
you
know
the
resources
into
the
entities.
Picking
only
certain
attributes
that
are
of
interest,
so
schemas
do
exist
in
the
back
end.
B
D
Yeah
we
have
these
schemas,
but
they,
but
they
were
purpose
built
for
as
little
as
possible
to
do
to
do
as
little
as
we
needed
them
to
do,
and
that
is
their
support.
They
support,
renaming
spans
and
renaming
metrics,
basically
and
renaming
attributes,
but
but
to
add
support
to
them
will
mean
version
1.1
of
the
yml
file
with
a
new
type
of
thing,
a
feature
saying
which
attributes
are
identifying
basically
and
then-
and
this
way
the
nuance
that
we're
talking
about
can
be
had
or
not
by
by
fully
working
with
schema
files.
D
All
this
conversation
by
the
way
doesn't
address
some
of
my
my
new
concerns.
After
listening
to
this,
which
is
about
the
actual
api
that
we're
going
to
use
like.
Is
it
something
like
for
sessions
to
get
the
association
between
a
context
and
a
session?
Is
it
contextual
or
is
it
based
on
the
state
in
the
in
the
sdk,
like
those
were
some
questions
that
I
came
away
with
as
far
as
programming
model,
but
most
of
my
earlier
comments
were
basically
just
about
the
data
model.
E
E
E
I
think
it's
something
like
like
it
might.
If
we
can't
call
it
a
resource
provider,
if
it's
some
scope,
something
something
you
just
get
handed
your
parent
scope
or
something
I
don't
know,
but
it
depends
on
where
this
thing
lives,
but
yeah
it's
either
a
resource
provider
or
if
we
bake
this
into
instrumentation
scopes,.
D
D
E
E
E
E
What
is
this
scope
envelope
and
anything
that
makes
sense
to
like
be
put
on
that
envelope
in
terms
of
like
what
it's
bounding
is?
Is
the
better
way
to
look
at
it,
so
that
goes
for
both
instrumentation
scope
and
resources.
For
me,
I
think
we
should
release
ourselves
from
saying
semantically.
This
information
has
to
mean
this
or
that.
C
E
E
B
Actually,
at
the
instrumentation
level,
they
do
have
separate
fields
for
the
instrumentation
library
name
and
the
version
and.
A
B
Separately
attributes,
so
the
those
two
fields
can
be
the
identifying
the
instrumentation
scope
and
the
attributes
could
be.
You
know,
free
form,
you
know
they
could
right,
you
know
if
they,
if
they
even
support
mutate,
mutable
attributes.
You
know
they
could
like
things
that
change
over
time,
you
know,
could
could
be
present.
There.
E
Yeah
and
what
josh
is
proposing
for
identifying
resources
is
essentially
the
same
thing
with
resources
right,
there's
just
this
set
of
them
that
you're,
using
as
the
identifiers
the
same
way
you
have
instrumentation
name
and
instrumentation
version
and
then
there's
a
set
of
them
that
are
just
like
attributes
that
just
just
attributes
they
might
have
semantic
meaning
to
somebody
somewhere,
but
they're
not
like
what
you
would
use
to
identify
this
originator
and
with
resources
right
now.
We
don't
have
that
distinction.
E
It's
a
little
dumb
because
it's
the
same
thing
as
resources,
but
if
what
we're
saying
is
the
cat's
already
out
of
the
bag
as
far
as
resources
needing
to
never
change,
because
people
are
out
there
making
a
hash
out
of
them
and
using
that
as
an
identifier,
and
that
was
like
the
intention
behind
resources.
So
it's
not
a
backwards,
compatible
change
to
to
screw
that
up
for
people.
So
we
can't
do
that.
Then.
E
I'd
prefer
to
not
do
that
and
do
the
thing
that
josh
suggested,
which
is
just
list
out
which
keys
you
should
use
to
make
that
hash
rather
than
say
all
the
resource
keys
should
go
in
it.
E
A
So
if
I
understand
correctly
like,
if
you
say
like
list
out
the
the
attributes
that
are
that
are
required
or
identifiable,
do
you
also
mean,
along
with
that
update
the
schema
or
like
have
have?
I
have
a
new
version
of
the
schema
that
would
say
like
hit.
This
is
like
you
know,
so
the
back
ends
that
they
could
look
at
that
and
say
like
if
I
had.
E
E
Yeah
exactly
but
schema
to
me
in
this
case
is
still
just
static
right.
It's
like
that
version
of
the
spec
like
we,
we
wrote
out
a
version
of
the
spec,
and
we
said
this
is
the
list
of
resource
keys
that
you
should
use
as
identifiers
and
to
me
that
that
means
like
make
a
hash
out
of
all
of
these
things,
and
that's
that's
your
identifier,
because
some
of
them
we
can't
guarantee
the
presence
of
any
or
all
of
them,
or
just
one
of
these
isn't
enough,
necessarily
whatever.
E
I
think
it
should
all
just
be
service
instance
id.
But
that's
just
me,
I
I
think
that
would
be
sufficient
to
just
say
that,
but
I
can
see
someone
coming
back
and
saying:
that's
not
backwards
compatible
and
they're
they're
right.
It
isn't.
If,
if
the
fact
that
resources
had
to
be
immutable
was
was
like
some
bedrock
that
like
systems
are
really
leaning
on,
I
don't.
I
personally
don't
think
that's
like
that
big
a
deal.
E
So
I
would.
I
would
like
that
to
be
the
solution.
I
think
that's
the
most
straightforward
solution
and
it
makes
lots
of
sense
to
me,
I'm
just
saying
if,
if
we
get
just
told
a
firm,
no,
if
like
it
just
becomes
impossible
to
go
through
that
door,
then
the
the
next
best
thing
for
me
is
to
say.
Well,
there's
this
the
same
way
we
just
added
instrumentation
scope.
E
We
need
a
process
scope,
something
that's
like
instrumentation
scope,
but
applies
it's
just
like
an
envelope.
That
applies
to
all
the
data
in
this
batch
so
that
we
don't
have
to
repeat
it
anywhere,
which
is
what
freaking
resources
are
right
now,
but
whatever
that's.
B
You
know
so
so
we
have
several
ideas
here
is
other
than
the
spec
meeting,
which
has
several
things
on
the
agenda.
Is
there
any
other
opportunity
to
talk
with
igran
and
bogdan
if
if
they
are
the
like,
basically
are
there
any
other
opportunities
to
talk
to
them
in
any
other
meeting?
E
I
think
we
should
schedule
a
meeting,
a
meeting
with
them
and
people
who
care,
I
think,
you're.
That's
a
good
idea,
because
this
seems
like
this
is
going
to
take
some
time
to
to
hash
out
in
that
spec
meeting.
E
There's
just
not
a
lot
of
time,
so
yeah,
maybe
maybe
let's
I'll
reach
out
to
them
in
in
our
slack
channel,
okay,
I'll
ping
them
there
and
then
dm
them
to
say
hey.
Can
you
like
have
a
look
at
this
and
like
work
out
a
time
to
talk
with
us
about
this?
So
we
can
sort.
B
It
out
so,
interestingly,
we
are
meeting
twice
a
week
so
both
tuesday
and
wednesday.
So
if,
if
they
are
available
tomorrow,
they
can
join
otherwise
next
week.
Yes,.
E
B
E
Could
they
can
meet
yeah
for
that
week,
but
yeah
I'll
I'll
set
that
up
with
them
yeah
because
yeah,
I
I
agree
I
want.
I
want
this
part
of
it
solved
quickly,
like
I
don't
wanna.
E
Just
move
forward
an
inch
we
need
to
to
figure
out
what
which
of
these
avenues
is
actually
has
a
chance
of
of
success,
which
is
why
I've
been
harping
on
like
tc
participation
in
all
of
these
groups,
because.
D
E
Yeah
and
I
think
that
the
case
is
made
stronger
by
the
the
potential
for
other
resources
needing
to
update
around
clients
reawakening
and
having
some
valid
resource.
That
would
change
that
honestly,
might
tell
you
to
like
re-identify
this
as
a
new
thing.
D
Yeah,
we
should
definitely
find
the
old
issues.
There's
one
saying
we
we
just
they're
too
early
in
the
process
lifetime
to
know
our
resource.
We
have
to
be
able
to
wait
like
one
second
later,
so
let
us
change
like
resource
after
the
fact,
and
that
was
also
blocked
on
the
same
exact
object.
Objection,
which
is
that
resources
are
permanent
and
immutable.
E
Slide,
I
actually
don't
think
we
should
get
this
mixed
up
with
the
like
delayed
fetching
of
resources
that
are
just
for
clarity,
because
those
are
resources
where
you're
saying
like
I
need
that
to
identify
my
first
batch
of
data,
it's
just
like
slightly
different,
I
think,
but
so
let's
let
let's
not
get
these
two
things
mixed
up
with
each
other
that'll
they'll
confuse
confuse
them.
B
Yeah,
since
we
have
few
more
minutes,
I
I
want
to
talk
about
the
programming
model,
the
api
interface
that
we
haven't,
get
your
thoughts.
Let
me
share
my
screen.
B
So
the
the
way
I
I
did
this
was
I
introduced
this.
You
know
in
addition
to
this
resource
provider,
I
introduced
something
called
a
you
know:
a
resource
modifier,
as
in
you
know,
instead
of
having
a
generic
method
called
update
on
the
resource
provider.
You
know
I
wanted
to
be
you
know
specific
as
to
who
all
can
update.
B
You
know
the
attributes
in
this
resource,
so
each
resource
modifier
is
supposed
to
register
with
this
resource
provider,
and
then
you
know
they
can
call
the
set
attribute
and
delete
attribute
on
on
this
resource
provider,
and
the
session
manager
would
register
with
this
resource
provider
as
one
of
the
resource
modifiers
and-
and
there
could
be
more,
you
know,
depending
on
the
different
use
cases.
So
that
way
we
exactly
know
who
modified,
which
attribute.
B
In
the
sessions
I
had
something
called
named
sessions
where
you
know
there
could
be
multiple
simultaneous
sessions
it,
so
the
session
manager
has
and
has
a
name,
and
since
there
is
some
confusion,
since
it's
not
very
common,
I,
whenever
the
default
is
the
name
of
the
session,
then
you
know
we
could
omit.
You
know
the
name
entirely
in
in
the
when
we
purchased
the
the
session
attributes.
B
C
I
I
don't
think
you
need
the
second
level
I
think
everything's
just
section
id,
and
it's
a
case
of
when
you
do
have
multiple
session
ids,
it's
effective.
That
chunk
just
goes
with
the
different
set
of
session
ids,
like
the
I.
I
don't
have
any
use
case
where
a
single
event
needs
multiple
session
ids.
If
I
do
I'm
happy
to
duplicate
the
event.
B
Yeah
yeah,
so
we've
at
our
company,
we
were
thinking
of
you,
know:
scenarios
where
you
know
this
whole
concept
of
sessions
you
know,
could
be
leveraged
to
give
more
features
such
as
you
know,
identifying
some
workflows.
B
So
typically,
you
know
today
all
these
sessions
are,
you
know
they
start
when
you
start
the
browser
and
they
end
when
you
close
the
browser
right
and
then
in
the
back
end
against
the
session
id
you
you,
you
know,
store
information
in
your
database
as
to
which
user
is
logged
in
in
against
this
session
id.
But
there
are
other
cases
where
you
want
to
know
hey.
B
How
long
has
the
user
been
logged
in
right
you
and
in
a
given
browser
session,
a
user
logs
in
and
logs
out
various
times,
so
you
want
to
specifically
know
the
duration
of
each
login
session.
You
know
that
could
be
something
you
know
that
could
be.
You
know
built
you
know
using
this
named
sessions
and
you
you
there
could
be
other
workflows.
B
You
know
like
a
checkout
workflow
card,
checkout
workflow,
so
you
want
to
know
how
many
people
are
currently
you
know
being
going
through
a
checkout
process.
So
that
could
be
a
session,
so
how
long
have
they
been
in
a
in
this
checkout
process?
So
so
you
anyway
will
be
building
the
session
begin
and
end
saying
hey
how
many
simultaneous
sessions
are
there?
How
long
each
session
has
been.
B
You
know
present
that
same
back-end
functionality,
you
know,
could
be
leveraged
to
answer
some
additional.
You
know
questions
as
well
for
for
these
kind
of
use
cases.
C
Yeah,
it's
one
thing:
I've
noticed
in
open,
telemetry
names
get
overloaded
a
lot.
So
for
me,
I
see
them
see.
Those
are
two
different
things
and
I
would
actually
call
it
the
session
id
is
the
session
for
the
thing
and
what
you're
talking
about
really
is
a
task
id.
I
want
to
do
this
thing
yeah.
You
could
do
it
with
a
name
session
like
that,
but.
B
C
So
if
you
wanted
like
what
I
would
call
it
out
so
if
you're
on
the
sub
tasks-
because
I
guess
yeah,
one
man
session-
is
another
man's
task
as
well.
So
it's
it's
just
an
identifying
attribute
for
a
thing
or
yeah
for
a
process
that
you're
going
on.
There
is
something
similar
in
identity
that
we
have
this,
because
there's
there's
actually
two
ids
associated
with
any
login
one.
We
call
an
unauthenticated
id
or
ua
id
and
the
other
one
was
you're
you're
when
you're
logged
in
you
actually
get
your
authenticated
id.
C
C
B
Yeah
so
the
same
thing
you
know:
by
bringing
it
to
the
agent
side,
it
becomes
more
clear.
You
know
everybody
could
follow
the
same
approach.
C
C
It's
like
ted
mentioned
earlier,
having
the
id
is
called
the
process
scope.
You
could
call
this
the
process
id
as
well
process
task
naming
is
important,
but
often
irrelevant
when
you
come
to
big
blobs
of
data
as
long
as
the
name's,
consistent,
okay,
okay,.
B
B
We
could
drop
the
you
know
the
session
prefix
here
for
for
this
attribute.
B
Yeah,
it
could
be,
it
could
be
like
you
know
it
could
be
user,
provided
name
so
in
the
api.
You
know
you
would
take
the
name
and
that
would
go
there.
C
Yeah
I
and
this
sort
of
gets
back
similar
to
what
josh
was
talking
about
with
and
my
mind.
Just
went
blank.
That's
schema,
so
you
know
so
it
could
be
the
for
this
particular
vendor.
They
have
a
schema
which
says
it's
not
called
session
dot
session
two
id,
it's
called
fred
dot,
something
so
the
default
default
hotel.
One
would
just
say
it's
this,
but
then
they
can
go
and
have
their
own
and
then
the
backend
would
know
how
to
stash
that
process
that
use
that
ignore
whatever
so.
D
There
may
be
some
interesting
connection
here.
I
might
just
throw
it
out
for
you
to
think
about
it's
much
like
with
the
process
and
the
resource
discussion
there.
There
is
a
question
of
how
long
has
the
process
been
alive
and
is
it
up
and
and
my
my
dialogue
about
joining
resources
out
of
process
like
prometheus
does
is
partly
because
you
can't
define
up
without
doing
such
a
thing.
D
So
so
the
question
is:
how
do
you
record
uptime
or
process
liveness,
and
I
want
to
recommend-
or
at
least
suggest
thinking
about
using.
D
A
metric
because
metrics
have
start
times
and
current
times
you
could
use
a
scoped
library,
a
resource
or
sorry,
an
instrumentation
scope
with
certain
attributes
on
it
for
storing
information
about
tasks
and
a
metric
within
that
scope.
To
turn
to
to
store
information
about
how
long
you've
been
alive,
because
the
question
has
come
up
in
the
past
independent
of
client
cytometry,
which
is
like
how
do
I
say
when
I
started?
D
Do
I
put
that
in
a
resource?
Is
it
identifying
or
do
I
use
a
metric
which
would
be
like
very
traditional,
like
an
uptime
metric,
and
I
find
that
it's
probably
best,
in
my
opinion,
as
data
model
of
open
summary,
goes
to
use
an
indicator
variable
which
is
value
of
one
if
you're
alive,
essentially
and
a
start
time
on
your
on
your
metric.
D
That
says,
when
your
liveness
started
and
not
resource
attributes,
but
that
is
a
preference
based
on
you
know,
wanting
to
be
able
to
do
metric
queries
like
how
many
are
up,
and
then
you
know
you,
you
match
how
many
indicator
variables
there
are,
you
add
them
up
and
so
on
so
think
about
using
metrics
for
information
when
there's
a
start
time.
That's
mostly
what
I
was
trying
to
say.
C
Yeah,
I
I
guess
from
a
browser
perspective,
you
don't
want
to
do
pings
or
keep
alive
flags
for
metrics.
It's
like
in
internet
microsoft.
We
have.
C
We
have
this
concept
of
a
stat
speed,
which
is
like
just
a
heartbeat
signal,
which
is
exactly
what
you're
talking
about
here
and
we've
explicitly
not
implemented
on
the
browser,
because
you
don't
know
how
many
users
you've
got
you've
got
like
you
know,
x,
000
servers,
you
know
what
that
is
as
soon
as
you
release
it
on
the
web,
you've
got
x,
millions
or
trillions
of
weber,
vets
and
you
don't
want
every
single
one
of
them.
Sending
a
heartbeat.
D
I
wasn't
yes,
I
see
your
point.
I
wasn't
trying
to
make
it
into
a
heartbeat
or
a
metric,
though
I
was
really
trying
to
say
that
if
you
want
to
encode
information
about
a
thing,
that's
alive
as
a
piece
of
telemetry
information,
you
can
synthetically,
create
a
metric
so
that
one
way
to
record
a
session
start
time
would
be
to
put
a
variable
metric,
a
metric
counter
with
value
one.
D
And
it's
start
time.
Yeah.
C
It's
really
case
the
first
time
you
see
that
session
id
it
started
the
that's
also
that
that's
how
we
do
it
internally,
because
you
don't
know
the
end
like
the
browser
could
just
close
and
never
come
back.
You
know
the
persistence
just
disappears
so
next,
next
time
they
open
it
up.
It's
a
different
cookie,
different
section.
So.
B
So
ted,
so
you
will
reach
out
to
book
then
and
again
I'll.
E
Reach
out
to
I'll
reach
out
to
them,
okay
and
get
something
scheduled
yeah
thanks.
C
E
C
Where
do
we
want
to
put
the
the
write
up
about
how
compression
is
painful
on
the
browser?
Could.
E
C
Okay
cool:
I
hope
that
I'll
get
to
this
this
week,
so.