| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-29 | |||
| 16:00:04 | sean-k-mooney | https://github.com/redhat-performance/tuned/blob/master/profiles/cpu-partitioning/cpu-partitioning-variables.conf | |
| 16:00:25 | melwitt | gmann: I'm trying to understand a bit about how/why two grenade jobs would run on stable/ussuri (we don't have an example yet). and I looked at the tempest change and realized I don't understand why it ran two grenade jobs on the name change patch https://review.opendev.org/722551 could you please explain why two jobs run on openstack/tempest? I thought it would have been only one | |
| 16:01:01 | sean-k-mooney | tuned uses the the sysfs/cgroups interface to achive the same effect without the drawbacks | |
| 16:01:31 | spatel | sean-k-mooney: ohh good to know :) | |
| 16:01:37 | spatel | will look into that | |
| 16:01:54 | sean-k-mooney | normally i would jsut set isolated_cores=2,4-7 and not set no_balance_cores=5-10 | |
| 16:02:09 | sean-k-mooney | although no_balance_cores=5-10 would be useful for realtime hosts or ovs-dpdk | |
| 16:02:52 | spatel | Do i need to restart machine to set this values ? | |
| 16:03:54 | gmann | melwitt: sure. for nova stable/ussuri, it will be both job running if you recheck any ussuri backport (or testing patch) until 724189 is merged. this is because compute template in Tempest switched to new job (https://review.opendev.org/#/c/722551/3/.zuul.yaml@543) and nova stable/ussuri ./.zuul.yaml have old job also listed for irrelevant file | |
| 16:04:01 | sean-k-mooney | spatel: am i dont think so | |
| 16:04:16 | sean-k-mooney | you would on teh kernel command line but not with tuned | |
| 16:04:23 | gmann | melwitt: https://github.com/openstack/nova/blob/stable/ussuri/.zuul.yaml#L400 | |
| 16:04:39 | spatel | sean-k-mooney: yes kernel does require reboot but lets me test in tuned | |
| 16:05:14 | melwitt | gmann: sorry I mean as an aside, why did two jobs run on https://review.opendev.org/722551 ? I realized I didn't understand that | |
| 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: [WIP] add workaround to disable multiple port bindings https://review.opendev.org/724386 | |
| 17:42:08 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] testing with force_legacy_port_binding workaround https://review.opendev.org/724387 | |
| 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 | |