Open Stack

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
<https://github.com/openstack/ansible-role-uwsgi> with Ubuntu based
containers managed by Ansible.

Sincerely,
    Luke Short

On Mon, May 4, 2020 at 6:35 AM Thomas Goirand <zigo at 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200504/06fc072f/attachment.html>