Open Stack

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)