One of the powerful features of custom attributes is the concept of inheritance. Custom attributes are inherited from higher level objects to lower level objects giving you powerful ways to control the values of the custom attributes you use in your Build Plans.
-
Facility level custom attributes are inherited by all servers on the appliance.
-
Device group custom attributes are inherited by all servers in that device group.
-
Build Plan custom attributes are inherited by any server running that Build Plan, but only in the context of that active job.
Custom attributes from higher levels can be overridden by identically named custom attributes at lower levels as follows:
-
A server level custom attribute has the highest precedence and overrides any other custom attribute of the same name.
-
A device group custom attribute overrides a facility level custom attribute, providing the server is in that device group.
-
A Build Plan has the lowest precedence and is overridden by any other custom attribute of the same name.
|
|
|
![[NOTE: ]](images/note.gif) |
NOTE: If the same custom attribute is assigned to multiple device groups and the same server is in both of those groups, the device group the server inherits that custom attribute from is unpredictable. |
|
|
Example of how inheritance works
Suppose every server you install needs to have a special access code. You design your Build Plan to get that access code from a custom attribute "AC" at run time. Since most servers in the organization can use a default access code, you create a facility level custom attribute "AC" and assign its value to the default code. Now, any server that runs that Build Plan picks up the default code from the facility level custom attribute.
The corporate finance group wants to use their own special access code. To solve this problem, you create a device group and assign a custom attribute "AC" to that device group with their special access code. You then add all of the finance group's servers to the new device group. Now, any time you run a Build Plan on one of those servers, the device group custom attribute overrides the one from the facility level, and just those servers get the special access code.
The head of finance wants their personal server to have a unique access code. So, you select that one server and assign custom attribute "AC" with the new unique access code. That value now overrides any value provided from the facility or the device group for just that one server. Note that at the server level, you see any inherited custom attributes. You create an override by editing the inherited value. This creates a local server override.
Finally, you want a safety mechanism to make sure an access code is always provided or access is disabled. So you create an "AC" custom attribute assigned to your installation Build Plan and set that to a value that disables the access port. Since the Build Plan level custom attribute is the lowest precedence, any "AC" custom attribute defined at the facility, device group, or server level overrides the fail safe, but if none of those are defined, the code from the Build Plan attribute is used and the access port is disabled.