Bug 1040225

Summary:	If a version does not exist, creating a hw spec+cert entry will report failure but actually half succeed
Product:	[Retired] Red Hat Hardware Certification Program	Reporter:	Damian Jansen <djansen>
Component:	Hardware Catalog	Assignee:	hwcert-catalog
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	5.2	CC:	hwcert-catalog, pmao, tfu
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-01 09:07:22 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:
Bug Depends On:
Bug Blocks:	1032329

Description Damian Jansen 2013-12-11 01:17:48 UTC

Description of problem:
In testing, an issue was found where if a version was not yet set in the database but the hw spec + cert entry for that version was created, an error is reported, i.e.:
---
Bugzilla XMLRPC Service is not available at the moment.

bz xmlrpc Bug.create failed: There is no version named 'RHELOSP 4.0' in the 'Red Hat Hardware Certification' product. at Hwcert.pm line 248.
Please try later.
---

Despite this cert create error, the hw spec is actually created, so navigating back and trying again reports the standard "Vendor, Make, and Model combination already exists" error.
Though an odd situation to be in, it seems wrong that half the request was created.

Version-Release number of selected component (if applicable):
dev

How reproducible:
Moderate ~ difficult

Steps to Reproduce:
Precondition: version RHELOSP 4.0 does not exist
1. Log in, click create
2. Select Create Both, fill in the details for a new hw make and model
3. Click Continue, and Commit

Actual results:
Error

Expected results:
This appears to be a disconnect between what is in the database and what hwcert submits. The code should not expect something is in the database, but read from it instead.

Additional info:

Comment 1 Tony Fu 2013-12-13 02:46:50 UTC

Thanks for reporting this issue.  Unfortunately, there is no easy solution to fix this issue, since the process involves two separate bz actions and we can not make them as an atomic action.

Because this issue was not introduced by 5.3 code, I just move out this one to later release.