►
From YouTube: 2022-02-08 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
A
A
I
I
took
that
as
as
a
starting
point,
but
wrote
a
slightly
different
document
which
describes
a
specific
supervisor
for
open,
telemetry,
collector
kind
of
just
just
a
draft
document,
I'd
like
to
see
what
others
think
about
it.
So
I'm
looking
for
for
some
comments,
reviews
here.
I
put
the
link
there
in
the
in
the
issue.
A
There
are
a
couple
open
issues
there,
which
I'm
not
quite
sure
what
this,
what
the
right
approach
is,
how
we
solve
those.
So
if
you
have
any
thoughts,
it
would
be
great
to
hear
what
you
think
about
it.
That's
the
first
one
I
don't
know
if
anybody
wants
to
discuss
the
supervisor
here
in
this
call.
A
I,
when
I
wrote
the
spec
I
was
looking
into
the
transports
I
kind
of
tried
to
look
into
some
of
the
aspects
and
brought
some
justifications
about
the
choices
that
I
made.
I
think
there
is
some
some
evidence
that.
A
Maybe
some
of
those
justifications
that
are
not
necessarily
valid
anymore,
so
I
listed
a
few
points
there
in
the
linked
issue.
I
think
it's
worth
maybe
rethinking
doesn't
necessarily
mean.
B
A
It
will
be
what
we
want
to
do,
but
because
I
heard
a
couple
times
from
others
as
well,
I
think
it's
worth
maybe
opening
the
discussion
to
see
what
people
think
in
favor
against
grpc,
instead
of
or
in
addition
to
web
sockets.
A
A
Okay,
so
if
you
want
to
comment
offline,
the
issues
open
there
as
well,
the
last
one
is
what
we
tried
to
discuss
the
last
meeting:
hey
primek.
Yes,
your
the
issue
that
you
open.
We
were
not
quite
we
tried
to
figure
out.
What
is
it
that
we
want,
or
you
wanted
us
to
discuss,
but
we
didn't
manage
to
so
maybe
you
can
tell
us
this
time
and
we
talk
about
it
now.
A
C
Okay,
let
me
switch
to
the
built-in
microphone
now.
Can
you
hear
me?
Yes,
yes,
okay,
so
so
the
the
this
issue
was
a
smaller
thing.
That
is
part
of
a
bigger
topic.
So
maybe
let
me
start
with
with
the
first
one
so
and
because
it's
it's
fairly
simple,
so
right
right
now
we
assume
that
the
instance
id
used
for
identifying
the
the
agent
is
being
generated
on
the
agent
side.
C
So
essentially
supervisor
can
generate
such
agent
and
and
persist
it
and
use
it
in
all
the
future
communication
with
the
agent
and
maybe
that's
good
enough,
but
maybe
it
will
be
safer.
If
that
would
that
could
be
responsibility
of
the
server
when
he
sees
a
given
agent
because
then
well,
it
might
ensure
that
the
algorithm
is
fair,
that
there
are
like
no
collisions,
and
things
like
that
like
so
when
I
was
discussing
this
within
my
team,
there
were
like
some
concerns.
C
What
will
happen
if
this
would
be
generated
by
agents,
and
maybe
there
will
be
some,
let's
say,
adversarial
agents
that
will
try
to
generate
always
the
same
id,
and
this
will
cause
all
those
issues
or
maybe
there
are
some
sort
of
bug
and
things
like
that.
So
I'm
not
sure
if
this
is
a
real
concern
or
not,
but
that
was
really
the
topic
of
this
issue.
C
However,
maybe
what's
more
interesting
is
the
bigger
concept,
because
this
is
about
really
one
of
the
modes
of
registration
that
we
want
to
support
on
our
site,
and
maybe
it
makes
sense
to
consider
this
as
part
of
open,
and
the
idea
is
that
there
is
something
called
installation
time
token.
So
you
can
imagine
that
maybe
you
have
several
environments
and
you
want
to
apply.
I
don't
know
different
attributes
in
each
of
these
environments.
C
The
server
then
can
assign
the
configuration
that
is
specific
to
this
installation
token,
and
then
it
can
be
used
to
say
well
provide
the
configuration.
So
it's
a
means
of
identification
of
of
the
agent
or
like
or
a
collection
of
agents
and
yeah,
and
this
is
where
it's
important
that
when
one
installation
token
is
used
and
ign
registers,
it
gets
some
unique
identifier,
and
this
identifier
must
be
persistent,
because
if
it's
not,
then
bad
things
can
happen.
So
so
so
that
was
the
motivation
behind
this.
The
decision.
C
Yes,
so
installation
token
can
be
shared
by
a
group
of
agents
and
it's
used
only
for
identification
when
registered
registering.
So,
for
example,
you
can
say
that
I
want
to
have
a
specific
installation
token
for
my
java
services
running
in
some
environment
and
they
will
have
specific
configuration
that
we
assigned.
A
Yeah,
so
let
me
I
guess,
address
you,
you
raise
two
topics.
One
is
the
instant
site
right,
whether
it's
generated
by
the
agent
or
the
server.
I
I
looked
into
the
possibility
of
the
server
being
the
driver
of
this
right.
If
the
server
generates
the
instance
id
that
requires
the
agent
to
persist
it
right.
If
the
agent
receives
it,
it
needs
to
somehow
persist
it.
Otherwise,
if
it
reconnects
it
will
it's
going
to
be.
A
It
will
look
like
a
brand
new
agent
right
if
you,
if
you
always
make
the
the
server
generate,
one
which
is
maybe
fine
in
some
cases,
in
some
cases
it
may
be.
No,
whereas
if
this,
if
the
agent
is,
is
responsible
for
that,
the
server
may
have
access
to
a
unique
identifier
which
it
doesn't
need
to
persist
a
persistently
available
one
like
if
you
have
an
sm
bios.
Typically,
there
is
a
new
id
that
you
can
query,
which
is
unique,
which
you
can
use,
but
you
don't
need
to
persist
it.
A
We
could
maybe
combine
these
two
approaches
and
if
we
had
the
ability
for
the
server
to
tell
the
agent
to
change
the
the
id
and
supply
an
id
in
that
case
and
the
server
maybe
could
do
that
when
it
detects
duplicates
for
example
or
stuff
like
that,
some
some
bad
situations,
we
could
probably
have
both
the
best
of
the
both
worlds
right.
If
the
agent
is
able
to
generate
it,
will
if
it's
not,
then
it
will
connect
and
the
server
will
see
that
there
is
nothing
there
that
the
id
is
missing.
It
will
generate
one.
A
C
Yeah,
so
actually,
I
have
an
idea,
because
one
way
this
could
be
achieved
is
that
if
the
agent
would
be
supporting
this
as
a
part
of
the
configuration,
then
actually
server
could
send
it
as
the
configuration
for
the
agent,
and
it
could
be
persisted
that
way
by
the
agent.
It
would
always
get
the
same.
Configuration.
A
Provided
the
agent
is
capable
of
persisting?
Yes,
of
course,
but
it's
always
about
persistence,
yeah,
yeah,
yeah,
so
yeah,
I
I
I
don't
know,
that's
that's
what
I
was
thinking
like.
I
think
it's
a
possibility
to.
Maybe
we
keep
even
both
right.
The
agent
generates.
If
it
wants
to
generate.
If
it
doesn't,
then
it
gets
assigned
the
one.
On
the
first
communication
the
server
generates
and
sends
vector
that
the
initial
id.
A
B
Of
the
open
issues
I
mentioned
this,
I
think
two
weeks
ago,
this
was
my
understanding
that
this
is
how
the
protocol
works,
but
you
explained
to
me
that
this
is
actually
an
open
issue,
number
24.,
so
it
looks
like
we
are
going
back
to
the
same
schema.
A
Yeah
and
again,
yes,
the
the
issue
is
open.
I
I
don't
see
any
comments
there,
so
I'm
not
sure
whether
we
actually
want
to
do
anything
about
it.
It's
certainly
doable.
I
mean
it's
not
complicated,
to
modify
the
protocol
to
allow
to
do
this,
and,
but
I
don't
know
if
we
want
it
to
be
the
only
mode
right
when
the
when
the
server
always
does
this
generation.
I
am
not
so
sure
about
this,
so
perhaps
we
need
both.
A
I
don't
know
some
thinking
is
necessary
here
for
for
for
your
second
item
that
you
wanted
to
discuss
the
the
installation
time
token
right.
I
think
it
if
you
read
the
the
spec
it
has
this
well,
not
maybe
directly
wristed
by.
If
you
look
at
the
the
the
client
certificate
portion,
it
has
this
trust
on
first
news
right
that
portion
where
the
where
and
and
it
is
coupled
with-
with
ability
for
the
server
to
regenerate
access
tokens
and
client
certificates.
A
It
essentially
amounts
to
what
you
you're
describing
you.
Can
you
can
give
the
agent
an
initial
access
token
or
an
initial
client
certificate,
some
sort
of
credentials
which
are
for
first
time
use
only
when
it
connects
to
the
server
it's
up
to
the
server?
If
you,
if
the
server
wants
to
use
the
ability
to
push
changes
to
the
to
the
connection
credentials,
the
server
can
do
it
which
allows
it
to
rotate
the
access
token
so
that
the
first
time
token
is
no
longer
used.
A
There
is
maybe
a
unique
token
assigned
to
the
particular
agent
or
also
include
a
client
certificate
for
that
particular
agent.
That
is
part
that
is
a
possible
way
to
use
the
protocol.
I
I
had
this
scenario
in
my
mind
where
you
must
deploy
agent,
you
give
all
of
those
agents
the
same
access
token
for
the
initial
connection,
but
you
don't
really
want
them
to
continue
using
that
for
the
for
the
actual
ongoing
communication
with
the
server.
A
So
after
the
first
connection,
the
server
issues
a
unique
one
for
each
of
the
agents,
which
then
decouples
all
the
agents
from
one
another.
You
can
rotate
individual
access
tokens
afterwards,
but
you
do
not
need
individual
access
tokens
for
the
for
the
installation
phase
right,
it's
more
complicated,
it's
easier
to
must
deploy
using
the
same
access
token
for
all
of
the
for
all
of
the
agents.
So
I
think
it's
already
part
of
the
protocol.
If
you
look
at
what
is
there,
this
scenario
is
supported.
You
can
actually
do
this.
What
you
were
describing.
C
Yeah
yeah
exactly
so.
I
think
that
this,
if
we
would
add
this,
let's
say
capability-
to
generate
the
instance
id
on
the
server
to
always,
because
then,
when,
when
the
agent
is
being
registered,
then
already
it
can
be
assigned
to
some
id
provided
by
the
server.
In
that
case,
and
we
would
say
not
have
to
worry
too
much
about
this
duplicate
ideas,
I
think
it's
it's.
It
simplifies
some
ways.
A
Will
it
work
if
we
allow
both
like
the
agent
is,
allow
it
to
generate,
but
is
not
required
to
generate
its
own
instance
id
and
the
server.
Then,
if
we
allow
the
server
to
push
instance
ids
to
the
agents,
it
covers
both
use
cases,
both
the
duplicate
and
society
case
and
the
first
time
assignment
right
using
the
same
exchange
essentially
right.
The
server
just
gives
an
instance
id
whether
it's
because
of
the
duplicate
detection
or
because
it's
the
first
time
assignment,
doesn't
really
matter.
The
agent
just
needs
to
accept
it
yeah,
I
think
so.
A
Yeah,
okay
yeah,
I
don't
know
if
there
are
any
other
things
that
we
need
to
consider,
but
it
does
sound
reasonable
to
me
reasonable
addition.
It
opens
up
essentially
two
interesting
probabilities,
duplicate,
detection
or
reacting
to
duplicate,
detection
correctly
and
assignment
on
the
first
use
of
the
instance.
Id
is
first
connection.