Bug 732831

Summary:	Drift configuration names could increment to prevent common error creating 2nd drift configuration
Product:	[Other] RHQ Project	Reporter:	Mike Foley <mfoley>
Component:	drift	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	NEW ---	QA Contact:	Mike Foley <mfoley>
Severity:	low	Docs Contact:
Priority:	low
Version:	4.1	CC:	jshaughn
Target Milestone:	---	Keywords:	FutureFeature, Improvement
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---
Bug Depends On:
Bug Blocks:	707225

Description Mike Foley 2011-08-23 19:22:34 UTC

Description of problem:  Drift configuration names could increment to prevent common error creating 2nd drift configuration.  For example, the 1st drift configuration is named "File System".  When you create a 2nd drift configuration, it is named "File System" as well ... and there is an EJB error ... and you have to start all over again.  It would be better if the 2nd drift configuration were named "File System 2" or some other unique name.




Steps to Reproduce:
1.  create 2 file system drift configuration
2.
3.
  
Actual results:
error creating 2nd drift configuration due to the name not being unique

Expected results:
default path thru wizard works every time.

Additional info:

Comment 1 John Sanda 2011-08-25 14:54:17 UTC

I think we may want to change the title of this bug. The problem is that drift configuration names for a resource have to be unique. I do not think we are enforcing that right now. If someone creates two drift configs for the same resource with the same name, bad things could happen particularly on the agent side because the agent already assumes that names are unique. I am upping the severity to high.

Comment 2 Jay Shaughnessy 2011-11-01 20:01:16 UTC

+1 this is working as expected.  Unless there is something we're missing,
please close.

Comment 3 Jay Shaughnessy 2011-11-01 20:03:05 UTC

Whoops, updated wrong BZ, setting back to New...

As an aside, I think the behavior here has been improved already in that
I think you must edit the template name prior to save. Also, template
names have been improved.

Comment 4 John Sanda 2011-11-02 16:00:36 UTC

I had previously set the severity on this to high because I thought that we could wind up with multiple definitions belonging to the same resource and having the same name. That would be bad, but after further testing yesterday, I found that we do in fact prevent multiple definitions with the same name. Given that, I am downgrading the priority and severity to low.