- openstack-discuss - lists.openstack.org

[qa][devstack] Moving to release specific nodesets and jobs for Fedora
by Lee Yarwood 16 Apr '20

16 Apr '20

Hello all, $subject has come up with the last couple rounds of changes introducing support for the latest version of Fedora within devstack. I've pushed a change introducing version specific nodesets and jobs for Fedora 31 as a way of starting a discussion around this ahead of the PTG: WIP Fedora: Start using version specific nodesets and jobs https://review.opendev.org/#/c/719775/ I'm personally on the fence about this as while it would be nice to have version specific nodesets and jobs it does introduce a lot of churn with each new release of Fedora across many projects: http://codesearch.openstack.org/?q=fedora%5C-latest Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

4 5

[QA][barbican][cloudkitty][heat][ironic][magnum][manila][monasca][swift] Intermediary release reminder
by Sean McGinnis 16 Apr '20

16 Apr '20

Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest ussuri release available on release week. The following deliverables have done a ussuri release, but it has not been refreshed in the last two months: Quality Assurance patrole barbican barbican-ui cloudkitty cloudkitty heat heat-agents ironic bifrost ironic-inspector ironic-prometheus-exporter ironic-python-agent ironic-ui ironic networking-baremetal networking-generic-switch magnum magnum-ui manila manila-ui monasca monasca-thresh monasca-ui swift swift There are still a couple weeks to go, so this is just a reminder that you should consider making a new one very soon, so that we don't use an outdated version for the final release. Just let me know if there any questions. Thanks! Sean

3 4

[tripleo] ptg meetings and time zones
by Wesley Hayutin 16 Apr '20

16 Apr '20

Greetings, Looking to see if there are strong preferences for our time slots for the PTG. I would suggest we try to shoot for 13-17 UTC slot [1] as much as possible. Any strong preference in not utilizing that time slot? Reminder.. topics topics topics Thanks all 0/ [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.opendev.org/p/tripleo-victoria-topics <https://etherpad.opendev.org/p/tripleo-victoria-topics>

3 2

[TripleO][Ironic] pxe boot remote host
by Ruslanas Gžibovskis 16 Apr '20

16 Apr '20

Hi all, Could someone help me, I do not get, I try to boot remote host (behind Firewall). I have dhcp-relay configured. And finally, I see the DHCP request, but nothing else happens... except me crying ;'( "D DHCP request captured on undercloud vnet5 where dhcp is listening also on eth1, But I am not able to load a remote host. I had a thought, maybe DHCP is generally not working, but one node which is local, I am able to introspect and provide it. completely nothing in /var/log/containers/ironic-inspector/dnsmasq.log Any suggestions? My network, which I used and have configured on undercloud host is: 10.120.191.80/28 and IP for DHCP which is configured as dhcp relay is 94. output from tcpdump: 21:19:00.058565 40:a6:77:4b:07:cb > 52:54:00:20:c1:dc, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 58, id 60458, offset 0, flags [none], proto UDP (17), length 576) 10.41.94.241.67 > 10.120.191.94.67: [udp sum ok] BOOTP/DHCP, Request from 24:6e:96:14:a1:a4, length 548, hops 1, xid 0x9614a1a4, secs 12, Flags [Broadcast] (0x8000) Gateway-IP 10.41.94.241 Client-Ethernet-Address 24:6e:96:14:a1:a4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 36: Subnet-Mask, Time-Zone, Default-Gateway, Time-Server IEN-Name-Server, Domain-Name-Server, RL, Hostname BS, Domain-Name, SS, RP EP, RSZ, TTL, BR YD, YS, NTP, Vendor-Option Requested-IP, Lease-Time, Server-ID, RN RB, Vendor-Class, TFTP, BF Option 128, Option 129, Option 130, Option 131 Option 132, Option 133, Option 134, Option 135 MSZ Option 57, length 2: 1260 GUID Option 97, length 17: 0.68.69.76.76.57.0.16.56.128.80.200.192.79.56.68.50 ARCH Option 93, length 2: 0 NDI Option 94, length 3: 1.2.1 Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001" -- Ruslanas Gžibovskis +370 6030 7030

2 4

[kolla][ptg] virtual PTG
by Mark Goddard 16 Apr '20

16 Apr '20

Hi, For Victoria we will again be having a virtual PTG, however this time due to "you know what" we will be holding it at the same time as the other teams. The PTG will take place from 1st - 5th June, with various slots [1] available throughout the day from which we can select. Looking at previous events [2][3], we had two four hour slots. For Train this was 12:00 - 16:00 UTC, and for Ussuri 14:00 - 18:00 UTC. Note that Train was during daylight savings, Ussuri was not. We also held a mid-Train planning session for Kayobe [4], which took two hours. Based on the above, I suggest we go with the same as Ussuri: Monday 1st: 14:00 - 18:00 UTC (kolla) Tuesday 2nd: 14:00 - 18:00 UTC (kolla) Wednesday 3rd: 14:00 - 16:00 UTC (kayobe) This is just a proposal - if you would like to attend these sessions and the above time slots do not work for you, please get in touch. In particular, please speak up if these slots are significantly out of your working day - with sufficient interest we could split sessions across timezones. [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.openstack.org/p/kolla-ussuri-ptg [3] https://etherpad.openstack.org/p/kolla-train-ptg [4] https://etherpad.opendev.org/p/kayobe-train-planning Cheers, Mark

2 4

[tc] [ironic] Promoting ironic to a top-level opendev project?
by Dmitry Tantsur 16 Apr '20

16 Apr '20

Hi everyone! This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion. TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. (And no, it’s not an April 1st joke) Background ========= Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it. And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team. Okay, so why? =========== The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it? Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here. Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above). What we will do ============ This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule. In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication). What we will NOT do ================ At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely. What do you think? =============== Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome. Cheers, Dmitry

