On Tue, May 23, 2017 at 11:57 PM, Zane Bitter <[email protected]> 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(<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]. >> > > 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- >> 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 >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
