►
From YouTube: 2022-06-14 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
I
I
logged
an
issue
probably
two
weeks
ago
that
nobody
commented
on
I'd
be
curious.
What
people's
thoughts
are?
Maybe
we
could
talk
about
it
real,
quick
now
the
issue
is.
A
Here
but
it's
adding
a
close
option
to
the
connection.
C
Yeah,
I
don't
really
have
any
issue
with
that.
I
think
it
makes
sense
and
not
everybody
would
have
to
use
it.
It's
just
another
tool
for
op-amp
and
I
think
your
reasoning
of
causing
load,
balancing
or
triggering
rebalancing
is
a
good
use
case.
A
Next
is
using
long
polling
just
to
look
at
what
that
looks
like
on
the
implementation
side,
but
certainly
for
web
sockets.
They
could
be
held
open
for
a
long
time.
B
A
Okay,
anything
else
was
it
on
the
agenda
beforehand.
I
believe
tigran's
out
this
week
on
vacation,
I'm
not
sure,
usually
tigran's
got
a
plan
so.
D
Thing
to
what
you
are
working
on
like
we
can
configure
remotely
sampling
rules
and
data
collection
rules
and
very
basic
configuration
for
like
the
otlp
exporter,
and
they
came
across
your
work.
It's
a
very
good
work
and
I
wanted
to
ask:
what's
what's
the
vision
for
the
future?
Do
you
imagine
that,
like
there
will
be
like
open
source
sdks
that
are
like
maintained
by
the
community,
that,
like
vendo
agnostic,
that
people
can
use
and
vendors
can
implement
the
server
to
control?
A
I
think
the
initial
goal
is
to
get
the
protocol
in
place
and
have
a
reference
reference
implementation
of
the
protocol
itself
and
then
allow
that
protocol
to
be
you
know,
potentially
implemented
differently
in
clients
and
servers,
clients,
being
agents,
service,
being
management,
platforms
of
all
sorts,
so,
ideally
being
able
to
manage
other
agents
in
the
future
and
also
vendors
building
management
built
or
building
capability
into
their
management
platforms.
B
Yeah
and
amir,
if
I
understood
correctly,
you
have
let's
say
like
no
javascript
instrumentation-
that
you
want
to
connect
potentially
with
with
op-um
for
for
configuration,
because
if
that's
the
case,
then
it's
one
of
the
reasons
we
have
added
http
support,
like
so,
let's
say
the
the
thinner
clients
that
don't
have
a
lot
of
dependencies
like
web
sockets
and
everything
like
that.
They
could
could
use
it
easily
with
just
http
to
to
pull
information
about
the
current
config.
D
Yeah,
so
actually
we
have
an
implementation
in
a
node,
that's
using
a
websocket.
So
when
the
user
is
changing
the
configuration
we
update
it
automatically
to
the
agents,
and
we
also
have
implementation
in
ruby,
which
has
no
support
for
a
socket
io.
So
we
do
it
with
polling
with
http
and
we're
looking
to
extend
the
capabilities,
so
I'm
kind
of
like
thinking.
Maybe
we
should
use
opinp
instead
of
what
we
use
currently,
which
is
just
something
that
we
crafted
like
internally.
B
Yeah,
so
the
specification
is
is
just
let's
say
on
on
the
connection
like
how
this
like
how
the
connection
should
be
established.
What
kind
of
information
could
be
sent
back
and
forth
and
you
can
pretty
much
send
any
payload
like
in
the
configuration?
B
There
are
some
concepts
like
the
the
configuration
like
the
the
connection
settings
and
etc,
but
I
think
that
this
is
like
something
very
generic
in
terms
of
the
specific
implementation,
we
have
reference
implementation
in,
go
which
can
be
used,
and
I
think
that
the
model
here
is
similar
to
the
model
we
have,
for
example,
with
like
other
pieces
of
open
telemetry.
There
is
the
concept
of
distribution,
so
you
as
a
vendor
can
take
that
code
and
and
build
your
own
distribution,
maybe
with
some
additions
to
to
to
that
that
code
base.
B
That
adds,
let's
say
your
specific
capabilities,
but
it's
based
on
the
same
core.
Essentially
that
is
like
provided
by
the
community,
and
I
think
that
this
model
could
work
here.
I
I
think
that
there
will
be
many
agents
that
will
be
using
op-um
to
to
communicate
with
with
many
servers.
So
it's
might
be.
B
It
might
be
something
I
know
it's
like
there
might
be
like
cases
that
that
one
server
can
support
multiple
agents,
but
it's
not
it's
not
necessarily
true,
so
I
I
don't
think
that
there
will
be
like
one
single
agent
and
one
single
server.
I
think
that
they'll
block
many
of
them.
B
So
the
the
we
don't
really
have
sdk,
I
think,
for
for
op-um.
We
have
only
this
reference
implementation
in
in
go
like
for
the
protocol
and
and
some
code
around
it.
So
it's
not
necessary
it's
not
strictly
sdk.
So,
for
example,
if
you
have
a
javascript
code
that
you
want
or
like
library,
instrumentation
or
agent,
or
anything
that
you
want
to
use
with
with
opamp,
then
you
need
to
implement
this
code
yourself
right
now.
B
B
I
think
it
depends
what
what
kind
of
project
you
have
like,
because,
for
example,
I
imagine
that
in
the
future
we
will
have
open
telemetry
instrumentations,
with
support
for
op-amp
to
dynamically
change
its
properties.
E
So
let
let
me
clarify
something
so
with
with
op-amp.
The
client
is
expected
to
be
really
the
collector,
not
not
the
tracer,
not
the
sdk.
So
that
was
the
first
case
that
was
addressed.
It
is
possible
to
extend
it
to
sdk
and
tracer,
but
all
the
focus
so
far
as
far
as
I
recall
was
for
collector
and
the
connection
between
tracer
and,
as
the
case
can
be,
can
be
made
through
files.
E
So
op-um
allows
us
to
push
configuration
files
to
the
collector,
which
can
be
then
written
to
a
file,
and
the
sdk
or
tracer
can
pick
up
those
changes
if
it's
written
in
a
special
way
that
will
watch
for
changes
in
the
configuration
file.
At
least
this
is
how
we
are
planning
to
to
use
this
functionality.
B
E
B
But
I
have
one
comment
here
like
there
are
many
cases
for,
for
example,
client,
instrumentation,
sick,
when
mobile
devices
are
like
data
from
mobile
devices
is
being
collected
or
from
from
web
browsers
directly
like
some
remote
ones,
and
for
those
you
certainly
do
not
have
the
local
collector
running
as
an
agent
on
the
same
device,
and
I
think
that
well,
it
will
be
interesting
to
have
capabilities
to
configure
those
using
opump.
If
the
current
specification
is
like
enough
to
cover
those
use
cases
or
or
not,
we
don't
know
like.
B
We
did
not
explore
that
path.
But
my
feeling
is
that
it's,
it's
maybe
a
next
step
like
after
this
specification
will
be
like
mature
enough
for
the
agent
management.
Then
maybe
we
could
use
it
for
instrumentation
management
to
some
extent.
D
Okay,
cool
and
one
last
question:
do
you
know
when
it
will
be
stable,
like
what's
the
plan
for
to
become
stable.
A
A
Metal
failure,
yeah,
there's,
there's
four
issues
tagged
required
for
stable.
We
had
a
discussion
two
weeks
ago
about
this
we'd
like
to
to
drive
toward
being
stable
in
the
near
term.
I
guess
that's
as
much
specificity
as
we've,
given
it
so
far,
there's
not
a
deadline
or
anything,
but
I
think
if
there
were,
if
somebody
wanted
to
put
a
deadline
out
there
because
of
their
own
requirements,
you
know
we.
We
could
possibly
rally
around
that
and
and
get
this
towards
stability.
There's
been
it's
been
very
volatile
in
the
past
month.
A
I
would
say
a
lot
of
really
good.
Work
has
been
done
to
iron,
some
things
out
and
refactor,
some
of
the
message
formats
and
but
but
I
believe
it's
converging
on
stability,
but
there
are
a
few
remaining
issues
in
the
spec
that
need
to
be
resolved,
and
then
those
might
be
some
consequences
for
the
reference
implementation
that
come
from
that
spec.
A
Okay,
cool.
Thank
you
very
much
sure,
and
just
to
give
you
a
little
background
on
our
role
in
this.
We
we
also
had
our
own
protocol
for
managing
agents.
We
used
to
have
node
services
in
typescript
that
managed
a
java
based
collector.
A
We
replaced
our
java
base
collector
with
open
telemetry,
so
we're
now
everything
we
do
is
built
around
the
open,
123
collector
in
go
and
our
management
platform
that
we're
working
on
is
all
in
go
as
well,
and
so
you
know
we're
using
op-amp
the
upgo
library
on
both
sides
of
the
agent
and
the
and
the
server.
A
But
we
we
also
have
a
long
history
of
doing
this
and
and
originally
had
our
own
protocol
and
felt
like
if
there
was
if
the
community
was
converging
on
a
on
a
protocol
that
was
going
to
be
really
useful
in
terms
of
being
able
to
support
many
different
agents
in
the
future
and,
of
course,
there's
actually
zero
agents
right
now
that
support
it,
because
it's
not
in
open
television,
trades
it
over
203
projects,
but
not
in
the
collector
right
now,
but
but
that's
also
the
goal
so.
D
A
Great
well,
nice
meeting
you
and
thanks
for
coming
and
sharing
your
thoughts.