Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-01-27
15:24:09 ade_lee__ sean-k-mooney, hey -- could you take a look at https://zuul.opendev.org/t/openstack/build/554ffdeb6c3a4cdc8c53c55dddd6c36e please and let me know whats missing?
15:24:33 ade_lee__ sean-k-mooney, this is for https://review.opendev.org/c/openstack/tempest/+/826580 as discussd the other day
15:26:12 sean-k-mooney sure ill take a look quickly and see if anything jumps out
15:26:24 sean-k-mooney you might need to set swap on the subnode too but ill check that
15:29:14 sean-k-mooney ade_lee__: actuly devstack may not have finished on the compute
15:29:41 sean-k-mooney ya ok
15:29:49 sean-k-mooney so on the compute devstack failed to install pip
15:29:57 sean-k-mooney https://zuul.opendev.org/t/openstack/build/554ffdeb6c3a4cdc8c53c55dddd6c36e/log/compute1/logs/devstacklog.txt
15:30:53 dmitriis sean-k-mooney: on 21.04 server tests are passing even with patches applied like it happens on the CI. Also not getting any failures in a 21.04 container locally with patches applied (with a rebase to master). Without a rebase I seem to be getting only "writer privilege escalation not allowed". So probably something in 21.10 libs is different and
15:30:53 dmitriis results in the breakage with locks. This hasn't happened recently so I'll try to explore further which update might have caused it.
15:31:14 dmitriis but at least one issue should be covered with rebasing
15:31:38 sean-k-mooney ack
15:31:58 sean-k-mooney if we dont see it in ci for now i would proceed with the rest of your work and we can keep an eye out for it
15:34:57 sean-k-mooney ade_lee__: this might just be an intermient failure on centos 8
15:35:17 sean-k-mooney so we shoudl recheck but ade_lee__ any plans to move that to centos-9-stream
15:35:28 sean-k-mooney if we dont do that this cycle we shoudl do it next cycle
15:35:41 ade_lee__ sean-k-mooney, maybe -- the relevant code seems to be here -- https://opendev.org/openstack/devstack/src/branch/master/tools/install_pip.sh#L121-L134
15:36:33 sean-k-mooney it looks like hte rax mirror just did not have a cenots8 compatiable packages
15:36:58 ade_lee__ sean-k-mooney, but yes, the plan is absolutely to move to centos-9-stream
15:37:10 sean-k-mooney the issue with 8 is its using python 3.6
15:37:17 sean-k-mooney which is now end of life upstream
15:37:35 sean-k-mooney so we are going to start to see pip not working on it sonner rather then later
15:37:45 ade_lee__ sean-k-mooney, the only problem right now is that fips+python+centos-9 is broken
15:37:56 ade_lee__ sean-k-mooney, but its getting fixed ..
15:38:25 sean-k-mooney so we might need to expand that to use pip form packages for cenos 8 stream too
15:39:09 ade_lee__ yup
15:40:10 sean-k-mooney https://github.com/pypa/pip/commit/0252c04a16cd93fe422cebf0b48453b559a2e404
15:40:17 sean-k-mooney pip droped support for 3.6
15:40:43 sean-k-mooney https://github.com/pypa/pip/blob/main/setup.py#L83
15:40:49 ade_lee__ sean-k-mooney, as soon as https://bugzilla.redhat.com/show_bug.cgi?id=1942527 is fixed, I plan to move all these to centos-9-stream
15:40:51 sean-k-mooney so ya that is the issue
15:41:23 sean-k-mooney this will break all centos 8 jobs so we should likely fix devstack to work around it for now
15:41:29 ade_lee__ which is supposed to happen maybe by next week ..
15:41:47 ade_lee__ yeah - I'll expand the conditional and see if that works
15:42:25 sean-k-mooney just have it check is_fedroa
15:42:27 sean-k-mooney drop the rest
15:42:39 sean-k-mooney and it shoudl be correct
15:43:04 sean-k-mooney we just need to ensure python3-pip is in the rpm files in devstack
15:43:05 ade_lee__ sean-k-mooney, ok - trying ..
15:44:03 sean-k-mooney which it is https://github.com/openstack/devstack/blob/master/files/rpms/general#L29
15:45:29 sean-k-mooney ade_lee__: by the way that is in post but has to go through qe ectra and then be published and buil in centos
15:45:39 sean-k-mooney so it will proably take more then a week
15:45:52 ade_lee__ sigh .. yeah
15:46:17 sean-k-mooney i mean it wont take that much longer there is a merge request up
15:46:21 sean-k-mooney we can still do it this cycle
15:46:38 ade_lee__ sean-k-mooney, oh we definitely want to do it this cycle
15:46:52 sean-k-mooney am so pip installed fine on one of the host
15:47:07 sean-k-mooney you can proably just recheck and see if you get looking and avoid rackspace
15:47:42 sean-k-mooney but i think infra/qa are aware of the centos 8 failure
15:48:01 ade_lee__ I'll throw up the dependent patch to avoid the issue for now
15:48:03 sean-k-mooney elodilles: ^ pip being broken on centos 8 on some clouds, is that new to you
15:48:17 ade_lee__ with my luck, I'll get rax three times in a row
15:51:05 sean-k-mooney ade_lee__: well staticially they used to be one of the larges ci providers so proably
15:53:48 ade_lee__ sean-k-mooney, seems like others have run into this -- https://review.opendev.org/c/openstack/devstack/+/779806
15:54:21 sean-k-mooney ya
15:54:39 sean-k-mooney i was conisdering addign a env var to disable it a few weeks ago
15:55:35 sean-k-mooney actully did i push my one
15:55:59 sean-k-mooney i have been using a modifed install_pip on one of my hosts
15:57:50 sean-k-mooney ade_lee__: https://termbin.com/k0x9
15:59:23 sean-k-mooney ade_lee__: i was modifying it to only install pip if it was not already there
16:00:38 ade_lee__ sean-k-mooney, makes sense -- anyways, for now added this as depends -- https://review.opendev.org/c/openstack/devstack/+/826714 - lets see how it goes
16:03:39 pmonteir Hi everybody! I was checking the "live_migration_downtime" parameter and I there's a function that supposedly configures the max_downtime, but this function (migrate_configure_max_downtime in https://opendev.org/openstack/nova/src/commit/ca03fe87371d8c13fc2895f8ff3e7e1ca88cfe79/nova/virt/libvirt/guest.py) calls another one which is just a "pass", has anyone ever used this parameter? I think it's not working properly,
16:03:39 pmonteir should this be implemented?
16:12:32 pmonteir ps: this function that's just a pass that I mentioned above, belongs to a "tests" folder (which makes me think that it shouldn't be used outside of a testcase).
16:15:25 opendevreview Balazs Gibizer proposed openstack/placement master: Add any-traits support for listing resource providers https://review.opendev.org/c/openstack/placement/+/826491
16:15:26 opendevreview Balazs Gibizer proposed openstack/placement master: Add any-traits support for allocation candidates https://review.opendev.org/c/openstack/placement/+/826492
16:15:26 opendevreview Balazs Gibizer proposed openstack/placement master: Remove unused compatibility code https://review.opendev.org/c/openstack/placement/+/826493
16:15:27 opendevreview Balazs Gibizer proposed openstack/placement master: Add microversion 1.39 to support any-trait queries https://review.opendev.org/c/openstack/placement/+/826719
16:17:55 gibi pmonteir: what you see is the libvirt test fixture we use for functional testing
16:18:30 gibi pmonteir: in production we use the real python binding for libvirt
16:18:32 gibi https://libvirt.org/python.html
16:18:44 prometheanfire uefi guests are failing to boot after upgrade to xena :| nova.exception.UEFINotSupported: UEFI is not supported
16:18:56 prometheanfire trying to find what in particular is triggering it
16:20:05 gibi pmonteir: so the the migrateSetMaxDowntime call is sent to libvirt
16:21:39 prometheanfire introduced in faad45b6323d7c52d35b7ccc45eacb5580b3b4d3
16:21:49 pmonteir gibi: ohhh, I think I got it know...
16:22:59 pmonteir but shouln't it be virDomainMigrateGetMaxDowntime then? Don't know if I'm looking at the right place here > https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateSetMaxDowntime
16:23:28 pmonteir I meant virDomainMigrateSetMaxDowntime*
16:24:45 gibi pmonteir: look at the naming rules at https://libvirt.org/python.html I think the python bindig call is generated to be MigrateSetMaxDowntime on teh domain object
16:25:14 gibi sorry migrateSetMaxDowntime
16:26:20 prometheanfire spatel: think this is a nova issue? (if so we should probably talk here) :D
16:27:16 spatel prometheanfire did you check your vm xml file and see what are the path you are seeing?
16:28:23 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: run nova tests with any--traits placement feature https://review.opendev.org/c/openstack/nova/+/825914
16:33:28 prometheanfire arch not specified, so hits the continue
16:33:46 prometheanfire spatel: the vm was shut down, so it's failing to boot on being defined
16:34:24 prometheanfire instance id is not listed in /etc/libvirt/qemu/
16:35:41 pmonteir gibi: I think I got it now, thanks!
16:35:54 prometheanfire if I had the xml it'd be easier to debug
16:35:55 gibi pmonteir: cool
16:44:34 gmann dansmith: gibi can you check this backport centos8 nodeset usage update for stable/xena https://review.opendev.org/c/openstack/nova/+/825930
16:45:02 gmann after that I will recheck on devstack patch and see if need to backport it for other stable too https://review.opendev.org/c/openstack/devstack/+/824290
16:45:21 dansmith gmann: by "check" you mean "rubber stamp" right?
16:45:37 gmann dansmith: yes :)
16:45:55 gibi gmann: looks good to me, but I only have the small stamp on stable
16:46:07 gmann oh did not know
16:46:08 dansmith gibi: any concern with me ninjaing?
16:46:15 gibi dansmith: go for it
16:51:04 prometheanfire I think nova uefi booting only works with redhat now
17:11:35 sean-k-mooney prometheanfire: it shoudl work on ubuntu 20.
17:11:40 sean-k-mooney 20.04

Earlier   Later