►
From YouTube: 2022-11-29 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
A
Quick
call
but
I
thought
I'd
call.
Him
is
on
the
agenda.
B
He
actually
put
an
item
on
the
agenda,
but
I
would
have
liked
tigrant
to
to
get
looked,
but
maybe
we
can
I
can
be
useful
for
me
also
to
get
a
sense
of
what
other
other
folks
think
about
this.
A
Yeah
that'd
be
fine.
Okay,
I
I
took
a
I,
took
a
look
at
it
really
I
noticed
that
was
on
the
agenda.
A
B
Yeah,
so
one
thing
that,
when
exploring
this
protocol
like
came
up
internally
in
your
Relic,
is
how
do
we
Define
an
agent
and
how
do
we
know
like
from
from
the
Telemetry
or
even
in
the
in
the
open
protocol?
What
is
an
agent
and
how
to
determine
like
its
type
and
other
for
other
sort
of
attributes?
And
there's
like
one
thing
is
like
discussing
with
tigran
and
other
folks
in
The
Collector.
It
looks
like
people
believe
that
the
open
Telemetry
collector
is
a
service,
and
that
could
be
it.
B
So
it
has
a
version
like
the
release
of
The.
Collector
could
be
the
version.
The
name
of
the
collector
could
be
just
Hotel
call
or
whatever,
and
the
specific
agents
running
on
the
host
would
be
instances
of
that
service
and
I
guess.
Well,
I
suppose
that's
that's
a
valid
point,
but
I
think
for
the
open
temperature
collector.
We
need
something
else:
it's
a
service,
but
it's
it's
a
special
kind
of
service
right
and
in
the
sense
of
in
the
context
of
op
amps.
B
If
you
want
to
build
a
UI
around
the
The
Collector,
one
thing
you
want
to
do
is
be
able
to
display
it
health
but
also
send
a
configuration
to
it.
And
since
the
protocol
is
render
neutral,
you
want
to
be
able
to
distinguish
between
the
open
territory
collector
or
the
neural
Lake
infrastructure
agents.
Or
you
know
the
data
locations
whatever,
because
the
kind
of
configuration
you're
going
to
send
or
the
Telemetry
you're
going
to
get
from
each
agent
is
going
to
be
different.
So
if.
B
On
top
of
it,
I
think
you
need
some
some
attributes
on
top
of
it,
which
is
this
is
why
I
wanted
to
suggest
to
have
agent
specific
attributes,
maybe
an
agent
resource
in
the
specs
in
which
we
could
have
a
thing
in
the
end
of
the
the
issue,
I
linked
an
agent
type
where
we
could
distinguish
between
the
collector,
the
open,
Telemetry,
collector
and
other
kind
of
Agents,
even
the
distribution,
where
you
could
distinguish
between
the
Splunk
distribution
of
The,
Collector
or
the
you
know,
neural
lake
or
honeycomb
distribution.
B
That
sort
of
thing,
so
that's
kind
of
one
point:
I
wanted
to
bring
up
and
and
the
HTT
Grant
says
he
like
he.
He
thinks
it's
an
interesting
idea,
but
I
wanted
to
know
like
what
would
be
the
next
step
to
to
go
ahead
and
and
make
a
change
in
the
specs
to
to
decide
on
on
a
set
of
attributes
for
the
agents.
A
I've
always
been
the
whole
like
identifying
versus
not
identifying,
attributes
and
and
sort
of
how
they're
used
with
Tigers
monetary,
so
I
guess
you're,
there's
sort
of
two
approaches
you
can
take.
One
is
establish
some
naming
connections
for
fields
that
appear
either
in
unidentified
or
identifying
attributes,
and
we
could
guarantee
yeah
or
at
least
reasonably
expect
to
be
there.
You
know
or
create
another
another
hash
somewhere.
That
would
include
this
information
is
that
what
you
were
suggesting
is
a
separate
like
agent
identifier.
B
But
I
was
suggesting
yeah
a
set
of
common
identifiers
that
we
can
like.
We
know
that
we
can
all
rely
on
so
that
in
the
as
part
of
the
identifying
attribute
for
an
agent,
you
should
get
the
the
type
of
the
agent,
for
example,
that's
an
identifying
attribute
so
that
we
can
all
build
uis
that
know
okay.
B
This
is
these
specific
agents
and
support
this
kind
of
configurations,
and
the
other
thing
is,
since
these
attributes
are
also
part
of
the
Telemetry
right,
so
the
collector's
own
Telemetry
sends
the
the
service
attributes
the
service
name,
the
version
and
in
the
instance
ID
I,
think
that
the
agent
attribute
the
agent
identifying
attribute
should
also
part
of
the
telemetry.
So
I
was
so
I'm
suggesting
that
we
could
have,
as
well
as
a
service
resource,
an
agent
resource
in
the
semantic
conventions
in
which
we
could
all
agree
on
what
defines
an
agent.
A
I
think
the
thing
that
gets
a
little
bit
tricky
there
is,
you
know,
we're
pretty
far
away
from
this
at
the
moment,
but
what
what
we
think
this
will
eventually
also
be
integrated
into
client
libraries,
in
which
case
it's
running
in
the
context
of
the
actual
service
and
is
not
engaging.
A
So
you
know,
if
you
think
about,
like
you
know
the
go,
find
Telemetry
libraries,
you
know
having
a
way
to
reconfigure
that
client
Library
via
op-amp.
C
A
Or
at
least
report
information-
and
you
know
its
existence
and
shown
in
a
UI,
and
it
would
be
a
different,
so
it
would
be
a
different
types
and
I.
Don't
know
if
it's
specifically
an
agent
type
yeah.
A
Yeah
I
mean
it
kind
of
reminds
me
of
the
recent
change
we
made
separating
client
and
agent
and
I
wonder
if
client
is
a
better
term.
B
A
Right:
okay,
yeah
I,
buy
that
I
I'm
again
I'm
thinking
more
on
the
trying
to
make
sure
that
we're
okay
with
the
client
Library
sort
of
model,
because
there's
a
couple
different
models.
B
A
B
B
Another
kind
of
point
that
we're
they've
been
discussing
internally
like
while
discussing
what
would
be
the
the
defining
attribute
for
an
agent
like
this
whole
concept
of
agents,
uid
that
you
know
in
a
new
proposal
for
the
supervisor,
is
persisted
by
the
supervisor
in
order
to
maintain
it
throughout
the
the
life
cycle
of
the
collector,
like
the
the
protocol,
doesn't
say
anything
about
this
uid
being
stable
after
a
restart
of
the
agent,
but
it
looks
like
in
practice
we're
all
implementing
some
kind
of
persistence.
B
B
On
top
of
the
pro
the
actual
process
and
I'm
not
saying
this
comes
with
mentioned
anywhere
in
the
specs
and
I
wonder
if
there,
if
we,
it
would
be
a
good
idea
to
introduce
this
concept.
D
Yeah,
because
immediately
every
implementation,
I've
tinkered
with,
has
always
had
that
be
persistent
with
the
one
exception
where
we
had
a
flag
to
force
re-registration
to
effectively
churn
the
IDS.
B
Yeah
so
I
wonder
if
the
spec
should
say
something
in
that
respect,
something
like
the
uid
should
be
stable
after
restart
or
introducing
another
concept.
C
Well,
if
I
remember
correctly,
there
is,
there
is
some
wording
in
the
specs
that
suggests
that
this
ID
should
be
persistent
or
it's
preferred
to
be
persistent,
but
it's
not
the
hard
requirement,
because
in
some
environments
you
simply
cannot
do
that.
B
Okay,
okay,
then
I
review
the
spec,
because
I
I
didn't
I,
didn't
see
that
but
probably
I,
just
maybe
I
read
an
older
version
of
the
spec
or
I
didn't
read
carefully.
You
know
so
and
I
have
another.
Look
at
that.
A
I
think
that
next
step
is
probably
the
put
together
a
proposal,
a
PR
for
this
package
that
identifies
yeah
what
exactly
conventions
we
want
to
establish.
A
It
seems
like
we're
backtracking
a
bit
on
the
you
know.
We
just
took
the
service
department
now
and,
and
now
we're
talking
about,
throwing
in
a
bunch
more,
but
I
also
think
it
is
necessary.
We
observe
Ikea
so
far,
really
only
dealing
with
the
single
agent
that
our
goal
is
absolutely
to
support.
Many
different
agents
and
this
issue
very
quickly.
B
Okay,
so
I
can
take
this
task.
I
guess
to
to
make
this
proposal
and
talk
internally
and
maybe
on
slack
I
can
I
can
first
send
the
proposal
on
slide.
We
can
discuss
it,
so
it's
it's
a
bit
more
Dynamic
and
then
I
can
I
can
try
and
make
it
PR.
Once
we
re
on
what
the
attributes
should
be,
that's
unreasonable
right
sure
it
does
so
that
was
my
topic
for
today.
Thanks
for
discussing
it,
do
you
have
anything
else.
A
Is
there
any
additional
discussion
I
want
to
have
on
Keegan's
proposal
of
implementing
off
amp
in
The
Collector,
unfortunately,
keep
that
all
to
give
a
bad
comments.
A
A
A
That's
it
I'm
gonna
I'm
gonna
duck
out
I'll.
Let
you
guys
wrap
up
all.