NetApp driver leaks ipspaces on vserver creation failure
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Shared File Systems Service (Manila) |
Triaged
|
Low
|
Carlos Eduardo | ||
Bug Description
Description
===========
The NetApp ONTAP DHSS=True driver creates ipspaces on the fly and tags them with the neutron network subnet ID when Neutron network plugin is used [1]. It does a good job on reusing ipspaces associated with the same VLAN as the share network being used if one is present. However, it's possible that there are orphaned ipspaces that match the same name as the neutron subnet ID, but aren't associated with any VLANs yet. One possibility where this may occur is if the ONTAP Vserver creation or Vserver network setup fails before a VLAN association is made [2]. The failure is bubbled up, but the ipspace remains on the backend.
Users could end up in a bad place if they retry their share creation request since the driver sees this orphaned resource and fails on name conflict: http://
[1] https:/
[2] https:/
Steps to reproduce
==================
A chronological list of steps which will help reproduce the issue you hit:
* Follow steps to reproduce https:/
* Fix your issue there and retry creating a share with the same share network
Expected result
===============
I expect ONTAP to reuse the unused IPSpace (or have it cleaned up during the prior failure) so that ipspace conflicts don't occur when re-attempting share creation
Actual result
=============
Share is set to "error", because share server creation failed in the backend
Environment
===========
1. OpenStack Manila Train
2. NetApp ONTAP 9.x
| tags: | added: netapp |
| tags: | added: low-hanging-fruit |
| Changed in manila: | |
| importance: | Undecided → Low |
| Changed in manila: | |
| assignee: | nobody → Carlos Eduardo (silvacarlose) |
| Vida Haririan (vhariria) wrote | #1 |
| Changed in manila: | |
| status: | New → Triaged |
This is a fallout from https:/
Additional comments http://