►
From YouTube: 2023-02-16 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
D
Also,
we
have
our
agenda
doc
in
the
chat.
If
anyone
wants
to
add
anything
there.
D
So
I
think
we
can
get
started
so
hello,
everyone.
This
is
the
goob
operator
Sig
meeting
for
Thursday
February
16th
looks
like
we
only
have
one
agenda
item
today.
Benny
this
is
you
with
simplify
operator
usage.
I'm
gonna
share
my
screen
and
we
can
discuss
with
that
share
going
how's
that
sound.
C
A
Yes,
yeah,
so
what
I
did
here
was
basically
I.
Just
wrote
them
some
down
some
thoughts
that
came
up
during
the
first
M,
so
we
discussed
it
with
some
people
how
they
use
the
open,
Telemetry
operator
and
I
would
say.
A
A
common
feedback
was
that
it's
sometimes
difficult,
because
you
need
to
yeah,
basically
know
the
open
territory
collector.
So
it's
it's
not
hard.
If
you
know
what
you're
doing,
but
it's
definitely
not
trivial
to
just
go
ahead
and
yeah,
then
I
had
some
thoughts
like
for
the
instrumentation
CID.
We
have
a
dedicated
crd
and
if
it
would
make
sense
to
add
some
specific
CRTs
for
specific
use
cases.
A
For
example,
if
I
would
like
to
use
the
target
allocator
to
scrape
some
metrics
right
now,
I
need
to
have
I
need
to
set
a
different
configurations
there
and
they
all
belong
to
each
other.
So
if
I
mess
up,
let's
say
the
mode,
something
else
doesn't
work
and
back
and
forth,
and
then
also
one
thing
that
came
up
was
that
the
current
configuration,
so
the
yeah
open,
Telemetry
collector
configuration
that
we
set
is
a
string.
So
you
can't
use
it
for
templates
with
customize,
so
it
doesn't
work
so
well
and
yeah.
A
So
I
thought
maybe
it
makes
sense
and
as
an
example,
I
just
used
the
target
locator
here
and
that
we
Define
something
which
is
easy.
So
if
I
would
like
to
scrape
metrics
I
just
use
the
entries
that
are
there
and
yeah
based
on
what
I
configured
a
service
account
is
created
or
something
and
then
I
thought
it's
difficult,
because
I
don't
want
to
configure
half
of
it
in
the
configuration
on
top
and
then
still
have
this
open
territory.
Collector
configuration
on
the
bottom,
so
I
thought.
A
Maybe
there
is
a
way
to
split
this,
but
while
typing
it
I
had
some
challenges
with
the
processors,
for
example.
If
you
have
certain
processes,
we
can't
have
all
the
configurations
predefined,
it's
probably
too
much
but
yeah,
and
that
was
the
point
where
I
had
that
in
mind.
Maybe
this
destination
crd,
where
you
can
refer
to
so
then
I-
can
have
yeah
different
series
for
different
kinds
of
signals.
But
this
is
also
there
with
the
destination,
because
I
don't
want
to
repeat
all
the
time.
A
Then
the
same
stuff,
because
now
it's
split
it
into
multiple
crds
yeah.
So
it's
just
a
an
idea.
Probably
it's
not
a
proposal.
It's
more
an
idea
and
yeah
I'm
curious
to
hear
what
you
think.
D
So
my
initial
take
on
this
I
have
a
few
thoughts
I
like
the
idea
of
like
providing
more
convenience
and
typing
around
these
things.
I
certainly
think
that,
like
the
collector
config
being
a
string
is
annoying
I'm,
not
sure
our
ability
to
change
that,
though
the
thing
that
I
that
I
think
about
is
like
you
know.
D
Ultimately,
this
is
all
go
typing
and
We're
not
gonna,
be
able
to
specify,
like
the
exact
valid
configurations
for
every
processor,
because
then
you'll
be
able
to
like
or
every
component,
because
then
you
can't
bring
in
custom
components
anymore
right
because
it
won't
be
valid
in
the
spec.
D
D
If
that
makes
sense,
you
can
maybe
require,
like
you
know
the
top
level,
directives
of
processor
or
receiver
processor,
exporter
extension
service
and
then
the
pipelines
you
might
be
able
to
like
get
that
to
be
more
typed.
But
it's
like
not
a
ton
of
detail.
D
I
also
wonder
about
what
some
other
operators
do
for
these
types
of
convenience.
Things
like,
for
example,
the
Prometheus
operator
is,
is
like
kind
of
just
passing
a
bunch
of
flags
to
run
Prometheus.
It
doesn't
really
do
a
lot
of
conveniences
for
you,
I
would
say
it
does
I'd
say
a
similar
level
of
convenience
that
we
do
now
where
it's
like,
for
example,
with
the
health
check.
D
If
you
set
up
a
health
check,
extension
It'll,
like
give
you
a
liveness
pro
like
that
that
type
of
convenience
I
think
the
thing
that
I
would
worry
about.
If
we
provide
this
level
of
convenience
is
someone
it
doesn't
fit
exactly
what
someone
wants
to
do
and
then
it's
like
we're
just
constantly
adding
more
and
more
features
until
we
get
back
to
the
like
to
the
thing
that
we
have
now,
if
that
makes
sense,.
A
Yes,
there's
what
I
thought
there
was
maybe,
instead
of
having
an
own
crd,
that
we
reconcile
with
all
the
magic
that
happens
behind.
This
could
also
be
implemented,
maybe
as
some
kind
of
yeah
abstraction
for
the
current
crd,
so
which
makes
the
current
one
just
simpler.
So
we
would
then,
in
the
background,
we
would
create
the
current
Alpha
version.
One
open
Telemetry
collector,
so
you
still
have
the
freedom
if
it
doesn't
match
your
needs
to
go
back
and
yeah
to
find
it
on
your
own.
B
D
Yeah
I,
wonder,
though,
if
like
this
would
be
solved
by
us
having
a
a
more
opinionated
Helm
chart
to
go
with
it
like,
for
example,
I
have
a
chart
that
I
wrote
that
I've
been
offering
to
donate
oops
that
I've
been
offering
to
donate
to
the
home
charts
group.
D
That
does
something
similar
where
it's
like.
You
know,
give
me
auto.
Instrumentation,
give
me
traces
collector,
give
me
a
metrics
collector
and
then
it
does
the
and
then
it
generates
the
necessary,
like
collectors
for
for
that
right
and
the
cluster
roles
and
whatever
and
so
I'm
wondering
if
this
is
Maybe
better
served
as
a
like
a
Helm
chart
Improvement
and
not
a
not
an
operator
Improvement
if
that
makes
sense,
but
then
again
like
not,
everybody
wants
to
install
this
via
help
right.
So.
E
Yeah,
it
feels
feels
to
me,
like
maybe,
a
combination
of
improved
Helm
charts,
improved
documentation.
More
solid
examples
is
the
way
to
go
like
this
is
a
complex
system
and
it
has
some
level
of
irreducible
complexity,
especially
since
the
collector
is
a
framework
and
people
can
build
their
own
things
on
top
of
it,
and
we
can't
really
predict
what's
might
be
needed
there.
D
Yeah,
like
one
thing,
that
would
be
great
if
we
could
do,
for
example,
that
I
think
would
get
us
to
a
much
better
spot
than
we
are
today
is
running
the
validation
on
the
config
that
we
get
as
a
string
and
then
returning
that
as
part
of
the
validating
web
hook.
But
that
would
require
us
to
start
up
a
whole
collector
and
like
pull
everything
down,
which
we
just
can't
do.
E
Would
need
a
dry
run
effectively,
which
we've
talked
about
in
The
Collector
many
times
of
having
an
ability
to
just
validate
a
config
and
return
good
or
bad.
D
E
Regarding
the
configuration
being
a
string
issue
with
the
ability
to
have
configuration
interpolated
from
any
sort
of
config
provider,
that's
available,
would
it
make
sense
to
make
something
like
a
config
map,
config
provider
and
allow
allow
users
to
specify
parts
of
their
configuration
in
a
config
map
and
say:
okay,
here's,
my
processors,
config
here's,
my
exporters
config
get
it
out
of
this
config
map.
D
And
then
we
would
like
like
merge
it
together
like
layer
it.
The.
E
The
Collector
would
do
that
yeah
I'm,
not
super
familiar
with
customize,
so
the
the
use
case
you
talked
about
with
customize
not
being
able
to
be
effectively
used
for
this
configuration,
because
it's
strings
I'm,
trying
to
think
of
ways
that
we
could
try
to
work
around
that
and
give
more
points
of
flexibility
to
users
who
want
to
use
it
in
that
way.
Mm-Hmm.
D
Yeah
I
guess
I'm
wondering
like
how
we
would
like,
for
example,
if
someone
were
to
find
just
a
processor
config
in
a
config
map
and
then
add
that
in
as
like
one
of
three
config
maps
that
they
want
to
mount,
we
would
then
like
have
to
combine
those
all
somehow
into
the
same
yaml
file
for
the
collector
right.
A
There
is
a
way
I'm,
not
100
sure,
but
there
is
a
way
to
define
files
for
specific
components
in
your
collector
configuration
so
that
it
reads.
For
example,
your
parameters
configuration
from
a
dedicated
file,
but
well
maybe
there
is
something
already
in
place
to
do
this
with
entire
configurations
for
a
receiver
for
a
processor
and
something
like
this.
E
So
I
think
that,
though
the
place
we
might
run
into
convocations,
if
we
do,
that
is
where
we
do
some
config
rewriting
in
the
operator.
I
think
the
operator
would
need
to
start
pulling
in
the
config
resolver
out
of
the
collector,
using
that
to
resolve
a
conflict
config
based
on
what
was
provided
and
then
it
can
do
rewriting.
E
B
A
Yeah,
with
using
the
hand
chart,
is
this
opinionated
way,
I
get
it
if
you
use
ham
but,
for
example,
our
customers
sit
on
openshift
and
probably
a
lot
of
them
just
use
the
operator
and
then
plane
manifests
and
with
yeah.
What
I
had
there
in
mind
with
this
side
effects,
if
I
would
like
to
have
it
as
a
premature
scrape
instance,
I
need
to
have
the
stateful
mode
and
all
the
others
don't
work.
A
D
I
think
we
have
a
validating
step
in
the
in
the
operator
or
Target
allocator
being
enabled
right
and.
A
D
Yeah
I
think
at
least
this
is
in
a
validating
web
hook.
So
someone
couldn't
like
apply
the
wrong
thing
here.
Right,
like
someone
couldn't
run
the
target
allocator
without
also
running
a
stupid
set
for
that
collector
right
and
at
least
I
give
you
like
it'll,
give
you
a
cube
error
message
back
I
think.
E
E
We
have
is
just
that
the
collector
is
such
a
flexible
thing,
especially
when
you
get
to
the
idea
of
people,
building,
custom
collectors
and
so
there's
some
level
of
irreducible
complexity.
We're
going
to
have
to
deal
with
here,
I
think
and
that
or
we
create
a
lot
of
a
lot
of
Independence
CRS
like
if
you
want
something
for
this
particular
use
case,
here's
one
that
will
do
that
for
you,
it's
not
going
to
go
anywhere
outside
of
its
bounds.
For
that
you
have
to
find
your
own.
A
Yeah,
are
there
some,
let's
say
common
use
cases
that
we
could
cover
so
some
things
like,
for
example,
scraping
metrics,
which
is
then
yeah
Limited
in
use.
So
you
don't
use
your
collector
to
scrape
metrics
for
what
traces
put
a
bunch
of
processors
in
it
all
in
one.
So
it's
that
we
have
only.
A
I,
don't
know
how
to
explain
it.
It's
for
a
few
common
use
cases,
some
kind
of
an
opinionated
crd,
so
I
didn't
plan
to
add
there
20
30,
different
crds
or
then
a
bunch
of
options
there.
Again
it's
more
for
the.
A
Probably
collecting
locks
if
you
use
The
Collector,
for
it
not
sure
if
this
is
something
that
people
do
but.
D
So
I'm
wondering
if
there's
Anthony
70,
you
said
earlier
around,
like
better
docs,
has
been
thinking
about
an
idea
that
we've
talked
about
a
lot
internally,
which
is
like
sort
of
a
spring
boot
Builder
type
thing
for
the
collector
for
those
not
familiar.
D
D
You
know
the
right
configuration
for
each
of
these
things
based
on
the
metadata
and
all
these
other
preferences,
and
you
then
you
can
also
explore
like
this
is
the
thing
that
it
will
generate
for
you
and
hear
the
dependencies
and
it's
sort
of
like
a
we're
telling
you
that
this
is
going
to
work
out
of
the
box
and
so
I'm
wondering
if
there's
something
that
we
could
do
in
the
doc
site.
E
Yes,
I
think
clay,
just
like
something
that
the
config
validator
right,
that
kind
of
goes
from
the
validation.
Half
of
this.
The
construction
have
I,
don't
think
we've
we've
at
all
talked
about,
but
would
be
interesting.
I
know
with
the
collector
Builder.
E
We
talked
at
some
point:
I
actually
built
the
hackathon
project
internally
to
have
like
a
a
web
service
or
a
website
where
you
could
go
and
say:
I
went
to
these
components
in
a
collector
and
have
it
give
you
either
a
click
or
build
or
manifest
or
a
binary
coming
out
of
it
similar
to
the
caddy
website.
I,
don't
know
if
you've
seen
the
website
for
the
caddy
HTTP
server,
where
you
can
tell
it,
you
know,
I
want
these
components
in
it
and
it
gives
you
a
custom
build
of
that.
D
Yeah,
that's
really
neat.
Some
of
this
could
be
really
cool
for
sure,
we'll.
E
Sure,
but
I
would
imagine
we
could
build
them
into
the
same
tool.
Right
have
have
you
know
one
one
part
that
has
built
the
collector
config
and
then
say:
okay
now,
do
you
want
to
build
this
into
an
operator
as
well?
Or
do
you
just
want
to
use
this
config
and
if
they
want
to
build
an
operator
config,
then
we've
got
another
set
of
board,
so
they
can
go
through
to
to
configure
the
operator.
D
E
Yeah,
even
the
hackathon
project
I
built,
got
as
far
as
building
an
API
that
could
do
this,
but
no
UI
for
it.
D
I
think
that
maybe
we
should
look
into
getting
a
better
Helm
chart
out
first
and
writing
better
docs
as
well
as
like
what
will
help
everybody
initially
and
then.
Maybe
we
can
think
about
more
examples
that
people
could
go
off
of
like
more
just
like
default
configs
that
they
can
just
copy
paste,
and
then
we
can
even
run
tests
on
those
defaults
configs,
so
that
we
know
that
they
will
always
be
valid
as
well.
So
people
update
them
as
they
update
features.
D
A
Yeah,
so
with
the
Hampshire
approach,
I'm,
not
that
happy
but
I
think
it's
still
a
good
way
to
start
so
maybe
having
some
opinionated
time,
charts
and
figuring
out,
it's
easy
to
change
right,
so
I'm
figuring
out
what
people
want
and
what
they
need,
and
depending
on
this
yeah,
probably
I
need
to
rethink.
If
there
is
some
way
to
glue
this
somehow
in
the
operator
also,
there's
better
examples.
A
Definitely
they're
always
helpful,
yeah
and
I,
like
the
generator
part,
but
there
have
one
question
so
I
can't
be
sure
that
let's
say
a
specific
receiver
is
in
my
image
that
I
specified.
How
could
this
be
solved?
Would
it
be,
then,
that
you,
for
example,
add
an
extension
which
includes.
D
Yeah
Anthony
correct
me
if
I'm,
if
I'm
wrong
here
as
well,
but
I,
think
that
there's
a
demand
in
The
Collector
binary
that
will
tell
you
the
available
components
that
isn't
just
like
run.
I
think
that
there's
a
command
for
this
I
think
I
remember
seeing
a
proposal
for
it
at
least
yeah.
E
I
I
think
that
was
added
recently.
Let
me
just
check
and
if
it
isn't,
if
you
start
a
collector
with
a
component
configured
that
doesn't
exist
in
that
collector's
set
of
factories,
it
will
error
out
immediately
and
include
a
list
of
components
available
of
that
type.
In
the
error
message,
that's
super
helpful,
I,
don't
think,
but
at
least
from
preventing
users
from
getting
into
a
situation
where
they've
got
erroring
components,
but
it
is
also
very
clear
that
it
will
fail
fast.
E
D
And
another
thing
that
that
we
could
do
if
we
did
this,
like
generator
approach,
is
actually
build.
The
image
for
people
as
well
like
we,
you
do
a
you
use
the
like
collector
Builder,
and
then
you
say
the
receivers,
processors
exporters,
extensions
that
you
want.
D
You
can
even
include
custom
ones,
just
like
how
you
install
them.
Maybe
I,
don't
know
how
that
would
work
in
this
case,
but,
let's
just
say,
no
custom
stuff
for
the
generator.
Someone
will
have
to
build
their
own
image
and
then
you
could
build
an
image
for
them
and
then
also
ship
them
a
config
as
well
in
that
world.
D
So
you
give
them
like
some
some
built
image
somewhere
and
also
the
config
for
running
that
image,
so
that
you're
sure
that
those
two
things
are
correct.
A
There's
another
thing:
it's
just.
Would
it
be,
then
a
thing
that
could
also
run
in
my
environment?
So
that's.
For
example,
the
operator
offers
this
UI
and
then
the
Builder
will
build
it
internally
for
me,
so
that
I
don't
rely
on
some
foreign
web
page
and.
E
A
D
So
maybe
this
goes
into
like
I
think
we're
starting
to
get
into
the
territory
of
the
remote
config
projects
that
I've
been
working
on,
actually,
which
is
sort
of
like
how
do
you
configure
collectors
consistently
and
the
idea
there
being
that
some,
like
external
server,
that
a
company
would
run
whether
it's
like
a
platform
or
like
an
org
themselves,
but
then
be
able
to
write
this
UI
that
we're
talking
about
to
connect
to
a
customer's
own
cluster
or
sorry,
a
user's
own
cluster?
D
To
do
this,
configuration
I
think
the
more
that
we're
talking
about
this,
the
more
that
it
seems
like
that's
what
we're
ending
up
at,
because
it
is
like
remote
config.
Ultimately,
the
goal
is
to
always
apply
a
valid
like
yeah,
a
valid
known
configuration
in
a
simple
way
and
that's
what
I
would
say
is
the
stated
goal
of
the
remote
config
project.
A
And
with
the
image
building
part,
it
would
be
the
next
component
that
you
configure
something.
This
component
doesn't
exist
in
the
current
image
and
it
would
then
also
rebuild
an
x
an
extra
image
for
you,
and
then
you
can
use
this
or.
D
I
think
the
idea
would
be
that
the
platform
provider
or
like
whoever
is
running
the
server
that
the
remote
config
Bridge
would
connect
to
would
also
provide
that
functionality,
but
it
wouldn't
be
provided
by
the
operator
so
so
that
if
someone
wanted
to
build
that,
like
as
a
component
that
someone
could
run,
they
absolutely
could.
But
it
wouldn't
be
part
of
the
operator.
It
would
just
be
like
their
own
thing.
F
I
wanted
to
chime
in
here
on
just
something
that
might
be
useful
for,
like
the
hosting
thing
it's
just.
If
there
was
a
GitHub
action,
they
did
the
building
and
Publishing
just
to
like
the
open
source,
GitHub
Docker
registry
that
might
get
most.
People
like
it
might
automate
away
a
lot
of
like
the
collector
building
Automation
in
a
way
where
people
just
run
it
on
their
own
repos,
public
or
private.
And
then
you
know
you
set
some
input,
variables
and
outcomes
an
image.
F
So
maybe
the
GitHub
action
path
for
The,
Collector,
Builder
repo,
might
be
a
really
nice
easy
thing
to
offer.
F
D
Yeah,
it's
a
pretty
nifty
idea,
because
then
someone
could
also
run
it
like.
You
would
assume
that
the
Builder
would
pull
down
like
a
git
repo
to
do
that,
so
it
could
pull
down
someone's
like
custom
code,
so
if
they
were
installing
any
of
their
own
custom
components,
it
could
also
do
that
as
well
and
then
just
build
the
image.
F
D
I
think
all
good
ideas
does
everyone
have
anything
else
that
they
want
me
to
add
and
notes
anything
else
on
the
topic.
D
Yeah,
so
the
idea
is
that
someone
who
is
running
the
actual
remote
config
server,
the
thing
that
you
know
might
be
provided
by
a
platform
that
is
the
Builder
that
we're
talking
about
here.
Essentially
where
someone
would
say
you
know,
give
me
something
that
collects
my
kubernetes
metrics,
give
me
something
that
you
know
can
accept
otlp
traces
and
then
send
them
to
destination
X,
and
then
someone
would
just
talk
to
that
thing,
which
then
applies
the
collector
in
someone's
cluster
for
them.
G
D
Okay,
yeah
yeah,
maybe
I'll,
use
a
different
word
for
this
configuring.
So
the
idea
is:
is
that
the
remote
server
that
would
connect
to
the
op-amp
bridge
the
operator
op-ampbridge?
The
remote
server
over
here
would
provide
a
convenience
to
a
user
to
help
them
easily
configure
a
collector
crd
so
rather
than
who's.
E
D
E
G
I
mean
I
think
that
that
helps
that
helps,
but,
like
ultimately,
someone
has
to
have
some
idea
of
what
is
correct,
and
that
is
what
to
me.
The
the
issue
is
about
right
is
like
how
does
someone
who's,
starting
out
figure
out
like
the
correct
way
to
deploy
the
operator
or
the
correct
way
to
deploy
collectors
with
the
operator.
D
Yeah
yeah
so
I
think
in
this
case
the
my
conjecture
would
be
that,
like
we,
as
the
operator
folks
and
collector
folks,
know
how
to
run
like
collect
your
crds
and
know
how
to
configure
these,
and
so
there
would
be
some
in
this
remote
server.
That
would
be
doing
this
translation
from
simplified
config
to
like
actual
crd
spec.
D
The
person
writing
that
code
would
know
like
this
is
the
right
way
to
do.
X
I,
don't
think
it's
like
that's
not
a
great
answer.
It's
not
like.
Oh,
there
is
some
like
actual
preventative
code
or
like
better
like
yeah.
It's
there's
not
like
a
real,
forcing
Factor
there
other
than
that
convenience
being
provided
and
I.
D
So
we're
gonna
have
some
way
to
make
that
easier,
because
then,
ultimately,
like
you're
gonna,
need
that
for
every
other
thing
like
in
what
system
would
that
convenience
live
right?.
G
No,
no
I
think
this
is
a
really
difficult
problem
to
solve
and
I
know.
We've
in
a
previous
dig
meeting
I
think
we've
talked
about
the
possibility
of
validating
configuration
more
and
it
it
seems
like
that
would
be
very
difficult,
so
yeah
I,
don't
I,
don't
have
anything
constructed.
D
Sorry,
which
is,
we
want
a
way
to
provide
a
convenience
to
users
to
translate
from
desired
features
to
actual
configuration
right,
like
that's
sort
of
where
we
started
out
and
I
think
that
that
is
what
the
remote
config
server
would
be
doing
here
and
that's
where
we
could
bake
in
real
opinions
into
like
how
these
things
should
be
done,
because
it's
the
layer
that
would
be
the
translation
between
like
user
wants
to
feature
a
to.
This
is
how
you
configure
feature
a
and
I
think.
That's
the
translation.
That's
missing
right
now,.
D
But
again,
I'm
very
happy
about
any
ideas
that
are
out
there
to
like
potentially
solve
this
one,
because
it
is
annoying
and
we
see
this
constantly
internally.
Just
today
someone
was
like
you
know.
Why
is
this
collector
configuration
failing?
It's
like
oh
you're,
trying
to
connect
to
a
Jager
back
end.
You
don't
have
a
Jaeger
back
right,
so
it's
stuff
like
that.
That
is
like
I
think
just
right
now,
a
constant
issue
that
I'm
not
sure
is
there's
a
great
way
to
solve.
D
Are
there
any
more
thoughts
that
we
want
captured
here?
Anyone
else
have
any
other
thoughts
on
this
topic.
H
I
mean
not
sure
if
heart
catering,
just
maybe
like
an
experience
of
someone
who,
like
just
recently
started
looking
at
the
operator
and
someone
who's,
not
diversity
in
working
with
operators,
I
actually
didn't
find
it
like
working
with
the
operator
that
much
complicated
than,
for
example,
Prometheus
operator
and
yeah
I.
H
My
thoughts
are
similar
to
what
has
been
already
expressed
so
I
I'm
sure
there
are
ways
to
provide
convenience,
but
I'm,
not
sure
if
you
know
if,
if
this
should
be
at
the
crd
level
and
yeah
I'm
I'm,
just
wondering
bringing
it
back
to
the
like
the
original,
the
original
idea
or
the
original
I
think
what
what
what
prompted
Bennett
to
created
the
the
issue
is,
was
the
the
feedback
from
the
people,
so
I'm
wondering
if,
if
the
the
barrier,
the
barrier
to
entries,
maybe
at
another
level,
so
not
not
at
the
level
of
the
operator,
but
maybe
at
the
level
of
of
The
Collector
or
open
Telemetry
in
general,
so
I
yeah
I'm
wondering
if
maybe
the
city
should
be
also
translated
to
outside
of
outside
of
operator.
H
If
this
is
what
what
people
are,
who
are
presenting
about
operator
and
open
Telemetry,
this
is
the
feedback
that
we're
receiving,
if
it
shouldn't
be
also
translated
outside
of
outside
of
operator,
which
I
think
part
of
this
discussion
showed
that
there
are
other
initiatives
and
ideas
going
around
that
are
not
strictly
instead
of
of
operator
project,
so
I
just
might
descent.
E
E
Good
point:
there
are
like
a
couple
levels
of
complexity
that
are
here
right.
There
are
some
that
are
just
within
the
collector
configuration
and
we
can
probably
come
up
with
ways
to
help
with
that
that
apply
whether
you're
using
the
operator
or
not,
and
then
there
are
some
that
are.
How
does
the
operator
configuration
interact
with
the
collector
configuration
that
you've
got
the
target?
Allocator
is
a
good
example
of
that
right.
You
need
some
level
of
collector
configuration
that
matches
what
you've
got
in
your
operator.
Crd
for
that
to
function
correctly.
D
I'd
have
thought
then
I
just
lost
it.
Oh
that's
like
started,
saying
it
and
then
I
just
it
was
gone.
D
Oh
I,
remember
so:
I
I
think
one
thing
that
would
really
help
here.
I
think,
regardless
of
of
all
these
other
conveniences
that
we're
talking
about-
and
it
is
definitely
the
the
thing
that
we
have
like
greater
control
over.
Is
this
right
here,
just
like
better
examples
for
common
use
cases
I
think
that
we're
lacking
in
that
a
lot
right
now
there
is
the
pr
open.
D
Here
for
the
improved
readme
for
the
Target
allocator,
which
I
think
will
help
with
this
for
sure
this
does
have
like
more
examples,
more
explainers
about
like
how
the
configuration
does
get
generated,
but
beyond
that
I
think
it
would
be
really
good
to
have
like
just
a
top
level
examples
folder
that
contains
just
crd
or
maybe
just
manifests
of
like
if
you
want
to
use
the
target
allocator
to
do
these
things.
These
are
the
required.
This
is
what
it
can.
D
A
sample
configuration
looks
like
and
will
work
out
of
the
box
if
you
want
to
just
collect
otlp
traces
and
forward
to
another
daily
back
end
like
that
type
of
thing,
just
top
level.
Examples
I
think
it
could
be
really
really
helpful
here
to
at
least
give
people
a
better
starting
point
to
Anthony's
point
about
like
how
do
we
make
it
easier
to
do
the
right
thing
just
give
people
like
the
right
thing
more
because
I
don't
think
you
do
that
a
lot
right
now.
D
I
can
make
an
issue
for
this.
One
and
I
can
Circle
back
with
the
helm
people
on
this
one,
because
I
already
have
an
open
issue
for
adding
in
my
home
chart
there,
which
will
be
that,
like
added
convenience,
hopefully
I,
know
Ben.
It
doesn't
solve
your
use
case
here,
but
hopefully
it'll
that
we
can
show
you
the
rendered
again.
Yaml
manifests
and
that
can
probably
be
made
into
some
type
of
customized
deal
but
I
think
yeah.
Some
more
examples
would
be
really
valuable
here.
A
D
Yeah,
that's
a
really
good,
really
good
call
out
that
should
probably
live
there
and
I
wonder
if
there's
a
way
to
like
link
both
or
something
I,
don't
know.
So
we
only.
E
Have
to
write
it
once
that's
been
a
challenge
that
we've
we've
struggled
to
find
a
good
way
to
do.
I
think
we've
gone
back
and
forth.
This
comes
up
with
the
SDK
getting
started
Ducks
as
well,
like
some
of
them
live
in
the
SDK
repos,
and
then
our
sub
module
in
the
doc
site
and
I
think
they
found
that
wasn't
quite
working
so
now
they're
moving
back
towards
keeping
them
all
in
the
dock
site.
I.
E
Don't
have
a
good
solution
for
that,
but
I
think
Phil,
Carter
and
Severn
Newman
would
be
the
people
to
talk
to
about
that.
F
On
the
open,
Telemetry,
docs
site,
I
think
Anthony.
Your
colleague
Michael
has
a
PR
open
for
like
collector
best
practices,
and
it
would
be
it
would
be
cool
or
maybe
convenient
to
link
like
for
the
collector
best
practices
that
Michael
is
proposing
for
the
I
o
docs
to
have
them
that
like
match
up
with
the
examples
in
the
operator,
so
it's
kind
of
like
here's,
a
best
practice
for
this
sort
of
collector
deployment
model
and
then
here's
an
example
in
the
operator
that
actually
like
implements
that
proposed
model.
F
If
that
makes
sense,
but
it's
it's
a
really
great
PR.
It's
on
the
I
o
site
and
it
was
opened
I
think
in
the
past
week,
but
kind
of
a
really
nice
refresh
of
The
Collector
docs,
but
hasn't
really
gotten
into
the
operator.
Yet.
E
D
F
Thing
all
at
the
BR
thanks.
D
D
I'm
sure
great
well,
thank
you.
Everyone,
our
next
one,
will
be
in
two
weeks.
Please
remember
to
add
to
the
agenda.
If
you
have
anything,
thank
you
all
see.
You
later
have
a
good
day.