Open Stack

On Fri, Aug 25, 2017 at 9: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 )
> - apache + mode_proxy_uwsgi ( recommended by uwsgi)
> - nginx + uwsgi
>
> So the question is why community choose apache rather than nginx?
>

Well, in TripleO we're using apache + mod_wsgi [1]   not mod_uwsgi.

[1] https://modwsgi.readthedocs.io/en/develop/

>
> [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-u
>>> se-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/openstac
>>> k-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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __________________________________________________________________________
> 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
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170825/35366549/attachment.html>