Thanks for the response, Federico. I have replied to most of the points you 
had pointed out to and also hope to send a draft proposal explaining them 
in much more details soon!

- we need to implement the current features and make them both work for 
> Prometheus and Influxdb


I have read it the documentation of *Prometheus* in more detail, it says 
that most of the data compression algorithms, query parameters and 
structure of the *Prometheus* is similar to *InfluxDB *which makes it easy 
for migration. Also, Prometheus suppoerts many *InfluxData APIs*(company 
behind InfluxDB) to make it easily integrable with other features that 
*InfluxDB* supports such as *Grafana*(currently these modules are not being 
used in the project but in future if they are included then too it would 
not cause any difficulty). So, it seems that our features would be 
compatible with *Prometheus* too.

- the new timeseries DB that we will support needs to provide an open 
> source solution for horizontal scaling, because influxdb does not provide 
> it (has a paid cloud service instead, which is not a viable option for many 
> openwisp users)
>

I looked into this though *Prometheus* originally doesn't support 
horizontal scaling, there are many good tools available(open-source) which 
many organizations use to achieve this. Namely, Cortex 
<https://github.com/cortexproject/cortex>, Thanos 
<https://github.com/thanos-io/thanos>, Victoria-Metrics(I just found out it 
is also built on top of Prometheus!), etc. Among these *Thanos*(completely 
open-source) is quite popular and *Victoria-metrics* docs were not clear 
whether it is available free or on Paid version. So, I think that this can 
be discussed later on too as to what would be best to be used on top of 
Prometheus to enable Horizontal-scaling (as there are many options 
available).

Django settings can be manipulated only by system administrators, who are 
> IT people and should know what they're doing.
> We will only need to provide some basic documentation giving an example of 
> how to write an additional chart query and add it to the settings, showing 
> the resulting chart.
>
> The rest of the users using the system (think about organizations that 
> operate the network and use OpenWISP to perform basic management operations 
> like updating the configuration on monitoring the statistics) will only be 
> able to select from the predefined set of chart queries available.
>
> In most cases, non technical users won't have access to this part of the 
> system, they'll only see the charts.
>

I have prepared a workaround which seemed to me a bit better than having a 
big list to select from for the end-user. Since, it is a bit lengthy I have 
included it in my draft proposal which I will be sending very soon :)

Yes you can make improvement proposals as long as they're in scope with the 
> project and help to achieve the goal.
>

Great!! Just wanted to know, can we use FusionCharts in this module. 
Currently, many charts have to be created/exported and this will involve 
changing dependency from plotly (which is currently being used) to 
FusionCharts. Plotly is great and lightweight too but fusion charts allows 
to select from a wide variety of charts and also allows us to provide it 
data in JSON format. We can export data in PNG/Pdf/SVG,etc. formats with a 
preview.

There's a better way to do it on OpenWRT, try this:
>
 
>
ubus call system info
>
> I forgot to share some scripts I implemented to collect these metrics: 
> https://github.com/openwisp/lua-monitoring 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fopenwisp%2Flua-monitoring&sa=D&sntz=1&usg=AFQjCNH4uETlbznRIpnuCfjTUPPBhE9Qkg>
>

Thanks for sharing, this command is surely better. Also, now I won't have 
to write a script for converting received data into *NETJSON* standard 
format. As, the script provided took care of the same :)

LEDE was a fork of OpenWRT, it was then merged back into OpenWRT and the 
> project avoided to split.
>

Thanks for sharing!

Best Regards
Hardik Jain
:)

-- 
You received this message because you are subscribed to the Google Groups 
"OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/openwisp/9404d5f9-b9b1-4e8d-ba12-452558f95a0a%40googlegroups.com.

Reply via email to