Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-23
14:50:21 lyarwood kashyap: so the new version constrats you suggested to avoid some known issues is what's causing us to be unable to test this prior to F31
14:50:46 kashyap lyarwood: Hmm; /me taps on the table and thinks ...
14:50:49 lyarwood sean-k-mooney: Libvirt 5.10 and QEMU 4.{3,2} I forget which
14:51:46 kashyap Seems like the diskimage-builder patch is at least being reviewed by the Right Person(tm).
14:52:08 sean-k-mooney lyarwood: i think ubuntu 20.04 will have libvirt 6.0 and qemu 4.2
14:52:33 lyarwood right
14:53:00 lyarwood sean-k-mooney: so support was introduced a while ago, kashyap just suggested we use a later version to include some bugfixes for blockCopy.
14:53:29 sean-k-mooney sure but this should not be a blocker right
14:53:36 lyarwood and using that later version is now causing issues testing this somewhere in the gate as the virt-preview repo has only built these packages for F31
14:53:39 sean-k-mooney we can test with the older versions?
14:53:57 lyarwood we can't if the constraints in code limit us to the newer versions
14:54:09 lyarwood otherwise we switch to the older blockRebase method
14:54:11 sean-k-mooney well the virt preview repo and fedora is not stble anyway
14:54:31 kashyap Yeah, FWIW, it's also the libvirt upstream suggested based on our use-case
14:54:48 kashyap sean-k-mooney: The reason for going with the current 6.1 and QEMU 4.2 (at least Ubuntu has this):
14:55:21 sean-k-mooney kashyap: i was tying to config the version did you find them
14:55:42 hrw Debian is at 5.0 and 3.1
14:56:03 sean-k-mooney hrw: ya we are not talking about min versions here
14:56:04 kashyap sean-k-mooney: See my second comment on line 286: https://review.opendev.org/#/c/696834/6/nova/virt/libvirt/driver.py@286
14:56:26 kashyap sean-k-mooney: The recommended version constants we're now using fix a disk image corruption bug.
14:56:49 sean-k-mooney right so we are defaulting to 5.10 for libvirt
14:57:02 sean-k-mooney and what version for qemu
14:57:16 lyarwood sean-k-mooney: we were
14:57:35 sean-k-mooney oh you bumped it to 6.1
14:57:40 lyarwood sean-k-mooney: now it's 6.1.0 for Libvirt and QEMU 4.3.0
14:57:47 sean-k-mooney so i dont think 6.1 will be in 20.04
14:57:58 sean-k-mooney or 4.3 i think they are using 4.2
14:58:11 sean-k-mooney so im not sure this will be a good base
14:58:15 kashyap lyarwood: I think you got the QEMU version wrong; now it is 4.2.0
14:58:29 sean-k-mooney ya i think it should be 4.2 as well
14:59:52 lyarwood ah!
15:00:08 sean-k-mooney can we use 6.0 for libvirt
15:00:10 kashyap :)
15:00:26 sean-k-mooney i also dont think 6.1 will by in ubuntu 20.04
15:00:33 kashyap sean-k-mooney: Let me check with the libvirt dev...
15:00:37 sean-k-mooney it might be in the cloud archive
15:01:42 hrw ubuntu focal is on 6.0 so it will stay at 6.0 unless uca
15:02:31 sean-k-mooney yep
15:03:01 efried_gone bauzas: +2
15:03:25 bauzas efried_gone: with love
15:03:39 bauzas go save the Openshift world
15:12:59 kashyap sean-k-mooney: lyarwood: Good news — we can lower the libvirt version from 6.1.0 to 6.0.0, thanks to lyarwood's "provide backing file explicitly" fix: https://opendev.org/openstack/nova/commit/0cfe9c81e3fe4d
15:12:59 kashyap sean-k-mooney: lyarwood: Good news — we can lower the libvirt version from 6.1.0 to 6.0.0, thanks to lyarwood's "provide backing file explicitly" fix: https://opendev.org/openstack/nova/commit/0cfe9c81e3fe4d
15:13:07 kashyap Added a comment in the change to that effect.
15:13:31 lyarwood kashyap: ack thanks
15:13:34 sean-k-mooney cool so we can use libvirt 6.0.0 and qemu 4.2.0 as the minium safely
15:14:20 sean-k-mooney the other way to test this would be via rdo and a centos job
15:14:26 sean-k-mooney centos 8
15:14:43 lyarwood do we have an AV repo in CentOS 8?
15:15:01 sean-k-mooney we should, im not sure but we definetly should
15:15:22 sean-k-mooney well in centos 8 or in rdo
15:15:39 sean-k-mooney we should not be testing with the defalut qemu and libvirt on centos
15:15:56 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Use virDomainBlockCopy to swap volumes when using -blockdev https://review.opendev.org/696834
15:49:54 hrw 97 tempest failures on aarch64 show that it is too early for that CI job
15:55:51 artom hrw, well, it's a start :) It'll probably remain non-voting and/or experimental for a bit, but those 97 failures can be chipped away at one by one
15:56:24 sean-k-mooney hrw: you could add it to the periodic pipe line
15:57:21 hrw ;D
15:57:24 sean-k-mooney hrw: but ya as artom siad the failures can be adressed one by one
15:57:42 sean-k-mooney its non voting anyway so it wont block the build
15:57:59 sean-k-mooney and its in a seperate pipleline alreday so the check pipepline wont wait for it
15:58:04 sean-k-mooney so it wont slow down the gate
15:58:40 sean-k-mooney it proably makes sense to not merge it untill its closer to working but you can always recheck the patch
15:58:53 sean-k-mooney if you do that however i would suggest disableing the other jobs
15:59:07 sean-k-mooney so as to not was gate resouces
16:01:47 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439
16:02:04 hrw ok, will reedit it then back
16:03:26 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: [WIP] CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439
16:04:25 hrw ok, my redeployment finished, can now teach tempest to use it
16:34:28 gibi /away
16:46:23 openstackgerrit John Garbutt proposed openstack/nova master: WIP: update quota apis with keystone limits and usage https://review.opendev.org/713499
16:55:27 hrw Took 15.46 seconds to build instance.
16:55:30 hrw now better
16:58:10 hrw uf. tempest even run with it
17:04:27 hrw - Passed: 0
17:04:27 hrw Ran: 353 tests in 34.9147 sec.
17:04:33 hrw so back to config
17:06:37 dansmith sean-k-mooney: gibi: we've got +2s pretty far up the stack, aside from one -1 from alex_xu on top of +2s, and then one -1 from gibi
17:07:05 dansmith sean-k-mooney: gibi: What do you think about dropping the -2 on the bottom patch to let some of those start to flow into the gate while Sundar fixes that one -1 from gibi?
17:07:20 sean-k-mooney dansmith: ya im trying to make my way through the stack today.
17:07:33 dansmith sean-k-mooney: okay you have +1s on a bunch of them too
17:07:46 sean-k-mooney i think the bottom patches i have looked at so far look sane to me
17:08:03 sean-k-mooney so i would be ok with droping the -2 and starting to merge those
17:08:24 sean-k-mooney i have not made it to the later patches in a while but if you feel comfortable with them then i would not be against droping the -2
17:14:26 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713845
17:14:26 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Replace ansible --sudo with --become in live_migration/hooks scripts https://review.opendev.org/713844
17:18:56 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713845
17:21:42 dansmith sean-k-mooney: okay let's see what gibi thinks
17:26:32 gibi dansmith sean-k-mooney: I think it is in a good enough shape to start merging the bottom
17:26:50 dansmith gibi: ack, will drop and make sure those that can merge are +Wd
17:27:00 gibi dansmith: ack, thanks
17:27:24 Sundar dansmith, sean-k-mooney, gibi: Thanks. FWIW, I have started responding to gibi's -1 comments.
17:27:41 gibi Sundar: ack. thanks
17:27:59 dansmith Sundar: cool, if and when you propose fixes, be sure to use git review -R to avoid rebasing the patches that may be in the gate below
17:28:57 dansmith gibi: alex_xu's concern on the "create and bind" is an existing problem not a new one, AFAICT.. I don't want to override his -1 but I don't think there's going to be anything we can or should do in that patch
17:29:13 dansmith gibi: can you have a look at his concern and my response and see if you agree? https://review.opendev.org/#/c/631244
17:30:34 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713036
17:31:27 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713845
17:32:44 sean-k-mooney dansmith: the whole multi create process cause extra issues.. if you set like --min 2 --max 4 and 1 fails but you end up with 3 running vms then that fine right
17:33:03 gibi dansmith: will check soon
17:33:33 sean-k-mooney so if we do fail to create a binding im not sure if we should be killing the full multi create or just that vm. ideally we woudl reshdule just the one vm that filed right

Earlier   Later