Bug #2041
closed
When applying a Technique in version 2.0 when a version 1.0 is already applied by an other rule on the same node, a bundle name collision occurs
Added by Matthieu CERDA over 12 years ago. Updated about 9 years ago.
Description
When applying a PT in version 2.0 when a version 1.0 is already applied elsewhere, a bundle name collision occurs
I suggest as a workaround that we use a stringtemplate variable containing the version number to discriminate the bundles and bodies.
Updated by Jonathan CLARKE about 12 years ago
- Target version changed from 2.3.4 to 2.3.7
Updated by Nicolas PERRON about 12 years ago
- Target version changed from 2.3.7 to 2.3.8
Updated by Jonathan CLARKE almost 12 years ago
- Category changed from Techniques to 14
Updated by Jonathan CLARKE almost 12 years ago
- Target version changed from 2.3.8 to 24
Updated by François ARMAND almost 12 years ago
- Status changed from New to Discussion
- Assignee set to Nicolas CHARLES
What to do with that, knowing that:
- it's rather a deep problem, and so quite involved given 2.5 timeline;
- we are on the way to change how versions are handle;
- CFEngine 3.4 adds namespaces for that very case.
Comments ?
Updated by Jonathan CLARKE almost 12 years ago
François ARMAND wrote:
What to do with that, knowing that:
- it's rather a deep problem, and so quite involved given 2.5 timeline;
- we are on the way to change how versions are handle;
- CFEngine 3.4 adds namespaces for that very case.
Comments ?
It doesn't seem to me to be very easy to fix this on the CFEngine level - it would involve changing all our Techniques, and of course requiring users who have built their own to do the same.
However, could we not implement in the WebUI a check to detect this situation, and only allow to enable one version at a time? Or something similar...
Updated by Jonathan CLARKE almost 12 years ago
- Target version changed from 24 to 18
Updated by François ARMAND over 11 years ago
- Subject changed from When applying a PT in version 2.0 when a version 1.0 is already applied elsewhere, a bundle name collision occurs to When applying a Technique in version 2.0 when a version 1.0 is already applied by an other rule on the same node, a bundle name collision occurs
- Target version changed from 18 to 2.4.0~rc1
The bug seems important (user will be eaten by that, and the error reporting in the deployment status box won't help them much - that should be an other bug), so we should see if it is possible to check that in Rudder before 2.4.0 final.
Status change to discuss it in the next release point.
Updated by Nicolas CHARLES over 11 years ago
Maybe we could implement a test at deployment time that would check that there are no two different version of the same technique applied on node, and if so, interrupt the deployment and complain (and explain)
Updated by Jonathan CLARKE over 11 years ago
Nicolas CHARLES wrote:
Maybe we could implement a test at deployment time that would check that there are no two different version of the same technique applied on node, and if so, interrupt the deployment and complain (and explain)
That sounds quite good. How about a test at the time we actually create the directive, that provides a warning, too?
Updated by Nicolas CHARLES over 11 years ago
Jonathan CLARKE wrote:
I thought about this one, but it's tricky for several reason :Nicolas CHARLES wrote:
Maybe we could implement a test at deployment time that would check that there are no two different version of the same technique applied on node, and if so, interrupt the deployment and complain (and explain)
That sounds quite good. How about a test at the time we actually create the directive, that provides a warning, too?
- It's okay to have directives based on several version of techniques, as long as they are not applied to the same node (ex on a group for production, and a group for preproduction)
- if we are migrating directives from on version to another, user will get constant warning
- with the cross-validation of deployment, there can be a lot of modifications before them being applied, and it can bug a lot the user
Updated by Jonathan CLARKE over 11 years ago
- Target version changed from 2.4.0~rc1 to 2.4.0~rc2
Updated by Nicolas CHARLES over 11 years ago
- Status changed from Discussion to Pending technical review
- % Done changed from 0 to 100
Applied in changeset a595a6d9876fbb1e59c55769aaffe71b26ddb6d1.
Updated by Nicolas PERRON over 11 years ago
- Target version changed from 2.4.0~rc2 to 2.4.0~beta5
Updated by François ARMAND over 11 years ago
The code use return, it is a bad practice.
Moreover, some code is commented, so I will update it.
Updated by François ARMAND over 11 years ago
Logic of the code was OK, I just made some code style arrangement.
Nicolas, could you review my modification to check that I didn't broke anything (I don't thing so, but perhaps I missed a usecase).
Updated by Nicolas CHARLES over 11 years ago
- Status changed from Pending technical review to Released
This looks valid, thank you Francois
Updated by Benoît PECCATTE about 9 years ago
- Category changed from 14 to Web - Config management