clarkb | zzzeek: 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 |
---|---|---|
clarkb | zzzeek: I tried sticking the get_current_revision in a context.begin_transaction(): context manager and that doesn't seem to help | 00:04 |
clarkb | but 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 succeed | 00:05 |
clarkb | this 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 schema | 00:05 |
clarkb | and 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 329 | 00:06 |
clarkb | oh wait I think I see it now. Is it because we're under the egine.begin() for both? | 00:08 |
clarkb | maybe if I split that into two begins there will be a separation of transactions? | 00:08 |
JayF | clarkb: that sounds 100% correct | 00:08 |
JayF | clarkb: based on my review of Ironic SQLA 2.0 fix patches | 00:09 |
clarkb | ya in fact I think I don't need two context managers | 00:11 |
clarkb | I just need to not nest the alembic work under the same transaction as the version retrieval | 00:11 |
JayF | I believe each context manager might be making you a txn | 00:11 |
JayF | (my advice may be stricter than your requirements; Ironic has to be extra careful due to our support for SQLite) | 00:11 |
clarkb | yup this fixed it | 00:12 |
JayF | \o/ | 00:12 |
clarkb | https://review.opendev.org/c/zuul/zuul/+/872363/ is the resulting change | 00:41 |
zzzeek | clarkb: 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 deadlocks | 02:07 |
zzzeek | clarkb: 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 proceed | 02:08 |
zzzeek | that is 2.0 API which you can get in 1.4 by using future=True on your create_engine() call | 02:08 |
*** yadnesh|away is now known as yadnesh | 04:24 | |
opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Use configparser to read configuration file https://review.opendev.org/c/openstack/ci-log-processing/+/871704 | 07:12 |
opendevreview | Ade Lee proposed openstack/project-config master: Add base openstack FIPS job https://review.opendev.org/c/openstack/project-config/+/872222 | 08:16 |
*** jpena|off is now known as jpena | 08:23 | |
opendevreview | Ade Lee proposed openstack/project-config master: Add base openstack FIPS job https://review.opendev.org/c/openstack/project-config/+/872222 | 08:28 |
opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Use configparser to read configuration file https://review.opendev.org/c/openstack/ci-log-processing/+/871704 | 08:35 |
opendevreview | Ade Lee proposed openstack/project-config master: Add base openstack FIPS job https://review.opendev.org/c/openstack/project-config/+/872222 | 08:59 |
opendevreview | Merged openstack/ci-log-processing master: Use configparser to read configuration file https://review.opendev.org/c/openstack/ci-log-processing/+/871704 | 09:22 |
*** rlandy|out is now known as rlandy | 11:11 | |
*** dviroel|uot is now known as dviroel|rover | 11:30 | |
opendevreview | Vishal Manchanda proposed openstack/project-config master: Step 1: End Project Gating, Retire xstatic-font-awesome https://review.opendev.org/c/openstack/project-config/+/871703 | 11:47 |
opendevreview | Vishal Manchanda proposed openstack/project-config master: Step 1: End Project Gating, Retire xstatic-font-awesome https://review.opendev.org/c/openstack/project-config/+/871703 | 11:49 |
opendevreview | Alex Kavanagh proposed openstack/project-config master: Add charms-stable-maint group for charms projects https://review.opendev.org/c/openstack/project-config/+/872406 | 12:19 |
opendevreview | Alex Kavanagh proposed openstack/project-config master: Add charms-stable-maint group for charms projects https://review.opendev.org/c/openstack/project-config/+/872406 | 12:47 |
opendevreview | Alex Kavanagh proposed openstack/project-config master: Add charms-stable-maint group for charms projects https://review.opendev.org/c/openstack/project-config/+/872406 | 12:59 |
opendevreview | Vishal Manchanda proposed openstack/project-config master: Step 1: End Project Gating, Retire xstatic-font-awesome https://review.opendev.org/c/openstack/project-config/+/871703 | 13:02 |
*** dasm|off is now known as dasm | 13:44 | |
*** yadnesh is now known as yadnesh|away | 14:35 | |
ralonsoh | clarkb, hi! I think this is the correct channel | 15:04 |
ralonsoh | do you mind reviewing https://review.opendev.org/c/openstack/project-config/+/872275? | 15:05 |
ralonsoh | thanks in advance! | 15:05 |
*** dviroel|rover is now known as dviroel|rover|lunch | 15:06 | |
*** dviroel|rover|lunch is now known as dviroel|rover | 15:57 | |
clarkb | ralonsoh: 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, and | 16:12 |
clarkb | version numbers | 16:12 |
ralonsoh | clarkb, yes, this is a quick reaction to sqlalchemy 2.0. The goal is to have periodic jobs (tempest + functional) running with master sqlachemy | 16:13 |
ralonsoh | this will be temporary, at least during the next release when we are migrating to sqla 2.0 | 16:13 |
clarkb | ya 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 jobs | 16:14 |
ralonsoh | and most probably, new minor versions will be pushed | 16:14 |
ralonsoh | but we do weekly in Neutron | 16:14 |
clarkb | the issue is going from 1.4 to 2.0 which has laready happened and can be tested with pypi pacakges | 16:14 |
clarkb | but I've approved the change and yall can prove me wrong | 16:14 |
clarkb | I just don't expect 2.x to create similar issues | 16:15 |
ralonsoh | I hope so but we'll check that weekly in the Neutron CI meeting | 16:15 |
ralonsoh | just in case | 16:15 |
ralonsoh | and if that proves to be stable, we'll remove those jobs then | 16:15 |
ralonsoh | btw, thanks! | 16:15 |
opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: DNM Add timeout parameter to avoid freeze https://review.opendev.org/c/openstack/ci-log-processing/+/872425 | 16:24 |
opendevreview | Merged openstack/project-config master: Add github sqlalchemy/sqlalchemy to the project list https://review.opendev.org/c/openstack/project-config/+/872275 | 16:28 |
*** rpittau is now known as elfosardo | 16:34 | |
*** elfosardo is now known as rpittau | 16:43 | |
*** jpena is now known as jpena|off | 16:52 | |
fungi | clarkb: 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 project | 16:59 |
fungi | so while people who do have some permissions on the project can tell whether or nor they're owner, nobody else can, even when logged in | 17:00 |
clarkb | fungi: at least the info is available I guess? but that makes it difficult to consume. | 17:00 |
fungi | yeah, 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 project | 17: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 |
clarkb | ya, 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 possible | 17:02 |
clarkb | just thinking about aeva for example I'm sure if we randomly deleted access that would create concern | 17:02 |
fungi | agreed, 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 required | 17:03 |
fungi | i agree that reaching out to people is necessary either way, but doing it first can make whatever needs doing as openstackci easier | 17:04 |
clarkb | exactly | 17:05 |
clarkb | also 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 anyway | 17:08 |
fungi | yes. 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 requests | 17:10 |
fungi | and maintainer is the minimum set of permissions we need to be able to publish releases | 17:10 |
clarkb | fungi: 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 maintainer | 17:12 |
clarkb | but maybe that is needlessly complicating things | 17:13 |
JayF | clarkb: 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 |
clarkb | nice! | 17:23 |
clarkb | I 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 though | 17:32 |
*** dviroel_ is now known as dviroel|rover_ | 18:36 | |
*** dviroel|rover_ is now known as dviroel|rover | 18:38 | |
*** gibi is now known as gibi_pto | 19:04 | |
fungi | clarkb: 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 account | 19:07 |
fungi | "opendev" is (unsurprisingly) already taken | 19:09 |
fungi | i've created an account called opendev.org in case we want to use it | 19:10 |
*** dviroel_ is now known as dviroel|rover | 19:51 | |
*** rlandy is now known as rlandy|out | 22:19 | |
*** dasm is now known as dasm|off | 22:40 | |
opendevreview | Ian Wienand proposed openstack/project-config master: nodepool: infra-package-needs; drop curl https://review.opendev.org/c/openstack/project-config/+/872473 | 23:16 |
opendevreview | Ian Wienand proposed openstack/project-config master: nodepool: infra-package-needs; cleanup python https://review.opendev.org/c/openstack/project-config/+/872476 | 23:58 |
opendevreview | Ian Wienand proposed openstack/project-config master: nodepool: infra-package-needs; remove lvm2 https://review.opendev.org/c/openstack/project-config/+/872477 | 23:58 |
opendevreview | Ian Wienand proposed openstack/project-config master: nodepool: infra-package-needs; cleanup tox installs https://review.opendev.org/c/openstack/project-config/+/872478 | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!