►
From YouTube: 2022-07-08 meeting
Description
Instrumentation: Messaging
A
B
C
C
C
B
A
B
A
A
C
C
Yeah
this
one,
I
think
there
was
a
race
condition
in
the
release
process.
Yesterday,
right
yeah,
the
the
only
thing
I
can
think
of
it.
That
would
like
really
prevent.
That
is,
if
we
just
automate
it
because
then
it's
just
part
of
the
process
and
there's
no
it's
like
the
last
thing
we
do
basically
before
we
actually
caught
the
release.
A
C
B
C
C
It's
loading,
you
know
basically
arbitrary
code
and
executing
it
right,
like
I,
don't
know
the
limitations
on
what
this
code
could
do
and
what
it
could
have
access
to.
But
it's
loading
an
artifact
right
and
if
that
artifact
is
overwritten
by
a
malicious
actor,
could
we
end
up
in
the
same
situation
as
we
had
already
decided
we're
not
going
to
allow
in
other
contexts.
C
A
C
Yeah,
I
think
like
to
summarize
what
I
remember
being
the
conversation
about
it,
this
one
it
was
a
sub
process.
It
was
basically
like.
Yes,
this
is
cool
functionality
and
and
whatnot,
but
ultimately,
if
something
does
go
wrong,
do
we
really
want
to
be
in
a
position
where
we
enabled
it
right,
like
it's
not
really.
B
This
one
is
more
like
a
processor
that
can
just
run
whatever
binary
you
want,
and
those
binaries,
like
whatever
you
choose
to
throw
in
there
like,
could
do
something
wrong
like
if
you
choose
to
use
a
binary,
that's
not
safe
yeah,
but
yeah.
It's
still
like
we're
still
enabling
this
this,
like
essentially
remote
code
execution
capabilities
right
like
the
binaries,
could
do
anything
like
it
loaded
in.
A
Yeah,
I
seem
to
remember
this
at
some
point.
You've
been
saying:
there's
there's
no
way
we're
going
to
be
able
to
avoid
this
forever.
So
I
mean
I
don't
disagree
with
them.
If
you
look
at
every
other
agent
type
thing
that
exists
in
the
world
of
observability,
they
all
have
some
kind
of
plugin
based
thing
that
can
be
enabled
so
yeah.
Maybe
this
is
a
good,
a
good
component
to
use
as
a
discussion
point
next
sig
call.
A
B
C
C
A
C
C
B
C
B
A
C
B
C
I
mean,
I
think,
that's
at
least
as
it
is
right
now,
that's
conflicting
with
our
definition
of
vendor
specific,
it's
basically
and
again.
We
maybe
maybe
we
need
to
redefine
this,
but
currently
we're
saying
that
it
has
to
be
someone
from
the
vendor
who's
going
to
maintain
the
component,
and
I
think,
as
I
understand
it,
the
reasoning
there
is
not
that
we
need
to
have
like
if
it's
not
from
the
vendor.
C
Yes,
that
person
may
be
willing
to
maintain
it,
but
the
reason
we're
obligated
to
accept
it,
regardless
of
our
opinions
on
the
component,
is
that
we
need
to
play
fair
with
all
vendors.
So
if
a
vendor
comes
to
us
and
says
we
have
a
component
that
needs
to
that,
we're
going
to
maintain
and
contribute
we're
not
going
to
say
no
because
we're
not
interested
in
it
it's
going
to
be,
they
have
basically
will
have
the.
C
C
B
C
B
C
C
B
C
B
B
Believe,
well,
these
people
were
saying
that
target
is
correct,
but
the
original
poster-
the
issue
creator
from
prometheus,
said
that
target
info
is
correct,
but
these
people
said
target
is
correct
so
which
one
is
which
again
I
don't
know
what
the
standard
is
in
prometheus.
But
it
sounds
like
hotel.
Spec
says
target
is
correct,
right.
B
Yeah,
I
feel
I
mean
changing
changing
the
telemetry
is
normally
not
done
at
the
exporter
level
right.
It's
normally
done
in
the
processing,
so
yeah
to
add
configuration
to
whatever
this
exporter
is
that
will
modify
the
data
other
than
transforming
otlp
to
whatever
the
back
end
is.
It
seems
like
it's
the
wrong
place,
but
maybe
that's
part
of
the
transformation
between
otop
and
whatever
influx
db
looks
like.
B
A
A
B
I'll
try
to
I'll
probably
do
a
little
bit
more
today
before
you
guys
go.
I
got
a
quick
question.
I'm
trying
to
plan
for
conferences
later
this
year
is
anyone
planning
to
go
to
kubecon
n
a
gotta
tell
employer
whether
or
not
I
want
to
go,
but
it's
in
detroit.
I
don't
really
have
a
lot
of
motivation
to
go
unless
a
lot
of
other
reversing
contributors
and
maintainers
are
going
to
be
there.