24 93

OpenStack should be buildable with sphinx 2.4: FTBFS in many packages
by Thomas Goirand 16 Apr '20

16 Apr '20

Hi, Sphinx 2.4 has been uploaded to Experimental. I just received bug reports against the OpenStack packages because some of them cannot be built with Sphinx 2.4. Here's the list: - ironic - os-api-ref - aodh - cloudkitty - kombu - panko - ceilometerclient - ceilometermiddleware - doc8 - dracclient - glareclient - murano-pkg-check - os-xenapi - scciclient - sahara - sphinxcontrib-programoutput - tempest-horizon It'd be nice if those affected could be fixed for Ussuri. IMO, it's just the doc, so fixing it wouldn't hurt code quality. In other words: help would be more than welcome writing patch or reviewing them, and testing Sphinx 2.4 compatibility. Cheers, Thomas Goirand (zigo)

7 13

[neutron] port binding issues after upgrade attempt
by Jean-Philippe Méthot 15 Apr '20

15 Apr '20

Hi, We’ve been running a somewhat old version of openstack-queens for a while (I don’t know the exact release number, you will understand why shortly). Our setup has dedicated network nodes which we set up to use l3ha not too long ago. The package version was more recent on the second network node than on the first one because of that, however, high availability worked fine. We then tried to upgrade to rocky and since then, we get binding failed errors for pretty much all our ports whenever a router change network node. The only way we’ve found to fix this is to shutdown our neutron services and then reimport our pre-upgrade openstack database backup. This way, every port gets created properly, as it was at the time. Since then we have: -Moved everything back to queens. -Reinstalled our controller and network nodes from scratch (which is why I don’t know which queens version we were using before). However, this issue still happens as soon as the router change network node. Most ports get binding failed errors and restoring the database backup is the only way we managed to get out of this issue each time. We use neutron-openvswitch for networking and tunneling is done with GRE. Our OS is centos 7. Is it possible that code pertaining to HA may have changed in the later versions of queens and rocky which could explain that we’re running into a bug of some sort? Is there a way I could get neutron to tell me exactly why port binding is failing? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

1 0

[all][elections][tc] Technical Committee Election Results
by Kendall Nelson 15 Apr '20

15 Apr '20

Hello Everyone! Please join me in congratulating the 5 newly elected members of the Technical Committee (TC). Graham Hayes (mugsie) Kristi Nikolla (knikolla) Mohammed Naser (mnaser) Belmiro Moreira (belmoreira) Rico Lin (ricolin) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_95cb11614fb23566 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round! -Kendall Nelson (diablo_rojo) & the Election Officials

9 8

[tripleo] undercloud installation failed at "waiting for container to start"
by Giuseppe Sannino 15 Apr '20

15 Apr '20

