| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-11 | |||
| 15:14:17 | stephenfin | cool, can +2/+W once it's respin | |
| 15:14:20 | stephenfin | *respun | |
| 15:14:26 | bauzas | sean-k-mooney: I thought your print was needed | |
| 15:14:39 | sean-k-mooney | i can add a log for it | |
| 15:14:44 | sean-k-mooney | that was me just debuging things | |
| 15:15:02 | sean-k-mooney | the way we use pbr does not work with the debugger in vscode | |
| 15:15:05 | bauzas | cool, just respin then | |
| 15:15:17 | bauzas | hah | |
| 15:15:37 | bauzas | I personnally rather pdb with an entrypoint I add | |
| 15:15:48 | bauzas | but I understand your ask for walking thru | |
| 15:16:12 | opendevreview | sean mooney proposed openstack/nova master: adapt to oslo.log changes https://review.opendev.org/c/openstack/nova/+/894538 | |
| 15:17:45 | stephenfin | thanks | |
| 15:26:47 | sean-k-mooney | bauzas: i mentioned this to you before but can we also try to land https://review.opendev.org/c/openstack/nova/+/860829 today | |
| 15:33:03 | bauzas | sean-k-mooney: this is just changing the way we query, right? | |
| 15:33:39 | bauzas | my only concern is how much it would impact the SQL query plan | |
| 15:33:53 | sean-k-mooney | we need to do it anyway | |
| 15:33:57 | bauzas | and what would be the impact in terms of performance | |
| 15:34:14 | bauzas | sean-k-mooney: because of SQLA 3, right? | |
| 15:34:34 | bauzas | S/3/2 | |
| 15:34:39 | sean-k-mooney | for 2 yes | |
| 15:34:52 | sean-k-mooney | we are changing the way we describe the join | |
| 15:35:00 | sean-k-mooney | but it should not matiraly chagne the queary | |
| 15:35:04 | bauzas | that, I understood | |
| 15:35:30 | bauzas | ideally, if the execution plan isn't changing, that's a no-brainer | |
| 15:35:40 | bauzas | but I don't know this | |
| 15:35:55 | sean-k-mooney | its been a while since i read the docs but im not expecting it to mofy the executed SQL at all | |
| 15:37:01 | sean-k-mooney | i read https://docs.sqlalchemy.org/en/14/orm/backref.html and stephens blog before reviewing https://that.guru/blog/sqlalchemy-relationships-without-foreign-keys/ | |
| 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" | |