<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 25, 2017 at 9:56 AM, Jeffrey Zhang <span dir="ltr"><<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small">thanks mnaser and sam for the advice.</div><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">i think uwsgi + native http is not a good solution, nova. A http<br>server + uwsgi is better. So i am imaging that the deployment</div><div style="font-family:monospace,monospace;font-size:small">architecture will be like</div><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc. </div><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">As mnaster said, one http server serve for others uwsgi services.</div><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">on the other hand, which following solution is better?</div><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">- apache + mod_uwsgi ( not recommended by uwsgi )</div><div style="font-family:monospace,monospace;font-size:small">- apache + mode_proxy_uwsgi ( recommended by uwsgi)</div><div style="font-family:monospace,monospace;font-size:small">- nginx + uwsgi</div><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">So the question is why community choose apache rather than nginx?</div></div></blockquote><div><br></div><div>Well, in TripleO we're using apache + mod_wsgi [1]   not mod_uwsgi.<br></div><div><br></div><div>[1] <a href="https://modwsgi.readthedocs.io/en/develop/">https://modwsgi.readthedocs.io/en/develop/</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small"><br></div><div style="font-family:monospace,monospace;font-size:small">[0] <a href="http://uwsgi-docs.readthedocs.io/en/latest/Apache.html" target="_blank">http://uwsgi-docs.<wbr>readthedocs.io/en/latest/<wbr>Apache.html</a></div><div style="font-family:monospace,monospace;font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple <span dir="ltr"><<a href="mailto:samuel@yaple.net" target="_blank">samuel@yaple.net</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div><div>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.<br><br></div>Additionally, running with HTTPS was measurably faster with nginx proxying to a uwsgi socket.<br><br></div>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.<br><br></div><div class="gmail-m_-3625873592133074795HOEnZb"><div class="gmail-m_-3625873592133074795h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser <span dir="ltr"><<a href="mailto:mnaser@vexxhost.com" target="_blank">mnaser@vexxhost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>> wrote:<br>
> We are moving to deploy service via WSGI[0].<br>
><br>
> There are two recommended ways.<br>
><br>
> - apache + mod_wsgi<br>
> - nginx + uwsgi<br>
><br>
> later one is more better.<br>
><br>
> For traditional deployment, it is easy to implement. Use one<br>
> uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc).<br>
> Then one nginx process to forward the http require into uwsgi server.<br>
><br>
> But kolla is running one process in one container. If we use<br>
> the recommended solution, we have to use two container to run<br>
> nova-api container. and it will generate lots of containers.<br>
> like: nginx-nova-api, uwsig-nova-api.<br>
><br>
> i propose use uwsgi native http mode[1]. Then one uwsgi<br>
> container is enough to run nova-api service. Base one the official<br>
> doc, if there is no static resource, uWSGI is recommended to use<br>
> as a real http server.<br>
><br>
> So how about this?<br>
<br>
</span>I think this is an interesting approach.  At the moment, the Puppet<br>
modules currently allow deploying for services using mod_wsgi.<br>
Personally, I don't think that relying on the HTTP support of uWSGI is<br>
very favorable.   It is quite difficult to configure and 'get right'<br>
and it leaves a lot to be desired (for example, federated auth relies<br>
on Apache modules which would make this nearly impossible).<br>
<br>
Given that the current OpenStack testing infrastructure proxies to<br>
UWSGI, I think it would be best if that approach is taken.  This way,<br>
a container (or whatever service) would expose a UWSGI API, which you<br>
can connect whichever web server that you need.<br>
<br>
In the case of Kolla, the `httpd` container would be similar to what<br>
the `haproxy` is.  In the case of Puppet, I can imagine this being<br>
something to be managed by the user (with some helpers in there).  I<br>
think it would be interesting to add the tripleo folks on their<br>
opinion here as consumers of the Puppet modules.<br>
<span><br>
><br>
><br>
> [0] <a href="https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/pike/deploy-api-in<wbr>-wsgi.html</a><br>
> [1]<br>
> <a href="http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-use-uwsgi-s-http-capabilities-in-production" rel="noreferrer" target="_blank">http://uwsgi-docs.readthedocs.<wbr>io/en/latest/HTTP.html#can-i-u<wbr>se-uwsgi-s-http-capabilities-i<wbr>n-production</a><br>
><br>
> --<br>
> Regards,<br>
> Jeffrey Zhang<br>
> Blog: <a href="http://xcodest.me" rel="noreferrer" target="_blank">http://xcodest.me</a><br>
><br>
</span>> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
</blockquote></div><br></div>
</div></div><br></div></div>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><span class="gmail-"><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-3625873592133074795gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Regards,</font></span></div><div><span style="font-size:13px;border-collapse:collapse"><font face="monospace, monospace">Jeffrey Zhang</font></span></div><div><span style="font-family:monospace,monospace;font-size:12.8px">Blog: </span><a href="http://xcodest.me/" style="font-family:monospace,monospace;font-size:12.8px" target="_blank">http://xcodest.me</a><font face="monospace, monospace"><br></font></div></div></div></div></div></div></div></div></div>
</span></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div>