Bug 741947

making sure all the bugs are at the right version for future queries

adding to ce-sprint-next

adding to ce-sprint-next

adding to ce-sprint

removing ce-sprint-next tracker

We presently support all EC2 regions except for sa-east-1 (São Paulo, Brazil). That is waiting on Image Factory support.

It should be possible for users to add support for additional regions through the UI, in any event, so at this point all we're doing is saving them the step of manually adding regions.


Support for automatically configuring the newer regions was added to aeolus-configure a bit ago:

commit 219f0238e0ff4a3ee8013365e57fce20029cd8f6
Author: Matt Wagner <matt.wagner>
Date:   Thu Nov 10 10:47:49 2011 -0500

    Adds ec2-us-west-2 (Oregon) region to EC2 setup

and

commit 219a7efa9c05a7a974158ffde121bce0df6f5fe1
Author: Matt Wagner <matt.wagner>
Date:   Thu Nov 3 12:53:48 2011 -0400

    Add all EC2 regions in ec2.pp profile
    
    Implements https://www.aeolusproject.org/redmine/issues/2766

need to add sa-east-1 as of 1/15/12

I think this is actually a bit of a can of worms.  I did a little poking into this and some thinking on it today, including reaching out to the deltacloud guys (will have more detail tomorrow).  There are 3 major levels of problem here, which I will attempt to descibe after listing the major blocker for _today_:

* The currently available release of deltacloud (0.4.1-8) does not include this region, so even if configure were to set it up in conductor, it could not be used yet.  This will (at some time, I dont know when) be obviated by a new release of deltacloud, which dynamically lists the regions that exist.  The potential problem with this is it is the regions _available for a given ec2 account_, rather than 'these are all the regions that exist' regardless of user.  Not sure how much chance there is of different users getting different lists back, but this has potential for more bugs, imo.

Now, for the layers of problem, and what I thought we might do to fix them:

1. As stated in the ticket, it would be nice if the user could have configure add all regions that exist for ec2.  The problem currently is whatever release we have of configure has a high probability of being behind what ec2 is offering (as new regions seem to be springing up more frequently of late).  This made me think we should pull the list dynamically from deltacloud (see point 2).  However, I have to question whether configure is even really the right place to be doing this.  It seems to me that the user/admin who is adding ec2 'providers' woudl either use the (not-yet-built) aeolus cli component for a batch of providers, or simply add what they want via the conductor web UI.  This, in turn could potentially pull the region list from deltacloud (which leads to another issue in point 2).  So the net of this is I think some thought should be given to if this is truly the right place for this functionality at all, and perhaps the best short-term solution is to not have this even be something configure does, and later implement it via the conductor api/cli

2. In order for configure (or conductor) to be able to retrieve a dynamic list of regions for ec2, deltacloud needs to actually provide such a dynamic list, which the current release does not.  What it does, is specify a list in /usr/share/deltacloud-core/config/drivers/ec2.yaml.  This list contains 5 entries, of which sa-east-1 is not one.  I spoke with marios from deltacloud today about getting that dynamic list, and he had what seemed initially to be good news - they have added dynamic region list support.  Then the bad news came - because of the ec2 api, the call requires provider _account_ credentials to get the list _for that user_.  This means we woudl have to have the user account first, but the way conductor is set up, you add the provider, and then attach an account to _that_, so we have a bit of a chicken and egg problem.  Perhaps the solution could be to allow the user to pass in account credentials to configure (or preferably cli/ui), but I am not sure this is ideal, or would work across other providers.  It just seems backwards to me.

3. If we solve 1&2 satisfactorily, there is still the issue of the static list of jeos images that image factory maintains, which is another place that necessitates a new release every time ec2 adds a region (and I suppose potentially other provider types, not sure which offhand though).  This is solvable as well, and can perhaps piggyback on whatever the ultimate solution is for 1&2, calling either ec2 directly, or using deltacloud to get a list of regions as needed.  Factory could then ask for a list of jeos images in a given region by asking for public images uploaded by the jeos user (I would hope they have an ec2 user dedicated to this task, but am not sure).  Since the account information is not needed until build time, that is the point when factory would be able to verify existence of a jeos for a given region and either commence with the in-cloud build, or return an error showing 'region not currently available for building images via this tool'.


The net of all this is that there are layers of issue to be resolved here, and I think the first step is/should be to just not have configure even provide the ability to add ec2 providers, it just doesnt make much sense to me.

Patch sent to list:

commit 4848404bc0ef9399a0d8c46b2e2c2603f37c9a69
Author: Jason Guiditta <jguiditt>
Date:   Wed Jan 18 16:43:37 2012 -0500

    BZ # 741947. RFE: add support for all ec2 regions
    
    https://bugzilla.redhat.com/show_bug.cgi?id=741947
    
    This adds support for automatically configuring sa-east-1 region
    via aeolus-configure.  We have agreed to freeze the list here,
    any additional regions can easily be added by user via the
    conductor UI for the time being, with future intent to move this
    to the cli tooling and provide a dynamic list of regions through
    conductor api via deltacloud.

Pushed to candyland

1348210 in aeolus-configure-2.5.0-7.el6

all supported versions in.. anything else is custom added by user..

thanks jayg


[root@qeblade32 yum.repos.d]# rpm -qa | grep aeolus
aeolus-conductor-daemons-0.8.0-25.el6.noarch
aeolus-conductor-doc-0.8.0-25.el6.noarch
aeolus-configure-2.5.0-12.el6.noarch
rubygem-aeolus-image-0.3.0-7.el6.noarch
aeolus-conductor-0.8.0-25.el6.noarch
rubygem-aeolus-cli-0.3.0-8.el6.noarch
aeolus-all-0.8.0-25.el6.noarch

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-0583.html