Hi all, need a (hopefully) small help from you. I'm trying to deploy Openstack on RHLE8 using TripleO. The "openstack undercloud install" fails at this stage: 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 5 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 623.63s 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 4 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 304.39s Images are fetched from the RedHat registry and pushed on the local registry: *>> containers-prepare-parameter.yaml* ContainerImageRegistryCredentials: registry.redhat.io: xxx:yyy ContainerImagePrepare: - push_destination: rhosp-under.ctlplane.localdomain:8787 *>> From "/var/log/tripleo-container-image-prepare.log"* I can see images are properly pushed into local registry: 2020-04-10 17:17:22,339 587093 INFO tripleo_common.image.image_uploader [ ] [registry.redhat.io/rhosp-rhel8/openstack-nova-compute-ironic:16.0-91] Completed upload for image 2020-04-10 17:17:22,341 586855 INFO tripleo_common.image.image_uploader [ ] result [] 2020-04-10 17:17:22,370 586855 INFO root [ ] ContainerClustercheckConfigImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 ContainerClustercheckImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 : : : ContainerZaqarImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 DockerInsecureRegistryAddress: - rhosp-under.ctlplane.localdomain:8787 >> From "install-undercloud.log" I can see a smooth procedure till it gets to the "TASK [Debug output for task: Start containers for step XX ]" phase. Specifically, at step 5 it ends unsuccesfully. *>> podman image list* Empty *>> podman ps* Empty >> openstack tripleo container image list [stack@rhosp-under ~]$ openstack tripleo container image list +--------------------------------------------------------------------------------------------------------+ | Image Name | +--------------------------------------------------------------------------------------------------------+ | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-heat-engine:16.0-91 | : : : | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-cron:16.0-96 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-keystone:16.0-93 | +--------------------------------------------------------------------------------------------------------+ Any suggestion would be more than welcome Many thanks in advance /Giuseppe

3 5

[neutron] Bug deputy report for week of April 6th
by Lajos Katona 15 Apr '20

15 Apr '20

Hi, I was Neutron bug deputy last week, please read a short summary of last week's reported Neutron bugs. What I would like to highlight: 1871032 <https://bugs.launchpad.net/neutron/+bug/1871032> and 1871239 <https://bugs.launchpad.net/neutron/+bug/1871239> are unassigned and 1871608 <https://bugs.launchpad.net/neutron/+bug/1871608> needs more investigation (at least from my side to what happens there). - Critical bugs - Rally job on stable branches is failing ( https://bugs.launchpad.net/neutron/+bug/1871596) In Progress - High priority bugs - Not Assigned: - OVN migration scripts doesn't work with SSL-only deployment ( https://bugs.launchpad.net/neutron/+bug/1871032) - ovn-octavia-provider is not using load balancing algorithm source-ip-port (https://bugs.launchpad.net/neutron/+bug/1871239) - In Progress - neutron.tests.functional.agent.ovn.metadata.test_metadata_agent.TestMetadataAgent.test_agent_registration_at_chassis_create_event fails randomly (https://bugs.launchpad.net/neutron/+bug/1871340) - OVN octavia provider driver should spawn long-living process in driver agent (https://bugs.launchpad.net/neutron/+bug/1871355) - fix Released - [VPNaaS]: DeprecationWarning: invalid escape sequence ( https://bugs.launchpad.net/neutron/+bug/1871621) - More investigation is necessary - OVN] Cannot create metadata port for segmented network ( https://bugs.launchpad.net/neutron/+bug/1871608) - Low priority bugs - [OVN] local conf devstack for a ovn-northd (DB only) node does not work (https://bugs.launchpad.net/neutron/+bug/1871730) - Whishlist - neutron ovn db clients need more logs if they fail to connect to db (https://bugs.launchpad.net/neutron/+bug/1871427) - Incomplete or solved in other projects - vm cannot be created after a large number of vms are removed from the same node (https://bugs.launchpad.net/neutron/+bug/1870723) - stable/stein tempest-full job fails with "tempest requires Python '>=3.6' but the running Python is 2.7.17" was solved in devstack ( https://bugs.launchpad.net/neutron/+bug/1871327) It was solved in devstack Best wishes Lajos (lajoskatona) ,-.,-. ( ( ( \ ) ) _..-.._ __)/ ,',' `. ," `. ,--. `. ," @ .' ` \ (Y ( ;''. `--.____, \ , ; ((_ ,----' ,---' _,'_,' (((_,- (((______,-' ------------------------------------------------ Thank you for visiting https://asciiart.website/ This ASCII pic can be found at https://asciiart.website/index.php?art=holiday/easter

2 4

[manila] Driver interface changes
by Carlos Silva 14 Apr '20

14 Apr '20

Greetings, zorillas! During the previous week we have merged a change in manila which improves the create share from snapshot functionality [1] to allow a multi-stage share creation. This means that a share creation request at the share manager can be acknowledged by the share driver to be pending; and the share manager will call a different driver interface to gather the status of this share, periodically until it is created. The primary benefit of this change is for drivers that cannot clone their snapshots instantaneously into new shares, and for drivers that would like to implement snapshot cloning across different storage pools or back ends. To make these changes, we needed to change the driver interface. All in-tree drivers were already modified and are up to date with the changes in the interface. The out-of-tree drivers will need to be updated as well according to the changes in the interface, then they will be able to work properly. [1] https://review.opendev.org/#/c/709697/ Regards, Carlos Eduardo da Silva.

1 0

[oslo] Ussuri stable branches created
by Ben Nemec 14 Apr '20

14 Apr '20

This has two major implications: 1) Master is no longer feature frozen 2) Any future Ussuri bug fixes will need to be backported Because of 2 and in spite of 1, please try to avoid merging any highly invasive changes to master between now and the Ussuri coordinated release. If we end up needing a last-minute bug fix we don't want to have to disentangle it from a huge refactoring effort (or whatever) in order to backport. Thanks. -Ben

