►
From YouTube: 2022-11-02 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
A
B
Do
I
do
we
had
Halloween
here
so
I'm
now,
just
like
eating
all
the
leftover
candy,
so
I'm
doing
great
and
probably
with
sugar
sugar
crash
in
like
an
hour.
B
D
Yeah,
hello,
everyone,
let's
start
well,
I
have
the
first
item
there
and
it's
about
opened.
So
I
was
at
the
kubecon
last
week
and
what
was
one
of
the
interesting
things
was
a
lot
of
interesting
in
agent
management
in
our
pump
and
I
wanted
to
discuss
with
this
sig
and
with
maintainers
and
approvers
in
particular.
Whether
what
do
you
think
what
we
think
about
it
and
whether
we
are,
we
think
it
needs
to
be
a
bit
higher
priority
in
our
list
of
things
that
we
want
to
implement.
D
There
are
a
number
of
things
that
block
appropriate
implementation
right
now.
There
are
two
directions
possible
here:
one
is
in-process
implementation
or
fall
pump
inside
the
collector,
either
as
an
extension
or
as
a
config
provider
or
as
a
combination
of
those
things,
and
another
direction
is
out
of
process
with
with
a
separate
supervisor
process.
We
discussed
this
briefly
in
the
past,
but
we
didn't
make
a
lot
of
progress
here.
So
there's
a
number
of
missing
capabilities
here
in
The
Collector
with
either
of
these
approaches.
D
We
we
can't
actually
do
a
proper
implementation
yet
so
what
I
want
to
ask
is
whether
it
is
okay
for
us
to
consider
this
to
be
a
bit
more
important
than
than
we
thought
it
is
and
and
and
actually
work
on
the
on
unblocking
these
capabilities.
I
I
can
come
up
with
an
actual
actual
list
of
what
needs
to
happen
like
what
is
the
actual
blockers?
I,
don't
have
it
yet,
but
I
just
wanted
to
maybe
gauge
the
interest
from
the
from
the
maintainers
and
approvers.
What
do
you
guys
think.
D
I
think
it's
fairly
independent.
It
doesn't
need
to
block
the
release
in
any
way
and
I,
don't
think
it's
more
or
less
independent.
That
I
would
say.
That's
my
feeling
at
the
moment.
I
don't
think
there
is
a
lot
of
interaction
with
the
rest
of
the
things
that
we
do
for
1.0,
particularly
with
paid
P
data.
There
is
no
intersection
at
all,
I,
don't
know
if
elsewhere,
somehow
it
can
interfere
with
that.
D
D
There
is
some
help
needed
in
The
Collector,
like
the
supervisor,
for
example,
like
small
things,
needs
to
know
the
version
of
The
Collector
executable,
which
can
be
either
a
runtime
sort
of
information
where
the
supervisor
queries,
The,
Collector
or
somehow
statically
embedded
somewhere
in
the
packaging
right.
This
sort
of
things,
I
I,
don't
think
there
is
anything
that
somehow
requires
a
major
refactoring
or
can
block
our
one
dot
or
relays
in
any
way.
D
I
hope
it
doesn't
require
breaking
changes
like,
for
example,
yeah.
It
may
like
there
is
there's
things
that
are
related
to
doing
this,
which
we
wanted
to
do
anyway.
One
example
is
the
component
status
reporting.
Remember
there
was
this
proposal
to
allow
the
components
to
to
report
their
own
status
and
then
for
other
interested
components
to
subscribe,
to
register
and
listen
on
those
events,
so
that
that
is
I
think
useful
on
its
own
independently
from
this.
D
But
the
old
pump
would
use
this
as
a
way
to
figure
out
the
health
of
the
collector
because
reporting
the
health
of
the
of
the
collector
is
part
of
the
op-amp
protocol.
So
things
like
this
right
and
that
the
status
reporting
I
believe
the
way
that
it
was
proposed
was,
in
addition
to
the
host
interface.
D
So
that
may
be
a
breaking
change
to
the
host
right.
That's
that's
in
the
core.
C
D
D
Just
yeah
the
idea
is
that
the
idea
is
that
the
collector
becomes
manageable,
using
a
A
system
that
that
works
through
all
pump
protocol.
The
Collector
becomes
a
client
of
opamp
protocol,
either
directly
by
implementing
the
oil
pump
logic
inside
the
collector
or
by
implementing
that
logic.
The
client-side
logic
in
a
separate
process,
which
we
call
a
supervisor
which
then
manages
the
collector's
process.
The
way
that
it
needs
to
manage
the
old
pump.
D
The
functionality
of
our
pump
is
basically
status
reporting,
so
the
health
of
the
of
the
of
the
collector,
whether
it's
up
or
and
running
whether
it's
healthy
or
no
reporting.
The
current
configuration
receiving
a
configuration
from
a
remote
location,
applying
that
configuration
to
The
Collector,
and
these
are
separate
capability.
It
is
in
all
pump.
They
do
not
have
to
implement
it
all
together,
you
can
be
selective
about
what
to
implement,
so
it
is
completely
fine
to
have
a
subset
of
those
capabilities.
D
So,
for
example,
inside
the
collector,
we
may
decide
that
we
want
to
have
a
status
reporting
so
that
you
can
observe
your
collectors
to
see
how
they
are
doing,
whether
they
are
healthy
or
no.
But
we
do
not
want,
for
example,
to
implement
accepting
remote
configuration
because
we
believe
that
that
may
be
a
security
risk
or
we
do
not
want
to
implement
the
auto
updating.
That
is
also
another
capability
that
opamp
offers.
So
it's
up
to
us
to
decide
which
subset
we
want
to
support
in
The,
Collector
and
in
particularly
in
process.
D
Implementation
of
oil
pump
may
be
different
from
the
out
of
process
supervisor
based
implementation
and
in
reality
the
complete
implementation
of
raw
pump
likely
requires
that
super
advisor
based
approach,
because
you
need
to
be
able
to
update
the
executable,
and
that
is
done.
That
is
best
done
when
you
have
a
separate
process
doing
that
right,
it
seems
like
there
is
an
appetite
for
both
of
these
approaches.
D
Some
people
want
to
have
a
simple
solution
where
things
live
inside
the
collector
and
in
all
it
only
does
it
supports
us
the
subset
that
is
about
studies
reporting,
but
some
other
people
also
prefer
to
have
the
full
implementation
of
The
Collector
so
that
they
can
manage
their
Fleet
of
collectors
at
scale
so
that
you
can
push
out
the
configurations
from
your
server
to
the
collectors
push
out,
maybe
even
updates
of
executables
or
new
versions
of
the
collectors
to
the
hosts,
which
are
running
those
collectors
and
again,
but
that
it's
it's
likely
going
to
be
the
choice
of
the
end
user,
which
capabilities
they
want
to
support
so
we'll
we
will
need
to
make
those
user
configurable
options
on
the
client
side.
D
When
you
deploy
your
collectors
for
the
for
the
first
time,
you
can
make
a
choice
about
I
want
to
support
status,
reporting
I
want
to
report
my
config,
but
I
do
not
want
to
accept
configurations
from
from
some
backend
I.
Don't
want
to
accept
executables
from
the
back
end.
So
that's
that's
the
end.
User's
choice.
G
I
I
got
the
same
impression
as
you
tigrant
at
keep
on
that
that
there
was
a
surprising
amount
of
interest
in
this
and
I
think
it
would
be
a
really
great
feature
for
us
to
have
I
think
it
would
also
create
a
nice
feedback
loop
for
us
to
make
sure
that
we're
solving
some
of
the
other
things
that
you've
mentioned,
like
like
status,
reporting
and
sort
of
the
more
real
world
management
considerations
that
we
might
be
overlooking.
If
we're
not
supporting
it.
D
D
So
I'm
happy
to
draft
some
sort
of
a
plan
here
about
what
what
exactly
is
necessary
a
list
of
tasks
and
issues
list
of
blockers,
that
we
need
in
The,
Collector
and
then
and
then
lead
the
I
guess
that
effort
myself,
but
I
need
support
from
you
guys,
because,
because
this
eventually
will
become
PR's
and
it
will
need
to
be
reviewed
and
approved.
This
is
kind
of
I
I'm,
trying
to
figure
out
whether
you
believe
it.
This
is
the
right
time
to
work
on
this
I
personally.
D
Do
but
I
want
to
make
sure
that
you
guys
also
believe
in
that,
and
we
can
work
on
this
set
of
features
essentially.
A
D
A
D
D
The
difficulty
we
have
here
is
that
I
see
also
a
number
of
people
who,
like
the
simpler
option
so
we'll
it
probably
there
needs
to
some.
We
need
to
do
some
sort
of
negotiation
here
to
see
whether
there
is
really
a
need
to
have
both
I
would
prefer
not
to
do
both
right,
because
it's
it's
extra
effort.
D
I
Usually,
there's
only
I'm
only
I'm,
the
only
Pablo
but
yeah,
so
I
just
wanted
to
get
your
feedback
about
a
proposal.
I
have
to
generate
and
create
yaml
files
that
describe
our
component
configs.
I
So
let
me
just
show
you
real
quick
here.
If
I
can
share
my
screen.
I
Okay,
so
so
on,
The
Collector,
all
the
well.
A
lot
of
our
components
have
a
metadata
di
gaml
file.
That
looks
like
this
and
we
generate
code
based
off
of
the
metadata.yaml
file.
I
So
my
proposal
is
to
create
it
is
to
create
a
make
file
Target
that
generates
an
additional
metadata.yaml
file,
but
for
for
the
configuration
for
that
component,
so
this
would
create
basically
for
every
collector
component,
a
CFG
metadata.yaml
file,
and
the
file
looks
like
this.
This
is
an
example
for
the
Apache
receiver.
It
basically
contains
all
of
the
godoc
or
the
the
configuration
type
itself
and
for
all
the
fields
and
then
for
all
the
sub,
all
the
subtypes
as
well,
and
it
creates
kind
of
like
this
tree.
I
So
the
idea
is
create
them
basically
do
one
big
PR
that
generates
all
these
metadata
yaml
files
number
one
number
two
would
be
create
well,
create
the
make
file
Target
and
then
basically
enforce
that
these
these
animals
are
up
to
date,
anytime,
either
a
configuration
is
changed
or
a
component
is
added
and
that's
pretty
much.
It.
I
Well,
I
I!
Guess
we
don't
have
to
commit
them,
I
mean
there's,
there's
lots
of
options
here.
It
just
seems
like
it
could
be
useful
for
consumers
of
this
yaml
file
to
not
have
to
generate
them,
but
interested
in
your
feedback.
I
Another
option
for
us
is:
we
could
just
generate
all
these
yaml
files
in
our
like
for
for
Splunk.
We
could
just
generate
all
these
yaml
files
in
our
Splunk
repo,
but
I
wanted
to
propose
and
see
if
the
community
was
interested
in
having
these
yaml
files
be
basically
just
pre-generated
and
lived
next
to
the
metadata
gamified.
I
H
We,
the
question
for
for
us,
is:
do
we
want
to
publish
this
on
the
website
and
do
we
have
a
tool,
because
if
we
do
have
a
tool
to
publish
this
on
our
website
and
we
connect
these
yaml
files
directly
to
the
website,
it
may
be
very
interesting
into
into
connecting,
and
then
we
have
a
use
case
for
for
for
putting
them
into
the
repo,
otherwise
I
I
believe
I.
Agree
with
that.
In
this
point
like,
why
do
we
put
them
into
the
rep
or
if
we
don't
use
them
at
all
in
our
organization.
H
Mean
if
we,
if
we
practice
and
so
on,
if
we
include
this
into
the
readme
of
the
component,
somehow
we
do
some
magic
and
we
import
this
into
the
readme
of
the
component
and
we
render
it
so.
Essentially
we
have
this
yaml
file
and
then
in
the
readme,
I
put
a
section
and
then
hence
I
see
the
config
nicely
rendered
and
stuff.
H
Then
I
can
see
a
reason
to
have
these
generated
files
without
that
it's
hard
for
us
to,
as
as
the
community
I
remember
said,
already
that
it's
hard
to
us
to
justify
maintaining
this.
I
Of
configuration,
it's
not
I,
don't
think
it's
a
requirement.
I
mean
it
can
just
be.
You
know.
Whatever
logic,
we
have
to
generate
human
readable
content
in
a
readme
that
can
just
run
dynamically,
does
not
have
to
you
know
deserialize
the
animal
it
can
just
do
the
introspection.
I
You
know
as
it's
needed.
Okay,.
C
Probably
can
go
ahead,
I
was
sorry.
I
was
I
was
saying
that
we
probably
can
have
this
tool
to
work
in,
like
several
options.
First
option
is
to
generate
these
metadata
files.
Another
option
is
to
generate
human
readable
yaml
files
that
we
actually
can
can
like
enforce
and
put
into
readme,
as
a
section
and
like
generate
make
Target
would
work
for
that
use
case,
but,
like
this
metadata,
yaml
option
of
generation
would
be
like
will
be
just
optional
and
not
not
run
always.
J
Right,
what
would
be
interesting
to
me
is
perhaps
using
this
generation
at
build
time
for
releases
and
embedding
the
generated
configuration
structures
into
the
binary
so
that
we
can
either
have
a
command
that
can
spit
out
what
are
all
of
the
config
options
that
this
particular
collector
can
support,
or
have
other
tooling
that
builds
on
top
of
that.
H
Then
then
I
think
it
will
be
cool
to
have
this
config
metadata
that
yaml,
because
then,
then
we
can
print
it
from
CLI,
for
example.
Okay,
it's.
F
J
Yeah
yeah
and
the
thing
that
I
really
like
about
that
is
that
it
then
ensures
that
you've
got
the
configuration,
that's
generated
from
the
same
code
that
is
running
in
the
binary
and
only
the
bits
that
are
in
that
binary.
So
if
you
included
a
subset
of
components,
you
only
get
the
configuration
for
those.
H
Okay,
that
needs
a
bit
of
another
helper
that
we
need
to
see,
but
anyway,
for
doing
that,
we
may
need
some
more
changes,
but
I
think
it's
a
cool
feature
to
have.
E
I
Okay,
yeah
so
yeah
we
can.
We
can
just
have
this
functionality
available
as
a
command
and
have
sub
commands
to
generate
different
kinds
of
output
but
and
we'll
you
know
we'll
do
that
PR
that
one's
in
progress
but
then,
as
far
as
like
requiring
the
config
metadata
yaml
to
be
you
know
actually
in
pre-generated
and
in
each
component
directory
we
can.
We
can
not
do
that.
That's
fine!
So,
okay,
great!
C
Another
thing
about
this
I
I
was
like
just
one
point
towards
having
this
regenerated
is
that
we
it's
it
becomes.
If
configuration
has
changed,
it
becomes
clear
that
the
configuration
this
particular
component
has
changed.
We
maybe
have
like
some
pull
request.
Labels
like
saying
like
hey
configurations,
change
it
and
take
a
look
into
that.
If
it
does,
if
it's
not
breaking
or
something
like
that,
but
probably
it
doesn't
work.
Even
this
checked
out
will.
H
C
H
Cool
okay,
so
what
we
agree
is
the
tool
is
useful,
Let's,
let's
figure
out
in
the
next
in
the
next
steps,
how
we're
gonna
use
it.
We
have
couple
of
ideas
and
somebody
has
to
lead
the
the
effort
of
using
this.
But
for
the
moment
we
agree
to
have
the
tool.
K
Hey
everyone,
so
I've
been
working
on
trying
to
make
the
kind
of
issue
triage
and
management
process
a
little
bit
more
self-service
in
the
contribute,
repo,
so
I
kind
of
wanted
to
publicize
a
couple
of
the
things
that
we've
done
get
any
ideas.
If
anybody
has
any
and
then
kind
of
look
at
kind
of
what's
next
I
look
for
input
on
what
we
can
do
to
improve
it
a
little
bit
further.
K
So
the
two
things
that
have
been
implemented
are
that
you
can
add
more
labels
through
comments,
namely
you
can
add
the
component
labels
and
that
will
ping
the
code
owners
when
you
add
that
so
this
is
mainly
for
anyone
who
doesn't
have
label
access
in
the
repo
and
then
likewise
issue.
Openers
are
now
able
to
select
a
component
or
multiple
components
from
a
drop
down.
Labels
will
be
added
to
the
issue
when
it's
opened
and
then
will
be
pinged.
K
The
goal
here
is
that
code
owners
should
be
able
to
more
effectively
and
more
often
be
able
to
be
notified
of
when
issues
for
their
components
come
up
and
triage.
Those
as
opposed
to
triage
is
having
to
always
take
a
look
next
up,
and
this
is
kind
of
what
I
was
looking
for.
Input
on.
There
are
additional
labels
that
are
usually
involved
in
an
issue
and
so
I'm
looking
for
input
as
to
whether
we
want
to
make
these
accessible
through
comments
so
that
you
can
add,
remove
them.
K
Whether
there's
some
concerns
around
that
and
just
what
sorts
of
labels
would
be
useful.
So
one
set
are
the
priority.
Labels
I
think
that
that
might
might
be
helpful
to
add
through
comments.
Additionally,
if
we
allow
adding
and
removing
the
needs
triage
label
through
a
comment,
then
that
would
allow
that
would
basically
allow
it
so
that
if
codones
remove
that
label,
then
triagers
can
go
through.
Basically
just
the
kind
of
few
that
haven't
been
seen
or
aren't
related
to
a
particular
component.
K
This
also
could
apply
to
other
labels
I'm
just
kind
of
looking
for
anyone's
feedback
if
they
have
any
opinions
on
whether
those
shouldn't
be
modifiable
through
a
comment.
J
K
Makes
sense:
okay,
I'm
good
with
that?
What
about
needs
triage?
H
A
way
to
signal
that
somebody
from
from
the
repo
with
knowledge
about
this
project
looked
at
this,
so
essentially,
if
I
create
a
report
and
another
maintainer,
don't
have
any
right
access
to
to
modify
labels
it.
It
looks
like
I'm,
a
pretty
Outsider
of
the
the
work
here.
K
So,
if
we're
going
to
let
anybody
that
isn't
that
doesn't
already
have
labeling
access
change,
that
it
would
probably
be
a
code
owner,
but
probably
the
code
owner
has
looked
at
the
issue
determined
that
they've
figured
out
a
course
of
action
forward.
K
H
Issues
yeah.
That's
that's
very
good
point
like
if
we
can
limit
this
to
the
code
owners
I
think
it's
it's
a
great
feature.
K
So
that
is
a
little
tricky
I
think
at
some
level
we
kind
of
have
to
trust
it.
An
issue
opener
is
going
to
behave.
We
did
just
add
the
ability
to
add
what
do
you
call
it
component
labels,
and
so
you
could
actually
use
that
to
add,
like
a
bunch
of
those,
if
you
really
wanted
so
I
think
at
some
level
there's
kind
of
an
expectation,
but
we
could
do
some
checks
in
there
in
the
future.
K
Yes,
the
label
action
would
be
what
is
updating
the
label
on
the
issue,
so
it
would
go
through
either
a
preset
list,
so
we've
got
help
wanted
and
good
first
issue
right
now.
K
Could
maybe
add
additional
ones
if
we
wanted
I'm
suggesting,
perhaps
needs
triage,
would
be
helpful
here.
H
K
I'm
not
sure
I
have
a
good
answer
to
that
I
mean
I,
figured
I
mean
at
the
end
of
the
day.
Somebody
could
write
a
comment
on
a
label.
They
can
ping
people
I
mean
it
is
open,
so
the
label
isn't
that
much
more
of
a
the
labels
that
we've
exposed.
Aren't
that
much
more
of
a
a
risk?
If
you
will.
A
K
K
Okay
and
looking
for
input
on
are
there
any
other
labels
that
people
think
would
be
helpful
in
managing
an
issue
looking
for
a
input
from
code
owners,
approvers
maintainers,
just
anybody,
that's
spending
a
lot
of
time
on
this.
K
The
only
other
type
that
you
could
change
would
be
the
issue
types.
That's
bug,
question
enhancement,
stuff
like
that
I,
don't
know
if
we
need
that
or
not,
but
I'm
not
sure.
If
this,
if
the
label
comments
would
open
up
additional
labels,
that
people
might
find
helpful,
it's
really
more
of
an
exploratory
question.
J
C
I
H
C
H
Let's
start
with
the
two
that
we
decided
everyone
even
cool
if
anyone
else
has
no
other
opinion,
happy
to
hear.
H
Especially
when
people
are
looking
for
the
community
to
jump
in
and
put
some
thoughts,
there.
E
I
know
there
are
some
other
cigs
that
are
kind
of
interested
in
the
way
that
contrib
has
started
to
manage
its
code
owner
stuff
without
prowl,
and
so
some
of
this
may
end
up
getting
useful
or
being
useful.
At
least
this
issue
stuff
that
we're
that
we've
been
doing
may
end
up
being
useful
for,
for
other
sakes,
not
just
collector
as
well.
K
Yeah
I'm
keeping
an
eye
for
that
I'm
kind
of
waiting
to
see
how
just
kind
of
waiting
for
things
to
settle
for
us
and
then,
if
it
looks
like
it's
good,
that's
I
agree.