| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-08 | |||
| 17:06:05 | sean-k-mooney | dansmith: the fast8 fix works for me locally so i have approved it | |
| 17:06:32 | sean-k-mooney | sylvain was already +2 | |
| 17:06:37 | gibi | dansmith: (with limited brain power left in me) you want to run pep8 locally but you dont want autopep8 to modify your code because you are in a middle of something. Still you are (not happily) accepting the fact that at the end before you push up the commit you will run autopep8 and let it do its things. If that is the case then totally supportive to your needs | |
| 17:07:11 | gibi | * then I totally | |
| 17:07:35 | dansmith | gibi: I do not ever want autopep8 to modify my stuff, even pre-push.. I want it to tell me what it objects to | |
| 17:07:47 | sean-k-mooney | for what its worth pre-commit ignored unstaged files but obviously that woudl be a change in your workflow jsut lettign you know | |
| 17:08:04 | dansmith | but yes, the major complaint is when I'm in the middle of a rebase or a complex change and it modifies my files and complicates my index so I have to manually revert things I don't want to change in the middle of a workflow | |
| 17:08:36 | sean-k-mooney | dansmith: that how i orgianlly implented it for what its worth autopep8 in the pep8 target complaied but did nto modify | |
| 17:08:42 | sean-k-mooney | in its sepreate target it fixed things | |
| 17:08:48 | sean-k-mooney | and via pre-commit it fixed things | |
| 17:08:50 | dansmith | sean-k-mooney: I know, that's what I want | |
| 17:09:22 | dansmith | since I'm not going to use pre-commit, that was fine.. and it was presented to us as fully optional because (a) it was a different tox target or (b) pre-commit was optional if you installed it | |
| 17:09:41 | gibi | dansmith: yeah I should have be more specific. Either running autopep8 and let it do its things, or run autopep8 and fail if wants to modify something and you iterate manually until autopep8 is happy | |
| 17:09:41 | dansmith | then, we moved to pep8 target using pre-commit and it's been complicating rebase workflows ever seince | |
| 17:09:53 | dansmith | gibi: yes, thanks | |
| 17:10:41 | gibi | dansmith: I'm OK with this approach. I will rely on autopep8, you will satisfy autopep8 manually. We won't clash and in CI the end result is the same happy autopep8 run | |
| 17:10:58 | dansmith | I had been working around this by using fast8 (which I usually use during a rebase anyway) and not complaining, but that broke recently as well hence the issue | |
| 17:11:08 | dansmith | gibi: ++ | |
| 17:11:16 | sean-k-mooney | im trying to think how to do that today and i htink i might know | |
| 17:11:33 | sean-k-mooney | give me a minute to test it | |
| 17:13:14 | sean-k-mooney | the applciation alwasy awa not actully intentional as part of stephens change. i.e. the removal of the opt out | |
| 17:13:36 | sean-k-mooney | ill try fixign that quickly as i have 2 idea of how to do that cleanly | |
| 17:21:23 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | |
| 17:28:37 | sean-k-mooney | i need to chnage my testcase since it currently brakign the wrong hook but i think i have it working lcoally with a very minor change ill push it for review in 10 mins or so | |
| 17:48:30 | opendevreview | Merged openstack/nova master: Reproducer for bug 2114951 https://review.opendev.org/c/openstack/nova/+/952894 | |
| 17:53:10 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | |
| 18:11:17 | opendevreview | sean mooney proposed openstack/nova master: refactor autopep8 pre-commit config https://review.opendev.org/c/openstack/nova/+/960167 | |
| 18:13:05 | sean-k-mooney | i need to test ^ a little more but i belive it keeps the bhavior gibi and i woudl like while also restorign the behavior dan desires | |
| 18:14:20 | sean-k-mooney | one of the things i need to confirm is that the exit code propagate form bash -c | |
| 18:14:54 | sean-k-mooney | i belive it should but we need that to ensure that tox -e pep8 fails if any of the other check fail | |
| 18:15:53 | sean-k-mooney | this is based on https://github.com/pre-commit/pre-commit/issues/2083 | |
| 19:17:48 | opendevreview | Merged openstack/nova master: Update compute rpc alias for epoxy https://review.opendev.org/c/openstack/nova/+/959181 | |
| 19:43:34 | opendevreview | Merged openstack/nova master: Fix fast8 tox target https://review.opendev.org/c/openstack/nova/+/960149 | |
| 20:36:18 | opendevreview | Tobias Urdin proposed openstack/nova master: libvirt: update description for live_migration_completion_timeout https://review.opendev.org/c/openstack/nova/+/874083 | |
| 21:22:14 | opendevreview | sean mooney proposed openstack/nova master: refactor autopep8 pre-commit config https://review.opendev.org/c/openstack/nova/+/960167 | |
| #openstack-nova - 2025-09-09 | |||
| 09:07:26 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2025.1: Reproduce bug/2115905 https://review.opendev.org/c/openstack/nova/+/960241 | |
| 09:07:27 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2025.1: [PCI tracker]Remove non configured devs when freed https://review.opendev.org/c/openstack/nova/+/960242 | |
| 09:07:28 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2025.1: [pci]Keep used dev in Placement regardless of dev_spec https://review.opendev.org/c/openstack/nova/+/960243 | |
| 09:14:02 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Reproduce bug/2115905 https://review.opendev.org/c/openstack/nova/+/960244 | |
| 09:14:03 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: [PCI tracker]Remove non configured devs when freed https://review.opendev.org/c/openstack/nova/+/960245 | |
| 09:14:04 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: [pci]Keep used dev in Placement regardless of dev_spec https://review.opendev.org/c/openstack/nova/+/960246 | |
| 09:21:27 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Reproduce bug/2115905 https://review.opendev.org/c/openstack/nova/+/960248 | |
| 09:21:28 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: [PCI tracker]Remove non configured devs when freed https://review.opendev.org/c/openstack/nova/+/960249 | |
| 09:21:29 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: [pci]Keep used dev in Placement regardless of dev_spec https://review.opendev.org/c/openstack/nova/+/960250 | |
| 09:41:04 | opendevreview | Johannes Kulik proposed openstack/nova master: api: Pre-query not deleted members in server groups https://review.opendev.org/c/openstack/nova/+/959696 | |
| 13:30:54 | Uggla | dansmith, I have seen you point above, would you like to "quickly" discuss about it at PTG ? | |
| 13:38:16 | dansmith | Uggla: I would like it fixed right now (i.e. stop forcing edits to my code) and yes, a quick discussion to get agreement that there should always be _some_ way to run the linters in read-only mode might be good | |
| 14:01:34 | opendevreview | sean mooney proposed openstack/nova master: remove hardcoded in-place config for autopep8 https://review.opendev.org/c/openstack/nova/+/960150 | |
| 14:01:35 | opendevreview | sean mooney proposed openstack/nova master: refactor autopep8 pre-commit config https://review.opendev.org/c/openstack/nova/+/960167 | |
| 14:22:09 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | |
| 14:26:09 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal https://review.opendev.org/c/openstack/nova/+/960130 | |
| 14:51:50 | opendevreview | sean mooney proposed openstack/nova master: Revert "Allow autopep8 to fix more things" https://review.opendev.org/c/openstack/nova/+/960150 | |
| 14:51:51 | opendevreview | sean mooney proposed openstack/nova master: renable autopep8 agressive=3 https://review.opendev.org/c/openstack/nova/+/960274 | |
| 14:51:51 | opendevreview | sean mooney proposed openstack/nova master: refactor autopep8 pre-commit config https://review.opendev.org/c/openstack/nova/+/960167 | |
| 15:19:18 | Uggla | Nova meeting in around 40mn. | |
| 15:43:43 | bauzas | elodilles: just a silly question, can we backport some patch that's merged on master branch in between RC1 and GA ? | |
| 15:44:13 | bauzas | I mean, can we merge the backport to say Epoxy branch in between RC1 and Flamingo GA? | |
| 15:46:42 | gibi | bauzas: thanks for asking! | |
| 15:48:22 | opendevreview | Nell Jerram proposed openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/960284 | |
| 15:50:39 | elodilles | bauzas: in Flamingo release, the RCs will be published as final release, | |
| 15:50:52 | bauzas | that, I know | |
| 15:50:58 | sean-k-mooney | bauzas: as far as i am aware we are not ment to unless we are either ok with including them in an RC2 if its requried or we know there will now be one | |
| 15:51:06 | bauzas | lemme give a specific example | |
| 15:51:14 | sean-k-mooney | if we backport before RC1 is tagged it shoudl be ok however | |
| 15:51:27 | sean-k-mooney | i.e. before the sabel tbranch is created | |
| 15:51:29 | elodilles | bauzas: that means, that teams can backport bug fixes and if those are release critical, then further RCs can be proposed | |
| 15:51:36 | opendevreview | Nell Jerram proposed openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/960284 | |
| 15:51:54 | elodilles | bauzas: until Final RC deadline -> https://releases.openstack.org/flamingo/schedule.html | |
| 15:52:07 | bauzas | elodilles: my question is specifically about https://review.opendev.org/c/openstack/nova/+/960242 | |
| 15:52:08 | elodilles | i.e. until week R-1 | |
| 15:52:41 | bauzas | elodilles: the master patch was merged in master which was Flamingo, this was proposed against Epoxy, can I +W it once we're past RC1 ? | |
| 15:52:48 | sean-k-mooney | thats already merged in master before rc1 is created | |
| 15:52:54 | bauzas | correct | |
| 15:53:02 | sean-k-mooney | so it will be in stable/2025.2 | |
| 15:53:10 | sean-k-mooney | so i dont see why that cant proceed | |
| 15:53:21 | sean-k-mooney | there is no chach of a regression | |
| 15:53:41 | bauzas | I was thinking we were holding stable approvals on /any/ stable branch during the RC phases, but that's probably me who's overthinking | |
| 15:53:53 | sean-k-mooney | going form 2025.1 to 2025.2 | |
| 15:54:15 | sean-k-mooney | unless it has teh poteial to impact grenade i dont hink we need too | |
| 15:54:32 | sean-k-mooney | so older banches like 2024.2 i think does not require any freeze | |
| 15:54:43 | elodilles | bauzas: you can, but the question is whether it is RC critical, and if not, will it cause trouble when an RC critical issue comes up and an RC2 needs to be proposed | |
| 15:54:46 | bauzas | of course once we branch 2025.2 with RC1, any master patch merged after couldn't be backported to 2025.1 as it would require to be merged first on 2025.2 which is only accepting regression fixes | |
| 15:55:21 | sean-k-mooney | elodilles: the patch in question was merged on master 4 days ago | |
| 15:55:24 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/954613 | |
| 15:55:41 | elodilles | sean-k-mooney: yes, but i guess bauzas just used it as an example :) | |
| 15:55:42 | sean-k-mooney | so in this specific example it will be included in rc1 anyway | |
| 15:56:03 | sean-k-mooney | ack | |
| 15:56:31 | bauzas | elodilles: not exactly an example, I'm a stable core and I was about to review that 2025.1 proposal, so I was wondering whether I should/could +W it after Thursday | |
| 15:56:33 | elodilles | sean-k-mooney: and of course, as you wrote, too, until RC1 is not merged, and stable/2025.2 branch is not cut, everything will be included from 'master' | |
| 15:58:02 | elodilles | bauzas: i see. so the question is then, if we see that too risky to merge now, just before the flamingo release. we can postpone the backport for later time, when we are over the 2025.2 Flamingo coordinated release | |
| 15:58:41 | elodilles | bauzas: so yes, the best is to keep master (and then stable/2025.2) as stable as possible, and maybe postpone every (risky) backports | |
| 15:59:32 | sean-k-mooney | im not sure if this woudl be condiered risky for what its worth at least when it comes to posibel impact on the 2025.2 release | |
| 15:59:45 | elodilles | bauzas: as far as i remember you usually said that after RC1 cut stable backports to stable/<current_series> should be avoided to merge, unless they are release critical o:) | |
| 16:00:09 | sean-k-mooney | yep ^ | |
| 16:00:15 | elodilles | so that is a nice and safe approach :) | |
| 16:00:15 | sean-k-mooney | and the bot patches | |
| 16:01:18 | sean-k-mooney | its imporant to merge the bot patches including any translation patches that might be propsoed once the stable branhc is created | |
| 16:01:35 | bauzas | elodilles: that's correct yes, that was my thinking but maybe I was overthinking it | |
| 16:02:35 | elodilles | sean-k-mooney: yes. as those should be pretty harmless and in fact, needed (but no need for an RC2 if those are the only merged patches on the stable branch) | |
| 16:03:25 | elodilles | bauzas: it's better to be safe than sorry o:) | |