vCAC and vCO build order

[TheVMinator]

I am waiting for my vCAC deployment project to start.  Meanwhile I have Orchestrator up and running.  If i create workflows for things like provisioning Vms, adding RAM, etc. now in vCO, will I need to rewrite them later when I deploy vCAC?  Is it better to do vCAC and vCO workflows at once or what in vCO can be done ahead of time?

[GMCON]

I think you really need to look at what you can do with vCAC itself instead of vCO.  The things you mention deploying VM's adding RAM etc are all things you can already do natively from within vCAC so there is honestly no reason to duplicate that in vCO unless you have some sort of unique need.

[GrantOrchardVMw]

Take a look at the Hands on Labs (1421 is vRA) to get an idea of what you can do without Orchestrator.

Grant

[TheVMinator]

Thanks for the input.  The entire provisioning process for a VM is going to involve:

1. Creating Vm from template

2. Requesting IP from external IPAM solution

3.  Requesting new DNS entry

4.  Updating the CMDB with the VM information

5.  Updating third party monitoring system with VM information

So some of this requires some custom coding and hitting 3rd party APIs with vCO plugins.  True I can do some things natively with vRA.  however, VRO I have now, and vRA will be a wait in my company.  If I plan to do some things in vRA as part of provisioning a new VM, but I can't do all things, then later I have to go and change my workflow to add all the custom integration with 3rd party tools as part of the provisioning process.  vRO is the thing that is installed and running now, not vRA, so right now I want to limit my efforts to what I can do in vRO.  But later I don't want to recode things once vRA is installed.

For example, say I create a custom plug-in in vRO to update a CMDB when a VM is provisioned.  Once we get vRA deployed, can I go back and pull that existing workflow into vRA and make it part of my provisioning process, or are there gotachas / caveats to that "Stepwise" development process where I create stuff in vRO with the intention of bringing it into vRA later?

Thanks!

[GrantOrchardVMw]

You can certainly "create now, use later". The thing is that some of the classes you will be passing only exist in vRA. So, the implication is that you can get the workflows created and working but you will need to do some modifications after the fact to get the integration with vRA working.

In terms of your bullet points:

1. Out of the box functionality.

2. Which IPAM are you using? Infoblox have a plugin on VMware Solution Exchange that you can use if that's your solution.

3. I'm assuming this isn't for Windows boxes which would handle this as part of a domain joining process? I've seen a workflow for this - I thought johndias had created it, however I can't find it after a 30 second effort on Google. I'm sure I can find it with a little more time.

4. Again, which CMDB are you talking? SNOW and BMC have plugins for vCO on Solution Exchange that you could make use of to save yourself some effort.

5. This is probably where I'd spend most of my time.

Hope that helps!

Grant

[TheVMinator]

ok great thanks for the info.  I was aware that there are plug-ins and so on for integrating with ticketing systems, infoblox (which we are using) and cmdbs (which we haven't chosen yet).  The main concern that I have is having to redo my vCO workflows when I get around to installing VCAC.   If that isn't a problem, then I can go ahead and make progress creating my workflows and getting integration with infoblox, AD joining, cmdb integration (when we pick one) and so on.  Then later pull these workflows into advanced service designer in VCAC and make them part of my official provisioning process.

However If I have to do a lot of recoding of plugins, or big changes to workflows in VCO, then I would rather wait until I'm deploying everything as one solution.  In the interest of time, I'd rather do as much now as I can do.  In this scenario what do you think?

[stvkpln]

The bottom line here is that you need to know where inputs are coming from in a workflow to properly architect it. I'd say you can start experimenting with capabilities of the plugins that are relevant to get a better idea of the available functionality.. and even maybe start putting together workflows that may or may not be useful... But, without knowing how you're going to feed those inputs and what needs to be hard coded where, it may be difficult. Your best bet is to start mapping out what the tasks you need to accomplish are, determine what information each of those tasks need to have available to meet a successful criteria, then start working backwards to determine where that information gets populated from. It'll end up saving you a lot of time in the long run.

[TheVMinator]

OK thanks - that makes sense.  Basically once I convert my vCO workflows into a design where they will be called by vCAC, then the inputs would change for those workflows.  Instead of being an input from a vCO webpage or vCO client or vCO HTTP Rest, the input would start coming from a vCAC call.   Thus my workflows would need to be modified when I introduced VCAC into the picture.  If a virtual machine provisioning operation started with the input coming from VCAC, and then there were 5 workflows in VCO that executed in sequence before control passed back to VCAC, then those 5 workflows would have the same inputs, because they are just taking inputs from the vCO workflow before them.  Then the output of the last workflow, if it passes control back to VCAC, would also change when VCAC was introduced later.

So perhaps if I have 5 workflows that will receive inputs from other workflows in VCO, and pass outputs only to other workflows in VCO - would that be a good place to start actually creating workflows, since that chain of workflows would be unmodified once VCAC is introduced?  Or not necessarily?

[stvkpln]

I don't know that you'd be changing the workflow so much as changing how the workflow itself is being called. Typically, what I do is build out a set of workflows, then wrap them instead of a master workflow for each state. That way, you have the master pull together the values necessary from vCAC, then feed them directly into the workflow.. but, it will somewhat depend on where your initiating the value collection. I tend to want to have all of my metadata in one of two places:  vCAC (via custom properties) or vCenter (for network value configuration).