Bug 848671 - Prevent duplication of priority group name and score
Prevent duplication of priority group name and score
Status: CLOSED DEFERRED
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.1.0
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Imre Farkas
Giulio Fidente
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-16 03:48 EDT by Rehana
Modified: 2016-09-20 01:02 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-02 10:32:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rehana 2012-08-16 03:48:20 EDT
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 11:34:39 EDT
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 09:08:57 EDT
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 05:17:52 EDT
in 1.1 branch:
commit 846fbb1ce0ec922288696ef66799e584a36acf47
Author: Imre Farkas <ifarkas@redhat.com>
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 17:58:01 EDT
in build aeolus-conductor-0.13.3-1.el6cf
Comment 6 Rehana 2012-09-26 04:04:08 EDT
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 05:45:07 EDT
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 10:32:11 EDT
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.