Howto delete existing interfaces

[qooqler]

when I add an interface to a device and save it. It will be created on the openwrt node (eventually). BUT when I delete the same interface in openwisp2 and save the configuration the interface remains on the node (i.e. it is never deleted)

Is this a limitation of openwisp or am I missing something?

Furthermore I had expected that when the device registers itself it's current configuration will be visible in openwisp2.

[Federico Capoano]

Hi,

On Wed, May 20, 2020 at 11:48 PM qooqler <qoo...@am-lindenbaum.de> wrote:

when I add an interface to a device and save it. It will be created on the openwrt node (eventually). BUT when I delete the same interface in openwisp2 and save the configuration the interface remains on the node (i.e. it is never deleted)

Is this a limitation of openwisp or am I missing something?

The standard behaviour should be that if an interface is added from openwisp, and an interface with the same logical name was not present before, when the interface is removed from openwisp it should be removed on the device too.

If the interface defined in openwisp was already present on the device (so it's being overwritten), the previous version will be restored.

 

Furthermore I had expected that when the device registers itself it's current configuration will be visible in openwisp2. 

Your expectation is totally legit.

There's a few technical challenges to resolve, but it's looking like we should be able to get this working in a few months:

- https://github.com/openwisp/netjsonconfig/issues/100

- https://github.com/openwisp/netjsonconfig/pull/152

- https://github.com/openwisp/openwisp-config/pull/107

It was a technical choice I did in the beginning to favour speed of development on other aspects of OpenWISP, but now it's becoming more pressing so we're working to achieve this by the next major release.

Compared to other controllers, OpenWISP has the concept of configuration templates, and also allows to edit any file on the filesystem, which makes this feature a bit more challenging to implement than other use cases in which the configurations that can be manipulated are well defined and the system does not have to deal with configuration templates, so that's why in the beginning it was left out.

Thanks for your feedback

Best regards

Federico