Community
Participate
Working Groups
It is now possible to model things that are mutually exclusive in an install. For historical reasons, the aggregator has no support for this. Everything that is aggregated must be coherent. This is of course a real problem when the aggregation includes several mutually exclusive features. We use the p2 planner to decide exactly what to aggregate. The plan that it comes up with contains the exact set of Installable Units that will be included. The planner can never come up with a plan that contains conflicts. So how can we detect undesirable conflicts while still allowing the ones that were put there for a purpose? Here are four different approaches. My personal favorite is #3. Ideas and suggestions are very welcome: *1. Exclusion list:* Add features that will introduce a conflict to a list. Don't include this list when creating the plan. Instead, resolve each feature on this list separately. Pros: Just as fast as today Cons: The features on the list will not be tested together with everything else *2. Compartments:* Think of a conflict as a switch statement. I.e. switch(feature) { case MySQL: case PostgreSQL: case Oracle: } Each case can contain features that are known to be in conflict with another case. Each case is then planned for separately and together with all features not covered by the switch. We could also test the opposite, i.e. that no case can be planned together with another case without a conflict. That would assert that the conflict itself is expressed correctly. Pros: Everything is verified Cons: Planning might take a long time depending on the number of compartments In order to be perfect, it's likely that we'd need nested compartments The number of compartments can grow exponentially as new conflicts are added *3. Strip conflicting requirements* If all requirements known to cause the conflict are identified, they can be stripped from the IU's during the resolution phase and then reinstated again. Pros: Everything but conflicts is verified. Just as fast as today Cons: The conflicts themselves are not verified by the planner. Identifiying requirements is slightly more complicated
The job of validation is to endure high quality, so I think the aggregator should do as much as possible. Since this may take a long time, an option could relax the checking. Some ideas... If the conlicting group is optional, it should be possible to validate each separately, then it is known that each element in the group works, but if something in the group conflicts with something else, it is a problem for this group- it will at least not prevent install of the rest. This is like #3 I guess, except validating there is no internal conflict, missing things etc. For mandatory conflicting elements, #2 seems best.
I'm contemplating a fourth option which is to not use the planner at all. Instead, we'd use something that is similar but not based on SAT. This would allow us to create "plans" that contains conflicts and we could instead issue warnings or errors for such conflicts depending on how the model is configured. We could also allow for platform independent plans which would lessen the time it takes to create the actual plan significantly. The approach I think would be feasible is to to a transitive query from all roots. Each requirement would be remembered globally and when conflicts occur, they could be dealt with separately. A conflict that would result in multiple versions of the same IU for instance, could be either permitted silently, logged as a warning, or cause a hard failure depending on how things are configured. Negations (requirements that will yield false when certain things are provided), would be collected and then dealt with separately once the resolution is complete. Thoughs?
(In reply to comment #2) > I'm contemplating a fourth option which is to not use the planner at all. > Instead, we'd use something that is similar but not based on SAT. This would > allow us to create "plans" that contains conflicts and we could instead issue > warnings or errors for such conflicts depending on how the model is configured. > We could also allow for platform independent plans which would lessen the time > it takes to create the actual plan significantly. > > The approach I think would be feasible is to to a transitive query from all > roots. Each requirement would be remembered globally and when conflicts occur, > they could be dealt with separately. A conflict that would result in multiple > versions of the same IU for instance, could be either permitted silently, > logged as a warning, or cause a hard failure depending on how things are > configured. > > Negations (requirements that will yield false when certain things are > provided), would be collected and then dealt with separately once the > resolution is complete. > > Thoughs? To help understand this - what would the difference be between the two approaches SAT, Non-SAT given that there are no expected conflicts - this to understand if there is any cost in "validation quality" when there are no conflicts. I am really looking for a way to objectively compare the alternatives in terms of "validation quality". Can you think of a way of measure this? A set of cases that can be validated? Set of cases that goes undetected? Seems like there would be value in writing them down - if only to be able to point people that are bit by corner cases to something that makes them understand what happened...
(In reply to comment #3) > I am really looking for a way to objectively compare the alternatives in terms > of "validation quality". Can you think of a way of measure this? A set of > cases that can be validated? Set of cases that goes undetected? > > Seems like there would be value in writing them down - if only to be able to > point people that are bit by corner cases to something that makes them > understand what happened... Sure, give it a shot and let's see where we end up.
Given the simplicity of the current use cases, I think that doing #1 is likely to be sufficient in the helios time frame since there is only really RAP and the rest of the world. #2 is definitely nicer but requires more management since you have to define your compartments and see where everybody falls. It also is probably more computationally expensive, but the benefit should outweigh the cost. As for a non-SAT based approach, I think this will lead to troubles where aggregator will say everything is fine where the p2 planner will say otherwise. At all cost I would avoid this.
(In reply to comment #5) > Given the simplicity of the current use cases, I think that doing #1 is likely > to be sufficient in the helios time frame since there is only really RAP and > the rest of the world. I agree. That's probably the best short term solution. > As for a non-SAT based approach, I think this will lead to troubles where > aggregator will say everything is fine where the p2 planner will say otherwise. > At all cost I would avoid this. That has been my view too. I really like the SAT approach and I have stubbornly refuted all arguments in favor of bypassing or removing it so far. Ideally I'd like to influence the solver to consider certain conflicts as OK and report them instead of failing. I haven't found a way to do that though. There are some other reasons why I would like to have an alternative to the planner. What if, for instance, I don't really care about the consistency? I just want to mirror a repository and get whatever it contains, just like the p2.mirror app does, but with all the bells and whistles that the b3.aggregator provides. I might want to aggregate in several steps (Helios +0, +1, +2 for instance) and only really validate the last one. Etc. There are plenty of examples where warnings would be better then a failure.
The solution for this was the introduction of ValidationSet's so I'm closing this as a duplicate. *** This bug has been marked as a duplicate of bug 338738 ***
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. Made no changes to assignee's for closed bugs, even though some were old inbox.]
