Custom Request Form

[shankm]

Hi all,

I am somewhat new to vRA and have a requirement (not sure if it is even possible) to be able to select things like - template, network, software components to install on the request form.

I have seen some vRA custom properties which allow you to add values into software components and vRO work flows that allow you to choose templates, but have not been able to find a way to select which software components to install upon a request.

I have found this; How can I allow software components to be chosen on the request page in vRA 7?  Which is mroe vRA 6, I am hoping there is a clean way to do everything we require.

Thanks!

[jburen]

Here is an example of customizing request forms: Customizing request forms using the new Custom Forms - VMware Cloud Management

[daphnissov]

Yes, it's possible to do basically all of these (although not software components unless you're using a config management tool). You'll have to be more specific as to what you want.

[shankm]

Essentially what has been requested is the ability to have a blueprint where any existing piece of software that can be installed through vRA/ vRO, network, template and datacenter to be an optional install, however not required.

Making the request form completely modular and up to the requestor to choose what bits and pieces they want.

[daphnissov]

So, again, yes, that is all entirely possible, but it's still not specific enough. I'm not sure what you're asking here, exactly. Is it a "can this be done?" or is it a "how exactly do you do this?" If it's the former, the answer is "yes"; if the latter you'll need to be more specific. As with most automation systems, there are near limitless ways tasks can be done, but without more specific requirements it's anyone's guess.

[shankm]

It's more of a how can it be done, as mentioned i'm somewhat new to all of this and am happy to provide details, just not entirely sure what information you require. 

Have you got some specific questions that I can answer ?

[daphnissov]

Have you got some specific questions that I can answer ?

Yes, you say "software through vRA/vRO". What does that mean, exactly? How is software being installed today? There are dozens of ways to install software through vRA. Is it software components? Is it Ansible? Puppet? Existing scripts triggered somehow? Something else?

In general, explaining how this can be done is 1.) not a trivial task and 2.) may be completely irrelevant based on you/your customer's constraints. It would be better to tell me why you're asking this as I can probably provide a better answer.

[shankm]

thanks for the response,

Software is currently being installed using software components and are just powershell scripts pulling software off a share, once way I was thinking of doing it is to create a wrapper setting something like a true / false statement, then in vRA use a property dictionary and set a drop down to trigger either of these values.

[daphnissov]

Ok, so this is all important information. If you're using software components, there's not a simple, direct way because these use the generic endpoint framework to provide canvas integration. One way (there are multiple) I would envision you could do this with custom forms would be the following.

1. Have only one software component which is essentially a wrapper or framework for running PS scripts.
2. Have one input (property) which supplies the name of the script.
3. Depending on where these scripts are stored, pull them in with a vRO action that sets the value of a custom property to be the script name.
4. Bind that custom property to the software component property so, when it runs, it gets the value of the custom property. This custom property would have to be placed on the machine object within the canvas to allow binding (there are some workarounds otherwise).
5. Create a custom form which uses said vRO action to dynamically populate a drop-down list with these scripts.
6. Each time catalog item is requested, custom form loads, and vRO action runs, the user gets a refreshed view of the available software components available. User can then select one and submit the form.

This does come with some downsides, however.

1. Software component code is fairly limited. Cannot use multiple, disparate properties based on script.
2. Error handling is up to you in the script.
3. Governance is also on you to determine what users should and shouldn't be able to install. (ex., Is it OK if I install Oracle that costs you $10K a seat? No? Who's allowed, then?)
4. Makes reporting, costing, and auditing more difficult because only a single software component is ever referenced.

Always remember that flexibility and providing choice comes at a cost. If you want to provide users more choice, you give them more opportunity to screw something up. If you give them less choice you potentially create more blueprints but provide better guard rails for them to not shoot themselves (or you). Everything is a trade-off when it comes to automation.