| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-22 | |||
| 13:55:40 | bauzas | opkay | |
| 13:55:48 | sean-k-mooney | once 6.7 is release we shoudl eb able to use the mainline package to install 6.7 | |
| 13:55:49 | bauzas | anyway, I'm done | |
| 13:55:59 | sean-k-mooney | and then compile that version | |
| 13:55:59 | bauzas | I just look at some test issue | |
| 13:56:05 | bauzas | but then I'll stop to work | |
| 13:56:12 | sean-k-mooney | ack | |
| 13:56:31 | sean-k-mooney | ill be around for a while but ill see if i can skim over it | |
| 13:56:40 | sean-k-mooney | if not ill take a look when im back on the 8th | |
| 14:01:13 | bauzas | ++ | |
| 14:01:33 | bauzas | if you want, you can quickly look at what I wrote for the design | |
| 14:01:52 | bauzas | I added two fields in the object | |
| 14:30:20 | sean-k-mooney | bauzas: by the way i think a major team of the D cycle will be decoupling nova form eventlet as that is likely to become a comunity wide goal to complete in the next 1-2 years | |
| 14:30:33 | bauzas | yup, I saw | |
| 14:30:37 | sean-k-mooney | bauzas: i have been looking at the low haning fruit | |
| 14:30:57 | sean-k-mooney | and there are a few small things i think we can do today or this cycle to make that simpler | |
| 14:31:12 | sean-k-mooney | so i may hack on that a bit adn propsoe a few patches premtivly | |
| 14:31:29 | sean-k-mooney | but im not sure if i really want to propsoe a spec/blueprint for that this cycle | |
| 14:31:36 | sean-k-mooney | or if i just want to experiment | |
| 14:31:42 | sean-k-mooney | to see what it would look liek | |
| 14:32:03 | sean-k-mooney | part of me feels liek we have enough on our plates | |
| 14:32:14 | sean-k-mooney | but i also want to have a better feel for this before the next ptg | |
| 14:32:46 | sean-k-mooney | so i might propsose some patches btu not sure if im going to ask for review on those or not | |
| 14:33:01 | sean-k-mooney | just in case you see them and wonder why im doing that | |
| 14:55:32 | bauzas | sean-k-mooney: sorry was working on the yearly internal certifications | |
| 14:55:41 | bauzas | sure, as you want | |
| 14:55:47 | sean-k-mooney | hehe i did that yesterday | |
| 14:55:50 | sean-k-mooney | it took like 2 hours | |
| 14:55:54 | bauzas | you could add them in the etherpad | |
| 14:56:40 | sean-k-mooney | sure | |
| 14:57:35 | sean-k-mooney | bauzas: melwitt has a patch that is related that i would like to see included in caracal https://review.opendev.org/c/openstack/nova/+/650172 | |
| 14:57:52 | bauzas | sean-k-mooney: please add it in the caracal etherpad | |
| 14:57:53 | sean-k-mooney | but that needs some rebases | |
| 14:58:14 | bauzas | I'll do a round of review when I'm back from my holidays | |
| 14:58:15 | sean-k-mooney | and if it missies its not the end fo the world but its will remove the only expelict use form the api | |
| 14:59:12 | sean-k-mooney | when is that by the way is it the 8th like me? | |
| 14:59:26 | sean-k-mooney | i know gibi is off for an addtional week | |
| 15:04:06 | bauzas | yeah, I'll be on Monday 8th Jan | |
| 15:04:39 | sean-k-mooney | ack as a head up i have asked kashyap to raise a specless blueprint in the team meeting on the 9th | |
| 15:05:29 | sean-k-mooney | this should be publically visabel https://issues.redhat.com/browse/OSPRH-32?focusedId=23691496&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-23691496 | |
| 15:05:57 | sean-k-mooney | tl;dr we need to dicusss if we are ok with that beign a specless bluepirnt or not before spec freeze | |
| 15:06:04 | sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/allow-disabling-ephemeral-disk-formatting | |
| #openstack-nova - 2023-12-25 | |||
| 11:20:09 | opendevreview | songjie proposed openstack/nova master: libvirt: stop enabling hyperv feature reenlightenment https://review.opendev.org/c/openstack/nova/+/904183 | |
| #openstack-nova - 2023-12-26 | |||
| 02:17:02 | opendevreview | songjie proposed openstack/nova master: libvirt: stop enabling hyperv feature reenlightenment https://review.opendev.org/c/openstack/nova/+/904183 | |
| #openstack-nova - 2023-12-27 | |||
| 06:48:57 | opendevreview | Rajesh Tailor proposed openstack/nova-specs master: List requested availability zones https://review.opendev.org/c/openstack/nova-specs/+/904368 | |
| 09:27:56 | opendevreview | Bence Romsics proposed openstack/nova stable/2023.2: Reproduce bug #2025480 in a functional test https://review.opendev.org/c/openstack/nova/+/904370 | |
| 09:27:57 | opendevreview | Bence Romsics proposed openstack/nova stable/2023.2: Do not untrack resources of a server being unshelved https://review.opendev.org/c/openstack/nova/+/904371 | |
| 09:28:22 | opendevreview | Bence Romsics proposed openstack/nova stable/2023.1: Reproduce bug #2025480 in a functional test https://review.opendev.org/c/openstack/nova/+/904372 | |
| 09:28:23 | opendevreview | Bence Romsics proposed openstack/nova stable/2023.1: Do not untrack resources of a server being unshelved https://review.opendev.org/c/openstack/nova/+/904373 | |
| 09:28:43 | opendevreview | Bence Romsics proposed openstack/nova stable/zed: Reproduce bug #2025480 in a functional test https://review.opendev.org/c/openstack/nova/+/904374 | |
| 09:28:44 | opendevreview | Bence Romsics proposed openstack/nova stable/zed: Do not untrack resources of a server being unshelved https://review.opendev.org/c/openstack/nova/+/904375 | |
| 13:14:33 | opendevreview | Rajesh Tailor proposed openstack/nova-specs master: List requested availability zones https://review.opendev.org/c/openstack/nova-specs/+/904368 | |
| 14:46:40 | opendevreview | Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381 | |
| 14:49:11 | opendevreview | Tobias Urdin proposed openstack/nova master: DNM: Alternative to parent patch https://review.opendev.org/c/openstack/nova/+/904382 | |
| 16:52:36 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/yoga: Fix the PCI device capability dict creation https://review.opendev.org/c/openstack/nova/+/899252 | |
| 16:53:46 | opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Store pf_mac_address and vf_num in extra_info https://review.opendev.org/c/openstack/nova/+/899253 | |
| 16:53:54 | opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/899254 | |
| 17:47:20 | tj90241 | Hello folks - happy holidays. Noticed today that: https://review.opendev.org/c/openstack/nova/+/700062 may have a regression and it does not seem fixed in at least a fairly-recent Yoga. | |
| 17:48:04 | tj90241 | Namely, after this change it is not possible to (cold) migrate a VM off a compute node that is strictly backed by Ceph, whereas it was previously. Does this ring a bell/stand out to anyone else? | |
| 17:48:20 | tj90241 | off a compute node, which is down/off/disalbed*** | |
| 17:49:53 | tj90241 | I understand the RPC call will hang forever and it's non-ideal for local storage, just wondering if anyone else thinks this may need to be gated by a flag like --on-shared-storage in older Novas or something somehow (or if this is already fixed and I haven't seen it). | |
| 17:54:01 | tj90241 | Totally unrelated -- would love another +1 or feedback on: https://review.opendev.org/c/openstack/nova/+/892614 as well. Been sitting for a couple months with the last feedback being lets not merge before 2023.2. | |
| #openstack-nova - 2023-12-28 | |||
| 18:44:19 | JayF | sean-k-mooney[m]: https://review.opendev.org/q/topic:%22codespell%22+repo:openstack/ironic-python-agent talent borrows; genius steals :P (seriously; thanks for doing that in nova; hadn't seen the tool before and it looks awesome, going to see if Ironic community agrees) | |
| 18:52:53 | sean-k-mooney[m] | givven how much time i spend respining my code for typos it felt worth my time to try out a few of the options and codespell seams to be one the nicer solutions. i wanted something that was pure python, i.e. had not deps on programs on your system, and that was designed for code i.e. was designed to reduce false positives | |
| 18:53:34 | sean-k-mooney[m] | JayF: i was kind of surprised at the number of issues found in nova | |
| 18:54:45 | sean-k-mooney[m] | the fact it automatically has suggestions for converting uk to us english is also really useful | |
| 18:55:40 | JayF | Honestly I'd consider that a downside, not an upside TBH. | |
| 18:55:55 | JayF | Any correct spelling being accepted would be better than it enforcing a specific regional standard | |
| 18:56:10 | sean-k-mooney[m] | you can disable that but our offcial docs policy for openstack say we use us english | |
| 18:56:16 | JayF | but I personally don't care *which* standard | |
| 18:56:34 | sean-k-mooney[m] | its just an additoanl correction dictionary | |
| 18:57:05 | JayF | that's fair, but I care more about not running someone away with CI churn than I do if a pydoc has an extra u | |
| 18:57:35 | sean-k-mooney[m] | https://github.com/codespell-project/codespell/blob/master/codespell_lib/data/dictionary_en-GB_to_en-US.txt | |
| 18:59:06 | JayF | yeah, my MVP in IPA is super simple, just invoking with the smallest correction list possible | |
| 18:59:24 | JayF | not sure if that's the right path or not, but bluntly, don't wanna invest that much time in a PoC that I made without talking to anyone else ironic-y | |
| 18:59:46 | JayF | I'm mildly tempted to do a similar POC with black/ruff/autopep8 or a similar tool | |
| 19:01:31 | sean-k-mooney[m] | we use autopep8 | |
| 19:01:55 | sean-k-mooney[m] | we talked about black but so far its a hard no form some so not pushing that at the moment | |
| 19:02:26 | sean-k-mooney[m] | we are currently trying to move as much of this to precommit wih optional tox targets for those that dont wnt to use precommit | |
| 19:02:54 | sean-k-mooney[m] | ruff is very interesting although i dont know if its packaged widely | |
| 19:03:35 | sean-k-mooney[m] | usign pre-commit to run flake8 has similar effect in that it only checks the files you changed | |
| 19:03:56 | sean-k-mooney[m] | so it gives a nice speedup althogh im sure its still slower the ruff | |
| 19:04:26 | sean-k-mooney[m] | the main problem with ruff would be hacking i.e. hacking checks would still need to be run elsewhere or ported | |
| 19:06:02 | JayF | the only reason I'm considering autopep8 at all is Nova's use of it | |
| 19:06:20 | JayF | yep, that's basically the #1 primary reason why ruff makes me :( | |
| 19:07:33 | JayF | ruff has some neat features around autoupgrading and dropping old python compat code | |
| 19:08:06 | JayF | I think it could have some real utility in OpenStack if we could bridge that gap, but I do think it's a bit early in the lifecycle compared to most tools we'd pick up | |
| 19:10:37 | sean-k-mooney[m] | JayF: i proposed using pyupgrade for that for nova | |
| 19:10:55 | sean-k-mooney[m] | but people were kind of uncomfortable with that being used automtically | |
| 19:11:00 | sean-k-mooney[m] | so i abandoned the serise | |
| 19:11:38 | JayF | pyupgrade is nasty for a handful of reasons | |
| 19:11:43 | JayF | ruff is better designed but just younger | |
| 19:11:52 | JayF | pyupgrade only running on a per-file basis is really strange | |
| 19:12:32 | JayF | let me put it this way: pyupgrade is written in an extremely opinionated way, and CI-style tooling like that with strong opinions I find offputting, as opposed to things with knobs you can turn to make them work in different ways/environments/runners/etc | |
| 19:12:38 | sean-k-mooney[m] | pyupgarde is using the python ast and validating that the upgraded line has the same behavior | |
| 19:12:42 | JayF | you're already on pre-commit, so that probably was easily glossed over :) | |
| 19:13:27 | sean-k-mooney[m] | welll the way we have been trating this is if the linters would change the code then you reject the patch in ci | |
| 19:13:41 | sean-k-mooney[m] | and provide a way to run that same check locally before its submitted | |
| 19:13:46 | JayF | sean-k-mooney[m]: yeah, my complaints are mostly about the interface/style than they are about the technical aspects of it. It's a useful tool; but I'd never trust it in a CI environment or anywhere that a human would not review it afterwards | |
| 19:13:48 | sean-k-mooney[m] | with pre-commit or tox or both | |