Bug 808022 - The message "That name is already in use" should be scoped only with in cloud resource zone
Summary: The message "That name is already in use" should be scoped only with in cloud...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
Assignee: Scott Seago
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-29 11:18 UTC by Rehana
Modified: 2013-09-17 18:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-17 18:23:53 UTC


Attachments (Terms of Use)
text (210.27 KB, image/png)
2012-03-29 11:18 UTC, Rehana
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.