April 2019 - openstack-discuss - lists.openstack.org

Openstack attaching same pci device to 2 different vms?
by Manuel Sopena Ballesteros 05 Apr '19

05 Apr '19

Dear Openstack community, I recently setup pci-passthrough against nvme drives to directly attach the disks to the vm as a block device. I created 2 vms on the same physical host and I can see the disks (nvme0n1) on both of them: [centos@test-nvme-small ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 10G 0 disk └─vda1 253:1 0 10G 0 part / nvme0n1 259:0 0 1.8T 0 disk [centos@test-nvme-small-2 ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 10G 0 disk └─vda1 253:1 0 10G 0 part / nvme0n1 259:0 0 1.8T 0 disk So I wanted to check which nvme device was attached to which vm. I thought one option would be to dump the vm xml file from virsh which can be found below (I am only putting the information between the disks section but happy to attach the hole file if needed): Device/disk configuration for instance-00000094 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/fd95cc45-1501-4693-8643-944be2ff4625/disk'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> Device/disk configuration for instance-00000093 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/7e6a055c-1b4e-458c-89cd-cb8c1d10e939/disk'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> Based on this output and If I am not mistaken I am under the impression that the host pci device attached to both vms is 0000:00:04.0 Questions: Is there an Openstack way to check which pci devices are attached to which vms instead of having to dump the vm xml file? Am I right assuming that the same disk is attached to both vms? If yes, how can that happen? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

octavia 4.0.0.0rc2 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for octavia for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/908 and tag it *stein-rc-potential* to bring it to the octavia release crew's attention.

1 0

openstack-congress 9.0.0.0rc2 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for openstack-congress for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/congress/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/congress/log/?h=stable/stein Release notes for openstack-congress can be found at: https://docs.openstack.org/releasenotes/congress/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/congress/+bugs and tag it *stein-rc-potential* to bring it to the openstack-congress release crew's attention.

1 0

[nova][dev] Fixing eventlet monkey patching in Nova
by Matthew Booth 05 Apr '19

05 Apr '19

We're hitting an issue with eventlet monkey patching in OSP15, which uses python 3.6. The issue manifests as infinite recursion when a nova service connects to another openstack service over SSL. The immediate cause is that we import urllib3 before calling eventlet.monkey_patch(). I can't find the precise details now, but the reason for this relates to initialisation done by either the ssl or urllib3 libraries at import time which is therefore not patched by eventlet. The detail isn't that important, in any case. The issue may just be specific to a particular combination of library versions we're using in OSP, or possibly that our default configuration exercises something we're not doing in the gate. Regardless, unless we change where we monkey patch we're going to hit this again in the future with other library quirks. Our own eventlet best practises say: "When using eventlet.monkey_patch, do it first or not at all."[1] We're not doing that for both types of service: * non-wsgi For non-wsgi services we monkey patch in nova/cmd/__init__.py with the call utils.monkey_patch(). At first glance that appears to be very early, but note that this required importing nova.utils first, which in turn imports the world, and all before monkey patching. I believe this was regressed in Stein by change Ie7bf5d012e2ccbcd63c262ddaf739782afcdaf56[2], which was attempting to fix the wsgi case. * wsgi For wsgi services our entry point is nova.api.openstack.wsgi_app, which calls utils.monkey_patch(). This suffers the same problem as the non-wsgi case, but additionally suffers from having loaded nova/api/openstack/__init__.py first, which also imports the world. Incidentally, as noted in change Ie7bf5d012e2ccbcd63c262ddaf739782afcdaf56 we *do* currently require eventlet in at least the nova api service, even when running as a wsgi service. This has not regressed the wsgi case, though, as that would already have been broken due to the libraries imported by nova/api/openstack/__init__.py. Lee Yarwood originally posted (and I took over from him) https://review.openstack.org/#/c/626952/ with the intention of fixing the wsgi case. We semi-abandoned it because, while the fix seemed to make sense, it didn't fix the wsgi case when tested. I now realise that this is due to the libraries loaded by nova/api/openstack/__init__.py. I have resubmitted this patch as it fixes the non-wsgi case, and also updated the commit message to be accurate according to my current understanding. However, fixing the non-wsgi case is more complicated. We can't do the monkey patching in nova.api.openstack.wsgi_app because nova/api/openstack/__init__.py imports the world. I believe we have 3 options: 1. Don't import the world in nova/api/openstack/__init__.py 2. Change the wsgi entry point to, for eg, nova.wsgi_app 3. Do monkey patching in nova/__init__.py Of the above, I haven't investigated either 1 or 2 in any great detail. I suspect (1) would be quite invasive, and (2) would presumably have a deployment impact. I believe that the reason we haven't previously done (3) has been the desire not to monkey patch in certain circumstances. However, as it stands today we always need eventlet, so (3) seems like an expedient route. The code change required is very small. In testing the above I threw up 2 follow on patches: * https://review.openstack.org/643579 This makes a couple of cleanups, but significantly adds an assertion that problem libraries haven't been imported before monkey patching. As expected, this kills nova-api (wsgi): http://logs.openstack.org/79/643579/1/check/tempest-full-py3/94b0156/contro… but not nova-compute (non-wsgi): http://logs.openstack.org/79/643579/1/check/tempest-full-py3/94b0156/contro… Interestingly, I also bumped the minimum eventlet version in that patch to remove some no-longer-required cruft from oslo_service. If I'm reading this failure correctly, we're pinning eventlet to version 0.18.2 in the gate. Why such an old eventlet? I can't see where this pin is coming from, but my (unsubstantiated) guess is that this is the principal difference from OSP, where we're currently installing eventlet 0.24.1: http://logs.openstack.org/79/643579/1/check/requirements-check/fc9f093/job-… * https://review.openstack.org/#/c/643581/ Here I just switched to top-level monkey patching. This is still running, but at first glance the tempest runs don't seem to have failed early, which they would have given that the patch is stacked on top of the the assertions from the prior patch. TL;DR I want to move monkey patching to nova/__init__.py because, for now at least, we always require it anyway. When we eventually remove the requirement for wsgi services to monkey patch we can move monkey patching back to nova/cmd/__init__.py. Matt [1] https://specs.openstack.org/openstack/openstack-specs/specs/eventlet-best-p… [2] https://review.openstack.org/#/c/592285/ -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK)

10 19

nova 19.0.0.0rc2 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for nova for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/nova/log/?h=stable/stein Release notes for nova can be found at: https://docs.openstack.org/releasenotes/nova/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+bugs and tag it *stein-rc-potential* to bring it to the nova release crew's attention.

1 0

[nova] Down cell testing with devstack
by Matt Riedemann 05 Apr '19

05 Apr '19

Just an FYI but I've posted a docs patch with a testing guide for recreating a down-cell environment with a simple devstack setup: https://review.openstack.org/#/c/650167/ I had done this awhile back and had it on my todo list to make sure this was documented for the next time I need to do some manual testing with down cells. -- Thanks, Matt

1 0

[requirements][FFE][congress] remove psycopg2>=2.7
by Eric K 05 Apr '19

05 Apr '19

Requesting exception to remove a requirement to resolve a packaging issue. The package is needed only for an experimental feature, but causes packaging issue on RHEL/CentOS 7. Propose to remove from requirements and require manual install to enable the experimental feature. https://review.openstack.org/#/c/649772/

5 11

[tc] Feedback on Kata Containers and Zuul pilot projects
by Jeremy Stanley 04 Apr '19

04 Apr '19

Per the confirmation guidelines[0] and foundation mailing list thread[1], the OSF Board of directors is soliciting feedback from representatives of existing confirmed Open Infrastructure Projects (so far that's just OpenStack) when evaluating the Kata Containers and Zuul pilot projects' upcoming applications for OIP confirmation. Particularly worth calling out, guideline #4 "Open collaboration" asserts the following: Project behaves as a good neighbor to other confirmed and pilot projects. If you (our community at large, not just TC members) have any observations/interactions with the Kata Containers and Zuul maintainers or their software which could serve as useful examples for how these projects do or do not meet this and other guidelines, please provide them in the per-project pads[2][3] and if possible include a citation with links to substantiate your feedback. After March 31, 2019 the information there will be assembled into more cohesive documents and posted to the foundation mailing list in preparation for the scheduled OSF Board of Directors meeting[4] on April 8. [0] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [1] http://lists.openstack.org/pipermail/foundation/2019-March/002721.html [2] https://etherpad.openstack.org/p/openstack-tc-kata-confirmation-feedback [3] https://etherpad.openstack.org/p/openstack-tc-zuul-confirmation-feedback [4] http://lists.openstack.org/pipermail/foundation/2019-March/002733.html -- Jeremy Stanley

1 2

openstack-heat 12.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for openstack-heat for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/heat/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/heat/log/?h=stable/stein Release notes for openstack-heat can be found at: https://docs.openstack.org/releasenotes/heat/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/989 and tag it *stein-rc-potential* to bring it to the openstack-heat release crew's attention.

1 0

mistral-dashboard 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for mistral-dashboard for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral-dashboard/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/mistral-dashboard/log/?h=stable/st… Release notes for mistral-dashboard can be found at: https://docs.openstack.org/releasenotes/mistral-dashboard/

1 0