| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-10 | |||
| 08:44:50 | sean-k-mooney | thats doing an online data migration but its not doing a reshape | |
| 08:46:00 | gibi | the analogous call would be nova.virt.libvirt.driver.LibvirtDriver.update_provider_tree | |
| 08:46:37 | gibi | but that needs a hypervisor connection as far as I see | |
| 08:46:46 | sean-k-mooney | well yes an no that would update the provider i guess but it would do more then just run the reshapes | |
| 08:47:28 | sean-k-mooney | gibi: yes it need the resouce track and a bunch of other things that reuiqre not just a connection to libvirt but file access too | |
| 08:47:49 | sean-k-mooney | im pretty sure we need to check /sys for some things | |
| 08:48:31 | sean-k-mooney | like sev support? we need the compute nodes config for allocation ratio stuff at the very least | |
| 08:48:40 | gibi | sean-k-mooney: agree that update_provider_tree does more than what is needed for reshape | |
| 08:49:22 | gibi | I guess we need to see what are the bare minimum information to run each reshape codepath and see how can we provide that | |
| 08:51:01 | sean-k-mooney | the pcpu reshape would need the compute node cpu_shared_set and cpu_dedicated_set config options techincally vcpu_pin_set too | |
| 08:51:35 | sean-k-mooney | i think the vgpu reshape to have seperate RP per pGPU needs libvirt and the mdev type config options | |
| 08:51:59 | sean-k-mooney | gibi: if we proceeed with numa in placment that is going to need the host numa toplogy info from libfirt | |
| 08:54:22 | sean-k-mooney | gibi: this is the vgpu reshape https://github.com/openstack/nova/blob/b6f3d393aa5cb755f30fa70d4acc614c32216c99/nova/virt/libvirt/driver.py#L7757 | |
| 08:56:09 | sean-k-mooney | well actully _update_provider_tree_for_vgpu is the top level function we would be calling and _update_provider_tree_for_pcpu is the cpu one | |
| 08:58:02 | gibi | I see | |
| 08:58:32 | sean-k-mooney | _get_all_assigned_mediated_devices which is used in the vgpu reshape directly read the guest xml https://github.com/openstack/nova/blob/b6f3d393aa5cb755f30fa70d4acc614c32216c99/nova/virt/libvirt/driver.py#L6940-L6973 | |
| 09:35:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Don't allow "reserving" file-backed memory https://review.opendev.org/734658 | |
| 09:35:51 | openstackgerrit | Merged openstack/nova stable/ussuri: Add functional test for bug 1550919 https://review.opendev.org/731247 | |
| 09:35:51 | openstack | bug 1550919 in OpenStack Compute (nova) ussuri "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Lee Yarwood (lyarwood) | |
| 09:36:15 | stephenfin | bauzas: Can you look at https://review.opendev.org/#/c/733668 ? | |
| 09:36:54 | bauzas | stephenfin: ack, will do | |
| 09:37:23 | bauzas | gibi: sean-k-mooney: sorry was on a meeting, saw your discussion | |
| 09:38:04 | bauzas | yup, from a vgpu reshape perspective, we need to lookup the guest XMLs hence libvirt | |
| 09:38:13 | bauzas | (and just not do a DB check) | |
| 09:39:29 | openstackgerrit | Merged openstack/nova-specs master: Stop to use the __future__ module. https://review.opendev.org/732879 | |
| 09:51:04 | gibi | stephenfin: about https://review.opendev.org/#/c/734658 would it worth to add a reno too to communicate a future breaking change? | |
| 09:51:41 | stephenfin | gibi: Good idea. "upgrade" section? | |
| 09:51:51 | gibi | stephenfin: yeah | |
| 09:52:00 | stephenfin | Cool. Sec | |
| 09:52:17 | gibi | thanks | |
| 09:53:50 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Snapshot: offload glance upload in a native thread https://review.opendev.org/734776 | |
| 09:58:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Mark e1000e VIF as supported https://review.opendev.org/734777 | |
| 09:58:01 | stephenfin | sean-k-mooney: Can you sanity check that too, please? ^ | |
| 10:15:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Don't allow "reserving" file-backed memory https://review.opendev.org/734658 | |
| 10:15:27 | stephenfin | gibi: ^ | |
| 10:15:30 | stephenfin | as requested | |
| 10:16:30 | stephenfin | bauzas: Another (easier) one for your list https://review.opendev.org/#/c/734777/ | |
| 10:16:50 | bauzas | stephenfin: the exception one is a bit hairy, I need to make sure you don't forget anything | |
| 10:17:33 | sean-k-mooney | stephenfin: yep ill take a look shortly | |
| 10:19:14 | sean-k-mooney | stephenfin: did you check if we report hugepages in the host numa toplogy blob | |
| 10:19:23 | sean-k-mooney | when file backed memory is enabled | |
| 10:19:40 | stephenfin | I did not. What would be the implication? | |
| 10:19:53 | stephenfin | Just that we shouldn't do it? | |
| 10:20:02 | sean-k-mooney | we cant use filebacked memory and hugepages at the same time | |
| 10:20:15 | sean-k-mooney | but the numa toplogy filter has no idea if this config value is set | |
| 10:20:23 | sean-k-mooney | so it wont elimiate those hosts | |
| 10:20:31 | stephenfin | Hmm, good point. That'd be another good fix | |
| 10:20:33 | stephenfin | Lemme go look | |
| 10:20:52 | sean-k-mooney | so unless we dont report hugepages when there vailable if its set then we could get boot fails i think | |
| 10:21:02 | sean-k-mooney | ya seperate patch if its not done | |
| 10:25:41 | stephenfin | Does anyone know how to get a KCS taken down? https://access.redhat.com/solutions/3947641 | |
| 10:26:20 | stephenfin | For some daft reason, someone suggested people modify their DB rather than ask us to resolve a trivial bug :-\ | |
| 10:30:53 | stephenfin | ^ Ignore that. Intended for downstream IRC :) | |
| 10:37:56 | sean-k-mooney | damit is there way way we can just stop support form publishing kcs artical without having them go through tech review | |
| 10:38:09 | sean-k-mooney | ya i dont know but i reviewd https://review.opendev.org/#/c/734658/3 | |
| 10:41:02 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Don't allow "reserving" file-backed memory https://review.opendev.org/734658 | |
| 10:41:29 | stephenfin | sean-k-mooney: Addressed doc typo. Let's track the hugepage/total GB issue separately? | |
| 10:42:04 | sean-k-mooney | yep im cool with that we can just file a seperate bug that patch fixes the bug you have already filed | |
| 10:43:09 | bauzas | stephenfin: https://review.opendev.org/#/c/733668/2 got a -1 because of PEP484 usage be py3 specific | |
| 10:43:35 | gibi | stephenfin: thanks for the reno | |
| 10:44:17 | sean-k-mooney | bauzas: we are allowed to use py3 only syntax and feature on master | |
| 10:44:25 | bauzas | I know | |
| 10:44:28 | stephenfin | I was about to say :) | |
| 10:44:43 | sean-k-mooney | bauzas: and this is not enforce excpetion type it adding them | |
| 10:44:49 | stephenfin | personally, I think this patch is too invasive to backport | |
| 10:44:51 | bauzas | but then if we backport, we'll get linters shouting at us with no idea why | |
| 10:45:22 | sean-k-mooney | if we backport we need to drop the type info | |
| 10:45:36 | stephenfin | I think we're just going to have to live with that. I'll just drop the type info if I went back past stable/ussuri | |
| 10:45:40 | sean-k-mooney | we were holding of on adding it so we did not need to use the comment syntax | |
| 10:45:50 | stephenfin | yeah, exactly | |
| 10:45:58 | bauzas | stephenfin: then, just amend the commit msg and we're all good | |
| 10:46:25 | stephenfin | Sure. What should I add? | |
| 10:46:44 | bauzas | I don't want to refrain ourselves to use py3 styles, but I rather just want us to take 5 mins before writing it and consider backportability of such things | |
| 10:46:55 | sean-k-mooney | it took me a long time to be ok with the type on the right after all the c/c++/java/c# i wrote before learning python but im slowly gettin gused to it | |
| 10:46:55 | bauzas | stephenfin: just tell your decision | |
| 10:47:11 | sean-k-mooney | it seam like most lanaguges are converging on that order now | |
| 10:47:15 | bauzas | option A/ this bugfix isn't intended to be backported | |
| 10:47:34 | bauzas | option B/ if people feel brave enough to backport, there will be a necessary change | |
| 10:47:49 | bauzas | in other words, document your code :) | |
| 10:48:03 | stephenfin | Hmm, I _could_ but it does feel like stating the obvious | |
| 10:48:03 | sean-k-mooney | bauzas: so im ok with b if iall it is is removing :<Type> | |
| 10:48:19 | bauzas | sean-k-mooney: me too, just my point | |
| 10:48:28 | bauzas | again, it's just a static check AFAIK | |
| 10:48:30 | sean-k-mooney | i dont think that need to be in a comit or called out anywhere in the chagne | |
| 10:48:45 | sean-k-mooney | bauzas: well its not even a staitc check | |
| 10:48:51 | sean-k-mooney | the py2 jobs will fail | |
| 10:49:00 | sean-k-mooney | it wont parse correctly | |
| 10:49:02 | stephenfin | We'd saying if you use Py3 syntax and your commit message has "Closes-Bug" in it, add this boilerplate | |
| 10:49:32 | sean-k-mooney | stephenfin: i would really like to avoid that | |
| 10:49:38 | stephenfin | I mean, we don't say "this bugfix has o.vo implications so you're not allowed backport it" in a commit | |
| 10:49:40 | sean-k-mooney | we coudld but i dont see the point | |
| 10:50:11 | sean-k-mooney | stephenfin: bauzas we could update the contibutor guide or somehting to call it out i guess | |
| 10:50:11 | bauzas | sean-k-mooney: the point is that I'm afraid stable core reviewers could miss such tiny bits that would break | |
| 10:50:23 | sean-k-mooney | bauzas: but it would not pass ci | |
| 10:50:31 | sean-k-mooney | so it wont get merged at least | |
| 10:50:32 | bauzas | fortunately, in this specific case, agreed, CI won't run | |
| 10:50:37 | stephenfin | Fortunately, as sean-k-mooney points out, this will raise a SyntaxError on python 2.7 | |
| 10:50:38 | sean-k-mooney | but they might not know why | |
| 10:50:56 | stephenfin | heh, yeah 0:) | |
| 10:51:00 | bauzas | this | |