[oslo] Remove eventlet from openstack.
Hi there, In the project to remove eventlet from openstack[1], we need to adapt oslo.service. The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it and replace it with cotyledon and futurist. The cotyledon project was created by openstack maintainers to replace oslo.service. It is already used in openstack by the telemetry project, for example. The oslo.service project has been created on top of eventlet to offer two main functionalities, periodic tasks and workers process management. The first feature has been replaced by another library called futurist[2] and the second is surpassed by cotyledon. More details in the project readme[3] about the difference with oslo.service. I would like to have your feedback and opinion on the deprecation of olso.service and it's replacement by cotyledon and futurist. In any case, we'll have to adapt the project, which is why replacing oslo.service with cotyledon seems to me the best solution, rather than having two similar projects doing the same thing. [1] https://review.opendev.org/c/openstack/governance/+/902585 [2] http://docs.openstack.org/developer/futurist/ [3] https://github.com/sileht/cotyledon/blob/main/README.rst -- Daniel Bengtsson Software Engineer
On 2024-06-10 11:09:44 +0200 (+0200), Daniel Bengtsson wrote: [...]
The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it [...]
It's probably worth clarifying that you don't mean "deprecate" in the sense we use it in OpenStack governance[*] (deleting all content from the master branch of the repository), at least not yet it doesn't sound like, since we'll presumably need to continue being able to fix critical (security vulnerability) bugs in it for at least as long as our other projects haven't completed a migration off of it. If you do mean following the deprecation process on oslo.service sooner, then we ought to talk through what the logistics of that process would look like in this particular case. [*] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-... -- Jeremy Stanley
On 2024-06-10 14:56, Jeremy Stanley wrote:
On 2024-06-10 11:09:44 +0200 (+0200), Daniel Bengtsson wrote: [...]
The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it [...]
It's probably worth clarifying that you don't mean "deprecate" in the sense we use it in OpenStack governance[*] (deleting all content from the master branch of the repository), at least not yet it doesn't sound like, since we'll presumably need to continue being able to fix critical (security vulnerability) bugs in it for at least as long as our other projects haven't completed a migration off of it. Yes you're right.
-- Daniel Bengtsson Software Engineer
Hi, 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/ Dmitry On 6/10/24 11:09 AM, Daniel Bengtsson wrote:
Hi there,
In the project to remove eventlet from openstack[1], we need to adapt oslo.service. The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it and replace it with cotyledon and futurist. The cotyledon project was created by openstack maintainers to replace oslo.service. It is already used in openstack by the telemetry project, for example. The oslo.service project has been created on top of eventlet to offer two main functionalities, periodic tasks and workers process management. The first feature has been replaced by another library called futurist[2] and the second is surpassed by cotyledon. More details in the project readme[3] about the difference with oslo.service. I would like to have your feedback and opinion on the deprecation of olso.service and it's replacement by cotyledon and futurist. In any case, we'll have to adapt the project, which is why replacing oslo.service with cotyledon seems to me the best solution, rather than having two similar projects doing the same thing.
[1] https://review.opendev.org/c/openstack/governance/+/902585 [2] http://docs.openstack.org/developer/futurist/ [3] https://github.com/sileht/cotyledon/blob/main/README.rst
-- Daniel Bengtsson Software Engineer
Dmitry, that is an excellent callout. We ideally need to limit single points of failure in our codebase and dependencies where reasonably possible. We need to be mindful of the ability to remedy security issues should they be discovered. -Julia On Mon, Jun 10, 2024 at 7:33 AM Dmitry Tantsur <dtantsur@protonmail.com> wrote:
Hi,
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/
Dmitry
On 6/10/24 11:09 AM, Daniel Bengtsson wrote:
Hi there,
In the project to remove eventlet from openstack[1], we need to adapt oslo.service. The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it and replace it with cotyledon and futurist. The cotyledon project was created by openstack maintainers to replace oslo.service. It is already used in openstack by the telemetry project, for example. The oslo.service project has been created on top of eventlet to offer two main functionalities, periodic tasks and workers process management. The first feature has been replaced by another library called futurist[2] and the second is surpassed by cotyledon. More details in the project readme[3] about the difference with oslo.service. I would like to have your feedback and opinion on the deprecation of olso.service and it's replacement by cotyledon and futurist. In any case, we'll have to adapt the project, which is why replacing oslo.service with cotyledon seems to me the best solution, rather than having two similar projects doing the same thing.
[1] https://review.opendev.org/c/openstack/governance/+/902585 [2] http://docs.openstack.org/developer/futurist/ [3] https://github.com/sileht/cotyledon/blob/main/README.rst
-- Daniel Bengtsson Software Engineer
Thanks Daniel, what do you propose as the next step? Concerning Cotyledon, indeed, the number of active maintainers should be one of our considerations in our research of alternatives for oslo.service. However, I'd highlight the fact that the latest PR (authored by Takashi) was merged one day after its proposal, so the maintainer looks active and reactive: https://github.com/sileht/cotyledon/pull/64 If we chose Cotyledon as an alternative to oslo.service, oslo maintainers may become a bit more involved in Cotyledon, like Takashi did 2 months ago. That seems like a good compromise. Both teams can benefit from this move. I'd also highlight the fact that Cotyledon was designed with an Openstack context in mind. It was designed to be an alternative to oslo.service. We should also consider the compatibility between APIs of both libraries. The migration would be cheap in comparison to using another alternative to oslo.service. IMO, It would be hard to find a better alternative than that. Le lun. 10 juin 2024 à 17:28, Julia Kreger <juliaashleykreger@gmail.com> a écrit :
Dmitry, that is an excellent callout. We ideally need to limit single points of failure in our codebase and dependencies where reasonably possible. We need to be mindful of the ability to remedy security issues should they be discovered.
-Julia
On Mon, Jun 10, 2024 at 7:33 AM Dmitry Tantsur <dtantsur@protonmail.com> wrote:
Hi,
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/
Dmitry
On 6/10/24 11:09 AM, Daniel Bengtsson wrote:
Hi there,
In the project to remove eventlet from openstack[1], we need to adapt oslo.service. The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it and replace it with cotyledon and futurist. The cotyledon project was created by openstack maintainers to replace oslo.service. It is already used in openstack by the telemetry project, for example. The oslo.service project has been created on top of eventlet to offer two main functionalities, periodic tasks and workers process management. The first feature has been replaced by another library called futurist[2] and the second is surpassed by cotyledon. More details in the project readme[3] about the difference with oslo.service. I would like to have your feedback and opinion on the deprecation of olso.service and it's replacement by cotyledon and futurist. In any case, we'll have to adapt the project, which is why replacing oslo.service with cotyledon seems to me the best solution, rather than having two similar projects doing the same thing.
[1] https://review.opendev.org/c/openstack/governance/+/902585 [2] http://docs.openstack.org/developer/futurist/ [3] https://github.com/sileht/cotyledon/blob/main/README.rst
-- Daniel Bengtsson Software Engineer
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
On Mon, 2024-06-10 at 18:55 +0200, Herve Beraud wrote:
Thanks Daniel, what do you propose as the next step?
Concerning Cotyledon, indeed, the number of active maintainers should be one of our considerations in our research of alternatives for oslo.service. However, I'd highlight the fact that the latest PR (authored by Takashi) was merged one day after its proposal, so the maintainer looks active and reactive: https://github.com/sileht/cotyledon/pull/64
If we chose Cotyledon as an alternative to oslo.service, oslo maintainers may become a bit more involved in Cotyledon, like Takashi did 2 months ago. That seems like a good compromise. Both teams can benefit from this move.
I'd also highlight the fact that Cotyledon was designed with an Openstack context in mind. It was designed to be an alternative to oslo.service. We should also consider the compatibility between APIs of both libraries. The migration would be cheap in comparison to using another alternative to oslo.service. IMO, It would be hard to find a better alternative than that.
is the idea that it woudl continue to be a single person lib with some oslo contirutors ro would it move to oepndev and formmally come under the maintainership or opendev/openstack if we were to adopt it. given its being proposed as a repleacment for a core part of oslo we would also need to look at it form a governacne/licenieng poitn fo view not only if its actilvly maintined. it is listed in upperconstriaits https://github.com/openstack/requirements/blob/master/upper-constraints.txt#... so at some point we must have reviewd its inclution on those critira and its a hard requirement of aodh and ceilometer which is a little concerning given its maintaince status but i also see som usage in outer project like cloudkitty and octavia so this feels like perhaps a project that could become a oslo deliverable if the current maintaienr was open to that. lookign at it brefily the over impleation is around 800 lines + tests with some supprot for oslo_cofnig integraiton but im not sure hwo compatiabel its api is with oslo service if i remember correctly oslo.service was orgianlly extraged out fo nova and nova was adapted to use the oslo.service lib internally but we still have a lot of legacy arelated to that. so im not sure how appliabel https://github.com/sileht/cotyledon/blob/main/doc/source/oslo-service-migrat... is to porting nova or cinder for example. https://github.com/openstack/nova/blob/master/nova/service.py#L99 the main api provdded by cotyledon for a service object are run,terminate and reload vs start, stop wiat and reset, in oslo service. https://github.com/openstack/oslo.service/blob/1.38.0/oslo_service/service.p... the other thing is cotyledon does not seam to have a log of docs and its using pytest insted of unittest for its test coverage. https://github.com/sileht/cotyledon/blob/main/setup.cfg#L21-L40 it also does not use requriemets.txt ecrtra and isntead uses setup.cfg to encode depencies. that not a deal breaker but it is a point of divergance as is the use of setuptools_scm instead of pbr. https://github.com/sileht/cotyledon/blob/main/pyproject.toml some of those deltas are actully good. i think moving to setuptools_scm instead of pbr would be a good thing in time but its not a direct dropin replacment and may or may not have some integration issues for exmaple its not actully using upperconstraits for its own testign. https://github.com/sileht/cotyledon/blob/main/tox.ini#L12 and since its not part of openstack it not requried to est with our testing runtimes ectra to supprot the python version we have to support. i think we would have to work out how we adress some of those point before using it more widely. regards sean
Le lun. 10 juin 2024 à 17:28, Julia Kreger <juliaashleykreger@gmail.com> a écrit :
Dmitry, that is an excellent callout. We ideally need to limit single points of failure in our codebase and dependencies where reasonably possible. We need to be mindful of the ability to remedy security issues should they be discovered.
-Julia
On Mon, Jun 10, 2024 at 7:33 AM Dmitry Tantsur <dtantsur@protonmail.com> wrote:
Hi,
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/
Dmitry
On 6/10/24 11:09 AM, Daniel Bengtsson wrote:
Hi there,
In the project to remove eventlet from openstack[1], we need to adapt oslo.service. The oslo.service project is strongly linked to eventlet, so rather than adapting the project, it would be wiser to deprecate it and replace it with cotyledon and futurist. The cotyledon project was created by openstack maintainers to replace oslo.service. It is already used in openstack by the telemetry project, for example. The oslo.service project has been created on top of eventlet to offer two main functionalities, periodic tasks and workers process management. The first feature has been replaced by another library called futurist[2] and the second is surpassed by cotyledon. More details in the project readme[3] about the difference with oslo.service. I would like to have your feedback and opinion on the deprecation of olso.service and it's replacement by cotyledon and futurist. In any case, we'll have to adapt the project, which is why replacing oslo.service with cotyledon seems to me the best solution, rather than having two similar projects doing the same thing.
[1] https://review.opendev.org/c/openstack/governance/+/902585 [2] http://docs.openstack.org/developer/futurist/ [3] https://github.com/sileht/cotyledon/blob/main/README.rst
-- Daniel Bengtsson Software Engineer
On 2024-06-10 18:55, Herve Beraud wrote:
Thanks Daniel, what do you propose as the next step? You're welcome. My next step is to propose a specs inside oslo project about it.
Concerning Cotyledon, indeed, the number of active maintainers should be one of our considerations in our research of alternatives for oslo.service. However, I'd highlight the fact that the latest PR (authored by Takashi) was merged one day after its proposal, so the maintainer looks active and reactive: https://github.com/sileht/cotyledon/pull/64 <https://github.com/sileht/cotyledon/pull/64> I agree with you.
If we chose Cotyledon as an alternative to oslo.service, oslo maintainers may become a bit more involved in Cotyledon, like Takashi did 2 months ago. That seems like a good compromise. Both teams can benefit from this move. Yes if you move on it I will also be more active in cotyledon for sure.
I'd also highlight the fact that Cotyledon was designed with an Openstack context in mind. It was designed to be an alternative to oslo.service. We should also consider the compatibility between APIs of both libraries. The migration would be cheap in comparison to using another alternative to oslo.service. IMO, It would be hard to find a better alternative than that. I agree with you.
-- Daniel Bengtsson Software Engineer
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.
-- Daniel Bengtsson Software Engineer
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. Dmitry
-- Daniel Bengtsson Software Engineer
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
Dmitry
-- Daniel Bengtsson Software Engineer
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.
Dmitry
-- Daniel Bengtsson Software Engineer
-- Best regards, Andriy Kurilin.
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
replacing oslo.service was not in the set of thing we were condierign doing in nova this cycle but if we compelte the ohter work and i finish the other feature im ment to work on i might try swaping in Cotyledon if anyone trys that for any other service or feels like trying it in nova the i owuld be happy to review to see what that looks like. looking at the gaps im not sure how much of them actully matter at the end of the day i.e. we planned ot remoe the eventlet backdoor debuging supprot with the removal of eventlet anyway so thet fact Cotyledon does not hook that up is fine. similarly we talked about removing the standaloen wsgi console script for nova-api or replacing it with something else like flask ectra so the wsgi supprot might not be an issue either. we will just have to asses those gaps when it comes to proting and if there is an upgrade impact that we can or cannot accept. teh fact that ceilometer and aodh use Cotyledon is at least encuraging espically since that implies the distor packageing shoudl already be in place but i just wanted ot make it clear i was not focusing on the governace question but also the technical gaps i was expeict that oslo.service would not be released as part of the eventlet removal and instead would have been ported to not depend on eventlet. i.e. have oslo.service perodici tasks just delegate to futurist providing the same api with a diffent backend. so i was kidn of surprised to see this topic come up. ill see if i can find time to do a poc but it wont happen until at least late july or august based on the other thing on my plate so if other do have a poc to share of portign ironic or neuton or cinder ectra that might fill in some of the gaps. On Tue, 2024-06-11 at 23:11 +0100, smooney@redhat.com wrote:
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
i was expeict that oslo.service would not be released as part of the eventlet removal and instead would have been ported to not depend on eventlet.
i.e. have oslo.service perodici tasks just delegate to futurist providing the same api with a diffent backend.
so i was kidn of surprised to see this topic come up.
I'll focus my answer only on that point ^. We were not thinking of managing the oslo.service topic at the same time as the Eventlet removal, but unfortunately, both topics can be separated... As oslo.service is heavily based on Eventlet, we can't touch one without touching the other. We were thinking of giving orientation for replacement through deprecation messages and through guidance [1]. But, indeed, a binding to futurist and cotyledon through oslo.service could be an option. Indeed it would really simplify the migration, but on the other hand it will produce technical debt, which at term, risks to remain an undefined amount of time. If people feel comfortable using this binding, they won't have reasons to drop oslo.service in favor of futurist and cotyledon. They will continue using the binding... But this side effect doesn't seem so terrible, it could be a credible scenario in the long term, so I don't think we should ignore that point. But if we consider the benefits brought by such binding, this side effect could be surely ignored. Indeed, on the other hand, such a kind of binding would be a good option to: 1. not have to internalize cotyledon into OpenStack. I'm personally more in favor of keeping Cotyledon as an independent deliverable as we did with Eventlet; 2. to host a wsgi binding (maybe based on flask) as an alternative to the Eventlet WSGI binding offered by oslo.service. Maintaining the binding would allow us to monitor if Cotyledon needs help at some point. Maintaining a binding would simplify the migration. Maintaining a binding could merge the best of both worlds in many aspects. [1] https://709b9532d61399a9e320-55e7a9d33a731efe4f7611907a31a4a1.ssl.cf2.rackcd... -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
On 2024-06-12 11:11, Herve Beraud wrote:
Maintaining the binding would allow us to monitor if Cotyledon needs help at some point. Maintaining a binding would simplify the migration. Maintaining a binding could merge the best of both worlds in many aspects. I agree with you. Keep oslo.service and use as a binding to cotyledon and futurist seems the best idea. Simplify a lot potential problem mentioned before.
-- Daniel Bengtsson Software Engineer
Sent from Workspace ONE Boxer On Jun 11, 2024 4:17 PM, Dmitry Tantsur <dtantsur@protonmail.com> wrote:
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.
Mehdi used to be an OpenStack contributor. He (and Julien) wrote this for Telemetry. Wjy don't you talk with him? Maybe ask him if it is ok to take-over the project and maintain it it Gerrit? I'm convince there is a high probability he will accept! Thomas Goirand
participants (8)
-
Andriy Kurilin
-
Daniel Bengtsson
-
Dmitry Tantsur
-
Herve Beraud
-
Jeremy Stanley
-
Julia Kreger
-
smooney＠redhat.com
-
thomas＠goirand.fr