| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-23 | |||
| 13:40:16 | sean-k-mooney | if you set hw:numa_nodes=1 you are basicaly saying i want a guest with 1 numa node and map it to a single host numa node. if you enbale hugepage or cpu pinning it imples hw:numa_nodes=1 | |
| 13:40:44 | sean-k-mooney | so with that toploy you would only be able to have at most 12 cores in a vm | |
| 13:41:00 | sean-k-mooney | but since you are not using numa for the vms it does not matter in your case | |
| 13:41:18 | jawad_axd | Okay.. | |
| 13:42:01 | sean-k-mooney | the numa feature are just for performance tuning | |
| 13:42:10 | sean-k-mooney | if you dont need them you can ignore them | |
| 13:42:26 | jawad_axd | I dont need them now, maybe in future. | |
| 13:59:17 | efried | nova meeting now-ish | |
| 13:59:49 | shilpasd | efried: hi | |
| 13:59:53 | efried | hello | |
| 14:03:50 | shilpasd | efried: dansmith: here added one question, https://review.opendev.org/#/c/694462/8/nova/db/sqlalchemy/api.py@2008 | |
| 14:04:16 | shilpasd | help me to understand 'any issues in setting 'volume_backed' field on the existing instances in the upgrade db script?' | |
| 14:05:13 | efried | shilpasd: dansmith is on vacation this week, and I'm not really qualified to discuss this one. It's Chinese New Year around now, so I'm not sure if alex_xu is around either. | |
| 14:05:23 | efried | IOW this may have to wait until next week to close on. | |
| 14:05:50 | shilpasd | efried: ok, thanks | |
| 14:06:13 | shilpasd | will wait for them | |
| 14:12:32 | sean-k-mooney | well that was quick :) | |
| 14:12:54 | shilpasd | :] (y) | |
| 14:13:18 | sean-k-mooney | looking at dansmith's suggestion i tened to agree that offloadign this to sql or adding a new field would be better | |
| 14:16:59 | sean-k-mooney | you could perhaps store the "is_volume_backed" info in the system_metadata table | |
| 14:17:24 | sean-k-mooney | that woudl avoid the need for a schema change but i think option 1 makes the most sense too | |
| 14:17:53 | sean-k-mooney | the only thing is we would have to keep the logic to handel old instance for a few release for FFU | |
| 14:18:06 | sean-k-mooney | but eventurlaly we could drop it | |
| 14:18:22 | shilpasd | sean-k-mooney: thanks for your opinion | |
| 14:18:38 | shilpasd | please clear me last point 'keep the logic to handel old instance for a few release for FFU' | |
| 14:19:39 | sean-k-mooney | we "support" skip level upgrade via Fast Forward upgrdes at lest downstream in OSP/tripleo | |
| 14:20:00 | sean-k-mooney | so if we add the code handel loading old instances and calulating the value | |
| 14:20:14 | sean-k-mooney | we need to keep it for a cople of release before we can remove it | |
| 14:20:21 | sean-k-mooney | and safly assume it will always be set | |
| 14:20:55 | sean-k-mooney | eventually that code for old instance can be removed but not for 2-3 releases | |
| 14:22:22 | shilpasd | for old instances will update 'volume_backed' based on bdms.volume and bdms.boot_index | |
| 14:23:38 | shilpasd | so still not clear why we need to keep code for couple of release, please elaborate further | |
| 14:23:48 | sean-k-mooney | its technically also stored in the request spec for instance created after rocky | |
| 14:24:12 | sean-k-mooney | FFU do not require the compute agents to start during the upgrade | |
| 14:24:35 | sean-k-mooney | so you can go form qeens to train without ever starting the agent untill you get to train | |
| 14:25:01 | sean-k-mooney | so unless you are groin to write an online data migration for this | |
| 14:25:10 | sean-k-mooney | which is not what dansmith was suggesting | |
| 14:25:48 | sean-k-mooney | if you take the approch of fixing it when you load the objects you need to keep that code for a few releases to not force peopel that are doing FFU to stop in ussuri | |
| 14:25:55 | sean-k-mooney | start the agent and have it fix the instnaces | |
| 14:27:05 | sean-k-mooney | so all i was really saying is eventaully we can remove that compatiablity code for old instnace but we will have to wait a releast or 3 | |
| 14:29:33 | shilpasd | ok, got it | |
| 15:09:28 | sean-k-mooney | by the way we can recheck stuff currently right | |
| 15:09:57 | sean-k-mooney | there is not specific gate blockers at the moment out side of the intermitenly failing jobs | |
| 16:03:43 | stephenfin | sean-k-mooney: not that I'm aware of, no | |
| 16:25:35 | KeithMnemonic | good morning melwitt: should i keep playing recheck roulette for that patch on stable/pike or wait to see if the issue with migration might be found? | |
| 16:28:22 | melwitt | KeithMnemonic: I dunno what the pass rate for that job is on stable/pike at this point but it seems pretty terrible. sean-k-mooney and I looked at it at bit yesterday and no clues yet what's going wrong | |
| 16:29:04 | KeithMnemonic | are you ok with me continuing rechecks to see if it passes eventually | |
| 16:30:24 | openstackgerrit | Merged openstack/nova master: nova-net: Make the security group API a module https://review.opendev.org/696746 | |
| 16:32:17 | melwitt | KeithMnemonic: yeah, you can | |
| 16:32:52 | KeithMnemonic | thanks | |
| 16:36:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unnecessary exception handling https://review.opendev.org/703973 | |
| 16:36:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused parameters https://review.opendev.org/703974 | |
| 16:36:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused nova-network objects https://review.opendev.org/697156 | |
| 16:38:36 | stephenfin | efried: You saw https://zuul.opendev.org/t/openstack/build/471f2388615e4ee5806a85e19b79569d ? | |
| 16:38:42 | stephenfin | Have you a patch up to address that yet? | |
| 16:38:53 | stephenfin | Seeing as you were attacking them in a piecemeal fashion? | |
| 16:39:26 | efried | stephenfin: I hadn't seen that. I can throw out a patch quick... | |
| 16:39:34 | sean-k-mooney | melwitt: i got side tracked with backports so i did not look at it properly so ill try to do it today | |
| 16:39:48 | stephenfin | efried: if you could, that'd be good, yup :) | |
| 16:39:52 | melwitt | thanks sean-k-mooney | |
| 17:12:40 | openstackgerrit | Merged openstack/nova master: Remove remaining Python 2.7-only dependencies https://review.opendev.org/698895 | |
| 17:15:19 | deke997 | Hey guys | |
| 17:15:34 | deke997 | I need to change how the guest pci addresses are generated. I have been trying to edit the config.py and driver.py files to add this functionality, but I cannot find the relevant code in the files | |
| 17:35:36 | stephenfin | deke997: What are you trying to achieve? | |
| 17:38:09 | deke997 | So I have a unique multi-function pci device that only works properly in the VM if the both devices are in the same slot but different functions. Like 0000:00:05.0 and 0000:00:05.1 | |
| 17:38:36 | deke997 | by manually editing the libvirt.xml file, I verified that it works properly in the VM when set up like that | |
| 17:39:17 | deke997 | However, the libvirt.xml file is now generated automatically by nova, and by default it puts the devices in separate slots like: 0000:00:05.0 and 0000:00:06.0 | |
| 17:40:49 | deke997 | So I want to change that behavior so that when I have a pci device that is passed through, it will pay attention to whether 2 devices were in the same slot with different functions on the host machine, and if so, it will repeat that behavior in the VM | |
| 17:47:19 | deke997 | stephenfin my understanding is that the xml file generation is handled by driver.py and config.py, but I cannot find the specific areas that deal with generating the guest pci address | |
| 17:47:29 | stephenfin | I'm trying to root that out at the moment | |
| 17:48:22 | yoctozepto | deke997: btw, is the device in question a secret or can you shed some light on it? | |
| 17:49:53 | sean-k-mooney | deke997: we dont do all the generation in nova | |
| 17:50:16 | sean-k-mooney | we actully leave it up to libvirt to assign the guesst pci adress and as a result define the toplogy | |
| 17:51:38 | sean-k-mooney | deke997: i have a backloag item to modify how that works for other reasons in the futre as i want o model 1 pci root complex per numa node to optimize how devices are exposed to vms | |
| 17:52:35 | sean-k-mooney | but it sould like you need to detect that the device is a multi fucntion device and then we would need to explcitly stat generating the toplogy and assing pci address in the guest to enable use to expose the device as a multi function device to the guest | |
| 17:52:58 | sean-k-mooney | deke997: this would be well into the catagory of a spec not a bugfix in my view | |
| 17:53:51 | sean-k-mooney | we might be able to skip the adress assignmentand still delegate that to libvirt but indicate that the device are both part of a multi function device but we would have to explore that to confirm | |
| 17:53:51 | deke997 | sean-k-mooney I see. This sounds like a fun project to work on. In the meantime, however, I have to find a solution that will let me get my VMs up | |
| 17:54:38 | deke997 | libvirt has a multifunction=on setting too | |
| 17:55:04 | sean-k-mooney | how to you request and whitelist the device at present | |
| 17:55:17 | sean-k-mooney | i assume you are using the pci whitelist and a flavor alias | |
| 17:55:21 | deke997 | yes | |
| 17:55:30 | deke997 | but I have to use a separate alias for each function | |
| 17:55:31 | sean-k-mooney | and you have 2 aliase right | |
| 17:55:35 | sean-k-mooney | one for each funciton | |
| 17:55:41 | sean-k-mooney | ya | |
| 17:55:57 | deke997 | We could add a multifunction alias type | |
| 17:56:07 | sean-k-mooney | so how are you ensuring the two VF/PF come form the same device on the hsot | |
| 17:56:29 | sean-k-mooney | deke997: we could add a tage but unless we can adress ^ | |
| 17:56:37 | sean-k-mooney | we have bigger problems | |
| 17:56:44 | deke997 | right now, I am just using all of them, so it's not an issue haha | |
| 17:57:12 | sean-k-mooney | so you have only 1 device on the compute node and your booting 1 vm that use all the fucntion form that device | |
| 17:57:27 | deke997 | yes that's what I have set up for testing | |
| 17:57:42 | sean-k-mooney | ya in that specific case you whave worked around that issue | |
| 17:57:49 | deke997 | But in the libvirt XML it is very easy to see which devices from the host were passed through | |
| 17:57:58 | deke997 | and match them | |
| 17:58:02 | sean-k-mooney | this has come up in the context of gpus in the past | |
| 17:58:21 | sean-k-mooney | the GPU and audio contoler are usally 2 differnt pci endpoint on the same device | |
| 17:58:48 | sean-k-mooney | at pressent we dont have a way to passthough both form the same card and ensure they are form the same device | |
| 17:59:51 | sean-k-mooney | deke997: form a nova point of view you would basically want ot have an alsi that can refernce a second alias and request both as a pair | |