User story #11851
Updated by Nicolas CHARLES over 6 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