►
From YouTube: 2022-01-11 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).
B
A
A
A
Okay,
I
guess
no,
then,
in
that
case
a
couple
updates
from
me
one.
I
added
an
example
which
implements
the
reporting
of
own
metrics
from
the
agent.
In
the
example
agent
that
we
have,
I
think
it's
it
will
be
useful
to
generally
improve
the
example
to
show
the
actual
usage
of
the
protocol
more
of
the
features
of
it.
So
this
is
one
additional
step
with
improving
the
the
the
sample
that
we
have.
A
In
addition
to
the
websocket
to
see
whether
that's
what
we
actually
want
to
support,
it
seems
like
that
that
is
preferable,
at
least
for
some
use
cases,
probably
for
the
for
open
203
as
the
case
to
use
that-
and
I
played
a
bit
with
the
implementation
side
of
things
on
on
the
server
seems
to
be
fairly
simple-
to
support
both
transports
with
one
implementation.
A
So
I'm
looking
into
the
client
side
of
things,
maybe
a
bit
more
complicated,
but
I
think
it
seems
to
be
feasible.
So
there
is
an
issue
we
have
an
issue
for
that
open.
So
if
you're
interested
in
this,
maybe
you
can
comment
on
the
issue
and
I
guess
the
third
one,
a
small
update.
I
I
discussed
with
splunk
legal
to
see
whether
we
can
actually
donate
the
protocol
specification
to
open
telemetry
instead
of
just
open
telemetry
using
it
legally
using
it
with
apache
license.
We
can
do
that.
A
We
do
that,
but
open
telemetry
recommends
that,
if
possible,
you
actually
do
the
copyright
assignment.
So
I
think
we
can
do
that
from
the
splunk
side.
It
doesn't
really
make
much
of
a
difference
from
usage
perspective,
but
I
think
it
aligns
better
with
the
other
things
that
we
do
at
all
from
telemetry,
so
that
was
approved
I'll
post.
The
pr.
D
D
A
Yeah
yeah,
sorry
guys
if
you
were
saying
something,
then
it
was
me.
I
couldn't.
A
Cool
anyway,
I'm
done
with
my
updates,
so
please
go
ahead.
If
anybody
wants
to
say
anything,
particularly
with
regards
to,
I
guess
the
first
item
we
have
in
the
agenda.
If
the
person
is
here,
please
go
ahead.
A
D
B
D
Yeah
best
too,
if
you
can,
I
actually
put
this
on
the
hotel
slack
because
I
think
not
everyone
knows
about
it.
There's
a
google
group
that
we
created
that
just
forwards
you,
the
hotel
calendar,
invites
blindly
for
all
of
the
sig
meetings.
D
So
a
lot
of
people
subscribe
to
the
community,
one
which
stays
up
to
date,
but
it
doesn't
block
your
own
calendar.
So
then
people
create
copies,
which
then
don't
stay
up
to
date.
If
you
join
the
google
group,
it
will
just
constantly
forward.
You
all
invites
and
updates
those
invites,
and
your
calendar
should
just
always
stay
in
sync.
A
A
Second,
I'm
looking
into
the
possibility
of
adding
the
playing
http
version
of
the
of
the
protocol
seems
like
that's
preferable
for
open
plan
jsd
case
to
use
in
the
future,
and
it
looks
visible.
I
played
a
bit
with
the
code
doesn't
seem
like
it's
going
to
be
complicated
to
add
and
the
third
is.
We
worked
with
our
legal
to
actually
donate
the
specification
to
open
telemetry
instead
of
us
open,
telemetry
licensing
it
like
we
do
with
apache
license.
It
doesn't
really
change
much
to
the
outcome.
A
It
just
makes
more
aligned
with
what
we
do
with
the
other
contributions
at
all
complementary,
so
it
will
just
have
the
open,
telemetry
copyright
instead
of
this
one
copyright.
That's
the
only
difference,
nothing
really
materially
changes
as
a
result
of
that
yeah.
So
that's
all
I
have
as
updates,
and
so
there's
this
one
item.
The
first
item
in
the
agenda
is:
who
is
the
person
who
put
it
there
supervisor
versus
extension?
Should
we
discuss.
B
That,
yes,
sorry,
that
was
me,
I
forgot
to
mention
that
I
added
that
one.
So
it's
just
you
know
we're
we're
happy
with
how
things
are
progressing
and
really
we're
just
exploring
of
what
model
we
want
to
kind
of
proceed
with
for
our
own
kind
of
implementations
of
remote
management,
whether
that
be
the
supervisor
versus
extension
model,
and
I
guess
it
just
raises
a
few
questions.
B
If
we
were
to
do
an
extension,
does
it
make
sense
to
to
contribute
one
in
more
of
an
upstream
way,
where
it's
more
of
a
if
others
are
more
interested
in
an
extension
for
this
purpose
of
putting
it
one
place
and
all
contributing
to
the
same
one,
or
does
it
make
sense
to
do
our
own?
Like
kind
of
vendor
specific,
you
know
a
sumo
logic,
op
amp
extension
for
our
our
more
specific
cases
and
then
related.
A
Yeah
yeah,
that's
that's
a
good
point
in
terms
of
code
reuse,
I
think
if
there
is
any
part
that
should
exist,
regardless
of
whether
it's
a
supervisor
or
an
extension,
we
could
put
that
in
the
opamp
dashboard
library
right
it
could
be
there.
Maybe
it's
not
a
client,
it's
not
a
server,
but
it's
something
some
sort
of
helper
to
build
a
supervisor
or
to
build
an
extension
right.
A
So
I
think
it
would
be
great
if
you
could,
if
you,
if
you
see
a
way
to
extract
that
that
portion
that
is
independent
of
the
decision,
whether
it's
a
supervisor
or
an
extension,
then
I
think
it
rightfully
belongs
to
this.
This
library
that
we
have
it
go
in
terms
of
whether
we
need
an
extension
or
no.
I
think
I
I
I
should
probably
defer
that
to
the
community.
If
people
want
it,
then
then
why
not
right?
A
Maybe
we
have
that,
especially
if
you
think
that
the
implementation
that
you
have
is
robust
enough
to
to
be
used
in
production.
I
think
it's
it's
it's
a
valid
approach.
Why
not.
B
I
think
we
still
have
to
to
explore
the
path
a
little
bit
further
before
we're
like
confident
to
that
degree
in
terms
of
production
use,
but
I
think
it
you
know,
I
think,
we're
fairly
confident
that
it
checks
the
majority
of
boxes
that
we
need
without
adding
you
know
a
secondary
process
and
yeah,
and
I
think
you
can
even
address
things
like
agent
upgrades.
It's
just.
It
might
have
to
do
a
little
bit
of
extra
song
and
dance
and
that
won't
be
able
to
be
reused.
A
B
I
appreciate
the
clarity
around
the
the
go
module
library
for
for
the
kind
of
the
shared
components.
So
I
think,
if,
if
that's
welcome
there,
we
can
absolutely
put
it
there.
Yeah.
A
I
think
it's,
it's
very
welcome
there,
one
more
thing
about
the
extension
sean
with
the
supervisor
model.
It
may
be
that
we
still
need
an
extension
which
is
used
for
the
supervisor
to
to
communicate
with
that
with
the
collector,
to
figure
out
the
state
of
the
collector.
The
extensions
have
access
to
the
to
the
state
of
the
whether
the
collector
is
up
and
running,
for
example.
So
let's
say
you
don't
have
a
health
check
extension.
You
don't
want
to
depend
on
that.
A
You
can
have
an
extension
which
cooperates
with
the
supervisor
to
provide
it
with
whatever
data
information
is
available
internally
from
inside
the
collector
to
help
the
supervisor
do
its
job,
so
there
may
be
a
need
still
for
an
extension
and
essentially
it's
a
it's,
an
old
pump
supporting
extension,
but
it
does
only
small
amount
of
the
work.
The.
A
A
A
B
Okay,
now
that
makes
a
lot
of
sense,
and
I'm
glad
you
raised
it
something
to
consider
now
naming
things
I
mean
we
haven't
been
too
bad.
I
mean
we've
all
kind
of
agreed
on
the
same
names.
Up
to
this
point,
yeah
yeah.
B
Okay,
now
now
is
this
also
because
you
know
we
don't
see
the
possibility
of
having
that
capability
make
its
way
into
the
collector
or
or
do
we
want
to
keep
it
like
the
the
piece
to
get
it
to
to
cooperate
with
the
supervisor
yeah,
so
that
that
part,
we
still
see
it
as
being
external
to
the
core
agent
itself.
B
A
If
they
are
using
the
supervisor,
but
actually
they
don't
need
to
enable
it
manually
if
you,
if
we
do
a
packaging
of
open
climate
collector,
which
includes
the
supervisor
and
the
supervisor,
is
responsible
for
creating
the
configuration
file
of
the
collector,
then
the
supervisor
just
trivially
puts
that
extension
enables
it
right
for
you.
You
don't
need
to
do
anything
as
an
end
user,
but
the
extension
as
a
component
has
to
to
still
be
in
the
the
collector
code
base
right.
So
it
has
to
be
somewhere
there
so
that
the
executable
includes
the
implementation.
B
Okay,
I
think
that
makes
a
lot
of
sense,
yeah
cool,
so
that
that
that
kind
of
addresses
my
question
so
now
I
know
you
know
if
there's
code,
reuse
opportunities,
we'll
put
it
in
the
go
project.
It's
welcome
there.
We
can
still
explore
the
extension
versus
supervisor
and
and
to
summarize
this
last
piece,
there's
likely
an
extension
required
anyways
to
make
the
agent
communicate
and
cooperate
with
the
supervisor,
and
that
could
give.
B
C
I
have
a.
I
have
a
couple
of
questions
like
probably
more
like
an
updates.
Excuse
me
so,
to
start
with,
I
I'm
I'm,
I'm
mostly
addressing
integrant's
comments
on
the
pr
and
I'll
push
a
new
version
of
the
pr
out
there,
so
that
others
can
take
a
look
at
it.
It
will
probably
a
bit.
It
will
probably
be
a
bit
more
simplified
because
few
things
are
not
really
necessary.
As
you
you
know.
As
I
said,
you
know,
as
I
see
from
tigran's
comments,
so
I'll
push
out
a
new
one.
C
I
also
raised
the
ticket
regarding
and
the
the
the
the
agent
thinker
being
part
of
the
of
the
supervisor,
and
then
taken
mentioned.
You
know
we
we
have
an
existing
interface.
The
only
thing
I
want
to
point
out
and
I'll
respond
to
the
ticket
as
well.
Is
that
even
then
yeah
we
need
to
let
the
op-amp
client
know
about
the
sinker.
C
I
mean
no
no
know
about
the
know
about
the
the
agent
package
state
provider,
which
has
to
be
external
to
the
client
in
my
understanding
right,
because
because
the
client
does
not
understand
the
nuances
of
the
agent
and
the
agent
is
the
one
who
knows,
you
know
which
files
to
update
and
things
like
that.
So
I
guess
the
packet
state
provider
implemented
implementation
should
be
outside
the
client
and
should
be
specified
to
the
client
as
per
the
start
settings
or
a
different
method.
I
believe
am
I
right.
A
Yes,
that's
a
state
provider
has
to
be
agent
specific
when
you
are
implementing
an
agent
which
uses
the
opamp
client
library,
you
provide
your
own
implementation
of
the
state
provider.
That's
that's
expected
right.
I
think
this
comes
back
to
what
I
was
saying.
I
need
more
examples
there.
I
need
to
actually
show
what
what
this
is
supposed
to
look
like
how?
A
How
is
this
supposed
to
work
so
I'll,
try
to
find
a
bit
more
time
to
actually
put
up
a
pr
which
which
shows
the
usage
of
the
package
thinker,
the
site
provider,
all
those
things
that
currently
are
like
kind
of
they
they
look
like
they
exist,
but
there's
really
no
code.
That
explains
how
this
all
works.
Right
and
yeah.
C
C
A
There
are
some
differences.
Primary
difference
is
that
there
is
a
single
package,
but
the
add-ons
you
have
multiple
of
those
right.
They
are
main
main
buttons
correct,
but
the
the
I
guess
the
operating
mode
is,
is
very,
very
similar.
There's
a
state
there
is
a
progress
made
being
made
on
the
downloading,
etc.
Yes,
they
are
simpler.
C
Right
and
one
other
thing
is
that
there
was
some
discussion
about
the
config
file
being
mentioned
twice
in
the
you
know
as
part
of
the
yaml
file,
and
I
guess
we're
trying
to
avoid
that.
But
I'm
just
curious:
should
we
worry
about
it
at
this,
this
point
or
should
just
live
with
it
for
now
and
then
see
if
we
can
improve
it
later.
A
For
the
generic
supervisor
right,
I
don't
see
a
good
way
to
to
avoid
it,
so
I
think
it's
fine
for
now,
but
let's
keep
that
in
our
mind
and
I
think
at
some
point
we
should
probably
have
this
this.
This
very
likely.
We
need
a
specific,
open,
telemetry
collector
specialized
supervisor,
which
then
avoids
having
this
big
file
referenced
twice
in
the
supervisor.
Config
right.
C
And
I
guess
one
last
thing
excuse
me:
I
have
is
like
what
should
we,
what
would
be
the
the
natural
progression
for
this
pr?
Do
we
is
this
more
like
a
draft,
or
should
we
take
it
like
to
the
next
and
and
try
to
merge
to
master
after
addressing
the
comments
and
any
other
things
that
come
out
of
it
just
curious,
or
is
it
more
like
a
like,
like
probably
a
reference
on
which
you
know
on
top
of
which
we
can,
we
can
have
further
discussions
and
figure
out.
A
To
use
the
pr
as
an
opportunity
to
discuss
the
design
to
to
which
what
what
we're
doing
right,
I
I
don't
know
if
you
merge
the
pr
as
it
is,
or
maybe
you
maybe
you
keep
it
as
as
kind
of
a
reference
point.
But
then
you,
maybe
you
can
yes
so.
A
C
I
think
that
will
be
a
you
know,
a
much
better
approach.
You
know
I'll
start
putting
out
this.
You
know
addressing
the
these
comments
that
you
have
posted
and
then
hopefully
we
will
see
you
know
a
proper
way
to
get
this
into.
C
The
mass
will
probably
separate
prs
or
one
single
yeah,
but
then
I
just
have
one
small
update,
like
I'm
moving
from
cisco
to
merida
fairly
soon,
so
this
friday
will
be
my
last
day,
so
I'll
contribute
as
much
as
I
can
before
that
and
if
you
know,
if
I
go
to
meta
and
then
I,
as
since
I've
seen
that
facebook
also
is
a
big
contributor
to
open
telemetry,
so
I'll
try
to
see,
if
I
can,
you
know,
find
some
place
there.
C
C
D
Sure
they'd
be
open
to
you
contributing
in
your
free
time,
but
but
that's
a
large
commitment
for
you.
Yeah.
C
But
it
has
been
very
interesting.
I've
been
here
only
for
a
brief
live
a
brief
while
like
about
a
couple
of
months
and
I've
really
enjoyed
this
whole
process.
This
is
very
new
to
me,
and
so
thanks
a
lot
for
triggering
sean
pleasure,
mac
and
others
to
to
kind
of
help
me
through
this
process
and
so
great,
so
I'll
contribute
as
much
as
I
can
before
I
leave
and
then
david
and
then
and
kelsey,
who
are
in
the
call,
will
be
replacing
me
from
cisco.
A
Sounds
good
you
should
probably
reach
out
to
yuri
yuri
shkuro,
who
is
on
the
technical
committee
of
open
telemetry
and
he's
he's
at
facebook
met
her
now
I
guess
so.
Maybe
you
guys
can
do
something
together.
I
don't
yeah
thank.