Project

General

Profile

User story #11851

Updated by Nicolas CHARLES almost 7 years ago

We need to port a maximum of techniques in the multi-versionned technique format 

 Some are more easy to port than others, and here I'll list the assessed level of complexity 

 h1. Easy 

 set_vars: it uses only ncf, so it's direct 


 h1. Ok 

 ManageFileAndFolder, FileAlterationMonitoring: we need to change the kept_if_else to rudder_common_classes, and it will be straitfoward 
 groupManagement, services_management: seem quite easy 


 h1. Hard or long 

 filePermissions: it loads its data from an external file - let's put the id in complexity of changing that seems quite high 
 jobScheduling: the file name code is really complex, it looks simple to port to multi-versionned, but the risk seems quite high 
 partitionSizeMonitoring: partitionSizeMoniroting: a body to move body with a new name in ncf lib, and everything is straightforward 

 h1. Hard or long 


 checkGenericFileContent: 
 conConfiguration: we need to restart only once cron at the code is really long end of changes 


 h1. Postponed Unknwown 

 generic*Definition: current implementation doesn't look compatible with the multiversioned multiversionned format (variable erasure), as we can't make sure the order will be common between multi-versionned and agregated one 
  -> need to have a proper migration script for these one, to migrate all techniques at once, so it will be done in 4.4 erasure) 
 variable_from_json, userManagement: we need to evaluate in details how to do it 


 cronConfiguration: we need to restart only once cron at the end of changes 
 We cannot simply do the service_restart for each version, as it would be done only once (service_restart call command_execution, so only the first will be done). 

 The actual solution would be to have a service where the technique will register itself and it would execute at the end the execution, along with reporting infos 


 packageSource, sshKeyDistribution: we need to evaluate reevaluate how we implement the purge of repos or keys 
  -> we need to have "mono-instance" value, for a given user. The solution is not straightforward (ideas: late evaluation, purge before editing but risk of loosing data, transaction, augeas, etc) 

 sudoers : need a monovalued code, as the one above, but it is kind easier 


 h1. Won't do 

 jobScheduling: the code is really complex - it won't be ported to new system 


 
 fstabConfiguration: there are a lot of classes defined in namespace, the actual code is not working as expected, so it will requiere a complete rewrite 




 we need to evaluate more 







Back