Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
In my article Custom Properties Demystified I reference a chart I put together that defines the override order of custom properties based on where they are defined. The document is available in the downloads section. This document is a list of my findings based on testing I performed.
While delivering a vCAC 5.1 training class today I shared the document with my class and one of the attendees was kind enough to look over the chart and determine a definitive override order based on the data. This is great as I never took the time to review the data to determine a definitive override order. So here you go.
Definitive Override order
- Provisioning Group
- Blueprint
- Build Profile
- EndPoint
- Reservation
- Compute Resource
- Storage
Working from the top of the list to the bottom is the order or override. So provisioning group will override everything below it and so forth.
Interesting… as listed in the current 5.1 operating guide page 62 (and inverted to match ‘higher wins’ ordering above), one would arrive at this conclusion:
Runtime
Endpoint
Reservation
Compute Resource
Provisioning Group
Blueprint
Build Profile
From my experience thus far, reservation properties are definitely overridden by build profiles and blueprints..so I’m sticking with your list rather than the documentation. 🙂
This makes me wonder if runtime (presumably those specified at request time by a PGM/EA) do in fact win above all – I haven’t pitted those against a provisioning group yet.
Runtime will always win. I have a document in the downloads section that are my finding from doing exhaustive testing on what the overrides are.
Hmm, I think things may have changed in 5.2. I don’t see it called out as “fixed” anywhere, and don’t see the _documented_ order changed between 5.1 and 5.2 docs, but I seem to have a new behavior whereby reservation properties win over build profiles – which arguably matches documentation now, but not the behavior I had come to expect (and that you have above). I have a little more testing to do but it’s currently breaking some things in our case that depended on the previous order.
More eyes are always great if you’ve by chance re-tested this 🙂
Regards,
Mike
Aha – it’s actually that the behavior differs for regular “users” vs. provisioning group managers. Apparently anything in build profiles and blueprints, for PGMs, become runtime and automatically win. Slightly problematic IMO, but at least understood now.
Looks like we need more matrices. :/