Open Stack

On Fri, Aug 25, 2017 at 2:56 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com> wrote:
> thanks mnaser and sam for the advice.
>
> i think uwsgi + native http is not a good solution, nova. A http
> server + uwsgi is better. So i am imaging that the deployment
> architecture will be like
>
> haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc.
>
> As mnaster said, one http server serve for others uwsgi services.
>
> on the other hand, which following solution is better?
>
> - apache + mod_uwsgi ( not recommended by uwsgi )

Not recommended by them is probably a sign to stay away

> - apache + mode_proxy_uwsgi ( recommended by uwsgi)

This has two advantages.   DevStack at the gate tests using this exact
architecture AFAIK which means that we would less likely run into
issues that were never discovered in testing.

> - nginx + uwsgi

I like this a lot, however, for applications such as Keystone, they
sometimes rely on Apache for some features (such as Federation:
https://docs.openstack.org/keystone/latest/advanced-topics/federation/configure_federation.html#configure-apache-to-use-a-federation-capable-authentication-method)

However, Apache has done a lot of improvements in terms of catching up
to nginx and if using an MPM worker such as mpm_event, you would end
up with a very similar architecture and performance.

>
> So the question is why community choose apache rather than nginx?
>
> [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html
>
>
> On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple <samuel at yaple.net> wrote:
>>
>> I have been running api services behind uwsgi in http mode from Newton
>> forward. I recently switched to the uwsgi+nginx model with 2 containers
>> since I was having wierd issues with things that I couldn't track down.
>> Mainly after I started using keystone with ldap. There would be timeouts and
>> message-to-long type errors that all went away with nginx.
>>
>> Additionally, running with HTTPS was measurably faster with nginx proxying
>> to a uwsgi socket.
>>
>> This was just my experience with it, if you do want to switch to
>> uwsgi+http make sure you do thorough testing of all the components or you
>> may be left with a component that just won't work with your model.
>>
>>
>> On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser <mnaser at vexxhost.com>
>> wrote:
>>>
>>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
>>> wrote:
>>> > We are moving to deploy service via WSGI[0].
>>> >
>>> > There are two recommended ways.
>>> >
>>> > - apache + mod_wsgi
>>> > - nginx + uwsgi
>>> >
>>> > later one is more better.
>>> >
>>> > For traditional deployment, it is easy to implement. Use one
>>> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api ,
>>> > etc).
>>> > Then one nginx process to forward the http require into uwsgi server.
>>> >
>>> > But kolla is running one process in one container. If we use
>>> > the recommended solution, we have to use two container to run
>>> > nova-api container. and it will generate lots of containers.
>>> > like: nginx-nova-api, uwsig-nova-api.
>>> >
>>> > i propose use uwsgi native http mode[1]. Then one uwsgi
>>> > container is enough to run nova-api service. Base one the official
>>> > doc, if there is no static resource, uWSGI is recommended to use
>>> > as a real http server.
>>> >
>>> > So how about this?
>>>
>>> I think this is an interesting approach.  At the moment, the Puppet
>>> modules currently allow deploying for services using mod_wsgi.
>>> Personally, I don't think that relying on the HTTP support of uWSGI is
>>> very favorable.   It is quite difficult to configure and 'get right'
>>> and it leaves a lot to be desired (for example, federated auth relies
>>> on Apache modules which would make this nearly impossible).
>>>
>>> Given that the current OpenStack testing infrastructure proxies to
>>> UWSGI, I think it would be best if that approach is taken.  This way,
>>> a container (or whatever service) would expose a UWSGI API, which you
>>> can connect whichever web server that you need.
>>>
>>> In the case of Kolla, the `httpd` container would be similar to what
>>> the `haproxy` is.  In the case of Puppet, I can imagine this being
>>> something to be managed by the user (with some helpers in there).  I
>>> think it would be interesting to add the tripleo folks on their
>>> opinion here as consumers of the Puppet modules.
>>>
>>> >
>>> >
>>> > [0]
>>> > https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
>>> > [1]
>>> >
>>> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-use-uwsgi-s-http-capabilities-in-production
>>> >
>>> > --
>>> > Regards,
>>> > Jeffrey Zhang
>>> > Blog: http://xcodest.me
>>> >
>>> > _______________________________________________
>>> > OpenStack-operators mailing list
>>> > OpenStack-operators at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> >
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>