►
From YouTube: 2022-05-03 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Okay,
I
think
we
can
start
yeah,
so
I
I
did
merge
the
implementation
of
the
unification
of
addons
and
packages.
B
I
made
a
few.
I
guess
I
missed
a
few
things
that
I
needed
to
do
from
the
spec
to
to
the
implementation,
which
I
guess
prompted
me
to
think
about
having
the
actual
example,
with
the
addons
there
in
the
repo
which
we
don't
have
the
I
had
one
when
I
was
doing
the
prototyping,
but
right
now
that
the
spec
is
now
significantly
diverged
from
the
prototype.
So
it's
not
going
to
be,
I
guess
just
simple
copy
pasting
of
what
I
had
yeah.
B
A
We
don't
have
anything
right
now,
but
we
probably
will
in
the
next
month.
B
Okay,
okay,
it
would
be
great
if,
when
you
do
have
your
own
implementation,
maybe
something
that
you
can
add
as
an
example
some
simplified
version
of
it,
maybe
yeah
if
like
by
then
we
don't
have
anything
else.
Anyone
else
adding
that
that
would
be
great
sounds
good,
okay,
and
so
the
I
saw
you,
you
proved
the
the
changes
in
the
the
hashes
with
agent
description
and
the
the
other
three
messages.
B
B
B
A
Thing
I
was,
I
was
yeah,
I
wanna
I'll
bring
that
up
in
a
second.
But
one
thing
I
was
thinking
about
with
regard
to
the
agent
description
and
the
new
flags
that
can
be
sent
down
is
if
we
should
sort
of
convert
control
from
the
op-amp
implementation
to
request
the
effective
config
and
the
agent
description
and
other
things
from
the
agent
implementation,
essentially
adding
more
functions
to
the
callback.
B
That's
an
interesting
suggestion.
I
guess
depends
on
how
you
intend
to
use
it
right
yeah.
I
guess
it's
worth
exercising,
maybe
I'm
not
sure
when
in
the
protocol,
I
guess
when
do
you
need
you
need
it
when
you're
starting
and
then
you
need
it
when
the
server
asks
for
it.
But
what
happens
if,
if
it
changes
on
the
agent
side
without
right,
there
needs
to
be
some
way
of
indicating
that
so.
B
B
B
A
They're
just
they're
just
situations
where
I
think
the
agent
you
know
needs
to
be
where
the
in
the
op
implantation
might
need
the
description
or
the
effective,
config
or
or
something
and
the
agent
the
way
it
is
now.
The
agent
needs
to
be
updating
that.
B
A
Early
on
and
there's
an
issue,
you
know
you
posed,
I
think
initially,
which
was
do
we
need.
You
know
the
agent
configuration
both
in
settings
and
set
or
sorry
agent
description
in
both
settings
and
yeah
yeah
and
a
set
agent
description.
I
don't
know
if
it
necessarily
resolves
that,
but
it
might.
B
A
Yeah
so
the
credentials
and
configurations
I
feel
like
we
may
have
discussed
this
months
ago
and
I
just
kind
of
came
up
again
recently.
But
there's
the
notion
of.
A
In
some
cases
that
might
that
might
be
a
little
too
specific
for
like
an
api
key
or
you
know,
if
you
think
of
just
as
an
example
like
google
cloud
has
a
json
key,
which
is
not
specifically
a
you
know,
private
or
public
key.
It's
it's,
it's
wrapped
in
a
json
structure,
but
but
you
might
need
that
to
export
to
google
cloud,
for
example.
A
A
That
is
just
credentials
or
something
like
that,
and
then
the
agent
would
potentially
this
would
be
in
the
other
settings
section
and
the
agent
would
potentially
store
that
off
and
then
reference
it.
Another
option
would
be
to
pass
it
down
as
configuration,
so
you
would
just
give
it
another
name
for
configuration.
A
So,
let's
just
call
it
exporter
key
or
something
like
that,
and
it
would
have
a
payload
where,
where
I
think
that
breaks
down
a
bit
is
that's
not
something
you
would
want
to
send
it
back
up
from
the
agent
as
part
of
configuration,
and
so
it
kind
of
breaks
that
notion
of
the
configuration
round
tripping.
A
So
I
don't
think
it
fits
right
now
in
either
spot
well,
unless
I'm
I'm
just
missing
something
on
there
being
another
way
of
solving
this.
This
json
key.
B
A
B
A
B
B
A
So
what
we're
proposing
internally
is
wrapping
the
google
cloud
exporter
to
allow
you
to
provide
the
key
so
via
probably
a
file
path,
but
could
also
just
be
passed.
A
C
B
A
B
B
C
B
Then
it's
up
to
the
agent
to
know
which
key
cards
yeah.
What
to
do.
I
think
it
does
make
sense.
The
the
question
I
have
then
is:
do
we
keep
the
current
structure
of
connection
settings
like
it
has
destination
the
headers
a
few
pre-predefined
stuff
right,
or
do
we
just
get
rid
of
that
all
together
and
just
have
key
value
pairs?
And
then
it's
up
to
the
agent
to
figure
out
how
it
interprets
it.
A
If,
if
we're
thinking
about
this
specific
example
again,
I
think
a
lot
of
that
would
be
in
the
hotel,
yaml
and
not
be
necessarily
provided
in
some
other
other
way.
It's
really
the
secret
part
of
it
that
needs
to
be
passed
separately,
but
the
endpoint
or
proxy
information
could
probably
be
in
in
the
actual
configuration
in
the
ammo.
That's
passed
down.
C
I
think
that
this
sounds
more
like
an
edge
case
rather
than
a
common
case,
and
I
think
we
should
optimize
for
the
most
common
case
and
and
add
support
for
for
for
the
problem
you
are
describing
by
the
way.
I
have
a
question
because
I
I'm
not
like
familiar
with
how
this
works,
but
this
credentials
is
it
like
run
locally
on
the
machine
when
the
collector
is
being
used
or.
A
Well
so
effectively-
and
I
I
hate
to
divert
too
much
from
kind
of
a
topic
of
this-
it's
that
sick,
but
effectively
we
have
the
issue
where
we
would
like
to
support
customers
running.
You
know
sending
data
to,
for
example,
google
cloud
from
outside
of
a
google
cloud
environment
so
from
an
on-prem
location,
in
which
case
you
don't
necessarily
have
credentials
readily
available.
A
We
also
want
to
be
able
to
as
part
of
configuration
and
and
centralized
agent
management
provide
those
credentials
via
management
protocol
without
having
to
have
those
pre-loaded
on
machines
and
some
other
x.
You
know
external
management
for
for
those
credentials
so
effectively.
We
need
a
way
to
get
credentials
down
to
the
agent
via
this
protocol.
A
I
think
it
would
be
very
similar
for
say
an
api
key
for
elasticsearch
or
you
know
how
do
you
do
you
want
to
just
have
that
api
key
embedded
in
the
hotel
config?
Maybe
that's?
Okay?
Maybe
it's
not!
You
know
it's
right.
Only!
It's
not
that
risky,
but
it's.
C
Yeah
because
so
what
I'm
thinking
about
this-
and
this
is
like
this
one
one
idea
but
the
first
that
came
to
my
mind-
is
that
maybe
we
should
have
this
ability
to
provide
two
additional
fields.
One
would
be
like
some
identifier
of
a
custom
connection
setting
or
like
authentication
or
whatever
you
want
to
call
it
and
then
just
like
a
byte
r
and
then
with
like
responsibility
of
the
of
the
client
to
have
a
callback
that
can
consume
that
data
and
and
use
it
for
whatever
exporter
or
I.
A
B
Spec,
I
guess
that's,
that's
essentially
slightly
more
structured
for
what
you're
saying
trimming
like
just
like
having
a
key
value
list
of
key
value
pairs,
not
just
a
single
like
name
thing,
which
is
a
byte
sequence,
but
more
like
a
number
of
those.
If
you
want
to
it's,
it's
very
close,
essentially
to
what
you're
describing
and
and
the
the
use
case
is
exactly
what
the
connection
settings
are
supposed
to
serve.
You
have
an
exporter
there.
B
B
I
can
find
it
so
it's
you're
intending
to
add
the
ability
to
do
that
to
the
google
cloud
exporter
and
that's.
B
The
the
connection
settings
the
way
that
I
designed
them.
They,
I
guess
they
they
serve
well
the
the
case
of
all
pump
connection,
settings
and
the
case
of
the
otlp
connection,
settings,
which
is
what
you
use
for
reporting
your
own
telemetry,
but
for
the
broader
application
of
any
connection,
settings
for
any
destination
and
any
protocol
I
mean
yeah.
Probably
this
is
too
limiting.
Maybe
I
guess
we
need
something
that
is
more
flexible
right,
I'm
not
surprised
by
by
the
discovery.
Let's
say
this
way
sure
sure.
A
So
here
is
one
I'll
just
post
this
in
the
chat
here.
Here's
one
discussion
on
one
possible
approach
that
just
led
to
discussion
about
that
and
then
there's
a
separate
one
on.
I
don't
know
if
it's
in
the
same
repo
or
if
it's
separate,
I'm
not
sure
where
the
other
discussion
is
about
the
specifically
about
the
google
exporter,
but.
A
This
was
an
approach,
and
this
is
this-
doesn't
really
completely
solve
it.
The
issue
here
is:
even
if
we
have
this
ability
to
set
environment
variables,
if
you
usually
do
have
customers
sending
to
different
using
different
service
accounts,
to
send
to
actually
different
projects
within
google
from
the
same
agent
and
to
avoid
having
two
agents
we
want
to
have.
A
You
know
just
two
pipelines
which
which
would
need
two
exporters,
but
if
they're
both
using
the
same
built-in
environment
variable,
then
we
have
a
problem
yeah.
So
so
again,
I
don't.
I
don't
want
to
go
down
this
rabbit
hole
of
this
very
specific
thing,
but
but
I'm
just
trying
to
figure
out
the
right
way
to
to
to
send
this
kind
of
payload
down,
and
I
and
I
do.
C
A
We
haven't
pursued
that
too
much
yet,
but
it
seems
like
some
of
that
could
be
in
the
configuration
itself
like
the
the
exporter
defined
and
the
like.
A
like
an
own
receiver
is
that
I
feel
like
that's
been
brought
up
before,
but
I
don't
know
where,
where
that's
ended,
up.
B
So
for
for
own
telemetry,
you
mean
the
the
the
otlp
destination
which
the
agent
uses
to
send
its
own
telemetry.
Could
it
be
part
of
the
agent's
configuration
itself
sure
it
could
be,
but
then
it
requires
the
server
to
know
the
the
the
format
of
the
config
file
right
to
be
able
to
just
to
to
provide
this.
This
settings
in
the
configuration.
C
B
B
A
B
Yeah,
so
I
think
anyway,
the
use
case
that
you're,
describing
with
google
cloud
exporter,
is
absolutely
something
that
we
should
be
able
to
solve
with
wall
pump.
If
it's
not,
then
we
need
to
make
whatever
changes
are
necessary
there.
Let
me
I'll
go
read
the
issue
that
you
gave
the
link
to,
and
can
you
also
file
an
issue
in
our
repo
in
open
repo
sure
and
maybe
describe
how
exactly
you
see
it?
Let's
open
the
discussion,
but
I
do
think
that
we
need
to
solve
it.
B
B
B
Yeah,
I
mean
the
secrets,
let's
say,
if
you're,
using
an
http
protocol.
Typically
you
put
the
secrets
as
some
sort
of
http
header
right
and
the
http
headers
are
handled,
that
you
have
this
generic
headers
field
in
the
connection
settings
and
you
could
put
anything
there.
It
should
work.
But
if
it's
not
in
the
headers,
then
I
don't
know,
maybe
you
send
it
as
a
query
parameter
or
I
don't
know
how
else
you
can
do
that?
Maybe
maybe.
A
I
think
you
know
in
essence,
in
this
particular
case,
it
would
be
a
configuration
setting
of
the
exporter
and
it's
really
up
to
the
exporter,
to
determine
how
that
is.
A
B
A
B
A
Absolutely
right
right:
that's
the
intention
right
exactly
you
pass
this
down
either
via
connection
settings
or
via
configuration,
save
it,
and
then
your
configuration
references
it
by
file
path.
B
Then
why
do
you
care
from
the
op-amp
perspective?
You
provide
a
key
value
pair
and
then
it's
agent
specific
that
it
wants
to
save
the
value
to
a
file
and
reference
the
file
name
in
its
own
configuration.
It's
not
an
open
concern
in
that
case,
so
where's
the
file
payload,
where
the?
Where
is
it
how's
the
file
certain
as
a
value
right,
you
can
have
arbitrary.
A
A
B
A
B
C
B
Via
connection
settings,
it
doesn't
have
to
be
a
config
file
right.
It
doesn't
have
to
be
a
remote
config
offer
from
the
server
it
can
be.
A
connection
settings
offer
it's
up
to
the
agent
then
decide
that
it
wants
to
put
this
this
particular
key
value
pair
into
its
own
configuration
and
use
it
that
way,
because
that's
that's
how
it's
used.
B
B
Yeah,
please
do
please
open
an
issue.
Add
the
other
links
that
you
had
there,
maybe
post
what
what
you
your
thoughts,
what
we
were
just
discussed
there
and,
let's,
let's
consider,
I
think
we
have
a
few
options
here:
okay,.