| 2024-05-06 09:40:06 |
Sylvan Le Deunff |
bug |
|
|
added bug |
| 2024-05-06 09:46:47 |
Sylvan Le Deunff |
description |
**When performing a share server migration, if no new network is specified same allocations should be reused on destination share server.**
But the code responsible to update existing allocations with new share_server_id seems to be missing here:
https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/manager.py#L6099
Trying this, we found out another issue:
**The way share server name is retrieved in NetApp driver prevents doing another migration after the first one.**
* NetApp driver determines the name of the source share server for a migration using templating (something like "os_{server_id}" by default).
* Migration of NetApp vserver with manila creates a new share_server entry in manila DB with a different server_id, but vserver still has the same name on NetApp cluster.
* Now the name "os_{server_id}" does not match "vserver_name" anymore.
* This breaks ability to migrate vserver a second time.
The problem occurs in those functions related to migration:
* [_check_for_migration_support](https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1286)
* [_migration_start_using_svm_migrate](https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1525)
And can be fixed by replacing templating by using backend_details stored in manila
```python
source_share_server["backend_details"]["vserver_name"]
``` |
ISSUE 1
=======
When performing a share server migration, if no new network is specified same allocations should be reused on destination share server.**
But the code responsible to update existing allocations with new share_server_id seems to be missing here:
https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/manager.py#L6099
ISSUE 2
=======
The way share server name is retrieved in NetApp driver prevents doing another migration after the first one.
- NetApp driver determines the name of the source share server for a migration using templating (something like "os_{server_id}" by default).
- Migration of NetApp vserver with manila creates a new share_server entry in manila DB with a different server_id, but vserver still has the same name on NetApp cluster.
- Now the name "os_{server_id}" does not match "vserver_name" anymore.
- This breaks ability to migrate vserver a second time.
The problem occurs in those functions related to migration:
- _check_for_migration_support: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1286
* _migration_start_using_svm_migrate: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1525
And can be fixed by replacing templating by using backend_details stored in manila
- source_share_server["backend_details"]["vserver_name"] |
|
| 2024-05-06 09:46:57 |
Sylvan Le Deunff |
description |
ISSUE 1
=======
When performing a share server migration, if no new network is specified same allocations should be reused on destination share server.**
But the code responsible to update existing allocations with new share_server_id seems to be missing here:
https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/manager.py#L6099
ISSUE 2
=======
The way share server name is retrieved in NetApp driver prevents doing another migration after the first one.
- NetApp driver determines the name of the source share server for a migration using templating (something like "os_{server_id}" by default).
- Migration of NetApp vserver with manila creates a new share_server entry in manila DB with a different server_id, but vserver still has the same name on NetApp cluster.
- Now the name "os_{server_id}" does not match "vserver_name" anymore.
- This breaks ability to migrate vserver a second time.
The problem occurs in those functions related to migration:
- _check_for_migration_support: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1286
* _migration_start_using_svm_migrate: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1525
And can be fixed by replacing templating by using backend_details stored in manila
- source_share_server["backend_details"]["vserver_name"] |
ISSUE 1
=======
When performing a share server migration, if no new network is specified same allocations should be reused on destination share server.
But the code responsible to update existing allocations with new share_server_id seems to be missing here:
https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/manager.py#L6099
ISSUE 2
=======
The way share server name is retrieved in NetApp driver prevents doing another migration after the first one.
- NetApp driver determines the name of the source share server for a migration using templating (something like "os_{server_id}" by default).
- Migration of NetApp vserver with manila creates a new share_server entry in manila DB with a different server_id, but vserver still has the same name on NetApp cluster.
- Now the name "os_{server_id}" does not match "vserver_name" anymore.
- This breaks ability to migrate vserver a second time.
The problem occurs in those functions related to migration:
- _check_for_migration_support: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1286
* _migration_start_using_svm_migrate: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1525
And can be fixed by replacing templating by using backend_details stored in manila
- source_share_server["backend_details"]["vserver_name"] |
|
| 2024-05-06 09:47:32 |
Sylvan Le Deunff |
description |
ISSUE 1
=======
When performing a share server migration, if no new network is specified same allocations should be reused on destination share server.
But the code responsible to update existing allocations with new share_server_id seems to be missing here:
https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/manager.py#L6099
ISSUE 2
=======
The way share server name is retrieved in NetApp driver prevents doing another migration after the first one.
- NetApp driver determines the name of the source share server for a migration using templating (something like "os_{server_id}" by default).
- Migration of NetApp vserver with manila creates a new share_server entry in manila DB with a different server_id, but vserver still has the same name on NetApp cluster.
- Now the name "os_{server_id}" does not match "vserver_name" anymore.
- This breaks ability to migrate vserver a second time.
The problem occurs in those functions related to migration:
- _check_for_migration_support: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1286
* _migration_start_using_svm_migrate: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1525
And can be fixed by replacing templating by using backend_details stored in manila
- source_share_server["backend_details"]["vserver_name"] |
ISSUE 1
=======
When performing a share server migration, if no new network is specified same allocations should be reused on destination share server.
But the code responsible to update existing allocations with new share_server_id seems to be missing here:
https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/manager.py#L6099
ISSUE 2
=======
The way share server name is retrieved in NetApp driver prevents doing another migration after the first one.
- NetApp driver determines the name of the source share server for a migration using templating (something like "os_{server_id}" by default).
- Migration of NetApp vserver with manila creates a new share_server entry in manila DB with a different server_id, but vserver still has the same name on NetApp cluster.
- Now the name "os_{server_id}" does not match "vserver_name" anymore.
- This breaks ability to migrate vserver a second time.
The problem occurs in those functions related to migration:
- _check_for_migration_support: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1286
- _migration_start_using_svm_migrate: https://opendev.org/openstack/manila/src/tag/18.1.0/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L1525
And can be fixed by replacing templating by using backend_details stored in manila
- source_share_server["backend_details"]["vserver_name"] |
|
| 2024-05-06 09:50:02 |
Sylvan Le Deunff |
manila: assignee |
|
Sylvan Le Deunff (sylvanld) |
|
| 2024-05-06 10:33:03 |
OpenStack Infra |
manila: status |
New |
In Progress |
|
| 2024-05-08 19:19:19 |
Vida Haririan |
tags |
|
migration share-migration |
|
| 2024-06-04 13:24:45 |
Sylvan Le Deunff |
manila: status |
In Progress |
Fix Committed |
|
