►
From YouTube: 2023-03-30 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
D
D
He
did
where,
in
the
operator
project
I
think
we
only
have
like
one
scanner
in
there
if
I
remember
properly
and
I
forgot,
which
one
it
actually
is,
but
there's
a
ticket
out
that
Brian
made
that
requests
that
we
add
another
vulnerability:
scanner,
something
like
trivia
or
coql
and
I'm
already
doing
this
in
my
own
Splunk
distribution
project
like
I'm,
going
to
be
adding
it
either
down
there.
D
But
I
was
wondering
like,
what's
the
group's
opinion,
on
adding
another
vulnerability
scanner
to
the
operator
project,
because
of
course,
that
comes
with,
like
maintenance
like
who
actually
watches
these
who's
like
actually
going
to
Tactical
the
fixes
and
I'm
wondering
if
I
don't
know.
If
we
have
a
stance
on
that,
but
I'd
love
to
hear
from
the
community
of
ideas
that
or
what
they
think
about
this.
D
I'll,
take
a
look
really
quick.
I
know
we
do
it
in
the
distribution
of
our
collector,
the
Splunk
distribution,
but
I'm,
not
sure
if
the
contrib
one
does
me
I
think
they
do.
B
B
Trivia
is
free,
I,
think
trivia,
as
a
company
has
built
a
SAS
product
along
like
the
automation
of
using
it,
but
the
actual
scanner
and
like
the
docker
image
itself,
is
open
source
and
free
to
use,
and
we
can
like
implementing
it
in
a
workflow
is
a
no
cost
to
us
other
than
the
action
workflow
hours.
D
Mm-Hmm
yeah
I've
already
got
a
code
example
I
could
put
in
there
for
PR.
It
looks
like
the
contrib
repo
doesn't
use
trivia,
but
they
do
use
code.
Ql
and
Coquille
is
another
open
source
free
product
I,
don't
think
they're
as
good
as
trivi,
but
both
those
options
are
great
I'm,
just
getting
a
second
vulnerability
scanner.
There
would
make
me
really
happy.
B
I
think
that
they're
different
and
I
think
code
ql
is
already
in
the
operator
repo.
Is
it
okay,
I
believe
so?
I
do
agree
with
as
the
author
that
putting
trivia
in
here
does
come
with
the
burden
of
like.
B
A
The
previous
or
today,
as
well
like
periodically
because
I'm
I,
just
maybe
I,
would
like
to
avoid
a
situation
where
we
are
due
to
release.
And
then
we
realized
that
hey
there's
like
a
bunch
of
work
that
we
need
to
do
and
it's
going
to
block
the
release
for
for
a
long
time,
I
find
doing
the
police,
but
maybe
as
well
do
something
more
periodic.
B
I
I
think
that's
totally
doable
as
long
as
we
have
things
to
scan
like
I,
think
for
trivia.
You
can
decide.
If
you
want
to
scan
code,
you
can
scan
images
like
I
use
it
regularly
just
to
scan
our
repositories
before
they're
built,
so
you
could
set
up
like
a
Cron
job
to
just
scan
dependencies
and
whatnot
and
do
it
periodically
to
catch.
It
also
just
depends
what
we
want
to
scan
and
how
we
want
to
utilize.
It.
D
Yeah,
if
we
can't
commit
resources
to
actually
like
addressing
these
vulnerabilities,
that
we
find
over
time,
at
least
knowing
that
they're
there
I
think,
would
help
and
like
that
way,
you
can
just
get
buy-in
from
the
community
members
who
actually
do
care
to
fix
the
big
ones
but
yeah
blocking
releases.
That
might
be
hard
if
we
can't
commit
the
resources
to
actually
like
maintain
these
reports
and
fix
them.
A
D
Yeah
I'll
start
us
off
I'm,
not
sure
if
other
people
want
to
talk
about
this
too.
But
so
we
have
the
auto
instrumentation
images
in
the
operator
repo
and
they
use
a
BusyBox
face,
image
which
it's
super
useful
for
like
getting
projects
off
the
ground
and
just
having
the
util
site
available
to
you.
D
But
you
can
bring
in
a
bunch
of
like
vulnerabilities
that
way,
because
BusyBox
packs
in
a
bunch
of
tools
just
get
the
CLI
running
all
the
tools
that
you
need
into
it,
and
so
it
seems
like
AWS
splunking
a
couple.
D
Other
people
are
starting
to
build
their
own
images
that
are
just
as
small
as
possible,
using
like
a
scratch
base
image
which
is
basically
like
nothing's
there,
except
for
like
a
binary
for
code
or
other
images
that
just
don't
bring
as
many
Tools
in
so
therefore,
there's,
usually
just
less
vulnerabilities,
my
company
we're
trying
to
figure
out
what
we
want
to
do
on
this,
and
so
there's
a
couple
of
different
approaches.
D
I've
heard
one
that
we're
thinking
about
is
we
make
a
go
helper,
pretty
much
that
just
does
what
CP
in
the
Upstream
operator
repo
they
use
CP
and
that's
why
you
need
to
bring
in
Linux
commands
to
and
do
a
container
injection
for
auto
instrumentation,
and
so
that's
how
why
we
have
to
have
all
those
Linux
utils,
but
the
other
two
options
that
were
thought
of
by
AWS
and
my
team
is
my
team
was,
let's
just
make
a
go
executable,
that's
just
a
utilx
cubital
executable.
D
It
has
as
little
as
possible
and
we
shove
that
in
there
AWS
went
with
another
route
that
you
decided
to
go,
do
something
quite
similar
with
rust
and
they
said
likely.
Rust
would
have
less
vulnerabilities
than
go,
but
they
were
debating
on
The,
Go
Solution
as
well.
But
that's
what
I
wanted
to
talk
about
like
if
we
wanted
to
actually
try
to
build
some
common
image
in
the
Upstream
operator,
repo
that
we
could
all
use.
D
E
A
B
Yet
at
least
from
our
side
in
the
AWA
side
it
was
the
primary
concern.
We
also
have
concern.
I
totally
agree
with
them.
You
know
bringing
a
small
footprint
for
an
image
as
possible
and
BusyBox
brings
things.
We
don't
use
and
a
quick
clarification,
because
we
did
bounce
back
like
and
forth
between,
go
and
Russ
and
I.
Think
Anthony
is
here
too,
or
he
was
yeah,
and
he
can
correct
me
when
I
say
something
wrong
is
that
it
wasn't
a
prediction
of
future
cves.
B
It
was
more
like
a
historical
look
into
the
past
for
CVS
lever
like
raised
against
Go
versus
rust,
and
we
felt
like
Future
tools,
be
a
bit
safer
to
build
it
on
top
of
rust
and
just
less
security.
Patching
I
mean
at
least
on
our
team.
We've
done
quite
a
lot
of
security
patches
just
for
the
collector,
based
on
recent
go
standard.
Library,
cves
and
we'd
like
to
avoid
patching
where
necessary.
A
B
Yeah
I
I
think
that's
fair
I
I
can
only
provide
kind
of
the
thoughts
of
what
our
team
went
with
here
and
I
think
just
provide
help.
Upstream
I
think
the
most
important
thing
is
when
licensing
compliance
into
ensuring
I
always
support
a
smaller
footprint
image
and
we'll
be
in
support
of
whichever
way,
I'm
sure
if
it
is
a
rest
way
that
we
think
it's
best
like.
We
can
definitely
be
involved
in
donate
code.
D
A
F
D
Would
it
be
worth
scanning
both
the
proposed,
like
images
and
just
to
see
what
the
vulnerability
count
differences
I
think
that
might
be
useful
for
at
least
me.
B
I
think
I
I
should
have
like
added
the
graph
here,
but
like
again,
it's
just
literally
the
number
we
we
used
it
as
a
baseline
as
the
number
of
cves
in
the
past,
but
Paulo's
right
like
if,
if
a
go
standard,
Library
affects
something
and
it
requires
patching,
then
honestly,
the
the
dashboards
at
CPU
utility
is
probably
going
to
get
patched
anyways
or
the
operator
will
get
patched
if
it
affects
that
CPU
utility
that
needs
patching,
then
there's
probably
a
pretty
good
chance.
B
The
operator
needs
to
be
updated
also
in
line
so
I
think
that's
also
a
very
valid
statement.
F
Though
the
places
where
this
utility
will
be
used
are
not
going
it's,
basically,
everything
about
go
like
so
like
the
the
other
things
in
the
images
with
this
are
Java
JavaScript,
python.net
right,
and
so
those
don't
necessarily
need
to
be
rebuilt
at
the
same
time
that
the
collector
or
operator
is
rebuilt.
If
there's
an
issue
and
go.
A
F
Or
even
if
they
are
using
the
collector
The
Collector
images
separate
from
these,
like
I
I,
get
to
the
point
that
go
is
the
language
that
is
familiar
for
the
maintainers
of
this
repo
and
that's
a
strong
point,
but
I
think
the
that
cves
in
this
utility
will
not
necessarily
be
correlated
with
necessary
changes
to
the
operator
or
collector
images.
D
A
B
Will
we
be,
could
we
at
least
submit
PRS
and
look
at
them
at
the
same
time,
at
least
to
let
other
people
look
at
them?
That
who
aren't
in
this
meeting,
rather
than
deciding
one
way
or
another,
totally
acknowledged?
Probably
people
will
be
like
hey,
go,
seems
way
more
comfortable.
It's
the
way
to
go,
but
at
least
allowing
people
to
look
at
them
in
both
ways.
H
A
To
the
next
one,
the
goal
and
auto
instrumentation
supports.
C
This
one
Yep-
this
is
more
of
just
a
heads
up:
we've
been
working
towards
adding
Go
Auto
instrumentation
support
for
a
while
there's
a
couple
blockers
on
the
go,
instrumentation
side
that
have
been
99
removed,
and
so
I've
got
the
pr
here.
It's
ready
for
review
we're
still
waiting
on
an
official
release
of
the
Go
Auto
instrumentation
image,
but
the
pr
is
mostly
independent
of
that
would
be.
You
know
a
small
change.
C
I
have
to
do
in
a
default
value
from
the
key
value
image
to
the
actual,
open,
Telemetry
one
but
yeah.
It's
it's
a
pretty
big
PR,
because
there's
a
lot
that
goes
on
to
adding
support
for
a
new
image
for
a
new
language,
I
mean,
but
yeah
people
could
start
taking
a
look
at
it
being
much
appreciated.
G
Just
as
a
heads
up
from
the
Go
Auto
instrumentation
side
to
keep
an
update
on
that,
there
are
a
couple
changes
right
now
in
the
pipes.
One
is
to
get
rid
of
that
key
Val
launcher.
So
you
don't
need
the
launcher
and
that's
just
kind
of
bundled
into
the
auto
instrumentation
agent
and
we're
also
trying
to
actually
add
some
UE
tests
to
make
sure
that
the
image
Works
so
that
the
test
shouldn't
block
you.
But
there
might
be
an
update
you
want
to
make
once
that
launcher
is
removed,
doesn't
FYI.
A
C
G
I,
don't
know
anyone
using
it
in
production,
yet
I
don't
actually
know
many
people
using
it.
It's
I've
been
wrangling
it
and
trying
to
get
it
just
to
run
locally
and
I've
gotten
a
couple
successful
runs
with
it,
I
think
Eden
who
contributed.
It
is
working
on
some
production
stuff
with
this
startup
to
actually
get
that
out.
There
too.
C
The
reason
that
we're
like
the
reason
that
our
company
is
working
on
this
right
now
are
like
trying
to
push
the
sport
is
because
we
have
some
customers
that
are
interested
in
trying
it
in
production.
Despite
it,
it's
like
heavy
Alpha
in
this,
so
I
do
I.
Do
think
that
this
one,
unlike
maybe
some
of
the
other
languages
that
have
already
been
added,
even
even
when
they
were
pretty
new
I-
think
the
go.
One
is
like
the
most
immature
of
all
the
auto
instrumentation
languages.
C
Probably
I
tried
to
call
that
out
where
I
can
and
some
like
some
of
the
support
isn't
there
for
some
things
like
multi-container,
like
the
multiple
container
name,
Concepts
I,
just
like
didn't
support
that
the
go.
C
Laying
other
instrumentation
does
a
sidecar
injection
instead
of
messing
with
the
different
containers,
and
so
like
I,
don't
even
know
if
it
can
support
multiple
containers
like
would
you
do
a
sidecar
injection
per
container
that
you
wanted
to
instrument,
or
would
one
container
be
able
to
handle
one
sidecar
injection
be
able
to
handle
multiple
containers
in
a
pod
like
I,
didn't
even
want
to
deal
with
that.
Yet
so
I
just
kind
of
dropped,
support
for
that
first.
C
Second,
so
there's
definitely
a
lot
of
immaturity
for
this,
but
we
do
have
some
customers
that
are
like
willing
to
to
experiment
with
it
once
it's
out
there.
So
hopefully
that
helps
us
improve
it
in
the
future.
F
Yeah,
given
the
context
one
thing
I'd
like
to
ask
about,
is
whether
there's
a
way
to
disable
support
for
utilizing
this
for
those
of
us
who
have
to
provide
Enterprise
support
for
operator
usage
and
don't
necessarily
want
to
expose
untested
or
beta
level
capabilities
to
our
users.
What
what
controls
do
we
have
for
that.
C
I,
the
first
time
I
brought
this
up
Jacob
from
lightstep,
had
brought
up
the
concept
of
maybe
putting
something
like
this
behind
a
feature:
gate
I,
don't
know
what
the
status
of
that
feature
gate
is.
During
that
conversation,
the
outcome
was
kind
of
well,
since
this
is
opt-in,
you
know.
Maybe
it's
maybe
it's
not
necessary,
but
it
does
Remain
the
fact
that,
like
if
you,
if
you
create
an
instrumentation
object,
anyone
could
go,
add
The,
annotation
and
get
the
thing
like.
C
C
Another
way
to
go
about
this
would
be
some
extra
configuration
in
the
instrumentation
object
that,
like
you,
have
to
explicitly
enable
go.
Instrumentation
I,
don't
know
if
that's
what
the
feature
flag
is
doing,
but
if,
if
the
community
thinks
that
that's
a
requirement
before
we
could
add
this
feature,
I'll
definitely
work
on
it.
A
F
Yeah
I
I
think
it
could
be
good
to
have
explicit
configuration
in
the
mutating
Web
book
that
is
responsible
for
modifying
us
to
inject
the
auto
instrumentation
to
control
whether
it
wants
to
support
any
of
the
given
instrumentation
injections.
That's
the
sort
of
thing
I
think
might
not
even
necessarily
be
a
featured
flag,
because
that
could
be
long-lived
capability
for
the
the
operator
of
the
operator
to
decide.
I
want
to
support
Java
and
JavaScript,
but
not
python,
something
like
that.
As
a
you
know,
an
internal
company
decision
to
do
their
policies.
C
A
To
start
using
the
operator
config,
which
is
like
a
config
file
mounted
Studio
operator,
some
of
the
other
kubernetes
operators
are
using
the.
E
A
And
it's
it's
quite
nice,
because
the
its
type
that
is
then
and
the
config
is
in
the
config
map
and
it's
much
cleaner
approach
than
than
the
flux.
But.
C
If
the
the
future
gate
work,
that
Jacob's
working
on,
is
that
like
good
to
go,
it
looks
like
there's
a
couple
of
like
several
approval
Founders
there,
something
that
we're
waiting
on
specifically.
C
F
I
believe
this
is
doing
both
this
is
adding
the
infrastructure
for
for
using
feature
Flags
and
also
adding
a
first
feature
flag.
F
F
Gates
package
to
to
do
the
same
thing,
but
it's
a
different
set
of
gates,
because
the
The
Collector
skates
won't
be
registered
with
it.
It's
just
reusing
that
functionality,
okay,.
C
A
Yeah
then,
for
this
CR,
maybe
I
would
prefer
to
split
it
into
publishing
the
auto
instrumentation
image
and
then
have
a
second
one
that
will
use
the
image
and
as
well
to
some
end-to-end
tests.
C
There's
no
there's
no
image
published
as
part
of
this
PR
that
we
I
think
we
had
a
discussion
with
this
in
a
Sig
or
maybe
it
was
just
in
a
the
issue,
but
the
go
image,
unlike
the
like
the
Java
and
and
the.net
and
python,
or
whatever
there's
a
lot
that
goes
on
with
the
Go
Auto
instrumentation
image.
It's
complicated
enough
that
we
didn't
want
to
have
to
manage
it
ourselves,
so
we're
going
to
depend
at
least
at
the
moment.
C
The
the
outcome
of
that
discussion
was
to
depend
on
the
actual
go
instrumentation
image
that
they
publish
instead
of
publishing
one
ourselves
and
and
the
docker
images
repo
whatever
that
folder
is
called,
not
repo
yeah
directory.
So
this
this
particular
PR
doesn't
have
any
like
added
Docker
file
or
anything,
because
that
image
is
being
sourced
from
the
open.
Telemetry
go
instrumentation
Repository.
C
So
that's
what
that's
going
to
have
to
change
that
and
separate
other
things
right
now
that
I
don't
have
an
image
to
actually
use
and
test
with
once
the
go.
Instrumentation
does
an
image
like
all
these
key
Val
references
will
be
updated
to
be
open,
toiletry
Dash
go
Dash
instrumentation
or
whatever
the
the
name
of
the
image
was
I
forget
what
I
called
it.
A
C
Definitely,
please
don't
merge
it
with
the
key
values.
Please
just
review
it
and,
like
specifically,
like
the
actual
like
instrumentation
package
changes.
I'm
most
curious
about.
You
know
the
golang.go,
the
podmutator.go
like
the
core
logic,
changes
and
then
I'll.
Definitely
as
soon
as
I
have
an
image
get
the
files
updated
and
all
the
end-to-end
tests
will
be
run
and
I'll
do
manual
tests
again
and
all
that
stuff.
C
And
I'll
work
on
the
I'll
work
on
the
future
gate,
I'll
review
that
Jacob's
PR
and
get
a
feature
gate
as
well.
I
think
it
sounds
like
I'll
need
to
wait
on
that
PR
to
get
merged,
but
once
it
is
merged
all
I'll
Implement.
That.
H
Yes,
I
I'll
explain
what
I
what
I
actually
mean
by
that
okay.
So
this
is
more
like
an
open-ended
question.
I,
don't
really
have
an
issue
in
anything
I'm
kind
of
interested
with
the
opinions
and
everyone
here
is
and
whether
everyone
anyone
else
actually
cares
about
this
kind
of
thing.
So,
if
you
look
at
Prometheus
operator,
there's
service
monitors,
spot
monitors
and
so
on
and
part
of
part
of
what
these
objects
do
right.
Is
they
abstract
the
way,
the
kubernetes
and
it's
the
kubernetes
implementation
details?
Let's
say
the
other
thing
they
do.
H
Is
they
let
you
make
a
division
between
like
a
team,
maintaining
some
set
of
Prometheus
instances
somewhere
and
all
the
other
teams
will
basically
just
create
service
monitors
and
don't
care
about
anything
else
right.
So
it
lets
you
when
I
say
distributed,
I
mean
this
kind
of
distribution
right.
You
don't
have
coupling
between
one
side
and
and
the
other
I
was
kind
of
curious.
H
I
know
this
is
like
a
super
super
high
level
and
complicated
sounding
thing.
So
right
now,
I'm
mostly
curious.
If
anyone
cares
for
the
record.
One
of
the
reasons
this
has
come
up
for
us
is
that
there's
a
thing
called
logging
operator
out
there
in
the
Wild
by
Bonsai
cloud
and
it
actually
it
kind
of
works
like
this.
It
uses
flu
and
de-influence
bit
under
the
hood
and
we
actually
have
a
we
have.
We
have
a
customer
who
uses
this
and
they
would
like
to
use
Auto
and
they're
coming
in
and
asking.
H
How
do
we
do?
How
do
we
do
the
setup
with
ultra
with
open
Telemetry
operator?
That's
kind
of
thing,
and
the
other
side
is
that
I
I
am
increasingly
because
we
use
the
auto
internally
as
well
in
our
infrastructure
and
I
am
increasingly
feeling
the
pain
of
having
one
monolithic
config
for
everything,
so
that
that's
the
second
reason.
E
Actually,
that's
a
thing
that
was
discussed
before
when
you
go
back
in
history,
I
think
two
or
three
meetings
back.
E
In
other
words
named
differently,
it
was.
F
Effect
providers
is
probably
the
thing
you
want
to
search
for.
We
need
or
configur
eyes.
The
Collector
already
has
support
for
assembling
configuration
from
multiple
sources.
What's
missing
right
now
is
a
way
for
the
user
of
the
operator
to
tell
the
operator
when
you
start
up
a
collector
use
this
list
of
configuri's
to
obtain
the
configuration.
E
Yeah
I
think
we
had
this
as
a
in
as
part
of
the
discussion
of
this
opinionated
crd
and
my
cursor
is
there.
If
you
want
to
jump
there,
I
concede
okay,
I.
E
This
one-
and
there
also
was
yeah
asking
in
the
issue
if
it
might
make
sense
to
split
the
configuration
somehow
it
was
yeah
it's
a
bit
different
because
there
are
other
ideas
in
the
same
mixed
in
So
like
yeah.
But
the
idea
is
here
so
to
have
something
like
an
optometry
collector
destination,
an
open,
Telemetry,
collector
Matrix,
which
is
a
bit
more
opinionated
and
makes
the
configuration
a
bit
easier
and
also
lets
you.
You
reuse
top
parts,
but
yeah
Pro
needs
some
more
thoughts.
A
E
We
agreed
on
having
hem
charts
first
to
make
the
configuration
a
bit
easier
and
then
in
Helm
you
can
use,
for
example,
the
destination
path
as
a
template
and
reuse.
It
multiple
times.
H
It's
not
exactly
the
like
I
said
the
distributed
thing,
I
kind
of
so
I
don't
want
to
like
bind
so
I,
don't
want
to
lock
into
any
particular
model.
The
Prometheus
model,
the
Prometheus
operator
model
I,
think,
is
really
nice
for,
like
at
least
it's
usability
is
very
nice
in
this
sense,
where
you
literally
as
a
like
as
someone
who
just
wants
to
wants
to
get
their
metrics
great
like
the
owner
of
some
service
in
kubernetes,
you
just
create
a
service
Monitor
and
you're
done.
H
That's
like
a
really
nice
user
experience,
but
I
think
with
autel.
This
might
be
more
difficult
to
do
like
achieving
something
similar
might
be
like
more
difficult
than
than
it
is
with
Prometheus,
where
it's
I'm
really
just
scraping.
That
works
this
way,
I
think
that
sounds
pretty
complicated
but
yeah
anyway
I'll.
This
is.
This
is
good
enough.
For
me,
this
is
the
kind
of
answer
I
was
looking
for.
So
thanks.
H
H
Yeah
anyway,
I
don't
want
to
hold
everyone
up
with,
like
this
kind
of
philosophical
musings
over
here,
I'll
check
out
the
the
what
already
exists
and
maybe
bring
maybe
bring
it
up
again
if
I
have
something
more
concrete.
A
A
Much
and
we'll.