Description

OnSphere is a composition of multiple modules, a module being an autonomous software entity responsible for handling a specific task (Here, autonomous is used to describe the module’s capacity to run on its own. It does not mean it will be able to properly perform its task on its own though. e.g., the Alarms module creates alarms, it can run on its own but without any other module asking it to create Alarms from specific triggers, it won’t do much).

Modules each have their own configuration. To ease handling of said configurations, OnSphere has a special core-module : the Configuration Dispatcher (osp-configuration-dispatcher). It is responsible for:

  • making all configurations available as a whole

  • detecting changes

  • validating said changes and

  • restarting modules targeted by those changes providing them with newly updated configuration

To manage the configuration, the osp-configuration-dispatcher uses Git which allows users to benefit from all the strength it has to offer (among others, lightweight, easy to learn, well documented, widely used, robust).

You will find below a list of advantages (and how they can ease your life as an integrator) brought by the use of Git in combination with having a text based configuration (if you are not familiar with Git we strongly suggest you follow a Git tutorial to be able to fully benefit from its capacities).

Local copy

Git works with local copies of a same “repository” (here, directory containing the configuration files) which allows you to :

  • Have multiple copies of the configuration in multiple places (ensuring yet another layer of redundancy in case of accident)

  • Work from multiple places, at the same time, on the same configuration (you no longer need to go to the place the system is running and wait for your colleague to finish working on it)

  • Work offline (you can now work on your configuration whenever you want, from anywhere and simply deploy it once you are done and have access to the system)

Text based configuration

Allows you to :

  • Edit the configuration with any text editor (no new tools to install, you can keep the habits you already have)

  • Script the configuration generation/edition (avoid manually doing repetitive tasks)

  • Easily/quickly observe changes (there are tools available which allow you to spot any differences between two files, or two versions of a same file, letting you choose which version you want to use)

Git log

Allows you to know :

  • What: has been changed

  • When: it has been changed

  • Why: it has been changed

  • By whom: it has been changed

Git diff

Allows you to :

  • Choose among the multitude of tools available, including tools with a GUI (Graphical User Interface)

  • Quickly spot what changed (no more endless search of what was changed between current and last configuration (or between any two configuration version at any time), git diff highlights only what has been changed)

git difftool --tool=[meld] --dir-diff[commit-to-diff-against]

Git branch

Allows you to :

  • Have branches for specific use case (you have a specific bit of a configuration which represents a common use case, create a branch with it so that you can quickly and easily deploy it)

  • Have branches for specific “version” of a project (production, quality, testing, …)

Git tags

Allow you to :

  • Quickly identify a specific version of a configuration (you no longer need to remember the date a configuration implemented a specific bit, you can simply tag it with an appropriate name)

Git-bisect

Allows you to :

  • Automate configuration debugging (Sometime you have hundreds of configuration files and need to find the last one which “worked”. With git-bisect you can create a script checking “if it works”, and let git-bisect tell you the last configuration file which matches.)