Wednesday, 2023-02-01

clarkbzzzeek: hey re that zuul sqla 2.0 thing I've narrowed it down to these two lines https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/sql/sqlconnection.py#L312-L313 holding a SHARED_HIGH_PRIO lock on alembic version which causes the alembic run_migrations later to sit pending on its EXCLUSIVE lock on that table (needs exclusive to create the table)00:03
clarkbzzzeek: I tried sticking the get_current_revision in a context.begin_transaction(): context manager and that doesn't seem to help00:04
clarkbbut if I set the revision to None (which is what we get back according to logging) and don't call get_current_revision then it proceeds and tests succeed00:05
clarkbthis is a mysql db schema created for this single test so that is what I expect as far as get_current_revision values. There is no revision because its a brand new schema00:05
clarkband if I show tables on the schema I see the zuul tables are created so expect we're hanging up on the stamp call on line 32900:06
clarkboh wait I think I see it now. Is it because we're under the egine.begin() for both?00:08
clarkbmaybe if I split that into two begins there will be a separation of transactions?00:08
JayFclarkb: that sounds 100% correct00:08
JayFclarkb: based on my review of Ironic SQLA 2.0 fix patches 00:09
clarkbya in fact I think I don't need two context managers00:11
clarkbI just need to not nest the alembic work under the same transaction as the version retrieval00:11
JayFI believe each context manager might be making you a txn00:11
JayF(my advice may be stricter than your requirements; Ironic has to be extra careful due to our support for SQLite)00:11
clarkbyup this fixed it00:12
JayF\o/00:12
clarkbhttps://review.opendev.org/c/zuul/zuul/+/872363/ is the resulting change00:41
zzzeekclarkb: that looks to be a front end to the alembic instructions.  so when it calls into alembic.command.upgrade or alembic.command.stamp, the env.py module is invoked which then has to acquire the connection on its own.  if this is not using the identical conneciton that you have right there in "with self.engine.begin() as conn" you open yourself up to deadlocks02:07
zzzeekclarkb: one strategy would be to use "with self.engine.connect() as conn:", then after you run context.get_current_revision(), call connection.rollback().   that will cancel the transaciton in progress so that subseuqent SQL on other connections within env.py will be allowed to proceed02:08
zzzeekthat is 2.0 API which you can get in 1.4 by using future=True on your create_engine() call02:08
*** yadnesh|away is now known as yadnesh04:24
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: Use configparser to read configuration file  https://review.opendev.org/c/openstack/ci-log-processing/+/87170407:12
opendevreviewAde Lee proposed openstack/project-config master: Add base openstack FIPS job  https://review.opendev.org/c/openstack/project-config/+/87222208:16
*** jpena|off is now known as jpena08:23
opendevreviewAde Lee proposed openstack/project-config master: Add base openstack FIPS job  https://review.opendev.org/c/openstack/project-config/+/87222208:28
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: Use configparser to read configuration file  https://review.opendev.org/c/openstack/ci-log-processing/+/87170408:35
opendevreviewAde Lee proposed openstack/project-config master: Add base openstack FIPS job  https://review.opendev.org/c/openstack/project-config/+/87222208:59
opendevreviewMerged openstack/ci-log-processing master: Use configparser to read configuration file  https://review.opendev.org/c/openstack/ci-log-processing/+/87170409:22
*** rlandy|out is now known as rlandy11:11
*** dviroel|uot is now known as dviroel|rover11:30
opendevreviewVishal Manchanda proposed openstack/project-config master: Step 1: End Project Gating, Retire xstatic-font-awesome  https://review.opendev.org/c/openstack/project-config/+/87170311:47
opendevreviewVishal Manchanda proposed openstack/project-config master: Step 1: End Project Gating, Retire xstatic-font-awesome  https://review.opendev.org/c/openstack/project-config/+/87170311:49
opendevreviewAlex Kavanagh proposed openstack/project-config master: Add charms-stable-maint group for charms projects  https://review.opendev.org/c/openstack/project-config/+/87240612:19
opendevreviewAlex Kavanagh proposed openstack/project-config master: Add charms-stable-maint group for charms projects  https://review.opendev.org/c/openstack/project-config/+/87240612:47
opendevreviewAlex Kavanagh proposed openstack/project-config master: Add charms-stable-maint group for charms projects  https://review.opendev.org/c/openstack/project-config/+/87240612:59
opendevreviewVishal Manchanda proposed openstack/project-config master: Step 1: End Project Gating, Retire xstatic-font-awesome  https://review.opendev.org/c/openstack/project-config/+/87170313:02
*** dasm|off is now known as dasm13:44
*** yadnesh is now known as yadnesh|away14:35
ralonsohclarkb, hi! I think this is the correct channel15:04
ralonsohdo you mind reviewing https://review.opendev.org/c/openstack/project-config/+/872275? 15:05
ralonsohthanks in advance!15:05
*** dviroel|rover is now known as dviroel|rover|lunch15:06
*** dviroel|rover|lunch is now known as dviroel|rover15:57
clarkbralonsoh: change lgtm but two pieces of feedback: first is I wonder if it would be better to connect to the sqlalchemy gerrit instead (I don't actually now) and second I wonder if this is a reaction to the 2.0 release and whether or not it is useful long term? sqlalchemy typically has really good compatibility and this was all well communicated in docs, release notes, and16:12
clarkbversion numbers16:12
ralonsohclarkb, yes, this is a quick reaction to sqlalchemy 2.0. The goal is to have periodic jobs (tempest + functional) running with master sqlachemy16:13
ralonsohthis will be temporary, at least during the next release when we are migrating to sqla 2.016:13
clarkbya so imo that is probably more trouble than it is worth. If a major release happens once every 6 years or whatever then I'm not sure anyone is really going to pay attention to those jobs16:14
ralonsohand most probably, new minor versions will be pushed16:14
ralonsohbut we do weekly in Neutron16:14
clarkbthe issue is going from 1.4 to 2.0 which has laready happened and can be tested with pypi pacakges16:14
clarkbbut I've approved the change and yall can prove me wrong16:14
clarkbI just don't expect 2.x to create similar issues16:15
ralonsohI hope so but we'll check that weekly in the Neutron CI meeting16:15
ralonsohjust in case16:15
ralonsohand if that proves to be stable, we'll remove those jobs then16:15
ralonsohbtw, thanks!16:15
opendevreviewdaniel.pawlik proposed openstack/ci-log-processing master: DNM Add timeout parameter to avoid freeze  https://review.opendev.org/c/openstack/ci-log-processing/+/87242516:24
opendevreviewMerged openstack/project-config master: Add github sqlalchemy/sqlalchemy to the project list  https://review.opendev.org/c/openstack/project-config/+/87227516:28
*** rpittau is now known as elfosardo16:34
*** elfosardo is now known as rpittau16:43
*** jpena is now known as jpena|off16:52
fungiclarkb: looking at pypi's ui, the only way i see to tell owners and maintainers apart is the collaboration subpage of the manage/project interface, which you can't access unless you have at least maintainer (maybe has to be owner) on that project. i can see it on some personal projects where i'm in the owner role, but not e.g. an openstack project16:59
fungiso while people who do have some permissions on the project can tell whether or nor they're owner, nobody else can, even when logged in17:00
clarkbfungi: at least the info is available I guess? but that makes it difficult to consume.17:00
fungiyeah, basically if the question is "what projects is openstackci owner for" we can really only answer that by either hearing back from other owners on each project or checking it as the openstackci project17:01
fungi(also to be clear, i wasn't proposing that we script removal of the other users, i was talking about the necessity of scripting something if we have to query hundreds of projects in order to find out which ones we have control over)17:02
clarkbya, I'm just thinking if we need to contact people to prevent panic anyway we may as well push down that path as much as possible17:02
clarkbjust thinking about aeva for example I'm sure if we randomly deleted access that would create concern17:02
fungiagreed, if reaching out to people whittles the number down to a subset that's reasonable to check through the webui then scripting the query wouldn't necessarily be required17:03
fungii agree that reaching out to people is necessary either way, but doing it first can make whatever needs doing as openstackci easier17:04
clarkbexactly17:05
clarkbalso our docs indicate openstackci should be maintainer not owner. For the older packages that twine didn't set up I expect we're relying on others anyway17:08
fungiyes. in fact we mention maintainer because we assume in general cases that the original owner will want to retain control of the project and the ability to manage it on pypi without burdening us with requests17:10
fungiand maintainer is the minimum set of permissions we need to be able to publish releases17:10
clarkbfungi: talking out loud here: one option instead of scraping would be to try and add a "backup" account using openstackci. Backup account is something we've discussed on the list as possibly being useful (something more cold storage that can be the actual owner). And if that works we've got ownership and done some useful work. If it fails we are just maintainer17:12
clarkbbut maybe that is needlessly complicating things17:13
JayFclarkb: I already reached out to Aeva fwiw :D and proactively have reached out to several (but not 100%) of the names listed for Ironic 17:20
JayF(as a nice side effect, hopefully will get to have some coffee and catch up since we're both in wa.us)17:20
clarkbnice!17:23
clarkbI don't spend as much time up there as I'd like now that I have kids. Having lived both in the portland and seattle areas we've done a fair bit of back and forth in the past though17:32
*** dviroel_ is now known as dviroel|rover_18:36
*** dviroel|rover_ is now known as dviroel|rover18:38
*** gibi is now known as gibi_pto19:04
fungiclarkb: i was going to mention something similar. it would also give us the opportunity to de-openstackize our presence on pypi over time with an opendev account19:07
fungi"opendev" is (unsurprisingly) already taken19:09
fungii've created an account called opendev.org in case we want to use it19:10
*** dviroel_ is now known as dviroel|rover19:51
*** rlandy is now known as rlandy|out22:19
*** dasm is now known as dasm|off22:40
opendevreviewIan Wienand proposed openstack/project-config master: nodepool: infra-package-needs; drop curl  https://review.opendev.org/c/openstack/project-config/+/87247323:16
opendevreviewIan Wienand proposed openstack/project-config master: nodepool: infra-package-needs; cleanup python  https://review.opendev.org/c/openstack/project-config/+/87247623:58
opendevreviewIan Wienand proposed openstack/project-config master: nodepool: infra-package-needs; remove lvm2  https://review.opendev.org/c/openstack/project-config/+/87247723:58
opendevreviewIan Wienand proposed openstack/project-config master: nodepool: infra-package-needs; cleanup tox installs  https://review.opendev.org/c/openstack/project-config/+/87247823:58

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!