Project

General

Profile

Actions
Copy link

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 about 13 years ago. Updated almost 10 years ago.

Status:
Released
Priority:
2
Assignee:
Nicolas CHARLES
Category:
Web - Config management
Target version:
2.4.0~beta5
Pull Request:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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.

Actions
Copy link
 #1

Updated by Jonathan CLARKE almost 13 years ago

  • Target version changed from 2.3.4 to 2.3.7
Actions
Copy link
 #2

Updated by Nicolas PERRON over 12 years ago

  • Target version changed from 2.3.7 to 2.3.8
Actions
Copy link
 #3

Updated by Jonathan CLARKE over 12 years ago

  • Category changed from Techniques to 14
Actions
Copy link
 #4

Updated by Jonathan CLARKE over 12 years ago

  • Target version changed from 2.3.8 to 24
Actions
Copy link
 #5

Updated by François ARMAND over 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 ?

Actions
Copy link
 #6

Updated by Jonathan CLARKE over 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...

Actions
Copy link
 #7

Updated by Jonathan CLARKE over 12 years ago

  • Target version changed from 24 to 18
Actions
Copy link
 #8

Updated by François ARMAND over 12 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.

Actions
Copy link
 #9

Updated by Nicolas CHARLES over 12 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)

Actions
Copy link
 #10

Updated by Jonathan CLARKE over 12 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?

Actions
Copy link
 #11

Updated by Nicolas CHARLES over 12 years ago

Jonathan CLARKE wrote:

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?

I thought about this one, but it's tricky for several reason :
  • 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
Actions
Copy link
 #12

Updated by Jonathan CLARKE over 12 years ago

  • Target version changed from 2.4.0~rc1 to 2.4.0~rc2
Actions
Copy link
 #13

Updated by Nicolas CHARLES over 12 years ago

  • Status changed from Discussion to Pending technical review
  • % Done changed from 0 to 100
Actions
Copy link
 #14

Updated by Nicolas PERRON over 12 years ago

  • Target version changed from 2.4.0~rc2 to 2.4.0~beta5
Actions
Copy link
 #15

Updated by François ARMAND over 12 years ago

The code use return, it is a bad practice.
Moreover, some code is commented, so I will update it.

Actions
Copy link
 #16

Updated by François ARMAND over 12 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).

Actions
Copy link
 #17

Updated by Nicolas CHARLES over 12 years ago

  • Status changed from Pending technical review to Released

This looks valid, thank you Francois

Actions
Copy link
 #18

Updated by Benoît PECCATTE almost 10 years ago

  • Category changed from 14 to Web - Config management
Actions
Copy link

Also available in: Atom PDF