[2.5.2][proposed] skip_storage and skip_networking used during commissioning affect restore-storage-configuration and restore-networking-configuration

[Dmitrii Shcherbakov]

It looks like skip_storage property applied to nodes during recommissioning affects `maas restore-storage-configuration`. The node storage configuration is not cleared but MAAS returns 200.

https://bugs.launchpad.net/maas/+bug/1815091/comments/10

https://bugs.launchpad.net/maas/+bug/1815091/comments/11

Code path:

https://paste.ubuntu.com/p/xHpvdvRXGP/

So MAAS clears the storage by applying a default storage layout.

Tracing shows that self.skip_storage is set to True (I used that option during re-commissioning once or twice but it should not affect this operation):

https://paste.ubuntu.com/p/sDS2xjcn3k/

3214 -> if self.skip_storage:
3215 return
3216 storage_layout = Config.objects.get_config("default_storage_layout")

(Pdb) n
> /usr/lib/python3/dist-packages/maasserver/models/node.py(3215)set_default_storage_layout()
-> return

[Dmitrii Shcherbakov (dmitriis)]

Subscribed ~field-critical. We rely on restore-storage-configuration for subsequent reruns of FCE during deployments and not being able to clear-and-reapply storage config breaks our workflow.

[Dmitrii Shcherbakov (dmitriis)]

From what I see, skip_storage is a column in the DB:

maasdb=# select * from maasserver_node;

 id | skip_storage
-----+--------------
 197 | t
 169 | t
  13 | f
  22 | f
  21 | f
   6 | f
   2 | f
 166 | t
 167 | t
 171 | t
  11 | f
 174 | t
   1 | f
   7 | f
 178 | t
 170 | t
 161 | t
 183 | t
 128 | f
   8 | f
   9 | f
  19 | f
 181 | t
 180 | t
 185 | t
 172 | t
 173 | t
 127 | f

[Dmitrii Shcherbakov (dmitriis)]

I did this

maasdb=# update maasserver_node SET skip_storage=false;

 and tried the restore storage operation - it worked just fine.

[Dmitrii Shcherbakov (dmitriis)]

The same behavior is present for networking config.