Uploaded image for project: 'MidPoint'
  1. MidPoint
  2. MID-6081

Align Configuration Management and Version Control



    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: backlog
    • Component/s: None
    • Labels:
    • Subscription:
      Active subscription


      This is a follow-up to the huge topic that we discussed at TIIME conference.

      • How do we differentiate between configuration and data?
        • Today, there is no absolute way to distinguish.
          Example: Roles -> might be created by midpoint admin, but enriched by user in GUI
      • How do we version control configuration changes made in midpoint itself?
        • Mostly manually. High risk of losing changes / creating a huge mess.
      • How can we export changes made in midpoint and merge them with version control?
        • Automatic exports with ninjas seem impossible or very hard. Just thinking about filenames, metadata, variables and secrets that have been replaced by either maven or midpoint itself.

      Another approach:
      Do we actually care about changes made in midpoint itself?

      All configuration changes should be made by developers and go through QA process. All data changes can stay where they are and no not need to be pulled into VCS.

      At the conference, there was the idea of introducing deltas for object import (initial and post initial)

      Requirements are:

      • Only update / add parts that are specified in the file.
      • Files should still adhere the current “standalone” format and not be some kind of changeset that cannot live without its predecessor.
      • Also, make deletes possible (configuration parts or whole files).

      The initial-objects would benefit from that greatly. When upgrading from 3.9 -> 4.0 we totally forgot about those, found no docu about the need to replace them and were wondering why we got errors. Deltas could have fixed that automatically. The same applies to post-initial-objects that we use for really everything.

      Besides of that, The only helpful mechanism that might need improvement would be the constants handling: (Maybe it is already working like that – just mentioning it for the completeness)

      Today we are replacing passwords in the configuration files (resources, sysconfig, saml policies) by maven or handle the passwords in clearValues or the encrypted ones which is both not very handy.

      Ideally we would specify constants, but when exporting the object or showing it in gui the constant should still be there and not be replaced by the actual (encrypted) value. Actually this behavior might be applied to all usages of any constant.. maybe except for config.xml.





            Unassigned Unassigned
            hoffm_ma Martin Hoffmann
            0 Vote for this issue
            1 Start watching this issue