LCM Instance Data History

Beginning with Platform 6, Lifecycle Manager (LCM) now provides users with the ability to view the properties which were changed with each action that was taken against an instance. With this feature, you can actually view what properties actually changed with each action against an instance.

This guide will explain how to view LCM instance properties in the instance history, some currently known limitations and their workarounds, and how to mitigate any issues that may occur while using the feature.

Viewing LCM Instance Data History

Let's say you are trying to troubleshoot an instance by understanding when a property has changed. With this feature, you now have complete transparency into how instance data has evolved over time and how an endpoint (such as a device) was changed.

Instance History

To view Instance Data History, select any single instance of a Resource. Each entry includes the user who ran the Action, the Action name, the group the Execution came from (if any), the Execution start time, and the status. The History tab is ordered by start time.

Figure 1: Instance Details View of an Instance’s Action History.

Execution Details

Click on any Action within the History tab to view the relevant Execution Details. The left side of the Execution Details page contains the Execution Metadata. The grey box in the Metadata contains the Execution Steps the Action contained when it was ran.

Figure 2: Execution Details in Platform 6 with a Pre-JST, Workflow, and Post-JST

Execution Data Diff

Starting with Itential Platform 6, the right hand side of the screen contains the Execution Data. The left JSON object, “Initial State”, is the state of the Instance when the Action was started. The right JSON object, “Output State”, is the state of the Instance when the Action was completed.

A standard line-based diff is run against the two states to highlight all additions, deletions, and modifications. If a line is modified (deletion and addition on the same line), the difference in characters is also highlighted.

Data more than three (3) lines away from any change is initially collapsed to help focus on the changes. Simply click the <> Expand # lines message to show the hidden lines.

Figure 4: Execution Data Containing Deletions, Additions, and Modifications

Instance Group Execution Details

When viewing the Data History for Instance Groups, the Execution Details page will display a table of Executed Actions for each Instance instead of a diff view. Click the links in the table to be redirected to the Execution Details for that specific Instance.

Figure 5: Execution Details of an Instance Group

Action States

The possible states for an Action are RUNNING, ERROR, COMPLETE, and CANCELLED. The diff view is only available for Executions where the state is COMPLETE. The page will automatically update when a running job completes.

Figure 6: Action Data View - Action is Running

Action Types

All three LCM Action types (Create, Update, Delete) will display a State Data diff view when completed.

The Initial State of a Create Action will always be an empty object.

The Output Stateof a Delete Action is defined by the Delete Action’s Output, just like a Modify (Update) Action. A deleted Instance’s Action History will still be available after deletion.

Figure 7: User-Defined Output State After Running a Delete Action

Diff View Handling

The Execution Data view stringifies the state objects and runs a standard diff to make the comparison. This view does not ignore white space or reorder keys when running this diff. If any keys were reordered by an Action, each moved key will appear to be deleted from the Initial State and appended onto the new line in the Output State, even if the value was unchanged. Additionally, changes in white space (such as from nesting the same data into another object/array) will be detected as a change. In the example below (Figure 8), there's a diff view of an Update Action where “balance” was unchanged but reordered, and the “friends” array was unchanged but relocated inside of a new “personal” object.

Figure 8: Diff View of an Update Action

Large strings are considered to be on a single line, even when they contain newline characters.

Figure 9: Diff View with a Large Modified String

State Handling

The difference between states is calculated by the client’s browser when opening each Execution Data page. The time to calculate the diff is a multiple of both the size of the States and the size of the diff itself. Executions that result in States that are both large and highly different will require significantly more calculation time than states with only one of these traits.

Additionally, all changed lines must be rendered by the browser, while identical lines are initially collapsed. States with many changes will have to render many more elements than states with fewer changes, even when the state sizes are the same.

Demo Video: Displaying the relative performance of Execution Details load times between two equivalently sized states.

• The first Execution Data has minimal changes, so it calculates the diff of the ~47,000 lines and renders all within a few milliseconds.
• The second diff is highly changed and takes multiple seconds to calculate and render.

Known Limitations & Mitigations

• Metadata such as “Instance Group” and “End Date” only appear if and when they exist.
   
• Upon execution of an Action, all current names and references to the current Action, Instance, Instance Group, Pre-JST, Workflow, and/or Post-JST will be stored in the Execution Details. These display names and references will remain unchanged in the Execution Details view regardless, even if any of these listed assets are later modified, renamed, or deleted.
   
• Currently, there is no available method to copy an individual State from the Execution Details.
   
• For optimal performance and to get the maximal utility from the diff view, minimize needless key reordering and excessively large strings.
   
• Avoid storing large objects as a single string property if you wish to clearly see any differences.
   
• Avoid Actions that involve both a large State and a large number of changes. If you must have one of these conditions, avoid the other if possible.

Should you encounter any issues viewing the data properties which were changed with each action taken against an instance, please reach out to the Itential Service Desk using the Customer Portal link.

Testing & Validation (Developer)

Automated component tests can be found in:

services/app-lifecycle_manager/client/routes/ResourceModelDetails/ExecutionDetails

To test the feature:

1. Create an LCM Model.
2. Create and modify instances with Actions.
3. Create Actions with various combos of workflows and JSTs.
4. View the History tab.
5. Open an Execution Details page.

Expected outcome:

• Metadata displays correctly.
• Execution steps correctly display any combination of Workflow and Pre/Post JST.
• Diff view functions properly.