Open Stack

On Tue, May 23, 2017 at 11:18 AM, Juan Antonio Osorio <jaosorior at gmail.com>
wrote:

>
>
> On Tue, May 23, 2017 at 8:23 AM, Rabi Mishra <ramishra at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Rabi Misra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170523/3b7a5b49/attachment.html>