Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-01-27
14:32:33 dmitriis sean-k-mooney: tried with the previous (VPD) patch only https://paste.opendev.org/show/812404/
14:33:41 sean-k-mooney well a uuid is not an rfc1738 url
14:34:00 sean-k-mooney hum same issue with older fasteners
14:36:59 dmitriis sean-k-mooney: the other failures are odd to see because that same patch passed on CI https://review.opendev.org/c/openstack/nova/+/808199. Checking with older fasteners as well.
14:37:11 sean-k-mooney dmitriis: master seam to work ok for me
14:37:20 sean-k-mooney dmitriis: have you treid rebaseing all your patches
14:37:36 sean-k-mooney we might have fix this already on master and you patches might be missing it
14:37:46 dmitriis sean-k-mooney: ack, let me try that
14:53:35 bauzas sean-k-mooney: cool, interesting
14:53:41 bauzas thanks for the follow-up
14:54:36 sean-k-mooney bauzas: gibi by the way we likely need to have a dicussion about what to do about placment,os-traits and os-resouce-providres at some point
14:54:54 gibi sean-k-mooney: ack. I read the scrollback from the release channel
14:55:32 sean-k-mooney perhaps a ptg topic. we coudl start it on the ML or in an etherpad
14:55:58 gibi I do believe that os-traits being a separate lib helps for the other consumers like nova and neutron. So I would not want to merge that back to placement
14:56:27 gibi So I'm on the side to relax the testing and add a release step where we check that the placement is released with the latest os-traits
14:57:36 sean-k-mooney ya long term that is proably the most operator freindly too
14:57:56 sean-k-mooney it would be a lot of work to reabsorb os-trait into placment
14:58:26 sean-k-mooney since we woudl have to modify nova,neutron,cyborg and possibel others + the deployment tooling
15:01:27 sean-k-mooney gibi: i can look at relaxing the test and push a patch for people to consider
15:01:48 gibi sean-k-mooney: OK, thanks
15:05:06 sean-k-mooney i dont know if cdent or others are aroudn that shoudl review
15:05:17 sean-k-mooney are any of the placment core team actully still active
15:05:50 dmitriis sean-k-mooney: hmm, tried master locally, getting the same failures with locking. Tried master on a server machine (21.04) - no failures.
15:06:05 gibi sean-k-mooney: I think we only have those that are active in nova too
15:06:24 dmitriis will try a few more combinations
15:06:43 sean-k-mooney perhaps tetsuro? although i have not seen them in a while
15:07:11 sean-k-mooney ill add the patch to open discuss for next weeks meeting once i figure out what to do
15:07:22 gibi ack
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

Earlier   Later