This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 805001 - Deployment is created even if match is not found
Deployment is created even if match is not found
Status: CLOSED CURRENTRELEASE
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Jan Provaznik
wes hayutin
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-20 08:19 EDT by Jan Provaznik
Modified: 2012-12-13 14:48 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-13 14:48:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Auto-select Realm (75.10 KB, image/png)
2012-09-20 14:33 EDT, Ronelle Landy
no flags Details
Launch with specifed realm selected (114.29 KB, image/png)
2012-09-20 14:35 EDT, Ronelle Landy
no flags Details

  None (edit)
Description Jan Provaznik 2012-03-20 08:19:49 EDT
Steps to Reproduce:
1. prepare a deployment launch (go to "/deployments/launch_time_params" but don't press "launch" button yet)
2. in another tab make some change which causes that deployment's instances won't be launchable on any provider account (for example make a provider unavailable, remove account from pool family, delete realm mapping or hwp...)
3. finish deployment launch from first step -> deployment is created, but all instances have state set to "new" (or "create_failed" depending if https://bugzilla.redhat.com/show_bug.cgi?id=796528 is applied)


Deployment should not be created if a match is not found, a user should stay on "/deployments/launch_time_params" (and an error message should be displayed).
Comment 1 Jan Provaznik 2012-08-21 04:26:06 EDT
This BZ was fixed meantime, switching to QA for checking.
Comment 2 Ronelle Landy 2012-09-20 14:33:12 EDT
Testing the following rpms:

>> rpm -qa |grep aeolus
aeolus-configure-2.8.6-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
rubygem-aeolus-cli-0.7.1-1.el6cf.noarch
aeolus-conductor-0.13.8-1.el6cf.noarch
aeolus-conductor-daemons-0.13.8-1.el6cf.noarch
aeolus-conductor-doc-0.13.8-1.el6cf.noarch
aeolus-all-0.13.8-1.el6cf.noarch

It's a mixed result ...

If I follow the reproduction steps above ... prepare the deployment lauch, on a second tab open to conductor, I remove the realm mapping, and then click the 'Launch' button (with , the Realm assigned to 'Auto-select'), the instance launches successfully and goes to a 'New' state. (see attached screenshot Auto-selectLaunch.png)

If I follow the same set of steps but, instead if using 'Auto-select' for the realm, I select *any* realm listed in the Realm drop down, I get an error when clicking the 'Launch' button and conductor stays on the launch_time_params page. (see attached screenshot SpecifiedRealmLaunch.png)
Comment 3 Ronelle Landy 2012-09-20 14:33:58 EDT
Created attachment 615043 [details]
Auto-select Realm
Comment 4 Ronelle Landy 2012-09-20 14:35:03 EDT
Created attachment 615044 [details]
Launch with specifed realm selected
Comment 5 Jan Provaznik 2012-09-20 14:51:48 EDT
Behavior in both cases is correct - remove realm mapping was one of examples how to achieve "match not found error". When using "auto-select" realm mapping is not applied.

In second case - if none of listed realms works it probably means that after removing the realm mapping there is not suitable provider account for which some realm mapping exists and where all deployment's images are pushed to.
Comment 6 Ronelle Landy 2012-09-20 15:03:27 EDT
So considering the explanation in Comment 5 above (thanks for that answer, Jan Provaznik), I'm marking this BZ as 'verified' for the case in which the Realm mapping is considered, conductor throws the 'Match not found' error and does not launch the instance.

Note You need to log in before you can comment on or make changes to this bug.