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

Easy¶

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

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

Hard or long¶

checkGenericFileContent: the code is really long

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

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 !!