....So in automation center we can set a custom property value to a blueprint or server build such as "VirtualMachine.Admin.Clustername" to override something in the default workflow like what cluster we are going to provision to.
If I start using the properties dictionary and I make a custom entry for VirtualMachine.Admin.Clustername and set it as a dropdown box I can effectively limit what the user can select...however, this limitation is going to be the same for ANY blueprint now that wants to use that custom property...so if I have blueprint #2 that I don't want to have access to one of those clusters as an option what am I to do?
Is the solution other people use to create a true custom property, mark it as a dropdown with whatever selections, and then as part of the default workflow have vCenter orcehstrator hooked in to read that custom value and then based on it's value set the actual VirtualMachine.Admin.Clustername? I am just finding the property dictionary to be extremly limiting in that I can only do each property once, I can only restrict values once, I can't provide user friendly names for the "values" unless I go this VCO route...am I on the right track?
Provide a dropdown for blueprint 1 that has cluster a and b as selections.
Provide a dropdown for blueprint 2 that has cluster c and d as a selection but not cluster a and b.
Provide a storage dropdown that has selections for storage based on value in the cluster dropdown (I think I can still do this with the XML with ONE instance of the custom property since it is just going to look at the value in the cluster dropdown and won''t have all options available)
Is it common to use the machine blueprint in this way where all of my true custom stuff I will have performed with Hooks into VCO, or is this a dumb idea? Should I be depending on VCO using advanced services designer to do the entire vm provision from start to finish?
I can say that you are not alone in your struggles.
You are describing dynamic form fields. We both want data to be able to drive other data within our forms. I would go as far as wanting to have the entire form change based on data selection. Some of this is implemented in the machine blueprints already. But it is unnecessarily difficult to leverage, and as you noted there are other complications when trying to use common properties across multiple Blueprints (when you want dynamic).
I think in the ASD form designer for 6.2, there is finally a lot *right* with it. (particularly now with the direct *external* actions calls to vRO... even though OGNL presentation based action calls was available prior) Unfortunately, ASD form designer is a world away from how the Machine Blueprint forms are created, and in reality... I think the whole design process in Machine Blueprints is hugely counterintuitive and lacks elegance. (let alone things we would consider *desirable* functionality that are missing... e.g. hiding/reordering/requiring built-in fields) But... I am just a dude with an opinion, and there are always enough of those to go around.
One thing I considered doing is to create simple machine blueprints that take in typed custom properties... but hide-them-yet-entitle-them to the requestors (Steve Beaver has an example leveraging Services) and use an ASD Service Blueprint form to control the data entry and call the simple Machine Blueprint via REST while supplying the gathered values. It is a lot of work... done to get around the limitations found in the form design for machine blueprints. And truthfully... it is very frustrating. Form design for machine blueprints needs to be improved greatly. I have some hope that 7 will give us better capability in that regard.
>>Should I be depending on VCO using advanced services designer to do the entire vm provision from start to finish?
I am going to say no. vRA gives you the lifecycle management, provisioning, categorization, and inventory that you need. You wouldn't want to make direct calls to vCenter to clone templates for example. (if that is what you meant)
What you maybe should look at doing is use ASD to gather your data to feed into a machine request. It can give you an operational dynamic layer to your request process and still give you the benefits that DO exist in vRA. In the end, it is a really good product... but there is always room for improvement.
What you're describing is exactly what reservation policies (+ the use of the location names for the compute resources) are for. Assign a reservation policy to your reservations, then also assign the same reservation policy to the associated blueprints, and if there are multiple clusters available, enable the location field. When the location is selected, that cluster will be used. I use it to pin specific environments to different groups of blueprints.
That would be the easiest way, and it's a completely supported and OOTB configuration. No need to mess around with custom properties at all.
Just to add to this...
I am using the above method and I am able to apply the logic along the way that the correct profile is selected. Check out this post with info on getting the reservationPolicyID. Tiering vCAC Blueprints with Policies, On Demand - Elastic Skies
Vrm.DataCenter.Location property is what you can use which then combined with with relationships can pick which cluster you want to deploy into but also limit any additional fields based on the section. This could be network choice, customization script, template to clone from etc etc etc.
Being able to use the location property with relationships was available in 6.0 removed in 6.1 and re added in 6.2. using this combined with relationships on other fields can limit the blueprint sprawl while having the form semi intelligent.
Also I should point out the location property is fine to use when there is only 1 reservation per cluster. If by chance you have multiple reservation pointing to a single cluster the location will still work but in the background with round robin which reservation it used.
Are you all following something similar to:
I guess I was trying to make this more dynamic by having one blueprint to do everything and one reservation per tenant...but this could work in the short term.
SeanKohler So you have been experimenting with or have been making a simple blueprint and then use ASD to make a form with all the information and dynamic fields/lookups for your machine and then pipe that into a rest call using vCO that starts that simple blueprint process? Do you have to entitle the ASD AND simple blueprint to the user or just the ASD? I wouldn't want my users seeing they had access to the simple blueprint and trying to use it.
So I see two options...
Option one sbeaver figured out. Basically you put the simple blueprints in a service that is set to inactive and add it to the entitlement for the business group but ALSO add the catalog items individually to the entitlement. He can explain more, but what I think happens is since the catalog items exist in the service and the service is inactive, they are effectively hidden-yet-entitled.
Option two would be my preferred option, but I haven't walked through it directly... but I suspect it is workable because I have done all these things individually.
Take all of the simple blueprints and entitle them to a service account placed in a business group Support User role. (you can bundle them in a Service) They are not entitled to the end user. This allows the service account to provision and own machines in the business group. (but wait there's more) Your ASD workflow Service Blueprint is entitled to the user (user blueprint)...
The workflow (user blueprint) takes in all of your data (managed dynamically via OGNL presentation in vRO or via presentation capabilities in ASD form) and calls...
1. Request a catalog item on behalf of a user which runs the simple blueprint as the service account and fills in the data for the request (or the Rest method to run the simple blueprint catalog item changing the user to the service account - who is entitled to run it)
2. After machine is built... Change the owner of the machine to the actual requestor (meaning the user workflow needs to wait for provision task to complete - there are examples of this out there). I have workflows for this ownership change if you want them.
This way you do not have to do any fancy hiding. It ends up just being a provision as one user (imaginary service account user) and change ownership to requestor.
Side note: (And it actually brings up another point that I think people tend to just brush aside when considering the implications: Service Accounts can own machines. There are use cases for this when you have an environment where you want to collect all machines into one or many business group(s) with lifecycles and the other advantages of using vRA/vRO, but you do not want dedicated ownership.)
Message was edited by: SeanKohler
When I have a custom property that I want to update based on logical decisions, I let vRealize Orchestrator perform the custom property value update for me in the Building Machine WFStub.
Sky Cooper has documented this process on his blog (http://realize.net).
Essentially Sky has documented being able to update CloneSpec and CloneFrom to create a single blueprint that front loads several OS types and customization spec files using case statements in vRO. I have done this to set memory and CPU settings based on S/M/L drop down selections among other uses.
I don't see why you couldn't update the VirtualMachine.Admin.Clustername custom property value based on logic that you create through a series of drop down selections in vRA.
Sean, you hit the nail here; the way the blueprint forms work is very counterintuitive and severely limited by the static nature of the underlying property dictionary.
The whole problem starts with the fact that the property dictionary - eg the value list you can consume in the blueprint form - is a tenant-wide property and does not even exist at the blueprint or business group level. So you can only ever set the dictionary values for a named property once.
And you can't use multiple dictionary entries to back the same custom property either - the way it's been implemented your custom property consumes a dictionary entry only if and when they have the same name.
NOw, all that being said: There is actually a way of achieving this; The property dictionary can actually consume a filter list by way of a custom XML.
I'll be using this mechanism when targeting my end-users with the various inputs in a blueprint request; I might be able to use a single property at the business group level to filter all my inputs, with a little luck and a lot pain (XML is not for human consumption).
I'm just wondering if you got this to work the way you wanted. I have a similar case and was wondering if the content of a list in the dictionary can be filtered based on properties set elsewhere in the data model, e.g.,
the dictionary contains a list of network profile names which are filtered by certain tags. The in my business groups I'd like to set the same tag values to force a request from a BG user to filter the dictionary for their tag...?
Does it work this way or am I better off going into vRO like I though?
Just to follow up on my own question here
This does work
I was able to add 'static' tag values to my business groups and then put an entry into the property dictionary to filter network profile names based on the tag value. This works because in effect the tag is a fixed value and the full set of network profiles for all BGs is effectively static too.
The main disadvantage would be that the ValueExpression in XML would need to be updated any time a BG was added/removed or indeed if a network profile name were added/removed/modified
Anyway, thought I'd share for anyone else that has wondered about this