Hi All,
There am thinking of two ways of creating vm resources with Advance Services designer. Let me know your thoughts.
1. ASD service invoking VCO workflow
Infrastructure:
1. VCO DynamicType . i.e LinuxVM
2. VCO workflow that creates and returns object of type LinuxVM
3. VCAC Custom resource based off of VCO Dynamic Type LinuxVM
4. Custom Actions
Pros:
* Flexible/Customizable - developer will have complete control over the workflow
Cons:
* More moving parts more error handling : Our environment distributed(multi-node plugin)
* More development work: Need to develop provisioning, action workflows
2. ASD Service invoking VCO Workflow which in turn call VCAC Catalog Item - Blueprint
Infrastructure:
1. VCO DynamicType . i.e LinuxVM
2. VCO that invokes custom catalog item and returns object of type LinuxVM
3. VCAC Custom resource based off of VCO Dynamic Type LinuxVM
4. Custom Actions
5. VCAC Catalog Item - Blueprint
Pros:
* Easier transition from ASD to Blueprint when VCAC matures
Cons:
* quicker development
* deal with two objects - one created by blueprint and other by ASD
Thanks,
Option #2 is the way I have things done in my environment
My two cents...
Sort of number 2, with regard to this concept: "ASD Service invoking VCO Workflow which in turn call VCAC Catalog Item - Blueprint"
But then your steps for number 2 sort of go off the rails. You shouldn't leverage Dynamic Types as Custom Resources when you WILL have Machine Resources using this method. It isn't D.R.Y. When you have an ASD request call an IaaS Machine Blueprint, you will end up with a machine resource. You use ASD so that you can better manage the REQUEST FORM, and use ASD to create custom actions on the machine resource... not on a custom resource. And this statement isn't true: "deal with two objects - one created by blueprint and other by ASD". Only one resource. A Custom Resource based on Dynamic type is not required at all.
Here are a few thoughts...
1. Dynamic Types, though useful, are not fully baked. (there are many //TODOs and less DONEs... for example the generateTypeFinderMethods(...) method: look at the resulting scripts. The VCOteam calls out that Dynamic Types isn't production ready at this time.
2. The benefit to dynamic types is that you can have ANY object with ANY metadata that can have custom actions built onto it in vRA when rolled into a custom resource. But Machine Resources have custom properties and custom actions plus the wealth of lifecycle, cost, state, and base-config management that comes built into vRA. Throwing that aside isn't something to be done lightly.
3. Custom Resources cannot have leases or costs (YET... but I do want this!). They are missing all of the lifecycle properties you get in the core vRA product.
4. The major product deficiency for machine provisioning in vRA is the request form designer and the ability to setup dynamic form fields easily. ASD just does this plainly better. And I am sticking to that opinion. What some people are doing (like Steve): leverage ASD form strengths to handle the "request" and let VCAC blueprints handle the provision (with callouts to VCO for workflow extensibility) and lifecycle of the machine. Add onto that custom Resource Actions on the provisioned machine resource and approvals on any action, and you have the best of all worlds through the entire machine lifecycle. I anticipate that form design will improve in the vRA core product.
>>>Option #2 is the way I have things done in my environment
Can you clarify if you are indeed leveraging Custom Resources for all of your machines... built and maintained within Dynamic Type namespaces?
I don't think that is the case... if so, would love it if you would explain. (I think you are doing machine resources.)
I have a question about blueprints. Do you create blueprints for each reservation i.e cluster? For example replicated and nonreplicated clusters do you create two blueprints? Then each cluster will have a blueprint. One way to avoid this is as suggested in the post Tiering vCAC Blueprints with Policies, On Demand - Elastic Skies with __reservationPolicyID dynamically assigning reservationPoicy at run time. To make this work the blueprint needs __reservationPolicyID property and this will value will be set by ASD-VCO workflow before calling the catalog item. With this there will be one blueprint that will work for all reservations. Do you see any issue or how have you done?
Can you clarify if you are indeed leveraging Custom Resources for all of your machines... built and maintained within Dynamic Type namespaces?
Built and maintained by Dynamic Type Namespaces, no I am not using namespaces. All logic and such is either achieved as an action in the presentation tab of the VCO workflow and any others are achieved during the building workflow stub and the vcac entity updated with the new values.
Is that making sense?
That is pretty much how I am doing things. In my VCO workflow I have an input called reservationId that is populated with an action that takes the value of the network environment and returns the proper reservation ID
Steve, I am not using custom resources Dynamic Datatypes any more.
The following is my setup let me know if you see any issues
1. ASD workflow provisions no resource
2. VCO workflow no output
3. VCAC Linux blueprint
ASD calls VCO workflow which in turn invokes catalog item( blueprint) to create a vm.
Custom resource action work flows have "IaaS VC MachineType" ( Resource Mapping ) input . These actions are visible under items>machines>actions.
Let me know if there is an easier way to do it.
I am not using any Custom Resource Actions in my build process. That I am using strictly for day two operations if I am understanding you correctly. I am using the request for a catalog item on behalf of a user workflow for this.
Below are all the inputs in the vCO workflow it did not copy and paste as I was hoping but notice the last column which is the input description This should give you an idea of all the inputs that are defined before it gets to the request catalog action
So the flow of the workflow starts with an action to get the requestBy value which becomes the owner. From there I have another action that sets which blueprint to use and then a scriptable task to create the property of all the variables and inputs and finally presents that to the requestcatalogitem action. Any other logic or processing will get done via the building workflow stub.
Does that help at all?
[Ljava.lang.Object;@8277f6a | ch.dunes.model.dunes.ScriptModuleParameter@591e0c54 | number | the number of virtual machines you would like to request with this order |
[Ljava.lang.Object;@43bb8c81 | ch.dunes.model.dunes.ScriptModuleParameter@4e058be4 | string | Operating System Type |
[Ljava.lang.Object;@4e234dc0 | ch.dunes.model.dunes.ScriptModuleParameter@6fc5a053 | number | Number of days you would like to lease this server |
[Ljava.lang.Object;@17a0e279 | ch.dunes.model.dunes.ScriptModuleParameter@4374820d | string | Operating System Version |
[Ljava.lang.Object;@16064614 | ch.dunes.model.dunes.ScriptModuleParameter@75e2d657 | string | Number of CPU's you would like to request |
[Ljava.lang.Object;@7f662637 | ch.dunes.model.dunes.ScriptModuleParameter@b572639 | string | Amount of memory you would like to request |
[Ljava.lang.Object;@68e6e00 | ch.dunes.model.dunes.ScriptModuleParameter@70d7c55c | boolean | Add additional storage |
[Ljava.lang.Object;@65de54e4 | ch.dunes.model.dunes.ScriptModuleParameter@679778fb | number | Amount of storage space requested for this drive |
[Ljava.lang.Object;@987dbdf | ch.dunes.model.dunes.ScriptModuleParameter@3674125c | string | Drive letter for this additional storage |
[Ljava.lang.Object;@7e6171f1 | ch.dunes.model.dunes.ScriptModuleParameter@2f7fc609 | string | Drive Label Name |
[Ljava.lang.Object;@6da2913b | ch.dunes.model.dunes.ScriptModuleParameter@4becf0b8 | boolean | Add additional storage |
[Ljava.lang.Object;@30afe6f9 | ch.dunes.model.dunes.ScriptModuleParameter@6c64fe67 | number | Amount of storage space requested for this drive |
[Ljava.lang.Object;@5a7a53c9 | ch.dunes.model.dunes.ScriptModuleParameter@1512df87 | string | Drive letter for this additional storage |
[Ljava.lang.Object;@a1122e0 | ch.dunes.model.dunes.ScriptModuleParameter@6b08a549 | string | Drive Label Name |
[Ljava.lang.Object;@49b9285 | ch.dunes.model.dunes.ScriptModuleParameter@1b05c20 | boolean | Add additional storage |
[Ljava.lang.Object;@617039bd | ch.dunes.model.dunes.ScriptModuleParameter@eded945 | number | Amount of storage space requested for this drive |
[Ljava.lang.Object;@488a48a3 | ch.dunes.model.dunes.ScriptModuleParameter@6ea6ea89 | string | Drive letter for this additional storage |
[Ljava.lang.Object;@10700120 | ch.dunes.model.dunes.ScriptModuleParameter@2959e44e | string | Drive Label Name |
[Ljava.lang.Object;@4c9bd217 | ch.dunes.model.dunes.ScriptModuleParameter@9fe0b4c | boolean | Add additional storage |
[Ljava.lang.Object;@597afb4 | ch.dunes.model.dunes.ScriptModuleParameter@2990554a | number | Amount of storage space requested for this drive |
[Ljava.lang.Object;@42cf8297 | ch.dunes.model.dunes.ScriptModuleParameter@4586a9c5 | string | Drive letter for this additional storage |
[Ljava.lang.Object;@bf3e82c | ch.dunes.model.dunes.ScriptModuleParameter@3a0fa6d5 | string | Drive Label Name |
[Ljava.lang.Object;@599207ba | ch.dunes.model.dunes.ScriptModuleParameter@2397247 | number | The total amount of storage requested that is equal to or less then 500GB |
[Ljava.lang.Object;@97d9475 | ch.dunes.model.dunes.ScriptModuleParameter@139d9231 | string | Does the total amount of requested storage match the storage policy of less than or equal to 500GB |
[Ljava.lang.Object;@4de8d906 | ch.dunes.model.dunes.ScriptModuleParameter@720040df | string | Description for this request |
[Ljava.lang.Object;@6ea32af1 | ch.dunes.model.dunes.ScriptModuleParameter@1a586cf6 | string | Will this request be fully managed or flex management |
[Ljava.lang.Object;@235997fd | ch.dunes.model.dunes.ScriptModuleParameter@4f09752c | string | Service Level Agreement |
[Ljava.lang.Object;@75ebc43d | ch.dunes.model.dunes.ScriptModuleParameter@49a0bd46 | string | Data Center location by city name |
[Ljava.lang.Object;@57ea646d | ch.dunes.model.dunes.ScriptModuleParameter@5d675d32 | string | Primary Business Unit this request is for |
[Ljava.lang.Object;@2d17ad86 | ch.dunes.model.dunes.ScriptModuleParameter@6d814f8a | string | Bussiness Segment of the Business Unit |
[Ljava.lang.Object;@448d2530 | ch.dunes.model.dunes.ScriptModuleParameter@e849579 | string | Server function in the environment |
[Ljava.lang.Object;@22714261 | ch.dunes.model.dunes.ScriptModuleParameter@39bcfff1 | string | Server Environment Choice - Production, Development, QA, DR, Sandbox |
[Ljava.lang.Object;@274744d4 | ch.dunes.model.dunes.ScriptModuleParameter@37f7ce71 | string | Network Environment based on zone and security trust zones |
[Ljava.lang.Object;@6e12796b | ch.dunes.model.dunes.ScriptModuleParameter@7ee19841 | string | DNS Domain you would like the virtual machine to be in |
[Ljava.lang.Object;@cd3147b | ch.dunes.model.dunes.ScriptModuleParameter@75e59dd0 | number | Cost Center number for billing purposes |
[Ljava.lang.Object;@35dbff28 | ch.dunes.model.dunes.ScriptModuleParameter@7e4cb6b7 | string | Technical Contact Group for this request |
[Ljava.lang.Object;@5e6fe928 | ch.dunes.model.dunes.ScriptModuleParameter@5347188 | string | Technical Contact User for this request |
[Ljava.lang.Object;@36099a63 | ch.dunes.model.dunes.ScriptModuleParameter@3076f54c | string | Service level offering based on size |
[Ljava.lang.Object;@51e2696f | ch.dunes.model.dunes.ScriptModuleParameter@67782068 | string | Reservation confirmation number |
[Ljava.lang.Object;@7f97c0e9 | ch.dunes.model.dunes.ScriptModuleParameter@43fa4270 | string | Reason for the request |
You are correct custom actions are for day 2 operations.
I am doing similar to what you are doing.
Thanks a ton.
There is a blueprint and there is ASD. The user can see both -- blueprint and ASD in catalog items. Is there a way to hide blueprint so that user only sees ASD?
Put the blueprints in their own Service. Entitle the service but deactivate it. It makes the catalog items entitled but invisible to the end user. Steve actually found this... I am just retelling.
I have a different way to do it altogether, but you would have to change directions some.
Sean, Thank you.
Let us know your way too
Well I guess I will just give you the premise.
General Concept: Provision As a Service Account User in the business group and change owner
Implementation
One disclosure... I do not have this implemented. It is only conceptual based off of doing all these "parts" in some form or another. I am fairly positive that I could get this to work however... but I am super busy in other areas right now.
I do plan on setting up a standing example in the next week or so for my own learning and discovery. I will try to share what I find.
Edit:
It might be a little confusing... but this is what is happening.
The service account is entitled to request/provision machines via machine blueprints. (so it owns machines - briefly)
The user is entitled to request an ASD Service Blueprint. (where the workflow has the service account do the work and changes the owner back to the user)
The user only has one blueprint to see, so the base machine blueprint doesn't need to be hidden through the Services hack.
hmm... deactive service did hide the service but it also made it not accessible from VCO. The error is "Catalog Item not found "
Is the individual catalog item ALSO entitled directly?
I might be a bit late to the party here, but the best way to do this is to create the blueprint and entitle it to the user you have configured in the vRA vRO plugin. Then create a service blueprint and use the 'request catalogue item' ootb workflow to call the blueprint you have published to the vRO service account.. The service account will then call the blueprint and provision the virtual machines however the service account own the virtual machines. So, once the virtual machines have been provisioned, you need to call the reconfigure action item and change the owner to the __asd_requestedBy value that gets populated when the user requested the service blueprint via ASD. Make sure you have the reconfigure action entitlement on the service account entitlement.
If you publish the blueprint and assign it to a service that only the vRA plugin service account has been entitled to, the end user does not see the published blueprint but only sees the service blueprint published catalogue item (the ASD form). Using ASD, you can get an interactive dynamic form and calculate request logic before you submit the request (ideal for __reservationPolicyId and vrm.datacenter.location). What more, you can do this for MMBP and even application services requests. At the end of the day, it's just a framework you hook in to once you have got he thing set up. Let me know if this is any help and if you need more info and I can send you a workflow that does all this.
Oli
Thanks Oliver it helped.
Please attach the workflow.
>>> the best way to do this is to create the blueprint and entitle it to the user you have configured in the vRA vRO plugin
Soooo... like the 13th reply to this question? :smileygrin: (... at least there is somebody out there in agreement...)
Only... there have been a couple of models that have come about for ownership changes that do not require the "reconfigure" action. I would definitely not recommend using "reconfigure" (via REST or Run Resource Action) for ownership changes when you can do this...
https://communities.vmware.com/people/flynmooney/blog/2015/03/20/change-vcac-vm-owner