►
From YouTube: 2021-11-16 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
C
B
C
Like
we
had
like
two
months
of
rainfall
in
a
single
day
yesterday
and
across
of
all
british
columbia,
we
lost
all
of
our
major
highway
routes.
So
if
you're
in
the
lower
mainland,
you
can't
get
anywhere
north
in
british
columbia
and
we
can't
get
down
so
supplies
are
cut
off.
Everything's
everything's
great,
you
know
just
on
the
forefront
of
climate
change.
Here,
we've
got
the
the
fires
and
the
floods,
and
no,
but
today
we
had
our
first
snow.
Just
you
know
an
extra
kick
us
while
we're
down,
but
it
was
lovely.
C
Where
do
you
live,
I'm
up
in
kamloops?
Oh.
C
Nice
yeah,
we
have
a
number
of
scentsy
folks
in
in
vancouver,
so
we've
been
at
the
both
ends
of
the
cut-off
talking
about.
D
D
C
Yeah
some
of
the
imagery
is
just
shocking
watching
the
news
this
morning.
It's
just
unbelievable.
It's
a
good
thing,
there's
at
least
barges
right
in
vancouver
right
now,
yeah.
D
Yeah
I
live
in
kitsilano,
and
so
we
had
like
a
32-foot
sailboat
just
lose
his
keel
and
lose
its
anchor
then
lose
his
keel
and
smash
up
on
the
beach.
And
then
I
saw
the
photos
of
the
barge
like
10
minutes
from
here.
Oh
wow,
fun
times.
A
Right,
let's
start
then
so
the
first
one
was
there
was
a
request
to
figure
out
what
the
priorities
are.
I
opened
an
issue.
I
think
we
have
some
amount
of
votes
that
make
it
relatively
clear
what
the
top
three
items
are.
That's
the
remote
configuration
is
the
top
one,
then
the
all
telemetry
reporting
and
then
basic
status
reporting.
A
The
other
three
connection.
Settings
auto
updates
add-ons
are
clearly
the
losers
here.
I
think
that's
that's
fairly
clear,
so
that
sends
a
signal
that
we
need
to
start
with
this,
and
I
think
it
also
means
that
we
need
to
make
sure
that
the
spec
is
more
elaborate
and
clearer
for
these
three
areas.
First,
before
we
work
on
the
rest
of
the
areas,
so
I
think
that's
good
so
yeah
this
is,
I
think
this
is
actionable.
Anybody
has
any
any
additional
thoughts
on
this.
A
So
I'd
like
to
have
some
reviews.
This
is
very
draft
and
preliminary
to
to
have
feedback
on
what
people
think
about
the
api.
Maybe
suggest
alternate
apis
if
you're
experienced
in
go
in
in
designing
programmatic
apis
in
designing
apis
in
go
especially,
would
be
great
to
have
your
your
feedback.
Your
input
on
this.
A
Let's,
let's
decide
how
we
want
to
expose
this
functionality
to
the
agents
who
want
to
implement
the
protocol,
and
I
think
once
we
have
that
then
we'll
be.
We
can
then
start
the
implementations
of
the
particular
features.
So
I
I
just
proposed
one
possible
there
using
callbacks,
but
I
think
there
are.
There
are
other
ways
to
approach
this,
so
I'd
like
to
have
some
feedback
from
from
you
from
everyone.
A
You
have
anything
you
want
to
talk
about
right
now,
with
with
regards
to
the
api.
We
can
do
it
now.
Anybody,
if
you
had
a
look
already.
A
Okay,
please
have
a
look
comment
on
the
pr
I
open
the
draft
pr
there.
The
link
is
in
the
meeting
notes.
Next
is
the
protocol
name,
so
there
are
concerns
about
the
search
ability
of
the
protocol.
Name
like
it's.
It's
a
it's
a
name
for
for
a
very
popular
thing
in
electronics,
world
operational
amplifiers,
which
I
think
is
kind
of
a
nice
plan.
But
maybe
it's
not
such
a
good
idea
when
you
need
to
search
for
the
protocol
specification
or
whatever.
So
there
are
a
few
proposals
about
other
names.
A
I
don't
think
any
of
the
proposed
names
got
like
a
significant
number
of
votes
to
make
a
change.
There
was
another
proposal
from
from
josh
j
mcd
to
use,
I
think
otm
as
the
name,
which
kind
of
it's
confusing
to
me.
It's
it's
a
one
letter
difference
from
otlp,
so
I
don't
know
how
how
good
that
one
is
and
but
that
got
some
I
guess
most
upvotes
there.
So
I
don't
know
I'd
like
people
to
talk
about
what
they
think
is
the
right
approach.
A
C
A
I
think
my
initial
thinking
was
that
we
do
not
want
this
to
be
limited
to
open
telemetry
optimized,
maybe
for
open
telemetry,
but
definitely
not
limited
to
open
telemetry,
and
for
that
I
think
it's
important
that
the
name
conveys
that
right,
that
thinking
that
we
are
actually
marketing
this
trying
to
sell
this
to
not
just
to
open
telemetry,
not
just
for
our
own
use,
but
for
for
others
as
well.
So
for
that
reason
I
think
it's
useful
if
we
can
try
to
avoid
using
open
telemetry
in
the
name-
and
it's
I
mean
it's
an
interpretation.
A
C
A
So
I
guess
the
the
alternate
was
like
slight
modification
from
the
current
one
or
aae
mp.
I
I
can't
even
pronounce
them.
I
don't
know
how
you
pronounce
it
round
or
m.
It's
unclear
to
me
the
other
one
that
got
some
votes,
but
the
the
other
suggestions
didn't
get
any
votes.
So
I
I
don't
know
what
to
do.
What,
at
this
stage,
no
good
suggestions,
no
good
alternatives
seems
like.
F
Yeah,
for
me,
none
of
the
alternates
seem
good
they're,
not
pronounceable
or
they're
they're
weirdly
pronounceable.
I
I
think
op-amp
is
probably
fine
if
we
really
are
averse
to
having
open
telemetry
in
the
name,
I'm
not
so
sure
that
I
see
otm
as
saying
it's
specific
to
open
telemetry.
A
E
Yeah,
I
kind
of
dislike
that
one
because
it
sounds
to
me
like
it's
saying:
telemetry
management,
which
certainly
to
a
large
extent,
that's
what
we're
trying
to
do
here,
but
you
know
it
makes
it
sound
like
we're
routing,
telemetry
or
things
like
that,
whereas
there's
a
lot
more
to
it.
I
think,
like
that
word
agent
needs
to
be
in
there
somewhere
or
something
equivalent.
C
I
mean
it
is
naming
a
protocol
as
well,
not
not
like
a
project
or
like
the
installable
that
people
are
searching
for
for
documentation
in
use.
It's
more
of
an
you
know
for
an
implementation
detail
of
of
said
things.
So
actually,
in
my
opinion,
like
the
search
issue
around
op
amp
is,
is
you
know
less
than
if,
if
that
was
the
name
of
our
project
that
we're
pushing
as
the
agent
name?
C
A
Yeah
and
and
search
issue
tends
to
become
less
problematic
over
time,
because
kind
of
search
engines
are
good
at
picking
up
the
new
things
like
otlp,
when
initially
it
was
named,
google
always
auto-corrected
it
to
oltp,
because
that's
a
thing
right,
but
then
it
gave
up
it
now
knows
what
that
otop
is.
If
you
search
for
that,
you
actually
get
otlp,
so
I
don't
know,
maybe
eventually
we'll
get
op
as
two
different
things.
One
is
from
from
whatever
it
is
today
and
the
other
one
I
don't
know.
Maybe
it's.
D
I
I
agree,
I
don't
know
if
it
really
matters
to
be
honest,
both
both
because
like
if
we
were
talking
about
the
name
of
open
selling
to
the
project,
I'd
be
a
little
more
opinionated
about
it,
but
but
also
yeah
it'll
get
indexed
it'll
get
found
correctly.
A
I
just
saw
her
now:
okay,
I
don't
know
if
the
votes
are
for
the
name
actually
right,
because
josh
talks
about
other
things
as
well.
Is
it
limited
to
the
agents,
so
I'm
not
quite
sure
how
to
interpret
this.
I
tried
to
ask
people
whether
they
are
voting
for
the
name
or
for
other
things
that
josh
asked
about
whether
it's
limited
or
not
limited
for
for
to
to
the
agent,
or
maybe
we
use
that
in
the
sdk,
so
kind
of
unfortunate.
F
That
yeah,
for
me
it
was
a
bit
of
both
the
potential
for
confusion
with
open
amp
and
for
the
the
name
otm.
I
think
the
the
other
name
that
I
had
suggested
somewhere
else,
but
that
didn't
appear
here,
was
open.
Ramp,
remote
agent
management
protocol
just
to
add
a
little
bit
more
clarification,
which
could
suffice
as
well
to
to
distinguish
between
open
amp
and
op
amp.
A
A
Okay,
let's,
let's,
let's
do
this,
I
don't
know
I
can
maybe
try
to
start
the
world
again
with
the
additional
names
which
the
one
that
we
might
not
missed
open
ramp.
Was
there
another
proposal
with
ltmp,
I
guess
again,
but
if
we
do
that,
if
we
restart
the
vote,
we
we
need
to
to
do
the
votes
quickly.
I
don't
know,
does
anybody
think
that's
a
good
idea
or
we're
just
unnecessarily.
F
Like
it,
I
forget
what
the
the
gc
elections
used
or
something
like
that
where
you
know
this
is
actually
a
voting
platform
and
we
can
say
yes,
these
are
the
things
that
I
would
be
okay
with
and
then
pick
the
one
that
most
people
are
okay
with.
I
don't
know
if
thumbs
up
on
on
comments
and
a
github
issue
or
the
best
way
to
vote.
D
F
A
A
But
also
we
missed,
we
missed
anthony's
suggestion
open
ramp
yeah.
Oh
that's.
D
Right,
okay,
you
could
also
do
google
form.
A
A
For
it,
yeah
requirement,
okay,
all
right,
how
many
people
we
have
16?
Okay,
okay,
that's
good!
So
the
first
one
to
react
to
is
the
current
thing
right
open?
Let's,
let's
do
how
do
you
so
we.
D
E
A
Okay,
eleven
four
four
pounds:
11.
the
second
one
is
otm
right:
otm
go
for
it
otm
one,
two,
three,
four,
five,
six.
H
C
I
A
Yeah,
okay:
this
was
good
thanks.
Everyone
no
more
time
spending
on
this
we're
good
with
this
one,
all
right
next,
so
I
opened,
I
went
over.
The
spec
opened
a
number
of
open
issues
in
the
spec
repo.
A
Some
of
those
are
existing
open
questions.
The
others
are
things
that
I
explored.
It
are
missing
and
and
also
then
I
believe,
opened
a
few
I'd
like
some.
I
guess
opinions
counter
arguments
if
you
have
a
use
case
for
the
particular
thing
that
tells
maybe
how
we
should
do
that.
Please
please
go
ahead
and
comment
on
the
specific
issues.
A
There's,
I
think,
a
bunch
now
like
20
or
more
even
already
things
that
would
we
would
want
to
clarify
in
the
specifications,
so
it
would
be
very
useful
to
have,
especially
if
you
have,
if
you
have
a
particular
use
case,
which
is
related
to
what
is
being
discussed
in
the
issue.
I'd
like
us
to
be
driven
even
more
by
the
actual
use
cases.
Please
do
that
the
link
is
there
in
the
meeting
notes
document,
and
I
don't
think
we
need
to
discuss
any
of
this
right
now.
Well,
unless
anybody
wants
to.
C
C
So
one
thing
I
just
wanted
to
share
now:
I
don't
know
one
question
that
came
up
for
me:
I'll
share
my
screen.
If
that's
okay,
can
you
all
see
this
all
right
yeah
and
I
apologize
I'm
not
trying
to
push
any
sense
of
stuff
on
anyone.
C
This
is
just
some
things
that
came
up
when
we
are
implementing
what
we
refer
to
as
assets,
which
are
effectively
like
our
add-ons
for
components,
both
around
collection
and
the
back
end
pipelines,
and
the
idea
is
that
an
asset
is
yeah,
just
a
url
and
a
shaw
generally
over
tls,
but
each
asset
has
one
or
more
builds.
So
it's
just
it's
a
single
tar
package
that
actually
includes
one
or
more
files.
C
We
do
some
trickery
around,
like
environment
variables,
to
unpack
them
as
like
a
sandboxed
environment.
But
what
I
want
to
raise
is
the
fact
that
we
do
some
filtering
around
like
agent
local
environment,
stuff
like
is
it
linux
or
windows
or
mac,
so
that
a
asset
is
a
package
of
things
from
a
web
repository
that
has
a
shaw
and
there's
one
or
more
possible
builds
of
that
thing,
and
then
you
have
some
selectors,
for
which
one
gets
unpacked
on
which
platforms
so
around
add-ons.
C
I
don't
know
if
this
makes
sense
or
is
it
in
scope,
but
it's
one
thing
I
just
wanted
to
to
raise
like
do.
We
always
have
the
expectation
that
the
agent's
going
to
be
running
on
like
say
an
amd
64
linux
and
our
add-on
is
always
expected
to
be
for
that
single
platform.
A
Yeah
that
we
only
support
a
single
platform
right,
so
the
the
agent
reports
its
platform,
the
operating
system,
the
built
building,
it
is
appealed
for
to
the
server.
The
server
knows
right.
What
what
platform
this
particular
agent
comes
from
so,
and
so
so
there
there's
two
two
possibilities
here:
one
because
the
server
knows
where
the
agent
runs.
A
It
sends
the
particular
set
of
add-ons,
or
this
particular
set
of
packages
to
that
to
that
agent,
the
suitable
ones,
the
ones
that
are
for
that
platform,
or
it
sends
a
package
which
contains
all
of
the
supported
whatever.
Is
it
executables
right
for
all
platforms,
and
then
the
agent
unpacks
and
uses
the
one
that
it
needs
to
use?
A
I
I,
as
far
as
I
understand
that
shouldn't
be
a
problem,
should
still
be
possible
to
do
right
and
if
the
the
server
wants
to
pack
the
addons
in
a
way
that
are
suitable
just
for
the
agent,
this
particular
agent
again,
that
is
still
possible.
You
can
do
that
on
the
flight.
I,
like
the
agent
says
I
am
this
version
on
this
operating
system
and
the
server
just
bundles
everything
that
is
necessary
in
a
single
zip
file
and
and
says:
okay,
here's
just
download
that
right.
A
A
C
A
Okay,
yeah
so
yeah
anyway,
I
I
put
a
draft
pr
there,
which,
which
does
that
change
to
the
spec.
If
you
have
any
any
thoughts,
please
comment
on
that.
I
guess
one
question
was
whether
okay,
if
it's
a
single
file,
do
you
still
need
the
name
of
the
file
or
it
doesn't
really
matter,
because
the
add-on
for
the
package
already
has
a
name
whether
you
use
the
file
name
for
if
it's
a
single
file,
not
clear
to
me,
maybe
it's
unnecessary.
C
Yeah
we
does,
it
make
sense
to
download
and
fetch
multiple
versions
of
a
particular
file.
So
if,
if
agent
has
been
running
for
some
time,
unpacks
it
for
particular
say
if
it
is
an
archive
or
that
file
has
a
sha
it
unpacks,
it
uses
a
file
name
combined
with
the
shaw.
A
At
the
same
time
on
the
agent
like,
you
could
probably
have
different
versions
for
different
agents-
that's
probably
a
possibility,
but
that
just
means
that
the
server
needs
to
make
that
decision
which
one
it
pushes
to
the
particular
agent
on
the
individual
agent.
I
don't
see
what
the
good
use
cases
for
having
one
add-on
with
the
same
name,
but
different
different
versions
of
that
present
simultaneously
on
the
agent's
side.
What
would
be
the
use
case?
I
don't
know.
B
Okay,
so
what
about
that
use
case
when
there
is
like
new
added
version
and
okay,
the
agent
downloads
it
and
then
tries
to
use
it
instead
of
the
old
version,
and
it
fails
so
then
it
can
do
back
off
to
the
old
version.
Okay,.
A
Correct,
that's,
that's!
I
guess
that's
expected
that
it
can
happen
and
should
be
done
that
way
right.
If
the
agent
needs
to
be
careful
with
anything
that
receives
from
the
server
and
tries
to
apply
it
can
be
configuration
as
well,
you
may
receive
a
configuration
which
you
can't
apply.
It
fails
right,
so
the
the
the
I
guess
good
way
to
handle
this
is
you
keep
the
old,
whatever
entity
you're
trying
to
modify
the
config
or
the
add-on
try
to
apply
the
new
one
one.
A
If
it
fails,
you
revert
to
the
previous
last
known,
good
one
right
so
same
for
the
add-ons.
I
think
right
you
try
to
apply
a
new
one.
Doesn't
work
go
back
to
the
previous
one
report,
the
error
we
have
that
reporting
in
the
protocol.
Yeah
again,
I
don't
think
you
want
to
keep
the
old
one
around
if,
if
the
new
one
is
good,
what
do
you?
What
do
you
do
with
that?
One
yeah.
C
So
there's
a
use
case.
This
is
more
specific
to
our
experience
in
our
agent
around
like
service
checks,
where
invocations
of
a
add-on
had
different
arguments
for
a
different
version
like
one
flag
existed
for
here
and
one
play
was
there,
so
we
had
jobs
running
that
actually
needed
both
versions
of
the
same
add-on
effectively
because
they
were
either
using
an
old
option
or
configuration
or
listener,
and
the
new
one.
That's
all
so
like
something
that
ran
within
the
agent
would
be
able
to
reference
a
particular
version
of
an
add-on.
C
So
you
had
you
know
kind
of
change
management
built
in,
but
I
don't.
I
don't
really
know
if
that
I
think
chemic's
use
case
in
terms
of
rollback
or
fall
back
makes
more
sense
within
the
scope
of
open
telemetry
agent.
C
One
with
the
same
different
versions,
yeah
versions,
yeah
yeah,
the
problem
that
we
still
have
with
with
our
implementation
of
assets
and
our
effective
use
of
add-ons-
is
that
we
don't
have
garbage
collection.
So,
if
you're
revving
your
versions
of
your
add-ons
rapidly,
we
actually
don't
collect
them.
That
has
to
be.
H
A
C
G
A
What's
the
right
answer
to
this,
maybe
let's
keep
this
open
yeah
well,
but
that's
that's
for
the
versions
that
coexistence
of
different
versions
right
that
still
doesn't,
I
guess,
prevent
going
to
a
single
file
right.
That's
right!
That's
still
fine
yeah
and
having
multiple
files
doesn't
solve
that
particular
problem.
That's
a
that's
a
different
problem!
Correct!
Okay!
A
Do
you
want
to
maybe
submit
that
as
an
issue,
because
I
don't
think
we
have
that
anywhere?
It
doesn't.
A
B
Yeah
this
is
just
like
a
very
small
note.
There
was
a
like
a
very
small
discussion
on
slack
brought
by
jurassic
about
openconfig.net
project,
and
if
we
we've
been
looking
into
that,
then
maybe
it
would
make
sense
to
consider
reusing
it
for
the
purpose
of
remote
admin,
agent
management
or
maybe
it's
too
late
and
the
ship
has
sailed.
Or
maybe
there
are
some
other
initiatives,
I'm
not
sure
myself.
I
was
looking
at
this
project
briefly.
B
I
think
it's
mostly
around
network
management
like
in
general,
which
does
not
include
agent
management,
but
I'm
not
sure
if
that's
that
that
I
could
fit,
but
I
thought
that
maybe
it's
worth
bringing
to
the
wider
audience
if
you
have
missed
that,
because
I
think
it's
an
interesting
idea
just
to
see
if,
if
this
is
something
we
should
consider-
or
maybe
it's
it's
too
late,.
A
A
If
somebody
has,
the
time
wants
to
go
and
have
a
look
at
that,
because
I
also
couldn't
because
some
of
the
documents
that
they
are
linking
to
are
are
not
found
for
all
fours,
so
it
kind
of
was
a
bit
painful
to
try
to
understand
what
it
is,
but
I
mean
we're
still
probably
open
to
reconsidering
things.
If
somebody
wants
to
have
a
look
at
that
has
the
time
I
think
yeah,
it's
doable.
B
B
It's
like
a
way
to
express,
let's
say,
model
of
the
configuration
which
then
later
can
be
stored
in
as
xml,
but
I
was
not
spending
that
much
time
on
that
either.
A
Yeah,
but
maybe
that
maybe
that
the
portions
of
this
are
interesting
for
us,
maybe
the
way
that
we
describe
the
agent
configuration
or
something
like
that
right
that
something
that
doesn't
exist
today
in
open,
maybe
maybe
that's
what
we
can
reuse
now.
It
doesn't
probably
mean
that
we
replaced
everything
by
that,
but
maybe
there
are
good
ideas
here
that
we
can
use.
So
that's
also
a
possibility.
B
A
Yeah
also
the
I
guess
the
general
impression
from
the
project
was
not
that
it
has
a
lot
of
traction,
but
maybe
I'm
maybe
I'm
wrong.
I
I
just
look
at
the
github
like
how
much
activity
is
happening
there.
It
was
not
that
definitely
like.
There
was
something
going
on
there,
but
compared
to
open
telemetry,
at
least
like,
like
the
level
of
activity,
was
much
lower.
Maybe
that's
why
maybe
they
are
they
are
complete?
Maybe
they
are
dumb.
That's
why
I
don't
know.
A
A
C
I
guess
just
a
question
on
the
op-amp
spec
28
for
recommendations
for
keeping
connections
alive.
I
mean
you
know
we're
we're
looking
at
thousands
of
agents
being
connected
to
a
single
platformer
or
back-end.
C
And
I'd
like
to
understand
what
you
know,
what
our
interest
in
in
keeping
those
connections
in
a
sense
of
aliveness
consistent
across
them
all
yeah,
obviously
just
having
all
those
connections
open,
is
more
costly
than
you
know,
periodic
interaction.
So
I'm
I'd
love
to
hear
what
everyone's
kind
of
feelings
are
around.
This
particular
point.
A
C
So
while
we
wait
for
peter
to
sort
out
his
his
audio
issues,
I
I
did
have
just
a
few
thoughts
on
this.
I
definitely
like
the
idea
of
having
persistent
connections
mainly
websockets.
C
It's
worked
for
us
in
terms
of
you
know:
traversing
complex
network
topologies
from
the
agent
to
the
back
end,
keeping
them
open
and
then,
for
you
know,
presenting
a
very
simple,
live
liveliness
indicator
or
heartbeat,
and
I
actually
like
the
idea
of
just
including
the
protocol
or
using
like
a
very
simple
status
report
even
over
using
the
websocket
ping
pong,
because
we
could
just
leverage
that,
for
like
a
agent
health
check,
anyways.
C
The
one
issue
that
I
do
have
with
with
that
is
just
in
the
event
of
large
network
partitions
or
outages
having
thousands
of
agents
all
hammering
back
for
tls
upgrades
and
the
persistent
connections
can
be
costly,
but
then,
once
that
cost
is
paid,
maintaining
them
is
fairly
inexpensive.
But
if
we're
looking
at
tens
of
thousands
of
agents
being
connected
to
a
platform,
that's
still
a
particular
workload
that
needs
to
be
scaled
yeah.
So
I.
A
Guess
in
case
of
network
partitions,
you
shouldn't
be
reconnecting
them
all.
At
the
same
time
right
there
should
be
a
back
off
some
sort
of
exponential
backup
with
g3.
I
think
the
protocol
touches
that
a
bit,
maybe
more
clarification
on
that.
I
did
run
some
experiments
actually
with
and
without
tls
with
fearless,
it's
obviously
a
lot
more
expensive
without
tls.
I
think
I
I
got
about.
A
Let
me
see
I
have
some
notes
there,
no
tls,
okay,
so
I
went
as
as
high
as
about.
A
Okay,
I'll,
maybe
I'll
post-
that
next
time,
when
I
find
my
notes,
I
don't
remember
the
exact
numbers.
But
anyway
I
went
to
hundreds
of
thousands
agents
and
I
was
able
to
manage
the
like,
maintain
the
connections
without
any
problems
and
once
established
and
you're
right
establishing
was
the
most
expensive
part
of
it
once
established.
A
Even
if
you
wanted
to
do
like
status
reporting
unnecessarily
once
every
two
minutes,
it
was
like
low
percentage,
single
digit
percentages
of
cpu
usage
on
on
the
server
like
establishing
was
the
costly
part,
but
once
you
are
established,
it's
fairly
like
easy
to
handle
the
load
yeah
we
even
on
a
single
server,
with
hundreds,
thousands
of
connected
agents
like
sending
status
reports
every
two
minutes.
It
was
like
five,
ten
percent
of
of
a
single
single
core,
so
wasn't
costly.
It
was.
A
Memory
was
a
bit
more
important
part,
and
but
that
highly
depends
on
your
implementation.
I
had
like
a
simple
one,
based
on
course,
websockets,
which
are
not,
which
are
not
known
for
for
low
memory
usage,
so.
C
And
I
guess
my
own
thoughts,
I'm
conflating
just
straight
websock
connections
with
tls
upgrades
with
the
the
reality
that
we've
embedded
like
key
value
store.
So
when
there's
an
up
spike
in
in
cpu
usage
for
just
the
tls
upgrades,
we're
stealing
cpu
time
from
other
aspects
of
our
back
end
in
terms
of
sensu
and
that's
really
where
the
scaling
factor
is
limited.
It's
not
actually
around
the
transport
itself,
but
the
side
effects
of
of
those
upgraded
connections
taking
off
interacting
with
other
parts
of
the
system.
Yeah.
In
addition
to
the
spike
of
cpu.
C
That
just
has
a
a
very
strong
effect.
A
The
connection
connection
persistency
doesn't
affect
that
right,
even
if
without
persistent
connections,
if
you
had
some
sort
of
network
partitioning
and
the
agents
are
coming
up
and
want
to
make
a
request,
even
if
it's
let's
say
simple
http
request,
then
you
have
to
somehow
handle
that
right.
You
have
to
pay
the
cost
of
establishing
the
tls
connection.
Anyway,
you
have
that
the
downside
is
actually
you,
you
pay
that
cost
and
you
lose
it
because
you
throw
away
the
connection
right
and
that's
the
costly
part.
So.
H
Okay,
wow,
okay,
so
I
I
think
I
agree
with
everything
that
was
said
in
the
meantime,
I
was
just
trying
to
to
say
that,
yes,
it's
a
it's
an
issue
and
the
issue
is
only
on
the
server
side
right.
So
if
it
has
just
is
to
having
resources
into
having
to
open
connections,
it
should
close.
The
connections
and
the
agent
should
just
fall
back
to
re-establishing
the
connections
as
required
based
on
a
certain
timeout,
and
that
would
of
course,
involve
additional
cost,
but
it
will
be
manageable.
A
C
Sorry,
I
should
actually
go
back
to
the
the
spec
a
few
times,
I'm
just
kind
of
digging
up
to
your
your
issues
in
in
this
project
and
bringing
up
the
ones
that
kind
of
tickle
my
fancy
right
now,
but
I'll
I'll
go
back
to
the
spec
and
and
come
more
prepare
next
time
with
more
specific
questions.
C
J
One
question
digren:
I
saw
there
were
several
issues
created
for
the
op-amp
server,
based
on
the
priorities
that
you,
which
you
had
posted.
Do
we
have
an
open
ticket
for
the
supervisor?
Implementation
like
the
poc
in
the
ghost
pack.
A
I
think
we
do
give
me
a
second.
Let
me
check,
I
don't
remember
in
the
go
repository
we
have.
J
Yeah,
I'm
wondering
whether
that
has
been
kind
of
sorted
out
like
someone
working
on
it.
Any
any
thoughts
on
that.
A
J
J
A
The
document
that
I
posted
last
time
on
the
supervisor-
it
was
just
sort
of
some
sort
of
introductory
right
like
like
how
do
we
want
to
do
a
supervisor
and
tries
to
raise
some
questions?
If
we
do?
How
do
we
do
that?
But
it
definitely
needs
answers
and
I
think
probably
it
should
go
together
with
actual
prototyping
of
the
supervisor,
because
some
of
these
questions
are
probably
they
require
actual
implementations
to
be
answered.
It's
probably
going
to
be
difficult
to
answer
them
without
actually
going
through
the
process
of
implementing
it,
regardless.
A
Yeah,
let's
yeah,
let's
open
an
issue
there
saying
that
we
we
do
want
to
do
the
prototype
of
a
supervisor
as
well.
It's
then
probably
we
need
to
break
it
down
into
smaller
ones.
It's
going
to
be
a
big
one.
A
J
A
kind
of
related
question
on
that
you
know
like
we
have
before
we
talked
about
supervisor.
We
also
entertained
the
idea
of
doing
everything
in
the
within
the
ot
agent
right.
Should
those
two
pocs
kind
of
go
hand
in
hand
and
see
which
one
which
one
offers
more
benefits,
or
should
we
go
with
the
poc
for
the
the
supervisor
first
and
then
see
how
that
plays
out
any
thoughts
on
that.
A
It
depends
on
how
much
resources
we
have
right.
Do
we
have
enough
people
to
do
this
to
plc's
at
the
same
time,
and
also
doing
the
poc
without
the
supervisor
when
everything
is
in
the
agent
is
going
to
be
more
difficult,
more
costly,
more
time
consuming,
because
the
collector
making
changes
to
the
collector
is
going
to
be
slower,
definitely
than
just
doing
the
quick
prototyping.
We
can
do
here
in
our
separate
repository.