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