This prevents a job reporting 'success' when the appropriate python
interpreter cannot be found, when actually it didn't run at all.
Also change the default envlist to use generic 'py3' instead of a
specific version which might not be present.
Jeremy Stanley has given a more thorough explanation of why this
is a good change:
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014810.html
Change-Id: I4be4c4167adf01b70980269b338fbb720c49aeab
This has been in place since Newton and was targeted for removal in
Rocky. That has long since passed but we can ease things by removing it
now.
Despite what change I7096463c5eba951dd6322ee6965435e877ca0371 said about
not removing this workaround from 'CryptsetupEncryptor', we do so anyway
since we're going to remove this encryptor shortly.
Change-Id: Id8d96c1eda2beab1aebd8ecc054d8511ccefca3e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-bug: #1633518
This patch fixes a problem where we don't return the right nqn value
when the /etc/nvme/hostnqn file doesn't exist.
Currently get_connector_properties returns a new nqn value every time it
gets called if the hostnqn file is not present in the system.
The reason for this is that we are calling "nvme gen-hostnqn" and piping
it to tee, but for some reason tee is failing to write the file, so on
each call we'll generate a new nqn.
Even if we were successfully creating the hostnqn file, that could
create problems if we have already attached some volumes, since those
would have used the existing nqn.
This patch replaces the series of command executions (mkdir, nvme,
chmod) with a privsep method that then leverages the equivalent python
methods when possible and also tries to use the show-hostnqn nvme
subcommand first to get the existing nqn before defaulting to generating
a new one with gen-hostnqn. This way we don't replace the current nqn
value that may be already being used by other nvme connections.
Subcommand show-hostnqn returns the host NQN configured for the system.
First looks for /etc/nvme/hostnqn, if it's not present (our case when we
call the new create_hostnqn method) tries to construct it from dmi
(/sys/firmware/dmi/entries) or from systemd's application-specific
machine IDs for the system [1].
It's important to differentiate between the ENOENT returned as OSError
and the same value returned by nvme [2] when show-hostnqn cannot return
anything.
[1]: ed9538622a/fabrics.c (L858-L875)
[2]: 5b8b065b1d/nvme.c (L5642-L5643)
Closes-Bug: #1928944
Change-Id: I252dd958767dcdd4f9a2767b362aaf675edb79c4
When nvme is not configured, the connector still logs error
traceback and creates /etc/nvme directory.
This patch checks if nvme is configured and avoids the case
if nvme is not used.
Closes-Bug: #1929074
Closes-Bug: #1929075
Change-Id: I2473f50671b9c3f1840efd0d12d2a2572a21d850
This adds the "tox -e mypy" environment which works
the same way we have introduced mypy in Cinder.
Files added to mypy-files.txt are validated with mypy.
Change-Id: I6d09422dbdf5ea58661aad7a63c4d4d7a2839833
The current NVMe-oF connector code in os-brick doesn't flush on
disconnect, as it just calls
nvme disconnect -n <conn_nqn>
Which doesn't flush on the `nvme` code or the kernel code.
This patch adds the normal block device ioctl flush call:
blockdev --flushbufs /dev/nvme0n1
The patch also adds and extends disconnect unit tests that were removed
when we added the new NVMe connector code (were not removed when we
added old code back).
Closes-Bug: #1903032
Change-Id: Ie6c8bdf1f3a629206da019405aee11c802a6a9bb
Recent multipathd doesn't remove path devices timely when it receives
burst of udev events but wait for a while to start actual removal.
Because os-brick removes path devices in a short time during detaching
a multipath device, it is likely to hit this burst limit and sometimes
path devices are not removed before a subsequent operation is started.
This change ensures that os-brick tells mutlipathd to remove path
devices when the devices should be deleted, so that orphan paths are
not left when starting a subsequent attach operation.
Closes-Bug: #1924652
Change-Id: I65204aa7495740dc1545bff2c5c485a8041e7930
With changing the SOAP library backing oslo.vmware [1], the cookiejar of
a session must be accessed differently. Therefore, oslo.vmware
introduced a property on the client to abstract this change away. This
commit uses the new place to access the attribute.
[1] https://specs.openstack.org/openstack/oslo-specs/specs/victoria/oslo-vmware-soap-library-switch.html
Change-Id: I0e308b4798e2c632c79f60f91abca697bd91687d
Resolves warnings like the following:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
Change-Id: Ibda458a394207539db128d99fbd45a1d4560562c
This patch adds tox settings for running tox -ebandit
to look at potential security issues.
Current issues:
scaleio connector disables SSL cert verification.
Change-Id: I79bec423a051eb12ab53042840a519bd4a77b4da
OS-Brick disconnect_volume code assumes that the use_multipath parameter
that is used to instantiate the connector has the same value than the
connector that was used on the original connect_volume call.
Unfortunately this is not necessarily true, because Nova can attach a
volume, then its multipath configuration can be enabled or disabled, and
then a detach can be issued.
This leads to a series of serious issues such as:
- Not flushing the single path on disconnect_volume (possible data loss)
and leaving it as a leftover device on the host when Nova calls
terminate-connection on Cinder.
- Not flushing the multipath device (possible data loss) and leaving it
as a leftover device similarly to the other case.
This patch changes how we do disconnects, now we assume we are always
disconnecting multipaths, and fallback to doing the single path
disconnect we used to do if we can't go that route.
The case when we cannot do a multipathed detach is mostly when we did
the connect as a single path and the Cinder driver doesn't provide
portal_targets and portal_iqns in the connection info for non
multipathed initialize-connection calls.
This changes introduces an additional call when working with single
paths (checking the discoverydb), but it should be an acceptable
trade-off to not lose data.
Closes-Bug: #1921381
Change-Id: I066d456fb1fe9159d4be50ffd8abf9a6d8d07901
Add file to the reno documentation build to show release notes for
stable/wallaby.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/wallaby.
Sem-Ver: feature
Change-Id: If3b3fef1a8b7a86db1bf08fa3cd05457209d3fa0
Merges the original nvmeof.py connector with the refactor change "NVMeOF Connector support MDRAID replication" such that the new features introduced in the mdraid+ change are only used when 'volume_replicas' is specified in the connection information.
Also includes a couple minor fixes to the nvmeof v2/mdraid+ mode of operation: host nqn generation and handling of raising connect volume exceptions.
Closes-Bug: #1916264
Change-Id: I94c00afc80f20965a0b391ee3bf21162b827bd31
Raise the minimum versions in the various requirements files to
reflect what we're actually testing with right now.
Change-Id: Ie7dcc859e1291bd1d50b1ae516be38d8732de836
Currently we don't properly catch some possible exceptions during
connectiing to iSCSI portals, like failures in "iscsiadm -m session".
Because of this _connect_vol threads can abort unexpectedly in some
failure patterns, and this abort causes hung in subsequent steps
waiting for results from _connct_vol threads.
This change ensures that any exceptions during connecting to iSCSI
portals are handled in the _connect_vol method corectly, to avoid
unexpected abort without updating thread results.
Closes-Bug: #1915678
Change-Id: I0278c502806b99f8ec65cb146e3852e43031e9b8
Zuul
Brian Rosmaita
Yandong Xuan
Stephen Finucane
Gorka Eguileor
Rajat Dhasmana
Eric Harney
dengzhaosen
Takashi Kajinami
Mike Durnosvystov
Hemna
OpenStack Release Bot
Zohar Mamedov
tushargite96