Hey folks,

From a RHEL/CentOS perspective, uWSGI is also not packaged in the main repositories meaning it is effectively unsupported as well. It is in the Extra Packages for Enterprise Linux (EPEL) repository but we do not support mixing our RDO (OpenStack) packages with EPEL as it will almost always guarantee issues with dependencies. In the TripleO community, because of this, we have had to stick with using Apache's WSGI module for serving the OpenStack API endpoints.

I do think the proposal sounds great and if anyone wants to work on adding the Puppet bits to support uWSGI then I do not believe anyone will stop you. The real-world testing and usage of it by other distributions may be minimal due to these packaging and support restraints. Alternatively you may also want to look into OpenStack-Ansible as they heavily use uWSGI with Ubuntu based containers managed by Ansible.

Sincerely,

Luke Short

On Mon, May 4, 2020 at 6:35 AM Thomas Goirand <zigo@debian.org> wrote:

On 5/3/20 10:17 PM, Tobias Urdin wrote:
> Hello Thomas,
> Thanks for starting this thread!
>
> I've been thinking about this as well, but due to other reason, how we can continue to abstract the service layer
> used in the Puppet modules.
>
> The most deployed way right now is the <module>::wsgi::apache (using puppetlabs-apache).
>
> Do you think there is a way we could move uWSGI into it's own <module>::wsgi::uwsgi layer and then use an
> upstream uWSGI module to do the actual configuration? Since uWSGI isn't in the OpenStack scope, same as
> Apache configuration hence the usage of puppetlabs-apache.
>
> I've been thinking about a similar concept with other service layers, like Docker with Kolla containers etc even
> though it's kind of out of scope for the Puppet OpenStack project, just thoughts.
>
> Best regards
> Tobias

Hi Tobias,

What you must know, is that uwsgi is not in main in Ubuntu (it is in
"universe", meaning it's just imported from Debian Sid when they release
the LTS). This means that Canonical don't provide support for it at all.
If one day, there's a security issue on it, Canonical will claim it is
"community maintained" and therefore, they will put no effort on
upgrading it.

The consequence is that it's not reasonable to use uwsgi in Ubuntu,
unless the situation with this package changes. We could still support
it, but I wouldn't recommend it for security and maintainability reasons.

In Debian, the situation is very different. All OpenStack services are
using uwsgi directly, and don't need to be configured in any way to use
uwsgi. You just install <FOO>-api and it runs over UWSGI. So, in terms
of puppet, for Debian, the only thing we need to do is to use something
like this:

service{ 'foo-api':}

which looks like what we used to do with Eventlet.

Now, I don't know what the situation is on CentOS/Red Hat. If you think
it's valuable to support uwsgi there, then why not. But I'm not
interested in contributing it.

What I care right now, is being able to configure the uwsgi thing for
the API. Namely, being able to configure the "processes" directive is
the most important bit. Just having the puppet provider could be enough,
though integrating it with the API's <service>::api "workers" parameter
would be nice.

Your thoughts?

Cheers,

Thomas Goirand (zigo)