| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-07-09 | |||
| 09:32:21 | elod | stephenfin: unfortunately most of the time that detail is not filled in | |
| 09:34:53 | elod | stephenfin: so maybe it's worth adding that option :) | |
| 09:38:40 | hrw | morning | |
| 09:38:57 | hrw | https://1d9789842ee1597bfc07-adfe1c2e7945e3f1ebfe34ebeb2d7062.ssl.cf2.rackcdn.com/739800/2/check/kayobe-overcloud-centos8/c7c8c01/primary/kolla/nova/nova-compute.txt shows new nova issue | |
| 09:39:03 | hrw | 2020-07-08 16:44:28.078 6 ERROR nova File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/utils.py", line 65, in <module> | |
| 09:39:06 | hrw | 2020-07-08 16:44:28.078 6 ERROR nova 'avx512vbmi': os_traits.HW_CPU_X86_AVX512VBMI, | |
| 09:39:09 | hrw | 2020-07-08 16:44:28.078 6 ERROR nova AttributeError: module 'os_traits' has no attribute 'HW_CPU_X86_AVX512VBMI' | |
| 09:43:57 | frickler | hrw: guess you either need an intermediate os_traits release or use it from git instead pypi | |
| 09:45:48 | hrw | or update to 2.4.0 | |
| 09:48:47 | lyarwood | yeah FWIW tripleo hit this as well and they just needed to pull in the new os-traits release | |
| 09:48:55 | lyarwood | that's AFAIK anyway | |
| 09:49:35 | hrw | weird as image says 2.4.0 os_traits. | |
| 09:49:41 | hrw | something to debug then | |
| 09:52:36 | bauzas | stephenfin: jumping late on your Backport-Candidate question, could you please explain the usage ? | |
| 09:53:10 | lyarwood | hrw: do you have a link to the build logs showing that? | |
| 09:53:53 | bauzas | stephenfin: if it's for telling "I think it's a good change for backporting it", then anyone can just bakcport it and leave the stable cores to look at it | |
| 09:54:08 | bauzas | I don't really see what it's helping | |
| 09:54:38 | hrw | lyarwood: https://1d9789842ee1597bfc07-adfe1c2e7945e3f1ebfe34ebeb2d7062.ssl.cf2.rackcdn.com/739800/2/check/kayobe-overcloud-centos8/c7c8c01/ is zuul job log dir | |
| 09:55:04 | hrw | lyarwood: docker kolla/centos-binary-nova-compute:master image used | |
| 09:55:05 | bauzas | stephenfin: and like gibi said, we already have both launchpad tags and series for stable | |
| 09:55:41 | hrw | yaawang: I did docker run image, python3, import os_traits and HW_CPU_X86_AVX512VBMI was there so wondering what is going on | |
| 09:56:13 | stephenfin | bauzas: You can just do the backport, but that means you have to remember to do it there and then | |
| 09:56:32 | stephenfin | which might be easier said than done, particularly if there are merge conflicts | |
| 09:57:00 | stephenfin | this is just a way for (core) reviewers to say "I think this should be backported" | |
| 09:57:16 | stephenfin | or, conversely, I think this should not be backported | |
| 09:57:27 | stephenfin | and then the actual backport can take place later | |
| 09:57:56 | hrw | stephenfin: 'Backport Candidate' options in gerrit you discuss? | |
| 09:58:03 | stephenfin | hrw: correct | |
| 09:58:17 | hrw | I like them. Use them in kolla | |
| 09:59:10 | stephenfin | So do I. Maybe you can answer the questions gibi and bauzas have? Namely, what it gives over setting the series metadata in Launchpad | |
| 10:00:54 | bauzas | mmm, I see your usecase then | |
| 10:01:03 | bauzas | it would be for people wanting to know what to backport ? | |
| 10:01:11 | bauzas | but honestly, who ? | |
| 10:01:19 | hrw | stephenfin bauzas: when I have fix for stable/* I have to get it into master and then u->t->s->r if needed. so I send for master and then comment with "backport needed" and say which branches | |
| 10:01:33 | hrw | so later it is visible which patches need backporting | |
| 10:01:38 | openstackgerrit | XiaolinZhao proposed openstack/nova master: Add USB keyboard to support for MIPS architecture https://review.opendev.org/740213 | |
| 10:01:56 | bauzas | and who would say +1/-1 ? stable cores or master cores ? | |
| 10:02:16 | hrw | bauzas: in kolla we have just cores | |
| 10:02:17 | bauzas | either way, not saying I disagree, just it looks to me something we don't really *need* | |
| 10:02:21 | stephenfin | bauzas: I mean, if I was given a list of stuff to backport and promised reviews then I'd be happy to skim the backport candidate list occasionally | |
| 10:02:42 | stephenfin | and it's backport candidate - not actual backport - so normal cores | |
| 10:02:48 | stephenfin | though we could conceivably do both | |
| 10:03:13 | hrw | bauzas: as you have master and stable cores then I would say that master core suggests backport and stable core may accept/reject | |
| 10:03:24 | stephenfin | yeah, that ^ | |
| 10:03:37 | bauzas | okay I see, it's then just yet another process... | |
| 10:04:01 | bauzas | some people would use it, some not | |
| 10:04:07 | stephenfin | Yes and no. It's just another checkbox in the review dropdown | |
| 10:04:24 | stephenfin | Personally, everyone is using it in oslo land because it's really low friction | |
| 10:04:43 | stephenfin | Certainly less than going to Launchpad and setting metadata there (which I don't currently do because I didn't know I was supposed to) | |
| 10:05:02 | hrw | xiaolin: nice to see that some other arch follows aarch64 steps | |
| 10:06:15 | stephenfin | bauzas: If it means we remember to backport even a few more bugfixes then I think it's a good thing, personally | |
| 10:06:22 | stephenfin | lyarwood: Have you been looking at https://review.opendev.org/739349 ? | |
| 10:06:37 | bauzas | okay okay, let's discuss tonight anyway | |
| 10:06:46 | stephenfin | seems tangentially related to stuff you've been working on recently | |
| 10:09:21 | lyarwood | stephenfin: on my list | |
| 10:10:15 | xiaolin | hrw: thanks : ) We just started | |
| 10:11:51 | hrw | xiaolin: check https://review.opendev.org/#/c/538003/ as you need to add test cases | |
| 10:17:41 | xiaolin | hrw: Thanks :) I will add test cases | |
| 10:21:00 | hrw | xiaolin: it took some revisions before I got them right so prefer to point you at start | |
| 10:48:37 | xiaolin | hrw: Thanks so much | |
| 10:50:41 | xiaolin | hrw: do you have time to review https://review.opendev.org/#/c/740151/ | |
| 10:52:10 | hrw | sure | |
| 10:54:49 | hrw | xiaolin: you do not use pflash on mips? | |
| 10:55:05 | elod | lyarwood: thanks for the patch! \o/[4~ I've fast-approved it >>> https://review.opendev.org/#/c/739608/ | |
| 10:56:42 | hrw | xiaolin: done | |
| 10:56:55 | lyarwood | elod: awesome thanks :) | |
| 10:57:10 | xiaolin | hrw: our KVM only support rom now | |
| 10:57:15 | lyarwood | elod: https://review.opendev.org/#/c/740193/ should also fix stable/queens btw | |
| 10:59:07 | hrw | xiaolin: comment comment then | |
| 10:59:31 | elod | lyarwood: thanks! let's wait for Rocky patch to merge then I'll +2+W that too :) | |
| 10:59:50 | sean-k-mooney | lyarwood: what branches are teh migration test broken on | |
| 10:59:58 | sean-k-mooney | ah also rocky? | |
| 11:00:29 | sean-k-mooney | i notice many of the rechecks i kicked off for some of my backports failed yesterday on the live migration job | |
| 11:00:42 | sean-k-mooney | havent had time to look into it yet | |
| 11:01:32 | sean-k-mooney | ERROR] /tmp/devstack-plugin-ceph/devstack/lib/ceph:1029 Supported for Ubuntu Xenial, Bionic or Focal. Not supported for other releases. | |
| 11:01:38 | sean-k-mooney | thats what ye are fixing? | |
| 11:01:54 | lyarwood | yes | |
| 11:02:11 | lyarwood | just taken a while as there were other issues with the ceph plugin we had to fix first | |
| 11:02:16 | sean-k-mooney | cool ill recheck those after it merges so | |
| 11:02:26 | lyarwood | https://review.opendev.org/#/c/739694/ | |
| 11:02:44 | sean-k-mooney | are tehre any other issue i should be aware of for rocky and queens that i should wait for | |
| 11:03:00 | lyarwood | sean-k-mooney: rocky should be GREEN once that lands | |
| 11:03:10 | lyarwood | sean-k-mooney: and queens once https://review.opendev.org/#/c/740193/ lands | |
| 11:03:12 | lyarwood | AFAIK | |
| 11:03:42 | sean-k-mooney | ok i have a number of backport against rock and queens that im trying to get off my outgouing queue but i can wait another while | |
| 11:04:04 | lyarwood | yeah shouldn't be long now | |
| 11:04:11 | lyarwood | I also have a load of stuff I want to rebase once these land | |
| 11:04:49 | sean-k-mooney | oh will i need to rebase i can but then i have too update the commit ids in train which i can do but effort :P | |
| 11:05:10 | lyarwood | sean-k-mooney: and this is why I hate the cherry-pick lines ;) | |
| 11:05:25 | lyarwood | sean-k-mooney: and yes you need to rebase | |
| 11:05:29 | sean-k-mooney | hehe stephenfin aggrees with you | |
| 11:05:59 | stephenfin | self-inflicted pain | |
| 11:06:24 | lyarwood | yarp | |
| 11:06:28 | sean-k-mooney | i normally just avoid backporting acrooss more then one or two branches but its still less painful to do it upstream then downstream | |
| 11:06:54 | sean-k-mooney | if i do it donwstream i also have to clone the bug across multiple releases | |
| 11:10:20 | elod | actually i think the rebase is only needed if there's a merge conflict :-o | |
| 11:10:48 | elod | otherwise zuul takes care of it | |
| 11:11:11 | sean-k-mooney | elod: that is my understandign too | |
| 11:12:16 | sean-k-mooney | although sometiems we get weird behavior for example as with the new cherry-pick checker but normally the zuul speculative merge is suffiecent | |
| 11:12:22 | gibi | cores: can someone send this through? https://review.opendev.org/#/c/725163/ It would unblock the python-novaclient gate | |