[openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi
ramishra at redhat.com
Tue May 23 06:06:20 UTC 2017
On Tue, May 23, 2017 at 11:18 AM, Juan Antonio Osorio <jaosorior at gmail.com>
> On Tue, May 23, 2017 at 8:23 AM, Rabi Mishra <ramishra at redhat.com> wrote:
>> Hi All,
>> As per the updated community goal 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 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.
> That's correct. You might want to refer to the configuration we use in
> puppet/TripleO. We got it working with that :).
>> Setting this for mod_proxy_uwsgi seems to work on fedora but not
>> ubuntu. From my testing It seems, it has to be set in 000-default.conf for
>> Rather than messing with the devstack plugin code, I went ahead proposed
>> a change to not encode the path separators in heatclient ( 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.
>> 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?
>>  https://governance.openstack.org/tc/goals/pike/deploy-api-in
>>  https://review.openstack.org/#/c/462216/
>>  https://github.com/openstack/heat/blob/master/devstack/files
>>  http://logs.openstack.org/16/462216/6/check/gate-heat-dsvm-f
>>  https://review.openstack.org/#/c/463510/
>>  http://logs.openstack.org/16/462216/11/check/gate-heat-dsvm-
>> Rabi Mishra
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
> Juan Antonio Osorio R.
> e-mail: jaosorior at gmail.com
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev