Development: implement stuff only once

[Akira25]

Currently bbb-configs implements some things by itself, hence there are already solutions in the falter-packages repo. Examples for this are #32, #26 and #1.

All of these issues are solved in standard falter. In addition, we shouldn't maintain separate structures, like the maintainer-keys. In standard falter theres already a package for that.

To maintain interoperability between bbb-configs and standard falter, we should definitely focus more on the idea we had at the start of falter:

Everything is a package. Everything

So I would be clearly in favor of replacing parallel structures in bbb-configs with their falter-conterpart. Because that was the idea of why we write everthing as a package. :)

[spolack]

while i largely agree with you, #1 cannot be fixed, since some locations may require additional users to have access. Its not possible with the imagebuilder approach to append to a file.

Ref: https://github.com/Freifunk-Spalter/bbb-configs/blob/master/group_vars/location_k9/ssh-keys.yml https://github.com/Freifunk-Spalter/bbb-configs/blob/master/group_vars/location_kiehlufer/ssh-key.yml

[PolynomialDivision]

My understanding is that we want to stay as much as possible compatible with upstream OpenWrt. Generating configs to feed the upstream image builder is totally fine for me. However, all code that implements functionalities is not. I highly encourage all people to upstream applications to the appropriate OpenWrt repositories. More people will review and test our stuff, making everything better.

Adding the snmp script would mean that we need to write an appropriate wizard configuring the collectd-snmp plugin. That is an extension that should be added to this repository: https://github.com/openwrt/luci/tree/master/applications/luci-app-statistics Before this has really an impact we would need to find a solution, to automatically support the meshing via ubnt or mikrotik devices.

So I think it is always a struggle between user interaction/abstraction and time and effort we want to invest in it.

[PolynomialDivision]

I'm at some point there I would say that it is more easy to write a script that uses this ansible stuff in the background to generate a image automatically, that the users only needs to flash to its AP. we would not require any user interface or migrations scripts. Just some IPs, we woud be also able to fetch automatically, or making configurable via some site.

[PolynomialDivision]

That is also very interesting: https://github.com/aparcar/asu

[Akira25]

My understanding is that we want to stay as much as possible compatible with upstream OpenWrt. Generating configs to feed the upstream image builder is totally fine for me. However, all code that implements functionalities is not. I highly encourage all people to upstream applications to the appropriate OpenWrt repositories. More people will review and test our stuff, making everything better.

I understand your intention here, but must disagree. Most Freifunk-features won't bother OpenWrt. Our Freifunk-Map integration for example. Or the wizard. Or our VPN tunnel setup. and so on. Those feature are definitely freifunk only and probably won't make it ever to OpenWrt.

Adding the snmp script would mean that we need to write an appropriate wizard configuring the collectd-snmp plugin. That is an extension that should be added to this repository: https://github.com/openwrt/luci/tree/master/applications/luci-app-statistics

mmh. One could do that. But we could also assume a standard setup and ship the finished configuration with the image. I consider SNMP an advanced use case. The one that uses it, should be able to configure it by itself. In my opinion there is no urgend need for a wizard.

[Akira25]

I'm at some point there I would say that it is more easy to write a script that uses this ansible stuff in the background to generate a image automatically, that the users only needs to flash to its AP. we would not require any user interface or migrations scripts. Just some IPs, we woud be also able to fetch automatically, or making configurable via some site.

One point of Berlin firmware is its ability to add something fairly easy. It's shell, which is understood by many of our people. This doesn't account for ansible.

ansible is really cool stuff. But it's major drawback is, that only @spolack has the knowledge to adjust and modify it. That's okay for configuration management, but not for general development. We should lower the bars on getting involved into firmware development. I feel, that ansible wouldn't help us with that.

[FFHener]

As we are currently laying out the path to bring bbb-configs and Falter back together and the last discussion here is more than 2 years old i close this issue for now