Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-09-11
15:37:32 bauzas I hope you understand my concern : if we merge anything so far in the cycle that would impact the query time on some large and frequently called records like instance or instance info cache, operators would jump on our throats
15:38:04 bauzas stephenfin: around ?
15:38:06 sean-k-mooney bauzas: i do but i dont think that is a reason not to merge this
15:38:20 sean-k-mooney no ne just left to head into the city
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: objects: Stop fetching from security_groups table https://review.opendev.org/c/openstack/nova/+/860850
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: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 opendevmeet The meeting name has been set to 'nova'
16:03:33 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
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 bauzas #startmeeting nova

Earlier   Later