© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
2eb648a
demo site
(Get the code!)
Hi folks,
I am trying to reproduce the issue and I am in same stage as andrebeltrami. I could not reproduce the issue. I tried some sleeps on the update_access with several create, delete and add/remove access to the share. I has not gotten the bug.
Reading the code, it seems that the reported issue happens when the policy of a share for some reason is created and not assigned to it. Or even it is assigned, but in a moment, it is lost. It keeps on the storage, but not assigned to the share. So, when a update_access runs, it checks that the share does not have the expected policy name and try to rename it, which breaks since there is a policy with that name on the storage.
To reach this scenario is not easy, so I would request to you a better log. Please, could you turn the debug mode on ?
To get the debug mode:
- add to the default manila.conf: debug=True
- add to the backend stanza: trace = True and netapp_trace_flags = method,api
You can send only the log since the share is created until the bug is hit with this share.
With this log trace we can understand how the policy is getting lost.
Thank you all.