Whenever a CNF operation fails, the status is marked as failed. However, there is no way to find out why the CNF operation has failed.

The CNF LCM granular status updates feature allows you to view the kubernetes events as well as Helm events while performing a LCM operation on a CNF. This feature helps you to know background activities as install, upgrade and so on while the CNF operation is performed.

The following are various stages of CNF operation:

  • Node Customization

  • Grant

  • Pre Workflow

  • Helm

  • Post Workflow

Depending upon the CNF, some stages may be skipped. For example, if the CNF does not contain a pre or post workflow then those two stages can be skipped.

This feature captures the events when the CNF reaches to fourth stage or Helm stage. During this stage, you can see the operations executed by TCA Helm Service and operations executed on the Workload Cluster corresponding to the CNF.

Note:

The events are captured when the helm command is in progress and it is stoped as soon as the helm command completes. It is advised to go to the Inventory page to get latest information on kubernetes resources corresponding to the CNF once the LCM operation is completed.

CNF Event

A CNF Event consists of the following information:

  • Event Category

  • Event Message

  • Event Type

  • Event Timestamp

Event Category

There are two types of event categoires, HelmEvent and K8sEvent. The HelmEvent is generated by TCA Helm Service whereas the K8sEvent are generated on the cluster and is captured by one of the monitoring services in TCA, specifically the K8s Event Collector Service. The Helm event indicates that an event is carried out solely by Helm Service.

For exapmple:

  • Downloading helm chart

  • Validating helm chart

The K8sEvent may contain information related to the the kubernetes cluster. For example:

Created Pod mysql-162-84b85-kx3zd-6fb4f49ff7-2wqn8

Container image "10.198.63.191:80/cnf-local/busybox:1.29.3" already present on machine

Scaled up replica set mysql-162-84b85-kx3zd-6fb4f49ff7 to 1

Event Message

An event message is the message corresponding to the event providing details of the activity happening at the time of CNF LCM operation.

Event Type

An Event Type indicates the severity of the event whether an event is information, warning or error type.

Event Timestamp

An Event Timestamp indicates the time when the event occurred. By default events are listed in descending order of their timestamp.

CNF Tasks Page

The events captured during the CNF operation are stored for each CNF and operation. If you wish to view the events later, visit the Task page. This page is helpful in case the CNF LCM operation fails, you can look at this information and later debug, correct the error, and redo the operation.

The following image shows the Task page for a CNF. This page lists all the operations that have been performed on CNF. It shows two operations have been performed on this CNF such as Upgrade and Instantiate. To know more details about the CNF operation, click the > icon.



After you click the > icon, the following page appears and you can see the details of each event.



CNF Events in the Main Page

You can also see the CNF events in the main CNF page ( the page where any of the LCM operations are triggered from). The events are shown under Recent Tasks.

This page lists the events only from the most recent LCM operation. To see the events from previous LCM operation, go to the Tasks page.



Filtering and Sorting of Events

You can filter events based on the type of the event or the category of the event. You can also sort the events using the event time, either in the ascending or descending order.

Enabling or Disabling the Feature

The feature is enabled by default. However, to turn this feature off post TCA 3.1 deployment or upgrade, use the following API:

curl -k --request PUT https://<tca-ip>/admin/hybridity/api/global/settings/Cnf/disableGranularUpdates \
--header 'content-type: application/json' \
--header 'accept: application/json' \
--header 'x-hm-authorization: <token>' \--data “{\”value\”:\”true\”}”

Where:

  • tca-ip is the IP address of the TCA system.

  • token is the session token that needs to be obtained by calling the Session API.

  • value can be either true or false. Setting this value to true disables the feature. Otherwise it is enabled.

Note:

The API should be called on TCA Manager as well as on TCA-CP. If there are more than one TCA-CP deployed, then the API should be called on all of the TCA-CPs. After changing the setting, restart the following services so that the updated services are reflected.

On TCA-M: TCA App engine

On TCA-CP(s): TCA App engine, Helm Service, K8s Event Collector Service

Known Limitations:

  1. The feature is enabled by default and can be disabled if required. The following services on TCA-CP need to be restarted whenever this setting is changed:

    1. TCA App Engine

    2. Helm Service

    3. K8s Event Collector Service

  2. Since the service monitors for events only until a CNF operation is in progress, there is a possibility that an event is not captured as the monitoring may have stopped before that event is received. It is advised to check the Inventory page for latest information on CNF resources.

  3. There is no retention policy for the events to stay in the database.

  4. A CNF operation can potentially take long time to complete for example, 30 minutes. This can generate large amount of cluster events. All of these events will be stored because there is no maximum limit to store events.

  5. If the following services are restarted in the middle of an ongoing CNF LCM operation then the events may be lost for that particular CNF. These services are:

    1. Helm Service

    2. K8s Event Collector Service