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 top-most blueprint, that user is entitled to all aspects of the blueprint, including 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 your 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 your outer blueprints, unless you have overridden those settings in the outer 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.

Networking and Security Rules and Considerations for Nesting Blueprints

  • All networking and security components in outer blueprints can be associated with machines that are defined 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.

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.