|Summary:||Drift configuration names could increment to prevent common error creating 2nd drift configuration|
|Product:||[Other] RHQ Project||Reporter:||Mike Foley <mfoley>|
|Status:||NEW ---||QA Contact:||Mike Foley <mfoley>|
|Target Milestone:||---||Keywords:||FutureFeature, Improvement|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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.