IMHO, renaming a backend resource is a breaking operation for the reasons you mentioned - i.e., the pool info is stored on manila and used by the driver to locate resources. One way the driver can support this in an automated manned is through ensure_shares - and that currently is kicked off only with bouncing the manila-share service. A challenge here though is something needs to tell the driver that the pool names have changed from underneath it - the driver has so far been stateless in this regard.
I think the decent solution for folks that may attempt renaming NetApp storage aggregates is by documenting this procedure:
1) Rename aggregate
2) Use manila-manage to update share hosts (``manila-manage share update_host [-h] --currenthost CURRENTHOST --newhost NEWHOST [--force FORCE]``)
3) Restart the manila-share service
IMHO, renaming a backend resource is a breaking operation for the reasons you mentioned - i.e., the pool info is stored on manila and used by the driver to locate resources. One way the driver can support this in an automated manned is through ensure_shares - and that currently is kicked off only with bouncing the manila-share service. A challenge here though is something needs to tell the driver that the pool names have changed from underneath it - the driver has so far been stateless in this regard.
I think the decent solution for folks that may attempt renaming NetApp storage aggregates is by documenting this procedure:
1) Rename aggregate
2) Use manila-manage to update share hosts (``manila-manage share update_host [-h] --currenthost CURRENTHOST --newhost NEWHOST [--force FORCE]``)
3) Restart the manila-share service