| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-24 | |||
| 07:14:13 | openstack | Launchpad bug 1921073 in OpenStack Compute (nova) "[arm64][libvirt] firmware metadata files not found for arm64 on ubuntu 18.04" [Undecided,New] | |
| 07:15:14 | ricolin | Also launchpad and patch for focal arm64 libvirt issue I mentioned in https://review.opendev.org/c/openstack/nova/+/781210 | |
| 07:15:15 | ricolin | https://review.opendev.org/c/openstack/nova/+/782634 | |
| 07:19:35 | ricolin | stephenfin, gibi bauzas kashyap takashin lyarwood ^^^ | |
| 08:32:53 | hrw | morning | |
| 08:33:09 | hrw | does anyone uses nova on Debian 'buster'? | |
| 08:34:43 | hrw | I am trying to get it working again in Kolla. so far updated libvirt and libvirt-python to 7.0.0, installed 2020.05 qemu-efi-aarch64 firmware. This gave me nova passing further. | |
| 08:38:30 | ricolin | hrw, do you facing the same issue as I'm on Ubuntu 'bionic'? https://bugs.launchpad.net/nova/+bug/1921073 | |
| 08:38:32 | openstack | Launchpad bug 1921073 in OpenStack Compute (nova) "[arm64][libvirt] firmware metadata files not found for arm64 on ubuntu 18.04" [Undecided,New] | |
| 08:40:24 | hrw | ricolin: do yourself a favor. move to 20.04 | |
| 08:40:42 | hrw | ricolin: I solved that problem with qemu-efi-aarch64 from buster-backports | |
| 08:45:49 | ricolin | hrw, already moved and it works with 20.04 (https://review.opendev.org/c/openstack/devstack/+/708317) | |
| 08:47:44 | hrw | https://paste.debian.net/1190776/ is where I am now | |
| 08:49:23 | ricolin | hrw, for that case, I think this fix works https://review.opendev.org/c/openstack/nova/+/782634 | |
| 08:55:11 | hrw | hm. need to install with nova in developer mode then | |
| 08:57:41 | kashyap | sean-k-mooney: My internet connection last evening was super flaky here (they were, and still are, reworking roads here). | |
| 08:58:12 | hrw | ricolin: thanks. | |
| 08:58:20 | hrw | redeploying now | |
| 08:58:21 | kashyap | ricolin: Is this the one that was breaking the AArch64 CI? | |
| 08:59:11 | ricolin | hrw, I'm now looking at issue with delete volume backups in https://zuul.opendev.org/t/openstack/build/22b514f0bb2041d9b744cc0b37df8bf9 | |
| 08:59:25 | ricolin | kashyap, yes | |
| 09:00:34 | hrw | ricolin: step by step. I first want to get something running. | |
| 09:01:02 | hrw | already have 3 patches in kolla queue to get to current state ;D | |
| 09:01:41 | kashyap | ricolin: The "rb" --> read and binary, yeah? | |
| 09:02:04 | hrw | mgoddard: yes | |
| 09:02:08 | hrw | kashyap: yes | |
| 09:02:36 | ricolin | hrw, will check your kolla patches, maybe I'm facing same issues you ware faced! | |
| 09:02:47 | ricolin | kashyap, yes as hrw said:) | |
| 09:03:19 | mgoddard | hrw: me? | |
| 09:03:21 | ricolin | read and make all output from file in binary mode | |
| 09:03:28 | hrw | mgoddard: sorry | |
| 09:03:40 | kashyap | hrw: ricolin: Nice debugging. It's the Python-3 only thing, I guess? | |
| 09:04:37 | hrw | kashyap: I would say that it is old open() behaviour but maybe I am too long in py3 | |
| 09:05:12 | hrw | anyway it is probably usual bytes != chars thing | |
| 09:26:51 | bauzas | stephenfin: dansmith: lyarwood: I'm a bit afraid of loosing the RPC API bump merge to be in Xena, could you please look at this one ? | |
| 09:27:03 | bauzas | context : https://review.opendev.org/c/openstack/nova/+/761452 | |
| 09:37:09 | hrw | ricolin: https://review.opendev.org/c/openstack/nova/+/782634 got me closer ;D | |
| 09:37:32 | hrw | now it is at: 2021-03-24 10:36:23.905 7 ERROR nova.compute.manager [instance: ef71de37-1a2b-4f60-9fb4-d5942ffe7fc4] libvirt.libvirtError: unable to open '/sys/fs/cgroup/machine/qemu-1-instance-00000002.libvirt-qemu/': No such file or directory | |
| 09:39:11 | hrw | ricolin: +1 | |
| 10:47:32 | gibi | fyi, there is an intermittent unit test failure in the gate since https://review.opendev.org/c/openstack/nova/+/733627 merged. https://bugs.launchpad.net/nova/+bug/1921098 | |
| 10:47:34 | openstack | Launchpad bug 1921098 in OpenStack Compute (nova) "test_init_application_called_twice unit test fails intermittently" [High,Triaged] - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 10:47:54 | gibi | I'm will push a patch soon | |
| 11:08:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reset global wsgi app state in unit test https://review.opendev.org/c/openstack/nova/+/782691 | |
| 11:10:25 | gibi | stephenfin, lyarwood, bauzas: could you hit it please ^^ ? | |
| 11:16:11 | gibi | lyarwood, stephenfin if you know how to make it nicer then a follow up is appreciated https://review.opendev.org/c/openstack/nova/+/779446/1/doc/source/admin/hw-machine-type.rst#26 | |
| 11:17:57 | stephenfin | gibi: done | |
| 11:18:46 | lyarwood | aaaaaand done | |
| 11:18:59 | lyarwood | stephenfin: I'll sort that machine type doc issue out now | |
| 11:20:05 | stephenfin | lyarwood: It's not you - it's the theme | |
| 11:20:36 | stephenfin | There's a <div> with multiple <p> elements inside. The <p> elements are getting styled instead of the <div> | |
| 11:21:00 | stephenfin | gibi: | |
| 11:23:26 | gibi | lyarwood, stephenfin : if it cannot be fixed then fine :) | |
| 11:23:34 | gibi | btw, I have a micro nit also in https://review.opendev.org/c/openstack/nova/+/779479/3/nova/api/openstack/compute/rest_api_version_history.rst#1138 | |
| 11:24:10 | gibi | and thanks for the review on the unit test fix | |
| 11:24:11 | gibi | :) | |
| 11:25:58 | lyarwood | gibi: kk I can respin that | |
| 11:27:03 | lyarwood | ah nvm it's in the gate | |
| 11:27:18 | gibi | yeah, it is totally OK not to fix it | |
| 11:27:36 | gibi | I just wanted to note that the anchor generation works differently if the label starts with a number | |
| 11:27:52 | gibi | so we should prefer labels starting with a nonnumber for stable achors | |
| 11:28:02 | gibi | but this one will work for the case you added it | |
| 11:28:10 | gibi | as the anchor and the ref is in the same doc | |
| 11:28:17 | gibi | and sphinx magic helps | |
| 11:28:43 | lyarwood | it's in a different doc? | |
| 11:31:08 | gibi | it is generated by the same single sphinx run so the anchor is resolved properly | |
| 11:31:44 | gibi | but externally (ie, from the python-novaclient docs) you would need to refer to the numeric id of the ancor 'id80' but that is not stable | |
| 11:32:15 | gibi | sphinx generates proper labelled achnors if the label starts with a nonnumber | |
| 11:32:21 | lyarwood | kk | |
| 11:33:49 | openstackgerrit | Lee Yarwood proposed openstack/nova master: doc: Use a non-numerical anchor when referencing microversions https://review.opendev.org/c/openstack/nova/+/782696 | |
| 12:10:34 | openstackgerrit | Rico Lin proposed openstack/nova master: [Arm64][libvirt] Fix read bytes from json files https://review.opendev.org/c/openstack/nova/+/782634 | |
| 12:13:10 | hrw | can someone point me to doc about how nova/libvirt create cgroupv2 dirs? | |
| 12:26:55 | openstackgerrit | Lee Yarwood proposed openstack/nova master: doc: Use a non-numerical anchor when referencing microversions https://review.opendev.org/c/openstack/nova/+/782696 | |
| 12:35:14 | lyarwood | https://review.opendev.org/q/topic:bug/1917619 & https://review.opendev.org/q/topic:bug/1919487 could use reviews if anyone has bandwidth this week btw | |
| 12:36:29 | lyarwood | gibi / stephenfin ; https://review.opendev.org/c/openstack/nova/+/768466 also this that gets us closer to finally closing out our migration to native zuulv3 jobs | |
| 12:36:44 | lyarwood | it has taken ages to land all the required stuff in devstack and the ceph plugin | |
| 12:37:13 | stephenfin | lyarwood: ack | |
| 12:37:42 | stephenfin | bauzas: Looking at the RPC change now. Can we rename parameters in this change? | |
| 12:51:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Clarify value for 'hw:cpu_realtime' extra spec https://review.opendev.org/c/openstack/nova/+/782708 | |
| 13:23:28 | openstackgerrit | Merged openstack/nova master: docs: Add version{added,changed} notes to the hw_machine_type guide https://review.opendev.org/c/openstack/nova/+/779446 | |
| 13:24:31 | openstackgerrit | Merged openstack/nova master: docs: Add note about rescuing bfv instances with the 2.87 microversion https://review.opendev.org/c/openstack/nova/+/779479 | |
| 13:26:07 | openstackgerrit | Merged openstack/nova master: Reset global wsgi app state in unit test https://review.opendev.org/c/openstack/nova/+/782691 | |
| 13:27:12 | openstackgerrit | Merged openstack/nova master: docs: Add a resource limits guide https://review.opendev.org/c/openstack/nova/+/781433 | |
| 14:18:19 | bauzas | stephenfin: whoops, just saw your question | |
| 14:19:16 | bauzas | stephenfin: please, don't ask to change the instance_type for my change | |
| 14:19:43 | bauzas | I know about this fact, but changing the parameter for this change is not related to the needed behaviour ? | |
| 14:19:45 | bauzas | right? | |
| 14:30:56 | bauzas | stephenfin: actually, I do understand your concern | |
| 14:31:17 | bauzas | problem is, changing this param name would also need to modify the rpcapi module | |
| 14:31:25 | bauzas | and then the tests... | |
| 14:32:09 | bauzas | something saying : if ver==6.0: <use flavor for the param name>; <use instance_type> | |
| 14:32:35 | dansmith | I understand the desire for consistency, | |
| 14:32:45 | dansmith | but it's pretty late to be changing that, and it's been that way since forever | |
| 14:32:58 | dansmith | so I'm pretty meh about it, as you might expect :) | |
| 14:33:30 | bauzas | yeah :( | |
| 14:34:07 | bauzas | I honestly haven't thought about changing this before | |
| 14:34:20 | bauzas | and the fact I was redefining what would be the compute RPC | |
| 14:34:34 | bauzas | I just looked at what was changed | |
| 14:35:05 | bauzas | and now, looks like it's difficult for me to do it as we would need to change a lot of stuff here | |
| 14:35:11 | dansmith | the client can look at the version to determine which param to send, and the v5 proxy can just convert the old to the new | |
| 14:35:31 | dansmith | I don't really know how much test damage there will be, since those usually dispatch positionally | |