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
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.
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
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)
in build aeolus-conductor-0.13.3-1.el6cf
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
The strict order will never be available in 1.1, you can only find it in upstream for now.
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