Bug #3039
closed
This is not possible to edit an Services management Directive after a migration from 2.4.0~beta4 to 2 4.0~rc1
Description
- There are several Directives from Services Management
- All of these Directives are at version 1.1 (the last version from 2.4.0~beta4)
- Before to update manually the Techniques from packages of Rudder 2.4.0~beta4 to 2.4.0~rc1, fix the metadata.xml of Enforce A File Content by replacing tag <POLICY> by <TECHNIQUE> (#3027)
- Using Rules with Directives based on Services Management Technique will work
- Trying to edit a Directive based on Services Management Technique will lead to:
- A message in the WebUI "The server cannot be contacted at this time"
- A message in the webapp logs:
"[...] Java.NoSuchElementException: [...] Key not found: 1.2 [...]"
The only way to be able to edit Directives is to remove the version 1.2 from the Techniques:
cd /var/rudder/configuration-repository/techniques/systemSettings/process/servicesManagement git rm -r 1.2/ git commit -m "Remove 'Services Management' v1.2 Technique temporarily"
Updated by François ARMAND almost 12 years ago
- Status changed from New to Discussion
- Assignee set to François ARMAND
Some more information are needed for that:
- the full stack trace that contains "[...] Java.NoSuchElementException: [...] Key not found: 1.2 [...]"
- does trying to CREATE a new Directive for that Technique works ?
- does removing the Technique version 1.2 and then add it again make it works again ?
Updated by François ARMAND almost 12 years ago
- Assignee changed from François ARMAND to Nicolas PERRON
Updated by François ARMAND almost 12 years ago
Information from #3038 seems to show that something went wrong in the registration process of the Technique version, and so adding the version again should also solve the problem.
Updated by François ARMAND almost 12 years ago
So, the bug, or at least something exhibiting the same behaviour, can be manually forged with the following steps:
- choose a Technique with several versions (or create a new version of a Technique on the configuration-repository/techniques directory for that technique, with cp -r TheTechnique/1.0 TheTechniqe/1.99, and then git add TheTechnique/1.99 and git commit and in Rudder, reload Technique Library) ;
- in the LDAP tree, go to the activeTechnique entry for that technique: DN: activeTechniqueId=XXXXXXXXXX,techniqueCategoryId=....,techniqueCategoryId=Active Techniques,ou=Rudder,cn=rudder-configuration
- modify the attribute acceptationTimestamp to remove a "key":"timestamp"
- for exemple, change {"1.0":"20120918133146.958Z","1.1":"20121129150426.437Z"} into {"1.0":"20120918133146.958Z"}
- now, in Rudder Directive screen, select the Technique => error.
So, if it is the same bug, we can conclude three things:
- the workaround in comment 3 should work reliably, as it force Rudder to write back correctly the acceptationTimestamp attribute;
- there is a Scala bug; we should guard again such inconsistent state to report an error and degrade nicely;
- something in the migration process override the acceptationTimestamp attribute.
Regarding that last hypothesis, it could be good to know what is overriding the attribute, and why, because even if it only revealed a bug here, perhaps that migration step is not exactly doing what we thought it was doing.
Updated by François ARMAND almost 12 years ago
- Status changed from Discussion to Pending technical review
- % Done changed from 0 to 100
Applied in changeset 240a1cc4b2971cab7b7deff7689adb62cc412a12.
Updated by Nicolas CHARLES almost 12 years ago
- Status changed from Pending technical review to Discussion
This commit looks valid, thank you for your workaround Francois
Updated by Nicolas PERRON almost 12 years ago
François ARMAND wrote:
So, the bug, or at least something exhibiting the same behaviour, can be manually forged with the following steps:
- choose a Technique with several versions (or create a new version of a Technique on the configuration-repository/techniques directory for that technique, with cp -r TheTechnique/1.0 TheTechniqe/1.99, and then git add TheTechnique/1.99 and git commit and in Rudder, reload Technique Library) ;
- in the LDAP tree, go to the activeTechnique entry for that technique: DN: activeTechniqueId=XXXXXXXXXX,techniqueCategoryId=....,techniqueCategoryId=Active Techniques,ou=Rudder,cn=rudder-configuration
- modify the attribute acceptationTimestamp to remove a "key":"timestamp"
- for exemple, change {"1.0":"20120918133146.958Z","1.1":"20121129150426.437Z"} into {"1.0":"20120918133146.958Z"}
- now, in Rudder Directive screen, select the Technique => error.
So, if it is the same bug, we can conclude three things:
- the workaround in comment 3 should work reliably, as it force Rudder to write back correctly the acceptationTimestamp attribute;
- there is a Scala bug; we should guard again such inconsistent state to report an error and degrade nicely;
- something in the migration process override the acceptationTimestamp attribute.
Regarding that last hypothesis, it could be good to know what is overriding the attribute, and why, because even if it only revealed a bug here, perhaps that migration step is not exactly doing what we thought it was doing.
After analysing the upgrade process, I didn't see anything which could modify the attribute activeTechniqueLibrary, except for the migration from 2.3 to 2.4 because of the renaming of this attribute.
Updated by François ARMAND almost 12 years ago
- Status changed from Discussion to Pending technical review
OK, so I'm going to close that one, as I don't really see how we could go further.
Updated by François ARMAND almost 12 years ago
- Status changed from Pending technical review to Released
Technical review was done by NCH in GitHub.
Updated by Jonathan CLARKE almost 12 years ago
- Status changed from Released to Pending release
Updated by Jonathan CLARKE almost 12 years ago
- Status changed from Pending release to Released