Earlier  
Posted Nick Remark
#openstack-nova - 2021-09-23
19:23:15 lyarwood kashyap: https://zuul.opendev.org/t/openstack/build/0f9c492eb1f84c1fbde643a94896c878/log/controller/logs/screen-n-cpu.txt?severity=4#24297 - for the morning, can you take a look at this? I'll also ask in #virt. I'm seeing it on centos-8 stream CI runs after a while and instance creation starts failing. Doesn't appear to be due to memory pressure but I might be missing something.
20:57:35 ade_lee lyarwood, ping - hey - how familiar are you with the cryptsetup?
20:58:22 lyarwood ade_lee: yeah I know my way around, is this about test failures?
20:58:28 ade_lee lyarwood, specifically, I have a tempest test that is failing under fips
20:58:33 ade_lee yup
20:58:36 ade_lee https://zuul.opendev.org/t/openstack/build/86cd01338d4a47d1854776b52d696ec9/log/controller/logs/screen-n-cpu.txt#58389
20:59:51 ade_lee it seems the os-brick is calling cryptsetup here which is failing because cryptsetup is using plain encryption and that uses ripemd160 by default -- which is invalid under fips
21:00:27 lyarwood ade_lee: tbh plain cryptsetup encryption has been deprecated for a while now
21:00:44 lyarwood ade_lee: so in terms of getting it to work here with FIPS I'm not entirely sure it's worth the effort
21:01:18 ade_lee lyarwood, ack - thats what I was thinking too -- wanted to confirm that we just wanted to skip the test
21:01:23 lyarwood https://github.com/openstack/os-brick/blob/4f63dd045ca07f66003d1ccbbb19423ee91cf926/os_brick/encryptors/cryptsetup.py#L137-L145
21:01:54 lyarwood the only reason we haven't removed it yet is because of the forced retype in cinder
21:02:03 lyarwood and all of the fun that brings to the table
21:02:22 ade_lee yup - I was just reading your note before :)
21:03:00 ade_lee ok -- so then this is a caveat we'll need to call out in case someone is updating their system to use fips
21:03:33 ade_lee if you have any old volumes , you need to retype them
21:04:13 lyarwood ack yeah
21:05:20 ade_lee lyarwood, what about this then -- https://zuul.opendev.org/t/openstack/build/fdf2ddc92ae64021a1386b027c7eebcf/log/controller/logs/screen-c-vol.txt#16290
21:06:53 opendevreview Lee Yarwood proposed openstack/nova master: Add regression test for bug #1943431 https://review.opendev.org/c/openstack/nova/+/810755
21:06:54 opendevreview Lee Yarwood proposed openstack/nova master: compute: Update volume_id within connection_info during swap_volume https://review.opendev.org/c/openstack/nova/+/807025
21:06:54 opendevreview Lee Yarwood proposed openstack/nova master: fup: Move _wait_for_volume_{attach,detach} to os-volume_attachments https://review.opendev.org/c/openstack/nova/+/810775
21:06:55 opendevreview Lee Yarwood proposed openstack/nova master: fup: Refactor and simplify Cinder fixture GET volume mock https://review.opendev.org/c/openstack/nova/+/810776
21:07:05 lyarwood ade_lee: you can ignore that
21:07:37 ade_lee lyarwood, eh? isn't it causing the test to fail?
21:07:45 lyarwood ade_lee: That's just an initial check of the format of the device, if it's not LUKS we reformat.
21:08:17 lyarwood it's not failing because of that
21:08:20 lyarwood trace req-e52cdd22-a649-4134-9a83-75b41fc5f2d3
21:08:29 lyarwood the request continues, it's just poor logging from os-brick
21:09:37 ade_lee lyarwood, seems like the cryptsetup isLuks is failing coz of "Running in FIPS mode.\nCommand failed with code -1 (wrong or missing parameters)."
21:11:00 ade_lee lyarwood, not sure if thats because its not a luks device and we need to reformat or if the command simply wont work under fips
21:12:14 lyarwood $ sudo cryptsetup isLuks --verbose /dev/vda
21:12:14 lyarwood Command failed with code -1 (wrong or missing parameters).
21:12:29 lyarwood Yeah the second part is what we see for unencrypted disks
21:13:48 lyarwood the rest of the flow completes
21:14:21 lyarwood there's another error when trying to use multipathd but again that looks like a poorly logged issue in os-brick and nothing to do with fips
21:14:24 lyarwood Sep 08 17:16:49.575982 centos-8-stream-rax-dfw-0026368401 cinder-volume[109619]: INFO cinder.volume.manager [None req-e52cdd22-a649-4134-9a83-75b41fc5f2d3 tempest-TestEncryptedCinderVolumes-1784657899 None] Created volume successfully.
21:16:04 lyarwood but that said
21:16:05 lyarwood 2021-09-08 17:21:22,863 117508 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''}... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/NoyUrXJvjHTTbNBDCCkifIsv)
21:16:13 lyarwood ^ that's dumped when we fail the test
21:16:20 lyarwood so the guestOS didn't boot
21:22:50 lyarwood ade_lee: Yeah this is weird, the volume creation looks fine but there's nothing being logged to the console of the instance
21:23:01 lyarwood ade_lee: You might want to ask the Cinder folks to look at this tbh
21:23:31 lyarwood from a Nova POV the instance boots correctly so the disk is at least currently encrypted with the expected passphrase etc
21:23:40 lyarwood correctly*
21:24:22 ade_lee lyarwood, ack thanks for looking. it is weird.
#openstack-nova - 2021-09-24
00:26:32 opendevreview melanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963
06:27:55 frickler good morning nova, it seems you are running the l-c job in gate as non-voting, which doesn't make sense to me, see e.g. https://review.opendev.org/809955
07:31:06 bauzas good Friday, Nova
07:31:26 bauzas frickler: tell me, we had issues with this job due to some dep
07:32:04 bauzas frickler: saw the mailing thread from gibi ? can find it if you want
07:36:08 bauzas actually, the problem is on placement, not nova
07:39:52 elodilles well, the problem is there in several projects
07:40:05 bauzas elodilles: I don't disagree
07:40:17 elodilles bauzas: good to hear that :)
07:40:33 bauzas but I'd somehow appreciate that we could only make the job non-voting only when needed
07:40:56 bauzas for nova, ussuri and later provide decorator>=4.0.0
07:40:57 elodilles and nova has it too in ussuri and older branches
07:41:33 bauzas oh, strange https://github.com/openstack/nova/blob/stable/ussuri/lower-constraints.txt#L21
07:41:35 bauzas oh shit
07:41:45 bauzas 22 to 24 is 3 releases
07:42:05 bauzas xena being the 24th, ussuri is 4 releases older
07:42:13 bauzas I forgot about victoria :D
07:42:33 bauzas probably the effect of not having the PTG physically located for the first time :)
07:42:54 elodilles anyway, gibi has a solution, which actually solves the situation: https://review.opendev.org/c/openstack/nova/+/810461
07:43:52 elodilles maybe we should use that one directly and not merge the 'set l-c as non-voting' patch (which meant to be as 'temporary')
07:44:54 bauzas maybe
08:01:17 gibi morning
08:10:45 kashyap lyarwood: Morning; that error about "Could not allocate dynamic translator buffer" -- I recall seeing it in the past (in OpenStack CI) -- it was due to out-of-memory mostly
08:30:49 lyarwood ACK, just getting my haircut now, I'll look again at the memory tracking log in the job when I get back
08:40:04 kashyap Have a good one
09:24:31 bauzas gibi: does that ring a bell to you if I say that when the virt driver returns a list of inventories, we don't remove the existing RPs that are no longer used ?
09:24:44 bauzas context : https://bugs.launchpad.net/nova/+bug/1944031
09:25:48 bauzas hmmmm, looking at https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8226
09:26:10 bauzas we update the provider tree
09:26:28 bauzas but I guess if we have resource providers, we don't verify whether they're still used
09:47:14 opendevreview Pierre Riteau proposed openstack/nova master: Create empty pcpuset for unpinned instances https://review.opendev.org/c/openstack/nova/+/810849
10:11:17 gibi bauzas: hm, it could be that we never had to delete any RP before VGPU move to its own RP
10:11:29 gibi from nova-compute
10:11:36 gibi so we might missed that case
11:06:03 opendevreview Balazs Gibizer proposed openstack/nova master: Reproduce bug 1944759 https://review.opendev.org/c/openstack/nova/+/810763
11:14:55 opendevreview Stephen Finucane proposed openstack/nova master: tests: Walk database migrations in correct order https://review.opendev.org/c/openstack/nova/+/810291
11:14:55 opendevreview Stephen Finucane proposed openstack/nova master: db: Add migration to resolve shadow table discrepancies https://review.opendev.org/c/openstack/nova/+/805738
11:14:56 opendevreview Stephen Finucane proposed openstack/nova master: tests: Address some nits with database migration series https://review.opendev.org/c/openstack/nova/+/810856
11:14:56 opendevreview Stephen Finucane proposed openstack/nova master: tests: Silence noise from database tests https://review.opendev.org/c/openstack/nova/+/810857
11:41:52 opendevreview Lee Yarwood proposed openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519
12:05:23 gibi sean-k-mooney: do you remember where we are with mixing numa aware live migration with sriov live migration? Does src_compute(PF-numa0) -> dest_compute(PF-numa1) works?
12:05:42 gibi I do remember that we had issues but I don't if we solved them or just punted them for later
12:06:14 gibi and I only have lab nodes where both PF on numa1 so I cannot test it
12:10:10 sean-k-mooney gibi: yes it should
12:10:53 sean-k-mooney although most of the testing i did was with nic that did not report numa affinity
12:11:30 sean-k-mooney but i did force cross numa migration viat the cpu_dedicated_set and test that with sriov
12:12:06 sean-k-mooney but i would have been using the prefer policy effectivly by relaying on the fact my nics did not report numa affinity
12:12:42 sean-k-mooney gibi: you can try testing it with the prefer policy in your case
12:13:14 sean-k-mooney the ohter way to test it is technially the numa filed in /sys is writable
12:13:25 gibi hm, interesting :D
12:13:29 sean-k-mooney so if you echo 0 into the file and restart libvirt ...
12:13:42 sean-k-mooney i have done that in the past to fake it too with my hardware
12:13:59 gibi OK, I can try that, thanks for the idea
12:14:26 opendevreview Lee Yarwood proposed openstack/nova-specs master: Repropose flavour and image defined ephemeral storage encryption https://review.opendev.org/c/openstack/nova-specs/+/810867
12:14:27 opendevreview Lee Yarwood proposed openstack/nova-specs master: Repropose Add libvirt support for flavor and image defined ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/810868

Earlier   Later