| Summary: | Build should be allowed only for that provider for which deployable is created . | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | Shveta <ssachdev> | ||||||
| Component: | aeolus-conductor | Assignee: | Matt Wagner <matt.wagner> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | wes hayutin <whayutin> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 1.0.0 | CC: | akarol, athomas, deltacloud-maint, ssachdev | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-01-25 14:58:30 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 744194 | ||||||||
| Attachments: |
|
||||||||
Created attachment 549704 [details]
server_error
adding to ce-sprint-next adding to ce-sprint-next adding to ce-sprint removing ce-sprint-next tracker taking off ce-sprint-next.. Jan points out that, since a deployable will be launched on only one provider, if an image is imported, that's the only provider anything else can sensibly be built for. It sounds like the following is in order: 1.) If all images are imported, hide the build/push buttons, as they're inapplicable. Only show the provider in question. 2.) If *some* images are imported: a.) The build_missing method should silently skip over imported images, rather than raising an exception. b.) The build section should only build for the provider of the imported image Scott points out that we may (post-1.0) eventually need to support imported images for multiple provider accounts here. So I think the most-correct thing to do here is to fetch an array of "all" provider accounts supported by all imported images. (In the event that they don't all share one or more provider accounts, an exception should be raised, since you'll never be able to launch the thing successfully.) After an inordinately long time, this is on the list: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/008190.html and children Unfortunately, as Jan points out on list, this is now rendered obsolete by https://bugzilla.redhat.com/show_bug.cgi?id=783133 -- see http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/008243.html Closing as a dupe. *** This bug has been marked as a duplicate of bug 783133 *** |
Created attachment 549703 [details] err Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Environment --> Images --> Import Image 2. Imported an image for ec2 provider. 3. Created a deployable (ec2_deployable) from the imported image named 4. Catalog --> click on ec2 deployable (catalog_entry) and click on build (start) Message displayed : "Failed. Response code = 500. Response message = Internal Server Error. " Actual results: Expected results: Additional info: rpm -qa|grep aeolus aeolus-conductor-0.8.0-0.20111222233342gitd98cb57.el6.noarch aeolus-all-0.8.0-0.20111222233342gitd98cb57.el6.noarch aeolus-conductor-daemons-0.8.0-0.20111222233342gitd98cb57.el6.noarch rubygem-aeolus-image-0.3.0-0.20111222173411gitc13b654.el6.noarch rubygem-aeolus-cli-0.3.0-0.20111222173356git3cd6277.el6.noarch aeolus-configure-2.5.0-0.20111222173430git17b704a.el6.noarch aeolus-conductor-doc-0.8.0-0.20111222233342gitd98cb57.el6.noarch