You can reuse blueprints by nesting them in another blueprint as a component. You nest blueprints for reuse and modularity control in machine provisioning, but there are specific rules and considerations when you work with nested blueprints.
A blueprint that contains one or more nested blueprints is called an outer blueprint. When you add a blueprint component to the design canvas while creating or editing another blueprint, the blueprint component is called a nested blueprint and the container blueprint to which it is added is called the outer blueprint.
Using nested blueprints presents considerations that are not always obvious. It is important to understand the rules and considerations to make the best use of your machine provisioning capabilities.
General Rules and Considerations for Nesting Blueprints
As a best practice to minimize blueprint complexity, limit blueprints to three levels deep, with the top-level blueprint serving as one of the three levels.
If a user is entitled to the outer blueprint, that user is entitled to its nested blueprints.
You can apply an approval policy to a blueprint. When approved, the blueprint catalog item and all its components, including nested blueprints, are provisioned. You can also apply different approval policies to different components. All the approval policies must be approved before the requested blueprint is provisioned.
When you edit a published blueprint, you are not changing deployments that are already provisioned by using that blueprint. At the time of provisioning, the resulting deployment reads current values from the blueprint, including from its nested blueprints. The only changes you can pass on to provisioned deployments are edits to software components, for example edits to update or uninstall scripts.
Settings you define in the outer blueprint override settings configured in nested blueprints with the following exceptions:
You can change the name of a nested blueprint, but you cannot change the name of a machine component, or any other component, inside a nested blueprint.
You cannot add or delete custom properties for a machine component in a nested blueprint. However, you can edit those custom properties. You cannot add, edit, or delete property groups for a machine component in a nested blueprint.
Changes you or another architect make to nested blueprint settings appear in the outer blueprints, unless you have overridden those settings in the outer blueprint.
Limit the maximum lease time on the outer blueprint to the lowest maximum lease value of a component blueprint.
While the lease time specified on a nested blueprint and on the outer blueprint can be set to any value, the maximum lease time on the outer blueprint should be limited to the lowest maximum lease value of a nested blueprint. This allows the application architect to design a composite blueprint that has uniform and variable lease values, but is within the constraints identified by the infrastructure architect. If the maximum lease value defined on a nested blueprint is less than that defined on the outer blueprint, the provisioning request fails.
When working in an outer blueprint, you can override the Machine Resources settings that are configured for a machine component in a nested blueprint.
When working in an outer blueprint, you can drag a software component onto a machine component within a nested blueprint.
If you open a blueprint in which a machine component in a nested blueprint was removed or its ID was changed, and the machine component was associated to components in the current blueprint, the associated components are removed and the following or similar message appears:
A machine component in a nested blueprint that is referenced by components in the current blueprint was removed or its machine component ID was changed. All components in the current blueprint that were associated to the missing or changed machine component ID have been removed. Click Cancel to keep the association history between the missing or changed machine component ID in the nested blueprint and components in the current blueprint and correct the problem in the nested blueprint. Open the nested blueprint and re-add the missing machine component with the original ID or change the machine component ID back to its original ID. Click Save to remove all association history between the missing or changed machine component ID in the nested blueprint and components in the current blueprint.
When you publish a blueprint, software component data is treated like a snapshot. If you later make changes to the software component's properties, only new properties are recognized by the blueprint in which the software component exists. Updates to properties that existed in the software component at the time you published the blueprint are not updated in the blueprint. Only properties that are added after you have published the blueprint are inherited by the blueprint. However, you can make changes to instances of the software component in blueprints in which the software component resides to change that particular blueprint.
Networking and Security Rules and Considerations for Nesting Blueprints
Networking and security components in outer blueprints can be associated with machines that are defined in nested blueprints.
NSX network, security, and load balancer components and their settings are not supported in nested blueprints.
When app isolation is applied in the outer blueprint, it overrides app isolation settings specified in nested blueprints.
Transport zone settings that are defined in the outer blueprint override transport zone settings that are specified in nested blueprints.
When working in an outer blueprint, you can configure load balancer settings relative to network component settings and machine component settings that are configured in an inner or nested blueprint.
For a nested blueprint that contains an on-demand NAT network component, the IP ranges specified in that on-demand NAT network component are not editable in the outer blueprint.
The outer blueprint cannot contain an inner blueprint that contains on-demand network settings or on-demand load balancer settings. Using an inner blueprint that contains an NSX on-demand network component or NSX load balancer component is not supported.
For a nested blueprint that contains NSX network or security components, you cannot change the network profile or security policy information specified in the nested blueprint. You can, however, reuse those settings for other vSphere machine components that you add to the outer blueprint.
To ensure that NSX network and security components in nested blueprints are uniquely named in a composite blueprint, vRealize Automation prefixes the nested blueprint ID to network and security component names that are not already unique. For example, if you add a blueprint with the ID name xbp_1 to an outer blueprint and both blueprints contain an on-demand security group component named OD_Security_Group_1, the component in the nested blueprint is renamed xbp_1_OD_Security_Group_1 in the blueprint design canvas. Network and security component names in the outer blueprint are not prefixed.
Component settings can change depending on which blueprint the component resides on. For example, if you include security groups, security tags, or on-demand networks at both the inner and outer blueprint levels, the settings in the outer blueprint override those in the inner blueprint. Network and security components are supported only at the outer blueprint level except for existing networks that work at the inner blueprint level. To avoid issues, add all your security groups, security tags, and on-demand networks only to the outer blueprint.
Software Component Considerations for Nesting Blueprints
For scalable blueprints, it is a best practice to create single layer blueprints that do not reuse other blueprints. Normally, update processes during scale operations are triggered by implicit dependencies such as dependencies you create when you bind a software property to a machine property. However, implicit dependencies in a nested blueprint do not always trigger update processes. If you need to use nested blueprints in a scalable blueprint, you can manually draw dependencies between components in your nested blueprint to create explicit dependencies that always trigger an update.