| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-11 | |||
| 15:38:27 | sean-k-mooney | he will be around tomorrow | |
| 15:38:29 | bauzas | kk | |
| 15:38:50 | sean-k-mooney | we can chat about it in the team meeting tomrowow if you like | |
| 15:39:02 | bauzas | sean-k-mooney: and I assume you want to address this in this cycle so that the SQLA 2 bump is considered 100% complete for Bobcat ? | |
| 15:39:10 | sean-k-mooney | yes | |
| 15:39:30 | sean-k-mooney | i want that to be one of our cycle highlights for what its worth | |
| 15:39:48 | bauzas | in the prelude if you want | |
| 15:40:09 | bauzas | cycle highlights are tend to be marketing-readable | |
| 15:40:18 | sean-k-mooney | well i would be happy even if its in the normaly release notes since all of the above means we finsihed it :) | |
| 15:40:44 | bauzas | I mean, don't get me wrong | |
| 15:40:48 | bauzas | this looks a quickwin | |
| 15:41:05 | sean-k-mooney | well support for sqlachemy 2.0 is good but we need all the other proejct to also support it before we can fully claim victory | |
| 15:41:06 | bauzas | and I wouldn't disagree merging such things | |
| 15:42:06 | sean-k-mooney | for what its worth this was first propsed 11 months ago and we punted it once already | |
| 15:42:13 | bauzas | a long time before in a very far galaxy, we had a DB job | |
| 15:42:29 | bauzas | that was ensuring our performance was stable | |
| 15:42:54 | bauzas | sean-k-mooney: I get your frustration and again, I'm not against merging it | |
| 15:42:59 | bauzas | I'm just asking for clarification | |
| 15:43:03 | bauzas | and visibility | |
| 15:43:22 | sean-k-mooney | yep i understand | |
| 15:48:41 | opendevreview | Merged openstack/nova master: doc: mark the maximum microversion for 2023.2 Bobcat https://review.opendev.org/c/openstack/nova/+/893742 | |
| 16:11:46 | opendevreview | sean mooney proposed openstack/nova-specs master: replace() argument 1 must be str, not _StrPath https://review.opendev.org/c/openstack/nova-specs/+/894553 | |
| 16:12:46 | sean-k-mooney | bauzas: ^ that will fix the nova-specs docs job | |
| 16:42:27 | opendevreview | Merged openstack/nova master: adapt to oslo.log changes https://review.opendev.org/c/openstack/nova/+/894538 | |
| 16:59:27 | opendevreview | Merged openstack/nova-specs master: replace() argument 1 must be str, not _StrPath https://review.opendev.org/c/openstack/nova-specs/+/894553 | |
| 17:04:09 | atmark | hello, is possible to migrate cell back to non cell on existing deployment? | |
| 17:07:50 | dansmith | atmark: there's no "non-cell" mode in nova | |
| 17:08:08 | dansmith | maybe explain more about what you're trying to do | |
| 18:41:03 | greatgatsby_ | Hello. Our host aggregates seem to get out of sync with our provider aggregates. There seems to be a `nova-manage placement sync_aggregates` command, but we're confused how they're getting out of sync in the first place. Any suggestions of what could be the cause? This is deployed via kolla-ansible yoga | |
| #openstack-nova - 2023-09-12 | |||
| 07:00:38 | elodilles | sean-k-mooney bauzas : oslo.log upper bump patch's tests are passing now \o/ https://review.opendev.org/c/openstack/requirements/+/892928 | |
| 07:00:41 | elodilles | thanks sean-k-mooney o/ | |
| 07:26:47 | bauzas | good to hear | |
| 07:36:57 | frickler | ack, thx for fixing this. sean-k-mooney would you reconsider your -1 on 892928 then? | |
| 08:00:10 | stephenfin | bauzas: around now | |
| 08:02:37 | bauzas | stephenfin: wrapping a few things now, but to;dr: would like to discuss any performance hit on https://review.opendev.org/c/openstack/nova/+/860829 | |
| 08:02:47 | bauzas | stephenfin: read above my comments | |
| 08:03:26 | bauzas | my only concern is to make sure that if land quite late in the cycle this change, we wouldn't see any performance change in terms of SQL execution plan | |
| 08:03:42 | stephenfin | ah, so that won't actually bump us to SQLAlchemy 2.x: it only prepares us for it | |
| 08:03:54 | bauzas | since most of the calls are changing queries against instances or instance extras | |
| 08:04:05 | bauzas | stephenfin: yeah yeah gotcha | |
| 08:04:10 | bauzas | it's a new 1.4 feature | |
| 08:04:19 | bauzas | and I've done my homework | |
| 08:04:24 | stephenfin | and there should be no impact to the SQL actually generated for 1.4 as it's merely a different way to describe the same thing | |
| 08:04:28 | bauzas | the objects relationships diffezr | |
| 08:04:42 | stephenfin | the relationships haven't changed. All that has changed is how we describe them | |
| 08:04:45 | bauzas | but the docs don't tell anything about the executed JOINs | |
| 08:05:18 | bauzas | stephenfin: that's my natural first thoughts, but then I wonder if the description change may arise some query modification | |
| 08:05:24 | stephenfin | this model is preferred because it's more explicit and iiuc allows for type hinting without a separate plugin | |
| 08:05:31 | bauzas | since relationships are now both-ways | |
| 08:06:07 | stephenfin | they were always both ways | |
| 08:06:23 | stephenfin | for example: look at the first thing we modified in https://review.opendev.org/c/openstack/nova/+/860829/1/nova/db/api/models.py | |
| 08:06:37 | stephenfin | sorry, https://review.opendev.org/c/openstack/nova/+/860829/1/nova/db/api/models.py#b150 (with anchor) | |
| 08:07:05 | stephenfin | that's saying the local side is called 'host_mapping' and the remote side is called 'cell_mapping' | |
| 08:07:16 | stephenfin | as defined by the backref | |
| 08:07:39 | stephenfin | now, instead of declaring both of these on one side, we declare it on both sides | |
| 08:08:20 | stephenfin | so if anything it's a bit more duplication but for the advantage of explicitness and readability/parseability | |
| 08:16:39 | stephenfin | bauzas: here, compare the output of these. First, with backref: https://paste.opendev.org/show/bD4K8pJoSl212q37kvEZ/ | |
| 08:16:48 | stephenfin | then, with back_populates: https://paste.opendev.org/show/bonhcuiyNJtYmM0wITE0/ | |
| 08:17:00 | bauzas | excellent, that's what I was testing | |
| 08:17:09 | stephenfin | they're modified versions of my examples from https://that.guru/blog/sqlalchemy-relationships-without-foreign-keys/ | |
| 08:17:23 | stephenfin | spoiler: it's the same SQL | |
| 08:18:32 | bauzas | so the main thing to doublecheck is that the implicit relationship that was given by the other way is now explicit in the object | |
| 08:18:41 | bauzas | right? | |
| 08:18:56 | bauzas | because if not, we regress by loosing a JOIN | |
| 08:19:41 | stephenfin | yeah, that makes sense | |
| 08:50:14 | opendevreview | Merged openstack/os-vif stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/os-vif/+/894060 | |
| 09:44:53 | bauzas | stephenfin: I may have spotted a problem with bdms.deleted https://review.opendev.org/c/openstack/nova/+/860829 | |
| 09:45:15 | bauzas | stephenfin: I need to go off the keyboard for gym reasons but I'll be back in the afternoon | |
| 09:50:19 | kashyap | Hehe, "gym reasons" | |
| 10:56:17 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused relationships https://review.opendev.org/c/openstack/nova/+/894635 | |
| 12:25:45 | bauzas | kashyap: I don't know how to call what I do :) let's say physical prep :) | |
| 13:01:29 | kashyap | Heh, I was just joking, dont' worry :) | |
| 13:34:58 | stephenfin | bauzas: you saw my reply, I assume? | |
| 13:35:18 | stephenfin | i can squash if you'd like but it's much of a muchness given it's "dead code" | |
| 13:35:20 | bauzas | stephenfin: I was literally seconds before pinging you | |
| 13:36:02 | bauzas | stephenfin: my only concern is that I need to check why we have this bdm relationship and I don't trust our test coverage for saying whether it's unused or not | |
| 13:36:32 | bauzas | at least I certainly understand why the backref was limiting to existing BDMs and not the deleted ones | |
| 13:37:50 | bauzas | stephenfin: wouldn't be easier to change the relationship in your first change to continue querying the non-deleted BDMs, and *then* remove the relationship later ? | |
| 13:38:05 | stephenfin | it would but then I need to rebase and lose the +2s :) | |
| 13:38:14 | bauzas | so, we could somehow merge the first one in Bobcat while the latter would be in Caracal | |
| 13:38:41 | bauzas | stephenfin: if this is just about a +2, we can ping sean-k-mooney :) | |
| 13:44:22 | stephenfin | Okay, once I know it won't take many months before it's looked at again :) I'll respin shortly after my current meeting | |
| 13:48:55 | bauzas | sure, I'll look | |
| 13:49:10 | bauzas | again, matter of priorities, y'know< | |
| 14:14:17 | opendevreview | Merged openstack/nova-specs master: Create specs directory for 2024.1 Caracal https://review.opendev.org/c/openstack/nova-specs/+/889177 | |
| 14:30:02 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Replace use of backref https://review.opendev.org/c/openstack/nova/+/860829 | |
| 14:30:02 | opendevreview | Stephen Finucane proposed openstack/nova master: objects: Stop fetching from security_groups table https://review.opendev.org/c/openstack/nova/+/860850 | |
| 14:30:03 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused relationships https://review.opendev.org/c/openstack/nova/+/894635 | |
| 14:30:10 | stephenfin | bauzas: sean-k-mooney: ^ | |
| 15:50:09 | bauzas | reminder : nova meeting in 10 mins | |
| 15:50:28 | bauzas | stephenfin: saw your update, thanks, but I need to continue reviewing it | |
| 16:03:28 | bauzas | shit | |
| 16:03:33 | bauzas | #startmeeting nova | |
| 16:03:33 | opendevmeet | Meeting started Tue Sep 12 16:03:33 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:03:33 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:03:33 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:03:39 | bauzas | sorry folks about the late start :) | |
| 16:03:44 | auniyal | o/ | |
| 16:03:46 | gibi | o/ | |
| 16:03:47 | elodilles | o/ | |