[goals][kolla][tripleo][all] Migrating from WSGI scripts to module paths
o/ For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack). From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former. I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free. I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier. Please do let me know if you have any questions or concerns. Cheers, Stephen [1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change. From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that. Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually. ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
Hi, It could be a great chance to discourage people from using mod_wsgi and use the combination with uWSGI indeed. Not just because mod_wsgi is a bad idea in general, but also because of the impeding (although not soon) switch to asynchronous IO. Dmitry On 12/6/23 13:05, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
I agree, looking at the changes Stephen has proposed, this is a good approach. I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use. Michael On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode. If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO. [1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)" On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet. But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :) Dmitry On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
Yes, this. There are also a few other of other WSGI server implementation (a quick Google points out Nginx Unit [1] and Granian [2] and I'm sure there are more. Coincidentally, both of these are configured with module paths). On top of this, in light of the eventlet "situation", we'd obviously eventually like to get to a point where we're providing ASGI servers rather than WSGI servers but we are still some distance from that. Cheers, Stephen [1] https://unit.nginx.org/configuration/#configuration-python [2] https://github.com/emmett-framework/granian
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
> From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote: the choice of wsgi server is reallly upto the installer/operator but for what its worth gunicorn is what starlingx is useing and its used in several other services like monasca too https://codesearch.opendev.org/?q=gunicorn&i=nope&literal=nope&files=&excludeFiles=&repos= so weven without going as far as recommending one approach over the other its important to note that it is possible today to use mod_wsgi, uwsgi or gunicorn with some additional packaging/instlaler work today. we dont necessarily need to recommend one over the other just ensure that we enable the installer/packager/opertor to choose the wsgi server that suits there needs best.
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
> From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
Hi, On 12/7/23 14:15, smooney@redhat.com wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote: the choice of wsgi server is reallly upto the installer/operator but for what its worth gunicorn is what starlingx is useing and its used in several other services like monasca too
https://codesearch.opendev.org/?q=gunicorn&i=nope&literal=nope&files=&excludeFiles=&repos=
so weven without going as far as recommending one approach over the other its important to note that it is possible today to use mod_wsgi, uwsgi or gunicorn with some additional packaging/instlaler work today. we dont necessarily need to recommend one over the other just ensure that we enable the installer/packager/opertor to choose the wsgi server that suits there needs best.
Sure, but it does matter what we document as the primary method. That's what newcomers will try to use, it will be a part of their OpenStack first experience. "Why is a single API service consuming gigabytes of RAM" is not the thing you want them to ask after their first deployment :) Dmitry
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
> From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: > o/ > > For anyone that hasn't been following along, there are changes coming down the > line in the Python packaging world that look likely to break pbr's > 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then > at some point these auto-generated scripts will no longer end up in 'bin' when > pip installed (as we do with e.g. DevStack). > >> From where I'm standing, we appear to have two options: we can either invest > time in pbr to re-implement this functionality from scratch, or we can drop the > idea of auto-generating wsgi scripts from our packaging tool and instead start > using module paths. Having looked at the former, I suspect it is going to be a > *lot* of work that will require implementing our own PEP-517 compatible build > backend instead of cribbing setuptools' one as we do now. Personally, I don't > think this is a good investment of anyone's time, and it gives us more stuff to > maintain for the many years ahead (Did you know that pbr *still* technically > supports Python 2. Fun story that). As such, I think we should instead look to > the former. > > I've proposed some patches for Nova [1][2], which I am hoping will provide a > blueprint for the other services, and patch for DevStack to enable the new Nova > functionality [3]. As you'll see, these patches are relatively small and > hopefully easy to grok. The biggest downside I see to this approach is that > tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack > will need to start packaging their own wsgi script. This is because mod_wsgi > does not appear to support configuration by module paths. On the flipside, > gunicorn does not support configuration by wsgi script so we get that for free. > > I would like to hear other's opinions on this approach. As this is something > that likely affects all services, I suspect that if there's consensus that this > is the correct way to go, there should probably be a small goal drafted for the > current cycle. In my opinion, it would be good to do the migration consistently: > in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module > and IMO if all projects could adopt the same convention we would make the lives > of our deployment tooling colleagues easier. > > Please do let me know if you have any questions or concerns. > > Cheers, > Stephen > > [1] https://review.opendev.org/c/openstack/nova/+/902687/2 > [2] https://review.opendev.org/c/openstack/nova/+/902688/2 > [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 >
Hey all, We are heavily relying on mod_wsgi here. If I am correct, kolla is also relying on apache+mod_wsgi (like [1]). How problematic will it be for such projects to do the switch? Could it be possible to keep some wsgi sample in code or, at least, in documentation so the switch could be done smoothly? [1] https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/keyston... On 07.12.23 - 18:13, Dmitry Tantsur wrote:
Hi,
On 12/7/23 14:15, smooney@redhat.com wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote: the choice of wsgi server is reallly upto the installer/operator but for what its worth gunicorn is what starlingx is useing and its used in several other services like monasca too
https://codesearch.opendev.org/?q=gunicorn&i=nope&literal=nope&files=&excludeFiles=&repos=
so weven without going as far as recommending one approach over the other its important to note that it is possible today to use mod_wsgi, uwsgi or gunicorn with some additional packaging/instlaler work today. we dont necessarily need to recommend one over the other just ensure that we enable the installer/packager/opertor to choose the wsgi server that suits there needs best.
Sure, but it does matter what we document as the primary method. That's what newcomers will try to use, it will be a part of their OpenStack first experience. "Why is a single API service consuming gigabytes of RAM" is not the thing you want them to ask after their first deployment :)
Dmitry
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote:
Hello,
> On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote: > > As long as the module path is documented and/or constrained/aligned > across all projects - that should be a totally fine change.
+1 this, I like this approach overall and should be an easy migration for tooling to adopt.
>> From an OpenStack-Ansible perspective quite trivial change would be > needed to be done and I don't see any huge blocker with that. > > Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with > "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really > want to support Apache+mod_wsgi then some example script should be > placed somewhere to ease life of those who decide to deploy OpenStack > manually. > > ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: >> o/ >> >> For anyone that hasn't been following along, there are changes coming down the >> line in the Python packaging world that look likely to break pbr's >> 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then >> at some point these auto-generated scripts will no longer end up in 'bin' when >> pip installed (as we do with e.g. DevStack). >> >>> From where I'm standing, we appear to have two options: we can either invest >> time in pbr to re-implement this functionality from scratch, or we can drop the >> idea of auto-generating wsgi scripts from our packaging tool and instead start >> using module paths. Having looked at the former, I suspect it is going to be a >> *lot* of work that will require implementing our own PEP-517 compatible build >> backend instead of cribbing setuptools' one as we do now. Personally, I don't >> think this is a good investment of anyone's time, and it gives us more stuff to >> maintain for the many years ahead (Did you know that pbr *still* technically >> supports Python 2. Fun story that). As such, I think we should instead look to >> the former. >> >> I've proposed some patches for Nova [1][2], which I am hoping will provide a >> blueprint for the other services, and patch for DevStack to enable the new Nova >> functionality [3]. As you'll see, these patches are relatively small and >> hopefully easy to grok. The biggest downside I see to this approach is that >> tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack >> will need to start packaging their own wsgi script. This is because mod_wsgi >> does not appear to support configuration by module paths. On the flipside, >> gunicorn does not support configuration by wsgi script so we get that for free. >> >> I would like to hear other's opinions on this approach. As this is something >> that likely affects all services, I suspect that if there's consensus that this >> is the correct way to go, there should probably be a small goal drafted for the >> current cycle. In my opinion, it would be good to do the migration consistently: >> in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module >> and IMO if all projects could adopt the same convention we would make the lives >> of our deployment tooling colleagues easier. >> >> Please do let me know if you have any questions or concerns. >> >> Cheers, >> Stephen >> >> [1] https://review.opendev.org/c/openstack/nova/+/902687/2 >> [2] https://review.opendev.org/c/openstack/nova/+/902688/2 >> [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 >>
On Thu, 2023-12-07 at 21:49 +0000, Arnaud Morin wrote:
Hey all,
We are heavily relying on mod_wsgi here. If I am correct, kolla is also relying on apache+mod_wsgi (like [1]). How problematic will it be for such projects to do the switch?
Could it be possible to keep some wsgi sample in code or, at least, in documentation so the switch could be done smoothly?
I expect this would be taken care of by Kolla. There are two options. The first is that Kolla can point Apache+mod_wsgi to the module, which will be in '/lib', rather than to the "binary", which was in '/bin' For example, instead of: WSGIScriptAlias / /var/lib/kolla/venv/bin/nova-api-wsgi you would have: WSGIScriptAlias / /var/lib/kolla/venv/lib/nova/wsgi/osapi_compute.py As a potentially nicer alternative, Kolla could create an e.g. 'nova-api.wsgi' script that simply contains the following: from nova.wsgi.osapi_compute import application This could then be laid down in a known location and referenced accordingly. WSGIScriptAlias / /path/to/wsgi/script.dir/nova-api.wsgi Hope this helps, Stephen
[1] https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/keyston...
On 07.12.23 - 18:13, Dmitry Tantsur wrote:
Hi,
On 12/7/23 14:15, smooney@redhat.com wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote: the choice of wsgi server is reallly upto the installer/operator but for what its worth gunicorn is what starlingx is useing and its used in several other services like monasca too
https://codesearch.opendev.org/?q=gunicorn&i=nope&literal=nope&files=&excludeFiles=&repos=
so weven without going as far as recommending one approach over the other its important to note that it is possible today to use mod_wsgi, uwsgi or gunicorn with some additional packaging/instlaler work today. we dont necessarily need to recommend one over the other just ensure that we enable the installer/packager/opertor to choose the wsgi server that suits there needs best.
Sure, but it does matter what we document as the primary method. That's what newcomers will try to use, it will be a part of their OpenStack first experience. "Why is a single API service consuming gigabytes of RAM" is not the thing you want them to ask after their first deployment :)
Dmitry
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote:
I agree, looking at the changes Stephen has proposed, this is a good approach.
I also strongly agree with Dmitry Tantsur in that we should not go down a path of encouraging mod_wsgi use.
Michael
On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote: > Hello, > > > On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote: > > > > As long as the module path is documented and/or constrained/aligned > > across all projects - that should be a totally fine change. > > +1 this, I like this approach overall and should be an easy migration for tooling to adopt. > > > > From an OpenStack-Ansible perspective quite trivial change would be > > needed to be done and I don't see any huge blocker with that. > > > > Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with > > "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really > > want to support Apache+mod_wsgi then some example script should be > > placed somewhere to ease life of those who decide to deploy OpenStack > > manually. > > > > ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: > > > o/ > > > > > > For anyone that hasn't been following along, there are changes coming down the > > > line in the Python packaging world that look likely to break pbr's > > > 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then > > > at some point these auto-generated scripts will no longer end up in 'bin' when > > > pip installed (as we do with e.g. DevStack). > > > > > > > From where I'm standing, we appear to have two options: we can either invest > > > time in pbr to re-implement this functionality from scratch, or we can drop the > > > idea of auto-generating wsgi scripts from our packaging tool and instead start > > > using module paths. Having looked at the former, I suspect it is going to be a > > > *lot* of work that will require implementing our own PEP-517 compatible build > > > backend instead of cribbing setuptools' one as we do now. Personally, I don't > > > think this is a good investment of anyone's time, and it gives us more stuff to > > > maintain for the many years ahead (Did you know that pbr *still* technically > > > supports Python 2. Fun story that). As such, I think we should instead look to > > > the former. > > > > > > I've proposed some patches for Nova [1][2], which I am hoping will provide a > > > blueprint for the other services, and patch for DevStack to enable the new Nova > > > functionality [3]. As you'll see, these patches are relatively small and > > > hopefully easy to grok. The biggest downside I see to this approach is that > > > tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack > > > will need to start packaging their own wsgi script. This is because mod_wsgi > > > does not appear to support configuration by module paths. On the flipside, > > > gunicorn does not support configuration by wsgi script so we get that for free. > > > > > > I would like to hear other's opinions on this approach. As this is something > > > that likely affects all services, I suspect that if there's consensus that this > > > is the correct way to go, there should probably be a small goal drafted for the > > > current cycle. In my opinion, it would be good to do the migration consistently: > > > in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module > > > and IMO if all projects could adopt the same convention we would make the lives > > > of our deployment tooling colleagues easier. > > > > > > Please do let me know if you have any questions or concerns. > > > > > > Cheers, > > > Stephen > > > > > > [1] https://review.opendev.org/c/openstack/nova/+/902687/2 > > > [2] https://review.opendev.org/c/openstack/nova/+/902688/2 > > > [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 > > >
Thanks for the pointers Stephen. Can somebody remind me why mod_wsgi is the one to not recommend using? ;-) Michal
On 8 Dec 2023, at 15:14, Stephen Finucane <stephenfin@redhat.com> wrote:
On Thu, 2023-12-07 at 21:49 +0000, Arnaud Morin wrote:
Hey all,
We are heavily relying on mod_wsgi here. If I am correct, kolla is also relying on apache+mod_wsgi (like [1]). How problematic will it be for such projects to do the switch?
Could it be possible to keep some wsgi sample in code or, at least, in documentation so the switch could be done smoothly?
I expect this would be taken care of by Kolla. There are two options. The first is that Kolla can point Apache+mod_wsgi to the module, which will be in '/lib', rather than to the "binary", which was in '/bin' For example, instead of:
WSGIScriptAlias / /var/lib/kolla/venv/bin/nova-api-wsgi
you would have:
WSGIScriptAlias / /var/lib/kolla/venv/lib/nova/wsgi/osapi_compute.py
As a potentially nicer alternative, Kolla could create an e.g. 'nova-api.wsgi' script that simply contains the following:
from nova.wsgi.osapi_compute import application
This could then be laid down in a known location and referenced accordingly.
WSGIScriptAlias / /path/to/wsgi/script.dir/nova-api.wsgi
Hope this helps, Stephen
[1] https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/keyston...
On 07.12.23 - 18:13, Dmitry Tantsur wrote:
Hi,
On 12/7/23 14:15, smooney@redhat.com wrote:
I think we should target gunicorn because it's maintained, supports async/await and plays well (IIRC) with eventlet.
On Thu, 2023-12-07 at 09:06 +0000, Dmitry Tantsur wrote: the choice of wsgi server is reallly upto the installer/operator but for what its worth gunicorn is what starlingx is useing and its used in several other services like monasca too
https://codesearch.opendev.org/?q=gunicorn&i=nope&literal=nope&files=&excludeFiles=&repos=
so weven without going as far as recommending one approach over the other its important to note that it is possible today to use mod_wsgi, uwsgi or gunicorn with some additional packaging/instlaler work today. we dont necessarily need to recommend one over the other just ensure that we enable the installer/packager/opertor to choose the wsgi server that suits there needs best.
Sure, but it does matter what we document as the primary method. That's what newcomers will try to use, it will be a part of their OpenStack first experience. "Why is a single API service consuming gigabytes of RAM" is not the thing you want them to ask after their first deployment :)
Dmitry
But note that I didn't suggest *discouraging* usage of mod_wsgi, I'd just avoid *encouraging* it :)
Dmitry
On 12/7/23 09:29, Takashi Kajinami wrote:
I personally agree that using apache + mod_wsgi causes several pains, (It has caused multiple nightmares with service dependency we attempted to describe in puppet) but at the same time would like to remind you all about the fact that uwsgi is now in maintenance mode.
If we officially discourage usage of mod_wsgi and aim to switch to uwsgi completely, then we have to consider investing in uwsgi as the OpenStack community, or start looking for any appropriate alternatives because uwsgi can be abandoned, IMO.
[1] https://github.com/unbit/uwsgi "Note: The project is in maintenance mode (only bugfixes and updates for new languages apis)"
On 12/7/23 02:05, Michael Johnson wrote: > I agree, looking at the changes Stephen has proposed, this is a good approach. > > I also strongly agree with Dmitry Tantsur in that we should not go > down a path of encouraging mod_wsgi use. > > Michael > > On Wed, Dec 6, 2023 at 7:05 AM Tobias Urdin <tobias.urdin@binero.com> wrote: >> Hello, >> >>> On 6 Dec 2023, at 13:05, Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote: >>> >>> As long as the module path is documented and/or constrained/aligned >>> across all projects - that should be a totally fine change. >> >> +1 this, I like this approach overall and should be an easy migration for tooling to adopt. >> >>>> From an OpenStack-Ansible perspective quite trivial change would be >>> needed to be done and I don't see any huge blocker with that. >>> >>> Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with >>> "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really >>> want to support Apache+mod_wsgi then some example script should be >>> placed somewhere to ease life of those who decide to deploy OpenStack >>> manually. >>> >>> ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: >>>> o/ >>>> >>>> For anyone that hasn't been following along, there are changes coming down the >>>> line in the Python packaging world that look likely to break pbr's >>>> 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then >>>> at some point these auto-generated scripts will no longer end up in 'bin' when >>>> pip installed (as we do with e.g. DevStack). >>>> >>>>> From where I'm standing, we appear to have two options: we can either invest >>>> time in pbr to re-implement this functionality from scratch, or we can drop the >>>> idea of auto-generating wsgi scripts from our packaging tool and instead start >>>> using module paths. Having looked at the former, I suspect it is going to be a >>>> *lot* of work that will require implementing our own PEP-517 compatible build >>>> backend instead of cribbing setuptools' one as we do now. Personally, I don't >>>> think this is a good investment of anyone's time, and it gives us more stuff to >>>> maintain for the many years ahead (Did you know that pbr *still* technically >>>> supports Python 2. Fun story that). As such, I think we should instead look to >>>> the former. >>>> >>>> I've proposed some patches for Nova [1][2], which I am hoping will provide a >>>> blueprint for the other services, and patch for DevStack to enable the new Nova >>>> functionality [3]. As you'll see, these patches are relatively small and >>>> hopefully easy to grok. The biggest downside I see to this approach is that >>>> tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack >>>> will need to start packaging their own wsgi script. This is because mod_wsgi >>>> does not appear to support configuration by module paths. On the flipside, >>>> gunicorn does not support configuration by wsgi script so we get that for free. >>>> >>>> I would like to hear other's opinions on this approach. As this is something >>>> that likely affects all services, I suspect that if there's consensus that this >>>> is the correct way to go, there should probably be a small goal drafted for the >>>> current cycle. In my opinion, it would be good to do the migration consistently: >>>> in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module >>>> and IMO if all projects could adopt the same convention we would make the lives >>>> of our deployment tooling colleagues easier. >>>> >>>> Please do let me know if you have any questions or concerns. >>>> >>>> Cheers, >>>> Stephen >>>> >>>> [1] https://review.opendev.org/c/openstack/nova/+/902687/2 >>>> [2] https://review.opendev.org/c/openstack/nova/+/902688/2 >>>> [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 >>>>
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting. If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling. Stephen [1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services. https://review.opendev.org/c/openstack/governance/+/902807 Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this. For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion. Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
From OpenStack-Ansible perspective there's none, except potential cross-dependencies. So it would be really nice to remove wsgi scripts with some time margin after adding modules to prevent circular dependencies from happening on integration tests, so that patches at least for "core" services could land smoothly. On Thu, Dec 7, 2023, 12:41 Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com
:
o/
For anyone that hasn't been following along, there are changes
line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will
blueprint for the other services, and patch for DevStack to enable
functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get
coming down the provide a the new Nova that for free.
I would like to hear other's opinions on this approach. As this is
something
that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
It may not be a problem for our modules in Puppet OpenStack but cause some problems with surroundings or our operations. - This causes the circular dependencies between Puppet OpenStack and RDO because - RDO is using Puppet OpenStack for their testing so need the fix for promotion - Puppet OpenStack is using packages which passed testing in RDO so need promotion for fix Mistral already removed the generated wsgi script and replaced it by wsgi.py and we had to handle with making some jobs non-voting and force-move some steps - Because Ubuntu does not provider packages based on master, we have to test the master branch with UCA bobcat now, so once wsgi script is removed and we adapt to the new wsgi.py, all Ubuntu jobs may not work until UCA Caracal is released and we may loose that test coverage for a few months. The concern I left in the goal document is more generic one. If we remove the wsgi script immediately then users have to change their wsgi config when they upgrade their deployment from A/B to Caracal. Previously people could upgrade packages first without any config change and then adjust config (eg. replacing a deprecated parameter) but now they have to make sure they make the configuration change at the right timing. Because Puppet OpenStack does not cover upgrade so it may not be a problem for us, but I'm still unsure if this really works with the all deployment toolings, including the one maintained in OpenStack projects and the others maintained externally (like users' own toolings). So I may vote for keeping the wsgi script at least one cycle, at Caracal release, with the new wsgi.py and then remove the existing wsgi script at D so that C can be a pivot point for smooth transition unless there is real pains/difficulties with keeping the existing wsgi_script entrypoint. On 12/7/23 21:51, Dmitriy Rabotyagov wrote:
From OpenStack-Ansible perspective there's none, except potential cross-dependencies.
So it would be really nice to remove wsgi scripts with some time margin after adding modules to prevent circular dependencies from happening on integration tests, so that patches at least for "core" services could land smoothly.
On Thu, Dec 7, 2023, 12:41 Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote: > On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote: > > On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote: > > > As long as the module path is documented and/or constrained/aligned > > > across all projects - that should be a totally fine change. > > > > This is my preference also and part of the reason for the original email. > > Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the > > root of the project [1], which seems like a good convention to follow. However, > > given some services (Nova, ...?) expose multiple WSGI servers, we need another > > layer of nesting. > > > > If we could settle on a pattern of '<service>.wsgi.<server>:application' I > > imagine we'd meet mostly everyone's needs and keep things easy for deployment > > tooling. > > > > Stephen > > > > [1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/ > > I have proposed a goal to make this clear and help ensure we deliver a > consistent pattern across services. > > https://review.opendev.org/c/openstack/governance/+/902807 > > Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
> > > > > > > > > From an OpenStack-Ansible perspective quite trivial change would be > > > needed to be done and I don't see any huge blocker with that. > > > > > > Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with > > > "ProxyPass / uwsgi://127.0.0.1:5000 <http://127.0.0.1:5000>" for instance. But if we really > > > want to support Apache+mod_wsgi then some example script should be > > > placed somewhere to ease life of those who decide to deploy OpenStack > > > manually. > > > > > > ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: > > > > > > > > o/ > > > > > > > > For anyone that hasn't been following along, there are changes coming down the > > > > line in the Python packaging world that look likely to break pbr's > > > > 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then > > > > at some point these auto-generated scripts will no longer end up in 'bin' when > > > > pip installed (as we do with e.g. DevStack). > > > > > > > > > From where I'm standing, we appear to have two options: we can either invest > > > > time in pbr to re-implement this functionality from scratch, or we can drop the > > > > idea of auto-generating wsgi scripts from our packaging tool and instead start > > > > using module paths. Having looked at the former, I suspect it is going to be a > > > > *lot* of work that will require implementing our own PEP-517 compatible build > > > > backend instead of cribbing setuptools' one as we do now. Personally, I don't > > > > think this is a good investment of anyone's time, and it gives us more stuff to > > > > maintain for the many years ahead (Did you know that pbr *still* technically > > > > supports Python 2. Fun story that). As such, I think we should instead look to > > > > the former. > > > > > > > > I've proposed some patches for Nova [1][2], which I am hoping will provide a > > > > blueprint for the other services, and patch for DevStack to enable the new Nova > > > > functionality [3]. As you'll see, these patches are relatively small and > > > > hopefully easy to grok. The biggest downside I see to this approach is that > > > > tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack > > > > will need to start packaging their own wsgi script. This is because mod_wsgi > > > > does not appear to support configuration by module paths. On the flipside, > > > > gunicorn does not support configuration by wsgi script so we get that for free. > > > > > > > > I would like to hear other's opinions on this approach. As this is something > > > > that likely affects all services, I suspect that if there's consensus that this > > > > is the correct way to go, there should probably be a small goal drafted for the > > > > current cycle. In my opinion, it would be good to do the migration consistently: > > > > in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module > > > > and IMO if all projects could adopt the same convention we would make the lives > > > > of our deployment tooling colleagues easier. > > > > > > > > Please do let me know if you have any questions or concerns. > > > > > > > > Cheers, > > > > Stephen > > > > > > > > [1] https://review.opendev.org/c/openstack/nova/+/902687/2 > > > > [2] https://review.opendev.org/c/openstack/nova/+/902688/2 > > > > [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 > > > > > > > > > >
Totally agree with Takashi, In Kolla we use mod_wsgi for all those services that we run as wsgi. While probably we could manage templating wsgi scripts in Kolla-Ansible - I don’t see us doing that on the longer run - especially if that introduces problems not visible in Devstack/other deployment projects. If we switch to Gunicorn and Apache+Gunicorn for Keystone/Horizon SSO - still users that have config overrides for mod_wsgi configs will need to adapt. Michal W dniu pt., 8.12.2023 o 04:35 Takashi Kajinami <kajinamit@oss.nttdata.com> napisał(a):
It may not be a problem for our modules in Puppet OpenStack but cause some problems with surroundings or our operations.
- This causes the circular dependencies between Puppet OpenStack and RDO because - RDO is using Puppet OpenStack for their testing so need the fix for promotion - Puppet OpenStack is using packages which passed testing in RDO so need promotion for fix Mistral already removed the generated wsgi script and replaced it by wsgi.py and we had to handle with making some jobs non-voting and force-move some steps
- Because Ubuntu does not provider packages based on master, we have to test the master branch with UCA bobcat now, so once wsgi script is removed and we adapt to the new wsgi.py, all Ubuntu jobs may not work until UCA Caracal is released and we may loose that test coverage for a few months.
The concern I left in the goal document is more generic one. If we remove the wsgi script immediately then users have to change their wsgi config when they upgrade their deployment from A/B to Caracal. Previously people could upgrade packages first without any config change and then adjust config (eg. replacing a deprecated parameter) but now they have to make sure they make the configuration change at the right timing. Because Puppet OpenStack does not cover upgrade so it may not be a problem for us, but I'm still unsure if this really works with the all deployment toolings, including the one maintained in OpenStack projects and the others maintained externally (like users' own toolings).
So I may vote for keeping the wsgi script at least one cycle, at Caracal release, with the new wsgi.py and then remove the existing wsgi script at D so that C can be a pivot point for smooth transition unless there is real pains/difficulties with keeping the existing wsgi_script entrypoint.
On 12/7/23 21:51, Dmitriy Rabotyagov wrote:
From OpenStack-Ansible perspective there's none, except potential cross-dependencies.
So it would be really nice to remove wsgi scripts with some time margin after adding modules to prevent circular dependencies from happening on integration tests, so that patches at least for "core" services could land smoothly.
On Thu, Dec 7, 2023, 12:41 Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI
"ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com :
o/
For anyone that hasn't been following along, there are changes
coming down the
line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
> From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get
with that for free.
I would like to hear other's opinions on this approach. As this
is something
that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
I did not split the patches for adding the new method and removing the old wsgi-scripts because I think we should just pull the bandaid off here. It's one of those situations where the distros and/or pip/setuptools are just going to break. We are either going to break people that expect the scripts now or in the future. I also found that the script generated by PBR is not handling the thread lock correctly (pylint complained when I created the wsgi module), so it's even slightly broken now (not that I'm 100% sure it would matter in practice). I lean towards a clear release note saying you need to change your deployment over the confusion of installations/upgrades just suddenly not deploying the scripts due to pip/setuptools updates we don't always have constraints over. Michael On Thu, Dec 7, 2023 at 3:41 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
On Thu, Dec 7, 2023, at 9:09 AM, Michael Johnson wrote:
I did not split the patches for adding the new method and removing the old wsgi-scripts because I think we should just pull the bandaid off here. It's one of those situations where the distros and/or pip/setuptools are just going to break. We are either going to break people that expect the scripts now or in the future. I also found that the script generated by PBR is not handling the thread lock correctly (pylint complained when I created the wsgi module), so it's even slightly broken now (not that I'm 100% sure it would matter in practice).
If this is an issue we should probably fix it. That said https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/useless-... appears to be the only lock related message in pylint and PBR is doing what is suggested: https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L378-L3.... I'm not sure what the problem would be given that.
I lean towards a clear release note saying you need to change your deployment over the confusion of installations/upgrades just suddenly not deploying the scripts due to pip/setuptools updates we don't always have constraints over.
Michael
On Thu, Dec 7, 2023 at 3:41 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>:
o/
For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack).
> From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former.
I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free.
I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier.
Please do let me know if you have any questions or concerns.
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1
On 12/7/23 18:17, Clark Boylan wrote:
On Thu, Dec 7, 2023, at 9:09 AM, Michael Johnson wrote:
I did not split the patches for adding the new method and removing the old wsgi-scripts because I think we should just pull the bandaid off here. It's one of those situations where the distros and/or pip/setuptools are just going to break. We are either going to break people that expect the scripts now or in the future. I also found that the script generated by PBR is not handling the thread lock correctly (pylint complained when I created the wsgi module), so it's even slightly broken now (not that I'm 100% sure it would matter in practice).
If this is an issue we should probably fix it. That said https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/useless-... appears to be the only lock related message in pylint and PBR is doing what is suggested: https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L378-L3.... I'm not sure what the problem would be given that.
Isn't it the same issue though? You're using a lock that you've just created, nothing else can use the same lock (if this code is called twice, it will create two locks). At least the lint may not understand the intentions there (given that I don't understand them either, and our computing overlords are only becoming smarter than me). Dmitry
I lean towards a clear release note saying you need to change your deployment over the confusion of installations/upgrades just suddenly not deploying the scripts due to pip/setuptools updates we don't always have constraints over.
Michael
On Thu, Dec 7, 2023 at 3:41 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: > > o/ > > For anyone that hasn't been following along, there are changes coming down the > line in the Python packaging world that look likely to break pbr's > 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then > at some point these auto-generated scripts will no longer end up in 'bin' when > pip installed (as we do with e.g. DevStack). > >> From where I'm standing, we appear to have two options: we can either invest > time in pbr to re-implement this functionality from scratch, or we can drop the > idea of auto-generating wsgi scripts from our packaging tool and instead start > using module paths. Having looked at the former, I suspect it is going to be a > *lot* of work that will require implementing our own PEP-517 compatible build > backend instead of cribbing setuptools' one as we do now. Personally, I don't > think this is a good investment of anyone's time, and it gives us more stuff to > maintain for the many years ahead (Did you know that pbr *still* technically > supports Python 2. Fun story that). As such, I think we should instead look to > the former. > > I've proposed some patches for Nova [1][2], which I am hoping will provide a > blueprint for the other services, and patch for DevStack to enable the new Nova > functionality [3]. As you'll see, these patches are relatively small and > hopefully easy to grok. The biggest downside I see to this approach is that > tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack > will need to start packaging their own wsgi script. This is because mod_wsgi > does not appear to support configuration by module paths. On the flipside, > gunicorn does not support configuration by wsgi script so we get that for free. > > I would like to hear other's opinions on this approach. As this is something > that likely affects all services, I suspect that if there's consensus that this > is the correct way to go, there should probably be a small goal drafted for the > current cycle. In my opinion, it would be good to do the migration consistently: > in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module > and IMO if all projects could adopt the same convention we would make the lives > of our deployment tooling colleagues easier. > > Please do let me know if you have any questions or concerns. > > Cheers, > Stephen > > [1] https://review.opendev.org/c/openstack/nova/+/902687/2 > [2] https://review.opendev.org/c/openstack/nova/+/902688/2 > [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 >
On Thu, Dec 7, 2023, at 10:17 AM, Dmitry Tantsur wrote:
On 12/7/23 18:17, Clark Boylan wrote:
On Thu, Dec 7, 2023, at 9:09 AM, Michael Johnson wrote:
I did not split the patches for adding the new method and removing the old wsgi-scripts because I think we should just pull the bandaid off here. It's one of those situations where the distros and/or pip/setuptools are just going to break. We are either going to break people that expect the scripts now or in the future. I also found that the script generated by PBR is not handling the thread lock correctly (pylint complained when I created the wsgi module), so it's even slightly broken now (not that I'm 100% sure it would matter in practice).
If this is an issue we should probably fix it. That said https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/useless-... appears to be the only lock related message in pylint and PBR is doing what is suggested: https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L378-L3.... I'm not sure what the problem would be given that.
Isn't it the same issue though? You're using a lock that you've just created, nothing else can use the same lock (if this code is called twice, it will create two locks). At least the lint may not understand the intentions there (given that I don't understand them either, and our computing overlords are only becoming smarter than me).
https://review.opendev.org/c/openstack/pbr/+/217733 introduced this code to PBR. The assertion seems to be that application is a global object, and I guess assumed that anything in that scope is also global? I don't know enough about mod_wsgi to know for sure. It is entirely possible that creating the lock, grabbing the lock, and checking if application is None was enough of a race condition reordering that the problem wasn't seen despite the lock being useless as a proper lock.
Dmitry
Ah, I copy-pastaed[1] and didn't look close enough that it was different from the file created by PBR. [1] https://review.opendev.org/c/openstack/nova/+/902687/4/nova/wsgi/osapi_compu... Michael On Thu, Dec 7, 2023 at 9:18 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Thu, Dec 7, 2023, at 9:09 AM, Michael Johnson wrote:
I did not split the patches for adding the new method and removing the old wsgi-scripts because I think we should just pull the bandaid off here. It's one of those situations where the distros and/or pip/setuptools are just going to break. We are either going to break people that expect the scripts now or in the future. I also found that the script generated by PBR is not handling the thread lock correctly (pylint complained when I created the wsgi module), so it's even slightly broken now (not that I'm 100% sure it would matter in practice).
If this is an issue we should probably fix it. That said https://pylint.readthedocs.io/en/latest/user_guide/messages/warning/useless-... appears to be the only lock related message in pylint and PBR is doing what is suggested: https://opendev.org/openstack/pbr/src/branch/master/pbr/packaging.py#L378-L3.... I'm not sure what the problem would be given that.
I lean towards a clear release note saying you need to change your deployment over the confusion of installations/upgrades just suddenly not deploying the scripts due to pip/setuptools updates we don't always have constraints over.
Michael
On Thu, Dec 7, 2023 at 3:41 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2023-12-06 at 18:13 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 17:44 +0000, Stephen Finucane wrote:
On Wed, 2023-12-06 at 13:05 +0100, Dmitriy Rabotyagov wrote:
As long as the module path is documented and/or constrained/aligned across all projects - that should be a totally fine change.
This is my preference also and part of the reason for the original email. Django's quickstart tool ('django startproject') places a 'wsgi.py' file in the root of the project [1], which seems like a good convention to follow. However, given some services (Nova, ...?) expose multiple WSGI servers, we need another layer of nesting.
If we could settle on a pattern of '<service>.wsgi.<server>:application' I imagine we'd meet mostly everyone's needs and keep things easy for deployment tooling.
Stephen
[1] https://docs.djangoproject.com/en/4.2/howto/deployment/wsgi/
I have proposed a goal to make this clear and help ensure we deliver a consistent pattern across services.
https://review.opendev.org/c/openstack/governance/+/902807
Stephen
Question for the (deployment tooling-focused) audience: is there any advantage to delaying the removal of the wsgi scripts by a cycle and/or backporting the addition of the '<service>.wsgi' modules to Bobcat? Takashi-san brought this up on the goal doc and I'm wondering if we should refine it to include this.
For context, editable wheels built under recent versions of setuptools/pip will not include these scripts (which is a pressing issue for DevStack) but for now they will still be present in non-editable wheels (using the latest pip (23.3.1), setuptools (69.0.2), and pbr (6.0.0)). I don't know how long this situation will last, however. As such, there's no real _cost_ to keeping things around but things will behave differently depending on your environment which will undoubtedly be a source of confusion.
Stephen
From an OpenStack-Ansible perspective quite trivial change would be needed to be done and I don't see any huge blocker with that.
Regarding Apache+mod_wsgi - well, you still can use Apache+uWSGI with "ProxyPass / uwsgi://127.0.0.1:5000" for instance. But if we really want to support Apache+mod_wsgi then some example script should be placed somewhere to ease life of those who decide to deploy OpenStack manually.
ср, 6 дек. 2023 г. в 12:01, Stephen Finucane <stephenfin@redhat.com>: > > o/ > > For anyone that hasn't been following along, there are changes coming down the > line in the Python packaging world that look likely to break pbr's > 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then > at some point these auto-generated scripts will no longer end up in 'bin' when > pip installed (as we do with e.g. DevStack). > > > From where I'm standing, we appear to have two options: we can either invest > time in pbr to re-implement this functionality from scratch, or we can drop the > idea of auto-generating wsgi scripts from our packaging tool and instead start > using module paths. Having looked at the former, I suspect it is going to be a > *lot* of work that will require implementing our own PEP-517 compatible build > backend instead of cribbing setuptools' one as we do now. Personally, I don't > think this is a good investment of anyone's time, and it gives us more stuff to > maintain for the many years ahead (Did you know that pbr *still* technically > supports Python 2. Fun story that). As such, I think we should instead look to > the former. > > I've proposed some patches for Nova [1][2], which I am hoping will provide a > blueprint for the other services, and patch for DevStack to enable the new Nova > functionality [3]. As you'll see, these patches are relatively small and > hopefully easy to grok. The biggest downside I see to this approach is that > tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack > will need to start packaging their own wsgi script. This is because mod_wsgi > does not appear to support configuration by module paths. On the flipside, > gunicorn does not support configuration by wsgi script so we get that for free. > > I would like to hear other's opinions on this approach. As this is something > that likely affects all services, I suspect that if there's consensus that this > is the correct way to go, there should probably be a small goal drafted for the > current cycle. In my opinion, it would be good to do the migration consistently: > in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module > and IMO if all projects could adopt the same convention we would make the lives > of our deployment tooling colleagues easier. > > Please do let me know if you have any questions or concerns. > > Cheers, > Stephen > > [1] https://review.opendev.org/c/openstack/nova/+/902687/2 > [2] https://review.opendev.org/c/openstack/nova/+/902688/2 > [3] https://review.opendev.org/c/openstack/devstack/+/902758/1 >
participants (10)
-
Arnaud Morin
-
Clark Boylan
-
Dmitriy Rabotyagov
-
Dmitry Tantsur
-
Michael Johnson
-
Michał Nasiadka
-
smooney＠redhat.com
-
Stephen Finucane
-
Takashi Kajinami
-
Tobias Urdin