Bug 806053

Greg, IIRC we discussed this and decided that at least for 1.0, this was a "well don't do that then" situation.  Can you confirm?  If so, let's move this off the 1.0 list.

As a practical example of where this affects things, the present Audrey wordpress examples use GitHub URLs like this:

  https://github.com/aeolusproject/audrey/raw/master/examples/wordpress/wordpress-http.sh

These should be:

  https://raw.github.com/aeolusproject/audrey/master/examples/wordpress/wordpress-http.sh

On the GitHub side, when a request for the first (above) URL comes in, a 302 response is given, with the new (updated) URL to use.

However, Config Server barfs instead of using the information correctly.

The deployment then fails, not being able to retrieve the needed configuration info from the URL.

The evidence of the failure is in /var/log/aeolus-configserver/thin.log on the running Config Server instance:

  warning: peer certificate won't be verified in this SSL session
  ERROR: could not get configuration file contents
  Could not download file https://github.com/aeolusproject/audrey/raw/master/examples/wordpress/wordpress-http.sh.  Http Response code: 302

Compare to a successful download, using a correct URL:

  warning: peer certificate won't be verified in this SSL session

All that's required here, is for Config Server to honour the http 302 status code (a redirect, pointing to a newer URL location), and automatically retry the download, using the new URL location provided.

PM input required.

This comes down to whether QE can get this added to their testing and still make the original 1.1 date.  If they can, then yes, this should be in 1.1.  If not, I'm not willing to slip 1.1 for this.  We can add it to v.next.  I'll confirm with QE and get back to everyone.

Moving it back, this should have already had devel-ack

The implementation change here is to attempt to follow a max of 10 redirects before failing to download a file referenced in a deployable.

https://github.com/aeolusproject/audrey/commit/f620722e5df0c1944f99a25861be682caea0ece1

Configured a redirect in apache and used the following blueprint:

<?xml version="1.0"?>
<deployable version="1.0" name="rhel62_test">
  <description/>
  <assemblies>
    <assembly name="test" hwp="small-x86_64">
      <image id="80f54e44-01b7-11e2-9261-00145e6d1d0c"/>
      <services>
        <service name="http">
          <executable url="https://zhongyong.usersys.redhat.com/redirect_script"/>
          <files>
            <file url="https://zhongyong.usersys.redhat.com/redirect_script"/>
          </files>
          <parameters>
            <parameter name="foo">
                <value>bar</value>
            </parameter>
          </parameters>
        </service>
      </services>
    </assembly>
  </assemblies>
</deployable>




on configserver:


[root@deaddonkey tmp]# tar xvzf ../6903b8a8-026f-11e2-9261-00145e6d1d0c.tgz 
.
http
http/redirect_script
http/start
[root@deaddonkey tmp]# ls
http
[root@deaddonkey tmp]# cd http/
[root@deaddonkey http]# ls
redirect_script  start
[root@deaddonkey http]# cat redirect_script 
#!/bin/bash
touch /etc/cloud-qe.cfg
printenv | grep auto_service_param > /etc/cloud-qe.cfg

exit 0 # Success

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-1516.html