[feature] Implemented device deactivation and reactivation #625

[pandafy]

Closes #625

Blockers

• [feature] Made admin/submit_line.html extendable openwisp-utils#370

TODOS

• we shall make all the field of a deactivated device readonly
• if the device has any related OpenVPN template with certificates, the certificates shall be flagged as revoked
• removes any config and template from the device, ensuring the revoked certificates do not get deleted (because we need those to be in the CRL)
• sets the config status to deactivating (this is a new status)
• once the config is applied by the agent (we must make sure it's deactivated) the config status should be set to "deactivated" instead of "modified"
• once the config is set to deactivated, the controller HTTP API should return 404 for these devices, so that the agent stops asking for the checksum
• I think we should hide the delete button of the admin and show "deactivate" instead, we could show the delete button only if the config status is "deactivated" or if the device does not have a config object
• we should add the deactivate admin list action, if we can add it before the delete action it's better
• the admin action which deactivates multiple items at once must deal with the case in which one or multiple devices are already deactivated in a graceful way, informing the user and without failing
• ensure we emit a signal when this happens, I believe a config status change is emitted but let's double check (so we can listen for this event in other modules)
• we will also need to update the API to prevent changing any details on the deactivated devices
• add an admin action which sets the config status to applied;
  • it must deal with the case in which one or multiple devices are already activated in graceful way, informing the user and without failing

[pandafy]

@nemesifier why do we need this? It is creating an issue for marking the device as deactivated. Instead of changing the status from deactivating to deactivated, this code is changing the status to applied. Can we rely on the report status request from the agent for this?

[nemesifier]

Agreed, proceed, there may be some test to change because of this removal.

[nemesifier]

#853

[nemesifier]

Looking good!

I did a quick code review, find my comments below.

Please let's take advantage to introduce the improvement discussed yesterday:

diff --git a/openwisp_controller/config/admin.py b/openwisp_controller/config/admin.py
index 764ae7f..cd573fb 100644
--- a/openwisp_controller/config/admin.py
+++ b/openwisp_controller/config/admin.py
@@ -641,6 +641,10 @@ class DeviceAdmin(MultitenantAdminMixin, BaseConfigAdmin, UUIDAdmin):
     ip.short_description = _('IP address')
 
     def config_status(self, obj):
+        if obj.is_deactivated:
+            return _('deactivated')
+        if not obj.config:
+            return _('unknown')
         return obj.config.status
 
     config_status.short_description = _('config status')

Another note:

Can we hide the save and save continue button on deactivated devices?

What else is missing?

• Do not allow to delete devices which are not deactivated first via admin action
• Admin inlines
• It would be great to show the readonly config value as indented JSON (now it shows OrderedDict(...)).

API changes:

• Disable API endpoints to make changes to deactivated devices
• I think we need to allow to enable and disable a device via API too, right?
  We could split the API changes in a separate issue but we need to discuss this first

Anything else?

[nemesifier]

Please update the checklist in this PR.

I see the following item: "add an admin action which sets the config status to applied;" did we discuss adding such an action? To flag the config as applied? Or what did we mean here?

Please also rebase on the latest master, updating docs and code formatting.

Can you please also double check if there's any other documentation section we need to add or if it's worth mentioning this in some other page?

[pandafy]

I see the following item: "add an admin action which sets the config status to applied;" did we discuss adding such an action? To flag the config as applied? Or what did we mean here?

I believe there's a typo in the point. Instead of "setting config status to applied", the admin action should be to activate the device. And this has been already implemented.

[nemesifier]

Is this emitted right when the device is flagged for deactivation or when the deactivation is complete?

[pandafy]

It is sent when the device is flagged for deactivation.

[nemesifier]

Ok, please clarify this in the text when you can.

[nemesifier]

After merging with the latest master and removing the reference to the openwisp-utils branch which was already merged, the feature is not working as expected anymore :(

[nemesifier]

I have a few questions below.

[nemesifier]

Suggested change

	# If the config is being deactivating or deactivated, then
	# If the device is deactivated or in the process of deactivatiing, then

[nemesifier]

Suggested change

	raise PermissionDenied('The device should be deactivated before deleting')
	raise PermissionDenied('The device must be deactivated prior to deletion')

[nemesifier]

Let's clear the management IP only once the deactivation is completed. This way we can speed up the deactivation because if the management IP is set, openwisp may be able to SSH into the device and remove the configuration faster.

[nemesifier]

Let's reapply all default templates when a device is activated again: shared default and required templates, org default and required templates, group templates if the device has any group, also tagged.

I think the best solution would be to basically register it again, without triggering the notification and register signal.

[nemesifier]

I think we should take advantage of this chance and add a docs page similar to what we have in the monitoring module: https://openwisp.io/docs/dev/monitoring/user/device-health-status.html, which lists the possible config status options and explains them briefly.

[nemesifier]

Update the rest-api.rst docs file:

• Add new endpoints
• Update delete device endpoint to mention the device needs to be deactivated first or it will return 403