Earlier  
Posted Nick Remark
#openstack-nova - 2020-07-09
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
11:13:06 sean-k-mooney and also get once step closer to no more legacy jobs

Earlier   Later