Bug 808022

Summary: The message "That name is already in use" should be scoped only with in cloud resource zone
Product: [Retired] CloudForms Cloud Engine Reporter: Rehana <redakkan>
Component: aeolus-conductorAssignee: Scott Seago <sseago>
Status: CLOSED WONTFIX QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, athomas, cpelland, deltacloud-maint, hbrock, morazi, ssachdev
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-17 18:23:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
text none

Description Rehana 2012-03-29 11:18:19 UTC
Created attachment 573634 [details]
text

Description of problem:


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


How reproducible:


Steps to Reproduce:
1.Login to conductor
2.create a new zone (say 'test')
3.create a new application in "default" zone with the name "Application1"
4.Create a new application in "test" zone with the same name "Application1"
  
Actual results:
Observed that user is able to create application with the same name BUT a message "That name is already in use" was getting displayed next to the "Application name" text field(PFA: text.png)

Expected results:

This message "That name is already in use" should be displayed only if the name duplication is happening with in the zone


Additional info:

rpm -qa | grep aeolus
aeolus-conductor-0.8.3-1.el6.noarch
aeolus-conductor-daemons-0.8.3-1.el6.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-configure-2.5.2-1.el6.noarch
aeolus-all-0.8.3-1.el6.noarch
rubygem-aeolus-cli-0.3.1-1.el6.noarch
aeolus-conductor-doc-0.8.3-1.el6.noarch

Comment 1 wes hayutin 2012-03-30 12:32:58 UTC
I have a feeling that is the current design, maybe it will change.. 
Asking Scott

Comment 2 Scott Seago 2012-03-30 14:11:05 UTC
From the look of it, we're only restricting uniqueness on the back end within one zone:

  validates_uniqueness_of :name, :scope => :pool_id

It looks like it's only the javascript validation that's failing -- but the server-side validation on submit is using the model validation properly.

So this is a bug, but it's a UI annoyance rather than the incorrect validation rules being applied.

There may be a related issue here -- if you have two applications with the same name, in different zones, and they're scheduled with the same provider, will we have name uniqueness problems on the provider-side?

Comment 3 Angus Thomas 2012-06-21 17:04:27 UTC
We need to establish whether the concern that Scott raises in Comment 2 actually applies.

Comment 5 Scott Seago 2013-09-17 18:23:53 UTC
Cloud Engine/conductor 2.0 is not currently planned; this code is no longer maintained.