[dev][requirements] Potentially ceasing development of Paste
Just a heads up that Chris is raising concerns about continued maintenance of the Paste library, which more than a few of our projects rely on: https://github.com/cdent/paste/discussions/91 It's worth considering whether we would offer to adopt/fork it or if there are straightforward migration paths to actively maintained alternatives. -- Jeremy Stanley
On 2024-04-05 18:27:48 +0000 (+0000), Jeremy Stanley wrote:
Just a heads up that Chris is raising concerns about continued maintenance of the Paste library, which more than a few of our projects rely on:
https://github.com/cdent/paste/discussions/91
It's worth considering whether we would offer to adopt/fork it or if there are straightforward migration paths to actively maintained alternatives.
For the benefit of those not following the issue, here's the quick summary: Chris had hoped that OpenStack and other users of the paste library would migrate off of it, but that doesn't ever seem to have finished (did it even get started?). Paste relies on some deprecated "dead batteries" which are being removed from the Python standard library in 3.13, so it will break without intervention. There is now a PR to switch it to using an external version of the deprecated bits, but this is really a stop-gap. If OpenStack is going to continue using paste in the long term, that will require volunteers to actively maintain it; but the general recommendation is to replace our use of paste with some (non-drop-in) alternative better aligned with the current state of the Python ecosystem. -- Jeremy Stanley
I thought I replied to the thread but I didn't... I looked into the specific concern about cgi and it seems it was already sorted out my patch and the other one proposed by someone else, so it may survive for some time. https://github.com/pasteorg/paste/commit/cf49c1628b6e0ea11aa4aae147420519ab0... https://github.com/pasteorg/paste/commit/0742dc433db86ebc5fb2825d04c40f6246e... However I know this does not resolve the overall concern about its maintenance. I saw one person volunteered to maintain the project but this does not secure the project status really so we have to decide if anyone from the OpenStack community can/will invest in it or we replace paste by something else. https://github.com/pasteorg/paste/discussions/91#discussioncomment-9244945 I took time to go through the current code when I was checking cgi usage, but that made me aware of some difficulties with maintaining the project really. The repository includes bunch of implementations we do not use in OpenStack. For me it looks like the repository has a bit tricky code base. One very good example is that it does not follow pep8 standard which gave me some challenges when updating the code. AFAIK pecan may be the first candidate as an replacement because it's already used in a few projects like ironic and octavia. However, I don't know if migration to pecan is a very good idea here, because I sometimes find it a bit frustrating that the existing usage of pecan in ironic and octavia does not allow injecting additional middleware. My hope is to provide a flexible mechanism like api-paste.ini though that may eventually mean that we need PasteDeploy, and then paste. On 4/25/24 22:33, Jeremy Stanley wrote:
On 2024-04-05 18:27:48 +0000 (+0000), Jeremy Stanley wrote:
Just a heads up that Chris is raising concerns about continued maintenance of the Paste library, which more than a few of our projects rely on:
https://github.com/cdent/paste/discussions/91
It's worth considering whether we would offer to adopt/fork it or if there are straightforward migration paths to actively maintained alternatives.
For the benefit of those not following the issue, here's the quick summary:
Chris had hoped that OpenStack and other users of the paste library would migrate off of it, but that doesn't ever seem to have finished (did it even get started?). Paste relies on some deprecated "dead batteries" which are being removed from the Python standard library in 3.13, so it will break without intervention.
There is now a PR to switch it to using an external version of the deprecated bits, but this is really a stop-gap. If OpenStack is going to continue using paste in the long term, that will require volunteers to actively maintain it; but the general recommendation is to replace our use of paste with some (non-drop-in) alternative better aligned with the current state of the Python ecosystem.
On Wed, 2024-05-01 at 16:31 +0900, Takashi Kajinami wrote:
I thought I replied to the thread but I didn't...
I looked into the specific concern about cgi and it seems it was already sorted out my patch and the other one proposed by someone else, so it may survive for some time.
https://github.com/pasteorg/paste/commit/cf49c1628b6e0ea11aa4aae147420519ab0... https://github.com/pasteorg/paste/commit/0742dc433db86ebc5fb2825d04c40f6246e...
However I know this does not resolve the overall concern about its maintenance. I saw one person volunteered to maintain the project but this does not secure the project status really so we have to decide if anyone from the OpenStack community can/will invest in it or we replace paste by something else.
https://github.com/pasteorg/paste/discussions/91#discussioncomment-9244945
I took time to go through the current code when I was checking cgi usage, but that made me aware of some difficulties with maintaining the project really. The repository includes bunch of implementations we do not use in OpenStack. For me it looks like the repository has a bit tricky code base. One very good example is that it does not follow pep8 standard which gave me some challenges when updating the code.
AFAIK pecan may be the first candidate as an replacement because it's already used in a few projects like ironic and octavia. However, I don't know if migration to pecan is a very good idea here, because I sometimes find it a bit frustrating that the existing usage of pecan in ironic and octavia does not allow injecting additional middleware. My hope is to provide a flexible mechanism like api-paste.ini though that may eventually mean that we need PasteDeploy, and then paste. im not really familar with pecan but i have been debatign if we should be moving nova to flask like keystone to remove paste amd paste deploy but yes one of the feature gaps would be delcaritive pipeline defiention via a file like api-paste.ini
keystone just does not allow the middelware to be confiurable https://github.com/openstack/keystone/blob/7a6e1a0bdc79927e5d7fd6ad7e6dda2e0... so maybe we dont actually need this configurableity that is one of the downsides of flask out of the box it does not have a config driveen way to configure middelware that im aware of so we would need to create our own if we were to keep api-paste.ini type functionality.
On 4/25/24 22:33, Jeremy Stanley wrote:
On 2024-04-05 18:27:48 +0000 (+0000), Jeremy Stanley wrote:
Just a heads up that Chris is raising concerns about continued maintenance of the Paste library, which more than a few of our projects rely on:
https://github.com/cdent/paste/discussions/91
It's worth considering whether we would offer to adopt/fork it or if there are straightforward migration paths to actively maintained alternatives.
For the benefit of those not following the issue, here's the quick summary:
Chris had hoped that OpenStack and other users of the paste library would migrate off of it, but that doesn't ever seem to have finished (did it even get started?). Paste relies on some deprecated "dead batteries" which are being removed from the Python standard library in 3.13, so it will break without intervention.
There is now a PR to switch it to using an external version of the deprecated bits, but this is really a stop-gap. If OpenStack is going to continue using paste in the long term, that will require volunteers to actively maintain it; but the general recommendation is to replace our use of paste with some (non-drop-in) alternative better aligned with the current state of the Python ecosystem.
participants (3)
-
Jeremy Stanley
-
smooney＠redhat.com
-
Takashi Kajinami