a number of tests fail under ppc64el arch

As noted in the libvirt driver [1], we only test against x86 and x86_64. While this would be relatively easy to fix, the lack of a gate job means it will likely regress again in the future and also means we can't justifiably make this architecture as supported. I think the more likely issue is this:

  I'm marking this bug as severity:serious since your package has only
  Architecture:all binary packages, and should thus, in theory, build
  everywhere. Failure to build on ppc64el might indicate a serious issue
  in this package or in another package.

Setting Architecture to indicate support for x86 and x86_64 only would seem far more sensible to me.

[1] https://github.com/openstack/nova/blob/46899968619e4ea0ff2ab380977619bb29578d43/nova/virt/libvirt/driver.py#L572-L581

im reopening this and marking it as triaged

ppc64le has been supported with thrid party integration testing provide by the
IBM PowerKVM CI on ppc64el for years here is an example test run https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/68/767368/1/check/tempest-dsvm-full-focal-py3/ef10362/

redhat also ships version fo nova for ppc64el in our downstream product
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/release_notes/chap-introduction#Content_Delivery_Network_CDN_Channels

that use libvirt kvm on ppc64el starting with power8 in osp 13 i think and now support power9.

stephen is correct that we have no 1st party ci that covers ppc64el but i think its still ok to fix the unit test, the are more likely to regress yes but perhaps we can work with infra to see if we can use qemu to emulate ppc or see if any of our providers have ppc avaiable.

i know rackspace used to run a large amount of there cloud on ppc.