On Tue, 2024-06-11 at 22:36 +0200, Andriy Kurilin wrote:
Hi!
вт, 11 черв. 2024 р. о 16:26 <smooney@redhat.com> пише:
On Tue, 2024-06-11 at 14:09 +0000, Dmitry Tantsur wrote:
Hi,
On 6/10/24 10:30 PM, Daniel Bengtsson wrote:
On 2024-06-10 16:28, Dmitry Tantsur wrote:
If we go with this proposal (which sounds reasonable), we need to carefully look at cotyledon's maintenance. It seems to be on life support by only one volunteer: https://github.com/sileht/cotyledon/commits/main/ You're right but he is pretty active and I don't think it's a big
issue.
How do you judge that? Herve mentioned a PR merging quickly, but that's not a perfect criteria. I have a pet project (rust-openstack) where I also tend to merge PRs quickly. Except when I'm on a vacation or very busy at work, then I can forget about PRs for a month or more.
Note that I'm not saying "let's not use it". I think a reasonable next step, if we decide to research this part, would be to get in touch with the maintainer, understand their plans and their position on adding more maintainers in the future.
i think in one of the other replies they mentioned propsoing it as a deliverbale under the oslo project so if that happens i think the maintainer ship and co installablity (use of upper constratits) issues as well as goverance issues go away
Why do we still rely on SQLAlchemy and do not request Michael Bayer to move the library under OpenStack governance? Most contributions come from a single maintainer. The project already uses Gerrit, so the contribution flow will be similar, right?
Also, do you believe that moving projects under OpenStack governance magically increases project aliveness? Let's discuss the "ldappool" library. It is under OpenStack governance and is required for LDAP integration in Keystone. Is it alive? The last release was on February 26, 2021. This release includes a bug: the usage of a dependency that is missed in requirements.txt - the "six" library. The fix waited for two years to be merged https://review.opendev.org/c/openstack/ldappool/+/805495 , and there is no new release with it. Hm... So, magic OpenStack governance did not help?! How did this happen?
Sorry for these sarcastic questions. I only tried to say that independently of project governance, the project may die and become unmaintained. The only valuable thing is the contributors. Asking a project maintainer to move from "his" development flow to work under OpenStack governance before reducing "his real maintainer's costs" sounds strange. If openstackers start actively contributing to Cotyledon, moving under OpenStack governance as Cotyledon community decision sounds reasonable to me. Otherwise, it doesn't sound nice. It is not "a chicken&egg problem"; the primary action should be obvious.
its not about being in or out of openstack or opendev governance. when i looked at the repo and swap it was using different build tooling was not using upper constraint and may or may not be co installable. for practial pourpuses we would need to make depend-on work in ci which means usign the github zuul integration and ensuring that devstack libs_form_git funcitionatliy works to be able to test changes before they merge. that woudl be simpler if it was hosted on opendev but its not a blocker. cotyledon is using pytest as a test runner instead of stestr so im not sure if that will integrate well with our ci tooling, i.e. we wont have subunit output to render test report for. but that porbaly less problmatic then if it was actully using pytest as the test framework. pytest can produce some nice html report but form normal openstack contibutor point of view a proejct that is not aligned to the PTI will add a slight learing curve especially if contirbutions is via github prs. there is enough divergance form what we normally use in the rest of openstack to potentially be problemaitc in the furutre. for exmaple its not using oslo.logging for logging, its using the pythong logging framework directly so we would need to ensure that it integrated properly with oslo.logging and our exiting log cofniguration that provides. on the doc front it has very little docs in tree and doees not appear to have a 1:1 mapping to the apis provided by oslo serviece. so my initial read is that it probably isn't a suitable drop in replacement in its current state. as oslo.service is a very core part of the services and we expect things like GMR ectra to ingenerate with specific behavior related to the use of sig_user2 so we need to evaluate how Cotyledon is operating system singles given the libary claims "Reload API (on SIGHUP) hooks work in case of you don't want to restarting children A separated API for children process termination and for master process termination " i think this is the relevnet code so it looks like it does not touch sig_user2 https://github.com/sileht/cotyledon/blob/main/cotyledon/_service.py#L221-L23... so the GMR aspect is proably fine what im less sure about is Cotyledon states it does not " facilitate the creation of wsgi application (sockets sharing between parent and children process). Because too many wsgi webserver already exists. " however nova does use that functionality in oslo.service https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi_app.py so that is a potentially a blocker for nova to use it unless we rewirte how our wsgi applicaiton works. for what its worth iwould nto be agaissnt replaceign our current usage with flask or similar but a project that was built to replce oslo.service for celimiter is not nesssiasarly a good fit for all other openstack porjects that use oslo.service. so to me Cotyledon has a lot of open question that woudl need to be answered not related to the governance
Dmitry
-- Daniel Bengtsson Software Engineer