| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-07 | |||
| 17:41:21 | sean-k-mooney | the scudler still selectied one of the 5 to do the build | |
| 17:41:30 | sean-k-mooney | what really changed is it wotn rebalance | |
| 17:41:31 | JayF | so a Nova+Ironic user will have to nontrivially change the devops automation around building their compute services, even if they aren't going to be sharding anymore | |
| 17:41:37 | sean-k-mooney | if the service died | |
| 17:42:09 | JayF | if the service died, any instances it was managing would not be able to be managed, but you'd retain access to all the ironic capacity thru its peers | |
| 17:42:27 | sean-k-mooney | to the avaiable nodes yes | |
| 17:42:30 | JayF | now if you want to maintain access to that capacity, you'd need something like e.g. a cold standby compute service to spin up and restore that access | |
| 17:42:41 | sean-k-mooney | yep | |
| 17:43:06 | sean-k-mooney | cold standby or a tool like k8s that will recreat the comptue agent with the same name/config elsewhere | |
| 17:43:09 | JayF | this is a pretty radical change from how nova compute services have been treated alongside Ironic ... probably the largest since the actual deprecation of the clusteredcomputemanager back in like, Juno | |
| 17:43:26 | JayF | so yeah, it's going to be in Ironic cycle highlights and I'll talk about it, but it should be in Nova too | |
| 17:44:02 | JayF | tbh this is sorta a win for unity in OpenStack overall, we're removing what has traditionally been a significant point of technical tension between Ironic/Nova, we should all celebrate it :D | |
| 17:44:27 | sean-k-mooney | JayF: for me the real highlight willl be when we delete the peer_list code in 2024.2 | |
| 17:44:46 | JayF | I mean, that's really the culmination of the pieces I'm talking about | |
| 17:44:54 | sean-k-mooney | but sure we can mention it i just would have epected the highlights to be framed mainly in the context of new featurs | |
| 17:45:31 | JayF | My background is sorta, in-the-weeds operations traditionally, so I tend to bristle at "look at the new shiny" without calling out the tradeoff made | |
| 17:45:39 | JayF | but I'm one vote out of many on how it gets framed, so we'll see how it works out | |
| 17:45:56 | sean-k-mooney | well the intent of the highlights is to be short | |
| 17:46:05 | sean-k-mooney | we also have the release notes | |
| 17:46:09 | JayF | I hope johnthetubaguy weighs in on that though, I think he has a pretty good view on what this would mean across a wider variety of environments than I have | |
| 17:46:22 | sean-k-mooney | but again im not agaisnt advertising the change in driection so more peopel see it | |
| 17:47:03 | sean-k-mooney | next cycle im expectign the highlights to include the deletion of the hyperv and vmware dirvers... | |
| 17:47:38 | sean-k-mooney | that woudl be both a highlight and a lowlight | |
| 17:47:55 | JayF | interesting, that means that at least at the virt driver layer, you've gotten rid of most of the centralized drivers *or* we've added a mechanism to make them shardable | |
| 17:47:59 | JayF | yeah? | |
| 17:48:20 | sean-k-mooney | well we marked them as experimeental and almost deleted vmware 2 before | |
| 17:48:27 | gmann | hyperv can definitely go in as ow-win is gone now and I am going to remove the all deps of it once 2024.1 is open | |
| 17:48:47 | sean-k-mooney | the removal is becasue of 0 testing or maintainces for basicely 2-3 years | |
| 17:49:27 | sean-k-mooney | gmann: i was goign to bring this up on the ptg adgenda but ya that why i mentioned hyperv i was aware of the os-win dep issue | |
| 17:49:42 | gmann | sure | |
| 17:49:59 | sean-k-mooney | we have similar issues with oslo.vmware i think | |
| 17:50:36 | gmann | oslo.vmware is still there not sure what status but it is not retired yet | |
| 17:51:27 | sean-k-mooney | it looks like it had 6ish patches since last cycle | |
| 17:51:45 | sean-k-mooney | the issue in the past was with its use of studs-jarako or whatever it was | |
| 17:52:18 | sean-k-mooney | its now using suds-community | |
| 17:52:28 | sean-k-mooney | but i dont know if that is healty or not | |
| 17:52:49 | sean-k-mooney | last release was a year ago "Jun 28, 2022" | |
| 17:53:27 | sean-k-mooney | it officlally supprot up to 3.9 but i dont knwo if we will start seeing issues with 3.11 | |
| 17:53:52 | sean-k-mooney | 3.10 and 3.11 started removing some deperecated features | |
| 22:21:31 | opendevreview | Merged openstack/python-novaclient master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894077 | |
| #openstack-nova - 2023-09-08 | |||
| 09:28:45 | opendevreview | liwenjian proposed openstack/nova master: Fixed an error when caching multiple images in aggregate https://review.opendev.org/c/openstack/nova/+/894288 | |
| 18:52:04 | atmark | hello, I have 8 computes and all showed up I ran `nova-manage cell_v2 list_hosts` however, `nova-manage cell_v2 discover_hosts --verbose` showed only 6 computes | |
| 18:52:06 | atmark | https://paste.openstack.org/show/bGqEX1e8TPAsE2zHsEO1/ | |
| 18:53:03 | atmark | running stable/victoria | |
| 19:02:05 | dansmith | atmark: the list shows that they're mapped. if you run discover again, does it continue to show only six? I think it should show none now | |
| 19:10:46 | atmark | yes, it's still showing six | |
| 19:11:47 | atmark | I ran discover multiple times and returns six | |
| #openstack-nova - 2023-09-11 | |||
| 02:53:00 | opendevreview | Ghanshyam proposed openstack/nova master: Remove the Hyper-V driver https://review.opendev.org/c/openstack/nova/+/894466 | |
| 07:00:06 | frickler | the new oslo.log release seems to need changes in nova unit tests, please check https://review.opendev.org/c/openstack/requirements/+/892928 | |
| 08:22:00 | bauzas | frickler: looking | |
| 09:12:15 | sean-k-mooney | frickler: we are passed the non client lib freeze | |
| 09:12:25 | sean-k-mooney | why is there a 5.3.0 happening now | |
| 09:24:00 | bauzas | my bad, I thought it was related to https://bugs.launchpad.net/ironic/+bug/2030976 but actually no, so indeed this isn't an urgency, right? | |
| 09:24:24 | bauzas | anyway, this is u-c, not a nova change | |
| 09:24:29 | sean-k-mooney | it would break master when it becomes caracl | |
| 09:24:55 | sean-k-mooney | the reason im askin gis do then intend 5.3.0 to be part of bobcat or not | |
| 09:25:52 | sean-k-mooney | we have not cut RC1 yet | |
| 09:26:15 | sean-k-mooney | so we shoudl not really be merging any changes for this until after that is done | |
| 09:26:30 | bauzas | https://docs.openstack.org/releasenotes/oslo.log/unreleased.html | |
| 09:26:46 | bauzas | if this is just for deprecating os-win, meh | |
| 09:27:12 | sean-k-mooney | deprecations need to go out in a slurp anyway so i think this can wait | |
| 09:27:30 | bauzas | sean-k-mooney: but maybe frickler wants to merge this u-c change after RC1 ? | |
| 09:27:33 | sean-k-mooney | it must contain something else too | |
| 09:27:58 | sean-k-mooney | ya perhaps and that is fine | |
| 09:28:34 | sean-k-mooney | i woudl just prefer to hold this until RC1 is cut but once it is we can correect whatever the unit test fallout is | |
| 09:29:18 | sean-k-mooney | https://github.com/openstack/oslo.log/compare/5.2.0...5.3.0 | |
| 09:29:27 | bauzas | https://github.com/openstack/oslo.log/compare/5.3.0...5.2.0 | |
| 09:29:31 | bauzas | heh | |
| 09:29:46 | sean-k-mooney | https://github.com/openstack/oslo.log/commit/6abf69e194c9dac13d26bca3e7ac1f710f9e26a0 | |
| 09:29:58 | sean-k-mooney | so they are droping 3.8 support | |
| 09:30:02 | sean-k-mooney | that is why its breaking things | |
| 09:30:10 | sean-k-mooney | so this cant merge in bobcat | |
| 09:30:25 | bauzas | right | |
| 09:31:01 | bauzas | and the relnotes are actually silent, which is sad | |
| 09:32:35 | sean-k-mooney | i -1'd the uc patch | |
| 09:32:58 | sean-k-mooney | and linked to the relevent commits and upstream runtimes | |
| 09:34:20 | sean-k-mooney | funillay enough this failind in the py310 job | |
| 09:34:23 | sean-k-mooney | https://6bd5f66fe830a1e3af93-5011cbf696878119f18f8b3f0098ae5d.ssl.cf1.rackcdn.com/892928/1/check/cross-nova-py310/9f15891/testr_results.html | |
| 09:36:07 | bauzas | sorry for lagging but this morning, I'm switching from 4G to fiber (which is back, woohooo) and testing a few things | |
| 09:36:53 | bauzas | I have an unifi USG as my home gateway and I'm tempted to stick with a passive HA mode with 4G :) | |
| 09:37:02 | elodilles | bauzas sean-k-mooney : the release is part of bobcat and it was released in time. when the release is out, then a requirements patch (upper-constraint bumping patch) is generated, that tests compatibility. this seems to be failing now | |
| 09:37:24 | bauzas | elodilles: I don't disagree | |
| 09:37:31 | sean-k-mooney | elodilles: well as i noted that oslo tag increases the min python to 3.9 | |
| 09:37:40 | bauzas | elodilles: but we're just saying that we can't import it in our bobcat release | |
| 09:37:49 | sean-k-mooney | elodilles: so it cannot be inclucded in bobcat without reverting that | |
| 09:37:54 | bauzas | anyway, kids taxi for a couple of mins | |
| 09:38:57 | sean-k-mooney | on wait... | |
| 09:39:12 | sean-k-mooney | 2023.2 i bobcat | |
| 09:39:28 | sean-k-mooney | ok actully it can be incled but i would still consider this late | |
| 09:39:59 | elodilles | sean-k-mooney: it didn't drop py38 support. py38 is still the min python | |
| 09:40:17 | sean-k-mooney | no it did https://github.com/openstack/oslo.log/commit/6abf69e194c9dac13d26bca3e7ac1f710f9e26a0 | |
| 09:40:21 | sean-k-mooney | python_requires = >=3.9 | |
| 09:40:41 | sean-k-mooney | but 2023.2 is bobcat and bocat technially did drop 3.8 support | |
| 09:40:55 | sean-k-mooney | however we didnt put in a min python_requires in nova | |
| 09:41:17 | sean-k-mooney | we did attempt too but there was objections to that as it would break other porjects that did not have that change | |
| 09:41:39 | elodilles | sean-k-mooney: all the py38 patches were reverted. here i see: https://opendev.org/openstack/oslo.log/src/commit/b5b8c30b0d925aa3d31b58932c94586631827b62/setup.cfg#L9 | |
| 09:42:02 | elodilles | * py38 dropping patches | |
| 09:42:12 | sean-k-mooney | oh just reread the runtimes patch too """All Python-based projects must additionally target and test against following Python versions: | |
| 09:42:14 | sean-k-mooney | Python 3.8 (available as default in Ubuntu 20.04) | |
| 09:42:16 | sean-k-mooney | " | |