Each configuration element has a unique identifier which is determined by its application. In Tulip’s language, this identifier is known as the Service ID. This ID is crucial in the context of a Tulip application connection, particularly when fetching configurations from security applications. For example, if an Okta configuration element is updated, Tulip utilizes the element’s Service ID to ensure that the correct element is updated. Similarly, during deployments, the Service ID is the definitive reference, guiding which updates are deployed to the security applications.
A key Tulip use case is the ability to compare and align configuration elements across multiple application connections. Tulip can deduce that element x in one application connection should be compared to element x in another only if the ID of both of these elements is identical. In cases where the elements’ Service ID is consistent across application connections, everything works well. However, there are cases where the Service ID may change only within a specific application connection. To overcome this Service ID limitation, Tulip relies on its own ID, known as Tulip ID. Typically the Tulip ID inherits its value from the Service ID, except for the ‘problematic cases’ (when a consistent cross-connection ID is not available) where the Tulip ID anchors itself to changeable attributes, like an element’s name or title.
Basing Tulip IDs on changeable attributes, such as an element’s name or title, can introduce unique challenges. While Tulip relies on the constant Service ID for accurate updates during fetch operations, the Tulip ID once assigned, remains static, meaning that it can change in certain cases. This is vital for ensuring consistency, since we assume configuration elements initially have matching attribute values. However, there are several scenarios where complications arise:
Sandbox Refresh:
When an operation alters the
Service IDsof elements, Tulip may perceive these as new elements due to the changedService ID.This can result in the assignment of a new
Tulip ID, potentially misaligning with IDs from other application connections.
New Sandbox Creation:
Creating a sandbox from an application connection with outdated
Tulip IDsresults in the new sandbox having updatedTulip IDs.This can cause mismatches when comparing with other application connections.
Manual Alignment of Application Connections:
Consider a scenario with a sandbox and a production application connection:
An element named
Xwith a specificService IDis added to the sandbox and fetched, resulting in aTulip IDofX.This element's name is changed from
XtoYin the sandbox and fetched again. However, itsTulip IDremains asX.In the production application connection, an element named
Yis manually created and fetched, leading Tulip to assign a newTulip IDofY.Comparing sandbox to production, Tulip inaccurately suggests adding the
Xelement and removing theYelement.
Regenerating Tulip IDs
To effectively address the above cases, it's possible to regenerate the Tulip IDs to reflect the current element attributes. To do so, navigate to your application connection settings in the Applications page, and click on the 'Regenerate Tulip IDs' button in the Danger Zone.
This will allow you to fetch and regenerate Tulip IDs for all / some of the elements in your application connection.
Important Notice on Restoring / Reverting after Regenerating Tulip IDs
When regenerating Tulip IDs, be mindful that attempting to revert deployments or restore to a version prior to the Tulip IDs regeneration may result in elements with newly generated Tulip IDs not being restored. This limitation is due to the absence of these IDs in earlier versions, which can prevent a direct match during the restoration process. Please plan your restoration activities accordingly to make sure you recover the application connection's configuration.
Related articles: Restoring an environment, Reverting deployments.