Do you mean enabling the RCPD HTTP API on ubus to fetch the data from it? In this case, the management VPN would become a requirement unless the devices are on the same L2 network, because OpenWISP would not be able to reach the HTTP API otherwise.
It's good that you're working with openwisp-config so your understanding of OpenWISP will increase.
In the initial phase I suggest you to focus on making sure sending the config to OpenWISP works well, because the following steps will be hard.
For example, these for me are still open questions:
- we're not going to send the full config to OpenWISP periodically are we? That would generate a lot of traffic. Maybe we can send the checksum like we do for the download config
- is there a way to find out if the config on the device has been changed by the user and send an update to the controller straight away?
if there is, maybe we can then check if we need to re-upload the full config less often;
if there isn't, we may implement a trick
- what happens if a user edits the config on the device while at the same time another user modifies a template? This will have to be handled well
- what happens if a user edits the config on the device while at the same time another user modifies the same config in the device config of openwisp? This will have to be handled well, an one of the two sides will win, probably the one that comes afterwards
These are just the ones that come from the top of my head. There are more.
What you're working on is the first phase. The second phase will need additional thought.
The best thing in these cases is to sit down, draw, sketch. Create issues. Discuss a bit more.
If we jump to coding straightaway we risk to create a messy solution, which is still good to learn, but with some more careful design we will be able to do a lot better.
Federico