Bug 859521

Summary:	errors with configure if provider already exists
Product:	[Retired] CloudForms Cloud Engine	Reporter:	Dave Johnson <dajohnso>
Component:	aeolus-configure	Assignee:	John Eckersberg <jeckersb>
Status:	CLOSED ERRATA	QA Contact:	Rehana <aeolus-qa-list>
Severity:	low	Docs Contact:
Priority:	medium
Version:	1.1.0	CC:	dmacpher, jeckersb, lbrindle, morazi, rlandy
Target Milestone:	beta2	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Attempting to add a second provider with the aeolus-configure command would cause an error: "Invalid HTTP Return Code: 400". The aeolus-configure command queried the API when attempting to add a new provider in order to ensure that the provider did not already exist. This required the full provider body, which was no longer returned as a result of other changes to Cloud Engine. This fix adds a 'with_data' parameter so that the providers list action returns the full body for each provider. The check is now successful and running aeolus-configure on the same set of providers a second time runs without errors.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-04 15:20:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dave Johnson 2012-09-21 18:03:00 UTC

Description of problem:

run aeolus-configure -p rhevm or -p mock twice shows a error, it appears that configure no longer handles pre-existing providers... maybe that is okay?  I would expect we could handle it a little cleaner and print a better error message.

err: /Stage[main]/Aeolus::Profiles::Mock/Aeolus::Conductor::Provider[mock]/Web_request[provider-mock]/post: change from  to https://localhost/conductor/providers.xml failed: An exception was raised when invoking web request: Invalid HTTP Return Code: 400,  was expecting one of 200



Version-Release number of selected component (if applicable):
aeolus-configure-2.8.6-1.el6cf.noarch

How reproducible:
100%

Steps to Reproduce:
1.  run aeolus-configure -p with the same provider twice
2.
3.

Comment 2 John Eckersberg 2012-09-21 21:28:42 UTC

https://github.com/aeolusproject/conductor/pull/73
https://github.com/aeolusproject/aeolus-configure/pull/12

Comment 3 John Eckersberg 2012-09-24 14:05:21 UTC

On conductor 1.1 as b801867
On configure 1.1 as a30ff3e

Comment 5 Ronelle Landy 2012-09-25 15:56:28 UTC

Tested rpms:

>> rpm -qa |grep aeolus
aeolus-configure-2.8.7-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
rubygem-aeolus-cli-0.7.2-1.el6cf.noarch
aeolus-conductor-0.13.14-1.el6cf.noarch
aeolus-conductor-daemons-0.13.14-1.el6cf.noarch
aeolus-conductor-doc-0.13.14-1.el6cf.noarch
aeolus-all-0.13.14-1.el6cf.noarch

Running aeolus-configure on the same set of providers a second time runs cleanly ...

[root@qeblade39 ~]# aeolus-configure -p mock,rhevm
Launching aeolus configuration recipe...
notice: /Stage[main]/Aeolus::Deltacloud::Core/Exec[deltacloud-core-startup-wait]/returns: executed successfully
....
notice: /Stage[main]/Aeolus::Profiles::Common/Aeolus::Create_bucket[aeolus]/Exec[create-bucket-aeolus]/returns: executed successfully
notice: Finished catalog run in 38.41 seconds

Checked the mock and rhevm providers on the running Conductor instance. Both providers were still there and I could test their connection.

Comment 7 errata-xmlrpc 2012-12-04 15:20:54 UTC

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