| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-29 | |||
| 16:05:43 | gmann | melwitt: on Tempest side it is still running because Tempest gate run 'integrated-gate-py3' template which is running all service tests. and that template is on openstack-zuul-jobs side so once i update that template then Tempest also will have single new job | |
| 16:06:00 | melwitt | thanks | |
| 16:06:54 | gmann | compute and service specific template are taken care by 722551 but integrated-gate-py3 template is not yet. | |
| 16:07:59 | gmann | best things we did in grenade side is we alias the grenade-py3 to new zuulv3 native job to avoid running legacy + new jobs during this migration. It is same zuulv3 jobs running twice with different name so will not cause issue. | |
| 17:09:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: objects: Add migrate-on-load behavior for legacy NUMA objects https://review.opendev.org/724381 | |
| 17:10:18 | stephenfin | dansmith: That's not complete, but when you've a chance can you sanity check to see if that's what you're after? ^ | |
| 17:10:57 | openstackgerrit | sean mooney proposed openstack/nova master: silence amqp heartbeat warning https://review.opendev.org/724188 | |
| 17:12:54 | artom | That just looks like stephenfin harpooned a dude coming at him | |
| 17:14:53 | sean-k-mooney | hehe you dont know what stephenfin gets up to on his runs | |
| 17:15:01 | sean-k-mooney | its one way to keep otheres away | |
| 17:15:27 | sean-k-mooney | i mean would you approch a person running with a harpoon | |
| 17:16:40 | artom | Depends | |
| 17:16:45 | artom | Am I a masochistic whale? | |
| 17:42:08 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] testing with force_legacy_port_binding workaround https://review.opendev.org/724387 | |
| 17:42:08 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] add workaround to disable multiple port bindings https://review.opendev.org/724386 | |
| 17:49:50 | sean-k-mooney | by the way how do people feel about ^ as a temproy workaround for this long standing issue while we figure out how to fully fix this | |
| 17:51:28 | sean-k-mooney | i think my other patches are still the wright approch https://review.opendev.org/#/c/602432/ and https://review.opendev.org/#/c/640258 but i have not looked at this in a year and was not planning to but i guess i can try to find time to look at this again | |
| 20:43:15 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645 | |
| 20:55:47 | gmann | gibi: i updated the upgrade check with more safer way to cover all cases how policy is initialized or not. I have added test also for that and waiting for grenade job result which run upgrade check. also I am preparing new devstack but some issue, please let me know if it run fine now on your env- https://review.opendev.org/723645 | |
| 20:56:26 | gmann | i mean with the policy file you showed in http://paste.openstack.org/show/792881/ | |
| 21:03:43 | JamesBenson | All: Does anyone know if Nova supports the Tesla M2050 or M2070 for vGPU? | |
| 21:08:16 | melwitt | JamesBenson: I don't know but here's the doc we have if you didn't already find https://docs.openstack.org/nova/latest/admin/virtual-gpu.html | |
| 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 | |