vCAC 6.0.1 - Hide Machine Resources (#CPUs, MemoryMB, StorageGB) in Blueprint

[pwmiller]

Hi All,

We're trying to hide the above fields for our deployment, relying on a drop-down box for CPU/Memory/Disk configuration through setting custom properties. Unfortunately, the inputs for #CPUs, MemoryMB and StorageGB are still visible to the end-user doing the provisioning. This is undesirable, as we want them to select from pre-defined, discrete values.

For example, when I select "Small", I get a VM with 1 vCPU and 2GB RAM. When I select "Medium", I get a VM with 2vCPUs and 4GB RAM. The configuration of these properties is currently done in vCO; all I want to do is hide the inputs for CPU/ Memory/ Disk so that the user doing the provisioning is not confused.

To elaborate:

Additionally, I've configured the property dictionary to give some context around this sizing dropdown, through the use of a property dictionary with a 'notes' and 'label' property. These don't display on the blueprint when deploying! Is this a bug? See the following for what I mean:

The documentation seems to indicate that I can use these to wrap some context around the deployments (eg. add notes and labels). Can somebody please elaborate as to how these are used?

Thanks,

[qc4vmware]

I too inquired about this with what looks like many others like yourself.  Its shocking that in this version you still can't suppress those fields.  Luckily you can override them at deployment time but it sure looks messy.  Eventually when the discovery runs on the compute resources vCAC will also update to reflect the correct size although initially things will be out of whack.  I tried to wrap this with an advanced service but that too will FAIL (sort of).  You can indeed deploy the IaaS blueprint but it will never show up in your inventory since the vCAC plugin is really just for the IaaS piece of the product. They will hopefully be filling those gaps soon in the vCO plugin.  For now you are stuck with it as is... keep complaining... complain to everyone you can.  Anyone else who reads this that is annoyed please like the post or chime in.  These threads are so silent but at least a like lets those that monitor the list know you are in agreement.

[qc4vmware]

I just attempted the second part of your question about the labels and notes properties.  They worked for me.  You need to add them to the blueprint or to a build profile included in the blueprint as well after you have created them in the property dictionary.  Did you complete that piece?

[pwmiller]

Interesting. I had some luck in actually allowing those values <Memory, CPU) to show the correct size post-provisioning by changing the VirtualMachines model from a stub on buildingmachine - this is without having to do discovery. That was with help from this article from vcoteam: http://www.virtualization-news.com/5452-vco-team-working-with-vcloud-automation-center-iaas-entities....

I'm not sure the problem is with the vCO plugin - I think the problem is with the integration between the UI components for IaaS. While IaaS exposes the isHidden property for these attributes, I don't think that it takes these properties into account. Maybe we can edit the webpage on the IaaS machine to hide these properties, or at least expose the 'isHidden' parameter to them?

I'll take a second look at the labels and notes tomorrow - I sear I attached them to both the build profile and blueprint.

[UserVcac]

Hey!

Did you finaly find a solution to hide ressources?

I'am on the same situation.
Thank you

[pwmiller]

There doesn't seem to be a supported solution to this problem in this release. The best we've been able to do is to set the maximum to the minimum, which disables editing of these fields.

VMware - if we can get more flexibility over the presentation of IaaS blueprints in 6.1, that would be super. There seems to be a large discrepancy between how these blueprints are treated and how the XaaS blueprints are treated (the XaaS are much more configurable and flexible).

[flynmooney]

Nothing changed in regard to this on 6.2 that I can find.

[Michael_Rudloff]

Especially silly when you deploy physical machines with vCAC - you still have those fields and the only way to do is like someone mentioned - set the minimum to the actual physical resources.

[prestonville]

I'm trying to do the same with fixed small, medium & large VMs at provisioning time but also want to allow for some entitled users the ability to reconfigure CPU/RAM as a 2nd day operation on the deployed VMs. If we do the setting of a minimum value only (no max) on the CPU/RAM fields to "fix" them for all provisioning jobs then we have issues on the vRA 2nd day operations. They fail to work for the entitled selected users as uses the blueprint min/max settings as the configurable range. Only solution I can see is add custom vRO workflows for changing vCPU/vRAM as published 2nd day action to replace the inbuilt vRA reconfigure action item.

Can anyone suggest a different way as I like the ease of 2nd day operations with attached approvals rather than writing admittedly simple vRO workflows.  

Again for me hiding these fields is ultimate aim.

Chris

[flynmooney]

If you have ASD you can build a complete solution that masks these fields.  You can build a vCO workflow that accepts the desired inputs from the ASD form and then makes a catalog item request.  In the workflow call 'request a catalog item' with the required properties.  I did this with the vCO service account which will create the VM and set it up and be owned by the service account.  I then change the owner of the VM using a custom property of the user and business group who requested the VM at the end of the MachineProvisioned workflow stub.

This link has some useful information about 'Request a Catalog Item'
How to use and extend the workflow "Request a catalog item" from the vCAC plug-in for vCO