Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Rabi Mishra]

On Wed, May 24, 2017 at 9:24 AM, Rabi Mishra  wrote:

> On Tue, May 23, 2017 at 11:57 PM, Zane Bitter  wrote:
>
>> On 23/05/17 01:23, Rabi Mishra 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.
>>>
>>> I've been working on a patch[2] for the transition and encountered a few
>>> issues as below.
>>>
>>> 1. We encode stack_indentifer( 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].
>>>
>>
>> We'd probably want 'AllowEncodedSlashes NoDecode'.
>>
>
> Yeah, that would be ideal  for supporting slashes in stack and resource
> names where we take care of the encoding and decoding.
>
>
>> 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.
>>>
>>
>> Pasting my comment from the patch:
>>
>> One potential problem with this is that you can probably craft a stack
>> name in such a way that heatclient ends up calling a real but unexpected
>> URL. (I don't think this is a new problem, but it's likely the problem that
>> the default value of AllowEncodedSlashes is designed to fix, and we're
>> circumventing it here.)
>>
>
>> It seems to me the ideal would be to force '/'s to be encoded when they
>> occur in the stack and resource names. Clearly they should never have been
>> encoded when they're actual path separators (e.g. between the stack name
>> and stack ID).
>>
> It'd be even better if Apache were set to "AllowEncodedSlashes NoDecode"
>> and we could then decode stack/resource names that include slashes after
>> splitting at the path separators, so that those would actually work. I
>> don't think the routing framework can handle that though.
>>
>>
> I don't think we even support slashes (encoded or not) in stack name. The
> validation below would not allow it.
>
> https://git.openstack.org/cgit/openstack/heat/tree/heat/
> engine/stack.py#n143
>
> As far as resource names are concerned, we don't encode or decode them
> appropriately for it to work as expected. Creating a stack with resource
> name containing '/' fails with validation error as it's not encoded for
> being inside the template snippet and the validation below would fail.
>
> https://git.openstack.org/cgit/openstack/heat/tree/heat/
> engine/resource.py#n214
>
> For that reason I believe we disallow slashes in stack/resource names. So
>> with "AllowEncodedSlashes Off" we'd get the right behaviour (which is to
>> always 404 when the stack/resource name contains a slash).
>>
>
>>
> 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
>>>
>>
>> Not related to the problem below, but I believe that when signalling
>> through the heat-cfn-api we use an arn to identify the stack, and I suspect
>> that slashes in the arn are escaped at or near the source. So we may have
>> no choice but to find a way to turn on AllowEncodedSlashes. Or is it in the
>> query string part anyway?
>>
>> Yeah, it's not related to the problem below as the request not reaching
> apache at all. I've  taken care of the above issue in the patch itself[1]
> and the signal url looks ok to me[2].
>
> [1] https://review.openstack.org/#/c/462216/11/heat/common/identifier.py
>
> [2] 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_500696
>
> 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?
>>>
>>>
I finally found out the reason for the above issue. We're explicitly
allowing nova vms to access heat api services with some iptables rules.

I've submitted a project-config patch[1] to add port 80.

[1] https://review.openstack.org/#/c/467703


>
>>> [1] https://governance.openstack.org/tc/goals/pike/deploy-api-in
>>> -wsgi.html
>>>
>>> [2] 

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Rabi Mishra]

On Tue, May 23, 2017 at 11:57 PM, Zane Bitter  wrote:

> On 23/05/17 01:23, Rabi Mishra 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.
>>
>> I've been working on a patch[2] for the transition and encountered a few
>> issues as below.
>>
>> 1. We encode stack_indentifer( 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].
>>
>
> We'd probably want 'AllowEncodedSlashes NoDecode'.
>

Yeah, that would be ideal  for supporting slashes in stack and resource
names where we take care of the encoding and decoding.


> 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.
>>
>
> Pasting my comment from the patch:
>
> One potential problem with this is that you can probably craft a stack
> name in such a way that heatclient ends up calling a real but unexpected
> URL. (I don't think this is a new problem, but it's likely the problem that
> the default value of AllowEncodedSlashes is designed to fix, and we're
> circumventing it here.)
>

