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
Added by Nicolas PERRON almost 12 years ago.
Updated about 11 years ago.
Category:
Web - Config management
Description
As
#3038, the upgrade of Rudder on a SLES 11 SP1 from
2.4.0~beta4 to
2.4.0~rc1 lead to an error when trying to edit a Directive based on Services Management Technique with these conditions:
- 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)
After a complete upgrade of Rudder and Techniques (commit new Techniques and restart Rudder or reload techniques on the WebUI):
- Using Rules with Directives based on Services Management Technique will work
- Trying to edit a Directive based on Services Management Technique will lead to:
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"
- 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 ?
- Assignee changed from François ARMAND to Nicolas PERRON
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.
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.
- Status changed from Discussion to Pending technical review
- % Done changed from 0 to 100
- Status changed from Pending technical review to Discussion
This commit looks valid, thank you for your workaround Francois
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.
- 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.
- Status changed from Pending technical review to Released
Technical review was done by NCH in GitHub.
- Status changed from Released to Pending release
- Status changed from Pending release to Released
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Nicolas PERRON 
Updated by Jonathan CLARKE