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 filePermissions: it loads its data from an external file - let's put the id in the file name partitionSizeMonitoring: move body with a new name in ncf lib, and everything is straightforward Package repository keys (RPM/APT) : it should be ok h1. Hard or long checkGenericFileContent: the code is really long h1. Postponed generic*Definition: current implementation doesn't look compatible with the multiversioned 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 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 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 Package repository keys (RPM/APT) : it reads all keys at first, and we use this info to manage keys. We should have a way to do it once BEFORE execution of the technique 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 downloadFile: it's a monoinstance technique !!