| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-10 | |||
| 11:26:30 | bauzas | meh to ignoring errors | |
| 11:26:42 | gibi | I'm fine ignoring errors | |
| 11:26:49 | gibi | during delete of a temp dir | |
| 11:27:00 | gibi | we will never reuse the temp dir as it has a random postfix | |
| 11:27:05 | sean-k-mooney | the flag is only there in 3.10 | |
| 11:27:09 | gibi | if my /tmp fills up that is on me | |
| 11:27:10 | sean-k-mooney | and we need to support 3.8 | |
| 11:27:17 | gibi | aah | |
| 11:27:21 | bauzas | gibi: that's the problem | |
| 11:27:26 | sean-k-mooney | so its fine for it to error | |
| 11:27:28 | sean-k-mooney | it wont | |
| 11:27:29 | gibi | ahh | |
| 11:27:30 | bauzas | we can't say 'ignore errors' if we use cleanup | |
| 11:27:38 | bauzas | hence me torn | |
| 11:27:41 | gibi | I'm fine both ways | |
| 11:27:41 | sean-k-mooney | i could have errored when we had the copy of sysfs because of some permision | |
| 11:27:51 | sean-k-mooney | but now its just normal files owned by us | |
| 11:27:54 | bauzas | correct | |
| 11:28:00 | gibi | if it starts failing on cleanup then we will switch to shutil | |
| 11:28:01 | sean-k-mooney | so it wont error unless there is a disk issue which si out of scope | |
| 11:28:08 | bauzas | yup, this ^ | |
| 11:28:09 | sean-k-mooney | +1 | |
| 11:28:44 | bauzas | I'll add a comment explaining the risk and how to mitigate it if we see it in CI | |
| 11:29:39 | gibi | cool | |
| 11:39:48 | bauzas | sean-k-mooney: gibi: I haven't yet written the docs patch as it requires a bit of effort, so I'll keep your comments on it unresolved but don't misunderstand me, surely I'll do it in a subsequent patch once I'm done (monday morning hopefully) | |
| 11:39:58 | bauzas | I just wanna give chance to other people to get reviewed | |
| 11:40:14 | gibi | bauzas: sure, doc is OK after FF | |
| 11:40:22 | sean-k-mooney | ya it can be a seperate patch | |
| 11:40:47 | bauzas | the core #0 note is actually very important | |
| 11:40:49 | bauzas | TIL about it | |
| 11:41:13 | bauzas | but yeah that makes sense from an OS perspective | |
| 11:41:21 | bauzas | you always rely on that core to be available | |
| 11:41:50 | bauzas | that's the most portable assumption | |
| 11:42:04 | sean-k-mooney | ya it generally need one core that can always be used to handel interupts and you know turn on the others | |
| 11:43:14 | sean-k-mooney | bauzas: that is why there is no online file in /sys/bus/cpu/devices/cpu0/ | |
| 11:43:24 | sean-k-mooney | but there is in all the rest | |
| 11:44:07 | bauzas | ooooooooh | |
| 11:44:39 | bauzas | but you can write an online file and set 0 into it for core #0, right ? | |
| 11:45:13 | bauzas | that's quite a destructive CPU equivalent of disk's rm -rf / | |
| 11:45:25 | bauzas | except it's stateless | |
| 11:49:40 | sean-k-mooney | it will be ignored | |
| 11:49:55 | sean-k-mooney | you can create that file but it wont do anything as far as i am aware | |
| 11:50:52 | sean-k-mooney | by the way https://github.com/SeanMooney/arbiterd/blob/master/src/arbiterd/common/cpu.py#L58-L62 | |
| 11:51:02 | sean-k-mooney | is how i got the aviable cpus | |
| 11:52:02 | sean-k-mooney | gibi: bauzas actully also for context | |
| 11:52:04 | sean-k-mooney | https://github.com/SeanMooney/arbiterd/blob/master/src/arbiterd/common/cpu.py#L106-L107 | |
| 11:52:14 | sean-k-mooney | that default 1 was because of this | |
| 11:52:19 | bauzas | gtk | |
| 11:52:24 | sean-k-mooney | https://github.com/SeanMooney/arbiterd/blob/master/src/arbiterd/common/cpu.py#L106-L114 | |
| 11:52:35 | sean-k-mooney | thats also why i did the get_online check in set online | |
| 11:52:46 | sean-k-mooney | to not do the write | |
| 11:52:59 | sean-k-mooney | i proably should have left a code comment for that... | |
| 11:53:26 | sean-k-mooney | ye removed that optimisation but that was actully the real reason i did that in the poc. it was not an optimisation | |
| 11:53:37 | sean-k-mooney | it was to workaround the cpu0 weridness | |
| 11:54:28 | sean-k-mooney | although to be fair i didnt fix that on the set offline path | |
| 11:54:30 | sean-k-mooney | so meh | |
| 12:04:01 | opendevreview | Sylvain Bauza proposed openstack/nova master: libvirt: let CPUs be power managed https://review.opendev.org/c/openstack/nova/+/821228 | |
| 12:04:02 | opendevreview | Sylvain Bauza proposed openstack/nova master: Enable cpus when an instance is spawning https://review.opendev.org/c/openstack/nova/+/868237 | |
| 12:04:06 | bauzas | gibi: sean-k-mooney: ^ | |
| 12:04:23 | bauzas | and after that, will take my pen for reviewing series | |
| 13:28:21 | gibi | bauzas: on it | |
| 13:28:29 | bauzas | ack | |
| 13:32:16 | opendevreview | Andre Aranha proposed openstack/nova stable/yoga: [stable-only] Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/860087 | |
| 13:36:21 | gibi | bauzas: I'm +2 +A on the power management series | |
| 13:37:32 | bauzas | gibi: thanks | |
| 13:38:11 | gibi | it was a self contained patch series with well splitted commits. so it was a plesure to review | |
| 13:38:49 | bauzas | I'll add in the etherpad the promised docs patch | |
| 13:41:35 | gibi | I will check the evac fup now | |
| 13:54:44 | gibi | bauzas: I'm not sure https://review.opendev.org/q/topic:privsep-usage-review is at a landeable state | |
| 13:55:13 | gibi | I think the two patches there are only pre-reqs for the real move but I can be mistaken | |
| 13:55:44 | bauzas | I need to open those links | |
| 13:55:54 | bauzas | ideally, I'd like a migration plan | |
| 13:56:07 | bauzas | something we could merge on a step way | |
| 13:56:45 | bauzas | but yeah, I assume this blueprint would be marked Complete once we pull all the callers out of the privsep.py modules | |
| 13:57:42 | sean-k-mooney | they can be merged increentally but i dont think there is enough done in those to see a benifit in A | |
| 13:57:51 | sean-k-mooney | i would proably wait till early next cycle | |
| 13:58:19 | sean-k-mooney | that said i have not really reviewed it so there might be more there then i think | |
| 13:58:25 | sean-k-mooney | i would not rush it however | |
| 13:58:30 | bauzas | yeah maybe | |
| 13:58:37 | bauzas | shit. https://review.opendev.org/c/openstack/tempest/+/873300 got again trampled | |
| 13:58:46 | bauzas | our gate is still onhold | |
| 14:02:35 | gibi | bauzas: there a global requirement bump https://review.opendev.org/c/openstack/requirements/+/872065 that is RED due to nova. And it blocks bumping os-traits to 2.10.0 in global requirements which in turn blocks the manila series and the https://review.opendev.org/q/topic:bp%252Flibvirt-maxphysaddr-support impl | |
| 14:03:36 | bauzas | damn shit. | |
| 14:03:47 | bauzas | we're constructing a pile of cards | |
| 14:04:14 | gibi | yeah | |
| 14:04:21 | bauzas | wait | |
| 14:04:23 | bauzas | https://effe4ed80a91c92fc386-ef4309a852fb3e3584cdcb1adbb4ea34.ssl.cf2.rackcdn.com/872065/4/check/cross-nova-py310/da20743/testr_results.html | |
| 14:04:49 | bauzas | 2023-02-07 15:57:42,351 ERROR [nova.privsep.utils] Error on '.' while checking direct I/O: '' | |
| 14:04:59 | bauzas | I have no idea about what would cause this | |
| 14:05:07 | gibi | I did not looked into that failure | |
| 14:05:31 | bauzas | after 10 years, I still discover new areas in Nov | |
| 14:07:01 | bauzas | gibi: ouch, see this ? https://review.opendev.org/c/openstack/requirements/+/872065/4/upper-constraints.txt#207 | |
| 14:08:00 | gibi | I counted > 20 major bumps in that patch but I did not noticed that libvirt-python is one of them | |
| 14:08:04 | gibi | so shit++ | |
| 14:08:21 | gibi | I don't like that big bump patch | |
| 14:08:26 | gibi | it moves to many things at once | |
| 14:08:29 | gibi | too close to RC1 | |
| 14:09:14 | kashyap | gibi: It's not merged yet, right | |
| 14:09:25 | kashyap | gibi: Yeah, I just see the 'libvirt-python' bump sneaked in there | |
| 14:09:34 | gibi | kashyap: right, it is failed on CI | |