| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Revert "Use SQLAlchemy native pre-ping" https://review.opendev.org/c/openstack/oslo.db/+/895621 | 09:20 |
|---|---|---|
| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Revert "Remove dead code" https://review.opendev.org/c/openstack/oslo.db/+/895622 | 09:20 |
| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Revert "Remove sqlalchemy-migrate" https://review.opendev.org/c/openstack/oslo.db/+/895623 | 09:20 |
| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Add back imports in sqlalchemy/utils.py https://review.opendev.org/c/openstack/oslo.db/+/895624 | 09:20 |
| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Revert "Get test suite to full pass with SQLAlchemy 2.0" https://review.opendev.org/c/openstack/oslo.db/+/895625 | 09:20 |
| frickler | stephenfin: ^^ I think I messed up a rebase in between, pushing anyway now so we can run some depends-on testing | 09:21 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db master: Temporarily re-add autocommit support https://review.opendev.org/c/openstack/oslo.db/+/895626 | 09:22 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db master: Temporarily re-add autocommit support https://review.opendev.org/c/openstack/oslo.db/+/895626 | 09:31 |
| frickler | stephenfin: note that you'd only need to patch 2023.2, the plan is to enforce newer oslo.db for caracal unless you have some objection to that | 09:36 |
| stephenfin | ack | 09:51 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db master: Temporarily re-add migration helpers, tests https://review.opendev.org/c/openstack/oslo.db/+/895630 | 09:58 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db stable/2023.2: Temporarily re-add autocommit support https://review.opendev.org/c/openstack/oslo.db/+/895631 | 09:59 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db stable/2023.2: Temporarily re-add migration helpers, tests https://review.opendev.org/c/openstack/oslo.db/+/895632 | 09:59 |
| stephenfin | frickler: Let's see how that performs | 10:00 |
| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Revert "Remove sqlalchemy-migrate" https://review.opendev.org/c/openstack/oslo.db/+/895623 | 10:02 |
| opendevreview | Dr. Jens Harbott proposed openstack/oslo.db stable/2023.2: Revert "Get test suite to full pass with SQLAlchemy 2.0" https://review.opendev.org/c/openstack/oslo.db/+/895625 | 10:02 |
| stephenfin | frickler: Okay, the combo of my two patches in enough to get heat fixed. Now testing with Manila | 10:34 |
| stephenfin | manila UTs pass also | 10:44 |
| frickler | stephenfin: that sounds good, I'm just wondering whether the use of "temporarily" is correct, since these changes will be permanent for the stable/2023.2 series | 11:35 |
| stephenfin | fair point | 11:36 |
| frickler | also, do you want to make testing patches for this from the integrated projects or do you think unit tests have enough coverage? let me know if you want help with creating patches | 11:36 |
| stephenfin | if we're only proposing those for 2023.2, we probably want to mark them as stable-only also | 11:37 |
| frickler | yes, in particular since I saw that you also started work on heat now, I think it would seem feasible to get sqla 2.0 into caracal finally? | 11:38 |
| frickler | s/started work on/uploaded patches for/ | 11:39 |
| stephenfin | Oh, I'd already done a lot of work on Heat but it is unfortunately still using autocommit. That's the remaining piece | 11:50 |
| stephenfin | and I've done all the work for masakari but no ones reviewed it yet :( | 11:50 |
| stephenfin | *one has | 11:50 |
| stephenfin | masakari UTs pass too | 11:54 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db stable/2023.2: [stable-only] Re-add autocommit support https://review.opendev.org/c/openstack/oslo.db/+/895631 | 12:02 |
| opendevreview | Stephen Finucane proposed openstack/oslo.db stable/2023.2: [stable-only] Re-add migration helpers, tests https://review.opendev.org/c/openstack/oslo.db/+/895632 | 12:02 |
| stephenfin | frickler, hberaud: Okay, I'm relatively confident with those. I'd much rather go with that than the revert given it's more focused and less likely to break the new oslo.db-tips jobs we've been adding all over the place. What other tests do we need to do before merging and cutting a release? | 12:03 |
| frickler | stephenfin: I agree with your patches being the preferred path. regarding testing as I said above, maybe do depends-on patches on nova, neutron, cinder maybe just to ensure there are no regressions? | 12:30 |
| frickler | but I'd also be fine with doing a release first, since it can't get much worse anyway, and then test the released version | 12:31 |
| frickler | also not sure which other oslo cores would need to get involved? | 12:31 |
| stephenfin | iiurc the nova gate is borked rn due to a testtools issues, so I'd be for merging and releasing | 12:31 |
| stephenfin | as you say, it can't get worse | 12:31 |
| frickler | and doing yet another bug fix release on top if needed also wouldn't hurt | 12:33 |
| frickler | stephenfin: speaking of bug, do you think adding a bug report and referencing that in the release notes would be helpful? | 12:34 |
| stephenfin | I think "other oslo cores" == {hberaud} :) | 12:34 |
| stephenfin | that depends on whether oslo.db is using launchpad or storyboard | 12:35 |
| frickler | https://bugs.launchpad.net/oslo.db | 12:38 |
| stephenfin | tbh, i don't know what the bug would say. "oslo.db didn't work with loads of projects and now it (temporarily) does again, but you won't have seen because we never merged the upper-constraint bump to include it"? | 12:40 |
| frickler | hmm, good point. on one hand the u-c bump failing could be seen as CI issue, otoh releasing a version of oslo.db in bobcat that doesn't work with multiple other project's bobcat release could be seen as release bug | 12:51 |
| frickler | hberaud: ^^ maybe we want to discuss this in the release team context? is there a release team bugtracker at all? would it make sense to cover both castellan and oslo.db together? | 12:53 |
| hberaud | stephenfin: ack, thanks. I'll have a look to your patches soon | 14:23 |
| hberaud | frickler: yeah it can't hurt to discuss this in a release team context, but we don't have a release team bugtracker.... however you can add notes there => https://etherpad.opendev.org/p/bobcat-relmgt-tracking (around line 449) | 14:24 |
| hberaud | that's our tasks for our next release meeting (next friday) | 14:25 |
| hberaud | frickler: you should notice that this etherpad section is already covering castellan and oslo.db together | 14:27 |
| frickler | hberaud: yes, I was more thinking of a bug reference that could be added in a release note, I don't think the etherpad is good for that | 14:52 |
| zzzeek | @stephenfin: hi | 17:22 |
| zzzeek | @stephenfin: have not been watching IRC since <employer> as you know moved to slack | 17:22 |
| zzzeek | @stephenfin: to track transaction starts use the event hooks as always: https://docs.sqlalchemy.org/en/20/core/events.html#sqlalchemy.events.ConnectionEvents.begin https://docs.sqlalchemy.org/en/20/core/events.html#sqlalchemy.events.ConnectionEvents.commit etc | 17:23 |
| zzzeek | @stephenfin: then you can put a traceback.dump_stack() in there or whatever you need | 17:23 |
| zzzeek | thats core level transactions. there are separate hooks for the Session's notion of a transaction which encloses zero or more connection-level transactions | 17:24 |
| stephenfin | zzzeek: I figured :) All good | 17:31 |
| zzzeek | stephenfin: looks like things have fallen apart a bit, oops | 17:32 |
| stephenfin | Hmm, okay, that's what I was trying but stestr's capturing of logs and stderr was screwing up my output so I couldn't built a clear timeline of transactions being started and completed (rollback or commit). I'll try with pytest instead and see if I can get something more readable | 17:33 |
| zzzeek | stephenfin: just so you know we're getting pretty close to ready to start 2.1, which means we'd slow down 1.4 releases to basically none | 17:33 |
| stephenfin | Yes, it's fallen apart a little bit. I didn't get Manila closed out and there wasn't enough traction on many of my patches nor anyone picking up the work in the other projects that I didn't get to. Very disappointing :( | 17:36 |
| stephenfin | zzzeek: Didn't know 2.1 was coming out so soon though, not that that's surprising. That's more fuel for the "We must do this in C" fire | 17:37 |
| zzzeek | it's not coming out that soon, we just are going to shift new dev work to 2.1, since we have to sunset python 3.7 and deal with some other compat things that are better for 2.1 | 17:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!