With 3PAR, share server(VFS) can have up to 4 IP addresses.
During bootup, driver queries 3PAR to get list of all IP addresses
and validates it against IP addresses provided in manila.conf. If
there is a mismatch, driver throws exception.
The bug was with 3PAR file client which always returns only one IP
address. To make driver backward compatible with 3PAR client,
mediator.py formats the value retured by client and passes it to
driver.py. This patch now correctly accepts all the IP addresses
as obtained from 3PAR and validates configured IPs against it.
Also removing unused function.
Updated and added new unit tests
Added release notes
Closes-Bug: #1621016
Change-Id: I1eeb18cc9905a71cd38c383bc0ab49e0a560ffc9
Previously only the DHSS=True mode was documented
in post install steps. The assumption that the generic driver
was being configured existed in other places as well.
* add DHSS=False documentation as necessary with the
LVM driver.
* correct assumptions in other places to clarify usage
of appropriate share driver modes.
Change-Id: Ic1356453e510e8f360269fb45a41379329ce68c2
Closes-Bug: #1616257
Adding a cleanup to method create_from_snapshot in case
of a failure.
Also, raising the correct exception on backend layer in
case of a failure when exporting shares.
Change-Id: I86d2c3c5ff5a790868f8362e065df1eb2be8a3ad
Closes-Bug: #1613721
For the moment, share migration works only when manila-share and
ZFS storage are located on the same host. So, fix it adding SSH
command to migration command.
Change-Id: I25f211de6a278c6f303ef3f33ff30f504146a0fa
Closes-Bug: #1623379
A share managed in HSP could have some access rules that
are not in Manila. Trying to add a rule that already exists
in backend results in an error. Also, rules in backend that
names are not "share_id + ip" can't be deleted.
Additionally, if this share has a rule only in backend and not in
Manila, trying to delete it would fail, because HSP doesn't allow
delete share when it still has rules.
Fix it by adding a check in update access when rules already
exist in backend. Check for access rule name in backend when
denying access. And cleaning all rules from backend before
deleting a share to ensure that it has no children in HSP.
Change-Id: I0c8ee5c47efe22f004692022dd952f301d669b06
Closes-Bug: #1620756
Improve coverage by adding tests that validate the share-type
change while also changing the driver mode.
Closes-bug: #1620800
Change-Id: I924c34aa69591754b437d75f43db91d77e73fb07
Share migration code [1] merged in newton intending to allow admins
to mount the share between phase1 and phase2, but API code for
allow_access and deny_access was set incorrectly, blocking it.
After discussing this feature's purpose further, we decided we do
not want this feature at this moment, so we are just fixing the
allow_access and deny_access error messages.
Also, addressed a small case of concurrency that was happening
once in a while in CI. Update_access was being invoked while
other rules were being applied, thus setting the access_rule_state
to "UPDATING_MULTIPLE", ignoring the migration access rule change
RPC request completely, failing migration. By refreshing the
model we are able to assign the proper access_rule_state at the
time the function is invoked, setting the access_rule_state
correctly.
[1] If4bfaf7e9d963b83c13a6fea241c2eda14f7f409
APIImpact
Closes-bug: #1623051
Closes-bug: #1623052
Change-Id: I76a7d8c3bdd597b951e700350f8f3f82bfb21e03
Docker containers were previously started with insufficient
privileges to successfully mount a LV created on host.
This change fixes this problem.
Closes-Bug: 1613675
Change-Id: I63f3480ace3be70100a245570d7f3579b333e972
A couple unit tests were attempting to test a wrapped method,
and the tests failed randomly. It is straightforward, and preferable,
to test the code with the decorator as it is called during normal
operation.
Change-Id: If0b92adcf974b4509424912f5fde1cf26ebfaf48
Closes-bug: #1622998
Big part of share migration feature in ZFSonLinux share driver
is not covered with unit tests. So add it.
Also, add reno releasenote saying that driver now supports share
migration.
Change-Id: I558d4c6a0802b6a0156416b3c9b481181a55298c
Closes-Bug: #1621068
The autosupport functionality of the NetApp cDOT driver is not working
with Python 2.7.12, the default in Xenial. Root cause is a deep copy
of the controller connection context, which includes some SSL context
stuff that doesn't play well with copy.deepcopy. So we can do a shallow
copy instead.
Change-Id: Ia2adc4ce27834e384e6d994fcb012ebf1d97c85c
Closes-Bug: #1621260
Currently, huawei driver will use the "AllocType" configuration
or default "thick" type to create share, if "thin-provisioning"
not specified in share_type, but scheduler default uses thin
type in this situation, so huawei driver isn't consistent with
scheduler.
This patch removes the "AllocType" configuration from huawei
driver configuration file and default use "thin" type if
"thin-provisioning" not given.
Depend on change I238a7962425ea35c356c5ed2e31b8f68462b3769.
DocImpact
Change-Id: I5b7128657e089113da44bc862e9c864de2ec59b2
Closes-Bug: #1609718
