| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-31 | |||
| 13:17:48 | sean-k-mooney | zigo: Uggla can correct men if im wrong but it should not need any config changes form using the backend without this feature | |
| 13:20:18 | sean-k-mooney | zigo: as far as im aware, your installer should not need to do any config on the manilla side and the only config change needed on nova are the manilla keystone auth parmaters https://docs.openstack.org/nova/latest/configuration/config.html#manila | |
| 13:21:08 | sean-k-mooney | we have only one manila specific option https://docs.openstack.org/nova/latest/configuration/config.html#manila.share_apply_policy_timeout | |
| 13:24:34 | carloss | zigo: ++ on sean-k-mooney's info. No additional configuration is needed in Manila. You would only need to have the backend properly configured as in any deployment other deployment, create a share and provide it during the nova attachment process, then nova and manila will do the rest for you (creating access rules, locking the share, locking the access rules and so on) | |
| 13:26:11 | sean-k-mooney | if your using the generic driver the main limiation is the share network needs to be routeable form the compute nodes | |
| 13:26:35 | sean-k-mooney | basically meaning it should be a neutron external network unlss floating ips work with manilla? | |
| 13:27:18 | Uggla | Yes only a manila section like the one from cinder but with name [manila] | |
| 13:28:15 | Uggla | so nova could get the enpoint + cred to access manila. | |
| 13:28:51 | sean-k-mooney | Uggla: i notcied we dont seam to have a tempest job for this in nova yet | |
| 13:29:03 | sean-k-mooney | or at least i didnt see this enabled in any of our exsitign jobs | |
| 13:29:10 | sean-k-mooney | do you have patches for that still pending? | |
| 13:29:42 | Uggla | yep I know and I'm guilty about it. I worked on them, but did not complete them yet. | |
| 13:29:49 | sean-k-mooney | it would be nice ot test cephfs in our ceph job and the generic driver with lvm in one of the ohters | |
| 13:29:51 | sean-k-mooney | ack | |
| 13:30:41 | sean-k-mooney | Uggla: well you did a lot last cycle. i was more asking to see if we could provide a refence to zigo of devstack cofniguration for ceph and nfs via cinder lvm | |
| 13:30:52 | sean-k-mooney | so they could take a look at how it works | |
| 13:31:08 | Uggla | sean-k-mooney, but there are discussion to have this effort done by the manila team. | |
| 13:31:22 | Uggla | or part of the effort. | |
| 13:31:36 | sean-k-mooney | it could be but we should be testing it in our jobs too | |
| 13:32:26 | Uggla | Of course I can provide zigo how to configure with devstack, so he could transpose to his configuration. | |
| 13:32:27 | sean-k-mooney | i dont think we need new jobs in nova just our existing jobs shoudl be tweeked | |
| 13:32:52 | sean-k-mooney | Uggla: ya i think that would help | |
| 13:33:25 | Uggla | btw there is a fn job with the sdk which is doint minimal testing against tempest. | |
| 13:33:50 | Uggla | s/doint/doing | |
| 14:21:10 | zigo | sean-k-mooney: If I'm going to use virtio-fs, that's precisely because I do not want to use the generic driver. | |
| 14:23:09 | zigo | What I don't get though, is if I'm using the "normal" cephfs driver, I do not want my users to be able to use cephfs direct connection from their VMs. | |
| 14:23:22 | zigo | For us, the Ceph backplane is *not* accessible from the VMs. | |
| 14:23:30 | zigo | (or purpose, for security reasons). | |
| 14:23:36 | zigo | So is there a way to desactivte it? | |
| 14:28:40 | zigo | Uggla: ^ | |
| 14:29:19 | sean-k-mooney | zigo: you can deploy your ceph so that there is no routeablity form the vm subnets | |
| 14:29:31 | sean-k-mooney | but there is routablity on the compute nodes | |
| 14:29:34 | zigo | That's the case already. :) | |
| 14:30:32 | zigo | But then, the API will be still available, I was hoping for it to say "404: cephfs API not activated, please use virtio-fs instead" or something ... | |
| 14:32:06 | sean-k-mooney | no | |
| 14:32:14 | sean-k-mooney | because manilla does not know about virtiofs | |
| 14:32:31 | sean-k-mooney | that an internal implemation detail of nova (sepcrically the libvirt driver) | |
| 14:33:45 | sean-k-mooney | zigo: i belive there might be a way to limit what info is shown to nova (via the service role) and the user (member/reader) | |
| 14:33:51 | sean-k-mooney | on the manilla side | |
| 14:42:07 | opendevreview | Dan Smith proposed openstack/nova master: Support "one-time-use" PCI devices https://review.opendev.org/c/openstack/nova/+/943816 | |
| 14:42:07 | opendevreview | Dan Smith proposed openstack/nova master: Invalidate PCI-in-placement cached RPs during claim https://review.opendev.org/c/openstack/nova/+/944149 | |
| 14:42:08 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test nova with placement alloc fix https://review.opendev.org/c/openstack/nova/+/945626 | |
| 14:42:08 | opendevreview | Dan Smith proposed openstack/nova master: Add one-time-use devices docs and reno https://review.opendev.org/c/openstack/nova/+/944262 | |
| 14:48:53 | dansmith | gibi: are you intending to hold off approving/merging OTU until after discussion at the PTG? | |
| 14:49:19 | sean-k-mooney | are there open desgin decisions ? | |
| 14:49:54 | sean-k-mooney | i.e. that need dicsussion at the ptg | |
| 14:49:58 | dansmith | not that I'm aware of, and the spec is merged, I just had the thought that maybe gibi was expecting to wait | |
| 14:50:01 | sean-k-mooney | or is it just normal code review that needed | |
| 14:50:07 | dansmith | just normal review, I think | |
| 14:50:12 | sean-k-mooney | ack | |
| 14:50:23 | dansmith | it's on the PTG for discussion, but TBH i was hoping to have it merged before then | |
| 14:50:32 | dansmith | since I'll be out for part of it (and the week after) | |
| 14:50:33 | sean-k-mooney | i personally have not had time to loop back to the impl much | |
| 14:50:57 | gibi | dansmith: I think we can progress with the normal code review. Right now I don't see any open questions on the spec level | |
| 14:50:59 | sean-k-mooney | but i didnt have any huge concern with the approch that was nto adressed in the spec | |
| 14:51:30 | dansmith | gibi: ack, I agree, I just realized I wasn't sure what others were actually thinking | |
| 14:51:42 | sean-k-mooney | dansmith: the only thing that comes to mind really are your expermient with using virt-rng ot try and test this in ci | |
| 14:52:06 | dansmith | sean-k-mooney: I've already got the images modified on vexx, and was planning to try to work on that next sprint | |
| 14:52:07 | gibi | sean-k-mooney: I still have the intention to test it with IGB locally | |
| 14:52:22 | sean-k-mooney | that not blocking i just dont know fi you want to present that approch to folks | |
| 14:52:27 | dansmith | but I also don't want to hold this up for that, since that is more just general PCI testing, and OTU in tempest will be a bit difficult | |
| 14:52:29 | sean-k-mooney | dansmith: oh cool good to know | |
| 14:52:57 | sean-k-mooney | dansmith: i was more thinking did we want to dicuss what else we could test with that | |
| 14:53:05 | dansmith | OTU in tempest is probably not doable because I need a single device, a dedicated flavor, no parallelism, etc, so I suspect whitebox is the best option | |
| 14:53:42 | sean-k-mooney | it might be possibel in upstream tempest but i dont think anyone would object to whitebox | |
| 14:54:04 | sean-k-mooney | anyway if we keep the ptg session this is what i was expecting to come up | |
| 14:54:27 | dansmith | the problem is tempest would need to know the alias in order to create the flavor in the one test we use it, or we'd need to communicate another flavor devstack setup that is only for that one test | |
| 14:54:31 | sean-k-mooney | not really OTU itself but how can we improve passhtough testing in general | |
| 14:54:34 | dansmith | but yeah, maybe we use the PTG to discuss testing | |
| 14:54:49 | sean-k-mooney | like we never finish the mdev testing work | |
| 14:55:06 | sean-k-mooney | we have your mtty devstack supprot just missing the nova bit to use it | |
| 14:55:25 | dansmith | ack, I thought bauzas had ruled that out | |
| 14:55:27 | dansmith | but it'd be nice | |
| 14:55:40 | sean-k-mooney | i think bauzas was just to busy to finish it | |
| 14:55:48 | dansmith | okay | |
| 14:55:54 | sean-k-mooney | i dont know of anything blockign completing the work | |
| 14:55:56 | bauzas | I'm pretty burned about vgpu but I can try to update my mtty series | |
| 14:56:49 | sean-k-mooney | the other thing gibi and i were hopign to do is after a coulple of the provider get to epoxy we would like to see if we can get image with igb enbaled | |
| 14:56:58 | sean-k-mooney | so we can test sriov | |
| 14:57:07 | sean-k-mooney | not sure when that will happen but its related. | |
| 14:57:18 | Uggla | bauzas, maybe you can offload some vgpu stuff to me. | |
| 14:59:12 | sean-k-mooney | dansmith: on a related note but changing the topic slightly https://review.opendev.org/c/openstack/placement/+/945465 is being tracked as a bugfix, but do you think its a backportable change or master only | |
| 14:59:31 | gibi | https://etherpad.opendev.org/p/nova-2025.2-ptg#L378 | |
| 14:59:53 | dansmith | sean-k-mooney: I think it's backportable and would be a good candidate, personally, since it's very self-contained and the bug really sucks for operators, IMHO | |
| 15:00:18 | dansmith | sean-k-mooney: but, I have not been able to test that it actually fixes the nova migration problems yet since I need two computes to do it | |
| 15:00:35 | sean-k-mooney | ack my follow up is if that backportable do we need nova work for the existing nova bug or do you think cold migration ectra woudl just start working? | |
| 15:00:51 | dansmith | I believe this should make it just work on the nova side | |
| 15:01:42 | sean-k-mooney | ack, not that our downsteam qe have a lot of capsity for upstream work but we might want to talk to them about how we coudl test the previously broken operation in upstream tempest | |
| 15:02:23 | sean-k-mooney | well or whitebox | |
| 15:02:32 | dansmith | again, this requires putting the compute node into overcapacity state with an allocation_ratio change, so I don't really think we can do that in upstream parallel tempest | |
| 15:02:38 | dansmith | whitebox potentially | |
| 15:04:34 | sean-k-mooney | tempest has the ida of serial test that run one by one. that might help here but many of these edge cases have the potentil to conflict wth other test so i guess we would need to be carful about how we would test this | |
| 15:05:05 | dansmith | yeah, true.. it just seems sort of off the table for tempest by scope too, but perhaps not | |
| 15:05:38 | sean-k-mooney | the other concern i have is will this break any current functionl tests if we have repoducer for any of the nova bugs | |
| 15:05:44 | sean-k-mooney | i dont think we do | |
| 15:06:02 | sean-k-mooney | but if you fix it in placment it will presumable sto raising an error with the placement driect fixture | |
| 15:06:14 | dansmith | if we do, I'm not aware of them | |
| 15:06:51 | gibi | having a placement only tempest test for the overallocation fix could be written to be independent from any other test by creating a separate RP, but I'm not sure that worth it compared to a full nova migration test with overallocation. | |
| 15:07:15 | sean-k-mooney | ok in that case i realy dont have any other question related to this. | |
| 15:07:27 | sean-k-mooney | gibi: that could be done but gabit kind fo does that already right | |