| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-25 | |||
| 10:02:19 | sean-k-mooney | but i have not tested that | |
| 10:04:10 | opendevreview | Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254 | |
| 10:04:36 | gibi | sean-k-mooney: this is a fix for what James saw the other day downstream ^^ | |
| 10:09:59 | sean-k-mooney | ah nice | |
| 10:11:38 | sean-k-mooney | gibi: can we not use the oslo stringutils str to bool function | |
| 10:11:49 | sean-k-mooney | i think that woudl be better | |
| 10:13:19 | gibi | sure, why not | |
| 10:13:21 | sean-k-mooney | bool_from_string | |
| 10:13:40 | sean-k-mooney | basiclaly whhen it becomes YES or true | |
| 10:13:46 | sean-k-mooney | i dont want to have to fix it again | |
| 10:16:39 | gibi | good point | |
| 10:16:44 | gibi | I will respin in a sec | |
| 10:18:00 | opendevreview | Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254 | |
| 10:18:05 | sean-k-mooney | by the way i noticed this change on more recent kernels | |
| 10:18:23 | sean-k-mooney | it seam all module parmater changed form 1 to y somewhwer around 5.10 ish | |
| 10:18:41 | gibi | I just checked mine and there it was Y | |
| 10:18:49 | sean-k-mooney | not sure exacatly where but i noticed it for say nested_vert for example | |
| 10:19:25 | gibi | hum in 5.4 it is still 1/0 | |
| 10:19:33 | sean-k-mooney | yep | |
| 10:19:43 | sean-k-mooney | so i think the kernel made this change globally at some poitn | |
| 10:19:47 | sean-k-mooney | 1/0 still works | |
| 10:19:52 | sean-k-mooney | it just now reports y/n | |
| 10:20:02 | sean-k-mooney | in sysfs | |
| 10:20:29 | sean-k-mooney | i guess libvirt is just doing a raw passthough and not normalising | |
| 10:20:32 | gibi | hm, it is module dependent, I see modules reporting 0 on 5.17 | |
| 10:20:42 | sean-k-mooney | oh ok | |
| 10:20:52 | sean-k-mooney | maybe a style change | |
| 10:20:59 | gibi | yeah | |
| 10:22:26 | gibi | OK , switched thet patch to strutils, thanks for noticing it | |
| 10:22:57 | sean-k-mooney | ill review it shortly just updating the iommu spec | |
| 10:23:52 | gibi | thanks | |
| 10:33:51 | sean-k-mooney | +2 by the way we will need to backport this to whenever we added sev support right | |
| 10:35:21 | sean-k-mooney | stephenfin: if you want to propsoe adding auto as a model please do i have no real objection to that | |
| 10:35:30 | stephenfin | will do | |
| 10:35:49 | sean-k-mooney | did you have any other outstanding questions | |
| 10:36:02 | sean-k-mooney | we are agreed on useign 48 for the bit with right | |
| 10:36:09 | sean-k-mooney | if libvirt is knew enough | |
| 10:36:59 | sean-k-mooney | i think that was the only other thing pending on the spec | |
| 10:37:15 | sean-k-mooney | well the last version was updated to say we would | |
| 10:37:44 | gibi | sean-k-mooney: sure I will do the backports | |
| 11:27:34 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix typos https://review.opendev.org/c/openstack/nova/+/843127 | |
| 11:33:13 | sean-k-mooney | i feel philosophically oblidged to not review ^ :) | |
| 11:49:37 | opendevreview | Balazs Gibizer proposed openstack/nova-specs master: PCI device tracking in Placement https://review.opendev.org/c/openstack/nova-specs/+/791047 | |
| 11:50:09 | gibi | stephenfin, sean-k-mooney, bauzas: I think all the open questions are resolved now ^^ | |
| 11:54:19 | sean-k-mooney | ack im currntly truning some wifi setting so i might loose connectivity for a bit but ill take a look later today | |
| 11:57:33 | sean-k-mooney | ok that might have stablised. | |
| 11:57:43 | sean-k-mooney | it was till repovisioning | |
| 12:59:25 | opendevreview | Ade Lee proposed openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844 | |
| 13:12:52 | kashyap | gibi: This can be interesting: https://bugs.launchpad.net/nova/+bug/1975711. I can reproduce that too; on a fresh checkout on F36, re-run (not the first run) `tox -v pep8` is taking 3 *minutes* | |
| 13:14:50 | sean-k-mooney | kashyap: im not sure this is really a valid nova bug | |
| 13:15:10 | sean-k-mooney | this seams like its more a tox/pip issue | |
| 13:15:30 | kashyap | sean-k-mooney: Apparently this can be fixed in Nova, see Miguel's comment there: | |
| 13:15:33 | kashyap | [quote] | |
| 13:15:33 | kashyap | [/quote] | |
| 13:15:36 | kashyap | Doing this means slightly refactoring how requirements are defined in the project. I'm working on a draft patch to show what that would look like and will create a review soon. | |
| 13:15:42 | kashyap | He used 'pip-compile' to sort this out | |
| 13:15:43 | sean-k-mooney | right there fix is not really valid | |
| 13:15:54 | sean-k-mooney | it change how we test | |
| 13:16:08 | sean-k-mooney | and what we are testing | |
| 13:16:29 | gibi | still I guess somewhere we have some problems in the transitive dependencies as pip get stuck, while normally pip does not get stuck on a simple pep8 setup | |
| 13:17:27 | gibi | I agree with sean-k-mooney not to blindly alter our test process by pinning requirements. I suggest to try to find the offending dependency and try to figure out what makes it hard for pip to resolve the deps | |
| 13:17:33 | sean-k-mooney | if we were to fix this in nova we woudl have to delete and recreate the pinned deps every time we run tox | |
| 13:17:53 | kashyap | sean-k-mooney: I wouldn't be too quick to dismiss the fix without actually looking at the problem and properly understanding it. | |
| 13:17:59 | sean-k-mooney | and we would have to ensure that pip-compile follows UC and test-requirement properly | |
| 13:18:22 | kashyap | gibi: Yeah, I think I should have a trace of one of the offending deps ... lemme check | |
| 13:18:26 | sean-k-mooney | kashyap: im not im pointing out that they probaly dont fully understand how we test and what | |
| 13:18:39 | sean-k-mooney | we require form a pti point of view | |
| 13:18:56 | sean-k-mooney | so we need to actully see if its pti compleint and test wat we want ti to test | |
| 13:19:00 | kashyap | sean-k-mooney: Ah, sure. I don't deny that. (Aside, what is "pti"?) | |
| 13:19:10 | sean-k-mooney | project testing interface | |
| 13:19:54 | sean-k-mooney | kashyap: https://github.com/openstack/governance/blob/master/reference/pti/python.rst specificly | |
| 13:20:10 | kashyap | gibi: E.g. for me it got stuck at this "decorator" thing: https://paste.opendev.org/show/baNIMuM5YxlBA8nwxm10/ | |
| 13:20:11 | sean-k-mooney | defien how all offical python project must do there testing | |
| 13:20:40 | sean-k-mooney | kashyap: it likely will not be stable in all caes | |
| 13:21:02 | sean-k-mooney | basicaly as release happen you might see that change | |
| 13:21:09 | gibi | kashyap: so the next step would be to compare the pip run on f35/36 with a non-stuck pip run on ubuntu 2004 | |
| 13:21:25 | gibi | maybe with a run from our gate | |
| 13:21:26 | sean-k-mooney | its porbaly python3.10 vs 3.9 really | |
| 13:21:35 | kashyap | gibi: But it's also non-deterministic for me; "eventually" it went ahead and succeeded | |
| 13:21:53 | kashyap | sean-k-mooney: You're using 3.9? | |
| 13:21:58 | gibi | sean-k-mooney: stilly p310 not stuck on my debian | |
| 13:21:58 | sean-k-mooney | the odd thing is im pretty sure it work for me on 3.9 and 3.10 | |
| 13:22:13 | sean-k-mooney | ya i think 3.10 worked for me too | |
| 13:22:23 | sean-k-mooney | kashyap: i have 3.8 3.9 and 3.10 | |
| 13:22:35 | gibi | so this can be pip cache (need a clean VM to reproduce) already globally installed python deps | |
| 13:22:40 | sean-k-mooney | i normlaly use 3.8 since its supported on the most set of branches | |
| 13:22:40 | kashyap | (I'm using 3.10 too; FWIW) | |
| 13:22:57 | sean-k-mooney | kashyap: just so you know 3.10 is not supported yet | |
| 13:23:09 | sean-k-mooney | as in its experimental for zed | |
| 13:23:32 | sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/runtimes/zed.rst#python-runtimes-for-zed= | |
| 13:23:44 | kashyap | gibi: sean-k-mooney: Sorry, I was lying! I was using 3.8.13, actually | |
| 13:24:02 | sean-k-mooney | so its nice that you are using it but we do not expect it to work in all cases. | |
| 13:24:11 | sean-k-mooney | kashyap: you are gettign that failure on 3.8 | |
| 13:24:16 | kashyap | Yep | |
| 13:24:22 | sean-k-mooney | hum maybe its related to the distro packages then | |
| 13:24:28 | kashyap | It's not deterministic. So I don't want to take your time much on it. | |
| 13:24:28 | sean-k-mooney | our your pip version | |
| 13:24:35 | sean-k-mooney | what version of pip have you installed | |
| 13:24:51 | kashyap | sean-k-mooney: It's in a tox env. And I'm using "pip 22.1.1" | |
| 13:25:33 | kashyap | But for now, it's "magically resolved" after a couple of runs. I haven't even recreated 3.8 tox env. | |