Step 4: Changing the configuration

You need to make changes in the configuration, for example, add a server, redistribute roles, or change their parameters. It would seem that it’s easier to put a new configuration file on all servers and restart the system. Then ServerShell will do everything as it did at the boot step (step 3). You could even choose not to restart, counting on ServerShell to keep track of file system changes on a regular basis. However, there are three significant drawbacks to this approach:

That is why there is an API for working with configuration files. This API is not a domain level API, it is a system level API, so only administrators of the master domain can use it.

The solution to this case study is a set of roles jointly responsible for configuration: MIC (Master Infrastructure Configurator) and IC (Site Infrastructure Configurator).

First, similar to step 1, the configuration file uploaded by the administrator gets through WS to MIC. There it is saved and awaits further administrator activity. The administrator verifies that the uploaded file is correct, validation is performed by the same MIC role. Then, if successful, the administrator applies the file with an API request /api/admin/v1/cfg/apply. The MIC initiates the complex process of synchronizing the file configuration file on all sites, servers, and _The process reaches every working role so that they have the opportunity to apply the new settings in a hot way. This process reaches every running role so that it can apply the new settings in a hot way.

Configuration application is a tree branching process.

Each of the nodes of the considered process of configuration synchronization sends a command to all its subscribers, and itself accordingly subscribes to the parent node. Thus, the responsibility of the child node is to detect the parent node by means of the configuration and perform the subscription (see figure).

MIC and IC roles like the others, which means their basic behavior is subordinate to their local ServerShell and BasedRole. And the target functionality keeps them at the top of the hierarchy of the configuration management process. (see pic above). There are two points of view on the connection of configuration services, two levels of connection: From the point of view of the process of subscription and configuration update the main MIC, and further MIC → IC → ServerShell → BasedRole, and from the point of view of system startup the main MIC → IC → ServerShell → BasedRole, and from the point of view of system startup the main MIC → IC → ServerShell → BasedRole ServerShell, and then ServerShell → BasedRole → Role, including MIC and IC. It is non-trivial to adequately draw a flat compact diagram reflecting both views simultaneously, but it is more than realistic to abstractly represent this model:

ServerShell starts BasedRole, BasedRole starts MIC among other roles, it starts working and provides configuration management functionality. Similarly IC on its server. If suddenly the configuration changes, MIC notifies all available ICs, IC notifies all available ServerShells on the site (including its own), ServerShell manages working nodes and notifies BasedRole (including on the MIC node). The MIC role can then change its location and behavior. As long as the IC is not running as a role, all ServerShells make unsuccessful attempts to connect to it based on the current configuration. These attempts are asynchronous and do not interfere with the intended process of starting working nodes and the roles in them.

Another chart..

MIC – special role, it must be present on exactly one site. The site that hosts the MIC is called the master-site. And on the other hand, if a site is a master site, it must have MIC. Other sites are called working sites. That said, if a site (whether working or master) has all the composition of the required roles, then it is called a communication site. Thus a communication site is a sign of a product site’s full functionality. Any working site must be a communication site_.

The diagram shows the hierarchy of subscription to configuration changes using the example of a binary branching tree (two sites, two servers, two roles each):

In the bottom layer of the diagram components are BasedRole, but we remember that they in turn control working nodes with functional roles. Thus, one of the BasedRole shown in the diagram controls the startup of a node with the MIC role, and two more control the startup of nodes with IC roles. You should think carefully about this model before moving on.