081fc4860b
When attempting to allow_access on a managed share, it fails because the proper share ID is not retrieved from private storage prior to attempting to validate that the share exists in the backend. The same happens when trying to create a share from a snapshot created from a managed share, the proper share ID is not retrieved from private storage. While we are dealing with two possible different IDs it is important to properly display the API share ID in log messages so it can be matched to the share instances ID, and not all log messages are accurately doing so. This change addresses this by retrieving the ID from private storage first for update_access and create_share_from_snapshot operations. The proper unit test changes included in this patch required a refactor of several IDs to ensure this problem is addressed in unit tests, thus it made sense to address several bugs caused by the same problem, having the same fix and requiring modifications to the same lines of code. Closes-bug: #1581541 Closes-bug: #1584179 Closes-bug: #1583785 Change-Id: I8cdb1a8a72a4ac7e710f57e3c288d48cd2adf0dd
10 lines
305 B
YAML
10 lines
305 B
YAML
---
|
|
fixes:
|
|
- Fixed error when allowing access to a managed share in
|
|
HDS HNAS driver.
|
|
- Fixed error when attempting to create a new share from
|
|
a snapshot taken from a managed share in HDS HNAS
|
|
driver.
|
|
- Fixed ID inconsistencies in log when handling managed
|
|
shares in HDS HNAS driver.
|