►
From YouTube: 2022-12-13 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
B
Okay,
let's
see
so
I
have
the
first
few
items.
First,
one
is
the
grpc
transport.
So
we
had
this.
We
discussion.
In
the
past,
we
talked
about
having
a
grpc
transport
for
oil
pump.
We
decided
not
to
do
it
recently.
I've
been
having
some
I
mean
hearing
from
some
folks
that
it
still
may
be
a
good
idea,
particularly
for
organizations
that
may
want
to
use
it
internally.
C
B
Where
there
are
sort
of
policies
around
what
sort
of
transports
you
can
use,
some
Works
prefer
to
have
everything
uniformly
on
grpc
for
I
guess
for
having
consistent,
pooling,
Etc,
I
I.
Don't
think
we
should
be
adding
this
just
yet,
but
we
specifically
have
an
issue
where
we
discussed
and
closed
it,
a
thing
that
we
won't
do
this
I
wonder
if
we
really
want
to
instead
say
that
it's
a
possible
future
extension
right,
adding
something
like
that
to
be
more
explicit
about
it,
so
that
people
are
not
I.
B
Guess
scared
about
us
being
somehow
objecting
to
grpc
in
particular,
and
just
to
leave
the
door
open
right
so
that
if
there
is
a
demand,
if
there
is
a
I
guess,
Justified
demand
for
something
like
that.
We're
open
to
considering
it
as
an
as
a
future.
Addition
to
the
spec
I
I
feel
like
it's
not
going
to
be
a
huge
complication
for
the
spec
itself
and
and
probably
even
implementation.
Wise
It's,
not
such
a
huge
big
deal
right.
So
I
was
wondering
what
do
you
guys
think
about
that.
C
I'm
I'm
over
to
it
I
guess
I
guess:
I
I
would
have
a
better
understanding
of
what
you
mean
by
leaving
the
door
open.
You
know
what
are
we
I,
don't
think
we're
explicitly
saying
we
would
not
support
grpc.
So
what?
What
does
that
really
mean
in
terms
of
the
spec
is?
Should
there
be
mention
of
it
or
I.
B
B
Okay,
cool
we're
good
with
that.
The
second
one
is
the
the
stability
right.
There
is
only
really
one
issue
remaining
there
for
us
to
formally
at
least
there
is
one
remaining
for
us
to
declare
the
stable
protocol
upon
being
stable.
It's
a
definition.
What
it
needs
to
be
stable,
so
I
was
hoping
that
otlp's
definition
will
be
ready
soon
and
we
can
just
borrow
a
week.
But
it's
not
I
wonder
what
should
we
do?
B
Should
we
wait
a
bit
more
or
or
just
do
our
own
and
the
reason
I'm
thinking
now
about
doing
our
own
is
likely
because
there
may
be
some
differences
there
in
our
definition
versus
what
otlp
does,
particularly
with
regards
to
the
guarantees
about
about
the
generated
products
and
stuff
like
that
about
the
names
of
things
there
is.
There
is
a
whole
lot
of
debate
around
that
in
otlp
and
which
I
think
does
not
necessarily
apply
to
what
we're
doing
at
our
pump
here.
B
We're
producing,
essentially
what
would
be
equivalent
of
the
sdks
in
in
the
language.
Libraries
in
open
planetary
not
would
be
the
equivalent
of
API
packages,
because
this
more
complicated
separation
to
apis
and
sdks
there,
which
we
don't
really
need
here
at
all.
So
it's
more
more
simple
in
our
case
and
the
arguments
that
are
brought
there
don't
necessarily
apply
to
us
right.
I
was
wondering
what
what
do
you
guys
think?
Maybe
maybe
there's
no
really
need
for
us
to
to
wait
for
that.
B
I
mean
or
we
just
wait,
a
bit
more
I,
don't
know
the
other.
I
guess
reason
we
would
want
to
wait
independently
from
that
would
be.
Is
that
now
that
the
op-amp
work
has
started
in
the
collector,
maybe
we
want
to
have
some
sort
of
implementation
there
and
and
learn
from
anything
that
comes
out
of
that
as
a
result,
right,
maybe
there
is
some
feedback
from
from
Sean
from
others
who
doing
the
implementation
and
tell
us.
Maybe
something
is
wrong
right.
E
E
Think
I
was
thinking
personally
that
sorry,
so
go
ahead.
Julie
yeah,
no
I
was
thinking
I,
don't
know
how
much
use
up
amp
has
yet
I'm
guessing
not
that
much
and
I
was
wondering
if
waiting
for
having
actual
Solutions
with
customers,
You
Know
How
likely.
Is
it
that
you
know?
Maybe
we
will
find
a
use
case
where
oh
no,
we
need
to
declare
this
thing.
We
need
to
make
a
breaking
change
in
the
protocol
because
we
didn't
consider
this
use
case
right.
B
Yeah,
that's
that's
always
a
concern.
I
think
we
so
and
correct
me.
If
I'm
wrong,
I
think
you
do
have
customers
who
use
this
I'll.
Maybe
although
a.
C
Video
version
of
it
right
yeah,
so
we
are
still
on
a
fairly
old
version
because
yeah
we
haven't
wanted
to
go
through
another
round
of
deep
stabilization.
Basically
we'll
need
to
I
told
the
story
a
bunch
of
times,
but
we
will
need
to
upgrade
the
agents
and
the
platform
at
the
same
time,
synchronously,
which
is
not
a
great
customer
experience
because
of
the
changes
in
The
Wire
protocol.
C
A
C
Trying
to
we're
sticking
with
an
older
version
at
the
moment
and
once
we
feel
like
we've
reached
enough
stability,
that
we
feel
comfortable,
update,
updating
the
platform
and
all
the
customers.
Agents
at
the
same
time
will
do
that,
but
you
know
kind
of
the
sooner
the
better,
but
we
also
don't
want
to
do
it
twice.
So
that's
the
that's
where
we're
we're.
B
At
so
we.
C
Have
found
some,
we
have
a
couple
features:
we've
we've
had
to
sort
of
work,
be
a
little
more
creative
with
with
the
protocol
and
and
I
think.
C
The
custom
message
capability
that
I
mentioned
a
few
months
ago
and
just
haven't,
had
time
to
really
come
back
to
I,
always
considered
it
to
be
an
additive
change,
and
so
I
think
that
that
should
probably
reflect
it
in
our
in
our
notion
of
stable
that
we
we
can
have
additions
yeah,
but
you
know
we
will
have
stability
on
on
structure
and
naming
and
formats
and.
C
E
Yep
and
I
was
also
thinking,
maybe
a
diff
implementation,
different
kind
of
Agents,
like
non-standalone
agents,
I,
think
there's
talk
about
implementing
op-amp
for
the
SDK,
for
example,
I
wonder
if
we
will
find
some
use
cases
there
that
make
it
significantly
different
from
from
The
Collector
use
case.
What
do
you
think.
B
D
For
what
for
what
it's
worth
like
we've,
the
protocol
as
it
sits,
is
quite
General,
like
it
it's
quite
flexible
and
that
it's
a
fairly
simple
protocol
and
then
we've
also
introduced
things
like
custom
messages
to
to
cover
the
use
cases
we
didn't
account.
For
you
know:
we've
got
Preamble
or
headers
introduced
for
future
capabilities
like
it.
D
It
seems
like
to
Grant
and
group,
have
done
a
good
job
of
kind
of
foreseeing
possible
issues
down
the
road
and
have
created
solutions
for
problems
we
may
not
yet
have
but
I
through
multiple
different,
like
iterations
and
pocs,
and
we
are
delivering
a
version
of
this
to
our
customers.
Quite
soon,
I
haven't
encountered
anything.
That's
like
Whoa
We
need
to.
D
You
know,
adjust
the
protocol
so
for
what
it's
worth,
I
I'm
not
too
concerned
I
I
would
be
fine
if
we
just
slapped
the
stable
label
on
it
today,
but
I
think
it's
it's
reasonable
to
say
you
know
we'll
get
it
some
version
of
this
into
the
core
collector
and
perhaps
get
more
customer
use
before
we
do
it.
I'm
I'm
cool
with
that
too,
we're
not
going
to
wait
until
it
has
the
stable
label
on
it
to
put
it
to
use,
at
least
at
some
capacity.
B
Okay,
so
maybe
I
guess
I
personally,
would
feel
more
comfortable
when
there
is
an
op-amp
extension
implementation.
I
would
not
necessarily
wait
months
after
that
to
hear
from
customers
about
problems,
because
I
I
don't
know
right
exactly
when
we'll
start
using
it
in
what
capacity,
but
once
the
oil
pump
is
also
in
the
collector
code
base,
and
let's
say
we
we
connected
with
with
some
even
experimental
backend
to
show
to
demonstrate
how
it
works,
doesn't
necessarily
have
to
be
something
that
a
vendor
sells
right.
Let's
say
right.
D
B
Yeah
I
think
so
yeah,
not
necessarily
the
supervisor
even
I.
Think
because
that's
that's
yes,
useful,
but
I,
don't
think
everybody
needs
it.
So
I'm
looking
here
more
of
a
sort
of
a
not
just
technical
validation
but
sort
of
a
validation
from
the
perspective.
Yes,
we
recognize
you
are
important
enough
and
good
enough
to
be
included
in
the
collector
code
base
right.
That
sort
of
validation,
I
think
that's
also
important.
B
B
D
Pretty
something
soon
I,
actually
just
gotta
pick
it
up
just
bringing
up
the
pr
right
now.
So
I
can
take
the
first
round
of
feedback
and
and
update
a
little
bit,
but
I
need
to
catch
up
in
the
status
of
the
not
necessarily
blockers,
but
the
associated
open
issues
around
it.
For
instance,
getting
access
to
the
instance
you
had
and
getting
access
from
an
extension
to
the
effective
config,
yeah
I
I,
don't
know
what
the
status
is
of
those
so
I
need
to
catch
up.
Yeah.
A
A
D
A
D
A
C
I
think
from
our
perspective,
like
you
know,
by
the
end
of
January,
would
be
great,
so
if
that,
if
those
you
know
that
next
five
six
weeks
helps
to
get
a
little
more
confidence
and
instability,
I
think
that
that's
fine.
B
Okay,
in
the
meantime,
I
think
we
should
write
down
what
the
stability
means
for
us
just
in
case
the
otlp
is
not
ready
when
we
are
ready,
otherwise
to
do
the
release.
Let's
have
that
discussion
happening
so
that
we
we
have
the
definition
for
ourselves
and
then,
when
the
the
extension
is
there
we're
happy
with
the
definition
of
stability.
There's
nothing
blocking
us.
I
say
we
just
go
in
and
Market
as
stable.
B
Okay,
cool
I
can
I
can
start
a
PR
that
defines
what
stable
means
for
us.
We
can
keep
it
in
draft
for
now.
Maybe,
okay,
cool,
yeah,
good
you're,
saying
something.
B
All
right,
so
the
third
one
I
have
is
about
yeah.
Well,
there's
a
there's,
an
open
issue
in
the
or
TLP
Repository.
That
argues
that
the
generative
products
should
not
be
exposed
in
the
API
that
that
is
accessible
to
the
end
user.
There's
a
long
discussion
there
with
a
few
I
guess
a
couple,
maybe
arguments
the
primary
argument
that
I
see
there
is
that
when
you
do
that,
you
are
forcing
the
whoever
consumes
your
library
to
also
take
a
transitive
dependency
on
protobots
and
the
way
that
openlantry
language
libraries
are
structured.
B
For
us,
that
argument
doesn't
really
apply,
I
guess
because
you're
using
the
the
entire
implementation
one
way
or
another,
so
there's
no
way
to
to
have
a
whatever,
whatever
agent
that
uses
no
pump
implementation,
without
also
depending
on
the
product
buff
Library,
which
is
I,
think
totally
fine.
That's
that's
expected
anyway.
What
I'm
saying
is
that
the
primary
argument
that
I
say
see
there,
which
says
why
the
product
Buffs
can
be
used
in
the
API
doesn't
apply
to
us.
B
So
I
would
like
to
make
this
clear
in
in
our
definitions
right
in
in
our
spec.
You
know
probably
in
the
spec,
because
it
applies
to
more
than
one
language,
although
it's
about
implementation,
more
sort
of
some
sort
of
a
policy
right
where
we
say
that
we
know
we
saw
this
issue
raised
in
the
with
regards
to
otlp
and
we're
doing
it
differently
because
of
this,
and
that
right,
one
of
the
arguments
why
we're
doing
it
differently
is
what
I
said.
But
I
would
like
some
other
support.
B
I
believe
you
guys
discussed
this
in
the
past.
So
if
you
have
any
other
things
that
can
help
us
justify,
this
decision
would
be
very
useful.
I
I
think
I
created
the
an
issue.
Yes
I
linked
the
issue
there.
So
if
you
know
of
what
the
reasons
should
be
for
us
would
be
great.
If
you
could
comment
on
that.
E
Yeah,
the
funny
thing
I
think
one
of
the
points
you
make
in
the
in
that
issue
is
that
the
implementation
is
more
more
complex
because
you
had
a
layer
of
abstraction
and
it's
not
completely
trivial.
We
basically
need
to
have
a
mapping
of
you
know,
classes
or
data
structures
that
one-to-one
with
the
produce,
and
it's
yeah
difficult
to
maintain.
Well.
B
B
B
Anyway,
if
you
can
think
of
anything
else
as
a
justification,
just
just
comment
from
it
or
I,
don't
know
just
support
the
existing
arguments
or
whatever
it
is
right.
Express
your
position
and
I'll
just
make
sure
that
it
is
known
outside
this
work
group
so
that
it's
not
a
surprise
to
someone
else
that
they
come
back
and
say
we
have
this
open
Telemetry
policy
which
you're
violating
I
don't
want
to
be
in
that
situation.
That's
what
I'm
trying
to
agree.
C
I
mean
the
way
I
I
know
I
mentioned
this
a
couple
weeks
ago,
but
from
my
perspective,
the
the
Specter
finds
the
transport
layer.
As
you
know,
any
encoding
as
part
of
so
you
know
the
the
binary
format
of
the
transport
layer
is,
is
paragraph
and
and
so
it's
a
it's
a
critical
component
of
any
any
language
implementation
of
this
protocol.
C
It's
different
in
The
Collector,
where
otlp,
receiver
and
exporter
are
optional
and
and
not
necessary
to
make
good
use
of
The
Collector,
but,
and,
and
and
and
and
P
data
is
used
as
an
internal
data
representation
of
telemetry
independent
of
the
ostlp
protocol
encoding
so
in
in
that
sense,
it
I
think
it.
It
makes
sense
that
they
have
sort
of
a
The.
Collector
has
a
working
data
model
and
a
separate
transport
data
model.
But
in
our
case
the
the
protocol,
the
you
know,
the
spot
really
defines
the
protocol.
The
protocol
is
protobuf.
C
Right
I
mean
I
could
imagine
if,
if
we
decided
not
to
use
protobuf,
we
would
then
need
to
implement
our
own.
You
know
data
structure
encoding
that
was
a
one-to-one
binary
match
with
protobuf,
because
it
is
is
defined
as
protobuf.
So
yeah,
it's
not
really
just
I,
don't
see
a
way
of
getting
you
know.
Removing
the
dependency
from
from
the
library
would
would
only
require
us
to
implement
photobuff
ourselves,
which
is
also
not
something
we
want
to
do
so
well,.
C
B
C
B
B
E
Ahead,
the
left
side,
yeah.
The
last
item
is
mine.
We've
been
discussing
this
a
bunch
of
times,
and
you
know,
tickets
and
I
also
brought
it
up
yes,
last
week,
a
couple
of
weeks
ago,
in
the
last
six
and
and
you
were
in
present
tigrant
but
kind
of
we
all
kind
of
agreed
that
it
would
be
useful
to
have
some
agent
specific
resource
attributes
as
part
of
the
open
protocol,
and
so
I
was
thinking
so
yeah.
What
what's
the
best
way
to
to
actually
put
this
into
place?
E
My
first
intuition
was
to
add
you
know
semantic
conventions
and
agents,
resource
attributes
where
we
would
add
the
type
of
the
agents
and
and
the
distribution,
and
maybe
some
more
things.
If
you
have
some
ideas
and
I
was
wondering
if
I
should
go
ahead
and
make
the
pr
or
if
this
requires
more
conversations
or
write
an
issue,
maybe
in
a
semantic
convention.
First
foreign.
B
We
should
try
to
put
this
into
the
hotel's
semantic
conventions.
If
we
fail,
then
our
own
spec,
Oppam
spec,
is
also
not
a
bad
place,
but
let's
try
first
to
make
this
happen
in
the
hotel.
If
it's
considered
to
be
kind
of
common
enough,
it's
so
if
you
call
it
an
agent
dot,
something
that
you're
implying
this
is
generic
right,
it's
not
just
for
open,
but
then
the
question
is
okay.
What
are
other
examples
where
this
can
be
useful,
yeah,
not
just
all
pump?
B
Maybe
there
are
right
and
maybe
that
the
people
believe
that
it
is.
It
is
something
that
has
a
place
in
open
Telemetry
as
a
generic
concept
like
the
agent
is
a
concept
to
recognize
and
we
want
to
record
its
its
attributes.
There
I
think.
Let's
do
that
right.
Let's
file
an
issue,
explain
what
is
it
that
we
want
to
do?
B
What's
the
reason
where
this
is
coming
from
that
it
was
raised
in
opam,
you
can
also
file
a
draft
PR
I,
guess
showing
how,
because
you
already
kind
of
have
it
right
and
and
let's
discuss
there
right.
B
Let's
see,
I
am
not
sure
what
the
reaction
to
that
is
going
to
be,
depending
on
what
what
the
reaction
is
we'll
decide
where
we
go
right,
we
either
I
guess
there
may
be
sort
of
a
reaction
that
no
this
doesn't
belong
to
open,
Planet,
systematic
conventions
at
all,
and
then
we
may
stop
there
right-
or
maybe
it's
more
like.
Oh
maybe
that
yeah.
This
is
a
good
idea,
but
the
main
kind
of
sounds
well
not
the
best
name.
C
E
B
So
we'll
need
to
discuss
that
part.
Let's
take
some
something
similar
but
different.
Like
a
database
right,
a
database
is
recorded
using
attributes,
let's
start
with
DB
daughter
or
something
like
that,
right,
I,
don't
think
we
have
database
version
as
an
attribute.
Let
me
try
to
find
it.
Where
is
it?
What
is
the
database
thing.
B
Yeah
it's
in
the
trace.
Okay,
we
have
a
version
there.
We
don't
yeah,
we
don't,
but
the
databases
also
have
versions
so
I
think.
The
idea
here
is
that
you
use
the
generic
attributes,
things
like
service
dot
version,
and
if
the
generic
one
doesn't
exist,
then
you
use
the
technology
specific
attribute
like
the
DB
dot
system,
right
which,
which
is
the
name
of
your
orb
of
your
database
I,
think.
A
E
B
E
B
So
yeah
the
sdks
have
their
own
set
of
attributes
that
are
so
you're
supposed
to
Define
like
the
SDK
language
name,
the
version,
if
you
look
at
it,
what
is
it?
I
lost
it
again
anyway,
there
is
a
bunch
of
those
that
you're
supposed
to
record
if
your
inflammatory
SDK
so
I
I
would
start
with
that
and
also
start
small
right.
We
can
add
more
later.
If
conceptually
it
is
acceptable
to
the
for
the
community
to
have
this
attributes
in
Hotel
conventions,
then
then
we
can
extend
them
in
the
future
with
more
I
guess
whatever.