►
From YouTube: 2022-06-28 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
Hi
everyone
can
you
hear.
B
A
B
B
A
A
A
B
A
I
only
see
the
stuff
that
I
added
to
the
agenda,
so
I
guess
let
me
start
with
the
items
I
have
so
the
first
one
is.
I
just
wanted
to
ask
for
help.
We
have
a
few
a
few
items
that
I
think
we
need
to
complete
before
before
the
ga.
A
A
So
yeah,
that's
the
link
there
and
the
second
one
is
the
the
basic
of
issue.
I
I
posted
a
draft
pr
for
the
implementation
with
basically
adds
the
up.
Boolean
value.
Uptime
is
duration
since
the
since
it's
up
and
running
so
I
was
wondering
if,
if
this
is
what
you
think
is
the
right
approach
for
the
for
the,
I
guess,
the
very
basic
health
matrix.
A
B
B
We
kind
of
talked
about
the
trade-offs
there.
One
thing
I'm
realizing
is
that,
if,
if
we
use
uptime,
that
will
basically
be
changing
constantly
and
in
order
to
fit
the
pattern
of
the
other
messages
where
you
either
send
the
hash,
if
nothing
changes
or
send
the
whole
message,
that
would
suggest
that
you
always
send
the
whole
message,
which
I
think
is:
okay,
it's
just
it's
a
slight
change
from
the
well
just
doesn't
allow
as
much
compression
does
it
make
sense.
A
A
A
A
A
A
Okay
and
the
last
one
I
had
was
about
the
packages,
so
we
have
the
the
top
level
packages
and
the
sub
packages
right
now,
and
the
idea
was
that
the
top
level
package,
essentially
is
the
agent
itself
and
the
sub
packages
are
whatever
the
plugins.
You
may
have
there,
the
add-ons
and
the
feedback
I
got
from
someone
a
colleague
of
mine.
A
He
said
that,
essentially
the
message
is
allowed
to
represent
multiple
top
level
packages,
but
it's
unclear
if,
if
the
sub
packages
are
are
intended
to
to
be
part
of
a
top-level
package,
somehow
there
is,
is
there
a
supposed
hierarchy
there
or
no?
And
if,
if
there
is,
then
how
do
you
know
which
one
corresponds
to
which
which
sub
package
is
part
of
which
top
level
package
which,
which
is
impossible
to
express
right
now
in
the
in
the
messages?
A
So
and
and
true,
it's
it's
unclear,
but
I'm
not
sure
how
to
actually
make
it
clearer,
because
I
don't
really
know
what
what
is
the
use
case
for
that
right.
So
I
can
I
we
right
now
we
really
have
actually
one
one
one
use
case
where
you
have
a
single
top
level
package,
the
agent
itself.
So
I
was
wondering
if
anybody
really
has
a
use
case
where
you
do
have
you
have
more
than
one
top
layer
package?
A
A
B
B
I
don't,
I
don't
see
a
case
where
there's
multiple
well,
let
me
put
it
this
way.
Our
in
our
implementation,
our
agent,
we
have.
The
only
thing
that
can
be
updated
is
the
agent
itself
and
so
there's
a
single
package.
We
don't
right
now
have
plugins
that
can
be
added
or
anything
like
that.
So
I
know
it
doesn't
affect
us,
but.
A
So
I
guess
the
most
complex
use
case
that
I
can
imagine
is
where
you
have
one
top
level
package
for
the
agent
itself
and
maybe
the
second
top
level
package
for
the
supervisor.
And
then
there
is
sub
packages
which
are
which
are
the
plugins
like.
If
we,
if
we,
if
we
wanted
to
adopt
the
notion
of
the
plugins
that
the
stanza
agent
had
those
probably
could
become
sub
packages
right.
A
B
Right
and
they,
but
it
also
is
all
going
to
be
handled
by
the
same
agent
side.
Op
implementation,
that's
going
to
be
responsible
for
coordinating
the
update
of
all
those
packages,
so
I
think
again
at
that
point
it
can
reason
about
using
naming
conventions
or
some
other
technique,
reason
about
how
those
packages
should
be
processed
and
associated
with
each
other.
A
A
B
At
the
agenda,
as
I
say,
but
so
I'm
I'm
part
of
the
right
here,
as
as
most
of
you
probably
know,
and
so
are
corbyn
and
dave,
and
we've
been
working
on
an
agent
management
solution.
We're
calling
bind
planning
op
for
observability
pipeline,
and
I
was
just
wondering
if
anyone
would
be
interested
in
the
demo
short
demo
of
that
next
meeting.
In
two
weeks
it
uses
op
amp
on
both
sides
and
it
uses
our
open
source.
B
Distribution
of
the
open,
telemetry,
collector
and
blind
playing
op
as
well
will
be
open
source
and
should
be
open
source
sometime
next
week
before
this.
So
this
is
something
some
people
would
be
interested
in.