Rudder

Of course, that is not that simple.

We have to take care of system configuration rules, because:

• if we import configuration rules from an other system, we are (pretty surely) going to completely broke Rudder;
• if we don't import system configuration rules, we may broke a working configuration (that need these configuration rules).

Nonetheless, the default case seems to be that we don't want to export/import system configuration rules:

• they are independent from user modification (at least from the configuration rules screen)
• they may be updated by system actions (accepting a new node, adding authorized network, etc) that should not be reverted without leading to non consistent states

So, I propose to have that use case and other related to import/export (PI, groups) only taking into account non system items, and add a "Save/restore configuration" action in administration screen that will take only care of system variables, but perhaps save them elsewhere.

François ARMAND wrote:

We want to be able to import archived CR thanks to a button in administration screen.

Importing CR means (at least):

• read serialized CR (in XML) from /var/rudder/configuration-repository/configuration-rules
  • on any error, abort
  • if no CR are present, what do we do ? Abort ? Or erase all existing CR ?

Good question. In the interest of being able to exactly replicate the state of a Rudder instance, I think we should erase all existing CR. (Imagine you have had a massive security audit, and been asked to start over with your config management. You delete all CR and PI, recreate the PI, and then want to sync them to a different site, but you haven't yet created any CRs because they apply to different groups on that site...).

Ideally, in the long term, we could ask the user to choose. But if we're importing PIs at the same time, which is the desired behaviour, the old CRs probably will be of no use anyway!