Bug 688857 - [RFE] wallaby features dependency and priority
Summary: [RFE] wallaby features dependency and priority
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: wallaby
Version: Development
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: 2.0
: ---
Assignee: Will Benton
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-18 09:26 UTC by Lubos Trilety
Modified: 2011-03-23 11:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-22 20:44:35 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Lubos Trilety 2011-03-18 09:26:52 UTC
Description of problem:
It will be better if dependency and include explicitly set the priority between features. Now (if no options is set, like -i) the first feature, which was provisioned on a node, has the bigger priority and its parameter values are used, this could be confusing.

e.g.
Feature 'Master' has
ALLOW_ADMINISTRATOR : $(ALLOW_ADMINISTRATOR)
'HACentralManager' which is indirectly dependant on 'Master' has
ALLOW_ADMINISTRATOR : $(ALLOW_ADMINISTRATOR), $(COLLECTOR_HOST)

Now if the 'Master' is provisioned first and then 'HACentralManager' the value of parameter ALLOW_ADMINISTRATOR will be: $(ALLOW_ADMINISTRATOR)
More logical will be the value set in HACentralManager: $(ALLOW_ADMINISTRATOR), $(COLLECTOR_HOST)

Even for include it could happen that first will be provisioned the included feature and after some time the feature which includes the first one.


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

Comment 2 Will Benton 2011-03-22 20:44:35 UTC
This is the intended behavior, at least with regard to dependencies.  The idea is that features can contain "holes" that get filled in appropriately given their context.

Say feature F is installed on group G.  F depends on F', and foo.redhat.com is a member of explicit groups G', G, and G'', from lowest to highest priority.

In this case the F' dependency can be satisfied on a given node in several places:  in the group that installs F (G), in a group of lower priority (G'), in a group of higher priority (G''), in the default group, or in the identity group for F.  By a priori forcing dependencies to be satisfied in a particular order, we would lose this flexibility.

Note that inclusions, as opposed to dependencies, are ordered and thus have explicit priority:  applying a feature repeatedly applies its included features to an empty configuration, in inverse priority order, followed by the parameters set immediately in the top-level feature.  (This is recursive, so as to account for transitive inclusion.)  As an example, if F0 includes F1 and F2, its configuration will consist of:

  1.  the parameter-value mappings set immediately in F0 applied on top of
  2.  the configuration of F2 applied on top of
  3.  the configuration of F1

Where "the configuration of X" is defined recursively as its immediately-set parameter-value mappings applied atop the configurations of its included features.


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