Bug 848671 - Prevent duplication of priority group name and score
Summary: Prevent duplication of priority group name and score
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
Assignee: Imre Farkas
QA Contact: Giulio Fidente
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-16 07:48 UTC by Rehana
Modified: 2016-09-20 05:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-02 14:32:11 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:1516 0 normal SHIPPED_LIVE CloudForms Cloud Engine 1.1 update 2012-12-04 19:51:45 UTC

Description Rehana 2012-08-16 07:48:20 UTC
Description of problem:


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


How reproducible:
100%

Steps to Reproduce:
1.Login to conductor
2.Move to administer -->environments --> provider selection
3.click on "strict" strategy -->configure
  
Actual results:
Allowed to duplicate priority group names and scores

Expected results:
Should not be allowed to duplicate

Additional info:
rpm -qa | grep aeolus
rubygem-aeolus-cli-0.7.0-0.20120815230025gitd64d64f.fc16.noarch
aeolus-conductor-0.13.0-0.20120816030008gite8ea044.fc16.noarch
aeolus-configure-2.8.0-0.20120815230023gitbdcd549.fc16.noarch
aeolus-conductor-daemons-0.13.0-0.20120816030008gite8ea044.fc16.noarch
rubygem-aeolus-image-0.6.0-0.20120815230028git25b7466.fc16.noarch
aeolus-conductor-doc-0.13.0-0.20120816030008gite8ea044.fc16.noarch
aeolus-all-0.13.0-0.20120816030008gite8ea044.fc16.noarch

Comment 1 Jozef Zigmund 2012-08-17 15:34:39 UTC
I'd like to prefer constraining only the names of groups, not the score. I can imagine the use cases when users want to have the same score. Also score is not the only one attribute that saying what provider/provider account will be choosen for deploying. Thus I don't see any reason to ban the same score for priority groups.

If you have some other points that I missed, please feel free to write them up here.

Comment 2 Imre Farkas 2012-08-21 13:08:57 UTC
I discussed this with Angus and agreed on that it makes more sense to apply the unique constraints on both fields. So the posted patch solves the issue:
https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-August/012169.html

Comment 3 Imre Farkas 2012-09-03 09:17:52 UTC
in 1.1 branch:
commit 846fbb1ce0ec922288696ef66799e584a36acf47
Author: Imre Farkas <ifarkas>
Date:   Fri Aug 17 16:17:07 2012 +0200

    BZ848671: Add unique constraints to ProviderPriorityGroup
    
    https://bugzilla.redhat.com/show_bug.cgi?id=848671
    (cherry picked from commit 38176e283cf4c51170e68f4fd39779875d2eef9b)

Comment 4 Steve Linabery 2012-09-07 21:58:01 UTC
in build aeolus-conductor-0.13.3-1.el6cf

Comment 6 Rehana 2012-09-26 08:04:08 UTC
Currently only "Penalty for failure strategy" is displayed

(testing down stream aeolus1.1 repo
repo:http://download.lab.bos.redhat.com/rel-eng/CloudForms/1.1/latest/el6-ce/x86_64/os/
)

Will retest it once "strict order" strategy becomes available for testing 

on 
rpm -qa | grep aeolus 
aeolus-conductor-doc-0.13.14-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-all-0.13.14-1.el6cf.noarch
aeolus-conductor-0.13.14-1.el6cf.noarch
rubygem-aeolus-cli-0.7.2-1.el6cf.noarch
aeolus-configure-2.8.7-1.el6cf.noarch
aeolus-conductor-daemons-0.13.14-1.el6cf.noarch

Comment 7 Imre Farkas 2012-09-26 09:45:07 UTC
The strict order will never be available in 1.1, you can only find it in upstream for now.

Comment 8 Giulio Fidente 2012-10-02 14:32:11 UTC
I think this[1] has removed completely the new/edit actions bound to priority groups, so I'm closing this bug as DEFERRED

[1] commit 4bc6d5630a29f51f0bb0ed2d5fdabb042142523a on 1.1


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