Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-29
21:09:41 JamesBenson melwitt: Yes, thanks, I saw that resource too. I have some older m1000e's that I got and just not sure if I should bother installing openstack or just have them as one off's for testing code.
21:10:22 melwitt ok. bauzas would know but he's off by now today. sean-k-mooney might know ^
21:48:26 openstackgerrit melanie witt proposed openstack/nova-specs master: Re-propose nova-audit spec for Victoria https://review.opendev.org/724430
22:37:51 melwitt gmann: heya, would you mind looking over this review? it looks sane to me but could use your api validation expertise https://review.opendev.org/407514
22:38:49 melwitt I'm not clear on whether it could possibly cause any backward compat issues. it means to only target the 500 error casd
22:38:51 melwitt *case
#openstack-nova - 2020-04-30
00:11:51 gmann melwitt: ack. I will check after finishing the testing of policy upgrade check.
00:17:57 melwitt awesome thanks
00:49:30 gmann gibi: bauzas : uploaded the upgrade check result of fresh devstack env on patch and those are as expected. tested 3 cases 1. policy file in json format with new defaults only bug scenario http://paste.openstack.org/show/792909/ 2. policy file with both defaults present http://paste.openstack.org/show/792910/ 3. policy file generated in yaml format - http://paste.openstack.org/show/792911/
01:05:42 gmann case4: no policy file - http://paste.openstack.org/raw/792913/
02:02:41 openstackgerrit xuyuanhao proposed openstack/nova master: the vms can not be force deleted when vm_status is soft-delete and task-state=deleting https://review.opendev.org/724260
03:12:28 gmann melwitt: tested locally and it lgtm from backword compatibility point of view and without microversion. but it is fixing more APIs than listed in commit msg so need test coverage for those.
03:52:18 melwitt gotcha thanks gmann
07:12:16 gibi good morning
07:13:44 PrinzElvis hi all
07:15:34 PrinzElvis https://www.irccloud.com/pastebin/KYjd5FUo/Rabbitmq_error_from_rocky_to_stein
07:29:55 gibi PrinzElvis: the only thing seems a bit strange to me is "{% endfor %}/{{ om_rpc_vhost }}" as that will be expanded to "//" as om_rpc_vhost is "/"
07:30:43 gibi PrinzElvis: but I'm no way expert on the rabbit config
07:44:53 PrinzElvis gibi: Ok I removed this "//" in my "transport_url = rabbit://openstack:2fe0525ec5db4f1b97d4d055527501ec@10.10.1.11:5672,openstack:2fe0525ec5db4f1b97d4d055527501ec@10.10.1.12:5672,openstack:2fe0525ec5db4f1b97d4d055527501ec@10.10.1.13:5672// "
07:45:33 nightmare_unreal artom: can you have another look at : https://review.opendev.org/#/c/715395/ . Thanks . Also i don't understand what can cause nova-live-migration zuul job to fail ? what does it even check ?
07:45:44 PrinzElvis gibi: and is work
07:47:28 gibi PrinzElvis: then I think the problem is in the ansible code you pasted
07:49:01 gibi gmann, dansmith: I'm +2 now on the policy upgrade check patch https://review.opendev.org/#/c/723645/
07:52:23 PrinzElvis gibi> this code is from stable/stein: https://github.com/openstack/kolla-ansible/blob/stable/stein/ansible/group_vars/all.yml
07:55:26 gibi PrinzElvis: I suggest to contact the kolla developers on #openstack-kolla channel
07:56:18 PrinzElvis gibi> Thks
09:46:32 openstackgerrit Stephen Finucane proposed openstack/nova master: nova-audit: Use cliff instead of homegrown argparse bleh https://review.opendev.org/724332
10:35:06 kashyap sean-k-mooney: Hope my response clarifies on some of our disagreements here: https://review.opendev.org/#/c/631154/7
10:35:40 kashyap sean-k-mooney: I wasn't assuming anything particular on your part, but asking to explicitly clarify with me what I meant
10:35:56 kashyap sean-k-mooney: As noted there, at one point in the past, QEMU *did* allow 'i440fx' + plain UEFI boot
10:36:13 kashyap (As noted in the spec comment, Nova doesn't allow that; we know that. Not debating that at all.)
10:36:28 kashyap Anyway, we can sort it out on the change. No rush to respond
11:43:10 artom nightmare_unreal, yeah, I'll look
11:43:26 nightmare_unreal Thanks :)
11:43:27 artom nightmare_unreal, nova-live-migration checks... live migration :)
11:43:49 artom It's unlikely to be related to your patch, most likely random failure
11:44:14 nightmare_unreal yes that's what I meant. WHy it was failing because I didn't touched anything with migration
11:49:29 openstackgerrit Jiri Suchomel proposed openstack/nova master: Add ability to download Glance images into the libvirt image cache via RBD https://review.opendev.org/574301
12:08:52 artom nightmare_unreal, somethings things fail :)
12:10:06 artom In this case looks like a server evacuation timed out: https://zuul.opendev.org/t/openstack/build/8ac593dc86074d128b16ae0796e9e458/log/job-output.txt#8481
12:11:51 lyarwood artom: it failed
12:12:13 lyarwood artom: the timeout is just because we are waiting for the instance to go to ACTIVE but it's always in ERROR
12:12:26 artom lyarwood, oh, right
12:12:49 artom In any case, it cannot possibly because of the changes to nova-manage heal_allocations :)
12:13:04 lyarwood '[' ERROR '!=' ERROR ']'
12:13:06 lyarwood erhm
12:13:31 lyarwood oh ignore that
12:14:03 lyarwood artom: but yeah sorry
12:14:06 lyarwood unrelated
12:22:32 lyarwood this looks like another VIF timeout issue, I wonder if we also need to remove the OVS ports etc before restarting the agents and attempting the rescue.
12:22:38 lyarwood evacuation even
12:25:29 sean-k-mooney lyarwood: you should not need too
12:26:04 sean-k-mooney we cenrtenly cant assume that will happen in a evacuate case
12:27:40 lyarwood well the host should be fenced in an evacuation
12:28:25 lyarwood https://review.opendev.org/#/c/723853/ - I was going to add that as a precondition FWIW
12:28:48 lyarwood but yeah I don't think that would actually help here
12:40:55 artom Who handles http://status.openstack.org/reviews/#nova ?
12:41:06 artom "Page refreshed at 2020-03-20 06:38:57 UTC"
12:41:09 artom Kinda stale ;)
12:41:24 gibi artom: I suggest to ask infra
12:41:54 gibi I've noticed the staleness of it but never get the time to dig around
12:42:01 sean-k-mooney i tink it updates automaticaly nightly
12:42:14 gibi it is just a looooong night :)
12:42:29 sean-k-mooney oh its 03 not 04
12:42:47 artom Yeah, this ain't Game of Thrones
12:42:49 sean-k-mooney adn the 20th not 30th
12:43:03 sean-k-mooney ya just misreda the date
12:43:55 sean-k-mooney i mix up numbers much less often then letters but it somethimes happens
12:54:07 kashyap Urgh
12:54:19 kashyap Rabit-Holes--
12:54:53 kashyap sean-k-mooney: I'm just reading your comment: right now 'i440fx' with UEFI *does not* work. I wrote to the OVMF maintainer to ask about what's the deal there
12:55:19 sean-k-mooney kashyap: i think it was just not implemented
12:55:22 kashyap sean-k-mooney: So, don't assume that: "it works with both" _today_. As I mentioned in my comment it was working at _one_ point_ in time...
12:55:29 kashyap sean-k-mooney: So, the core problem is this:
12:55:38 sean-k-mooney given its like 20 years old im not suprised it was not a priortiy
12:56:34 kashyap The 'i440fx' chipset does not have SMM emulation: hence Secure Boot is not possible with it. If someone adds SMM to 'i440fx', SB should work 'fine' for it.
12:56:43 kashyap (But indeed it's not a priority to do that)
12:57:05 sean-k-mooney kashyap: by the way im not assumeing ti works with both
12:57:08 kashyap I'll comment the rest on the change.
12:57:32 kashyap sean-k-mooney: You say on the change in the past OVMF_CODE.secboot.fd didn't work with 'i440fx'
12:57:38 kashyap That's of course correct -- it never wored
12:57:41 kashyap s/wored/worked/
12:57:59 sean-k-mooney yes the .secboot one did not
12:58:16 sean-k-mooney and the release note you quoted state that the OVMF_CODE.fd file did
12:58:20 kashyap The non-secboot.fd used to work in the past. Right now, it drops me directly to the UEFI shell.
12:58:36 kashyap sean-k-mooney: Yes, it did in December-2016. Today, it didn't. Still checking what's the state of it
12:58:57 kashyap There's only one responsive OVMF maintainer/developer that I know; and he's terribly overworked
12:59:05 sean-k-mooney well OVMF_CODE.fd is just uefi firmware
12:59:18 sean-k-mooney secure boot is an optional feature
12:59:33 sean-k-mooney it might be that the droped support form loadign the firmware form rom
12:59:49 sean-k-mooney i think pflash was not supported on i440fx
13:00:15 sean-k-mooney i tried to get uefi without secure boot wokking with the pc type a few times in teh past
13:00:22 sean-k-mooney but i have only had success using q35
13:00:42 sean-k-mooney using the ovmf binarys in ubuntu 16.04 and 18
13:00:45 sean-k-mooney .04
13:01:35 sean-k-mooney i have not really gone out of my way to get upstream copies or anything like that but i have had to check uefi stuff on 1-2 ocations in the past and just always ended up going to q35
13:02:44 sean-k-mooney anyway i think we can ignore that part of the spec as it really not relevent to chanign the default in nova
13:03:08 sean-k-mooney it is relevent for your secure boot spec but not this one
13:09:18 kashyap 1 sec; bbiab
13:10:19 kashyap sean-k-mooney: I've checked how UEFI / OVMF is built for Ubuntu and Debian and SUSE as part of some earlier work:

Earlier   Later