On Tue, May 23, 2017 at 11:18 AM, Juan Antonio Osorio <[email protected]> wrote:
> > > On Tue, May 23, 2017 at 8:23 AM, Rabi Mishra <[email protected]> wrote: > >> Hi All, >> >> As per the updated community goal[1] for api deployment with wsgi, we've >> to transition to use uwsgi rather than mod_wsgi at the gate. It also seems >> mod_wsgi support would be removed from devstack in Queens. >> > What do you mean support for mod_wsgi will be removed from devstack in > Queens? other projects have been using mod_wsgi and we've been deploying > several services (even Heat) in TripleO. > I think it's mentioned in the community goal I linked earlier - "with the intent that the mod_wsgi support is deleted from devstack in Queens". Atleast that's the intent I assume;) > > >> I've been working on a patch[2] for the transition and encountered a few >> issues as below. >> >> 1. We encode stack_indentifer(<stack_name/stack_id> along with the path >> separator in heatclient. So, requests with encoded path separators are >> dropped by apache (with 404), if we don't have 'AllowEncodedSlashes On' >> directive in the site/vhost config[3]. >> > That's correct. You might want to refer to the configuration we use in > puppet/TripleO. We got it working with that :). > https://github.com/openstack/puppet-heat/blob/master/ > manifests/wsgi/apache.pp#L111-L137 > >> >> Setting this for mod_proxy_uwsgi[4] seems to work on fedora but not >> ubuntu. From my testing It seems, it has to be set in 000-default.conf for >> ubuntu. >> >> Rather than messing with the devstack plugin code, I went ahead proposed >> a change to not encode the path separators in heatclient[5] ( Anyway they >> would be decoded by apache with the directive 'AllowEncodedSlashes On' >> before it's consumed by the service) which seem to have fixed those 404s. >> >> Is there a generic way to set the above directive (when using >> apache+mod_proxy_uwsgi) in the devstack plugin? >> >> 2. With the above, most of the tests seem to work fine other than the >> ones using waitcondition, where we signal back from the vm to the api >> services. I could see " curl: (7) Failed to connect to 10.0.1.78 port >> 80: No route to host" in the vm console logs[6]. >> >> It could connect to heat api services using ports 8004/8000 without this >> patch, but not sure why not port 80? I tried testing this locally and >> didn't see the issue though. >> >> Is this due to some infra settings or something else? >> >> >> [1] https://governance.openstack.org/tc/goals/pike/deploy-api-in >> -wsgi.html >> >> [2] https://review.openstack.org/#/c/462216/ >> >> [3] https://github.com/openstack/heat/blob/master/devstack/files >> /apache-heat-api.template#L9 >> >> [4] http://logs.openstack.org/16/462216/6/check/gate-heat-dsvm-f >> unctional-convg-mysql-lbaasv2-non-apache-ubuntu-xenial/ >> fbd06d6/logs/apache_config/heat-wsgi-api.conf.txt.gz >> >> [5] https://review.openstack.org/#/c/463510/ >> >> [6] http://logs.openstack.org/16/462216/11/check/gate-heat-dsvm- >> functional-convg-mysql-lbaasv2-non-apache-ubuntu-xenial/ >> e7d9e90/console.html#_2017-05-20_07_04_30_718021 >> >> >> -- >> Regards, >> Rabi Mishra >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Juan Antonio Osorio R. > e-mail: [email protected] > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Regards, Rabi Misra
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