1 0

[all][elections][tc] TC Voting Last Days
by Kendall Nelson 14 Apr '20

14 Apr '20

We are coming down to the last hours for voting in the TC election. Voting ends Apr 14, 2020 23:45 UTC. Search your gerrit preferred email address[0] for the following subject: Poll: OpenStack 'Victoria' TC Election (yes, the CIVS system had problems with escaped characters) That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/#victoria-tc-candidates What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[1] and email the election officials[2]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/raw/tag/0.5.0/reference/projects.y… [2] https://governance.openstack.org/election/#election-officials

1 0

[tc][all][SDK][API] Multi-region/edge OpenStack deployment
by Marie Delavergne 14 Apr '20

14 Apr '20

Hi, Following the previous discussions regarding approaches to make several instances of OpenStack collaborative[1], we finally decided to make a research report on the approach we initially proposed during the edge hackathon in Berlin (OSF summit 2018). The document is a short article (~10 pages long)[2] that gives a rather complete overview of the approach. If you are interested to see how mutliple instances of distinct OpenStack can give the illusion of a single system you might be interested to give it a look. A brief excerpt: “We propose a novel approach that delivers any collaboration between services of distinct OpenStack once and for all. Our approach eliminates development efforts related to the brokering aspect by leveraging dynamic composition and a Domain Specific Language (DSL). Using these two mechanisms, Admins/DevOps can specify, on a per-request basis, which services from which OpenStacks are required for the collaboration. This information is then interpreted to dynamical recompose services between the different OpenStacks, enabling the execution of single-, cross- or multiple-site requests without code effort.” The main idea is, considering several OpenStacks running, to use a DSL to specify which instance of the service (i.e. on which Openstack) the user wants its request to be executed. For instance, to provision a VM on a Nova in Paris using an image from a Glance in New York. You may contact the API either in NewYork or in Paris and perform the following request: "openstack server create --image debian --scope { compute: Paris, image: New York }" Along with the report comes a proof of concept available on GitLab[3]. Feel free to get back to us. Cheers [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013562.ht… [2] https://hal.inria.fr/hal-02527366/ [3] https://gitlab.inria.fr/discovery/openstackoid ---- Marie Delavergne

2 2

[cinder] datera ibm-gpfs macrosan sandstone - upcoming deadlines
by Brian Rosmaita 14 Apr '20

14 Apr '20

This is a reminder that the drivers listed in the subject have ussuri blueprints containing some open items. datera: https://blueprints.launchpad.net/cinder/+spec/datera-driver-restoration - needs: update support matrix, update docs if necessary, release note ibm-gpfs: https://blueprints.launchpad.net/cinder/+spec/ibm-gpfs-supported - have declared intent to restore CI and mark driver supported, but no patches yet macrosan: https://blueprints.launchpad.net/cinder/+spec/macrosan-driver-supported - support patch mixed in with features, so must be merged by noon UTC on Friday 17 April - patch requires revision - at this point, should probably make sure the CI is running reliably and split the patch into (a) mark the driver supported in ussuri, and (b) the new features (which will be held for victoria) sandstone: https://blueprints.launchpad.net/cinder/+spec/add-sandstone-driver - needs: update support matrix, documentation page, release note Please address these issues immediately; all patches should be merged before RC-1 (23 April). Tracking this on: https://etherpad.opendev.org/p/cinder-ussuri-driverstuff

1 0

[tripleo] puppet-tripleo has puppet-openstack-unit-5.5-centos-8 broken
by Takashi Kajinami 14 Apr '20

14 Apr '20

# resending with the correct tag. sorry for the noise. Hi All, Currently puppet-openstack-unit-5.5-centos-8 job in puppet-tripleo is broken. I've already filed a bug[1] and submitted the fix[2] to revert the commit which caused the failure. [1] https://bugs.launchpad.net/tripleo/+bug/1872562 [2] https://review.opendev.org/#/c/719699/ Please hold rechecks in puppet-tripleo until the fix is merged. Sorry for the inconvenience. Thank you, Takashi -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

2 2

[nova]-Pci device pass-through error.
by zhangcf9988＠aliyun.com 13 Apr '20

13 Apr '20

Hello, contributors to the Openstack community: I've got a problem and I'd love to get some advice. When we used the openstack-pike version, we encountered the following problems: Deployment environment: The openstack-pike version of openstack was installed on CentOS7.7.1908 system using yum, where nova version was 9.1.3 Nova - compute node: The Dell R730 server was used, and three graphics CARDS of the same model Nvidia 1050 Ti were installed. At the same time, the iommu was enabled and the graphics card pass-through was configured. But we had a problem: Two PCI expansion board CARDS were installed on Dell R730, two Nvidia 1050 Ti graphics CARDS were installed on the first PCI expansion board card, and one was installed on the second PCI expansion board card. As an Nvidia 1050 Ti graphics card is composed of two chips, respectively: Video card chip (Proudct_id:1c82, Vendor_id:10de) Sound card chip (Proudct_id:0fb9, Vendor_id:10de) Create a VM, we hope that the VM can passthrough for graphics and sound card chip at the same time, but we test found that VM will get 2 graphics or sound card chip, rather than a complete physical graphics should be some graphics and sound card chip, consequences of this, we installed the three pieces of graphics card, no one can be normal use, because the first VM occupies two graphics chips, lead to the second created, VM libvirtd detected a VM occupies physical graphics graphics chips, cause the failure of the second always create a VM. At the same time, I also tested that when I removed one of the two Nvidia graphics CARDS on the first PCI expansion board card and installed a physical Nvidia graphics card on the first and second PCI expansion board CARDS, the test created a VM that could obtain a video card and a sound card chip at the same time, so that the VM successfully obtained a complete Nivida physical graphics card. We hope that we can insert pieces of the same type of graphics card, but now we tried by modifying the nova pci_devices table in the database, the first VM can be modified by the graphics card is assigned the wrong question, but in fact, the second VM still complains when created, and will also we manually modify the database information to clean up, at present there are two possible solutions, the first is to modify the source code, the second is using different types of graphics CARDS, don't know the problem, can be solved by modifying the source code. Thank you very much. The following is the configuration of nova on the control node: [DEFAULT] enabled_apis = osapi_compute,metadata my_ip = 172.16.160.206 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver transport_url = rabbit://openstack:mqpass123@baseserver available_filters=nova.scheduler.filters.all_filters available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter enabled_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:novapass123@baseserver/nova_api [cinder] os_region_name = RegionOne [database] connection = mysql+pymysql://nova:novapass123@baseserver/nova [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://controller:9292 [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = baseserver:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = novapass123 [neutron] url = http://controller:9696 auth_url = http://controller:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = netpass123 service_metadata_proxy = true metadata_proxy_shared_secret = 20190909 [oslo_concurrency] lock_path=/var/lib/nova/tmp [pci] alias = { "name": "nvidia1050ti", "product_id": "1c82", "vendor_id": "10de", "device_type": "type-PCI" } alias = { "name": "nvidia1050ti", "product_id": "0fb9", "vendor_id": "10de", "device_type": "type-PCI" } [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller:35357/v3 username = placement password = novapass123 [vnc] enabled = true vncserver_listen = $my_ip vncserver_proxyclient_address = $my_ip #The following is the configuration for nova-compute: /etc/nova/nova.conf: [DEFAULT] enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:mqpass123@baseserver my_ip = 172.16.160.204 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver instance_name_template = instance-%(uuid)s remove_unused_base_images=false [api] auth_strategy = keystone [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = baseserver:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = novapass123 [vnc] enabled = True #vncserver_listen = 0.0.0.0 #vncserver_proxyclient_address = $my_ip vncserver_listen = 172.16.160.204 vncserver_proxyclient_address = 172.16.160.204 novncproxy_base_url = http://172.16.160.206:6080/vnc_auto.html keymap=en-us [glance] api_servers = http://controller:9292 [oslo_concurrency] lock_path = /var/lib/nova/tmp [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller:35357/v3 username = placement password = novapass123 [libvirt] virt_type = kvm #virt_type = qemu use_usb_tablet=true [filter_scheduler] enabled_filters = RetryFilter,AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateCoreFilter,AggregateDiskFilter,DifferentHostFilter,SameHostFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters [PCI] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1c82" }, {"vendor_id": "10de", "product_id": "0fb9"}] alias = { "name": "nvidia1050ti", "product_id": "1c82", "vendor_id": "10de", "device_type": "type-PCI"} alias = { "name": "nvidia1050ti", "product_id": "0fb9", "vendor_id": "10de", "device_type": "type-PCI"} [neutron] metadata_proxy_shared_secret = 20190909 service_metadata_proxy = true url = http://controller:9696 auth_url = http://controller:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = netpass123 flavor: openstack flavor create --public --ram 10240 --disk 50 --vcpus 4 nvidia1050ti --id 1 \ --property os_type=windows \ --property hw_firmware_type=uefi \ --property hw_machine_type=q35 \ --property img_hide_hypervisor_id=true \ --property os_secure_boot=required \ --property hw_cpu_cores=4 \ --property hw_cpu_sockets=1 \ --property hw_cpu_threads=2 \ --property pci_passthrough:alias='nvidia1050ti:2' image: openstack image create win10base1903UEFI --file win10base1903Q35V1.qcow2 --container-format bare --disk-format qcow2 --public \ --property os_type=windows \ --property hw_firmware_type=uefi \ --property hw_machine_type=q35 \ --property img_hide_hypervisor_id=true \ --property os_secure_boot=required \ --property hw_cpu_cores=4 \ --property hw_cpu_sockets=1 \ --property hw_cpu_threads=2 \ --property pci_passthrough:alias='nvidia1050ti:2' #The following is an error reported in openstack-nova -compute: 2020-03-31 10:57:04.555 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.723 2643 ERROR nova.virt.libvirt.guest [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Error launching a defined domain with XML: <domain type='kvm'> <name>instance-7e5d283f-5ed5-4ebe-b145-d348e94addca</name> <uuid>7e5d283f-5ed5-4ebe-b145-d348e94addca</uuid> <metadata> <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> <nova:package version="16.1.7-1.el7"/> <nova:name>test1</nova:name> <nova:creationTime>2020-03-31 02:57:04</nova:creationTime> <nova:flavor name="nvidia1050ti_50G"> <nova:memory>10240</nova:memory> <nova:disk>50</nova:disk> <nova:swap>0</nova:swap> <nova:ephemeral>0</nova:ephemeral> <nova:vcpus>4</nova:vcpus> </nova:flavor> <nova:owner> <nova:user uuid="68711849a60849d7807d71968ba6b275">demo</nova:user> <nova:project uuid="fa79259f6d2a442c86d4cd5e0e6c788c">demo</nova:project> </nova:owner> <nova:root type="image" uuid="24bb256e-9cea-4dcd-96e0-e6bd81156052"/> </nova:instance> </metadata> <memory unit='KiB'>10485760</memory> <currentMemory unit='KiB'>10485760</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>4096</shares> </cputune> <sysinfo type='smbios'> <system> <entry name='manufacturer'>RDO</entry> <entry name='product'>OpenStack Compute</entry> <entry name='version'>16.1.7-1.el7</entry> <entry name='serial'>30535dfb-90e3-401e-bbf7-f2c43120fb65</entry> <entry name='uuid'>7e5d283f-5ed5-4ebe-b145-d348e94addca</entry> <entry name='family'>Virtual Machine</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> <nvram>/var/lib/libvirt/qemu/nvram/instance-7e5d283f-5ed5-4ebe-b145-d348e94addca_VARS.fd</nvram> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='123456789ab'/> </hyperv> <kvm> <hidden state='on'/> </kvm> </features> <cpu mode='host-model' check='partial'> <model fallback='allow'/> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='localtime'> <timer name='pit' tickpolicy='delay'/> <timer name='rtc' tickpolicy='catchup'/> <timer name='hpet' present='no'/> <timer name='hypervclock' present='yes'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </disk> <controller type='usb' index='0' model='qemu-xhci'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x15'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0x16'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> </controller> <interface type='bridge'> <mac address='fa:16:3e:51:25:34'/> <source bridge='brq8d505aa1-51'/> <target dev='tap1a673f99-8a'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <log file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/console.log' append='off'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <log file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/console.log' append='off'/> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='172.16.160.204' keymap='en-us'> <listen type='address' address='172.16.160.204'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <memballoon model='virtio'> <stats period='10'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </memballoon> </devices> </domain> : libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.724 2643 ERROR nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Failed to start libvirt guest: libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.726 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.741 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deleting instance files /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del 2020-03-31 10:57:04.743 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deletion of /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del complete 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Instance failed to spawn: libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Traceback (most recent call last): 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2203, in _build_resources 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] yield resources 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2018, in _build_and_run_instance 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] block_device_info=block_device_info) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2903, in spawn 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] destroy_disks_on_failure=True) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5453, in _create_domain_and_network 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] destroy_disks_on_failure) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self.force_reraise() 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(self.type_, self.value, self.tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5423, in _create_domain_and_network 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] post_xml_callback=post_xml_callback) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5341, in _create_domain 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] guest.launch(pause=pause) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 144, in launch 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self._encoded_xml, errors='ignore') 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self.force_reraise() 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(self.type_, self.value, self.tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 139, in launch 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] return self._domain.createWithFlags(flags) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] result = proxy_call(self._autowrap, f, *args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] rv = execute(f, *args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(c, e, tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] rv = meth(*args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1110, in createWithFlags 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] 2020-03-31 10:57:04.887 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Terminating instance 2020-03-31 10:57:04.896 2643 INFO nova.virt.libvirt.driver [-] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Instance destroyed successfully. 2020-03-31 10:57:04.898 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.939 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deletion of /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del complete 2020-03-31 10:57:05.025 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Took 0.13 seconds to destroy the instance on the hypervisor. 2020-03-31 10:57:05.869 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Took 0.62 seconds to deallocate network for instance. 2020-03-31 10:57:12.019 2643 INFO nova.compute.resource_tracker [req-5a0cf06d-ee8e-4839-a5a5-ee5269299d20 - - - - -] Final resource view: name=dellserver phys_ram=261922MB used_ram=10752MB phys_disk=399GB used_disk=50GB total_vcpus=48 used_vcpus=4 pci_stats=[PciDevicePool(count=0,numa_node=0,product_id='1c82',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=2,numa_node=0,product_id='0fb9',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=1,numa_node=1,product_id='1c82',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=1,numa_node=1,product_id='0fb9',tags={dev_type='type-PCI'},vendor_id='10de')] zhangcf9988(a)aliyun.com

2 1

[project] puppet-tripleo has puppet-openstack-unit-5.5-centos-8 broken
by Takashi Kajinami 13 Apr '20

13 Apr '20

Hi All, Currently puppet-openstack-unit-5.5-centos-8 job in puppet-tripleo is broken. I've already filed a bug[1] and submitted the fix[2] to revert the commit which caused the failure. [1] https://bugs.launchpad.net/tripleo/+bug/1872562 [2] https://review.opendev.org/#/c/719699/ Please hold rechecks in puppet-tripleo until the fix is merged. Sorry for the inconvenience. Thank you, Takashi -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

1 0

[tacker][neutron] Need help in setting up QOS for Neutron Service in Devstack CI Job
by Patil, Tushar 13 Apr '20

13 Apr '20

Hi OpenStackers, In tacker project, we need to setup QOS plugin in devstack CI job (tacker-functional-devstack-multinode-python3) to run our functional tests. I have checked what config options are needed to enable QOS in neutron and updated .zuul.yaml accordingly as you can see in patch [1] PS 18. Mainly, I have enabled following environment variables in .zuul.yaml:- Q_SERVICE_PLUGIN_CLASSES: router,neutron.services.metering.metering_plugin.MeteringPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,neutron.services.qos.qos_plugin.QoSPlugin, Q_ML2_PLUGIN_EXT_DRIVERS: port_security,qos L2_AGENT_EXTENSIONS: qos NEUTRON_PORT_SECURITY: False Problem: Main point is service_plugins config option is configured with qos but the [ml2].extension drivers doesn't include qos. I hav set qos" in Q_ML2_PLUGIN_EXT_DRIVERS but still it's not set in the /etc/neutron/plugins/ml2/ml2_conf.ini in Section [ml2].extension_drivers on the controller node and because of this reason the q-svc service is not starting on the controller node. I have scoured devstack.log to find out where it's overwriting extension_drivers with "port_security" instead of "port_security, qos" but I couldn't find one. On the controller node, we can see this log statement:- 2020-04-10 13:07:23.388678 | controller | + lib/neutron_plugins/ml2:populate_ml2_config:59 : iniset /etc/neutron/plugins/ml2/ml2_conf.ini ml2 extension_drivers port_security,qos It's clear from above log, qos is set properly but where exactly it's overwritten with just port_security or qos is removed is not clear to me. Any pointers where I can debug to solve this problem or how to set QOS correctly? [1]: https://review.opendev.org/#/c/717530/18 Regards, tpatil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 3

Re: [Release-job-failures] Release of openstack/puppet-aodh for ref refs/tags/16.2.0 failed
by Emilien Macchi 13 Apr '20

13 Apr '20

We have identified the issue and will propose patches today and it'll fix the release jobs. On Mon, Apr 13, 2020 at 8:56 AM <zuul(a)openstack.org> wrote: > Build failed. > > - release-openstack-puppet > https://zuul.opendev.org/t/openstack/build/816a2104b2c94b199eaab1288b64f1c7 > : POST_FAILURE in 2m 57s > - announce-release https://zuul.opendev.org/t/openstack/build/None : > SKIPPED > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Emilien Macchi

3 3

[cinder] feature freeze and FFEs
by Brian Rosmaita 13 Apr '20

13 Apr '20

I wasn't paying close enough attention to the "real life" calendar, and did not realize that we would be so short-handed on reviewers around the Feature Freeze, with a lot of people unavailable. So, I am granting Feature Freeze Exceptions to the following. To make it into Ussuri, these should be merged by noon UTC on Friday 17 April. https://blueprints.launchpad.net/cinder/+spec/sf-aa-support - looks good, but I really want to allow time for one of our A/A HA experts to take a final look https://blueprints.launchpad.net/cinder/+spec/copy-image-in-multiple-stores - this may need a minor revision, but otherwise looks OK https://blueprints.launchpad.net/cinder/+spec/nfs-volume-encryption - some questions have come up about testing this one. We should decide by mid-week whether it still looks good for Ussuri or not. https://blueprints.launchpad.net/cinder/+spec/macrosan-driver-supported - this patch includes adding support for some new functionality and hence is subject to the feature freeze; needs a minor revision and release note; third-party CI appears functional. Problems need to be addressed very early next week, or this may wind up slipping to Victoria. The following blueprint contains multiple patches that have all been approved. Two haven't been able to merge; they require a rebase and conflict resolution. I expect that they will all merge early next week, but technically they require an FFE (which is granted). https://blueprints.launchpad.net/cinder/+spec/unity-ussuri-features The following blueprints are not yet marked 'Implemented', but the outstanding work is not subject to the feature freeze (mostly verification of stable third-party CI and then marking drivers as 'supported' or 'unsupported', which by Cinder policy must be done by RC-1). I just want to mention them so no one freaks out about not having an FFE. (You don't need one.) https://blueprints.launchpad.net/cinder/+spec/add-sandstone-driver https://blueprints.launchpad.net/cinder/+spec/cinder-nimble-driver https://blueprints.launchpad.net/cinder/+spec/datera-driver-restoration https://blueprints.launchpad.net/cinder/+spec/ibm-gpfs-supported https://blueprints.launchpad.net/cinder/+spec/restore-unsupported-drivers If I missed anything, please apply for a FFE by the usual method, that is, an email with the subject '[cinder] FFE request' before 18:00 UTC on Tuesday 14 April.

1 1

[requirements][glance]FFE for python/glanceclient stable/ussuri bug fix
by Abhishek Kekane 13 Apr '20

13 Apr '20

Hi Stackers, We have released python-glanceclient 3.1.0 last week, however testing it with a recent glance feature we have found one important bug [1] which is fixed in master and backported to stable/ussuri branch [2]. I am requesting a FFE for this so that we can release python-glanceclient 3.1.1 with this bug fix. Kindly consider my request. [1] https://launchpad.net/bugs/1871674 [2] https://review.opendev.org/#/c/718551/ Thanks & Best Regards, Abhishek Kekane

2 1

[Glance] FFE for python/glanceclient stable/ussuri bug fix
by Abhishek Kekane 13 Apr '20

13 Apr '20

Hi Stackers, We have released python-glancecient 3.0.0 last week, however testing it with a recent glance feature we have found one important bug [1] which is fixed in master and backported to stable/ussuri branch [2]. I am requesting a FFE for this so that we can release python-glanceclient 3.0.1 with this bug fix. Kindly consider my request. [1] https://launchpad.net/bugs/1871674 [2] https://review.opendev.org/#/c/718551/ Thanks & Best Regards, Abhishek Kekane

1 0

[TripleO] Train cannot finish introspection due to ironic-agent fails
by Ruslanas Gžibovskis 13 Apr '20

13 Apr '20

Hi all, I have python-ironic-agent failing using standard template files. Reproducible with CentOS7 + repos: * base: mirror.hh.se * centos-ceph-nautilus: mirror.hh.se * centos-nfs-ganesha28: mirror.hh.se * centos-openstack-train: mirror.hh.se * centos-qemu-ev: mirror.hh.se * epel: mirrors.glesys.net * extras: mirror.hh.se * updates: mirror.hh.se getting an error while loading provisioning, attached in the image attached. Text is: [ 317.948425] system[1]: Starting Ironic Python Agent. ... python trace ... SyntaxError: Non-ASCII character '\xe2' in file /usr/lib64/python2.7/site-packages/psutil/__init__.py on line 997, but no encoding declared: see http://www.python.org/peps/pep-0263.html for details any suggestions except running it on c8? Should i consider: remove epel repo? I have it added when creating images... install python3? from which repos? install some additional package? Thank you -- Ruslanas Gžibovskis +370 6030 7030

2 1