Concerns
In ADCM, some of the user notifications are implemented in the form of concerns. Such concern notifications occur, for example, in cases of incorrect configuration, when mandatory parameter fields are not filled in configurations of services, components, or other objects. Another example where ADCM creates a concern is when, after modifying the configuration of an object, the user forgets to apply it to the cluster hosts and continues to work with the outdated configuration.
The causes for concerns, as well as their types and properties, are described in detail below.
Types of concerns
ADCM has three types of concerns:
-
Flag
-
Lock
-
Issue
Concerns of all types are displayed in the UI.
Concerns can be either blocking or non-blocking. If a concern is blocking, any actions and updates are unavailable for the associated ADCM object. In the UI, blocking concerns are marked in red, while non-blocking concerns are marked in yellow.
Let’s consider each type separately.
Flag
Flag is a non-blocking concern that indicates a mismatch between the configuration of the object in the ADCM database and its actual configuration on the host. Typically, the appearance of a flag indicates outdated configuration on the hosts after changing object parameters in ADCM without subsequent application. To resolve such a problem, it is necessary to apply changes on the cluster hosts by performing the corresponding actions.
|
IMPORTANT
Flag concern functionality is available only when it is supported by the product in use.
|
The cause of a flag concern is displayed in the UI as the message <Concern owner> has an outdated configuration.
The purpose of flag concerns is to exclude interaction with objects whose configuration is outdated on the hosts and to provide the flexibility to set the order of actions for interconnected services. For example, changing the configuration of an already installed service may require its restart. In this case, ADCM creates a flag concern, reminding the user of the need for a restart.
Lock
Lock is a blocking concern that occurs each time an action is started on an object. At this point, UI and API elements related to the object become inaccessible.
The cause of a lock concern is displayed in the UI as the message Object was locked by running job <job>.
The purpose of lock concerns is to prevent simultaneous execution of multiple actions by the user.
Issue
Issue is a blocking concern that can be caused by several reasons:
-
The object has unfilled or invalid fields in its configuration. This cause is displayed in the UI as the message <Concern owner> has an issue with its config.
-
The object contains a service with mandatory import. This cause is displayed in the UI as the message <Concern owner> has an issue with required import.
-
A required service needs to be installed for the cluster to work. This cause is displayed in the UI as the message <Concern owner> has an issue with required service.
-
The object contains a service that requires another service to be installed for it to work. This cause is displayed in the UI as the message <Concern owner> has an issue with requirement. Need to be installed: <target service>.
-
There is no mapping between hosts and components in the object. This cause is displayed in the UI as the message <Concern owner> has an issue with host-component mapping.
The purpose of issues is to prevent incorrect interaction and operation of objects.
Concern owners
Concerns have an owner. For flag and issue concerns, the owner is an ADCM object affected by this problem.
In the UI, the concern owner is demonstrated in a pop-up message about the cause next to the concern icon.
For lock concerns, the owner is the corresponding job.
Concern prioritization and inheritance
If an ADCM object has two concerns, one of which is blocking and the other is not, the blocking concern takes precedence. The icon of the concern is colored with the color of the higher-priority concern.
Concerns can also be inherited by objects from other objects. For example, if a hostprovider has a concern, it can be inherited by a host created using that hostprovider.
Concerns are inherited in both directions between parent and child objects. Objects are in parent-child relationships if there is an explicit hierarchical link between them. If a service has a concern, that concern is inherited both by the cluster containing that service and by the component contained within that service. However, a service concern is not inherited by hosts if the service’s components are not added to the host. Similarly, if a concern arises on a cluster containing a host without components, that cluster concern will not be inherited by the host until at least one component is added to that host. If a concern arises on a host without components, it will not be passed to the cluster containing that host.
Flag concerns for a service do not spread to other services in the cluster. Lock and issue concerns spread from a host to components located on that host, even if the concern owner is another parent object: cluster, service, component, or hostprovider.
If the concern owner object is deleted, the concerns of all related objects (both parent and child) will also be deleted. For example, if services with concerns are removed from a cluster, those concerns will also disappear from the cluster. However, concerns whose owner is the cluster itself will not disappear.