> It seems to me the ideal would be to force '/'s to be encoded when they
> occur in the stack and resource names. Clearly they should never have been
> encoded when they're actual path separators (e.g. between the stack name
> and stack ID).
>
It'd be even better if Apache were set to "AllowEncodedSlashes NoDecode"
> and we could then decode stack/resource names that include slashes after
> splitting at the path separators, so that those would actually work. I
> don't think the routing framework can handle that though.
>
>
I don't think we even support slashes (encoded or not) in stack name. The
validation below would not allow it.

https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/stack.py#n143

As far as resource names are concerned, we don't encode or decode them
appropriately for it to work as expected. Creating a stack with resource
name containing '/' fails with validation error as it's not encoded for
being inside the template snippet and the validation below would fail.

https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resource.py#n214

For that reason I believe we disallow slashes in stack/resource names. So
> with "AllowEncodedSlashes Off" we'd get the right behaviour (which is to
> always 404 when the stack/resource name contains a slash).
>

>
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
>>
>
> Not related to the problem below, but I believe that when signalling
> through the heat-cfn-api we use an arn to identify the stack, and I suspect
> that slashes in the arn are escaped at or near the source. So we may have
> no choice but to find a way to turn on AllowEncodedSlashes. Or is it in the
> query string part anyway?
>
> Yeah, it's not related to the problem below as the request not reaching
apache at all. I've  taken care of the above issue in the patch itself[1]
and the signal url looks ok to me[2].

[1] https://review.openstack.org/#/c/462216/11/heat/common/identifier.py

[2]
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_500696

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-
>> 

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Zane Bitter]

On 23/05/17 01:23, Rabi Mishra 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.

I've been working on a patch[2] for the transition and encountered a few
issues as below.

1. We encode stack_indentifer( 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].


We'd probably want 'AllowEncodedSlashes NoDecode'.


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.


Pasting my comment from the patch:

One potential problem with this is that you can probably craft a stack 
name in such a way that heatclient ends up calling a real but unexpected 
URL. (I don't think this is a new problem, but it's likely the problem 
that the default value of AllowEncodedSlashes is designed to fix, and 
we're circumventing it here.)


It seems to me the ideal would be to force '/'s to be encoded when they 
occur in the stack and resource names. Clearly they should never have 
been encoded when they're actual path separators (e.g. between the stack 
name and stack ID).


It'd be even better if Apache were set to "AllowEncodedSlashes NoDecode" 
and we could then decode stack/resource names that include slashes after 
splitting at the path separators, so that those would actually work. I 
don't think the routing framework can handle that though.


For that reason I believe we disallow slashes in stack/resource names. 
So with "AllowEncodedSlashes Off" we'd get the right behaviour (which is 
to always 404 when the stack/resource name contains a slash).



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


Not related to the problem below, but I believe that when signalling 
through the heat-cfn-api we use an arn to identify the stack, and I 
suspect that slashes in the arn are escaped at or near the source. So we 
may have no choice but to find a way to turn on AllowEncodedSlashes. Or 
is it in the query string part anyway?



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




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Rabi Mishra]

Apologies for the spam. Resending  with the earlier missed [openstack-dev]
tag to the subject for greater visibility.

On Tue, May 23, 2017 at 10:53 AM, Rabi Mishra  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.
>
> I've been working on a patch[2] for the transition and encountered a few
> issues as below.
>
> 1. We encode stack_indentifer( 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].
>
> 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-
> functional-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
>
>


-- 
Regards,
Rabi Misra
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Rabi Mishra]

On Tue, May 23, 2017 at 11:18 AM, Juan Antonio Osorio 
wrote:

>
>
> On Tue, May 23, 2017 at 8:23 AM, Rabi Mishra  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( 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-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Rabi Misra
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Juan Antonio Osorio]

On Tue, May 23, 2017 at 8:23 AM, Rabi Mishra  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've been working on a patch[2] for the transition and encountered a few
> issues as below.
>
> 1. We encode stack_indentifer( 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-
> functional-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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [heat] [devstack] [infra] heat api services with uwsgi

[Rabi Mishra]

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.

I've been working on a patch[2] for the transition and encountered a few
issues as below.

1. We encode stack_indentifer( 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].

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