settingsLogin | Registersettings

Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

0 votes

On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang zhang.lei.fly@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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Aug 25, 2017 in openstack-dev by Mohammed_Naser (3,860 points)   1 3

4 Responses

0 votes

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@vexxhost.com
wrote:

On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang zhang.lei.fly@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 24, 2017 by Sam_Yaple (3,560 points)   3 3
0 votes

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 -> uwsginovaapi / uwsgiglanceapi 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 + modeproxyuwsgi ( recommended by uwsgi)
  • nginx + uwsgi

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@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@vexxhost.com
wrote:

On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang zhang.lei.fly@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@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@lists.openstack.org?subject:unsubscribe
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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 25, 2017 by Lei_Zhang (6,360 points)   1 2 5
0 votes

On Fri, Aug 25, 2017 at 9:56 AM, Jeffrey Zhang zhang.lei.fly@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 -> uwsginovaapi / uwsgiglanceapi 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 + modeproxyuwsgi ( recommended by uwsgi)
  • nginx + uwsgi

So the question is why community choose apache rather than nginx?

Well, in TripleO we're using apache + modwsgi [1] not moduwsgi.

[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@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@vexxhost.com
wrote:

On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang zhang.lei.fly@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
k-operators


OpenStack-operators mailing list
OpenStack-operators@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Juan Antonio Osorio R.
e-mail: jaosorior@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 25, 2017 by Juan_Antonio_Osorio (2,900 points)   1 2
0 votes

On Fri, Aug 25, 2017 at 2:56 AM, Jeffrey Zhang zhang.lei.fly@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 -> uwsginovaapi / uwsgiglanceapi 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 + modeproxyuwsgi ( 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@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@vexxhost.com
wrote:

On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang zhang.lei.fly@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.


OpenStack-operators mailing list
OpenStack-operators@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Aug 25, 2017 by Mohammed_Naser (3,860 points)   1 3
...