Bug 808022 - The message "That name is already in use" should be scoped only with in cloud resource zone
The message "That name is already in use" should be scoped only with in cloud...
Status: CLOSED WONTFIX
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Scott Seago
wes hayutin
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-29 07:18 EDT by Rehana
Modified: 2013-09-17 14:23 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-17 14:23:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Rehana 2012-03-29 07:18:19 EDT
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 08:32:58 EDT
I have a feeling that is the current design, maybe it will change.. 
Asking Scott
Comment 2 Scott Seago 2012-03-30 10:11:05 EDT
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 13:04:27 EDT
We need to establish whether the concern that Scott raises in Comment 2 actually applies.
Comment 5 Scott Seago 2013-09-17 14:23:53 EDT
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.