<div dir="ltr">On Tue, May 23, 2017 at 11:57 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 23/05/17 01:23, Rabi Mishra wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi All,<br>
<br>
As per the updated community goal[1]  for api deployment with wsgi,<br>
we've to transition to use uwsgi rather than mod_wsgi at the gate. It<br>
also seems mod_wsgi support would be removed from devstack in Queens.<br>
<br>
I've been working on a patch[2] for the transition and encountered a few<br>
issues as below.<br>
<br>
1. We encode stack_indentifer(<stack_name/s<wbr>tack_id> along with the path<br>
separator in heatclient. So, requests with encoded path separators are<br>
dropped by apache (with 404), if we don't have 'AllowEncodedSlashes On'<br>
directive in the site/vhost config[3].<br>
</blockquote>
<br></span>
We'd probably want 'AllowEncodedSlashes NoDecode'.<span class="gmail-"><br></span></blockquote><div><br></div><div>Yeah, that would be ideal  for supporting slashes in stack and resource names where we take care of the encoding and decoding.   <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Setting this for mod_proxy_uwsgi[4] seems to work on fedora but not<br>
ubuntu.  From my testing It seems, it has to be set in 000-default.conf<br>
for ubuntu.<br>
<br>
Rather than messing with the devstack plugin code, I went ahead proposed<br>
a change to not encode the path separators in heatclient[5] ( Anyway<br>
they would be decoded by apache with the directive 'AllowEncodedSlashes<br>
On' before it's consumed by the service) which seem to have fixed those<br>
404s.<br>
</blockquote>
<br></span>
Pasting my comment from the patch:<br>
<br>
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.) <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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). <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br></blockquote><div><br></div><div>I don't think we even support slashes (encoded or not) in stack name. The validation below would not allow it. <br><br><a href="https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/stack.py#n143">https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/stack.py#n143</a><br><br></div><div>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.<br><br><a href="https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resource.py#n214">https://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resource.py#n214</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<span class="gmail-"></span> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"> 
</span><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is there a generic way to set the above directive (when using<br>
apache+mod_proxy_uwsgi) in the devstack plugin?<br>
<br>
2.  With the above, most of the tests seem to work fine other than the<br>
ones using waitcondition, where we signal back from the vm to the api<br>
</blockquote>
<br></span>
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?<br>
<br></blockquote><div>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]. <br><br>[1] <a href="https://review.openstack.org/#/c/462216/11/heat/common/identifier.py">https://review.openstack.org/#/c/462216/11/heat/common/identifier.py</a><br><br>[2] <a href="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">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</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
services. I could see " curl: (7) Failed to connect to 10.0.1.78 port<br>
80: No route to host" in the vm console logs[6].<br>
<br>
It could connect to heat api services using ports 8004/8000 without this<br>
patch, but not sure why not port 80? I tried testing this locally and<br>
didn't see the issue though.<br>
<br>
Is this due to some infra settings or something else?<br>
<br>
<br>
[1] <a href="https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/tc/goals/pike/deploy-api-in<wbr>-wsgi.html</a><br>
<br>
[2] <a href="https://review.openstack.org/#/c/462216/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/462216/</a><br>
<br>
[3]<br>
<a href="https://github.com/openstack/heat/blob/master/devstack/files/apache-heat-api.template#L9" rel="noreferrer" target="_blank">https://github.com/openstack/h<wbr>eat/blob/master/devstack/files<wbr>/apache-heat-api.template#L9</a><br>
<br>
[4]<br>
<a href="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" rel="noreferrer" target="_blank">http://logs.openstack.org/16/4<wbr>62216/6/check/gate-heat-dsvm-f<wbr>unctional-convg-mysql-lbaasv2-<wbr>non-apache-ubuntu-xenial/<wbr>fbd06d6/logs/apache_config/<wbr>heat-wsgi-api.conf.txt.gz</a><br>
<br>
[5] <a href="https://review.openstack.org/#/c/463510/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/463510/</a><br>
<br>
[6]<br>
<a href="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" rel="noreferrer" target="_blank">http://logs.openstack.org/16/4<wbr>62216/11/check/gate-heat-dsvm-<wbr>functional-convg-mysql-lbaasv2<wbr>-non-apache-ubuntu-xenial/<wbr>e7d9e90/console.html#_2017-05-<wbr>20_07_04_30_718021</a><br>
<br>
<br>
--<br>
Regards,<br>
Rabi Mishra<br>
<br>
<br>
<br></span><span class="gmail-">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>